How can I read a CPPM signal with my PICAXE?

abenn

Senior Member
I'm familiar with using pulsin to read the input from single channel of an RC receiver, but I've recently bought a receiver which uses CPPM to combine nine channels into one signal wire.

Is there any simple way I can distinguish between the individual channels using this single output to a PICAXE? According to the receiver's literature (it's an FrSky TFRSP) the CPPM signal has a period of 20ms, but no other info.
 

hippy

Technical Support
Staff member
It might be possible if you can synchronise to the sync pulse, perform consecutive PULSIN commands to read the channel(s) you want to read.

The channel(s) you want to read will determine how much time you have to process the data before needing to be ready for the next sync pulse. In some cases it may be acceptable to skip frames to provide time for whatever you need to do with the data.

There's some more information on the FRSky CPPM protocol and its timing at the link below ( we have no opinion on the actual product or the opinions presented on that page ) -

http://diydrones.com/profiles/blogs/why-frsky-cppm-signal-is-so-disappointing
 

abenn

Senior Member
Thanks hippy. I think the programming you're suggesting is beyond my present capabilities -- maybe something for long dark evenings next winter.

Your link also had me worried until I saw the date of the article. The literature that came with my FrSky clearly states that it uses a period of 20ms, not the 18ms mentioned in the article. Today I used seven channels via its PPM link without any problem.
 

eggdweather

Senior Member
I have the Taranis and the original CPPM update rate was 18mS, but Frsky slowed it down sometime back, perhaps 2-years ago after issues with some servos and receivers. They made the firmware updates available, still are, but if you have recent equipment they should be OK as specified. You can update the tx and Rx firmware to solve the update frequency problems, well they were fine on all FrSky equipment.
Your code would need to use PULSIN to wait for the sync pulse then read each consecutive pulse acting on the width of each as required.
loop:
PULSIN pin, 1, variable
IF variable < 500 THEN GOTO loop ;wait for the sync pulse of 5mS
PULSIN pin, 1, channel1
PULSIN pin, 1, channel2
PULSIN pin, 1, channel3
PULSIN pin, 1, channel4
PULSIN pin, 1, channel5
PULSIN pin, 1, channel6
PULSIN pin, 1, channel7
PULSIN pin, 1, channel8
PULSIN pin, 1, channel9
; Now you have the width of each channel you can do something
IF channel1 = 100 THEN GOSUB switchonlights ; if this channel is a minimum or 1.0mS then do something
IF channel3 = 150 THEN GOSUB geardown ; if this channel is at the middle or 1.5mS then do something
IF channel6 = 200 THEN GOSUB flapsdown ; if this channel is a maximum or 2.0mS then do something
IF channel1 < 175 GOSUB flashthelights ; and so on
GOTO loop

switchonlights:
LOW pinx
RETURN

~~~

Is how I would approach this. It is probably not more complicated than that. Bruce has a good visualisation here: https://www.youtube.com/watch?v=FBAKxz7NSJk
I think you should have enough time to receive each pulse and like hippy says, you could miss a frame or two while you process the data as long as your not using the data to control a model like an aircraft as a lot could happen in the mill-seconds between a command!
 
Last edited:

westaust55

Moderator
Looking at the signal waveform in the link hippy provided, with the time for the longer channel pulses at 2ms then the low period between each pulse is of the order of 0.2 ms (= 200 us).

The PICAXE clock may need to operate at a higher speed like 32 MHz or even 64 MHz (20X2 for 64 MHz).

If you do the first PULSIN command to check the synch pulse
Then have and IF ... THEN test to check the duration
And if okay set up for the first channel pulse,
That all takes some finite time.

To squeeze all these actions into a 200 usec. Period needs a fast clock speed.
At 4 MHz a single PICAXE command may take 250 to 280 usec to perform.
The above sequence may take the duration of say 6+ simple commands so consider at least 1800 usec at 4 MHz.
At 8 MHz = 900 usec, at 16 MHz = 450 usec, at 32 MHz = 225 usec so ideally go for 64 MHz.

Even saving the result of a PULSIN command and then setting up for the next command takes some time.
Maybe around 50 usec at 64 MHz.

Thus a PULSIN sequence is doable but needs a high PICAXE clock speed.
 
Last edited:

hippy

Technical Support
Staff member
Also note that the synch pulse is the high period between two low going pulses which represent channel data. That means the sync pulse leads right in to the first channel pulse so it won't be possible to PULSIN the sync pulse and then PULSIN the first channel data of the same frame.
 

