EHS5-E rev.4 - GSM call problems | Telit Cinterion IoT Developer Community
February 28, 2019 - 3:09pm, 4824 views
We have bought some EHS5-E devices, and surprisingly they don't have onboard as usual a fw version = 3.001 but instead they have a fw version = 4.x.
The response to the command ATI1 is the following:
The problem is that if we try to make a GSM call versus the device, it does not work as it do in fw. 3.001 versions.
Also, there is no documentation or SDK available for this 4.000 revision !!!
Someone could help me?
Rel 4 is not in the market at today.
Most probably such units have a test FW.
Please, ask the provider for a new FW
Somewhere over the rainbow!!! Looking for the Oz Land!!!
also the chip is marked as "... *******400", not "A300" as for the units we have bought before.
It seems it is not only the firmware, also the hardware revision is changed.
Yes these modules have new hardware - some elements are changed due to a discontinued production. But it is still the same module with the same features. As indicated by Antonio this version is not yet a released version so you should ask the person you have these modules from about the firmware update or documentation and software.
Your module is probably a customer sample. It is possible that with the updated firmware your problem will disappear. You can also describe in more details what exactly the problem is.
we have bought 1000 pieces from our provider, they all have rev4 version. Could it be possible that all are customer samples ?
So we contacted the provider and they sent us updated SDK and documentation. We have compiled the software with the new SDK, and the problem disappeared.
So actually all seems to work. But the information about rev4 is very confused, and I would like to make sure that we have bought "production" and officially released samples.
I'm not selling modules, so I may not be 100% up to date with sales department about what modules are already being sold and what are still being treated as customer samples. I think that you can rely on your provider as they have the modules form Gemalto. If they are already distributing the modules, especially the hardware must be the final version. If you have bought 1000 pieces they must have been produced as a release versions.
You did not describe what exactly the problem was but Java libraries are also being updated and especially here (between two different releases) there might have been some incompatibilities which was causing these problems. That's why it is important to use the appropriate SDK released for the firmware version currently used.
after some testing with the new SDK for EHS5 rev4, we have now some problems:
- SMS does not work anymore
- USB debug connection is unreliable (terminals such as putty keep on resetting when connected to one of the EHS5 ports
These problems does not happen in rev.3 engines.
I'm looking to the new documentation and release notes, but for the moment I found nothing that could lead to Java code changes for REV4.
I hope Gemalto can soon give some information to us, or new firmware or sdk or whatever. Java code that worked correctly in REV3, should work also in REV4, or please Gemalto tell us what we have to change in the code to support this new release.
Can you write more details about SMS problems? Is it not possible to send it or receive notification or something else? Do you have any log?
How does the USB problem look like? How is the terminal program resetting?
As for Java code compatibility it should be working on REV4 also but you need to build the MIDlet with the libraries dedicated to REV4 module.
As for firmware updates please ask your contact person (supplier or local Gemalto office) for any possible firmware updates.
The problem about SMS is that the device doesn't receive them. The send of SMS works correctly. Note that incoming GSM calls (with RING notification) also works correctly.
For the USB problem, not sure this is the same problem, but when I try to remote debug the device through USB port using Eclipse, I get an exception, as reported in the log below:
Using USB port COM47.
Connecting to module...
Initializing module for debugging...
Establishing "IP connection for remote debugging of EHSx"...
Registering ip address "192.168.244.1" of remote debugging device...
Waiting for debug device registration of "IMP_NG_EHS5_REMOTE"...
Passing control to external device emulator...
Installing suite from: http://192.168.244.2:64688/ModemEHS5.jad
Gsm232 - Constructor!
Gsm232 - MIDlet starting ...
ATCommand: CSD supported: true
Sending dispose command to the VM.
Exception in thread "Object Server Connection - Handle JMX Notification Thread" java.util.ConcurrentModificationException
at com.sun.jme.toolkit.remoting.client.rmiimpl.ObjectServerConnectionImpl$1.run(Unknown Source)
End of debug session. Emulator is closed!
As for SMS please make sure that there is free storage space. Is the SMS not received or there is no notification about the incoming message? As for notifications - it can be configured on 1 interface only (physical interface or particular ATCommand instance). When you configure the notification on the other interface it will no longer come to the previous one. Please specify if the problem exists in Java MIDlet or via physical interface.
Please also check AT+CSMS? reply. If Phase 2+ is configured (by default there should be Phase 2) incoming messages need to be acknowledged with AT+CNMA command. If a message is not acknowledged there will be no more notifications.
As for the debugger log I can see that the debug connection was established and some application output was printed before this exception. You didn't explain the initial USB problem in details. But at the moment this could also be something else. For debug connection there is a special dial-up connection established between PC and the module. Maybe (just a hypothesis) there is some collision between the debugger and MIDlet functionality, for example MIDlet is using CSD. It would imply that this functionality can not be tested with the debugger.
the answer to the command AT+CSMS? is: +CSMS: 0,1,1,1, so it seems Phase 2 is configured.
In my opinion, these problems (USB, SMSs etc) have all a common root: there should be a sort of conflict with my MIDlet and JRC. The cause could be searched in my MIDlet, you can say. But why this MIDlet is working perfectly in EHS5-REV3 ?
So there should be something in EHS5-REV4 that is changed, or my application should manage in a different way that I don't know!
I have made another test: I haven't started my MIDlet, and I've tried to send an SMS to the module. Then, using AT+CMGL and AT+CMGR commands I was able to receive the SMS!
For me the question is very simple: why the same application is working correctly in EHS5-REV3 and it is not working in EHS5-REV4 ?