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 -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
