We are testing the re connection ability of the wp7xx, this is by disconnecting the cellular antenna and then to reconnect it after a while, in order to evaluate how quickly the modem gets back on the network.
This is the legato version 19.11.5 we are using, and a combination of le_mrc, le_mdc and le_data.
le_mrc will check that there is a valid radio signal before using le_mdc api to connect the modem and finally le_data api will connect the data, everything works well in normal situations.
However, once we preform the test above, we have noticed that the modem struggle to get back on the network, to the point that if we keep disconnected the cellular antenna for 30 minutes, then the modem will not get back on the network at all.
We can re-start the legato app we have written, and this seems fixing the issue, the modem quite soon gain back access to the cell network, but we are struggling to understand the reason for this, as at that point the le_data session is closed and the le_mdc api has disconnected the modem.
If we disconnect the antenna for a little while, and then reconnect it, then the modem get access back to the network quite quickly, but if we leave the antenna disconnected for a while, 30 min to 1 hour, then the modem will take a long time to reconnect, or will not reconnect at all.
It seems related to some sort of exponential backoff mechanism? So if the radio is no-existent the device will exponentially increase the timer for re-attempt to connect? But it could also be related with the data or mdc interfaces hanging somehow and preventing the reconnection? We are still investigating but if anyone has seen this problem and could advise what is related to (and how to solve it) and to which of the three API (mrc, mdc, data). That would make our finding much simpler.
The following are the defines for backoff time parameters, including the init duration &
the max # of retries. After each failure to connect, the next backoff duration will be doubled
until the max # of retries is reached.
*/
//-------------------------------------------------------------------------------------------------- #define CELLULAR_RETRY_MAX 4 #define CELLULAR_RETRY_BACKOFF_INIT 1
@Pankaj thank you for your reply, I am still testing the behavior of the modem connection with the different services to try to isolate the issue, but so far I am forcing a cellular scan with le_mrc every 3 minutes if the modem is not already in the network. The 3 minutes start from when the previous scan finishes, as this can take up to a couple of minutes sometimes.
We are still checking on some odd situations when the modem doesn`t fall off the network even if the antenna is disconnected, the modem never returns the DISCONNECTED status to the handler. Or in a situation the modemDaemon just crashed due to the watchdog, not sure why.
Can you confirm you have the dcsstatehandler implemented? In any case if the modem data connection is lost and the interface details cannot be retrieved the dcs statechangehandler should come up with disconnected even from where you can reinitiate the connection.
Depending on the events from handler would be efficient compared to using a timer with 3 min interval.
if (ret != LE_OK)
{
// See LE-11280 that a failure to get the network interface might be due to back-to-back
// state changes and old state being received late here. Thus, when this happens,
// override the state to be reported with the “disconnected” state instead
LE_DEBUG("Report the disconnected state upon no network interface retrieved for "
“connection %s”, connName);
state = LE_MDC_DISCONNECTED;
}
I am using a prebuilt version for the FX30 and this (as far as we understand) hasn’t been fully implemented le_dcs, we are still using the le_data.
Our legato version is 19.11.5_
Also, with data from the handlers, we have seen them changing a bit in an odd way as well, but we are using the handlers for data connection and modem change status for indication.
We had cases when connecting the modem the handler was returning disconnected and then connected a few times before settling to connected status, also if you query the status of the modem (connected or disconnected) within the handler, we had cases when these didn`t match.
We did struggle a little bit with the legato, especially because we were expecting everything to work properly, but once you start planning for this, and you build extra logics to make it bullet proof, it works pretty well.