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:
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 ?
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:
Telemetry port with at least Ground, TX and RX wires. CTS and RTS are optional but preferred (see the Serial wiring note below)
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
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.
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).
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).
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…
question regarding the choice of sbus output. I’m setting up my “receiver” radio using the RFD900 Tools software, and these are the choices of sbus output:
SBUS1
SBUS2_12CH
SBUS2_18CH
SBUS2/1
SBUS1_NOFAIL
can you (or anyone) shed some light on which of these to select? what’s the difference?
thanks
I want to see @xfacta 's reply, but I think you set S19 to 1 (SBUS1).
If I remember right SBUS2 has to do with telemetry over the SBUS protocol. But RFD has in their docs that their implementation is non-bidirectional. So it all seems a little pointless to me.
When I connect a remote radio via USB I can see this in RFD Tools → “SBUS1”
This worked with our failsafe tests too, so there was no need to do the “Set PPM Failsafe” procedure, but definitely test signal loss yourself to ensure the autopilot takes the expected action.
I am hoping someone can help provide some clarification re: completing this configuration to allow for RC and Telemetry: I can’t get RC(SBUS or PPM) to work .
My set up:
Tx Radio: RadioMaster TX16S
Telemetry Radio: RFD900x-US FCC bundle,TXMOD v2
FC: Matek H743-Slim
GCS: Windows 11/ Mission Planner
Arducopter:4.1.4
I have wired my Matek H743 Slim to the RFD900x-US using the guide in post #1 of this thread. Firmware on both RFD receiver and TXMOD v2 is 3.38. PIN 15 of RFD receiver is connected to RX6 of my H743. Baud rate is set at 57 on both modems. Yaapu telemetry works (though if OpenTX telemetry only discovers RSSI and GPS Coordinates).
Settings are as follows:
I have tried 4(Frsky SPort) and 23(RCIN) for SERIAL7_PROTOCOL, with 0 and 3 respectively for SERIAL7_OPTIONS - same results. SERIAL6 has the correct protocol (mavlink) and baudrate (57).
I saw this reference in the wiki, so flashed the non-bi-directional Dshot firmware version with the recommended settings for SERIAL7 - I still can’t get SBUS to work - no response from sticks.
Is GND and POWER on pin 1 and 3 on the RFD Modem correct (like shown on the image)?
The modem does not get power this way.
I have to put GND and POWER on pin 2 and 4.
Except for that everything telemetry and RC control is working as expected
I am literally going crazy with a TXMod V1 modified with the SPORT pin (RFD868X) and the corresponding RFD868X2 on a Cube Orange.
I can get both PPM and SBUS working (connected on the pin 15 of the module), telemetry in UDP works but Yaapu on the tx absolutely not.
Tried on TX16S and Horus X10S Express with the latest EdgeTX firmware.
I have experience with Yaapu which I have been using for years, I was one of the beta testers and helped the developer to improve some things, I normally use it with ELRS or FrSky receivers.
So I don’t think it is something I am forgetting, yet Yaapu does not work at all.
I had to downgrade the modules to version 3.54 because UDP did not work with 3.57 either, so I don’t consider these modules to be the top in terms of firmware, upgrading and having a deterioration in performance is not a good thing.
If TXMod receives the “mavlink 2” telemetry stream, shouldn’t it automatically divert it to the relevant pin connected to the tx to make SPort work, or is it only done using the RC output PIN 15 of the drone module connected to another serial configured in FrSky Sport mode?
What could it be?
