Go Down

Topic: OBD II Bike Connector - Pass via bluetooth (Read 84212 times) previous topic - next topic

TriB

Hi Gerry!
Nice to have another ambitious follower :)

The both of us uses an L9637D, which changes the K-line one wire signal to a two wired serial signal.
It´s connected directly to the Arduino serial port (PIN 0 & 1).
With that, we have full control about the communication, which you might not have with the ELM327 in between.
For example: If you deactivate header information (ATH0) you will not be able to communicate with another control unit.

The sketches can be found here:
My solution which communicates by Bluetooth
Scissor´s solution, which uses a SD card

Where do you got the information about the PID and module from? (Just interested :D )
81 20 F1 81 15
81 means: no Length information (single byte only)
20 is Target
F1 is sender (you)
81 means "start communication"
15 is the checksum


82 20 F1 21
82 some fomat I don´t know. KWP only has 80, 81, C0, & C1
20 Target
F1 Sender
21 Read Data by local indentifier
-----------------
30 PID
E4 Checksum

Against your expectation, you are talking to the module 20. Not 21, that only means to read live data (Service ID).

Before talking to the device, you need to wake up the ECU by fast init (you will find in the code). Afterwards you will probably have to start a diagnostic session by  0x10 0x80.

I think there are all needed infos about Arduino, soldering, documentation and code in my GitHub.

Which kind of vehicle do you own? Sounds like a quad :D

Scissor

I think the SDS protocol has got a similar format byte, where the length byte is incorporated i.e. 0x80 + length byte. Such that 1 data byte results in 0x81, 2 results in 0x82 etc. Check what data bytes you get returned when requesting start communication.

If you check the latest log I posted, you'll see that my battery voltage suddenly started decaying. On startup it was close to 14V, which out of the blue went down to 11 V. So yesterday I stranded my bike with a dead battery (due to a defect in the charging system. I came to the conclusion that it was way too hot to push start my Z750). Also I noticed that in the long 0xBF response that two values that normally were 0, changed to 1. I guess in that response there are several errors being logged since there are various values constant at 0. Hence If I used my brains when plotting these graphs I would have been able to prevent all the hard work yesterday.  :)

TriB

Oh no  :o  I hope it is not a big/expensive deal to make it work again!
There is nothing more satisfying then pushing the bike with security clothing in the sun!

I just passed the 24.000km, so I´ll spend some money for big inspection, too  :-\

0xBF is a testing dataset, I´m quite sure! There are some values string together for a short checkup or something. Now you should have something in your diagnostic log!

What I´m interested about is (After charging the battery ;) ):
0x21 0x56 - My guess of Number of stored issues
0x13 0x01 - Read Troublecodes (group 01, all other didn´t respond properly)
0x12 0x01 0x01 0x0A - read Freezed Frame Data (Voltage)
       0x0X                -> Count until freezed Frames return 0x7F

Maybe we will find something more about diagnostic!

Scissor

I did some measuring today, and I'm pretty sure the regulator/rectifier stops working when it's hot. Costs only like €50,- second hand.

