Cellular Interface + SARA-R4 : Modem does not re-register after momentary connection loss

Libraries
1

Hi,

I have been testing the FreeRTOS cellular interface for the SARA-R4. I have a setup which allows me to simulate a loss of connection (by attenuating the antenna signal). I have implemented the
RegisterUrcNetworkRegistrationEventCallback in such a way that the callback prints out connection status changes.
When I simulate a brief connection loss of 10 seconds, the callback first triggers and reports that the cs and ps registration status are REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING. When the connection comes back up again the callback reports REGISTRATION_STATUS_REGISTERED_HOME. This is expected behavior.

A problem occurs when I simulate a longer connection loss, of a minute or so, then again REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING is first reported, but when the connection comes back up, there is no REGISTRATION_STATUS_REGISTERED_HOME callback. The modem remains disconnected.

What might be related is that I noticed that the networkRegistrationMode is always reported as REGISTRATION_MODE_UNKNOWN, should this not be REGISTRATION_MODE_AUTO in order for the modem to reconnect automatically? How can I configure this?

2

I left the setup running in the REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING state waiting for reconnection, and eventually, after roughly 40 minutes, the connection came back up again. Log:

#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING
psRegistrationStatus==REGISTRATION_STATUS_REGISTERED_HOME
#----------------------------------------------------------#
#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING
psRegistrationStatus==REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING
#----------------------------------------------------------#
#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_REGISTRATION_DENIED
psRegistrationStatus==REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING
#----------------------------------------------------------#
#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_REGISTRATION_DENIED
psRegistrationStatus==REGISTRATION_STATUS_REGISTRATION_DENIED
#----------------------------------------------------------#
#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_REGISTERED_HOME
psRegistrationStatus==REGISTRATION_STATUS_REGISTRATION_DENIED
#----------------------------------------------------------#
#----------------------------------------------------------#
RegisterUrcNetworkRegistrationEventCallback triggered…
networkRegistrationMode==REGISTRATION_MODE_UNKNOWN
csRegistrationStatus==REGISTRATION_STATUS_REGISTERED_HOME
psRegistrationStatus==REGISTRATION_STATUS_REGISTERED_HOME

Clearly a 40 minute connection loss when the real loss was only about a minute will not give a usable product.
Do I need to implement some kind of watchdog thread that tries to reset the connection after a certain time in the REGISTRATION_STATUS_NOT_REGISTERED_SEARCHING state? That seems like a rather ugly way of addressing this issue.

3

I noticed that in the case when a network becomes available again, but when the modem registration status is sticking to anything but home, a manual cycle of Cellular_RFoff(), pause and Cellular_RFon() quickly reregisters the modem to the network. Without doing this, it can take a really long time (>30mins) before the modem re-registers itself.

So I implemented a mechanism that starts a timer when the RegisterUrcNetworkRegistrationEventCallback is triggered and the reported connection is not home. When the timer expires after a short while, a check is performed on the registration status and if it is still not home, a cycle of Cellular_RFoff()-pause(1s)-CellularRFon() is performed.

If there is reception again, the Cellular_RFon() will then quickly result in a state change to REGISTRATION_STATUS_REGISTERED_HOME.

I also implemented a flag representing the registration status. Whenever the MQTTAgent returns an error the flag is raised, it also kicks off the timer which forces the re-registration. The flag is only lowered when the network state returns to REGISTRATION_STATUS_REGISTERED_HOME.

This flag is then in turn used to halt any socketconnect() calls, so when socketconnect() is called the function first waits for the right network state before attempting to connect the socket.

I have tested this mechanism in the scenario where halfway during an OTA job, I remove the antenna, simulating bad reception, and this works. The OTADemo then suspends the OTA Agent and disconnects the socket, waits for the network re-registration, makes a new TLS socket and resumes the agent successfully, leading to a successful OTA update.

There are still some other scenarios I need to test, for instance when the connection drops during different moments in the TLS setup after the socket is connected, so I’m not 100% sure yet this is the final solution.

I do feel like what I came up with is a bodged solution for a fundamental core problem that should have already been addressed in the libraries I’m using.

Any opinions here on this?

4

Hi Mike,

Sorry for late reply. The cellular interface provides low level modem control API to send/receive AT command and handles URC with callback function. Currently, network re-connect function needs to be implemented by user of cellular interface. We will read this thread and discuss what we can do in the future. Thank you for your problem and solution sharing.