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?
There was a problem hiding this comment.
There is a release notes section at the bottom of the document where for other updates we have been bumping release versions.
That said, this feels like it is becoming increasingly legacy, and I don't feel these really add anything on top of the versioning git provides. If the proposal in https://github.com/orgs/harp-tech/discussions/129#discussioncomment-12664412 is accepted, then I would actually motion for us to stop adding manual release notes in the files, and actually have all notes in PRs which can then be used to automatically generate notes for new releases.
If necessary we could generate back tags and create releases for older versions to keep track of when which bit was introduced, but going forward I feel it would be much simpler for everyone if there was a single version of everything protocol related.
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).
There was a problem hiding this comment.
I noticed for this specific one you created a separate folder for both the .sch and the .pdf files. Since we didn't do this separation yet for the other ones, could you move them both back to the root of the assets folder for now?
We could end up deciding it makes sense to have independent folder schematics, but in that case I would rather we do a single consistent refactoring for all assets simultaneously in a separate PR.
|
|