Anyway, I remembered incorrectly. Nothing changed in the 0xBF response (I've identified many sensor values in there, mainly voltages and pressures). But instead 0x32 and 0x56 return '1' instead of '0'. I will try to ask for any diagnostic faults tomorrow! This is actually a great opportunity :) 

Gerry48

#49
Jul 21, 2016, 06:31 pm Last Edit: Jul 21, 2016, 06:38 pm by Gerry48
Thanks Trib for the great info to get me started.  I have a '06 Sprinter (Mercedes) motor home that I'm trying to hack into. 



I have a specialized OBD tester for the Sprinter that can access all the modules (air bag, automatic temp control, central timer module, engine control module, keyless entry, shift lever module and transmission control module).   I built a bus sniffer.  It's actually not much, just a comparator as a voltage level shifter (12V to 5V) and an Arduino Uno.  Data is collected using Putty. 

Here's a data stream from the transmission:

81 20 F3 81 15
0
81 20 F3 81 15
83 F3 20 C1 EF 8F D5
82 20 F3 1A 86 35
92 F3 20 5A 86 03 25 45 48 32 47 05 20 04 08 02 51 00 06 07 25 69
82 20 F3 21 31 E7
96 F3 20 61 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3B
82 20 F3 21 30 E6
9A F3 20 61 30 0 0 0 0 0 0 0 8 0 0 DD 4E FF D5 FF B7 0 0 6 18 0 8 0 0 21


Do you know why the tranny reply with starting byte either 92, 96, or 9A? 

I'm interested in transmission temperature, but I looked at a few other parameters.
From transmission data:
9A F3 20 61 30 2 A5 0 3C 0 0 0 4 0 0 11 47 0 16 0 25 0 0 0 10 0 8 0 0 D0


Byte 17 is 47 hex, or 79 dec. That's transmission temperature.

Temperature = 79 - 40 = 39C


Byte 13 is 4 hex, or 4 dec. That's the fourth gear.

1 = first
2 = second
3 = third
4 = fourth
5 = D
7 = reverse
8 = park

I look forward to working with you guys.  Can I tag along here or should I open a new thread?

Gerry

Scissor

#50
Jul 21, 2016, 07:00 pm Last Edit: Jul 21, 2016, 08:23 pm by Scissor
Hi Gerry,

I can also give you a hand here. Let's take a closer look at the requests and response messages:


The first requests initiates communication with the ECU:
Request:

81 Format byte (80+1 => 1 Data byte)
20 Target address byte
F3 Source address byte
81 startCommunication Request Service Id
15 Checksum

Response:

83 Format byte (80+3 => 3 Data bytes)
F3 Source address byte
20 Target address byte
C1 startCommunication Positive Response Service Id
EF Data byte 2
8F Data byte 3
D5 Checksum

The positive response is always Service Id + 0x40, hence you get 0x81+0x40=0xC1 as a positive response. The important data bytes are 0xEF and 0x8F, which are described in the KWP2000 protocol as: "Both types of header supported" i.e. you can choose to include the source and target addresses but it's not mandatory.


This requests ask some information about the ECU, this could be all kind of information. It depends on the manufacturer what information is stored in the registers (0x86 in this case)

Request:

82 Format byte (80+2 => 2 data bytes)
20 Target address byte
F3 Source address byte
1A readEcuIdentification Request Service Id
86 identificationOption
35 Checksum

Response:

92 Format byte (80+12 => 12 data bytes)
F3 Source address byte
20 Target address byte
5A Positive response (since 1A+40=5A)
86 identificationOption
03 All your data bytes below, probably some kind of ID
25
45
48
32
47
05
20
04
08
02
51
00
06
07
25
69 Checksum

This requests asks for the data stored with localidentifier 0x31.

Request:

82 Format byte: 2 data bytes
20 Target address byte
F3 Source address byte
21 readDataByLocalIdentifier Request Service Id
31 recordLocalIdentifier
E7 Checksum

Response:

96 Format byte: 16 data bytes
F3 Source address
20 Target address
61 Positive response (21+40=61)
31 recordLocalIdentifier
0 All your data bytes
0 0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3B Checksum

Same as last request, but now identifier 0x30 is requested.

Request:

82 Format byte: 2 data bytes
20 Target address
F3 Source address
21 readDataByLocalIdentifier Request Service Id
30 recordLocalIdentifier
E6 Checksum

Now you can figure out how to analyse the response ;)

Gerry48

Thank you Scissor, very appreciated.  I realize there's a gold mine of knowledge here.  Perhaps you guys can solve my problem I'm having with the ELM327 clone. 

I've connected Arduino to the ELM RX & TX inputs.  In other words, I'm controlling ELM via Arduino.  It all works fine when ELM is communicating with the engine.  I can display many engine parameters.  My problem is that I can't make ELM communicate with the transmission. 

Here's my initiation:
ATZ
AT L1                   (Linefeed on)
AT E1                   (Echo on)
AT SP 5                (Protocol 5)
AT SI                   (slow initiation)
AT H1                  (Headers on)
AT KW                 (display Key Words)
AT IIA 20             (Set ISO address to 20)
AT WM 81 20 F1   (Set wakeup message)
AT SH 82 20 F1    (Set header)
21 30                  (Get tranny temp)

Here's ELM's response:
> ATZ ELM327 v1.5
>AT L1 OK
>AT E1 OK
>AT SP5 OK
>AT SI ?
>AT H1 OK
>AT KW 0 ?
>AT IIA 20 ELM327 v1.5
>AT WM 81 20 F1 81 ?
>AT SH 8220 F1 OK

ELM sends C1 33 F1 81 66, and not 81 20 F1 81 15 on the K-line to the tranny as a wakeup message.

