PPM Input in UAV Dev Board (Coded And working!!!! with Failsafe!!!!)




Now I've Coded to read the PPM and tested, it's working fine! That means you only need one channel to read all the RC input so you have more 4 channels to play with!


In my case I'm going to use those available channels to read battery and airspeed! Nice!


The code is attached. I don't Know if it works for other receivers but for the FP-R127DF works fine!




Have anybody already coded the PPM input reading in the UAV Dev Board 2?

I've just started changing the PIC PWM parameters but I was wondering if anybody have already done that for me.

I hacked my futaba receptor on monday and I took some pictures of the signal. The component the demux the signal is the Dual 4-bit static shift register BU4015B / BU4015BF and the PPM signal comes in the clock pin. 

My receiver is 7ch but  only use 6, so I've cutted the 7th channel line and sniffed the clock pin in the 7th channel pin.

The picture of the signal is bellow, there was a post in wikipedia that explained everithing about PPM but I coundn't find it again. But I know that the signal goes from 0.5ms to 1.5ms in low logical state and there's a sync period in the end.

Any help is appreciated!


Views: 671


Reply to This

Replies to This Discussion

Actually each servo pulse should be between 1.0 and 2.0 ms nominal, expect down to 0.8 and up to 2.2ms. The servos also expect positive pulses, rather than negative ie their signal pin goes high for between 0.8ms and 2.2ms then goes low for the remainder of the frame time. Maximum frame rate is 60Hz, minimum is 40Hz, nominally 50Hz for a frame time of 20ms, outside of this range expect the servos to not perform to specifications, in other words they may become slow and/or jittery and not produce the speed or torque specified. These are the accepted R/C servo specifications, your mileage will vary.
Oh, thanks for the reply poul.

The signal shown above is the PPM output of the receiver, that's why it's negative pulse. After the signal passes through the demux it becomes a positive pulse in this specification you said.

I'm testing the code now, if it works I'll post it here.
As far as I know, no one has coded PPM input for the UAV Devboard (or the UDB servo-interface by Matt).
Sounds like super work. Thanks for publishing. It would be super to push your work to a temporary branch of MatrixPilot Trunk, and also to republish it as a patch, to make it easy for people to apply to MatrixPilot2.5.1 retrospectively. (If you've not done patches before, then I would be happy to advise you on how that is done.). Best wishes, Pete
Hi Pete,

Actually it wasen't that hard to implement the code because i've just changed it to read the low pulse instead of reading the high pulse. And I've changed the failsafe a bit.

I tried to follow the MatrixPilot software pattern to implement this code, so you just need to uncomment the PPM_RADIO_INPUT directive and configure the minimum pulse width. But i'm very interested about how to do a patch because every new release of MatrixPilot I have to ajust my modifications, and it would be pretty easier if I had a patch.

I'm going to change the code now because I realized that I implemented the PPM reading in a ADC channel, so I'll use a different channel to read the PPM, this should be no troubble. My final goal is to add a airspeed sensor to control the motor, and a voltage divider to measure battery voltage on the pins RB4(I1) and RB5(I2).

If u have any doccument about how to produce a patch I'd be very thankfull.
Ok, Now I've Changed the code to read the PPM signal in the channel 4! Now We're able to read two Analogic signals on channel 1 and channel 2!
Cool !. That is really excellent. Great idea and execution.
fairly good reference on the subject here


there is also a thread on RC groups but i can't find it, i left a post there in the hopes someone will link it so it could be added here too.
I don't have a document ready to hand on how to make a patch. I did a video on using Tortoise SVN, and you should probably watch that (about 5 minutes), and then you should install Tortoise SVN as a preparation.

I will try to write to you later tomorrow or Monday with more details on how best create the patch.
In overview you will need to:
1. Install Tortoise SVN
2. Download the MatrixPilot repository using Tortoise SVN
3. Copy your version of MatrixPilot (all our files) into the correct directory of the repository on your machine.
That will be somewhere like ....\gentlenav\tags\MatrixPilot_2_5_1
4. Tortoise SVN will then highlight all the files that you have changed and show them in Red in MS File Explorer windows.
5. In File Explorer, hover your mouse over this directiory:- ....\gentlenav\tags\MatrixPilot_2_5_1
and right click on your mouse and select .... Tortoise SVN / create patch
That will then show you the files that will be changed, and let you save the patch to the filename of your choice.

There is one catch with the above. The patch will contain all of your options.h changes. So really you need to keep the original options.h, and just change it with the lines that define PPM usage. Then re-do the patch using the clean options.h with the one change for PPM.

That is rather a short explanation, but you may like to try that before I write further. Best wishes, Pete
Thanks Paul! That was very usefull
I have been modifying your code for MP3. I would like you to take a look at it.

Regards Matt
Ohh... good idea to use the frameok bit!!! im gonna add that to mine.

De PPM_ADJUST variable that u've commented WHY? is used to adjust the input value of my receiver to the normal 2000 to 4000 value.

My receiver gives me a low pulse from 500us to 1500us, then I add a 1000 to the timer conversion so the input goes from 1800 to 4000.

got it?
Glad you like the frameok idea. I was not sure about it.

It also checks the range of the failsafe channel.
Some receivers might output a PPM signal during failsafe. Only checking if the PPM signal is valid is not enough.

WHY? is there because I did not understand why you need to do this.
I thought that the high pulse period should be added to the low pulse time.
If this is correct, we should re-write the code to add the actual high pulse time and remove the PPM_ADJUST.

A point of preference:
I prefer to write completely alternative files like the one I sent to you.
It is easy to remove radioIn from your MPLAB project and intert the new file.
The code is much easier to read and maintain. Especially for other developers.
If you make mistakes in your new code module, it doesnt mess up all the normal users.

This is just my preference. Your style is your choice. I only wish to make you aware of this alternative.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service