Kawasaki Concours Forum
The C-14, aka Kawasaki Concours-14, the new one :) => Accessories and modifications - C14/GTR 1400 => Topic started by: RedRambler on September 22, 2015, 06:43:23 PM
-
I've been studying the CAN bus on the Connie for a couple of weeks now. While there is still a LOT that I don't understand, there is quite a bit that I have been able to figure out. Basic parameters like vehicle speed, engine RPM, water temp, gear, etc., can be readily read from the CAN bus. Most recently I've been working to decode the TPMS sensor messages. The pressure reading is very straightforward, and I'm pretty sure I have the tire temperature also figured out.
Also, for reasons I won't go into here, my rear TPMS sensor was recently replaced but the dealer lost the sensor code and therefore could not program it to the bike. However, I believe I am able to read the code embedded in the TPMS message that is transmitted on the CAN bus. I have proven that I can read the tire pressure on the rear sensor even though the rear sensor is not programmed to the bike.
I made a trip to another dealer today and spent a couple of hours in the shop, but they were unable to get their KDS software to work to program the code for me. :-\
So, I'm about ready to try to make a DIY TPMS programmer. I was thinking about making 2 or 3 of these and making them available to the members of this group as a "loaner" tool. I'm thinking it could work much like the loaner windshields today: the tools are shipped out to the next person that needs to program a sensor (or maybe even a key fob). The parts to build one should not be more than about $15.
Now for the catch: I'm probably going to need to get my hands on a KDS system for a week or two to be sure I get the commands and responses right in order to do the sensor programming. Is anyone out there who owns a KDS tool willing to work with me to record the commands and responses?
I have already created a CAN datalogger that is logging the CAN messages to memory and I can display those messages on a laptop. All I need to do now is connect a KDS tool, and record the programming sequence. Then I should be able to replay that sequence back to program sensors on other bikes.
And lastly, this exercise is purely for educational purposes only. If I am successful, the DIY programmer will not be for sale.
RedRambler
-
This is a kewl thread.... (note how I spelled "cool" to indicate it is even beyond just plain, old, ordinary "cool"). Can't wait to see how it goes!
-
I was real clise to grabbingine on ebay for 300 last week, it might still be there. My bike is for sale so i decided to pay the stealer.
-
Here's a bit of info that you may have seen before, or not.
http://www.zggtr.org/MGalleryItem.php?id=455 (http://www.zggtr.org/MGalleryItem.php?id=455)
Starting on page 3 there's info on KDS, fobs, and TPMS.
FYI, the bike is programed to read the TPMS sensors, not the other way around.
-
Yes, you are correct. The bike is programmed with the ID numbers of the TPMS sensors. But generally speaking that cannot be done except by a dealer, unless you have access to the expensive KDS system. My goal is to make that capability more readily available to the members of this forum.
-
I am intersted in this,
Being a programer myself, let me know what you have found or if need any help digging or parsing data.
-
There's a guy selling a KDS Module on ebay and has a com cables and the converter which is the newest 57001-1725 for $750. Would it be a worthwhile investment or can you guys hack the system. I was thinking of getting it then do a few reprograms to make up for some of the money I spent. If anyone else is interested, I have the guys contact info or you can find him on ebay.
-
Same system sold a couple weeks ago for $300
-
Red Rambler where are you located??
-
Red Rambler where are you located??
Thanks for the heads up :)
-
... Most recently I've been working to decode the TPMS sensor messages. The pressure reading is very straightforward, and I'm pretty sure I have the tire temperature also figured out.
Tire temperature? How are you going to do that?
-
Sorry guys, I've been traveling out of state for the past 10 days.
I'm located in Birmingham, AL.
-
Tire temperature is commonly reported by tire pressure sensors along with pressure and battery status. On the Connie, it is not displayed for the user to see.
I'm fairly certain that the tire temp is being reported to the ECU but I have not done enough testing to validate the numbers that I am seeing.
-
I've still not been able to get the dealer to program the bike with the rear tire sensor ID. I had an appointment set up to do that but the dealer called and cancelled saying that they could not get their KDS system to communicate with any bikes. So I'm still stuck.
That's just one reason why I want to take on this project. So forum members would have access to a tool to program these sensors themselves at low cost.
RedRambler
-
I've still not been able to get the dealer to program the bike with the rear tire sensor ID. I had an appointment set up to do that but the dealer called and cancelled saying that they could not get their KDS system to communicate with any bikes. So I'm still stuck.
That's just one reason why I want to take on this project. So forum members would have access to a tool to program these sensors themselves at low cost.
RedRambler
RedRambler,
Where are you located ?. If you are in Florida I have a KDS unit & can program that sensor :chugbeer:
-
I'm in Birmingham. I would like to find someone who would be willing to loan me a working KDS unit or who can meet me somewhere so I can do some testing. What I am really after is to duplicate the programming commands so that I can create a small inexpensive TPMS programmer that can be used as a loaner tool for the user s of this forum.
-
Just to update my progress:
I have built a CAN bus datalogger to work with the Connie's CAN system. I chose to use a Arduino Nano microprocessor board, modified to be compatible with my Atmel Dragon ISP programmer/debugger. I also bought a MCP2515 circuit board off Ebay to interface the Nano to the CAN bus. The combined cost for these two parts was about $10. In addition, I ordered a high-speed non-volatile memory from Digikey ($4) to provide storage. Using these three parts, I have been able to log and study the CAN messages going back and forth between the processors.
I wired up this system to the wiring harness of the bike and stored it in the tool storage compartment where it would be out of the way. Last week, I was able to get the bike over to a dealer who successfully programmed the rear sensor ID into the bike's computers. Fortunately, all the commands to do this were logged and saved by the datalogger.
After studying the logged data, it is very apparent that the KDS system first "logs in" with the bike when connected. There is a two part command-response sequence that establishes the initial connection to the bike. Once this is completed, the KDS system then retrieves the part numbers for the three major ECU units on the bike: FI ECU, Steering Lock ECU, and KIPASS ECU. The part numbers are returned by the bike as ASCII encoded strings, and they are readily identified in the data.
That seems to be all that happens until the user issues a command in KDS. In my case, the tech navigated to the menu for TPMS, and the ID numbers for the tire pressure sensors were then retrieved. The command to retrieve the sensor IDs is very straightforward, and I have been able to duplicate this command using my CAN bus interface. The command syntax is as follows:
(front) Arbitration ID = 0x754, DLC = 3, Data0 = 0x02, Data1 = 0x21, Data2 = 0x14.
(rear) Arbitration ID = 0x754, DLC = 3, Data0 = 0x02, Data1 = 0x21, Data2 = 0x15.
The bike will respond with:
Arbitration ID = 0x745, DLC = 8, Data4 - Data7 = 32 bit sensor ID number.
As I said, I have been able to retrieve the sensor IDs from the sensors on my bike using these two commands. I have also been able to retrieve my ECU IDs using similar commands.
Next up is to actually reprogram the rear sensor. The command for that is:
Arbitration ID = 0x754, DLC = 8, Data0 = 0x07, Data1 = 0x31, Data2 = 0x86, Data3 = 0x02, Data4 - Data7 = ID number.
Once I can confirm that I can program the rear sensor reliably, the next step would be to try it on other years to make sure the commands are the same. I feel sure it would be the same on 2011-2014 (the ECU part numbers are the same), but not sure for 2008-2009 models.
I would also like to add the capability to program additional fobs as well. Hopefully, I will be able to find someone with a KDS system that would allow me to record more of the programming sequences. Then we could make a very useful DIY tool, I think.
Sometime soon I plan to post quite a bit more of the technical details of the Kawasaki CAN system, since there is so little publicly available information out on the web.
Incidentally, the sensor ID and sensor readings for all 'unknown' sensors is broadcast on the bus as well using message ID 0x695. Knowing this, one can read the sensor ID from an unknown sensor directly from the bus. This is how I came to figure out the sensor ID for my rear tire sensor (the installer had lost the sticker with the ID number). I gave the dealer the number I had read from the bus, and he programmed it in for me. Now my rear sensor is working like a charm!
RedRambler
-
Neat!
-
OMG!
-
Well done Red!
So there IS a way to retrieve the code numbers from a TPS without taking the tire off?
-
http://youtu.be/__urA6qNxLw (http://youtu.be/__urA6qNxLw)
-
<So there IS a way to retrieve the code numbers from a TPS without taking the tire off?>
There are two options. Neither involves removing the tire.
1. If the sensor ID has been previously programmed into the ECU, you can issue commands to the ECU to return the sensor ID number.
or
2. If the sensor ID is not known and has not been programmed to the ECU, you can connect a device like I have made to log all the 0x695 messages that are broadcast. All messages from unknown sensors are broadcast with ID 0x695, DLC = 8, Data0 - Data4 = sensor ID, with the pressure reading in Data5. Data7 = 0xff for unknown sensors. You would need to connect the data logger and then ride the bike around the block to give the tire sensors time to transmit. They transmit about every minute or so when the bike is moving. The sensor messages can then be reviewed. The sensor ID will be readily apparent in the first four data bytes of the 0x695 messages.
Not only was I picking up the transmissions from my own rear sensor, I fairly regularly picked up messages from tire sensors which were apparently on other vehicles as I rode around the city in traffic. This is really not that surprising when you think about it, since the TPMS sends its data on the 315 Mhz UHF radio band. Any radio receiver within a reasonable range should be able to receive the messages. However, the messages received from a sensor on your own bike are about 100 times more frequent than messages received from other vehicles.
RedRambler
-
Wow!
-
Don't the new style sensors broadcast at a different Mhz?
-
<Don't the new style sensors broadcast at a different Mhz?>
I have a new sensor made by Schrader Electronics and it is marked 315 Mhz. I think the new and old sensors probably use the same frequency and data formats, as they are interchangeable.
RR
-
It would have to be that way to work on the existing bikes.
-
Carry on then.
-
You would need to connect the data logger and then ride the bike around the block to give the tire sensors time to transmit. They transmit about every minute or so when the bike is moving. The sensor messages can then be reviewed. The sensor ID will be readily apparent in the first four data bytes of the 0x695 messages.
First of all, great work RedR'!. :thumbs:
I'm curious about the sensors needing to be on the bike to get the ID. When I've finished balancing a wheel after a tire change and/or a sensor battery change, I've spun the wheel on the balancer a few feet away from the bike and the pressure showed up on the bike after a short interval of a minute or so. I've heard/read that the sensor (the original style that comes apart easily for those that wish to install a new battery) needs to be under pressure for it to "turn on" but I've also heard that it can be simply spun on the end of a string with roughly the same spin radius as the tire to check a replacement battery install. If you get the chance in your research RedR', see which of those statements are correct or if neither are. I guess I could do the same test (for the pressure, not the ID. but you said it's in the same data stream if one can read it), but I recently changed batteries so it's going to be a while until the next tire change, I wish I had thought of it at the time I did the last one.
-
The sensor does not need to sense any pressure to 'turn on'. The string spinning thingie works fine although it has been my experience you will hit at least two COG members even after repeatedly saying (quite loudly) "Watch out, I am spinning a sensor here". After striking as many COG members as seems to be required, continue to spin the sensor with the bike's ignition turned on and the screen set to tire pressure; w/in one minute (post ALL COG strikes- it must be contiguous spinning), the display will flash a warning that there is now zero (0) pressure in the tire, which is absolutely correct. Turn the bike off, mount the sensor (Easy Boys!) in the wheel, mount the tire (Boys!) and inflate.
It is centripetal force that turns the tire pressure sensor on and the lack of same, plus a time delay, that turns it off. All of that is to conserve battery power so it can display the low battery warning after a few months rather than after a few weeks....
Brian
First of all, great work RedR'!. :thumbs:
I'm curious about the sensors needing to be on the bike to get the ID. When I've finished balancing a wheel after a tire change and/or a sensor battery change, I've spun the wheel on the balancer a few feet away from the bike and the pressure showed up on the bike after a short interval of a minute or so. I've heard/read that the sensor (the original style that comes apart easily for those that wish to install a new battery) needs to be under pressure for it to "turn on" but I've also heard that it can be simply spun on the end of a string with roughly the same spin radius as the tire to check a replacement battery install. If you get the chance in your research RedR', see which of those statements are correct or if neither are. I guess I could do the same test (for the pressure, not the ID. but you said it's in the same data stream if one can read it), but I recently changed batteries so it's going to be a while until the next tire change, I wish I had thought of it at the time I did the last one.
-
I personally could not get a new sensor (right out of the box) to turn on by simply spinning it. I tried putting it inside a long sock and spinning it as fast as I could. I then strapped it to a bicycle wheel with the bicycle upside down and tried turning the petals to spin the back tire. Again, no luck. Lastly, I tried taping the sensor to the rear tire of the Connie, and using the engine to spin the wheel. I did get transmissions from the sensor inside the wheel, but not from the new one that I had taped to the spoke of the wheel. That led me to believe that the sensor had to be under pressure to turn on. The sensor I was using was one of the new ones. I have not tried one of the older ones.
However, I won't dispute the success that others on the forum have had with this. I've tried only one new style sensor.
RedRambler
-
It sounds like you may not have had the sensor in the correct position to generate the force in the correct direction. ?? The force must be placed in- line with the air fill fitting; putting the sensor in the bottom of the sock almost certainly will not work.
What I use is a piece of string, tied around the stem so that when the sensor is spun, all the linear force (centripetal force to be exact) is along the axis of the tire valve, exactly as it is when the sensor is mounted in the tire.
Some have speculated that it is some part of the rotation that turns on the sensor but that is not correct; the only forces generated specifically through rotation would all nullify at highway speeds and the sensor would turn off. The only force left that the sensor can sense is acceleration. That is the scientific reasoning that explains it; the coward's way out is to look up the data for the Infenion SP 30 or Infenion SP 35 by tracking down the datasheet and reading it. ;) ;D
Now, all of this applies to the older type sensors supplied by LDL. The newer, potted sensors may well use a different scheme although physics being what it is, I suspect they too use centripetal force to turn the sensor on. And while it <may> be possible that they also require some minimum amount of air pressure in addition to the acceleration to turn on, I doubt it because if built that way they would not sense a low pressure condition if used in a flat tire.
Brian
I personally could not get a new sensor (right out of the box) to turn on by simply spinning it. I tried putting it inside a long sock and spinning it as fast as I could. I then strapped it to a bicycle wheel with the bicycle upside down and tried turning the petals to spin the back tire. Again, no luck. Lastly, I tried taping the sensor to the rear tire of the Connie, and using the engine to spin the wheel. I did get transmissions from the sensor inside the wheel, but not from the new one that I had taped to the inside of the wheel. That led me to believe that the sensor had to be under pressure to turn on. The sensor I was using was one of the new ones. I have not tried one of the older ones.
However, I won't dispute the success that others on the forum have had with this. I've tried only one new style sensor.
RedRambler
-
I knew this would make my brane hurt.
-
C'mon Jim, you can keep up with this- just picture a 1930's gangster swinging a coin around, standing outside, being tough. Now mentally swap the coin for a TPS sensor and then swap the gangster for a tall, extremely handsome motorcycle rider and you will have it to a 'T'.
:rotflmao:
Brian
I knew this would make my brane hurt.
-
The sensor does not need to sense any pressure to 'turn on'. The string spinning thingie works fine although it has been my experience you will hit at least two COG members even after repeatedly saying (quite loudly) "Watch out, I am spinning a sensor here". After striking as many COG members as seems to be required, continue to spin the sensor with the bike's ignition turned on and the screen set to tire pressure; w/in one minute (post ALL COG strikes- it must be contiguous spinning), the display will flash a warning that there is now zero (0) pressure in the tire, which is absolutely correct. Turn the bike off, mount the sensor (Easy Boys!) in the wheel, mount the tire (Boys!) and inflate.
It is centripetal force that turns the tire pressure sensor on and the lack of same, plus a time delay, that turns it off. All of that is to conserve battery power so it can display the low battery warning after a few months rather than after a few weeks....
Brian
Now that was rather funny!
-
It was pretty funny in person too- just enough of a tap to scare them and get their attention but not enough to actually hurt them; otherwise what I like to think of as the 'funny zone'. Who am I kidding- it would be funny even if they got a little hurt but not too much of course.
There is no limit to the goodness that is the entire KiPass system or physics.... but mostly KiPass.
Brian
Now that was rather funny!
-
Saw this on ebay $799 including the Laptop: http://www.ebay.com/itm/Kawasaki-Diagnostic-Tool-KDS3-Combo-KIT/171979720878? (http://www.ebay.com/itm/Kawasaki-Diagnostic-Tool-KDS3-Combo-KIT/171979720878?)
-
It's located in Poland. Would there be anything different about it vs one that would have gone to the US I wonder?
-
To update progress on the DIY TPMS programmer, I've determined that the Kawi uses the standard Unified Diagnostic Services (UDS) protocol for its diagnostic communications over the CAN bus. That fact, along with some extremely helpful data from jwh20 on this forum, has enabled me to decode and understand most of the diagnostic messages I have seen.
So I am able to use my homemade tool to request virtually any data that the KDS tool can get. Sensor readings from most of the sensors (throttle position, barometric pressure, water temp, battery voltage, etc) as well as counters for many significant events (communication failures, sensor failures, hours operated, and over-rev conditions).
Unfortunately, Kawasaki has utilized a security feature of the UDS protocol that requires an exchange of encrypted keys before requests to make any changes are allowed. So we will be unable to actually program new sensors until we find a way to overcome the encryption. I think I have a brute force solution that could work, but it will take some considerable time and programming. In the mean time, jwh20 is working to solve this problem another way. I'm still hampered by not having access to a KDS... :-[
Any data encryption or software reverse engineering gurus out there?
-
Any data encryption or software reverse engineering gurus out there?
Hmm, well darn Red', I thought that was your title. ???
Joking aside, great work so far.
According to the owner's manual, there is a certain low voltage threshold where the linked brakes are disabled leaving the ABS still active in an effort to maintain safety and extend battery life. If you put that on your future research list, many here would appreciate it. That is to say if there where a way to electronically/or diagnostically turn off the linking of the brakes, well that would be interesting to many. Of course I'm assuming that the ECU sends that signal to the ABS ECU over the CAN bus?..
...and that what ever that signal is, could be faked?
Yeah, pretty much talkin' out my rear about something that is way over my head.
-
Red, is that copyright encryption you're running into?
-
Getting a ruling on this. I'll let ya'll know in a day or so how we are going to proceed. Thread is unlocked.
-
Red, is that copyright encryption you're running into?
It's basically just a passcode. You have to know the correct passcode to enable functions that modify settings on the bike, like changing a TPMS ID number. Basically the bike sends you a 3 byte seed, and you have to respond with an 8 byte passcode that corresponds to that seed. If you respond correctly, you can then proceed to program the sensor. If you don't provide a correct passcode, the bike will reject your programming command.
After doing some reading on the internet, its seems that other manufacturers have similar security built in. So its not unique to Kawasaki.
RR
-
According to the owner's manual, there is a certain low voltage threshold where the linked brakes are disabled leaving the ABS still active in an effort to maintain safety and extend battery life. If you put that on your future research list, many here would appreciate it. That is to say if there where a way to electronically/or diagnostically turn off the linking of the brakes, well that would be interesting to many. Of course I'm assuming that the ECU sends that signal to the ABS ECU over the CAN bus?..
...and that what ever that signal is, could be faked?
We would have to figure out how to re-create that condition and then record the messages that are passed. If the FI-ECU is commanding the ABS-ECU to turn off the hydraulic pump to save battery, leaving only the ABS function active, then that command could certainly be spoofed, but I would be surprised if it didn't also generate other alert messages that are displayed on the meter unit (along with a big red light). Re-creating the condition would require disabling the alternator and running the battery down, or using a resistive network to drop the voltage entering the ABS controller. Not sure I'm willing to try that on my bike at this point...
RR
-
It's basically just a passcode. [...]After doing some reading on the internet, its seems that other manufacturers have similar security built in. So its not unique to Kawasaki.
Indeed not. Manufacturers are probably *required* to provide at least some security to prevent people from tampering with the ECU in ways that will make its use illegal (pretty much anything that would affect emissions, noise, or fuel efficiency).
The reason Jim had to analyze it, is that it is against the policy of the Forums to engage in copyright infringement. This case isn't quite so clear.... talking about it is one thing, but publicly posting about how to actually circumvent the protections might set up the operators of the Forums in some type of liability situation.
-
It seems there is a conflict between the Magnuson-Moss Act and the DMCA. John Deere opened Pandora's box by telling people they didn't really own their tractors due to proprietary (word of the day) software.
-
It seems there is a conflict between the Magnuson-Moss Act and the DMCA. John Deere opened Pandora's box by telling people they didn't really own their tractors due to proprietary (word of the day) software.
The DMCA is an abomination. Of course, so are the insanely over-extended copyright laws and stupidly obtuse software patent laws. It is obvious that companies would rather spend all their money lobbying Congress and fighting consumers than creating new ideas or content. Don't get me started!!!
-
At this point guys, let's just get back to the thread's original purpose. If you want to delve into the perceived legalize of the situation, start a thread in Open, but I think we have one already somewhere.
-
Hi Red,
I was wondering if you might be able to help me out. I have a sensor that is missing the ID code (it is not on the label). I'd like to send it to you and have you read it and then send it back to me. Happy to pay you for this service. The catch is that I don't know that the sensor I have is any good. The device appears to be brand new.
-
If it's the early non-potted type there should be an ID label inside it.
-
Very interesting thread but it appears once it went down the "ooh someone's being very naughty and we're worried about legal schizzle" path that RedRambler has "vanished"
His last post oN this thread was Dec 01 2015 and he hasn't posted on the forum at all since 20 Dec 2015
Pity after reading back on where he was going and what he was looking to achieve :(
-
If it's the early non-potted type there should be an ID label inside it.
Thanks, ihave the newer potted style. Man, we need a hero that can pull the id tag from the CAN bus. These things are cheap on ebay but none have the id tag. How about a kickstarter campaign to track down redrambler?!
-
Zarticus, where in FL are you? I'm looking for someone near/between Jax and Daytona with a KDS. Actually in the middle of those but also inland a bit: Welaka. I need to get a passive chip registered as a backup for the active transponder for my 2010 c14. Right now I have only the active transponder. Its passive chip was lost and I got one from another fob. Apparently, registering the passive chip doesn't require any original ID code or anything like the active transponder does.
Maybe the dealer will do this for a reasonable price. I'll check Monday. But it would be great if I could save miles and/or dollars and give the dollars to someone who got a KDS instead.
-
Steve Sefsick of Shoodaben Engineering has the KDS3 system. You can reach him on his website. https://sites.google.com/site/shoodabenengineering/concours-14-ecu-flash (https://sites.google.com/site/shoodabenengineering/concours-14-ecu-flash)