A deviationTx protocol?

We've had a number of discussions about developing custom protocols at one point or another, but I don't know that anyone has actually done it. But a recent discussion brought to mind another advantage of doing that which I hadn't thought of before.

An open source protocol that ran on the NRF24L01 might well be attractive to the various toy manufacturers that are licensing/rolling their own, even if we GPL it. If so, then we wouldn't be in the position of reverse engineering protocol tweaks every few model iterations, especially if we GPL it.

The question is - can we create a protocol that will use as few resources as the toy protocols while providing similar flexibility, but at the same time be as solid and reliable as the hobby-grade protocols (DSM & FrSky in particular) with the flexibility that THEY need? It would need to be extensible, so that low resource implementations don't have to implement all the features, just have a way to indicate which features they do implement.

Am I just being naive to think the toy manufacturers might adopt such a thing rather than licensing something else? If not, then I don't think there's a group more capable of doing that in the RC world than this one. Anyone else interested in working on such a thing?

"Maybe" they will not want to use a free protocol , because that mean most of users need only BNF , that will reduce toy makers profit , only few people will buy RTF modle .

Yeah, I doubt the manufacturers would be interested. I recall only one case a manufacturer communicated with hobby group about technical matter, and it was only because of one enlightened person. When the person left the company every such communication ended.

And crappy plastic TX for RTF must be a profit center for them, why kill it?

Also, I'm afraid that without review board or licensing (which we just don't have resources to provide) they will twist your beautiful and well designed protocol to adapt to some pressing needs in a contrived and incompatible manner. Witness how many small variants of already existing protocols are there.

Another approach , can we develop DIY receiver with deviation protocol at same time, just like Frsky F801/F802 receiver , maybe some China company / TaoBao seller will try to produce it (Air-Wolf ?) , it's a chance to get it work, if it can support ppm/s.bus/telemetry it would be much better for some FPV quad. flyer .

Yeah, having an Rx implementation - or several, at different capability levels - is certainly part of the plan. We'd need that to test the Tx side, and to have something to work with. It's also probably the only way we'll get a rock solid protocol of any kind.

As for the RTF/BNF issue - I can't see how this would matter. Most of the toy quads are only available in an RTF version , so using a standard protocol won't impact sales of the RTF version. Some of the more popular models do have a BNF version, and they almost certainly know what's going on. The second biggest impact is liable to be on sale of replacement transmitters - assuming those are available at all. The biggest impact could be no longer having to pay license fees to whoever they got the protocol from, assuming they didn't develop it internally.

As for twisting the protocol - that's the point of releasing it GPL, in spite of my own politics. The question is how many will simply violate copyright and not release the source? Even some hobbyists giving away binaries do that.

I think there has been a topic sometimes about that with ideas about ideal protocol.......

Some of my input was that the protocol should be flexible, modular so not fixed nr of channel but undefined. Possibly slots to fill in as we like?
Also switches not anymore to take full channel bandwith. just digital?
On latency would be maybe of interest to have low latency priority channels ch1-4, high speed, possible some more latency, less bandwith for channels and switches?
Some way for sending just small low speed data commands, f.i. change esc config, config pids, enable modes on flight controller digitally by command instead of channel switch?



Possibility to bind in a tranparant, modem mode, datalink, for short range no control, I could think of sending configuration, uploading firmwares wireless, downloading log data from the model.

There have been a number of topics on custom protocols for various reasons. A lot of what you mentioned has been discussed.

The toy companies introduces the idea of "narrow" channels that were only 1 bit wide, so this would need something like that to be attractive to them. They did it on top of standard hobby protocols by turning on high order bits in the standard analog channels. You see that in a lot of those protocols, though I think it started with the WLToys V9x9 quads. This has the undesirable side effect of rather nasty behavior should you use one of those on a craft that doesn't understand it. It broke my V915 . The idea I like best for this kind of thing is some kind of variable-width channel spec. So they have real channels, but instead of sending 12 bits of data, we might send 8 channels in 8 bits, etc.

Your list of "low speed" examples are mostly not Rx things, but Flight Controller/ESC/etc. things. As such, you need an on-craft protocol so those various bits of kit can talk to each other. The Rx needs to implement that, but it's not clear how it fits into a protocol. But it would need to be an extension.

One of the things that I keep coming back to is "extensions". In my mind, that's similar to the extension facility you find in a number of TCP protocols like SMTP, telnet, etc. When the connection starts, the two ends send each other a list of extensions they want to do, and then the other end sends back a reply indicating which of those requested it's willing to do. This really needs something like that, but simpler. Possibly a fixed-size bit mask indicating features you want. You and that with the mask from the other end, and the result is the set of features you can actually use. If we support binding (and that might well be the first extension), you'd save that result along with the other end's ID.