Florent Clairambault

If you use the TC65 to transmit some frequent (with a transmission interval of less than 700 ms) data, you should know that the TC65′s has a poor TCP implementation considering the ACK management of sent messages.

When the TC65 sends a TCP packet, it waits for the ACK packet of this transmitted packet before sending any other packet. That means that if you have a delay 400 ms between the TC65 and your server (which is very quite common), the TC65 will wait for 800 ms (400 ms for the data packet from the TC65 to the server and 400 ms for the ACK packet to return) before sending any data.

I discovered it because I wanted to send real-time GPS tracking data, and at a rate of 20 positions per second it was way above the minimal delay of 800ms. My positions came by packet of 5 to 20.

I asked for help to the french Cinterion’s support with complete description of the problem, “AT^SCFG” complete view and some libpcap network captures. And they couldn’t give me any real solution to this problem.

I think this is a chosen restriction. The chip has a memory of 400 Kb, to use this the chip would have to use a more complex TCP stack and to consume some RAM to store the last not yet aknowledged messages. I might be wrong, there might be a way to activate this, but right now Cinterion isn’t able give me any answer.

The only solution I found is to send data from the TC65 using UDP and to receive data using TCP. And receiving in real-time (I mean short time) DOES work perfectly with the chip (no need for increasing the receive buffer). You just have to disable Nagle’s algorithm (TCP_NODELAY=TRUE) on the remote host (most probably the TCP server).