CPPM input stopped working in v6.0_dirty

[OpenUAS]

On a Lisa MXS flightcontroller I've flashed git object ID 0b64c15879fd9659c85c5c03b2041551f871e8fa This is the closest ID I could find before the massive changes of building the firmware where pulled in.

There CPPM input still works, tested with Airframe openuas_wltech_xk_a160.xml

On exactly the same hardware This Git ID does not work anymore... 23d99579550630b60c51500ab4502e5c6215efd1

This makes continuous test-flying the 6.0_Dirty branch on Lisa M(X)(S) (and other AP's also) quite impossible. Even more so due to e.g. multiple https://flapper-drones.com/wp/ with very tiny receivers with only CPPM output exist replacing all RX is not feasible on those.

Tested airframe on bare metal since there is no Chibios version of Lisa MXS board,

Then tried on however Lisa MX2.1 where CPPM pin is on Servo6. On On exactly the same hardware the Baremetal of this git object ID 0b64c15879fd9659c85c5c03b2041551f871e8fa works, the Chibios does not,

This means CPPM not working on Chibios is already longer an issue :(

But in the past it worked on chibios see https://github.com/paparazzi/paparazzi/pull/581 and the remark of @podhrmic "commit can be merged, since the ppm radio now works"

So if CPPM input only could be fixed for Chibios on v6.0 and not baremetal anymore, not ideal but acceptable IMHO

[OpenUAS]

Maybe relevant, same everything with the only difference when compiling

to

Gives:

Chibios: mcu_periph/sys_time.c:39:1: note: #pragma message: Config: SYS_TIME_FREQUENCY = 10000 39 | PRINT_CONFIG_VAR(SYS_TIME_FREQUENCY)

Baremetal: mcu_periph/sys_time.c:39:1: note: #pragma message: Config: SYS_TIME_FREQUENCY = (2 * 512) 39 | PRINT_CONFIG_VAR(SYS_TIME_FREQUENCY)

[gautierhattenberger]

chibios and baremetal used to have a different timing for the polling of event and main freq. However, I have harmonized that part with the recent code reorg with #2721

[OpenUAS]

@gautierhattenberger Want to debug to help fixing, a hint what has the highest chance of being broken would be great.

BTW already browsing through relevant sourccode, and plan getting BMP2 debug setup on the LisaMX2, but there is just so much to do and this make testflying for other thing to fix a bit problematic. Any help in a timely fix to try out welcomed.

[gautierhattenberger]

just to be sure, we are talking about the radio_control_ppm not working with ChibiOS, right ?

[OpenUAS]

Yes, "radio_control_ppm". the CPPM pulse of a valid RC Receiver into a flightcontroller, e.g. Default connected on lisa MX 2.1 on SERVO6 (PA01) and where the hardware works. Since latest changes somewhere also Bare-metal does not work anymore. Chibios unknown as of which commit it stopped working, since not tried CPPM in the past for Chibios. But now when in the process upgrading all aircraft to use Chibios in preparation before v6 release one will come across some issues, as expected. This is one of them, but the most unfortunate one, since it prevents testflights to discover potential other issues.

e.g. in Aircraft config:

...

     <module name="radio_control" type="ppm">
        <define name="RADIO_CONTROL_NB_CHANNEL" value="8"/>
        <configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/>
        <define name="RADIO_GEAR" value="RADIO_AUX2"/>
        <define name="RADIO_FLAP" value="RADIO_AUX3"/>
      </module>

...

[OpenUAS]

Tested the exact same RX with cppm out on a PX4FMU v5 (Pixhawk4) on PPM port with latest addition #2751 of @fvantienen to that FMU that works. So it is not the hardware nor basic functionality of chibios but should be something in the Lisa MX board file IMHO.

[pcampolucci]

@gautierhattenberger @OpenUAS I have looked into the issue and possibly found the issue of why the readings from the PPM signals are zero in latest master.

I have analysed on the oscilloscope the CPPM signal sent by the FrSky 2.4GHz ACCST R-XSR receiver both in a 5.18_stable branch and latest branch. Here is the difference.

For 5.18_stable (which is sending nonzero messages to pprz), you can see that the dV from LOW to HIGH is around 3.26 V

For latest master, the dV drops to around 2.38 V.

Now by looking at several logic level implementations, it could be that the logic for SERVO6 pin in Lisa makes the signal HIGH fall into the invalid state range, resulting in no PPM received.

Just as a check i would decrease the Vih magnitude to 2V or something for that pin and see if that is fixed. @gautierhattenberger do you know by any chance in which file i should look to change this setting?

[gautierhattenberger]

The modification that might have affected the lisa_mx(s) board is the order of initialization between radio control and actuators modules. In the airframe file openuas_wltech_xk_a160.xml for instance, the RC comes after the actuators, but the new organization makes the actuators always come after RC. So the PIN is set to output while being used as an input (explaining the lower voltage, but that would not even be enough to have it at the correct level). So I think the config of these boards was wrong from the start at it was only working by chance. In the board header, the PWM6 is always activated (https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/boards/lisa_mx_common.h, L423). You can first try to disable it to check if it is solving the problem, and if yes, make it configurable (and fix the relevant airframe file). Also an error when using the pin for both RC and actuator would be good.

[pcampolucci]

understood, I will look into that, thank you

[pcampolucci]

@gautierhattenberger and @OpenUAS.

Indeed, the fact that the setting of the USE_PWM6 variable to 1 was the issue. If now I make it configurable, the PPM signal works. This issue applies to both lisa_m and lisa_mx boards. I have added the following modifications.

#ifndef USE_PWM6
#define USE_PWM6 1
#endif

#if PPM_CONFIG == 2 && USE_PWM6 == 1
#error "You cannot USE_PWM6 and SERVO6 (or equivalent) at the same time"
#endif

In this way if the user defines servo6 by not specifically deactivating the PWM6 variable it gives an error.

I will make a pull request

[OpenUAS]

Working for Baremetal, needs more testing on Chibios, but since there some other issues to fix before can be tested fully, so still open WIP. The SERVO6 and PWMS warnice could use some improvment, as in use SERVO6 for PPM then disable Servo6 output without warning.

[gautierhattenberger]

should be fixed now