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?
This thread has been great to get up and running - thank you! I have some comments that might help others and a call for help (point 4) before I tear out the rest of my hair!
The TXMOD2 setup wizard will not work with RFD900x with regional limitations (e.g. AU) as the default settings it attempts to apply aren’t accepted by the radio. This has been confirmed via email by RFDesign.
Some of the regional constraints are strange (e.g. air speeds of 64 and 224 are acceptable, but the intermediate 200 is not accepted by the 900x-AU). RFDesign told me “the behaviour of the radio at certain rates causing extra noise or emissions that are non-compliant”. The acceptable values have not been documented and need to be determined by trial and error.
I have gotten to the point where I can get telemetry over wifi/UDP (and control the drone via ppm), but telemetry on my TX16S is not working (I can’t discover new sensors and Yaapu shows “no telemetry data”). This is my first time using this sort of system, so it is quite possible I have left out an obvious setting, but I am also starting to wonder if there might be a hardware fault. Any help would be greatly appreciated. For reference my current settings are below, I’m particularly concerned whether there are any radio settings I have missed (there didn’t seem to be many relevant ones).
Many thanks!
Radio Setup (tried EdgeTx 2.9.0, 2.9.4 and 2.10.0):
Starting from the blank setup I have:
Set External RF to “PPM” “Mlink” (CH1,CH8, 22.5ms 300us)
Left Internal RF as “Off”
Added Yaapu widget to the telemetry screen
TXMOD: (software version 2.1.1, RFD SiK 3.57 on RFD900X2)
S.PORT enabled (the module is V2.0)
Baudrate 57600
Radio parameters to match the defaults in the RFD 900x-AU (serial speed 57, air speed 64, mavlink 1, GPO1_R/CIN 1 on TXMod and GPO1_R/COUT 1 on the 900x-AU
Remote radio: RFD SiK 3.57 on RFD900X2-AU
Power from own BEC
Arducopter (Orange Cube+):
Serial 1: 57600, MavLink2
Serial 2: 57600, MavLink2
I have also tried increasing the baud rate to 115200 as per the previous post (in the radio, arducopter and the TXMOD2 network settings), it still worked on UDP, but not for telemetry data on the Tx…
Hi Klaash,
I appreciate the info along with Xfacta and others.
I have the same 900x Au setup and same result, except no happy ending as yet. Even with firmware 2.7,2.8, 2.9 still no luck, RSSI and GPS telem only. My guess is that a tx16s setting or silly mistake with rfd900 mod setting.
Any ideas would be appreciated
I’ve finally got back to this project (so this is probably too late to help you, but others might find it of interest) and having used it a little bit more now its clear that my previous “works perfectly” was a bit of an overstatement. My current status is:
Telemetry to mission planner on the laptop seems to always work well.
Yappu behaves well if mission planner is not connected and the baud rate is 57600 or less.
With a higher baud rate or if mission planner is also connected the txmod seems to pass some spurious data onto Yappu (fake flight mode changes and the text log messages are intermingled). However mission planner still seems to connect robustly.
I can reduce the incidence of the spurious Yappu messages by reducing the amount (rate and message types) of data that Mission Planner is requesting from the FC. The five message groups you can easily adjust aren’t fine grained enough control to eliminate the issue and still obtain essential data.
I had a few suggestions from RFDesign and tried using the software versions (firmware for the TX16S, Yappu version) that they have in their test setup. But it seemed to make no difference.
My conclusion so far – it seems a robust system (and from all reports it should be very robust) for telemetry to mission planner on a laptop and RC control. But data through Yappu seems unreliable and can cause some false alarms…
Thanks again Klaash,
After my last post I have managed some success.
The link is rock solid with ranges of 7-8km tested and as mentioned by jimenezlee if i power up the ac first then the rc i find the link is flawless (no false alarms)
That said my issue that i have not been able to resolve is that i cannot connect udp wifi to MP or QGC.
UDP 14550-1-fixed wing / 115200 and Tx Mod linked to device or laptop by wifi.
Mission Planner just hangs on “getting param…” but does display the artificial horizon and telem data. Q Ground Control seems to link but then shuts down after a minute with a scrolling error " Error writing to QHostAddress(“192.168.4.1”)14555"
RFDesign have reported a few customers with this issue but no resolution as yet. I wonder if its not a simple fix with settings or i have noticed that when changing firmware on my tx16s sometimes some settings dont transfer well and need attention?
That said if you or anyone can see a fix or issue with attached settings please share your thoughts. It would make my day to be able to fix this.
I just tried mine now and I was able to connect MissionPlanner to the copter via TXMOD using its wifi password and IP with port 23.
Parameter load was slow, but after that MissionPlanner HUD seemed realtime enough and messages were OK.
Yaapu was issuing incorrect alerts, such as “motors armed” “motors disarmed” quite a lot, which could be quite disconcerting. This wasnt reflected in messages or the HUD.
My radios are all still configured as per my guide linked earlier in this thread.
EdgeTX has to be at version 2.9.4 or the latest version 2.10.6 - the inbetween versions wont work with the telemetry. There’s also an additional setting to check in the new version.
I’m yet to try that new version for myself, I’ll try to give it a go in the next few days.
I was able to connect an ordinary RFD900X to the groundstation via it’s FTDI cable while the TXMOD was also connected and both would work at once and Yaapu didnt complain at all.
If I can figure out anything about the Yaapu alerts and complaining I’ll let everyone know.
