-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hearbeat register #45
base: main
Are you sure you want to change the base?
Add hearbeat register #45
Conversation
+1 on this! This would be hugely useful, and head off a lot of data quality issues. |
|
||
#### **`R_HEARTBEAT` (U16) – Heartbeat register reporting the current status of the device** | ||
|
||
Address: `018` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we fix this address now? Or do we need to wait for merging #39 and #38 beforehand?
In general I guess this is an interesting question regarding numbering of newly proposed common registers, should the address be part of the proposal, or should we number them incrementally as they get merged on a first-come, first-served basis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think there is any requirement for registers to be sequential right now. Or at least in the protocol. I think that in general we should honor the "reserved" register of the PR in case people implemented a proof-of-concept already. But maybe there is a stronger reason to follow the sequence?
section Id | ||
IS_ACTIVE :id0, 15, 16 | ||
IS_SYNCHRONIZED :id1, 14, 15 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the exact issue is, but for some reason the visual diagram of the register does not render correctly on my browser as the two bits are overlapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about grouping the reserved bits as we do for the other registers? e.g.:
---
displayMode: compact
---
gantt
title R_HEARTBEAT (018)
dateFormat X
axisFormat %
section Bit
15-2 :reserved, 0, 1
1 :bit1, 1, 2
0 :bit0, 2, 3
section Id
- :idr, 0, 1
IS_ACTIVE :id0, 1, 2
IS_SYNCHRONIZED :id1, 2, 3
section Default
- :dr, 0, 1
- :d7, 1, 2
- :d6, 2, 3
Co-authored-by: glopesdev <[email protected]>
Co-authored-by: glopesdev <[email protected]>
Summary
This PR adds a new register to the protocol called
HEARTBEAT
.Motivation
We want to be able to periodically check the status of the device. Including synchronization, mode and error status.
Detailed Design
We will add a new register with the following specs:
Name: Heartbeat
Address: 18
Format: U16
Access: Read-only
For now, only 3 bits will be implemented:
The other 14 bits will remain free for future status bits.
More information is available in the PR.
Design Meetings
See further discussion in the following issues: