Searching \ for '[PIC]: Advice for datalogger speed' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=data
Search entire site for: 'Advice for datalogger speed'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Advice for datalogger speed'
2001\02\13@090147 by Roman Black

flavicon
face
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.


2001\02\13@093933 by Simon Nield

flavicon
face
if the 12 bit limit is simply due to the width of the memory you are using then you could just
repack 6 18 bit words into 9 12 bit words...


Regards,
Simon

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


2001\02\13@101048 by Olin Lathrop

face picon face
> 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.

You have a large range problem because the numbers are not speed but period,
which gets infinite as speed approaches 0.  Just invert the period and store
normalized speed in the 12 bits.  I've done lots of projects that included
measuring speed from pulses, and almost always converted to speed before
using the value in the rest of the system.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

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


2001\02\13@104604 by Bourdon, Bruce

flavicon
face
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 removed}

2001\02\13@214444 by Roman Black

flavicon
face
Simon Nield wrote:
>
> if the 12 bit limit is simply due to the width of the memory you are using then you could just
> repack 6 18 bit words into 9 12 bit words...


Thanks Simon, but unfortunately the limit is
on total memory size and I really do require
12 bits/sample and no more. :o)
-Roman

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


2001\02\13@220458 by Roman Black

flavicon
face
Olin Lathrop wrote:
{Quote hidden}

Thanks for the suggestion Olin, are you saying I should
invert the period by doing a 1/period division calc for
each sample? Or use x/period where x is chosen to
give a result in the 12 bit range?? I don't quite
understand.
-Roman

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


2001\02\14@075326 by Roman Black

flavicon
face
Hi Bruce. I had to read your post a couple of times
to get it but I think that is really clever.
Part of my problem with the 18bit period value is
that I have way too much resolution at the slow
speeds, with values like 200,000 ticks, and not
enough resolution with high speed values like 370
ticks.

If I use ranges this evens out. It also saves me
a lot of math calcs as I can do the bulk of the range
work when I *detect* the pulse rate, letting me use
the better resolution from sampling period over 4
to 16 pulses as the speeds increase.

Vehicle specs:
10kph = 10Hz = 200,000 ticks (min speed)
400kph = 5400Hz = 370 ticks (max speed)

So rather than using my original plan of sampling
over 16 pulses only for higher speeds, I will do the
sampling in 4 specific ranges;

speed range low = period of one pulse
speed range 2 = period of 4 pulses
speed range 3 = period of 8 pulses
speed range 4 = period of 16 pulses

So, as you suggested I can then use a
12 bit stored data consisting of:
10 bits (actual data value, cropped to 10bit)
2 bits (range indicator)

This should be simple to implement as there
is no real data processing done on the fly,
just storage. When it is uploaded to the PC
later I can do the conversion from period
data in four specific ranges to actual speed,
as it needs a set calibration applied by the
PC anyway to account for the vehicle gearing.

I will have to do a little bit of homework re
the exact range choices and resolution but
I think this is a good way to go about it.

Darn it, just done a couple of hours number
crunching and I don't think it will work.
I really don't think the data will fit in 12
bits with the resolution I need.
Technically, 12 bits is 4096, which should
give me 400kph at 0.1kph resolution. But my
problem is a 10:1 difference from vehicle
to vehicle re the freq per kph. I really need
that 0.1kph resolution to 4000kph to give
the same resolution for all vehicle types.
Darn!:o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@080358 by Bob Ammerman

picon face
> Darn it, just done a couple of hours number
> crunching and I don't think it will work.
> I really don't think the data will fit in 12
> bits with the resolution I need.
> Technically, 12 bits is 4096, which should
> give me 400kph at 0.1kph resolution. But my
> problem is a 10:1 difference from vehicle
> to vehicle re the freq per kph. I really need
> that 0.1kph resolution to 4000kph to give
> the same resolution for all vehicle types.
> Darn!:o)
> -Roman

Roman,

Maybe you need to have some kind of set up parameter to determine an initial
division rate for the vehicle, which would just multiply the number of
cycles to be acquired by a number in the range 1..10. Fast shaft = fewer
cycles, slow shaft = more cycles.

Maybe: drive at 20kph and push the button, unit figures out appropriate
scaling.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@082745 by Roman Black

flavicon
face
Bob Ammerman wrote:
{Quote hidden}

Thanks Bob, that would give a sort-of solution.
Trouble with these vehicles is they are generally
racing motorcycles with sprockets/gearing changed
from race to race, even on the same day. This
changes all the speed frequencies. I really wanted
to avoid making the user manually set up the
datalogger to get decent resolution. Even though
your automated idea is cool (and I hadn't thought
of that!) it still involves one more step that
really won't appeal to pit crew guys, these bikes
don't have speedos, they don't really have anywhere
to run them at 20kph apart from valuable track
time...

The perfect solution is obviously to allow for
good resolution from 10Hz to 5400Hz, but by my
calcs that is about 16bits...
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@083752 by Alan B. Pearce

face picon face
>these bikes
>don't have speedos, they don't really have anywhere
>to run them at 20kph apart from valuable track time...

How are you expecting to store the data? As raw data, or are you expecting to
download sprocket/gear ratio information when these are changed so it is stored
in a normalised format? I just get the feeling that there is going to be a very
large place for errors to creep in as mechanics swarm over the bike like a bunch
of wasps, and you will not be able to get close enough to attach a data cable or
push a button to say that this should now be saved as a different data set
because the ratios have changed.

Ideally radio telemetry back to the pits the way Formula 1 cars do it would be
best, then you do not need to worry about storing it on the bike, but then ....

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@090853 by Roman Black

flavicon
face
Alan B. Pearce wrote:
>
> >these bikes
> >don't have speedos, they don't really have anywhere
> >to run them at 20kph apart from valuable track time...
>
> How are you expecting to store the data? As raw data, or are you expecting to
> download sprocket/gear ratio information when these are changed so it is stored
> in a normalised format? I just get the feeling that there is going to be a very
> large place for errors to creep in as mechanics swarm over the bike like a bunch
> of wasps, and you will not be able to get close enough to attach a data cable or
> push a button to say that this should now be saved as a different data set
> because the ratios have changed.
>
> Ideally radio telemetry back to the pits the way Formula 1 cars do it would be
> best, then you do not need to worry about storing it on the bike, but then ....


Hi Alan, i'm pretty flexible as to the way the data
is stored. Once uploaded to the PC the user can then
adjust the final calibration for sprocket and tyre
sizes. They will be doing that anyway.

My main concern for storage is the 12 bit limit for
the speed reading per sample, and getting decent
speed resolution within that limitation.

Depending on vehicle type, 10kph-400kph could
be from about 10Hz-400Hz to 135Hz-5400Hz.
I really would like to use the 12 bits to their
max, and I know the guys want sub 1kph resolution.
0.25kph resolution is ok but 0.1kph resolution is
much better. And of course it would be nice not
to be forced to recalibrate the datalogger at
all from one setup to another.

I'm pretty stumped. The easiest way to get the
performance is go one more storage byte per sample,
giving me 20 bits for speed. But this requires more
eeprom chips and gets nasty for pricing and size...
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@104057 by Olin Lathrop

face picon face
> Part of my problem with the 18bit period value is
> that I have way too much resolution at the slow
> speeds, with values like 200,000 ticks, and not
> enough resolution with high speed values like 370
> ticks.

Do you really need to know the vehicle speed to better than one part in 370
(0.27%) at 400Km/hour?  If so, I thought you said you were using a prescaler
value on timer 1.  If you reduce the prescaler value by 2, all the period
values will double.  Is one part in 740 good enough?  Alternatively you
could also enable the prescaler on the PWM input.  How often do you need to
store a speed sample?

Of course you would have to increase X as discussed in my other post by the
same factor the prescaler is decreased by.

> If I use ranges this evens out. It also saves me
> a lot of math calcs as I can do the bulk of the range
> work when I *detect* the pulse rate,

Are you thinking that doing a divide will take too long?  I bet it comes out
to a small fraction of the time between measurements when you work it out.
You didn't say how often you need to store speed values, but if this is a
racecar or something, I imagine a few times per second is sufficient,
probably less often.

Just to give you a reference, I have a 16F876 at 20MHz doing two nested PID
control loops that probably do 10 to 30 floating point operations per
iteration.  The loop time is 10mS, and the worst case PID computation time
is 7mS.  And oh yeah, the processor is also measuring the speed of an engine
from tachometer pulses, which includes a 32 bit integer divide exactly as
described in my other post.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\14@104112 by Olin Lathrop

face picon face
> Thanks for the suggestion Olin, are you saying I should
> invert the period by doing a 1/period division calc for
> each sample? Or use x/period where x is chosen to
> give a result in the 12 bit range?? I don't quite
> understand.

Yes, the latter.  You need to make sure that most of the 12 bit range maps
to the full speed range you want to represent.  From your original post, the
fastest speed results in a period of 370, which you want to result in a 12
bit speed value of 4000 (It's a good idea to leave a little headroom above
the max you expect).  The equation for finding speed from period is:

 X / period = speed

We know that a period of 370 is supposed to result in a speed of 4000, so we
can solve for X:

 X / 370 = 4000
 X = 4000 * 370 = 1,480,000 = 169540h

