> I have a sensor hooked to an input capture, the data I care about is =

> frequency. (DSPIC 30F4012, freq<3kHz if it matters) The input capture =

> trigers an interrupt every 16 pulses and I read a timer value. This =

> works, but it's not actualy measuring frequency, it measures period =

> which is 1/frequency. The result is an exponential function when I =

> wanted a linear one. How have other people dealt with this?

I've had a simmilar problem reading the rotational speed of the wheels
in a little car. I used inductive sensors to "see" the holes in the
four brake disks. Each sensor was tied to the input of a CCP module
(16F877). The problem, as you say, is that the relation between period
of the signal and frequency is not linear. Not only this affect to the
acquisition rate, but also to the resolution: if I measure time between
"tics" in the sensor, then I have very poor resolution at higher
frequencies. If I count "tics" in a fixed time (0.01s, in my case) I
have good response at higher freq, but very poor at low. The
acquisition rate is very slow at lower freqs, in the first case, and
very slow at higher freqs, in the second one.

Also, in my case, i was limited in the number of bits used to code the
speed of the wheel (freq of the holes in the brake disc), because this
was part of an acquisition system, and the math was done in "the other
side" of the rf link. I needed acceptable aquisition rates and
resolutions in the whole speed range.

But it happens that the number of bits needed to code time between
"tics", and "tics" in a time unit are almost complimentary. That is,
when one of them increases, then the other decreases. So, using BOTH
measures at the same time solved the problem. I coded the number of
"tics" for time unit and the time between "tics" in a unique 10-bit
number, and did the math (in this case, a simple quotient) upward of
the rf link.

Only in the very low freqs (in my case, speeds of the car in the 0-1m/s
range) the total number of bits raised to 16. From 1,5m/s to the full
speed range of the vehicle it was enough with 10 bits. So I used 10
bits (6 for the time, and 4 for the number of "tics"). The final
codification error was, in this range, below 0,005.

Hope this helps. Regards,

=C1lvaro Deibe D=EDaz.


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist