Time interval counter (13ns resolution)

What are you developing?
Post Reply
User avatar
ddrown
Posts: 154
Joined: Sat Jan 09, 2016 4:49 am

Time interval counter (13ns resolution)

Post by ddrown » Wed Jan 17, 2018 12:32 am

I wanted to compare two GPS modules, specifically the amount of time between the pulse per second of each of them. I used a STM32F103 as my hardware, and setup two channels on TIM3 as input capture. The timer is running at 72MHz so it has a 13ns resolution. I also setup TIM2 as a slave to count TIM3's overflow events, so I could use both 16 bit timers together as a pseudo 32 bit timer. The timestamps were sent via USB serial to a PC to log and graph.

The two GPS modules should be within +/-20 nanoseconds of each other, if everything went right.

Image

From this graph, you can see they were not. I believe this was a configuration issue on one of my GPS modules as well as signal issue. I've ordered some more parts and will have to re-run this part of the test again.

An interesting part of the data shows the STM32F103's clock has a sawtooth pattern to it:

Image

I think this sawtooth pattern is a combination of the HSE circuitry and the PLL. Has anyone seen this before?

Code: https://github.com/ddrown/stm32-cdc-pps/tree/tim3

Additional information: https://blog.dan.drown.org/gps-module-measurements/

dannyf
Posts: 231
Joined: Wed May 11, 2016 4:29 pm

Re: Time interval counter (13ns resolution)

Post by dannyf » Wed Jan 17, 2018 12:55 am

so I could use both 16 bit timers together as a pseudo 32 bit timer.
if there is something else going on on your chip - like another ISR on UART or ADC, a composite timer may show jitter consistent with the pattern shown in your measurement. Those chips allow chaining / master + slave pair of two timers, if input capture is used.

alternatively (not as good), you can use DWT - it is 32-bit.
I think this sawtooth pattern is a combination of the HSE circuitry and the PLL.
plausible. two ways to test:

1) the same pattern would show up on HSIPLL vs. HSEPLL, and disappear on HSI vs. HSE.

2) a more affirmative approach is to use a non-PLL external oscillator and MCO on the STM32 and run the output via an XOR gate + R/C network. you should observe slow moving voltage on the capacitor, when PLL is used on the chip, and a steady voltage when HSE / HSI is used.

User avatar
ddrown
Posts: 154
Joined: Sat Jan 09, 2016 4:49 am

Re: Time interval counter (13ns resolution)

Post by ddrown » Wed Jan 17, 2018 1:26 am

dannyf wrote:
Wed Jan 17, 2018 12:55 am
so I could use both 16 bit timers together as a pseudo 32 bit timer.
if there is something else going on on your chip - like another ISR on UART or ADC, a composite timer may show jitter consistent with the pattern shown in your measurement. Those chips allow chaining / master + slave pair of two timers, if input capture is used.

alternatively (not as good), you can use DWT - it is 32-bit.
Since I'm using input capture, I'm not affected by interrupt latency. I actually measure interrupt latency/jitter from this data.
dannyf wrote:
Wed Jan 17, 2018 12:55 am
I think this sawtooth pattern is a combination of the HSE circuitry and the PLL.
plausible. two ways to test:

1) the same pattern would show up on HSIPLL vs. HSEPLL, and disappear on HSI vs. HSE.

2) a more affirmative approach is to use a non-PLL external oscillator and MCO on the STM32 and run the output via an XOR gate + R/C network. you should observe slow moving voltage on the capacitor, when PLL is used on the chip, and a steady voltage when HSE / HSI is used.
HSI is way worse than HSE

Image

That tiny purple line is the full frequency difference of the HSE. The green dots at the bottom represent all the HSI frequency values.

By comparison, this is a STM32F031 with a TCXO (using bypass instead of the HSE oscillator circuitry)

Image

User avatar
Pito
Posts: 1743
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Time interval counter (13ns resolution)

Post by Pito » Wed Jan 17, 2018 7:56 am

The GPSes 1Hz tick is not precise short term, but long term. Based on module and conditions short term jitter could be XXns- Xuseconds. Thus the tick itself cannot be used as the base for a counter for example. You have to discipline a quality OCXO with the 1Hz tick to get precise output.

The sawtooth frequency stability of the 72MHz PLL - yes, I measured the same (72MHz BPill against OCXO base). Here the spread is 30Hz (72Mhz/2, last three digits shown):
BluePill 72MHz_half against OCXO.JPG
BluePill 72MHz_half against OCXO.JPG (52.39 KiB) Viewed 307 times
It is most probably caused by the design of the phase comparator inside the PLL.
Pukao Hats Cleaning Services Ltd.

User avatar
ddrown
Posts: 154
Joined: Sat Jan 09, 2016 4:49 am

Re: Time interval counter (13ns resolution)

Post by ddrown » Wed Jan 17, 2018 7:22 pm

Pito wrote:
Wed Jan 17, 2018 7:56 am
The GPSes 1Hz tick is not precise short term, but long term. Based on module and conditions short term jitter could be XXns- Xuseconds. Thus the tick itself cannot be used as the base for a counter for example. You have to discipline a quality OCXO with the 1Hz tick to get precise output.
Yup, the spec for these GPS modules is 20ns RMS jitter. That is roughly 0.020ppm uncertainty on each sample. That is a source of error, but it is tiny compared to the PLL or HSE.
Pito wrote:
Wed Jan 17, 2018 7:56 am
The sawtooth frequency stability of the 72MHz PLL - yes, I measured the same (72MHz BPill against OCXO base). Here the spread is 30Hz (72Mhz/2, last three digits shown):
BluePill 72MHz_half against OCXO.JPG
It is most probably caused by the design of the phase comparator inside the PLL.
Thank you for this data, that's in the same ballpark (60Hz vs 30Hz) as what I'm seeing with just the GPS. I wonder how much variation there is per chip/board design.

When you say 72MHz/2, were you measuring a 36MHz PWM?

User avatar
ddrown
Posts: 154
Joined: Sat Jan 09, 2016 4:49 am

Re: Time interval counter (13ns resolution)

Post by ddrown » Fri Jan 19, 2018 11:59 pm

The GPS antenna arrived in the mail and I reran my tests, this time it (the offset between the two GPS modules) was much better:

Image

I'll have to experiment with various changes (antenna swap, channel swap, etc) to see the impact to the offsets.
Last edited by ddrown on Sat Jan 20, 2018 2:54 am, edited 1 time in total.

User avatar
mrburnette
Posts: 2226
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Time interval counter (13ns resolution)

Post by mrburnette » Sat Jan 20, 2018 2:28 am

Short PDF doc on "jitter" that may be of interest to readers unfamiliar with the subject...

https://www.google.com/url?sa=t&source= ... MjCRhLRPIn

User avatar
ddrown
Posts: 154
Joined: Sat Jan 09, 2016 4:49 am

Re: Time interval counter (13ns resolution)

Post by ddrown » Sat Jan 20, 2018 3:31 am

mrburnette wrote:
Sat Jan 20, 2018 2:28 am
Short PDF doc on "jitter" that may be of interest to readers unfamiliar with the subject...

https://www.google.com/url?sa=t&source= ... MjCRhLRPIn
Thank you, I didn't properly define all my terms. I've probably confused a bunch of people with this post.

User avatar
Pito
Posts: 1743
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Time interval counter (13ns resolution)

Post by Pito » Sat Jan 20, 2018 9:21 am

When you say 72MHz/2, were you measuring a 36MHz PWM?
Those 30Hz were measured at 36MHz output. Thus with 72MHz it will be 60Hz. The OCXO was free running, none disciplining.
Pukao Hats Cleaning Services Ltd.

Post Reply