2011 Kawasaki Concours CAN BusOver the past several weeks, I have been studying the CAN bus on the Kawasaki Concours to understand how it works. I wanted to determine some of the basic operating parameters of the system, as well as decipher the communication protocol that Kawasaki used. I have been partially successful in this effort, and I wanted to post my learnings here for others to build upon.
CAN Bus BackgroundFirst, some background information on CAN bus technology may be helpful. CAN bus is a communications protocol and physical specification defined by ISO 11898-1 that is commonly used on most new vehicles today. This protocol allows computers on a vehicle to pass information back and forth as needed to operate the vehicle. The CAN system uses differential transmission on a twisted pair of wires, somewhat similar to how Ethernet works in LANs. Multiple computers are connected to a single pair of wires, so all messages broadcast on the bus are received by all nodes. There is an ID number associated with each message (the Arbitration ID) that defines generally what information or request is contained in the message. The computers receiving messages on a CAN bus use the arbitration ID to determine whether the message is intended for themselves. In times of heavy traffic, the arbitration ID is also used to ensure that higher priority messages get through, while lower priority messages are delayed. In addition to the arbitration ID, each message has a Data Length Code (DLC) that indicates the number of data bytes contained in the message. Each message can contain a maximum of eight data bytes.
On the Kawasaki Concours, there are five computers that are attached to the CAN bus: 1. KIPASS ECU, 2. Fuel Injection ECU, 3. Steering Lock ECU, 4. K-ACT ABS ECU, and 5. Meter unit ECU. There is also a connector under the seat to attach the Kawasaki Diagnostic System (KDS) to the bike for diagnostic purposes.
Test SetupIn order to analyze the CAN bus messages that were being sent, I built a CAN bus analyzer from the following components:
• Arduino Nano board containing an ATMega328P microprocessor running at 16 Mhz.
• MCP2515 can bus controller
• 32KB FRAM SPI non-volatile memory
The Nano was connected to a laptop using a USB cable in order to display the messages that were captured. The Serial Peripheral Interface (SPI) connection between the Nano and the other two components was set to run at the maximum speed of 8Mhz. I modified the Nano slightly to enable it to work with my Atmel Dragon programmer/debugger. The total cost of these three components is under $20.
The MCP2515 CAN bus controller was connected to the KDS diagnostic port under the seat. I extracted the correct pins from the 6-pin KDS connector, soldered a short length of cat-5e cable with a female RJ-45 8-pin connector, and replaced each pin back into its original position in the KDS 6-pin connector. I then attached another length of cat-5e cable with a male RJ-45 connector to the CAN bus analyzer, allowing me to easily connect and disconnect the test setup to the bike. I stored the test electronics in the tool storage compartment to keep it protected and out of the way. This setup allowed me to connect the CAN bus analyzer to the bike without interfering with the ability to connect a KDS system.
Because I had no knowledge of what messages I might encounter or even what bit-rate the system used, I put the controller in listen-only mode until I was certain that I had figured out how to properly set up the CAN interface. Here are the setup parameters that I am using for my test board:
• MCP2515 oscillator frequency: 8Mhz
• Base Baud Rate: 500 Kb/s
• Baud rate Prescaler: 1
• Synchronization Jump Width: 2 Time Quanta
• Propagation Segment 1: 3 Time Quanta
• Propagation Segment 2: 3 Time Quanta
Message Decoding Technique: To decode the CAN messages, I first had to write a program to collect and display those messages. My first software routine simply saved all messages and printed them out when the buffer filled up. This allowed me to observe the messages that were being transmitted during simple things like key-on, key-off sequences.
I quickly realized that most of the messages I received were repeated very frequently, over and over. So I wrote a software routine to record all the messages that changed during a one second interval, and print to the screen only those messages whose values changed. In this way, I could experiment by changing gears, engine speed, rear wheel speed, etc., and then noting what message values were changing. Using this technique, I was able to quickly determine what message IDs were being used for various functions on the bike.
I later modified this routine to ignore all message IDs except one, and print to the screen any message with that ID that was not identical to the previous message with the same ID. In this way, I could focus on one specific message type and observe what changes occurred due to a variety of user inputs.
Finally, I wrote software to filter out all unwanted messages, and save only messages that I knew I wanted to record, or messages that I had never seen before. The messages were saved in non-volatile FRAM. This created a practical way to log data messages while I was operating the bike, which could be printed out later when I returned home.
Key Learnings:• CAN bus operates at 500 Kb/s.
• Uses Standard 11 bit Arbitration IDs.
• No remote frames used under normal operation.
• Very high traffic rate: several thousand messages per second.
• Impractical to log data to EEPROM. It’s WAY too slow.
• Cannot transmit data fast enough to a laptop screen to log all messages, even at 230Kbps.
• Except for diagnostic messages, the protocol appears to be simple: each arbitration ID corresponds to a specific parameter or function.
• Most system critical signals are wired directly to the corresponding processors that need them. Therefore, many parameters (e.g. throttle position) are not normally passed across the bus. These parameters have to be requested via diagnostic requests. Page 1-22 of the service manual contains a basic description of the general information that is floating around on the bus.
• Tire Pressure messages from sensors are repeated 3 times, every minute (approximately). Three messages with the same data are sent except for a counter byte (data5) that indicates the sequence number.
• Tire Pressure messages sent to the display are formatted differently than the messages coming from the sensors and are sent much more frequently.
• Tire Pressure readings from unknown sensors are broadcast with message ID 0x695, having data byte 7 = 0xff. The ID number for the sensor is located in Byte0:Byte3 of the message. By taking advantage of this fact, one can read the TPMS sensor ID from the CAN bus for working sensors when the ID sticker from the sensor has been lost.
• It is very difficult to log every message without message loss with this setup. A better solution is to use a microprocessor with an on-board CAN controller, like the Atmel AVR ATMega32M1. A processor like this would greatly reduce the time required to process incoming messages and provide much better filtering and masking options.
Table 1.
Usage Table for Observed Message IDsArbitration ID Usage
0x010 Front/Rear Wheel Speed
0x011 Timer/Counter
0x018 Brake Status (Brake OFF: Byte0=8, Brake Depressed: Byte0=0)
0x050 KTRC Button Status (See Table 3)
0x058 KACT Button Status (See Table 4)
0x060 Mode Button Status (See Table 5)
0x100 Engine RPM
0x110 Vehicle speed
0x120 Water Temp
0x121 Gear Indicator (data0 = gear, data1 = Neutral indicator)
0x130 Tire Pressure Display
0x205
0x220 Ignition Status (Key on = 1, Key Off = 0)
0x221
0x223 Steering Lock Status (Locked = 0, Unlocked = 1)
0x224 KTRC Mode (Enabled = 1, Disabled = 0)
0x225 KACT Mode (Low Combined = 1, High Combined = 2)
0x227 ECO Mode (OFF = 0, ON = 1)
0x230 KTRC Error
0x310
0x311
0x318
0x319
0x320
0x321 Engine Status (Cranking/Running = 1, Stopped = 5)
0x328
0x32f
0x331
0x340
0x695 Front or Unknown Tire Pressure Sensor Message
0x696 Rear Tire Pressure Sensor Message
0x700 – 0x7ff Reserved for Diagnostic System Requests
Table 2.
Message Formats for Common Display ParametersUsage | ID | DLC | Data0 | Data1 | Data2 | Data3 | Data4 | Data5 | Data6 | Data7 |
Engine RPM | 0x100 | 6 | MSB RPM | LSB RPM | 0 | 0 | 0 | 0 |
Vehicle Speed | 0x110 | 6 | MSB Speed | LSB Speed | 0 | 0 | 0 | 0 |
Water Temp | 0x120 | 6 | MSB water temp | LSB water temp | 0 | 0 | 0 | 0 |
Gear Indicator | 0x121 | 2 | Gear number 1-6, 0 for neutral | 0x01 for neutral, 0x00 otherwise |
Tire Pressure Display | 0x130 | 4 | Front Pressure in 0.2 PSI increments | Rear Pressure in 0.2 PSI increments | Front pressure warning | Rear Pressure Warning |
Front Pressure Sensor | 0x695 | 8 | ?? | ?? | ?? | ?? | Pressure in 0.2 PSI increments | Message counter | Pressure in 0.2 PSI increments | 0x00 |
Rear Pressure Sensor | 0x696 | 8 | ?? | ?? | ?? | ?? | Pressure in 0.2 PSI increments | Message counter | Pressure in 0.2 PSI increments | 0x00 |
Unknown Pressure Sensor | 0x695 | 8 | ID:3 | ID:2 | ID:1 | ID:0 | ?? | Pressure in 0.2 PSI increments | ?? | 0xff |
Table 3.
Message ID 0x050 - KTRC Button StatusCondition | Data0 Value |
KTRC in Self Test Mode | 0x0e |
KTRC Mode off, KTRC button not pressed | 0 |
KTRC Mode off, KTRC button pressed | 2 |
KTRC Mode off, KTRC button held, mode changed | 3 |
KTRC Mode on, KTRC button not pressed | 2 |
KTRC Mode on, KTRC pressed | 3 |
KTRC Mode on, KTRC button held, mode changed | 1 |
KTRC Mode off, KTRC button released | 0 |
Table 4.
Message ID 0x060 - Mode Button StatusCondition | Data0 Value |
ECO Mode off, Mode button not pressed | 0 |
ECO Mode off, Mode button pressed | 1 |
ECO Mode off, Mode button held, mode changed | 3 |
ECO Mode on, Mode button not pressed | 2 |
ECO Mode on, button pressed | 3 |
ECO Mode on, Mode button held, mode changed | 2 |
ECO Mode off, Mode button released | 0 |
Table 5.
Message ID 0x58 – KACT Button StatusCondition | Data0 Value |
KACT High Combined mode, KACT button not pressed | 4 |
KACT High combined mode, KACT button pressed | 5 |
KACT High combined mode, KACT button held, mode changed | 3 |
KACT low combined mode, KACT button released | 2 |
KACT low combined mode, KACT button pressed | 3 |
KACT low combined mode, KACT button held, mode changed | 5 |
KACT High combined mode, KACT button released | 4 |
Next StepsAs time permits, I plan to continue studying the message IDs 0x010, 0x011, and 0x018. 0x010 is somehow linked to vehicle speed, maybe wheel speed sensor readings. 0x011 is a timer or counter, but I'm not sure what it is being used for. 0x018 is a status message. The only status that I have figured out is the first bit, which indicates whether brakes are being applied.
Message 0x32f appears to be related to engine RPM. Could be fuel consumption.
Additional work needs to be done to understand what the TPMS flags and the system error flags.
The diagnostic interface needs to be documented.
Hopefully, my work will motivate some of the very talented folks here to take this a step further and figure out the rest of this protocol. By understanding the protocol, I think all sorts of useful things could be done. (think digital speedo and tach, speedo correction, TPMS sensor programming, Key FOB programming, and more.)
RedRambler