[TriB]

We all know about car diagnostics and learned that things were different on motorbikes.
The bike manufacturers were not forced to use OBD II until 2020. So everyone did something unique.

At least for Suzuki, there are several possibilities to find issues:

• Shortwire the diagnostic plug, to see the error code on the dashboard.
• Use the official SDS (when you are a dealer or were lucky to buy it second hand).
• Buy a multi-manufacturer workshop-tool for several thousand bucks.
• Use a 3rd party tool like Healtech.
• Trust a promising chinese tool, which pretends to support many manufacturers for small money.
• Create an own unique device and program it from scratch, to understand how all of this works, by trial & error (like me)

Shortwiring is the simplest one, but just works rudimentary.

SDS and Healtech only support a single manufacturer. Healtech has a single device per Honda, Kawasaki & Suzuki, which are working quite well! But every solution also requires a notebook.
To see which features healtech supports, I can recommend to download the application from their official website and open the included demo-files.

Skipping the very, very expensive tools for workshops, which often are combined with monthly fees to get recent updates to new manufacturers and models, for invaluable reasons...

After searching and comparing several cheap tools, offered by a well known chinese selling portal, I found the JDiag M100. It pretends to support 26 manufacturers, reading livedata, read/reset Diagnostic Trouble Codes, actuator tests and much more.

So I gave it a try for around 120$ without manufacturer dependend plugs (which would have come for additionally almost the same price). In the meantime they released a sucessor, which seems to be the same device with a different look and fancy icons.
It supports updates, which enhanced the manufacturer list to 29 and resolved some issues.
My tests on Kawasaki, Suzuki, KTM, Ducati and Honda....worked.
What does that mean in particular?
The JDiag connects (even if the modell selection might not be exact, "auto search" mostly works) and gives you some data.
Live Data: This shows manufacturer dependent RPM, temperature, speed, etc. There is often more data, which the device does not show. Some entries display wrong values, because "null" or "(currently) not available" is represented by hexadecimal 0xff or integer 255, but JDiag calculates with it. So speed greater then 500km/h is not unusal on idle.
Showing the DTC works okay. On some entires the description is too long and does not scroll, so you have to guess.
Deleting DTC mostly works, for me it failed on the Kawasaki ABS module.
Showing freezed frames (represents the live data from the exact point where a DTC occured) isn´t reliable at all. Sometimes is won´t show data because the DTC was deleted, but the FF data is still there and requestable, sometimes it shows data like "starter switch pressed" but nothing helpful from the remaining 52 values.
Actuator Test was updated a bit on the last release. You can drive the exhaust valve, power up the fuelpump or use a cylinder specific injector. But it does not show the current value, which just would be nice.

In short: It works okay, but not much more. Having several bikes and you´d like to see or delete a DTC, this might be a helpful companion in your garage. Going deep into finding issues with your bike, this won´t give you all the needed information. At least for the manufacturers I have tested.

In the past, there has been the ECU Hacking forum around. Some guys found out how the communication protocol worked for Honda, Kawasaki and Suzuki. So I created a device on my own and found out more and more, how all of this works. Since then I am submitting my ECU data onto my Garmin Virb camera via bluetooth:

This works quite well and I started to find out more and more about the possible functionalities and more manufacturers. For that reason I bought the Healtech and JDiag devices, to see how the communication protocols look like and what I can adapt.
My custom adapter(s):

A very old code can be found for Kawasaki here.

From ~2020 on, there will also be OBD II available on most bikes. Or even earlier, it the manufacturer already planned the bike to be future proof. The plug will look like that:

and you might buy an adapter to OBD2, where you can attach an ELM327 such as an OBDLink.

Can I just create an adapter myself for an older bike and attach a cheap chinese ELM327 clone to make it work? No!
The clones don´t support proper reprogramming! It might be possible to use an original OBDLink with a pre-OBD2 bike. But this will only enable the physical communication. So you still need to have a tool or app which changes header data, translates values and calculates independently from the OBD2 standard.

That´s it for now. If you were interested, I can go more into detail

 

[TriB]

Hi Bill,
you can show a graph on the JDiag as well. Even on true/false values
Saving data is not possible, although it has an internal SD card.
But during all my "hacking" attempts, I´ve created a device, which can be attached between the bike and any diagnostic device. It throws everything on the K-Line or CAN-Bus onto a SD card.
In earlier times I´ve sniffed the data transferred by the software over USB to the dongle.

