Hello,
We've been using DA14681 chip on our smart watch and we observed that the time since boot was changed after a sleep.
We are using pm_mode_extended_sleep and the tick count is done perfectly but the issue appears when we do an RCX calibration since the tick_rate_hz is changing. This caused the macro OS_TICKS_2_MS to reflect a different OS time and thus this will affect out timestamp.
Ex:
tick_rate_hz | ticks | ms | delta (previous_ms - current_ms)
478 t=3830 8012, 44
478 t=3851 8056, 44
547 t = 3872 7078, -978
547 t=3891 7113, 35
547 t=3913 7153, 40
As it can be observed due to the change of tich_rate_hz the time in ms changed to a previous value. The minimum tich_rate_hz is 450hz and maximum is 550hz.
In order to keep the time at the proper value I have suggested 2 options:
1. change the number of xTickCount to correspond to the new frequency (can be positive or negative delta). This may affect other functions that uses tick count.
2.增加了蜱虫count based on a base frequency (should be lowest common divisor of the frequencies). This may require a float operation to have the right precision.
Has anyone else encountered this time issue?
What is the best solution to keep the time running constantly regardless of the tick frequency?
What is the reason of the calibration task? I saw that if we don't change the tick_rate_hz everything is ok.
Thanks in advance for your responses and suggestions.
Hi cmarius,
I dont quite understand the issue or what exactly you are doing, do you perform a seperate RCX calibration ? The tick_rate_hz variable that you mention is the configTICK_RATE_HZ in the FreeRTOSConfig.h file ? Can you please provide some more information on what exactly you are trying to do.
The calibration task should be invoked regularly in order for the RCX to be calibrated (when the RCX is used as a LP clock), if not invoked the RCX will drift.
Thanks MT_dialog
Hello,
That is correct. configTICK_RATE_HZ in the FreeRTOSConfig.h file is defined as rcx_tick_rate_hz and it is modified by sys_clock_mgr in calibration.
We are using RCX as LP clock but the change of frequency affects the conversion tick_to_ms.
Should we update RCX but avoid changing the tick_rate_hz?
Is there another fix to have the proper time since boot if we update the RCX with the tick rate as well?
Thanks.
Hi cmarius,
As mentioned the RCX cannot generate a steady frequency (and it will also vary upon temperature) thats why the device needs to calibrate the RCX at steady intervals, it measures the frequency of the RCX and calculates the appropriate values in order to have a tick period of approximatelly 2ms and in order to keep the tick steady. So the rcx_tick_rate_hz holds the value in Hz of the tick period which should be near 500Hz in order to have a 2ms period. So since the RCX frequency isn't steady the SW will try to do as much in order to compensate that variation, and this is why the rcx_tick_rate_hz varies. The function that does this is the get_optimum_tick_rate(), and as far as i am aware there is no reliable way to get accurate timing like this, since the RCX is not a stable clock, even if you update the RCX but not the tick_rate_hz, then you will just have the illusion that you are measuring time correctly since the calculations will be valid (no negative deltas) but still they wont represent the actual time. What you can try to use in order to keep time and be more precise is to use the rtc_get() function.
Thanks MT_dialog