[time-nuts] The amazing $5 timestamper, part 2: discovering a bug in my signal generator

[Jeremy Elson]

A few months ago, posted to the list about a new device I'm designing based
on the latest-generation STM32 CPUs. I'm back to post about some
improvements to it -- and, it's now good enough that it found a frequency
error of 1 part in 1e11 in my Rigol DS1022Z signal generator! Read on for
the story.

To recap, the relatively new STM32G4 series of ARM Cortex microcontrollers
have high resolution timers capable of 184 picosecond resolution, and I am
using it to build a device that can timestamp an arbitrarily long sequence
of events, on 4 channels, with 184ps resolution and under 1 microsecond of
dead time between events. The first time I posted, it was after a feverish
3-day hackathon getting an early prototype built on a breadboard. I posted
some (very) preliminary results using a Rubidium frequency reference to
timestamp the PPS signal coming from my GPS. There were odd jumps in the
timestamps. At the time, I attributed that (incorrectly, it turns out) to
the GPS losing and regaining lock.

After a lot of careful analysis, and some helpful feedback from other
time-nuts, I decided it was better to do some better-controlled experiments
to pin down where the errors were coming from. I found and fixed a number
of sources of error:

(1) I realized the gaps were all 100ns of the timestamper falling behind,
which is exactly one tick of the 10mhz reference clock. It turned out my
analog circuit for conditioning the 10mhz, 1.8vpp, 0-centered sine wave
generated by the reference clock into something that could be used as an
STM32 clock input was not boosting the voltage quite high enough; the STM32
was sometimes missing pulses. I redesigned it to prevent this.

(2) I then found another class of error: the clock going too *fast,* again
with 100ns gaps. This turned out to be noise on the clock line causing
spurious pulses, which was because it's hard to keep noise out of a
breadboarded circuit full of long wires and clips. I designed and
fabricated a proper printed circuit board for testing.

To differentiate errors introduced by my timestamper from errors in the
devices I was using to test it, I set up an experiment that drove the
timetsamper and the test signal from the same clock source. My first setup
was to use a Rubidium oscillator (lpro 101) as the master clock for both
the timestamper and a test pulse. I fed the RbXO's reference clock into
both my signal generator (a Rigol DG1022Z) and my timestamper, and I
configured the DG1022Z to generate a 1us-wide pulse every second. This came
close to working, but as you can see in this graph of residual errors (
https://www.circlemud.org/jelson/2020-04-01_proper_connectors_1pps_rubidium.time.plot.png),
there was a small frequency error of about 1 part in 1e11. The resolution
of the timestamps was about 6ns (170mhz clock; I haven't gotten to the
higher-res 184ps mode yet), and the measurement's low order bits would
change by 6ns about every 1,000 seconds.

I tried variations, all with the same results. I removed the RbXO and had
the signal generator emit its reference clock instead of using an external
clock. Instead of using the 10mhz clock reference output, I tried
configuring one channel of the generator to emit a 10mhz sine wave and the
other a PPS. All showed the same small frequency error.

Looking carefully at the graph, I realized that each transition from one
least-significant-bit to the next was not "clean", i.e. rather than a
single point of transition, there was a period where the old and new values
were intermixed. This realization led me to the conclusion that it could
not be my timestamper that was at fault but that the PPS and reference
signal really were not perfectly frequency synchronized. I tried hooking up
the two signals to my CNT-90 and having it measure for a few hundred
seconds; the results showed an error larger than could be explained by the
CNT-90's 100ps resolution.

The signal generator was the only consistent part of all these failures.
Could it be at fault?!

I decided to buy a TADD-2 (
https://tapr.org/product/tadd-2-pulse-per-second-divider/); the signal
generator is complicated, but you can't get any simpler than just counting
to 10 million and then flipping a bit on and off. The task is so simple I
was tempted to just build one out of a $1 microcontroller I had lying
around, but I figured it would not be a very compelling story to say "The
test gear I built says the timestamper I built works!". I wanted to have
something in the experiment that had been externally validated.

Yesterday, I used the RbXO as a master clock again, feeding it into both
the TADD-2 and my timestampers' clock inputs; the TADD-2's PPS output was
fed into the timestamper's test input. And, lo and behold, the timestamper
has now given me 88,000 timestamps in a row (and still going!) with the
exact same low-bits. Success!

So the signal generator can not generate 1pps pulses of the right
frequency! I suppose the two questions I have for anyone still reading are
(1) why? and (2) are there better signal generators out there?

I suspect these two questions are related. The DG1022Z can generate
arbitrary waveforms; it is a digital device that has some list of samples
that it feeds into a DAC. The DAC probably runs at some fixed frequency, so
the limit to the frequency accuracy of any signal it generates will be
related to the width of one of those samples. But, I would be surprised
that the DAC frequency is not an integral number of samples per second. I
suppose there might also be some dead time between buffers, or some other
rounding error when the DAC buffer wraps around. Are there "known-good"
siggen's out there that would not have this problem?

But, the bottom line is I'm pretty excited that the timestamper has now
reached another milestone of accuracy. There's still much to do (e.g.,
integrating USB output; getting the 184ps mode working), but I hope to make
this thing available to time-nuts in the next few months. Including all the
costs of PCB fabrication, assembly, connectors, packaging and shipping, and
retail overhead I'm guessing it'll end up costing somewhere between $50 and
$75.

Regards,
-Jeremy N3UUO