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.
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
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.
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.
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
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.