I´d like to use a 433 system while having a 2.4 receiver onboard for backup, in case the 433 fails. I could connect the 433 to RcIn and the 2.4 to SPKT/DSM, although that would probably not work, I suppose. Any other ideas ? How would the Pixhawk react if both were connected ? What is the “primary” input ?
Redundancy questions are pretty common here, and I am used to answer by few questions:
- Why would make the 433Mhz fail ?
- How to detect when the radio link is down ?
- How to detect the backup link is good ?
- By design, a switching mecanism will add a single point of failure,so the design must offer a better failure rate than the FC and associated peripherals (Radio Link in this case).
Thx for the quick reply ! Didn´t find anything that fitted my question…
- Why would make the 433Mhz fail ?
It is an EZUHF connected to a Graupner System. You have connectors for PPM and battery. I imagine a faulty connector or someone accidentally ripping the cable out. I know, not very likely but on a expensive plane with countless hours of work in it I really much appreciate redundancy. And I have the 2.4 right in my hands
-How to detect when the radio link is down ?
If the 433 Tx goes down due to whatever reason, the Rx can just stop sending a PPM signal. That should be detectable…?
- How to detect the backup link is good ?
PPM available. In my scenario at first it would be dead anyway because I´d run 433 only (2.4 system is shut off by default when connecting the ezuhf). The plane would go RTL while I power up the 2.4 system which then connects to the receiver as soon as it is within range
- By design, a switching mecanism will add a single point of failure,so the design must offer a better failure rate than the FC and associated peripherals (Radio Link in this case).
That´s what I thought, too. I was considering using an arduino to pass through PPM433 and when it is lost, switch over to PPM2.4. But if that chip failed, the plane would be lost, too. So I was wondering if this could be solved onboard the Pixhawk. It does have two inputs (SPKT/DSM and RcIN). If there is no hardware aspect that would prevent it, it should be possible to do this “onboard”, even select a primary and a backup input.
I found this, but it´s for the old APM:
https://www.rcgroups.com/forums/showthread.php?2469187-Redundant-Receivers-in-the-future-for-APM
I think the main aspect here is if I´m holding to TXes on different frequencies in my hand, why not use that for redundancy ?
For the Radio Link, we would need a method add some ‘‘intelligence’’ in the transmitted message.
For example, sending a timer message with incremental millisec, could be used by the Flight Controller for validation by comparing received millisec with internal timer (with some relaxation for clock drift). That would only work for the RF chain, because you could have a failure of joystick or encoding 
Concerning the FailSafe, IMHO it is still the best method, providing it has been configured properly and tested
@docromano
Just as curiousity, considering the Arduino single point of failure is not problematic, You could use this library with a Tennsy
https://forum.pjrc.com/threads/25890-New-Pulse-Position-Modulation-(PPM)-Library
Features:
Single instance to support all in/out PPM streams
Read/Write up to 12 simultaneous input/output PPM streams, each up to 16 channels apiece.
Basically the Tennsy would read 2 PPM stream simultaneously and select InPut Channel based on RSSI or Channel 3 (that can be configured as ‘‘sub’’ 950 microseconds if signal lost) , or any other detection method. Then the selected RC link would be fed to FC using a third PPM channel used for output stream.
You already have a failsafe in Ardupilot for transmitter going away. Causing an RTL. Why would it be hard to implement a "primary’ rcin and a secondary RCin. So you set primary to RCIn for an s.bus receiver and secondary to Spektrum. You get an RTL due to failure of the primary so you first check for a stream on the secondary and use that if available else RTL per parameter settings.
Yes, the same way it detects a transmitter failure. The incoming PWM values drop to failure value set during failsafe cal.
I do think your original question is valid tho, how often does a receiver/transmitter fail as opposed to flying out of range causing the failure?
But for a mission critical commercial application it is valid.
Looking at code, it might be possible to add this logic within advanced Failsafe, but as I wrote before, better make sure you switch to a working channel, other wise you still loose precious seconds to a safer RTL or LAND…
You would have all the same problems as switching to stabilize after and RTL from Loiter, for instance, where the fc changed the throttle level and once you swtich back to stabilze the sticks are in a different position. Your backup transmitter is going to do the same thing.
Unless you throw it into Loiter and park it while it is switching to the new transmitter.
Guys, that sounds really great but you lost me way up because I don´t know a thing about programming. If this could be solved within the code, it would be a really great thing though !
Just to clarify the situation I´m thinking about…:
The “backup” is only thought to be as an emergency to be able to land the plane. Therefore switching time between inputs wouldnt be a big deal. I think that the loss of main control is a big enough failure to engage RTL immediately, not matter the status of backup input. When the plane reaches home, I could check telemetry, check if I´m able to reactivate main control. If not, I fire up the 2.4 Tx, take control and land it.
Of course, there is AUTOLAND, but in many areas it is not an option, especially with a bigger plane.
@docromano the failsafe is already programmed that way, I know its nerve racking but you must test it regularly to ensure it works and to get the feel of it.
So the test is basically takoff , go in loiter and turn the transmitter off, the plane should go in the programmed mode like RTL and then you can turn the Transmitter on == Bear in mind what Mike wrote == make shure that the radio switches are in a proper mode and that throttle is high enough.
Addition note: Most radio have a throttle warning if its not minimal at power on == On a plane it might be a good safety, on a quadcopter its a disaster because it make the bird fall out of the sky , its allways disabled on my xmitters
Well, my failsafe works great, tested many times. Depending on the Rx I use throttle failsafe or “PPM lost” failsafe.
I´m not quite sure if I understand - so I can connect both, SPKT and RcIn and see what happens if RcIn gets no more input ?
OK
There is no radio redundancy nor automatic switchover implemented at the moment,
I briefly explored 2 avenues , Teensy and Advanced Failsafe but these require writing code.
I realize this is a very old thread…but I just implemented a setup with two different receivers.
I have an RFD900X that streams PPM to the plane. I’ve also added an FRSky XSR set up for PPM.
I programmed an Arduino Nano that watches the RFD900X PPM stream.
- The Nano looks to see that there is a valid PPM stream.
- The Nano checks channel 3 to make sure the throttle is not in failsafe
- The Nano check channel 12 to see that there is a heartbeat from the RC transmitter (any hardware problem or a switch on the TX will kill the heartbeat)
If any of the above conditions go false, the Nano switches to the XSR. If all is good (and the TX switch is set to the RFD900), the RFD900 is selected.
The RFD900X is set for 12 channel PPM and is connected to the ground-side RFD900 with a trainer cord. The XSR can only do 8. The PixHawk doesn’t seem to care that the quantity of channels is different when there’s a change…channels 9 thru 12 just drop out when the XSR is selected.
I use a NOR gate connected to the Nano output for the actual channel swap. Even if the Arduino goes wrong (dies, locks up, etc.) the NOR gate should still be connecting one of the two PPM streams.
Much of my motivation is to minimize the odds of seeing my plane circling in RTL or running Auto with the realization that my RC control path is dead. With this approach, the only single point of failure for RC control is the NOR gate in the plane and the FRSky X9D transmitter. And…even if the TX fails…I might be able to borrow another transmitter at the field, program one channel for mode (AETR are fairly standard), plug it into my GCS and land.
Bottom line is that you can achieve some level of redundancy…but it’s not super easy.
Hi
i have two rfd900a with firmware 1.13 rfd900a.
can i transmitter ppm channels?
chechbox GPI1-1R/CIN and GPO1-1R/COUT is not active.
thanks
Only the RFD900x does PPM.
RR
can i send SBUS?
with gpio digital i/o
I don’t recall seeing any specifications on the data rate that a GPIO pin can support. But, it seems very unlikely that a GPIO pin would be capable of running fast enough to support SBus.
PPM works well. I’m doing 12 channels over the RFD900x with it.
There is a RFD900 thread on DIY Drones that would probably be more suitable for these questions. RFD monitors and responds on that one.
RR