[time-nuts] Re: RTC DS3231: how well can it be regulated?

[ASSI]

I finally found the time to implement some sort of FLL that continously 
monitors what the PPS from the DS3231M RTC does and adjusts the aging register 
accordingly to keep it in sync with the PC's notion of time.

Attached is a plot that shows the last four weeks of operation, the first two 
of which were still manually adjusted and the last two are with automatic 
control (done by the same Perl script that logs all the data).  I've changed 
the control strategy a few times during the first few days and there's the odd 
reboot here and there (which generally creates gaps less than 90 seconds, so 
you don't see it in the data except for the timing noise characteristics).

Both the environmental sensor and the RTC hang off the DDC channel that the 
otherwise unused VGA port on the PC provides and PPS is read via an FTDI high-
speed USB2 serial interface.  The PC gets its time over the local network from 
five rasPi that all have their own GPS and should be within 1µs of true time 
most of the time, but there is about 50µs of average jitter on the clock from 
the network connection.  The single hardware serial port is used by a DCF-77 
receiver, but I know from other experiments that connecting a GPS via this 
serial port does not improve the timing jitter very much over a longer 
timespan.  The USB serial has another 125µs of frame jitter that is very 
prominent when looking at the PPS data in detail (see the second plot which 
shows just the data from today).

I can also read the PPS by polling a register in the RTC.  Most of the time 
the system will come up in a way that I get about 1ms jitter and the average 
can be aligned to the PPS with a 24.5ms bias, but each reboot shifts some 
stuff around in how all the other things in the PC are aligned to each other 
and then either the offset changes or its average isn't stably at the same 
offset to the PPS until the next reboot.  So I could use that signal when PPS 
is not available, albeit with some noticeable degradation in accuracy.

The aging register in that RTC provides a theoretically 120ns/s granularity 
control over the PPS, however since it is not possible to switch off the 
temperature compensation of the RTC (that I know of) you end up having to 
ratchet up on the steering until you've managed to override the internal TCXO 
algorithm and then need to swing it the other way when inevitably it will 
start to go too fast in the other direction.  So instead of the control 
algorithm using just two or three settings to keep the average relatively 
stable, it will use about two more levels.  Actually the initial control 
strategy was intended to keep the settings more stable, but ended up with 
larger PPS deviations overall, so I changed that.  The relatively large 
residual jitter in my timebase likely isn't helping either, but I still seem 
to be able to keep the RTC within the frame given by the jitter.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DS3231M_PPS_monitor_4wk.png
Type: image/png
Size: 607946 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20210717/c6100f0f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DS3231M_PPS_monitor_1d.png
Type: image/png
Size: 454894 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20210717/c6100f0f/attachment-0001.png>