- Posts: 69
RX multiprotocol
- john
- Topic Author
- Offline
Less
More
07 May 2016 00:37 #47931
by john
RX multiprotocol was created by john
hi guys
atm , modul RF 3in1 and 4in1 availeble, and we have a TX multiprotocl
So ,anyone have idea about RX multiprotocol ?
atm , modul RF 3in1 and 4in1 availeble, and we have a TX multiprotocl
So ,anyone have idea about RX multiprotocol ?
Please Log in or Create an account to join the conversation.
- shaker
- Offline
Less
More
08 May 2016 11:18 #48027
by shaker
Replied by shaker on topic RX multiprotocol
good idea.
Please Log in or Create an account to join the conversation.
- Cereal_Killer
- Offline
08 May 2016 15:47 - 08 May 2016 16:52 #48039
by Cereal_Killer
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Replied by Cereal_Killer on topic RX multiprotocol
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.
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.
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Last edit: 08 May 2016 16:52 by Cereal_Killer.
Please Log in or Create an account to join the conversation.
- Fernandez
- Offline
Less
More
- Posts: 983
08 May 2016 17:19 #48053
by Fernandez
Replied by Fernandez on topic RX multiprotocol
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 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?
Please Log in or Create an account to join the conversation.
- mwm
- Offline
08 May 2016 21:16 #48074
by mwm
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Replied by mwm on topic RX multiprotocol
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.
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.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
- Fernandez
- Offline
Less
More
- Posts: 983
09 May 2016 12:33 #48108
by Fernandez
Replied by Fernandez on topic RX multiprotocol
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
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
Please Log in or Create an account to join the conversation.
- mwm
- Offline
09 May 2016 18:30 #48129
by mwm
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Replied by mwm on topic RX multiprotocol
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.
Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.
My remotely piloted vehicle ("drone") is a yacht.
Please Log in or Create an account to join the conversation.
Time to create page: 0.035 seconds
- Home
- Forum
- Development
- Development
- RX multiprotocol