Jump to content
audihere

Best method to measure pulse width on PIC

Recommended Posts

Hi, I'm wondering if anyone has any advice on how to best/most reliably/most accurately measure Rx pulse with on a PIC?

- Obviously, a Port I/O TTL bit test?

- Port I/O with Schmitt Trigger? Would that be better?

- IOC Port input?

- Use the comparator input so that voltage trigger level could be set arbitrarily?

- Directly gate Timer1 with the comparator?

- Did I forget anything?

This would be for just a single channel device. I'd like to measure the pulse width, then do a bunch of operations to it, but I'm wonder if there is a preferred way of doing that? I've been using the comparator with internal only output and bit testing that to start and stop Timer1 manually on a 12F675 and I have good results, but I'm curious if maybe that's overkill, or not a good way to do it etc.

Thanks,

Chris

Share this post


Link to post
Share on other sites

Any way that works is a good one... :)

On the 12F675 I usually use IOC, it works perfectly fine.

This way can induce measurement errors that might or might not be an issue depending on your application. Technically the "cleanest" method would be direct timer gating as all the critical operations happen in hardware and aren't affected by things such as code path length, interrupt latency, other interrupts already being serviced at the wrong moment...

But it has the drawback of requiring signal of a certain polarity on one certain pin.

Share this post


Link to post
Share on other sites

Ya, I used the "Directly gate Timer1 with the comparator?" on a 16F677, but I'd have to jump up to I 12F683 for that feature I think. Right now, I have it working in the software pseudo-gating Timer1 with the comparator. Since I'm not doing anything else at all during that time, it almost seems overkill to let the PIC gate the timer, as I'd only maybe get a couple micro-seconds better accuracy since my loop is only a couple lines long.

Missed frames is obviously a problem, but what about frames that are too short? I'm thinking that if a short frame comes in, say 8ms, but the pulse width is within the correct range, that's OK. Would glitches only be missed frames and pulse widths that are out of tolerance?

Thanks,

Chris

Share this post


Link to post
Share on other sites

You can gate the timer 1 dirtectly with the T1G pin on the 12F675, BUT the required polarity (active low) is unfortunately the opposite of what we need, requiring external inverting.

What was the purpose of the comparator? Why not just use an input pin?

Edited by Kilrah

Share this post


Link to post
Share on other sites

Hi, Audihere

I do think the best method is mainly linked to the used compiler ... and functions offered.

for the input choice ...

Shmitt trigger looks fine BUT it is unusable with most of Futaba receivers ( Signal high level is 2.9 to 3.2 v ... GASP ! )

So TTL input is the most compatible with ANY receiver.

TO ME, the most reliable and easiest way is pin polling ( i use PicBasic Pro ) with full software pulse measurement : glitches ( obviously outside the valid values !!! ) are always identified ...by a 0 returned.

But C compilers do not offer such a function ... or you have to write your own assembler function ;)

Alain

Share this post


Link to post
Share on other sites

Alain, thanks for ruling out the schmitt trigger. I didn't know the Futabas has such a low voltage signal. I do remember scoping one out and noticing it seemed strangly low, so that must not have just been my imagination.

Chris

Hi, Audihere

I do think the best method is mainly linked to the used compiler ... and functions offered.

for the input choice ...

Shmitt trigger looks fine BUT it is unusable with most of Futaba receivers ( Signal high level is 2.9 to 3.2 v ... GASP ! )

So TTL input is the most compatible with ANY receiver.

TO ME, the most reliable and easiest way is pin polling ( i use PicBasic Pro ) with full software pulse measurement : glitches ( obviously outside the valid values !!! ) are always identified ...by a 0 returned.

But C compilers do not offer such a function ... or you have to write your own assembler function ;)

Alain

Share this post


Link to post
Share on other sites

Guys:

I use a comparator and voltage ref module on a 627 or 675 and this cleans up the incoming signal (and leaves it inverted) then feed this out and then back in to the capture pin. This will give a 1Us accuracy when trigged from TMR0. Because its not reliant on latency within the interurpt then its repeatable. Just make sure that you manage the rollover of TMR (the reference for capture) properly or it will glitch...

STeve

Share this post


Link to post
Share on other sites

Steve, could you elaborate on that a little? I understand the comparator and voltage ref, but then you "feed this out and then back in to the capture pin"? Do you mean out of the comparator out pin, or internally? Is the capture pin you're referring to, part of the Capture Compare, PWM module?

If you're running at 5V, what do you set your voltage ref to for the comparator?

Thanks,

Chris

Guys:

I use a comparator and voltage ref module on a 627 or 675 and this cleans up the incoming signal (and leaves it inverted) then feed this out and then back in to the capture pin. This will give a 1Us accuracy when trigged from TMR0. Because its not reliant on latency within the interurpt then its repeatable. Just make sure that you manage the rollover of TMR (the reference for capture) properly or it will glitch...

STeve

Share this post


Link to post
Share on other sites

OK.

Make the comparator -ve the RC input and put aabout 2.5v from Vref. (that coveres the 3.3v outputs from some RX's) connect the comparator out to a pin and then via a resistor (1 k ish) to the capture compare input. (you can also put a switch to -ve here if you need a program input) The comparator removes any rubbish on the edges and is a universal level converter. so at the input to the ccp module you have a good clean 5v signal (a bonus is you can also put a scope on it to see when you havent turned the Vref on !!!) I know it uses up two pins but is a good soulition as the comparator is free running and it gives accurate 5v input to the capture (CCP module) Below is the capture ISR that gives a 16 bit result in Us

Steve

;------------------------ INTERUPT PROCESS--------------------------------------

TMR1_ISR

;------------------------ TMR1 free running with an underflow counter ---------

BCF PIR1,TMR1IF ; CLEAR INT FLAG

bsf Tick

return

CCP1_ISR ; --------- Edge detect and constant save---------

; --------- INVERTED SIGNAL-----------------------

bcf PIR1,CCP1IF ; re enable capture

btfsc CCP1CON,CCP1M0 ; check Falling edge

goto Falling_edge ; yep then sort

movf CCPR1L,w ;

movwf Leading_1 ; and store

movf CCPR1H,w

movwf Leading_1+1

bsf CCP1CON,CCP1M0 ; set for raiseing edge capture

bcf Pulse_1_done ; only half done

return

Falling_edge

bcf CCP1CON,CCP1M0 ; set for rising edge capture

movf CCPR1L,w ; grap captured value

movwf Capture_1

movf CCPR1H,w

movwf Capture_1+1 ; and store

bsf Pulse_1_done

SUB16 Capture_1, Leading_1; do maths result in Us in capture

Return

Edited by Xygax

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×