Very high precision timer hiding in plain sight.. Ethernet MAC / PTP block

[ocelot]

A while back at work, I created a simple NTP server, using an STM32F407. This has one of the (I believe Synopsys synthesisable IP bloc) Ethernet MAC blocks in it.

One thing I discovered and enabled and re purposed is the fact that this MAC block supports the PPTP protocol as used e.g. at CERN for nanosecond level timing where the time of flight of Ethernet cables can be measured.

It contains a 63 bit timer (seconds with a 31 bit fraction) with an adjustable increment rate used to timestamp Ethernet frames, but it does have a compare register that allows triggering of other timers or an output pin - basically it allows you to create timing pulses which have an average period adjustable to sub-nanosecond level rate, but which have about 20nS jitter on each edge (the counter updates at some fraction of the core clock) with a 208MHz core clock.

Its pulse output can be for instance sampled by a 32 bit timer - on that device Timer 2 , while a GPS 1PPS signal can be also sampled on Timer 2, and some maths done to create a PLL.

You can turn on PPTP and use this timer without actually using the Ethernet MAC for data transfer - if you do use it, the Ethernet frames will contain PPTP timer data but by design, this gets ignored by all non-PPTP hardware.

Using this and a non-timing grade UBlox GPS (where the vendor deliberately ramps reported precision timing parameters because you did not pay 110 Euros for the module although the 1PPS output is in reality actually far more stable than the reported values  ) , it was possible to measure the clock frequency of the microcontroller to 1Hz precision, and use that in a simple NTP server, so that "NTP" time could survive some GPS outages ..

[fchk]

this MAC block supports the PPTP protocol

No, it does not. PPTP is the Microsoft Point-to-Point Tunneling Protocol as defined in RFC 2637. You surely don't mean this.
https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol

What you probably mean is the PTP Precision Time Protocol as defined in IEEE 1588.
https://en.wikipedia.org/wiki/Precision_Time_Protocol

[peter-h]

Are you building a PTP server running over ETH? Can your really get nanosecond grade accurate that way, delivered to clients?

I know that the 1 sec pulse from a U-BLOX is supposed to be very accurate and if you do an interrupt from that and use it to sync a simple hardware RTC you should get pretty good accuracy, but as you say if you lose GPS for a long time then you need something else e.g. a TCXO.

[nctnico]

Are you building a PTP server running over ETH? Can your really get nanosecond grade accurate that way, delivered to clients?

No. Not by a long shot as delays in the hardware and network components in between isn't compensated or even known.  PTP gets you low hundreds of nanoseconds at best. If you can calibrate and correct for delays you can get into the tens of nanoseconds ballpark. Beyond that you'll need White Rabbit (PTP extension) or PTP with the high accuracy profile. Neither is supported by standard hardware though.

[peter-h]

In that case I don't get it because a timer in the CPU will never be better than the CPU crystal.

You may as well use the 1Hz GPS pulse, in conjunction with a hardware counter driven by a TCXO for when the 1Hz pulse is lost. And reset this counter from the 1Hz pulse.

Then you need some logic to take over the generation of the 1Hz pulse if the GPS module stops emitting it. I'd use both sources (the GPS and the TCXO-driven counter) ORed together. 10MHz TCXOs are common so you get 100ns resolution.

[ddrown]

I found the stm32f407 timestamp hardware interesting for NTP as well, here's my code for it https://github.com/ddrown/ArchMax-NTPServer

The downside I found was the PLL in my stm32f407 is not stable, it has jitter measured in ppm. I wrote up some more info about that problem on https://blog.dan.drown.org/gps-module-measurements/ starting with the section "Wait, why is the STM32's clock moving around so much?"

[nctnico]

In that case I don't get it because a timer in the CPU will never be better than the CPU crystal.

You may as well use the 1Hz GPS pulse, in conjunction with a hardware counter driven by a TCXO for when the 1Hz pulse is lost. And reset this counter from the 1Hz pulse.

Then you need some logic to take over the generation of the 1Hz pulse if the GPS module stops emitting it. I'd use both sources (the GPS and the TCXO-driven counter) ORed together. 10MHz TCXOs are common so you get 100ns resolution.

I think the OP's idea is to measure the clock frequency accurately and compensate for any frequency offset. This could bridge a GPS outage for a couple of days if the accuracy needed is 1 second. AFAIK most RTCs have frequency offset adjust settings for this purpose. Using the IEEE1588 hardware in the ethernet MAC block saves a regular timer of you are short on general purpose timers.

[RoGeorge]

Are you building a PTP server running over ETH? Can your really get nanosecond grade accurate that way, delivered to clients?

Should be possible to get sub-nanosecond sync between clients with White Rabbit (PTP + more), see:
https://en.wikipedia.org/wiki/White_Rabbit_Project

This other page from NI https://forums.ni.com/t5/Past-NIWeek-Sessions/TS10623-Precision-Time-Protocol-IEEE-1588-Primer/ta-p/3319213 has a TS10623 NIWeek_2016_1588.pdf with some bird-eye view about various methods and performance comparison.

Don't know the intimate details, or how much of these applies to STM32F407.

[ocelot]

Sorry wrong acronym. I meant PTP.

[ocelot]

The point is that you can set the period of that 63 bit counter such that it is more precisely exactly tracking the GPS 1PPS, than the 32 bit counter - it is using an integrating technique to update the counter with periods of N or N+1 distributed in a way that gives fine adjustment.

You could do the same by altering the period of a 32 bit counter to N or N+1 in a pattern that gives an average of some value  between N and N+1 . This hardware does it by itself, but using the pipelined reload mode on the counter its fairly trivial to do it that with some firmware too.
 
 Because it is sub nanosecond adjustable rather than clocked off the CPU clock, you can gain another order of magnitude in adjustment over simply altering the period of the timer by 1 count.