Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: SDS protocol


Senior Member

Status: Offline
Posts: 123
Date:
SDS protocol


I was going to add this circuit to my propeller output for connecting to the SDS serial link on the ECU. It uses 2N3904 transistors but is designed for 12 volts. Don't the resistor values need to be cut down for 3.3/5v? I'm not sure of the values. I was guessing about 1.8k for R1 and R2 since they see 5v, and 820R for R3 since it's 3.3v. Any thoughts?

cablewires.gif

__________________


Guru

Status: Offline
Posts: 963
Date:

What makes you think this circuit will work with the SDS?

This is a half duplex setup that echoes any data on TxD back down RxD. This is the kind of setup the Dash TECH line uses on the Busa. But the SDS plug has separate send and receive lines.

I guess I'm confused about what you are trying to accomplish. This circuit, with modification for 5V, would work if your connecting a PC COM port or propeller serial port on RxD and TxD and ALDL M to a Busa Dash Data wire. Is that what your trying to do?



__________________


Senior Member

Status: Offline
Posts: 123
Date:

The SDS uses only one wire to my knowledge. There is no Rx or Tx on the Bandit dealer port. Although bikes such as the Gsxr (and busa I assume) have Rx and Tx wires at the dealer port, they apparently are not used. I checked with a member who has the suzuki SDS box and only three wires are connected through the cable from the dealer port - power, ground, and serial data.

When I tried coupling the Rx and Tx lines together on the propeller I could not pull one line high without messing up the other and I was lead to believe this circuit would help me get a single line communication from the Rx/Tx output of the propeller. The echo is not a problem as I can ignore it using a setting in the software.

So, what I am trying to accomplish in physical connectivity for the SDS is basically the same as RS232 to the busa dash serial data line.



__________________


Guru

Status: Offline
Posts: 963
Date:

Ok, that explains my confusion.


So another question is your propeller Rx/Tx actually rs232 or is it Serial TTL?

True rs232 use +/- voltage a logic 1 is between -3 and -15V while a logic 0 is between +3 and +15V. The lowest circuit shown above can sink Rx is 0v or gnd so it may not work on a true 232 port

Now TTL serial uses the same bit patterns as 232 but a logic 1 = 5V and logic 0 = 0V. Now electrically this circuit would work with serial TTL if you changed the the 12V power to 5V power however logically it is going to invert your data so it wouldn't work.

Do you have a link to a spec sheet for your propeller?

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The propeller is going to be 0-3.3v TTL with it's own logic threshold at 1.65v. The logic inversion can be addressed in the software by sending inverted signals and inverting the recieved signals.

But, hold the presses...

I just put a voltmeter on the SDS pin of the ECU and was surprised to see it at 12 volts (12.54). All this time I assumed it would be 5 volts. The speedometer serial pin shows 5 volts (4.63v).

There's a guy who has been insisting that his dealer does not use the SDS box with the SDS software, and instead connects the SDS cable (which conveniently has a 9-pin female) directly to their laptop. I found this hard to believe, but now can see some merit to it.

The pins from the dealer port to the 9pin serial would connect as follows:

12v - Pin 1 (Carrier Detect)
Ground - Pin 3 (Tx)
Serial - Pin 4  DTR

Obviously this would not work. But, what if the guy who gave me the cable specs inverted pins 3 and 4? Serial works, one way anyhow. What happens if the DTR is held low?
If 12v was asserted on the DCD line it would tell the computer the other end was ready, so that's good. But there's no common grounding which isn't too good...

Is it possible for a windows app to cause both Rx and Tx to be handled through a single pin on the 9pin serial port of a PC? It wouldn't follow true 232 specs, but could it be done?

I don't know about the SDS cable-only concept, but I think I'm going to hook up a partial 232 interface direct from my PC to see if I can receive anything from the ECU.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Well, I had no luck with combinations of Rx and Tx plus ground either with the SDS software or hyperterminal. I got no characters back from the ECU under any conditions. But I did take notice of something with the SDS software. The initial connection string at 9600 baud is:
01 20 0C 00 00 00 04 00 00 00 00 00 00 25 80 D6

But at 19,200 the same string ends with 4B 00 7C. At 38,400 it's 96 00 C7, and at 57,600 it's E1 00 12

Clearly, it's telling the other end what baud rate to use. But an ECU would likely use a single rate like 7812 or 15,625 right? Also, the non-connect timeout error says "interface box not connected" rather than "no motorcycle connected", or "could not connect". I would guess there's another message if the interface box is connected but no motorcycle is.

