PWM Detection

On Feb 26, 7:25=A0am, clark <clarkd...@gmail.com> wrote:

> Unfortunately cost is part of the issue, as well as size. =A0An 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.

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

On Tue, 24 Feb 2009 20:33:30 -0800 (PST), clark <clarkdawg@gmail.com>
wrote:

>> So, 0% is within spec?
>>
>
>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.
>
>> 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).
>
>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.
>
>> Pulse width? Do you mean the period?
>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 <= 1%.
>
>> 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.
>
>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 -

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

John

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

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