2011 Kawasaki Concours CAN Bus

Over 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 Background

First, 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 Setup

In 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 IDs
Arbitration 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 Parameters

Usage	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 Status

Condition	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 Status

Condition	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 Status

Condition	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 Steps

As 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

Most excellent information....my brane hurts now. 

I'm hoping you'll be coming up with a cheap warp drive..
 

+1

+2   

Is someone's riding season over? 

Have you figured out the message that turns off warnings (such as TPMS low battery)? The message that gets sent when push and hold top button, push and release bottom button, release top button. Would love a way to do this with just a single button on the handle bars. I'm assuming these PANIC!!! ALL HOPE IS LOST!! warnings are one day going to get me killed and if I had an easy way of shutting them off, they might not kill me. I'm also assuming the only reason I'm still alive is because of BDF's device to turn off the low fuel warning.

RedRambler,
you keep pointing out how low cost is your set up to hack into the CAN Bus, but you neglect the immense knowledge that you seem to have. I am an engineer myself, but mechanical, and I deem all electronic things as pure witchcraft; stuff that in terms of comprehension could as well be sitting after Saturn's rings. How a human being can accrue and put in use all this stuff is beyond me. Thanks a lot for sharing.
 

Good thread, just found it.

Martin, the mysterious electrons are not so bad once you begin to think of them as mechanical objects rather like marbles or ball bearings. Then everything becomes a bit more clear. Besides, no 'real man' would ever admit to frolicking with invisible, magical things that travel in a circle but have no mass. Even worse is the 'holes' that counter those ridiculous electrons; the 'holes' are the compliments of electrons but strictly imaginary as the negative of a negative (which is NOT positive) cannot exist.

 

Brian

RedRambler,
you keep pointing out how low cost is your set up to hack into the CAN Bus, but you neglect the immense knowledge that you seem to have. I am an engineer myself, but mechanical, and I deem all electronic things as pure witchcraft; stuff that in terms of comprehension could as well be sitting after Saturn's rings. How a human being can accrue and put in use all this stuff is beyond me. Thanks a lot for sharing.
 

I cannot answer your question with any certainty but I do not think so. I believe the low fuel warning is hard- wired into the system and is not merely a message send by CAN bus. But I would have to re- visit my notes and schematics to know.

One of the problems with these complex vehicle systems is that various parts are located in different places. For example: the low TMPS battery warning is located in the TMPS sensor itself rather than the ECU on the bike, so it is impossible to re-code the ECU to behave better regarding the early warning the sensors present when cold. Now there is always the possibility of interrupting the error before it gets to the dash display but I doubt it would be practical even if possible.

Brian

Have you figured out the message that turns off warnings (such as TPMS low battery)? The message that gets sent when push and hold top button, push and release bottom button, release top button. Would love a way to do this with just a single button on the handle bars. I'm assuming these PANIC!!! ALL HOPE IS LOST!! warnings are one day going to get me killed and if I had an easy way of shutting them off, they might not kill me. I'm also assuming the only reason I'm still alive is because of BDF's device to turn off the low fuel warning.

Excellent work, and thanks for post this!

Just a thought but you might be able to help yourself a bit by reverse engineering what individual devices are sending to the KiPass ECU; for example, the tire pressure sensors send additional information such as the low battery warning. The originals used an Infeneon SP 30 and later, the SP 35; the data sheet for either one may be most helpful in trying to determine what data the ECU receives.

Again, great job and great info.!

Brian

2011 Kawasaki Concours CAN Bus

Over 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.

<snip>

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

This is what it will take to keep these bikes running and out of the scrapyard when electronic gremlins pop up... cracking the code is first, bypassing it with a viable workaround is second. Stick with it, this is important stuff. Steve

RedRambler,

Great Information!!  I've been meaning to do this exact thing and I have a particular interest in the diagnostic and FOB programming commands used by the KDS box.  It's on my list of things to do this winter...

If we can get access to a KDS system for a few hours, it should not take long to capture all the data we need to document the diagnostic interface. Building a do-it-yourself programmer for key fobs and tire sensors would then be straightforward.

I look forward to seeing the results of your work. PM me if I can assist.

RR

If we can get access to a KDS system for a few hours, it should not take long to capture all the data we need to document the diagnostic interface. Building a do-it-yourself programmer for key fobs and tire sensors would then be straightforward.

I look forward to seeing the results of your work. PM me if I can assist.

RR

I have a KDS in my possession.   

Ah Hah! 

 

This is great work! Thanks for sharing.

RedRambler:

I have a TPMS sensor that needs to be programmed into the ECU and I thought instead of pulling the front wheel to maybe or maybe not find the sensor ID I would try setting up something similar to what you were experimenting with.

I am using the Arduino Nano as well and the MCP2515 Can Controller. I figured I would just send the data to the laptop for now and once I got it working I can fiter the ID's and take the laptop for a ride and get the sensor ID I need.

For some reason I am not getting any data off the bus and I am at a loss to see what I am doing wrong. I was wondering if you could take a look at what I have setup and see if you can point me in the right direction.

I am connecting to the Diagonostic conenctor on the the Can H and CAN L pins as below.

Diagnostic Connector:
-----------
| O      O |
| O  O  O | <---GY/BL (Can High)
-----------
       ^
        |________ LB (Can Low)


I initialize the can controller to 500kbs

if(CAN_OK == CAN.begin(CAN_500KBPS))

The read of data is just a loop so anything that comes into the Can buffer should be sent to the laptop screen. I configured another CAN controller that is transmitting and connected CAN H/L between them and I receive data so I can assume at least the harware is correct and working.

Any information wouyld be greatly apprecited.
Thanks;

Paul

RedRambler:

I have a TPMS sensor that needs to be programmed into the ECU and I thought instead of pulling the front wheel to maybe or maybe not find the sensor ID I would try setting up something similar to what you were experimenting with.

I am using the Arduino Nano as well and the MCP2515 Can Controller. I figured I would just send the data to the laptop for now and once I got it working I can fiter the ID's and take the laptop for a ride and get the sensor ID I need.

For some reason I am not getting any data off the bus and I am at a loss to see what I am doing wrong. I was wondering if you could take a look at what I have setup and see if you can point me in the right direction.

I am connecting to the Diagonostic conenctor on the the Can H and CAN L pins as below.

Diagnostic Connector:
-----------
| O      O |
| O  O  O | <---GY/BL (Can High)
-----------
       ^
        |________ LB (Can Low)


I initialize the can controller to 500kbs

if(CAN_OK == CAN.begin(CAN_500KBPS))

The read of data is just a loop so anything that comes into the Can buffer should be sent to the laptop screen. I configured another CAN controller that is transmitting and connected CAN H/L between them and I receive data so I can assume at least the harware is correct and working.

Any information wouyld be greatly apprecited.
Thanks;

Paul

seeing as I couldn't find where he actually combined KDS and his system, and even if he did, it would not extract a code number for a TPS that was not prior manually input into that ECU via KDS, (it must be manually typed in), combined with the fact he has not been here for over 3 years...
Last Active: May 09, 2016, 08:33:32 am

I would say stop connecting wires, and attempting right now, as the cost for an error on your part will be very high, compared to removing a tire and reading the "needed" code printed for the sensor...
Once input into the system, using a KDS, that number (i.d. number) remains there, and can be seen using the KDS... but unless it was manually input... it will not be identified, or read...

sorry.

MAN OF BLUES :

Finally figured it out, the libraries I was using didn't have any parameters for crystal frequency and therefore my baud rate was not correct.
Once I sorted that out I am getting data off the bus so with a little more programming I should be able to retrieve the data I need.

Thanks;