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
PWM Detection
Started by ●February 24, 2009
Reply by ●February 24, 20092009-02-24
"clark" <clarkdawg@gmail.com> wrote in message news:dd878079-0972-4699-a1a3-906c6046f23b@s20g2000yqh.googlegroups.com...> 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, > ~clarkYour 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 by ●February 24, 20092009-02-24
On Feb 24, 4:50 pm, clark <clarkd...@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%.So, 0% is within spec?> 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.It would be difficult to get within 5% to 10% with internal RC.
Reply by ●February 24, 20092009-02-24
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, >~clarkBest 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 by ●February 25, 20092009-02-25
> 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 -
Reply by ●February 25, 20092009-02-25
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
Reply by ●February 25, 20092009-02-25
> >> 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.
Reply by ●February 25, 20092009-02-25
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.
Reply by ●February 25, 20092009-02-25
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.
Reply by ●February 25, 20092009-02-25
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.
