Supported Hardware Interfaces
This manual applies to Version 1.05 of freediag
Table of contents:
Electrical Interface Types
There are various common hardware interfaces used for diagnostic
interfaces to vehicle electronic control units (ecus). Most manufacturers use
one or two such interfaces for all systems on a vehicle. These include:
ISO9141 and ISO14230 are essentially compatible at an electrical level
(with the exception that the latter will work on 24 volt vehicles).
The freediag protocol stack supports the above list with the exception of
the CAN. The US OBDII standard and the European EOBD standard for
communicating with emissions related ECUs do not mandate CAN support.
The ISO protocols are generally used by European Vehicles, and the two
SAEJ1850 types by Ford and GM.
At a software level, ISO14230 is a vastly extended ISO9141-2 protocol that
supports much longer data frames and much quicker communications startup with
Further information can be obtained from:
About Smart/Dumb classification
There are two general types of interfaces, referred to as "active" / "smart"
(with an onboard microcontroller) and "passive" / "dumb" (no mcu, only signal
level translation and possibly opto-isolation).
"Active" IFCs are very friendly for the programmers, because
they take care of all the car protocol timing issues, and turn the
very strange and demanding signals into a simple PC serial port flow
of characters. This is like using the "AT"modem commands, so you can
see how easy it is. So timing is not critical and can be left to the
interface HW, and logical results are garanteed at the SW level. However,
the protocol is interface-proprietary.
It may also set limits on what freediag can do outside of what the interface supports,
such as custom protocols over standard layers etc.
"Passive" IFCs have very little electronics on them, because they
only try to protect the PC serial port and adapt the voltage levels (sometimes with
optical isolation) . This means that the PC is dealing directly with the
car's ECU signals, and therefore the timing must be VERY precise. But
these IFCs have one advantage: they are open-source-friendly and low-level enough
to allow any protocol to be used. In some cases they can also be faster than "smart" interfaces.
Freediag Supported Interfaces
Freediag contains various drivers for different adapters that connect the
PC serial port to a vehicle. Certain interfaces support more protocol types
than have been implemented/tested within a driver, and some interfaces need
to be ordered with special attributes (such as their address) to work without
recompiling the freediag software library.
- Generic dumb serial adaptors
Freediag Driver: DUMB (diag_l0_dumb.c)
*** read doc/dumb_interfaces.txt !!! ***
These are generic serial to K-line interfaces, typically very simple circuits *without* an onboard microcontroller.
VAG409 / KKL409 interfaces fall in this category. Other examples include:
Andy Whittaker's OBD-II ISO9141 interface;
Silicon Engines ISO 9141 interface:
It is supplied in a robust box with lots of lights. This interface was used to
develop the first bits of the freediag project. It is functionally the same
as the above two interfaces (with the exception of all the lights and the
Jeff's OBD-II ISO 9141 interface:
This site shows you how to build a generic serial to ISO9141 interface.
Availability : various vendors, or DIY projects
- B.Roadman ISO9141/VPW/PWM interface:
Freediag Driver: BR1 (diag_l0_br.c)
Another commercially available interface, we haven't yet tested the ISO9141
side of the interface (supports address 0x33 only), and it does not support ISO14230. Future versions
will support ISO14230 and we used this interface to develop the
J1850-VPW/PWM support in Freediag. Thanks to B. Roadman for the donation of
hardware to the project.
These qualify as "smart" interfaces.
- Multiplex Engineering VPW, PWM, and ISO 9141-2 interface:
Freediag Driver: MET16 (diag_l0_me.c)
When ordering this interface you must order a T16 type interface.
Multiplex Engineering produce two varieties of the T16 interface:
- T16-002: opto-isolated interface that requires power from the PC's
serial port and uses a straight through male-female DB9 cable.
- T16-003: Non-opto isolated interface, uses a null-modem female-female
DB9 cable, doesn't require (much) power from the PC.
Many PC's do not provide enough power to drive the T16-002 interface and
thus errors will occur (and "checksum error" messages will be printed by
the freediag software). As the T16-003 has no opto-isolation there is a
slight risk of damage to the PC. According to the manufacturer the risk is
low and is negligible unless the vehicle is connected to a battery
When ordering an interface an interface that operates at 19200 baud and
uses address 0x38 should be specified, or simple modifications to
diag_l0_me.c and recompilation will be needed.
The T16-002 interface was used to develop support for smart interfaces in
freediag, it worked on a modern Sony Laptop but not on various branded PCs
Availability: See website
- ELM32* based interfaces:
Freediag Driver: ELM (diag_l0_elm.c)
The ELM32x ICs are smart protocol translators that are frequently found in recent USB->OBD cables. Freediag partially
supports these devices. Be aware that many so-called ELM32x adapters use a cloned but not completely compatible
IC. Most cheap devices sold on eBay will be clones.
These qualify as "smart" interfaces.
Availabilty: IC by itself direct from vendor, or assembled interfaces from various third parties
- CARSIM interface:
Freediag driver: CARSIM (diag_l0_sim.c)
The CARSIM interface allows testing of higher levels (L2, L3) without
having an actual car connected. It reads requests and responses from a file.
This was coded by vnevoa ~2004. From his presentation:
Basically, it is a file reader and parser that searches for the byte
sequence that is being sent to the car, and if it finds any number of
answers for it, it simulates the responses from the car. I included a
simple parsing mechanism to simulate whatever test values we want by
placing a few text tokens inside the response sequences, which get
translated into byte values through specific functions.
(*) Support for ISO14230 software layer, not for 24V vehicles.
(1) Should work, but not tested.
(2) Will work in some applications [including OBDII] but h/w doesn't
support all of the features of the protocol.
(3) Support planned by h/w manufacturer.
(4) ELM support is incomplete in freediag.