| 26 Jan 2022 |
 adamgreig | in my custom version I also have a coax network between nodes that need higher synchronisation levels and measure the phases there and feed that into my PTP kalman filter, and that gets me down to about 2ns relative error | 12:50:25 |
| adamgreig | (the coax network is what was previously used for time sync via timecode signals instead, before i wrote the first version of this ptp thing, but since the hardware was all there i figured may as well use it) | 12:51:05 |
 Robert Jördens | But in any case, WR is still pretty niche. Most people will be vary happy if they get a sub-µs no-hassle PTP clock from their stm32s without doing much work. | 12:51:11 |
| adamgreig | yea! | 12:51:18 |
| adamgreig | yea, I bet if smoltcp Just Did It it might well find a lot of new use cases | 12:51:30 |
| adamgreig | cuz it's a huge chore to go from "i have the stm32 reference manual" to "i have working time sync", not least with the PTP spec not open access | 12:51:49 |
| Robert Jördens | In reply to @adamgreig:matrix.org
in my custom version I also have a coax network between nodes that need higher synchronisation levels and measure the phases there and feed that into my PTP kalman filter, and that gets me down to about 2ns relative error Very cool! | 12:53:48 |
| adamgreig | the 2ns number requires some knowledge of cable length as I don't have hardware capability to measure it bidirectionally though :P | 12:54:18 |
| adamgreig | still it was more than good enough | 12:54:27 |
| adamgreig | the previously sync accuracy with the timecode was like, microseconds | 12:54:36 |
| Robert Jördens | But if you have such a good distributed frequency reference, then you only need PTP as a PPS-on-steroids to get you the absolute delays. | 12:55:31 |
| adamgreig | anyway I'll give you a shout if/when I get the itch to write a conformant protocol implementation | 12:55:57 |
| adamgreig | not all nodes have the coax, and we probably won't include it in future hardware since the ethernet one works, so I wanted to base it around ptp primarily | 12:56:30 |
| adamgreig | and just add the coax as basically a measurement of pure t_offset with almost zero t_delay | 12:56:49 |
| Robert Jördens | I see. | 12:57:37 |
| Robert Jördens | Somewhat related topic, while bragging about accuracy and stability 😉 We are just finishing a device that stabilizes the effective optical path length of a fiber (or for that matter any coax line) against acoustical and thermal fluctuations to sub-ps (RMS in 100 kHz). | 13:01:10 |
| adamgreig | 😱 nice! | 13:02:19 |
| Robert Jördens | And there PTP would still be super-useful to get absolute accurate UTC time-tags for periods where the fluctuations we so large that they could not be compensated (or for those times where some piece of dust fell through the laser beam). | 13:02:39 |
| adamgreig | I really like how many orders of magnitude you can play with in timing precision. I'm having a great time here in the some-nanoseconds and you're 4 orders of magnitude lower | 13:02:52 |
| adamgreig | my timer/counter "only" goes to 20ps ultimate resolution, lol | 13:03:42 |
| Robert Jördens | Well time is the thing we can measure most accurately. Many, many orders of mangitude more accurately than anything else. | 13:03:58 |
| Robert Jördens | In reply to @adamgreig:matrix.org
my timer/counter "only" goes to 20ps ultimate resolution, lol Hardware? The one in the PTP block? Or is that your software state? | 13:07:50 |
| adamgreig | my test gear | 13:08:10 |
| adamgreig | the PTP block is 10ns increments on a 1ns counter | 13:08:24 |
| adamgreig | (well you can increment at whatever you want and in theory set it to be more like 0.3ns? but about that) | 13:08:44 |
| Robert Jördens | Ah ok. | 13:09:01 |
| adamgreig | it can count decimal nanoseconds or binary 2^-31th of a second before incrementing the seconds counter | 13:09:51 |
| adamgreig | counting in binary is in theory more precise but also more annoying to convert to and from decimal nanosecond timestamps on the network, and I already have no rounding error from nominal 168MHz through the NCO, so no point | 13:10:36 |
| Robert Jördens | Hmm. The capture is probably jittery enough that quantization doesn't matter much. | 13:12:46 |
| adamgreig | yea, I doubt it's a huge concern, I suspect the option is so you can use whatever is more convenient.. if you weren't doing ptp at all you could also leave it in binary mode to get a 63-bit nanoseconds counter instead, I guess | 13:13:36 |
