CPPM for spektrum modules

Arduino projects on the go
Post Reply
jmendoza
Posts: 167
Joined: 18 Feb 2018, 23:07

CPPM for spektrum modules

Post by jmendoza »

Is it possible to configure the arduino 7 channel w/ SCE sketch to do CPPM for using with the Spektrum modules from a DX4e/DX5e?

There is no bind button on these modules. The I-Range multi protocol module also has no bind button so I'm assuming the arduino would have to create the GUID and have a digital input configured for a bind switch. In addition it would have to output CPPM to the module. Has anyone done this?

I have a bunch of the DX4e and DX5e transmitters here as they come with RTF planes. Most guys set them aside and use a DX6i or better, so there is a surplus of these inexpensive transmitters around.

Thanks in advance for any assistance,
Jay Mendoza
User avatar
Phil_G
Posts: 597
Joined: 15 Feb 2018, 23:32
Contact:

Re: CPPM for spektrum modules

Post by Phil_G »

Theres some confusion here Jay.
cppm IS ppm, thats what the encoders generate. PPM and CPPM are the same thing, the 'C' simply indicates that it was created by combining all the edges of the pwm channels at the receiver.
Take a scope and look at a receiver outputting CPPM and the PPM from the encoder in the transmitter its bound to. There is no difference, its the same information in the same format!
Non-information aspects may have changed such as the frame rate, pulse polarity and the width of the ppm pulse itself (none of which contain control information), but the actual channel timing information is identical. You cannot distinguish between cppm and ppm on a scope.

Dx5e and DX4e modules use a 125kbps async serial protocol, which (given time & inclination!) could be worked into existing code. But its not a trivial change, it would need some work. Whilst the serial protocol is quite simplistic, 125k isnt a 'standard' baud rate so the hardware serial can't be used, and software serial is difficult at such high speeds. Why they didnt use 115k which is a standard, I dont know. Maybe it was an anti-cloning technique!

Cheers
Phil

PS
One of my many unpleasant attributes Image is that I do enjoy the occasional bit of pedantry, and what we know and love as PPM in an RC transmitter sense (as implemented by Doug Spreng) has always been DPPM. No RC system takes its channel timing relative to the sync nor to a regenerated clock, its asyncronous and times relative to the previous pulse, hence its DPPM.
At the encoder end from the earliest multivibrator-followed by-halfshots encoder through NE5044 and to processor-based R/C ppm encoders, each pulse has always been timed relative to the previous one - often actually triggered by the previous one - so again, clearly DPPM Image
Post Reply