RFD900x-TxMod for Taranis X9D and Horus X12S with Telemetry

yes i did only need TX pin off the rdf 900x to rx pin on the teensy
its just there for future projects if needed

the RDF900x does all the polling for mavlink

well anyone using the TXmod will know it will pulldown your TX battery quick
after an hour flying i had to recharge the TX bit hard the field
so i made this box an wireless relay box with frsky telemetry for my TXMOD unit for when i do long flights

so now i have a wireless like from my frsky Horus to the TX mod that i can mount it on a tripod


first i got the frsk R-XSR receiver will work up 10v but i will add DC to DC Buck Step-Down Voltage Regulator to 5V the TXMOD will do 18V so its ok on a 4S


R-XSR with Sbus and S-port remove the bind button add a button so i can bind other planes
185998_3

bind button and power switch and antenna for 2.4 link

tested works great




2 Likes

There is an ESP8266 on board and RFDesign publishes the source code for that module. I don’t know if there are any free pins on the ESP8266, but wouldn’t a more eloquent solution be modifying the ESP8266 source to output Frysky telemetry to a pin (using probably software serial)? Then one would just need to run one wire to pin 5 on the TXMOD.

Or if there isn’t enough space on the ESP8266, just echo out the MAVLINK messages to that pin. In this case one would need to create a Lua script for MAVLINK for the transmitter. Seems like a good upgrade that should be provided by RFDesign. I wonder why they didn’t think to do this.

1 Like

@yak-54
Can you share your .hex file of your teensy 3.2 please. Am stack with it as i dont know how to compile in arduino. Am trying to built a relay station also.

all the info and Hex are here

and here is the Hex
Mav2PT.zip (63.5 KB)

2 Likes

@yak-54
Thanks A Million man!!! It worked!!!

1 Like

Think Eric already has ESP 8266 Code underway.

yes he does have set it up

and the wifi to pc or laptop works well

Hi.

It seems that RFDesign has been aware of our interest for sport feature in TXMOD.

Versión V2 of TXMOD comes with integrated sport telemetry support as seen on TXMOD most updated manual (http://files.rfdesign.com.au/Files/documents/TXMOD%20User%20Manual%20v1.4.pdf.

Version V1 of TXMOD can be upgraded to get integrated sport telemetry support as seen on http://files.rfdesign.com.au/Files/documents/TXMOD%20-%20Adding%20S.PORT%20Support.pdf and flashed with, at least, firmware version 1.4. No need for aditional hardware.

Thanks.

1 Like

yes i was told that by RFD i have not tested it yet is it frsky pas-through or just Sport ?
i would hate to lose Yaapu script
ok i just got an reply its pass-through yes it supports Yaapu :wink:
will test it later on tonight see how it goes

I can report that it works fine after adding the wire from the S-port to IO pin 4 on ESP 8266

Hi All,

We have modified two of the TXMOD v1 units. They have been great to test with, but we have a few problems. The controller (a Horus X10) frequently announces “Telemetry Lost” followed immediately by “Telemetry Recovered”. It is as if there is a brief delay in s.port data of a fraction of a second and the Horus announces both the loss and recovery of the data. The other problem we noticed was there was no message to indicate the complete loss of signal of an aircraft. There is the indication for lost telemetry but this message happens several times per minute in the worst case and is not a reliable indicator.

Has anyone else experienced these issues?

Edit: The other issue we are experiencing is that no data is read by the Yaapu script until a ground station connects over the link. We have the SRx params set to non-zero but it does not seem to have an effect.

1 The only time i get hat issue is when the Receiver is to close to the radio
2 never had that one what version software is on the TXmod ?

Hi Colin,

We always see that issue with the standard frsky 2.4 link, but the problem we are seeing with the TXMOD seems to be independent of distance. We are on v3.16 for the radio modules and v1.41 for the TXMOD.

The more concerning issue right now is the lack of indication that the connection is lost. If you unplug an aircraft while using the txmod, the module will continue to send the most recent rssi to the horus through s.port.

is this in mission planner or openTX ?

i will test it later on today
may be an openTX issue

if i turn off the flight controller on my setup its not holding rssi but it fall back to 69 db and holds that not going back to zero in yaapo ?
is this config setting somewhere i have over looked
and open tx in the sensor page it holds the last value it receded last as well

Sorry for the late reply. I really appreciate the help. The warnings or lack there of are in Yaapu on openTX. I tried to record some of the issues on camera. There is a brief view of the testing setup in the second video. The original behavior I was seeing when unplugging the aircraft was the rssi would hold at the previous value indefinitely. Now, upon further investigation, I have found a few behaviors that can occur.

  1. On disconnect the RSSI decays to zero, then increases back to 69db, then displays “no telem” on the top right and has a subtle red border. This behavior would be good if it was consistent.
    https://drive.google.com/file/d/11kRNad4ikTW1w2stU_QRetcFHBcir4hY/view?usp=sharing

  2. On disconnect the RSSI decays to zero, then increases back to 69db where is stays indefinitely. OpenTX announces telemetry lost. OpenTX announces sensor lost if you have also discovered the emulated GPS sensor.
    https://drive.google.com/file/d/11XALBPMSHQpZYepJtbmAQ8wVIC2SZ7wj/view?usp=sharing

  3. On disconnect the RSSI holds at the last reported value. OpenTX announces telemetry lost. This is the original behavior. I don’t have this one on video right now. Seems to not want to occur anymore.

Additional Findings
The telemetry lost, telemetry recovered messages happen even if the aircraft is not powered. It might be an issue with the timing of s.port messages.
https://drive.google.com/file/d/11X_DdXm_VMQBJqTpX0fkVzGoBQiXhtm4/view?usp=sharing

The controller occasionally re-announces the flight mode.
https://drive.google.com/file/d/11aYJ874ill3kl0bab0JrkpL6KxBw1lyT/view?usp=sharing

Status messages are broken on occasion. This has happened on multiple txmod units and aircraft.
https://drive.google.com/file/d/11d5VmAte9LhTVB6Q_CcLUJUATuEzWh02/view?usp=sharing

I am going to attempt a work around for the issue of alerting the pilot to loss of connection. It seems that the simulated GPS sensor is always lost when the signal is lost. It also seems that as long as you have a GPS lock you will receive a GPS messages every 2-3 seconds. I am going to try to set an alarm in OpenTX to sound when the GPS sensor is lost for more than 2 seconds. I will test this workaround and report back.

i have ask Eric Stockenstrom - zs6buj this is the way the mavlink to passthrough works

Yeah, we installed a PR from hasil123 back in 2020-01-18 v2.51

  if(fr_rssi < 1){    // Patch from hasi123
    fr_rssi = 69;
  }

The purpose was to ensure connectivity to the Taranis et al, even when there was a problem with rssi. Before that we had

//#define RSSI_Override // Dummy RSSI - fixed at 70%

Further, I continue to send rssi even if we lose Mavlink telemetry. We did this because on some long-range radios telemetry would time out, rssi to Taranis would stop, and Taranis screen stops updating.

So it’s a bit of a mish mash and could benefit from a logic clean up.

Since then we increased the telemetry time-out to 10 seconds, so it’s probably ok to stop forwarding (the most recent) rssi on the downlink when the uplink is broken.

Also, maybe 69 is a bit odd, so I could make it say 70% when rssi == 0, but only if
(#defined RSSI_Override) is true.

so its to fix openTX issue not updating