[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
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 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 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 abou
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
Hi It is not unusual to see MCU PLL’s up in the “nanosecond” range in terms of jitter. Finding one that is below 200 ps was pretty much impossible last time I dug into them. Bob > On May 6, 2021, at 8:39 AM, Pluess, Tobias wrote: > > Good to know that they offer the Spread Spectrum functionality. > But as I see, the function is switched off by default. > And it still does not explain why the F303 had the issue with the frequency > modulated CPU clock. > But as far as I understand, I can use the PLL without any issues, as long > as the spread spectrum feature is switched off. > It would still be interesting to see how much jitter the PLL adds to the > OCXO's one. > > Tobias > HB9FSX > > > On Thu, May 6, 2021 at 12:45 PM Detlef Schuecker via time-nuts < > time-nuts@lists.febo.com> wrote: > >> Hi, >> >> yes, the STM32F4xx series has the spread spectrum feature, the STM32F3xx >> does not. >> See the RCC_SSCGR (reset and control clock spread spectrum clock >> generation register), Bit 31 in >> dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf, >> >> catchy names :)). >> >> But the STM32 are real fine machines imho.. >> >> Cheers >> Detlef >> >> >> >> >> Von:"Lux, Jim" >> An: time-nuts@lists.febo.com >> Datum: 05.05.2021 22:21 >> Betreff:[time-nuts] Re: The amazing $5 timestamper, part 2: >> discovering a bug in my signal generator >> >> >> >> On 5/5/21 12:57 PM, Poul-Henning Kamp wrote: >>> >>> Pluess, Tobias writes: >>> >>>> 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. >>> It's called "spread-spectrum" and is done deliberately to game the EMI >>> criteria for various certifications. >>> >>> By sweeping the frequency through a range, the peak energy of any one >>> frequency, as averaged over a second, drops correspondingly. >>> >>> In many cases you can actually disable it, but you may have to punk the >>> manufacturer quite hard to find out what bit to set or clear. >>> >> >> https://www.st.com/resource/en/application_note/dm00281138-stm32-mcus-spreadspectrum-clock-generation-principles-properties-and-implementation-stmicroelectronics.pdf >> >> >> Says the STM32F2, F4, F7, but not the F3. But it might be similar. >> >> You could look at the register map of the F3 for MODPER, INCSTEP, >> SPREADSEL, SSCGEN ? >> >> A casual grep didn't find it. >> >> There's also a scheme in another ap note about going in and changing the >> PLL fractional divider every millisecond using software. (I guess that's >> if you fail your radiated emissions test, and you're desperate?) >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send >> an email to time-nuts-le...@lists.febo.com >> To unsubscribe, go to and follow the instructions there. >> >> >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send >> an email to time-nuts-le...@lists.febo.com >> To unsubscribe, go to and follow the instructions there. >> > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an > email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
Good to know that they offer the Spread Spectrum functionality. But as I see, the function is switched off by default. And it still does not explain why the F303 had the issue with the frequency modulated CPU clock. But as far as I understand, I can use the PLL without any issues, as long as the spread spectrum feature is switched off. It would still be interesting to see how much jitter the PLL adds to the OCXO's one. Tobias HB9FSX On Thu, May 6, 2021 at 12:45 PM Detlef Schuecker via time-nuts < time-nuts@lists.febo.com> wrote: > Hi, > > yes, the STM32F4xx series has the spread spectrum feature, the STM32F3xx > does not. > See the RCC_SSCGR (reset and control clock spread spectrum clock > generation register), Bit 31 in > dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf, > > catchy names :)). > > But the STM32 are real fine machines imho.. > > Cheers > Detlef > > > > > Von:"Lux, Jim" > An: time-nuts@lists.febo.com > Datum: 05.05.2021 22:21 > Betreff: [time-nuts] Re: The amazing $5 timestamper, part 2: > discovering a bug in my signal generator > > > > On 5/5/21 12:57 PM, Poul-Henning Kamp wrote: > > > > Pluess, Tobias writes: > > > >> 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. > > It's called "spread-spectrum" and is done deliberately to game the EMI > > criteria for various certifications. > > > > By sweeping the frequency through a range, the peak energy of any one > > frequency, as averaged over a second, drops correspondingly. > > > > In many cases you can actually disable it, but you may have to punk the > > manufacturer quite hard to find out what bit to set or clear. > > > > https://www.st.com/resource/en/application_note/dm00281138-stm32-mcus-spreadspectrum-clock-generation-principles-properties-and-implementation-stmicroelectronics.pdf > > > Says the STM32F2, F4, F7, but not the F3. But it might be similar. > > You could look at the register map of the F3 for MODPER, INCSTEP, > SPREADSEL, SSCGEN ? > > A casual grep didn't find it. > > There's also a scheme in another ap note about going in and changing the > PLL fractional divider every millisecond using software. (I guess that's > if you fail your radiated emissions test, and you're desperate?) > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send > an email to time-nuts-le...@lists.febo.com > To unsubscribe, go to and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
Hi, yes, the STM32F4xx series has the spread spectrum feature, the STM32F3xx does not. See the RCC_SSCGR (reset and control clock spread spectrum clock generation register), Bit 31 in dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf, catchy names :)). But the STM32 are real fine machines imho.. Cheers Detlef Von:"Lux, Jim" An: time-nuts@lists.febo.com Datum: 05.05.2021 22:21 Betreff: [time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator On 5/5/21 12:57 PM, Poul-Henning Kamp wrote: > > Pluess, Tobias writes: > >> 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. > It's called "spread-spectrum" and is done deliberately to game the EMI > criteria for various certifications. > > By sweeping the frequency through a range, the peak energy of any one > frequency, as averaged over a second, drops correspondingly. > > In many cases you can actually disable it, but you may have to punk the > manufacturer quite hard to find out what bit to set or clear. > https://www.st.com/resource/en/application_note/dm00281138-stm32-mcus-spreadspectrum-clock-generation-principles-properties-and-implementation-stmicroelectronics.pdf Says the STM32F2, F4, F7, but not the F3. But it might be similar. You could look at the register map of the F3 for MODPER, INCSTEP, SPREADSEL, SSCGEN ? A casual grep didn't find it. There's also a scheme in another ap note about going in and changing the PLL fractional divider every millisecond using software. (I guess that's if you fail your radiated emissions test, and you're desperate?) ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
On 5/5/21 12:57 PM, Poul-Henning Kamp wrote: Pluess, Tobias writes: 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. It's called "spread-spectrum" and is done deliberately to game the EMI criteria for various certifications. By sweeping the frequency through a range, the peak energy of any one frequency, as averaged over a second, drops correspondingly. In many cases you can actually disable it, but you may have to punk the manufacturer quite hard to find out what bit to set or clear. https://www.st.com/resource/en/application_note/dm00281138-stm32-mcus-spreadspectrum-clock-generation-principles-properties-and-implementation-stmicroelectronics.pdf Says the STM32F2, F4, F7, but not the F3. But it might be similar. You could look at the register map of the F3 for MODPER, INCSTEP, SPREADSEL, SSCGEN ? A casual grep didn't find it. There's also a scheme in another ap note about going in and changing the PLL fractional divider every millisecond using software. (I guess that's if you fail your radiated emissions test, and you're desperate?) ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
Pluess, Tobias writes: > 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. It's called "spread-spectrum" and is done deliberately to game the EMI criteria for various certifications. By sweeping the frequency through a range, the peak energy of any one frequency, as averaged over a second, drops correspondingly. In many cases you can actually disable it, but you may have to punk the manufacturer quite hard to find out what bit to set or clear. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
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 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 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 w
[time-nuts] Re: The amazing $5 timestamper, part 2: discovering a bug in my signal generator
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 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
