[BillV]

SDS has the ability to log the bike's data and graph and/or save it. In fact the service manual recommends getting a baseline and saving it for later comparison. There used to be several sellers of SDS on AliExpress. Prices were originally in the low $200's and trended down over time to around $150. Their pics were of the genuine SDS but it was never clear if they were actually selling that. I tried contacting some in an attempt to get a newer version of the software for my SDS and got no response or a runaround. The SDS graphing capability wasn't as good as it could be so I spent a bunch of time decoding the saved file and writing a program to convert it to a format that could be read by higher power graphing software like KST. I've shown some of the results elsewhere here. I also bought a cheap mini-laptop that would fit in a backpack to log data while riding. It's a bit awkward but better than nothing.

It's unfortunate that the ECU hacking forum has disappeared. It was the creation of RidgeRacer and I suspect was shut down due to lack of activity/interest. I haven't checked but some of it might be retrievable on the internet archive.

Shortwiring the diagnostic plug is a hack. A Suzuki or aftermarket dealer mode switch is cheap and makes it much easier to enter dealer mode, especially when you don't want to turn the ignition off, which will clear many codes. Shortwiring invites the possibility of shorting something else that shouldn't be.

P.S. I just checked the internet archive. The ECU hacking forum has been archived and here's an example. The Kawasaki link that you provided is interesting.

P.P.S About two years ago I got some information on how to hack the cluster from someone in Bad Munder. This isn't for illegal rollback of the odometer, rather to remove the tach and speedo error plus some other things.

 

[BillV]

Here's an example of my KST graphs:

I'd posted others here but they were hosted on Tinypic and they've since shut down with the images no longer available.
I was able to figure out the how the SDS save files were organized and determine the equations that convert the SDS values to physical data. But it was on another computer running W98 and it will take a while to access it. So I have SDS save files, a program to convert them to a spreadsheet type format, maybe csv, some associated spreadsheets, and the KST graphs. I'd added an extra line to the data with my chain/trans gearing and rear tire diameter. This allowed me to convert RPM to speed and include it in the graph. Interestingly, as I've mentioned elsewhere here, the SDS file had some extra information that was not listed in the SDS documentation or displayed/plotted by the SDS software. I suspect that it is the injector duration and ignition advance for each cylinder but can't do much with it without more info.

P.S. The graph is a large image (2045x768). It's best viewed by copying it to a hard drive and viewing it from there.

 

[BillV]

I don't know if you're still monitoring this thread but I've placed some SDS info here for download. This is nine years old and I've forgotten many of the details. So some of this may not be exactly correct.

"Baseline.pds" is a SDS save file. SDS also has the ability to read such files and plot the data in it.

"SDS data summary.txt" is a text file that explains the structure of a SDS save file (pds extension).
I think the Min, Max, and Engine Off columns are for a particular run that is different than the Baseline run. I don't say as much but I think the time data may be in milliseconds.

"Baseline interpretation simplified and cleansed.csv" is a csv file created from the pds file by the program described below. I think that "cleansed" means that I've removed data columns that are always 0 and not logged by the SDS. In this particular run, the bike sat for roughly 85 seconds before I started it, hence all the zero values in the beginning.

"Baseline interpretation simplified.xls" is a spreadsheet created from the csv file. It's easier to go through than the csv file.

What I did was first create a small file with the transmission ratios, sprocket sizes, and tire diameter for my K6 1000. I think it may also include preferences for °C/°F, etc. in the output file. Then I wrote a program that reads the small file and the SDS/pds file and outputs a csv file with the SDS data values converted to real values. The conversion algorithms are in the comments at the top of the xls spreadsheet columns. They were determined by a lot of comparing the data values in the SDS file and the real values displayed by the SDS program. The SDS file has no information on speed or distance. I calculate both from the RPM, gear position, and time data in the SDS file using the transmission ratios, sprocket sizes, and tire size. The KST plotting program reads the csv file.

The SDS will connect to other vehicles like scooters. Some of the unused values are associated with parameters unique to them. But there are also data values for my bike that are not displayed by the SDS program that I suspect are the fuel injector pulse width and spark timing for each cylinder.

 

[BillV]

I've forgotten the details but remember having big lists of the raw data and what was displayed by SDS, then trying various conversion algorithms until the converted data exactly matched the displayed. 255 surprised me too but that's what is was - and it kept coming up again and again. I've guessed that it has something to do with the SDS hardware. I also distantly recall that there was something unexpected about the acquisition time increments, i.e. that they aren't smoothly spaced. My conversion program is on a Windows 98 system that is partially broken right now. I routinely archived things but it was done using Ghost, which was discontinued in 2013 and never available for XP or 10. I'm currently looking into installing 98 in a virtual machine as I also have old versions of Autocad and Photoshop that I'd like to use again. Alternately I might be able to physically move the IDE hard drive to a marginally operational XP system and copy things from it there.

P.S. I've also uploaded Test-1.pds and Test-6.pds. Test-1 apparently corresponds to the Min, Max, and Engine Off values in SDS data summary.txt. But I don't know any more than that. Test-6 corresponds to the big KST plots that I've previously posted here.

 

[BillV]

It sounds like you may have figured it out but I've also come across "PDS data structure.xls" and uploaded it. It may have additional insight. But, as previously stated, these are old files and I've forgotten much. It looks like NDP is Number of Data Points and NC is Number of data Channels. I'm drawing a blank on PTP. The two columns between Address and Value, ex. C and D, are identical but are calculated in different ways. I don't remember what that's about but it probably has to do with some sort of check.

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.

 

[BillV]

SDS asks the user to enter the VIN at the beginning and uses that for year specific features, ex. the ISC in 2007. All your comments about encoding were something that I didn't remember. As stated, I can't access my source code right now. This was back in the W98 era, was in MS compiled Basic (I think), and I think I was just reading things a byte at a time.

 

[BillV]

The advantage of KST is that you can create multiple plots with a common horizontal axis, thereby avoiding much of the vertical scaling problems that you're encountering.

After thinking about it some more I now believe that my program was written in C.

 

[BillV]

SDS allows you to upload a saved pds file and inspect it via its graphical feature. It's been years but I remember doing that and then going through it to create a list of temperature/voltage/pressure values versus the hex values in the file. From that I determined the conversion formulas. Some of them took a while and were close but not exactly correct. It was only after noticing that 255 kept coming up again and again that I was able to reach the final formulas.