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

[Jeremy Elson]

Hi Tobias,

In the latest round of experiments in which the clock resolution was 6ns, I
could not detect any instability; the timestamps of the 1pps signal being
fed into my timestamper had identical low order bits for 250,000 seconds
(until I stopped the experiment). In this case the 10mhz reference was
PLLed up using the STM32's internal PLL, x17, to 170 mhz.

The next step is to use the "HRTIM" peripheral which has a second PLL, x32,
that will yield 184ps resolution. The system clock will not go above
170mhz; 5.4ghz is only the internal clock of the HRTIM peripheral.

Once I am able to do that experiment, I might see instability, in which
case my backup plan is to use an external PLL chip to feed a more stable
170mhz signal directly to the STM32's timer peripheral.


On Wed, May 5, 2021 at 5:43 AM Pluess, Tobias <tpluess at ieee.org> wrote:

> Hi Jeremy
>
> I assume you use the inertnal PLL of the STM32 to get this amazing 184ps
> resolution.
> Can you say something about the frequency stability of that PLL?
> In my very first GPSDO I built, I used a STM32F303. This one had a quite
> bad PLL stability, the frequency was varying over time in a sawtooth like
> manner for some reason. My GPSDO was only stable when I disabled the PLL
> and let the entire MCU run from the 10 MHz OCXO.
>
> In my current GPSDO, I use the STM32F407. I have not tested the PLL yet, so
> currently everything also runs from the 10 MHz clock. I am still testing my
> design since almost a year, and it works quite stable and reliable, but if
> I could use the PLL, that would allow me to improve my algorithms and stuff
> and would let me even connect a small LCD panel to the MCU for status
> display. Currently, with only 10 MHz clock, the CPU is a bit too slow ;-)
>
> So it would be interesting to see what the stability of that PLL is. While
> I do not use the same MCU as you do, it could still be interesting for
> comparison.
>
> Best
> Tobias
> HB9FSX
>
>
> On Sat, Apr 24, 2021 at 9:38 PM Jeremy Elson <jelson at gmail.com> wrote:
>
> > 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
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send
> > an email to time-nuts-leave at lists.febo.com
> > To unsubscribe, go to and follow the instructions there.
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.
>