What to do when it doesn't work immediately?

[iwanders]

This issue comes from a comment on 9448f75 by @CallMeIce.

I'm trying to use this library with Arduino Nano(v3) and SN65HVDA100 but i didn't had any luck. When you use it with Arduino UNO , did you use the same schema that was described? or did you used something else?

I tested it with the diagram as described, without R1 and D2 as they are unnecessary in my situation, be sure to set the Enable pin of the SN65HVDA100 high to enable the chip.

If your wiring is correct and the above does not help: Check the voltages; the K-line should be approximately the battery voltage most of the time, the Rx pin follows the K-line but at logic level.

I measured voltage of K-line, and was aproximately the same with batery voltage, but if I measured it again with everything connected ,voltage drop to aprox 7V. And also if I measure the SN65HVDA LIN pin without k-line connected , voltage was about 12V. Also the voltage of Rx pin , range from 0 to 3.5 V. Do you think I might fried the chip?

The K-line that drops to 7V is quite low in my opinion, you should really use R1 and D2 in order to provide sufficient pullup to the K-line. The SN65HVDA100 datasheet recommends 1k, but some other sources use ~500 ohm.

What is the output of the example sketch? If it says init_success:0 the initialization handshake with the ECU fails. In this case, go the the OBD9141.h file and uncomment this line:

#define OBD9141_DEBUG

And check the output on the serial terminal, it should look like:

Looping
Before magic 5 baud.
Before setting port.
After setting port.
First read is: 85
read v1: 8
read v2: 8
v1: 8
v2: 8
init_success:1

If the output is different, it might provide a clue what goes wrong in the OBD9141::init() method. If the handshake fails debugging this is not straightforward, you are best of by hooking up a logic analyzer and investigating what is actually happening on the K-line and on the Tx and Rx pins.

[iacobcatalin]

Hello again, I've done again the circuit and also change the tranceiver(just in case), but also the init_success was 0. I had uncommented debug line, and the response was:

"Looping
Before magic 5 baud.
Before setting port.
After setting port.
Timeout on read 0x55.
init_success:0 "

Unfortunately I dont have a portable logic analyzer, and at my University I can't find one ( i'll try in weekend in front of my university, with a plugged in one, when aren't a lot of students :) ). From the code I tried to expand/short the timeout(just in case) but with no luck. Have you been in the same situation?
Thank you very much for all your help.

[iwanders]

During the initialization the following happens:
The 'slow' handshake is started by sending a byte to the ECU at a baudrate of 5, after that the baudrate becomes 10400 and the ECU should send a 0x55 byte back, which is followed by two more bytes v1 and v2, these should be identical and the reader (the device trying to handshake with the ECU) should respond by sending the inverted value of v2, after this the ECU should answer with 0xCC to finish the initialization.

Based on the debug output you provided, this 0x55 byte is never received from the ECU. There are several things you can try:

• Be sure to use adequate pull-up on the K-line.
• Ensure that the ECU is listening to your handshake (it should be powered); try it with the engine running in idle to be sure. In my situation it works when the engine is off but the key is turned so that all systems are powered, but this might vary depending on the vehicle / ECU.
• It might be that the ECU does not implement the stop bit of the 5 baud sequence correctly; try to disable the delay in this this->kline(true); delay(200); // stop bit line of the init() method and add it to the timeout for 0x55. This delay is used to create the stop bit of the 5 baud sequence, if the ECU does not adhere to the specification it might send the 0x55 byte while we are in the delay.
• Hook up a logic analyzer to the K-line: be sure to use a voltage divider. If you do not have a logic analyzer you can try investigate whether the 5 baud sequence looks correctly by hooking up another Arduino, connect its interrupt pin to the voltage divided K-line and print millis() on the serial port when it changes. If that looks alright, you might try to use a USB serial converter configured at a baudrate of 10400 to see whether the 0x55 byte is actually sent over the bus. (You can also use the second Arduino as a serial converter; there are plenty of how-to's for this on the internet.)
• If you have another OBD reader which works; connect this and use the logic analyzer / USB-serial converter to sniff its communication and investigate what is different.

The last two steps are by far the most insightful to investigate what the problem is, because if you can see what is happening you can probably see what is going wrong. Especially the last step is insightful, as you can record what the correct handshake is. It might be the case that your ECU requires the 'fast' initialization, whereas the one implemented in this library is the 'slow' one.

Have you been in the same situation?

Not exactly the same, but I encountered plenty of issues when I first started this project. With these sort of problems a logic analyzer (or second microcontroller) really helps, and comparing the signal to a working OBD reader also helps. I hope the steps above help solving the issue for you, please let us / me know if it does.

[wanthalf]

Hi. I have a similar problem with Macchina M2 and Škoda Octavia I 1.9TDI (1999). I wonder why the initialization sequence is '11001100', i.e. 51 backwards. According to https://www.blafusel.de/obd/obd2_kw1281.html it should be the address of the unit (ECU is 1), i.e. '10000000'. Even the rest of the init process seems to be different. Is this code supposed to be compatible with KW1281?

[iwanders]

Hi Wanthalf,

This library is not expected or supposed to be compatible with KW1281, that seems to be a proprietary protocol by VW. Unfortunately there are many OBD signal protocols, this library only handles OBD9141-2, which is one of them (ISO 14230 KWP2000 could be added relatively easily; only the handshake is different).

KW1281 seems to be a whole different protocol, not only the initialisation, but also the checksums appear to be different than OBD9141. So I don't see any easy way to adapt this library to suit your requirements.

I'm closing this issue as the discussion of whether or not this library implements a specific protocol is unrelated to the original issue. I hope my reply answers your question.