I’d like to build a battery-powered clock with no physical interface and no access to the Internet. The user will set the time from a web page the clock will broadcast for the first five minutes after the battery is installed, then turn off the radio to conserve power. ESP8266-based systems and the Photon are the main contenders.
Of course, there are lots of Photon clock projects out there, but all the ones I’ve come across get their time from the net. At this point in my analysis, it seems fairly straightforward to do what I want with the Photon, plus the Photon has an RTC which is missing from the ESP8266 offerings I’ve seen so far.
The general approach I’m thinking of taking (feel free to offer a better one) is to use System.sleep() to sleep for, say, 55 seconds, update the time variable and display (it’s e-ink, so it takes awhile), then use one of the Time object methods to decide when to, precisely, go back to sleep.
I just wanted to confirm the Time object is preserved during System.sleep(). Wouldn’t make much sense otherwise, but I often get hammered when I assume. I also assume it gets its time from the RTC, but regardless of where it comes from, is there a way to measure the accuracy of its timebase so I can introduce a correction factor to improve the accuracy?
I may make 50-100 of these clocks, so I can afford to invest 10-15 seconds determining the factor for each (using a frequency counter, e.g.) and then customizing a variable in the code before flashing. Running each for an hour or more to measure an accumulated error won’t work, though. Thanks for any tips.
Yes, the RTC keeps running during sleep and you can easily calculate the sleep period to wake aproximatly the same time before the minute change.
However, the Photon’s RTC has a drift of ~1-2 seconds per day, so you’d have to re-set the time regularly. But the drift is neither constant for one device nor across devices so you’d have to find a fitting approximation for your device and environment.
Thanks, ScruffR. I thought that temperature and age tend to be the biggest causes of drift in a crystal, and these clocks will be in homes and offices with fairly consistent temperatures. Of course, I could measure age easily enough, but there probably isn’t any way to correlate it to drift. Is there something else influencing the drift of specific devices?
Also, is there a way to measure the RTC’s accuracy other than just toggling a pin every second and measuring how far off 1 Hz it is? I don’t need atomic precision, but two seconds/day is too much. I’d like around .5 second/day. Applying a correction factor in code once a day, of course, would be trivial.
You can sync the photon RTC with cloud (unix) time. You should do this once per day to ensure accuracy but if you have a cloud link then there is no reason to run this slightly more frequently - say once per hour. That would keep the time to the nearest second. If a cloud connection is not feasible then an accurate RTC via I2C could be a DS3231 - it is temperature compensated and super accurate. This would also be a way to calibrate the Photon RTC?
No network connectivity, I’m afraid. DS3231 is a fallback if I can’t correct the RTC drift. I’m hoping I can measure it quickly on each device and apply a correction factor in code. I’ll need to do some tests to see how well that works.
If you search for comparison of RTCs you will find approaches to measuring drift and also how to correct it. If no network connectivity it begs the question why use the photon? An arduino/Atmel and a RTC would be simpler with buttons to setup but obviously without the web page!
I also assume it gets its time from the RTC, but regardless of where it comes from, is there a way to measure the accuracy of its timebase so I can introduce a correction factor to improve the accuracy?