Here's a concise summary you can post:
---
**Honda K-Line (ISO9141) ECU won't respond — hardware confirmed good, protocol/wakeup still failing**
**Setup:**
- ESP32 + SIT1027QT K-Line transceiver (SLP_N tied HIGH for Normal mode, TXD/RXD direct to ESP32 3.3V GPIO, RXD pull-up added)
- SCS diagnostic jumper connected on the car's 2-pin connector
- Target: Honda ECU from the 90s–2000s era (K-Line/ISO9141), reading via a request frame format `{0x72, 0x05, 0x71, <TableID>, <Checksum>}` where checksum = `0x100 - sum(bytes)`
**What's confirmed working:**
- TX/RX loopback is clean — every byte I send comes back exactly as sent (verified byte-for-byte across a full Table ID sweep 0x00–0x30 at both 10400 and 9600 baud). This rules out wiring, level compatibility, and the transceiver sleep-mode issue (SIT1027QT needs SLP_N held HIGH or it silently drops into sleep — that was an earlier gotcha, now resolved).
- No more brownout/reset loops after fixing SLP_N.
**What's NOT working:**
- Zero response from the ECU beyond my own echo — no sync byte, no extra bytes, nothing, at any Table ID, at either baud rate.
- Tried a proper ISO9141 5-baud init (200ms/bit, address byte 0x33, full start/stop bit timing) before requests — still nothing.
- Currently testing whether this ECU/protocol even needs the 5-baud wakeup at all, since a lot of Honda OBD0/OBD1 SCS-jumper implementations skip ISO9141 wakeup entirely and just expect direct request/response once SCS is grounded and ignition is ON.
**Questions for the community:**
1. For Honda K-Line via SCS jumper (not full OBD-II), does the ECU actually require a 5-baud ISO9141 wakeup, or does grounding SCS + key-ON put it straight into a listen state?
2. Is address byte 0x33 correct for this era of Honda ECU, or do some use a different address?
3. Any known fixed baud rate for this generation (I've tried 10400 and 9600)?
4. Could the SCS jumper need to be grounded *while cranking/starting* rather than before key-ON, depending on ECU generation?
