Olin Lathrop wrote:
>
> > 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.


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
mailto:piclist-unsubscribe-request@mitvma.mit.edu