TX16S, EdgeTX 2.10.x, no RC Link using "External RF" JR Bay (external module) and PPM\SBUS

[packetkiller]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

Using TX16S with RFD TXMOD v2 in JR port to a RFD 900x v2 to a Matek H743-WING. TX16S running 2.10.2 or 2.10.4. Flight Controller running Ardupilot 4.5.4 (Plane). Radio receives telemetry from FC and telemetry is viewable in Mission Planner via Mavlink from TXMOD WiFi. Telemetry is NOT visible in TX16S. RC link is not transmitted from TX16S to TXMOD (and thus never shows up on air side). Validated radios on both sides TX/RX sending and recieving data using scope. RFD radios are using default settings except for NETID custom value that is set to same on both.

Expected Behavior

RC link sent to air side and then to FC. Telemetry from FC sent to TXMOD, then to TX16S, then discoverable in EdgeTX and live stream via telemetry LUA widget.

Steps To Reproduce

Upgrade working firmware and SD card contents of EdgeTX from 2.9.x to 2.10.x.

Version

2.10.4

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

No response

OS Version

No response

Anything else?

This issue seems to be a root cause for issue #5064 (telemetry only issue).

[pfeerick]

RC link is not transmitted from TX16S to TXMOD

This sounds somewhat fishy... shouldn't it be configured simply as PPM output? So if you have PPM output on the top pin of the module bay... you should at least have the control link, thus meaning that whatever the core issue is here, it appears that most of the reports in 5064 are common to the RFD TXMOD (v2 or modified v1), and changes around PPM/telemetry. Which would probably be that it defaults to No telemetry (as PPM doesn't have telemetry), and an option to allow MLink compatible telemetry... we probably need another option to add SPort telemetry...

[packetkiller]

Even with the TX16S EdgeTX "External RF" option configured with PPM, MLink Telemetry, Channel Range CH1 to CH16, PPM frame set to 38.5ms, 300us, and -, there is no RC link but there is telemetry coming back to the TXMOD and viewable via the TXMOD WiFi in Mission Planner, but not via the TX16S EdgeTX (no telemetry discoverable). Powerup sequence is model, then TX16S, then connect to TXMOD via laptop WiFi. Matek H743 UART4 used for RC, UART6 used for Telemetry. Maybe it a setting thing on the Ardupilot side? Given the above radio configuration, how would you suggest Ardupilot be configured?

[mha1]

TX16s External RF set to PPM/No Telemetry or PPM/MLink, CH1..CH16, 38.5ms, 300us. -. A perfect 16ch PPM stream at the JR Bay CPPM pin. You've gotta find your problem at the receiving end of the PPM stream.

[packetkiller]

TX16s External RF set to PPM/No Telemetry or PPM/MLink, CH1..CH16, 38.5ms, 300us. -. A perfect 16ch PPM stream at the JR Bay CPPM pin. You've gotta find your problem at the receiving end of the PPM stream.

I agree. I will check each leg of the radios starting at the TX16S and working my way to the FC. The first test at the TX16S JR bay on PPM pin shows good PPM signal coming out. When I move the sticks, I see the signal move. Will status each leg to show others how I troubleshoot this...maybe it will help someone else. Next checking the 900x side to see if it got the PPM signal.

[packetkiller]

So first leg across the radios shows no signal on pin 15 as expected. So, the radios are talking as I can configure both from the TXMOD. For this forum, this means that the TX16S is working and spitting out PPM to the radio, but the radio is not relaying that to the other side, or the other side is not picking it up. I will keep working this with RFD and report back when I have something to report.

[packetkiller]

Update, managed to get ppm across link by resetting both radios to default, then setting S16:GPI1_1R/CIN = 1 on the TXMOD radio. Though I had this setting in place before and it did not work. This time, I did not run the "Go to First Run Wizard!". I have confirmed that the wizard sets something that breaks a standard PPM passthrough link. I am now going to attempt to validate on a flight controller and not just the oscilloscope.

[packetkiller]

Update, am not able to get the flight controller to recognize the PPM signal. Going to try and move from PPM to SBUS and try again. RFDesign support has validated the PPM configuration. I have asked for config changes required to enable SBUS. Will see if this helps.

[packetkiller]

Update, have now narrowed the issue to the radio software. Once a pair of radios are linked and configured, using the TXMOD web interface to change the configuration seems to "get stuck". I have been able to use the USB interface to change the radio settings but even that can get stuck and take a few tries to make a single change. Once changed, the pair do not communicate, thus the issue. Will continue to work with RFD to sort it out.

[pfeerick]

Thank you for the updates, good to know making progress narrowing the culprit, whatever it may be

[packetkiller]

Finally figured it out. The main issue was related to the nature of how the radios save data to memory...meaning you must follow strict procedure for certain configuration changes. In short, when in doubt, just start back from all defaults and reconfigure fresh. It is a bit late here so will add another comment with the configuration details in the morning.

[mha1]

Good to know. I was certain you'd find the problem at the receiving end of the PPM stream. Don't forget to close this issue.

[packetkiller]

Since this is an EdgeTX forum, I will provide feedback that helps EdgeTX users as much as possible.

In my case, when using the following radios, the root cause is configuration getting stuck and configuration tools reporting old data. Ultimately, the fix is to revert to default settings using the RFDTools utility and reboot the devices multiple times to ensure the defaults and new settings stick. Another "gottcha" is when configuring the RFD devices using the RFDTools utility, watch where your wheel mouse is on the screen and be careful of using the scroll wheel. The scroll wheel will change the drop-down items without "popping" out the menu item. So, it is very easy to make a change and never realize it.

