[Docs] [Bug] Radio Control docs don't reflect new architecture

[hamishwillee]

Describe the bug

RC setup seems to be a bit confusing currently.

[!NOTE] Bunch of questions/confirmations here. If I can get confirmation, I can update the docs. @dagar > @dakejahl If you could answer the questions would be great. I think most of it should be "yes, that is correct"

I think the theory is that:

• right now rc_input is still present and enabled on all boards. This appears to have all protocols inbuild except GHST and should autodetect if you plug the receiver into the "Radio Control" port. Nothing has changed for users.
• in future rc_input is removed and protcol-specific modules are added instead (and will generally be present on all boards). What changes is that you would specifically enable the module you want on the port you want rather than the protocol being detected.

Is that right?

How closely do we meet that theory?

• Some boards do not appear to have the rc_input module, and in any case some people want to use GHST.
• The support of ELRS in the rc_input module is new information in the last four months. Is this the same as the support that used to be in the standalone module?
• Given that, there are a some parameters like RC_CRSF_TEL_EN that no longer have a clear use?

I think the TL;DR is that if you want to use RC you should:

• Check if rc_input is in firmware and the auto detect param is enabled. If it is, then you can pretty much assume the other modules will be disabled even if present. You can then just plug your RC into the Radio Control port.
• If that doesn't work, check the new RC modules are in firmware. Easily enough done by looking at their params in QGC, such as RC_SBUS_PRT_CFG
  • You'd enable the param you want on the port labeled "Radio Control" (presumably) and check the others are disabled, including the Rc input param.
• That should be enough to enable normal RC if you connect a receiver of the appropriate type to the "Radio Control" port.

Is that about right? There is a question below about how you map the Radio control port, since it doesn't appear for me in QGC.

MOre detailed context below - additional things like "what new protocol module supports ST24?", and "what do you need this telemetry parameter for then if things are enabled automatically?"

---

Is all this right. Please highlight bits that are wrong?

1. Historically we had a single module rc_input that was present in all board firmware, and which was started on boot to connect to whatever port is the "RC Input" or SBUS or whatever. You would attached RC to the physical input of choice and it would auto-detect your protocol. a. The board has PPM next to the PWM outputs, and often has separate DSM/SBUS/RSSI port. Does this mean we ran multiple instances of the module pointing to each connector? b. Is the physical RC ports compatible with all the protocols? (PPM, SBUS, DSM. SUMD, ST24, TBS Crossfire (CRSF))? c. All of these are strict "RC input" right? I.e. they are not telemetry too?

2. We also had Frsky Telemetry (Listed as communications driver) and CRSF listed as an RC protocol - but still doing telemetry only. a. My understanding is CRSF module works with TBS Crossfire radio system or ExpressLRS radio systems, and sends both telemetry and RC information. This is somehow different from "normal TBS crossfire CRSF" RC right? In what way? b. Previously we had to remove RC-in from firmware to add CRSF - this doesn't appear necessary.

3. We decided to split up the monolithic rc-input module into modules for separate protocols. This removes the complication of auto-detection, and makes it possible to produce smaller firmware (in theory).

   • The new modules are added to most boards by default using CONFIG_COMMON_RC=y.
   • The old rc_input driver is added to some boards using CONFIG_DRIVERS_RC_INPUT=y
   • Some have both keys.

4. The intent is that eventually when all boards have the new modules configured as desired the old rc_input will be removed from firmware everywhere, and eventually from the source tree.

5. Currently we have these modules:

   • crsf-rc - parses the CRSF RC uplink protocol and generates CRSF downlink telemetry data
   • dsm-rc - This module does Spektrum DSM RC input parsing.
   • ghst-rc - This module does Ghost (GHST) RC input parsing.
   • sbus-rc - This module does SBUS RC input parsing.

6. Which of those above are used for which RC protocols? I mean I can guess from names which do DSM, TBS Crossfire (CRSF), GHST. But which do PPM, SBUS, . SUMD, ST24?

7. These protocols are assigned to a port using the following parameters.

   • RC_SBUS_PRT_CFG - port for SBUS (default is 300 ("Radio Controller"), but may be overridden)
   • RC_CRSF_PRT_CFG - 0 (disabled)
   • RC_DSM_PRT_CFG - 0 (disabled)
   • RC_GHST_PRT_CFG - 0 (disabled)
   1. Do we need to do anything other than assign these to a port to get them to work? (other than disable anything assigned)?

8. What are these params for then? - RC_CRSF_TEL_EN - RC_GHST_TEL_EN

   I assume that Telemetry and RC enabling all move on the same port, but for some reason you might choose to sometimes just send RC. Why?

