Why use a full channel to transmit a switch

Why all protocols use a channel to transmit just a binary setting 0-1 for a switch?

It seems very much taking unused bandwith? We could send much more switches setting just transfering switch id and a on off bit?
Or we could have more range use lower bandwith?we could send a 1000 swiches on bandwith of one channel?

For analog POT's the could be sampled at amuch lower rate. Doing this can have lower band with so longer range?

RC radios might be very different if designed today by folks without knowledge of past radios.

Lots of left-over (pre-computer) ideas keeping odd structures alive today.

Not all models/protocols use a channel to send a single bit. Most modern flight controllers use s channel for "flight mode", which is liable to include some small set of flight modes, a " panic" mode, and a return to home mode, among others.

Some of the "toy" protocols also use "unused" bits in an analog channel value instead of a dedicated channel. That's hard to do with the deviation mixer, as the values get scaled and tweaked as part of the mixing process, so the protocol implementation checks a channel value to control that bit as part of building building the output packet.

So yeah, you could send ~1000 binary values in a single channel, assuming you have something on the other end to interpret them.

By the same token, you could wonder why we only have 12 (or 16, or 32) channels. Instead of sending a packet that's a fixed size array of channel values whose number if determined by position, why not send a variable-sized list of channel number, value pairs? That way you could have hundreds or thousands of channels. But you have the same problem - you need something on the Rx end to interpret the numbers.

Well, 16 if each bit is for an individual switch, but if you had the smarts at the other end 16bit can account for 65,536 different combos?

mwm wrote: something on the other end to interpret them

And therein lies the nub

The thing on the "other" end isn't nearly as much of a problem as the interface on the Tx. You can get servo controllers with a serial bus interface and potentially hundreds or even thousands of addressable servos attached to a single microcontroller. Weight or power might be a problem for small aircraft, but not for larger ones, and the Age-of-Sail ships I wad looking at usually need extra ballast to look scale, so even less so.

So given a craft with a couple of hundred functions you can control remotely, how do you pick one out on a Devo12? Even if you punt on the traditional Tx and go with a tablet, you're still liable to wind up with an unwieldy mess if you're not careful.

Yes that is excactely what I was thinking, if moreless transmitting serial data you could send an id for switch channel etc and a value, you could decided to send first channels at 100hz, some channels for pots etc at 25hz and fi switches on change. Wondering why there is not yet an open RX project or I mean open RC link format.......
I think that although we have nice digital link, we not use really irt's benefits, still based on old ppm style radio.

FDR wrote: I've already suggested to the guys to develop an open protocol, which every toy manufacturer could use, so we don't have to reverse engineer every protocol...
It could spread if you include useful libraries with that for each possible microcontroller family...

Different chipsets (nrfxxx, etc.) and the desire to constantly reduce costs by pennies may stand in the way.

A paradigm shift in the R/C control interface must be on the horizon. That would likely require revamping of the protocols.