!yafYEipFNsXDdwiHMT:matrix.org

Real-Time Interrupt-driven Concurrency (RTIC)

506 Members
Welcome to the Rust Embedded Real-Time Interrupt-driven Concurrency (RTIC) chat room! | Documentation: https://rtic.rs/ | Discuss, coordinate, help: https://github.com/rtic-rs | Meeting-notes: https://rtic.rs/meeting | Code of conduct: https://www.rust-lang.org/conduct.html62 Servers

Load older messages


SenderMessageTime
26 Jan 2022
@adamgreig:matrix.orgadamgreigin 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 error12:50:25
@adamgreig:matrix.orgadamgreig(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
@jordens:matrix.orgRobert JördensBut 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:matrix.orgadamgreigyea!12:51:18
@adamgreig:matrix.orgadamgreigyea, I bet if smoltcp Just Did It it might well find a lot of new use cases12:51:30
@adamgreig:matrix.orgadamgreigcuz 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 access12:51:49
@jordens:matrix.orgRobert 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:matrix.orgadamgreigthe 2ns number requires some knowledge of cable length as I don't have hardware capability to measure it bidirectionally though :P12:54:18
@adamgreig:matrix.orgadamgreigstill it was more than good enough12:54:27
@adamgreig:matrix.orgadamgreigthe previously sync accuracy with the timecode was like, microseconds12:54:36
@jordens:matrix.orgRobert JördensBut 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:matrix.orgadamgreiganyway I'll give you a shout if/when I get the itch to write a conformant protocol implementation12:55:57
@adamgreig:matrix.orgadamgreignot 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 primarily12:56:30
@adamgreig:matrix.orgadamgreigand just add the coax as basically a measurement of pure t_offset with almost zero t_delay12:56:49
@jordens:matrix.orgRobert JördensI see.12:57:37
@jordens:matrix.orgRobert JördensSomewhat 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:matrix.orgadamgreig😱 nice!13:02:19
@jordens:matrix.orgRobert JördensAnd 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:matrix.orgadamgreigI 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 lower13:02:52
@adamgreig:matrix.orgadamgreigmy timer/counter "only" goes to 20ps ultimate resolution, lol13:03:42
@jordens:matrix.orgRobert JördensWell time is the thing we can measure most accurately. Many, many orders of mangitude more accurately than anything else.13:03:58
@jordens:matrix.orgRobert 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:matrix.orgadamgreigmy test gear13:08:10
@adamgreig:matrix.orgadamgreigthe PTP block is 10ns increments on a 1ns counter13:08:24
@adamgreig:matrix.orgadamgreig(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
@jordens:matrix.orgRobert JördensAh ok.13:09:01
@adamgreig:matrix.orgadamgreigit can count decimal nanoseconds or binary 2^-31th of a second before incrementing the seconds counter13:09:51
@adamgreig:matrix.orgadamgreigcounting 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 point13:10:36
@jordens:matrix.orgRobert JördensHmm. The capture is probably jittery enough that quantization doesn't matter much.13:12:46
@adamgreig:matrix.orgadamgreigyea, 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 guess13:13:36

There are no newer messages yet.


Back to Room List