Then I did the same thing like you and wrote a program to show (but not visualize) the logged data. With that, I was also able to convert the Healtech logs and some more. That approach helped a lot to find the right equation, I could not find out myself in the past.

If you´d like to, send me some SDS files and I´ll try to analyze them as well. This would be very helpful

What I read about the SDS and Healtech devices from Ali: They will be destroyed using the latest, original software. They can detect if its a clone and kill the USB chip. The same way as fake FTDI chips were destroyed, when the chinese just 1:1 copied them.

Sounds interesting how to get inbetween the cluster. AFAIK it´s also a K-Line communication.
For Kawasaki I got the dealer code activation, which can enable reading and reprogramming the ECU, I guess. But since I do not want to brick my ECU, I did no further research on that...

Many equations on the ECU Hacking forum were wrong, but to get into the topic for Suzuki and Kawasaki, this is a great starting point. And good to know about the Web-Archive!

 

[TriB]

That looks great!
I think I should also add some graphes and gauges
For a very long time, I´m considering to rewrite the whole application, make it available for other operating systems, add some features, etc. But got spare time for that...
Started with a little ECU emulator for Kawasaki, so I must not go into the cold garage to test my adapter. Then, when I bought the Suzuki, which send all the data in one response, rather then each per request, I extended the application.
Then I found out about the message structure from Honda (a different format) and found my self in a dead end 🙈

Winter is coming, I´ll try to make it to my next project.

It would be amazing to get some SDS files!
For request SID 0x08 there are about 8 missing values, because they are allways 0xFF in my bike. And then some bits, which are "hidden" somewhere together with driving mode, clutch, starter switch, etc.
Then there were SID 0x80, 0x90 and 0xC0, which seems to be some static values (00, 40, 80, C0), some are similar to TPS, Speed, STPS and others were not related to anything. Maybe a testing feature.

 

[TriB]

Happy new year!
I´ve just released my current Arduino code:
gitHub/KDS2Bluetooth
The repository is still called "KDS", but this version supports Suzuki SDS and Kawasaki KDS.
A little explaination video is made right now and will be released within the next days.

New version of my ECU Emulator and the HEX-Viewer will also be released. But I don´t have a roadmap for that right now.

 

[TriB]

Hi Bill,
thanks a lot for sharing this with me!
I can understand the most of your files Only having a single difference in the bit-position of the neutral switch. You got 4, I have 7. All other positions and equations seem to be the same.

The Baseline-File is really interesting! This will take me a while to enhance my interpreter software. But that´s what I want to archive And your Excel-sheet helps a lot!

I´ll further dig into that during the next days. Feels like I mostly have everything together for SDS.
There were only other messages, I don´t understand. Like PID 0x80, 0x90 and 0xC0. This seem to be a specific channel for testing and/or min-max values.

EDIT:
How sure are you about the equations with 255?
For Kawasaki I got the resolution from the official KDS software.
RPM for example has a resolution of 0.390625
This is exactly 100 / 256.
Your´s would be 100 / 255 = 0.392156862745098. Which seems quite hard to calculate on 8 bit sytems. Healtech was using strange calculations as well: A * 256 + B, combining two digits, but then also going on with 255: ( A * 256 + B) * 100 / 255.
This bothers me for a long time! It seems every system does it differnently

 

[TriB]

Don´t make yourself too much work with that!

I just need a hint how the combine the Baseline-File to the Excelsheet/csv. It seems that there is some kind of header within the SDS file. And afterwards the data is arranged vertically? I can see blocks of values 🤔 But the number of values does not exactly match to the Excel.
At least I could find some of the values, translating the Basline.pds into ANSI and then into Hex.

Strange way of designing a binary file like that! But I´ll figure it out

EDIT:
Okay, got it!
There is some kind of header between the data:
00 0b 00 10 00 02 00 00
0x0B RPM - 0x02 no of bytes.

00 0d 00 10 00 01 00 00
0x0D TPS - 0x01 no of bytes.

 

[TriB]

Thanks a lot!
The first challange was to determine the correct file encoding. After converting to UTF-16 BE BOM, the values seem to fit to your findings. But the position is shifted by two places.
Reading the time works for about 290 of 521 datasets. Then the index disappears 🤷‍♂️
So going on with the search for a better encoding, ISO-2022-JP seems good! Now the comment makes sense, but the timing drifts away one place forth, and back after a while.
And the number of data points stopped working...

