PWM Detection

Howdy Group,

I'm currently working on a project which requires detecting a PWM train using a microcontroller. The pulse width must be between 800ns and 35us to be considered valid, and the duty cycle must be 1% +/-

2%. Additional requirements are: 1) The uC be in as small a package as possible, something like an 8pin Atmel AVR uC or PIC may do the trick. 2) No external oscillators may be used. I believe this is due to the device being used in an RF application.

I was looking at possibly using an ATtiny25 family from Atmel. My thinking was that if I could use the edge triggered interrupt, start a timer to measure the pulse width, if that width is within the valid range, start the timer to measure the LOW time, and go from there, accounting for interrupt latency and clock cycles for executing instructions. If I tune the oscillator to 5 MHz, I could get a timer to increment ever 200ns, and overflow at 51.2us. That seems to be good for timing the pulse width, but won't do the job when it comes to timing the low time.

Using the above approach, I thought it may be possible to change the counters prescaler value to accomodate the time needed to measure the LOW time, or use a second timer with the prescaler value set appropriately, but I have a feeling that I may get myself into some trouble going that route.

Of course, I may be way off on the way I am approaching this, so any advice or direction would be greatly appreciated.

Regards, ~clark

Reply to
clark
Loading thread data ...

Your approach is almost there. To remove the interrupt latency effect use the timer in input capture mode, looking for edges, rather than just just waiting for the edge and starting to time. In capture mode you get a time stamp at the edge of the transition and providing you service the interrupt before the next edge you remove the latency error. Once you have the time stamp its easy to calc the time between edges. The resolution of your time stamp is governed by the speed you have your free-running counter at. You can use your counter rollover interrupt to track > 16 bit time values (assuming 16 bit free running counter).

regards PhilW

Reply to
PhilW

So, 0% is within spec?

It would be difficult to get within 5% to 10% with internal RC.

Reply to
linnix

Pulse width? Do you mean the period?

If the period is 800ns, then 1% of 800ns is 8ns and you want to measure that to within +/-2% = +/-160ps. That's not a job for a micro.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

Good catch... What I really should have said is that I need the LOW time to be at least 100 times the HIGH time, or pulse width. If its a bit greater than 100, which would be a duty cycle less than 1%, then I can live with that. There is a tiny bit of tolerance for it to go greater than 1% but too much and devices could fail due to too much RF power going through them.

Alas the devices I've looked at thus far provide a couple of 8-bit timers. That's why I was looking at adjusting the prescaler of one so that it would meet the longer timing requirements. Due to the requirement of having to use the internal RC and using a part with minimal pins (8), my uC choices have been reduced a bit. The atmel parts are nice as they have a decent internal RC speed and run most instructions at 1MIPS/MHz.

Yup, pulse width. Based on the measured pulse width, the signal should then be low for at least 100 times the time of the pulse, which would give a duty cycle of If the period is 800ns, then 1% of 800ns is 8ns and you want to

I'd surely hate to even attempt that as the timing would never be met using a uC.

Anyhow, I appreciate the responses thus far, and look forward to any other suggestions, although I think using the capture mode of the timers is the sanest approach thus far.

~Clark

- Hide quoted text -

Reply to
clark

Okay, so if a "tiny bit" is +/- 5% you need a resolution measuring the high time of 40nsec. Still not easy with a micro.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

To do better than 1% accuracy, analog circuit would not be easy. All components (R,C,etc) has to be much better than 1%. I think it's impossible to achieve without a good clock source anyway. If cost is no issue, FPGA/CPLD assisted digital circuit would be more better.

Reply to
linnix

a

quoted text -

Unfortunately cost is part of the issue, as well as size. An RF engineer of ours had attempted this with analog circuitry and did not have good success, and now we're looking into a possible digital approach.

Reply to
clark

quoted text -

You have to consider a good clock source. If you have the volume, try a hybrid silicon resonator, CPLD and uC. You can build a very small module and shield it well from RF.

Reply to
linnix

Not true at all. 10% caps and 5% resistors are fine for the filter, and you need two 1% resistors and a comparator with reasonably low Vos (eg. an inexpensive CMOS R-R op-amp with 100uV Vos). All cheap and common parts, requiring no programming and creating no EMI.

Do a worst-case tolerance analysis of the analog circuit and you'll see. It's ratiometric so most errors cancel out, and we don't care much about the filter cutoff frequency, depending on required response time (since it's presumed to be a thermal thing).

If I'm right he doesn't care much about the actual times, only that the average "on" time not exceed 1%, to prevent overheating the transmitter.

Reply to
Spehro Pefhany

You need to ask a better question, and explain what is important.

Your min and max times are 800ns-32us ? The duty cycle seems to be your most important parameter ?. What are the TIME limits, for pass and fail ? Did you really mean 1% of 800ns, which is just 8ns ?

Is this a fixed and stable PWM stream ? If so, you can get a quite precise average duty cycle readout from a ADC - if you are worried about thermal issues, that may be the simplest as it models thermal time constants too. You can also skew the range, with asymmetric Chg/Discharge, to magnify one region. Probably do the whole thing in TinyLogc like 74LVC2G53

-jg

Reply to
-jg

Sample the logic level, say, 10000 times and count how many are high.

John

Reply to
John Larkin

Sampling would have been great if I did not have to worry about devices blowing due to a large pulse width or too high of a duty cycle.

It's been a little while since I originally posted this question and I wanted to let the group know that I appreciate all the input I have received. Since my last post, I have been successful in detecting these pulse widths and duty cycles correctly using the TI MSP430F2013 microcontroller. I ended up using two pins as inputs, one for capturing rising edges and the other for falling edges. This allowed me to capture the different times into two different registers and not miss my timing. Once a new pulse is detected, I set a flag so the main routine can do some quick math to determine high and low times as well as the duty cycle. Running the part at 16MHz provided a good resolution that I could work with and gave me enough processing power to do things quickly when it comes to detecting the 800ns pulse widths. As a matter of fact, I was able to detect a much smaller pulse width than that, which was rather nice.

I'm sure there are other devices out there that would have done the trick, but I am quite happy with the MSP430's performance for this task.

Again, thanks to everyone for your input.

~Clark

Reply to
clark

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.