Modem connection state detection

RE: Modem connection state detection

nicolae.georgescu — Tue, 07 Jan 2025 14:03:18 GMT

Ok, understood, makes sense! Thank you for investigating this in more detail, much appreciated!

RE: Modem connection state detection

JONATHAN LL — Tue, 07 Jan 2025 06:48:17 GMT

Update:

Periodic searches can be configured using LTE LC API lte_lc_periodic_search_set(). If power consumption is not an issue, configure the time between periodic searches to a very low value, can even set to 0 seconds.

Modem being stuck offline for days is not caused by lack of periodic searches, but most likely a modem issue. If possible update the modem firmware to the newest one possible, there has been a lot of improvements since MFW v1.3.2.

For extra safety, some kind of watchdog would probably be good. If modem can not connect to the network for a longer period of time, either reset the whole system or do the modemlib shutdown/init sequence as you have suggested earlier. System reset could be preferable, because that would also handle problems on the application side.

This would be the recommendations we have.

RE: Modem connection state detection

JONATHAN LL — Fri, 03 Jan 2025 21:22:03 GMT

[quote user="nicolae.georgescu"]In the past, with modem fw 1.3.2 sometimes the device was stuck in offline for days. We don't know why, no time to debug,[/quote]

Would be good to have som info on the reason here so that if it is a bug or some other issue we can address it as best as possible. Would you be able to provide some debug info or best a modem trace.

[quote user="nicolae.georgescu"]So just to repeat the question: how can we control how fast/often the modem tries to reconnect?[/quote]

will need to get back to you after I consult the experts on this here as to what would be best practice.

Regards,
Jonathan

RE: Modem connection state detection

nicolae.georgescu — Thu, 02 Jan 2025 15:57:15 GMT

Happy New Year Jonathan!
Thanks a lot for the detailed answer and for checking internally.

For (1) understood LTE_LC_EVT_NW_REG_STATUS is enough. I will double check on the events we received, a LTE_LC_NW_REG_SEARCHING makes perfect sense.

For (2) understood that the modem reconnects automatically. We can confirm this.

The only question left is about timing. How can we control how fast/often the modem tries to reconnect?
For us timing is very important, users control our device through an app, and we want app -> our server -> device to be < 5 seconds.
In the past, with modem fw 1.3.2 sometimes the device was stuck in offline for days. We don't know why, no time to debug, so after 3 minutes of software retries we added a division by zero to force restart and this always worked.
A reboot has other downsides though, the device goes through full init phase + the 3 minutes of offline when the device doesn't receive messages.
This is why we wanted to do a softer reboot, to be faster <1 minute, ideally 30 sec, and without full reinitialization of our other components.

So just to repeat the question: how can we control how fast/often the modem tries to reconnect?

Thank you

RE: Modem connection state detection

JONATHAN LL — Thu, 02 Jan 2025 14:34:31 GMT

Update:

[quote user=""]1. Is monitoring the LTE_LC_EVT_NW_REG_STATUS a correct way to detect if a modem connection is still available or it dropped out of the sudden?
If so, on first attempt to connect we get an LTE_LC_NW_REG_NOT_REGISTERED and then it connects. We should ignore that first occurrence?

[/quote]

When modem starts searching for a network, there should be a LTE_LC_NW_REG_SEARCHING event, not LTE_LC_NW_REG_NOT_REGISTERED.

If you need a simple way to check if modem is connected to the network or not, the current way seems sufficient.

Another possibility would be to use the PDN library and follow the PDN_EVENT_ACTIVATED and PDN_EVENT_DEACTIVATED events.

If you need to know between server and modem level issue, you should probably use PDN library too. But I would think twice if it's really needed and keep things simple with LTE_LC_NW_REG_REGISTERED_HOME and LTE_LC_NW_REG_REGISTERED_ROAMING.

[quote user=""]2. Is the full modem reconnect code flow correct? Or should we do it without the nrf_modem_lib_shutdown + nrf_modem_lib_init?[/quote]

In most of the cases, there's no need for any reconnect logic in the application. When LTE is enabled, modem tries to stay connected to the network automatically. When it has again successfully registered to the network, the application will receive a LTE_LC_NW_REG_REGISTERED_HOME or LTE_LC_NW_REG_REGISTERED_ROAMING event. If a suitable network can not be found, the modem enters sleep and periodically wakes up to search for a network. The sleep times between searches depend on the periodic search configuration.

There is no need to reinitialize the modem ( nrf_modem_lib_shutdown() -> *_init()) to disconnect and reconnect to network.
When the modem is in CFUN mode 1 (or 21) with LTE activated, and looses network connectivity, it will attempt to reconnect automatically and trigger a new notification when reconnected with the network.

So there does not need to be a manual disconnect and reconnect step here. It should sort it self out unless there is some specific reason you would want that.

Regards,
Jonathan

RE: Modem connection state detection

JONATHAN LL — Thu, 02 Jan 2025 11:58:01 GMT

Happy New Year Nicolae,

Looking in to this to see if there is something extra to do, what you are doing should work relatively well and the LTE_LC_EVT_NW_REG_STATUS will give you a response CREG 1 or 5, so its a indicator.

As for what would be the reason to why the disconnects happen not all can be picks up\debugged with these functions and might need a modem trace in some cases, its worth doing if this is a issue that you see often and there are no obvious reasons.

So from the LTE link controller library options I belive LTE_LC_EVT_NW_REG_STATUS is the correct way to check if the connection is lost or not.

I am checking internally if the sequence you are using is the desired one or if there are other better ways.

Regards,
Jonathan