RC PPM input not working on HolyBro Pixhawk 6X with IO off

[julianoes]

If I set SYS_USE_IO to 0 on a Pixhawk 6X, I no longer receive RC.

nsh> rc_input status
INFO  [rc_input] Max update rate: 250 Hz
INFO  [rc_input] UART device: /dev/ttyS5
INFO  [rc_input] UART RX bytes: 8
INFO  [rc_input] RC state: searching for signal: ST24
rc_input: cycle time: 6594 events, 41091us elapsed, 6.23us avg, min 4us max 967us 16.218us rms
rc_input: publish interval: 0 events, 0.00us avg, min 0us max 0us 0.000us rms
nsh> rc_input status
INFO  [rc_input] Max update rate: 250 Hz
INFO  [rc_input] UART device: /dev/ttyS5
INFO  [rc_input] UART RX bytes: 8
INFO  [rc_input] RC state: searching for signal: PPM
rc_input: cycle time: 6720 events, 41742us elapsed, 6.21us avg, min 4us max 967us 16.066us rms
rc_input: publish interval: 0 events, 0.00us avg, min 0us max 0us 0.000us rms
nsh> rc_input status
INFO  [rc_input] Max update rate: 250 Hz
INFO  [rc_input] UART device: /dev/ttyS5
INFO  [rc_input] UART RX bytes: 8
INFO  [rc_input] RC state: searching for signal: GHST
rc_input: cycle time: 7076 events, 44060us elapsed, 6.23us avg, min 4us max 967us 15.948us rms
rc_input: publish interval: 0 events, 0.00us avg, min 0us max 0us 0.000us rms

With SYS_USE_IO set to 1, the IO board correctly has RC:

px4io status
...
8 raw R/C inputs 1500 1502 1505 1506 992 991 992 1503
...

This is with an FrSky D4R-II receiver jumpered to output PPM.

I looked into this related to this question: https://discuss.px4.io/t/forwarding-rc-channels-through-i2c/31334/6

[AlexKlimaj]

Does your carrier not have an IO or are you just turning off using the IO?

[julianoes]

I'm just setting SYS_USE_IO to 0, so presumably it's still on.

[julianoes]

@davids5 any idea what I could try?

[AlexKlimaj]

https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-010%20Pixhawk%20Autopilot%20Bus%20Standard.pdf

Page 15.

So I would expect sbus/crsf input not to work when turning off the IO since the RC serial input goes to the IO when its present. On non IO carriers, it goes to UART6 on the FMU.

But PPM goes to the IO and FMU when there is an IO. On non-IO carriers it just goes to the FMU. I can report it also is not working on the ARKPAB carrier. @dagar, @davids5, and I went through the code a couple of weeks ago and found there is nothing in place to handle PPM directly on the FMU.

[davids5]

@julianoes First off NO IO mean the HW has no IO installed, U7 is de-poped, and the resistors (R58, 59) are configured correctly. As noted the PPM should work, regardless. But not duplicated. The HRT is accumulating the data. The configuration to use the data should be similar to a V4. I have not looked at it, but I would assume it is a build config issues.

[julianoes]

First off NO IO mean the HW has no IO installed

Sorry, I guess my title wasn't clear. It's not without IO but rather when the param is set not to use IO. So it's still there but not used.

I have not looked at it, but I would assume it is a build config issues.

Ok, from what I can see in the board config, the pin is selected and set up correctly as TIM8 CH1 on port I5. However it is not triggering as it should. Edges are triggered every second (or slower) and the count numbers I printed where around 17000 and 40000, not sure what sort of invalid data that is.

[julianoes]

Well, according to @vincentpoont2 I5 is not connected which would explain it:

On our BASE, RC IN is not connected to I5 of IO and FMU at the same time. The RC IN of the Pixhawk5/6X reference board schematic is connected to I5 of IO and FMU at the same time. The reason for this is that our RC input port is different from the reference board: The reference board PPM_RC is a single port, while DSM and SBUS share one port. In this way, the SBUS receiver channel was confused when the early Ardupilot firmware was ported. So we changed it to a common port for PPM_RC and SBUS, and DSM is a separate port. Because it is uncertain whether the ISSUE will occur when the SBUS signal is applied to the PPM_IN pin (I5) of the FMU, it is not connected by default.

[julianoes]

@dagar I guess there is not much we can do other than to keep it in mind?

[Mitchell-Lee-93]

I'm having the same problem with RC SBUS input on HolyBro Pixhawk 6C with IO off (sys_use_io=0). To use DShot on Pixhawk 6C, however, sys_use_io should be 0 according to (DShot ESCs). Does this mean I cannot use PPM or SBUS RC while using DShot on Pixhawk 6 series? Or would there be other methods to solve this problem?

[Mitchell-Lee-93]

In addition, with the same setup, I noticed that SBUS RC works fine with sys_use_io = 0 on the stable PX4 version (1.13); however, with the current master PX4 version, it doesn't work.

[julianoes]

You need to have SYS_USE_IO set to 1 but then use the actuator config to set the actuators to be on FMU. I would suggest to do this by enabling SYS_CTRL_ALLOC, or using v1.14 instead where it's the default.

[NicolasM0]

I have the same issue on cube orange and cube orange+ with px4 1.14 branch. SYS_USE_IO = 0 #IO PWM disabled (RC only) disable RC. Controlling my dshots esc work without setting it to 0 thanks to the new output selection.

As outputs can be configured through the ctrl allocator, is this parameter still useful?

[julianoes]

As outputs can be configured through the ctrl allocator, is this parameter still useful?

Yer, I agree. We might want to get rid of that parameter eventually.

[NicolasM0]

I have the same issue on cube orange and cube orange+ with px4 1.14 branch. SYS_USE_IO = 0 #IO PWM disabled (RC only) disable RC. Controlling my dshots esc work without setting it to 0 thanks to the new output selection.

As outputs can be configured through the ctrl allocator, is this parameter still useful? Could it be removed from PX4 parameters and just be an environment variable for rcS ?

[AlexKlimaj]

SYS_USE_IO is set in the board startup scripts. Then the common startup scripts logic is based on that. Each board has different logic to set the state of SYS_USE_IO.

[junwoo091400]

I would like to add this in the release note to caution the users 🙏

[AlexKlimaj]

I think we need to port a PPM driver to the FC. As of now it only lives on the IO MCU.

[AlexKlimaj]

I can confirm PPM input directly into the ARKV6X/FMUV6X on a carrier board without an IO MCU works.

The issue is on carrier boards with an IO MCU is that the RC input driver on the FC doesn't run.

[davids5]

I think we need to port a PPM driver to the FC

It has always been available on the FC.

It is a wiring choice and Jumper option on some FC HW.

The correct wiring is to connect the PPM to both CPUs (FC, IO) with just Isolation resistors.