Remote NFC Switch Panel: Risky wireless operation

[Toffs]

Hi, Using the latest January 2024 firmware and the wireless On/Off Tx control feature I’ve observed an unanticipated, potentially dangerous situation. Please share your thoughts and use-cases if there’s good reason to continue this current process.

From my testing the following condition must be met at all times for the Rx (and model) to remain powered On: the selected Tx bind channel, let’s say channel 16, must continuously output positive 100%. Anything other than this such as the channel output value being the default 0, the Rx switches off.

Issue: Currently, the bind channel output being set to +100% to keep the Rx On is done by a Free Mix. Therefore, if any other mix, flight mode, or any Tx programming which inadvertently changes the selected bind channel output from always outputting the fixed value +100%, the Rx switches off the model - potentially mid flight. I propose this feature in it's current form introduces additional risk by not following fail-safe logic. When dealing with critical operations like Rx/model power switching it's expected the normal safe operation using defaults would be 'state: On', or 'keep last state'.

Solution: 2 parts (i) Have the default bind output channel value 0 = the last know state for the Rx. IE, don't change anything.

(ii) Have the wireless switch function only trigger a state change if there’s a bind channel value change. IE the channel output acts like a Toggle Edge switch (or momentary switch) instead of a sustained 'must always be above X value' to keep the Rx On. This could be done 2 ways:

A) Trigger inverted state: If the channel output value goes above +50% for a moment it inverts whatever the Rx state is. Example: if the Rx is Off, a momentary +100% on the bind channel changes the state to On. When the bind channel goes back to 0 nothing changes. Repeating this +50% output action would switch Off the Rx.

Or B) Set state depending on positive/negative output. Example: If the channel output value momentarily goes above +50% it turns On the Rx (or no change if already On). If the channel output value momentarily goes below -50% it turns Off the Rx. After this, when the channel goes back to 0 the Rx state remains in this state.

Implementation ideas I’m aware that changing the default behaviour of the NFC wireless function could bring risk for existing setups. To help mitigate this I propose a toggle switch is added in the existing Device Config > Remote NFC setup menu. This could be: Wireless switch trigger: [fixed value / momentary]

This isn't great menu wording - please suggest improvements! If this change is implemented I’d recommend this be toggled to 'momentary' as default for all new binds. People with existing binds should automatically have the toggle set to 'fixed value' (current process), to mitigate the change risk.

Not sure if (ii) option A - invert on/off toggle switch, or option B - positive/negative value switch state is best. Please give your ideas, maybe both?

Note: I’m aware that technically the bind channel output doesn’t have to +100%, the switchover state is around +58% but this doesn’t impact the actual issue raised and it's solution. As always, I might have forgotten a key reason why the existing process is as it is, or not be aware of potential blocker causing the above new proposal not to work - please speak up if so :)

[Dsrenger]

I read it now several times, but didnt get your point.

If have it in the current way, you have to take care, das the channel never leaves the +100% during flight.

If you do it in the momentarily way, you have to take care, that it never gets over +50% (or -50%) . Otherwise it will toggle the RX off midflight. Where is the difference?

In any case you have to take care what you program. But thats normal with a RC Switch.

Perhaps I am missing something.

If it is regarding failsafe setting, I programmed it as "Hold" so the last known value will stay.

I dont understand where the benefit is. In every case you need to know what you program.

I dont get where adding more complexity to it increases the safety. At the moment it is simple. It behaves like a switch in end positions. And is compatible direktly with a mechanical switch, that gives out +100 and -100. It is easy to understand.

[RealTadango]

I don't see any issues with this. You just need to make sure the "Power" channel is never changed when it should not be changed, but that is no different than any other channel. If you have a weird mix that can pull elevators fully down you have the same issue. The Remote switching function has been working reliable in my 3 setup's and i don't see an issue with it.

I have a LS that is a combination of throttle cut and another switch which controls the power channel. So when the engine is running the plane can never turn off even if the power toggle switch is used. The LS is the input for the power channel and that is the only thing that controls that channel.

[bsongis-frsky]

I need to take time to read it!

[Toffs]