I'm drawing the conclusion that there is no way to use the Suzuki SDS software without their SDS box, since the box not only does the translation to and from the ECU but the software expects certain programmed responses from it.

This does not mean we can't bypass the entire thing and speak directly to the ECU, but it does mean my hope of using the SDS software and the captured transmissions as a guide is not going to happen. It would seem the software is completely useless as it's dependant on the "box".

That means we either need to reverse engineer the protocol from the ECU, or track down a box so we can observe and mimic it's behavior.





__________________


Veteran Member

Status: Offline
Posts: 37
Date:

Gadget,
I know on either Max-Suzuki or TWT, a poster bought both the box and the software. He was going to have a peek inside once he had used it a few times.
He may just be able to monitor the output and give us a clue as to what is going on. I am curious as to how a dealer can be bypassing the SDS box completely......?
If we could ask the other poster what messages he see's when the software is running with and without the box connected and then with and without the bike connected it would give us an idea what handshaking/checking is going on.
Of course you could have the settings changed by an SDS box and get the maps out again and see what area the SDS box is playing with......
I haven't read much about the SDS and its uses, just that you need it to set the idle speed valve and maybe the TPS value. It does have a bunch of useful diagnostics tools though.

Geoff

__________________

'Started out with nuthin' and I still got most of it left"



Guru

Status: Offline
Posts: 963
Date:

It may end up easier to do it from the inside out, to trace the code for the serial channels. In addition to the SDS I assume the Bandit also has a Dash data wire.

If I come up with a little test can you query the aud port while sending data to the SDS to isolate which serial port is which? You will have to write a modified version of your propeller software that instead of running thru the addresses sequentially allows you to enter an address from the terminal that the propeller then asks the ecu for and returns the value to the terminal.

Do you guys know of anywhere online where the shop manual for this bike is posted?

__________________


Veteran Member

Status: Offline
Posts: 72
Date:

If anyone is interested:
Attached you will find pics of the SDS-Box inside.
Not a simple thing.....weirdface

Attachments
__________________


Guru

Status: Offline
Posts: 963
Date:

Definitely more going on then simple serial voltage level conversion.

The chip between the heatsink and the USB port and the OKI square chip above the heat sink are the USB physical interface chip and USB controller chip. The big rectangle is obviously the CPU. The skinny rectangle is a memory chip. That is a lot of memory for a converter box.

Does this box have logging capability? Could you attach it to the bike and then take it for a spin around the block and bring it back to the shop and then download the log to the PC. It would be a much more valuable diagnostic tool if you could.

And then of course the white plug in the upper left. Lets hack the SDS box!

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Wow, that box is much more involved that I thought it was. I like the idea of hacking it!

Blackgixxer, is that something you have access to or did you have it just for the pictures?

RR, I can setup the propeller to test the ECU for the serial input. Let me know what you think I should be looking for.

Geoff, that user was on TWT and seemed reluctant to do anything with the box other than use it as Suzuki intended. If Blackgixxer doesn't have the box, I'll ask the TWT user again.

__________________


Guru

Status: Offline
Posts: 963
Date:

At a minimum see if you can get a readable pic of the numbers on the cpu chip. That would at least tell us if it could be downloaded.

I'll get back to you gadget on the serial test...

__________________


Veteran Member

Status: Offline
Posts: 72
Date:

Unfortunately I had the box just for the pictures.
I sent the pics in original resolution to RR.

On the CPU is written 64F2636F20 H8S/2636.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Timsyrop on TWT agreed to run a port capture program for us when he runs the SDS setup on his bike. I figure with that we can find out what the box sends back to the software which causes the software to "open" and make available the menus. Once I'm able to click on those options I can hopefully find out what memory areas are being probed, etc. I'm not sure how much the box is doing in that department though, and what comes from the software may not be very helpful.

On another note, Dale Walker is organizing a donation based purchase of an SDS box at his dealer cost so we can experiment with it. I would think that if the money is going to come through for it, it would happen in about 2 weeks.

__________________


Guru

Status: Offline
Posts: 963
Date:

I found this interesting statement in the SDS users manual


For communication protocol between the computer and adapter, the international standard ISO14230 is used.
I assume they are talking about between Windows and the box over the serial / usb.


__________________


Senior Member

Status: Offline
Posts: 123
Date:

That is interesting.

They also refer to the cable that plugs into the bike as a "K line", which is the same terminology used for that line in an OBD connection.


