Accurate Freq Measurment

[Terry]

I am using a PIC to make a very accurate (sub hertz) frequency measurement of a 4 kHz signal in as little time as possible, about ~ 100msec. I am using TIMER1 to measure the period of 400 cycles of the 4kHz signal. I am starting Timer1 on a rising edge of the 4kHz signal, keeping track of the number of cycles and then stopping Timer1 on the 400th cycle of the 4kHz signal. I then have a count and number of rollovers of the timer from which I calculate the frequency in a computer, not the PIC. Below is the code of my technique. The question I have is there a better approach to taking advantage of the PIC’s hardware Timers and/or capture compare module, such to improve the accuracy and to do this in the background. The code in currently for the PIC16F877, but I can easily switch to an 18F part.
Thanks in advance for the help,
Terry

[amgen]

one pulse-in, will give a count in 10-micro second units,and I think give the same accuracy of your routine. Plus only take 1/4000 seconds or 1/8000 sec due to 1/2 cycle.

[skimask]

Assuming a 50% duty cycle on the input signal, COUNT might work well for you. There are a few tricks a person could use to fool the compiler into giving you a result that would be 'sub-hertz'.

[Terry]

Thanks for the suggestions, but at the moment I think I am getting quite a bit more resolution since essentially my time increment is 1/5MHz or 200nsec and then this is applied over a longer period of time in regards to only measuring over only 1 cycle, there is an extended resolution due to the fact that it is over 200 cycles rather than just one. It would be nice to use the hardware timers as I would like to do this in the background more on an interrupt basis rather than taking using CPU time to make the measurement, but I do appreciate the ideas.
T

[dhouston]

The minimum period for COUNT is 1mS but I've never tested it to see how accurate that is. You might try it and compare it to your current method for accuracy. It counts low to high transitions so duty cycle is really immaterial. I'm not sure why the manual even mentions duty cycle. If you use 1mS, then the result x 1000 will give the frequency. It's certainly simpler than what you do now.

[skimask]

It would be nice to use the hardware timers as I would like to do this in the background more on an interrupt basis rather than taking using CPU time to make the measurement, but I do appreciate the ideas.

Then you fire up one of the timers...
Say it runs at a base frequency of 1Mhz (4Mhz OSC / 4 ), each tick is 1us.
Clear the timer...
Wait for a rising edge of the input and start the timer.
Wait for the next rising edge of the input and stop the timer.
Subtract the few cycles it takes to start and stop the timer.
Since you want a frequency of 4Khz, the timer should have a count of 250 in it (after the necessary subtractions).
If the count is 249, then your input freq is 4016 Hz, if 251, then 3984 Hz.
But you want sub-Hz resolution...
So kick up the PIC to 40Mhz, and the timer runs at 10Mhz, each tick is .1us.
Using the same logic as above, the timer should have a count of 2500 in it between the 2 rising edges (after the subtraction).
If the count is 2499, the freq is 4001.6 Hz, count = 2501 then freq = 3998.4 Hz...
But that's still not quite sub-Hz resolution...Sooo....
Instead of counting one rising, you go for the max resolution, wait for the next 25 rising edges. After that 25th rising edge, the timer should have a count of 62,500.
If it's 62,499, your input frequency average over the last 25 cycles was 4000.0640010240163842621481943711 Hz.
If the timer reads 62,501, the input frequency average over the last 25 cycles was 3999.9360010239836162621398057631 Hz.
Problem is...it takes 25 cycles to get that number, which might not be fast enough for you. The only way to increase this is to increase the speed of the timer, hence the CPU. With a PIC18F, you aren't going to get much better than .1us accuracy at 40Mhz.
And since you want to do this in the background, that's easy enough by applying your input signal to, say, the RB0 interrupt, and having the interrupt routine do the timer starting/stopping, clearing, count saving and so on. And your main loop handles the hard math...

[amgen]

yes....resolution and overhead

use ccp (capture/compare) module in capture mode....
count at 10MHZ,(Fosc/4 from 40MHZ) set for every 16th rise or fall edge to get counts directly, at 4000.0 hz, count is 40000
-at 3999 hz count is 40010
-at 4001 hz count is 39990

freq then = (40,000 +/- difference)/10 hz down to .1HZ

i think?
don

[amgen]

actual hz calculation........

HZ = 16x10^7/count (from ccp) within range of 2500hz to 10MHZ ?
for ccp @ every 16 edges.

don f