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?
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
__________________
When asking a question, you can also consider posting it to facebook:
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.
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.
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.
__________________
When asking a question, you can also consider posting it to facebook:
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
__________________
When asking a question, you can also consider posting it to facebook:
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.
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.
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.
__________________
When asking a question, you can also consider posting it to facebook:
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
__________________
When asking a question, you can also consider posting it to facebook:
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...
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 ?
__________________
When asking a question, you can also consider posting it to facebook:
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
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.
__________________
When asking a question, you can also consider posting it to facebook:
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)
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
__________________
When asking a question, you can also consider posting it to facebook:
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
__________________
When asking a question, you can also consider posting it to facebook:
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.
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.
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
__________________
When asking a question, you can also consider posting it to facebook:
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?
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.
__________________
When asking a question, you can also consider posting it to facebook:
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.
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.
__________________
When asking a question, you can also consider posting it to facebook:
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...
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.
__________________
When asking a question, you can also consider posting it to facebook:
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
__________________
When asking a question, you can also consider posting it to facebook:
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
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
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.
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.
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?
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 ;)