#SRECV command behavior differences on CE910 from versions 18.01.022 to 18.02.021

10 thoughts on “#SRECV command behavior differences on CE910 from versions 18.01.022 to 18.02.021

  1. I am working with CE910s with firwmare versions 18.01.022 and 18.02.021 on the Verizon network.

    I’ve noticed that the behavior of the #SRECV command is different between the two when using UDP sockets in command mode.

    With version 18.01.022 it looks like each time #SRECV was sent we were guaranteed to receive one, and only one, complete UDP datagram.

    For example, if I dial a UDP socket and receive two messages 50 bytes long, the AT#SI command would show that there is 100 bytes of data in “buff_in”. With firmware version 18.01.022, If we issue AT#SRECV=1,100 the modem would return only the first 50 byte message. In the same scenario, it looks like the 18.02.021 modem will return the full 100 bytes compromising both messages. Is this assessment accurate? Was the AT#SRECV command changed between these two firmware versions?

    In the latest AT command documentation for version 18.02.021, I see that there was an optional parameter added to the AT#SRECV command to return the “UDPInfo” with the socket read. I was hoping that using this optional parameter would revert the behavior to 18.01.022 but I only get ERROR when I try to use this parameter:







    #SI: 1,0,0,0,0
    #SI: 2,13,0,14,0
    #SI: 3,0,0,0,0
    #SI: 4,0,0,0,0
    #SI: 5,0,0,0,0
    #SI: 6,0,0,0,0



    I dial a socket, send a message, get a response, try to read the response with the UDPInfo parameter set to 1 and the modem returns ERROR. What do I need to do in order to get the optional parameter working?

    1. Has anyone else gotten the optional <UDPInfo> parameter of the #SRECV command to work with the CE910 running firmware version 18.02.021?

        1. AT+GMR



          #SRECV: (1-6),(1-1500)


          So I am mistaken, 18.02.021 does not support the UDPInfo parameter. I will update my test device to 18.02.023 and see if it gives me the behavior I am looking for.

          Is 18.02.023 the latest firmware release for the CE910 DUAL? Is there a complete AT command set reference for this version? The latest Telit_CE910_Series_AT_Commands_Reference_Guide_r8.pdf says it only applies to 18.02.022 for Verizon

          1. Hello Scott,

            Yes, now the 18.02.023 is the latest firmware for CE910 DUAL.

            Also, Telit_CE910_Series_AT_Commands_Reference_Guide_r8.pdf is the latest document for CE910 DUAL now.

  2. I upgraded my modem to 18.02.023 and am able to use the UDPInfo parameter:





    #SRECV: (1-6),(1-1500),(0,1)


    However, it still has the same behavior of concatenating datagrams that I explained in my first post.

    For example, I sent a message to a remote server and it sent back two distinct UDP datagrams, one 26 bytes long and one 14 bytes long. AT#SI shows 40 bytes in the RX buffer:

    #SI: 1,0,0,0,0
    #SI: 2,71,27,40,0
    #SI: 3,0,0,0,0
    #SI: 4,0,0,0,0
    #SI: 5,0,0,0,0
    #SI: 6,0,0,0,0

    In firmware version 18.01.022 when I would send AT#SRECV=2,40 It would only return the 26 bytes of the first datagram. I would have to issue another AT#SRECV command to get the next 14 byte datagram. In other words, each time I sent AT#SRECV I would get one, and only one, datagram.

    With firmware 18.02.023, when I issue AT#SRECV=2,40,1 it gives me the full 40 bytes of both messages (I changed IP/port to dummy values in my example):


    #SRECV: “”,50000,2,40,0

    [40 bytes of data follows]

    Why does the #SRECV command work differently between 18.01.022 and 18.02.023?

      1. Ok then I dont understand why the documentation for #SRECV says this:
        0 – UDP information disabled ( default )
        1 – UDP information enabled: data are read just until the end of the UDP
        datagram and the response carries information about the remote IP address and
        port and about the remaining bytes in the datagram.
        #SRECV: <sourceIP>,<sourcePort><connId>,<recData>,

        When I set UDPInfo=1 it still seems to concatenate datagrams. Why does the documentation imply that it wont concatenate when in reality it does? Is there any way I can read data in command mode one datagram at a time?

        This change in behavior is fairly significant and impacts our development

        1. You can know the data arriving by “SRING” URC.

          But this URC is issued when <buff_in> of “AT#SI” is 0.

          This means that you have to issue “AT#SRECV” before the next data arriving.

          In the other way,

          If you set <srMode> as 2, then you don’t need to issue #SRECV to read the data.

          And the “SRING” URC display the data like below.

          <srMode>:2, <dataMode>:0 (text mode)


          > aaaaaaaaaa

          SRING: 1,10,aaaaaaaaaa

          <srMode>:2, <dataMode>:1 (hexadecimal number mode)


          > aaaaa

          SRING: 1,5,6161616161

          Please refer to the “AT#SCFGEXT” command.