Hi,
We have been noticing some drift issues with the RTC using the RCX clock which has lead to a few questions. The main issue that started this is we have seen time drifting of up to an hour (on average) over two weeks on a sample size of around 5k-6k devices, which is nearly 3000ppm by our calculations.
1. The SDK source stops the RTC, reads the time and date, then starts the RTC again. Is stopping and starting the RTC contributing to this drift? We are reading from the RTC at a frequency of 0.1Hz to 10Hz. Is there a way to read the RTC without stopping it while still keeping the guarantee that the time and date are correct?
2. From [1] it sounds like the RCX is calibrated when exiting a sleep mode, but that same source says the RCX doesn't get calibrated if the RTC is enabled. [1] also states that stopping the RTC, calibrating, then starting the RTC results in larger drift. Will calibrating the RCX help at all with this issue?
3. How do we minimize the ppm drift of the RTC? Adding an external crystal is our last resort, if it is even possible.
Best,
Nathan
References
[1] community.renesas.com/.../da14531mod-rtc-accuracy
Hi Nathan,
Thank you for posting your questions online.
1, Which sleep mode you are using?
2, As the thread you shared, OV has a very clear description, Voltage and temperature will effect the ppm. So what kind of operation condition your device is used?
3, about the calibration for RCX, even regular calibrations can't handle out if the environment temperature has a big gap or voltage waves.
BR,
JH_Renesas
Hi JH,
1. Extended Sleep Mode
2. Voltage varies from 3V to 2V (lithium coin cell), the device is in bypass mode. Initial power up occurs around 22 C and storage in a semi-temperature controlled warehouse of 21 C when occupied and fluctuates when not.
3. We have seen battery voltage fluctuate with time of day (due to temperature) but from our understanding the battery runs through an LDO when in bypass mode which should flatten the voltage seen by the device.
1，
nathan_bsee said:The SDK source stops the RTC, reads the time and date, then starts the RTC again
This is not necessary to stop, read, start. It's Readable in the running time.
2,
nathan_bsee said:From [1] it sounds like the RCX is calibrated when exiting a sleep mode,
Yes, The RCX will been calibrated in every in every BLE awake. but RTC can't refresh the new calibration offset value in run-time. so this may cause a drift. but this drift is lower than 500ppm.
3, attaching an external crystal can be a choice, but you need to remap the SPI flash assigned PINs.
JH,
1. Great, but can starting and stopping the RTC contribute to the drift we are seeing?
2a. So there is no way to refresh the RTC calibration without stopping the RTC?
2b. Since OV says in [1] that stopping to re-calibrate (assuming this is the same as refreshing) can make the drift worse, we are stuck with the original calibration for the most accurate time?
2c. So, assuming the voltage and temperature are within-spec, the RCX will never be less accurate than 500ppm? By extension, say the RTC is calibrated at -500ppm and the RCX has been re-calibrated to 500ppm, the RTC should never be less accurate than 1000ppm?
1, Yes, it will make drift worse
2a, yes
2b, Yes, so, you can find some other solutions like a BLE RTC sync up from mobile.
2c, Yes if the RTC is keeping running.