Go Down

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


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 :)


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!


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.


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?!


TriB: tnx for all your information

The device is working (with modification on electrical circuit) - first test with torque pro


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


What connector name brand type is used to connect to the KDS connector on the bike.
Hi keremoktem,
I expect it to be this one.
It is the most common on lots of Kawasaki.


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.




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 :)


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.


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!

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.

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)

Good luck!


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


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


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



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

Go Up