__________________


Guru

Status: Offline
Posts: 963
Date:

Makes you wonder if in fact what the more modern bikes have is actually just some form of OBD interface.

__________________


Guru

Status: Offline
Posts: 963
Date:

There is all kinds of freeware OBD software out there. Maybe someone should give it a try before we go and try to reinvent the wheel here.

There as to be a few people fluent in OBD hanging around here.

__________________


Veteran Member

Status: Offline
Posts: 74
Date:



-- Edited by ffaspector on Saturday 17th of October 2009 10:11:37 PM

__________________


Veteran Member

Status: Offline
Posts: 74
Date:



-- Edited by ffaspector on Saturday 17th of October 2009 10:19:01 PM

__________________


Senior Member

Status: Offline
Posts: 123
Date:

This is all very good news. I just read on the swiftcom site about the data rate for ISO-14230 being 10,400 and that a microprocessor is commonly used for the conversion to PC speeds. That might partially explain the one in our SDS box.

I found this circuit which shows how a max232 could be used with a bus transciever. The si9243 is discontinued but the L9637 is available and might work the same. I'm going to add this to the propeller where I can set the baud, and see if we have communication. Why do I always find the need for parts at the end of the week? Grrrr.....

Something like this should work too, and without the propeller. I assume the ELM chip does the baud conversion.


-- Edited by Gadget at 05:24, 2008-11-28

__________________


Veteran Member

Status: Offline
Posts: 74
Date:



-- Edited by ffaspector on Saturday 17th of October 2009 10:27:29 PM

__________________


Senior Member

Status: Offline
Posts: 123
Date:

I ordered the 232 parts, should be here mid-next week. I have a good feeling about this...

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Timsyrop did a data capture for us of the communication between the SDS software and the interface. You can see it Here.

I think this confirms at least that the communication between the software and the interface is OBD. I don't know the OBD language enough to make sense of it. I see capabilities requests and reserved responses that look like this:
01 20 0C 00 00 00 04 00 00 00 00 00 00 E1 00 12
  81 00 00 81
02 40 02 55 AA 43
  82 00 02 55 AA 83
06 20 08 00 00 00 0A 00 00 00 3C 74
  86 00 00 86
06 40 08 00 00 00 0C 00 00 00 06 60
  86 00 00 86
09 60 1D 00 00 00 00 00 00 00 04 00 00 00 00 00
01 00 00 00 00 00 05 00 00 00 04 81 12 F1 81 05
9E
  FF 00 05 09 00 00 00 00 0D

Later, when more data is being sent to the software the lines start with 40 which should mean "download not accepted"... but I'm confused why that would be used so often. IE:
40 40 2F 00 00 00 00 00 00 00 03 00 00 00 00 00
00 00 00 00 00 00 17 00 00 00 16 80 F1 12 12 5A
9A 33 32 39 32 30 2D 31 38 48 30 00 00 00 00 00 (ECU identified here)
00 97 0D

If it is OBD, we only know what Suzuki has already told us. The question of the ECU's serial line being OBD is still in question. I don't have the max232/L9637 working yet with the ECU, but I still have a lot of other things to check including plugging it into my car to make sure it works.

What's interesting with the captured communication is that it doesn't show a 5 baud 0x33 wake-up and 0x55 response as the swiftcomm site indicated was normal initiation.

__________________


Guru

Status: Offline
Posts: 963
Date:

Based off that I found the SDS code in the software, at least the rcv side anyway. It is the Interrupt Service routine for SCI4 RXI.

I'll look at it and see what I can find...so far all I've found is the max msg len is 260 chars.

__________________


Veteran Member

Status: Offline
Posts: 74
Date:

This is why I doubted the ELM chips. It would seem that suzuki is using the K-Line protocol, but not the standard OBD commands, which would have confused the ELM chip. Now that RR found the code location, I'm sure he'll have some more info shortly....

__________________


Guru

Status: Offline
Posts: 963
Date:

Instead of a whole bunch of posts I'm going to come back and edit this one as a running commentary

SDS Rcv Protocol

After 4th byte buffered, rcvr and rcvr interrupt disabled.
81 00 00 81 looks like the initialization or wake up packet. It is a 3 byte packet with a checksum (checksum is the simple sum of all the bytes )






This is very interesting found the following string

S9030000FC

This is an Motorola S Record (s19) File end of block. Does this mean the ECU sends and / or receives large blocks of data in s19 format?





