Specification for downsampled clock synchronization protocol

[glopesdev]

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Standardize the operation of the clock synchronization protocol for transmission over virtual serial ports operating over much slower baud rates. This would allow logging the Harp clock synchronization signal on non-Harp devices running their own local clocks for the purposes of automated post-hoc alignment.

Motivation

The device-specific developments in harp-tech/device.behavior#3 provide an interesting option for general-purpose interoperability of the Harp clock synchronization protocol with non-Harp IO devices for alignment purposes.

The implemented solution transmits the clock via a digital output using a lower baud rate which can be recorded by other devices which are not Harp devices. Generalizing the approach would allow potentially embedding this slower transmission protocol into clock synchronizer devices themselves, allowing these devices to become a one-stop shop for all device synchronization needs.

Routines such as harp-tech/harp-python#38 could also be adapted to provide a general infrastructure for automatically aligning any Harp and non-Harp streams post-hoc.

Detailed Design

Multiple levels should be considered to complete the detailed design, specifically:

• consider whether a new core register or a standardized device-specific register are more appropriate to provide this feature;
• hardware implementation requirements to assess the difficulties and impact of implementing this transmission over existing clock synchronizer devices;
• assess the requirements to develop an automated post-hoc alignment procedure.
  The existing design needs to be reviewed and its internals understood to find out operation limits and applicability to heterogeneous devices with varying sample rates. We need to understand whether configuration of the virtual baud rate should be allowed to allow customizing the amount of downsampling per application, and the implications and tradeoffs of changing this parameter.

Drawbacks

There may be unknown impacts of providing downsampled transmission of the clock signal in parallel with generating the original synchronization signal which need to be taken into account during development of this specification.

Alternatives

Not doing this will continue to proliferate ad-hoc solutions for interoperable clock synchronization between non-Harp and Harp devices, including TTL sync pulses, pseudo-random sequences, counters, etc.

Unresolved Questions

The existing design needs to be reviewed and its internals understood to find out operation limits and applicability to heterogeneous devices with varying sample rates. We need to understand whether configuration of the virtual baud rate should be allowed to customize the amount of downsampling per application, and the implications and tradeoffs of changing this parameter.

Design Meetings

[Poofjunior]

Thanks for starting this convo. Here's a couple things from our experiences synchronizing NIDAQ devices with Harp timing.

The White Rabbit already does something like this to remove the need to require the behavior board to generate this slow timing signal you describe above. The Auxiliary Baud Rate feature emits the current second on the start of the whole second. The baud rate is configurable, but the default is 1000bps, which was to be compatible with existing time-series post-processing alignment scripts written by Josh Siegle.

Implementation details worth mentioning:

To actually meet the timing requirements in the feature described above forced me to do a soft uart implementation with interrupts. That's because the Pico's uart peripheral uses clock division to generate slower baud rates, which meant I could not guarantee that start-of-uart transmission time would emit <32us from its target time if I emitted the timestamp using the peripheral. Instead, it would be the emitted at the next-nearest multiple of the divided clock, which for 9600bps is every ~104us--far too late to meet the spec.

That's all to say: implementing this feature and validating that it is within the <32us spec involves some work.

Suggestions

I'd suggest making the "slow baud rate" a standard baud rate, i.e: 4800bps, 9600bps, etc. because I would not expect UART peripherals that would be the recipients of this signal to support arbitrary baud rates.

Other Alternatives

The White-Rabbit also supports a 50% duty cycle TTL output with the rising edge on the start of the whole second. While not providing actual time, it could be useful to start other systems on a known timestamp.

Another solution might be a small "timestamp interpreter" device that connects to a Clock Generator audio jack and reinterprets the signal into something else. Rather than baking the solution into the Clock Generator, this would enable features to remain standalone and easier to change. This could also be useful if multiple non-Harp devices need a synchronization signal where having multiple auxiliary-style outputs on the Clock generator would be impractical.

[bruno-f-cruz]

Current implementation in the behavior board:

• 1Kbps
• Each byte has 1 stop and 1 start bit (RS232 spec)
• When to start pulsing? The first falling edge occurs when a new second has elapsed.

Consider standardizing the functionality and, if people implement it, encourage to do so following it. We should recommend that future clock generators implement this feature.

Consider making the baud rate configurable.

[bruno-f-cruz]

@filcarv @Poofjunior @glopesdev
I was about to write a proposal for this, but after taking another look at @Poofjunior 's post, I am having second thoughts regarding the spec on the baud rate.

I am currently leaning towards spec'ing it as configurable, but strongly recommending a specific value. In theory, I would recommend what we already use (1kbps), however, Sonya's point suggests we should probably adopt something more "standard". Looking at common baud-rates, it seems like 1.2kbps is the closest.