Servers by jDrones

Radiomaster TX16S + RFD TXMod Sbus

Thank you very much! I’ll give that a try tomorrow. I need around 12 channels so your setup is perfect for me, didn’t realise PPM was capable of more than 8 but good to know otherwise!
Regarding failsafes, did you use the set ppm failsafe button? I’m thinking of setting it so all sticks are centred, arm switch is enabled and flight mode set to RTH

I know some have had issues with setting up the failsafe using the failsafe button, but it worked for me. I almost got caught out because I was connecting to my air radio by USB, and using the radio to link to the TXMOD unit. So that means the air radio looks on the screen as the “local” and the TXMOD is the “remote”. If you’re doing the same, then you set the failsafe on the “local” radio.

You can set the switches and sticks as you’ve described and it should work. But the problem is the pixhawk will not actually recognize there’s a radio failsafe. So it just thinks you’ve hit the RTL switch and called it a day. The RFD radios don’t actually send a fail signal to the Pixhawk. The only way the pixhawk would see an RC Failsafe is if the air radio were to fail. If the failure is on the TX16S/TXMOD side then your air unit will just send the failsafe configuration you’ve setup above. The end result is hopefully the same, that your drone comes back, but if you want the FC to recognize a failsafe condition then I posted a work around. The link is below. So far it’s held up to my ground testing, and nobody has piped up to say that X, Y, or Z is wrong and it’s a bad idea.

https://discuss.ardupilot.org/t/opentx-rfd900x-txmodv2-failsafe-workaround/63054/4

1 Like

Okay brilliant, thanks for all your help!

Hi, your set up works well for me, including the failsafe workaround you suggested. Tested on bench, so far so good. Thanks again for your help!

Great to hear! Glad to help.

If you do notice anything strange about the failsafe work around please share it.

1 Like

Hey @Yasiinm, @Allister, thank you for posting this, I will try the suggestion and inform on my results. I have the TXMod V2 and RFD900x combo, also on a TX16S and I’m also having trouble getting it to work correctly. I would like to set it up to have this where I can get the Yaapu telemetry working on the Tx and sending Mavlink to a GCS via wifi. Please let me know if you guys have pointers on the telemetry piece as well.

Thanks!

The Yaapu telemetry does work, but there are some errors with the warnings. In fact I’ve turned off all the audible warnings because I get these random “Telemetry Lost” or “Disarmed” messages. They clear up and they are very obviously false warnings, but It just gets my heart rate up when I don’t need it.

I’ve found the wifi connection for the GCS is solid, once you get it connected. I have altered my start sequence to get everything going and it’s works very reliably:

  1. Power up the airplane
  2. Power up the TX16S(TXModV2)
  3. Connect the laptop to the wifi (if it isn’t auto connected already)
  4. Open up Mission Planner.

I don’t wait long between the steps. In fact I’ll power up the plane with the radio sitting right beside me and turn it on as soon as finished securing the battery. I only do it this way because of the Yaapu telemetry. If I have the radio on first then power the plane (the traditional way to power things up) then I find the Yaapu script has errors. Most annoying it’s displaying the wrong flight modes, the battery voltage is wrong. But I discovered if the airplane (probably more importantly the RDF900X) is powered before the TX16S, then all the scripts are correct.

Once the plane and the radio are connected then mission planner will start up just fine. MissionPlanner should automatically detect the wifi connection to the flight controller and start to download parameters. Again, if Mission planner is running before the connection is made, I found it quirky to connect.

The system has it’s quirks. But so far I’ve found it to be solid in flight. The wifi connection to the GCS has been one of the most reliable that I’ve used. The warnings that come up for on Yaapu are script errors and not real issues. It’s disappointing that I had to turn them off, but for the plane I’m using this with I’m usually right beside the laptop once it’s flying so it’s not a big deal.

I’ve also done some ground testing with UgCS and QGroundControl and those both work over this connection. I haven’t flown with them on this system but I wouldn’t expect any problems.