-- Edited by RidgeRacer at 01:25, 2008-12-08

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Isn't the 81 00 00 81 a response from the ECU headed towards the software? I guess I'm not reading this right...which doesn't surprise me because so far I can't find any of the things you have RR.

Is it safe to conclude with your discovery of the SCI4 connection that the data is likely exchanged directly with the ECU with little or no translation/conversion by the interface?






-- Edited by Gadget at 23:24, 2008-12-08

__________________


Guru

Status: Offline
Posts: 963
Date:

Ah, I thought this WAS the ECU data.

That box is kind of complex for just a level converter. It could be that it is a baud rate translator and logger.

Software design wise it is always easier to let the Windows software do the heavy lifting as it has all the power.

When you say you can't find "any of the things" are you talking about the software or the captured data?

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The data above was captured on a PC by monitoring the USB port. It shows the traffic between the Suzuki software and the Interface box. How much of that data continues strait through the interface to the ECU is unknown. An ECU was connected during the capture so the data includes responses from it, but they may have been modified by the interface.

As you said, the interface is too complicated to be just a level converter but I wonder why they would set it up to log data when the PC is better off doing that. I don't think the interface works without the software telling it what to do, although I guess it's possible you could turn on the logging/disconnect the PC/go for a ride/plug the PC back in. I saw nothing in the SDS instructions about that.

As far as not finding anything, I was talking about the things you had located like the motorola string, the SCI4 reference, etc. My lack of knowledge and experience is impeding me greatly.

What I was hoping the data would show is if the OBD protocol (even with custom suzi commands) was being used by the ECU. At a minimum I'd like to know of a string I can send the ECU and be sure of getting a response. I thought of duplicating what the software initially sends, but I'm assuming the baud rate would not be passed to the ECU. That means the first string we see in the capture is intended for the interface. For all I know the response we see is generated by the interface as well.

 

__________________


Guru

Status: Offline
Posts: 963
Date:

Do you have Ida pro? If so what version? I could send you what I have so far.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

I've got version 5.2



__________________


Guru

Status: Offline
Posts: 963
Date:

I have the older 4.8 version. I know in the past others with the newer versions have had problems importing IDC files generated from my older version but if you want to give it a try I'll send it to you.

I spent a couple hours on it this weekend. The ECU appears to look for an 81 00 00 81 to set a flag that then allows other non 81 packets to be processed. After that the code gets kind of crazy.

it ends of at a routine the tests one of the received bytes asking...

is it 20
is it 21
is it 22...

A yes answer to any value jumps to the same place where it once again asks

is it 20
is it 21
is it 22...

Again, the yes answer to any value jumps to the same addr, a third routine that asks

is it 20
is it 21
is it 22

Finally it jumps to a unique location for each test value.

I ran out of time to work on it at that point but it looks like all the commands are there. Someone just has to do the grunt work of tracing the function of each one. Many of these appear to be a simple query of a particular address much like the Dash Data serial line.

I didn't get around to looking at the transmit reply portion. But I don't see any reason why you shouldn't be able to have a direct conversation with the ECU without the interface box.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

If you could email it to me, I'd try and see if I can get it loaded.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

A member of the Max-Zuk board is going to loan me his SDS box so we can hack it. Probably going to have it in about a week.

I'm thinking the first thing to do is figure out what protocol it's using to communicate with the ECU. I could use a scope to capture the communication between the two and then translate that to binary/decimal afterwards. Any other ideas on how to go about it?

__________________


Senior Member

Status: Offline
Posts: 123
Date:

I got the SDS box a few days ago. I was happy to see it communicates just fine with an ECU on the bench, but so far have had no luck at all isolating the TTL data I thought I should be seeing on the SDS line to the ECU with a scope.

I have no previous experience with a scope, but I've tried every combination of speed, trigger, and coupling. The best image I get out of it is around 15ms where a saw wave shows a series of verticle lines dropped below it. Almost looks like a bar code. If I go any faster with the speed I lose all semblance of verticle trace. The scope has a calibration point (1khz square) and it makes a nice crisp display of that wave so I think the scope is okay. Is it not possible to view TTL data on an analog scope like a Tek 2465B? Or am I doing something wrong?

trace18.jpg
 
See how the data burst on the right has different vertical lengths and floor? Even if it has to be viewed this "congested" I would have at least thought the lines would be the same length, even if they were at different heights (0 or 1).

I can post pictures of faster captures if that helps, but IMHO they only get uglier from here.

-- Edited by Gadget at 04:49, 2009-02-14

