Skip to content
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

interlock flop connection #370

Closed
jordens opened this issue Aug 20, 2020 · 6 comments
Closed

interlock flop connection #370

jordens opened this issue Aug 20, 2020 · 6 comments

Comments

@jordens
Copy link
Member

jordens commented Aug 20, 2020

Currently, the comparators are connected to the clock inputs while the on_offn signal is connected to the asynchronous active low clear input. That's not a good design. The interlocks should always (i.e. asynchronously and level sensitive) assert and block the rf switch while they should only ever be cleared on falling on_offn (i.e. negative edge sensitive). With the current design, if the interlock thresholds remain asserted when on_offn rises again (e.g. because someone connected two amplifier outputs via a splitter and there is some mismatch) you'd never trip the reverse power interlock. It also prevents safe testing of either the interlock thresholds (i.e. disable the switches, set the thresholds very low and hope for them to be triggered). It's not a huge risk but it's clearly wrong.

Introduced in #192

Suggest to make the comparators an asynchronous set, and the on_offn a negative edge sensitive clear.

Debugging credits to @ryan-summers

@hartytp
Copy link
Collaborator

hartytp commented Aug 20, 2020

With the current design, if the interlock thresholds remain asserted when on_offn rises again (e.g. because someone connected two amplifier outputs via a splitter and there is some mismatch) you'd never trip the reverse power interlock

Unless I'm misremembering things, the reverse power interlock is implemented in software only so this isn't an issue.

@hartytp
Copy link
Collaborator

hartytp commented Aug 20, 2020

(but I can see it being a pain for debugging etc and I'm not suggesting that the current design is great).

@hartytp
Copy link
Collaborator

hartytp commented Aug 20, 2020

The nice thing about these boards is that they're nice and cheap (2 layers, cheap silicon). So it's easy to produce a couple at low cost to test out ideas for better interlocks using an existing Booster before committing to a larger production run.

@jordens
Copy link
Member Author

jordens commented Aug 20, 2020

Nope. Reverse power interlock is implemented in hardware. See the other issue.
IME, low board price is dwarfed by the hours of debugging/maintaining saved with a clean design, good review, and thorough tests.

@hartytp
Copy link
Collaborator

hartytp commented Aug 20, 2020

IME, low board price is dwarfed by the hours of debugging/maintaining saved with a clean design, good review, and thorough tests.

Sure. Anyway, the point is just that we should prototype any changes before rolling out to users, which is presumably uncontroversial...

@jordens
Copy link
Member Author

jordens commented Aug 20, 2020

That is indeed uncontroversial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants