Switching PWM to Direct Voltage?

[rdf0011]

Hey all-

Is there a way to switch a PWM signal, such as one from a UAV autopilot, to a direct voltage.

The reason I ask is because I am researching whether or not it is possible to control general aviation type autopilot servos with a UAV autopilot board.

Thanks in advance for the responses!

[rjet]

I don't think any of us are familiar with the signals used to control general aviation autopilots. You might be able to build a translator of sorts using a microcontroller to convert the signals to DC, but the best option may be to contact a UAV autopilot manufacturer and see if they would be willing to modify their software and/or hardware for your application.

[kd7ost]

Hey all-

Is there a way to switch a PWM signal, such as one from a UAV autopilot, to a direct voltage.

The reason I ask is because I am researching whether or not it is possible to control general aviation type autopilot servos with a UAV autopilot board.

Thanks in advance for the responses!

This is just for your thriller novel though right? UAV autopilots found among us, the hobby group, don't meet any FAA specs for any use on any manned aircraft for control. So even if it can be done,,,,,,,, you get the idea.

It's like that show on TV if you ever saw it called "Mythbusters". They have used what appears to be high end JR or Futaba Radios and some other mechanical gear to remote control full size cars for crash testing and the like. They did it, but they won't get and aren't looking for any DOT endorsements
to take it on the highway.

Dan

[Cats Eyes]

UAV autopilots found among us, the hobby group, don't meet any FAA specs for any use on any manned aircraft for control. So even if it can be done,,,,,,,, you get the idea.Wow. I never thought of that! :eek:

I'm sure the CIA (& CSIS here in Canada) are looking over our shoulder anyway, we don't need something like that getting us into trouble. Hear that, guys, we're all responsible, law-abiding, government-fearing citizens that wouldn't hurt a fly and would report any suspicious activity to the authorities immediately! Right, guys?! :rolleyes:

Maybe rdf0011 better tell us exactly what he's planning on doing with this before we go any further, eh? :D

-- Kevin

[kd7ost]

Wow. I never thought of that! :eek:

I'm sure the CIA (& CSIS here in Canada) are looking over our shoulder anyway, we don't need something like that getting us into trouble. Hear that, guys, we're all responsible, law-abiding, government-fearing citizens that wouldn't hurt a fly and would report any suspicious activity to the authorities immediately! Right, guys?! :rolleyes:

Right

Maybe rdf0011 better tell us exactly what he's planning on doing with this before we go any further, eh? :D

-- Kevin

We might not want to know on this forum. It is a bit strange in the thinking to try to put Micro UAV guidance packages into Cessna's and Pipers. Or is it? Hmmmm. Better keep an eye on this Tex!

Dan

[kd7ost]

http://www.rcgroups.com/forums/showthread.php?t=383147

I think as we ponder this idea, it really isn't a good one. (IMHO) It bears no viable application from a RC Groups.com UAV standpoint.

Dan

[LukeZ]

The dubious nature of the intended implementation aside, it seems to me that rdf0011 is asking a rather legitimate question, which is simply can PWM be converted to a variable voltage? I don't see a problem in answering a question about basic electronics, and the answer is yes, you could do it with about one resistor and capacitor (though it would most definitely take more than that to drive the kind of servo you're thinking about). Do a Google search on PWM to voltage and you'll find plenty of links and schematics.

Of course it's good to promote common sense, but all the same I'd like to help people learn where it's possible. I know I've had plenty of dumb ideas myself, but usually in there somewhere I was trying to learn something actually useful and good to know... well, pretty much ;)


LukeZ

[Cats Eyes]

... and the answer is yes, you could do it with about one resistor and capacitor ...
Actually, you need a non-linearity in there as well, for instance a diode.

In fact I've done almost exactly this for an analog brushed ESC implementation (before I discovered the magic of µCs). I found a transistor worked better than a diode, mainly for impedance matching purposes. This produced a varying voltage that was roughly proportional to the input PWM duty cycle. This voltage was fed to one input of a comparitor; the other input was a 3KHz triangle wave; and the output went to the switching MOSFET. Worked very well.

You could easily modify this circuit to produce a variable-voltage output. (Refer to the signal path up to the input to the "Throttle" op-amp.) Then you'd need an op-amp as a buffer and to do any amplification and/or level shifting that might be required.

-- Kevin

[kbosak]

). I found a transistor worked better than a diode, mainly for impedance matching purposes. This produced a varying voltage that was roughly proportional to the input PWM duty cycle.
-- Kevin
Hi, I did some research on the web, but everybody states that R-C filtering of PWM produces serious lag and has inherent nonlinearity due to capacito charge characteristics.
How do you fight those factor with transistor or diode?

