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?