EHS5-E firmware | Telit Cinterion IoT Developer Community
July 17, 2018 - 8:31am, 3407 views
We are debugging some socket connection issues. For unknown reason we get following socket errors:
- Send fail <java.io.IOException: error -121 in socket::open>
This is strange because there is a valid GPRS connection at that specific moment (LAI:20416,+CREG: 2,5,"05FD","010036FF",6)
Question:
we are running with firmware below. How can we get a latest version, and is it possible to update it remotely using OTAP ?
Cinterion
EHS5-E
REVISION 03.001
A-REVISION 00.000.42
Regards,
Eric (Concilio)
Hello,
Can you share some more information about the application and this error. Does it happen each time or sometimes only? How many connections are used, how frequently etc.? Is APN configured, how do you configure it?
There is com.cinterion.io.BearerControl class and BearerControlListener interface that you could use to catch bearer state changes and to display information about bearer name, address, state, DNS.
Maybe the problem is caused by the poor network connection. Please check AT+SMONI, AT+CSQ, AT+COPS? commands.
There is a newer firmware which I could send to you.
Gemalto provides a ready solution to update the user application remotely (OTAP). However for security reason it must be first activated on the module with a dedicated AT command before the first usage. For remote firmware update we don't provide the full solution but the dedicated AT command and demo FOTA MIDlet which shows an example how it could be implemented in the customer application. Although it is only a demo it in fact is a complete application which can update the firmware and JRC MIDlet on reception of a special SMS message. It can be found on the installation CD with some other demo applications. If you have installed Gemalto SDK you should be able to find these applications on your hard drive (C:\Users\Public\Cinterion or similar path depending on your OS version).
So it could be possible to install the FOTA MIDlet remotely with OTAP and then the FOTA MIDlet could perform a firmware update. But the module must be enabled for OTAP.
Best regards,
Bartłomiej
Dear Bartłomiej,
thanks for your quick response. We are buying and using software from Aplicom. It is not a poor network connection, our telco provider confirms that the units in question have an active data session in the GPRS network.
Triggering an HTTP POST by sending an SMS works over the same data session. It's really a problem with re-opening tcp://socket connections somehow. This only seems to happen when switching between countries (MCC).
Hello,
So the scenario is getting more complicated, also for testing, if it's connected with crossing the borders. The device registers to the new network and the data connection is lost for a while.
To be able to debug this some traces would be needed from the module to analyze the situation step by step.
Besides our scenario there are many possibilities (not necessarily related to the local GPRS connection) that can cause the network connection to fail. So I think that the most important thing is if it is possible to recover from that situation, if for example another connection (after some delay for example) can succeed, if the application can manage such situations.
Regards,
Bartłomiej
Hello,
the problem cases seem to narrow down to situations where GPRS registration is denied due to failing roaming contract. We noticed that the FPLMN on the SIM is not written in those cases:
at+crsm=176,28539,0,0,16
+CRSM: 144,0,"FFFFFFFFFFFFFFFFFFFFFFFF"
Before we investigate further it would be good to know if EHS5-E is using the FPLMN mechanism?
Best regards,
Eric
Hello,
If it comes to roaming registration problems have you verified the preferred operator list settings (AT+CPOL, AT+CPLS commands)?
Regards,
Bartłomiej
After a lot of testing we narrowed down the problem. We have SIM's with roaming Multi-IMSI. We are almost sure now that problems ****** in the IMSI switching phase. Sometimes it works without problem, but in case of problem the modem will not connect.
It's very hard to debug because it happens on Modem and SIM Toolkit level.
Hello,
Indeed that could be hard to debug without tracing the module. Please check AT+CEER command - maybe there will be some error description.
As I understand this problem only happens while switching the network? Is it possible to establish the connection in another attempt, after some delay etc. or there are special steps needed to recover from this situation?
You might try to test this with a newer firmware to check if there are any difference.
To debug this some module tracing is needed which you can't do. So a contact with Gemalto support would be required. As you are not the Gemalto customer I think that you should report this to Aplicom.
Best regards,
Bartłomiej