Modem connection state detection

[nicolae.georgescu]

Hello,

Our board connects and remains connected to our server with only eDRX sleep periods.

When a disconnect occurs we want to know if it's a connection issue to our server or a modem level issue.
Right now we check if the modem IsConnected by listening to 

case LTE_LC_EVT_NW_REG_STATUS:

{

if ((evt->nw_reg_status != LTE_LC_NW_REG_REGISTERED_HOME) &&

(evt->nw_reg_status != LTE_LC_NW_REG_REGISTERED_ROAMING)) {

ModemManager::m_state = ModemState::DISCONNECTED;

break;

}

}

If the modem is disconnected there is no point in attempting a new socket connect, we are doing:

lte_lc_power_off()

nrf_modem_lib_shutdown()

Sleep(1s)

nrf_modem_lib_init()

lte_lc_system_mode_set

lte_lc_edrx_req

lte_lc_modem_events_enable

lte_lc_connect_async

Questions:
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?

2. Is the full modem reconnect code flow correct? Or should we do it without the nrf_modem_lib_shutdown + nrf_modem_lib_init?

Thanks,
Nicolae

[JONATHAN LL]

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

[JONATHAN LL]

Update:

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?

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.

2. Is the full modem reconnect code flow correct? Or should we do it without the nrf_modem_lib_shutdown + nrf_modem_lib_init?

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.

1. There is no need to reinitialize the modem ( nrf_modem_lib_shutdown() -> *_init()) to disconnect and reconnect to network. 
2.  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

[nicolae.georgescu]

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

[JONATHAN LL]

nicolae.georgescu said:

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,

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.

nicolae.georgescu said:

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

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

Regards,
Jonathan