What's the problem with ATSI, ATKW0 and ATWM 81 20 F1 81 ?
Why does ELM reply with  ELM327 v1.5 when the command is AT IIA 20?

Does the clone ELM work correctly? Or am I screwing it up?

Thanks for any insights.
Gerry

Scissor

#52
Jul 23, 2016, 10:23 pm Last Edit: Jul 24, 2016, 11:53 am by Scissor
I don't have any experience with the ELM, but I suppose you might find some information in this thread.

@Trib

I just tried a whole bunch of DTC requests, and with very little success. The three Service IDs I tried are:

18: ReadDiagnosticTroubleCodesByStatus
17: ReadStatusOfDiagnosticTroubleCodes
12: ReadFreezeFrameData

Of all combinations I tried, only ReadFreezeFrameData would return a positive response. The requests I send are:

12 xx 01 yy

'xx' is the 'freezeFrameNumber' and only works for values 1, 2 and 3 on my bike.
'01' is the 'recordAccessMethodIdentifier' and is 'requestByRecordLocalIdentifier' for this value.
'yy' is the recordLocalIdentifier from 0x0 to 0xFF (similar tot the 21 service Id)

The responses are described as:

52 Positive response
xx freezeFrameNumber
aa Value of the localIdentifier (can be several bytes)
01 requestByLocalId
yy localIdentifier

This also matches with your early findings. I attached both my KWP2000 document and my results.



 




TriB

Hi Gerry,

okay now I understand how you manage the communication!

For performance reasons I recommend to turn spaces, echo and linefeed off.
Header is needed to talk to different modules.

I´ve tested different protocols, and most of the time AT SP (Protocol Auto) was working.
Change the protocol manually didn´t work from time to time.
AT SI is only supported with protocol 2 and 4.
AT KW is only supported by ISO 9141-2 and ISO 14230-4. From my point of view there is no need to use keywords. But I probably just don´t understand the benefit  :)
AT IIA Seems to reset the ELM, that´s why it is showing its version. the documentation says, that it will require a single byte (81 only).
"Note that setting this value dies not affect any address values used in the header bytes".
AT SH changes the Header for 11 bit headers. I don´t see any advantages here, rather then messing things up :D
You can find all information here.

I think you are trying to do too much manually. If the communication with the main ECU is working, just stay with that initialization process.
Activate the Header and change the Target address to 0x20 during the startup and requests.
It´s like a housenumber. Main ECU is 11, the tranny 20. Your No is F1 :)

Hi Scissor, great! Thank you  :smiley-lol: I´ll check your file and look if I can figure someting more out how to create some kind of a dynamic sniffer.
There has to be a response which says how many Freezed data frames are there. My thought was that 0x54 PID (which always returns 3 dec) is the number of DTC groups. Or maybe the number of stored frames?

On Saturday I did a 7 hour ride with some friends. The Arduino worked for about 20 minutes.
Then it stores a timeout as an error. That means, the while-loop to receive responses was timed out.
Code: [Select]
  while ((bytesRcvd <= maxLen) && ((millis() - startTime) < MAXSENDTIME))
  {
    [...]
  }
  //Timeout: Reset ECUConnected & LED + delay 5 Seconds 
  SetLastError(3);
  ErrorAppeard(); 
  return false;
}

ErrorAppeard() calls a 5 second delay and ECUConnected is set to false. On the next Request, it should execute fastInit() again because of that.
But it does not happen! The recording doesn´t get further, no other error message appears (fastInit failed).
The WatchDog has never raised an error, which means the sketch didn´t end up in a infinit loop or something.

