GM ALDL interface

[Terryk]

Well I replied to the wrong folks. Gotta watch that address. 

You are not behind. I couldn't find a combination that would yield 8 data
bits from 9 bit stream.

And as far as I can remember, it is not pulse width modulated. It is 200uS
sync bit, 3mS of data (0 or 1), and 3mS of logic 0 dead time, start again.
If you put a scope on it and trigger on a falling edge (there is only one
at the start of the sync bit), it is obvious.

Unless there is a PWM 160 baud ECM, that is how it works.

TK

----------
> From: Ron & Cathy Webb <cwebb at polarnet.com>
> To: diy_efi at efi332.eng.ohio-state.edu
> Subject: Re: GM ALDL interface
> Date: Sunday, December 07, 1997 11:04 AM
> 
> I hate it when I know i'm either one step ahead of you, or 3
> steps behind...
> 
> I keep seeing referance to "one stop bit, 8 data bits, no parity"
> adding up to 9 bits. Can I be so old that I'm the only one who
> remembers that there is also a start bit?
> 
> In a standard UART, the async data comes out as follows...(no
> books handy, working from memory here)
> 
> 1 start bit - always 0
> 7 or 8 data bits
> Odd, Even, or No parity
> 1 or 2 stop bits, always 1's
> 
> so an 8n1 data byte contains 10 bits, not 9! Unless the 160 ALDL
> is even wierder than I thought, which I suppose is entirely
> possible.
> 
> steve ravet wrote:
> 
> > Ludis Langens wrote:
> >
> > > steve ravet <steve at imes.com> wrote:
> > > >There are at
> > > >least 2 flavors of ALDL, one is aobut 160 baud and the other
> > is 8192
> > > >baud.  The second is a TTL level rs-232 signal, the first
> > one is strange
> > > >and will not connect to a serial port.
> > >
> > > Not necessarily so, read on.
> >
> > > First some background info:  Bits in the 160 baud stream are
> > encoded as
> > > different length pulses.  A "zero" is sent as a low pulse
> > with a duration
> > > of around 24/65517.1875 seconds (~366 uS).  A "one" is sent
> > as a pulse of
> > > around 288/65517.1875 seconds (~4.4 mS).  The interval from
> > the start of
> > > one pulse to the start of the next pulse is 412/65517.1875
> > seconds (~6.3 mS).
> > > In other words, the actual data rate is really around 159.02
> > baud.  (This
> > > timing data applies to _some_ of the 160 baud ECMs, it might
> > not apply to
> > > _all_ of them.)
> > >
> >
> > If you search the archives you will find a post made by me,
> > that details the 160
> > baud data format.  I'll summarize again.  Here's the waveform:
> >
> > -----     ---------------
> >      |   |          |    |
> >       --------------
> >     t0   t1   t2   t3   t4
> >
> > t0 makes the start of a BIT (not byte).
> > t2 is the sample point.  high voltage=0, low voltage=1
> > t3 is the end of the bit
> > t4 is the start of the next bit.
> >
> > if the bit is a zero, t1 indicates the transition point.  The
> > important timings
> > are:
> >
> > t0-t4=6.25 msec
> > t0-t2=1.5 msec to 2.3 msec
> > t3-t4=.5 msec minimum
> >
> > > My basic idea is to set the UART to a baud rate that receives
> > a full byte
> > > (or more) per every ALDL bit.  The start of each ALDL pulse
> > acts as an async
> > > start bit.  The low interval of the pulse is received as a
> > variable number
> > > of async zero bits.  The baud rate could be set such that:
> > >
> > >  a) A long ("one") pulse is received as a start bit and 8
> > zero bits - i.e.,
> > >     a NUL byte.  A short pulse should then be received as
> > just a (slightly
> > >     short) start bit - i.e., a 0xff.
> >
> > Now THAT is a clever idea.  The maximum byte length would be
> > 5.75 msec.  At 8
> > data bits, one stop bit, you would need a baud rate of 1739.  A
> > baud rate divisor
> > of 66 on the PC gives you a baud rate of 1745 which is close
> > enough.  If you had
> > a level shifter to generate the proper voltage levels, and used
> > this baud rate,
> > you would receive one byte from the serial port for every ALDL
> > bit.  As noted
> > above, a "one" bit would result in a byte of all zeros, and a
> > "zero" bit would
> > result in a bit with at least some ones in it (non zero).
> >
> > The rest of the format is this:
> >
> > 9 one bits in a row indicate the start of a frame.  subsequent
> > bytes all begin
> > with a zero start bit, and 8 data bits.  The frame is variable
> > length, and
> > continues until another sequence of 9 ones in a row is
> > received, indicating the
> > start of the next frame.  The zero start bit means that 9
> > consecutive ones cannot
> > be received as part of the data.
> >
> > The meaning of each byte in the frame is unknown, and probably
> > differs per ECM.
> >
> > Thanks for the idea,  Ludis!  I plan on trying that out.
> >
> > --steve
> >
> > --
> > Steve Ravet
> > steve at imes.com
> > International Meta Systems
> > www.imes.com
> 
> 
>