Searching \ for '[PIC] measuring fast pulses' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'measuring fast pulses'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] measuring fast pulses'
2007\01\12@085724 by alan smith

picon face
I'm sure this has been done before....measuring the RPMs of a flywheel, but just looking for a sanity check.
 
 Lets say you have a hall sensor pickup on a flywheel that is giving you around 5000 pulses/sec  from the teeth.
 
 So thats 5000Hz or 200uS between edges.  A 4MHz PIC has an internal cycle time of 1uS so it can easily count these, but better yet is to use TMR0 and the prescaler so you can get a reasonable number using the 1:128 and get out 39 Hz when you use a 1 second interupt to read the TMR0 value.
 
 This is assuming the input signal is relativly clean as well.
 
 Comments?


---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.

2007\01\12@114233 by David VanHorn

picon face
>
>
> So thats 5000Hz or 200uS between edges.  A 4MHz PIC has an internal cycle
> time of 1uS so it can easily count these, but better yet is to use TMR0 and
> the prescaler so you can get a reasonable number using the 1:128 and get out
> 39 Hz when you use a 1 second interupt to read the TMR0 value.
>
> This is assuming the input signal is relativly clean as well.


Seems like the wrong sensor for the job.
If you're getting that much resolution, then throwing most of it away.

Might be better off, if you need fast response time, to average the most
recent two pulse widths, and use a lookup table.   The AVR can go to 64 MHz
on peripheral clock in some chips, you could get a pretty accurate count.

You could also do an external /2, /4 or /8 on the input signal, and that
would assure you a clean signal too.

2007\01\12@150138 by Orin Eman

picon face
On 1/12/07, alan smith <spam_OUTmicro_eng2TakeThisOuTspamyahoo.com> wrote:
> I'm sure this has been done before....measuring the RPMs of a flywheel, but just looking for a sanity check.

Sure has.

>  Lets say you have a hall sensor pickup on a flywheel that is giving you around 5000 pulses/sec  from the teeth.
>
>  So thats 5000Hz or 200uS between edges.  A 4MHz PIC has an internal cycle time of 1uS so it can easily count these, but better yet is to use TMR0 and the prescaler so you can get a reasonable number using the 1:128 and get out 39 Hz when you use a 1 second interupt to read the TMR0 value.

Here are some code fragments that I use...  Hopefully the formatting
doesn't get too trashed.  I use TMR0 and a software high byte.  The
variable names and macro usage should be obvious.  I read the values
every 1/10 second, but every second would work too, it would just
change the constants used converting to RPM.  The code also does very
simple averaging and replaces a divide by a multiply and shift.  It
works fine for display of RPM from a car flywheel based inductive
sensor.

Enjoy, Orin.

; Somewhere in the interrupt handler:
       btfsc        INTCON, T0IF                ; Check if Timer 0 Overflowed
       goto        IRQ_T0I                        ; yes, go handle it
; Handle other interrupts

;--------------------------------------------------------------
; Timer0 Overflow
;--------------------------------------------------------------
IRQ_T0I
       bsf        INTR_FLAGS, IF_HANDLED
       bcf        INTCON, T0IF                ; Clear the interrupt
       incf        COUNTER_HIGH, F                ; Increment Counter
; go back to main interrupt handler

;--------------------------------------------------------------
; Timer 0 Handling
;--------------------------------------------------------------
;
; Clear_Timer - Clear SW and HW timer
;
ClearTimer
       DisableInterrupts
       bcf        STATUS, RP0                ; Bank 0
       clrf        TMR0
       bcf        INTCON, T0IF
       clrf        COUNTER_HIGH
       EnableInterrupts
       return

;
; Read_Timer - Put timer value in indirect location
;                Assumes FSR has the desired location
;
; Note:        Call with interrupts ENABLED
;        Trashes FSR
ReadTimer
       incf        FSR, F
       movf        COUNTER_HIGH, W        ; Get high byte
       movwf        INDF
       decf        FSR, F

       movf        TMR0, W                ; Get low byte
       movwf        INDF

       incf        FSR, F
       movf        COUNTER_HIGH, W        ; Re-Read high byte
       subwf        INDF, W                ; W = first - second
       btfsc        STATUS, Z        ; Same high byte?
       return                        ; yes, clean read

                               ; No, re-read timer
       subwf        INDF, f                ; Works out to 'second'
       decf        FSR, F                ; Re-read low byte
       movf        TMR0, W
       movwf        INDF
       return

;--------------------------------------------------------------
; Calculate RPM (runs every 100mS)
;
; Get Flywheel tooth count as quickly as possible
;
       movlw        ACCaLO                        ; ACCa is new count
       movwf        FSR
       call        ReadTimer                ; Get flywheel tooth count

       MovWord        ACCaLO, ACCbLO                ; ACCb = ACCa
       SubWord        ACCaLO, PrevTeeth        ; ACCa -= PrevTeeth
       MovWord        ACCbLO, PrevTeeth        ; PrevTeeth = ACCb

       AddWord        ACCaLO, PrevAvg                ; ACCa = (ACCa + PrevAvg)/2
       bcf        STATUS, C
       rrf        ACCaHI, F
       rrf        ACCaLO, F
       MovWord        ACCaLO, PrevAvg                ; PrevAvg = ACCa

;
; RPM is flywheel tooth difference * 40 / 9
;
; To turn this into a binary fraction of 1000 RPM,
; we multiply by 65536/1000, giving the 1000 digit
; and two bytes of mantissa.  Subsequent multiplies of
; the mantissa by 10 give the 100, 10 and units digits.
; (40/9)*(65536/1000) is 291.27.  We round this
; to 291.25 and note that
; it is 1165/4.  So we multiply by 1165 then divide by 4.
; We could pick other combinations, but this one is
; accurate enough, doesn't overflow for expected RPM values
; and replaces the divide with 2 shifts.
; Resolution is (291.25 * 1000) mod 65536, about 4 RPM.
; There is no attempt to display > 9999 RPM.

       movlw        0x8D                        ; Multiply by 291.25 by first
       movwf        ACCbLO                        ; multiplying by 1165 then...
       movlw        0x4        
       movwf        ACCbHI
       call        D_mpyS

       bcf        STATUS, C                ; ...dividing by 4
       rrf        ACCbLO, F
       rrf        ACCcHI, F
       rrf        ACCcLO, F
       bcf        STATUS, C
       rrf        ACCbLO, F
       rrf        ACCcHI, F
       rrf        ACCcLO, F

2007\01\12@154039 by Andre Abelian

flavicon
face
I worked with engine project I used CCP to capture
RPM it worked fine and I used timers for other functions.

Andre





{Original Message removed}

2007\01\12@170311 by Jinx

face picon face
> > 4MHz PIC has an internal cycle time of 1uS
> > So thats 5000Hz or 200uS between edges

If you're using IntRC, be aware it varies with Vcc and temperature

(In fact an 18F452 with R = 3k3 will swing between 600 -
550MHz, peaking at !! 750MHz !! with just 2.5V Vcc ! Check
out Fig 23-14 of DS39564B. Oh, if only it did......)

There have been a few threads about RPM meters for car engines,
might be worth looking up

> If you're getting that much resolution, then throwing most of it away

If this were a frequency meter you might be switching between
two methods to get the best accuracy

- for low frequencies, measure the period directly
- for high frequencies, sample and average

'low' and 'high' are relative to the PIC's speed

If the 5000Hz is the average and you're happy to have a 1Hz
update, perhaps

- count all the pulses and calculate at 1Hz

- count with T0CKI and compare TMR0 rollover time with
another timer, using this as data for a moving average, updated
at around 20Hz (TMR0 = 8-bit) that's calculated and displayed
at 1Hz

Use maths (slower, probably better resolution) or, as Dave
suggested, a lookup table (faster, but can be a pain to set up
and change)

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...