can we use stop mode to wake xenon once a month and send the reading and then go back to sleep for another month ? does the clock drift ? and can it keep up with the time ? For such an application would you recommend an adafruit DS3231 featherwing or the inbuilt clock ?
How accurately do you need to wake up after 1 month asleep? I have not tried this sort of thing more than 1 day. Suggest you try some tests gradually increasing the number of days. The external RTC is required with Standby / deep sleep mode.
how does the internal clock keep time with once a day, do you see any drift ?
The max sleep time on the mesh devices is currently ~24 days.
(2^24 - 1) * 125ms ~= 24 days
(I just learned that myself from Andrey Tolstoy - should be documented soon)
the clock is only available in stop mode, correct ?
I am planning to use xenons for some battery powered projects which will be in the field for say about 18 months, can the clock keep track of day, months and year also ?
is there any drift after say 1 year of usage ?
@abhishek2101, there is no Real Time Clock on the nRF52840 used by the mesh devices. Instead, it is a Real Time Counter which can be used by the DeviceOS to "simulate" a true RTC. However, this would not work in STANDBY sleep mode without waking the processor at regular intervals and would have considerable drift over time. I suggest you look at using an external independently powered RTC which could wake the processor from STOP or STANDBY sleep are needed. See here:
i am not able to buy that board, can you suggest any other clock ?
@abhishek2101, these are currently available:
This board allows the interrupt output to the host processor to be configured so it goes HIGH instead of LOW on alarm. This is required by the current Gen3 DeviceOS (0.9.0).
You can also build your own version of this board with these available PCBs:
What is the maximum sleep time on non-Mesh devices?
On Particle non-mesh devices the timed wake interrupt is created by the RTC which runs on 1 second resolution and has an internal 32bit counter which should allow sleep times up till January 19th 2038.
IIRC the sleep command uses the sleep timeout parameter to calculate
now + x_seconds to store the wake time which the RTC then compares to the internal, advancing now time and triggers the wake interrupt when they match.
The limited sleep time I mentioned is due to the fact that I don’t know how the RTC will cope with the epoch time roleover 2038