Standardize the "extensions" channels?

I've been updating the docs for protocols, and have noticed I find annoying:

we have a 7 models with "extensions", that are basically hacks to add (mostly) on/off channels in unused bits of a 4-channel radio system. As such, we can assign these functions to pretty much any channel we want. But they're a hodge-podge. Here's the table of what I have:

About the only thing they all agree on is that still cameras should be on 7, and headless mode should be on 9.

I propose we standardize these things. If we go with:

WIth the understanding that if a quad has a function, it should be on that channel. If it doesn't have one, it can do whatever it wants with it.

Then we will only break two protocols: Flysky V9x9 will need to swap flip & video, and YD717 will need to swap flip & lights.

Hubsan4 will need to move video to 8. We might be able to set it up so that both 7 and 8 can start/stop video, depending on how it works. I can investigate that.

Note that since these aren't real channels, but are handled internally by flipping bits in other channels, the only cost for having unused channels is needing to scroll past them in the mixer. But there won't be many of those.

I'm not sure if the "rate" control on the cx10's and the cg023 is really a rate, or is some form of envelope control. If someone knows, we ought to document that.

In any case, trying to set up standards for both rate and two calibration channels would push us out to 13 channels. So maybe we should break all of those, and just have "calibration", which triggers all of them (do you really ever want to calibrate a single axis?), and put rate on the other one.

9x9 is the oldest of the bunch. What's I find interesting is that it's not even compatible with itself. So even though you can fly a V626 (I think that's it) with a V959 model.ini, the extended functions won't work right. Of course, since the V9x9 extensions are in the throttle channel, and the newer models treats those as actual values, trying to fly a new model with a V9x9 protocol is dangerous.

All the ones that need to be changed exist in v4.0.1. Possibly we should change the documentation to name the new flavors, and then document the legacy versions as different, to encourage authors of future extensions to do it the more common way?

I never really saw a clear answer as to what the rates actually do. I'm going to try and be very clear here, which probably means repeating a lot of things everyone knows. My apologies for that.

Yes, I understand that this is what happens when you set the RTF Tx to those rates. That it actually transmits bits to the Tx is, um, disturbing. Normally, setting those on an RTF Tx doesn't transmit any bits to the Tx, just changes the interpretation of the stick positions, and that behavior is what is usually meant by rates.

So in this case, a 20% rate would mean that, with the sticks at full throw, the aircraft changes orientation at 20% of the speed it would with a 100% rate. As noted, this doesn't really need to be sent to the aircraft, as deviation can do all this in the Tx. Using Tx rates and then PB's hack of setting the Rx rate to deal with the lack of bits in the protocol sounds like a good idea, as it means that someone who uses expo to less sensitive sticks near the center would actually get that in all rates.

The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

If channels are virtual why give them numbers at all? Why not give them functional names?

Instead of assigning video to channel x, assign it to 'video'. And a table can cross reference 'video' to some other level of abstraction. Or to actual hardware.

If you don't like how the assignments are laid out in your transmitter then change them. By reference. No one else needs to know or care. Everyone can move things around on their unit as they please. Without changing model files. If I want a certain switch to control video on every model I just set it up. one time. Then every model conforms to my wishes. And I know better what to expect from any model.

If model.ini files could eventually reflect this functionality they would become more readable too.

Press a button and a picture of the transmitter appears on the display. With all switches and controls labeled according to function.

mwm wrote: The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

This is what "rates" means for the majority of toy quads - the maximum angle of deflection from horizontal. Often called angle mode in hobby quad controllers, it also means the aircraft self-levels when the sticks are returned to zero. Stick position controls the angle of the aircraft..

In what's called "rate mode" the limit refers to the maximum rate of rotation allowed by the controller. Stick position controls the rate of rotation.

For example the Syma X1 operates in rate mode because it only has a gyro. I think a couple of the WLToys quads support both, but most toy quads with accelerometers ("6-axis").are always in angle mode.

hexfet wrote:

mwm wrote: The alternate case I'm wondering about is if the rates affect the maximum orientation of the aircraft. In this case, a 20% "rate" would mean that the aircraft stops changing roll and pitch orientation when it reaches 20% of the value it would go to with a 100% "rate". This is a useful feature, and requires that the rate information be sent to the aircraft.

This is what "rates" means for the majority of toy quads - the maximum angle of deflection from horizontal. Often called angle mode in hobby quad controllers, it also means the aircraft self-levels when the sticks are returned to zero. Stick position controls the angle of the aircraft..

Well, that's not my experience, but I haven't bought many of the toy quads since they started showing up with 6-axis gyros: just a couple of Estes Proto X's (one SLT, one normal). If so, it also means we aren't handling "rate" mode on the majority of the toy quads, as only a few of them (just the cx10, dm007 & cg023) implement it. At least, that I noticed when updating the manual.

This makes me wonder if we can turn off the rate mode in some of them, even if the RTF Tx's don't allow that. The lack of such a mode is one of the reasons I haven't bought many of them. It would make them a lot more interesting, even if still had auto-levelling.

Richard96816 wrote: If channels are virtual why give them numbers at all? Why not give them functional names?

Because we don't have any other method of communicating between the user interface and the mixer output but channels. Which have numbers. Yeah, it makes this kind of thing clumsy, but there's really no other way to handle things. I guess we could try looking for virtual channels with those names and use those if they existed, but that's not really a lot better.

FWIW, I've been contemplating a desktop config editor that would let you do this kind of thing. You'd give it a config file that listed your favorite mapping from functions to switches, and could then pick a protocol and set of functions, and it would write out a model config file. Or (the real goal), it could read in a config file for some arbitrary Tx, use heuristics to figure out the functions, then write out a model using your config - which means it would work on your Tx, even if it's a different one. Not a single line of code written yet, so don't expect it soon, if evern

mwm wrote: Well, that's not my experience, but I haven't bought many of the toy quads since they started showing up with 6-axis gyros: just a couple of Estes Proto X's (one SLT, one normal). If so, it also means we aren't handling "rate" mode on the majority of the toy quads, as only a few of them (just the cx10, dm007 & cg023) implement it. At least, that I noticed when updating the manual.

This makes me wonder if we can turn off the rate mode in some of them, even if the RTF Tx's don't allow that. The lack of such a mode is one of the reasons I haven't bought many of them. It would make them a lot more interesting, even if still had auto-levelling.

I wasn't clear. The "rate" controls on most 6-axis toy quads set the maximum angle - the quad always flies in angle mode. The CX10 doesn't have a "rate mode" (it's the only one of the three you named that I own). The nanoQX is an example of a RTF quad that supports both rate mode (SAFE agility mode) and angle mode (SAFE stability mode).

mwm wrote: FWIW, I've been contemplating a desktop config editor that would let you do this kind of thing. You'd give it a config file that listed your favorite mapping from functions to switches, and could then pick a protocol and set of functions, and it would write out a model config file.

That's an interesting idea. I can also think of many interesting opportunities that present themselves with a desktop config application...

• Model managment
• Graphical curve editor
• Configuration comments... maybe?....
• etc...

To see a desktop config system that's been in development for a few years, take a look at the OpenTx companion app. Emulator, configuration editor including graphical curve editing, model management, etc.

I think the most useful thing would be template system, to make it easy to set up oddball fixed wing things. Then again, that's also something I have no experience with, so maybe it isn't nearly as hard as I think.