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]

AndMar8 said:

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

 This command does not exist anymore, so that not working is expected.

 

AndMar8 said:

AT#XRECVFROM="x.x.x.x",20080

 Based on the discussion in the PR to fix the documentation, it seems I was wrong in my guess for what form of the command was right. So with that knowledge, this is also expected not to work.

Instead, the correct syntax for the command is the one in the documentation, and which you were originally using:

#XRECVFROM[=<size>]

What server do you send data to, and expect data in return from?

Are you certain that it does send a reply?

Can you take a modem trace?

That will let us see if the modem receives the response, and it is the application that is the problem, or if the response never arrives at the device.

[AndMar8]

Hi,

I'm sending data using NODE-RED udp-out block. I tested it with different devices and it works.
Regarding the modem trace I'm working on it.

I tried this AT command but I get an error:

first try:

AT#XRECVFROM=[4]
ERROR
[00:02:19.316,406] ESC [1;31M<err> tcpip: F

[1;31m<err> tcpip: Failed to parse AT command -11

[0m

second try:

AT#XRECVFROM

Here the code stops and it returns me an error in the window of log output under the terminal.

I'm wondering what is the correct procedure to send and receive data using UDP.

Are these steps right?
1)Opening a Socket
2) Sending data
3)Waiting for a response

Is the UDP data sent from the server buffered somehow or do I need to put the modem into receveing mode before sending the UDP data?

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

[Achim Kraus]

Basically, I use the "serial_lte_modem" successfully , but I patched the "xrecvfrom".

That command is based on "recvfrom", which according https://linux.die.net/man/2/recvfrom uses the "src_addr" as **OUT** not **IN** parameter. The original implementation seems to assume, that this is an **IN** parameter. So, my patch applies a recv_timeout via setsockopt and then calls the recvfrom using the OUT parameter src_addr to fill the received source information also into my adapted at-response.

I'm not sure, if this is just a mistake by the developer to assume, the src_addr is **IN**, or if this is really the intention.

(As additional hint related to the last question about the PUBLIC IP:

My server returns the response just to the source-address, the server receives the package from (as usual for UDP).)