View Single Post
Old Aug 03, 2012, 04:50 PM
GoFaster is offline
Find More Posts by GoFaster
Live for speed
GoFaster's Avatar
USA, CT, Bethany
Joined Mar 2004
1,396 Posts
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 View Post
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.
GoFaster is offline Find More Posts by GoFaster
Last edited by GoFaster; Aug 03, 2012 at 04:57 PM.
Reply With Quote