GM ALDL interface

[Terryk]

I read 160 baud by building a simple two tranny circuit (level shifter)
connected to the parallel port and writing a routine to interrupt the some
code and read a parallel port bit at a fixed rate. 

 I samples at 2-3X the 160 baud rate and dumped the serial stream it into a
large buffer (9x max bytes +1). 

Then I scanned through it looking for the leading 9 1's (start sync byte by
watching for a 0-1 transition), skipped "n" bits (equivalent to delaying
the 1.25mS or whatever it was), skipping one bit, delaying, and taking the
next 8 and building a byte from it. I repeated that until the next 9 1's
showed up.

Considering how slow 160 baud is, there is plenty of time to do all of
this, convert, display the results and start again.

After reviewing this a million times, I found there was no way to get a
uart to handle it. I just wasn't meant to be.

Terry Kelley

----------
> From: Ludis Langens <ludis at netcom.com>
> To: diy_efi at coulomb.eng.ohio-state.edu
> Subject: Re: GM ALDL interface
> Date: Saturday, December 06, 1997 10:47 AM
> 
> 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.
> 
> >A neat project would be to use a
> >PIC microcontroller to read the 160 baud stream, convert the data, and
> >send it out over a regular serial port.
> 
> I've breadboarded a fully optoisolated ALDL interface for a Mac.  The
serial
> data is routed to the RxD input of a serial port.  The 8192 baud mode can
> (of course) be received using the standard serial driver software.  For
the
> 160 baud mode, I've written a device driver to receive the 160 baud data.
> The Zilog SCC used in Macs can do magic!  Anyway, the technique I used
has
> given me an idea of how receive the 160 baud ALDL data using a standard
> async-only UART.  This technique could be used with the ALDL interface
> schematic found in this list's archives.
> 
> 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.)
> 
> 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.
> 
>  b) A short ("zero") pulse is received as a NUL byte.  A long pulse would
>     then be detected as an async BREAK.
> 
>  c) Some other baud rate in this same range.
> 
> Some real world testing is needed to choose an actual baud rate. 
Hardware
> and software factors need to be considered.  With a good baud rate
choice,
> it should be possible to use a standard serial driver - possibly even
with
> DMA!  Application software would be responsible for converting the 160
> bytes/second into the 160 bits/second data stream - and then further into
> ALDL data packets.
> 
> In summary, no PIC microcontroller in needed.  All you need is a TTL to
> RS-232C level shifter and some software.  Further, that software
shouldn't
> need to access anything at the hardware level!  (I'm not familiar enough
> with the Wintel software architecture to be certain.)
> 
> PS, I'll be real pissed if somone patents (or has patented) this idea.
> 
> PPS, The ALDL<->Mac interface isn't ready to be "published" yet, so don't
> ask for a schematic.  It works "in the lab" - using a short TinyBASIC
like
> program running in a spare ECM and animating the ALDL output, and a
simple
> raw hex dumping shell around the 160 baud device driver.  I need to etch
a
> circuit board, improve the Mac end's software, and actually test it in
the
> field.
> 
>                    unsigned long BinToBCD(unsigned long i) {unsigned long
t;
> Ludis Langens         return i ? (t = BinToBCD(i >> 1), (t << 1) + (i &
1) + 
> ludis at netcom.com                 (t + 858993459 >> 2 & 572662306) * 3) :
0;}