Go Down

Topic: OBD II Bike Connector - Pass via bluetooth (Read 41528 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 ...

Go Up