__________________


Guru

Status: Offline
Posts: 963
Date:

You need to use the trigger delay feature.

In order to read the individual bits of the data you posted you need to 'zoom' in. (decrease the time base). Problem is when you do that it zooms in on the far left side or what happens immediately after the trigger event.

It is like your trying to read a long sentence but your only allowed to zoom in on the first word of the sentence. zoom in farther and all you get to see is the first letter of the first word. But what if you want to zoom in enough to read letters but want to read the letters of a word in the middle of the sentence?

This is where the Run After Delay comes in. You set it up so that after the trigger it waits before is starts to trace a display. In other words you tell it to read farther down the sentence before it starts displaying the letters. Set up correctly you can use the delay knob to 'walk' the display down the waveform like pulling a magnifying glass across the page.

Few other things. Set you voltage for DC. It looks like you have it set for 10V AC per division. Also if I remember correctly the SDS is a single bidirectional data line. If so then the varying vertical size (voltage) of the signal is caused by two different devices talking on the same wire. Actually you will be able to use this to help tell you when the sds box is speaking and when the ecu is replying.

Also your power supply has a lot of 60Hz hum (saw tooth wave at the top) which is making the signal harder to read. Your display is set to 15ms per division and two of those waves is just over a division. The period of a 60hz wave is 1/60 or 16.6mS. That means your power supply is a linear (has a big transformer) with a full wave bridge rectifier. It needs a bigger filter capacitor and/or a regulator.




-- Edited by RidgeRacer at 15:05, 2009-02-14

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Thanks RR, the run after delay works great. The only problem now is that the data changes too fast to keep up with. While I'm examining the selected delayed area (no more than half the screen) there is data outside the selected area I'm missing. Plus there's no time to scroll across the delayed data as it changes too often. Even looking at it frame-by-frame on 30 fps video so far has been a very uphill battle for me. I'm sure I'm not doing it right, but counting 1 bits seems harder than need be anyway.

I'm trying another approach. I've tapped an RX connection onto the SDS line and run it to another computer. Now I'm trying to figure out the baud rate. 9600 looks the best so far out of standard rates but has sporadic data loss. I traced the SDS pin to TxD4 which is what you told us back in December RR, it's using SCI4. Would the ECU code be able to tell us what baud rate it's using? I wonder if it's the same 7812 PetriK found for the gauge serial. With that info, I think monitoring the SDS comms and figuring out the protocol should be fairly straitforward (famous last words? confuse).


-- Edited by Gadget at 06:04, 2009-02-16

__________________


Guru

Status: Offline
Posts: 963
Date:

To figure out the baud rate you need only measure the width of the smallest pulse which would be one bit. If the period of the bit for instance is 104.2uS the baud rate = 1 / 0.0001042 = 9596 (9600)

Your going to be hard pressed to make any progress with out a storage scope, one that can memorize a waveform and let you examine it at your leisure. Your idea of tapping into the communication stream is the best way to go.

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

This is the scope i use .

http://www.hobbylab.us/Oscilloscope/Help/UART.aspx

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The baud rate turns out to be 10,400. That plus the fact that the line goes 12v high on idle tends to support it being ISO-14230 communication.

I wasn't able to communicate though using the k-line off an L9637 chip, possibly because I didn't know what to send to the ECU to get it to talk back. When I added my K-line to monitor the communications between the SDS box and the ECU, the communication between those two devices failed. I'm guessing the combined current of 2 k-line devices is too much for the remaining device to pull down when it wants to talk. This is supposed to be a 1:1 connection.

So, I gave inverted RS232 a try using a MAX232 on a TTL232 adapter and that works! I changed the 57,600 baud rate on my TTL232 to 10,400 by using an override (34,00 becomes 20,41) in the ftdiport.inf file prior to driver installation. Then I used Mprog to invert the RX and TX.

When comparing the traffic from the PC to SDS capture to the SDS to ECU capture, it's clear there is a lot of traffic going to and from the PC that is never getting to the ECU. But, the actual commands from the PC and the responses from the ECU are not being translated by the SDS box. This means we should be able to send them directly.

In this block of data we see a command from the PC in purple, and a response from the ECU in blue. This data is repeatable, so there appears to be no corruption.

81 12 F1 81 05 80 F1 12 03 C1 EA 8F C0 80 12 F1

02 1A 9A 39 80 F1 12 12 5A 9A 33 32 39 32 30 2D

31 38 48 32 00 00 00 00 00 00 99 80 12 F1 02 1A

