DIY: Receiving the PPM signals from RC receivers

[kurte]

Hi Jonny,

This was a fun project, as with many other attempts of using the RC receiver, the code spent far too much time waiting for the 6 channels to report data and it took up 6 different IO ports on the BAP. So I did a search on the web to find out if anyone sold a receiver that you could simply get the data from, instead of having to capture the servo signals. Did not find any, but an expanded search did find hacks that allowed you to modify a receiver to get at the signals. The hacks centered around finding the clock signal of an internal chip and bringing that out. That iwhatht this project was based on.

Earlier I thought about doing a different approach, which was to use a second processor like the BAP-1M that you would plug all of the servos into and have it dedicated to reading in the signals, then have some simple protocol to the main processor that allowed it to grab the data whenever it needed it. I did not go this route as the 1M only had 8 IO pins and I also wanted to the spectrum which has 7 channels plus probably 2 for I2C or the like. Plus there was no board designed for these. Could probably do my own, but… Should maybe consider doing this again with an Arduino…

Sorry about leaving the XBee code in that project. That project was set up that allowed me just to change a define or two and use different input devices. Also it was set up that I could at times have 2 different devices, where the first device to talk to the robot (PS2 or XBee), wins… There are several reasons preferredeXBee XBees. The first was it was easy to have the same remote control different robots. This is probably true with the RC as well, you simply have to purchase multiple receivers, although I am not sure how that works with some like the spectrum. Would you have to rebind the two each time you wish to use a different one? Also I like the Bidirectional communications, where I can get feedback, back to the remote. Also I can use a PC to talk to the robots as well, and you can also set up to have the robot potentially talk to multiple recipients. Example the remote control for commands, and to a PC to display or log data…

No problem taking up my time. I like dinking around and am often playing with multiple different projects at the same time. Let me know if want any help here.

Kurt

[likwidchz]

Innerbreed,

You really need a oscilloscope to find that PPM signal, honestly I wasn’t connecting the dots a while ago but they use shift registers to split up the signals!

I built a circuit “not my design” out of an Atiny 2313 which takes the T7C receiver outputs and converts them to a single PPM signal.

I wish there was more RC receiver support as I think its an easy solution for people who want to make something RC relatively easily… Although from Kurt’s work in assembly I find it challenging to understand it and assist without him doing the bulk of the work.

As a side note I was thinking of something like the Arduino Nano to capture one or X number of input channels and output serial data as an example something easily parsed such as my t7c does 7 channels, it would output something like 1500:1500:1500:1500:1500:1500:1500 about 100 times a second. This device would also output buffered signals ie 2x the speed at which the device actually reads the PWM data so that the device itself isn’t a bottle neck.

If a stand alone device was made/sold it would be really nice to see more RC in robotics… I have been working with Kurt off and on for the past couple months regarding his assembly code, but It would really be nice if there was a hardware solution… something tiny, something open source… something easy to use.

If anyone has any ideas feel free to chime in!

–Aaron

[km6vv]

Pulse Position Modulation?

thats right, I guess that’s what they are calling the multiplexed R/C signal from an R/C transmitter.

I did find something about 6 months ago, search for “PPM summensignal”.

jreise.de/PPM/R617FS.html

for an ATTiny2313, rather use a more familiar chip.

Maybe something can be done with it.

Alan KM6VV

[likwidchz]

Km6vv that’s exactly what I built!!
viewtopic.php?f=8&t=7633 scroll down for pictures of my device.
He was helpful in getting my device working. However it really needs a linear voltage regulator to power the receiver. In my testing I had found that it would run at about 4volts as well as my Futaba 7 channel Receiver would as well, but when it went a little over 6.4 volts the output of the ppm signal would die. “testing on a bench adjustable digital power supply”

The botboard runs on 7volts or is able to and regulate it. I wouldn’t want to have to plug the ppm signal in one part of the botboard then in another part have power going to it. It’s a REALLY nice circuit when you see a single 3 pin servo style connector providing power along with 7 channels of data in a single wire… a single 5volt linear regulator would work great for this, and its current draw is less then 100ma so the device wouldn’t even get warm.

I Could probably email that guy and have him edit his 328byte hex for the Atiny2313 and make the signal inverted from what my oscope photo shows in the thread at the beginning of this message… its probably a single byte changed ya know?
The circuit works great! you just need some hardware to program it such as the bus pirate I have all the syntax in his original email for assistance if anyone wants it. The chip is a couple bucks and you can translate the page above but he only captures i believe 5 of the 7 channels the remaining two channels are derived from the time between the adjacent channels… tricky!

I believe that this is the only transmitter its compatible with you would have to figure out the firing order from your receiver to use this circuit.

So not really sure what is more complicated to do PPM to some format or PWM to some format?

[km6vv]

Well I though I responded, but I don’t see it. Musta lost it all.

The circuit splits up the PPM into 7 individual signals, right? Or did I misunderstand (I can’t read German very well at all).

I’d rather have the source code, not just the hex.

Alan KM6VV
Actually, PPM means “Proportional Pulse Modulation” for the R/C use.

[kurte]

As I mentioned in a different thread (viewtopic.php?f=8&t=7633&p=76707#p76707)

I think the same code I did for measuring the signals I did for this one, could be used for the board that Aaron is using. I needed to change which edge of the signal to look at, which was not hard. Also in that thread, I did write up a basic version of the interrupt handler. Did not try it as I don’t have that hardware configuration. I could probably reverse it and hook up my Hacked up receiver.

The code simply uses the input capture of TimerW. When the signal goes high (or low depending on settings), the current timer value is placed into a hardware register. A bunch of the code in it is to do error checking, like what is the state of the signals if the user turns off the transmitter?

From Aaron s scope output in the other thread, it looked like all 7 signals are output… Again would be interested to see if the test program gets anything.

Kurt

[likwidchz]

Kurt - I just managed to sit down and will try this out tomorrow after work!

Alan, I used Google translate on that page, I cant read German very well at all either …

Its just recently I had learned how this assembly code works, it captures the #of clock ticks that a line is high/low and stores it in a memory address then later does some division on it to return 500-2500 integer? so it seems like PPM might be easier on the processor to deal with rather then reading 7 digital IO lines right?

I believe you have something in the assembly code that checks to see if the receiver is out of range or not? I think you can eliminate that bit of code for this particular setup that I have as it would be kinda worthless to use… When I have the oscope reading the ppm signal I turn off the receiver and the ppm signal is still generated. Jorg who was the individual who coded this application Is using used a light detector that was placed ontop of the r617fs receiver and when the light changed from green to red, the signal would zero out. HOWEVER!

I did not choose this option as I did not have a spare light sensor… but apparently the color change from red to green was measurable… Very cool indeed.

So as a side note one of two things can be changed.
Alan I could probably email Jorg and get his source code… infact I think its attached on his site? there is a hex and asm… but I’m sure if you want another source I could probably ask for it?

If there is an available pin left on the Atiny device you could use it to shut off the ppm signal if it has not seen a signal within lets say 10mS as this device only captures channels 13567, channels 2 and 4 off the R617fs receiver are derived from the time in between the adjacent channels… which would be a fix to not use the light detector.

As for Kurt, the same thing could be used for your assembly code to detect an out of range receiver… there would be the main PPM signal on the bot board on pin 10, then possibly a wire coming off channel 2 or 4 off the RC receiver as the fail safe. If No pwm comes out of the receiver when the transmitter gets shut off then it would go into failsafe mode. I could potentially just see the assembly code defaulting to 1.5ms on all channels until pin p9 on the botboard sees a change in pin state… but I’m pretty sure the servo goes limp if the transmitter is not in range… it doesn’t hold the last pulse value…

however for my setup I do not need any failsafe code in it… if its easy to put in great, but for my particular setup I want literally THE DUMBEST thing that works… I don’t foresee my phoenix being more then 50 feet away from me while playing with it.

I’ll try this code tomorrow that you posted in the other forum post Kurt!

Thanks again.

Let me know if anything I typed doesn’t make sense… its been a long day at work.

[km6vv]

I wouldn’t mind seeing the code, although I’m more inclined to put it into an interrupt routine.

You’re wanting a serial string output, right? The serial input stream could be handled with hardware OK, and in the background. And I suppose one could implement the serial output just like a PS2. In fact, that’s not a bad idea. then a software serial in could probably handle it just fine. Then a little chip would be OK. Maybe more versatile.

Maybe the Arduino MAX has a few more interrupt in pins. That would make a good C solution on one processor.

Play with the code I sent. Maybe post it here after you add the setup() and get it working.

As for out-of-range, if an LED is on the XCVR, the a line into the uP from it could give notice of loss of signal.

Alan KM6VV

[likwidchz]

Alright this is the basic idea.

Develop a circuit out of the Arduino Nano or a similar small device… it could be a pic?.. I’ll just leave it at something tiny and enough support around it for multiple people to chime in and support it.

It would be smart enough to work with 1-x number of input pins My t7C has 7 channels
This Arduino nano has 8 analog pins and 14 Digital IO pins. The goal would be to develop code for this device to support 14 PWM inputs or the max for XYZ arduino/pic.

The goal – Connect a RC receiver to an Arduino Nano to digital IO pins 0-6
The output should be via a single IO pin serial data “the output data would be someone would have to agree on that is easily parsable” would look something like this when all 7 RC channels are in center position.

1500:1500:1500:1500:1500:1500:1500:0:0:0:0:0:0:0 <---- That should be 14 inputs what the output would look like IF only 7 inputs are used.

The output speed would be the maximum that the Arduino Nano could support or XYZ device. The output would send data out faster then it could read it, if the value wasn’t read quick enough the previous read of that digital IO pin would be output again and it would catch it on the next pass.

This is the main idea so more people could use RC in robotics as I find its a much cheaper solution… However the ps2 remote offered on Lynxmotion is also a pretty nice deal at less then 30$… which is completely reasonable… This would be for people who want a bit longer range.

Feel free to comment! and give me a hard time.

–Aaron

[kurte]

Personally I don’t like normal Serial type communications for things like this. Why? On Bap you only have 1 hardware serial port, so if it is in use, you either have to to do lots of tricks to make sure the BAP is in a serin statement or you lose the data. And if you do it on using serin, if anything else is hooked up that is doing interrupts, your data will get corrupted. So personally I would either do some other interface, like SPI or I2C, or at least make that an option.

Also only try to send data that is needed. That is if there are only 7 channels, send only 7 channels…

Kurt

[likwidchz]

Yes! these are the things id like to brainstorm.

[km6vv]

You only need the PPM input, not seven discrete I/O inputs if I’m following this.

Kurt is right on the serial output stream, more work to input if input is software driven. Hardware I2C or SPI would probably be better.

Should probably “sync” any output to the 20mS PPM input.

Could interrupt driven PPI input be “interleaved” into an I2C or SPI output? They are the masters, they can determine the output rate (might have answered the previous “sync” statement.

Alan KM6VV

[likwidchz]

Alan,

Well the way I have it now is Receiver --> PPM converter “that Atiny 2313 device” then Kurts assembly code on the phoenix… Which I still have not tested quite yet! as I’m at work and other things came up last night.

However.

My idea is a plug and play device

Receiver 7 wires to Arduino Nano - > i2c/spi whatever format is agreeable… or maybe all formats at once!? at different pins if it does not slow down the cpu… Honestly 20ms per output is 50 outputs per second, if this went down to 30 or even 20 it would still be quite usable! my three cents … 1 cent better then the competition!

–Aaron

[km6vv]

If the receiver already splits up the PPM, why do you need the Atiny to do it? (I must be missing something). Except for the additional pins, (or just use the PPM), an interrupt driven decode routine could run in the background of the main uP. No serial to read!

I suppose if you don’t need the extra I/O lines, then 7 in would be OK. Then you don’t need the PPM line! but simply running a counter and using the interrupt to “parse off” the individual pulse widths might be easier then trying to time 7 INDIVIDUAL pulse I/O inputs. But then they probably come in sequential, so no problem to then read one at a time…

An AtMega 328 chip would be an easy replacement, doesn’t need many support parts, and can be programmed on a UNO.

Comments?

Alan KM6VV

[kurte]

His receiver splits up the signals as you mentioned. You can simply use pulsin to read in the pulses, but you can not do it in one pass, as even if they were just sequential, they come to fast to exit the first one and enter the 2nd one before the 2nd pulse started. You can do it typically in 2 complete RC passes, depending on when you start your input could take 3… So for every pass of reading the data it could eat up something like 60ms, during which time nothing else is happening in your main code. I wrote an assembly language version a long time ago that could do it in one pass, which worked fine for the Hitec and spectrum receivers were things were sequential (not necessarily 1,2,3,4,5,6…), but no overlap. Thing comes along the Futaba, and it turns out some of these signals overlap, which screwed up the code.

Then later, I did the hacking of the Hitec receiver, which intercepted the clock signal going to the chip generating the pulses. This allows you to get all of the information on one IO pin, which is where the this whole thread comes along. Aaron then tries out a new board, that outputs a signal that looks like it is inverted from my hacked receiver. I think he might be able to use that code or the basic version of it and see if it gets him anywhere. Still have not heard anything back on that…

Now if I were to receive the RC data on an Arduino or other Atmega based board, I would probably simply use the Pin Change interrupt for the 6 or 7 pins and be done with it. In fact here is an example of how it has been done: arduino.cc/playground/Code/ReadReceiver

Kurt

[likwidchz]

Kurt. I will test this soon and provide you with what works… I wish you had skype or something as we could communicate a bit quicker.

Alan, Yes that chip looks like it would be fantastic! and at only $4.95 its a cheep CHEEP solution, this might be better then the Arduino Nano… This would be easy to build and put on a through hole circuit board and attach a bunch of pins to it… As for coding for this is there a solution I could potentially start to poke around with? perhaps make an led blink?
I have a spare 2313 handy not sure if the code is the same thing… I’d love to help in some form or another I can certainly build a bunch of these and ship them out if people have requests for them… maybe if we beta something lynxmotion will sell the kits pre programmed…?? any thought to this… The cost to build this device would be sub 10 bucks each… Im thinking maybe around $15-20 per if a pcb was etched and it looked all professional?

I’m jumping the gun a bit… anyone have any thoughts?

[km6vv]

Hi Kurt,

I’m looking at the ReadReceiver example, but so far the TimerOne lib is not compiling. A good example of using the pin change interrupts, as you said.

Could be a candidate, if the compile errors can be resolved.

I know why he flips back and forth between rising/falling edges, maybe he needed to do that for the particular XCVR he choose? What was the “overlap” you mentioned, and on which XCVR(s)? I’m thinking of getting the Futaba 7C.

Alan KM6VV

[likwidchz]

Alan,

This was Kurts post

This is My photo

This is a photo of the PPM output of that Atiny2313 device…

You know come to think about it, if you want me to program one for you and build you the same circuit I did for my t7c I can do that for you! I have some spare parts laying around.

Should I pick up an Atmega328? Would love to learn this coding just need some direction as to where to start.
I think that chip as a base product would be pretty slick as its cheep, just need an external crystal attached to run it at 20mhz are there better options? If we could simply get a really fast chip and have pins output every type of data to satisfy everyone’s needs that seems like it would work well right?

–Aaron

EDIT – you know come to think about it the Atiny2313 also runs at the same speed with an external crystal… its 2k of program space vs 32k but really is this code more then 2k??? does not seem like it… the assembly code Jorg provided was 328bytes… SO not sure if C code is more bloated? or if on something like this if it makes a difference… anyway both of you guys would know more then me… I just cook up ideas!

[km6vv]

The 2313 is probably fine. 168’s and 328’s are on the Arduino boards, easy to use if you want C, or go for BASIC on the BB II. Each can now be run as a stand-alone chip.

Thanks for the offer, I need a 7C R/C first.

Do you want to work in BASIC or C?

So both you and Kurt have 7Cs? I can’t see any way for overlap. So, every positive going edge could be used to advance a state, record the count, and generate a set of counts, the deltas of which represent the needed mS pulse widths.

Alan KM6VV

[kurte]

Hi guys,

Personally, I would try to simply use some currently built Arduino boards… Could work with the Uno or the Botboarduino or the like. If you want a small size one, you can always get one of the Sparkfun ones like: store.nkcelectronics.com/arduino … 28516.html (Can get from sparkfun as well, but used the NKCElectronics link as the sell lots of different Arduinos…).

Note: I don’t have a futaba remote either and probably will not pick one up… I do have a Hitec 6ch and the Spectrum pieces from the first DIY… If I were to pick up another transmitter, it would probably be one that Lynxmotion sells… As you can probably tell, I am more interested in the XBee solutions as I like the bidirectional communications.

However I am willing to help out. If we were to code this properly on the Arduino, I think it would work for most any type receiver… As you can see from Aarons post of the trace of a futaba receiver (I think that came originally from Zenta…) some of the signals overlap each other, which my first assembly language code did not handle. At one point I thought I had the code reworked to handle it, but it was never tested…

Now with the ReadReceiver example. I think that was OK for a quick and dirty version of the code. Which for most cases may be good enough. It may take 3 or 4 passes to get a complete set, but that may be good enough… But if I were doing it for real, I would probably completely rework how the Pin Change Interrupt is used, such that we are not looking at one pin at a time…

My understanding of the the Pin Change Interrupt(s) is that there are 3 interrupts. One for pins 0-7, another for 8-15 and the third for 16-23 (Atmega pins not Arduino pins, need to map…). There is a register that allows you to enable any or all of these interrupts. There is also a register associated with each of these interrupts that you can configure which pins you want interrupts on…

When one or more of the pins changes state and the interrupt is enabled on that pin(s), the interrupt is generated. You then have to figure out which pin changed. One way is to only have one enabled, which is what the example did. Another way would be to have the pin states before the interrupt and the new pin states and see what changed. This is what I would probably do. If you can get all N pins on one data register you could simply read it, XOR it with the previous one and any that changed would be a 1… Grab the timer value, see if value is high or low…

So I might dig up my Hitec receiver and try it on the UNO I have sitting around.

Kurt