
As simple as the driver circuit is there are a few items which should be mentioned. Specifically Volkswagon made a few pre OBDII cars with a wiring mistake in which the K and L lines were actually wired directly to battery power. The result was that when a scan tool with the simple interface shown above was connected it would fry the transistors. To prevent this from happening on my scan tool, I included some poly fuses on the K and L line which will open long before the transistors are damaged.
Now that the driver circuits are done it on to the receiver functions for the ISO. A simple solution might seem to be a circuit as shown below:

In fact on the first OBDII system I made had a similar circuit. The problem is that the ISO specification states that threshold for logic 0 is when the K line is less than 10% of the battery voltage. Thus the circuit above would work on most cars but not all as I discovered. The solution is to use a comparator which compares the K or L line with the battery reference.

The ISO protocol uses an asyn serial transfer here if we look at the data bus as shown below, during a transmission.
The bus when nothing is being transmitted is at a logic high
level, battery voltage (12V) for the ISO bus. When a device transmits some data
it starts with a start bit which is always active low. Then it sends the 8 bits
of data starting with the least significant bit first. Thus in this example we
send out the data bits 01001001 or hex 45h. One can imagine that the start bit
is needed to signal the start of the data transmission,
the stop bit is needed such that if another byte (8 bits) of data follow it
needs to have a high bus to signal before the start bit goes low.
ISO protocol uses a simple method of collision detection, specifically when a device is attempting to communicate on the bus it will wait a predetermined time for the bus to become idle, which is when the bus stays at a passive state (12V on K/L line). Then it will start communicating by pulling the K line low for one bit time as a start bit. After which the device will start sending out it’s data, however if the device is sending out a passive bit, then it must check to see if the K line is indeed passive. This is used for collision detection, to understand it lets imagine that we have two devices attempting to use the bus at the same time.

For example if we have two devices like above and each device is trying to clock out data at the same time we can get a situation as shown below:

From the schematic and the above example it is easy to see that the simple solution is that when a device transmits a passive bit, logic high in example above, the device should verify that the bus is at passive level. When the bus is not at the passive level the device should stop transmitting wait for idle bus and then try again. For the above example if the devices checked for bit collisions our example would become.

Here what happens is that device 2 gives up the bus to device 1 when it realizes that it requested the bus to be at a logic high level (passive state) and it was actually at logic low (active state). Thus device 1’s data got out on the bus where as before garbage was transmitted. This bit level collision detection requires a buss to have an active and passive state as noted above. When we discuss the other protocols we will revisit this again as they all use a similar method for bit level collision detection. To implement the collision detection in software the code will need to monitor the bus when the code reader is transmitting a logic high bit. Thus what happens is that when a logic high bit is transmitted we wait half the bit time and check to make sure the bus is still high. If the bus is not high we assume that someone else got the bus and we give up and try again after bus goes idle.
The data packet specification that the ISO bus uses is referenced in J1979 standard. The packet is made up of a three byte header followed by up to 7 data bytes and single byte checksum as shown below.
|
Message Header |
Data Bytes |
CheckSum |
||||||||
|
1 |
2 |
3 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
1 |
|
68h |
6Ah |
F1h |
|
|
|
|
|
|
|
|
When the OBDII code reader connects to the cars computer system it must follow some detail steps in order to initiate the communications.
Of course with all protocols the steps above need to be followed with in certain timing parameters.
|
Source |
Tester |
W1 |
ECU |
W2 |
ECU |
W3 |
ECU |
W4 |
Tester |
W4 |
ECU |
P3 |
|
Parameter |
33h |
55h |
08h |
08h |
F7h |
CC |
The above table show the initiation sequence where W1,W2,W3,W4, and P3 are timing requirements shown below.
|
Parameter |
min (ms) |
max (ms) |
|
W0 |
2 |
∞ |
|
W1 |
60 |
300 |
|
W2 |
5 |
20 |
|
W3 |
0 |
20 |
|
W4 |
25 |
50 |
|
W5 |
300 |
|
|
P1 |
0 |
20 |
|
P2 |
0 |
50 |
|
P3 |
55 |
5 secs |
|
P4 |
5 |
20 |
Additionally when sending out a data packet there are some additional timing parameters. When the OBDII code reader (tester) is sending out a data packet for example:
|
69h |
6Ah |
F1h |
01h |
00h |
C5h |
Then the time between each byte is required to be P4 from the table above. Once the ECU gets the message it will send a response with in P2. Finally the code reader must make any further requests with in P3 time period. If the code reader waits any long than 5 seconds between requests it must go through the 5 buad initiation again. Finally before the tester can send out a packet of data it must wait at least W5 time period.
As a side note you will notice that when the ECU response to the 5 baud initiation sequence it sends out 55h this since the LSB of 55h is a one we can time the period the K line is low for the start bit to determine the baud rate. This technique of determining baud rate is called auto baud and had been used for years in modems.