Combined RC and Telemetry on a single link (TXMod v2, RFD 900x, TX16S, GCS, Matek H743)

Hi all…

I’m really desperate :roll_eyes:

I’m new to this hobby and I’ve spent days trying to understand how should I connect and configure my system… made by a Radiomaster TX16s + RFD-TXMOD v2 on the GS, RFD868ux + Pixhawk4-mini on the vehicle.

RFD radios are working as expected… I see the green led on both and I can connect the TXMOD and R/W settings on both modules…

What I do not understand is how to setup TX16s w/ YAAPU script… I’ve followed the hints reported here regarding the S16, S17, S18, S19 registers but it does not work for me… I start thinking that maybe my wiring are wrong… especially between RFD868ux and the Pixhawk-4 mini.

At the moment, I have connected the 10pin JST cable that comes with RFD868ux to the Pixhawk-4 mini Telemetry1, PPM and MAIN-OUT8 ports:

PIXH2 to RFD900ux Telemetry cable

with this wiring, I was able to control the plane (fly-mode, servos, arm etc) using PPM on TX16s and with the following settings:

LOCAL RADIO REMOTE RADIO
S16=1 GPI1.1 RC-IN S16=0 GPI1.1 RC-IN
S17=0 GPI1.1 RC-OUT S17=1 GPI1.1 RC-OUT
S18=0 GPI1.1 S.BUS-IN S18=0 GPI1.1 S.BUS-IN
S19=0 GPI1.1 S.BUS-OUT S19=0 GPI1.1 S.BUS-OUT

…but YAAPU script was not working…

Then I’ve try to enable the S.PORT and to move from PPM to S.BUS but without success… as reported before, S.PORT is enabled on the TXMOD but when I select S.BUS on the TX16s it does not seems to work.
In one of this thread message there are some notes regarding SERIAL_6 and SERIAL_7… I suppose these are not applicable to my case as Pixhawk4 mini don’t have a SERIAL7…

NOTE that the Pixhawk4 RX-IN port is not used so far… do I need a special cable like this one ?

I’m also a little bit confused about the relations between PPM, S.PORT, S.BUS, F.PORT and Mavlink… shouldn’t the latter be enough to pilot the plane and to receive telemetry ?

Any hints will be really appreciated…

    thanks, 

             Giampaolo

You might be overthinking it all. Let us start from the beginning.

Let’s call the RFD radio on the aircraft a “receiver” for the purpose of this exercise.
Let’s assume you are using the Telem1 port on your flight controller, Serial1 in the ardupilot settings.

The RFD “receiver” only needs 2 connections to the flight controller:

  1. Telemetry port with at least Ground, TX and RX wires. CTS and RTS are optional but preferred (see the Serial wiring note below)
  2. Flight controller RC-in port, 1 wire from pin 4 of the “receiver” EDIT: the standard cable has a signal and ground wire

Mavlink 2 must be enabled for the telemetry port, set SERIAL1_PROTOCOL = 2

The “receiver” should be powered from an external 5vdc supply - usually the telemetry ports can not supply the peak bursts of current required.

In the RFD settings only use the SBUS options, deselect any RCin/RCout (S16/S17) options.
Set the TXMOD to SBUS in (S18), set the “receiver” to SBUS out (S19).

In your TX16S set the external module output to SBUS.
Follow the Yaapu telemetry instructions for adding the Widget in the Horus section of the wiki

The serial port TX/RX data wires “cross over” but CTS and RTS are “straight through”

  • RFD TX connects to Flight Controller RX
  • RFD RX connects to Flight Controller TX
  • RFD CTS connects to Flight Controller CTS
  • RFD RTS connects to Flight Controller RTS

That’s all old-school serial cable stuff. The supplied cable should be good, you may only need all this info if making your own cable or modifying a cable.

Unless I forgot something, all that should just work.
You should also confirm you can connect MissionPlanner to the TXMOD wifi network and get telemetry from the aircraft. This should work regardless of PPM, SBUS or yaapu script.

You dont need to worry about setting any serial ports to S-Port or F-Port on the flight controller or using any S-Port cables or adapters. I didn’t understand where or how the RFD receiver would connect to the MAIN-OUT8 port, and I think it most definitely should not.

