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 <[email protected]> wrote: > Date: Sat, 17 Jul 2021 18:06:01 +0200 > From: ASSI <[email protected]> > Subject: [time-nuts] Re: RTC DS3231: how well can it be regulated? > To: [email protected] > Message-ID: <1819392.ffsGRN3TFe@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. > > _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