We did some stops to refuel and eat something. Off course restarting the bike opened the communication again. But the more we drove, the faster it broke down. 5 Minutes, 2 Minutes...
It was quite warm outside and the Airbox temperature got 40°C which could be a convergence to how hot it is under the rear seat.
I was quite sure, that I will have a WatchDog error log or the sketch will restart the communication automatically. Both didn´t :(
My device cannot easily be changed to use an external powerbank. That would be necessary to eleminate voltage differences, I think.

You´ve said you make it work to reinit after 5 seconds? How did you manage it?

Scissor

#54
Jul 25, 2016, 11:52 am Last Edit: Jul 25, 2016, 12:04 pm by Scissor
The captured freezeframe was very recently if I compare the total operating hours with previous logs. I was not running the engine as the RPM is 0, gear is 6 (it always says this when the engine is not running and in neutral) etc. Hence the freezeframe data seems to work fine! No matter what I tried, I cannot get any result to request the DTCs with service ID 17 and 18. Also the FI light is not burning, so probably no DTC is stored.

It seems like 21 32 and 21 56 returns the number of stored freezeframe data/DTCs, as these changed from 0 to 1. However it's hard to say. Maybe I can reset the freezeframe data and check if these numbers change.

Your logger shows strange behaviour, I think it is overheating somehow. Probably the bike's battery is screwing up the voltage regulator slowly. Indeed, I can restart the Arduino after 5 seconds, the code looks like this:

Library:
Code: [Select]



// 5000 ms response timeout
uint16_t responseTimeout = 5000;


byte SimpleKDS::getResponse(byte *rbuffer) {

// Reset the timer
if (t == 0) t = millis();

if (millis() - t < responseTimeout) {

....read datastream

// Reset timer after each received byte
t = 0;
....

return BUSY;
}

return TIMEOUT;

}


Arduino code:

Code: [Select]


void loop() {

  if (!ECUconnected) {
    ECUconnected = KDS.initECU();
  } else {

    sendrequest(def_req, sizeof(def_req));

    // Receive response
    resState = BUSY;
    while (resState == BUSY) resState = KDS.getResponse(resbuf);

    switch (resState) {

      case SUCCESS:
        logData();
        break;

      case TIMEOUT:
        ECUconnected = false;
        break;

      case BUFFEROVERFLOW:
        ECUconnected = false;
        break;

    }


  }

 
}



And the fast init sequence:

Code: [Select]

 byte start_communication[] = {0x81, ECUAddress, sourceAddress, 0x81, 0x00};
 start_communication[4] = start_communication[0]+start_communication[1]+start_communication[2]+start_communication[3];
 
 byte start_diagnostic_mode[] = {0x80, ECUAddress, sourceAddress, 0x02, 0x10, 0x80, 0x0}; 
 start_diagnostic_mode[6] = start_diagnostic_mode[0]+start_diagnostic_mode[1]+start_diagnostic_mode[2]+start_diagnostic_mode[3]+start_diagnostic_mode[4]+start_diagnostic_mode[5];
 
 byte resbuf[10];
 byte resState;
 
 // Clear serial RX buffer
 while(Serial.available()) Serial.read();
 
 // End Serial Port
 Serial.end();

 // Start fast init sequence
 pinMode(K_OUT, OUTPUT);                       
 digitalWrite(K_OUT, HIGH);
 // Idle communication to create correct initial conditions
 delay(350);                               
 digitalWrite(K_OUT, LOW);                     
 delay(25);
 digitalWrite(K_OUT, HIGH);
 delay(25);

 // Start serial communication with ECU
 Serial.begin(BAUDRATE);

 // Send start communication request
 sendRequest(start_communication, sizeof(start_communication));

 // Read response
 resState = BUSY;
 while (resState == BUSY) resState = getResponse(resbuf);
 
 // Return false if start communication request was denied or failed
 if (resState != SUCCESS) return false;
 if(resbuf[4] != byte(start_communication[3] + 0x40)) return false;
 
 // Send start diagnostic mode request
 sendRequest(start_diagnostic_mode, sizeof(start_diagnostic_mode));             
 
 // Read response
 resState = BUSY;
 while (resState == BUSY) resState = getResponse(resbuf);
 
 // Return false if diagnostic mode request was denied or failed
 if (resState != SUCCESS) return false;
 if(resbuf[4] != byte(start_diagnostic_mode[4] + 0x40)) return false;
 
 // Initialization successful
 return true;


TriB

#55
Jul 25, 2016, 01:48 pm Last Edit: Jul 26, 2016, 10:55 am by Trib
Good hint! I didn´t have had a clue from when the freezed Frame was. But to check engine runtime makes sense :D

That is our guess:
21 32 True/False: Freezed Frames available (1)
21 54 Supported DTC Groups (only one as our results have shown in the past) (1)
21 56 Stored freezed Frames (3)

The block 31, 32, 33 is separated by unsupported PID´s and all have a 1 as result.
That might be an info about stored frames, errors (without FI) and maybe errors with FI.

Clear Diagnostic should reset the counter and set 32 to 0...
14 01 - 01 is the DTCgroup

I´ll test that soon.
  • Clear diagnostic
  • Read 32, 54 & 56.
  • Read 12 xx 01 yy (especially total runtime)
  • Freeze Data (How?)
  • Read 32, 54 & 56 again
  • Read freezed total runtime

I´m sure there is a way to freeze frames without having a malfunction. Its also documented in KDS 3.0.
But not how. All "Write"-Functions really manipulate values. Not storing frames :-/
Today I can ask my Kawa dealer if he has some ideas. And he should show me which failures where stored :D

That´s strange! I was sure that it should reinit automatically after 5 seconds. But it would be possible, that the camera has a timeout and stops asking after I don´t respond within a period of time.
My code will be doublechecked and afterwards, I´ll see if I can cool down the Arduino or mount it on the outside. Overheating or Voltagedrops would explain why there is no WatchDog Error and why there is no automatic initialization.

[EDIT:]
Nice to see the differences in your Excel-Sheet:
PID 54 is "empty" on 2 and 3.
In my tests, all three frames got values.
PID 56 also differs and look like a raster for something. On ServiceID 21 I receive a "3" as result.
It´s very strange! We still need your KDS :D

[EDIT2]
Tested some Diagnostic things before I leave my bike at 24k inspection:
13 - Diagnostic Trouble Codes
13 01 - 53
13 02 - 53 03 10 01 10 02 15 07
13 03 - 7F 13 10 (ERROR)

12 - Freezed Data PID 54
12 01 01 54 - 52 01 15 07 01 54
12 02 01 54 - 52 02 10 02 01 54
12 03 01 54 - 52 03 10 01 01 54


12 - Freezed Frame engine Runtime
12 01 01 44 to 12 05 01 44 (5 just for testing)
52 01 00 00 E7 47 01 44
52 02 00 00 E6 37 01 44
52 03 00 00 E5 24 01 44
7F 12 10 (ERROR)
7F 12 10 (ERROR)


Now Clear Diagnostic 14 01:
-> 54

13 - Diagnostic Trouble Codes: 01 + 02 Empty, 03 Error
Worked :)

