[Gllug] Data sampling problems

[Anthony Newman]

Tethys wrote:
> In my spare time, I'm part of the crew for a top fuel dragster[1].
> Lacking the money to buy an off the shelf model, I built us a
> datalogger, so that we can analyze information from the car after
> each run to try and work out what went right and what went wrong.
> (it's an embedded system based around an ARM CPU running Linux --
> naturally :-)
> 
> Amongst other things, I'm trying to measure the crankshaft RPM,
> using a sensor and some magnets embedded into the flywheel, with
> the time between pulses being used to calculate the RPM. The
> problem I'm having is that the results aren't consistent. Instead
> of the expected RPM, my results are showing oscillating values
> above and below the expected figure:

Counting the time between pulses is a poor way of calculating this IMHO, 
unless you intend to use the speed as an input for engine management, at 
which point you would then have to worry about all sorts of things 
besides (e.g. inter-pulse crank acceleration affecting ignition/fuel 
injection timing). It is also requires a logarithmic type operation or 
lookup table to calculate the speed, rather than a simple 
multiplication, and requiring a far higher counter clock speed to give 
the required granularity of readings at the higher RPM end of the scale.

The jitter you mention is probably consistent with the sample period 
being insufficiently significant wrt the pulse repetition rate from your 
sensor, as you postulate; such that you are seeing one more or less 
pulse per sample period according to the unsynchronised nature of your 
sample period and incoming pulses. Magnetic sensing will also be 
affected by the relative speed of the magnet and sensor, possibly 
causing the trigger point to vary with speed giving non-linearity, 
whereby an optical sensor would be superior.

A regular interrupt at the rate you wish to update/measure the RPM 
value, between which you count pulses is a superior method, as the pulse 
rate becomes insignificant wrt the sample period (say 1 second), giving 
less jitter due to unsynchronisation. This will be potentially less 
accurate at lower speeds (e.g. only 40pps at 600rpm), but I guess this 
isn't the end of the scale you are concerned about ;-)

You could even implement that technique by reading the output of your 
ripple counter as an n-bit binary number and resetting the counter every 
measurement period. A 10-bit counter (max count 2047) would give a 
maximum speed of 512 rps, or 30720 rpm; or 15360rpm with a 1/2 second 
measurement period.

Anthony
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug