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

[Tim S]

I did want to pose the question, are you aware of the existence
of DS1341/DS1342 RTCs? These parts have a 1pps (or power-line 50/60Hzr
following built-in.

-Tim

On Sat, Jul 17, 2021, 09:47 <time-nuts-request at lists.febo.com> wrote:

> Date: Sat, 17 Jul 2021 18:06:01 +0200
> From: ASSI <Stromeko at nexgo.de>
> Subject: [time-nuts] Re: RTC DS3231: how well can it be regulated?
> To: time-nuts at lists.febo.com
> Message-ID: <1819392.ffsGRN3TFe at gertrud>
> Content-Type: multipart/mixed; boundary="nextPart2447953.YtKovMPEme"
>
> 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.
>
>