ISO9141-2 INIT fails with ECU simulator (OBDLink SX / ELM327) — INIT…ERROR>

[anyzunstudios]

Hi,

I’m using your Arduino ISO9141-2 / K-Line library and I’m having trouble completing the INIT sequence when connecting to my K-LINE ECU simulator sketch. I’ve tried both an OBDLink SX and an ELM327 v1.5, and I consistently get an initialization error.

On the diagnostic adapter side I’m sending:

ATZ
ATSP3
0111 (or any PID)

The adapter replies:

INIT….ERROR>

At the same time, the Arduino serial output shows:

00 00 00
ERROR WHILE RECEIVING STUFF

Hardware detail: I’m using a UART-LIN TTLv3 module from AliExpress with an SIT1021T chip (it seems like a clone of the TJA1021). The module works perfectly on LIN. I’m using these AliExpress modules mainly because I already had them at home for another part of a project I’m building, and since LIN and K-Line are physically quite similar and the TJA1021 datasheet explicitly states “K-Line compatible”, I decided to try them for K-Line as well.

For K-Line, communication works only if I bypass the INIT. If I do this on the OBDLink SX / ELM327:

ATZ
ATSP3
ATBI (bypass INIT)
0111

…then it works and I can read from the simulator. But I’d really like to make the proper ISO9141-2 INIT work both for the K-Line “reader” side and for the K-Line “simulator” side.

Do you think this is likely a timing issue in my setup, or could it be that the SIT1021T / TJA1021-style transceiver doesn’t handle ISO9141-2 init timings reliably (despite being advertised as K-Line compatible)? If you have any recommendations (specific init method, timing parameters, pull-up values, wiring checks, etc.) I’d really appreciate it.

This is the module:
https://a.aliexpress.com/_EvP6LJ6

Thank you very much for your time and for the huge contribution your library makes to the Arduino community. It simplifies K-Line development a lot ;)

Kind regards,
Julio.

[iwanders]

Hey Julio, thanks for the kind words, I'm always glad to see this small project still provide value.

Do you think this is likely a timing issue in my setup, or could it be that the SIT1021T / TJA1021-style transceiver doesn’t handle ISO9141-2 init timings reliably (despite being advertised as K-Line compatible)? If you have any recommendations (specific init method, timing parameters, pull-up values, wiring checks, etc.) I’d really appreciate it.

It's not an issue on your end! I wrote the simulator just provide values for developing against a fake device instead of the ECU in my car. So mostly as a dev tool to use on my desk, I've never tested it against an ELM327.

The second problem with the simulator and the handshake is that it needs to detect the 5 baud init and handle that correctly, only then switch to the serial port... If I recall, it was sort-of-working, but not reliably enough for me, so I actually disabled the init section with a define. You can re-enable it and read the comment here, the actual code for handling the initialisation is in this state machine. I don't remember what the exact problem was, it's over 10 years ago >_<

[anyzunstudios]

Hey Julio, thanks for the kind words, I'm always glad to see this small project still provide value.

Do you think this is likely a timing issue in my setup, or could it be that the SIT1021T / TJA1021-style transceiver doesn’t handle ISO9141-2 init timings reliably (despite being advertised as K-Line compatible)? If you have any recommendations (specific init method, timing parameters, pull-up values, wiring checks, etc.) I’d really appreciate it.

It's not an issue on your end! I wrote the simulator just provide values for developing against a fake device instead of the ECU in my car. So mostly as a dev tool to use on my desk, I've never tested it against an ELM327.

The second problem with the simulator and the handshake is that it needs to detect the 5 baud init and handle that correctly, only then switch to the serial port... If I recall, it was sort-of-working, but not reliably enough for me, so I actually disabled the init section with a define. You can re-enable it and read the comment here, the actual code for handling the initialisation is in this state machine. I don't remember what the exact problem was, it's over 10 years ago >_<

Hello again!

I’ve been working on the library and made a few changes that improved reliability on my side:

