Some time ago, I designed a number of interface circuits to enable a simple display of running data and error conditions on the Fiat Coupe 16v and 16vt versions. That design and software are now out of date, but the circuits and software can be found here. Since that was designed I have made a number of changes - not least is the adoption of commercial but inexpensive hardware - and can communicate with an increasing number of Fiat, Lancia, and Alfa ECUs.
This software is released under the terms of the current GPL license. Please note the following warning from that license:
There is no warranty for the programs, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and/or other parties provide the program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warraties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair, or correction.
You are encouraged to use and redistribute this software, subject to the terms of the GPL license. You are also encouraged to improve the software!
In Europe and the UK, it became a legal requirement to use a common ECU connection protocol and connector - OBDII - around 2001. Anything prior to this date is likely to be non-standard both in terms of the connector location and type, and the protocols for communication with the ECU.
This software is intended to simplify connection to ECUs built before this time - mostly, these will have been built from the late eighties onwards. Because of the number of possibilities, while it is possible to have a single program which could conceivably talk to all of them, it's simpler to provide a number of different programs, each tailored to a particular ECU, or small group of ECUs. Generally, each version of the software will talk to a handful of cars, each of which uses a personalised version of the same ECU.
Because of the rise of the OBDII standard, adaptors for USB to OBDII are commonly available. Googling for 'VAGCOM 409.1 KKL' will produce hundreds of hits. Most are around a tenner. You'll also need an adaptor to match the OBD connector to the 3-pin AMP connector used by the Fiat group - googling for 'FIAT OBD adaptor' will produce a number of links to suppliers. These usually have a pair of flying leads with clips on the end - the red lead must be connected to the positive terminal on the battery for the adaptor to work. The black lead is ground, and can be ignored as it's also provided in the connection itself.
The final thing you'll need is the necessary drivers. If you're using linux, the device drivers are already part of the kernel and you don't need anything else, but for windows (the software works all versions from XP to Windows 7) you'll need to install the drivers for the USB chipset. Because I'm paranoid, I'd prefer to install from the FTDI driver page. The FTDI chipsets are the most commonly used in these adaptors, and are the only ones definitely known to work.
StarTrek is available in a number of versions. All the version listed on this page expect to interface with the OBDII adaptors above - if you have a microwidget, then you need the version available on the old page linked above or in the box to the right.
This is the original version, modified to work with the OBDII adaptor. It's a windows app which displays the current engine status on a series of linear gauges, with indicators to show the current error status. If an error label is shown in a red cartouche, then there's an error in that function or sensor.
To use, connect the adaptor to the car and turn the ignition on or start the car. Connect the USB to the laptop, and just run the executable. Select the port to which the adaptor has been allocated by Windows from the drop-down list, and select the appropriate engine from the menu. The program will then display current data.
The ECU is the Magneti Marelli P8 by PQP. According to the Fiat documentation, this works with the following vehicles (the square brackets indicate the ECU part number):
This is operated the same way as Startrek, but instead talks to the single-injector FIRE engine used in many of Fiat group's smaller cars.
The ECU is the Magneti Marelli IAW 16F. According to the Fiat documentation, this works with the following vehicles (the square brackets indicate the ECU part number):
This version uses the MSDOS legacy console to run under Windows rather than the graphical user interface. It provides the same functionality as Startrek above, but also gives an expanded explanation of the meaning of the error messages. It speaks to the same P8 by PQP ECU.
To use it, wake up a windows terminal, change to the directory where you've stuck the executable, then type the executable name followed by the number of the port that Windows has allocated to the adaptor (you can use the hardware manager to find this) - e.g. startrek_console 4, where 4 is the port number. The only control is the Q key to quit, and the T key to toggle turbo mode which changes the pressure readings.
This is another console application, started the same way as the startrek console version above. It works in a similar way, but without the turbo key - this is not required on this ECU - and instead provides a way of clearing the error code memory - the D key.
The ECU in question is the Bosch M2.10.4 (and, untested but probably, the M2.10.3 which uses apparently identical protocols and is used on earlier versions of some of the engines below. Note that it does not work with VIS engines. According to the documents, the cars for which this will work are:
As I mention above, each of the MM ECUs operate in slightly different ways. However, most of them work in vaguely the same way. They use a K and L line for comms - the signal timings follow normal RS232 protocols but the levels are ISO9141 (which roughly means '0' is below 10% of V+ and '1' is above 90% of V+ - all other levels are indeterminate.) The data format is always one start bit, eight data bits, one stop bit, and no parity. The K line is used to send data from a tester to the ECU, and the L line returns data from the ECU to the tester. However, an internal connection on the 409.1 KKL adaptors means that everything sent on the K line is immediately received on the L line, followed by the response from the ECU. That means that for every data write, you must perform an immediate data read and discard the byte.
All MM ECUs (of this type) send a data stream of a six bytes at 1200 Baud - the ISO code - when first powered. This can be safely ignored, but can take up to eight seconds to complete, so you should wait for at least that time after the ECU powers up before trying to talk to it.
Some, but not all, MM ECUs require a formal initialisation before they will communicate. The IAW P8 does not, the IAW16 and most others, do. This initialisation takes place at 1200 baud and requires you to send three bytes - 0x0f, 0xaa, and 0xcc separated by 110ms. There is no response from the ECU.
Now you change the baud rate to 7812.5 baud, whether you had to initialise or not.
Thereafter, all communications involve the tester sending a single byte, and the ECU responding with a single byte. Where a two byte answer is required, two separate send/receive byte processes are used.
After receiving a byte (or two) you then apply some fairly obscure transforms to turn the answer into something you can understand and display.
And as it happens, some of the later MM ECUs. The protocol is much more complex for these ECUs and the timing is a lot more critical, which can make talking to them tricky if your computer is busy multitasking.
Most of the communication is done with a packet of data, which must be acknowledged correctly not only at the packet level but also at the character level. However, before this can occur, it is always necessary to initialise the communications. The K line is used bidirectionally, so as above everything sent from the tester to the ECU appears immediately at the input of the tester and must be discarded.
The signature byte '0x10' is sent at 5 baud. Since this is below the minimum speed of the vast majority of modern chipsets, including the USB adaptors, it's usually necessary to simulate this by bit-banging the port. Under windows, you can set and clear the break status of the line on 200ms clock intervals which will achieve this. If the ECU is happy with the format - like everything else, one start, eight data, one stop, and no parity - and critically if the engine is doing under 2,000 rpm, the ECU will respond with six bytes at up to 200ms apart. These bytes are transmitted at 4800 baud, and after this point everything works at that speed. Within 1200ms, but not sooner than 5ms, you must respond with the bit-inverse of the third byte. If you fail to do this, or send it improperly, or the ECU is having a bad day, it will send those six bytes a further two times. If you still don't respond correctly, you'll have to start again with the 5-baud initialisation.
Assuming the ECU loves you, it will now send you thirty bytes of identification data.
These will arrive in a number of packets, and at this point you have to respond using the defined packet protocols. Usually three packets of ten bytes are used, but the specification doesn't say how many - it may choose, I suppose, to send thirty packets of one byte each. However, you will need to receive the packet, and acknowledge it, until you have received thirty bytes of data. Once that's happened, and you've acknowledged the last, you can start asking for specific data.
This is not a particularly robust protocol, but it's what we have to work with. There are up to sixteen bytes in a frame, and as each byte is received it must be replied to with the bit-inverse of the byte, unless it is the last byte in the frame in which case the uninverted byte is returned. The same protocol works in both directions, so if you send a packet to the ECU, you will receive the same inverted bytes back.
Byte 1 is a length byte; the number of following bytes. The maximum this will ever be is 15.
Byte 2 is a frame counter, of the number of frames sent to you. (When sending you also increment the frame count).
Byte 3 is a frame type identifier, which is different depending whether the packet starts with you or with the ECU.
Bytes 4... until count-1 are the data packet. This may be zero, as in the case of an acknowledge packet.
The final byte is always 0x03 - end of transmission. Unfortunately you can't just watch for that byte as it can occur within the data transmission. Very helpful.
| Frame description | Tester | ECU |
| Request error memory read | 0x07 | 0xfc |
| Request error memory clear | 0x05 | 0x09 (ack) |
| Request data memory read | 0x01 | 0xfe |
| Request ADC channel read | 0x08 | 0xfb |
| Request actuator demand | 0x04 | 0x09 (ack) |
| Request end of diagnosis | 0x06 | varies |
| Acknowledge | 0x09 | varies |
| Not-acknowledge | 0x0a | varies |
| Transmit security code | 0x24 | 0xea |
Once the process has been initialised, and the last ID block has been received from the ECU, the tester responds with its final ack. The ECU then responds to that with an ack of its own.
Thereafter, either data packets or acks must be exchanged within an interval of one second from the last transmission to maintain the link; otherwise, you're back at the 5-baud initialisation.
At this point, one would - assuming you just want the running status - request memory reads (frame type 1), where the first byte of the payload is the number of bytes you want to read (max 12), and the second and third are the address of the first of those bytes. They high address is sent first.
The ECU responds with the data packet containing those bytes; it's up to you to interpret them and display the results.
This is still to be done. I'll get around to it one of these days! Meanwhile, look in the code in the various versions above for the details.