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

[ASSI]

MLewis writes:
> It got me wondering. Between the DS3231's Aging Trim, insulating and
> perhaps a heater for some temperature control, does anyone know if the
> DS3231's PPS could be synced and stabilized into a reasonable PPS
> source through an opto-isolator?

I've got some DS3231SN modules some time ago, but never got around to
use them until now beyond checking that it was an actual SN and not the
M variant.  But when I'm at home the whole time anyway, I can keep the
spare Linux PC running some experiments 24/7…

> I don't know if the onboard temperature sensor is precise/stable
> enough to be useful for maintaining a stable temperature with a
> heater. It's accuracy is listed as +/- 3 C, but that doesn't speak to
> the stability of the temperature it reports.

The resolution is only 0.25°C and measured every 64s, so while better
than nothing you would probably want to use something more precise when
trying to regulate temperature.

> The SQW output can be set to 1 Hz, 1.025 kHz, 4.096 kHz or 8.192 kHz.

So I've cut up an old VGA cable and spliced out the DDC lines and
connected the SQW output to an FTDI TTL/USB serial converter that has
the full set of control lines over DCD.  The modules (they come with
various markings, but they are the same as the often-seen "blue"
"ZS-042"), as noted elswhere, have superfluous pull-up resistors on the
I²C lines (I needed to keep the pullup on SQW for the PPS out that you
may or may not want for other projects) and a charging circuit that
needs to be deactivated.  Then I activated the I²C bus device to the VGA
DDC and set the RTC to current time, while monitoring the PPS via ntpd.
It turns out that my module was very near the datasheet spec limit, so
I've had to set the aging register quite far off the default value to
get it on frequency.  As noted elsewhere, the control gain around the
0ppm point is actually only about half the datasheet value of
100ppb/LSB.

After reading the datasheet again I was wondering about the 64s cycles
between temperature reads and TCXO mesurements/calculations.  These are
supposed to take 125…200ms, so I've set up a loop to look at the BUSY
bit every 0.1s… and yes there it is.  I've refined that search with some
hires timers to get into the µs regime and set up logging for the assert
and deassert of the BUSY bit.  The counter chain reset happens at the
half second mark per the datasheet, so the TCXO computation (taking a
nominal 125ms) should run a bit before that.  A sensible counter value
to trigger on would be 0x3300 (or 398.438 ms) and the datasheet also
says something about the registers getting updated 2ms after the start
of a manual conversion (assuming a synchronous operation the closest
possibility is 64 clock cycles or 1.953ms).  If that same delay happens
for the automatic conversion we should see the BUSY bit appear around
counter value 0x3340 or at the 400.391ms mark.  Now, my current
measurement entirely from userspace is very noisy, having around 5ms
pk-pk jitter with an occasional outlier, but if I average it enough I
currently see an offset of 401.1ms vs. the PPS (as seen by ntpd, also at
64s interval).  Both the PPS and the register read have unkown latency
into the PC, so I'm not going to worry about that 700µs difference; I'll
try to look at that later with a logic analyzer when I find the spare
cycles.

I'm attaching the plot for running the DS3231 the last three weeks,
starting with me manually converging on the correct aging value and
later tracking the offset (with the occasional reboot and associated
drop-outs thrown in).  The last week additionally logs the BUSY bit
start as explained above (plus the cycle time it takes until it
de-asserts).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DS3231_PPS_monitor_3wk.png
Type: image/png
Size: 397964 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200419/839c9bec/attachment.png>
-------------- next part --------------

Based on what I see so far, it should be possible to write a software
PLL that keeps the PPS within a double or low triple digit µs range
(most of that relates to the jitter from the measurements, so using
something that has interrupt driven or even hardware counter based GPIO
PPS would imprve that figure a lot) around zero while locked and leave
the RTC within 100ppb off frequency when unlocked.  I suspect that over
time you'd be able to correlate the optimum settings for the aging value
to the temperature reading you get from the chip, which might offer a
path to a feed-forward FLL+PLL strategy (i.e. the feed-forward FLL keeps
track of where the 0ppm point is supposed to be and the PLL just
deviates from that value to steer the PPS to zero offset).  The module
has an EEPROM where you could store those values, so it's possible to
add a small controller that keeps the feed-forward FLL loop going while
the PLL is unlocked when you need to bridge longer holdovers.  Such an
active holdover could probably stay within 10ms for well over a week if
environmental conditions do not change too fast and still run on battery
for an extended period of time.



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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada