Go Down

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


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


I came along this interesting article for this atomic issue I was talking of (didn't read it completely, though) : here

Maybe not your problem, but it might be (and I wouldn't exclude it)...


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


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


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


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.


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!

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

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.


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


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.

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



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.

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


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


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.


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


I even have a scanner that if anyone knows how to tell me how I can extract information from him!!


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

Go Up