I am operating a mesh network where the endnodes are not cloud/internet connected and rely on the gateway to obtain the current local time to correctly set their RTCs. These endnodes are sleepy and use the Sleep (Stop) mode to pause for around 60 seconds and then wake on RTC, send a heartbeat and stay awake for a short period to listen for any gateway commands before re-entering sleep. These devices all seem to gain time - is there an issue with the accuracy of the RTC with Sleep (Stop). I do something similar with the Photon and do not notice any drift.
The nRF52840 in Gen 3 devices doesn’t actually have a real-time clock module. It’s a real-time counter that’s incremented based on the system CPU clock, so it’s not particularly accurate.
Time synchronization isn’t done to the gateway, however. Or at least not directly. Each non-gateway (end node or repeater) will only synchronize the clock on a establishing a cloud connection, or when you manually synchronize using Particle.syncTime. And then it’s synchronizing to cloud time not the gateway’s time. The gateway is necessary to get the packets to the cloud of course, but its time setting is not used.
Wow, these Gen3 devices have the power to disappoint!
If I want to implement a reasonable fleet of sleepy end nodes that are only Mesh connected, I am either going to need to very regularly manually sync their local time with the gateway (probably every time they wake up) and the gateway also which since it needs to be powered can be more easily make Particle.syncTime calls. The alternative is to fit each one with an RTC - ultimately a better solution.
3 Likes
For a Xenon in an Ethernet featherwing (i.e. with a reliable internet connection) working as a Mesh gateway, is there any advantage/disadvantage in using the ntp-time library to keep the ‘RTC’ accurate over using Particle.syncTime? I am going down the route of using a DS3231 based RTC (Adafruit 3028 feather for prototyping) as this appears to offer the best accuracy/cost for the sleepy endnodes - possibly also for the gateway. I would rather not have the extra cost of the RTC and manage this in software. Have you any emphirical data on how accurate or otherwise a Xenon in an Ethernet featherwing RTC is? Thanks
@armor, take a look at @rickkas7 RTC featherwing work. The RTC used can also be used to wake a mesh device from deep sleep.
Thanks for reminding me about another of these great projects that Rick has done - I had bookmarked it and then forgot to look back at my bookmarks! I am not sure I need the accuracy in the waking and certainly I was not planning using Deep Sleep/Standby - but the MFP is neat.
2 Likes
Hi, i am facing a similar problem with a set of Xenons that i want to use.
I also have come to the conclusion that the clock of these devices does deviate a lot, especially when in sleep.
I don’t quite get why, as there is actually a RTC crystal shown in the schematics of the xenon.
xenon-v1.00-schematic
Is this crystal not used at the moment or are there other factors that lead to a bad performance even with the 32khz crystal being used?
If somehow possible I’d like to avoid using an additional external RTC over I2C and the additional software logic that comes with it.
Some pointers would be greatly appreciated
~Ben
Belated welcome to the community. The reason you never got a reply was that the topic was ticked as solved.
I was just looking back at posts around the inaccuracy of the sleep period for a Xenon.
I have implemented an RTC (DS3231) on my prototype board using an Adafruit feather for DS3231.
I am still finding that even a short (<60 seconds) stop sleep can vary enormously to the point that it really cannot be relied upon.
I found my way to this post because I am attempting to use the Xenon clock to write a timestamp of a visit to an NFC tag. The Xenon is completely disconnected (System Mode Manual) and the absolute time set upon flashing and only maintains time while the Xenon remains powered. Low power use is important for these sensors so I implemented an NFC triggered wake to to a stop sleep mode. I quickly found the unacceptable drift of time when sleeping.
In a 24 hour period, the clock was observed to drift as much as 1.5 hours. The data:
Start with less than 3 minutes time difference:
{"station":"47571","timestamp":"2019-12-08T21:27:26-08:00"},
{"station":"38377","timestamp":"2019-12-08T21:26:12-08:00"},
{"station":"e00fce68daebdb15e7531da6","timestamp":"2019-12-09T21:24:59-08:00"}
+~24 hours
{"station":"47571","timestamp":"2019-12-09T19:57:45-08:00"},
{"station":"38377","timestamp":"2019-12-09T19:05:11-08:00"},
{"station":"e00fce68daebdb15e7531da6","timestamp":"2019-12-10T20:44:03-08:00"}
-
e00fce68daebdb15e7531da6=(baseline) cloud connected Argon with accurate synched time - 47571= Xenon ~47 minutes slow
- 38377 = Xenon ~100 minutes slow
Similar results observed across two tests.
The sleep mode used is stop mode with wakeup on interrupt.
I’m now testing the clock without using sleep mode. Preliminary results are more promising, although my application is not practical without using a low power mode.
I am using a similar sounding pattern of stop sleep. I decided to go with the DS3231 RTC - I sync the time to a gateway which is internet connected - the device resyncs locally with the DS3231 after each wake so that the time is only ever out by 1 second due to the delays in the sync request and reply from the gateway. The last post I made I was seeing what I thought was highly inaccurate sleep periods - others reported it was fine and I tracked the cause to something else in the application code. For short periods of seconds (up to 300) it seems fairly accurate - long not so good. I also use the DS3231 alarms and interrupt to wake from longer sleeping periods.