Based on what I’ve read here I know I’m not the only person struggling with the failsafes on the RFD900X. I think I have a work around.
My problem has been that when I set up the failsafe as per the RFD instructions the Pixhawk does not recognize the failsafe condition based on throttle failsafe. During testing (turning off the radio) I could get it to trigger an RTL mode so it was functional but not ideal.
I’m using:
TX16S (2.3.9) and Yaapu Telemetry
RFD TXModV2 and RFD900X (Both on 3.16)
Pixhawk Cube Orange (Arduplane 4.0.6)
Here’s my workaround:
1 - Turn on Extended Limits on the Model Setup page of the radio.
2 - On the Output page I set the throttle channel output min (CH3 in my case) to -110%.
3 - Plug the aircraft’s RFD900X into the computer using the FDTI cable and set up the fail safe as per the radio’s instructions. Using 3.16 on both radios I found the “set failsafe” button the GUI worked for me. I didn’t have to use the AT commands, but that should still work. Make sure you have your throttle stick at the bottom.
4 - After getting everything set, disconnect the radio from the computer and re-connect it to the Pixhawk.
5 - Reset the throttle channel minimum to -100% and disable Extended Limits.
6 - Since I’m still mid-build the pixhawk is on the bench. So I reconnected it to mission planner and verified the radio function. At -100% on the radio channel, Mission Planner is showing 986 on the corresponding channel. -110% was about 935 so I set the throttle failsafe value to 960.
When I turned off the radio (with pixhawk connected by USB to mission planner) the throttle channel now drops to the recorded value of~ 935 and now triggers throttle failsafe.
I have not flown this set up yet. I don’t know what monsters this idea may have unleashed so if someone sees some glaring issue please speak up before crunch some expensive gear. At first glance everything seems to be fine, and radio channel calibrations don’t seem to be affected. (throttle output still goes to normal min value of 1100)
I think if you’re always using a GCS then the GCS Failsafe may make this irrelevant. However, if you’re like me and occasionally fly without a GCS (Thank you Yaapu) then I think this may be more important.
Through playing with this I’ve noticed that when the radio powers up again my arming was resetting to low (disarm) because I had a “fancy” double switch safety set up through some logical switches. I’ve had to do some dancing around with OpenTX to get my radio channel to stay armed when the radio powered up after a shut down (but only when the switches are in a certain combination). That would be totally disappointing to recover from a fail safe from a radio failure, only to have the aircraft disarm in flight when you powered up again.
Long story short: When you’re testing this on the bench don’t forget to watch your arm status.
@Allister now that I’m mucking about with my TXmodV2 I’m considering doing this same extra-credit step. How has it been treating you? Any issues in the past year? Also–what advantages does this offer over the simpler RTL mode change that is the default way I set it up? I have my RC failsafe on the FC set up to simply RTL as it is, so would your more genuine failsafe setup offer any advantages? Also good note about the arm status, I don’t think I would have issues given my setup but it would really be disappointing as you mention.
To be honest it’s been a while since I’ve used this plane. Priorities were shifted. But as of the last few times I used it, there were no issues I remember.
The reason I did this method, rather than just the RTL, is I found in some conditions on the bench the RX/FC would not acknowledge the loss of signal and therefore would not trigger the RTL. I’m working from pretty dusty memory, but I think it was if there was a power failure to the RX or signal loss between the RX and FC (but I’m not 100% on that). By setting the throttle failsafe then I could reliably trigger the failsafe. Also by using this method the plane will actually use it’s failsafe systems. So if the RX signal goes back and forth you have the short and long failsafe timers, and once the RTL is triggered it will stay there, even if the signal is recovered until you regain control, preventing a cycling of modes if the signal is sketchy.
I like your term “extra credit”. This is probably a little over kill, and in reality simply using the RTL would probably be enough. I never had a loss of signal with RFD radios (once properly setup).But because my tinkering on the bench revealed a loophole, I felt this was worth the time for me. Other than the extra mucking about, I haven’t seen a reason to not do it.
I am struggling with rfd900 system as well .
The instructions provide one of the most horribly written paragraphs I’ve ever read .
“To record a failsafe PPM stream first connect the PPM generator to the ground station modem. Then power up the receiving modem. Connect the ground station modem using the FTDI cable. After the modems have established a link set the desired PPM failsafe stream using the generator and connect to the ground station modem. Then send the following command to set the failsafe on the receiver modem.”
WHAT is a PPM generator
HOW do they want me to connect said generator to ground station .
HOW am I supposed to connect FTDI cable to ground station if said PPM generator is already connected to it .
Isn’t the ground station the receiving modem ?
I cannot make any sense at all with this explanation .
Any input would be appreciated . They need to EXPLAIN what they are talking about to the users who obviously do not know !
A PPM gernator would usually be your RC transmitter
I’m assuming you have a TXMOD since that’s what this thread is about - get everything turned on and connected.
Probably the easiest way is if you can connect your flight controller and (by extension) your air-side RFD radio ( “receiver” ) to your computer via USB cable and use the RFD Tools. Connect and read settings to see if it’s all working OK. The “local” should be the air-side, and remote will be the TXMOD when doing it this way.
In my case I have a switch and channel set to RTL in the transmitter and in Arducopter settings.
Set your transmitter to the exact combination of channels you want in failsafe conditions, such as throttle to middle, RTL channel activated, maybe drop a payload if necessary, that sort of thing.
Now press the “Set PPM failsafe” button under the corresponding radio - the air-side in this case…
You should be able to test by turning off the transmitter and observing the MissionPlanner RC calbration screen to ensure channels do what you expect.
The alternative is change over to using SBUS if your transmitter supports sending SBUS to the module bay. SBUS gives way less jitter than PPM, and supports the “throttle below failsafe” and lost signal. This is handled much more automatically by Ardupilot and there’s no need to set special conditions, but do definitely test properly so you know what you are getting.
The wiring is the same, no need to change anything there, just set SBUS Out on the air side and SBUS in on the TXMOD side, unselect the RCin/RCout options.
Feel free to keep posting questions here if you are not having luck.
Setting channel specific failsafe positions works perfectly in PPM mode (FRSky X12 to rfd 868TXmod and rfd868 modem directly to Pixracer RC in Port) - is there a similar failsafe feature for SBUS mode if there is no SBUS RX involviert? Ardurover itself has no option to define channel specific failsafe positions which are mandatory to run a sub safely.
Theo
I’m struggling to set up SBUS failsafe positions on a Horus X12 with external TXmod V2 module on the TX and rfd868 modem plus pixracer on the RX side - specifically I need to define failsafe positions on 3 servo outputs - SBUS works ok - but rfd documentation for the txmod is limited on setting up PPM failsafe only. PPM failsafe works perfect. Any suggestions on how to set up SBUS failsafe positions without SBUS RX? Theo
For future reference, here is a link to a “How-To” for setting up the TXMOD for SBUS RC control, it should work OK for any RC Transmitter with OpenTX or EdgeTX.
Old post, but I found this method very helpful. I have a rover that uses the RFD900x and whenever I turn my transmitter off, the FC reads this as all of the PWM values dropping and, due to the delay used in PWM RC failsafe, the rover would spin it’s motors to the left for a split second. Almost broke a finger when the rover flung itself off a table due to this. On a fixed wing, you could probably observe this by looking at the roll/yaw surfaces when you turn your transmitter off and seeing if they move to one side.
Using just the RFD900X’s PPM failsafe doesn’t force the user to rearm if connection is lost and this could be unsafe in some instances. Using both failsafes together with this “hack” seems to be a very good solution. I’ll update if I find anymore advantages/disadvantages.
You should be able to set throttle channel and others where you want them via the transmitter, say to stop all motors, then hit the PPM Failsafe button in RFD tools.
That should make the receiving radio go to that pre-set state when it loses signal.
That’s one reason why SBUS is better - the failsafe doesnt depend on the throttle or some other channel going below some PWM value. Right away your flight controller would go to failsafe mode and ignore the other channel inputs.