> 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

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

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 Wed, 25 Feb 2009 09:23:17 -0800 (PST), linnix
<me@linnix.info-for.us> 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.
>>
>> Okay, so if a "tiny bit" is +/- 5% you need a resolution measuring the
>> high time of 40nsec. Still not easy with a micro.
>>
>> ...
>> I'm going to suggest that using a micro to do this directly may be
>> fundamentally silly, and that you should consider using an analog
>> circuit.
>
>To do better than 1% accuracy, analog circuit would not be easy.  All
>components (R,C,etc) has to be much better than 1%.

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). 

> 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. 

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.  

On Feb 25, 10:25 am, clark <clarkd...@gmail.com> wrote:
> On Feb 25, 9:23 am, linnix <m...@linnix.info-for.us> 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.
>
> > > Okay, so if a "tiny bit" is +/- 5% you need a resolution measuring the
> > > high time of 40nsec. Still not easy with a micro.
>
> > > ...
> > > I'm going to suggest that using a micro to do this directly may be
> > > fundamentally silly, and that you should consider using an analog
> > > circuit.
>
> > 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.- Hide quoted text -
>
> > - Show 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.

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.

On Feb 25, 9:23=A0am, linnix <m...@linnix.info-for.us> wrote:
> > >> So, 0% is within spec?
>
> > >Good catch... =A0What I really should have said is that I need the LOW
> > >time to be at least 100 times the HIGH time, or pulse width. =A0If its=
 a
> > >bit greater than 100, which would be a duty cycle less than 1%, then I
> > >can live with that. =A0There 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.
>
> > Okay, so if a "tiny bit" is +/- 5% you need a resolution measuring the
> > high time of 40nsec. Still not easy with a micro.
>
> > ...
> > I'm going to suggest that using a micro to do this directly may be
> > fundamentally silly, and that you should consider using an analog
> > circuit.
>
> To do better than 1% accuracy, analog circuit would not be easy. =A0All
> components (R,C,etc) has to be much better than 1%. =A0I think it's
> impossible to achieve without a good clock source anyway. =A0If cost is
> no issue, FPGA/CPLD assisted digital circuit would be more better.- Hide =
quoted text -
>
> - Show 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.

> >> 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.
>
> Okay, so if a "tiny bit" is +/- 5% you need a resolution measuring the
> high time of 40nsec. Still not easy with a micro.
>
> ...
> I'm going to suggest that using a micro to do this directly may be
> fundamentally silly, and that you should consider using an analog
> circuit.

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.

On Tue, 24 Feb 2009 20:33:30 -0800 (PST), the renowned 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.

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

>> 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%.

Okay, so the period is between about 80.8uS and 3.54 msec. 

I'm going to suggest that using a micro to do this directly may be
fundamentally silly, and that you should consider using an analog
circuit. 

If I understand your need correctly, you just need to ensure that the
average value of the signal never exceeds 0.01 for very long. You may
need nothing more than an RC low-pass filter and a comparator if the
digital signals are CMOS.  

>> 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 -


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

> 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 -

On Tue, 24 Feb 2009 16:50:59 -0800 (PST), the renowned clark
<clarkdawg@gmail.com> wrote:

>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%.

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.

>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


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