My idea is to get rid of servo signal jitter by using ATMEGA32 with 8 analog inputs (10 bit resolution). Other methods of capturing at least 8 PWM servo signals at once in a single chip without jitter with 10bit resolution ended up at 200MHz uprocessor requirement or FPGA or CPLD even using the best interrupt-driven techniques. Note: the specs is that the raising and failing edge may of any of the PWM channels may occur at any time (f.ex think about Futaba PCM and Spektrum). THis is for servo capture datalogger project.

[Cats Eyes]

I'm no expert here, but I'll throw in a couple of notes.

First off, just to put things in prespective, in an ESC, non-linearity and lag are non-issues, because the pilot is in the feedback loop. The pilot will adjust the throttle stick to get the throttle he wants, moving it up if it's too slow and down if it's too fast, so the absolute position of the throttle stick for a given throttle output is largely irrelevant. And for most applications, a slow throttle response is actually beneficial. In the odd instance where you really need fast throttle response, you would generally not rely on the ESC, as the momentum in the motor/prop limits response time, and would instead go with a variable-pitch prop. All of which is to say that the transistor and capacitor scheme I came up with was quite sufficient for my application, though would not perhaps be of use for yours.

Secondly, I would question whether you really need to detect rising/falling edges at any time. I'll have a look at my XPS RX just for fun, but I suspect they sequence their channels, just like 27MHz RX's, even though they don't strictly need to. Anyone else checked this out for Futaba or Spektrum?

In actual fact, the lag problem can be solved and the non-linearity problem can be reduced considerably. At one point a few years ago I made a circuit out of a number of op-amps (must have been at least 4) that would follow a PWM signal pretty well instantaneously and fairly linearly. It worked like this: The pulse would ramp up an integrator (here's where the linearity is introduced). At the end of the pulse, the integrator would stop and a sample-and-hold circuit which would sample the output of the integrator at that point. The sample-and-hold circuit transfers it's "sample" to the output right away (here's when the lag is eliminated). After a short delay, the sample-and-hold circuit would then go into "hold" mode and the integrator would be ramped back down to zero in preparation for the next pulse. If the output of this circuit were fed to an A/D converter, I think it would largely achieve what you want.

I say this just to mention that it is possible. In your application, if you need a quad op-amp (14 pin DIP package) for each of your 8 channels, it might be a bit unwieldy. Why not instead devote a small/cheap microcontroller such a PIC12F629 (8 pin DIP, about $1.50 each) to each channel? So each controller would just measure the pulse on one channel and could send out the results on some kind of bus when polled. With interrupt-driven firmware, the 12F629 could measure the channel pulse to 1µS resolution.

My 2¢

-- Kevin

[kbosak]

Secondly, I would question whether you really need to detect rising/falling edges at any time.

This is for sure.
Futaba PCM outputs servo signal in pairs - there are many traces of it on the forum and I have tested on an oscilloscope on 4 types of futaba receivers (new - old, double and single conv.).


Why not instead devote a small/cheap microcontroller such a PIC12F629 (8 pin DIP, about $1.50 each) to each channel?

It would be cool but we must understand that in such case I need some 10 PIC12F which in DIP package will use a lot of space.
So I need to make a board, in practice a board of PIC12 with surface mounted elements. All this is possible but the final in my country is 11x3USD=33USD for the chips only (cmon you can have 200MHz ARM9 or 11 for that price), and a lot of work, giving finally a very ugly design.
Worse, in order to have coherent results I need external oscillators. A lot of mess.

The whole idea of zero-jitter operation is not for nitpickers or theorists. I want to be able f.ex. to detect PCM failsafe state.

(BTW is your cat a 'norwegian forest cat'?)

[zik]

Hi kbosak,

I think Cats Eyes is suggesting the use of a single PIC to watch all the PWM inputs simultaneously. This is definitely workable - in fact I do it in one of my autopilots.

I can think of a few ways of doing the analog outputs but I think I'd just use an 8-channel DAC such as a TLV5608. That way you just have two chips - a PIC and a DAC. Simple.

[Cats Eyes]

It would be cool but we must understand that in such case I need some 10 PIC12F which in DIP package will use a lot of space.
Yes, but my point is that trying to implement an analog solution (fairly linear and with no lag) is going to take a lot more board space than a one-PIC-per-channel solution. If I remember, I used at least 4 op-amps, which is a 14-pin package vs. an 8-pin package if you use the PICs.


... in order to have coherent results I need external oscillators. A lot of mess.I agree. I just threw it out as an idea. Probably not very workable.

I think you are probably going to have to hook up your receiver to a 'scope and figure out exactly when each channel starts and stops, and figure out your solution based on that. For example, if as you say the rx outputs are in pairs, then maybe you could use just two controllers, one for each channel in each pair?


(BTW is your cat a 'norwegian forest cat'?)I'm afraid I don't really know. Probably just an American Shorthair, but she had little ear tufts so there might have been some Pixie-Bob in there somewhere. Her lineage is shrouded in mystery (we were her fourth owners, er, slaves), as is the origin of her name, which was "Panda." (I use the past tense as unfortunately she passed away in June.)

-- Kevin

[dmgoedde]

I would do this:

1) u-controller measure the width of PWM signal by rising and falling edge, thus scalable to several PWM inputs (but you need a fast assembly rouinte in a u-controller)
2) u-controller does whatever math is required
3) u-controller sends signal(s) to DAC
4) DAC is part of a circuit that gives properly scaled and leveled analog voltage output.

