Capture woes...

I need to measure the RPM of a motor that would range from about 300 to 2000. Based on a thread in which Bruce had given code to measure the pulse width (only the width, not the frequency) of a signal using the capture function, I used the following code, modified for frequency. I used a square wave generator to test out the code, and the numders I get dont match up at all.

Its a 16F628A running the internal oscillator.

INTCON = 0 ' Interrupts off


CCP1CON = %00000101 ' Capture mode, capture on rising edge
T1CON = 0 ' TMR1 prescale=4, clock=Fosc/4, TMR1=off
T1CON.4 = 0
T1CON.5 = 1

CLEAR

Reload:
TMR1H = 0 ' Clear high byte of TMR1 counter
TMR1L = 0 ' Clear low byte
T1CON.0 = 1 ' Turn TMR1 on here

Capture = 0 ' Clear capture int flag bit
While !Capture ' Wait here until capture on rising edge
Wend

T1CON.0 = 0 ' Turn TMR1 off here

' Rising edge detected / stuff 'captured' Timer1 value in T1
T1.HighByte = CCPR1H
T1.LowByte = CCPR1L

DEBUG #T1,13,10

GOTO ReLoad


I'm also attaching a screen grab of my calculations.

Any idea where the problem is, guys?

Thanks,

Anand

You may want to look at this
http://www.picbasic.co.uk/forum/showthread.php?t=9037

Thanks, Dave. But that thread deals more with the display driving aspect rather than the speed measurement.

I just cant figure out the discrepancy in my reading using the capture command.

Anand

well, I haven't go through the code, but internal OSC have it's own accuracy, I would compare with a real one first.

Next, how accurate your Frequency measure is? What are you using to measure it? That's pretty low frequency... pretty low frequency will add lots of count if not 100% spot on.

Try on higher frequency and see if the results are better.

Yes, I understand the internal oscillator wouldnt be extremely accurate. I did try it with a 4MHz external crystal, same readings.

The test source for square waves is a pic based instrument called 'Superprobe'; a great little instrument, the plans for which are available here: http://members.cox.net/berniekm/super.html

I did suspect the accuracy of the Superprobe, but checked it with a scope, and its spot on.

So, the issue boils down to my having messed up the capture code in some indeterminable way; or my understanding of the prescalers being totally off :(

The wrong results I get are very consistent for a given frequency. But, the ratio of observed readings to expected ones is not the same for different frequencies. Another mystery.

Anand

Lets look at this and see what its doing:

Code:

---

INTCON = 0 ' Interrupts off
 
 
CCP1CON = %00000101 ' Capture mode, capture on rising edge
T1CON = 0 ' TMR1 prescale=4, clock=Fosc/4, TMR1=off
T1CON.4 = 0
T1CON.5 = 1
 
CLEAR
 
Reload:
TMR1H = 0 ' Clear high byte of TMR1 counter
TMR1L = 0 ' Clear low byte
T1CON.0 = 1 ' Turn TMR1 on here 'here you turn on the timer, but at what state is your signal?
 
Next you wait for capture flag, but again, if the flag sets on rising edge (or falling) but
you started in the middle of a "high", you will stop when 75% of the cycle is done.
 
 
Capture = 0 ' Clear capture int flag bit
While !Capture ' Wait here until capture on rising edge
Wend
 
T1CON.0 = 0 ' Turn TMR1 off here
 
' Rising edge detected / stuff 'captured' Timer1 value in T1
T1.HighByte = CCPR1H ' I don't understand why you replace T1 count with CCPR1
T1.LowByte = CCPR1L  'T1 has the counts you are comparing in your spreadsheet
 
DEBUG #T1,13,10
 
GOTO ReLoad

---

You need to wait for a rasing edge before you start the counter, then on next rising edge, stop and get the counts. Or even better, set a word = to count, after you turn the timer off. then reset it and turn it back on. Right now you don't turn it back on until after you have sent data out. You are missing a portion of your signal this way.

HTH

Bert, thanks for the insight.

I'm still trying to wrap my brain around what you suggested. Are you saying the Debug might be affecting the captured value?

Sorry I'm being so dense here.

Have a look at this document
http://ww1.microchip.com/downloads/e...doc/41214a.pdf

Steve, thanks for that pointer. Things are very well explained indeed. Clarified some things, but am still not out of the woods yet.

Is my understanding correct here?

Slowest speed to be measured is 300 rpm. That is 5 Hz.
Maximum time to be measured between consecutive high going edges is therefore 200,000 us.
Therefore, T1, set to a prescaler of 1:4 should read 50,000 for a frequency of 5 Hz?

This is at clock frequency of 4 MHz, Capture configured to increment every rising edge.

Okay, finally got it working. Used the Melabs example at http://melabs.com/samples/LABX2-16F877A/ccpx2.htm and things are working precisely as expected.

Thanks, guys!