[Diy_efi] Traction control strategy (solution offered)

[Brian Dessent]

Crescent Kao wrote:

> I think at this point in time, I would prefer to take this route - having a
> PC run the algorithms - rather than using a PIC or MCU. Main reason being,
> is because I am most familiar with this kind of setup. However, if you can
> talk me into the other route, then I may decide to venture that way instead.
> 
> So, if i have this correct, all that needs to be done is to power up a
> simple zero crossing detector circuit with the LM339. Feed the four ABS
> signals to the input on the LM339. Then direct the output of the LM339 to
> the parallel port.
> 
> No Op Amp is required and no A/D is required either.
> 
> So do i have this correct? Or am I missing a few components.

You want to do the counting in hardware.  Otherwise you would basically
have to poll the data bits of the parallel port as fast as possible, and
this is a terrible way to measure time between pulse events.  If you
really want to do it this way you'd need a RTOS (real time operating
system) so that you can guarantee that you are polling the port at your
desired resolution.  DOS might work but it'd be a big hack.  Think of it
like this, you are trying to measure the period of a signal that could
be as high as approx 500 Hz (based on 60 mph, 40 teeth per rotation, 800
tire rotations to the mile.)  To do this by polling, which is the only
method available for the parallel port, you would have to poll **at
least** 10 times as fast, and that only gives you a precision of 10%. 
You might say "well I don't care about timing the period, I just want to
count how many pulses occur in a given time slice."  It's really the
same thing, you're now using Nyquist sampling theory.  In order for your
results to make sense you have to sample **at least** 2X and more like
10X the highest frequency (500 Hz) component that you care about.  Is it
possible to write a loop that polls the parallel port a minimum of 5000
times per second (remember, legacy hardware here) and still has time to
do useful processing?  Maybe.  But writing and maintaining this code
will be painful without support from a RTOS, and it's really a kludge.

Get yourself a microcontroller or some simple logic chips to do the
counting.  As a bonus you could do as the other poster said and have the
hardware do a "differential mode" output (throwing away the "common
mode" of the two signals) by simply rigging an up/down counter such as
the CD40193 to count up for each left pulse and down for each right
pulse -- or front/back, whatever.

Others have mentioned reseting the counts, I wouldn't bother.  Just
write your software to take into account when they roll over, and make
sure to poll fast enough so that you can guarantee that they would never
be able to roll over twice between reads.  Then just always subtract the
previous reading from the current reading.  Doing this simplifies the
interface glue a bit.

Brian

_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi