RFD 868x, TXMOD v2, Pixhawk 4 - no RC channels

Hardware Radios
, ,
1

Hello,
I have a problem with my new RFD system. Everything works fine, the transmitter connects to the receiver, I also get telemetry. The problem is with RC channels that cannot be seen in Mission Planner and it doesn’t working. Below is my specification:

RFD900 Tools
RFD900 Tools1131×775 204 KB

RFD868x and a RFD868x-TXMOD v2 both running (firmware 3.38) and the ESP32 on the TXMOD is running version 1.46.

Pixhawk
Pixhawk3072×2048 464 KB

I have Pixhawk 4 flight controller running newest Arducopter connected via TELEM1 to the RFD868x. The RDF868x can’t provides SBUS data to the DSM/SBUS RC input of the autopilot. I did set the parameter RC_PROTOCOLS=8 to make 100% sure that it gets correctly decoded.

telemetry
telemetry1920×1920 592 KB

I’m using Jumper T18 running on OpenTX with Yaapu telemetry which works great. Also using SBUS to communicate with the RC transmitter.

Thanks!

2

I think you miss configured the SBUS output. The input looks fine but the output looks fishy.

I and some other users use similar versions and it works great:

1 Like
3

What does the radio settings look like via the TXMOD web interface?
Also try using the PPM RC port instead of the SBUS input port - there used to be issues with which one worked and which one didnt, not sure of that’s cleared up.

1 Like
4

Today I will try connect to PPM port in Pixhawk. These are my settings:

1
11209×1283 255 KB

5

I have also tried to connect RFD to another flight controller and RC channels still not working.

IMG20220207212028
IMG202202072120281920×2560 301 KB

6

That looks like you are using the correct pin, 15 P1.1
The only thing odd I see in the TXMOD Local/Remote screenshot (and in the RFD Modem Tools) is the number of channels. It may be region-locked to 1, but otherwise you would pick as high a number as the interface will allow, or 20.

I would try recreating the model in the Jumper T18 and see if that has any effect. Also check the channel view and see if the radio is putting out changing data on the channels. The OpenTX simulator even works for this - if it doesnt work in the simulator (no output on channels) then it wont work in the actual radio. I’ve experienced that and had to recreate the model.

Otherwise change to PPM as a test and see if that works.

1 Like
7

I once read somewhere, that the number of channels should not be set so high to avoid overlapping channels. This information might be out of date though.

If the telemetry works, sbus should also work. Change to PPM would be my next step of diagnosis too, after checking physical connections.

1 Like
8

I checked all connections and connectors twice. Telemetry works great, but channels are still not being read even after creating new model in OpenTX. Maybe it’s a question of the radio, maybe the transmitter or receiver is damaged. Also RC channels are disabled in PPM mode.

As for me, it’s time for a complaint.

9

The only other thing I can think of (apart from the RFD868 itself) is that we did all the radio firmware updates on the TX16S we use, and it’s also working with a Taranis on OpenTX.
I’ve used both PPM and SBUS on the Taranis, but went straight to SBUS on the TX16S.

1 Like
10

I have good news. Channels work after installing the latest EdgeTX. Thanks for your time!

1 Like
11

Thanks for sharing. I am having the same issue…SBUS/PPM not working. Perhaps this is an OpenTX “bug” on the TX16S? I am going to flash EdgeTX to see if it fixes the RC channels problem.
Ps: you are using PPM or SBUS?

12

Our TX16S is using OpenTX and it works OK. As I said I had done all the radio module firmware updates too, in case that makes any difference.

13

Thanks. Quite weird / inexplicable. I had Opentx 2.3.14, with both radio module firmware updated to 3.38, couldn’t get SBUS to work. After flashing EdgeTX (using the same settings) on the TX16S, it worked.

14

I meant the actual radio modules in the TX16S, not the RFD radios. But if EdgeTX fixes it that’s great.

15

Ok, got it. By the way, if you don’t mind sharing, what specific updates did you apply to the radio modules (in the TX16S)?

16

I just followed this when we got the radio

1 Like
17

I noticed that in SBUS mode, when the drone is armed, the motors are spinning and I turn off the radio, there is no failsafe. The receiver operated in such a way that it remembers the last positions of the sticks. The throttle value does not drop below that specified in Throttle failsafe. Do you have that too?

18

That usually happens when using PPM and you need to set a very specific failsafe combination of channels → the function of the Set PPM Failsafe button in RFDTools.
SBUS should respect the transmitters failsafe setting if you have it set to no output or no pulses. Check the setting in you TX.

The trick with the RFD radios is one can be set as SBUS and one can be set for PPM and they will convert between the two systems. You (usually) don’t want this.

1 Like
19

I noticed that in Mission Planner the default value of Throttle failsafe is 975, which caused popping up in FS_THR_VALUE telemetry messages, the drone could not arm. I started lowering this value and noticed that at around 960-965 the error was gone. I have the throttle calibrated in Radio Outputs on CH3:
Subtrim: 1.4
Min: -96.5
Max: 99.0
thanks to these values in Mission Planner I can see: max: 2000, min: 1000.
I tested the drone behavior (at home) in Loiter and AltHold modes with a reduced Throttle failsafe value to 960. After arming, I gave the maximum throttle and turned off the radio. The flight mode was automatically changed to RTL in Loiter mode and to Land in AltHold mode. The positions of all other stick deflections, eg rotated gimbal on the YAW axis, were not changed to their zero positions. It is also important that if you have a landing gear, it should work automatically from a given flight altitude.