If the yaapu widget still doesn’t work try creating a new model in the TX16S and just set up the minimum required items, SBUS and Yaapu widget, then worry about optional channels and switches later. If that works delete the old non-working model. I’ve experienced this before.
I’ve found the simulator in OpenTX Companion to be reliable → if channels are not working as expected in the sim then they wont in real life. If you get stuck with something odd like you can only get 12 channels, create a new model from scratch. It should work, then just copy over other settings you need within OpenTX Companion. Unfortunately the simulator wont show yaapu telemetry screens :frowning:

Then some optional settings for the RFD’s
You can increase Air and Baud rates quite significantly, they need to be matching on both ends:
Baud 115k
Air 200k
Max window 80
TXMOD wifi setting: 115k
Ardupilot setting: SERIAL1_BAUD,115
If you plan on staying within line of sight you can set TX Power = 27 in the RFD radios to operate at about half power and get a tiny bit extra battery life.
EDIT: reducing these RFD radios to half power is not going to turn it into a cheap junk radio with only 50m range, it will still be usable to further than you can effectively see your aircraft.

PPM and SBUS are basically two different ways of encoding the RC channel signals down one wire, SBUS is more modern and preferred, it will give your better quality RC control (less jitter) and failsafes just work without doing the “set PPM failsafe” dance.

S-Port and F-Port are two different FrSky “over-the-air” protocols for telemetry data between tranmitter and receiver, F-Port being newer and having more capabilities. Originally it started out as a way to add accessories to traditional RC models to give feedback, like vario, current nd voltage. In your case the TXMOD is handling converting the mavlink2 telemetry to F-Port for the TX16S/Yaapu widget to display data onscreen.

The “TXMOD Wifi setting” baud rate I refer to is this one, and you get to it by connecting a web browser to the TXMOD wifi, in the System Status panel select General Settings
The wifi baud rate must match the main baud rate for telemetry data transfer.
The S.PORT output enable will always be on unless you changed it, leave it on.

Hi Shawn,

first of all, thanks a lot for your support…

By following your hints I’ve been able to establish my first S.BUS connection between the TX16s and the Pixhawk4-mini… the main problem was in the wiring… the cable provided with the RFD bundle (TXMOD+RFD868us) is probably designed for a PPM-controlled system and not for S.BUS… that’s my fault.

In order to work with S.BUS I had to cut one of the cable provided with the Pixhawk4-mini (just to reuse the 5pole JST connector) and re-wire RC-IN pin2 (SBUS) to RFD pin 4 (GPIO1_ext) and RC-IN pin 5 (GND) to RFD pin 3 (GND).

RFD-Telemetry

Pixhawk4miniRCIN

Regarding the fact that I have a connection between the RFD receiver and the MAIN-OUT8 that’s just for powering the radio module… which, in turn, is provided by the 40A ESC that comes with the Sonic Modell AR Wing PRO…

I’ve also set the radio registers S16, S17, S18 and S19 as you point me as well as the air/serial speeds and tx-power reduction (in the picture S4 was still at 30 but I’ve changed it to 27 later).

Here are my settings:

I’m not sure regarding the S10 value (number of channels)… I’ve seen different values here and there and I have to investigate it.


At the moment the link seems not very reliable… sometimes an gimbal change takes up to 1s to reach the servo… I’m investigating this… could be a power-supply noise or something similar… but at least I have something… YAAPU script is working as well as Mission Planner…

thanks again

        Giampaolo

You dont need to change that number of channels, it should be defined in the radio firmware based on your region.

It’s good to hear you’ve had more success. Im not sure about the gimbal though, it might need another discussion of its own.

There is however a problem with mavproxy 1.8.46.

When I execute mavproxy.py --master=udp:0.0.0.0:14550 --console I get:

Connect udp:0.0.0.0:14550 source_system=255
Loaded module console
Log Directory: 
Telemetry log: mav.tlog
Waiting for heartbeat from 0.0.0.0:14550
MAV> Received 31 parameters
Saved 31 parameters to mav_0_240.parm

It only sees 32 parameters and it does not display any vehicle status.

param fetch hangs forever when I issued it

QGroundControl works fine on the same computer, connected to localhost:14550 as well

Has anyone found a solution for it?