How to recover a nRF9160 from sporadic ENETDOWN

[Achim Kraus]

Using a Thingy!91 (v1.0.0 and v1.4.0, firmware 1.2.3, 1.2.7) I get sometimes (every couple of days) a ENETDOWN when sending data out. Before that ENETDOWN, the device was usually able to exchange 100 and more UDP messages.

Currently I do a "sys_reboot(SYS_REBOOT_COLD)", but I'm wondering, if there are less massive ways to recover.   

I found other questions, but I'm still struggling to see an "useful" answer. e.g.

https://devzone.nordicsemi.com/f/nordic-q-a/57642/nrf9160-lte-modem-documentation

but the link at the end, ends in "NOT FOUND".

So, what is the recommended way to recover from ENETDOWN?

[Albrecht Markus Schellenberger]

Hello Achim,

I found other questions, but I'm still struggling to see an "useful" answer. e.g.

As Håkon described in the above mentioned case, our recommendation is to subscribe to unsolicited result codes of +CEREG and use +CESQ, or subscribe to %CESQ. This way, you can verify that ENETDOWN actually occurs due to that the modem has lost connection to the network.

So, what is the recommended way to recover from ENETDOWN?

Putting the modem into flight mode for a while with AT+CFUN=4 could be a good thing to do in such a situation, but it of course depends a little on your use case and the connection/network status as well.

Regards,

Markus

[Achim Kraus]

Hello Markus

I already use

lte_lc_connect_async(lte_handler);

so, which events should be used for verification? Currently I use

LTE_LC_EVT_RRC_UPDATE with LTE_LC_RRC_MODE_CONNECTED

to adjust the time, when the message is really sent. 

So, which event/value should be processed?

If "+CFUN=4" is sued, what need to be called/executed, to have the modem stack working for UDP again?

Starting again from "lte_lc_connect_async(lte_handler);"?

Something before? After?

[Albrecht Markus Schellenberger]

Hello Achim,

Achim Kraus said:

so, which events should be used for verification? Currently I use

LTE_LC_EVT_RRC_UPDATE with LTE_LC_RRC_MODE_CONNECTED

to adjust the time, when the message is really sent. 

So, which event/value should be processed?

You should use LTE_LC_EVT_NW_REG_STATUS, as demonstrated in this LTE handler.

Achim Kraus said:

If "+CFUN=4" is sued, what need to be called/executed, to have the modem stack working for UDP again?

Starting again from "lte_lc_connect_async(lte_handler);"?

Something before? After?

Since you are using the LTE link controller library, you can use lte_lc_offline() instead of writing +CFUN=4 to the modem directly, but you might want to re-open the UDP socket again.

If the modem looses its connection to the network, it will automatically retry to connect after a while, as long as there is an available network to connect to. So if flight mode is an appropriate choice or not depends a little bit on your use case.

Regards,

Markus

[Achim Kraus]

Though this case is rare in reality, I'm still not that sure. Anyway, that are my results so far:

On reboot, I use

   lte_lc_init();

   lte_lc_connect_async(lte_handler)

and

   socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)

With that, the device is able to exchange UDP messages. In rare cases, sendto returns an error, and errno is ENETDOWN.

In that case, I wait now, until the registered lte_handler (see above) reports, that the device is connected again. After that, I close the old socket and open a new one with    

   socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)

again.

So far, that works. Lets see, if it still works in 2-3 weeks :-).

[Albrecht Markus Schellenberger]

Hello Achim,

Achim Kraus said:

So far, that works. Lets see, if it still works in 2-3 weeks :-).

Thanks for your feedback :-)

Achim Kraus said:

Though this case is rare in reality, I'm still not that sure. Anyway, that are my results so far:

What is it you are not sure about?

Regards,

Markus