12 - Freezed Data PID 54: As before
12 - Freezed Frame engine Runtime: As before

Scissor

#56
Jul 26, 2016, 01:29 pm Last Edit: Jul 26, 2016, 02:09 pm by Scissor
Quote
Good hint! I didn´t have had a clue from when the freezed Frame was. But to check engine runtime makes sense :D

That is our guess:
21 32 True/False: Freezed Frames available (1)
21 54 Supported DTC Groups (only one as our results have shown in the past) (1)
21 56 Stored freezed Frames (3)

The block 31, 32, 33 is separated by unsupported PID´s and all have a 1 as result.
That might be an info about stored frames, errors (without FI) and maybe errors with FI.

I don't really understand completely what you are saying here. In my case 21 32 and 21 56 initially both returned 0, but approximately 1 week ago both turned to 1. 21 54 is constant so far at 0 0.

I understand that you propose that 21 32 returns 1 when freezeframes are available, and 21 56 gives the total number of freezeframes. But what exactly do you mean with 21 54? In my case this returns 0 0, does it mean only group 0000 is available?

Quote
[EDIT:]
Nice to see the differences in your Excel-Sheet:
PID 54 is "empty" on 2 and 3.
In my tests, all three frames got values.
PID 56 also differs and look like a raster for something. On ServiceID 21 I receive a "3" as result.
It´s very strange! We still need your KDS :D
Now I start to understand it. You are saying that the freezeframe of localIdentifier 54 holds the DTC group that malfunctions? In my case it returns 15 04 i.e. DTC group 1504 is not working correctly?

Quote
[EDIT2]
Tested some Diagnostic things before I leave my bike at 24k inspection:
13 - Diagnostic Trouble Codes
13 01 - 53
13 02 - 53 03 10 01 10 02 15 07
13 03 - 7F 13 10 (ERROR)

12 - Freezed Data PID 54
12 01 01 54 - 52 01 15 07 01 54
12 02 01 54 - 52 02 10 02 01 54
12 03 01 54 - 52 03 10 01 01 54


12 - Freezed Frame engine Runtime
12 01 01 44 to 12 05 01 44 (5 just for testing)
52 01 00 00 E7 47 01 44
52 02 00 00 E6 37 01 44
52 03 00 00 E5 24 01 44
7F 12 10 (ERROR)
7F 12 10 (ERROR)