9. And what is this one for then?

   • TEL_BST_EN (INT32) Blacksheep telemetry Enable. If true, the FMU will try to connect to Blacksheep telemetry on start up (looks like duplicate of RC_CRSF_TEL_EN

10. I assume these are separate modules you can enable for different kinds of telemetry that is separate from the RC?

• TEL_FRSKY_CONFIG (INT32) Serial Configuration for FrSky Telemetry. Configure on which serial port to run FrSky Telemetry.
• TEL_HOTT_CONFIG (INT32) Serial Configuration for HoTT Telemetry.

11. Whats the difference between RC_PORT_CONFIG and RC_INPUT_PROTO - I think the later is a new version of the former - changed so that it can be removed more easily in future or for some similar reason

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/spm4651t-serial-connection-to-pixhawk-issues/45451/10

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-dev-call-may-14-2025-team-sync-and-community-q-a/45516/4

[hamishwillee]

• [ ] How is the 300: Radio Communication port mapped?
  • When I try using the feature on my v6x board, I don't get offered all ports, and in particular the 300: Radio Communication mapped to the port you should assign.
  • This also isn't something we map in the docs - https://docs.px4.io/main/en/flight_controller/cuav_pixhawk_v6x.html#serial-port-mapping . How can we work out what port it is to map from the board config?

@dagar ?

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-dev-call-may-21-2025-team-sync-and-community-q-a/45657/2

[hamishwillee]

Note, @julianoes explained part of why this is so hard. Apparently traditional RC is often handled through the FMU at all, but through the IO board. That means that (at least currently) when you plug in an RC you don't know if it is being handled by that IO board or by the modules.

You could decide to use some other serial port such as TELEM1 and the instructions above might make sense - and you would have to in order to get the protocols not supported by the IO such as GHST. Further, on a board without IO the above discussion makes sense, because the RC must be mapped to FMU.

So the bigger question is then "what is the longer term RC plan for boards with IO". Is there a plan? How can users know what their RC ports are mapped to?

[julianoes]

1.a. The board has PPM next to the PWM outputs, and often has separate DSM/SBUS/RSSI port. Does this mean we ran multiple instances of the module pointing to each connector?

No, either one module using more than one microcontroller pin (e.g. ARK 6X configuration (without IO)).

Or recently combined in one microcontroller pin (e.g. Kakute H7 Wing).

1.b. Is the physical RC ports compatible with all the protocols? (PPM, SBUS, DSM. SUMD, ST24, TBS Crossfire (CRSF))?

For FMU: all of them (see rc_input). For IO: PPM, SBUS, DSM, ST24 (see px4iofirmware)

1.c. All of these are strict "RC input" right? I.e. they are not telemetry too?

For FMU they might have telemetry, for IO it's just RC input as far as I know.

2. CSRF, FrSky Telemetry?

You tell me. I don't know the details.

3. This removes the complication of auto-detection, and makes it possible to produce smaller firmware (in theory).

That's correct and also the goal is to just get rid of all auto-detection magic and rather have a declarative setup instead. The focus is on one specific locked down config, rather than a do-it-all approach. It removes a lot of failure cases which auto-detection can mask. Without auto-detection you can specifically complain if a GPS or RC is missing because you know this (and exactly this) should be available rather than "meh I tried everything but couldn't detect anything".

The inconsistency in terms of what you see in default.px4board is just because of the FMU vs IO split, or just boards that aren't up to date.

4. The intent is that eventually when all boards have the new modules configured as desired the old rc_input will be removed from firmware everywhere, and eventually from the source tree.

For @dagar to confirm but it sounds about right.

6. But which do PPM, SBUS, . SUMD, ST24?

Your guess is as good as mine. I assume SBUS, SUMD, ST24 don't exist yet. And PPM does neither but that's because it needs a timer pin and not a serial pin, so it's not necessarily available on any serial port.

7.i. Do we need to do anything other than assign these to a port to get them to work?

I don't think so but you don't know until you try.

8. but for some reason you might choose to sometimes just send RC. Why?

I assume it goes back to the "we specify everything declaratively" paradigm.

9. Blacksheep telemetry Enable.

Looks like it starts bst. Some code from 2015, not sure.

11. Whats the difference between RC_PORT_CONFIG and RC_INPUT_PROTO

This confused me as well recently!

• RC_PORT_CONFIG chooses the serial port for rc_input.
• RC_INPUT_PROTO selects the protocol (e.g. SBUS).

Hope that helps. Just in terms of docs, is this more user documentation or developer documentation? The questions seem geared towards developer documentation but the parameters itself would be user facing. And I'm not sure it's worth documenting the developer docs too closely as it's obviously all in flux. I think it's worthwhile to highlevel document what the goal is and how it is changing but not necessarily each and every protocol and feature. At least for me, I would just look at the parameters and code and try it out directly as I would never expect docs documenting implementation to be in sync, no offense...

[hamishwillee]

Thanks @julianoes

1. The intended docs are user facing. The questions are developer facing, because without understanding how this works it is hard to understand what a user will see.
2. At the end of this we just say "do this as a user" to get RC to work. I don't know what we'd want for a developer - probably an overview of the architecture so they understand how they might add a new protocol.

I have a theory about how this can work, based on docs and my testing, and an "assumption".

You're supposed to enable an RC protocol by assigning the serial port it uses on the protocol's "enable parameter". For example, I can assign [RC_GHST_PRT_CFG(https://docs.px4.io/main/en/advanced_config/parameter_reference.html#RC_GHST_PRT_CFG) to point to the ports as shown (according to docs).

6: UART 6
101: TELEM 1
...
201: GPS 1
---
300: Radio Controller
301: Wifi Port
401: EXT2

When I tried this on real hardware, only a few ports were shown, and that did not include 300: Radio Controller.

My theory is ports are only assignable if they are on the FMU. So the absence of 300: Radio Controller indicates that the RC port on this particular board is done though the IO.

• Does that seem reasonable?

If it is true, then the user guide becomes easier.

1. Check if IO board has the RC port by checking any of the relevant params such as RC_PORT_CONFIG. If QGC does not offer 300: Radio Controller as a selection option the RC port is on the IO - otherwise it is on the FMU.
2. If RC port is on the IO
   • you use it for protocols [add list] plug and play - the protocol will be autodetected.
   • if you want to use another protocol you will have to use another port, which will be one of the ones offered when you try assign the RC parameters.
3. If the RC port is on the FMU you can assign it (or another port) to either the monolithic RC input or the RC-protocol-specific. It is likely something will already be enabled on the RC port so I'd provide some methodical instructions for checking.

OF course it all hinges on being able to know about the IO board. The parameter seems like it should be useful for this purpose, but we need to confirm.

[julianoes]

My theory is ports are only assignable if they are on the FMU. So the absence of 300: Radio Controller indicates that the RC port on this particular board is done though the IO.

I believe 300: Radio Controller is shown when this line is in the default.px4board. And - I think - if it is configured correctly that's the case.

That being said, it's for instance not correct for the Kakute H7-Wing that I just added recently because I wasn't aware of it.

If the RC port is on the FMU you can assign it (or another port) to either the monolithic RC input or the RC-protocol-specific.

I think so. The devil will be in the details but yes. At the end of the day it hinges on the board configs being done right.

[hamishwillee]

My theory is ports are only assignable if they are on the FMU. So the absence of 300: Radio Controller indicates that the RC port on this particular board is done though the IO.

I believe 300: Radio Controller is shown when this line is in the default.px4board. And - I think - if it is configured correctly that's the case.

@julianoes I think it might be a little more complicated. The CUAV Pixhawk v6x appears to use the default.px4board - or at least it downloads the same name firmware. However I am pretty sure this has an IO board and I am not offered Radio Controller as an option for selection when using main.

So I think it is "must have this assignment" AND no IO board.

Would it be that "/dev/ttyS5" doesn't map to anything on an FMU v6x board with an IO board so this isn't displayed?

Does Radio Controller get displayed for any board you have? It doesn't work for anything I have, which makes me worry that perhaps my QGC set or something else is wrong.

[hamishwillee]

I think I might be able to write this now. Though it is going to be messy and possibly inaccurate in the fine detail.

[julianoes]

I believe the reason why it's tricky with IO board is that there are these cases - as far as I'm aware:

• IO available, RC connected to IO (CubeBlack, CubeOrange, etc.)
• IO available, RC connected to both (not sure which ones have it that way, maybe Holybro/PX4 6X?)
• IO available, RC connected to FMU (CUAV 6X?)

That's why it's messy and I'm almost thinking we need to go through all boards and update their docs and also create some overview table.

If @dagar wants to weigh in and shed some light on it, that would of course help.

[hamishwillee]

@julianoes That's worse than I thought.

• IO available, RC connected to FMU (CUAV 6X?)

CUAV 6X does not show Radio Communication as an option. My assumption therefore is that this is the case of > * IO available, RC connected to IO

As in my last comment I suspect that the theory is that FMUv6x might be used in IO and mini versions, so you would get that option in the IO-less version.

• IO available, RC connected to both (not sure which ones have it that way, maybe Holybro/PX4 6X?)

Specifically, you don't have any control over what is running on the IO to turn off RC say, so wouldn't this always result in clashes? How could this work?

That's why it's messy and I'm almost thinking we need to go through all boards and update their docs and also create some overview table.

Yes.

Again though, knowing if you can check Radio Communication as an option in QGC to know if the RC is FMU connection would make this a lot easier.

Do we know any board that allows you to see this option? I have tried Cuav 6x, 7 nano, Pixhawk 4 mini. The later doesn't even have an IO board.

[hamishwillee]

Right now the instructions would have to be

• If you want to use one of the older protocols plug your receiver into the RC port. If QGC shows that RC is working then your RC is configured.
• If that doesn't work you can't use the RC port on your Pixhawk. Pick some other unused port and do X, Y, Z.

This sux so bad.

[julianoes]

I'd have to go through all the boards I have and do some research.