[Diy_efi] Traction control strategy (solution offered)

[Axel Rietschin]

Maybe the LM339 -> parallel port is not as simple as it looks like?

----- Original Message -----
From: "Brian Dessent" <brian at dessent.net>
To: <Diy_efi at diy-efi.org>
Sent: Tuesday, April 30, 2002 12:07 PM
Subject: Re: [Diy_efi] Traction control strategy (solution offered)


>
> 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


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