The “start craft before starting radio” routine is something I’ll have to try. I’ve noticed my yaapu telemetry has minor errors or data not displaying like battery capacity, this might just fix that. And I second the link to GCS being rock solid.

Did you have any issues with channel ranges? I found my ranges were weird and have had to tweak them in opentx quite a bit to get the end and midpoints correct.

There’s also a new fw version out for the txmod, I’ve not tried it yet but changelog indicated some change to rssi reporting which might help the intermittent telemetry lost warning.

I remember that the channel ranges were just crazy before I did all the firmware updates to 3.16. I could adjust everything to get it to work but the values were like nothing I was used to seeing. I can’t remember what they are now after the updates but I don’t think they’re anything too abnormal.

Thanks, I just looked: 3.20 is now out. I’ll be doing those updates first chance I get. Unfortunately where I live winter is setting in so our flying time is on hold for a while. Could be some time before I get to test it.

@Allister, @Yasiinm

Gents, I can report that with your kind suggestions I have been able to get RC Control, Mavlink telemetry, and Yappu scripts working on my TX16S correctly. Your inputs are much appreciated.

@Allister, The start sequence you outlined is still needed. I was also getting Yaapu script issues until I used your recommended sequence and the issues went away. They were the same ones, incorrect flight modes, and some incorrect values.

I did have to update firmware on both the TXMod V2 and the RFD 900x radio, both to the latest versions, below is how TXMod reports it. By the way, I have not seen Telemetry Lost messages, there is a note in the latest TXMod version that they increased RSSI reporting frequency to address this, and for the past 30 minutes I’ve had it working; I have not got those messages so far.

Software Version: 1.4.6
Build date: Nov 30 2020 10:57:11
Internal modem version: RFD SiK 3.16 on RFD900X
Remote modem version: RFD SiK 3.20 on RFD900X

I decided to go with these versions, even though they are not the same internal and remote RFD900x versions because of the release notes, which I’ll post below for completeness.

I’m going to make a separate post with my full setup showing FC and all pieces, both for my own reference in the future and so it can help others. I’ll post back a link to that thread once I have it done.

Here is the link to the thread with my full setup, thanks again!

Thanks again!

TX MOD Firmware Notes

The current version of the TX MOD firmware is 1.4.4
This firmware will update the internal modem to V3.15 or V3.16 depending on selected SPIFFS file and will require the paired modem to be updated to the same version.

Version History

30/11/20 - 1.4.6 Addresses issues relating to telemetry loss warnings by increasing RSSI report frequency
01/09/20 - 1.4.5 Bugfix: clears cached radio parameters once First Run Wizard is executed
28/08/20 - 1.4.4 Bugfixes and code refactoring: RSSI figure is now reported without an active WiFi connection
06/08/20 - 1.4.2 Added feature that initiates datastreams, without GCS connected to the WiFi, and some minor enhancements.
18/06/20 - 1.4.1 Bugfix: S.PORT also working while connected via TCP
25/05/20 - 1.4.0 Added MavLink to S.PORT support. The user is required to modify the hardware to get the feature working.
12/05/20 - 1.3.12 Bugfix: TXMOD no longer resets modems during bootup

And for the 900x:
RFD X V3.X series modems SiK firmware version release log

Version

  • 3.20

New

  • added analog read command atpr?=x
  • added Fsframeloss param to set frame timeout manually

Improved

  • turn sbus output off until first data
  • changed sbus rx delay for restart to 2.6mS and force clear of rx buffer before every SBUS rx DMA start
  • changed india max rate to 188 instead of 200 for compliance reasons

Fixed

  • fixed SBUS2 extra data
  • fixed SBUS ati11 command
  • fixed fix bug with jerky servo for Futaba SBUS
  • fix bug with large packets for ppm and aux serial
  • fixed bug with 868,842 and 933 setting max air rate when ati5? command issued
  • Fixed problem with Futaba ppm on 12 channels, PPm width goes down to 500uS on futaba instead of 1mS, extended range to allow these values through

