Hello everyone, I’ve resurrected an old and no longer supported implementation of PTP for the STM32 series of 32-bit microcontrollers. In a nutshell: the ethernet MAC on these micros has hardware support for packet time stamping and fine-grained adjustment of a free running timer. ST Micro had released a port of the ptpv2 client/server which took advantage of this hardware using ptpd-2.0.0, but it’s been lost to the sands of time. I’ve figured out a similar port and it’s working pretty good. The end application I’m working toward is a closed (no availability of internet or gps time) network where multiple devices are working together to measure position and orientation of objects in an environment with carefully synchronized LED flashes and camera exposures. Absolute time is unimportant, but everyone in the closed network agreeing on what time it is is very important, down to single-digit microseconds. I have a pair of STM32F756 development boards syncing to a ptpd server running on Linux. Using the hardware, timer-based (no interrupts or software involvement) PPS output of the STM32s and a logic analyzer I can see that the two STM32 dev boards wander in and out of sync with each other. The absolute difference between the rising edges of the PPS signals ranges from a few hundred nanoseconds to about 40-50us over the span of about 20-30 minutes. The test system has a single (non-1588-aware) network switch, but the final implementation will have a master with multiple network interfaces directly connecting to each slave. The logging output of the STM32s shows that the second-to-second offset error of a slave is in the neighbourhood of +/-1500ns, and the long-term drift stabilizes out around 1200-1500pps. I’m looking to close the range of the short-term sync and try to hold the slaves to within a half dozen microseconds of each other if possible. Now the master clock is just a free-running clock on the PC (no GPS or NTP discipline) but the absolute time is unimportant for me; what is important is very tight sync between the slaves over the short (second-to-second) term. I have some hardware coming in which will help me visualize how jittery the master clock is, as I suspect some of this “slop” in sync comes from the master clock jittering and the measurement of the master clock by one slave not being the same as the other slave, causing the timing loops to diverge. My newbie questions revolve around the short term sync error. Will an undisciplined master clock aggravate the ability for multiple slaves to stay synchronized relative to each other? What if I used a 10MHz OCXO and divider to provide a PPS signal to the PC, lying to it that this is a GPS PPS output and disciplining the master clock that way? It’s my understanding that an OXCO short-term error is very small, and the GPSDOs take advantage of this attribute while using the GPS long-term stability to keep the time correct. The other newbie question is regarding adjusting the PI loop in the pop codebase on the STM32 slaves; is there any value in trying to adjust the loop coefficients to favour shorter term stability? I’m leery to do this, as I am fully aware of my newbieness and that the coefficients are there after a LOT of hard work to get them to optimal values. Thanks, Andrew

I also have an STM32 port of the ptpd code that seems to work reasonably well -- it runs on an STM32F407 board. I'll hack up some code to see what the actual error is -- the ptp master is another board deriving time from GPS and I could add another gps to the second board to use as a source of truth to measure the error. In my case, the two boards are connected by a non-ptp capable switch... It is two different types of GPS receiver providing timing (one cheap chinese V.KEL VK16US and the other is a genuine u-blox LEA-6T) .. time passes .. The experiment is now running.... and looks as though it should settle down in the 10s (maybe low 100s) of ns. (the clock is 12ns period, and that is the measurement limit). The antennas are within a foot of each other, so they both have the same poor view of the sky. Philip On Thu, Sep 5, 2019 at 12:07 AM Andrew Kohlsmith (mailing lists account) < aklists@mixdown.ca> wrote: > Hello everyone, > > I’ve resurrected an old and no longer supported implementation of PTP for > the STM32 series of 32-bit microcontrollers. > > In a nutshell: the ethernet MAC on these micros has hardware support for > packet time stamping and fine-grained adjustment of a free running timer. > ST Micro had released a port of the ptpv2 client/server which took > advantage of this hardware using ptpd-2.0.0, but it’s been lost to the > sands of time. I’ve figured out a similar port and it’s working pretty good. > > The end application I’m working toward is a closed (no availability of > internet or gps time) network where multiple devices are working together > to measure position and orientation of objects in an environment with > carefully synchronized LED flashes and camera exposures. Absolute time is > unimportant, but everyone in the closed network agreeing on what time it is > is very important, down to single-digit microseconds. > > I have a pair of STM32F756 development boards syncing to a ptpd server > running on Linux. Using the hardware, timer-based (no interrupts or > software involvement) PPS output of the STM32s and a logic analyzer I can > see that the two STM32 dev boards wander in and out of sync with each > other. The absolute difference between the rising edges of the PPS signals > ranges from a few hundred nanoseconds to about 40-50us over the span of > about 20-30 minutes. > > The test system has a single (non-1588-aware) network switch, but the > final implementation will have a master with multiple network interfaces > directly connecting to each slave. The logging output of the STM32s shows > that the second-to-second offset error of a slave is in the neighbourhood > of +/-1500ns, and the long-term drift stabilizes out around 1200-1500pps. > > I’m looking to close the range of the short-term sync and try to hold the > slaves to within a half dozen microseconds of each other if possible. Now > the master clock is just a free-running clock on the PC (no GPS or NTP > discipline) but the absolute time is unimportant for me; what is important > is very tight sync between the slaves over the short (second-to-second) > term. > > I have some hardware coming in which will help me visualize how jittery > the master clock is, as I suspect some of this “slop” in sync comes from > the master clock jittering and the measurement of the master clock by one > slave not being the same as the other slave, causing the timing loops to > diverge. > > My newbie questions revolve around the short term sync error. Will an > undisciplined master clock aggravate the ability for multiple slaves to > stay synchronized relative to each other? What if I used a 10MHz OCXO and > divider to provide a PPS signal to the PC, lying to it that this is a GPS > PPS output and disciplining the master clock that way? It’s my > understanding that an OXCO short-term error is very small, and the GPSDOs > take advantage of this attribute while using the GPS long-term stability to > keep the time correct. > > The other newbie question is regarding adjusting the PI loop in the pop > codebase on the STM32 slaves; is there any value in trying to adjust the > loop coefficients to favour shorter term stability? I’m leery to do this, > as I am fully aware of my newbieness and that the coefficients are there > after a LOT of hard work to get them to optimal values. > > Thanks, > Andrew > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >