Better control over interlocks

[jmatyas]

Currently it is possible to disable interlocks directly only by the means of setting power threshold to a specific value or forcing over-temperature shutdown. Please add a way for both MCU and an external controller to force disabling RF channel (preferably each channel independently).

And while an external controller is able to read the channel's state, MCU has no way of doing that. Please add a way for the MCU to read the channel's state.

[kaolpr]

How it is implemented in Booster? I know that there is a setting exposed via MQTT that can make channel enabled or disabled, but don't know how it is implemented. @ndnq can you comment on that?

Anyway, channel state information in MCU should be available.

[ndnq]

If we are talking about output power interlocks, in Booster they too can only be "disabled" by writing a high enough threshold value. Other interlocks are hardcoded and cannot be turned off.

As for reading the RF channel's current state, Booster posts it over MQTT as part of telemetry data. The fastest it can do so is I think every second. For what I've been doing with it, it has been sufficient.

You can also post or read the state from the settings interface over MQTT. Posting to it can disable the RF output or completely power down the channel depending on the sent payload, and that's what I have been doing.
Reading from it, on the other hand, makes little sense as it will repost the state that it was set to and not the current one.

[jmatyas]

I think there was a misunderstanding. What I actually meant by saying "disabling interlocks" was to disable or enable RF channel. Sorry.

Booster hardware provides a means of turning RF channel off in at least two ways other than setting interlock threshold low enough. CPU can either:

• drive SIG_ON LOW to turn the safety switch (IC14 on preamp sheet ) OFF, which decouples input signal from the amplifiers, or
• disabling power fed to the RF channel.
  However, the two solutions usually are used together.

On Silpa there is no such possibility so it would be nice to add these functionalities (together with channel state). It shouldn't be a pin-availability problem, since there are plenty unused - we don't need 2 serial ports (USART1 AND USART3) AND USB communication. Additionally, we don't use ADL5904 as the threshold detection device, so we could free both VCAL pins as well.