Bike interface OBD

Hey, it has been a while im posting here but im still watching. I just wanted to say sorry that i removed my project from github. Im not active on it and someone has probably done better work so thats why.

TriB: The approach here on this thread, yes. The solution from malexsky, one poste above won´t work for your bike. It does not support OBD2.

Hi @TriB I will keep waiting for you :grinning: :-X

After several canceled events (and some period of time procrastinating), I´ve finally managed to get to the racetrack :muscle:t3:

Testing went well, instead of anything else…

My collegue is fine, but due to an open wound, we had to leave immediately.
So, all in all about 15-20 minutes of driving.

Got two amazing optimizations, which went well:

  1. Storing all values temporary
  2. Introduce an persistend errorlog

Due to the fact, SDS gives you all values at once, I´ve added a storage, which the OBD2 app (in my case the Virb XE camera) requests one by one.
On every RPM request, I submit the request to the ECU. Everything else comes from this very storage.
As you can see, the performance is amazing :smiley:
Speed is off, but it´s not offered by the ECU. It´s a GPS based number.

The errorlog takes 10 bytes per entry. A counter, the AT-command, SID / PID and a code what happend. My preperations seemed to be precise enough, to have it empty after two rides :sunglasses:
Didn´t expected that, after only testing in my garage.

Within the next days, I want to create another video around the ECU hacking. For Kawa & Suzuki, code, functionality, the tools I´ve used and written by myself, etc.
Until now, I´m not sure if I can publish all the code and data or if I will just make it partially public, to rebuild it yourself.
Stay tuned :slight_smile:

1 Like

Hello guys.
First I'm really impressed from the results all you have reached.It was a pleasure for me to read the thread, thank you.I really appreciate all your effort to finish the project and to share with us the results. So far I have tried to run the code from o5i 006 and 007 but the ide couldn't compile it. There is something wrong or missed with SdFatUtil.h library. Does anyone else have the same problem and what is the solution?

Hi guys great work with the development. I had a question with regards of using a LINbus interface IC.

The IC I am using for my hardware is MCP2025-330E/SN
Datasheet https://ww1.microchip.com/downloads/en/DeviceDoc/20002306B.pdf

When I send the Honda Initialize command the LIN output signal is not correct see log below.
If take logic analyzer log at the Serial TX pin it measure correctly 70ms low then 120ms high.

See attached sketch. This sketch works perfect MC33660.

In the datasheet for the MCP2025-330E/SN I read something about TXD/LBUS TIME-OUT TIMER on page 7. I dont know if this is causing the issue here.

Please any help is appreciated

INT_working_ATTINY4411.ino (1.4 KB)

Using the same code, which works on your MC33660, but not on your all in one IC, will be caused to an hardware difference, I guess.
Did you compared the voltage on K- & (optionally) L-Line?

Ending the Serial, might cause the pin to remain high, or will be set to low, depending to the device and library.
This might also be a difference between those two.

1 Like

Hi TriB,

Thanks for your reply.

The goal is use the the MCP2025-330E/SN in my design.

I want to send the Honda INT command to initialize the ECU. When using the same sketch instead of the 70ms going low its fixed to 22.65ms. I cannot seem to change this time by modifying the code.

I can send data to the ECU and it works perfectly using MCP2025-330E/SN but I just cant initialize it

I wanted to see if someone can help me figure this out. I will pay for their time.

Thanks

Hi,

I have been watching this since the beginning hoping someone would post some info on Yamaha (YDS), but have not seen anything as conclusive to date. Has anyone managed to do anything for Yamaha? I have looked everywhere for information, PIDs, etc. but nothing anywhere.
Would anyone be interested in guiding me on what to do to scan my Yamaha for codes, I don't mind purchasing what is required and getting it done. I currently have a L9637 configured and several Arduino options. @TriB or @aster94 would you be interested? Thank you.

Hi trism,

as far as I know, the older yamahas does not have a diagnostic K-Line.
There is a K-Line, but this connects the dash and the ECU. This seems to be a bit documented and probably you can grab those signal.
Then yamaha introduced CAN-Bus to their superbikes and later on, down to the MT-series, etc.

So I think you cannot use the L9637 as described here.
I have a diagnostic device available here, which pretends to "speak" YDS, but I´ve not tested it yet. The model selection only covers some 125cc´s.
And I have no Yamaha with a diagnostic plug among my friends.

