Hi everyone,
I am working on a diagnostic adapter for a 2011 Kawasaki Concours 14 / GTR1400, using an Arduino Nano and an MCP2515 CAN controller.
My goal is to communicate with the FI ECU using the Kawasaki KDS3 diagnostic protocol, and eventually translate the diagnostic data into standard OBD-II / ELM327-style responses for applications such as Torque.
I found an older Arduino Forum discussion in which user jimmy06 mentioned reverse engineering the KDS3 software and obtaining the CAN Bus IDs. He also shared a spreadsheet called “Kawasaki KDS3 CAN Bus Commands.”
Unfortunately, that old thread is now closed, so I am starting a new topic in case anyone here has worked on the same protocol or has preserved information from that project.
From the available KDS3 command table, I have information for diagnostic parameters such as:
- Water Temperature – command
0x06 - Engine RPM – command
0x09 - Battery Voltage – command
0x0A - Gear Position – command
0x0B - Vehicle Speed – command
0x0C
What I am still missing is the actual CAN transport/protocol information required to send these commands to the FI ECU:
- KDS3 → ECU CAN request ID
- ECU → KDS3 CAN response ID
- Request payload/frame format
- Response payload/frame format
- Meaning and use of the “ECU protocol code” in the KDS3 command table
- Any initialization/session-start sequence required before sending diagnostic commands
I have already connected directly to the motorcycle CAN bus at 500 kbit/s in listen-only mode and have been analyzing the normal communication between the FI ECU and the instrument cluster.
So far, two signals appear to be identified:
- CAN ID
0x100, bytes 0–1: Engine RPM, apparently a 16-bit big-endian value with approximately 1 rpm/bit - CAN ID
0x120, byte 1: Engine coolant temperature, apparentlyraw - 40 °C
I am now also investigating gear position, vehicle speed and fuel-consumption-related data.
If anyone has reverse engineered KDS3, captured CAN traffic while a genuine KDS3 interface was connected, or has old source code, CAN logs, database information, or notes related to this protocol, I would greatly appreciate any information you can share.
Even a single CAN capture of a KDS3 reading Engine RPM or Water Temperature could be extremely useful for identifying the request/response protocol.
Thank you,
Maxkazoo
Japan