I am sorry, but now I am lost with this. Do not recognize command 0x08 from the ecu code. Its most likely because how the commands are implemented.

Just in case, would like to ask if it is possible that 0x08 is a parameter to a command ?

The commands that been able to find so far are:
#0x21 KWP2000_read_local_ID_loc_F628
#0x18 KWP2000_read_DTC_loc_F618
#0x14 KWP2000_clear_DTC_loc_F610
#0x1A KWP2000_read_ECUID_loc_F620
#0x82 KWP2000_stop_communications_loc_F638
......KWP2000_test_outputs_loc_F6A0
#0x3E KWP2000_tester_present



-- Edited by PetriK at 22:16, 2009-03-12

Now I understand. The first value to be returned seems to be RPM, then TPS and so on... can you confirm 14th and 15th on the list (my numbering reflects the actual KWP data structure, not the needed bytes before). Should be doable by modifying the battery voltage and just playing with a resistor with GPS sensor input.

ROM_:00052914 KWP_package_return_local_id_argument_plus_off_52914:.word RPM_1
ROM_:00052918 .word unsure_TPS_byte_80502F
ROM_:0005291C .word unsure_IAP_unk_80674F
ROM_:00052920 .word unsure_ECT_unk_804F24
ROM_:00052924 .word unsure_IAT_unk_804F25
ROM_:00052928 .word unsure_HOX_unk_804F48
ROM_:0005292C .word unsure_AAP_unk_804F49
ROM_:00052930 .word unk_804F4C
ROM_:00052934 .word unk_804F4D
ROM_:00052938 .word unk_804F52
ROM_:0005293C .word unk_804F53
ROM_:00052940 .word unk_805062
ROM_:00052944 .word unk_80506D
ROM_:00052948 .word unk_805076
ROM_:0005294C .word unsure_battery_voltage_AD9_value_unk_8050A9
ROM_:00052950 .word unsure_gear_bitvalue_unk_8050B3
ROM_:00052954 .word unk_805085
ROM_:00052958 .word unk_804F88
ROM_:0005295C .word unk_8063D0

-- Edited by ffaspector on Sunday 18th of October 2009 03:01:33 AM

More info ....

when I put ELM327 http://www.elmelectronics.com/DSheets/ELM327DS.pdf to listen the ecu while SDS is communicating with it I can see the traffic which I guess is from ELM to ECU. In this case its message:
02 21 08

Then I can monitor also the Clear all DTC:s and e.g. setting pair on and off commands, and of course the keepalive commands 01 3E.

The chinese version I have can not skip the initiliazion sequens and some other new KWP commands implemeted in ELM so I would guess there is something in this.

First line when starting to monitor seems like all the parameters are received, but after that only 02 21 08.


----------------------

Initialization sequence
02 1A 9A
02 1A 91

then only keepalives
01 3E

and when data monitoring starts
02 21 08

When closing connection
01 82

------------------------

Makes me to wonder why the responses are not seen ?

Had the additional header bytes monitoring off, so in real life you see 80 12 F1 on front of all the above.



-- Edited by PetriK on Friday 13th of March 2009 09:03:17 PM

-- Edited by PetriK on Friday 13th of March 2009 09:24:30 PM

Some command 21 arguments and responses, with no sensors connected:

80 12 f1 02 21 80 26
80 f1 12 66 61 80 0c 16 50 e0 17 50 e1 00 00 ff ff ff ff ff ff 7e 80 53 ff ff ff 80 10 ff ff ff 00 80 00 ff ff ff ff ff ff 80 ff ff ff ff 80 80 80 80 00 01 00 01 00 01 00 01 ff ff 80 00 01 00 01 00 01 ff ff ff ff 80 00 00 ff 00 00 00 80 80 80 80 80 80 80 80 80 80 ff 80 80 26 07 ff ff ff ff 00 ff 00 01 15 20 10 ff ff 9a
--------
80 12 f1 02 21 90 36
80 f1 12 48 61 90 44 34 46 39 53 45 32 30 01 40 00 00 98 c0 ff c0 ff c0 ff c0 00 c0 fe c0 ff c0 ff c0 00 80 ff 80 ff c0 ff c0 ff c0 00 00 df ff 1f ff ff ff 00 ff 00 01 00 01 01 db ff ff ff ff ff ff f8 49 00 bc 70 10 a0 ff 03 e9 94
--------
80 12 f1 02 21 c0 66
80 f1 12 3e 61 c0 00 dc ba cc 00 b0 70 00 98 00 07 00 ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ff ff 80 80 80 80 80 43 40 40 40 40 6b 6b 00 ff 26 ff ff 00 00 00 00 01 22 15 20 10 00 00 00 00 ff 19
--------
80 12 f1 02 21 40 e6
80 f1 12 12 61 40 16 50 e0 ff 00 00 00 ed 00 00 00 ff ff 28 ff ff 8c
--------
80 12 f1 02 21 41 e7
80 f1 12 12 61 41 16 50 e0 ff 00 00 00 fb 00 00 00 ff ff 29 ff ff 9c
-------
80 12 f1 02 21 42 e8
80 f1 12 12 61 42 16 50 e0 ff 00 00 00 fe 00 00 00 ff ff 2c ff ff a3
-------
80 12 f1 02 21 43 e9
80 f1 12 12 61 43 16 50 e0 ff 00 00 00 fb 00 00 00 ff ff 29 ff ff 9e
-------
80 12 f1 02 21 44 ea
80 f1 12 12 61 44 16 50 e0 ff 00 00 00 fb 00 00 00 ff ff 29 ff ff 9f
-------
80 12 f1 02 21 45 eb
80 f1 12 12 61 45 16 50 e0 ff 00 00 00 ed 00 00 00 ff ff 28 ff ff 91
-------
80 12 f1 02 21 50 f6
80 f1 12 12 61 50 17 50 e1 ff 00 00 00 ed 00 00 00 ff ff 28 ff ff 9e
-------
80 12 f1 02 21 51 f7
80 f1 12 12 61 51 17 50 e1 ff 00 00 00 fb 00 00 00 ff ff 29 ff ff ae
-------
80 12 f1 02 21 52 f8
80 f1 12 12 61 52 17 50 e1 ff 00 00 00 fe 00 00 00 ff ff 2c ff ff b5
-------
80 12 f1 02 21 53 f9
80 f1 12 12 61 53 17 50 e1 ff 00 00 01 ff 00 00 00 ff ff 3f ff ff cb
-------
80 12 f1 02 21 54 fa
80 f1 12 12 61 54 17 50 e1 ff 00 00 01 ff 00 00 00 ff ff 3f ff ff cc
-------
80 12 f1 02 21 55 fb
80 f1 12 12 61 55 17 50 e1 ff 00 00 00 ed 00 00 00 ff ff 28 ff ff a3

Voltage wise do you have it on the bike or on the bench?

There are several voltage monitoring points like the Fuel voltage switch by the fuel relay and also possibly the unswitched memory backup line (batt)

No luck with reversed header byte order, exepc that then I get bus init error, ie. the header byte 81 12 F1 is correct. I can monitor transmitter F1 (SDS?) but not transmitter 12 (ECU?). The good thing is that all the commands from SDS to ECU can now be made known, most common being. (repeating what is being said earlier in this thread, but slightly different angle).

80 12 F1 02 21 08             monitor sensor data
80 12 F1 03 14 00 00          clear dtc
80 12 F1 04 18 00 00 00       dtc monitoring
80 12 F1 01 3e                keep alive

for testing purposes also this may be useful:

80 12 F1 06 a5 01 80 00 00 00 set pair on
80 12 F1 06 a5 01 00 00 00 00 set pair off

I suspect that the KWP protocol implementetion (as descibed by ELM documentation) expects ascii ISO Key Words (like TPS, BV+ etc) to be received as part of the capabilities request so that the OBD software knows which packages to expects. Based on disassembly the Suzuki motorcycle ECU does not support the ascii keywords in command 21, just direct addressing so therefore initialization may fail.

In ELM 327 v 1.3 documentation you can disable the key word checking, but that is not implemented in ELM 327 v 1.0 which I have. Really hate this that someone sells a box as elm327 but when you open it then you are disappointed it being a copy.

While testing I occasionally get a longer package when starting to monitor data only to be followed with an error message indicating that the protocol does not support it. Anyhow this confirms that the data is on the bus. ( should see all the data with a direct connection to the data bus)

So need to wait for about a week to receive an ELM 327 from Germany which is supposed to be a real thing with more advanced protocols to test this further.

Gadget - what tools and hardware are you using to write the initialization sequence ? FTDI interface with the double inverting transistors ? How about programming language ? I mean can it be easily converted into visual basic to try out on my desktop ?



-- Edited by PetriK on Saturday 14th of March 2009 08:09:46 AM

Gadget wrote:

---

According to the datasheet, the lowest baud the TTL-232 can do is 182. That explains why the wake-up is not working. I imagine you can create an artificially slower byte send in software by holding the output low or high the required milliseconds for each bit, but we won't be able to hear the 0x55 ack from the ECU. I guess we can do without that though.

If I stick to 10,400 baud, the timing on the 00110011 wake-up packet needs to be 2,080 times longer to to simulate 5 baud. That plus a start bit. So, I think I need to send:
2,080 bit 0's
4,160 bit 1's
4,160 bit 0's
4,160 bit 1's
4,160 bit 0's

That is, if I can figure out how to send bits with VB...

---

Have you tried out various divisors for TTL232 as per this document for 5baud?
http://www.ftdichip.com/Documents/AppNotes/AN232B-05_BaudRates.pdf

I was able to set serialport to 7812 directly from VB, same propably applies to 10400. Unfortunately as you said, when going well below 300baud the rate just goes up not low. (Wrote a small VB program as ititilization routine for the ECU, but baudrate 5 can not be set.)

As 5 baud is really not possible then perhaps DTR or alike signal can be set using timer millliseconds for a while to emulate 5 baud bits ?

For the coming version I am using VB2008 which is free from microsoft for non profit/educational work. Earlier version was VB2005.

I am looking at the DTR pulse right now and playing around with VB2008 trying stuff.

DTR (FTDI green wire), 0/5V - this and a gate should do it.

Something like the below could work, at least on scope I can see something that looks like the init sequence using just the RX/TX lines (no DTR etc.). Please note that this allows only one FTDI device being connected. I dont have hardware (the two transistor rig yet built up to test this.) Written with Visual Basic 2008 Express Edition. Someone may find a more elegant way of doing this than disabling the thread for a few milliseconds at a time...

Have fun

Public Declare Function FT_SetBreakOn Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer
 Public Declare Function FT_SetBreakOff Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer
Public Declare Function FT_Open Lib "FTD2XX.DLL" (ByVal iDevice As Integer, ByRef lnghandle As Integer) As Integer
Public Declare Function FT_GetNumberOfDevices Lib "FTD2XX.DLL" Alias "FT_ListDevices" (ByRef lngNumberofdevices As Integer, ByVal pvarg2 As String, ByVal lngflags As Integer) As Integer
Public Declare Function FT_ListDevices Lib "FTD2XX.DLL" (ByRef lngNumberofdevices As Integer, ByVal pvarg2 As String, ByVal lngflags As Integer) As Integer
Public Declare Function FT_Close Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer

Public lngHandle As Integer
Public High As Boolean = True
Public Low As Boolean = False

Private Sub k_line(ByVal b As Boolean)
Dim FT_status As Integer
  If b Then
     FT_status = FT_SetBreakOff(lngHandle)
  Else
     FT_status = FT_SetBreakOn(lngHandle)
  End If
End Sub

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim i As Integer
Dim rxbyte As Byte
Dim FT_status As Integer

' 5 Baud Init
FT_status = FT_GetNumberOfDevices(i, 0, &H80000000)
If i > 1 Then MsgBox("Dont know device id, too many FTDI devices connected")
FT_status = FT_Open(0, lngHandle) ' only one
If FT_status <> 0 Then MsgBox("Can not open FTDI USB device, error:" & FT_status)

