-
Notifications
You must be signed in to change notification settings - Fork 1
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
Adding support for Booster v1.6 channels #237
Conversation
TESTED ON BOOSTER HL v1.6 input_power = -25 dBm |
…v1.6-support * origin/main: (78 commits) Updating changelog Adding detected phy to service info Updating workflow Fixing detection algorithm Adding basic phy detection Adding token Removing deploy key Updating trigger branches for docs Updating booster docs location Removing W5500 patch Simplifying watchdog timer types Updating HAL and other dependencies Bump serde from 1.0.157 to 1.0.158 Bump serde from 1.0.156 to 1.0.157 Bump serde from 1.0.155 to 1.0.156 Bump serde from 1.0.152 to 1.0.155 Bump enum-iterator from 1.3.0 to 1.4.0 Bump cortex-m-rtic from 1.1.3 to 1.1.4 Bump cortex-m-log from 0.7.0 to 0.8.0 Bump bit_field from 0.10.1 to 0.10.2 ...
bors try |
tryBuild failed: |
bors try |
tryBuild failed: |
bors try |
tryBuild succeeded: |
Bors r+ |
237: Adding support for Booster v1.6 channels r=jordens a=ryan-summers This PR fixes #233 by adding an additional ON/OFF toggle during the channel initial power-up. ~~It's not currently known if this is sufficient to clear the interlocks in all cases because of the unknown states of the power detectors during the power-up process. If the power detectors create transient voltage outputs that exceed the interlock thresholds, the channels will power up in a tripped state.~~ ~~However, the most likely case is that the power detectors will remain low during the power-on process and the interlock will not trip, so there's relatively high confidence that this should address v1.6 concerns.~~ It was discovered that the power detectors did not stay low during initialization, but this was remedied by resetting the interlocks immediately after the channel powered up. Co-authored-by: Ryan Summers <[email protected]> Co-authored-by: Robert Jördens <[email protected]>
This PR was included in a batch that successfully built, but then failed to merge into main. It will not be retried. Additional information: Response status code: 422
{"message":"At least 1 approving review is required by reviewers with write access.","documentation_url":"https://docs.github.com/articles/about-protected-branches"} |
Bors merge |
Build succeeded: |
This PR fixes #233 by adding an additional ON/OFF toggle during the channel initial power-up.
It's not currently known if this is sufficient to clear the interlocks in all cases because of the unknown states of the power detectors during the power-up process. If the power detectors create transient voltage outputs that exceed the interlock thresholds, the channels will power up in a tripped state.However, the most likely case is that the power detectors will remain low during the power-on process and the interlock will not trip, so there's relatively high confidence that this should address v1.6 concerns.It was discovered that the power detectors did not stay low during initialization, but this was remedied by resetting the interlocks immediately after the channel powered up.