Ug… 
I understand the circuit perfectly. But it’s for reading PWM not PPM. PWM is pulse width modulation. It goes from 0 to 100%. PPM for a servo is 1-2mS on and 20mS off. So it’s never more than 5% to 10% on. This will give you a total range of 0vdc to .5vdc, not the 0vdc to 5vdc you are looking for.
Ahh ok so if that pwm signal did not have that 20ms off delay this circuit could probably be used. That 20ms off period would toss off the averaging of the Circuit.
As for what voltage you would get out, that would be adjusted with the resistor and the cap value to find a setup that works for you ???
that image was just to show the conversion from pwm to voltage it wasn’t to use those exact values…
I wasn’t sure where you got PPM from?
I’m probably missing something here.
–Aaron
Not trying to step on anyone’s feet here…
Aaactually servo control signals are PWM; they have a 20mS period with a standard pulse ranging from 1mS to 2ms, or an extended pulse ranging from 0.5mS to 2.5mS duration. This definition cmes from how the orriginal servo encoders worked where they could encode/decode up to 9 channels in a single 20mS frame. Here is a link to a popular data sheet for an LM1871 R/C encoder chip used back in the day, so to speak.
Here is where it gets confusing… The servos themselves are however forgiving enough that they allow a PPM signal with a constant 19 to 20mS off time and a pulse varying from 0.5 to 2.5mS to work.
The problem in using your R-C filter circuit is as described, the very short duty cycle combined with the low frequency makes it impractical to apply.
Ideally you can use a capture input of a microcontroller to measure the pulse duration in terms of counter pulses. I think some effort has already been spent in that direction in other threads on the forum.
An other option would be an integrator circuit where a capacitor is charged using a constant current source while the signal is high, then measured by an a/d converter when the signal goes back low. Once the voltage is read a transistor is used to discharge the capacitor until the next pulse arrives. the reason a constant current source is used is because the voltage across the cap increases linearly over time when a contant current is applied. The reason a transistor is used to discharge the cap in the off state is because leaving a pull-down resistor across the cap while charging makes the charge non-linear. A circuit like this is really easy to implement using a simple controller like the Atom but requires a dual channel op-amp, a couple transistors, and a capacitor be wired up to make the integrator. It also requires a multiplexer of some sort to select which r/c servo input you are measuring… something like a CD4051 would probably work just fine.
I agree Eddie. The term PPM really applies to the signal the old radios used to transmit to the receiver. The position of the pulse determined the position of the servo. I carried the term through the post just to differentiate it from PWM because the signals do not behave as, or are not used as, pure PWM (0% to 100%).
Eddie, Robot dude.
Thanks,
I’m not an electronics wiz but there has got to be a way of converting pwm signals from rc transmitters into a usable format that is somewhat easy to code with so we don’t run into situations where we have to use gobs of code to interpret the pwm signals…
It would be nice if there was a electronic circuit we could build that would do this, and convert it to something that the BB2 can get a numerical value from with the least amount of wasted cpu cycles.
–Aaron
Personally I’d go for a small CPLD with a 12-bit counter, 12-bit PI-SO shift register, and 8 channel mux to do the conversion. It would take maybe 4 wires from the controller to interface using an SPI style protocol. It’d be like 3 parts. 
Sounds great 
, All you got to do is write the logic code for the CPLD to make it work?
Eddie … haha draw up a schematic and ill build it, but was thinking more of the lines of something really simple CPLD already sounds complicated… 
If I were to only have my stupid 50x servo extension wires I ordered off ebay about a month ago from china, I would be able to try all these methods to see if I can get away with using Kurte’s or Xans code on this issue, or at least make my own and see what happens with it.
By the way a bit off topic, how do you run code off the BB2 with the serial port linked to it to view live values or debug it?
Sure… straight forward enough in even the old HDL languages like CUPL or ABEL. Verilog and VHDL make my head hurt usually but then again I’m older so it’s probably the pain of thinking how to make the new fangled way of expressing logic do what I can do in only a few straight forward lines of the afore-mentioned HDLs. 
… OK you officially lost me…
Can ugh someone decode that for me ?
Wow , funny stuff…
ok a quick overview, although admittedly off topic so I’ll keep it sort of short.
Digital logic can be expressed as a form of mathematical equations. there are ICs called programmable logic devices (PLDs) that allow their output functions to be written in a programming language as a form of equations combining their input pins and feedback from their output pins. such a programming language is called a hardware description language (HDL). ABEL, CuPL, and PALASM are examples of early HDLs and their syntax resembled very closely the actual matematical equations used to represent the logic. Verilog and VHDL are examples of more modern HDLs and have a much more structured approach that resembles C more than straight equations. Verilog in partcular is used heavily both for coding devices as well as writing test procedures to validate the logic programmed to the devices.
The simplest PLDs were based on an array of fuses much like an EPROM and called PALs for programmable array logic. they had simple output functions like, for instance an or 8-input OR gate where each input was tied to an AND gate that could access every input pin to the device as well as a feedback from each output pin. the programmable part was which of the inputs to the AND gate were actually connected to a signal. there might be 8, 10, or 12 of these (OR + 8 AND) channels in a single package and upwards of 24 inputs depending on the device package size (i.e. number of pins available.) There were more options, the OR gate could drive a D-type flip-flop for making shift registers or state machines, or migh be replaced by an XOR gate to make building addition or CRC circuits simple. The next generation of these devices were called GALs, G for generic, as they replaced a single type of output with an output macrocell which had one or more registers and XOR gates or other specific logic functions which could be selected by programming… very flexible. The next generation is called complex programmable logic device, CPLD, and has multiple GAL devices in a single package which are, in addition to having a programmable array in each GAL, connected internally through yet another programmable fuse array that allows the different GALs to share input signals and pass outputs to other GALs. CPLDs can get quite large, I’ve used parts with as many as 16 GAL sections. Lattice and Xiinx are probably two of the biggest active CPLD developers but there are many others.
CPLD, GAL, PAL is implemented in silicon using EEPROM cell technology. therefore it has some of the same benefits as well as limitations. One of the biggest benefits is you turn on the power and it’s there… vs something called an FPGA (field programmable gate array) which is based on an SRAM cell and requires its arrays be re-loaded from a PROM device every time power is applied. This tends to make smaller CPLDs more cost effective than FPGAs with similar logic capability. Of the disadvantages of EEPROM cell are it’s slower and takes more transistors to implement when compared to SRAM… which is why very large FPGA devices are often comparable in cost to moderately large CPLDs. Many FPGA architectures are also considerably more flexible than the interconnected GAL sturcture of a CPLD. In the end you need to balance all of the factors of capability, complexity, re-programmability (FPGA are generally easier to manage in this regard), and cost when selecting a programmable logic device.
For the project you have been discussing, capturing lots of servo inputs efficiently into the BAP, I would probably lean towards a Lattice Mach 4 or Xilinx XC9500 series CPLD, with somewhere between 48 and 96 macrocells. This is like a $3-5 range part in USD.
Well… I said sort of short anyway.
It has been a long long time for me since I had to look at a hardware description language. Probably back in the ice age at school. I think the language they used back then was AHPL, which was based on APL…
Thanks Eddie for the overview as you said you could probably make a cost effective way of offloading the work from the BAP. I am not sure that it would make it easier for non-hardware programmers to understand.
It would possibly have the added advantage of maybe using fewer of the BAPs IO pins.
quite right of course in it not being much of an at home type solution… really would need to be sold as a breakout PCB with programmed part installed.
ya know I wonder if there is an option there… one of those generic breakout footprint patterns like on a vectorboard or surfboard but on a SSC-32 / BB2 stackable footprint. Could run some through BatchPCB and find something similar for sale on sparkfun a couple months later. 
Sry, my bad. 
well 3-5 bucks aint bad!
Although I think programming one of these with the knowledge I have is probably going to be pretty challenging!
Although I’m kinda leaning more towards code
how do you run code off the BB2 with the serial port linked to it to view live values off variables to debug??
Put this in your program.
serout s_out,i57600,[dec my_variable,13]This will send whatever is in that variable to the DB9 so you can open a terminal window to see the results. Make sure the baud rate in the terminal connect is set the same.
Thanks Jim,
Is this feature in the atom pro software under debug?
I thought I saw something in the atom pro software that was for debugging… this the same kinda thing?
Or was the only way to do this was to use the Lynxterm software as you mentioned.
… Kinda tempted to get a small lcd for debug and mount it…somewhere…
–Aaron
There is also a debug mode, that you can compile the program in a special mode by clicking the Debug button. There are some special commands that only work in debug mode (debug, debugin). In this mode you can step through your program set breakpoints, view variables and the like. This works great some of the time. However if your program is a little more advanced and includes things like assembly language or interrupts or timing loops, etc, the debug mode causes the program to run different enough that you may not be able to debug your actual issue. That is where the serout S_OUT is very nice. I use this a lot. Likewise I quite often have serial LCDS connected to my bot and I use serouts to its IO port as well to output variable contents and the like.
Other times I use the LEDS on the BB2 to help me debug. If you are not sure if your code gets to a certain point, you can set it up to turn on one of the LEDS if the code gets there. On one program I ended up blinking a couple of the LEDS with the value (one led for 10s one for ones…).
So there are lots of ways debug.
Kurt
Hey thanks kurte,
I was going to try and write my own plusin command for this pwm conversion to I can understand the math and convert the pwm signal into usable numbers I tend to think the code I write is pretty simple … alt least when I did VB…
It’s also pretty tempting to order that logic analyzer you have from the website thing looks pretty legit and easy to use might consider buying that, I can see how you would use that to determine which inputs to read in what order on your receiver! quite handy
I find it quite tempting to order another bb2 and Atom pro just for experimenting rather then keep reloading the code on my Phoenix…
I might have to look into one of these serial lcds I wish there was a way to run the code by emulating the atom processor but do it over the serial cable and still able to use its input/output pins and all… “OH WELL”
I like your interesting ways of debugging code I assumed the led’s were not usable with the phoenix code because of those jumpers… I think I’m going to display which gate your currently on in binary with the A B C led’s that would help me quite a bit “on xan’s ps2 code 1.3”
anyway GOOD ideas!
I keep ranting on and on about this silly pwm thing been talking about it 2 weeks and I still have not got my 50 150mm futaba ends I baught off ebay for 1.99 from china! ERRR should have bought 500 if I knew it was going to take this long hahaha SIGH…
Thank’s again kurte
I never use debug for the reasons Kurt mentioned. Using the built in terminal works better for me.
I never mentioned LynxTerm. The programming IDE has built in terminals that are at the bottom of the screen.
Yes a serial LCD is another good way for getting info out of your running program.
You know you could have got these a lot faster and cheaper.
lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44