SDS protocol

Gadget · Senior Member

RE: SDS protocol

PetriK · Guru

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

Gadget · Senior Member

Sorry, my fault, I meant to say argument not command.
Command 21, argument 08 calls for the status of all the sensors. The hex commad is: 80 12 F1 02 21 08 AE

The byte positions I specified are of the return string. so, the TPS byte is 20, the temp byte at 22, etc.

PetriK · Guru

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

PetriK · Guru

The ELM327 arrived. Unfortunaley its not a real ELM327, its a chinese copy with v1.0 firmware in it. After setting up the ecu response byte the protocol init goes through, but no data can be monitored. Anyway after opening up the thing it revealed that it was a PIC processor (most likely copied by the chinese manufacturer) and firmware being 1.0 I can not trust this either. Maybe the Suzuki implementation is only partial or maybe the chinese version is crap. Ordered a proper elm iso interface which is supposed to have latest firmware v1.3 which has some more KWP related commands in it.

There is two new discoveries though:
1) The SDS D-9pin cable to suzuki service connector is built according to OBD II specification. This means that they knew the OBD II spec when building SDS.
2) Freediag open source software written for linux is KWP2000 compatible and using the simplier hardware (not an elm chip). Freediag is in .tar.gz library - could be interesting to find whats in it.

ffaspector · Veteran Member

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

PetriK · Guru

I did not recall that 323 would support KWP2000 short init ?

In 327 the ECU response init s set by commands

ATSP05 - this is to set it to KWP2000 short init
OK
at sh 81 12 F1 - this is to set the response byte
OK

but then response to all commands is no data ...

PetriK · Guru

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

Gadget · Senior Member

Does the ELM device have an ID like the ECU or SDS box does? Or, does it monitor all communications on the K-line? If it has an ID that matches the ECU then it would only see the communication destined for that address, the responses are destined for F1 instead.

By the way, I measured with a scope. The SDS box uses fast init per the spec. A single 25ms low pulse, followed by a 25ms wait before the first packet. The swiftcomm document says the timing must be plus or minus 1ms, but that may not turn out to be true for us.

Gadget · Senior Member

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

Gadget · Senior Member

PetriK, your SDS software screen for the sensor data is showing Driving mode selection 1 and 2. Mine does not show that. It wonder if the software knows to add those additional result rows based on your ECU ID, or it's something in the command 21 response.

The gear position is indicated with byte 27. I am not sure how to get the battery voltage byte. My SDS software is reporting 0 volts even though I have a 12v supply attached. I don't currently know what pin I must energize for it to sense the voltage.

RidgeRacer · Guru

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)

PetriK · Guru

Ecu is on bench, yes - and the ecu sends the 0x64 if subroutine is active to service request so it can detect which sensors (or in this case subroutines) are active.

Gadget - you may be right, I am using at sh 81 12 F1, maybe shoud try at sh 81 F1 12.

PetriK · Guru

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

PetriK · Guru

This may be of your interest, instructions and source code how to initiate conversation with ecu:

http://www.andywhittaker.com/ECU/OBDIISoftware/tabid/69/Default.aspx

PetriK · Guru

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 ?

Gadget · Senior Member

I used the divisors to get to 10,400 but it's not possible to set it as low as 5 baud. 180 is the lowest it'll go. I'll have to try the RTS/DTR signal with an AND gate for the pulse we need.

The software from the andywhittaker site is the C software I mentioned earlier that I tried. It doesn't work though, because it can't do 5 baud from the TTL-232 interface. We would need to modify it to sent the low signal we need, but I don't know C language well enough.

I think VB is the way to go, for both you and me. I'm currently using "Serial Port Monitor" by Eltima software to send and receive the Hex commands. But I can only do one command at a time and I can't send the 25ms low to initialize the k-line.

MScomm was used in VB6 for serial port work. I'm not sure if it still is in .net. Are you using .net for ECUeditor?

-- Edited by Gadget on Saturday 14th of March 2009 02:18:42 PM

PetriK · Guru

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.

PetriK · Guru

There may be other way which may work better... the article below explains this and also says that dtr may cause difficulties.

http://www.aktivematrix.com/forum/viewtopic.php?printertopic=1&t=42&start=0&postdays=0&postorder=asc&vote=viewresult&sid=494a2df12b48a1e8fdca8ae0e7bfb752

Public Declare Function FT_SetBreakOn Lib "FTD2XX.DLL" (ByVal lngHandle As Long) As Long
Public Declare Function FT_SetBreakOff Lib "FTD2XX.DLL" (ByVal lngHandle As Long) As Long

Shall test this one.

PetriK · Guru

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

PetriK · Guru

Maybe its time to build the interface to find and fix the bugs in this ...

PetriK · Guru

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

PetriK · Guru

Success !!!

Well - have not validated the responsedata fully, but looks familiar enough. SDS is not connected and ecu is reseted before pressing connect button. I think this is enough about proof of concept. The key was to wait for 0x00 before sending anyting to the ecu at 10400.

Many thanks to everyone who have contributed to this thread, particularly to Gadget for such an excellent groundwork. I am also sorry for hijacking a bandit thread for Hayabusa gen2 stuff. (Btw the bike I had before Busa was Bandit.)

The story from my part will now on mostly continue as part of gen2 Hayabusa tools development section.

Here is how, a bruteforce method in coding this:

http://macmadigan.no-ip.com/Public/gen2/kwptest.txt

Here is a working program to test the interface (only com5 works with this):

http://macmadigan.no-ip.com/Public/gen2/kwptest.zip

Interface is this:

-- Edited by PetriK on Sunday 15th of March 2009 06:56:15 PM

Gadget · Senior Member

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

PetriK · Guru

Looks like I have FTDI com port drivers version 2.4.16.0 and same version of FTD2XX.DLL as you.

-- Edited by PetriK on Monday 16th of March 2009 06:03:50 AM

Gadget · Senior Member

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?

PetriK · Guru

))

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 Declare Function FT_GetComPortNumber Lib "FTD2XX.DLL" (ByVal lnghandle As Integer, ByRef portnumber As Integer) As Integer
Public Declare Function FT_SetBaudRate Lib "FTD2XX.DLL" (ByVal lngHandle As Integer, ByVal lngBaudRate As Integer) As Integer
Public Declare Function FT_Write_Bytes Lib "FTD2XX.DLL" Alias "FT_Write" (ByVal lngHandle As Integer, ByRef lpvBuffer As Byte, ByVal lngBufferSize As Integer, ByRef lngBytesWritten As Integer) As Integer
Public Declare Function FT_Read_Bytes Lib "FTD2XX.DLL" Alias "FT_Read" (ByVal lngHandle As Integer, ByRef lpvBuffer As Byte, ByVal lngBufferSize As Integer, ByRef lngBytesReturned As Integer) As Integer
Public Declare Function FT_GetStatus Lib "FTD2XX.DLL" (ByVal lngHandle As Integer, ByRef lngamountInRxQueue As Integer, ByRef lngAmountInTxQueue As Integer, ByRef lngEventStatus As Integer) As Integer

Gadget · Senior Member

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?

PetriK · Guru

I would put the SDS box into the same category with ELMbox and alike OBD2 boxes. Its very similiar. And there even is a real need for that: A standard PC can not do the 5baud init. Even with our skills we are at the limit of having a conitnuous data comms so a device that sends keepalives and does the 5baud is very handy.

I should receive a KWS2000 emulator in a couple of days. I will hook that in to SDS to test how well it can cope with real OBD data and see how good it is.

Anyway - we have learned that with 2usd worth of transistors and resistors you can add full KWP2000 capabilities to our programming cable USB TTL232R from FTDI - so this will make life so much easier for many of us.

The next ECUeditor 2.0 version will have data monitoring capabilities and DTC error clearing possibilities built in there using this cable. That should be usefull for anyone riding a suzuki as the basics should be the same. I have not yet decided on what to do wit all the othe KWPdata that may be possible to get.

Right now my mind is occupied by two things: Preparing my bike for a trip from Finland to Garda/Italy and secondly in hacking the fuelmaps so that I can get my new coming motor to adequate levels powerwise witout and with nitrous.

Gadget · Senior Member

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.

PetriK · Guru

Nothing changed ... I dont have any registers inverted or anything. Its just plug and play with the schematic above.

The 5baud init timing parameters were somewhat critcal. I used 23ms to get the responses, so its 23+2ms. When I have more time will look into this again to have an user adjustable timing for initialization which may be needed - now the installation package has some adjusting capability for timing.

As visual basic is not a real time environment we can not fully trust the timers.

Gadget · Senior Member

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...

PetriK · Guru

I think that the biggest problem was to try using Com port, initializing and using that causes too long delay. When switched over to FT_ calls, accuracy improved. Obviously some time must be reserved for executing FT_calls and that may be computer dependant.

I can post all of the code after I (re)find the GNU type copyright to add to the beginning of the code.

PetriK · Guru

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

Gadget · Senior Member

That timer call works well. With it and 23ms I usually connect every time, with the occasional miss. Without it I've tried as many as 10 times in a row without a connect.

Here's the "wrapper":
timeBeginPeriod(1)
FT_status = FT_SetBreakOff(lngHandle)       ' K-line high
System.Threading.Thread.Sleep(300)
FT_status = FT_SetBreakOn(lngHandle)        ' K-line low
System.Threading.Thread.Sleep(i)
FT_status = FT_SetBreakOff(lngHandle)       ' K-line high
System.Threading.Thread.Sleep(i)
timeEndPeriod(1)

and the declares:
Public Declare Function timeBeginPeriod Lib "winmm.dll" (ByVal uPeriod As Integer) As Integer
Public Declare Function timeEndPeriod Lib "winmm.dll" (ByVal uPeriod As Integer) As Integer

Note: You should end the special timing right after the critical init because it slows everything with it's increased interrupt rate.

-- Edited by Gadget on Wednesday 18th of March 2009 12:28:48 AM

PetriK · Guru

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.

smithabusa · Guru

Petrik,

in your diagram, are you no longer using the 5V red wire coming from the USB device? Are you grabing 12 volts from a wire going to ecu?

-- Edited by smithabusa on Sunday 12th of April 2009 03:05:43 PM

PetriK · Guru

the kwp assumes always 12v with same levels as ecu

dhula · Newbie

PetriK wrote:

The product on this link below looks interesting:

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

Hi, I'm new here as i have an interest in what you are doing with the bandit ecu. i don't think i have anything what so ever to contribute at this stage as i'm still considering whether to do anything with the info i have gleaned from this forum (which by the way is bloody great and i must say i am in awe of the skills/knowledge of you guys)

anyway, i'll have access to one of these very soon (should be delivered Monday around 4 pm according to UPS) and just thought i'd mention that if you need info about it i'd be glad to help if i can.

i'll also have access to one of these and one of these if you are interested

RocJumper · Newbie

HI Guys

I'm working on a on-board computer for Wee and this thread is very useful for me. All of you did a excellent job.

I've got the original ELM327 and I put it in monitor mode. It seems Wee works the same way than Bandit. I captured some packets and the information is the same.

My problem now is the "command 21, Read by Local ID" Did you find out the meaning of these 50 bytes of sensor's information? I saw you said that byte 27 (counting from bytes number byte?) is the gear position for example.

Thnks

PetriK · Guru

Check out the thread under gen2 hayabusa on engine data monitor and ecueditor2.0.

On this picture left is the suzuki list and right is the ecueditor 2.0 KWP data monitor screen.

-- Edited by PetriK on Thursday 23rd of July 2009 06:59:36 PM

RocJumper · Newbie

Thnks PetriK!

Very nice! Great Job.

From SDS Engine Speed is 835 rpm and Ecueditor2 shows 832 rpm. It's because polling delay? Or division factor should be 2.55 instead of 2.56?

Roc

Surfer · Newbie

Bump for a bit of assistance?

I've got a 2008 DL650 that I'd like to do the throttle body sync. The service manual requires the SDS tool to lock the ISC (Idle Speed Control valve) at position 60.

I'm able to communicate with the ECU using my KWP2000 interface, but I don't know the PID/command to take active control of the ISC.

Can anyone with the SDS record their ECU interaction while locking the ISC? Here is the service section that describes the process.

a) Connect the SDS tool.
b) Start the engine.
c) Click "Data monitor".
My note: At this point the SDS screen shows the oil temperature, engine speed (rpm), throttle position, battery voltage, intake air temp, 02 sensor.
d) Warm up the engine (Water temp. more than 70 °C (158 °F).
e) Click "Active control". (My note: on the SDS screen.)
f) Click "ISC air volume control"
g) Click "ON" to fix the ISC air volume of the cylinders. Service manual NOTE: When making this synchronization, be sure themperature is within 70 * 100 °C (158 * 212 °F).
i) Engine speed: Approx. 1 150 rpm
ii) ISC valve position: Approx. 60 step
My note: so far the SDS is used to monitor the oil temperature, the idle rpm, and the ISC valve position, and to set the ISC to approx. 60 step.
h) Check for the synchronization of vacuum from #1 to #2 cylinders.

Then Clear the ISC and turn off active control.

Anyone??? I know it is a lot to ask of someone who has access to an SDS, so let me know if there is something I can do in return.

dealbu · Newbie

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

PetriK · Guru

Package 0x8 i guess... let us know the package info on gixxer back to us.

.word KWP_packageID_unk_80675D
ROM_:000525A4                                         ; DATA XREF: KWP2000_read_by_local_id_argument_parser_sub_4D74C+8o
ROM_:000525A4                                         ; 0x08
ROM_:000525A8                 .word KWP_unk_8066DC    ; 0x12
ROM_:000525AC                 .word KWP_unk_8066DD    ; 0x01
ROM_:000525B0                 .word KWP_unk_80675E    ; 0x10
ROM_:000525B4                 .word KWP_unk_8066DE    ; 0xa1
ROM_:000525B8                 .word KWP_unk_8066DF    ; 0x01
ROM_:000525BC                 .word KWP_unk_80675F    ; 0xe0
ROM_:000525C0                 .word _0xFF_unk_7D11B   ; 0xFF
ROM_:000525C4                 .word _0xFF_unk_7D11B   ; 0xFF
ROM_:000525C8                 .word _0xFF_unk_7D11B   ; Normally 0xFF, Using this for the boost pressure by ECUeditor
ROM_:000525CC                 .word _0xFF_unk_7D11B   ; Normally 0xFF, Planning to use this for mode_ABC_selected_ramvar_unk_8050D5
ROM_:000525D0                 .word KWP_RPM_1a_unk_8066D2 ; case 24 in ecueditor
ROM_:000525D4                 .word KWP_RPM_1b_unk_8066D3
ROM_:000525D8                 .word KWP_TPS_unk_80672F
ROM_:000525DC                 .word KWP_IAP_unk_806730
ROM_:000525E0                 .word KWP_CLT_unk_806732
ROM_:000525E4                 .word KWP_IAT_unk_806733
ROM_:000525E8                 .word KWP_AP_unk_806731 ; case 30 in ecueditor
ROM_:000525EC                 .word KWP_BV_unk_80673D
ROM_:000525F0                 .word KWP_HOXs1b1_unk_80673E
ROM_:000525F4                 .word KWP_GP_unk_806734
ROM_:000525F8                 .word _0xFF_unk_7D11B
ROM_:000525FC                 .word isc_unsure_desired_idle_speed_KWP_unk_80673B
ROM_:00052600                 .word isc_unsure_isc_valve_position_KWP_unk_80673A
ROM_:00052604                 .word _0xFF_unk_7D11B
ROM_:00052608                 .word KWP_fuel1a_unk_8066D4
ROM_:0005260C                 .word KWP_fuel1b_unk_8066D5
ROM_:00052610                 .word KWP_fuel2a_unk_8066D6 ; case 40 in ecueditor
ROM_:00052614                 .word KWP_fuel2b_unk_8066D7
ROM_:00052618                 .word KWP_fuel3a_unk_8066D8
ROM_:0005261C                 .word KWP_fuel3b_unk_8066D9
ROM_:00052620                 .word KWP_fuel4a_unk_8066DA
ROM_:00052624                 .word KWP_fuel4b_unk_8066DB
ROM_:00052628                 .word _0xFF_unk_7D11B
ROM_:0005262C                 .word _0xFF_unk_7D11B
ROM_:00052630                 .word KWP_ign0_unk_806367
ROM_:00052634                 .word KWP_ign1_unk_806368
ROM_:00052638                 .word KWP_ign2_unk_806369 ; case 50 in ecueditor
ROM_:0005263C                 .word KWP_ign3_unk_80636A
ROM_:00052640                 .word _0xFF_unk_7D11B
ROM_:00052644                 .word KWP_STP_position_unk_806735
ROM_:00052648                 .word _0xFF_unk_7D11B
ROM_:0005264C                 .word _0xFF_unk_7D11B
ROM_:00052650                 .word KWP_engine_bitflags_1_unk_80673C
ROM_:00052654                 .word KWP_engine_bitflags_2_unk_806748
ROM_:00052658                 .word KWP_engine_bitflags_3__DSM1_DSM2_PAIR_IGN_TIP_STP_unk_806749
ROM_:0005265C                 .word KWP_engine_bitflags_4_0x10whenClutchNeutralAndevenStart_0x2whenTST_unk_80674A
ROM_:00052660                 .word KWP_engine_bitflags_5_unk_80674B
ROM_:00052664                 .word _0xFF_unk_7D11B
ROM_:00052668                 .word _0xFF_unk_7D11B

dealbu · Newbie

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?

I have some live data from the bike, if anyone is interested in taking a look.

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

PetriK · Guru

i think busa is not supporting speed data so can not really tell which byte that is.

there is several package info types in busa, but 08 is most informative.

PetriK · Guru

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

songotag · Member

Gadget wrote:

Does the ELM device have an ID like the ECU or SDS box does? Or, does it monitor all communications on the K-line? If it has an ID that matches the ECU then it would only see the communication destined for that address, the responses are destined for F1 instead.

By the way, I measured with a scope. The SDS box uses fast init per the spec. A single 25ms low pulse, followed by a 25ms wait before the first packet. The swiftcomm document says the timing must be plus or minus 1ms, but that may not turn out to be true for us.

hello, can you tell me if the kwp200 can be use with my vstrom k8 ? and if you know the pins of the ODB connector of the strom ;)

thanks

PetriK · Guru

Thats suzuki, so just look at the factory manual what it says - the Busa interface should be a direct fit.

http://ecuhacking.activeboard.com/forum.spark?aBID=99460&p=3&topicID=41122594