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 -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
