Search Results

SRavet@ban ==> re: ALDL to serial converter

From owner-diy_efi-archive  Mon Dec  2 16:13:59 1996
Received: by (940816.SGI.8.6.9/940406.SGI)
	for diy_efi-outgoing id QAA11675; Mon, 2 Dec 1996 16:10:15 GMT
Return-Path: <owner-diy_efi>
Received: from by via SMTP (940816.SGI.8.6.9/940406.SGI)
	for <> id LAA11670; Mon, 2 Dec 1996 11:10:10 -0500
Received: from []) by
	via sendmail with smtp
	id <>
	for <>; Mon, 2 Dec 96 10:09:59 -0600 (CST)
	(/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
Received: from []) by
	via sendmail with smtp
	id <>
	for <>; Mon, 2 Dec 96 10:09:59 -0600 (CST)
	(/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
Received: by; Mon, 2 Dec 96 10:09:47 -0600
Date: Wed, 27 Nov 96 13:53:08 CST
Message-ID: <>
X-Priority: 3 (Normal)
To: <diy_efi>
Subject: re: ALDL to serial converter
MIME-Version: 1.0
Content-type: text/plain;
Sender: owner-diy_efi
Precedence: bulk
Reply-To: diy_efi

Scott Feaver <> Wrote:
| What chip would be required to convert the ALDL signal from a 1991 ECM to 

| standard serial connector?  Would it be a matter of using something like 
| 8031 or 68H11, reading them in on a i/o pin and some software to convert 
| Scott

I just got back from Thanksgiving holiday, and I see that I have 100+ new 
messges.  Maybe this email has already been answered, but I had already 
typed most of this up so I'll send it anyway.

Depends on the data stream.  GM used two.  The "C3" ECM uses a 160 baud 
stream, the "P4" ECM uses an 8192 baud stream.  The 8192 stream is TTL 
level serial, 0=0 and +5=1.  All you need to hook this stream to a serial 
port is a TTL to RS232 driver, like the MAX332ACP that the EFI-332 project 
is using.  You can get this part for free from the Maxim WWW page.  Then 
program your serial port to 8228 using a divisor of 14, and 
you should be good to go.  This paragraph is "theoretical" in that I've 
never tried it, but is what I've been told is possible.  I'm not sure how 
to tell if you have the 8192 stream or the 160 stream.  Additionally, you 
have to trigger the ECM into sending this data, it doesn't send it all the 
time.  I don't know how do that.

The 160 baud stream is different.  It's not really serial, in that each 
data bit is preceeded by a falling edge.  The line is driven to the 
inverted data value 1.5-2.3 msec after the falling edge.  After this sample 
interval goes by, the line goes back high, and 6.25 msec later another 
falling edge indicates that another bit is coming.  This won't connect to 
any serial port, but it wouldn't take much to have a little programmable 
logic convert these into bytes and feed them to a UART.  Here's a diagram:

______     _____________
      |   |        |    |
      |___|________|    |
     T0   T1  T2   T3   T4

T0=falling edge that indicates the start of a bit (not byte).
T1=rising edge, if the bit is a zero.  If the bit is a one, the line stays 
T2=sample period
T3=rising edge to prepare for next bit
T4=start of next bit

T0-T2 = 1.5 to 2.3 ms
T3-T4 = .5 ms minimum.

Data is sent as nine bit bytes, with the first bit being a start bit.  The 
remaining 8 bits are sent MSB first.  The very first byte is a sync 
character.  It has a "1" start bit, and all "1" data bits, ie 9 ones in a 
row.  The data bits then are sent, each with a start bit of zero.  When all 
the data has been sent, the whole thing starts over with the sync character 
followed by the data bytes.  I don't have any information regarding what 
the bytes actually mean.


Steve Ravet
Baby you're a genius when it comes to cooking up some chili sauce...

John S. Gwynne <>