RTC library

What could be included in further releases, or for the forum.
electrobling
Posts: 77
Joined: Fri Jan 26, 2018 9:28 pm

Re: RTC library

Post by electrobling » Mon Apr 09, 2018 6:00 pm

GrumpyOldPizza wrote:
Sun Oct 23, 2016 2:01 pm
Ok, finally got around implementing all of this for the STM32L4 core. Could somebody review && || provide feedback whether I got the API and functionality correct ?
[...]
Some notes. RTC.getCalibration/setCalibration allows to speed-up/slow-down the clock. One uses RTC.pinMode(OUTPUT_1HZ) for example to output a 1Hz signal on PC13 which can be compared to a more precise reference clock. RTC.adjustTicks() can be used together with RTC.pinMode(INPUT_SYNC) to aligned the RTC with an external clock. Say one connects the PPS of a GPS to PC13, and uses RTC.onSync(). Each time there is a rising edge on PPS, the onSync() callback will be called, and with RTC.getSyncTicks() the offset (or adjustment factor) can be determinted. The sync facility itself can be used also to measure the exact time of an external event, say a button press (which is the default for Dragonfly).
I'm just curious about the sync method. I admit I haven't yet looked at the F4 calibration circuit to see if there are any major differences from the F1. But on the F1, it takes more than one second to obtain a measurement equal to the register calibration steps, it takes at least 32 seconds. What I did is sample the 32kHz ticks twice, at least 32 seconds apart. That is because N pulses are removed in one 32S interval. Then some math to scale it to calibration steps. Is that close to what you are doing with the sync method in your RTC library?

Also have you considered the possibly intermittent nature of the incoming sync? For example, a device might only get PPS when it is near a window and it would be desirable to automatically retain the resulting cal, and continue to operate normally, even if the whole thing is moved to a place were GPS is dark.

Or, if the device lacks GPS hardware, and it is applied to external terminals for the purpose of an initial or a periodic calibration.

User avatar
GrumpyOldPizza
Posts: 204
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: RTC library

Post by GrumpyOldPizza » Tue Apr 10, 2018 3:03 pm

electrobling wrote:
Mon Apr 09, 2018 6:00 pm
GrumpyOldPizza wrote:
Sun Oct 23, 2016 2:01 pm
Ok, finally got around implementing all of this for the STM32L4 core. Could somebody review && || provide feedback whether I got the API and functionality correct ?
[...]
Some notes. RTC.getCalibration/setCalibration allows to speed-up/slow-down the clock. One uses RTC.pinMode(OUTPUT_1HZ) for example to output a 1Hz signal on PC13 which can be compared to a more precise reference clock. RTC.adjustTicks() can be used together with RTC.pinMode(INPUT_SYNC) to aligned the RTC with an external clock. Say one connects the PPS of a GPS to PC13, and uses RTC.onSync(). Each time there is a rising edge on PPS, the onSync() callback will be called, and with RTC.getSyncTicks() the offset (or adjustment factor) can be determinted. The sync facility itself can be used also to measure the exact time of an external event, say a button press (which is the default for Dragonfly).
I'm just curious about the sync method. I admit I haven't yet looked at the F4 calibration circuit to see if there are any major differences from the F1. But on the F1, it takes more than one second to obtain a measurement equal to the register calibration steps, it takes at least 32 seconds. What I did is sample the 32kHz ticks twice, at least 32 seconds apart. That is because N pulses are removed in one 32S interval. Then some math to scale it to calibration steps. Is that close to what you are doing with the sync method in your RTC library?

Also have you considered the possibly intermittent nature of the incoming sync? For example, a device might only get PPS when it is near a window and it would be desirable to automatically retain the resulting cal, and continue to operate normally, even if the whole thing is moved to a place were GPS is dark.

Or, if the device lacks GPS hardware, and it is applied to external terminals for the purpose of an initial or a periodic calibration.
A loaded topic. I am starting to use a slightly different technique now, mainly because the SYNC input might not be always available. The idea in general is to qualify the PPS input with a valid fix. I.e. it's only armed after a valid fix (or sequence thereof). If you have a valid fix, then you have everything down to the second essentially. So you need to align the subsecond as a first step. With a PPS interrupt that is half way easy. If the getSubSeconds() read back is say between 1 and 16383, then you need to subtract from the subseconds, i.e. RTC.adjustSubSeconds(-offset). If your subseconds are between 16384 and 32767, then you need to add to the subseconds. Obviously you want to apply a filter, so that the steps close to the right alignment are smaller than the ones from far out.

If you have 2 back to back PPS measurements you also can derive from the uncompensated subseconds the period, and hence do fine calibration. Again, the issue is jitter, which requires a filter.

Have only really looked into that with regards to a GNSS ...

electrobling
Posts: 77
Joined: Fri Jan 26, 2018 9:28 pm

Re: RTC library

Post by electrobling » Tue Apr 10, 2018 3:39 pm

All good. I looked at the manual yesterday. You definitely have your work cut out for you, the F4 RTC calibration options are more complex than the F1. Of course, there are multiple options and use cases so it's sometimes difficult to decide how to extend the basic framework into an interface. I see what you mean about the single back to back PPS, but if I recall correctly, some modules provide it with only a +/- 10uS accuracy. That wouldn't be sufficient for a 1PPS or finer calibration. I am also a bit lost about how you could measure the 32kHz clock accurately in only only one second. But if you have this all in hand, it will become evident when you publish.

Indeed, when I experimented with some GPS modules, they sometimes provided PPS pulses before a fix and I wasn't too sure about that. I implemented a gate based on the NMEA sentences, as you suggested, to wait until the fix to sample it. But this time around, I've been lazy and wait 5 minutes after the light starts flashing (serial not connected). I also check for missing pulses. If one is missed, I stop the calibration and start all over.

I have some F4 boards on order, they have an onboard battery circuit so I may get a chance to try out whatever you come up with.

Post Reply