91 30 80 F1 12 12 5A 91 33 32 39 32 30 2D 31 38

48 32 2A 00 00 00 00 00 BA 80 12 F1 01 3E C2 80

F1 12 01 7E 02 80 12 F1 01 82 06 80 F1 12 01 C2

46

The first pair I believe is the wake up and response.
The second pair shows the ECU returning it's Model#(32920-18H2).
The blocks of black numbers are unknown. They do not exist on the PC-SDS side.
The third pair is a request also resulting in the model# return.
The fourth pair is the keepalive. If I do nothing this pair repeats forever.
The last pair is the disconnect.


Initialize:
From SDS: 81 12 F1 81 05
From ECU: 80 F1 12 03 C1 EA 8F C0

Keep alive:
From SDS: 80 12 F1 01 3E C2
From ECU: 80 F1 12 01 7E 02

Quit (disconnects from ECU)
From SDS: 80 12 F1 01 82 06
From ECU: 80 F1 12 01 C2 46


-- Edited by Gadget at 04:44, 2009-03-02

__________________


Guru

Status: Offline
Posts: 963
Date:

It looks like the first three bytes are the packet preamble. 80 12 F1 identifies sender as SDS and 80 F1 12 identifies sender as ECU.

After that comes Length or number of data bytes. Then comes the message data followed by a simple checksum. The checksum being the byte wise sum of all the preceding bytes.

So for example 80 F1 12 03 C1 EA 8F C0 reads as

packet from ECU ( 80 F1 12 )
3 bytes in data ( 03 )
data is C1 EA 8F
checksum = (80 + F1 + 12 + 03 + C1 + EA + 8f) & 00FF

It also looks like every command byte sent is replied with the same byte + 0x40. For instance 3E replies 7E (3E + 40). Likewise in the version request SDS sends 1A 9A and ECU replies 5A 9A (1A + 40)

At least this narrows down what command bytes we actually need to look for in the code.

I would suggest sending more 1A commands with different arguments than 91 and 95, see if it starts returning other data.


__________________


Senior Member

Status: Offline
Posts: 123
Date:

I'm only able to read with the inverted RS232 setup, and only have one TTL-232, so I'm going to read all the commands and replies I can using the SDS software before I go back to the L9637 chip for Tx tests.

The "Data Monitor" in the software shows the value of 21 different sensors including rpm, throttle position, MAP, temp, PAIR, etc. The command sent to the ECU is
80 12 F1 02 21 08 AE. My ECU on the bench replies 80 F1 12 34 61 08 0C 16 50 E0 17 50 E1 FF FF FF FF 00 00 01 FF 00 00 FF 00 FF 00 FF 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40 40 FF 00 FF FF 26 00 00 01 22 FF FF D0. The response would be different on a running bike of course.

The "Data Trouble Code Inspection" is called by sending
80 12 F1 04 18 00 00 00 9F.
The response indicates 12 trouble codes on the bench with 80 F1 12 26 58 0C 01 05 E1 01 10 E1 01 15 E1 01 20 E2 17 50 E1 16 50 E0 16 51 E2 16 54 E2 16 55 E0 04 80 E0 05 05 E0 04 43 E0 C3.

The "Show data when trouble" display indicates 2 troubles on my benched ECU- the ignition switch circuit, and the MAP circuit. This screen shows 8 sensors (engine speed, throttle pos, ISC valve, etc) for each trouble. This one is different than the others in that it does not send the same request packet over and over like the first two. This one loops through 6 packets:
80 12 F1 02 21 40 E6
80 12 F1 02 21 41 E7
80 12 F1 02 21 42 E8
80 12 F1 02 21 43 E9
80 12 F1 02 21 45 EB
80 12 F1 02 21 44 EA

Gaining these responses:
80 F1 12 12 61 40 16 50 E0 FF 00 00 00 EE 00 00 00 FF FE 28 FF FF 8
80 F1 12 12 61 41 16 50 E0 FF 00 00 00 FB 00 00 00 FF FF 29 FF FF 9C
80 F1 12 12 61 42 16 50 E0 FF 00 00 00 FD 00 00 00 FF FF 2C FF FF A2
80 F1 12 12 61 43 16 50 E0 FF 00 00 00 FB 00 00 00 FF FF 29 FF FF 9E
80 F1 12 12 61 45 16 50 E0 FF 00 00 00 EE 00 00 00 FF FE 28 FF FF 91
80 F1 12 12 61 44 16 50 E0 FF 00 00 00 FB 00 00 00 FF FF 29 FF FF 9F

