Robin,

Why not feed the pulses from the wheel sensor into the RTCC input of the
PIC, and read pulses for a while, and then calculate the speed based on
The frequency recorded?  Ie 320 Hz = 150 MPH, so 160 Hz = 75 MPH, 10 =
~5 MPH, 100 Hz = ~47 MPH, ~117 Hz = 55 MPH, and so on.  This too could
be 
Set up in a table.  The table could be rather samll as you could go up
in 2 MPH or 5 MPH increments.

In my opinion, this would be easier to implement than your algorithm.
I'm not saying you're wrong.  I just think this may be easier.  Anyway,
it
Is just a suggestion on my part.  You have to make the final choice
yourself.


				
	
Regards,

	
Jim
 

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf
Of Robin D. Bussell
Sent: Thursday, June 12, 2008 2:27 PM
To: piclist@mit.edu
Subject: [EE] frequency dividing 

Hi Folks,
      It looks like I may just have found the perfect excuse to get a
PIC into my car :) The speedometer died the other day, investigation
revealed the cause was the failure of a drive gear deep in the gearbox
that will take lots of cash to get replaced, a fair fraction of the
car's worth in fact :(

It's an electronic speedo drive so I need to synthesise a signal to feed
it. One source of speed related information would be the anti lock brake
system wheel sensors which are of the magnet, coil and toothed wheel
variety, outputting 46 pulses per revolution at 0.5 - 0.7V (so I'm
told).

The speedo wants 2,458 pulses per kilometre. This works out at dividing
the wheel sensor frequency by about 2.367 with a maximum frequency from
the wheels of 320Hz at 150MPH (no I don't plan to go that fast! Might as
well design to the max speed though).

So I was thinking that for this purpose I could do this with a small
pic:

Take 1000 "1" bits and distribute them evenly over a 2367 bit string
with everything else being "0", (so we're looking at a 296 byte table)
every time a pulse comes in from the ABS, read the next bit in this
string and set an output pin appropriately. End result should be a
signal that is (on average) the input divided by 2.367 .

Can anyone see any problem with this algorithm in this application?

I daresay I could happily cut down the table length too, I only need a
maximum error of 5% or so I guess.

All thoughts welcome!

Cheers,
     Robin.


--
http://www.piclist.com PIC/SX FAQ & list archive View/change your
membership options at http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist