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:
AT#SI#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,0OK
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?
Has anyone else gotten the optional <UDPInfo> parameter of the #SRECV command to work with the CE910 running firmware version 18.02.021?
You can check the compatibility of command with “AT Command=?”.
And I checked that the <UDPInfo> is supported on the below firmware.
Would you please re-try with this firmware?
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
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.
I upgraded my modem to 18.02.023 and am able to use the UDPInfo parameter:
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:
AT#SI#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):
[40 bytes of data follows]
Why does the #SRECV command work differently between 18.01.022 and 18.02.023?
There have been a change in #SRECV command due to some chainging of packet receiving mechanism.
Since the time, #SRECV command return all of data in <buff_in>.
Ok then I dont understand why the documentation for #SRECV says this: <UDPInfo>0 – UDP information disabled ( default )1 – UDP information enabled: data are read just until the end of the UDPdatagram and the response carries information about the remote IP address andport and about the remaining bytes in the datagram.AT#SRECV=<connId>,<maxBytes>,1#SRECV: <sourceIP>,<sourcePort><connId>,<recData>,<dataLeft>data
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
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)
<srMode>:2, <dataMode>:1 (hexadecimal number mode)
Please refer to the “AT#SCFGEXT” command.
Or simply put in place packet begin/end markers in your data.
Hit enter to search or ESC to close
Knowledge Base & Download Zone