Hi Andrew, On 2019-11-03 23:28, Andrew Kohlsmith (mailing lists account) wrote: > Good afternoon, everyone, > > 000702615.150663173 (000342239): state=slave: offset= -107ns > drift=1073.417ppm HCLK=216.232MHz (4.325x) > 000702616.150761324 (000343239): state=slave: offset= -41ns > drift=1073.414ppm HCLK=216.232MHz (4.325x) > 000702617.150859615 (000344239): state=slave: offset= -63ns > drift=1073.414ppm HCLK=216.232MHz (4.325x) > 000702618.150957847 (000345239): state=slave: offset= -176ns > drift=1073.408ppm HCLK=216.232MHz (4.325x) > 000702619.151056198 (000346239): state=slave: offset= -258ns > drift=1073.393ppm HCLK=216.232MHz (4.325x) > > I tried playing around with zeroing the drift once I was synchronized, but > that just creates a step response in ‘addend’ value the STM32 uses to finely > adjust its time, which usually knocks it out of sync, performs a one-time > step in the slave time and my drift is back in this 1000-1100ppm range. This > tells me that the drift value is correct, but I can’t figure out why. > > > My question is why would the long-term drift stay so high even though the > systems *are* synchronized? I know I’m missing something, I just do not know > what it is.
"Drift" is most probably phase-drift, i.e. frequency, so you do not measure it in ns but in fractional form as done already. The control-loop needs to build up that frequency control value to compensate for the oscillator frequency offset in order to have it run at the same rate as the master, and then it can phase-align it. All that you described is consistent with that, its a concequence of your oscillator, master reference and a working PLL loop. Why you have a relative frequency error that large may have many reasons. Cheers, Magnus _______________________________________________ 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.
