How many channels supported on PPM RC input?

I have a ULRS Rx in my plane connected its 16ch PPM output to the Pixhawk (lite) FC, but can only see 12 channels in Mission Planner (ch13in-ch16in all show 0). Is 12 channels the limit in Plane for PPM RC or is it something specific to me possibly?

Thanks in advance, Paul

Long running problem, sadly :frowning:
I found that using sbus gave me 16 channels, but CPPM only 12:

Thanks Marc. I suspected as much. Not sure why they can’t have it supporting all 16 channels on PPM in Plane. Works fine in copter.

if it works fine on copter with the same hardware, that’s very helpful information actually.
Please add this to the bug, so that hopefully we can find out why on earth it’s limited to 12 on plane.

As far as I know, PPM is limited to 12 channels which is a frame length of 32.5 mSec
I am wrong?
My Pixhawk works with 12 channels PPM stream supplied without any issue.

CPPM is not limited to 12 channels, my Taranis sends 16 channels to my LRS transmitter using CPPM, and they are received (all 16) by the openlrs receiver in the plane. Channels 13 to 16, I need to plug devices directly into the openlrs receiver since they don’t get received by the pixhawk.
Now, I didn’t use a scope to verify if my openlrs device failed to send channels 13 to 16, or whether the pixhawk is failing to receive them.
@pauljatherton please give us more details on your setup where all 16 channels do work and get processed by the pixhawk with copter, so that we can rule things out.

By the way please call it CPPM (or PPM-Sum), Combined PPM, as PPM is just pulse position modulation, which refers to a single channel.

That’s not strictly true. See the definition of PPM here from wikipedia - “A complete PPM frame is about 22.5 ms (can vary between manufacturer), and signal low state is always 0.3 ms. It begins with a start frame (high state for more than 2 ms). Each channel (up to 8) is encoded by the time of the high state”. As far as I am aware, the acronym CPPM was introduced by FrSky. No idea where the expression PPM-Sum came from either. Just “PPM” describes the encoding of several channels into one PPM frame. The width of the PPM frame can be expanded however to include additional channels (2ms per additional channel). A 16 channel PPM frame would generally be 38.5ms in length. I believe some manufacturers use more proprietary techniques such as proportionally reducing the size of channel pulse widths within the PPM frame to reduce the overall frame size giving a higher refresh rate for the RC controls (read this on the ULRS forum in last few days).

As for 16ch PPM support in Arducopter - I thought I had read about this on RCG, but in fact the writer was referring to Ardupilot ‘Rover’ version, and he provided evidence (Mission planner screenshot) that this supports 16channel PPM input in the article here:
I just tested my ULRS setup on copter 3.5-rc7 and it also only supports 12 channels. Would be nice if plane would support 16ch PPM - I appreciate copter flyers would not necessarily appreciate a longer PPM frame size which would result in a lower channel refresh rate, and of course this issue doesn’t affect SBUS, so that is always preferred. Hopefully SBUS will be supported in future versions of ULRS (once the hardware design advances).

Just FYI, openlrsng has supported sbus output for 1-2 years now. I have it working on my brotronics module and feeding 16 channels to ardupilot (the brotronics module has a built in serial inverter, so sbus out just works)
It’s a bit sad that uLRS started over from scratch, slowly re-inventing the wheel for all the things that were already in openlrsng, although it’s almost there by now. That said, my main issue with it is the closed source model, and especially the time bomb in it (every release will stop working after a while).
In the meantime, you can work around it by plugging things into PWM channels 13 to 16 of your LRS receiver, assuming yours does PWM output and channel mapping to random pins (the openlrsng modules allow this).

The time bomb is just a part of the beta programme - he hasn’t failed to either release a new version in time or extend the time bomb (occasionally goes a day or so over), so it hasn’t affected anyone so far in the whole. It only affects the CC app in any case and doesn’t touch the Tx/Rx firmware - these stay working indefinitely. I know - you will likely respond to say that the CC is essential… but like I say, the time bomb is just a part of the beta programme and will not exist in the paid versions once they are released. He wants to get everything 100% stable before releasing a paid version, so for now the software (as you correctly say, which is closed source) remains free to beta testers. He wrote it from scratch (so he says) to remove any reliance on the open-source code which ULRS v1 was based on, as a means to make it closed source. Yes, as you surmise, it does not support PWM outputs yet - only PPM, and hence only 12 channels in Ardupilot. It does provide all 16 channel outputs over i2c, and his workaround for enabling PWM connections is to use an i2c->pwm board. I don’t really need the channels that badly! There are also future plans to release a teensy 32bit (instead of pro-mini) version and the teensy has a lot more I/O options and so will facilitate the provision of SBUS whilst at the same time providing the 19.2k telemetry link (which is the main reason I am onboard with the ULRS project in the first place. It does work amazingly well, even in its beta versions. I only hope the developer maintains his interest to see his plans through to fruition - this is my only real concern, and hence the reason I keep offering my pep talks in the RCG thread :slight_smile:

HI Paul. I didn’t want to write too much about this, but I guess it’s important to be precise. Thanks for writing up the details.
Also, I missed how uLRS doesn’t do PWM at all yet, I guess it’s good that I’m sticking with openlrs then since I do use 14 channels on 2 of my planes (some servos are plugged directly into PWM outputs of the brotronics openlrsng receiver).
All that being said, yes, it would be good for AP to figure out why PPM signals get cut at 12 channels, so that uLRS users can get at least 14 on a pixhawk.
And while that’s off topic, you don’t need a teensy for sbus, the brotronics dues sbus natively on openlrsng by having a hardware inverter built in on one pin. It’s actually very sweet hardware outside of the lack of 1W back channel for telemetry. I got to send 16 channels via sbus directly to my pixhawk and it just worked.
Actually it can be helpful to have 16 channels received by the pixhawk with 14 output by using channel 15 for PWM of RSSI signal (supported by pixhawk/AP) and channel 16 for mode switch, leaving you 14 channels you can do PWM output for. Right now I had to fudge and use channel 11 for RSSI PWM and channel 12 for mode switch if I use CPPM

Marc, Think its better to keep ULRS discussion in the thread on RCG. I know the question has been discussed about SBUS over there. To get both 2-way telemetry and SBUS you really need two hardware UARTS. You can use soft serial but the other limitations on the 328p chip prevent adequate resources for both. Anyway - like i said, back to RCG for ULRS chat/questions where you will get responses from folk who really have knowledgeable answers!

Oh yeah, you can’t do SBUS and RX/TX telemetry at the same time on openlrsng, because indeed just one UART as you said. I stand corrected on my comment that a teensy isn’t needed. a Mega or something with more than one UART or a fast 32bit CPU (teensy) is needed to do serial + SBUS.
uLRS could do SBUS now, but it would lose telemetry, which defeats the reason why people use it.
By the way, not trying to knock down uLRS here, just interesting to talk about the difference between the firmwares and in this case I wanted to focus on the fact that you can get 16 channels now with SBUS on openlrsng if someone cares about this, but again 12channel CPPM + 4 PWM driven output ports work just as well, and for now that’s only on openlrsng should someone need more than 16, or us uLRS with an I2C to PWM board as you said.
That is, again, until AP get fixed to support the full 16 channels over CPPM.