Flyaway due to deviation bug?

Well, I think so. Here's the scenario:

I got a JJRC H20 as a gift. Set up a model file, played with the headless and RTH modes. Those were worthless, as reported and expected - that's what happens when you try and mimic hobby-grade features with toy-grade parts. So I dialed the # of channels back to 6, and changed the switches to my default version.

When I then tried to turn off the lights, it took off over the road/neighbors/pond, which pretty much was what I expected RTH to do. The issue was that I'd changed the switch that turned on RTH to be the one that turned on the lights, but didn't change the channel that turned on RTH. On a hobby-grade quad that doesn't use "magic bits" like this, dialing down the channels would be enough, since the channel wouldn't be transmitted. But the magic bits are still interpreted and sent, so....

That the mixer interprets output channels that are never output is arguably a bug, but one that is hard to fix and useful if you run out of virtual channels. That the magic bit channels are used even if they channels aren't sent is arguably not a bug, but I don't see how it's useful.

That made me think about my hobby quad since the higher channels are used for in-flight adjustments. I wouldn't trust that dialing down the channels would result in desirable behavior by the flight controller.

For the toy quad feature bits we'd generally know the correct behavior would be turning the feature off. I'm sure most of the protocols I've done do not check the number of channels enabled when checking each feature bit. Especially for the protocols that have multiple protocol options the feature bit code is already scattered through the packet building section. In recent protocols a macro is used so it could be extended. Or maybe add a minimum number of channels limit for the protocols? though that wouldn't force you to define a mixer.

in JJRC H20 case, i don't think so it's a deviation bug, i've seen this before. if you search on youtube "h20 flyaway" there are several video shows how this quad flyaway and they use stock tx. so i think is the JJRC H20 it self causing this flyaway.

Hmm. Ok, I can believe it's a JJRC problem. Makes me regret ordering a replacement, but they are cheap.

Not sending a channel should work properly on any hobby-grade FC. I can try some tests to make sure we do that. A reworking of the protocols - create an API for them, update all of them to use best current practices, and some other issues - is needed, so this can go on that list if it's a good idea.

BTW, the H8-3D protocol isn't in the manual. Any chance we could get that fixed? Especially the flip channel. That doesn't seem to make sense: it works as a switch or toggle, but you have to turn it off to use it a second time. If you try setting it up as a momentary button, it only works if you hold it down. This is a pita. Or did I do something wrong here?

mwm wrote: Not sending a channel should work properly on any hobby-grade FC.

Don't think this is a given. Say the FC has an RTH function which I've put on channel 6, and only send 5 channels. Should the FC invoke RTH? It's not a failsafe condition because 4 channels are still coming in. If the FC is configured to set RTH based on channel value > 0, and doesn't get a value because there's no signal, how does it know the correct thing thing to do? (kind of like getting a null when expecting true or false)

For a digital interface like spektrum satellite or sbus what value is sent to the FC if no channel is received? The deviation protocols generally put a mid-channel value in the channel data for unused channels if the rf interface transmits all channels all the time. Assuming the receiver still outputs those values (or even if it puts some other value on the channel if the protocol itself knows how many channels are in use) then the FC will interpret them as if they're the intended command. That might not produce the intended result.

Unless I'm missing something

Well, yeah, the behavior if we don't send a value - or send a fixed value - will depend on the Rx and FC. But we shouldn't be able to change the value the Rx sees for a channel if the model is configured to not send it. The Rx could have a failsafe for that channel that's different from the default, and the FC could well do anything at all depending on other channels (i.e. - a "panic" channel could trigger RTH along with other actions, or after a timeout, or RTH could be triggered by an LVC, or ....).