1. Replaced blocking delay() usage with a millis()-driven state machine (non-blocking).
2. Implemented a new slow-init (5-baud) detection approach based on RX edge timing.
   It works with 4/5 OBD tools I tested (Torque app via ELM327, OBDLink SX, an OBD HUD display, etc.).
   The only one that still fails is a very cheap multi-brand scanner that reports “connection error”.
   (So it may be stricter about handshake timing, keywords, or inter-byte gaps.)

I also added some new features while keeping legacy behavior (retro-compatible), for example:

• setAnswerBytes() to define variable-length PID payloads:

uint8_t PID[2] = { 0x00, 0x08 }; // Custom response from a 2003 Lexus IS200 1G-FE (Snow Mode Status = ON)
car.setAnswerBytes(0x01, 0xF9, sizeof(PID), PID);

• I added car.onWriteDID(callback), a hook for KWP service 0x2E (WriteDataByIdentifier). When a tester writes to a DID, the callback receives (did, data, dataLen) so user code can handle simple “programming/adaptation” routines over K-Line.

bool onWriteDid(uint16_t did, const uint8_t* data, uint8_t dataLen)
{
  // Example: service 0x2E, DID 0x0055, 1-byte payload
  if (did == 0x0055 && dataLen == 1) {
    if (data[0] == 0xFF) {
      // Do something...
      return true; // Positive response
    }
  }
  return false; // Negative response
}

void setup()
{
  // ...
  car.onWriteDID(onWriteDid);
  // ...
}

One thing I’m still debugging: on replies to these 0x2E requests, my checksum/CRC byte is not always accepted by a strict scanner.
However, the DID write is parsed correctly, the changes are applied correctly in the Arduino side, and the message transmission itself works.
If you can confirm the expected checksum method/coverage for these frames (or any timing quirks), I can align my implementation.

EDIT: Never mind, I've fixed it. The issue was caused by frame truncation (a 0x2E fast-path forcing len=8 and flushing remaining bytes) and checksum calculation using the wrong length / uninitialized bytes. Works fine now 👍

If you’re interested, I can open a PR with the changes (or share a patch/diff first).
Also, if you have recommended slow-init/handshake tolerances that improve compatibility with stricter scanners,
I’d love to hear them.

Thanks!

[iwanders]

Glad to hear you made lots of good progress!

Replaced blocking delay() usage with a millis()-driven state machine (non-blocking).

Yeah, it should've probably been a state machine from the get go...

Also, if you have recommended slow-init/handshake tolerances that improve compatibility with stricter scanners,

I wonder if this is just something small where either the end of the handshake is off by one, or switched to the serial port too early which causes the line to go high? (100% speculating here though).

If you’re interested, I can open a PR with the changes (or share a patch/diff first).

Yes, we should explore that I'd say? I'm not sure how it looks right now, but I expect that with some work we can get it into a shape where I'd be happy to merge it in.

The simulator has been a bit of an odd part for the longest time, I don't think many people use it, but it is very useful for development. It sounds like you did a lot of work on it to get it working and not just against the reader class, but against actual other readers! I think it would be a valuable addition.

setAnswerBytes() to define variable-length PID payloads:

Yeah, good idea, the fixed length ones can call into the variable one to ensure a single codepath. Originally my class only handled the fixed with u8, u16 types. The reader got the variable length support when the DTC stuff was added, the simulator just never got that.

I added car.onWriteDID(callback), a hook for KWP service 0x2E (WriteDataByIdentifier). When a tester writes to a DID, the callback receives (did, data, dataLen) so user code can handle simple “programming/adaptation” routines over K-Line.

Hmm... part of me wonders if we should generalise that to also handle the PIDs... hard to say without seeing some of the code, I'm not familiar with the DIDs, to be honest. Like, it would be neat if asides from the limited list of fixed answers we currently have, this callback could just push the response onto the wire? That way the response can also be variable, and there's nice infrastructure in place that allows more functionality than the fixed answers? (For exampling toggling an LED a different color based on the incoming request?)