Now Clear Diagnostic 14 01:
-> 54

13 - Diagnostic Trouble Codes: 01 + 02 Empty, 03 Error
Worked :)

12 - Freezed Data PID 54: As before
12 - Freezed Frame engine Runtime: As before
That's some good progress, so you can delete the stored trouble codes. In my ISO14230 document Service ID 13 is not described! Can you upload your document?

[Edit] Found another document where the request is described, no need to upload your document. I've ran the requests and these ar the results:

Code: [Select]

TX                         RX
80 11 F1 2 13 0 97 80 F1 11 3 7F 13 10 27
80 11 F1 2 13 1 98 80 F1 11 2 53 0 D7
80 11 F1 2 13 2 99 80 F1 11 4 53 1 15 4 F3
Increasing the number even more only leads to negative responses.


So requesting DTCs of DTCgroup 02 gives 1504 as a response. This is exactly the same that is stored in the freezeframe data of 12 54. Hence I think you are right, that this is the actual DTC, service code, whatever it is called. Now all we need to do is to find out what it actually means.

TriB

The values are belonging together, that´s for sure!
I´d say 21 56 is the number of freezed Frames. It doesn´t reset after I cleared the DTC.
21 32 and 21 54 say if there is an error available. I guess there are regular errors and FI errors where the red lamp turns on and you should stop. Like critical and warning.
21 54 is 0 on my bike. When I check the bike for FI´s, nothing is shown (Change to Odometer, press Mode for 2 seconds).
21 32 also returns 0 an my bike. Hard to say what is what.


Every protocol is speaking from DTC-groups...
A group could be engine, transmission or breaking-system (which is separated on my bike because of ABS control unit).
Only using 01 is working. That´s my 2 Cents on 21 65 or 21 68, which both answer always with 01.


Every SID 12 request throws an error if I go further then 3.
Also SID 13 has max. 2 positive answers.

I always thought a frame is freezed automatically on every error. That would make sense to have 3 errors, 3 freezed frames and 3 DTC´s.
My first DTC (13 01) is 00. 02 is 53 03 10 01 10 02 15 07 and 03 returns an error...

Is that again a DTC Group instead of a counter?

We need to clear everything and produce an error manually...

Talked to my Kawa dealer, today. He will let me test anything on all of his bikes. Off course I have to build him a device, too :D
He does not own KDS. He just has a regular diagnostic device with a lot of different cables. I have no clue if it is possible to do more with it, then reading and deleting DTC codes...

Now you have to test alone for some days ;)

Scissor

#58
Jul 27, 2016, 10:01 am Last Edit: Jul 27, 2016, 12:52 pm by Scissor
I think we're on the right track about the DTCs. I think a maximum of three freeze frames is just hardcoded in the ECU firmware. Possibly the freeze frames are just shifting a position whenever a new error occurs.

It seems like 13 02 is receiving all DTCs e.g. in your case:

Code: [Select]

13 02 => 53 03 10 01 10 02 15 07

53       Positive response
03       Three DTCs   
10 01   1
10 02   2
15 07   3


The strange thing to me, is that the second byte in the request (02) is described as "groupOfDTC" i.e. a 1 byte value links to a DTC group. In my other KWP2000 document, a DTC group is always described by a 2 byte value! Previously I always send a two byte DTC group for requests with service ID 17 (ReadStatusOfDiagnosticTroubleCodes) and 18 (ReadDiagnosticTroubleCodesByStatus), which always results in a negative response. I will try to do the same experiment, but now send a 1 byte DTC group.

The three DTCs you got from 13 02 match with the freezeframe data:

Code: [Select]

12 01 01 54 -  52 01 [b]15 07[/b] 01 54
12 02 01 54 -  52 02 [b]10 02[/b] 01 54
12 03 01 54 -  52 03 [b]10 01[/b] 01 54


This also is the same for me:

Code: [Select]

80 11 F1 02 13 02 99 80 F1 11 04 53 [b]01 15[/b] 04 F3

80 11 F1 04 12 01 01 54 EE 80 F1 11 06 52 01 [b]15 04[/b] 01 54 49
80 11 F1 04 12 02 01 54 EF 80 F1 11 06 52 02 00 00 01 54 31
80 11 F1 04 12 03 01 54 F0 80 F1 11 06 52 03 00 00 01 54 32


