Dev/sync time validity #61
Conversation
Poofjunior
commented
Nov 18, 2024
Poofjunior
commented
- Added supplementary logic analyzer waveform
- Added microcontroller cpp code for interpretting the received timestamp data as the current time.
- Added link to a full state machine example for clocking in the timestamp byte-by-byte.
|
@glopesdev are you ok with merging this? Thx! |
| uint64_t curr_us = ((static_cast<uint64_t>(encoded_sec) + 1) * 1e6) - HARP_SYNC_OFFSET_US; | ||
| ```` | ||
|
|
||
| A full example demonstrating a state machine receiving the 6-byte sequence can be found in the [Pico Core](https://github.com/AllenNeuralDynamics/harp.core.rp2040/blob/main/firmware/src/harp_synchronizer.cpp). |
There was a problem hiding this comment.
| A full example demonstrating a state machine receiving the 6-byte sequence can be found in the [Pico Core](https://github.com/AllenNeuralDynamics/harp.core.rp2040/blob/main/firmware/src/harp_synchronizer.cpp). | |
| A full example demonstrating a state machine receiving the 6-byte sequence can be found in the [Pico Core](https://github.com/harp-tech/core.pico/blob/main/firmware/src/harp_synchronizer.cpp). |
@Poofjunior These changes look great, thanks for the greatly improved documentation! If you think we are close to transferring the pico repository I would adapt the URL of this example as suggested above.
You will notice I am implicitly suggesting a naming convention for the core repos which should be consistent with yours, but I have opened a discussion for us to review it together: https://github.com/orgs/harp-tech/discussions/120
| The connector used is from `Switchcraft Inc.` with PartNo. `35RASMT2BHNTRX`. | ||
|
|
||
| A KiCAD schematic template for creating a Harp device based on the [RP2040](https://www.raspberrypi.com/products/rp2040/) microcontroller with circuitry for receiving the timestamp is provided through the [Pico Template](https://github.com/AllenNeuralDynamics/harp.device.pico-template). |
There was a problem hiding this comment.
| A KiCAD schematic template for creating a Harp device based on the [RP2040](https://www.raspberrypi.com/products/rp2040/) microcontroller with circuitry for receiving the timestamp is provided through the [Pico Template](https://github.com/AllenNeuralDynamics/harp.device.pico-template). | |
| A KiCAD schematic template for creating a Harp device based on the [RP2040](https://www.raspberrypi.com/products/rp2040/) microcontroller with circuitry for receiving the timestamp is provided through the [Pico Template](https://github.com/harp-tech/device.pico-template). |
Similar to above, it might be useful to transfer the pico template repository to harp-tech. Not sure whether it should be named device or whether we should have a different convention for templates. I am happy to keep the device prefix but just leaving it out there in case anyone has any concerns.
There was a problem hiding this comment.
I like this idea!
Per Kicad-9 improvements, I may make some changes and add a secondary hardware library to this template, but I haven't settled on that just yet.
The big change in V9 was the ability to create schematic "snippets" called Design Blocks and reuse them within and across projects. I paste snippets across projects manually for various power supply designs, so I may do further reading on how to tease them into a repository.
There was a problem hiding this comment.
Short term, I think the docs changes are usable and an improvement as-is, so I'd motion for pico hardware template repo migration later.
| * Remove table of contents to avoid redundancy with doc generators. |
There was a problem hiding this comment.
Is there a missing version increment here? We can discuss what is our convention for incrementing standard document versions going forward.
There was a problem hiding this comment.
You might have to fill me in what you mean here. Do I need to bump a version somewhere?
SynchronizationClock.md
Outdated
| > [!NOTE] | ||
| > The device *sending* the timestamp isolates each clock output port, preventing ground loops from forming when connecting the audio jack between sender and receiver. | ||
|
|
||
| A supplementary PDF [example](./PhysicalConnector.pdf) of the sender and the receiver is also available. |
There was a problem hiding this comment.
We should probably move the original connector PDF into the assets folder.
There was a problem hiding this comment.
Moved (and also moved the .sch file).
SynchronizationClock.md
Outdated
|
|
||
| The schematic snippet for a device *sending* the timestamp is shown below: | ||
|
|
||
|  |
There was a problem hiding this comment.
|  | |
|  |
Could we rename the file to follow PascalCasing for consistency with other asset and document files? I like the name you used for the image alt tag so placing that as a suggestion.
By the way this did lead me into a rabbit hole to try and decide between "synch" and "sync" (https://grammarhow.com/sync-vs-synch/). I am happy to go with one or the other but we probably should be consistent.
SynchronizationClock.md
Outdated
|
|
||
| The connector pinout for a device *receiving* the timestamp is shown below: | ||
|
|
||
|  |
There was a problem hiding this comment.
|  | |
|  |
Similar to the sender, can we rename the file to follow PascalCasing for consistency with other asset and document files? I like the name you used for the image alt tag so placing that as a suggestion.
SynchronizationClock.md
Outdated
| > | ||
| > To avoid unexpected behaviors, only one bit at a time should be written to register `R_RESET_DEV`. | ||
| A sample logic trace is shown below: | ||
|  |
There was a problem hiding this comment.
|  | |
|  |
Similar to the other assets, can we rename this file to follow PascalCasing? In this case I propose a mix keeping the alt tag casing and the "trace" word for clarity.
