Arduino Forum

Topics => Device Hacking => Topic started by: TriB on Jul 08, 2015, 03:54 pm

Title: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 08, 2015, 03:54 pm
Hello,

I´d like to receive diagnostic data from my motorcycle (Kawasaki Z750r - 2012).
The first challenge is, that against all cars and trucks, the diagnostic interface is not standardized on two wheels.
Neither the plug, nor the communication.

That´s why I cannot use a cheap (china) OBD II to Bluetooth adapter.

I´m familiar how to communicate via K-LINE of KDS Bus, from here (http://ecuhacking.activeboard.com/t56234221/kds-protocol/?page=1&sort=oldestFirst). In my case KWP2000 (ISO-14230).

What I´d like to do:
Contrary the most solutions here (https://www.google.de/search?ie=UTF-8&oe=UTF-8&q=bike+obd&btnG=search&domains=http://forum.arduino.cc&sitesearch=http://forum.arduino.cc&safe=active&gws_rd=cr,ssl&ei=siWdVaPoMoWvUc-wg8AL) (or the most famous OBDuino (https://en.wikipedia.org/wiki/OBDuino)), I want to pass the data via Bluetooth, not receiving it.
My receiver is a Gamin Virb XE (http://virb.garmin.com/en-US/virb-xe) Action-Cam. It stores the information according to a video, and display them later on, as some nice gauges.

Step two will be an additional, small display to show current gear and some infos, at present I don´t know :)


Background:
The Virb XE action cam already has GPS, gyro sensors and stores the data onto a microSD card.
It comes with a OBD 2 compatible bluetooth connection.
Thats why I am searching for a lightweight solution.

There are lots of (more or less) expensive OBD Boards. But none of them fulfilled my wishes.

What do I have:


What do I need:


Questions:

Which board would you suggest?
The space blow my seat is really restricted. It should be powerful enough to transmit several information at once. In the best case, it already has Bluetooth.
Will it work with the L9637D?
The description says it can handle ISO 9141 and I need 14230.
How to submit the signal to the receiver? It seems that the Virb XE uses the same protocol (ELM327 (https://en.wikipedia.org/wiki/ELM327)) as the OBD II Bluetooth adapters are using. Also the famous Torque App (https://play.google.com/store/apps/details?id=org.prowl.torque&hl=de) communicates by that. Maybe someone has already forwarded diagnostic data.

Maybe you´ve got any further suggestions or Ideas.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 22, 2015, 02:31 pm
A small update:

The partially above mentioned items (E-L9637D & Virb XE-Camera) arrived. Also some wires, 12V switch, SOIC Board (to solder Lxxx SMD on it), ect.

And I just bought some stuff to finally begin with the project.


At first I wanted to start with my old UNO, but to implement the bluetooth part, its necessary to have a BT device :)

My next steps will be (dependent on what arrives first):


*My most influential Tutorials:
KDS Protocol Kawasaki (http://ecuhacking.activeboard.com/t56234221/kds-protocol/?page=1&sort=oldestFirst)
KawaDuino (https://bitbucket.org/tomnz/kawaduino/overview)
OBD 2 LCD Sketch (https://github.com/Magister54/opengauge/blob/master/obduino/obduino.pde)
ELM327 Commands PDF (http://www.elmelectronics.com/ELM327/AT_Commands.pdf)
OBDuino Wiki (https://en.wikipedia.org/wiki/OBDuino)
OBD Explaination (German) (http://www.blafusel.de/obd/smd_adapter.html)
LCD wiring (https://learn.adafruit.com/character-lcds/wiring-a-character-lcd)
Getting started with Blend Micro (http://redbearlab.com/getting-started-blendmicro/)

That´s pretty much everything I/you need and a bit more :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Nov 04, 2015, 01:51 pm
A huge update:

It´s nearly done! There´ve been several challenges, but it finally works :)

Hardware:

Also several different displays, to test. At least I´ve ordered a 128x64 OLED from AdaFruit 0,98".

There are a lot of wiring schematics around. But it´s only important to connect Rx to Rx and Tx to Tx (not twisted!) and use a pullup-resistor to the K-Line (connect K-line with VIN from diagnostic by ~510-550Ohm)
Important: Unconnect Rx if you want to upload your Sketch!


Software:
This has to be splitted into several smaller pieces of work.

AT-Commands
OBD II compatible Bluetooth dongles all work with a ELM327 chip (or a china-clone).
This adapters are used by AT-Commands, which setup the communication protocol. Afterwards the Protocol ID´s were submitted in Hex-values as text.

The cmd´s begin with "AT" + command [+ Value] + '\r'

ATL0\r - means tunrning Linefeed (\n - 10) off (That does NOT mean, turn CarriageRetrurn | \r - 13 off)!
You have to return: OK\r>\r
The > is a prompt, which completes a command-set. Exceptions where: Unknown Cmds ? or Device Info.
Important for my Action Cam: The answer to ATZ (Reset) must contain the Version. F.e. "ELM327 v1.4". Otherwise the cam will not proceed.

DSet to default (Header = false, spaces = false, ect)
ZReset Device
H0 / 1turn Header on or off
IDevice Info (ELM Version)
SPProtocol Auto
S0 / 1turn spaces on or off
L0 / 1turn linefeed on or off
E0 / 1turn Echo on or off
M0 / 1use memory (store last CMD)


PID Lists:
There are every 32 bits lists of the following 32 specified bits:

RequestResponse
01004100181B8001
0102412000000001
0104414008000000
0106416000000000
0108418000000000


The response is not completed with OK. Only newline and Prompt (>)!
What does it mean?
Take all PID´s from 01 - 20 (32pcs). 00 is reserved for the first PID-List, 20 is the next one.
Now convert the response from 00-request to bits:

181B8001 (ignore 41 [Response is valid] and 00 [Request])
00000100000011000000

Now you can lay it over your PID-list and see which PID is valid 1 or not supported 0.

My personal challenge was to translate the OBD2 PID´s to the appropriate KDS PID (Kawasaki Diagnostic System). And afterwards to calculate the response to the required format.

Sending Data:
Now you will receive the register and can put the answer through. (Torque-App will ignore the valid PID´s and you will have to return "NO DATA", Garmin Virb-Cam suits to the valid values)
01 (Show current data) + 0C (PID) + \r [sometimes a space only. Don´t really know why]
Remember to answer properly:
41XXYY\r>\r
XX-Requested PID, YY-Value (can also be longer)

ECU-Communication:
Now one of the most interesting part!
I´ve made usage of a code from Tom Mitchell (Kawaduino)
You can get it from BitBucket (https://bitbucket.org/tomnz/kawaduino) and see the result on YouTube (https://www.youtube.com/watch?v=ie-Pfxzt-yQ).

The most important parts are the FastInit()-Function to start communication and diagnostic mode.
And the sendRequest()-Method to create & send the request and receive the response, unpack it and check the checksum.

Conclusion:
It was a hard way to get the hardware work (wrong Bluetooth-module, broken E-L9637D, Pulldown instead of Pullup resistor...).
The software was also very time consuming. To check the Arduino Sketch, I created a ECU-Emulator in C#. It answers requests with configurable responses.
Then I created a Bluetooth-Sniffer to receive what kind of information the Camera or Torque-App requests and how I have to respond.
At least I made a ECU-Sniffer, which requests all supported PIDs from my motorcycle.

When it all worked, the next task was to find out which PID correspond to which sensor. The ECU-Hacking Board (link in my second post) just got knowledge of Speed, RPM, Temp, Battery  and Gear. By try and error and some help from a guy with a diagnostic device, I was able to find out about 33 known PIDs. Another 27 are still open.

My further investigations are to find out some calculations, how to use throttle or throttle valve.
After that, I´d like to upload all my code to GitHub. Including:


As you can see in the attached pictures:

The finished Arduino Nano:
(http://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=142579)
Test on my bike:
(http://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=142581)
ECU-Emulator with Ardu connected:
(http://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=142583)
My first ride :)
(http://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=142585)
(Garmin Virb XE Action-Cam)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Nov 07, 2015, 07:54 pm
It still is not ready, but working.
Who ever is interested can find the code here:

GitHub - KDS 2 Bluetooth (https://github.com/HerrRiebmann/KDS2Bluetooth)

Including my working solution, a .Net ECU Emulator and a Bluetooth-Sniffer to identify the AT Commands.

I´m sure it can be optimized a lot. If you got some hints, please let me know :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: felixi on Nov 23, 2015, 10:04 pm
Good job! :smiley-cool:
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: penny50514 on Apr 12, 2016, 11:50 am
It still is not ready, but working.
Who ever is interested can find the code here:

GitHub - KDS 2 Bluetooth (https://github.com/HerrRiebmann/KDS2Bluetooth)

Including my working solution, a .Net ECU Emulator and a Bluetooth-Sniffer to identify the AT Commands.

I´m sure it can be optimized a lot. If you got some hints, please let me know :)
AMAZING!! You just did what I've been preparing to do on my Z800 :)

Thanks for sharing the information, it helps a lot a lot a lot.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on May 12, 2016, 11:06 am
You are welcome!

The final result looks like that:
http://www.youtube.com/watch?v=MKdlcnXseew (http://www.youtube.com/watch?v=MKdlcnXseew)

I´ve adopted the idea of combining that with a display. It would be way to slow.
Maybe it will be another project :)
There are some possibilities to read the value directly from the tachometer (CAN-Bus).
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: rmachiavel on Jun 21, 2016, 04:53 pm
You are welcome!

The final result looks like that:
http://www.youtube.com/watch?v=MKdlcnXseew (http://www.youtube.com/watch?v=MKdlcnXseew)

I´ve adopted the idea of combining that with a display. It would be way to slow.
Maybe it will be another project :)
There are some possibilities to read the value directly from the tachometer (CAN-Bus).
Good job!!! Thanks for shared information!!!

Sorry but I'am noob about this type of comunications.

Knowing all of it, there is a possibility to configure an ELM327 interface to conect directly to ECU, I have tried, but with no success!

Thanks again!!!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 22, 2016, 10:05 am
Hi rmachiavel,

no I dont think that´s possible. An ELM327 is created for an OBD II Interface, which bikes don´t have.
The communication of OBD is made by two wires (Serial), f.e. KDS has one wire (K-Line). The ELM has also a K-Line, but as fas as I know only for manufacturer specific things. Not Diagnostic.
It has a specific initialization procedure and an own set of Service ID´s. An example: Read current Data: OBD 01, KDS 21.
On the top of it, the PID´s which are requesting the specific values, are completely different. RPM 0C in OBD and 09 in KDS. Also the response has a different length and calculation.

So you´d need a L9637D-Chip to change Serial to K-Line. Then you have to find out how to change the Init-Sequence to wakeup the ECU (ELM do not have KWP2000 (ISO-14230), its a gambling to find a similar one). The device, which is connected to the ELM327 has to translate all ServiceID´s and PID´s. The calculations are different, so this has to be fixed also.
Last but not least, the PID-Lists have to be manipulated to the translated ones.
That means (if the init works) you have to write a software from the scratch to communicate with the ELM327 and fake & translate all that values.

All of that is done by my project, pretending to be a real ELM327.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: rmachiavel on Jun 23, 2016, 03:54 am
Thanks a lot!!!!

Saved me a lot of time! I´ve have tried a lot with ELM327, because I can´t find the L9637 in Brazil and the ELM have a interface that seems to be similar, but is not. So I bought the IC from ebay yesterday, so I will wait it arrive to continue with project. Thanks again!!!

Best Regards!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Budvar10 on Jun 23, 2016, 07:58 am
Great. I can't believe that I miss this topic up to now. Have a karma. +1
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 29, 2016, 03:52 pm
I´ve updated the code on GitHub (https://github.com/HerrRiebmann/KDS2Bluetooth/tree/master/ECU_Reader).
There have been some precision problems, which are solved now.
Also as announced, I removed the LCD part.
Some AT-Commands where added to fit to more OBD-Apps.

Then I began to "Sniff" some diagnostic stuff like Error-Codes and how to clear them. But currently I´m in the middle of investigating and testing it. It will take some more time.

During that, I came to a big limitation of sending and receiving messages. Everything was created for a specific Mode and ServiceId. So I started to rewrite that also.
KWP2000 is a precursor of Unified Diagnostic Services (https://en.wikipedia.org/wiki/Unified_Diagnostic_Services), which helps what is possible and which ServiceID´s are available.

The whole code will be rewritten more clean and flexible, then.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 05, 2016, 02:01 pm
I've also been busy to connect an Arduino to my motorcycle (Kawasaki Z750 2004), I'd like to thank you a lot for your effort. Especially determining the conversion formulas to get actual engineering units is really useful. I put together this basic library for the KDS serial communication which you can find on my Github (https://github.com/Eztys/SimpleKDS), which you might find useful.

Did you try to request localidentifier 0xBF? I get a large response message of 72 bytes (including headers and checksum), which might contain interesting data.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 05, 2016, 04:04 pm
Hi Scissor,
you are welcome! I´m glad to find more and more combatants.
The list of known PID´s is far from being complete, maybe we will get further with some people :)

Many PID´s base on try & error, some where collated with a 3rd-party diagnostic device. Hard enough to calculate the values to a meaningful result, even harder to make it OBD II understandable :D

I´ve not investigated 0xBF. Is it officially supported by '04 Z? As you can see in my Excel-Sheet (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/OBD%20II%20PIDs.xlsx), its not part of my PID-List.
There are diagnostic functions, which are sending more frames at once (f.e. freezed data) or constantly (for exhaust testing purposes). I´ll try that, after I raised my buffer to such a huge value :-O

If you´d like to, run my SniffEcu()-Method and send me your results, we will have '04 Z750, '12 Z750r & '14 Z1000 results.

There are many things to investigate. Likewise ECU-ID, which is 1A without a ServiceID. I´m sure, there is a lot more! Currently I search for trouble-codes SID 0x13 and freezed Data SID 0x12. Not very easy without a failure ;)

You are theoretically able to down- and upload even the ECU firmware :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 05, 2016, 05:03 pm
Thank you. I understand it's difficult to obtain those conversion formulas, I guess they're mostly similar to the formulas for the Suzuki Diagnostic System (SDS). Unfortunately only very few are made public so far.

I made a simple datalogger which I used to find available PIDs (I call them localidentifiers, as in the ISO documents). So far I ran the datalogger from localidentifier 0x00 to 0xFF. I've listed the results in an excel file and it looks very similar to your results, I will post them here shortly.

One remarkable thing is that localidentifier 0xDB does not return anything, not even a negative response message. From the ISO-14230 documents:

Quote
0x00 - reservedByDocument
0x01 - localIdentifierScalingTable
0x02-0xEF - localIdentifier
0xF0-0xF9 - dynamicallyDefinedLocalIdentifier
0xFA-0xFE - systemSupplierSpecific
0xFF - reservedByDocument
Hence I expect that the most standard sensor data should be in the 0x02-0xEF range. Unfortunately the 0x01 request does not return the scaling table which would reveal all conversion formulas.

In your excel sheet you mention "Supported PIDs" several times. I don't really understand how you obtain the available localIdentifiers based on that response message. At first I thought it just might be a bitmask i.e. convert the HEX values to bits, and assume every "1" corresponds to an available localIdentifier. However this does not correspond to the results I get.

There are many more things we might try e.g. periodic transmission and  dynamicallyDefinedLocalIdentifier to construct a localIdentifier, with this a much higher data rate could possibly be reached.

I also tried once to request all DTCs, but without luck. I might have done something wrong, so I can try again soon.

Indeed, at some point we can decide to use the upload and download functions described in the ISO-14230 document. However, I expect it is a rather delicate process which can easily screw up the ECU if something fails during data transmission.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 05, 2016, 08:36 pm
Attached are the two excel sheets containing the data from a few minutes of datalogging. The datalogger is capable of logging at approximately 7 Hz to a microSD card, which could be increased by fine tuning the serial communication timing parameters.  

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 06, 2016, 10:10 am
Thank you very much for your data! I will include it into my document.

In your excel sheet you mention "Supported PIDs" several times. I don't really understand how you obtain the available localIdentifiers based on that response message. At first I thought it just might be a bitmask i.e. convert the HEX values to bits, and assume every "1" corresponds to an available localIdentifier. However this does not correspond to the results I get.
It is exactly working like that!
You will receive a PID-List on

00 gives me Hex: DF F7 87 87
Which is in Binary: 1101 1111 1111 0111 1000 0111 1000 0111
Now you can overlay the binary to PID 1-32.
0x01 supported
0x02 supported
0x03 unsupported
0x04 supported
...

That´s what my sniffer-functionality does:
Code: [Select]

const uint8_t pidList[] = { 0x00, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, 0xE0};
const uint8_t pidListCount = (uint8_t)(sizeof(pidList));
void SniffEcu()
{
  //Get first PID List
  SniffCommand(pidList[0]);
 
  for (int i = 0; i < pidListCount; i++)
  {   
    //Copy Array  from last PID List before it will be overwritten:
    uint8_t ecuResponseCopy[7];
    memcpy(ecuResponseCopy, ecuResponse, 7);       
    //Result: PID List
    //80 F1 11 06 61 00 DF F7 87 87 CD
    //                  DF F7 87 87
    //0000 0000 0000 0000 0000 0000 0000 0000
    //01 02 XX 04 05 06 07 08 09...
    //For each Hex value in ECUresponse (4 bytes, without checksum)
    for (uint8_t j = 2; j < 6; j++)
    {
      byte bin = ecuResponseCopy[j];
      //0x80 = 1000 0000 | Shift 1 to the right
      for (int mask=0x80; mask != 0; mask >>= 1)
      {       
        if (bin & mask)           
           SniffCommand(lastPID);         
         lastPID++;
      }       
    }
  }
}


KWP2000 / ISO-14230 is a previous version of Unified Diagnostic Service (https://en.wikipedia.org/wiki/Unified_Diagnostic_Services), which gives you a small impression of what is possible.
As you an see there, it is not possible to upload the FW without a special token from Kawasaki. But there is enough to mess up :D So stay careful :)

7Hz is very good! Due to the BT connection, slow Serial2 and my bad code, mine is about ~4-5.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 06, 2016, 06:54 pm
Using the bitmask method to find supported localIdentifiers does give some strange results. Whenever the bitmask is "1", the response method is not always positive, many general reject messages (0x7F 0x21 0x10) are given as well. You have got the same result in your excel sheet. Is it related to secured registers? Also the 0xBF seems not to be supported, yet I get a very long response message which at this point appears to be related to pressure measurements.

Soon I will take the motorcycle for a ride while datalogging. Do you know if it's safe to log at a high rate? I can imagine the ECU will spend most time controlling the ignition especially at high RPM, additional serial communication might block functions which could result in strange behaviour.

Edit: In the mean time I did a little calculation on the speed of the communication. From the ISO-14230 documents the minimum timing parameters are given as:

Inter byte time ECU response: 0 ms
Request-response delay: 25 ms
Response-request delay: 55 ms
Inter byte time request: 5 ms

Using these parameters in combination with a baudrate of 10400 bits/s = 1300 bytes/s, the resulting maximum request-response rate is about 7.8 Hz (assuming a request of 7 bytes and a response of 9 bytes) and a data rate of approximately 125 bytes/s. This is very close to my datalogging rate at approximately 116 bytes/s (3138 bytes in about 27 seconds). Note that over 50% of the time the response-request and request-response delay are active.

Sending one byte in a request takes at least 5.8 ms (5 ms delay + 0.8 ms due to the baudrate), whereas the response byte can be send in just 0.8 ms. Therefore to achieve very high data rate we should try to use periodic transmission (send 80 11 F1 02 10 82 (instead of 80 for regular diagnostic session) 16). In this case, the rate increases to rougly 16 response messages per second. Additionally we can try to see if it's possible to reduce the Response-request delay and the inter byte time for requests in order to obtain higher datalogging speed.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 07, 2016, 12:01 pm
The bitmask is fine. But some values like Injector timing, CO² Adjust timing, ect. are only working during a diagnostic session. It has to be initialized separately (somehow).
I don´t expect it is related to a security layer. There are testing scenarios for exhaust or injection, which can be run and I´d expect they will activate these sensors.

The PID´s are valid globally. Some are available during current data 0x21, some by freezed data 0x12, some maybe only on testing purpose. If you take a look into the KDS3.0 Documentation (http://www.ca-mc.dk/files/pdf/pdf/kds3_manual_final_lr1.pdf)(from page 21 on), you will see what is possible with the ECU.

0xBF is really curious! Can´t explain it right now. But due to it´s "hidden" location way at the end, it will be a undocumented testing feature, I guess.

Yes, you are safe! You cannot break anything. The diagnostic is on a very low layer. If you are to fast, it will just cut off the connection and that´s it.
It is not possible to use important capacity or block anything, everything is separated. That´s how a BUS works :)

Thanks, the timing calculations are very interesting! Currently I´m waiting 10ms between every byte. I´ll try to change that to 5. But I´m still limited by my Bluetooth communication :( I´m sure I can delete my request delay, because it´s already taken by BT! (I should measure that somehow)

The ISO Documentation also says how to manipulate these timings :D

Response Timing works similar to that, but with SID 0xC3.

My goal was to make OBD II dongle compatible devices/apps work with my bike. So I will always loose time by converting requests, calculating values and converting responses.
Raising from ~4 to 5 or 6 messages per second would be amazing!

Right now I am designing a more straight sketch to be flexible with different SID´s and response/request length. Not very easy, because I need to convert, fake and redirect requests. Also constantly receiving?  :o
A challenge!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 07, 2016, 01:13 pm
Thanks for your response! Maybe we can try to start a diagnostic session by sending 0x81 instead of 0x80 after the start communication request. If this works we might have access to the non functioning registers.

You should take a look at the library I wrote. It contains very simple functions to send and receive messages. I posted the link to my Github on the previous page.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 07, 2016, 05:21 pm
Off course I took a look into your GitHub, as you responded to this thread :D
And I like the idea of not waiting for data responses with a delay. Simple wait for Serial.available() or timeout.

Reduced ISORequestByteDelay from 10 to 5.
Then removed all delays according to the receiver -> We will see if the ECU simply responds as fast as it can or stops due to ISO protocol breach...

The last thing, was to change the static delay between the messages to a dynamic value.
I´m storing the last K-Line Response milis and simply calc the time left:
Code: [Select]
delay(ISORequestDelay - millis() - lastKresponse);
My Emulator counts up to 10(!!!) messages per second, even via bluetooth! Sure, my PC is to fast and I should implement the byte & request delay there as well!

Can´t wait to test that on my bike! Sure, it will slow down to 6-7 responses a second. But that´s great!


0x81 is just a different format with no length information, because messages can only be 1 byte long.
There are two more formats without any source and target information but it seems they are not supported. After fast Init, we receive 0xEA + 0x8F as response. That describes:
Header with Target & Source Information. Additional Length. Normal Timing.
ISO14230 / KWP2000 Protocol (http://read.pudn.com/downloads118/ebook/500929/14230-2.pdf).
The more often I read these documents, the more I understand what´s going on there ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 07, 2016, 06:05 pm
Alright that sounds good! I just tested my datalogger with the inter byte request time delay of 0 ms instead of 5 ms, and it just worked fine, although the data rate did not increase much.

What I actually meant with sending 0x81 instead of 0x80 is this:
To establish communication you send:

Start communication:     81 11 F1 81 04
Start diagnostic session: 80 11 F1 02 10 80 14

According to the KWP2000 documents the available parameters for the start diagnostic request are:

...
0x80: ReservedByDocument
0x81: StandardSession
...

Hence I figured it might help to send 0x81 instead of 0x80 to get positive responses from the currently blocked PIDs. However I just gave it a try and communication could not be established. So probably for the KDS protocol the 0x80 parameter requests already a standard diagnostic session.

Furthermore I tried to requests localIdentifiers from 0x0 to 0xFF, and observed that no positive response were given after 0x62 except for the "Supported PIDs" and the long 0xBF message.



Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 08, 2016, 12:44 am
It really works! My Sniffer is amazingly fast  :o
Nearly doubled my requests from 4 to 7, sometimes 8 per Sec (Maybe rounded).

Good to know, that it doesn´t work. But somehow like that, it should change the mode. We will go on investigating :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 08, 2016, 08:52 am
That's really good performance, good job! Today I'll try to adjust the timing paramerers. However I first have to do some reading because the timing paramers need to meet certain conditions.

Are there any other interesting requests I can send? Did you ever figure out how to control certain actuators? Btw, do you have access to actual KDS software?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 08, 2016, 10:11 am
Today I'll try to adjust the timing paramerers. However I first have to do some reading because the timing paramers need to meet certain conditions.
Spare your time...
Out: 83 02
In:   7F 83 10
0x7F is a negative Response Message. Maybe it is related to the result of the init-sequence, which I explored 4 posts above. It just says "Normal Timing". Probably it also means "not editable"?!?

Are there any other interesting requests I can send? Did you ever figure out how to control certain actuators? Btw, do you have access to actual KDS software?
I´m still investigating the diagnostic fault codes but didn´t get further...
ClearDiag: SID 0x14 PID 0x01.
Read Freezed Data Frame:
Out: 12 01 01
In:   52 01 15 07 01 54

Out: 12 02 01
In:   52 02 10 02 01 54

Out: 12 03 01
In:   52 03 10 01 01 54
It does not fit to any known results in the Z750 diagnostic schema.

No, I have not access to KDS Diag. software :( that would make my life a lot easier! You could sniff the data which is being transferred to the COM-Port and all that guessing, try and error would be unnecessary.
[EDIT] Got it. But you cannot install it, without the specific driver. I´m not sure if I can find them and make my device compatible with that driver. Or rewrite the driver...
[EDIT 2] I could extract the Installer and got access to the executable. It starts but (understandable) could not find a connection. I´ll try to fake the driver somehow and see if I could make it work. This will solve all our problems and answer any question :D

Two things I found out yesterday:
The throttle maximum value is getting bigger and bigger. Started with 405 and currently I´m on 455.
It means, that I will not reach 100% again on full-throttle (works also with engine turned off).
Maybe I will stop storing it onto the EEPROM and adjust it on time.

And I got a little setback, also on throttle valve. In the past I could not see it, because of the slow reaction time.
Turning the gas tap slowly, it raises 5%, 10%, 15%, then it drops to 5% again and went on with 20% and upwards.
Maybe you can keep an eye on that. I don´t know what to change on my calculation...

Code: [Select]
     //201 = 0% = idle, 405 = 100%
      minimum = 201;
     
      value = ecuResponse[2] * 100 + ecuResponse[3];
           
      if(value > ThrottlePosMax)
      {
        ThrottlePosMax = value;
        EEPROM.write(0, ThrottlePosMax - 255);       
      }     
      //((Value-Minimum) *100) / (Maximum - Minimum) = %     
      //OBD II Calculation: (100/255) * A [Backwards]: 100% = 255
      if(value > minimum)       
        ecuResponse[2] = ((value-minimum) *100) / (ThrottlePosMax - minimum) * 255/100;
      else
        ecuResponse[2] = 0x00;
      //Reduce 2 byte answer to 1 byte:     
      ecuResponse[3] = 0x00;
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 08, 2016, 11:16 am
That's a shame that it's not a supported function. Nevertheless I'm going to give it a try, you never know! :)

Why don't you try to send 12 00 00 (Requests all data, according to chapter 8.4.1 of ISO-14230-3)? I did not read too much about decoding the DTC response message, but I'll take a look at it soon.

Regarding the KDS software, maybe you could take a look at the files with a hex editor to extract some useful data. Or it would be nice if there were some kind of database files which already contain many possible requests.

I still don't really understand the TPS as two bytes are returned (right?) however the TPS would just give a voltage between 0 and 5 V, such that 1 byte would be sufficient to describe the TPS reading. Anyway, I can imagine the sensor is subjected to noise and interference, such that sometimes you get spikes in the signal. I think it could work to incorporate either some kind of thresholding or a running average to minimize the effect of spikes.

Edit: I managed to get the timing down to 0 ms inter byte request delay instead of 5 ms, and 49 ms between a response-request delay instead of 55 ms. Probably the arduino takes 6 ms to execute the code such that overall the delay equals 55 ms. This implies that the maximum working delay is code specific i.e. you need to figure it out for your self. When I got below 49 ms the ECU did not respond to the request.

Edit2: I also got a general reject message when requesting the 0x83 serviceId to read the timing parameters.

Edit3: I tried to use ReadDataByCommonIdentifier (0x22 instead of 0x21 for localIdentifier), but I only got general rejects (7F 22 10) on all parameters I tried. Probably no data is stored in these registers for the '04 Z750.

Edit4: It looks like your DTC readFreezeFrame request is missing a byte.

12 = readFreezeFrameData
01 = freezeFrameNumber
01 = recordAccessMethodId=requestByLocalId
xx = recordIdentification

Seems like you are missing the last byte, of which the possible values are given in table 8.4.6.1 of the ISO-14230-3 document. If you want to request all data from a single freezeframe number send: 12 NN 00, where NN is the freezeFrameNumber of your choice. And even better if you send 12 FF 00, this would send all the data from all freezeFrameNumbers in several response messages. I'm curious if this trick works for you!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 11, 2016, 09:22 am
Searching goes on: Just found another PDF (http://documents.mx/documents/kw2000-supported-services.html), which seems like a combination of ISO-14230-1,2,3&4 documents.
There are SID´s below 10  explained :o
Like Powertrain diagnostic data 0x01, which for sure will contain the injector and ignition data.
Or Emission related data 0x03 for CO2 purpose.

We are starting the Diagnostic mode the "regular" way. By changing the SID, it should be possible also to manipulate values.

Constantly receiving data should be possible by adding parameters:
0x21, 0x0C, [0x00-0x04], [0xXX]
SID, Speed, Transmission Mode (single, slow, medium, fast, stop), Maximum number of responses

I tried to send 12 00 00 before your edit. Now it´s clear why it didn´t worked!
My ISO Document has only 8.4.4 as maximum 8th chapter... I´ll investigate!
My working solution was 12 X 01 54, where X is my counter. But I don´t understand the Answer.
Also I don´t know PID 54, but the healtech software asks that from startup.
On 0x21 it responds with 0 all the time.
There is a lot of black magic going on there ;)

The KDS Software is compiled in C, there is no way to look into it. But there is a KDSAdapter.dll which might be rewritten and connect to my device. The hope dies last, but I don´t expect to make it work.


Yes, you are right. It must be a value related to the current (operating) voltage. That will explain the different max values. But not the spikes :( I´ll keep an eye on that!
Most sensors are already calculated by the ECU due to the voltage oscillation.
=> After some testing, it has a really strange behaviour. Every 20% it breaks down to 0% very crazy... I have to analyse that.

Nice to know how fast you got it! I am calculating the delay every request. So the time, the code consumes should be irrelevant.
49ms + 6 for your code... I think I´ll stay on 55 :)

The next days I´ll be on a racetrack and go on testing!

[EDIT]: TPS seems like it is calculated different to all the other 2byte values...
Speed and RPM: A * 100 + B.
My only explanation for dropping values is: A * 255 + B. Every time I am passing the 255 mark, it calculates 155 less. That´s why it is dropping lower again.
That´s very bad, because I have to change my min & max calculation and the max-data storage... Both is at not suitable for values greater then 509, at the moment :(
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 11, 2016, 10:46 pm
There appear to be a bunch of documents about the KWP 2000 protocol, but I doubt if all are relevant. Nevertheless we can always try to see if some function works of course!  :)

If I understand you correctly, you send 12 00 00 54? Does the response also have 54 as last byte? Or did you make a typo? Do you have the healtech OBD software? If so, why don't you try to use your sniffer to reveal all the requests?

Regarding the TPS value, I see the same thing happening. I think it simply means that the value is a 16 bit integer e.g. a range of 0-65535. Now all we need to do is normalize it to fit the engineering unit.

TPS = ((256*A+B) / (256*256) )* C

Where C is the constant we are looking for. According to my Z750 manual:

0.99 ∼ 1.03 V DC (at idle throttle opening)
4.19 ∼ 4.39 V DC (at full throttle opening)

The minimal value I get is 213 (0x0 0xD5) and at full open in the range of 871 (0x03 0x67). What first comes to mind is a simple factor of 5 (C = 5*256*256, resulting in simply the 16 bit integer value mulitplied by 5). This yields: 0% open: 1065 mV and 100% 4355 mV. I cannot guarantee this is correct, as I did not check the 100% throttle output properly. Does this fit your readings?
In any case, I'm pretty sure you don't need to update your extreme TPS values during each run, as the output will always be between 0-5V. You could always do some post processing to get a value between 0 and 100%.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 12, 2016, 01:25 pm
Yes, I was sending 12 00 00 54 which does not work. But call DTC group 01 is okay:

To ECU: 12 01 01 54
FrmECU: 52 01 15 07 01 54
To ECU: 12 01 02 54
FrmECU: 52 02 10 02 01 54
To ECU: 12 01 03 54
FrmECU: 52 03 10 01 01 54


If I would have the Software & the Healtech plug, I would have been already through ;)
But I know someone, who sent me some data in the past. That´s where I got the most known PID´s from.

TPS is (on my bike) a value from 00 D8 up to 03 7F, which I tested several times.
I was totally wrong with my dynamic adjustment, because with my old equation, I more or less took an eye on the last byte.
Calculation A*256+B means 201 - 895, which worked great, yesterday (Forgot to reset max value, so I only got max ~70%).

This is not very straight if you compare the calculation with RPM and Speed. But rather then have to fix voltage oscillation :D


Tomorrow start my trackdays. There, I´ll go on testing the data values. After that I´ll keep on going with the diagnostic.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 12, 2016, 03:30 pm
I see, it is indeed a strange result. At this point I'm not sure how to analyse the response message. I agree that it's odd how the conversion formulas differ from each other. I think I did not see the same thing for the SDS protocol. Probably the Kawasaki engineers like to confuse us. :)


Have fun on your trackday, ride save ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 14, 2016, 10:18 pm
Today I estimated the conversion formula for the pressure readings (IAP & MAP) by comparing to the Z750 manual.

In the manual there is a graph of Pressure vs. Voltage for the IAP. From the linear plot I was able to determine the slope dP/dV to be 191.0±0.4 mmHg/V using the least squares method of excel.

The 2 bytes are a 16 bit integer such that the value is given by x=256*a+b [0-65536]. I assumed again that normalizing the value and multiplying by 5 V results in the sensor voltage.

V = (5/(256*256)) * x

Then the pressure is simply given by P = (dP/dV)*V.

This results in:

P_mmHg = 191*(5/(256*256))*x

Or, in more common units:

P_Pa = P_mmHg * 133 = (133*5*191)/(256*256)*x

The last equation can be approximated by using 100 * 256/192=133:

P_Pa = (100*256/192)*(5*191)/(256*256)*x  ~= (100*5/256)*x

And by simply dividing by a factor 1000 to get the pressure in kPa:

P_kPa = P_Pa/1000 =  (1/(2*256))*x

Now, this last equation can be simplified by losing some resolution by ignoring b.

P_kPa = a/2 + b/(2*256) ~= a/2



Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 15, 2016, 11:49 am
I´m back and me and my bike are still intact :D

There have been several issues during the rides:
TPS went up to 92,7% and afterwards down to zero. That must be related to a rounding issue, which results on a value greater then 255. It overruns and begun at 0.
My temporary fix was to set the value to 0xFF manually, if value is greater then 880 but the response is below 10.
Not the gentleman-way, but it worked.

The speed formula was made by people with speed limits. It covers 120kmh only  :smiley-yell:
Like TPS, you have to multiply with 255 instead of 100.

In matter of that, it would be consequential that RPM has to be multiplied by 255 instead of 100, also. But 100 worked good from 1000-11.500 RPM  :smiley-roll:

There must be a specific value, which reboots the arduino. Sometimes after 2, sometimes after 15 minutes.
It should not be related to the communication, global variables or something like that. My emulator is working for hours with the Ardu. I think it must be related to a formula which probably divides by null or something :(

MAP is calculated without voltage. My calculation has always been like that :D
Code: [Select]
      case 0x05: //Airpressure: From 2 byte to 1 byte:   
      if(ecuResponse[2] >= 2)
        ecuResponse[2] = ecuResponse[2] / 2; //Double precision
      //Ignore accuracy
      ecuResponse[3] = 0x00;     
      break;   
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 15, 2016, 12:52 pm
Very good to hear your results. Good to know that the speed is calculated the same way, strange though that RPM deviates from that. The longer I work on this, the more confused I get. I just wanted to double check the formula for the IAP/MAP value :) Now this simply proves that you were right all along haha! It also proves that the IAP/MAP values follow the specifications written in the Z750 manual e.g. the sensor pressure is linearly proportional to the voltage.

What is your code to calculate the TPS?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 16, 2016, 09:49 am
I'm having some issues to reconnect with the ECU after communication is lost. When I adjust the delays on the go with a potentiometer, of course at some point the request is send too fast after the last responds which ends up in a timeout (> No response within 1500 ms). Now, when I send a fastinit command directly, I don't get any response back no matter how many times I try.

The sequence looks like this:

...
Response
45 ms delay
Request (This is not received by the ECU)
Response timeout

350ms
Fast init sequence
Response timeout

350ms
Fast init sequence
Response timeout

350ms
Fast init sequence
Response timeout
...

I assumed a simple >300 ms delay would be sufficient as described by the KWP2000 protocol. However, it just won't initiate. So I tried to increase the delay before sending the fastinit sequence to 5000 ms, and it worked!
I took at look at your code, and I see you have a 2000 ms delay before reconnecting. I remember to have read this somewhere in the KWP2000 protocol, but I can't remember in what document. Do you know what the rules are for reconnecting after a timeout?

Edit: I guess it simply means that I have to wait up to 5000 ms to receive the response. There is no way to ignore the response and restart the ECU earlier. I'm going to test this right now.

Edit: Turns out you have to wait for 5000 ms before reinitializing. That's a shame.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 17, 2016, 11:03 pm
What is your code to calculate the TPS?
Today I changed my approach to fix wrong values, by using a different function, to avoid rounding issues:
Code: [Select]
        //ecuResponse[2] = (value-minimum) *100 / (ThrottlePosMax - minimum) * 255/100;
        ecuResponse[2] = map(value, minimum, ThrottlePosMax, 0, 255);

Seems to work :)

I don´t really remember where I got the 2 seconds from. Think the EcuHacking-Forum was it.
Raised it today, but after 20 minutes I still got a break down :(
Maybe the Error was never called and it is really a divide by zero or something.

If the init comes earlier then the 5 Seconds, but then static every second, does it still get ignored?

What´s the matter, that you need the reinitialization?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 18, 2016, 10:13 am
Today I changed my approach to fix wrong values, by using a different function, to avoid rounding issues:
Code: [Select]
       //ecuResponse[2] = (value-minimum) *100 / (ThrottlePosMax - minimum) * 255/100;
        ecuResponse[2] = map(value, minimum, ThrottlePosMax, 0, 255);

Seems to work :)

I don´t really remember where I got the 2 seconds from. Think the EcuHacking-Forum was it.
Raised it today, but after 20 minutes I still got a break down :(
Maybe the Error was never called and it is really a divide by zero or something.

If the init comes earlier then the 5 Seconds, but then static every second, does it still get ignored?

What´s the matter, that you need the reinitialization?
Good that you have hopefully solved that problem! I finally did some first test rides, and found the datalogger works great. I can log approximately 8-10 localIds per second, at a very stable rate. However the Arduino seems to restart sometimes. It takes roughly 10 seconds to restart logging as I found from the motorcycle operating time (works as a RTC :) )

I guess there are two possible reasons for a reboot: SRAM overflow or a power supply issue.
I have excluded the first possibility by logging the free memory, which was constant i.e. no memory leaks. The latter possibility seems more likely to me, especially since my (Ebay) Arduino Nano does not have the standard voltage regulator. After a ride the datalogger also feels quite hot, so this indicates there is quite some heat dissipation. The voltage regulator is an AMS1117 with an absolute maximum input voltage of 15V, which is on the edge I think. Do you know if the 12 V line from the diagnostic plug is stable at 12V, or is it directly coupled to the battery such that during charging the voltage can be like 14V? I hope to have solved this problem by using an extra decoupling capacitor. If this problem can't be solved I either have to buy a genuine Arduino Nano, or use an additional voltage regulator.


About the reinitialization, the strange thing is that the K-line must be silent for > 5000 ms. I investigated this by changing the response-request delay (0-55 ms), and the response timeout (0-5000 ms) on the go. Only when the response timeout > 5000 ms (including the 350 ms I have included in the fast init sequence) the ECU responds again. Setting it to a lower value like 1000 ms, and trying 5 or 6 times does not work. It could be related to a flaw in my code, but at this point I assume my code works as it should.




Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 18, 2016, 11:22 am
That´s a great speed! You have removed every delay, except the 55ms between the messages, right?
Got still the delay between every byte. Removed it also and test that tomorrow!

I was expecting that! The Arduino crashes and my Action Camera goes on asking for values. EcuConnected is false, so it will try to init constantly.
I have no clue how to differ between a clean startup sequence or a crash to execute the 5 Sec delay :(

But the best solution would be not to crash :D
Checked temperature and it was okay! BT module is warm, but far away from hot!
Also the soldering is made to resist cobblestones or earthquakes ;)

You should add a Ceramic-Capacitor 10 nF 50 V/DC. The voltage will be up to ~14,5 on idle. Probably more during the ride.
As you can see in the manual, even the internal voltage differs.

Our beloved discussion about A*100+B or A*255+B:
I´ve never reached more then 11.100 RPM. The limiter comes up at about 12.500 RPM (which I maxed out on the home straight, several times).
Did the camera missed the point or do we still have a wrong formula?

Last but not least: The first thing which stops on my recordings, was the temperature.
Maybe it is just the result of a failure, maybe the cause.
The formula is not very typesafe...
Code: [Select]
    case 0x07:
      //(A-48)/1.6 = Celsius (KDS)
      //+40 to avoid negative values (OBD)
      if(ecuResponse[2] == 0x00)
        ecuResponse[2] = 40; //0C°
      else
        ecuResponse[2] = (ecuResponse[2] -48) / 1.6 + 40;
    break;

I´m sure it will explode below zero! But water has been between 40-80° (Celsius) and Air between 19-40° (temperature in the Airbox which heats up, not the outside temp).
Do you also store temp on your SD card?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 18, 2016, 01:54 pm
It is really fast! I didn't expect this rate, since I do use the 5 ms and 55 ms delay, just to make sure no timeout occurs.

I added a 1 uF capacitor besides a 100 nF, and managed to capture 21 minutes of logging (I attached the CSV file). I already used the 100 nF capacitor, and could not log the data for more than about 5 minutes before crashing the Arduino. I'm going to try to use the 10 nF capacitor, and see if it can improves stability. This time the arduino did not feel that hot as before, although that's a bit of a placebo effect I guess.

So far I used the 100*a+b formula to calculate the RPM, but never checked carefully. You can use the attached file to compare with your results. I think the formula is at least very close, you could have missed the rev limiter, as it obviously is only a very short period of time. My logger logs the RPM roughly every second, therefore you have to be very lucky to capture the exact right moment.

You can see in the attached log that I capture 10 localIds: TPS, IAP, ECT, IAT, MAP, RPM, Battery voltage, gear, speed and total operating time.


Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 18, 2016, 02:02 pm
Here is the log file of approximately 20 minutes of riding in regular traffic.

Btw, to double check if the RPM formula is OK, you can try to log only the RPM. If you manage to log at like 8 Hz the probability is a lot higher that you can capture the rev limiter.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 18, 2016, 03:45 pm
Possibilities for a reset:

The serial buffer can be overloaded as well and cause problems.

When emulating, the Arduino is connected via USB, not Pin 0 & 1 and powered by it, also.
The Emulator values  differ a bit from what the ECU does. Only some fake random values within the known ranges.
Anything else is the same!
In that scenario the Arduino works like charm for more then 2 hours! Stopped it by myself afterwards. That´s why I´m sure it is related to the data itself. Or as you mentioned, to the power supply.

I got the Autobahn here. Think I will reach the 12,5k RPM for testing purposes somehow :D

The init sequence has to timeout or receive an error value as response. Before it will return "false" I attached a 5 Sec delay. I hope it will make the deal to go on working after an error occurred.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 19, 2016, 12:01 am
I also observe the same phenomenon. Using your emulator (which is extremely useful for debugging btw, thanks alot!) never leads to restarts. Restarts only occur when logging a real ride, and not at a regular interval. I think the most likely causes for the restarts are noisy power supply or index out of bounds. I tend to suspect the former cause most, as I could reduce the number of restarts by decoupling the noise. Since my arduino uses a voltage regulator with a relatively low maximum input voltage, this is easily exceeded when noise is on the line.

Today I bought a cheap Kawasaki Diagnostic tool from ebay, I believe it is an old version of the Healtech OBD tool. It will arrive in 2-4 weeks! I'll prepare a sniffer to find all the possible requests. :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 19, 2016, 11:59 am
There are more and more people complaining about that behaviour...

I´ve never read about 3rd party gear indicators, which have breakdowns. They are also connected to the diagnostic plug and have been the basis of our work (some guy sniffed such a device to find out the init sequence and the communication protocol).

From my perspective it can only be:


What happens, if the data is not as expected? If any value is missing or wrong, it could break the whole communication. Length is greater then X, Checksum is missing, last byte got lost somewhere.
The switch-case is a nice solution to identify the header, PID, value and checksum. But if the byte count will be shifted, caused by missing data: Good night :D

I´ll include a WatchDog (http://www.megunolink.com/articles/how-to-detect-lockups-using-the-arduino-watchdog/) and see what happens. If it won´t store anything, its related to the power connection. If it will store something, we can identify where it happens.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 19, 2016, 08:18 pm
I think you are right, it's either a hardware or software problem. We can also test it by running the arduino from a battery to identify the problem.

My code simply continues receiving bytes untill it recognizes the 3 or 4 byte header. Then the number of bytes to read is determined from the response. If not all bytes are received the receiver times out. It does not check the checksum though.
Whenever the response has some weird format it will just be discarded, not filling up te buffer. It could go wrong when the length byte got messed up somehow, such that possibly the buffer overflows. I cannot think of any other possible software issues.

A battery of a motorcycle is typically very hard on electronics due to the inductive character. If spikes occur the voltage regulator might shut down to protect itself.

It is a good idea to use the watchdog to see if its related to software. I'm curious what the results are going to be.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 20, 2016, 04:02 pm
Watchdog is included and seems to work. Tested it by starting the Sniffer, which takes much longer then 4 seconds. But the Arduino just blinks at the end and does not restart. Even the reset button doesn´t help. Only remove vin.
The error code is written, which is important!
Additionally to that, I´m storing a number if no WatchDog error appears, but the Init fails. Or a timeout appears.
It is so hot right now, that I don´t want to ride  :o
Maybe at the weekend...

Beside of that, I changed the engine load to the current gear:
Code: [Select]
ecuResponse[2] = map(ecuResponse[2], 0, 6, 0, 15);
So I can reuse it on my video overlay. The value has to be rounded, then it works great!

Cannot wait to test that!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Gerry48 on Jul 21, 2016, 02:15 am
Hi,

You guys are doing some great work!  I'm trying to do something similar on a KWP 2000 Protocol (K-line) vehicle.  I want to access the transmission temperature, which is located in the transmission module.  That's my problem, how to communicate with the TCM (transmission control module).   I know the TCM address is 20 and the PID is 30, the wake-up command is 81 20 F1 81 15 and the header is 82 20 F1 21.   

I've connected an Arduino Mega Rx/TX outputs to an ELM327 to communicate on the K-line.  Communication works well when talking to the ECM (engine).  The ELM has different modes.  Mode 01 talks to the engine.  I need mode 21 to talk to the TCM (note the last byte in the header = 21).  I've had no luck getting that communication started.

My understanding is that you are not using the ELM327, but directly communicating on the K-line via an Arduino processor & L9637 bus driver?  Which Arduino are you using?  Did you post a sketch?   

Thanks for any info.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 21, 2016, 10:19 am
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 (https://github.com/HerrRiebmann/KDS2Bluetooth)
Scissor´s solution, which uses a SD card (https://github.com/Eztys/SimpleKDS)

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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 21, 2016, 12:49 pm
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.  :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 21, 2016, 03:07 pm
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!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 21, 2016, 05:42 pm
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 :) 
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Gerry48 on Jul 21, 2016, 06:31 pm
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. 

(http://i429.photobucket.com/albums/qq12/Calbiker/Boondocking/P1070875C.jpg) (http://s429.photobucket.com/user/Calbiker/media/Boondocking/P1070875C.jpg.html)

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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 21, 2016, 07:00 pm
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 ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Gerry48 on Jul 22, 2016, 05:56 pm
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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 23, 2016, 10:23 pm
I don't have any experience with the ELM, but I suppose you might find some information in this thread (http://ecuhacking.activeboard.com/t22573776/sds-protocol/?sort=oldestFirst&page=5#comment-49610241).

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



 



Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 25, 2016, 11:17 am
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 (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/ELM327DS%20Schnittstellenbeschreibung.pdf).

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?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 25, 2016, 11:52 am
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;

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 25, 2016, 01:48 pm
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.

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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 26, 2016, 01:29 pm
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.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 26, 2016, 03:45 pm
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 (http://www.manualslib.com/manual/375217/Kawasaki-Z750-Abs.html?page=127)).
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 ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 27, 2016, 10:01 am
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.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 27, 2016, 02:13 pm
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:

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:

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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 27, 2016, 07:13 pm
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!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 28, 2016, 11:15 am
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:
(http://fs5.directupload.net/images/160728/j8i544j9.png) (http://www.directupload.net)
(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.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 29, 2016, 12:12 pm
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:

(http://www.motorvista.es/tienda/images/ht_obd/ht-6003_obd-kawasaki-ss2-error_codes_ht_en.jpg)

The description given seems to match with the OBD DTC code http://www.obd-codes.com/p0115 (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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 29, 2016, 02:17 pm
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:

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:
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 29, 2016, 02:47 pm
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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Jul 29, 2016, 02:52 pm
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? ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Aug 02, 2016, 06:43 pm
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:

(http://i64.tinypic.com/29lbgo2.png)

(http://i64.tinypic.com/vysdpe.png)

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

(http://i63.tinypic.com/152gl8m.png)

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:

(http://i67.tinypic.com/5noe44.png)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Aug 20, 2016, 12:13 pm
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

(http://i63.tinypic.com/29kutfm.png)
(http://i67.tinypic.com/2pzmjcp.png)
(http://i67.tinypic.com/1z4ve6r.png)
(http://i67.tinypic.com/fc79k4.png)
(http://i67.tinypic.com/2vcvu4o.png)

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.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: kamibutt on Dec 08, 2016, 10:29 pm
Dear Concern,

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

Regards
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Dec 19, 2016, 04:45 am
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!
          }
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Dec 19, 2016, 12:05 pm
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 (http://forum.arduino.cc/index.php?topic=236092.0).
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Dec 19, 2016, 01:30 pm
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 (http://forum.arduino.cc/index.php?topic=236092.0).
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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Dec 20, 2016, 10:41 am
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.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Dec 21, 2016, 04:49 pm
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?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: alexsoletti on Dec 22, 2016, 05:18 am
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
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Dec 22, 2016, 10:47 am
Hi Alex,

I understand the DTC Codes.
Kawasaki is able to store up to 3 Errors.
SID 13 followed by the error number (1-3), gives you the Code. As you did already!

The response will be:
53 03 10 01 10 02 15 07
SID 13 + Succes (40) = 53
03 - Error Code Length
10 01 10 - Error Code: Intake Air Temperature Sensor
02 Failure Record Length Or again Number of error (I forgot)
15 07 - (Failure Record, which localize the data in Freezed Frames [SID 12])


With that, you can get all the sensor data with SID 12, from the exact point where the malfunction appeard.

Your response looks a bit different...
There is a 100115 which means "Coolant Temperature Sensor".
Which model do you have?

It would be possible to read and write the flash. But as far as I know, you need a special mode for that. And you can only activate that mode, by submitting an official Dealer-Number, which you will only get from Kawasaki.
SID
27     Security Access
34 Request Download
35 Request Upload

Some "tuner" just overwrite sensor data to make the ECU changing the injection and stuff. This seems to be an easier way.

But nothing for me, right now. I´m happy with what I got and don´t need to change the mapping. Or in worst case: Destroy my ECU  :o
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: alexsoletti on Dec 22, 2016, 02:01 pm
Hehe, I feel like an idiot. Havent read the entire page #5 here. It was all there!!

Ok, mine is a Denso ECU ID 21175-0734.. From a ER-6n 2013 I think.. its just the ECU..

I have connected a OBD BikeTech tool to this ECU and it gave the following error codes.. just noticed this morning (check attachment image)


Checking my reply the ids match according to attached image

Original ECU response: 80 F1 11 0E 53 06 01 10 01 15 01 20 11 01 11 04 15 04 71

80 F1 11 0E 53 06 ???
01 10 Intake Air Temperature Circuit Malfunction Bank 1
01 15 engine coolant temperature circuit
01 20 throttle position sensor/switch a circuit
11 01 inlet air pressure sensor
11 04 sub throttle sensor
15 04 vehicle down sensor
71  - crc code?

So its a list with all active dtc codes for current session.

Now, according to this site (https://www.obd-codes.com/trouble_codes/) error codes initiated with P1xxx are manufacturer specific, and on the image I attached we have 3 codes.. do we have a mapping for all those P1xxx codes? Maybe they are listed in KDS manual?!

Btw, I've noticed in the HealTech image (googled the same image that Scissor posted) and indeed, only 3 DTC codes are stored, and each stored freezeframe has a snapshot of what were the values of many sensors like TPS position, coolant temperature, battery value, etc.. dunno how to read them tho.


Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Dec 22, 2016, 04:41 pm
Hi Alex,

your ECU has the same protocol like my Z750r from 2012 (Protocol: 20002).

So its a list with all active dtc codes for current session.

Now, according to this site (https://www.obd-codes.com/trouble_codes/) error codes initiated with P1xxx are manufacturer specific, and on the image I attached we have 3 codes.. do we have a mapping for all those P1xxx codes? Maybe they are listed in KDS manual?!
There is no offical list about that :(
The codes you get in the bike-display are different and only a few. They are documented in the manual.
In the Kawasaki Software, they are hardcoded. I think Healtech only matched them with the original KDS V3 Software.

Btw, I've noticed in the HealTech image (googled the same image that Scissor posted) and indeed, only 3 DTC codes are stored, and each stored freezeframe has a snapshot of what were the values of many sensors like TPS position, coolant temperature, battery value, etc.. dunno how to read them tho.
That´s the way where I got them from. Sniffing the Healtech requests and match them in the correct order.
You find them in my GitHub:
OBD PID´s (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/OBD%20II%20PIDs.xlsx)

There is everything you need. All documentation, Code, SID´s, PID´s, ect.

Read them by:
80 11 F1 02 21 07 AC
Where 21 is SID to "Read Data By Local Id"
07 is the PID "Intake Air Temperature"
AC is the Checksum.

If you want that data according to you failure:
80 11 F1 04 12 01 01 07 XX
12 SID Read Freezed Data
01 Number of Error (Count up to 3)
01 DTC Group (there is only one)
07 Intake Air Temperature
XX Checksum


There is no image attached ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: alexsoletti on Dec 22, 2016, 07:40 pm
Ouch, I thought the image was attached!!
There It goes!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Dec 23, 2016, 01:34 pm
Okay, does not matter :) I think you get all the information needed from the Excel-Sheet, I linked in my post.
Except the complete DTC Error list, as I explained.


I´d be interested in the Injector-Stuff!
Would it be possible to sniff the Serial-Port/USB Signals to see what the software is sending to display the Injector values?


The Software seems quite light, against the healtech solution. But I guess a lot cheaper!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: alexsoletti on Dec 23, 2016, 01:46 pm
Yeah, I'v been using the excel-sheet.. its pretty complete. Amazing job!

I'll see what I can do. Sniffing wont be easy as the whole solution is modified, there are no USB Drivers listed under Computer Devices, neither I can solder a wire to the usb chip because the box is armored.
Guess I'll have to build some sort of USB bridge using a raspberry pi or something.

Indeed, HealTech solution seems a lot better. I think its outdated, but the tool owner dont care. :/



Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jan 01, 2017, 11:42 pm
Used my free time to review some recordings.

Here are two laps in Mettet, Belgium with the data transferred to my Virb camera:

Mettet Warmup - Kawasaki Z750r (https://youtu.be/7NzQdNrY6Ro)

After some laps, it was disconnected. That´s why these were not my best/fastest Laps.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: AndreKravcenko on Jul 01, 2017, 08:14 pm
First of all: Thanks Scissor and Trib for all the work already done.
By myself, understand only 1/3 of everything you posted.
It looks like an alien language !! kkkk...
I want to learn and I am studying the ISO 9141-2 protocols.
Maybe I can contribute a little help. It's a tactic. I used to apply in the first MAMES (multiple arc machine machine emulator) to find cheat codes, such as infinite lives, invulnerability, etc., but the principle is the same. On one line: Inducing the desired ECU´s response.
Well ... here is a link that can clarify what I mean. :

https://theksmith.com/software/hack-vehicle-bus-cheap-easy-part-2/

Keep the good job guys !!!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 02, 2017, 02:52 pm
First of all: Thanks Scissor and Trib for all the work already done.
[...]
Keep the good job guys !!!
Thanks! :)
I have already read the vehicle hack. Really interesting stuff! But it makes usage of CAN Bus, which is a different communication protocol as K-Line (KWP2000). Both, in soft and hardware manner.
The only bike manufacturer, which uses CAN Bus is BMW (afaik).
"Accidentally" I got a Plug to connect a BMW S1000rr to a cheap china ELM327 adapter. But it did not work on the first try. Now my college sold his bike :(

The best thing is to read the documentation (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/iso.14230-4.2000.pdf). It´s boring, but you have to understand it to start hacking :)
If you have any questions, just ask!

Currently I began to hack my Suzuki. The bad weather helps me to stay motivated ;)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: AndreKravcenko on Jul 04, 2017, 08:34 pm
Thanks for the .pdf. Very instructive. For now, I'm still stuck on this ic L9637d which I can´t find where to buy.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 04, 2017, 11:10 pm
Thanks for the .pdf. Very instructive. For now, I'm still stuck on this ic L9637d which I can´t find where to buy.
As I don´t know where you are coming from, I can hardly help :(
In Germany we got several electronic shops, like
Conrad (https://www.conrad.de/de/linear-ic-stmicroelectronics-e-l9637d-soic-8-1184592.html)
RS-Online (http://de.rs-online.com/web/p/peripherie-treiber/6864857/)
and a lot more...

But international, you will always find anything on
AliExpress (https://de.aliexpress.com/item/2PCS-L9637D-SOP8-L9637-SOP-L9637DTR-SMD-free-shipping/32714788772.html?isOrigTitle=true). But it takes a long time to deliver.

Don´t forget to order an SMD 2 DIP adapter (https://www.amazon.de/gp/product/B00JK8EYTG/ref=oh_aui_search_detailpage?ie=UTF8&psc=1). Else it will be nearly impossible to solder it :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: AndreKravcenko on Jul 05, 2017, 02:54 am
 (SMD 2 DIP adapter) - Good point ! I did´t even think this. Btw,  Amazon Germany not even make sales to Brazil !!!! But i can do it myself with my DIY CNC Monster Machine"...LOL - https://www.youtube.com/watch?v=6wbK1HUdtEU&t=4s


---------------------------
Today I was in an authorized kawasaki. I tried extracting some PID codes from the technician. He will try to help me (maybe).

Thank you Thomaz !!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 05, 2017, 10:16 am
In my Excel-Sheet, there are many PID´s, which I found out by try & error:
OBD II PIDs.xlsx (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/OBD%20II%20PIDs.xlsx)

Not all of them, but I think the most important.


Hmm, I´m currently not in a view of Brazilian electronic specialist-retailers ;)
But you will also have Amazon (but my Portuguese is to bad to search for you) and AliExpress ships all over the world. I think, it won´t be faster to send a carrier pigeon from germany :D
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: AndreKravcenko on Jul 05, 2017, 05:20 pm
Yes...(your .xlsx file - I already download and will use it), that´s a great job. For now i´m trying to find  somewhere the "Consumption average", "Kms per liter" and "Total mileage of the motorcycle 1 & 2".

( Finally, I bought the IC L9637 in Amazon. ( I hope this time, they accepted my amex card !!!! ) ).

That´s a shame : IC - $2.00 (*5) --------- Shipping $39.00 !!!!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: jonsey on Feb 22, 2018, 08:46 am
Hi All!Thanks to TriB for your amazing job!I want to try with my z750 my11 this solution with Torque installed on my android phone!
I've just received my ESP32 dev kit board, with bluetooth and wifi integrated in one board, is possible to implement your solution with this thing instead of use an arduino Nano+ bt module?Can you help me?I've also the E-L9637D chip for K-line and a board where solder it to make easier the connections.
Is needed also a voltage regulator?This is the only thing i miss... :/
Thans for your suggestions/help!
F.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Feb 22, 2018, 10:59 am
Hi,
yes I was considering using an ESP32 as well. This would have two or three great advantages!
Onboard Bluetooth, (parallel) processing power and WiFi. OTA Updates!!!

Theoretically you can put all the converting stuff in another process, separated from the communication. If this really speeds the system up... I don´t know! The ECU limits the amount of requests.

Anything else is "nice to have" from my perspective.

But: The Arduino libraries seems not to be ready, yet. Bluetooth is not working for me. Using EEPROM reboots it. WiFi connections takes more time than an ESP8266...


You should regulate the voltage! There are possibilities to have voltage peaks and the Arduino gets very hot, if you max the VIN out. It often quits, until it´s cooled down again. The chinese Ardu´s earlier then officials.

The L9637-D needs a PullUp-resistor between K-Line and power supply. That´s it, more or less :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: jonsey on Feb 22, 2018, 06:50 pm
Hi TriB, today we have talked also on Hangouts...hope to continue that conversation! :D
Do you mean this kind of issue with BT serial ports?! https://hackaday.com/2017/08/17/secret-serial-port-for-arduinoesp32/
I don't think to be able to make some complex stuff at the moment...i was confident that changing few things was possible to make it works also on this ESP32... :/
About the pullup-resistor, maybe i've something here around in my house!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Feb 22, 2018, 09:45 pm
No, I´ve read about BT issues in some german threads. But it seems to be related with the Firmware according to the manufacturer of the board. It wasn´t completely ready at that time.
Currently mine is just using WiFi and located under a wall. So I cannot test it  :smiley-yell:

Code changes must be done for BT serial and Hardware serial pin matching. Onboard LED is also different and as I said, EEPROM didn´t work fine for me.
With that changed, you can attach the L9637D and it should work.

510Ohm will do the deal to straighten the signal on the K-line.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: jonsey on Feb 23, 2018, 07:11 am
Change the SoftwareSerial to the HardwareSerial and LED pins...ok, i believe that i can do it  :) .
However my ESP32 is available for you if you need it!  :smiley-cool:
Can you tell me what is that fw issue with ESP32?!
F.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Snecer on Mar 01, 2018, 06:36 pm
TriB: tnx for all your information

The device is working (with modification on electrical circuit) - first test with torque pro
https://youtu.be/O3VYY08cjY0

(http://shrani.si/t/G/9J/f5LDUsH/wp20180301013.jpg) (http://shrani.si/?G/9J/f5LDUsH/wp20180301013.jpg)
(http://shrani.si/t/r/OM/4sG5XkYj/wp20180301017.jpg) (http://shrani.si/?r/OM/4sG5XkYj/wp20180301017.jpg)
(http://shrani.si/t/3i/pS/DUeJdIR/wp20180301006.jpg) (http://shrani.si/?3i/pS/DUeJdIR/wp20180301006.jpg)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: keremoktem on Apr 02, 2018, 05:12 pm
Dear all,
Thank you very much for this really great post.

I would also like to add this functionality for my Versys 650 ABS 2013. Especially the gear indicator.
I have a question...

What connector name brand type is used to connect to the KDS connector on the bike.

Best Regards
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Apr 02, 2018, 08:08 pm
What connector name brand type is used to connect to the KDS connector on the bike.
Hi keremoktem,
I expect it to be this (https://www.corsa-technic.com/item.php?item_id=341) one.
It is the most common on lots of Kawasaki.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: ENG_EE on Jan 23, 2019, 02:09 am
Hey guys,
thanks so much for all the info provided here.

Quick question:

Has anybody experimented with the service code 0X31 in KDS (start routine by local ID)?

After reading the KWP2000 docs and checking some sample files from Healtech software it seems you can initiate actuator tests (such as fuel pump test) with this code.

Any hint or help is appreciated.

Thanks!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jan 23, 2019, 10:57 am
Hi,

yes I was playing around with them a bit, but with no success.
Every 0x31 I put into the bike, was responded with 0x7F. So I ended my attempts and concentrated on other things. As many other SID´s, Kawasaki does not support what KWP2000 or ISO14230 describes. Or they just differ the service ID to it.

I know Suzuki supports that as well, but the messages are quite different:
Testing the cooling fan
ON : 80 12 F1 06 A5 06 80 00 00 00 B4
OFF: 80 12 F1 06 A5 06 00 00 00 00 34

As you can see, no 0x31.

And then, there is the diagnostic mode, we are starting all the time (0x10 0x80). Like known supported PID´s as 0x0E (Injector 1 Operating time), we also receive 0x7F.
Why is that? I expect we are using the wrong mode! There is surely another mode, which allows tester or manipulating stuff.

Right now, I repair my Gsx-R to be on the track by may. If I´ll be on time, I´ll move on testing the Z750r :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 03, 2019, 10:34 am
Hello, TriB !

I am totally in awe for the solution you've been able to create, where you make the Arduino act as a "proxy" (guess I can call it like that) for your VIRB action cam. I myself have been looking for a solution where I would log my Honda's OBD- data to bluetooth, and receive these data on my Android smartphone where I'd log them with an app still-to-be-developed (but where there is more than storage enough for a full 10 day's holiday's logs, not to speak about the extra complexity if saving the data -to SD- would be done on an Arduino, with which, after all, I'm totally unfamiliar with as of yet). And this way, looking for some bluetooth hardware's usage, I came along this thread : well documented project, great conceptual idea.

My intention for the moment would be, ideally, to extend your solution with my Honda's capabilities. But, first things first, I only have a very limited idea about which PID's I can (identify and) read from my Honda. So I guess I should work more on that rather than to start by extending your project (with data I don't have yet).

My first steps will now be to order the parts I think I will need (-> may I come back here to have a validation of the hardware like I intend to make it ?). I'm not all that familiar with designing hardware myself, like e.g. this voltage divider for the K-Line that had been mentioned earlier in this thread, is this needed ? I don't see it come back in the schematics, and moreover I'd think the 9637D can cope with it's voltage ? I also see the capacitor between the 9637's Vcc and GND, why is that for ?

Later on I'll have a look at trying to fetch the data from my Honda, and identifying as much of the PID's as possible (there's this other thread started by o5i_ where I have some basic information from). Who knows I come to the point where I still have some perseverance left to extend your project by implementing a VIRB-to-Honda interrogation-translation step.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 04, 2019, 05:23 pm
Hi sudolea,

yes, the solution is somehow like a proxy. But also manipulating/converting the data.

You can record the data with any OBD II compatible app, like Torque (Pro), Car Scan or for racing purpose RaceChrono.

If you´d like to write a custom app, you can disclaim the conversion to OBD II on Arduino-side. I´d rather transfer the raw data and do any conversion later on android, then doing this on low level with limited ram and storage.

Currently I additionally store the raw data onto a SD-card. That´s quite easy with an SD-Shield! It can be connected easily to the arduino and there are hundreds of example sketches and libraries!

Conceptual:
The bikes (up to 2017) have a custom protocol, which is somehow similar to OBD 2 via K-Line, but not equal!
As you found out right, the PID´s does not fit.
There might be some hints on the ECU-Hacking Board (http://ecuhacking.activeboard.com/).

I´ve enhanced my solution to Suzuki (working) and Honda (only theoretically initialization process). But I did not go further, due to nobody next to me, who will give me his bike to test :)

Buy the stuff and solder it all together, then I will help you out as far as I can!
The L9637D is capable up to 40V.
It should be pulled down to the ground (which you can find in the documentation sheet (https://github.com/HerrRiebmann/KDS2Bluetooth/blob/master/Documentation/L9637D%20IC_INTERFACE_BUS_ISO_E_L9637D_SOIC_8_STM.pdf))

Good luck!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 04, 2019, 08:09 pm
Hello, TriB,

I've ordered the parts, and in the meanwhile I have downloaded your git repository, created a new branch locally, and am doing my coding thing in there, focusing on the Honda things. Up to now : only the code preparations, not the values yet. And I also inserted some defines to enable making Honda ECU's value translations aside the Kawasaki ones...

I don't know if I could make a pull request, for you to approve them, if you didn't make that branch yourself ? Anyway, you might be interested in my modifications, and if so, I can try to make a pull request in your online git repository...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 06, 2019, 10:39 am
Hi sudolea,

I must be honest: There is another, more straight forward solution I´m working on.
Currently it is not yet public. It contains KDS & SDS and the basement (initialization) for Honda.

Right now it seems to work good on KDS, but my camera sometimes does not proceed recording the data. I want to figure out why and how I can fix that.
SDS works sometimes good, sometimes not. When the RPM reaches more than 14.000, it starts on 7.000. I´ve triple check the coding (variable sizes, overflow, ect.) and created lots of tests, but this freaks me out :D

Until this is not solved, I won´t release it. So a pull request would run into the "old" solution...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 06, 2019, 06:51 pm
TriB, I have had a close look into the parsing part of the 'AT' commands, as I am already experimenting for the moment with the parsing code. Don't you sometimes loose input characters from the bluetooth ? Unless I'm wrong, there are delays that are strictly seen not necessary in my reading (may be wrong). I removed them and adapted that code a little. Maybe there are parsing timing issues with your new version ?

Apart from that, I am a little confused about the pinning on the Nano. There is only one serial port, apparently ? I am now at the point of connecting the bluetooth module HC-06. It's data sheet indicates to connect it's TXD and RXD pins to the Arduino's Rx and Tx pins respectively. In your code, I see you using, as the Arduino's pins for the bluetooth module, 11 for RX, and 10 for TX. But I don't see these mentioned, for the Nano, anywhere here (https://www.arduino.cc/reference/en/language/functions/communication/serial/). How come ? I hope my little Nano CAN do the job, can't it ? I guess you're working with the Nano too, aren't you ?

Then also : do you use a 1KOhm/2KOhm voltage divider for your Bluetooth's RXD pin ?
And lastly : is my understanding thus correct that I connect the bluetooth module's RXD (after voltage divider) to Arduino's TX pin 10, and the bluetooth module's TXD to the Arduino's RX pin 11 ?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 07, 2019, 01:47 pm
Hey,

no I don´t loose BT input. The data will be received fine and the code works for hours for me.
The bluetooth is connected via SoftwareSerial (https://www.arduino.cc/en/Reference/SoftwareSerial), sometimes, when the data comes in, you will have BT.available but the transmission is not completed. Due to it´s a buffer, you can read delayed.
Just read about Serial or SoftwareSerial (which is different, but compares the lack of a storage using interrupts, a bit).

SoftwareSerial can be used at most pins, in my case 10 & 11.
Off course it is better to use another hardware serial, but only the Mega has a second one.
Since this is a request-response protocol, you will have no overlapping, receiving ECU data and bluetooth requests.

The Nano I´m using with the public code, has no resistor to the BT module. It worked reliable in the past.
I created a custom PCB with a ATmega328 and L9637D onboard. There I use a 1.8k on Rx and 3.3k to GND.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 10, 2019, 10:06 pm
Hello, it's working as I intend to use it, the Android app "ELM Identifier" shows 20 greens (not better than ELM v.1.3 though). Also some random Android OBD- app I installed (to try the Nano) could be "fooled" thinking there was a "real" OBDII bluetooth dongle connected. Some little discomfort with using the Nano to develop : I had to use the hardware serial for the Bluetooth module to have it working, so my debug info is a little bit garbling the standard bluetooth's output, the Mega would've been better for this kind of development, or I should buy a couple of USB to TTL serial converter CP2102 UART (cables or chips).

So everything fine up to now, I'll start implementing the Honda part now. One thing I admit : in the near future, I'll be a little afraid to hook my real bike's KLine to the Nano- hardware (over that 9637D- chip), as I'm rather a programmer than a hardware-guy, and I don't want to break my bike's ECU in any way ... I'll use a 510 Ohm pull-up resistor between the battery's voltage and the KLine (before connecting it to that 9637D), as I've seen this come back quite regularly, so I suppose this is how it's supposed to be done...

To avoid too localised heat (i.e. only in the Nano), I decided I'll put a 7809 chip in between my bike's 12V and the Nano, that way the Nano is a little less up to it's maximum VIN, and doesn't have to reduce the input voltage alone (and moreover, I hope nasty voltage peaks will be a little less harsh to my Nano too).

To come back on your Suzuki PID seemingly overflowing : I hope you found it already ? To me, FWIW, it sounds like some variable in 2 bytes not atomically being reset or set, but in some nasty non-atomical way... (that it's not around the 256- range but rather around the 7000- range could maybe be explained by the conversion further on in the calculations ?)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 10, 2019, 10:51 pm
I came along this interesting article for this atomic issue I was talking of (didn't read it completely, though) : here (https://forum.arduino.cc/index.php?topic=73838.0)

Maybe not your problem, but it might be (and I wouldn't exclude it)...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 12, 2019, 10:55 am
Yes, I´ve made the same experience. That´s why I got the second solution "HC06 Sniffer", where I fake all the values and use the main-serial for debug purpose.
With that I found out, what commands my camera or CarScan, Torque, ect. sends. And which are mandatory to be answered properly.

Now I created a second board with a SD-card, which just writes all down, which comes via serial port.
That´s not optimal, but enough to find problems or check all incoming data.

But my Suzuki is a racetrack-only bike and I cannot test stuff at home. And on the track, I mostly got enough different things to do...

I know the atomic property, but this only comes in place using interrupts.
My thought was a classical overflow. But I created a test sketch and faked data up to 17.000 rpm, which came out correctly, without any flaw.
There will be a memory leak, which will not get better, expecting messages up to 70 bytes long, which have to be converted and answered...
As I just finished a different project, I´ll get back to this one :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 12, 2019, 04:28 pm
As I see that a lot of data comes with a single request for the Honda- request, I am planning on interrogating the ECU (close to) continuously with the "one and only known" Honda- request (IF that one will work on my VFR800F, which I hope it does of course).

And then, whenever the bluetooth side asks some (known/identified) PID, I wouldn't go back to the ECU for interrogation, but compose the response based on the last known fetched data. I might obtain (/hope to obtain) some more throughput this way. At least, that's my current plan, will have to see confirmed if this would/will work ...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 27, 2019, 09:16 pm
I have it working nearly good enough to start testing it live on my bike ... apart from 1 design issue which I don't know how to solve properly...

How it's designed : I don't start interrogating the ECU, until the ELM- side asks some PID. At that point, I establish the (Honda) communication, and keep on interrogating the ECU (always the same request) until something goes wrong, at which point I stop communication with the ECU, to only re-establish communication as from the first new ELM- side request thereafter.

However, the problem I encounter, is that while I interrogate the ECU, so-to-say in the (virtual) "background", I loose my bluetooth side's received characters : the Nano only has one Serial, which I use for uploading the compiled sketches and as the debug output. So the ELM- interrogations and the KLine communications are done by means of 2 SoftSerial ports. This means I can only listen out on either one of them at the same time.

My design solution would be to NOT interrogate the ECU continuously (but only when the ELM- side asks for some PID). But then again, the same issue arises when the timeout value is reached, at which point there is an ("automatic") PID- request to the ECU anyway ... which would make me loose ELM- side characters anyway.

Apart from switching to another Arduino type (than the Nano) which has more than one single Serial ports, how could this be solved ? Did you encounter this issue ? I would like to avoid switching to another board because of the bigger inevitable bigger board size...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Hiddenvision on Jun 28, 2019, 12:30 pm
One option is to use a small Arduino to handle the OBD or the Bluetooth seperatly.
Then use the SPI interface to pass data between the two boards.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jun 28, 2019, 01:37 pm
Honestly, I did not tried to make it work with constantly two Software Serials.
In my project(s), the L9637D is connected to the hardware Serial. It´s with 10417 baud not very fast. So SoftwareSerial *should* handle this. But I´m not sure if it is even capable of such a baudrate (https://www.arduino.cc/en/Reference/SoftwareSerialBegin)!

The Bluetooth-Dongle runs on 57600 baud, which seems the maximum, which SoftwareSerial is capable, reliable.

When I attach my SD-datalogger, I have to stop the BT and reinitialize the second SoftwareSerial, to write my debug information. After this is done, I start the BT again:

Code: [Select]
void Log(String text){
  if(!LoggerActive)
    return;
  BT.end();
  Logger.begin(LOGBAUD);
  Logger.println(text);
  Logger.end();
  BT.begin(BTBAUD);
}

When I doesn´t, I get garbage.

The communication is like PingPong. You´ll get a request and without a response, you won´t get a next request. Only after a timeout or an attempt to reinitialize.

If you will have a long taking task, like an error, where you have to wait for at least 2 seconds, you can send a "BUSY".
When I receive a request to the ECU without proper initialization, I send a "BUSY", do the ISO-Init stuff and then go on.
So I expect no commands being received until you answer the previous one properly!


Maybe you have a different behaviour? Do you wait until the BT command is completed? Sometimes it sends a CR and a LF.


From my opinion, I´d try to use just a single SoftwareSerial and connect the L9637D to RX & TX. You will loose the Debug-possibility via USB, but that´s the price for using a Nano.

PS: My datalogger works with a second Arduino Nano, like Hiddenvision suggests.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jun 29, 2019, 01:43 pm
Hello, thank you both for your responses, I have read your 2 replies carefully, and using 2 Nano's is an interesting idea I hadn't tought of. OTOH, I asked myself how to connect these 2 Nano's in the case I would let them co-operate, would both be powered by the one 7809 chip, or would you power both by each their own 7809 chip ? I guess only GND should be connected to each other ?

Although, this is only a question asked out of curiosity, because I have since then changed plans, and won't be continuously interrogating the ECU with keep-alive messages any longer : I will have my (Android) logger app re-interrogating the ELM-side frequently enough (i.e. well before the KLine's timeout limit), so that I don't have the necessity for these KLine keep-alive messages...

So yes, I waited - the first time there is a communication need between the Nano and the ECU - till the BT request was properly received and until the ECU's response was properly coming back after the very first KLine initialisation sequence had completed. I saw this CR - CR/LF issue in your code, and implemented this in my code too : based on your good comments I could quickly see why you did what you did there.

Whereas before I started, after that KLine's initialisation was completed, the continuous ECU's interrogation (i.e. not triggered by some ELM-side request), I will now "just" take care the next ELM-side request is sent soon enough thereafter by my (Android) logger app. This will make my life a little easier, I guess... I might interrogate the ECU only in case of the very first of the ELM PID-request list, and for the other follow-on PID's in the request list "just" use the data that had been sent in that same ECU's burst response for the first PID interrogation (i.e. without doing the round-trip to the ECU in case of these other PID's).
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Hiddenvision on Jul 03, 2019, 05:14 pm
You could run the two boards from the same PSU. Or separate if desired, but remember that you need at least a common ground for most interconnects.

Remember also with a running bike or car the voltage can peak at over 16v when the battery is charging. Some 78xx regulators may not like going up there, and use 25v caps NOT 16v ones.

Using two boards will allow you to split the workload.
Using the SPI port or other methods to chat between themselves.

There is even the option of using things like the ESP8266 or similar to give standalone Wifi connectivity.
The two processors do not have to be the same type.

What was the need for the ELM device.?

Perhaps another way to interface to the Kline
More wiring focused rather than what processor was used.
https://lb9mg.no/2017/12/27/reading-obd2-data-without-elm327-part-1-can/ (https://lb9mg.no/2017/12/27/reading-obd2-data-without-elm327-part-1-can/)

Then you have a more direct access to the true serial coms rather than talking thru the ELM.
Oh this is similar to what Trib is using L9637D?

Sorry I have not read all the messages so not sure if the above or similar has been tried.
Oh I feel like I should have read more first.!


Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jul 04, 2019, 03:43 pm
...

What was the need for the ELM device.?

Perhaps another way to interface to the Kline
More wiring focused rather than what processor was used.
https://lb9mg.no/2017/12/27/reading-obd2-data-without-elm327-part-1-can/ (https://lb9mg.no/2017/12/27/reading-obd2-data-without-elm327-part-1-can/)

Then you have a more direct access to the true serial coms rather than talking thru the ELM.
Oh this is similar to what Trib is using L9637D?

Sorry I have not read all the messages so not sure if the above or similar has been tried.
Oh I feel like I should have read more first.!

No, you shouldn't (have read more), it was me being unclear when talking about the "ELM-side". Because what I mean there (by mentioning "the ELM-side"), is the bluetooth part of TriB's project - basically implemented similarly by me just a little differently for my Honda ECU. It is at that bluetooth side that the ECU interrogations start, in a way that is very similar  to -albeit a subset of- the way the ELM-chip interrogates an ECU...

The code sample you provide is no option for me, as I only have a KLine available on my bike for interrogating the ECU, no CAN bus there...

It may become a little less confusing as I'll show my hardware setup in the next post coming hereafter - with the intention to have my hardware validated by good souls having been there, having done that before...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jul 04, 2019, 03:58 pm
I tested my application with some bash scripts (as I'm working in Linux) - the setup to have the .Net ECU emulator was too cumbersome to setup to run in Linux. For the Honda there can be sent 7 PID's in one ECU-interrogation, and I "invented" a new PID which sends them all in one ELM-side (bluetooth-side) interrogation instead of doing 7 separate PID interrogations to the ECU. The ECU can be interrogated at 10.25 Hz (and 9600 baud, no real ECU connected yet). All of this in the hope that the Honda documentation I found around is also valid for my VFR800F of course, touch wood...

Now as my little project is working properly (enough), also the bluetooth part, AND while busy developing my Android logger, I can start thinking of connecting my Arduino to my motorcycle. However, before doing so, I'd like to have some confirmation that my hardware is valid (I'm scared like hell to break my ECU)... Could some good soul, better educated in the hardware domain than me the poor programmer, have a look at my attached hardware scheme to verify that my setup is valid, please ? Arduino's bluetooth pins in my case are 10 and 11 (Rx respectively Tx), and Arduino's KLine pins are 8 and 9 (Rx respectively Tx) - so using 2 SoftwareSerials, I got them working OK...

More specifically, I'm thinking of
- the 1.2 kohm - 2.2 kohm voltage divider for the bluetooth module's Rx side to bring the 5V input level a little closer to 3.3V. I guess it may not be necessary, but it won't harm either, will it ? When testing here on my breadboard, I don't use one...
- the 100 nF capacitor between GND and KLine. I saw this scheme somewhere in my quest for information, but I can't remember where any more. But I wonder what it's function is (avoid dendering ?)
- the 100 nF capacitor between GND and the 9637's Vcc (same function ?)
- I guess the 510 ohm pull-up resistor between Vs and the KLine is OK ?

What is unclear to me too, is the correct orientation of (pin 1 of) the 9637's chip. I have supposed it is at the left-bottom side when reading the markings on the chip. I guess that is the correct orientation ? There was no notch nor bevel on the chip whatsoever - a nightmare for the poor programmer ;-)

Getting closer little by little :-)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 06, 2019, 01:57 pm
Hi sudolea,

nice to see you are proceeding!
I´m just on my way to my holidays, so I just got spare time...
The L9637D got an flattened edge on a long side. It´s tiny but it´s there! No point like the documentation shows.
This is the bottom line and on the left side at the bottom, there is the "1"-> VIN.

Just took a short look on your scheme, looks okay for me. But I´m also more a developer and not a good electronic :-/
A friend of mine did the cirquit design from my latest version.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Jpauloguino on Jul 10, 2019, 02:34 am
Good night guys! Working with Remap of motorcycles and I need to develop a datalogger, I have the original file of all motorcycles HJ Yamaha Kawasaki Suzuki and Honda, with what can I help you??
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Jpauloguino on Jul 10, 2019, 02:42 am
I even have a scanner that if anyone knows how to tell me how I can extract information from him!!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Jul 12, 2019, 09:26 am
..., I have the original file of all motorcycles HJ Yamaha Kawasaki Suzuki and Honda, with what can I help you??
Well, the information I myself found on the internet regarding the KLine- communication with my VFR800F (eighth generation, so model 2014/2015) was rather shallow. I don't know what you mean by your post, but if you can provide it, would appreciate more information on :
- how to start the communication with a VFR800F's ECU over the K-Line, and
- the (Honda) PID numbers for the most common PID's ( = the link between e.g. throttle position, AIT, AIP, rpm, ..., ... and their Honda PID numbers), including the way how to interrogate the ECU for obtaining these data (and converting them to something meaningful)

It's rather quite specific stuff, but if you could obtain that information, feel free to do so...

Maybe TriB still has similar requests left ?

Regarding this datalogger of yours, if you intend to run it on Android, I'll share my Android datalogging code ... once it's working, ánd working properly...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Hiddenvision on Jul 12, 2019, 01:39 pm
The code sample you provide is no option for me, as I only have a KLine available on my bike for interrogating the ECU, no CAN bus there...

K-LINE (https://lb9mg.no/2018/01/02/reading-obd2-data-without-elm327-part-2-k-line/)

Second post was K-Line.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 17, 2019, 07:05 pm
Maybe TriB still has similar requests left ?
It would be interesting what the scanner sends and receives. And what it displays!
This is how my project started:
A friend of mine got a healtech KDS adapter and the according software. Then installed a Software Serial Tool, which recorded everything which was transferred between the computer and the adapter.
Looking at the recorded and the shown data, f.e. RPM gave me the calculations and the right PID´s.

But he sold it and we did not got further to see what to send to get the fan turning, moving the exhaust valve, read the troubleshoot codes, read mapping, write mapping, ect. This were the interesting things I need to know :)

If the scanner works without a PC, you can attach a device in between, which just writes everything on a sd card. Should not be that complicated  :smiley-cool:

My knowledge is quite good at Kawasaki and okay for Suzuki (got both in the garage). But I got spare knowledge about Honda and none about Yamaha. I´d love to learn more about their protocols and stuff.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Kea09 on Jul 29, 2019, 10:34 am
Hi ALL,
    Thanks a lot of all information available here, I going to make myself Gear indicator and also coolant temperature, but when I requested that seems the coolant temperature quite lower than the ambient temperature even I have stopped the bike for a whole night(No start engine), in the morning that the ambient temp was around 29 Degree C but my calculation I got only 12 Degree C. for coolant temp., My bike is Ninja1000 year 2017 with the KDS plug with 6 pins.
I also tried with other bike like a Z800 with 4 pin KDS connector and the result it correct corresponding with Z800 display.
I used a formula (a-48)/1.6, this formula available here (Thanks a lot for provider).
I am not sure I have requested correct  requested or not, I used 88 11 F1 02 21 06 AB. and retuen 80 F1 11 03 61 06 XX 5C (XX is a byte I use for calculate)
Kindly please help with the fomula.
Thanks a lot.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Jul 30, 2019, 09:34 am
Hello Kea09,

I was also struggeling a lot with the temperature. It seems to fit and after riding around it was totally wrong.
Many of the findings (Speed calculation, Air pressure, ect.) in the ECUhacking-Forum were wrong.

But what seems to be correct is:
Offset = -30
Resolution = 0,625

In my code, I subtract -10 because the OBD2 standard needs a offset from -40.
The resolution means 0,625 * 256 = 160. Every value base on 256. Calculation with decimals is bad, so try to work with integers as long as possible.

Code: [Select]
coolantTempCelsius = ((a * 160) / 256 ) - 30;

Good luck!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Kea09 on Sep 08, 2019, 02:23 am
Hello TriB,
       Thank you so much, I will test it again.
DO you know the reason why Kawasaki changed to type of he KDS connector, the old model that we have 6 pin, then replaced with 4 pin and right now changed to 6 pin again, like a Jinja1000,Z900.
Thanks.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Sep 08, 2019, 12:11 pm
Hi Kea09,

I can only guess.
In former times, you could bridge two pins, to receive a FI code (Failure Information) on the bikes display.
Then you got K-Line, L-Line, VCC & GND as we already know.

The newer bikes (from 2017) must relay on the OBD2 standard, since EURO4 homogenisation.

There might be both, KDS and OBD2 separated at the same plug to support all ancient diagnostic devices.

Since now, I haven´t found reliable infos about the new 6-Pin plug.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: sudolea on Sep 14, 2019, 03:43 pm
Do you mean you're looking for the connectortype to order ? (as I have recently bought a connector of as well the 4- pins as well as the 6- pins connector)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Kea09 on Oct 29, 2019, 10:39 am
Do you mean you're looking for the connectortype to order ? (as I have recently bought a connector of as well the 4- pins as well as the 6- pins connector)
No, I already have a connector, But I only get the different reading on the coolant temperature on Z800 and Ninja1000 2017. The software I wrote that can read the temperature  same as on the Z800 dash meter, but when I  tried to apply the circuit and software I made only the coolant temperature was different, battery, gear were okay, at the ambient temperature (30 Degree C) I read the data from Ninja1000 that I only get 12 Degree C. But for Z800 it the same as an ambient, even start the engine, the reading on my project and Z800 dash monitor also the same.
I don't know the formula to calculate this parameter especially on ninja1000 year 2017, the different of both model was the connector type, 4 pin and 6 pin. I don't know maybe the generation changed from kawa.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Oct 29, 2019, 10:51 am
Hi Kea09,

there are two different calculations, which I found in KDS:
1 Byte temperature: (A * 160 / 256) - 30 °C
2 Byte temperature: (A * 256 + B) - 40 °C

But the equations are older then 2017.
Just post the HEX value and the real temperature and maybe we find out  8)

Did you found any other differences between these models, yet?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Kea09 on Oct 30, 2019, 08:09 am
Hi Kea09,

there are two different calculations, which I found in KDS:
1 Byte temperature: (A * 160 / 256) - 30 °C
2 Byte temperature: (A * 256 + B) - 40 °C

But the equations are older then 2017.
Just post the HEX value and the real temperature and maybe we find out  8)

Did you found any other differences between these models, yet?
Hi TriB,
     The Z800 is mind but the Ninja1000 that was my friend's bike, unfortunately I cannot find the HEX file I saved, 555 I will check with my friend again.
 
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Mar 26, 2020, 04:32 pm
Just want to let you know that I'm back to investigate the KDS protocol. My ambitious goal is to find more features, like actuator tests and downloading/uploading data. I will use a very systematic approach by staying close to the ISO 14230 protocol documentation. I also want to try to find useful information in diagnostic software by decompiling or any other reverse engineering technique.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Mar 27, 2020, 10:36 am
Hi Scissor,

nice to see you back again!
These things have also been tested by myself. The actuator test just gave me error codes (I tried to use the Suzuki SDS approach) and the Up-/Downloading feature requires a dealer code.

My findings were: The ISO14230 is a great document (14230-3s) but most features are not implemented in KDS. The SID are responding with a "not supported" or "unknown".

What most others do, is to use the ECU´s very own diagnostic port. It was created for the software developers and hardware creators. That way, it was possible to download the whole software and mappings.
That´s another port, which might only be accessible by opening the ECU.


Currently I´m much further with Suzuki. Got several applications which indeed could be decompiled and or reverse engineered. This was very helpful to find the right calculations and stuff.
Right now, I got a Healtech diagnostic tool for SDS which easily can be sniffed on the usb port. But that´s not necessary anymore, because I created a tool (https://raw.githubusercontent.com/HerrRiebmann/KDS2Bluetooth/master/ECU%20Emulation/Images/Hex%20Reader.png), which can read and calc the values directly.

Let me know where I can help you or where we can work things out, together :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Mar 28, 2020, 10:07 pm
I'm now just putting together a new testing board, and started decompiling the KDS software. I hope to make some progress next week.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Apr 05, 2020, 11:35 am
hi, I just released a library that can use both the KDS (kawasaki) and the SDS (suzuki): KWP2000 (https://github.com/aster94/Keyword-Protocol-2000)

I am looking for people with honda/yamaha because i can bring the library also to these bikes!
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Apr 05, 2020, 07:10 pm
I've looked at your code, and I'm truly impressed. Good job!

I have now put together a board for testing purposes. The nice feature is that I can control the communication remotely, because I have also used an ESP 8266 wifi chip. So the board keeps the communication with the bike alive, and I can test any request message nicely from my desk while my bike is in the garage.

I have spend most of my time on disassembling and decompiling the KDS software. I have found all of the important functions, which are also described in the ISO 14230-3 protocol. Now the tricky and time-consuming part is to actually make sense of the decompiled code.

However I have already fully reverse engineered the simpler functions like start/stop communication and start/stop diagnostic session. And I'm pretty sure that at some point (although it may take a long time) I will be able to reverse engineer the remaining functions.

Edit:

I have found these Service IDs in the KDS software:
Code: [Select]

0x10
0x11
0x12
0x13
0x14
0x17
0x18
0x1a
0x20
0x21
0x22
0x23
0x26
0x27
0x2c
0x2e
0x2f
0x30
0x31
0x32
0x33
0x34
0x35
0x36
0x37
0x38
0x39
0x3a
0x3b
0x3d
0x3e
0x80
0x81
0x82
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Apr 06, 2020, 10:54 am
I've looked at your code, and I'm truly impressed. Good job!
Thanks :D i really appreciate!

can I ask why are you reverse engineering the KDS instead of writing a software from zero? Are there some
hidden features which are not described in the ISO 14230-3?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Apr 06, 2020, 12:07 pm
So far I've (mostly together with Trib a couple of years ago) found that most features described in the ISO 14230 documents are not supported by Kawasaki, or at least my Z750 from 2004. By decompiling the KDS software I hope to find which functions are supported, and more importantly, which manufacturing specific data bytes are required.

For example, as far as I know, for Kawasaki it is still unknown which requests are necessary to start actuator tests. And also if we manage to get the key for the Security Access, we may be able to do more advanced stuff.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Apr 06, 2020, 12:21 pm
Scissor was faster  8)

Yes, reprogramming the ECU, changing the immobilizer / learning new keys, driving/testing motors & sensors and stuff. Faking values, setting a required RPM for testing...
Reading/Writing the firmware is described within the ISO-Protocol, but does not work like that.
Testing the fan, exhaust valve, etc. works fine with Suzuki, but not with Kawasaki. There must be a difference, which the KDS-Software got inside, somewhere.

Tried to unpack the Healtech Software, but did not get further, due to no obvious tables or information I understand.
It was easier just to sniff the data via USB and also use the example files or own recordings from that software.
That way I could optimize several Suzuki calculations and understand the DTC stuff better.

The Kawa conversions are resilient, by reverse engineering the KDS-Software (but in another way) and some mathematical findings from Scissor  :D
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Hiddenvision on Apr 06, 2020, 04:18 pm
Not promising but
disassembling and understanding software is one of my abilities.
Happy to look if needed.

HV.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Apr 06, 2020, 09:15 pm
All this would be astonishing! I am planning to stay on a "softer" level and stop my library at error codes and sensors

maybe fan tests, and some little other stuff but anyway i am not planning to do too deep
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Apr 09, 2020, 06:18 pm
Breakthrough! :) I discovered how to get security access to the ECU!

The procedure is as follows:

1. A seed is requested, which the ECU will provide in its response.
2. You will have to respond by sending a matching key that is checked by the ECU.

However, non of this is described in the ISO 14230 documents as it's manufacturer specific. So I was afraid that the seed-key pairs were matched through complex encryption algorithms. But fortunately I have discovered that it is actually extremely simple.

There are just three hard-coded seed-key pairs.

Code: [Select]

Seed 13 52 43 64 75
Key  63 27 53 67 42

Seed 57 48 58 49 58
Key  30 20 39 48 74

Seed 58 37 48 45 95
Key  58 49 57 69 84


For example. this is what I did today as a first successful test.


I got 13 52 43 64 75 as a seed.

Code: [Select]

TX 80 11 F1 02 27 01 AC
RX 80 F1 11 08 67 01 13 52 43 64 75 34 A7


So, the matching key is 63 27 53 67 42.

Code: [Select]

TX 80 11 F1 07 27 02 63 27 53 67 42 38
RX 80 F1 11 03 67 02 34 22


Done!
 
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Apr 11, 2020, 10:45 am
Wow! Great  :smiley-eek:

I´ve read that functionality somewhere... Must have been somewhere in one of the 3 ISO14230 or the KWP2000 protocol. But too long ago, that I can remember. But it was in there!

From that, they created the OBD standard, which uses a similar functionality. Many manufacturers are sending the very same "seed" all the time, so it also is just a ridiculous safety wall :D
Someone hacked his Prius and overtook steering and acceleration via OBD2 and CAN-Bus. Everything with a single key, found out after 10 minutes of bruteforcing :)

Are you now able to use the download function?
Do you have to enter a different mode, that the SID´s dont´t throw an error on a request, any more?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Apr 11, 2020, 12:16 pm
Yes, it follows the ISO 14230 protocol. This is described in the ISO 14230-3 document. What surprised me most is that apparently the seed-key pairs are completely independent of the bike i.e. it should work for all Kawasaki motorcycles.

I have not tried to use other functionality yet. Because I am really focusing  to make sense of the decompiled KDS software. At this point I have a decent understanding of the possible requests, which I'm now writing down comprehensively.

For instance, I have found that once you have security access you can start a "programming" diagnostic session, instead of the "workshop" diagnostic session (this terminology is really used in the ISO 14230 documents). This is probably required to access all the other functions like actuator tests and downloading/uploading and so on.

I hope to have a complete understanding of all the possibilities in the following weeks.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: aster94 on Apr 11, 2020, 11:11 pm
Code: [Select]

Seed 13 52 43 64 75
Key  63 27 53 67 42

Seed 57 48 58 49 58
Key  30 20 39 48 74

Seed 58 37 48 45 95
Key  58 49 57 69 84


Interesting! actually I didn't understood how from 13 52 43 64 75 you extrapolated the 63 27 53 67 42
Could you explain?
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: Scissor on Apr 12, 2020, 09:02 am
I have not tried yet to find out how the seed and key are related. Actually I think I'm not even going to try, as I believe there are most likely no other seed-key pairs.

Because I found that in the KDS software there are literally just three if statements that compare the received seed with the three hardcoded ones. If the match is found, it just sends the corresponding key.

Perhaps there is some connection e.g. it could be ASCII, mathematical operation or maybe some bitwise operation. But in the end it does not matter as I really believe there are just three seed-key pairs.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: windoze_killa on Aug 07, 2020, 03:15 am
Did you ever find a waterproof display and case?

What do I need:
  • Arduino Nano, BlendMicro (http://redbearlab.com/blendmicro/) or similar (included Bluetooth?)
  • Bluetooth-Shield (unless already included)
  • Waterproof LCD Display - Step II
  • Waterproof case - Step II


Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Aug 07, 2020, 10:41 am
Hi windoze_killa,

no, I´ve buried the idea of an external display.
All informations (except the gear) would be nice to have or just playing around.
So I decided to focus on the OBD II compatibility, so I can use any app or device.

Currently I´ve created the second version of an unique PCB design. There is an SPI for future purpose, which could probably being used for that.

Since I also got a Suzuki bike for racetracks, many optimizations have to be done in the code to speedup the communication. That´s my work for now  :smiley-yell:
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: windoze_killa on Aug 10, 2020, 03:35 am
I am actually trying to get the data stream from the ECU to the cluster. I have captured some data but I am having no end of trouble working out what it all means. From what I can work out in is uni directional so there is no handshaking that I know of. I want to play around with a colour display for speed, tach, indicators, gear and clock. I know I can buy one but where is the fun in that.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Aug 11, 2020, 10:06 am
I´m completely with you ;D
Found my drawings where to put what on a display (Voltage, Gear, etc) and a demo sketch, which was way to slow to update a little oled and handle the KDS.
Probably an ESP32 would be the better solution!

Since I got a small 3D printer, a case could be designed pretty fast. With the right plexiglass and silicone, it should be rain-proof!

Do you want to fetch the data from the ECU or directly from the tachometer?
What´s the struggle with your data? I guess I currently have all data and calculations available  8)

Right now, I create a data class, where I put everything in. Then I can optimize readings from temperature (which does not change so fluently) and speedup rpm, throttle or speed.
Suzuki reads all data at once, so there is even much more potential for performance!
Sadly lots of work and space for issues...
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: 2gnospam on Sep 09, 2020, 09:24 pm
Noob here.  Great thread!  I am trying to help a friend out who wants to log ECU data from a Kawasaki SX-R 1500 jet ski to an AEM AQ-1 (available in CAN or OBII) versions.  Any idea where I should start.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Sep 10, 2020, 12:07 pm
Hi,
I watched the manufacturer video about the AQ-1.
This is made to be connected directly to the ECU via CAN-Bus or OBD II connector.
OBD II is the way to go!

What have I done:
I connected the Kawa-ECU with an Arduino and transfer the Data OBD II compatible via Bluetooth.
Within that, I had to convert the requests and calculations, to be within the official OBD II ranges.

What you need:
Connect the Kawa-ECU with an Arduino and the OBD II AQ-1 on the other side, both via (Software-)Serial.
And you also need to translate between both parties.

Hardware:
So you need to create an adapter, which has an L9637D on both sides, which converts the K-Line (OBD II connector) to a serial signal.
Instead of my Bluetooth-module, you have to use the second L9637D.

Software:
Instead of receiving AT-commands (control commands for OBD II dongles), you will now get the whole initialization sequences and messages.
I´d ignore the initialization request (some high and low on the Serial port) and concentrate on the messages.
After receiving the first request, you can do the initialization yourself.

The requests itself are now with header, length and checksum. My code expects only the SID and PID via bluetooth. So you have to rewrite that part and process that stuff and extract SID & PID.


From my point of view, it´s possible!
Change the hardware layout, delete the bluetooth & AT stuff and optimize the method, which receives the OBD requests to process or ignore the format, header, length and checksum.

Good luck  :)
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: budzioq on Oct 19, 2020, 01:48 am
Hi, I have a problem with connecting to the 2013 Kawasaki ER-6F ECU. When the engine is off, I can connect without any problem, but as soon as I start the engine, communication is interrupted and I cannot re-establish it. The connection is established in the standard way. First, to start communication, after fastInit procedure I send 0x81,0x11,0xF10x81,0x04, after a positive response I send a request to start a diagnostic session (0x80,0x11,0xf1,0x02,0x10,0x80,0x14) again I get the correct answer and then I can query the ECU about information that interests me. However, if at this time I start the engine, the ECU breaks the current connection and no longer responds to the start communication message. I checked different times (2s to 13s) between repeating the startup procedure with no results. What could be the reason for the ECU breaking communication ? I attach a graph (https://megawrzuta.pl/download/f3d7db9a06a5ae5ba51c68d953a267c8.html) from a logic analyzer - opened in Saleae Logic Software (free) - the engine starts in 12.27 seconds of recording.

Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: TriB on Oct 19, 2020, 08:56 am
How did you design/connect the board?
I expect the ERna (How we call it in germany), will give some inteferences on the power, with the alternator running.
Are you sure, the Arduino is still running? When it´s powered with more then 12V for a longer time, it will overheat.

So, I guess it will be related to the powersupply.
Title: Re: OBD II Bike Connector - Pass via bluetooth
Post by: budzioq on Oct 19, 2020, 07:40 pm
I don't use Arduino, but STM32. For power supply I use 7805 stabilizer with 100 uF capacitors on the input and output. Then 5V supplies directly the LCD TFT and the 3.3V stabilizer of the STM32 module. STM works for sure, I have messages on the display informing about subsequent connection attempts.