Connection with EHS6 in Hungary | Telit Cinterion IoT Developer Community
March 7, 2018 - 10:25pm, 1525 views
I am little lighter on information that I would like to be on this problem, but here goes:
Customer in Hungary is reporting their device (weather station with an enbedded EHS6) occasionally stops connecting and requires a power reset. It will connect every 10 minutes for a month at a time and then get stuck. After a power reset I have been able to remote get our internal logs. It look likes the the module is starting up just fine, finding a tower and sending out a UDP packet without an issue. The packet never makes it to our server and the call evetually ***** out. After the attempt no successful calls are completed until the power is removed from the system.
EHS6 appears to shutdown without issue and also restarts without issue.
Any ideas on either what might be the issue or what a potential recovery path might be? Unfortunately my hardware does not have a mechanism for pulling the power from the EHS6. The EMERGENCY_RST would be an option, but I have full control and have no issue shutdown via SMS0.
Rob
Hello,
Could you write some more details about the problem? What kind of connection is the weather station using? Is it any dialup or is the UDP send with AT commands or maybe there is some Java application on the module?
So after a month the UDP packets seem to be sent out from the module but are not received by the server?
Besides that problem the module is responding to AT commands and is registered to the network?
Can you paste the ATI1 reply?
Regards,
Bartłomiej
I have limited information. There is a Java application on the module that controls the UDP send and receive. That appears to be working normally. Here is a snippet from the logs that shows a successful connection and then one that is a failure.
The non-standard URCs are gerenated by our code.
02/02/18 13:48:10 ^SYSLOADING
02/02/18 13:48:14 ^SYSSTART
02/02/18 13:48:32 +PBREADY
02/02/18 13:48:37 +CREG: 1,"0030","00CBA0DC",2
02/02/18 13:48:42 AT^SMONI
02/02/18 13:48:42 ^SMONI: 3G,10588,472,-5.0,-49,216,30,0030,0CBA0DC,8,66,NOCONN OK
02/02/18 13:48:47 +CREG: 1,"0030","00CBB8CA",2
02/02/18 13:48:47 at^sjam=0,"a:/NetUdpATWD.jad"?^C
====== Log Page 234 ======
,""
02/02/18 13:48:49 at^sjam=1,"a:/NetUdpATWD.jad",""
02/02/18 13:48:49 Cell On
02/02/18 13:48:50 ^APPSTART NetUdpATWD v=1.0.3.3
02/02/18 13:49:25 ^UDPCONN1 @34s
02/02/18 13:49:26 ^UDPLINK1
02/02/18 13:49:28 ^UDPKK1
02/02/18 13:51:32 ^Requested terminate: Xmt 540; Rcv 51
02/02/18 13:51:35 ^SHUTDOWN
02/02/18 13:51:35 Cell Soft Shutdown
02/02/18 13:51:35 SessionClose
---------------------------
02/02/18 14:00:36 ^SYSLOADING
02/02/18 14:00:38 ^SYSSTART
02/02/18 14:00:57 +PBREADY
02/02/18 14:01:02 +CREG: 1,"0030","00CBA0DC",2
02/02/18 14:01:08 AT^SMONI
02/02/18 14:01:08 ^SMONI: 3G,10588,472,-3.0,-49,216,30,0030,0CBA0DC,12,66,NOCONN OK
02/02/18 14:01:08 +CREG: 1,"0030","00CBB8CA",2
02/02/18 14:01:13 at^sjam=0,"a:/NetUdpATWD.jad",""
02/02/18 14:01:14 at^sjam=1,"a:/NetUdpATWD.jad",""
02/02/18 14:01:15 Cell On
02/02/18 14:01:15 ^APPSTART NetUdpATWD v=1.0.3.3
02/02/18 14:01:18 ^UDPCONN1?^C
====== Log Page 236 ======
@2s
02/02/18 14:01:19 ^UDPLINK1
02/02/18 14:01:22 ^UDPKK1
02/02/18 14:06:21 ^Requested terminate: Xmt 578; Rcv 0
02/02/18 14:06:26 ^SHUTDOWN
02/02/18 14:06:26 Cell Soft Shutdown
02/02/18 14:06:26 Host Inactivity Timeout
Hello,
The log is not much helpful. We know that the MIDlet is used which is started and stopped by some microprocessor (after each send and receive?) and it sends and probably also receives a datagram.
In fact unlike TCP the UDP protocol does not give any guarantee that the datagram will be delivered, there are no acknowledgments and retransmissions on UDP layer. But according to your description after one undelivered datagram the next ones are also not delivered.
Still we can't be sure if there is no problem in the customer application or on the network provider side. We don't know the firmware version, the application code and any details about the execution i.e. if there is any exception thrown or is there anything unusual besides that there's no reply, if it is possible to establish some other connection etc. This problems happens quite rarely so it might be hard to investigate it.
Maybe the disconnection of data bearer or wireless network would also help instead of rebooting.
It's hard to say much based on the information we have. First of all you need more details.
You might think of contacting Gemalto support (directly or via your distributor). Some investigation and testing would be needed on the customer side to isolate the basic scenario and application functionality that is enough to reproduce the problem. Then the support could verify if the customer code is correct and try to reproduce the problem.
Regards,
Bartłomiej