k_line(High)
System.Threading.Thread.Sleep(300)
k_line(Low)
System.Threading.Thread.Sleep(25)
k_line(High)
System.Threading.Thread.Sleep(25)
FT_status = FT_Close(lngHandle)

serialport.PortName = "COM5"
serialport.DataBits = 8
serialport.Parity = IO.Ports.Parity.None
serialport.StopBits = IO.Ports.StopBits.One
serialport.BaudRate = 10400
serialport.Open()
serialport.DiscardInBuffer()
'
' Here after this initiate normal conversation using com port
'

-- Edited by PetriK on Saturday 14th of March 2009 05:01:18 PM

I think there is more to be learned about the initialization sequence... Added a simple listen the K-line routine between ECU and SDS. In initialization the first byte looks like 00, but I am not sure which end is sending that one - or it could be that the fast initi is ending too soon or even causing readbuffer to read something ?

Gadget, do you have a possiblity to scope the exact initialization sequence that SDS is using including first character direction and value ?

My scope is not intelligent enough to be able to trigger to see the initialization.




EDIT: here, http://macmadigan.no-ip.com/Public/gen2/kwptest.zip
Only FTDI USB adapter installed at com5 is supported.

Changed the first connect wait byte to 0x30 and get a string, but I would guess that this is more due to incorrect initialization timing sequence as on the above screen there is 0x00 instead of 0x30 ?

EDIT 2: After some debugging all this seems to now pointing again to the direction of visual basic non real time timer control. Need to find a method for precicely control the lines for accurate timing of the init signal.


-- Edited by PetriK on Sunday 15th of March 2009 02:25:41 PM

Awesome job PetriK!!

What driver version do you have for your TTL-232? I'm not able to find FT_Read_Bytes in FTD2XX.dll version 3.1.18.0. Looks like FT_Read is the "classic" function, but I get errors when I try to use that.







-- Edited by Gadget on Monday 16th of March 2009 03:50:13 AM

That's strange...we have the same .dll yet the available functions are different. When I try to use FT_Read_Bytes I get an unable to locate entry point in dll error.

How are you declaring the function?

Thanks PetriK. Are you doing anything to eliminate the SDS transmit echo or are you just ignoring it in software?

So, what's the consensus on the purpose of the SDS box? Baud rate converter, data buffer, USB adapter, initialize pulse generator, echo absorber, and really expensive dongle?

That trip to Italy sounds like fun!

Question for you - Did you have to change any of your TTL-232 divisors to get 10,400 baud? I'm using your program with Com5 but am not getting any response from the ECU.

Have you seen this page? http://gpwiki.org/index.php/VB:Timers

They say that by using "timeBeginPeriod 1" you reset the timeGetTime function to 1 millisecond accuracy. Sounds like a good wrapper if it works. I can give it a try tonight to see if it makes any difference in the code I cobbled together from your previous posts. Hopefully all I've got wrong is the timing problem...

The http://macmadigan.no-ip.com/Public/gen2/kwptest.txt has full source code under GNU license.

A small disclaimer about GNU license: Anyone using the information published must commit to share the sourcecode including also derivered products that is based on the concept presented in this file. In case the sourcecode is not presented of the derivered product then a proof must be presented that its not based on the sourcecode published in that attachment. Obviously this limitation only applies to this published version, not versions prior to publishing.

-- Edited by PetriK on Tuesday 17th of March 2009 02:08:49 PM

The product on this link below looks interesting:

http://www.probike.co.uk/it080002.htm

Anyhow based on what we know not all suzukis >2003 are supported with KWP, so dont know how well I trust this material presented.

the kwp assumes always 12v with same levels as ecu

HI Guys

Thnks PetriK!

Gadget wrote:

---

I just remembered that while the SDS software will not send anything other then the 08 argument, I can send any command I want from a terminal session while the SDS and ECU are in keepalive mode.

