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

[paul swed]

Wanted to respond its been an interesting thread.
You mention sawtooth and that does appear in the GPSDO. Thats why some GPS
receivers actually offer saw tooth correction. (I hope I just didn't
embarrass myself in front of many time nuts)
10 MHz is slow. It would be reasonably simple to double 10 MHz to 20 MHz.
There are cheap doublers on the various pay sites and amplifiers if you are
not a builder. Though its desirable to have some filtering. That at least
gets the STM to 20 MHz without a PLL. It can be doubled again to 40 Mhz.
But that would start to add a lot of noise. But again a simple approach.
Good luck and please keep sharing.
Regards
Paul
WB8TSL


On Wed, May 5, 2021 at 8: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.
>