IMP Network Time Accuracy

IMP Network Time Accuracy

In our main application is to use the Electric IMP
to serially (UART Tx) feed a remote micro controller with your
servers network time. We update the time to the micro controller
once a second. We also feed a LED status bit to indicate second
updates.

We have other precision clock sources like WWVB Atomic
time, GPS and a precision ± 2 PPM Real time clock. In
checking your “network time” it drifts a lot eg up to 7 seconds
or more from our other precision clock sources. We found out
that by shutting the power off the IMP and back on again brought
the IMP back in-line with the other clock sources ±2 seconds.
Any ideas on the drifting or accuracy problem?

Just a guess. The Imp probably does not have a real-time clock onboard. It must be attempting to keep time with the crystal for the micro and these are not usually accurate enough for time.

When the imp is powered up it has no idea of the time so it requests is from the server.

edit:darnit, bad guess, sorry!

The imp does have a RTC, which is set from the server at every server connection. This is used for RTC wakes when in low power mode. It’s pretty accurate (though not +/- 2ppm!). The RTC runs all the time the imp has power.

Right now, the time() call currently drifts quite a bit due to the HSI oscillator being untrimmed; when the CPU is idle we drop bus clocks down and switch to the HSI oscillator which can cause significant time loss.

The next big release switches to use the HSE xtal which is a lot better; as a temporary workaround, adding imp.enableblinkup(true) to your code will prevent the clock switches and you should find that time() is a lot more accurate.

Let us know how this works for you!

time() uses the RTC, which uses LSE, the low-speed crystal. It’s as accurate as the crystal is.

The thing you’re thinking of is the duration of imp.sleep() and imp.wakeup(), which are on the centisecond timebase, plus hardware.millis() and micros() on the microsecond timebase; those are the ones being moved from HSI to HSE. Suppressing clock switching will improve the accuracy of sleep(), wakeup(), millis(), and micros() – but not that of time().

Peter

See, Peter actually knows everything! :slight_smile:

We tried your patch suggestion and the time still drifts a lot.
I think the solution is to have our micro controller
switch a TIP120 darlington to enable and disable the IMP’s supply
power to update the clock periodically once an hour. This would
force or trick your server to update the clock for better precision
network time. Your network time is keeping up with our other accurate clock
sources eg GPS, WWVB and ± 2 PPM RTC when this calibration trick is performed.

addition …
On the downside, if everyone wanted to use your servers as a low cost time
reference then it would be possible with hourly updates @ 2 million users
your servers might not be able to keep up?

if you have 2 spare pins, you could attach an external RTC over I2C

Thks but that defeats the purpose of our project since we already have a GPS, WWVB Atomic clock and an I2C DS3232 precision real time clock.

@impandy: I’d be interested in a PM with details of what drift you’re seeing, because it seems to be out of line with what our expected performance.

However, the imp is not intended to be an NTP-like time source. +/- 1 second accuracy is about the best I’d expect. It seems like you have many many time sources, many of which are better than the imp server itself - is there any reason you want to ask the imp server for time?

No issues with 2 million devices connecting regularly. That’s the idea :slight_smile:

is there any reason you want to ask the imp server for time?
We are using the IMP as a "backup" low cost clock source in our projects. Our on/off/on power trick does fix the drift problem and like I said it brings your server time reference close to our other precision time sources. That should be good enough. thks

Just curious … what is the IMP’s HSI crystal PPM? (parts per million)

By watching the IMP’s time deviation every day and since most crystals are tuned
to ambient temperature then the drift we are seeing is normal. The IMP, in our application, is subjected to somewhat large deviations from ambient temperature and this will cause a large time error. In fact, any micro controller, without having a TCXO oscillator, will have the same problems. Again, forcing the server to update the IMP by powering the IMP on/off/on again once an hour will keep the time good as our expensive, precision TCXO RTC, GPS and WWVB Atomic clocks. The IMP provides an inexpensive solution for remote time keeping.

The crystals (HSE and LSE) are +/-10ppm, I think. HSI isn’t a crystal, it’s an RC oscillator, and is probably +/-10% or worse (and is all over the shop versus temperature). Currently the imp uses LSE for RTC, HSE for centisecond/microsecond time in “CPU fast” mode, and HSI for centisecond/microsecond time in “CPU slow” mode. In the next release it will use HSE for centisecond/microsecond time all the time.

Peter

LSE is 20ppm, HSE is 30ppm, the wifi clock is 10ppm (which, as it gets PLL’ed up from 26MHz to 2.4GHz, is a good thing).

@impandy: what sort of temperature swing are you seeing?

what sort of temperature swing are you seeing?

7 seconds after a few days and ± 15 degrees F. from ambient.

Addition …
Note: @ 20 ppm an error of 1.73 seconds per day but
due to our temperature swings from ambient
this error is greatly amplified.
Now if I can strap the IMP to my wrist and use my body heat as a fixed temperature
source most of that drift would disappear.
Another solution is to force your servers to update once a day to keep the drift down to a manageable number.

Here is our micro controller circuit to turn the IMP off and on for precision
network time

That circuit is definitely not recommended; cutting the ground reference is a bad idea as you have IO pins connected which then have no reference; you’ll get current leakage through those from the VCC line and the imp will be drawing power trying to turn on.

You should use a high-side switch for this; a PFET in the imp supply line (eg FDN302P), source to 3.3v, drain to imp. Pull the gate to the source via (eg) 100k, then connect an NFET from gate to ground (S=nfet gnd, D=pfet gate). The gate of the NFET, when driven high, will turn power on to the imp.

you have IO pins connected which then have no reference; you'll get current leakage through those from the VCC line and the imp will be drawing power trying to turn on.

All we have is one status LED (with current limit resistor) and the UART Tx line which also has the current limit series resistor. Its been working so far?

Another solution is to use a NC relay with driver to interrupt the power just
for a few milliseconds.

In either case, the end result is a “re-calibration” of the network time to the IMP
and it holds within ± 2 seconds which is great!

If you have some current limiting resistors then it’s likely not too bad, but still not generally advisable.

You won’t need to do this soon; forthcoming releases allow you to connect to the server under squirrel control so you’ll be able to connect (and sync time) whenever you fancy it without a hard reboot.

You won't need to do this soon; forthcoming releases allow

In our situation, we design our projects for “today” and its nice to know that some future enhancement will be done tomorrow but if we waited for tomorrow, then we would be not be able to finish any of our projects! It would be nice for Electric IMP to show the future IMP migration path it will take with hard, fixed, dates of completion. We cannot design for the future.

Hard date: definitely in the next month :slight_smile: