ECU2PC project 
ECU2PC project
Important notice: some information from this page are unaccurate or obsolete. Please check the latest ECU information.
As you can see, the content of this page is in english, so that this project could be shared with a maximum number of persons. The aim of this project is to design both hardware and software that are necessary to access to the data from the ECU. Please feel free to pass any information, comments and remarks related to this project.
Warning: Information from this site is provided as is, with no warranty of any kind from the author. Information is subject to change without notice. No support and no material is available from the author.
DefinitionsModern vehicles are equipped with a variety of environmental, safety and other features that require some form of computer control. All EFI vehicles have at least one electronic modules (including a computer) that controls the fuel injectors and usually the spark timing. Other features such as electronic transmissions, antilock braking systems and air bags require additional electronic modules for monitoring and control. Modules communicate information electronically between themselves via a bus. A bus is just a computer term for a wire (or set of wires) that carries electronic messages from one part of a computer-controlled system to another. The bus in most EFI vehicles consists of a single wire that carries a 5-volt serial data stream. Each module that is connected to the bus may broadcast and receive discrete packets of information via the bus.
OBD stands for On-Board Diagnostics and has been on most vehicles since 1981. The first generation of OBD (or OBD I) was originally designed as a means to monitor various systems on a vehicle (i.e. fuel injection system, ignition system, emission system, etc.) and detect any failures it sees. While the vehicle is running the computer will illuminate the MIL (Malfunction Indicator Lamp: either a "Check Engine" light or a "Service Engine Soon" light) on the dashboard to warn the driver that a fault has been detected. At that point, the computer is programmed to generate and store a numeric fault code (two or three digit code) that is associated with the failure. This is when a Code Reader becomes useful. OBD I covers the years of 1981 through 1993. OBD I was not named until the emergence of OBD II. This second generation of OBD was introduced universally in 1996 as part of a government mandate to lower vehicle emissions pollutants. These OBD II systems are found in vehicles built from 1996 to present. This recent system is a far more advanced and precise version of the first generation but the concept is still the same. The computer still monitors vehicle systems to look for faults, vehicles computer still uses an MIL indicator to warn the driver of problems, and codes can still be pulled to identify the systems or circuits where the problem was detected.
HardwareThe idea is to make this project as popular as possible, so that any kind of PC would work. In the begining, testing shall be executed with the help of a desktop PC (Pentium II MMX 166 Mhz, 32Mb RAM) running MS WINDOWS 98 and a lap top PC (Pentium 100Mhz, 8Mb RAM) running MS WINDOWS 95.
On the other hand, I'm investigating the possibility to use a pocket PC (SH3 processor running under Microsoft CE rev. 3) as a very fancy and easy to handle terminal.
Finally, after attempting to create the ultimate interface, I decided to switch back to good ol' circuits. Again, the design mathes the following requirements:
Ecu data can be read/write using one single wire (pin G from the diagnostic plug). This line is kept at the logical HIGH level by a pull up resistor wired to the 12V, helping to square the signal. TTL to Serial protocol convertion is performed by a specialized chip (MAX232A). The whole circuit power supply is drown from the car's battery (typ. 12v).
This circuit has been designed, built and tested using a bread board and a lap top computer. Connection to the ECU is not necessary for testing this circuit, because the same data line is used for input and output. A PCB will later be designed once the reliability of the circuit will be demonstrated.
Software
ECU2PC software shall be written in Micrcosoft Visual Basic rev. 6, due to availability and programing skills reasons. The tricky 8192 baud rate imposes the use of API calls in order to manage the serial comm port. As a reminder, let's recap the ones used here:
Definitions (and variable formats) can be found in the API viewer, while more information is available from MSDN Library. The big surprise is that the 8192 baud rate can be simply entered in the parameters line from the BuildCommDCB function, and I had to plug a scope to the serial port to make sure of this! Data requests and capture shall be performed using the ALDL frames, as described in some nice pages referenced below. The project itself shall contain three forms!
The picture below illustrate the bar graph form:
LinksMany, many thanks to the nice persons who published the very needed information. Investigating the field of ALDL is just like cryptlogy: you deadly need a starting point! Then its just a matter of logic, method and intuition. Experience in this area will save your time and nerves.
Data format
The mandatory tuning tips:
http://www.diy-efi.org/gmecm/
A very good starting point:
http://www.geocities.com/MotorCity/Shop/9938/diagnostics/baud8192.html
A summarized version of ECU data format:
http://www.syntaxis-technology.co.uk/lotus/aldl.html
Some more details:
http://www.seanster.com/scantool/better_data_format_with_timings.html
Some very interesting information about motronic ECU:
http://www.ludd.luth.se/~rotax/motronic/motronic.html
Andy's clean and nicely shaped information:
http://www.andywhittaker.com/ecu/aldl.htm
COMMUNICATION HARDWARE
A Lotus fan site containing plenty nice information related to the GM ECU:
http://www.andywhittaker.com/ecu/aldl_hardware.htm
A nice looking site with plenty ALDL information:
http://www.techedge.com.au/vehicle/aldl8192/8192hw.htm
An other interface design:
http://www.syntaxis-technology.co.uk/lotus/hardware.html
ELECTRONIC COMPONENTS
78L00 Data sheet:
http://us.st.com/stonline/books/pdf/docs/2143.pdf
MAXIM's site:
http://www.maxim-ic.com
4n35 data sheet:
http://ds.dial.pipex.com/isocom/4n35.htm
An other data sheet library, including the 4N35 opto coupler:
http://alds.stts.edu/datasheet/index.htm
RS232C specification
A lot of well presented RS232C information:
http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
Interfacing systems through RS232C (almost everything you need to know):
http://www.beyondlogic.org/serial/serial.htm
RS232C specifications:
http://www.rs485.com/rs485spec.html
A very well designed private web site with plenty usefull information about RS232C protocols:
http://www.lammertbies.nl/comm/software/RS-232.html
Interfacing system through RS232C:
http://www.airborn.com.au/rs232.html
http://www.arcelect.com/rs232.htm
Wirings:
http://www.blackbox.nl/techweb/intrface/rs232d.htm, http://www.blackbox.nl/techweb/intrface/rs232c.htm, http://www.blackbox.nl/techweb/intrface/rs232.htm, http://www.blackbox.nl/techweb/intrface/rs232db9.htm
SOFTWARE
A list of available software:
http://www.andywhittaker.com/ecu/ecu_software.htm
REFERENCE INFORMATION
The real ECM content (Data and routines) How did they get this information?
http://www.cableone.net/rahmrh/disassnotes.html
Acronyms:
http://www.ericcameron.com/Niec/automotive_acronyms.htm
Glossary:
http://www.ag.auburn.edu/users/gparmer/efi/glossary.htm
General information about GL ALDLs:
http://www.mindspring.com/~amattei/aldl.htm
ALDL basics, Lotus oriented:
http://www.lotus-carlton.fsnet.co.uk/aldl_basics.htm
An other ALDL basics Lotus oriented site:
http://www.espritfactfile.com/ECM.html
FAQ about OBD:
http://vehicletest.state.ma.us/obdqa.html
An other very well documented FAQ about OBD:
http://www.sema.org/faq/obdII.cfm
An other well documented FAQ about OBD:
http://www.autocheckup.com/faq.htm
ECU codes and curative actions:
http://www.gnttype.org/maint/malf.html
ADLDL information about PONTIAC Fiero:
http://www.euronet.nl/users/fo_elmo/techno.htm
CAN at Bosch:
http://www.can.bosch.com/
RésuméUne fois n'est pas coutume, le contenu de cette page est en anglais. Le choix de cette langue permettra de partager ce projet avec le plus grand nombre de personnes possible. Le projet ECU2PC consiste à étudier et réaliser les moyens matériels et logiciels nécessaires pour accéder aux données mémorisées dans le boîtier de gestion du moteur. Toutes les contributions, avis et conseils sont les bienvenus.
Important: Les informations contenues dans cette page sont mises à votre disposition en l'état. L'auteur de ce site ne saurait en aucun cas être tenu responsable des conséquences d'une information erronée ou utilisée de manière inappropriée. Aucun support ni aucun matériel ne sera fourni par l'auteur.