receive UDP on nRF9160-dk SLM application

[AndMar8]

Hi,

I want to receive UPD message on my nRF9160-DK.

I can send UDP messages from my Nordic device to a server and from that messages I get the public IP address of my module. But when I try to receive messages, I don't receive anything.  

I use the serial LTE modem application.

I see the following links to send messages:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/TCPIP_AT_commands.html#udp-receive-data-xrecvfrom

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/slm_description.html

First try:

AT#XSOCKET=1,2,0

#XSOCKET: 1, 2, 0, 17

OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"

#XSENDTO: 8

OK

AT#XSOCKET=0

#XSOCKET: 0, closed

OK

AT#XSOCKET=1,2,1

#XSOCKET: 1, 2, 1, 17

OK

AT#XBIND=3442

OK

AT#XRECVFROM

and after this I get: "Error: 'AT#XRECVFROM' timed out"  and I cannot send AT command to LTE Link Monitor.

-------------------------------------------------------------------------

Second try:

AT#XSOCKET=1,2,0

#XSOCKET: 1, 2, 0, 17

OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"

#XSENDTO: 8

OK

AT#XSOCKET=0

#XSOCKET: 0, closed

OK

AT#XSOCKET=1,2,1

#XSOCKET: 1, 2, 1, 17

OK

AT#UDPRECVFROM="x.x.x.x",3442

+CME: 0

Here I don't know how to solve this error.


-------------------------------------------------------------------------

Third try:

I set the UDP proxy to use the command AT#XUDPSVR;
So in "Configure nRF Connect SDK Project" I select "Stateful connection-oriented UDP client/server <SLM_UDP_PROXY>"

AT#XUDPCLI=1,"x.x.x.x",20080

#XUDPCLI: 1 connected

OK

%CESQ: 32,1,19,2

%CESQ: 29,1,24,3

AT#XUDPSEND=1,"Test UDP"

#XUDPSEND: 8

OK

AT#XUDPCLI=0

#XUDPCLI: disconnected

OK

AT#XUDPSVR=1,3442 or AT#XUDPSVR=2,3442

#XUDPSVR: 1 started

OK

Here it seems to work but I don't receive anything and retrying I get sometimes: "Error: 'AT#XUDPSVR=1,3442 ' timed out"

I try using the IP that I get in the receiving messages and also with the IP that I get with the command "AT+CGDCONT?"

I try also using the example script "client_udp.py" but nothing.

I try many times with all possible combinations.

What can I do? The nRF9160-DK receives messages but doesn't print them on the LTE Link Monitor or I'm using wrong AT command? Is there an error in the client code? Is the IP that I use the error? Is it possible that my server doesn't know how to reach my APN even if I specify the correct public IP address?

Please, help me to receive a simple "hello".
Thank you in advance.

Best regards

[Didrik Rokhaug]

Hi,

You should not close the socket after sending data, for so to open a new socket that you listen on.

Instead, you should listen on the same socket that you sent data from.

Also, be aware that due to Christmas vacations, response times might be slower than normal.

Best regards,

Didrik

[AndMar8]

Hi,
Thanks for the answer.
I tried without closing the socket but the recvfrom returns always this error: "Error: 'AT#XRECVFROM ' timed out" and always from here I can't send AT command through the LTE Link Monitor.
In the following I put the command used:

First try:

AT#XSOCKET=1,2,1
#XSOCKET: 1, 2, 1, 17
OK

AT#XBIND=3442
OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"
#XSENDTO: 8
OK

AT#XRECVFROM (here stops)

-----------------------------------------------------------

Second try:

AT#XSOCKET=1,2,0
#XSOCKET: 1, 2, 0, 17
OK

AT#XSENDTO="x.x.x.x",20080,1,"Test UDP"
#XSENDTO: 8
OK

AT#XRECVFROM (here stops)

I have to change something in the project file?

I closed socket in previous tries because I thought that I have to set the socket in client mode (AT#XSOCKET=1,2,0) to send messages and in server mode (AT#XSOCKET=1,2,1) to receive messages.

Best regards

 

[Didrik Rokhaug]

AndMar8 said:

I'm sending data using NODE-RED udp-out block. I tested it with different devices and it works.

 Were do you host it? Did you test with devices outside the local (to the server) network?

 

AndMar8 said:

AT#XRECVFROM=[4]

 The "[ ]" in the syntax means that it is an optional parameter. You should either use AT#XRECVFROM, or AT#XRECVFROM=<size>, where <size> is the number of bytes you expect to receive. You should not use "[ ]" in the command.

 

AndMar8 said:

Are these steps right?

 Yes. Assuming the device is already connected to the network.

These commands worked for me:

at#xsocket=1,2,0
#XSOCKET: 1, 2, 0, 17
OK
at#xsendto="x.x.x.x",7,1,"test"
#XSENDTO: 4
OK
at#xrecvfrom
test
#XRECVFROM: 1, 4
OK

[AndMar8]

Hi,

Thanks for the answer.

Yes I tested it with a device outside our local network and the udp packet is correctly received.

I have tried to replcate your steps but at#xrecvfrom command is not recognized and after that the modem stops answer me and i have to reboot the board.

To be clear as much as possible, these are the steps that I do:

1. at+cfun=1
2. at+cfun?
3. after that command start automatic command due to the "automatic requests"
4. after this command:
   at+cgact?
   +cgact: 0,1
   ok
   I send the AT commands that you use
5. at#xsocket=1,2,0
   #XSOCKET: 1, 2, 0, 17
   OK
6. at#xsendto="x.x.x.x",20080,1,"test"
   #XSENDTO: 4
   OK
7. at#xrecvfrom

Here the code stops working and under the terminal in the Log window immediately appears:

09:47:24.974       Error: 'at#xrecvfrom' timed out

From here all AT commands (also a simple AT) returns me this same error (Error: 'at' timed out).

Which's your modem version? What about the firmware? Are you using the slm application?

Thank you very much for the help.
Best regards

[Didrik Rokhaug]

AndMar8 said:

Which's your modem version? What about the firmware? Are you using the slm application?

 mfw v1.2.2, SLM from NCS v1.4.0.

 

AndMar8 said:

09:47:24.974       Error: 'at#xrecvfrom' timed out

 I assume you are using the LTE link monitor?

It is note really meant for this kind of use case, but to communicate with the modem "directly". As such, almost all the AT commands it is "meant" to send returns a reply immediately. It therefore has a fairly short timeout. However, it should not be a problem that a command times out, as long as there is a response eventually.

 

AndMar8 said:

From here all AT commands (also a simple AT) returns me this same error (Error: 'at' timed out).

 The SLM implementation of #RECVFROM is blocking, so this is not surprising.

Can you take a modem trace, so we can analyze the IP traffic?

Also, if you could capture an IP trace from your server, that could also help.

[Achim Kraus]

> The SLM implementation of #RECVFROM is blocking, so this is not surprising.

Sorry to write that, surprising is indeed not the behavior, it's more, that it is implemented in that way. Doesn't this block the modem for new AT-commands until it receives something? If the sent data is lost, you will not be able to even resend it. For me this implementation is very close to "useless"?

[AndMar8]

Hi, Sorry for the delay. I were able to collected the modem Trace. 
Please find attached the zip file containing two modem traces. 

I have also tested the receive mode using a different terminal. I use Termite as both putty and were not able to communicate with the SIP:

Just for knowledge I have tested the sim card with a different modem from Quectel and I was able to receive the data coming from the node-red UDP node.

I have also tested the UDP functionality with a desktop packet receiver and it works as well. 

Here a screen shot from node-red showing the message I am receiving from the SIP. OFC I use the same address and port to send data back to the SIP.

I am starting being clueless about why I am not able to receive the UDP packet using the nrf9160 SIP.

I do not know if it can be useful but, can you please share your firmware HEX files just to test it.

Thank you for your kind help.

nRF9160_recvfrom_trace.zip

[Didrik Rokhaug]

Hi,

I've had a quick look at your traces so far, and I have noticed two things:

1. Neither the IP address or the source port (from the device) matches your screenshot from the server. Are you sure the screenshot is from the nRF9160?

2. The modem never receives an recvfrom RPC call from the application core.

To debug 2 further, could you enable debug logging in the SLM (by setting CONFIG_SLM_LOG_LEVEL=y), and capture the debug log which will be sent over RTT (as well as the UART log and a modem trace)?

But, the device never receives the reply from the server, so even if the recvfrom call had been there, you still wouldn't have seen any response.

[AndMar8]

Hi,

1. I believe that the messages are sent by my device because when I send messages from nRF9160 they appear on the node-red debug messages window (as in the screeshot). However to be sure is there an at command to get the IP address of my nRF9160?

2. Debug:

I didn't find CONFIG_SLM_LOG_LEVEL=y so I guess you mean CONFIG_SLM_LOG_LEVEL_DBG=y (I hope it's correct).

For the debugging I also set in the prj.config file:

CONFIG_USE_SEGGER_RTT=n
CONFIG_RTT_CONSOLE=n
CONFIG_UART_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=y

I attached the zip with modem trace bin, terminal of Termite, logfile of LTE Link Monitor and the prj.config file

nRF9160 log.rar

[Achim Kraus]

Usually, neither the local ip-address your nRF9160 nor the local port you use will be visible at the server. The mobile provider mostly use a NAT, which exchanges that address and port. And because of that NAT, you must respond "in time". I would try to start with less than 30s. 

[Didrik Rokhaug]

AndMar8 said:

I didn't find CONFIG_SLM_LOG_LEVEL=y so I guess you mean CONFIG_SLM_LOG_LEVEL_DBG=y (I hope it's correct).

 Yes, sorry. That was a typo on my part.

I also forgot to mention that you have to comment out the CONFIG_SLM_LOG_LEVEL_INF=y line (or replace it with *_DBG=y).

I have also done some more tests myself, and it doesn't seem like the recvfrom call actually gets registered in the modem trace unless it returns some data.

So the 2nd point in my last comment doesn't seem to be an actual problem, just another indication that the device never receives the response.

 

AndMar8 said:

is there an at command to get the IP address of my nRF9160?

 AT+CGDCONT?

But, it is worth noting what Achim Kraus says about NAT.

[Didrik Rokhaug]

Hi AndMar8,

Could you try the following sequence of commands (with the same server and port)?

AT+CEREG=5
AT+CSCON=1
AT+CFUN=1
// Wait for the nRF9160 to be connected (CEREG 1 or 5)
AT#XSOCKET=1,2,0
AT#XSENDTO="84.215.43.232",56227,1,"<some text here>"
AT#XRECVFROM

You should then end up with a log similar to this (if you have enabled debug logging):

Fullscreen slm_udp_working.txt Download