Another place to keep a look out is your browser used to configure the RFD radios. Ensure your pages are not cached, and ensure you start from the main TXMOD page (http://192.168.4.1) and not sub-pages. I hope RFD updates these pages with "back" options for better navigation. Seems like such a simple thing, but that would make page navigation much more manageable and also give a place in the web page code for ensuring the page data is refreshed...but what do I know...

Here is the hardware I was working with: RFD TXMOD v2 (RFD900X2) RFD 900x v2 (RFD900X2) Firmware: RFD SiK 3.57 on both EdgeTX 2.10.2 Radiomaster TX16S Matek H743-WING v3 Ardupilot 4.5.6 iNAV 7.1.2 Yes, I tested with both Ardupilot and iNAV to compare results. Results were the same. RFD Tools 3.0 (April 2024 version)

Here is my test procedure (follow each step and if mess up, default all radio settings and start at the beginning again), if you just want SBUS, skip procedure 2, if you want higher baud rates, do that after, add encryption as a last step:

Procedure 1 (Configure PPM Radio Settings):

1) Set TX16S PPM Settings in EdgeTX > Model Settings > External RF PPM, MLink CH1 to CH16 PPM Frame = 38.5, 300us, - 2) Turn off TX16S 3) Turn on TX16S with TXMOD in JR bay 4) Connect to TXMOD WiFi on default WiFi SSID 5) Open browser and go to http://192.168.4.1 6) Select the "General settings" button on the web page 7) Set TXMOD WiFi settings AP SSID = yourapssid AP Password = yourpasskey WiFi Channel = 6 <--- your desired WiFi channel Station SSID = yourstassid Station Password = yourpasskey 8) Select the "Save" button on the web page 9) Restart TX16S 10) Power on the remote 900x 11) Connect to TXMOD WiFi on new WiFi SSID 12) Open browser and go to http://192.168.4.1 13) Select the "Go to First Run Wizard!" button on the web page (can use any node id you want; I used 253) Next 253 > Next Disable encryption button > Next Yes, enable PPM passthru button > Next No, I am not using that feature button > Next Yes, I know this can crash my aircraft if I set it wrong button > Finish 14) Turn off TX16S and remote 900x 15) Turn on the TX16S 16) Power on the remote 900x 17) Should see non-inverted PPM on remote 900x pin 15

Procedure 2 (Configure PPM to SBUS Radio Settings):

1) Perform procedure 1 2) While connected to the TXMOD web interface, select the "RFD900x Radio Settings" button 3) Select the "Load fresh parameters" button 4) After receiving fresh parameters from both radios, change the S16, S17, S18, and S19 registers TXMOD 900x S16 1 0
S17 0 0 S18 0 0 S19 0 1 5) Select the "Save parameters" button 6) Restart both the TXMOD and 900x radios 7) Should see SBUS (non-inverted) on remote 900x pin 15

Procedure 3 (Configure SBUS Radio Settings):

1) Perform procedure 1 2) Set TX16S PPM Settings in EdgeTX > Model Settings > External RF SBUS CH1 to CH16 Refresh rate = 7.0ms, normal 3) Restart the TX16S 4) While connected to the TXMOD web interface, select the "RFD900x Radio Settings" button 5) Select the "Load fresh parameters" button 6) After receiving fresh parameters from both radios, change the S16, S17, S18, and S19 registers TXMOD 900x S16 0 0
S17 0 0 S18 1 0 S19 0 1 7) Should see SBUS (non-inverted) on remote 900x pin 15

I know someone will say, why not just go to SBUS on first config. I tried that and it did not work. I tried a second time and still did not work. Since I cannot say what happens inside the firmware, my guess is that you must "pair" the two radios first before making additional changes. I also believe that some change combinations will confuse the radios or the tools that reconfigure the radios and also cause the stuck config situation. In either case, follow the above procedure and you will always get to a working SBUS config, even if using the AT commands.

Of note, there is a nice feature of the radios that if you cannot get SBUS out of the TX16S for some reason, you can output PPM from the TX16S and then from the remote 900x output SBUS. It did test and it works very well. Another helpful hint to those working with non-commercial flight controllers, like the Matek H743-WING (I think this is a great FC by the way), the wireup I used:

RFD 900x Wireup: 900x Pin Function FC Pin Color

---

1 2 GND G Black 3 4 +5V 4v5 Red 5 6 7 RX (input) Tx4 Green <<<< S.Port 8 9 TX (output) Rx4 Orange, Dark Red <<<< S.Port 10 11 12 13 14 15 PPM/SBUS I/O Rx6 Yellow <<<< PPM/SBUS from TX16S/TXMOD to RFD900x pin 15 to FC

The Ardupilot Serial configs (based on the above wireup): UART SERIAL/U/Function

---

7 SERIAL1/UART7/MAVLink1/115200 <---- MAVLink1 1 SERIAL2/UART1/MSP/115200 <---- MSP 2 SERIAL3/UART2/GPS/230400 <---- GPS 3 SERIAL4/UART3/Rangefinder/115200 <---- Rangefinder 8 SERIAL5/UART8/None/57600 <---- None 4 SERIAL6/UART4/Mavlink2/57600 <---- MAVLink2 6 SERIAL7/UART6/None/57600 <---- Frsky SPort / RCIN (SBUS) 5 SERIAL8/OTG2/None/NA <---- None

To verify in Ardupilot what inbound protocol is being used: RC_PROTOCOLS,8 for SBUS only, or RC_PROTOCOLS,2 for PPM only, or RC_PROTOCOLS,1 to accept everything (the default) If you lose connectivity, just plug in the USB cable to the flight controller and set the RC_PROTOCOLS setting back.

The rest is flight controller (Ardupilot/iNAV) or RC channel setup, so I will stop here. I am certainly not the first to do this but hoping this helps others wanting to go this route.

[packetkiller]