RX multiprotocol

hi guys
atm , modul RF 3in1 and 4in1 availeble, and we have a TX multiprotocl
So ,anyone have idea about RX multiprotocol ?

good idea.

The problem is the processing power it would take in a small package. In a tx we can have multiple processors offloading some of the work, we have a flash chip for storage and, perhaps most importantly we have a limited need for analog ports (the sticks and pots, the buttons and switches are digital in's). On the rx side you have to tax the processor running 6 or 8 (or more) channel PWM outputs taking up all the timers the proc has and running it near its capacity.

We could circumvent this by only dealing with a serial protocol output but which one? S.BUS I imagine would be best but a quick Google search for "S.BUS processing power" brings up, almost exclusively, projects again requiring a second MCU to offload actually assembling the final output from the main control PROC so it can handle talking to the RX / TX and the second embedded PROC only has to handle building the output.


Not to mention price, each of these different RF chips costs about the same so a RX with 3 to 4 RF IC's and multiple processors is, by design going to cost 3 - 4 times more than a single, dedicated protocol RX.

This is the reason we have devo, to be able to interface with multiple receivers from the same tx, not the other way around.

What's the benefit of that?

I think at some pojnt it might be more of interest to design an super "deviation" over the air protocol. But than f.i. must flash the receiver.
If we could use cheap receiver such as Flysky, it could be of interest?

I agree - why do you want a multi-protocol Rx? In particular, what do you want to do with it that couldn't be done with multiple Rx's on the same craft? The only thing I can see is wanting to be able to switch Tx's without having to rebind, but that needs keeping multiple bind ids, not multiple protocols. Once you have that, being able to bind to tx's with different protocols is possible, but it's not clear it's interesting.

At some point, we'll almost certainly have some "deviation" protocols. I've been poking at them, and a few other people have as well. There are already some DIY Rx's around, but the ones I know of use standard protocols so they can work with proprietary Tx's. My instinct is to go with the NRF24L01+ or one of it's clones, since those are cheap and easy to interface to. There are also some IoE devices showing up that include an MCU and RF module in a single package, if not on a single die. Those might even be more interesting, but most of them are targeted at networking protocols, not DIY protocols. For my uses, there's no disadvantage to having separate MCU & RF modules, so I'm not investigating them.

FI, The flysky Rx such as IA6B, they are about 10bucks only, diversity circuitry, good range do have pins for telemetry and they do contain an ARM CPU. See picture
www.rcgroups.com/forums/attachmentNew.php?attachmentid=8010553

Could be contender for alternative firmware, but than someone to write protocol for Tx and Rx and to be superior to excisting solutions, not sure if it of interest and what to be improved?
For future ideas maybe option switch to transparant modem mode could be of interest? F.I possibility configure settings of ESC, Flight controller, or upload new firmware from your Tx to esc flight controller etc

At $10, the flysky Rx's are more expensive than an nrf24l01 and a separate arduino mini, micro or an STM32 board. Probably not as good - no diversity, the really inexpensive ones tend use a PCB antenna. Buy the flysky would only be considered of we can reflash them and get the internal hardware connections.