Go Down

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

Scissor

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.
I think you made a typo, you don't receive 01, 02 and 07 but 10 01, 10 02 and 15 07. These are your DTC(groups?).

The 01, 02, 03 is just the freezeframe counter.

You:

13 02  -  53 03 10 01 10 02 15 07

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

Me:

13 02  -  53 01 15 04

12 01 01 54  -  52 01 15 04 01 54
12 02 01 54  -  52 02 00 00 01 54
12 03 01 54  -  52 03 00 00 01 54


It could be coincidental in your case, but it seems like the first DTC given by 13 02 is stored in freezeframe #3, the 2nd in freezeframe #2 and the 3rd in freezeframe #1. For me, the first (and only) DTC given with 13 02 is stored in freezeframe #1.

It could be possible that the most recent DTCs are added to the 13 02 response like:

53 n [DTC #1][DTC #2]...[DTC #n]

Such that the response of the freezeframes is like this:

52 01 [DTC #n] 01 54
...
...
52 n [DTC #1] 01 54

In our case only a maximum of 3 freezeframes could be stored obviously.

Therefore, by counting the number of DTCs given by 13 02, you can figure out which is the corresponding freezeframe. For example, 13 02 gives two DTCs: 53 02 aa bb cc dd. Now you know that the DTC aabb occured first and therefore the DTC ccdd is the most recent DTC. Hence, DTC ccdd is stored "on top"of the previous DTC i.e. in freezeframe #1, which you can request with 12 01 01 xx.

Quote
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.
I don't know. Perhaps it just is not possible, since the user does not know of it existence anyway.

Quote
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 had the same problem, error code 16 is not described in my manual. That's the reason why I think the two bytes represent one DTC. Otherwise you would not have the DTC 10 twice, but just once with an increased count rate for instance.

My DTC is 15 04 (HEX) = 21 04 (DEC), and the FI code I got was 31. I don't know how this is related though.

Quote
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
Thanks! Will give that a try.

Quote
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.
Seems interesting indeed! Definitely this is related to all the 0s we get when requesting localids.

Quote
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 ;)
I'm pretty sure PID 02 is the starter switch. I've logged it a couple of times, and sometimes I was lucky to capture the moment I pressed the starter switch and it turned from 0 to 1. PID 01 was always constant at 05 when I logged it.

Quote
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
I agree all the 0s in the range of 39-63 (27-3F in HEX) most likely are related to a malfunction timer. Could very well be that I activated that one! Where did you find that specific malfunction? I can only find the list above from the KDS V3 document.


You did some very good research and crosscorrelation, awesome!

TriB

I think you made a typo, you don't receive 01, 02 and 07 but 10 01, 10 02 and 15 07. These are your DTC(groups?).
No, I it was intended. I thought that these are two informations. The DTC and the according freezed frame.
But the number doesn´t match and as you´ve said, I´d have error 10 twice.
Makes it not easier to find the trouble code  :o

I had the same problem, error code 16 is not described in my manual. That's the reason why I think the two bytes represent one DTC. Otherwise you would not have the DTC 10 twice, but just once with an increased count rate for instance.

My DTC is 15 04 (HEX) = 21 04 (DEC), and the FI code I got was 31. I don't know how this is related though.
Hmm, the FI 31 is "Vehicle-down sensor malfunction, wiring open or short". We still need to sniff KDS :D
My DTC is empty now. So I can maybe manipulate something an see what happens.

I'm pretty sure PID 02 is the starter switch. I've logged it a couple of times, and sometimes I was lucky to capture the moment I pressed the starter switch and it turned from 0 to 1. PID 01 was always constant at 05 when I logged it.
Possible... I got the Starter on 02 at first, also! In the KDS V3.0 manual, there are some screenshots with live-data or a selection of all possible PID´s. Sadly only little parts :(
Our known PID´s have all been in the correct order...

That´s also where I got the specific malfunctions from:

(Page 57)
As you can see: Starter, Emergency Stop, All Sensors in correct order, Sensor Failures.

I hope I´ll get my bike back today or tomorrow. Then I´ll go on searching and try to manipulate something. Remove a fuse or a plug :D
Next week I´ll have some free time. My sketch gets more and more ugly, the more functionality I put into it! This should be rewritten and I want to add some features like "Pass through"-Mode which ignores my OBD compatible calculations. Or a "Constantly respond"-Mode to see if I can activate the transmissionMode to get sensordata periodically.

Scissor

#62
Jul 29, 2016, 12:12 pm Last Edit: Jul 29, 2016, 02:37 pm by Scissor
Maybe the two byte DTC response contains some kind of status byte. This is described to be contained in the response of 18 (readDiagnosticTroubleCodesByStatus). The status byte is just a bit encoded type of data where each bit represents a status of the DTC. For example, the first bit is "pendingFaultPresent", second bit "pendingFaultState" etc..

I also found that FI code 16 31 is the vehicle down sensor. It could be possible that the sensor malfunctioned in the past, and is not related to the 15 04 DTC I get. On the other hand it seems obvious that Kawasaki makes these FI codes as user friendly as possible, and just assigned a random number to the malfunctions. All the numbers seem to be not directly related which makes it hard to figure out what it means.

The numbers I have:

FI code: 31 (1F HEX)
DTC: 21 04 (15 04 HEX)
Local Id triggered: 50 and 86 (32 and 56 HEX)

I googled the Healtech OBD and on some of the images shown, the DTC consist of a 2 byte value:



The description given seems to match with the OBD DTC code http://www.obd-codes.com/p0115

If I google P2104 (my DTC in DEC) I mostly get DTCs for Ford cars related to the Throttle Actuator, similarly for P1504 (DTC in HEX) the result is a DTC related to the intake air system. I'm very confused. For now I'll just wait until I receive the KDS stuff which hopefully can shed light on the fault codes.

This morning I tried a few new requests:

- Periodic transmission by sending 10 82 (instead of 10 80 for a default diagnostic session), without luck. Got a negative response. Hence, periodic transmission is not supported for my bike.
- Transmission mode by sending 21 XX 04 LL, where XX is the localId, 04 Fast rate and LL the number of responses. Unfortunately this also gave a negative response.

It seems that many requests described in the ISO 14230 documents are not supported by my bike. So far the Service Ids that work are:

12
13
14 Probably works, but did not test yet as I would like to keep the stored DTC until I get the KDS stuff
1A

TriB

Nice idea to search for Healtech images, Sherlock :D

That´s a reasonable thought! All Error codes are describing the sensor plus it´s malfunction.
When I take a look into the Ford codes, there is no such combination. These are kind of running values (granted, but coherent).
I´d say:
  • You are right, it´s a DTC + Status (that´s why I got DTC 10 twice, because of different issue)
  • Read by status is seperated and the 13-response is just a unique 2 byte number

Should be possible to find out!

I also found that FI code 16 is the vehicle down sensor.
Typo? Its FI 31, as I wrote in the post before :D


I´ve questioned my Kawa dealer if he has some different codes. We´ll see!

There has to be a way to receive specific values, constantly. KDS has some functions, which suppose that! (Diagram, Actuator-Test and RealTimeMonitor for example)

Did you test some 1A ServiceID´s?

The working SID´s are (Just for completation):
10 Start Diagnostic Session
11 ECU Reset
12 Read Freeze Frame Data
13 Read Diagnostic Trouble Codes
14 Clear Diagnostic Information
1A Read Ecu Id
20 Stop Diagnostic Session
21 Read Data By Local Id
81 Start Communication
82 Stop Communication


I´m also really looking forward to your KDS system :D
Still need the drivers (KDS Adaptor.inf & KDS Adaptor.sys). Until I got then, I cannot even click somewhere within the software :-/

Got my bike back, yesterday. Quite expensive, but it rides like a new one  :smiley-lol:

TriB

Nice idea to search for Healtech images, Sherlock :D

That´s a reasonable thought! All Error codes are describing the sensor plus it´s malfunction.
When I take a look into the Ford codes, there is no such combination. These are kind of running values (granted, but coherent).
I´d say:
  • You are right, it´s a DTC + Status (that´s why I got DTC 10 twice, because of different issue)
  • Read by status is seperated and the 13-response is just a unique 2 byte number

Should be possible to find out!
Typo? Its FI 31, as I wrote in the post before :D


I´ve questioned my Kawa dealer if he has some different codes. We´ll see!

There has to be a way to receive specific values, constantly. KDS has some functions, which suppose that! (Diagram, Actuator-Test and RealTimeMonitor for example)

Did you test some 1A ServiceID´s?

The working SID´s are (Just for completation):
10 Start Diagnostic Session
11 ECU Reset
12 Read Freeze Frame Data
13 Read Diagnostic Trouble Codes
14 Clear Diagnostic Information
1A Read Ecu Id
20 Stop Diagnostic Session
21 Read Data By Local Id
81 Start Communication
82 Stop Communication


I´m also really looking forward to your KDS system :D
Still need the drivers (KDS Adaptor.inf & KDS Adaptor.sys). Until I got then, I cannot even click somewhere within the software :-/

Got my bike back, yesterday. Quite expensive, but it rides like a new one  :smiley-lol:
[EDIT]
Oh, boy! I´m through...
Just found a way to get all data from KDS. The most is described in japanese, but google translator is helping my out :D
"Bad" news, I´m going to be on vacation the next days  :o

Scissor

#65
Jul 29, 2016, 02:52 pm Last Edit: Jul 29, 2016, 03:05 pm by Scissor
It was a typo indeed, I got it mixed up in my head somehow. I tried all 1A 00-FF requests, and only got negative responses. Only without the additional parameter I can retrieve the ECU ID (21175-0016 in my case). Over here the weather is quite poor, so I did not even had the chance to test if my new rectifier can do it's job properly. Maybe I'll also try to pull some plugs to see if it's possible to trigger DTCs, that would be a nice and easy way to determine how the DTCs are formatted.

I agree with your list, even though I did not test all of them (11, 14, 20, 82). I suppose your bike might have an improved version of OBD with more features. Possibly you can achieve periodic transmission.

Another thing that might give us some more information is the magical 0xBF response I get. I've observed some pressures and voltages since they follow the same values and trend as other voltages in other PIDs. The very first few bytes are always constant at:

HEX:      43 32 33 31 4B 50 45 31
DEC:      67 50 51 49 75 80 69 49
ASCII:     C 2 3 1 K P E 1

I've googled quite a bit, but cant relate it to anything. I don't know if the ASCII values are actually meaningful, maybe they ring a bell at you?

Great that you got your bike back, have fun riding!

[EDIT]
Oh, boy! I´m through...
Just found a way to get all data from KDS. The most is described in japanese, but google translator is helping my out :D
"Bad" news, I´m going to be on vacation the next days  :o
What did you find?  :o  I can do some more digging if you like to share :) Where did you get the KDS software from in the first place? I cannot find it on the internet, you got a good relationship with your Kawasaki dealer? ;)

Scissor

#66
Aug 02, 2016, 06:43 pm Last Edit: Aug 02, 2016, 07:02 pm by Scissor
I've managed to log for a rather long time without restarts! Over nearly half an hour of logging is my best result so far. And I think it's nice to finally see some results instead of always talking about the details, since in the end most important for me is the datalogging itself.

Here I plotted the RPM and speed:





And of course it is always nice to see the correlation between these two:



Besides the RPM and speed I've logged 15 more PIDs (total of 17) at a rate of approximately 2.5 seconds (0.4 Hz) for all PIDs, such that the RPM and speed are also logged at about 0.4 Hz.

Another nice plot is the RPM vs. sub throttle voltage which shows linear behaviour:


Scissor

I wrote a simple piece of code in MATLAB to import the .csv logs. The .csv logs contain raw data i.e. just the received data bytes. In MATLAB I convert this raw data to the right unit and simply plot this. The result looks like this







I plan to add a few more features, such that the graph axis limits are set in the code. And to plot the data as a function of time. At this moment I always use the Total Operating Time as a clock for the logging. But for future use I intend to just use the arduino's internal clock, as this will improve the logging rate of course.


kamibutt

Dear Concern,

Can you please share the circuit diagram i want to make the circuit please help me.

Regards

aster94

#69
Dec 19, 2016, 04:45 am Last Edit: Dec 19, 2016, 12:09 pm by aster94
finally i get a l9637 and i m starting experimenting with it

the functions of kawaduino are nice but i am trying to make them more flexible, i found some errors and some not necessary code

since i have a suzuki (gsx-r 600 2011) i found some pids for my bike too:

Quote
Pos byte desc
 
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 <-- IAP1
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 <-- STP secondary throttle pos
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
so now (presuming they are right) i have the ecu addres and tester id
i will try to start the comunication as the kawasaki (quite the same except for the ecu addres), so i will use (correct me if i am wrong):
0x81, 0x12, 0xF1, 0x81, 0x5

hoping it will work, then i thought that if "4 61 Message type (Sensor data)" is the answer maybe 0x21 is the request

Trib and Scissor or whoever have studied more than me the iso14230 could answer me? i started only two days ago and it s almost 5 am (maybe this project is taking me too much sleep)

edit: trib how could i open your ecu emulator?

edit2: i add two more question if someone can answer me:
in the stop comunication when i send the request there isn't any confirmation from the ecu?
Code: [Select]

 // Stop Communication is a single byte "0x82" packet.
    format = 0x80;
    req[0] = 0x82;

    rLen = sendRequest(req, resp, 1, 3);

    //no "if" confirmation???


second question:
while receiving the response from the ecu in the case 2, what do you mean with " it came from us!" how is it possible?

Code: [Select]

case 2:
          // should be the sender address
          if (c == ECUaddr)
          {
            forMe = true;
          }
          else if (c == MyAddr)
          {
            forMe = false; // ignore the packet if it came from us!
          }

TriB

Hi aster94,

thanks for sharing your list of values!

You are right, kawaduino´s solution is not the very best in case of performance and error handling. Mine is also not as flexible as it should be.
I was working on a solution, which can easily be extended and reused for different bikes/manufacturers. But I´m stuck at the moment. Maybe I can finish it between Christmas and new year.


As far as I read, the Suzuki needs the following Message to retrieve response:
0x81, 0x12, 0xF1, 0x81, 0x5
So, you are right! At first, you need to initiate once:
Code: [Select]
digitalWrite (TX, HIGH);
digitalWrite(ledPin,HIGH);
delay(2000);
digitalWrite (TX, LOW);
delay(25);
digitalWrite (TX, HIGH);
delay(25);
Serial1.begin(10400);

They you have to send a request, at least every 2 seconds. Then you don´t need to re-initiate.

Kawa and Suzuki is quite different. Kawasaki has single requests. You are asking for RPM and receive only that single value. Suzuki gives you everything in one request.
So you don´t have to handle all the SID (ServiceID) & PID (ParameterID)-Stuff, we have to.

Just send the 0x81 with Header and Checksum and process the huge response.
I think it will be slow enough, that you don´t have to think about the timing ;)

