Not working with Yamaha YZF R125 Gen 1 (2008-2013)

[tmargot]

I could not get this to work. I was hoping for this to work to broadcast ECU data on a race bike to a mobile laptimer app. I also tried commenting out the function configureKline() which stated maybe Yamaha and Honda should not run this in the comment. Any ideas?

[aster94]

Hi, it is not working because you need to find the PIDs for the sensors you needs (rpm, speed, ecc)

See:

Keyword-Protocol-2000/src/ISO.h

Lines 140 to 149 in 243d79a

	else if (brand == YAMAHA)
	{
	/*
	As far as I could understand the YDS (Yamaha Diagnostic Protocol) protocol, it is close to the Honda protocol.
	There are no sender-/receiver-addresses or header information. Just the checksum at the end.
	You initialize the diagnostic mode by sending 0x80 and from then on you can just submit 0x02 and it gives you:
	Rpm, Speed, Error, Gear & Checksum.
	*/
	ECU_addr = '?';
	}

If you are able to find more info online I may try to help you

[tmargot]

Hi, thanks for the reply. Is this also for the k-line initialisation? Using your example, I enter i and it does not connect. I will do some internet digging for PIDs. Thank you

[aster94]

yes, this is all needed for the initialisation, the example without the correct sequence won't ever work

[terrafirma2021]

HI, any ideas on where to find PIDS ?

I have a yamaha xt660x 2008

There are lots of us who would like to attempt this, but we are stuck,

Were would we find PIDS?

How could we look for them in the ecu ?

Thanks as always

[terrafirma2021]

I can enter Diag mode on the Dash, and cycle though the diag numbers to know what each diag is and its value,

Would that be of use ?

[aster94]

Hello, unfortunately the known PIDs have been found with reverse engineering of diagnostic tools made by the constructors (yamaha, suzuki, ecc). So if you haven't found them on google your best chance is to get one, otherwise it will be quite difficult to find them Il giorno sab 14 ott 2023 alle ore 20:56 terrafirma2021 < ***@***.***> ha scritto:

…

I can enter Diag mode on the Dash, and cycle though the diag numbers to know what each diag is and its value, Would that be of use ? — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBUBTUP6JGRMDLIJWGVRBLX7LN4PANCNFSM47TERATQ> . You are receiving this because you commented.Message ID: ***@***.***>

[terrafirma2021]

Thank you for the prompt reply.

Google yields no results

I will try to source this info out, because prior to 2017 ODB 2 YDS plugs didnt exist, thus the DIAG was used on the dash to see faults issued.

i know woolich racing and ftecu have flashed ECUS and read ecus with ease,
even though the info is not publicly sourced, it shows that people may know somewhere.

If I find any table info, I will let you know.

thanks

[tmargot]

@terrafirma2021 - I can flash the ECU on Gen 1. I started this post as I was interested in doing this for direct. What I do know is that the clocks error code purely work on the k-line. This could possibly be intercepted. I tested this by unplugging a sensor and seeing the error code, and then unplugged the k-line bullet connector and no error code showed.

[terrafirma2021]

@tmargot tmargot
Thanks for the reply, glad to see you are also active here,
I have also managed to bench flash the ecu, using an lone elec usb to Yamaha odb cable, (FTDI FT232RL) (I had to splice the end to pin to the ecu
I was trying to passively sniff the k-line, but I could not get anywhere and gave up, i also didn't have the correct scope to monitor data

The dark arts of the k-line are being lost now due to the ODB port standard, and the information needed to complete the task seems a long shimmer of hope.

My idea would've been to use an ESP8266 to create a simple web server with data logging, which would then be connected to another device able to use the data.

But without knowing the correct values, or even how to solve them in maths's a case of waiting,

Hopefully one day :)

Cheers

[terrafirma2021]

HI @tmargot @aster94 if you look on my GitHub I have solved the YDS
I found another fork of a yamaha Datalogger from AVR to rasp pi

The photo example is taking the data stream and showing the 4,5,6 bytes wide frame, which makes logging the ecu dead easy
by formatting the data in real time 3 ways, as sometimes ecu frames are 4 5 6.

I have made a k-line data logger with a USB KKL ODB cable which works in python

This means that anybody can buy a USB cable now and read data from the k-line, as some people may not have the skills or the kit to build the l9637d.

I can confirm that my findings are correct to the sum that was worked out in the RPM value.

The way the k-line handles data is each frame contains the stats aimed at the dash.

I will finish up the main tool and merge both tools into one.

Then the next stage is to Perform a MITM so on boot we can enter diag mode to log every sensor on the bike, whist the dash displays the original data frame required for it to function correctly.

@aster94 If you need frames have a look on my repo, i have logged a chunk of my ecu comms and i have split the blocks for easy understanding
( Edit i have added the log file to here for you to find it )

https://github.com/terrafirma2021/Yamaha-K-line-Tool/blob/main/ECU%20Log.txt
Thanks and glad to have found this repo.

[terrafirma2021]

Engine Running
1st Byte is Request 0x01
2nd byte is RPM (value * 50)
3rd Byte is Velocity
4th Byte is Error code
5th Byte is Coolent Temp
6th Byte is Checksum ( 2+3+4+5=6) Control byte is never included in the checksum
01 31 00 80 2e df
01 31 00 80 2e df
01 31 00 80 2e df

5th Byte is Checksum (1+2+3+4=5)
31 00 80 2e df
31 00 00 2e 5f
31 00 00 2e 5f
31 00 00 2e 5f

[aster94]

That's a very good news that yamaha uses the same protocol!
I wonder what happends is you edit the config of this library src/ISO.h
You should just change yamaha_request_sens, at the bottom you assign the pid to the sensors and in the cpp file just change the formula for the rpm

[tmargot]

@terrafirma2021 - unbelievable thank you!

[terrafirma2021]

@aster94 im not done yet, i am going to buy another KKL cable so i can work out who is sending.

I managed to get into the DIAG Menu and the C0 menu via unplugging the dash and sending the commands

There was also an E and F menu also

but sadly I cannot replicate it every time,

I also note that sometimes data is being sent 00 00 01 01 00 00

but other times it's 00 00 01 01

When I get another KKL cable, I will be able to work out the order of data sent to hit the diag menu every time.

On the YDS I watched a video and there is a live logging method whilst the bike is running.

I'm hoping that we can do the same with the bike running to log everything.

Maybe a dream, but the only way to test is to get the other KKL cable and have a go

Thanks

[D4rk4]

@terrafirma2021 any progress with Yamaha proto?

[66zai]

This is an automatic reply, confirming that your e-mail was received.Thank you----------------------------------------------------------您的E-mail我已经收到，如果看到定会很快给您答复。

[terrafirma2021]

@terrafirma2021 any progress with Yamaha proto?

Hi @D4rk4, the Yamaha protocol uses a switch case menu system which is navigated by sending bytes from the dash ( or the YDT tool) to the ECU.

To poll the menu you need to initiate coms via sending CD until the sub menu system opens. I have fully decoded the protocol and on my repo if you have a look you will find the sigrok sniff of the cases, and their responses.

When the starter is pressed, the ECU exists the menu, and you are no longer able to enter the diag sub menu.

The furthest you can go back in is the RPM.

I am building a ESP32 BLE ELM327 yamaha kline to odb2 convertor which will convert live data to odb2 can bus standard (this will enable any app that supports BLE elm327 to receive live data:
RPM
Speed
Temp
RPM
Error codes

There is nothing more able to be obtained via the passive sniff method.

I also created a transparent uart bridge which did allow control to call the diag menu on key turned, ( because you cannot stop the dash from polling the ecu, you have to unplug ( like the OEM YDT requires ) Or you create the bridge to control the flow of bytes.

I am currently finishing off my 3d printer to make a box, then i will push an update to my datalogger repo.

[aster94]

Nice work, I am happy that finally someone invested some time on Yamaha bikes! If you plan to use this library you will find a lot of useful function that manage automatically timing and repeated requests Il Mer 14 Feb 2024, 23:03 terrafirma2021 ***@***.***> ha scritto:

…

@terrafirma2021 <https://github.com/terrafirma2021> any progress with Yamaha proto? Hi @D4rk4 <https://github.com/D4rk4>, the Yamaha protocol uses a switch case menu system which is navigated by sending bytes from the dash ( or the YDT tool) to the ECU. To poll the menu you need to initiate coms via sending CD until the sub menu system opens. I have fully decoded the protocol and on my repo if you have a look you will find the sigrok sniff of the cases, and their responses. When the starter is pressed, the ECU exists the menu, and you are no longer able to enter the diag sub menu. The furthest you can go back in is the RPM. I am building a ESP32 BLE ELM327 yamaha kline to odb2 convertor which will convert live data to odb2 can bus standard (this will enable any app that supports BLE elm327 to receive live data: RPM Speed Temp RPM Error codes There is nothing more able to be obtained via the passive sniff method. I also created a transparent uart bridge which did allow control to call the diag menu on key turned, ( because you cannot stop the dash from polling the ecu, you have to unplug ( like the OEM YDT requires ) Or you create the bridge to control the flow of bytes. I am currently finishing off my 3d printer to make a box, then i will push an update to my datalogger repo. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBUBTXNHZ37NI3AYYEYJVTYTUYC7AVCNFSM47TERAT2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJUGQ3TKNRYGU3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>