Bob Ammerman wrote:
>
> > 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.


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 listserv@mitvma.mit.edu with SET PICList DIGEST in the body