There is no need to use a crude RC method, as the lag (problem or not) is unnecesary. The method I outlined would have minimal lag.

Dean

[Mel Duval]

http://www.edn.com/article/CA6372821.html?nid=2431&rid=1336869726

[kbosak]

I would do this:

1) u-controller measure the width of PWM signal by rising and falling edge, thus scalable to several PWM inputs (but you need a fast assembly rouinte in a u-controller)
Dean
No no no this is not that trivial, I have to repeat to 90% of ppl since almost everybody is using PPM receivers. In PPM receiver you can do any of the 2 or both:
-grab the singnal line just at shift register's pin. You will get a series of PWMs for all channels on a single wire. Trivial for a single uc, I did it, you did it, many ppls did, paparazzi project ppl did.
-(NONINVASIVE) grab all signal lines frolm PPM receiver for all servos (6-10 cables of course), connect all to single 'interrupt-on-change pin', use 6-10 timers and go. Usually needs 2 atmegas 128. there migh be 1-chip solutions and more clever coding methods.

PCM receiver:
-serial 'all signals together' doesn't exist (because the sum of all duty cycles for all channels exceeds total update period)
-signals are emitted in pairs

Spektrum receiver:
everything emitted simultaneously, so even more difficult, other problems like PCM

We have a thread:
Help! - Capturing Receiver Outputs
http://www.rcgroups.com/forums/showthread.php?t=752440&highlight=receiver+capture
Read it and you will see that we have 'strong scientific/engineering evidence' that NOBODY did universal (manufacturer-independent, noninvasive), truly zero-jitter, 1024 or 2048 resolution servo capture for PCM or Spektrum receivers in less than 2 chips (the last only for PCM only in theory and under development, is a new idea by shanghai_fool).

[kbosak]

http://www.edn.com/article/CA6372821.html?nid=2431&rid=1336869726
Nice, straight text. I learned a lot about practice from it.

[kbosak]

CatsEyes:
14-pin package vs. an 8-pin package
yes this is a good point. 8-pin SOP with PIC12F683 or something looks to be the smallest reliable solution.

Signals order:
Futaba PCM ordering identified in 'Receiver signal capture' thread. It is really one pair then another then another.
'For example, if as you say the rx outputs are in pairs, then maybe you could use just two controllers, one for each channel in each pair?'
Very short-sighted solution:
1. works only for Futaba PCM, when I want to mighrate to Spektrum in 2-3yr timeframe.
2. one changed pair of signal cables and jitter comes back
3. useless for capturing the PWM emitted by gyroscope or FMS co-pilot etc since it can be at any moment, colliding in time with signal from ANY other receiver channel.

[Cats Eyes]

Very short-sighted solution
Well, really, no need to get nasty about it. ;) You didn't specify your requirements. You mentioned nothing about supporting any RX, nor did you mention gyroscopes or co-pilots. From what you're saying, you want a single-chip solution that will measure, accurately, gitter-free and with no lag, multiple channels of PWM where any channel can change at any time. Good luck, but I doubt you'll find such a thing.

The main problem I see is, if you have two channels that start or end very close together, say 1 or 2 microseconds apart. The first channel is going to trigger your interrupt routine, but no matter how small your interrupt routine is, and no matter how fast your processor, it isn't going to finish before your second channel triggers another interrupt, which you'll miss because you're still in the interrupt routine for the first pulse and haven't re-enabled your interrupts. So the second interrupt won't be triggered until you've finished processing the first, throwing the timing way off.

If, as you say, any channel can start or end at any time, it seems to me you really need to have some dedicated circuitry for each channel, at a minimum a gated counter which can be read out later. It would be nice if you could find a microcontroller that has a whole slew of gated counters which you can assign to input pins. I haven't kept up on all the controllers out there, but it's possible that such things exist. Other than that, I just don't see a firmware solution other than dedicating a controller for each channel.

-- Kevin

[kbosak]

Well, really, no need to get nasty about it. ;)
I sam sorry I sound sometimes so harsh. I am lacking the vocabulary sometimes and using almost-matching words leads me to construct the phrases I wouldn't say in my primary language (Polish). :o

[kbosak]

