Hi,
I need a precision timeout functionality. Like several months.
我用一个app_easy_timer()和最长延迟possible (5*6000-1), which is 5 minutes -10ms. Correct me if am wrong.
In my timer callback I increment my own counter and restarts the timer with app_easy_timer().
To get the highest precision I use
#define CFG_LP_CLK LP_CLK_XTAL32
XTAL32 for sleep.
然而,在我看来like my timer is running 5% to fast.
My question:
What should I do to get the best timer precision, when my timeout is on the order of months?
Thank you in advance
Ciano霜
Denmark
Keywords:
Device:
Hi ciano,
The app_easy_timers() haven't got enough presision to run as an RTC and to calculate accurately the passage of months, the reason for that is because the base timer, that the kernel timers rely on, it gets compensated every time the device wakes up, and that introduces an error in the time measurements, i am not sure if changing the current XTAL32 with a more accurate clock you will be able to reduce that error, most probably you wont. What you can try in order to measure time, instead of having the a kernel timer, you can wake up via a kernel timer and poll the time from the BLE_BASETIMECNT_REG via the lld_evt_time_get() function, perhaps this will give you more accurate time measurements since it removes any overhead that the ke timers have, but even that way, i am not sure if you will get the accurancy that you want for an RTC.
Thanks MT_dialog
Hi Dialog,
Thank you for your hint.. I will poll the BLE_BASETIMECNT_REG and test it.
Best Regards,
Ciano霜
Denmark
Hi Dialog,
One more question:
If using an accurate XTAL32, which we do, wont give a more precise time, then what is the benefit for using a XTAL32 instead of the internal RCX?
Best Regards,
Ciano霜
Hi ciano,
The XTAL32 is mandatory only over boost configuration since the RCX wont be able to function properly, you can only use the RCX over buck therefore the XTAL32 can be ommited (as indicated by the datasheet). The reason for using XTAL32 is not in order to keep more accurate timing (which will improve the results in time keeping, over the RCX, but i dont think that the whole system is going to be accurate enough for an RTC for the reasons i mentioned in my previous post). The reason for using the XTAL32 in boost mode is because when the device goes in sleep mode the RCX is powered from the alkaline battery and not from DCDC converter, so different voltage on the LP clock and this will result in drifting.
Thanks MT_dialog
Hi Dialog,
I have not tested you suggestion, adn read BLE_BASETIEMCNT_REG via lldevt_time_get() in my 5 minutes timer.
I calculate the elapsed seconds since beginning of time, and print the result.
The code looks like this
uint32_t app_too_old_timer_cnt[NUM_SAFETY_CPY] __attribute__((section("retention_mem_area0"),zero_init)); //@RETENTION MEMORY;
uint32_t app_ble_basetimecnt_reg_old[NUM_SAFETY_CPY] __attribute__((section("retention_mem_area0"),zero_init)); //@RETENTION MEMORY;
..
inside 5 minute call back
uint32_t ble_basetimecnt_reg;
uint32_t time_since_last_cb_in_seconds;
// Calculate time parsed since last callback, and increment total counter in seconds.
ble_basetimecnt_reg = lld_evt_time_get(); // get 625us ticks
time_since_last_cb_in_seconds = (ble_basetimecnt_reg - app_ble_basetimecnt_reg_old[0]) * 0.000625;
app_too_old_timer_cnt[0] += time_since_last_cb_in_seconds;
// update copy of basetimecnt
app_ble_basetimecnt_reg_old[0] = ble_basetimecnt_reg;
arch_printf("%i\r\n",app_too_old_timer_cnt[0]);
this gives me the following printout, where I noticed 2 large Jumps in time:
82823 [16/10/16 - 15:09:15:366]
83122 [16/10/16 - 15:14:15:355]
83421 [16/10/16 - 15:19:15:345]
***JUMP***
2684189 [16/10/16 - 15:24:15:344]
2684488 [16/10/16 - 15:29:15:333]
…
2767311 [17/10/16 - 14:34:12:500]
2767610 [17/10/16 - 14:39:12:499]
****JUMP ****
5368378 [17/10/16 - 14:44:12:489]
5368677 [17/10/16 - 14:49:12:488]
For me to solve this pusle, I need to know the reason for these two jumps.
Do you have any explanation to why this could happen?
Best Regards,
Ciano霜
Denmark
Hi ciano,
Something that i ve noticed, the 83421 value before the "JUMP" corresponds to ((83421/60)/60) = 23,1725 hours (you ve run this test for a bit less than a day, is that correct ?) which is approximatelly the size of the BASETIMECNT which is 27 bits count register (on the next 5 minutes, from the time that the 83421 value was printed, the counter would have elapsed and would start counting from the beggining). So when the timer reaches its maximum point it will roll over thus, when the ke_timer hits the current value of the ble_basetimecnt_reg variable will be less than the previous value of the same variable, therefore the subtraction will result in an negative number stored in an unsigned 32-bit variable type and then you add that value to the previous calculated value and i suppose that this is the reason for seeing this kind of jumps in the values that you print.
Thanks MT_dialog