Or I have a bug in my code…
Let me simplify and see if it’s still wrong. Standby.
Here’s my code:
function fdn(value){
server.log(hardware.millis()%1000);
}
agent.on(“dn”,fdn);
fdn() gets called every second from a server.
Log looks like:
Fri Apr 05 2013 08:45:55 GMT-0700 (Pacific Daylight Time): 827
Fri Apr 05 2013 08:45:56 GMT-0700 (Pacific Daylight Time): 796
Fri Apr 05 2013 08:45:57 GMT-0700 (Pacific Daylight Time): 691
Fri Apr 05 2013 08:45:58 GMT-0700 (Pacific Daylight Time): 626
Fri Apr 05 2013 08:45:59 GMT-0700 (Pacific Daylight Time): 545
Fri Apr 05 2013 08:46:00 GMT-0700 (Pacific Daylight Time): 514
Fri Apr 05 2013 08:46:01 GMT-0700 (Pacific Daylight Time): 406
Fri Apr 05 2013 08:46:02 GMT-0700 (Pacific Daylight Time): 424
Fri Apr 05 2013 08:46:03 GMT-0700 (Pacific Daylight Time): 301
Fri Apr 05 2013 08:46:04 GMT-0700 (Pacific Daylight Time): 209
Fri Apr 05 2013 08:46:05 GMT-0700 (Pacific Daylight Time): 126
Fri Apr 05 2013 08:46:06 GMT-0700 (Pacific Daylight Time): 72
Fri Apr 05 2013 08:46:07 GMT-0700 (Pacific Daylight Time): 986
Fri Apr 05 2013 08:46:08 GMT-0700 (Pacific Daylight Time): 923
Fri Apr 05 2013 08:46:09 GMT-0700 (Pacific Daylight Time): 864
Fri Apr 05 2013 08:46:10 GMT-0700 (Pacific Daylight Time): 775
Fri Apr 05 2013 08:46:11 GMT-0700 (Pacific Daylight Time): 759
Fri Apr 05 2013 08:46:12 GMT-0700 (Pacific Daylight Time): 664
Fri Apr 05 2013 08:46:13 GMT-0700 (Pacific Daylight Time): 589
Fri Apr 05 2013 08:46:14 GMT-0700 (Pacific Daylight Time): 505
Fri Apr 05 2013 08:46:15 GMT-0700 (Pacific Daylight Time): 438
If my math is correct… It drifts 70ms per second!!!
You can tell by the timestamp above the server isn’t drifting?
Please help!
Same 4 lines of code above…
Was just working without drifting at all for 5 minutes!
Then it started again??? Same as before.
This change happened while I was watching, I didn’t touch anything or reboot.
Odd…
Experiment is repeatable. Nearly the same each time. Once it starts drifting it never stops?
Verified the log messages occur perfectly in sync (within 100ms) of accurate clock. The timing of the log messages does not drift.
Try adding imp.enableblinkup(true) to the start of your code?
There’s a known issue with the current release where we drop ticks at clock switches. Locking the blinkup sampler on with the above command stops the switching and hence stops the drift. It’s fixed in the next release.
You’re the Man! Enableblinkup also makes the green LED continue to blink?
Wait until you see what I’ve made. The ability to record the time of an event with near millisecond accuracy. I mean absolute real world time. Maybe…
Yes, enableblinkup leaves blinkup on too…
I’ve been able to calbrate millis() to be within 1ms PER DAY.
The good news is that it’s barely effected by temperature between 50-90F.
Is your timing code available somewhere?
Let me find it. It’s been awhile. What are you trying to accomplish?
I am recording and re-playing discrete events (from one imp to another) where I care about the timing between them but am not terrifically concerned with absolute time. Events happen about once every 1s and I store the time interval between them. In my current implementation the cumulative effect of clock drift is a large delay in playback.
Really in general I’d just like to have one true clock with ~1-10ms resolution that I can count on so I don’t pull my hair out figuring out timing for each application 
If you want to be even more accurate, with a low cost, you can buy 2 or more GPS modules with a PPS output pin. Let me know if you’re interested in that solution. This will give you absolute accuracy on the order of nanoseconds. Another option is to send each event occurrence to one arbitrary agent. Keep in mind that multiple Imps can only talk to their own agent directly. You’d have to use HTTP to talk from one agent to the next, which involves an unknown delay between 80-200ms in my case. So your accuracy would be of that order of magnitude. That’s not what you asked for.
So the best solution is to start with my code which gives you about 10ms accuracy once you calibrate the Imp clock with a constant. It will remain within 10ms if you reset it about once per day using NPT thru the agent. This gives you an absolute time which is independent of temperature between 50-90F I have found.
Let me test it with the new v25 firmware, and clean it up a little. Your solution is near!
The latter sounds perfect, having to use GPS to get a decent clock seems ridiculous, where decent is <10ms.
The delay of 80-200ms is fine as long as the recorded times of the events (on the recording imp, not the server etc) are consistent with reality.
A general NTP implementation for Imp sounds like a great idea (I’ve only skimmed the feature requests board, my other feature request would be searching within just one Discussion Board
Thanks!
I don’t have a good connection here yet, so it may be difficult for me to test my code today. The 80-200ms variance will change from one minute to the next, by more than 10ms. You cannot get a more accurate measurement of the time between events with this method. My code allows you to find the correct constant to keep the local clock in sync with NTP on the Agent. You can prove it’s working before you implement it. Although it’s difficult to get the absolute time within 10ms over the internet, you can see there is zero drift within a 24 hour period.