The main problem I see is, if you have two channels that start or end very close together, say 1 or 2 microseconds apart. The first channel is going to trigger your interrupt routine, but no matter how small your interrupt routine is, and no matter how fast your processor, it isn't going to finish before your second channel triggers another interrupt, which you'll miss because you're still in the interrupt routine for the first pulse and haven't re-enabled your interrupts. So the second interrupt won't be triggered until you've finished processing the first, throwing the timing way off.

Exactly. I knew this. Only one small objection:
If I will be able to make an interrupt routine that assigns flags or starts/stops N (say 8) 16-bit counters, all this in less than 1 us, I would do the job by software.
For this I need a uC that will execute around 100...1000 instructions in 1us and very carefully written assembly routine.
1e2*1e6: 1e8 MIPS machine would do the trick, 1e9MIPS RISC machine would do with ease. So a tiny 100MHz...1000MHz :eek: RISC uProcessor dedicated just for this task would do the trick. Easy :rolleyes:
Plus a few inches of heavy-duty power supply cable.

At the end of this I wonder: is the whole idea of PWM a sort of one-way conversion? Technically it looks so, very easy to decode by analog op amps but a nightmare for digital tech.
There are so many PWM generators that there is practically impossible to me to find dedicated ...err... PWM decoders?

[kbosak]

Here it is, here I found:
http://homepages.which.net/~paul.hills/Circuits/RxDecoder/RxDecoder.html
Receive Signal Decoders

Perfect description.
Of course a few parts per channel.

[pmurray80027]

I have just finished prototyping a device to log data for a UAV project. It is intended to help me tune my filters in the INU I will build. What the device is intended to do, while an RC plane is flown manually, is record the PWM servo signals, the sensor data, add a time stamp and record it to a flash memory card.

I was initially going to implement this in an Altera FPGA but instead I used one of Atmel's AVR's that have an FPGA combined with it.

The device works quite well in that, for each channel, the servo PWM width time is computed in hardware and the value is placed in a register and an interrupt is pulled for the software to grab the value and write it to flash. There seems to be plenty of bandwidth and accuracy.

In addition, the flash I am using is a microSD using the SPI interface. The software also has a file system that allows the data to be written in a FAT16/32 format. The file system will make it easy to plug the flash into a computer and extract the data for analysis.

For several reasons, I am not that pleased with the Atmel part and have decided to use an Altera - so I will be converting what I have done so far to a new platform. However, anyone who is interested in the C & VHDL source files I have at present, you are welcome to them.

plm

[kbosak]

I am interested. Any docs to kbosak at box43.pl please?

I bet shanghai_fool (Donald Nash) would be interested as hell in the design.

I was about to go for FPGA with the beginning of the new year.
The choice of company is not forever, but is an open question. I would appreciatye your comments on what was uncomfortable with AVR-with-builtin-FGPA mixture.

[pmurray80027]

kbosak,

Files sent.

My issues with the Atmel part were primarily the tool licensing and chip support.

First, I had to buy their evaluation board before they would give me a license. The board was cheap, so money was not the problem but, I would of liked to of seen how good the tools were before making a commitment.

Once I got the board they were not able to get a license to me for a week because their license generator was not working. The license is suppose to be a 5-month evaluation license but when I received it, I was told that it was only good for one month because they were still having trouble with the generator and that they would send me a new license in a month to cover the balance of my evaluation period.

A week before my one-month license was to expire I asked them if they were going to be able to generate a new license. Well, I did not get a warm and fuzzy feeling that this was going to happen. The license expired and I still have not heard from them. I guess that I just don't feel the chip is something they plan to support much longer.

I used their AT94K10 chip which is one of three that they offer (AT94K5 and AT94K40 are the other two). Aside from price, the three parts basically differ by the amount of gates for the FPGA section. To implement my logic design I had to cut down on the number of PWM input channels in order to get the part to place and route - I don't like these situations with FPGA's. I don't want to be fighting routing issues.

I figured that I would probably go with the largest part, the AT94K40, for the final PCB, but, now I am in a price range that a comparable (price wise) Xilinx or Altera and they would give me a lot more horsepower and gate size.

I have also been evaluating this past year the Altera embedded Nios II processor, in an evaluation mode, which is all free until you decide you want to use the IP. I have always liked the Altera tools over the other offerings from other companies and the Nios II processor has a lot more processing ponies than Atmel's AVR.

The Altera part will cost more for the chip and IP licensing but, that is not a consideration for me since I am doing this for a hobby and not a business. When it comes to hobbies, if I can afford it I do it.

plm

[Cats Eyes]

I am sorry I sound sometimes so harsh.
Don't worry about it. The winking icon ";)" means I was just kidding. I was "pulling your leg." There's an English idiom for you to look up!

-- Kevin