Difference between KTCPSTART and KTCPSND


I was wondering what the difference between the commands KTCPSTART and KTCPSND is.

Other than the fact that you can tell the module exactly how many bytes you want to send with KTCPSND,
I can’t see any difference.

However, KTCPSND returns more often the NO_CARRIER reply when large amounts of data (>20kB) are being sent which take more time for the module to receive via UART.

Is there a reason for this?

Can I use the two commands interchangeably?
My scheme as it is now consists of: AT+KTCPCNX and then AT+KTCPSND
Can I replace KTCPSND with KTCPSTART with no troubles?


+KTCPSTART can receive data

So if i just use KTCPSTART, send data, give EOF pattern then I can use it again in the same TCP connection as I am doing with KTCPSND at the moment?

In my application I use KTCPSND many times during one TCP communication so I was wondering if I can now use KTCPSTART as many times i’d like.


actually you don’t need to quit the data mode when using KTCPSTART

I know but I am trying to keep the code changes minimum.

It seems to be working fine with KTCPSTART used over and over.


After a bit of research, I realized that the module is dropping the TCP connection when sending large amounts of data with both KTCPSTART and KTCPSND after getting the NO CARRIER reply.

I can see the data being received with Wireshark on the PC side and then i get the no carrier and connection is dropped. Is there some sort of timeout occurring ?

Are you using uart?
Did you enable flow control?
How many data would make the “no carrier”?
Is this network drop?

I am using UART with hardware flow control. Data are 26kB so it takes quite a bit for the module to send all of it…
Here’s the Mosquitto MQTT broker side:

1646235359: Received PUBLISH from aseru (d0, q0, r0, m0, ‘3546xxxxxx258xx’, … (26010 bytes))
1646235359: Client aseru closed its connection.

So the module sometimes sends the PUBLISH message but it doesn’t return OK. It returns NO CARRIER and then any subsequent try to send anything fails.

You can setup a tcp server, ask module to send 26k of 0x31 data instead of mqtt data, and see if this is related to the content of data

BTW, Is this network drop in AT+CEREG?

I tried that and the result is the same.

When the payload is large the module needs time to send it all, it returns NO CARRIER and connection is down.

I still think it might be some sort of a timeout occurring inside the module. Network is not dropped in CEREG.
At least the module does not give any indication (after at+cereg=1).

From Wireshark I can see that whenever the NO CARRIER reply occurs, there is a “TCP Previous segment not captured” message which would indicate packet loss?

However, sometimes I receive the PUBLISH message even though the “TCP Previous segment not captured” message appears…