This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

receive UDP on nRF9160-dk SLM application

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

Parents
  • 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).)

Reply
  • 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).)

Children
No Data
Related