EHS5-E randomly disconnected from mobile network | Thales IoT Developer Community
July 15, 2021 - 9:38am, 2204 views
For our applications we use the EHS5-E module with our midlet.
It happens to us that the module disconnects from GPRS, or from GPRS + GSM service.
An LED that indicates the status of its connection, however, indicates that it is logged in the network.
We have tried the following commands / procedures to reconnect.
AT+CGATT=0/1 for GPRS detach/attach
AT+CFUN=4 + AT+CFUN=1 + AT+COPS=0 for reconnect to mobile network
However, they did not correct the condition described above.
Since we control another device with the midlet, a complete reset of the module is undesirable.
Do you have any ideas on how to solve the problem?
Could you tell me how exactly your application monitors that GSM/UMTS and/or GPRS registration is lost? Is it done via +CREG and +CGREG URCs or some polling mechanism (if so, which AT commands are checked)? Also, the LED you mentioned is the Status LED, am I correct? Is it set to <****>=1 in AT^SLED command?
In general, module might lose network registration in case network coverage is poor or due to some external interference. But once network signal is back your EHS5 should automatically register again by itself since you use AT+COPS=0 (automatic registration ****).
As for GPRS detach, please check if you have AutoAttach feature enabled by AT^SCFG="GPRS/AutoAttach","enabled" command (it requires a module reboot for the change to take effect). Otherwise your module will detach from GPRS services automatically whenever all previously used PDP contexts get deactivated, e.g. once you close all IP services opened in your MIDlet.
thank you for the reply. The application does not monitor the connection status, but tries to connect (open a TCP / IP connection). However, the socket does not open, nor do we see any connection attempts on the server side. The only thing that will help is the already mentioned restart.
The setting of AutoAttach + LEd are following:
We do not close the TCP / IP connection, but if we are unable to connect to the server, the application closes the connection and opens it again.
The signal is sufficient and after the restart the connection (both GPRS and GSM) will be established immediately.
By saying that socket connection cannot be opened do you mean that your application receives some kind of exception? Or do you try to send/read some data from the socket but the operation timeouts? How many socket connections are being opened by your MIDlet at the same time? Does you MIDlet application implement BearerControlListener interface? If not, could you add it for debugging purposes, to check if PDP context gets activated correctly once the TCP socket is being opened? How often does you application exchange data with server? Is it possible to experience longer periods of time when no data is exchanged through an open socket connection?
Also, would it be possible for you to share your Java output log with me? At least the part where your socket connection establishment fails? From what I understand after module startup your application can open socket connections correctly and the issue happens only after some time passes - in between which you open some TCP sockets without closing them. If I'm wrong then please correct me. But also please note that keeping too many opened sockets may exhaust module resources and prevent additional connections from being opened.
if our application din not receive the answer from server, close the connection and try to open the new one. We open only one socket connection, which is closed and reopen, if the connection fails.
In this time we try to implement the BearerControlListener interface to our midlet to prepare some data for you from debugging and log output.
Our automatic procedure in case of connection loss is as follows:
10:5:43:597 21.5.2021 # DataConnectionDaemon.openConnection to ***/yyyy/zzz
10:5:43:597 21.5.2021 # GPRSWatchDog.kick from DataConnectionDaemon, delay 900000 ms
10:5:43:597 21.5.2021 # Open socket connection preset 1 to ***/yyyy/zzz
10:5:44:97 21.5.2021 # DataConnectionDaemon.openConnection error::java.lang.Exception: DataConnectionDaemon.openConnection TCP/IP error ***/yyyy/zzz(msg=DataConnectionDaemon.openConnection TCP/IP error ***/yyyy/zzz)
10:5:44:597 21.5.2021 # GPRSWatchDog.cgatt=0 response:
10:5:47:97 21.5.2021 # ModemDrv.GSM unhandled event:
10:5:47:596 21.5.2021 # GPRSWatchDog.cgatt=0 response:
10:6:9:597 21.5.2021 # GPRSWatchDog.cgatt=1 response:
As you can see the connection has not been established. However, when we restart the entire module, the connection is established immediately. The main question is - is there any command that would restart only the modem part?
Thank you for you help!
unfortunately, it took us longer than we expected to obtain the LOG of the fault.
It was because of this problem, which also bothers us, but we have somehow learned to live with it:
Where can I send you the log, or should I put it in a link?
I contacted you via email. Please share your logs there.
Also, I assume that by restarting the ****m part you mean to deregister from the network and register again, am I correct? If so, we recommend using either AT+CFUN=4 & AT+CFUN=1 & AT+COPS=0 sequence (to switch to Airplane ****, then return to full functionality **** and trigger network registration) or AT+COPS=2 & AT+COPS=0 sequence (to deregister from the network manually, then trigger registration procedure).
The first approach will take more time and we also recommend adding a delay between calls to AT+CFUN=4 and AT+CFUN=1, as going into Airplane **** shuts down RF circuits. However this sequence performs a more general radio restart. The second option will take shorter time but it basically comes down to simply re-attaching to the network.
I recommend to check how both of those approaches work on your setup to see which one would be a better option for your application.