Hi,
I am trying to calculate the real time using ticks. My idea was, that I know real time of some tick. For example, I know, that tick 0 is 10:00. I expected that one milisecond = one tick. After approx. 7 hours is time delayed for 12 minutes. (At this moment I have in the log 26 015 s → 433 minutes. I started the device at 12:39. 12:39 + 433minutes = 19:52, but the real time is 20:04) Is it possible? Is possible that every tick takes different time?
Does exist any other method how to calculate real time? Probably it is possible to use GPS module, but is little bit expensive for this function
Does it mean that when I plan to run something after 8 hours, it will run not after 8 hours, but for example after 7 hours and 45 minutes? (It is 2 minutes difference in every hour --> it is 48 minutes per day, it is so much…)
So, when I would like to call something once per day, It will be performed not after 24hours, but after approx. 23hours?
Is any way how to call functions more accurately than I explained? Or are you planning to make it more accurately in the SDK? (if yes, when?)
Unfortunately this breaks my concept, because until now I thought that 1tick = 1ms
Yes is in plan add support for calibration rtc over sdk, but for now I don’t tell when.
This problem is not only about support in sdk, but must exist way how you can calibration start and settings it.
For better working with nodes, we plan to use AT interfaces.
it is a few years I have implemented RTC for BigClown scheduler so I may be a little wrong but here is what I remember
The scheduler and tick is running from RTC, the RTC has 32768 Hz crystal. You can easily use 15 bit counter (2^15) in the RTC to get correct number of seconds. But we needed more precise time slices for scheduler so we have decided for compromise that the tick and scheduler will be incremented in 10 ms intervals. That means that you have to count 32.768 which equals to 10ms. But what with that 0.768 fraction when MCU registers are integers? There is a 16x divider and WUTR (wake-up timer register) register is 20, that means that 10ms is in real
You can cheat a little bit and change the WUTR to 19 for a few cycles to compensate, you can get close to 10ms but you cannot get exactly to 10ms. So we have accepted this inaccuracy.
Good news - today we’ve implemented RTC date and time basic functions. http://sdk.bigclown.com/group__bc__rtc.html
(you don’t have to call bc_rtc_init function, it is empty right now and initialization of RTC is always done in by_system)
It is far from perfect. In the future we would like to add some software timer callbacks for call once a:
second
minute
hour
day
But now you have to create your own code for example in a task, that will check the RTC time.
We need to do some further testing for precision. There is still some innacuracy around fraction second a day, but it is much more usable than with a bc_tick.
Hi Martin,
these are great news! Thank you for detailed description how it works. It is much complicated than I expected… I will try it! 5s per day is great, because it is 150 seconds per month. At this moment I am syncing time from the server four times a day. At this moment I can do it much less.
I did some bigger tests on more Core Modules onvernight and it seems that 5 second error was my mistake. The Core Modules have correct time only a fraction of a second which can be because I entered time by hand so this could be the initial inacurracy.
I keep them running for a few days and let you know.
Martin
I’ve tested the inaccuracy of the RTC clock on two units.
Test period: 21 days
Unit A: - 30 seconds
Unit B: +45 seconds
I’velooked around and everyone else is measuring this in ppm - parts per million.
Here is some computing from top of my head, not sure if its right…
21 days ~ 1800000 seonds ~ 2 million seconds
30 + 45 = 75 seconds of difference
72 / 2 (because of 2 mil samples) = 36 ppm ?
It looks good. I am going to try it in my solution. It resolve my problem with time shift. At this moment I am syncing time from server periodically. It is consuming lot of power, so I very appreciate this function