Hi gents, I’ve given this much thought over the Summer, but am now more convinced then ever that the logic for powering on/off the Rx with the NFC switch panel is not correct.

As I’ve observed manufacturing sites, critical hospital equipment, safety and override functions in high tech equipment, basic electronics design, handheld power tools, passive engineering solutions: ALL of them (without any exception thus far) have failsafe defaults that are ON or OFF - whichever is safest.

We surely must all be in agreement it is safest that the Rx stays in its last known power state (or default on) unless we’ve specifically (and clearly) instructed it to turn off - Yes?

I programmed it as "Hold" so the last known value will stay.

You just need to make sure the "Power" channel is never changed when it should not be changed

That both of you (and myself) highlight we’re adding extra programming in order to achieve this ‘failsafe’ operation is exactly the point of this issue :) It should be the other way round, the programming logic does this automatically, with extra code needed to override the failsafe default.

The NFC Switch should always stay in its last known state (or on) by design/default - not needing the operator to always remember this and ensure an ‘active’ Tx signal at all times. Supposing there’s a half second blip/glitch with the Tx transmitting the ‘channel 16 on’ signal? This could be a mechanical fault, signal interference issue, or simply a programming error done by the operator (most likely). This will turn off the plane mid flight - disastrous! If this happens with another channel, like the flaps let’s say, there’s a good likelihood that you could recover. Try recovering a plane that’s been switched off…

And finally, the NFC switch/Rx physical interface has been designed with this same failsafe by design already. If there is a connection or voltage failure between the NFC and Rx it will Keep the last known state > because failsafe! :) That we’re completely ignoring this for the radio logic which has similar risks is why I’m raising this, it’s not right and potentially really dangerous.

[RealTadango]

Hi gents, I’ve given this much thought over the Summer, but am now more convinced then ever that the logic for powering on/off the Rx with the NFC switch panel is not correct.

As I’ve observed manufacturing sites, critical hospital equipment, safety and override functions in high tech equipment, basic electronics design, handheld power tools, passive engineering solutions: ALL of them (without any exception thus far) have failsafe defaults that are ON or OFF - whichever is safest.

We surely must all be in agreement it is safest that the Rx stays in its last known power state (or default on) unless we’ve specifically (and clearly) instructed it to turn off - Yes?

I programmed it as "Hold" so the last known value will stay.

You just need to make sure the "Power" channel is never changed when it should not be changed

That both of you (and myself) highlight we’re adding extra programming in order to achieve this ‘failsafe’ operation is exactly the point of this issue :) It should be the other way round, the programming logic does this automatically, with extra code needed to override the failsafe default.

The NFC Switch should always stay in its last known state (or on) by design/default - not needing the operator to always remember this and ensure an ‘active’ Tx signal at all times. Supposing there’s a half second blip/glitch with the Tx transmitting the ‘channel 16 on’ signal? This could be a mechanical fault, signal interference issue, or simply a programming error done by the operator (most likely). This will turn off the plane mid flight - disastrous! If this happens with another channel, like the flaps let’s say, there’s a good likelihood that you could recover. Try recovering a plane that’s been switched off…

And finally, the NFC switch/Rx physical interface has been designed with this same failsafe by design already. If there is a connection or voltage failure between the NFC and Rx it will Keep the last known state > because failsafe! :) That we’re completely ignoring this for the radio logic which has similar risks is why I’m raising this, it’s not right and potentially really dangerous.

I don't see what you mean. Once you are settings up the module for remote control you are switching away from the default (token only) so you need the additional logic in your programming to make sure the remote off is only triggered when you want. There is no default channel and switch assignment so there is no default risk. When you setup this up i assume you understand the risk and take caution with the logic you assign to turn of the receiver. Failsafe should not have any affect because the remote module has its own logic and receiver unit. Only a change in the channel will switch it off, not signal loss or anything. When i apply power the receiver always powers on so even if the battery would disconnect in flight it would activate again regardless of the previous state. Exactly like you want it. Sound perfectly safe to me.

My logic so far is one of the 6 push buttons in a certain state AND throttle cut active will trigger the off channel state. It would be hard to trigger this mid flight......