I would certainly appreciate that; so I don't need to have my workaround and also so the decode routine in the FC doesn't have deal with the extra useless/filler frames.
I noticed that the max frame length is ~30ms from the Nano, and the guard pulse is squeezed to accommodate whatever the channel pulse widths are.
With my workaround, the min guard pulse width is 2.8ms and I set the valid time in the FC to 2.7ms.
Regarding the min 750/900us width, if I set the endpoint on a channel to a few % less than -100%, I see frames like the second pic in post #2 above.
Do you happen to have a link to the PPM spec?
Thanks for looking into this!
Originally Posted by JimDrew
What I probably should do is cap the number of channels in PPM mode to something usable, like 10 channels or less.
Remember, a PPM frame is calculated as: max PWM time x number of channels + 5.7ms. So, with 12 channels that would be:
2.1 x 12 + 5.7 = 30.9ms
That is the amount of time a 12 channel frame can take. If you have a 25ms frame, you are going to be way out of sync! 16 channels is even worse:
2.1 x 16 + 5.7 = 39.3ms
This is why you can't even fit 9 channels in a standard 22ms frame:
2.1 x 9 + 5.7 = 24.6ms
Graupner uses a variable frame rate to get 9 channels - and oh, what a nightmare it is to support this!
The 5.7ms is what you are calling the 'guard time', and is per the PPM spec created back in the 70's. You can reduce this to about 2.7ms and get away with it:
2.1 x 9 + 2.7 = 21.6ms
Keep in mind that the original PPM spec is 750us to 2250us, not the 900us to 2100us that is common. Our system supports the original PPM spec.