This data will be more interesting on a running bike where I can better identify which bytes represent which sensor. For now though, it shows DTC info coming from a command 18, and sensor data from 21. I also noticed
80 12 F1 06 A5 05 20 00 70 00 C3 is used to reset the ISC learned value, so there may be more to look for in A5 as well.


-- Edited by Gadget at 04:46, 2009-03-02

__________________


Guru

Status: Offline
Posts: 963
Date:

Actually it is easier to identify the things like the sensor values with the ECU on the bench then on the bike. We do it all the time with new ECUs to identify the analog ports using the AUD connector.

You take two 1k ohm resistors and twist one end of each together. The connect one end of the pair to sensor power (+5V) and the other end of the pair to ground. You have now make a voltage divider where the common node of the two resistors will measure 2.5V

Find the ECU TPS pin on your wiring diagram and connect a clip lead to it. Start the sensor scan while its running observe the data when you connect the TPS lead to the resistors and when it is open. You should see one of the FF values change to around 80 when its connected and go back to FF when it unconnected. That value is your TPS.

Move the jumper to STP, IAP, SAP etc and repeat the procedure. Some of the inputs like temperatures are normally just resistors to ground so they will probably read higher than 80 but you should still see them change.

I've noticed that so far the syntax I described seems to be holding up. Hopefully sometime this week I'll be able to give you some help and try to look up some of these commands in the code. If I can find them I might find a table of commands for you to try.

Keep up the good work

__________________


Senior Member

Status: Offline
Posts: 123
Date:

That's good to know about the bench testing of sensor values, that's MUCH easier than involving the bike.

I went back and looked at the ISO-14230-2 spec that ffaspector gave us a link to earlier. Sure enough, the commands we're seeing are listed there and there's confirmation of the packet structure that you identifed already RR. Although, they show the packet data length as an addition to the command byte, rather than a separate byte as we've been seeing it. Here's some of the commands they list:

10    Start Diagnostic Session
11    ECU Reset
12    Read Freeze Frame Data
13    Read Diagnostic Trouble Codes
14    Clear Diagnostic Information
17    Read Status Of Diagnostic Trouble Codes
18    Read Diagnostic Trouble Codes By Status
1A    Read Ecu Id
20    Stop Diagnostic Session
21    Read Data By Local Id
22    Read Data By Common Id
23    Read Memory By Address
25    Stop Repeated Data Transmission
26    Set Data Rates
27    Security Access
2C    Dynamically Define Local Id
2E    Write Data By Common Id
2F    Input Output Control By Common Id
30    Input Output Control By Local Id
31    Start Routine By Local ID
32    Stop Routine By Local ID
33    Request Routine Results By Local Id
34    Request Download
35    Request Upload
36    Transfer data
37    Request transfer exit
38    Start Routine By Address
39    Stop Routine By Address
3A    Request Routine Results By Address
3B    Write Data By Local Id
3D    Write Memory By Address
3E    Tester Present
81 -> xx xx    Start Communication
82    Stop Communication
83    Access Timing Parameters
85    Start Programming Mode

I bolded the ones we've already seen with the SDS software.

I wonder if command 23 could be used to loop through all the addresses and read out the original program without needing to access the AUD port.

__________________


Senior Member

Status: Offline
Posts: 123
Date:

Some more commands:

Clear Trouble codes: 80 12 F1 03 14 00 00 9A

EVAP purge valve:

On: 80 12 F1 06 A5 07 80 00 00 00 B5

PAIR solenoid:

On: 80 12 F1 06 A5 01 80 00 00 00 AF
Off: 80 12 F1 06 A5 01 00 00 00 00 2F

Secondary throttle
:
Full open: 80 12 F1 06 A5 03 80 80 00 00 31
Full closed: 80 12 F1 06 A5 03 80 00 00 00 B1

Here's some ECU responses to 2.5v sensor inputs, differences highlighted in purple:

No sensor inputs

80 F1 12 34 61 08 0C 16 50 E0 17 50 E1 FF FF FF FF 00 00 01 FF 00
00 FF 00 FF 00 FF 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40 40
FF 00 FF FF 26 00 00 01 22 FF FF D0
Intake Air Temp Sensor:

80 F1 12 34 61 08 0B 16 50 E0 17 50 E1 FF FF FF FF 00 00 01 FF 00

42 FF 00 FF 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF 11