I think it's a neat result. 13 02 gives us the stored DTCs and 12 gives us the corresponding freezeframe data. I will try to send service ID 17 and 18 with 15 04 as DTCgroup, maybe it works.

Cool that you can test your device on many other bikes, I hope we can get some useful data! Btw, did you ever try to obtain ECU identification data with service ID 1A? A couple of days ago I send 1A 00-FF, but over the entire range only got negative responses.

[Edit] I tried sending all possible combinations of service id 18, and only got negative responses, therefore I believe this is just not supported for my bike. W

When going into "dealer mode 2" (faults that occured in the past, but not present right now), I get service code 31 which corresponds to "Vehicle-down sensor, malfunction, wiring open or
short". Possibly this service code corresponds to DTC 15 04 (21 04 in DEC). If this is a recent error, than it's probably related to a dead battery.

TriB

Summarized:
We have two DTCgroups: 01 & 02 (03 gave me an error).
13 01 is empty in my response
13 02 returns 3 stored errors

It will return the number of errors and 2 bytes each, the DTC and a number/identifier (I guess).

Then reading freezed frames is working by a counter, not the returned number!?
You got 01, 02, 03, I got 01, 02, 07.  I´d anticipate that I should have read 07 instead of 03.

The PID 54 is the DTC and the number again. That´s how we can make sure, the read frame matches to the DTC.
This is against my guess, what the number is for. It should´t be a counter, because I got DTC 10 twice.

With that information, I´ll try to create a dynamic sniffer about the DTC´s  :)

As you have shown in your match, it now makes sense with the freezed frames! 3 errors, 3 frames which all belong together! Great :D
But why can the DTC be deleted and the frames are still there? Sure, they will be overwritten on the next malfunction. We will see.

Compare the response with the Z750 manual:
Code: [Select]
52 01 15 07 01 54 - 0x15 = 21dec = Crankshaft sensor malfunction, wiring open or short
52 02 10 02 01 54 - 0x10 = 16dec = Intake Air Pressure Sensor #2

The Z750 don´t have a second Intake Air Pressure sensor! I found error 16 only in the Z800 manual :-/

I´m sure, when I´m allowed to test the bikes, we will be able to attach the diagnostic device, as well. Then we can see which code it receives and what we have read.


ECU ID is easy: 80 11 F1 01 1A 9D
That will definitely have a positive respond! Didn´t test more then 01.

More Infos should have been on 09 (documented somewhere...) But as it is not an official part of KWP2000, UDS or ISO 14230 it responded with an error:
09 00 - Info Types
09 01 - Numbers of VIN
09 02 - Vehicle Identification Number


The KDS docu explaines how to handle with KIPASS Diagnosis. That´s the part about immobilizer and learning keys. That could possibly be the other DTC group.
Or:
Failure History - There are 4 options which errors can be displayed:
  • [Engine Information]: Displays current engine information.
  • [Warning Information]: Displays current failure information.
  • [Monitoring Information]: Displays current monitor information. (This function is not supported now.)
  • [All Information]

2 groups left... Like I´ve said: Warning and Failure?!?

If you take a look into KDSV3.0 Page 50, it lists a record/frame. As you can see, the values are in the correct order. EngineStopped + Failure Record are before Engine Starting Mode (6B)
63-65 could be that.
The failure Record seems to have some more information! Like a sub-error, which explains what happened.

The printed report tells us what PID 1 is. It is the cranking motor, aka. starting switch :)
That was on PID 02 in my documents. 02 must be the emergency stop then.
I´ve never captured data during a start process ;)

It goes on, you can select which data to show. After Vehicle Speed, there are:
  • Engine Stopped
  • Throttle Sensor Failure
  • Inlet Air Pressure Sensor Failure
  • Inlet Air Temp  Sensor Failure
  • Water Temperature  Sensor Failure
  • Athmospheric Pressure Sensor Failure
  • ...

As you can see, there are many values which indicates a malfunction. In our tests, there have been many values 00 all the time. Or some, which have been 01 until I cleared the DTC. It´s a counter as "times" assumes.
The Sensors are in the same order like the values. We don´t know where it starts, but its something :)

You should have found this one ;) :
Battery Voltage Malfunction -> Activated if battery voltage drops below 6.6V


You are right with the max. of 3 failures and frames:
Quote
Up to a maximum of three failure records can be displayed, with some models limited to only two
Sometimes you have to read the different manuals several times, in different orders, to find some surprising informations :D

Go Up