From the hex value of X you can see that a minimum of 21 bits are required
for X.  That means you can use a 24 or 32 bit integer divide routine.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\15@023157 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
> > Part of my problem with the 18bit period value is
> > that I have way too much resolution at the slow
> > speeds, with values like 200,000 ticks, and not
> > enough resolution with high speed values like 370
> > ticks.
>
> Do you really need to know the vehicle speed to better than one part in 370
> (0.27%) at 400Km/hour?  If so, I thought you said you were using a prescaler
> value on timer 1.  If you reduce the prescaler value by 2, all the period
> values will double.  Is one part in 740 good enough?  Alternatively you
> could also enable the prescaler on the PWM input.  How often do you need to
> store a speed sample?
>
> Of course you would have to increase X as discussed in my other post by the
> same factor the prescaler is decreased by.


Unfortunately I do need decent resolution at the
higher speeds. The pit crews use this info to
tune the engine power and aerodynamics, and the
peak speed on straights is a good measure of
these. I really need 0.25kph res at 300-400kph.

At higher speeds my code already samples period
over 16 or 32 pulses total, so I have the extra
res there. Just storing it is the problem. :o)


{Quote hidden}

Thanks for that info Olin, I really can spare
about 4mS for the total division calc, so at
16MHz that's 16,000 instructions. I guess that's
plenty long enough to do an accurate 24bit
division and trim the result! Cool.

Now I have another problem, the different vehicle
types have up to 15:1 difference in how many
pulses/kph. I'm having trouble fitting that range
into my 12 bits with decent resolution.
I really need 10Hz to 5400Hz with 1:4000 resolution
through the whole range...
-Roman

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\02\15@024120 by Roman Black

flavicon
face
Olin Lathrop wrote:
{Quote hidden}

Thanks again Olin, that all makes perfect sense. Now
I have the rouble of getting enough resolution at the
other end of the range. My big period is 10kph=200,000
so I would be doing:
(10kph) 1,480,000 / 200,000 = 7.4
(11kph) 1,480,000 / 182,000 = 8.1
(12kph) 1,480,000 / 167,000 = 8.9

Obviously with rounding this shoots my resolution
out the window. I need better than 0.25kph and
prefer 0.1kph throughout the whole range.
Worst caes:
10Hz = 10kph
5400Hz = 400kph

I'm heading closer and closer to adding another eeprom
chip and just using 20bit storage for the speed data
and not 12bit...
-Roman

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\02\15@101049 by Olin Lathrop

face picon face
> Now I have another problem, the different vehicle
> types have up to 15:1 difference in how many
> pulses/kph. I'm having trouble fitting that range
> into my 12 bits with decent resolution.
> I really need 10Hz to 5400Hz with 1:4000 resolution
> through the whole range...

My engine controller has the same problem because the number of tachometer
pulses per engine revolution varies from engine to engine.  In an early
version we solved this with DIP switches.  Now we use EEPROM on the 16F876
which is set up at manufacturing time from a Windows program via the RS-232
port.

In your case, I gather you need to configure more "on the fly".  How often
is the unit moved from one motor cycle to another?  Would it be acceptable
to change a few DIP switches or connect a laptop to run a configuration
program?

Note that all this configuration only changes the value of X in the
equations we discussed earlier.  After X is properly set up, you always end
up with a 12 bit speed value in the right range.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinEraseMEspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\02\15@101105 by Olin Lathrop

face picon face
> >   X / 370 = 4000
> >   X = 4000 * 370 = 1,480,000 = 169540h
> >
> > >From the hex value of X you can see that a minimum of 21 bits are
required
{Quote hidden}

Something seems inconsistant here.  If a period of 370 implies 400Km/H, then
10Km/H would be 14,800, not 200,000.  Your 200,000 figure must be for a
different bike configuration, in which case you would be using a different X
(20,000,000 in that case).  Once X has been chosen for the particular bike
configuration so that you get 4000 for 400Km/H, you end up with a value
that can resolve .1Km/H.

By the way, given your potentially large X values, you need to be doing a
32, not 24 bit, divide.  As you mentioned in your other post, you have
16,000 cycles available, which is way more than enough.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinEraseMEspamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu


2001\02\16@014041 by Roman Black

flavicon
face
Olin Lathrop wrote:
{Quote hidden}

Thanks Olin, the inconsistency is indeed my problem.
I really wanted to avoid having to configure the
logger for different bikes. The logger will be used
at riding training schools, and will be plugged in
a number of different bikes.

The perfect setup is simply to have enough resolution
for the whole 10Hz to 5400Hz range.

I'm still stumped. The last two days I've been working
on the hardware. It's looking more like going to 20bit
speed data storage, and just storing the period as is.
This has to give the best possible accuracy with the
data at hand but will cost one more eeprom chip.
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...