Maybe someone has 'been there, done that', and can help me here.

I'm struggling with part of a UAV design for a custom control board. The part with (as the title suggests) is responsible for the PPM decode (from the Rx), and PWM synthesis (to drive the servos).

Basically, it 'works'. The problem is that the 'jitter' on the PWM outputs is significant, and outside of the deadband on just about every servo that I have tried (over 10us).

The design uses a 16F88 PIC, clocked at 20MHz, with the PPM driving one of the GPIO lines, and 5 PWM outputs emitting from others.

I've looked at various ways to this, but keep hitting against brick walls when I try to reduce the jitter in the output. Here goes on the more technical details.

The basic problem is that during one 22ms PPM frame, I don't have enough time to decode 7 channels of PPM, and encode 5 channels of PWM, plus i2c communications with another device, without the PPM and PWM overlapping to some extent.
When the processor is busy processing an edge on the decode side, the encode side is delayed, and vice-versa. Using interrupts doesn't really help since the interrupt latency on this part is fairly significant, and adds to the jitter.

One thought was to use do something quite extreme, and 1/2 the frame rate. Interleaving PPM frame decode, with PWM encoding. This would 1/2 the frame rate to the servos. Is this something that is commonly done in the UAV controller world?. All of the servos that I have tried don't seem to be upset about the 1/2 frame rate. Of course the holding torque is reduced, and the speed is lower, but for UAV purposes with a fairly slow model it sounds reasonable.

Another thought was to reduce the number of channels supported. With only 4 channels decoded, and 4 channels synthesized, the problem goes away, but when you include Rudder, Elevator, Ailerons, Motor, Camera shutter, Camera position, you quickly exceed 4 channels. Of course, then there is the autopilot on/off which consumes another channel.

Yet another thought was to synthesise the 'jitter-sensitive' channels (Rudder + Elevator + Ailerons) while simultaneously decoding the 'jitter-insensitive' channels (Camera shutter, Motor, Autopilot on/off.

Of course then there is an additional problem, when the receiver is out of range, or the transmitter is powered down. The output of the receiver that I am using (Hitec electron 6) emits noise on the PPM output, which of course the PIC attempts to decode. Since there are many, many edges during the frame period this negatively affects the PWM synthesis timing. When this is detected its not possible to simply ignore the PPM, because when back in range I need to detect the request to turn the autopilot off.

My apologies for the rather verbose post here. I'm Hoping that someone can give some advice.

-- Anthony

Anthony,

I'm not a software guy so can't help you with code. But I'm a hardware guy that would probably use a hardware fix. You can get a servo controller for a fair price. Here's a few options. You only need to output a pulse to each servo once and the controller will continue to replicate the pulse. Up to 8 channels or better depending on the model you adapt. If you need to update a pulse for control purposes, you'll need to send a new pulse with proper duration for that particular servo. I don't know if this will help you but I hope it does.

http://www.seetron.com/ssc.htm
http://www.lynxmotion.com/Category.aspx?CategoryID=52

Dan

Originally Posted by AnthonyRC

Of course then there is an additional problem, when the receiver is out of range, or the transmitter is powered down. The output of the receiver that I am using (Hitec electron 6) emits noise on the PPM output, which of course the PIC attempts to decode.

If you use a failsafe receiver, the output of each channel can be pre-set to a chosen position (usually neutral or close to neutral). This will only ocur during lost signal conditions, and should solve this problem.

With some work, you should be able to sense this with your PIC chip, but it sure is easier to buy a failsafe receiver.

There are probably more, but here are a couple receivers.

FMA FS5 , a 5 channel failsafe reciever
FMA FS8 , an 8 channel failsafe receiver with copilot capabilities

Walter

Anthony,

As Dan mentioned there are already a lot of boards out there that might meet your needs, for an even larger list you might check out this thread: http://www.rcgroups.com/forums/showt...=459418&page=2

However, it sounds like you want to go the DIY route and that's fine. I can't offer very many specific suggestions, except, as Dan noted, that maybe you could come up with some hardware solutions.

It seems to me that camera shutter, and autopilot on/off don't need to be much more than, uh, on/off. Depending on your camera, you may be able to build a hardware shutter trip with a minimum of components. There's lots of good circuits in the DIY Forum as well as the AP forum. Mr. RC-Cam has lots of projects over on his site: http://www.rc-cam.com/projects.htm.

For the autopilot on/off you might consider a circuit similar to what Jay Francis was selling a while back here: http://www.rcgroups.com/forums/showt...=6#post4564161. His RX-Mux was a complete hardware solution for switching servo commands from two sources - RX or autopilot.

Anyways, these might cut down by a few channels the number that you need to decode, perhaps freeing up just enough extra time for you to accomplish what you're trying to do.


Luke

Anthony, I'm very interested in the exact features you list that you have working (decode 4 channels, output 4 or less). Check your PM!

Dan

Just a short message to say that this problem has been solved, although at slightly reduced specs.

The simultaneous PWM approach was considered, but the current summing is a killer.

The final approach was to reduce the number of channels to decode to 5 (Ail, Rud, Elev, Motor, Autopilot on/off/mode, and the number of channels to encode to 4 (Ail, Rud, Elev, Motor).
This allows for the 5 channels to be decoded, then the 4 channels encoded sequentially, leaving just enough time for an i2c chat with another uP on the board.

The solution results in absolutely rock-solid servo positioning with no noticable jitter (i.e. pwm jitter is within the servo's deadband).

This solution also allows the garbage that emits from the Rx when out of range (or Tx Off) to be processed without affecting the PWM outputs.

Originally Posted by AnthonyRC

Just a short message to say that this problem has been solved, although at slightly reduced specs.

I am very interested on details.
My understanding was that in order to keep PWM capture working reliably with Futaba PCM (that emits servo pulses in pairs - per channel), I needed many independent (6? 8?) PWM CCPM modules - while PIC16 series has at best 2.
Simple calculations shows that in order to capture with 1024 resolution, when teh difference of the lenght of duty cycle is 1ms, I need a system that has not more than 1us jitter for PPM receiver and not more than 0.5us for Futaba PCM receiver. With PIC running at 20MHz, instructions are executed at a rate of 5MHz, so one upinstr. takes 0,2us. I cannot imagine interrupt handling on PIC capturing the actual state of PWM requiring not more than 2.5 instructions. For this reason I believe it is not technically possible to capture PWM with 1024 precision using mid-range PIC microcontroller, unless we use dedicated PWM capture modules.
For this reason I am trying to move to ATMEGA162 which has 8PWM modules as I understand. What is your solution?

Hi kbosak,

I think you're confusing interrupt latency with instruction rate. Let's just say that your PIC interrupt handler always takes 10 instructions to register an input change. It's deterministic - it's always the same 10 instructions that it takes to do the job - so all you do is take into account that your event happened 10 instruction periods earlier.

In your example if your instruction timing is 0.2us then your resolution will also be 0.2us. This is ample for 10 bit resolution. (In fact you could do a couple more bits of resolution if you wanted)

Originally Posted by zik

Hi kbosak,

I think you're confusing interrupt latency with instruction rate. Let's just say that your PIC interrupt handler always takes 10 instructions to register an input change. It's deterministic - it's always the same 10 instructions that it takes to do the job - so all you do is take into account that your event happened 10 instruction periods earlier.

In your example if your instruction timing is 0.2us then your resolution will also be 0.2us. This is ample for 10 bit resolution. (In fact you could do a couple more bits of resolution if you wanted)

I believe I am not confusing it even if it wppears to be so from my post. I was just estimating that it takes not less than single uP instruction to jump into interrupt routine. Extremely, naively optimistic case I would say. Even then, the processing appears to be too slow.

Imagine and interrupt handling routine, that must notice the raising edge.
This is how I suppose this routine to be written:
Suppose that Futaba PCM raises its edges simultaneously on CH1 and CH2 as is used to do. PIC calls proper interrupt handling routine (at least one uP instr, or maybe ten), by some quirk selecting CH1-related interrupt to be raised first (it could have been CH2 as well - depending on which input pin is hotter and conducts better...). In the routine you are starting to do the job, you verify than input line corresponding to CH1 is up as expected but in a next clock or so the interrupt from CH2 is raised. PIC has single level intr priority so the first interrupt must finish (as I understand). So the interrupt routine continues handling CH1. It raises some flag saying f.ex. PWM_SIGNAL_HIGH[CH1]=1 (at least one instr expended if we use named variable in C), affects actual PWM_SIGNAL_RAISE_TIME[CH1] (16bit counter, so >=2 instructions expended if I use named variables). So we spent 4 instr+ the time to call the intr routine handling CH1. And only then interrupt routine for CH2 is called (it could be physically the same function). But it is some 4...10 instructions later. So for the CH2 its time of rising edge will be shortened by the duration of those around 4...10 instructions, what is longer than a period corresponding to 1/1024th of 1ms. Isn't it?
In general you don't know what is channel 2 and what is channel 3, and which is supposed to be paired with who, simply because I need my PIC to register the inputs for post-flight processing.
If Futaba is setting CH1 and CH2 up, the PIC may raise interrupts in any order. You don't know that if you detect in intr. routine that CH2 is high, it doesnt means that CH1 was,or is about to be high. Wlso I don;t want to make something cryptic that will correct itself just for specific model of futaba just to discover that PCM 2048 or something emiths channels in different order - thsi is not a good design as such, I will have much more details to care about later.
Unfortunately, channels from Futaba PCM may go through a gyro, FMA Co-pilot or whatever. On top of this is that my interrupt routine on failing edge has potentially a lot to do (do the math that computes the length of the actual cycle, check valid length, keep old value if invalid or go error state etc.).
At the end of it, I really need 10bit resolution if I want to drive camera pan/tilt servos with the PIC.

You might advise to use shared intr handling routine, check what channels are up then do the bookkeeping, but this is not simple. some channels are ups since a long time already and got their raising time noted, a pair of channels just appeared and both want to know the actual value of 16 biut timer for further processing etc. This will require if() for each channel to check RECENT_UP_BIT[CHn] followed by optional affectation of actual timer value. Worse, the fact that futaba emits CH1 and CH2 in parallel doesnt means that at the beginning of the shared interrupt handling routine both input lines will be high! one might be up at the beginning of intr routine, the other might be up sometime later and will go unnoticed during the lenghty shared bookkeeping, and will be handled in a second call to interrupt routine, this time after very long processing of the first call.

Originally Posted by kbosak

I am very interested on details.
My understanding was that in order to keep PWM capture working reliably with Futaba PCM (that emits servo pulses in pairs - per channel), I needed many independent (6? 8?) PWM CCPM modules - while PIC16 series has at best 2.
Simple calculations shows that in order to capture with 1024 resolution, when teh difference of the lenght of duty cycle is 1ms, I need a system that has not more than 1us jitter for PPM receiver and not more than 0.5us for Futaba PCM receiver. With PIC running at 20MHz, instructions are executed at a rate of 5MHz, so one upinstr. takes 0,2us. I cannot imagine interrupt handling on PIC capturing the actual state of PWM requiring not more than 2.5 instructions. For this reason I believe it is not technically possible to capture PWM with 1024 precision using mid-range PIC microcontroller, unless we use dedicated PWM capture modules.
For this reason I am trying to move to ATMEGA162 which has 8PWM modules as I understand. What is your solution?

I guess there is a slight confusionhere. As the title of the thread suggests this was a question of PPM decode, and not PWM. It was the single PPM stream emitted from a modified receiver that was being decoded, and not the individual servo outputs.

Hi kbosak, I actually have a system very much like this in my "SkyBot" autopilot. I just handle any and all pending interrupts in the interrupt handler. Works for me!

Sorry AnthonyRC - I know this is off topic...

Hi Anthony! If you were using Cypress PSOC chips instead of PIC ....
Even cheapest ($0.80) chips like CY8C21123 have enough hardware resources to decode/encode many (I use 7) channels practically without jitter.
I mostly use CY8C21234 connected direct to FM detector, one chip controls airplane, video link, K2 LED beacon(plus dropped frames warning), digital camera (on/off,focus,shutter) and TX for locating lost plane.

I have the pod kit from when they first introduced the PSOC. Do you know if that works with the newer devices?

U can get PIC assembly from vicacopter.com that does this using a 40Mhz clock and a very tight polling loop. This loop also does A/D conversion, 115kbit serial port I/O, and SPI I/O. There is no PPM. The remote control uses CRC checked phase shift keying to eliminate errors.

Originally Posted by AnthonyRC

I guess there is a slight confusionhere. As the title of the thread suggests this was a question of PPM decode, and not PWM. It was the single PPM stream emitted from a modified receiver that was being decoded, and not the individual servo outputs.

And that's the point. I posted off-topic! Sorry.
I did it mostly in desperation, looking for efficient method for general PWM capture suing PIC.

What I am trying to do is PCM-Receiver PWM decode using non-invasive methods. I am aware that f.ex. Paparazzi project used direct connection to the output line, but in PCM receivers it is not that well documented (where to steal this signal).
The people saying this 'works' apparently are using non-PCM receivers. I confirm that in PPM case everything is easy to be arranged, f.ex using PIC Interrupt-on-change feature. I am still battling with with the PCM simply because I believe and agree with what JettPilot said once somwhere, that when using PPM Receiver at the edge of reception when using FPV setup, you cannot always distinguish turbulence from glitch, what limits safe FPV flying in windy conditions to fairly small radius.
I believe that PCM output decoding is an unsolved problem on this forum - there are even some magic non-working solutions for interfacing PCM with Co-pilot etc. but this loks like a gray area. Anyway, thanks for advices I received.