Slow Data Transfer with AT#SKTL on GE864-QUAD

18 thoughts on “Slow Data Transfer with AT#SKTL on GE864-QUAD

  1. I am using the GE864-QUAD with firmware 07.02.204 and I am having problems very slow data transfer after using the AT#SKTL command.  

    The Telit GE864-QUAD receives the incoming connection and CONNECTs OK to the incoming device but the data transfer can be very slow (sometimes 15 seconds delays then a rush of lots of packets at once).

    It is like it is buffering the data somehow even though I have set the Data Sending timeout to 1 second and the packet size to be 100 bytes.  The data transfer in the other direction where the modem CONNECTs to the other device using the command AT#SKTD always works OK and the delays are relatively small (a second or two at the most).

    Here are some of the commands I have used to configure the GE864-QUAD.


    AT#FRWL=1,”″,”″ (allow all addresses)
    AT#GPRS=1 (activate GPRS)
    AT#SKTL=1,0,1000,0  (listen on port 1000 for incoming connections)



    I am using telnet as a test client to connect to the GE864-QUAD – it is normally different
    software but the results are the same

    telnet 1000

    What would the benefits be of using the Improving Socket Listen command AT@SKTL instead of command AT#SKTL?  Does anyone know what version of firmware for the GE864-QUAD has got this command? – 07.02.204 does not seem to have it available.



  2. Is hard to say, maybe the network is slow, do you have a chance to try another service? How is it configured, with and addresses?

    Also check AT#MSCLASS, signal level and quality. Do outgoing connections work better? 

  3. Thanks Cosmin.

    "Is hard to say, maybe the network is slow, do you have a chance to try another service? How is it configured, with and addresses?"

    >  I don’t think it is the network – we have tried another Fixed IP SIM on a different VPN and network and the delays are still apparent.
    The same data transfer but initiated by the Telit modem connecting to the server using the AT#SKTD command takes 30 secs compared to 2.5 mins
    when the server connects to the Telit modem that is listening using the command AT#SKTD.

    "Also check AT#MSCLASS, signal level and quality. Do outgoing connections work better?"

    >  AT#MSCLASS? returns 10.  I have tried changing it to AT#MSCLASS=5,1 and AT#MSCLASS=8,1 and it made no noticable difference. 
    Yes, outgoing connections work a lot better, as above.

    I have upgraded to firmware 7.02.204 but the improving AT@SKTL command is still not available. 



    #SKTL: 0,0,0,0


    The Telit AT command Reference PDF says that this should be available but it does not appear to be.  Does anyone know why this might be?

    1. I sent you download links to some newer firmware, please try them. @SKTL should be available in 7.03.xx1.

  4. Thanks for the download links.  We have got the PC hardware to do the Telit firmware upgrades and have used the TFI software with success in the past to do the upgrades.


    However, using the same COM port and baud rate settings (COM1, 115200 baud), we cannot get the XFP type upgrades to work.  We have even tried slower baud rates (9600) but it still does not work.


    We have followed the instructions with the XFP software and power the modem on after pressing the Program button.   Any ideas what we might be doing wrong?



  5. Cosmin

    We have managed to upgrade the GE864-QUAD modems to the 7.03.001 firmware using XFP.

    There are two serial port connectors on the upgrader hardware.  Both seem to work with the TFI software but only the top one seems to work with the XFP software.  We got it working on the top port with both a real serial cable and a serial to USB converter.

    I have tried the new firmware and the AT@SKTL command still does not seem to be there.  I have also tried the same AT#SKTL command and it seems to give the same result (very slow transfer rate).

    #SKTL: 0,0,0,0

    1. as you can see on the AT Commands Reference Guide the @SKTL is only available for #SELINT=0/1 interface. The default #SELINT for GE864/GC864/GE865 is #SELINT=2


      Anyway I recommend to use the new set of commands (not so new…it is available since 7.02.003), #SGACT, #SD, #SL…on #SELINT=2.


    Thanks Andrea


    I tried the AT#SL command as you suggested and the communications were no better – I think it was even slower taking on average 3.5 mins instead of 30 secs in the other direction using AT#SD or AT#SKTD.


    What flow control settings do you recommend – the default settings?

    1. Of course hardware flow control is the preferred choice; if you don’t use take care to disable it (AT&K) to prevent surprises from free shaky  RTS/CTS lines.

  7. A quick update on this thread in case this helps anyone out.

    We made a small (one line) change to the PC application that connects to the remote logger with Telit GE864 QUAD modem and it is working well now.

    We removed the following lines

    int on = 1;
    setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)&on, sizeof(on));

    from the socket_connect routine and the speed increased by about 3-4 times when the remote device had a Telit GE864 modem.  The other modem we hae used previously does not seem to be affected by this command nearly as much.

    Although it is still not as fast (about 1/3 slower) as a different type of modem that we used in the past for the same application, that modem is no longer made and we are now happy with the Telit GE864 QUAD for this application where the PC connects to the Fixed IP logger with Telit modem and reads the data from it.

    1. Well Jamie, I think this is another application that the one with problems above, which uses module’s internal TCP/IP stack. Looks like the one in your latest post uses host’s (PC) stack which is a completely another situation, isn’t it?

  8. Sorry it is a bit confusing.

    You are correct – the solution was not to modify the AT commands etc used to configure the TCP/IP settings on the Telit modem itself but to modify our PC application that Connects to the Remote Data Loggers with Telit modem using a Fixed IP address and port.

    It is just interesting that with the TCP_NODELAY setting applied at the PC software end, the performance was very poor.  When this setting was taken away the speed of data transfer increased by 3-4 times without changing any TCP/IP settings on the Telit.  With a different modem in the data logger, the TCP_NODELAY setting at the PC end seems to
    make no difference.

    1. Very interesting, TCP NODELAY is to enable/disable Nagle buffering algorithm, there are a lot of discussions on the net regarding this.


        TCP_NODELAY is for a specific purpose; to disable the Nagle buffering
        algorithm. It should only be set for applications that send frequent
        small bursts of information without getting an immediate response,
        where timely delivery of data is required (the canonical example is
        mouse movements).