Now I´ve ended up with reading Unicode Little Big Endian and convert it to UTF-16. And it finally seems to be what I´m looking for. What a travel 🤦‍♂️ You don´t want to see my code testing all the possible combinations...

Reading the times went well, but the data freaks me out again. It seems that the header changes it´s size due to the byte-length of the data. This will still take me a while to make it work and a bit more robust.

 

[TriB]

What a "birth"
I was on the wrong track with the encoding. The files needed to be read as raw binary!
But everything is in LittleEndian, which means you have to add those numbers from right to left.
Except the data itself! It´s in BigEndian.
All the data? No! The timestamp is also in LE

The format is really dumb! The Suzukis have 52 bytes of data. But you cannot just fit it back into an original message.
Need to skip some redundant values and fill others with blank values, now I can use my Hex Viewer to interpret and show pds-files!
Thanks a lot Bill!!!

Now, I´ll investigate the 255-256 thing a bit 💪

Ahh, and does anyone knows where the VIN comes from? All requests by SDS I know, does not contain such a response.

 

[TriB]

Good to know with the VIN. Thanks!
After sucessfully playing around with your files, I´ve added a little graph functionality:

This was an hour ride with my Kawasaki, having only the values which fit to OBD2 (and my Virb camera).
Every recorded data can be displayed, even from different control units, like ABS:

Using RPM kills the scale quite a lot and TPS is more or less useless then. You can scroll or zoom in a bit, but only rudimental:

Maybe I´ll put some more afford into it at the weekend.
Colors are random and change on every view. That´s far from ideal!
There is no tooltip with the exact data and/or timestamp.
It also would be nice to reduce the data by selecting start- and end time.
Having more then one diagram to seperate the scales would be amazing. Or just open the graph-window more then once

I´ll push this into my repository within the next days. No promise about the whishlist

 

[TriB]

Also, with regard to 255, note that battery voltage and throttle position are simple multipliers. I think it was them where I first determined the 2.04 and 12.75 factors, later realized that they contained 255, and found 255 in the other algorithms.

Finally had some time to investigate the multiplier/base. Or in other words: Start my therapy session 🤣

We have values from 0 to 255 or 0x00 to 0xFF in hex. Values greater then that, will combine two (or more) bytes with the easy formula:
A * 256 + B
Beside the pure logic and that this approach is well documented for KWP2000 & OBD2 protocol,
it´s optimal to solve equations by bitshifting on 8-bit processors.

As I already mentioned, Kawasaki does any further equation on the base of 256, which makes quite manageble decimal places to calculate with. Or just bit-shift on the ECU. Like: (A * 256 + B) * 100 / 256
100 / 256 -> 0.390625
100 / 255 -> 0.392156862745098

However, Suzuki has 0xFF or 255 as some kind of placeholder for values which are not available.
So I thought SDS might "skip" 255 like like that:
(A * 255 + B) * 100 / 256
And the results mostly fit quite well! On higher values, it does not seem to make any difference if you multiply by 255 and divide later on by 256, or the other way around.

But my curiosity was awaken (again) and I opened the Healtech SDS application.
The graph told me, that the highes RPM on that record, was 1711.666 RPM.
My application shows 1712 RPM. The Hex is 11 0E.
I did the math with all (A * X) * 100 / Y combinations:

	255	256
255	1705.490196	1712.15686
256	1698.828125	17054.6875

I don´t know what Heltech is doing there, but I guess I´ll go on using my equation. Even if they are only close 🤷‍♂️

SDS on the other hand really works mixed and confirms your findings: (A * 256 + B) * 100 / 255.
Or for TPS 125 / 255, which requires multiplying by 0.49 or dividing by 2.04. Both does not make any sense to me.


Then I tried to make the SDS application run with my very own adapter, attached to my (software) ECU emulator.
But SDS sends out a high bit on the Tx channel and awaits some specific response.I responded with several messages, but wasn´t lucky enough.
Took a look into the SDS binaries, but didn´t found anything meaningful, at least for me. Except the *.dll´s in the database folder. They seem to be the DTC´s and ECU ID´s for newer models with some additional information. Maybe I can get them into something readable 💪

 

[TriB]

Even if this is a GixxeR Forum:
I´ve just added KTM to my tool.

Found a file on my PC, where I sniffed some data from the JDiag device and a 990 Supermoto.
Some work to do, but only a diligent but routine piece of work.