The ECU Emulator is uncompiled C# code. You need Visual Studio to compile it. It is not a very common and secure way to distribute EXE-Files. But I can send it to you via PM (If you trust me ;) )

The Suzuki related stuff can be found here.

aster94

Hi aster94,

thanks for sharing your list of values!

You are right, kawaduino´s solution is not the very best in case of performance and error handling. Mine is also not as flexible as it should be.
I was working on a solution, which can easily be extended and reused for different bikes/manufacturers. But I´m stuck at the moment. Maybe I can finish it between Christmas and new year.


As far as I read, the Suzuki needs the following Message to retrieve response:
0x81, 0x12, 0xF1, 0x81, 0x5
So, you are right! At first, you need to initiate once:
Code: [Select]
digitalWrite (TX, HIGH);
digitalWrite(ledPin,HIGH);
delay(2000);
digitalWrite (TX, LOW);
delay(25);
digitalWrite (TX, HIGH);
delay(25);
Serial1.begin(10400);

They you have to send a request, at least every 2 seconds. Then you don´t need to re-initiate.

Kawa and Suzuki is quite different. Kawasaki has single requests. You are asking for RPM and receive only that single value. Suzuki gives you everything in one request.
So you don´t have to handle all the SID (ServiceID) & PID (ParameterID)-Stuff, we have to.