So, I can send the arguments from the list RR provided. But, the responses will be similar to the ones I got for the 08 argument. I can't read them either. Maybe if we had more data, from repeated sensor tests under the different arguments we could be more clear about what each byte represented?

Right now these are my guesses:

Sensor : Command, Byte
TPS      : 08,20
IAP#1  : 08,21
Temp   : 08,22
IAT       : 08,23
O2S      : 08,26
IAP#2   : 08,28

---

 

Hello everybody!

This is my first post to this forum and I'd like to take the opportunity to thank everybody who contributed to this real "knowledge database".

Thank to all the work here, I managed to connect to my GSXR 1000 k7 using a microcontroller interface.

Right now I'm at the point at which I should decode the answer to the sensor monitor command (21 08).

This is what I managed to figure until now (Please note that I might be wrong, more or less!):
Pos. Value Data

0 80 Header byte
1 F1 Tester ID
2 12 ECU ID
3 34 Message length
4 61 Message type (Sensor data)
5 08
6 02
7 05
8 05
9 A0
10 17
11 69
12 A2
13 FF
14 FF
15 FF
16 00 Speed = byte 16 * 2 in km/h
17 00 RPM byte 1 
18 00 RPM byte 2: RPM = 10 * byte 17 +byte 18 / 10
19 37 Throttle position: 0x37 = 0%, 0xDD = 100%
20 B8
21 6B Engine Temperature = (byte 21 - 48) / 1.6 in Celsius degrees
22 61 Intake Air Temperature, same formula as above
23 B9
24 00
25 FF
26 00 Gear indicator 0-neutral; 1- 1st gear... a.s.o.
27 FF
28 5E
29 1F
30 FF
31 00
32 00
33 00
34 00
35 00
36 00
37 00
38 00
39 FF
40 FF
41 40
42 40
43 40
44 40
45 FF
46 1A
47 00
48 CB
49 1A
50 30
51 00
52 04 Clutch sensor (bit 8?): 0x04 = clutch released, 0x14 clutch "pressed"
53 00 Neutral sensor (bit 1?): 0x00 = neutral, 0x02 = in gear
54 FF
55 FF
56 07 Checksum

 

This seems to be the same for Bandit or Hayabusa, right?

So, please, anyone who dug more into this, be so kind and contribute to this! If I will have more data, I will keep you informed.

 

-- Edited by dealbu on Saturday 17th of July 2010 12:03:23 PM

-- Edited by dealbu on Wednesday 21st of July 2010 06:54:48 AM

-- Edited by dealbu on Thursday 24th of March 2011 08:57:16 AM

Exactly, the command string is 0x21 0x08.
What do you mean by "package info"?

On the other hand, I would like to know about the vehicle speed, which, by my guess, is the byte no. 16. Do you know in what units is expressed?

-- Edited by dealbu on Wednesday 21st of July 2010 07:05:11 AM

Some of you may find also this interesting - not tested yet so may not work as its only based on reading the disassembled code.

80 12 F1 02 21 08 monitor sensor data
80 12 F1 03 14 00 00 clear dtc
80 12 F1 04 18 00 00 00 dtc monitoring
80 12 F1 01 3e keep alive

not all below mentioned are tested...

80 12 F1 06 a5 01 80 00 00 00 set pair on
80 12 F1 06 a5 01 00 00 00 00 set pair off

80 12 F1 06 a5 02 not applicable

80 12 F1 06 a5 03 80 00 00 CKS set excva on
80 12 F1 06 a5 03 00 00 00 CKS set excva off

80 12 F1 06 a5 02 not applicable

80 12 F1 06 a5 05 28 RPM 00 CKS set ics rpm value, value needs to be between 54 and A0, rpm is =(HEX2DEC(RPM)*2^5)/2.56

80 12 F1 06 a5 06 80 00 00 CKS set fan on
80 12 F1 06 a5 06 00 00 00 CKS set fan off

80 12 F1 06 a5 07 80 00 00 CKS set evap on
80 12 F1 06 a5 07 00 00 00 CKS set evap off