eggdweather

Senior Member
I'm thinking that you mean there won't be time to complete the PULSEIN for the sync-pulse and then begin a PULSEIN for the command pulse because the zero time period will be too short, because the next pulsein won't start timing until the next 0-1 transition which starts the first channel pulse-length?
 

hippy

Technical Support
Staff member
That's correct. The sync pulse determination has to start at "A" and will end at "B" ...


Code:
    Ch8        Sync        Ch1
___     __________________     ___
   |___|                  |___|

      |                    |
      `--- A               `--- B
I might be wrong. If thr channel pulses are active high that would be okay ...


Code:
Ch8           Sync             CH1
___     __________________     ___
   |___|                  |___|

      |                    |
      `--- A               `--- B
 

eggdweather

Senior Member
On the FrSky CPPM pulse train it is active high and the start of the sync-pulse is the positive going edge, it lasts for ~5mS, then returns to 0, waits for the fixed inter-symbol time of ~0.208mS then starts channel-1 for its command length of 1 to 2mS, then there's another 0.208mS gap and channel-2 starts and so on. I think it will work OK, but as westaust55 says the PICAXE needs to be running fast enough to get ready for the next pulse and it appears from his timings that only at 64Mhz will it be feasible because at 32MHz the timing is 225uS which is too long.
 

westaust55

Moderator
My timings are only indicative but should be in the right order of duration.
It can depend upon where in a program a command is how long it will take.

I would suggest start at 64 MHz and once proven then try at 32 MHz.
The 200 usec is ample for the inter channel periods (even for 32 MHz and just maybe 16 MHz), it is just the extra time needed for the IF ... THEN test after the synch pulse that could be the stumbling point.
 

abenn

Senior Member
Thank you for all the comments, advice, and information.

My original reason for asking the question was because I couldn't get GPS to work with my Naze32 flight controller, and I was frustrated that it gives no meaningful visual indication of what's happening, so I was thinking to have my receiver activate some LEDs so I could at least get confirmation I was sending the correct signals. But on Sunday my GPS started working -- I think it was reducing the amount of wiring from six separate cables from Futaba receiver to Naze, to one cable from FrSky to Naze, that sorted it.

I've also realised that my FrSky receiver has conventional outputs for channels 5 to 10 in addition to the PPM one, so I don't need to decode the PPM :eek:
 

reywas

Member
Hello All,

I'm working on a similar project as the OP so I thought I'd piggy-back on this thread since it isn't very old. I hope that doesn't break any forum etiquette rules. I'm new to Picaxe but I have read through the manuals and worked through most of the tutorials so I'm excited to get started on the project.

I have a FrSky receiver that puts out a CPPM signal at a 27mSec frame rate. The sync pulse is 9-17mSec long. Reading through this thread I've learned that there may be an issue with missing the channel pulses due to the relatively short inter-pulse space following the sync pulse. I had a thought that I could get around this issue if I could come up with a way to the measure the sync pulse and jump out of that measurement routine once I know it is long enough to be nothing other than the sync pulse, say 5mSec. This would leave plenty of time to get to the first pulsin command and be ready to read the first channel pulse. Any thoughts on how this could be elegantly accomplished? I was thinking of a short loop that is triggered by an interrupt and then just sits and reads the port for a "high" and counts the number of times through the loop, but I'm not sure how to translate that into a time measurement.

Also, previous posts on this thread discuss getting things working at 64MHz and moving to the slowest speed that works. Why not stay at 64MHZ? Are there down-sides to running at a faster clock speed?

Thanks for any help
 

hippy

Technical Support
Staff member
Welcome to the PICAXE forum.

I do not see there's any problem riding on the back of the previous discussion as you are talking about the same thing.

Counting time during the sync pulse then jumping out early, once you know it is a sync pulse ( has been present for some minimum period ), seems an ideal and valid way to do that, assuming it's long enough to do that which it looks like it could be ...

Code:
w0 = 0
Do
  w0 = w0 + 1 * pinX.Y ; Resets w0 to 0 when pinX.Y= 0
Loop Until w0 > SOME_VALUE
PulsIn X.Y, 1, channelOne 
PulsIn X.Y, 1, channelTwo
[i]etc[/i]
I am not sure if the previous discussions were suggesting dropping the operating the system speed rather than saying it would unlikely be possible to use slower speeds, though I must admit I didn't study every word of previous posts. There is no problem with staying at 64MHz so long as that doesn't cause any problems.
 
Top