Just send the 0x81 with Header and Checksum and process the huge response.
I think it will be slow enough, that you don´t have to think about the timing ;)

The ECU Emulator is uncompiled C# code. You need Visual Studio to compile it. It is not a very common and secure way to distribute EXE-Files. But I can send it to you via PM (If you trust me ;) )

The Suzuki related stuff can be found here.
well i didn't know that suzuki just needed only a request i will try cyclegadget's suggestions

i am sending you my modified version of kawaduino code, now it has error handling, debugging mode, renamed values, rewrote some part of the code, and I made big comments. I hope you will use it (change the ecu addres)



by the

TriB

Some small things, I´ve seen at the first sight.

You should increase the buffer:
Code: [Select]
uint8_t outBuf[16], inBuf[16];    //buffer to hold the incoming/outgoing bytes
AFAIK 61 bytes will come back (including header + checksum).

The delay can be optimized, by using the last received millis:
Code: [Select]

uint32_t lastKlineResponse;

  //wait until last request is older then ISORequestDelay
  if(millis() - lastKlineResponse < ISORequestDelay)
  {
    uint32_t waitIsoDelay = millis() - lastKlineResponse;
    if(ISORequestDelay - waitIsoDelay > 0)
      delay(ISORequestDelay - waitIsoDelay);
  }