*** Booting Zephyr OS build v2.4.0-ncs1  ***
Ready
[00:00:00.231,994] <inf> app: Serial LTE Modem
[00:00:00.232,177] <dbg> at_host: TX
52 65 61 64 79 0d 0a                             |Ready..          
[00:00:00.232,177] <dbg> at_host.slm_at_host_init: at_host init done
at+cereg=5
OK
[00:00:06.317,932] <dbg> at_host: RX
61 74 2b 63 65 72 65 67  3d 35                   |at+cereg =5      
[00:00:06.318,450] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:06.328,948] <dbg> at_host: TX
[00:00:06.329,010] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at+cscon=1
OK
[00:00:09.456,085] <dbg> at_host: RX
61 74 2b 63 73 63 6f 6e  3d 31                   |at+cscon =1      
[00:00:09.456,604] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:09.466,735] <dbg> at_host: TX
[00:00:09.466,796] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at+cfun=1
OK
[00:00:12.772,094] <dbg> at_host: RX
61 74 2b 63 66 75 6e 3d  31                      |at+cfun= 1       
[00:00:12.772,613] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:12.844,238] <dbg> at_host: TX
[00:00:12.844,299] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CEREG: 2,"76C1","014A3901",7,0,0,"11100000","11100000"
+CSCON: 1
[00:00:14.167,694] <dbg> at_host: TX
2b 43 45 52 45 47 3a 20  32 2c 22 37 36 43 31 22 |+CEREG:  2,"76C1"
2c 22 30 31 34 41 33 39  30 31 22 2c 37 2c 30 2c |,"014A39 01",7,0,
30 2c 22 31 31 31 30 30  30 30 30 22 2c 22 31 31 |0,"11100 000","11
31 30 30 30 30 30 22 0d  0a                      |100000". .       
[00:00:14.195,556] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     
+CEREG: 5,"76C1","014A3901",7,,,"00000010","00000110"
[00:00:16.082,397] <dbg> at_host: TX
2b 43 45 52 45 47 3a 20  35 2c 22 37 36 43 31 22 |+CEREG:  5,"76C1"
2c 22 30 31 34 41 33 39  30 31 22 2c 37 2c 2c 2c |,"014A39 01",7,,,
22 30 30 30 30 30 30 31  30 22 2c 22 30 30 30 30 |"0000001 0","0000
30 31 31 30 22 0d 0a                             |0110"..          
at+cgdcont?
+CGDCONT: 0,"IP","ibasis.iot","10.160.177.45",0,0
OK
[00:00:18.583,740] <dbg> at_host: RX
61 74 2b 63 67 64 63 6f  6e 74 3f                |at+cgdco nt?     
[00:00:18.584,259] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:18.595,428] <dbg> at_host: TX
2b 43 47 44 43 4f 4e 54  3a 20 30 2c 22 49 50 22 |+CGDCONT : 0,"IP"
2c 22 69 62 61 73 69 73  2e 69 6f 74 22 2c 22 31 |,"ibasis .iot","1
30 2e 31 36 30 2e 31 37  37 2e 34 35 22 2c 30 2c |0.160.17 7.45",0,
30 0d 0a                                         |0..              
[00:00:18.599,945] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
at#xsocket=1,2,0
#XSOCKET: 1, 2, 0, 17
OK
[00:00:24.831,848] <dbg> at_host: RX
61 74 23 78 73 6f 63 6b  65 74 3d 31 2c 32 2c 30 |at#xsock et=1,2,0
[00:00:24.832,366] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:24.842,163] <dbg> at_host: TX
23 58 53 4f 43 4b 45 54  3a 20 31 2c 20 32 2c 20 |#XSOCKET : 1, 2, 
30 2c 20 31 37 0d 0a                             |0, 17..          
[00:00:24.842,163] <dbg> tcpip.do_socket_open: Socket opened
[00:00:24.844,238] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CSCON: 0
[00:00:27.609,008] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     
at#xsendto="84.215.43.232",56227,1,"didrik port test"
#XSENDTO: 16
OK
+CSCON: 1
[00:00:30.552,490] <dbg> at_host: RX
61 74 23 78 73 65 6e 64  74 6f 3d 22 38 34 2e 32 |at#xsend to="84.2
31 35 2e 34 33 2e 32 33  32 22 2c 35 36 32 32 37 |15.43.23 2",56227
2c 31 2c 22 64 69 64 72  69 6b 20 70 6f 72 74 20 |,1,"didr ik port 
74 65 73 74 22                                   |test"            
[00:00:30.552,825] <dbg> tcpip.parse_host_by_ipv4: IPv4 Address 84.215.43.232
[00:00:30.552,856] <dbg> tcpip.do_udp_init: UDP initialized
[00:00:30.553,009] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:30.561,676] <dbg> at_host: TX
23 58 53 45 4e 44 54 4f  3a 20 31 36 0d 0a       |#XSENDTO : 16..  
[00:00:30.561,706] <dbg> tcpip.do_sendto: UDP sent
[00:00:30.580,383] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
[00:00:30.665,832] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  31 0d 0a                |+CSCON:  1..     
at#xrecvfrom
didrik port test
#XRECVFROM: 1, 16
OK
[00:00:40.058,105] <dbg> at_host: RX
61 74 23 78 72 65 63 76  66 72 6f 6d             |at#xrecv from    
[00:00:40.058,410] <dbg> at_host: TX
64 69 64 72 69 6b 20 70  6f 72 74 20 74 65 73 74 |didrik p ort test
[00:00:40.058,624] <dbg> at_host.uart_callback: RX_DISABLED
[00:00:40.059,875] <dbg> at_host: TX
0d 0a 23 58 52 45 43 56  46 52 4f 4d 3a 20 31 2c |..#XRECV FROM: 1,
20 31 36 0d 0a                                   | 16..            
[00:00:40.059,875] <dbg> tcpip.do_recvfrom: UDP received
[00:00:40.061,798] <dbg> at_host: TX
4f 4b 0d 0a                                      |OK..             
+CSCON: 0
[00:00:42.356,109] <dbg> at_host: TX
2b 43 53 43 4f 4e 3a 20  30 0d 0a                |+CSCON:  0..     

As you can see from the log, I have verified that this server works, and I am able to communicate with it with my nRF9160DK and iBasis SIM card.

I also have some logging running on the server, so it I can confirm that it receives the packet and sends a response.

And, as always, if you could share the log and modem trace afterwards, that would be great.