SARA SFF R410M UDP Long send times

NB-IoT
1

Hello,

I’m having some issues with the R410m losing connection and taking a long time to come back online.
I’ve digged into ublox’s documentation and did some logging on the device. The problem seems to be linked to UDP packet sent with AT+USOST taking a very long time on some instances.

I don’t use the universal tracker. My code is based on the Sodaq_R4X library.

I observed that a call to AT+USOST usually takes less than a second. Which is fine. On some occasions taking a longer time is expected.
The ublox’s documentation says that the response time for AT+USOST should be less than 10 seconds.
See “18.11 SendTo command (UDP only) +USOST”.

However, my tests show that sometimes it takes way longer that that to send the data. I’ve seen times of 2 minutes.
Problem is, when the send timeout, the modem seems unresponsive. After that the connection is lost and the modem will take multiples tries and up to 2 additional minutes to get back online.
At first I thought that the problem was network coverage. I’ve since ruled that out, my last tests where done on a well covered area and at the same place the modem took less than 10 seconds to connect and minutes later took 3 full minutes.
The problem doesn’t seem to show when stationary. I’ve let a device online for 6 straight days without interruption.
When moving on an highway, the UDP packets take random times to be sent and I get a lot of timeouts, around 10% of the packets. Which is not a real problem, the problem is that the modem doesn’t get back online anytime soon after that.

I tried to lower the SOCKET_WRITE_TIMEOUT from 120s to 30s to see if that helps. That did the opposite and cause more timeouts. But that helped me to get logs of the problem.

[2019-05-16T17:16:50.041Z] >> AT+CGATT?
[2019-05-16T17:16:50.048Z] << +CGATT: 1
[2019-05-16T17:16:50.048Z] << OK
[2019-05-16T17:16:50.048Z] >> AT+CSQ
[2019-05-16T17:16:50.055Z] << +CSQ: 12,99
[2019-05-16T17:16:50.056Z] << OK
[2019-05-16T17:16:50.056Z] >> AT+CGDCONT?
[2019-05-16T17:16:50.068Z] << +CGDCONT: 1,"IP","iot.1nce.net","100.68.224.4",0,0,0,0
[2019-05-16T17:16:50.068Z] << OK
[2019-05-16T17:16:50.069Z] >> AT+USOST=0,"[redacted]",45827,5,"0103681964"
[2019-05-16T17:17:20.288Z] << timed out
[2019-05-16T17:17:20.288Z] >> AT+CGATT?
[2019-05-16T17:17:30.527Z] << timed out
[2019-05-16T17:17:30.527Z] Connecting to network
[2019-05-16T17:17:30.527Z] >> AT
[2019-05-16T17:17:31.026Z] << timed out
[2019-05-16T17:17:31.026Z] >> AT
[2019-05-16T17:17:31.526Z] << timed out
[2019-05-16T17:17:31.526Z] >> AT
[2019-05-16T17:17:32.025Z] << timed out
[2019-05-16T17:17:32.025Z] >> AT
[2019-05-16T17:17:32.525Z] << timed out
[2019-05-16T17:17:32.525Z] >> AT
[2019-05-16T17:17:33.024Z] << timed out
[2019-05-16T17:17:33.024Z] >> AT
[2019-05-16T17:17:33.523Z] << timed out
[2019-05-16T17:17:33.523Z] >> AT
[2019-05-16T17:17:34.023Z] << timed out
[2019-05-16T17:17:34.023Z] >> AT
[2019-05-16T17:17:34.522Z] << timed out
[2019-05-16T17:17:34.522Z] >> AT
[2019-05-16T17:17:35.022Z] << timed out
[2019-05-16T17:17:35.022Z] >> AT
[2019-05-16T17:17:35.521Z] << timed out
[2019-05-16T17:17:35.521Z] Error: No Reply from Modem
[2019-05-16T17:17:35.521Z] Connection failed. Tries: 1
[2019-05-16T17:17:35.521Z] Disconnecting modem
[2019-05-16T17:17:35.521Z] >> AT+CGATT=0
[2019-05-16T17:17:35.948Z] << +USOST: 0,5
[2019-05-16T17:17:35.948Z] << OK
[2019-05-16T17:17:35.948Z] >> AT+CFUN=0
[2019-05-16T17:17:36.068Z] << OK

As can be seen on that log, with a timeout of 30s, the +USOST response comes in after the timeout and the modem is unresponsive in the mean time. I’ve had issues like this with 120s instead of 30s. Sometimes the modem was not responding after 4 mins and had to be powered off. Sadly, there is no logs of that.

For my use case, I send data every seconds. A delay of up to 30 seconds to send a packet (~20 bytes) is acceptable. But after 30s the data is next to useless for me and I should resume sending the next data and discard the one that is taking too much time. On a failed send, my goal is to get back online as fast as possible.

Now that the situation is exposed, here are some questions.

  1. The ublox documentation for AT+USOST says that the response is less than 10s but in practice it take much longer than that sometimes. How can we impose a timeout on the modem?
  2. In cases where the modem becomes unresponsive after a send, is it better to force reset it or to wait for the modem to get back by itself?
  3. When the network is lost, should I let the modem do it’s thing an only check AT+CSQ and AT+CGATT or should I force reset it (AT+CFUN=15) and reconfigure it fully?

Sorry for the long and confusing post, that was a bit hard to explain.

2

I don’t see the command to create the socket, I assume you have created the socket earlier?
Right now you are using:

-->socketCreate() //presumably
-->socketSend()
...
-->socketSend()
...
-->socketSend()

If you are creating the socket just once at the beginning perhaps try closing it after each send and then re-opening it for the next send. So for each send:

-->socketCreate()
-->socketSend()
-->socketClose()

Or maybe try the connect / write approach instead (I know this is not what is recommended in the AT Command manual.)

-->socketCreate() 
-->socketConnect()
-->socketWrite()
-->socketClose()