So long story short, I replaced my old GPX Pro with an AiM MXL2 dash. One of the nice things is that the dash supports the Suzuki SDS protocol for the GSXR. SDS is sorta like ODBII for cars- if you’ve ever heard of a “K-Line”, well that is pretty much SDS. Long story short, the MXL2 dash can decode some of the sensors (TPS for example) but others are pretty far off (water temp).
I reached out to AiM to see if they could fix it, but they didn’t have the information necessary to fix their decoding of the messages. They suggested reaching out to Suzuki to get the specs, but I don’t know anyone there and nobody I know seems to know anyone there…
Long story short, I’m going to reverse engineer it myself.
I’ve started another little project up on GitHub. Right now it includes some python scripts I’ve written to parse the bytes on the wire and find the individual messages between the ECU and diagnostic tool. Here’s some sample messages:
OK [0.033ms] ToECU: 0x81,0x12,0xf1,0x81 csum:0x05 [5]
OK [0.107ms] FromECU: 0x80,0xf1,0x12,0x03,0xc1,0xea,0x8f csum:0xc0 [8]
OK [0.034ms] ToECU: 0x80,0x12,0xf1,0x02,0x1a,0x91 csum:0x30 [7]
OK [0.092ms] FromECU: 0x80,0xf1,0x12,0x12,0x5a,0x91,0x33,0x32,0x39,0x32,0x30,0x2d,0x31,0x37,0x47,0x32,0x2a,0x00,0x00,0x00,0x00,0x00 csum:0xb8 [23]
OK [0.035ms] ToECU: 0x80,0x12,0xf1,0x02,0x1a,0x91 csum:0x30 [7]
OK [0.091ms] FromECU: 0x80,0xf1,0x12,0x12,0x5a,0x91,0x33,0x32,0x39,0x32,0x30,0x2d,0x31,0x37,0x47,0x32,0x2a,0x00,0x00,0x00,0x00,0x00 csum:0xb8 [23]
OK [0.035ms] ToECU: 0x80,0x12,0xf1,0x02,0x1a,0x91 csum:0x30 [7]
OK [0.093ms] FromECU: 0x80,0xf1,0x12,0x12,0x5a,0x91,0x33,0x32,0x39,0x32,0x30,0x2d,0x31,0x37,0x47,0x32,0x2a,0x00,0x00,0x00,0x00,0x00 csum:0xb8 [23]
OK [0.034ms] ToECU: 0x80,0x12,0xf1,0x02,0x1a,0x9a csum:0x39 [7]
OK [0.092ms] FromECU: 0x80,0xf1,0x12,0x12,0x5a,0x9a,0x33,0x32,0x39,0x32,0x30,0x2d,0x31,0x37,0x47,0x30,0x00,0x00,0x00,0x00,0x00,0x00 csum:0x95 [23]
OK [0.034ms] ToECU: 0x80,0x12,0xf1,0x02,0x1a,0x9a csum:0x39 [7]
OK [0.094ms] FromECU: 0x80,0xf1,0x12,0x12,0x5a,0x9a,0x33,0x32,0x39,0x32,0x30,0x2d,0x31,0x37,0x47,0x30,0x00,0x00,0x00,0x00,0x00,0x00 csum:0x95 [23]
OK [0.030ms] ToECU: 0x80,0x12,0xf1,0x02,0x21,0x08 csum:0xae [7]
OK [0.060ms] FromECU: 0x80,0xf1,0x12,0x34,0x61,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0xff,0xff,0x00,0xff,0x43,0xca,0x3f,0x40,0xff,0xa7,0xff,0x00,0xff,0xff,0xff,0xff,0x00,0x00,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x47,0x47,0xff,0xff,0xff,0x80,0xff,0xff,0xff,0xff,0x00,0x04,0xff,0xff,0xff csum:0x4a [57]My next plan is to see if I can hook up both the diagnostic tool and a Teensy + STL9637D chip which in an interface to the “K-Line” signaling used for the SDS protocol. If I can properly decode the messages to/from the ECU using the Teensy I should be able to capture more then ~12 sec of data (one of the limits of my cheap $50 logic analyzer is that it doesn’t have much memory for longer captures).
Once I have that then I can map each byte to a sensor and then start comparing the values on the wire to what is actually being displayed by the cheap-o diagnostic tool and figure out the formula for converting between the two values.
For those curious, here’s the project on GitHub.
Hi, I’m currently working on a simlar project, except my bike is a ’04 Kawasaki Z750 which communicates via the KDS protocol.
The KDS and SDS protocol are nearly identical, so that makes it a lot easier to find info online. One of the differences though is the fact that the KDS does not have a pre-programmed ServiceID which sends all sensor data in one packet. So I have to request one packet at the time. This makes it slightly more difficult to locate all the sensor ServiceIDs.
I have found some ServiceIDs for several sensors (RPM, speed, engine coolant temp, etc.) However the trickiest part is to get the conversion formula (called Data Scaling in the ISO 14230 files) to get actual engineering units from the 1 or 2 bytes from the data packet. This appears to be more or less identical for Suzuki and Kawasaki machines. So I was wondering if you could use the software to reverse engineer those conversion formulas. The formulas I found so far are mentioned on the ECUhacking forum which you probably already found. The remaining formulas are still to be discovered. I was hoping there is some kind of configuration file that comes with the software, which contains all these conversion formulas. Would it be possible for you to take a look at that?
Thanks in advance!
Hi Eztys,
So I’ve looked around the software and without using something like IDA to reverse engineer the code (beyond my abilities) that’s kinda a dead end. Right now my best idea is to be able to passively listen on the K-Line while the SDS software is decoding the values, build a table and then find a formula which fits the data.
If you haven’t yet, checkout the links listed on External References here: https://github.com/synfinatic/sv650sds
A few of them are for KDS and one of them (I think the bluetooth project) has a lot of information and lists many of the formulas.
Hi Aaron,
Thank you for your quick reply. Ok, that makes sense. I’ve already used all my googling capabilities to find all information about KWP2000. Unfortunately, besides the ECUhacking forum, there is very little practical information.
I bet you already found the ISO-14230 documents, which contain most of the data you need to know. If you did not, I strongly suggest you take a look at those. It basically is a comprehensive guide to the basics of the KWP2000 protocol.
While I was reading the documents, I fortunately found a section called ‘Data Scaling’. Which pretty much means all ECUs contain a table where the scaling or conversion formulas are located. From the ISO-14230-3 document I cannot completely understand how these conversion formulas can be requested. I did try to send [0x80 0x11 0xF1 0x02 0x21 0x01 0xA6], and got a positive response, however did not receive the scaling table. It’s definitely something you should look into, because you could be able to obtain the exact conversion formulas. Additionally, I’m very curious if it works for your machine.
Furthermore you should also be possible to request Diagnostic Fault Codes (DTSs), which is more clearly documented in the ISO documents.
Oh, I wasn’t aware of the data scaling table in the spec. I’ll have to give it a try. FWIW, I know that the SV650’s implementation of the protocol is sufficiently un-standard and that generic KWP2000/K-Line tools won’t work with it so honestly I’m not expecting much.
As for the ECUHacking forum, I can’t even login. :( I’ve tried registering an account multiple times (with different email addresses) and apparently the moderator won’t approve my account so I can login.
Unfortunately, my development of this has temporarily halted- I recently crashed in a race and both I and the bike are damaged. So gotta focus on that for now.
I guess the same holds for the KDS protocol. I also tried to register at that forum, and also did not got accepted. Judging from the activity on the forum I doubt if that ever will happen. Sorry to hear you crashed, hope you get up and running soon!
Maybe I can keep you up to date of my activities so you might be able to implement some of the results.
Cheers
I’m trying to build a custom dash for a kawasaki Versys. I don’t have the knowledge, but would like to engage someone to assist with the design and code.
If anyone would be interested in a paid project, perhaps we can make contact?
I’ve been working alot on the arduino based datalogger for my Kawasaki lately. I’ve also made some pretty good progress, at this point I’m able to log pretty much all interesting sensor data e.g. intake air temperature, engine coolant temperature, throttle position, sub throttle valve angle, RPM, speed, gear, intake air pressure, manifold air pressure, total operating time, battery voltage, vehicle down sensor.
The downside is that the highest possible datarate is approximatelly 8-10 response messages per second, due to the delays that are required to sustain communication. The standard KWP2000 protocol has a function to adjust these values, such that a higher data rate of ~20Hz is possible. Unfortunately this is not supported for my bike. Therefore using the KDS or SDS protocol very high datalogging rate is not feasible, such that a custom dash is not very responsive unless you only log RPM and speed for instance (4 Hz refresh rate in that case).
At this moment I’m mostly working on optimizing the hardware and software, as the Arduino seems to reset itself every now and then. Furthermore, I bought a KDS OBD tool from ebay, which I can sniff to figure out more possible requests.
I tried the ECU forum as well, but no success…
“Therefore using the KDS or SDS protocol very high datalogging rate is not feasible, such that a custom dash is not very responsive unless you only log RPM and speed for instance (4 Hz refresh rate in that case).”
Thanks for the info. I would still like to try and see what it looked like. It is a shame though.