Roman:

Just a quick thought; to convert 24 bits to 12, you could scale it...

For example, you (probably) don't really need to have 1 kph resolution when
speeds are near 400 kph.

If this is the case, perhaps you could have eight data bits (taken directly
from the count) and four bits for a multiplier.

The multiplier would indicate how many zero bits are to follow the value,
while the data bits would be the 8 most significant NON-Zero bits of the
tick count.

When encoding you would just scan the raw tick data for the first non-zero
data bit starting at bit 23 (though your figures show you only really need
to go to bit 21), take it and the following seven bits as your data to store
(i.e. upper 8 bits) and then the quantity of bits following these eight
would be your multiplier (zero to 16) and stored with the previous steps
data (as the lower 4 bits of your 12 bit processed data).

One advantage of this arrangement would be that you would always have eight
bits of precision.

Alternately you could dedicate 10 bits to the data and 2 bits for the
multiplier - but in that case the multiplier would indicate the number of
nibbles not bits following the data. A serious drawback of this would be
that resolution would oscillate over the range from best:worst of 10:6.

Bruce.

-----Original Message-----
From: Roman Black [mailto:fastvid@EZY.NET.AU]
Sent: Tuesday, February 13, 2001 8:56 AM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: Advice for datalogger speed


Hi Guys, I'm hoping someone might have a brilliant
suggestion for my minor problem. I'm doing a data-
logger which measures vehicle speed and stores in
an eeprom. The PIC clock is 16MHz and i'm using
timer0 at /2 which gives 2,000,000 ticks per second.
Speed sensor on the vehicle gives me a PERIOD reading
of fastest=5400Hz= 370 ticks. Slowest speed is
10Hz=200,000 ticks.

This data (in ticks) starts as a 24bit number for
each sample, to get the worst case of 200,000 I need
18 bits to store it. Here's the problem, I only
have 12 bits to store each sample. 12 bits should be
plenty, it gives me 0-4095 so for a projected 400kph
max, 12 bits gives me 0.1kph resolution which
is all great.

Any suggestions for how to handle this?? I want to
avoid spending too long in the PIC doing calcs,
as the speed figure is re-calibrated after upload
to a PC for charting. The perfect solution would be
to just store the 18 bit period and do ALL calcs
in the PC later, but I only have 12 bits storage.

Also, for the higher speeds I am sampling 16 pulses
period (for accuracy) but then dividing by 16,
so I lose a lot of that accuracy. That seems a shame
too...
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.