Suggested changes, firmware part 2: channel names

While using channel numbers everywhere is obvious and makes things consistent, it also creates issues across the board. We need special code for the basic for channels in order to set up a default model and deal with templates. Proprietary protocols (well, dsm & devo) tend to use names in their tx config instructions, not numbers, so we have to figure out the map from one to the other in order to follow those instructions with deviation. The toy protocols use a variety of different channels for camera/trick/light control, which again has to be looked up when a model is configured.

So let's add a "names" array to the protocols. Instead of simply having a way to get the AETR/etc order, we have an array of pointers to channel names. Channel display code will have to look the name up instead of using whatever it does now with special handling for the first four or five and then just numbers.

The advantage of this is that we can skip looking things up in both cases: the channel names will match the instructions from the hobby vendors. The toy protocols will have the name of what's controlled - at least on the default model - in the channel. Since the controlling switch & source are also displayed if appropriate, it makes the advanced GUI mixer a bit more self-documenting.

We would have to rewrite the default configuration code to check for "magic" channel names - say defined in the protocol.h file. But we might be able to extend that as well. For instance, if a channel is named "GEAR" and the tx has a "GEAR" switch, we could have it assigned as the channel source, just like analog inputs. Not clear how useful that would actually be, but it's an interesting prospect.

We could either keep writing config files with numbers, or write out names and then check for either on input for backwards compatibility. We might also be able to make the protocols backwards compatible, so there's no need to change them all at once, and those protocols that use numbers (like FrSky) can just stay the same.

Is this probem also related to the trims issues I had, I couldnt get it right.
Then i found the list of trim switches, in the trims menu must be in the correct order or you have lots of issues getting it right, especially when have a flapperon mix.

I think it would be best if we can assign any stick or switch, to any Rx channel = nr we like.
If we can put a label, basically a txt field we can enter define any names our selves such as (throttle or rudder or whatever txt)

You can already assign any stick or switch to any channel number you want in the advanced gui.

The issue of changing channel names has come up a number of times. I've got no plans for such, since the names on hobby protocol channels come from the manufacturer and changing them is asking for problems.

I know what you're talking about, mwm. I (as a user only) already had issues finding the right channels or finding out which channel is doing what on what model. It would be great if there was a way of spelling out the names of the channels. e.g. flip channel, headless channel and so,on. But i see a small problem concerning all the toy protols: I already had the issue that 'flip channel' on the one model was led on/off channel for another one using the same protocol, too.

So how to handle things like that? Wouldn't it be possible to use some type of spreadsheet in a wiki-like behavior where everyone could put the infos together?

I think the model database and the manual are a good starting point, but many protocols work with more models than expected at first, so if anyone is playing around with his devo trying to bind a new toy quad for example, he or she could post the infos gotten from that in this wiki spreadsheet.

Just an idea...

I did mention that issue with toy protocols. Leaving them as is is about the only solution - and the protocol author can chose to do that by calling them "Channel6" or "AUX1" or whatever.

The whole protocols/models/etc issue is a nasty one. I know the solution, but we need someone (several someones, actually) to do the work of curating a proper models library. And it's ongoing work.

no naming, no protocol specific ordering please. just channel numbers will do and get rid of all the confusions while switching different protocols.

cmpang wrote: no naming, no protocol specific ordering please. just channel numbers will do and get rid of all the confusions while switching different protocols.

The issue of changing protocols is unrelated to this. That we mangle things when you change protocols to try and get them in the right place does indeed create problems if you aren't using them for what the name suggests. On the flip side, it makes life much easier when it works right. I'm not sold on either version, and would have no problems making it go away. If you're really interested in doing that, please open another thread discussing it so we can get wider participation.

The critical thing the names are used for is setting up an empty model. Without names there, the controls wouldn't wind up connected to the right defaults - so you probably have to change the order on every model. Without that, I think we'd be better off having empty models with all the mixes off, requiring you to set them up every time as a better option than having them be wrong more often than not. But the current situation - where at least for hobby-grade things they're mostly right - is better than either option.

So the question is whether or not we want to expose those names to the user. I claim the answer is yes, because some companies provide us with models that use named channels and not channel numbers. If you're trying to set up a model that uses DSM for instance, the instructions will say to set the Gear or AuxN channel to control various features on their aircraft. As things are now, this is great if they use a channel name that we already have (which basically means "Gear"), but if they give us another channel name, you have to figure out what the channel number is. That information is specific to the protocol and never changes, so it makes sense to make it available in the protocol file.

Some manufacturers do just use channel numbers. In that case, we should be able to flag the protocols for the flight controls but show the users the numbers instead of the names. Others don't have any such instructions at all. These are mostly the toys, as they spin up protocols on a per-model basis, recycle them at random and sometimes change the channel order between different spins of the protocol and change protocols without changing the model name/number. Since there's no documented order, the best we can do is a guess based on the model that it was reversed engineered from. I suspect there's no one right answer for all of them, and think that leaving it up to the protocol developer is again the right choice.

mwm wrote: The critical thing the names are used for is setting up an empty model. Without names there, the controls wouldn't wind up connected to the right defaults - so you probably have to change the order on every model. Without that, I think we'd be better off having empty models with all the mixes off, requiring you to set them up every time as a better option than having them be wrong more often than not. But the current situation - where at least for hobby-grade things they're mostly right - is better than either option.

We could move the names completely to the model file. An empty model would have all mixers off. New templates could be added for the "standard" manufacturer channel names and those can be used to initialize a new model. Or not if you just want to use numbers.

Not sure about the automatic remapping when you change protocols. It works well for the first four channels...if you use them according to the standard names.

These are mostly the toys, as they spin up protocols on a per-model basis, recycle them at random and sometimes change the channel order between different spins of the protocol and change protocols without changing the model name/number. Since there's no documented order, the best we can do is a guess based on the model that it was reversed engineered from. I suspect there's no one right answer for all of them, and think that leaving it up to the protocol developer is again the right choice.

The toy protocols channel order is completely arbitrary. There's a thread somewhere proposing a convention - I think most of them start AETR.