Remove the delay at "Serial.Read". If there is data, read it!

The translation-stuff at the end was to use ELM327 commands, which our bikes don´t understand. According to your use-case you can completely ignore it.

aster94

Yep i wrote it before discovering that suzuki sent 61 bytes. At the end i m writing some new function not using arrays to store the values and i ordered an arduino mega to have a better understanding about what there is happening there

You are right about the delay during the reading but i found it in kawaduino's code so i thought it was important. The flexible isorequestbyte delay using millis is nice, well done

I still need to figure out how to discover the pids that i miss and other important request for example "send errors codes" and "stop comunication" any idea how to discover them?

alexsoletti

Hi, did you guys managed to understand the DTC codes?
Mine replies with this:

(2016-12-22) (01:16:00.823) (COM3) 1301
(2016-12-22) (01:16:00.926) (COM3) 80 F1 11 0E 53 06 01 10 01 15 01 20 11 01 11 04 15 04 71
(2016-12-22) (01:16:00.983) (COM3)
(2016-12-22) (01:16:00.983) (COM3) >
(2016-12-22) (01:16:02.323) (COM3) 1302
(2016-12-22) (01:16:02.413) (COM3) 80 F1 11 0E 53 06 01 10 01 15 01 20 11 01 11 04 15 04 71
(2016-12-22) (01:16:02.504) (COM3)
(2016-12-22) (01:16:02.504) (COM3) >

Note: Im using STN1110 to communicate with ECU, and my ECU is on my bench. Im not testing in the bike!!

Note2: Great development here.. I'll share mine once I finish drawing/testing my board and do some real testing.

Note3: Does anyone have any idea if we can read ECU Flash memory? So we could program the ecu with new fuel maps, change KTRC values.., etc..

Regards,
Alex

Go Up