-
Notifications
You must be signed in to change notification settings - Fork 6
Description
- Proposed
- Prototype: Not Started
- Implementation: Not Started
- Specification: Not Started
Summary
Provide a complete specification of the clock synchronization protocol, from both the generator and receiver side, taking into account both Harp and non-Harp devices.
Motivation
Currently how to generate the clock synchronization signal is detailed in the SynchronizationClock.md specification file. However, this document only describes how the generator side works, but not how receivers are supposed to decode the signal, and align their own clocks to the common specification.
This under-specification already created synchronization issues across different cores, e.g. see #62. Furthermore, other non-Harp devices such as the ONIX acquisition system have already been designed to acquire the Harp clock signal, and it is unclear how to assess their compliance from a receiver point of view.
Detailed Design
Consider renaming the specification file to ClockSynchronization.md to emphasize the fact it will describe both sides of the clock synchronization protocol, rather than just the generator. Add new sections for both generator and receiver devices, and describe in detail how both should work in concert, including initialization, coordination and expected recovery routines when the signal is lost.
Any deprecated protocols such as the old ATxmega clock receiver behaviour should be documented and clearly labelled as deprecated to encourage people to upgrade their firmware and explain clearly the consequences of not doing so.
Drawbacks
None are known at the moment.
Alternatives
Not completing the clock synchronization spec will likely continue the current trend of non-standardized reading and logging of Harp clock data. The new Pico core was the first to show a large deviation, but also in the ONIX receiver there may be a misunderstanding of whether the received second is the elapsed second, or the forthcoming second.
These ambiguities need to be clearly laid out to ensure interoperability works as expected, and to reduce the cost and risk of non-compliance.