Improved specification of sync clock protocol #192
Conversation
fix graphic
glopesdev
requested review from
Poofjunior,
artursilva0,
bruno-f-cruz and
filcarv
|
@filcarv @Poofjunior @artursilva0 @bruno-f-cruz I have decided to try and tidy up the synchronization clock protocol to fit within the style of all the other specs. Specifically, I continue to have questions about how best to represent little-endian byte ordering (right-to-left or left-to-right, indices are correct and consistent with @filcarv @Poofjunior I have grouped both the oscilloscope and the logic analyzer trace in the same section, let me know of thoughts and/or whether you would prefer to see both, or just one or the other, or keep them separate (and if so, in which section). @Poofjunior On the example schematic for the audio jack connector for Harp synchronization signal (ESD protected with TVS diode) provided with the pico template, I was wondering if it might make sense to transfer a copy of that specific schematic to this repository for now, so we could reference it locally as in the other files and make the final distribution self-contained? |
glopesdev
force-pushed
the
dev/sync-protocol
branch
from
ba69229 to
64d4293
Compare
* Improved specification of synchronization clock protocol * Adopt requirement key words from RFC 2119 * Reorganize document sections for consistency and improve wording * Add explicit transmission packet diagram
glopesdev
force-pushed
the
dev/sync-protocol
branch
from
64d4293 to
a17795f
Compare
|
|
||
| Transmission of the last byte MUST start exactly 672 μs before the current second lapses. | ||
|
|
||
| Receivers MUST align their clocks so the next whole second starts exactly 672 μs following reception of the last byte, ensuring any fractional part of the timestamp is zero. Receivers MAY complete the initial alignment over a few transmission events, but thereafter MUST keep updating the whole second in sync with successfully transmitted Harp Synchronization Clock messages as long as the whole second is incremented sequentially. |
There was a problem hiding this comment.
@filcarv @Poofjunior @bruno-f-cruz I tried to describe here how the clock alignment process is expected to unfold from the point of view of the receiver. I am not sure how well this reflects the exact implementation details of each of the cores, so would be great to have some feedback before merging.
2 participants
This PR builds on top of and supersedes #61 by restructuring the synchronization clock protocol specification to improve wording and consistency with other spec documents.
Closes #155