We have observed behavior that appears to be a malfunction with the WP7605. Please advise on how to resolve this issue.
・Devices running the latest firmware (Rev17) experience frequent communication dropouts. The fix patch has already been applied.
・Once the communication status has deteriorated even once, frequent dropouts begin to occur upon reconnection.
・This occurs regardless of the mobile carrier (docomo, au, softbank).
・Communication dropouts also occur on devices running the older module (Rev13), but they do not persist.
・With the older modules, when the radio signal environment deteriorated, the connection was terminated via le_data_AddConnectionStateHandler, followed by le_mrc_SetRadioPower(LE_OFF) and le_mrc_SetRadioPower(LE_ON). After that, communication resumed normally. However, with the new modules (Rev17), even when the radio signal environment improves, the RF appears to repeatedly turn on and off.
We are currently receiving strong complaints from our customers and need to address this issue urgently.
We are working with our Japanese distributor, Macnica, to resolve this issue, so you can also confirm the details with Macnica.
I will test this on the official FW R17 to verify the relevance of this issue.
Meanwhile, while we investigate the cause, we are also exploring potential workarounds.
In that regard, I would like to ask: what methods are available to speed up reconnection when communication with the base station is lost? Currently, we are manually turning the radio on and off.
When we tested using the official FW R17, the same issue occurred.
We do not believe this issue is caused by the patch.
Upon checking the logs, we found that the radio continued to turn on and off after a communication disconnection was detected.
Based on past experience—specifically, an issue in Rev13 where communication with the base station would not resume unless the radio was turned off and on—we implemented the following procedure based on advice from our distributor:
・Upon app launch, we establish a connection by executing le_mrc_SetRadioPower(LE_ON) followed by le_data_Request().
・We monitor network status changes using le_data_AddConnectionStateHandler, and
if a connection is lost, we execute le_mrc_SetRadioPower(LE_OFF) followed immediately by le_mrc_SetRadioPower(LE_ON).
Please advise on the correct procedure to follow if the connection is rejected by the base station.
Is the above procedure unnecessary in Rev17?
Then you need to figure out why there is frequent dropout from base station.
Is this related to your legato application?
Or is it due to poor signal strenght in some area?
For example, if you are not running your legato application (i.e. pure FW R17.1) do you see the network dropout issue?
If yes, then that means it is a network problem and we need to take qualcomm DM log to understand why there is network deregistration.
If no, then that means your application makes the network dropout problem.
Besides, according to the description below, actually you don’t need to reconnect the data connection manually.
Once an application makes a data connection request, it should monitor the connection state reported to the registered connection state handler. The application should only try transmitting data when the state is connected, and should stop transmitting data when the state is not connected. If the state is not connected, the data connection service will try to establish or re-establish the connection endlessly until le_data_Release() is called. There's no need for an application to issue a new connection request.
It should be reconnected automatically.
So I wonder if you really need to terminate the connection via le_data_AddConnectionStateHandler, followed by le_mrc_SetRadioPower(LE_OFF) and le_mrc_SetRadioPower(LE_ON)when the radio signal environment deteriorated
Lastly, please remember to sync the status with your distributor Macnica
In R13, there was an issue where it could take up to 30 minutes for data communication to resume after being rejected by the base station. To address this, we monitored the status using le_data_AddConnectionStateHandler and, upon detecting a disconnection, executed le_mrc_SetRadioPower(LE_OFF) and le_mrc_SetRadioPower(LE_ON).
Please let me know if there are any effective ways to reduce the time it takes for the connection to automatically resume.
Furthermore, when we ran R13 and R17 in the same environment, we found that R17 very frequently detects disconnections via le_data_AddConnectionStateHandler (which rarely occurs in R13).
If the behavior of le_data_AddConnectionStateHandler differs between R13 and R17, we will design our program based on that assumption. Please explain the reason for this change in behavior.
Since the occurrence frequency is low in R13, we have not been able to confirm the signal strength.
In R17, we are currently testing two scenarios: one where the radio is not turned on or off after a disconnection is detected by le_data_AddConnectionStateHandler, and another where le_data_Request() is executed again.
In both cases, a “connect” notification is received approximately 30 milliseconds after the “disconnect” notification.
if just 30ms between “connect” and “disconnect”, then probably this is not network deregistration.
And the reconnection of data channel should be done automatically according to the legato documentation above, so you don’t need to do radio on/off actually.
In addition, you don’t need to call le_data_Release() when receiving data disconnect event and you don’t need to call execute le_data_Request() as the reconnection will be done automatically.
Thank you for your reply.
As you mentioned in your comment, I understand that if the interval between “connect” and “disconnect” is short, there is no need to turn the radio on/off or execute le_data_Request.
Our concern is how to handle situations where it takes time for the device to reconnect after being rejected by the base station.
Additionally, we still find it puzzling that the event detection frequency for le_data_AddConnectionStateHandler is so high in R17.
Then as said before, you need to figure out whether this is related to the network base station.
e.g. Is this related to your legato application? Or is it due to poor signal strength in some area?
For example, if you are not running your legato application (i.e. pure FW R17.1) do you see the network dropout issue?
If yes, then that means it is a network problem and we need to take qualcomm DM log to understand why there is network deregistration.
If no, then that means your application makes the network dropout problem.
We have observed similar phenomena in various regions where we have been running the system.
The issue also occurs in a simple program that executes le_data_Request and monitors the state using le_data_AddConnectionStateHandler.
please add le_mrc_AddNetRegStateEventHandler() just like this application and see if there is network deregistration when you receive data disconnect in your le_data_AddConnectionStateHandler() :
If there is no network deregistration, then probably you can ignore those data disconnect event as after 30ms, the data connection will be automatically re-established
Following your suggestion, we implemented le_mrc_AddNetRegStateEventHandler() and correlated it with disconnected. events from le_data_AddConnectionStateHandler() in the field .
We isolated the cases where a NetRegState event was logged after a disconnected. event (60 cases total), and checked each one against our carrier’s own session log (Deleted, excluding normal power-off) to see whether the carrier side also detected the disconnect.
When the carrier side detected the disconnect (11 cases): the NetRegState events seen were Searching (7), Not registered (2), Registered to home (2).
When the carrier side did NOT detect the disconnect (49 cases): the NetRegState events seen were Searching (30), Not registered (16), DENIED (3).
So the large majority (49/60) of the deregistration events we can confirm on the device side never show up in the carrier’s own session records at all — deregistration is happening more often, and more often unnoticed by the network side, than the carrier-visible incident count alone would suggest.
Question: Is it expected that NetRegState can transition through DENIED/Not registered/Searching without the carrier ever tearing down the session on its side — i.e., is this deregistration purely local (device re-registering on its own) without any corresponding network-side event, or would you expect the carrier to always log something for a genuine deregistration?