Intake Air Pressure #1:

80 F1 12 34 61 08 0C 16 50 E0 17 50 E1 FF FF FF FF 00 00 01 80 00

00 FF 00 FF 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF 51

Intake Air Pressure #2

80 F1 12 34 61 08 0C 16 50 E0 17 50 A1 FF FF FF FF 00 00 01 FF 00

00 FF 00 FF 00 80 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF 11

Oxygen Sensor

80 F1 12 34 61 08 0C 05 05 E0 16 50 E0 FF FF FF FF 00 00 01 FF 00

00 FF 00 80 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF F3

Throttle position sensor

80 F1 12 34 61 08 0C 05 05 E0 16 50 E0 FF FF FF FF 00 00 80 FF 00

00 FF 00 FF 00 FF 60 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF F1

Engine temperature

80 F1 12 34 61 08 0C 05 05 E0 01 05 E1 FF FF FF FF 00 00 01 FF 4B

00 FF 00 FF 00 FF 71 7C FF 00 00 00 00 00 00 00 00 FF FF 40 40 40

40 FF 00 FF FF 26 00 00 01 22 FF FF 6F




-- Edited by Gadget at 00:32, 2009-03-03

__________________


Guru

Status: Offline
Posts: 963
Date:

I found the code where the commands are parsed. It is at 0x00007840.

It looks like only the following commands are supported:

14 Clear Diagnostic Information
18 Read Diagnostic Trouble Codes By Status
1A Read Ecu Id
21 Read Data By Local Id
3E Tester Present
82 Stop Communication
A5 Test outputs

81 establish communications is not in the list but I'm assuming it is a special case.

I should be able to find the list of 'Local IDs' pretty quickly.


__________________


Guru

Status: Offline
Posts: 963
Date:

On command 21 Read by Local ID supports the following arguments

0x08 (returns 50 bytes)
0x80 (returns 100 bytes)
0x90 (returns 70 bytes)
0xC0 (returns 60 bytes)

0x40 (returns 16 bytes)
0x41 (returns 16 bytes)
0x42 (returns 16 bytes)
0x43 (returns 16 bytes)
0x44 (returns 16 bytes)
0x45 (returns 16 bytes)

0x50 (returns 16 bytes)
0x51 (returns 16 bytes)
0x52 (returns 16 bytes)
0x53 (returns 16 bytes)
0x54 (returns 16 bytes)
0x55 (returns 16 bytes)

Here are the lists of addresses read by each argument

SDS_001.txt

Now 'all' we have to do is look up all those values in the code. Unfortunately the Bandit is not a very well developed disassembly. Now that I know what I'm looking for I'm going to go back to the busa and see what I can find.

Update: Here is a stupid question....Does the K2-K7 Busa have an SDS plug? The software doesn't look like it supports it.



-- Edited by RidgeRacer at 02:47, 2009-03-03

__________________


Senior Member

Status: Offline
Posts: 123
Date:

The SDS software lists the 08-9 Busa and 04-9 GSXR 600/750 as being compatible, so due to the omission I'd guess the pre 08 Busa does not support SDS.



__________________


Guru

Status: Offline
Posts: 963
Date:

Was the 04-09 GSXR1000 was in that list? I looked at the 06 1000 code and it appears to have the same setup as the bandit. Uses the same subset of commands and list even.


Good work on the sensor testing. At first the data looked a little strange to me but then I'm used to scanning the Analog ports were you get the raw data. It then occurred to me that obviously these are the values the software uses after they have been converted and massaged.

For instance the air pressure values read FF unconnected and 80 at 2.5V just like an analog port because those are the numbers the software actually uses. The conversion to real world numbers is inherent in the x axis table of maps that use these values.

Scanning ports I would expect to see the same thing on the TPS. Of course however here it reports as 01 when unconnected, not FF, because you wouldn't want the software to think the throttle was WOT if the TPS became disconnected.

Also I'm sure the temperatures are reporting as degrees C (after some conversion) not sensor voltage. The voltage to temp conversion is non linear and varies by model so of course it makes sense to report the temp version rather than voltage.

The next question in my mind is are these values consistent across models. If command 08 byte 20 is TPS on the bandit is it also TPS on all the GSXRs? When we write the software we should use a system similar to RomRaider where we can have an xml file that can be edited to name all the variables and provide units and conversion factors. That way as new variables are discovered thru testing like this they can be added without having to rewrite the software.



__________________
1 2 35  >  Last»  | Page of 5  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard