ConnectPort X4 time function unreliable

Greetings all,

I have been developing an application on the ConnectPort X4 for receiving, parsing, and collecting packets sent from remote devices. In addition to using the socket.timeout exception, I am using a timer that is based off of the time() function in the “time” module.

I have discovered a possible issue with time management in the X4. If a Python application is running, the time does not update properly. The easiest way to see this is to:

  1. telnet into the X4.
  2. enter “python” into the command window and hit enter
  3. enter the following code:

>>>from time import time
>>>while 1:
...    print time()

(be sure to indent the line following the while loop)

As can be easily seen, this timer does not reliably count every second.

Furthermore, if you bring up the X4’s web interface in a browser and navigate to the “System Information” page, if the Python script is running, you can see the Date/Time uptick by 2-3 seconds on a refresh (hit the refresh button constantly).

I have tried using the “timer” function built into the “threading” module to no avail, so I performed a comparison on the time() function to determine if the sender timed out, and unfortunately this time() function can return improper values - sometimes jumping as much as 29 seconds in one iteration of the loop, with no pause in-between. I’m assuming this is happening because the X4 is synchronizing its internal time somehow.

Anyhow, is this a known bug? Are there any other time function available to me on the X4? Is there anything else I can do outside of a socket.timeout exception that will reliably time out a device that has not responded in a specified time?

Please let me know as soon as you can.

Turn off SNTP update, then manually set a time. You need to manually set the time to undo the damage SNTP has done.

The hardware RTC within the CPX4 is accurate to at last 1 second per day, but the SNTP update in the EOS/firmware is … well, bad is the nicest thing I can say about it.

I have seen jumps of HOURS into the future or past when SNTP is active.

Thanks for this, Lynn. I’m experiencing the same time weirdness and was just about to go off chasing it. Another post I saw suggested that the problem could be solved by making the SNTP update infrequent, but it sounds prudent to avoid the built-in SNTP altogether.

  • C

Thanks for the quick responses. The X4 was set up to update via cellular every 60 seconds. I removed this feature; I’ll test to see if this was in fact causing the problem.


Yah, unfortunately cellular time is a hit-or-miss. Of the large customers I’ve worked with - those with over 5000 X4 devices - they tend to see time problems related to cell-towers in perhaps about 0.5% of their devices.

So 99.5% of the sites work fine, but those 0.5% bad can be hopeless. What we’ve seen:

  1. cell time which is always offset by a few days or weeks (aka: time is okay, but date is always off by say 11 days.
  2. cell time which only changes a few times per day - so of 24 hourly samples, 13 might have 3:12AM as the time stamp, 4 have 7:38PM and so on.
  3. cell time which never arrives (starts at 00:00:00 1-1-2002 and counts up), and the cell modem doesn’t tell the Digi that the time is bogus. The GSM module API includes various errors for time, but the actual big-name modules don’t ever seem to use the errors, so pass of bad time as okay.

Just as a follow-up, disabling the functionality did indeed fix the problem.

I have contacted Digi through our regional rep and made them aware of the problem.



Thanks, unfortunately there’s not much Digi can do if the cell tower gives bad time, but claims it is good. If the cell tower gives a Digi the wrong time as correct, how would you suggest the Digi learn the truth?

Imagine being blind and having no sense of temperature feel. You ask a-passer by what time it is - they say with confidence “3:15pm”. Is that the right time? You’d have no way to know.

I guess with human+cell phones it’s not much of an issue because people move around, change tower frequently. The only place i have witnessed this bad cell time directly is in the oilfields in Taft CA ( ), and although the cellular people I have asked scoff at the idea, I suspect they move older, less reliable equipment into such people-less environments which need cell service for commercial reasons.