Wehave an interesting problem that affects our GE863GPS and GM862GPSmodules on various hardware platforms and with all the latestversions of Telit firmware (862: 07.03.400, 07.03.401 and 07.03.402 -863: 07.03.700, 07.03.701 and 07.03.702). We have over 500 units inthe field.
Theproblem is that these module stop working. The STAT_LED ispermanently on, there is no communications on the RS232 and themodule does not respond to a ground signal on the ON pin. We do nothave access to the RESET pin on the hardware platforms. It seemslike the unit is in reset.
Someof these hardware platforms have backup batteries and other not, andare all fitted in 12 volt vehicles with load-dump protection. Thisfailure appears to mostly happen when the vehicle is moving, but doeshappen now and again when the unit is stationary. It also seems tohappen in high GSM congestion areas.
Lastly,the modules are running our Python script and all communications onlyuses HTTP protocol via GPRS only.
Wehave tried various power supply test, software changes and networktests to try simulate the problem but without any success. Ihave tried to be as comprehensive as possible, and wonder if anyoneelse has ever experienced the same or similar problem, and might beable to guide me to find the cause, albeit hardware or software. Weare experiencing around about a 10% failure per week due to thisproblem. Any assistance would be greatly appreciated.
please contact TS-EMEA@telit.com support that will put you in contact with Telit Tech Support force in South Africa.
I have already sent the same request to the support guy in South Africa.
Thanks to Telit, Gatetel and the local SA technical team. Your efforts to resolve this is greatly appriciated. I know it is like "looking for a needle", but I hope we get to the bottom of the cause.
No one is able to resolve my problem yet. Is anyone else experiencing this problem running python on the GM862GPS and GE963GPS modules in a mobile application?
With the help of Telit and GateTel, we seem to have got the units to be stable, and none have failed in the last week. This two main fixes revolve around AT commants inside a Python script.
Firstly, it was recommended not to use AT#REBOOT to restart the python code, as this can cause problems. the suggested fix is to use the following:
And to let the python watchdog restart the script.
The second was not to use ATZ in your code. In the days of dialup, this would do a soft reset, but it appears that if does something different in the GSM modules.
I still do not understand why these cause the unit to hang-up, but since making these changes, it seems way more stable.
Thank you very much for the solution report, for sure will be helpful for some of us. Lets keep an eye on your modules for the definitive answer. Thanks for your patience too!
Sadly, although these fixes have helped, the problem still persists, with 4 units locking up in the last 24 hours. This is not good news.
Thanks for the input Lukasz.
I use CFUN=1.
I will look at the VBATT path.
As a thought, What if my problems are power related, ot IO related. Firstly, does this module internally have a brownout circuit to reset the GSM module when a brownout occurs?
Secondly, if any of the inputs exceed their max values, what happens to the processor in the GSM module?
Andy there are 2 possibilities:
– Below 3.22V there is the SW power off. Power supply is monitored and processor is shut down since full functionalities are not guaranteed.
– Below 2.90V there is the HW power off of the processor.
The functionality of the module can be recovered with an ON/OFF pulse as soon as VBATT is again above 3.22V.
The max working level of digital lineas is 3.3V (GE863 and GM862). Absolute level is 3.6V (not functional). Above this limit the port can be damaged.
Have the similar problem with modules on HE-910
Did you find the solution ?
Hit enter to search or ESC to close
Knowledge Base & Download Zone