Notes
The recommended firmware version.

1 Like

That sounds great! I’m glad that worked for you.

The Telemetry lost messages and disarmed/armed messages are issues with the Yaapu script, they aren’t radio issues. When I’ve verified the telemetry logs for my flights there has been no issue with telemetry and arm status. The RSSI is excellent at all times in my flights. The fault is very rare on the bench, and I only seem to get them in flight and not consistently enough for me to figure out a trigger.

The big take away, is once your aircraft is flying, don’t panic if you hear your RADIO say “DISARMED” from the radio.

The false warnings have never happened on the laptop with MissionPlanner.

I look forward to hearing about your testing with the new firmware!

1 Like

Hi both,
Just wanted to confirm that with the newest firmware (1.46 TXMod, 3.20 on vehicle radio), I haven’t received any random telemetry lost/motors disarmed messages during flight.

That’s good to know. Flying season is back here and I was just looking into those updates.

thank goodness I found this post. I freaked a bit when the yaapu script randomly told me my motors had armed. I just got my TXMOD V2 setup working, and I can confirm it has the same insanity issues with the audible script warnings.

Question that wasn’t completely obvious to me: when you use the suggested startup sequence, do you still get insane warnings coming through or are they completely resolved?

Also, if the RFdesign folks are listening, this behavior is definitely something to a) note prominently in the manual b) hopefully resolve… Aside from that, I was really impressed with the quality of the instruction manual and how easy it was to set up. I’m eager to see how it all works, hopefully without excessive anxiety from those warnings. There’s just no way for me to hear a random “motors disarmed” while flying and not freak out a bit. I really like the audible notices so I don’t want to have to turn them off, that would defeat some of the purpose of getting the telemetry.

thanks again, I’m really appreciative that you guys sorted this out and posted about it

Hi Matt,
What version of firmware are you running on the txmod/UAV side radio? I’ve not had the random warnings yet since I upgraded to the latest version (1.46 TXMod, 3.20 UAV side)

I assumed that it would be the latest since they arrived in the mail earlier this week, but I just took a look and discovered that ASSuming is not a good idea.

I have 1.4.5 on the TXMod and 3.16 on the radios. I’ll have to dig back into the manual and figure out how to update them properly, thanks for that heads up.

They’re easy enough to update, manual walks through it well. However, I’ve not had success updating the UAV side radio OTA the way it’s described in the manual, and have had to resort to using an ftdi cable to connect the UAV side radio to my laptop and use rfd tools to update that way. Just a heads up to verify the firmware did update on the UAV side radio if you’re following the txmod manual.

Ok I updated firmware, 1.4.6 on the TXMOD V2 and 3.20 on both of the modems. Definitely still getting the incorrect spastic audible alerts, even when using the recommended power-up order. What’s the consensus, are there any other troubleshooting steps or am I going to have to just live with this for now?

I’ve just flashed the 1.4.6/3.2 firmware. Between lockdowns and weather I can’t fly right now but I wasn’t getting any warnings in the shop. The only thing I noticed was the battery voltage on Yaapu would sometimes go to 0.0v, but come back right away. There was no issues on the battery display on MP.

I’ve also turned the TXpower down to 25 (~310mW if my math is right). Mostly just to reduce heat when I’m working on the bench, but honestly for most of the VLOS flights I’m doing right now it’s probably more than enough.

I’m still having constant issues, both with incorrect verbal warnings as well as incorrect telemetry appearing on the Yaapu screen. 1.4.6 on the TXMODV2 and 3.20 on both modems. What can I do here? Is this simply a product that doesn’t function as advertised? I’m a bit frustrated; the RFD900x have been solid, reliable products, and this TXMOD version is just about opposite that experience.

Servers by jDrones