Posted by Chris Anderson on December 11, 2009 at 10:52pm
The best way to read RC signals is PPM, which is a sequential stream where each channel is output in turn on a single wire. But traditionally the only way you can get that is to open up your RC receiver and solder a wire to a special pin. Fortunately the Paparazzi team designed a board that will convert up to 8 channels of regular PWM servo signals to one PPM signal, with no RC hacking required. We've now modified it a bit to work with our failsfe multiplexer and released a version as a DIY Drones product ($24.95).
BTW, the forthcoming ArduPilot Mega will use this technique, as well.
From the product description:"This improved & reduced PPM encoder board, based on a Paparazzi design, plugs into the servo output ports on a R/C receiver and encodes them into a PPM pulse suitable for the paparazzi autopilot and other projects. This allows you to use any R/C equipment with the paparazzi autopilot or read up to 8 servos with a single I/O pin of your uController. Modifications to the R/C receiver are not necessary. Connect the wires from your receivers channels to the PPM and one wire to the PPM in of your system. If you decide to use the tiny board to power the receiver, make sure you put-in a jumper and plug something between the 8th channel and the receiver.
The whole project is based around the ATMEL ATMEGA168/328 AVR processor and all timing is done
within interrupts so accuracy and stability is optimized
It is now also possible to select the PPM waveform shift, negative or positive.
Firmware is free and was created by Hendrix and Moa, with tiny modifications by Jordi Muñoz that allows control an extra failsafe multiplexer.
I have now tested the PPM encoder on two other RX. One Futaba R617 FASST and one JR RS10DS. When any of these RX is connected I only get 6 channels out of the PPM output on the PPM encoder. Am I doing somthing wrong. Do I have to program the PPM encoder with latest firmware ?
Hi. I bought this PPM encoder. I have connected it to a Futaba 2.4GHz FASST R6114FS. I use a 10ch TX. The PPM encoder seems to only output the first 6 channels. I have scooped the PPM output, and I can only see 6 channels.
Is'nt it compatible with futaba FASST ? Or is there some setting or tricks I have to do to make it work ?
Well it was not that hard to make, the difficult part was to make it reliable enough for a UAV.
I am glad that it was found to worth something.
It would be nice if Atmel would make a simpe but faster than 20 Mhz AVR or at least make the internal oscillator capable of more than 8 Mhz.
Also remember to set the BODLEVEL fuses to 4.3v because during power up or down the plane the flash memory might get corrupted (but never in flight)
Chris
Thanks for the really helpful updates and info (and great job on the software, which I've heard described as "magic"!). This is a great example of open source hardware spreading, thanks to your excellent design.
One last thing i forgot to add:
Even though some receivers output a servo pulse every 14.5ms or lower, the actual servo pulse
width is updated every two servo pulses.
For example some Futaba receivers (2,4 Ghz) output all 8 channel pulses within 14,5 ms and then
start again so in a ~20ms time we need to produce one full 8 channel ppm wave train, two servo pulses for one or more channels have been detected at the ppm encoder's input.
This might seems like we are loosing pulses but in reality the Futaba rx updates the servo channel with the actual value sent from the tx every 29 ms so the rx servo output contains the same value
for at least two consecutive servo pulses.
Chris
Hi.
I am the "hendrix" who wrote the firmware (Moa wrote the pdf manual as English is not my native language)
I want to add some details to the technical aspect of the ppm encoder.
There is some jitter present in the ppm output (not much to be a problem)
but after much testing i found that this is caused by the use of the rc internal oscillator.
The rc oscillator is voltage dependent and any noise present in the supply rail will make the oscillator change it's frequency by a small amount, it is not stable enough even if the noise is zero to begin with.
I knew this from the start that's why my first pcb's had a smd crystal but since size was important
and the performance was not that bad i omitted it later.
I have build a couple boards that use a 16 Mhz crystal that has zero jitter.
Even digital servos are totally quiet although there is nothing gained except weight and cost.
Secondly about the lost frames the problem is that if for example the ppm output waveform contains 8 channels plus the reset pulse (~20ms) and the rx output is refreshed every 16ms
for example, then there is not available time in order to refresh the ppm output in time.
There is a workaround though.
If someone wants he can compile the source code to use less than 8 channels or make a small modification to the code and make the ppm output contain as many channels as those detected during startup thus speed up things by reducing the ppm output's total length.
With paparazzi it would be awkward to use such a scheme because the user would need to update the radio file (a special xml file that contains the channels of the ppm input) every time he changed something so i went for a constant ppm waveform.
I also have wrote newer versions with a filter and asm interrupt routines for increased accuracy that i will post when i am certain that are 100% stable at the paparazzi wiki.
(it is i am sure but i need some more air time)
Meanwhile if anyone want's to try the new code just email me at hendrix at vivodinet dot gr
Chris
Got mine last night, and it works perfectly. If you reversed the S+G order it would solder right on an AR-6000 making a really clean setup. As it is I soldered pins into the holes and pit heatshrink over it then it plugs right into an AR -6000 making a farily clean setup.
Comments
Is'nt it compatible with futaba FASST ? Or is there some setting or tricks I have to do to make it work ?
I am glad that it was found to worth something.
It would be nice if Atmel would make a simpe but faster than 20 Mhz AVR or at least make the internal oscillator capable of more than 8 Mhz.
Also remember to set the BODLEVEL fuses to 4.3v because during power up or down the plane the flash memory might get corrupted (but never in flight)
Chris
Thanks for the really helpful updates and info (and great job on the software, which I've heard described as "magic"!). This is a great example of open source hardware spreading, thanks to your excellent design.
Even though some receivers output a servo pulse every 14.5ms or lower, the actual servo pulse
width is updated every two servo pulses.
For example some Futaba receivers (2,4 Ghz) output all 8 channel pulses within 14,5 ms and then
start again so in a ~20ms time we need to produce one full 8 channel ppm wave train, two servo pulses for one or more channels have been detected at the ppm encoder's input.
This might seems like we are loosing pulses but in reality the Futaba rx updates the servo channel with the actual value sent from the tx every 29 ms so the rx servo output contains the same value
for at least two consecutive servo pulses.
Chris
I am the "hendrix" who wrote the firmware (Moa wrote the pdf manual as English is not my native language)
I want to add some details to the technical aspect of the ppm encoder.
There is some jitter present in the ppm output (not much to be a problem)
but after much testing i found that this is caused by the use of the rc internal oscillator.
The rc oscillator is voltage dependent and any noise present in the supply rail will make the oscillator change it's frequency by a small amount, it is not stable enough even if the noise is zero to begin with.
I knew this from the start that's why my first pcb's had a smd crystal but since size was important
and the performance was not that bad i omitted it later.
I have build a couple boards that use a 16 Mhz crystal that has zero jitter.
Even digital servos are totally quiet although there is nothing gained except weight and cost.
Secondly about the lost frames the problem is that if for example the ppm output waveform contains 8 channels plus the reset pulse (~20ms) and the rx output is refreshed every 16ms
for example, then there is not available time in order to refresh the ppm output in time.
There is a workaround though.
If someone wants he can compile the source code to use less than 8 channels or make a small modification to the code and make the ppm output contain as many channels as those detected during startup thus speed up things by reducing the ppm output's total length.
With paparazzi it would be awkward to use such a scheme because the user would need to update the radio file (a special xml file that contains the channels of the ppm input) every time he changed something so i went for a constant ppm waveform.
I also have wrote newer versions with a filter and asm interrupt routines for increased accuracy that i will post when i am certain that are 100% stable at the paparazzi wiki.
(it is i am sure but i need some more air time)
Meanwhile if anyone want's to try the new code just email me at hendrix at vivodinet dot gr
Chris
Paul