With a bit of a luck, I´ll find someone on a racetrack, willing to let me test something, next year.

Hi @TriB,

Thanks for the reply, yeah the bike is a 2008 YZF R125. Exactly as you said, it does connect to the dash. The odd thing is, everything works on the dash with it disconnected, but have seen a WR125 present an error code with it detached. So I fear it may as you say, not a full k-line. I am currently however flashing the ECU via K-line and the official Yamaha Service Manual states you can monitor sensor data and that engine speed, coolant temperature and fault codes can be displayed with the FI Diagnostic Tool. Any thoughts?

That´s interesting!
I guess there is a huge difference between the Yamaha Motorbikes (R6, R1, MT07-09-10, etc.) and Scooters and 125ccm machines.
The bigbikes does not have those plug. They do have a possibility to shortwire a diagnostic port, to see the errorcode (FI) on the dash and the K-Line between ECU and dash. Which is not intended to be used for diagnostic.

But your image prooves a diagnostic plug! So I made a little test and took my diagnostic device (which has mostly 125ccm models avaliable) and hooked it up to my K-Line Adapter.
A little code just sends everything via Bluetooth...

Selected a YZF-R125 and gave it a go:
It tells you to start the ignition, while doing that, it penetrates the adapter by constant 0xFE values. As long as you press "Enter" (that you started the bike) and the initialization started:
FEFEFE00C133F0816500C133F0816500

The zeros might come from the FastInit protocol, everything else seems to be the initialization request, send out for several times:
C1 33 F0 81 65

AFAIK this is a standard KWP2000 (Keyword protocoll) message.
0xC1 should be the header
0x33 the receiver
0xF0 the sender (it´s mostly F1, so try to better search with that instead)
0x81 Start communication request
0x65 Checksum (Sum of all values before MOD 255 [or just use uint8_t and let the overflow do the rest])

I cannot find much about this exact message on the internet. There was an ECU Hacking Forum, which is down :frowning: This allways was a good startingpoint for different manufacturers. But changing the tester present to more standard 0xF1, you will find uncountable documents and implementations for KWP2000.
Like this explaination: Reading OBD2 data without ELM327, part 2 – K-Line – M0AGX

  • KWP2000 – fast initialization
  • Requesting a PID – KWP2000

These seem to be your startingpoint, understanding the protocol and go on with reverse engineering.

It seems your bike does have K-Line diagnostics :smiley: And it rely on some kind of standard!

Brilliant news this! Thank you so much for all the effort, information and starting point! I really appreciated it. I will get reading/learning, attempt to setup some testing/probing and more than likely be back with some more informed questions and update. Thanks again.

Any ideas why my L9637D would return a response the same as my request?

I am using an ESP32 module with L9637D pcb connected as per @aster94 github (GitHub - aster94/Keyword-Protocol-2000: The KWP2000 is a communications protocol used for on-board vehicle diagnostics systems (OBD) by Suzuki (SDS), Kawasaki (KDS), Yamaha (YDS), Honda (HDS) and possibly more. It is standardized by ISO 14230).

Initially, I thought it was the ECU but I disconnected everything from the one side of the chip (pins 5-7, namely Supply Voltage VS and Common GND) and get the same result. Disconnecting the TX I get now response. I have checked everything several times and all looks good, but obviously something is wrong.

When they state Common GND on the L9637D datasheet, does that mean the ESP32 should be on the same circuit ground (powered from the same source)?

Yessss, same ground

This echo is covered by my implementation (which was adapted from Kawaduino) here and by Aster94 here.
But I never investigated where that really came from and also included it as an option into the ECU Emulator...

The L9637D´s job is to convert a two wire signal into a single one and furthermore decide if the data is for you or from you.
I guess it cannot do that properly, if GND is not the same. Then you are sending out data by Tx and receive it by Rx at the same time.

If I remember right, I´ve never seen those echo from the ECU as well :thinking:
I just rely on Kawaduino´s code :innocent:

Well thank goodness I am not crazy here and imagining things. Thanks once again for the info. I hadn't got as far as reviewing code options and initially attempting a simple test to see if things are connected. I guess the initial test worked despite it being a negative outcome :crazy_face:. I will pull out a power buck converter and run the ESP32 off that from the 12v supply (I would like to avoid running the ESP32 at 12V) and proceed with some more testing. I will also add the similar code additions to my test script to account for the echo. I'll be back :wink: