Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Yamaha FI Diagnostics tool


Guru

Status: Offline
Posts: 2338
Date:
Yamaha FI Diagnostics tool


Lets start a thread here about Yamaha FI diagnostics tool...

- Its based on a PIC 16F73, on top of the PIC there is a sticker YM-OUZ001_A propably indicating the firmware version.
- Looks like there is a 6 pin CN2 for programming the PIC
- The switch 1 is used to configure the between Metric/Imperial (e.g. Celcius vs Fahrenheit) operation
- The clock speed for PIC seems to be 4Mhz
- CN1 connects pin1 +12V, pin 2 n/c, pin 3 signal (propably K-line), pin 4 Gnd




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Peak to peak voltage is around 9Volts. When connecting the signal to K-line the signal can be monitored.

The FI Diagnostics tool seems to send a package to ECU to which the ECU replies.

This is the FI Diagnostics package to ECU without a reply from ECU.

FIDIAG_protocol.jpg

When reading the replies from ecu it looks like one character could be around 600us long then there is an idle periood of 700us after which the next character is sent.

FIDIAG_protocol2.jpg

So the next step is to somehow try to estimate or calculate what is the baud rate etc...

In industry there is the following rates being used: 10400 for SDS, 7800 for american automotive industry.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Quick calculation would show that 8 bits over around 520us would mean about 15300bps.

I am able to see alike values (e.g. varying from 0 to 10) in packages with this baud setting e.g. when setting the CO value with FI tool.

Based on quick testing e.g when setting CO command Fi tool sends:
Command 0x80
Value 0x80 (is baseline i.e. 0)
Checksum 0x00
--> Ecu responds 0xCA

Respectively when monitoring a diagnostics value the Fi tool sends:
Command 0x40
Value: 0x01, 0x03, 0x46 or what ever the command is
Checksum 0x41 etc...
-> ECU respons 0xCA byte1 byte2 byte3 checksum

Normal mode, i.e. mode button not pressed when power is on
Command 0x80
Ecu responds -> 0xA, RPM_lowbyte, 0x01, RPM_highbyte, 0x0
Note: temperature sensor not connected so can be indicating any value

These command and responses are based just on a quick test which means that these may and most likely contain mistakes and errors in details, but as a concept it should be a starting point. E.g. It is impossible to distinquish which bytes are actually sent by the FI Diagnostics tool and what are replies.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

More protocol info, this is from diagnostics mode...
FI Dianostics screen showing D01: 0
40 1 Diag> 5B CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 40 1
0 40 1 Diag> 5B CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 40 1
0 40 1 Diag> 5B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 40 1
0 40 1 Diag> 5B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 40 1
0 40 1 Diag> 5B CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 40 1
0 40 1 Diag> 5B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 40 1
0 40 1 Diag> 5C CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 40 1
0 40 1 Diag> 5C CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1A 0 0 0 1A CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1B 0 0 0 1B CA 1A 0 0 0 1A CA 1A 0 40 1

FI Dianostics screen showing D62: 7
0 40 3E Diag> 98 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 40 3E
0 40 3E Diag> 98 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 40 3E
0 40 3E Diag> 98 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 40 3E
0 40 3E Diag> 98 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 40 3E
0 40 3E Diag> 98 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 40 3E
0 40 3E Diag> 99 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 40 3E
0 40 3E Diag> 98 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1B 0 0 7 22 CA 1A 0 0 7 21 CA 1A 0 0 7 21 CA 1B 0 0 7 22 CA 1B 0 40 3E

FI Dianostics screen showing D62: 7, RPM=0
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E
0 40 3E Diag> 7E CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 0 7 7 CA 0 0 40 3E


-- Edited by PetriK on Monday 25th of October 2010 07:20:55 AM

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 11
Date:

Dear Petrik,

How I could get this F1-diagnostic tools and how to install at My PC at home.
do you know the link can I download the tools.


thank you

__________________


Member

Status: Offline
Posts: 11
Date:

Dear Petrik,

If you have some information about that, could you send to my email :
ravkyakri@gmail.com.


thank you

__________________


Veteran Member

Status: Offline
Posts: 28
Date:

15625 is a common baud rate used in Japanese ECUs.
If you want to see what data is being sent or received you need to monitor the pins on the PIC, don't forget that you always get an echo from the Tx signal.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:


Thanks - propably trying to figure out which pic pins are for tx and rx will shorten this process a lot.


PIC16F73-pinout.jpg
(EDIT - changed the pinout .jpg to a correct one with 28pin package)


ps. This is early phase at this stage - no ready to be installed products at this stage, maybe in a couple of months if I get some time for this.



-- Edited by PetriK on Sunday 31st of October 2010 02:02:11 PM

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The TX and RX pin seem to correlate with the protocol, and also showing echo wink.gif

Turned the device a couple of times on and off and did not notice anything that would look like a 5 baud fast init or something alike - so we may be somewhat lucky and can just start looking at the protocol

Here is what the oscilloscope shows when hooked into RX and TX pins of the PIC processor...

FIDIAG_protocol3.jpg



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Some more information based on some monitoring of the Tx and K-lines ...

Tx byte may contain something like below:

TxByte=0x01 - No buttons depressed during powerup of the ecu. Somekind of keepalive request for gaugedata. In this case RPM, IAT and running S/D code is displayed on the screen.

When the mode button is depressed during startup of the ecu then these bytes are sent

TxByte=0xCA - somekind of keepalive requesting last asked data package. This byte is sent even when button is not depressed.
TxByte=0xCE - Mode button is depressed
TxByte=0xCB - Up button is depressed
TxByte=0xCC - Down button is depressed

In every case after Tx there seems to be 5 bytes to be replied after around 2ms idle time.

Diagnostics_send: TxByte -> ECU_Reply: Byte1, Byte2, Byte3, Byte4, Byte5

Next step is to build an FI diagnostics tool master around the above presented scenarios.


-- Edited by PetriK on Sunday 31st of October 2010 04:43:41 PM

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Small progress, package 0x1 seems to work, but changing mode needs more debugging of the protocol ... this data is read with using the Hayabusa gen2 interface from Yamaha ECU.

FIDIAG_protocol4.jpg

Below some data for RPM conversion and S/D data...
 

        '
        ' Send command and receive data
        '
        SerialPort1.Write(c, 0, 1)
        System.Threading.Thread.Sleep(50)
        TextBox1.Text = ""
        i = SerialPort1.BytesToRead
        If i > 7 Then i = 7
        For x = 1 To i
            b(x) = SerialPort1.ReadByte
            TextBox1.Text = TextBox1.Text & Hex(b(x)) & " "
        Next
        '        ' Parse data        '        Select Case Txchar            Case 1                TextBox1.Text = TextBox1.Text & " >>> "                TextBox1.Text = TextBox1.Text & " RPM=" & (50 * b(2))                If b(4) > &H80 Then                    TextBox1.Text = TextBox1.Text & " S/D=" & (b(4) And &H7F)                End If                If b(4) = &H80 Then                    TextBox1.Text = TextBox1.Text & " FI LIGHT ON"                End If
        End Select
        '        ' Checksum calculation        '        i = 0        For x = 2 To 5            i = (i + b(x))            i = i And &HFF        Next        If i = b(6) Then            TextBox1.Text = TextBox1.Text & " CHKSUM=OK"        Else            TextBox1.Text = TextBox1.Text & " CHKSUM=FAULT"        End If
 



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

FIDIAG_protocol5.jpg



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 13
Date:

Mr. petrik
I am a motorcycle mechanic and electrician, working in official agent Yamaha
I hope my knowledge will be of great help to this project.
Yamaha motorcycles using the diagnostic Tool fi are the ybr-ys 250, xtz250
XT660 tenere and some models of atv.
One of the ways that you can test to see if this team diagnosis
works well, is to connect your financial diagnostic tool and start the motorcycle.
The reading you have is the rpm and engine temperature readings to compare these two instruments (tachometer and thermometer). I think it's way to know if it works correctly, because the bike is running and the data rate increases.
In training courses Yamaha reports that the communication protocol is ISO.

ps: google translated text, sorry I do not speak English, I hope you can understand

Sincerely,

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks - the text was very good and easy to understand.

The information that it is ISO really helps a lot, time to look into ISO protocol implementations...


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 13
Date:

PetriK wrote:

Small progress, package 0x1 seems to work, but changing mode needs more debugging of the protocol ... this data is read with using the Hayabusa gen2 interface from Yamaha ECU.

FIDIAG_protocol4.jpg

Below some data for RPM conversion and S/D data...
 

        '
        ' Send command and receive data
        '
        SerialPort1.Write(c, 0, 1)
        System.Threading.Thread.Sleep(50)
        TextBox1.Text = ""
        i = SerialPort1.BytesToRead
        If i > 7 Then i = 7
        For x = 1 To i
            b(x) = SerialPort1.ReadByte
            TextBox1.Text = TextBox1.Text & Hex(b(x)) & " "
        Next
        '        ' Parse data        '        Select Case Txchar            Case 1                TextBox1.Text = TextBox1.Text & " >>> "                TextBox1.Text = TextBox1.Text & " RPM=" & (50 * b(2))                If b(4) > &H80 Then                    TextBox1.Text = TextBox1.Text & " S/D=" & (b(4) And &H7F)                End If                If b(4) = &H80 Then                    TextBox1.Text = TextBox1.Text & " FI LIGHT ON"                End If
        End Select
        '        ' Checksum calculation        '        i = 0        For x = 2 To 5            i = (i + b(x))            i = i And &HFF        Next        If i = b(6) Then            TextBox1.Text = TextBox1.Text & " CHKSUM=OK"        Else            TextBox1.Text = TextBox1.Text & " CHKSUM=FAULT"        End If
 



 Mr. Petrik, you can send this software and interface scheme so I can do tests on my motorcycle ybr - XTZ 250, and see if the operation is correct?
I will record all the information obtained from checks on motorcycles and send them for you to analyze.
I have a motorcycle that has problems in the injection system and I think it would be a good opportunity to check with their diagnostic tool and see the results.
if you want to send privately, this is my mail: marceloariel67@gmail.com



__________________


Newbie

Status: Offline
Posts: 2
Date:

hi mate great project can you please send me you program and details on how to make the diagnostic cable i would like to test this on a r125 engine my email address is mayurjani@hotmail.com thanks

__________________


Guru

Status: Offline
Posts: 2338
Date:


Sorry - due to lack of time never further than what is documented here...


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 5
Date:

Hello
Some time ago I made a logger to see the communication, to study the communication between the ECU and the immobilizer. Use a pic to 20 mhz, to use the serial port to a standard speed.
According to my tests the communication of the xtx660 was 15385 baud. You must use a circuit to adjust the levels as the pic works qeu 5V bus and a yamaha 12v.
If anyone is interested in the circuit and want to document the commands used by the ECU, I can post the circuit used
regards

__________________


Member

Status: Offline
Posts: 5
Date:

Data captured
3E E1C643C5AF 3D 4A5D4B7F71 9F 474747471C 8E 474747471C 89 474747471C 3F 4545454514 3F 4545454514 3F 4545454514 3F 4545454514 FE 00011

__________________


Member

Status: Offline
Posts: 5
Date:

Thanks Petrik. I managed to find out how the ECU communicates with the immobilizer. The ECU supports 1-byte commands. I have documented some commands, and I've reversed the algorithm immobilizer. The operation is as follows, the immobilizer calls for a 3-byte challenge using the command 3E, if the key is correct, this returns 3 byte response and may start. If anyone is interested in implementing the algorithm. It could make a tool FI + Yamaha immobilizer emulator. Sorry for my English but is translated with google.
Some commands yamaha:
3E -> calls on the ecu the challenge for the immobilizer
3D ->? Serial number of the ECU, the immobilizer verifies that the same number that is stored

__________________


Member

Status: Offline
Posts: 18
Date:

@pico: could you share this document for me?
dlhindustry@gmail.com

Thanks a lot

__________________


Newbie

Status: Offline
Posts: 2
Date:

Pipo, could you share this document for me? jawaman76@gmail.com

At the moment I am versed with the ECU on the bike yamaha tdm900A 2006. ECU from DENSO. The communication protocol with immobilizer too interesting.

Thanks :)

__________________


Newbie

Status: Offline
Posts: 2
Date:

I have obtained here such data (K-Line, COM speed 15625 baud).

Ignition ON
3E 0D 0A 43 D1 2B
3D 53 73 4B 70 81
81 47 47 47 47 1C
8D 47 47 47 47 1C
89 47 47 47 47 1C
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
FE 00 00 00 00 00

Ignition ON, Diag Mode
3E A7 78 43 FB 5D
3D 53 73 4B 70 81
96 47 47 47 47 1C
9E 47 47 47 47 1C
AD 47 47 47 47 1C
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
FE 00 00 00 00 00
CD 00 00 00 00 00
CD 00 00 00 00 00
CD 00 00 00 00 00

Ignition ON
3E DF A0 43 F3 B5
3D 53 73 4B 70 81
9F 47 47 47 47 1C
9B 47 47 47 47 1C
AD 47 47 47 47 1C
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
3F 45 45 45 45 14
FE 00 00 00 00 00
01 00 00 00 28 28 - '28' - TPS???
01 00 00 00 28 28
01 00 00 00 28 28
01 00 00 00 28 28

After inclusion of ignition at a command ' 3E ' ECU each time new data gives out. After command 3D issued three more commands. They do not repeat and probably depend on the answer to a command ' 3E '? Somebody knows this dependence?

Sorry for my bad English (google translator)



-- Edited by Kosmonavt on Monday 7th of November 2011 07:17:44 AM

__________________


Newbie

Status: Offline
Posts: 2
Date:

hi, ok i have started building my own pc based program. in visual basics 2008

but will need loads of help

what are you guys setting the the ports settings too.

15300,8,n,1

if anyone has made anymore progress with anything else.

trying to do a diag on a yzf r125. (yes i know have a good laugh on the piddly little bike)

the cable i am using is a standard obd cable on opto-iso

i would like it to just like to connect read codes and ecu data eg RPM, engine temp ect



__________________


Member

Status: Offline
Posts: 5
Date:

I post immo algo but i dont kwon its legal or not...


__________________


Newbie

Status: Offline
Posts: 3
Date:

Reading errors Yamaha MT03, raptor700 ...

communication:
KKL OBD regular cable


After turning point:
3E9522439993 3D78704B73A6 88474747471C 84474747471C A9474747471C 3F4545454514 3F4545454514 3F4545454514 3F4545454514
Communication is probably the immo.
parcel after 5 bytes + checksum
eg 3E9522439993
3E
95 +22 +43 +99 = 93

3D78704B73A6
3D
78 70 4 B 73 = A6
It does not interest me.



The current reading of engine operating parameters.
send data

normal:

send: 01
read: 0000 00 2A 2A
      | RPM | ERROR | TEMP | CHECKSUM

  RPM: RPM (bytes reversed)
  ERROR no. error
  TEMP: engine temperature

send: 02
read: 0000000101
to verify



we make a mistake.

unfastened sensor error 21
21 Coolant temperature Open or short circuit is Fixes the coolant temperature sensor detected.

01 0000950095
(0x95-0x80 = 0x15 / 21 /)


data format:
send: 01
read: 0000 95 00 95
      | RPM | ERROR | TEMP | checksum


send: 02
read: 00 00 95 01 96
to verify
I wrote a simple program in visual basic that reads data from the ECU.

I'm sorry for the mistakes but I'm using a translator

 

 



Attachments
__________________


Newbie

Status: Offline
Posts: 3
Date:

data format:
send: 01
   read: 00    00        95        00      95
          |RPM|SPEED|ERROR|TEMP|checksum

 

 



Attachments
__________________


Senior Member

Status: Offline
Posts: 350
Date:

Nice work! Keep it up! Plan on adding logging capabilities also?
I am doing exactly same for my Nissan Navara. 3 sensors done, 6 to go. Generic PID´s, so much easier!
The KKL interface you are using, mcu/firmware controlled or "dumb" passive components circuitry?

__________________


Newbie

Status: Offline
Posts: 3
Date:

We'll see what next :) For now I'm building a diagnostic tool supporting all Yamaha.

 

YFM700 GRIZZLY
data format:
send: 02
   read: 00    00       95      09    9E
          |RPM|SPEED|ERROR|gear|checksum
        
        Gear lever
        P->C1->11000001
        R->09->00001001
        N->21->00100001
        H->41->01000001
        L->81->10000001

       OVERRIDE button included 10010001 

       OVERRIDE button excluded 10000001 
       

-- Edited by adzio on Saturday 23rd of March 2013 12:51:14 PM

I was able to enter the diagnostic mode.





-- Edited by adzio on Saturday 23rd of March 2013 01:34:03 PM

Attachments
__________________


Member

Status: Offline
Posts: 11
Date:

Hi,

I would like to ask about this project. I have an Aprilia Pegaso Strada and I found that my dashboard reads the same data as you wrote.

Do you have any new information about this? I mean I can read the 0x01 requests, but nothing more about further diagnostics... Does anybody

have that small program to read these values? Thanks!



__________________


Member

Status: Offline
Posts: 11
Date:

I've made a LabView project to read my dash data.



__________________


Veteran Member

Status: Offline
Posts: 73
Date:

dm13dv1b wrote:

I've made a LabView project to read my dash data.


 nice work !

 CHristian Piasini



__________________
Christian Piasini


Member

Status: Offline
Posts: 11
Date:

Thanks! But I need more information regarding the diag things! Please anyone would help me!?

__________________


Veteran Member

Status: Offline
Posts: 73
Date:

write me an email to christian.piasini@piasiniengineering.it

BR

 

 

Christian 



__________________
Christian Piasini


Member

Status: Offline
Posts: 11
Date:

Dear Christian!
I've sent an email last week! ;)
Thanks!

__________________


Member

Status: Offline
Posts: 6
Date:

Hi everyone.

I plan to connect by Raspberry PI to Yamaha XJ6 SA I own, and gather some data like RPM and velocity, and record a video at the same time. If I succeed, that would be some kind of route recoder (dunno how it's called in English, but you get the idea). As far as I understand some of you are using OBD cable which converts ECU signals to some USB data understandable by PC computer (that is what adzio did - am I right?) and some other people connects directly by some additional electronics they made themselves (Petri K, Kosmonavt ?). I am rather interested in the second approach, and thus wand to summarize / ask a few things:

* ECU establish some serial communication with gauge set.
* Baud rate vary from bike to bike, but is something about 15300bps, oscilloscope needed.
* How many wires is used for RPM and velocity between ECU and gauges? What is this mysterious "K-line"? According to my service manual, I suspect there is only one wire, which connects ECU, gauge and immobilizer. It has Y/B color in XJ6SA.
* Suppose I'm right about this Y/B wire - now I should monitor signals in it using some voltage converter (from 12 to 5V like MAX232 for RS-232).
* Suppose I'm still right, and managed to obtain some data - what is the protocol? Is it OBD, or OBD2 (http://en.wikipedia.org/wiki/OBD-II_PIDs)? But then why would you do so much reverse engineering guys? Is this protocol non-standard? May it vary depending on motorcycle model? Awww just noticed, that maq67 said this is ISO protocol, but is it ISO 9141 and ISO 14230 (aka KWP)?
* Can the RPM and velocity be recorded using only one-way communication (I mean monitoring this K-line without sending any commands to the ECU). I don't want to set anything (like CO volume etc).
* What is a Tx signal Rhinoman mentioned? Is it something in the FI-tool? If yes, it is of no use to me.

Sorry for so long post. If someone could answer to some of questions above, I would be grateful.
Regards
Iwasz (Poland).



__________________


Member

Status: Offline
Posts: 11
Date:

iwasz wrote:

Hi everyone.

I plan to connect by Raspberry PI to Yamaha XJ6 SA I own, and gather some data like RPM and velocity, and record a video at the same time. If I succeed, that would be some kind of route recoder (dunno how it's called in English, but you get the idea). As far as I understand some of you are using OBD cable which converts ECU signals to some USB data understandable by PC computer (that is what adzio did - am I right?) and some other people connects directly by some additional electronics they made themselves (Petri K, Kosmonavt ?). I am rather interested in the second approach, and thus wand to summarize / ask a few things:

* ECU establish some serial communication with gauge set.
* Baud rate vary from bike to bike, but is something about 15300bps, oscilloscope needed.
* How many wires is used for RPM and velocity between ECU and gauges? What is this mysterious "K-line"? According to my service manual, I suspect there is only one wire, which connects ECU, gauge and immobilizer. It has Y/B color in XJ6SA.
* Suppose I'm right about this Y/B wire - now I should monitor signals in it using some voltage converter (from 12 to 5V like MAX232 for RS-232).
* Suppose I'm still right, and managed to obtain some data - what is the protocol? Is it OBD, or OBD2 (http://en.wikipedia.org/wiki/OBD-II_PIDs)? But then why would you do so much reverse engineering guys? Is this protocol non-standard? May it vary depending on motorcycle model? Awww just noticed, that maq67 said this is ISO protocol, but is it ISO 9141 and ISO 14230 (aka KWP)?
* Can the RPM and velocity be recorded using only one-way communication (I mean monitoring this K-line without sending any commands to the ECU). I don't want to set anything (like CO volume etc).
* What is a Tx signal Rhinoman mentioned? Is it something in the FI-tool? If yes, it is of no use to me.

Sorry for so long post. If someone could answer to some of questions above, I would be grateful.
Regards
Iwasz (Poland).


 Welcome Iwasz! I don't have time now but I will try to answer all of your questions! But until that you should provide some more information

like your bike's year, ECU type whatsoever. I'm Hungarian so I hope you know that Polish and Hungarian are always friends!



__________________


Member

Status: Offline
Posts: 6
Date:

Hi dm13dv1b, hi forum. Thanks for your interest in my questions. Bike was made in 2010, and it is XJ6 S (semi) with ABS (so it has another ECU called ABS ECU, but I suppose this does not change anything). About the ECU itself - I must check its brand and model, and I will, once I'll finish work. And about Polish - Hungarian friendship : there is even a saying in Poland (Polish, Hungariant two brothers, for drinking, and for fight). But this is TOTALLY off topic :D REGS!



__________________


Member

Status: Offline
Posts: 11
Date:

iwasz wrote:

Hi everyone.

I plan to connect by Raspberry PI to Yamaha XJ6 SA I own, and gather some data like RPM and velocity, and record a video at the same time. If I succeed, that would be some kind of route recoder (dunno how it's called in English, but you get the idea). As far as I understand some of you are using OBD cable which converts ECU signals to some USB data understandable by PC computer (that is what adzio did - am I right?) and some other people connects directly by some additional electronics they made themselves (Petri K, Kosmonavt ?). I am rather interested in the second approach, and thus wand to summarize / ask a few things:

* ECU establish some serial communication with gauge set.
* Baud rate vary from bike to bike, but is something about 15300bps, oscilloscope needed.
* How many wires is used for RPM and velocity between ECU and gauges? What is this mysterious "K-line"? According to my service manual, I suspect there is only one wire, which connects ECU, gauge and immobilizer. It has Y/B color in XJ6SA.
* Suppose I'm right about this Y/B wire - now I should monitor signals in it using some voltage converter (from 12 to 5V like MAX232 for RS-232).
* Suppose I'm still right, and managed to obtain some data - what is the protocol? Is it OBD, or OBD2 (http://en.wikipedia.org/wiki/OBD-II_PIDs)? But then why would you do so much reverse engineering guys? Is this protocol non-standard? May it vary depending on motorcycle model? Awww just noticed, that maq67 said this is ISO protocol, but is it ISO 9141 and ISO 14230 (aka KWP)?
* Can the RPM and velocity be recorded using only one-way communication (I mean monitoring this K-line without sending any commands to the ECU). I don't want to set anything (like CO volume etc).
* What is a Tx signal Rhinoman mentioned? Is it something in the FI-tool? If yes, it is of no use to me.

Sorry for so long post. If someone could answer to some of questions above, I would be grateful.
Regards
Iwasz (Poland).


 I don't know much about your bike.

Mine is an Aprilia Pegaso strada and I have a complete wiring diagram, thats how I know it has a K-line connection with the ECU. K-line is a kind of physical layer of an OBD standard. It is much like an RS232 communication but it has only one line to communicate. The standard baudrates are the 10.400, 9.600 and 4.800. I know from my service manual that my bike uses 15.625 which is a well known baudrate for japanese bikes.

The standard OBD things are not so commong among bikes, I know only a few newer ones that use CAN between sensors etc.

As you see in this topic, some bikes have a special communication between the ECU and the dashboard. The dash asks for information (first byte 0x01) then after a while the ECU answers (the next bytes, RPM, Speed, ERR, Temp and checksum). My goal was to make a secundary dash which can show me these parameters.

Later I have seen some projects which utilises the KWP2000 standard comms to communicate with the ECU but it is a different story.

In this topic PetriK and other guys tried to debug the FI tool to find some more information.

That is all I know. :)



__________________


Member

Status: Offline
Posts: 11
Date:

iwasz wrote:

Hi dm13dv1b, hi forum. Thanks for your interest in my questions. Bike was made in 2010, and it is XJ6 S (semi) with ABS (so it has another ECU called ABS ECU, but I suppose this does not change anything). About the ECU itself - I must check its brand and model, and I will, once I'll finish work. And about Polish - Hungarian friendship : there is even a saying in Poland (Polish, Hungariant two brothers, for drinking, and for fight). But this is TOTALLY off topic :D REGS!


 Never mind :D I've met some Polish people in the High Tatras and in Afghanistan and they were all great people! :) Thats all. :)



__________________


Member

Status: Offline
Posts: 6
Date:

Many thanks for your help. It seems, that we plan to make something similar, but you want to display it, and I want to save it to some SD card. Pretty much the same. So do you use this KWP2000 or rather you made some custom electronics and you monitor signal on K-line which ECU sends to the dashboard? If the latter is true, was it difficult to make such circuit? Maybe you even could reveal some schematics? Regs. Iwasz.



__________________


Member

Status: Offline
Posts: 11
Date:

iwasz wrote:

Many thanks for your help. It seems, that we plan to make something similar, but you want to display it, and I want to save it to some SD card. Pretty much the same. So do you use this KWP2000 or rather you made some custom electronics and you monitor signal on K-line which ECU sends to the dashboard? If the latter is true, was it difficult to make such circuit? Maybe you even could reveal some schematics? Regs. Iwasz.


 I've bought a simple KKL cable and a fiat one (http://harapofogo.blogspot.hu/2013/03/aprlia-obd.html) and I had to change the wiring a little bit. Then I used an RS232 sniffer to catch the signals. It was almost the same as described in this topic. The dash comms and the KWP are two different things. My bike has an active and a passive diag mode. In passive mode the dash talks to the ecu, in active mode some kind of KWP protocol can talk to the ECU - that is what completly unknown for me :(



__________________


Member

Status: Offline
Posts: 6
Date:

Hi guys. A little progress here! This was long, but fruitful night when I managed to eavesdrop data flying on the K-line. My setup was as follows : 1) some voltage converter, which gave me 5V @ 3A from my bike's battery, 2) L9637 chip connected to the K-line, 3) Saleae logic analyzer, and 4) PC with Ubuntu. Data stream was similar to examples posted here before (adzio), the majority being packets with RPM and temperature. This was easier than I expected, and I'm very glad I've got the real data from the ECU. BUT the question arises : where the heck is the velocity!? I've got only RPM and temp, but no speed. I suspect that it is transmitted somewhere else without any protocol at all. Like some pulses or so. Next question is about L9637 chip. Dunno why, but after starting the engine, bike shows error indicator, and "check engine" light comes on. I use 560 ohm pull up resistor between VS (7th pin) and K (6th pin) of the chip like here : http://img205.imageshack.us/img205/4990/rs232l9637.jpg.  

PS. wanted to post photos but don't know how :(



__________________


Member

Status: Offline
Posts: 11
Date:

iwasz wrote:

Hi guys. A little progress here! This was long, but fruitful night when I managed to eavesdrop data flying on the K-line. My setup was as follows : 1) some voltage converter, which gave me 5V @ 3A from my bike's battery, 2) L9637 chip connected to the K-line, 3) Saleae logic analyzer, and 4) PC with Ubuntu. Data stream was similar to examples posted here before (adzio), the majority being packets with RPM and temperature. This was easier than I expected, and I'm very glad I've got the real data from the ECU. BUT the question arises : where the heck is the velocity!? I've got only RPM and temp, but no speed. I suspect that it is transmitted somewhere else without any protocol at all. Like some pulses or so. Next question is about L9637 chip. Dunno why, but after starting the engine, bike shows error indicator, and "check engine" light comes on. I use 560 ohm pull up resistor between VS (7th pin) and K (6th pin) of the chip like here : http://img205.imageshack.us/img205/4990/rs232l9637.jpg.  

PS. wanted to post photos but don't know how :(


 

Nice to hear! :D I don't know exactly where your speed signal goes and I have not tested it on my bike. I hope itt will be the second word of the sentence. I guess your level converter somehow disturbs the line, you should make some delay after ignition to start the L9637. Or insert a FET switch between the K-line and the L9637. Or you can use an MCP201 it has a Wake-up pin.



-- Edited by dm13dv1b on Thursday 30th of May 2013 04:07:42 AM

__________________


Member

Status: Offline
Posts: 6
Date:

This is what i've got so far : http://www.iwasz.pl/electronics/motorcycle-black-box-part-1-data-acquisition-with-arduino-mega/



__________________


Member

Status: Offline
Posts: 11
Date:

Nice job! :) There are some formulas how to calculate things from these parameters. For example, I have to multilply the RPM with 27 to get the exact RPM. The temperature for me is the water coolant temp in celsius. Since you have the speed and the RPM now you can calculate the gear ratio



__________________


Member

Status: Offline
Posts: 11
Date:

kline.JPG

This is the easiest without a dedicated level converter.



Attachments
__________________


Member

Status: Offline
Posts: 6
Date:

Neat circuit! But I'll stay with those IC's i have. I bought 4 of them, so why not using them :D Besides, they are only $1, and are easy to solder SMDs. And as for the gear ratio : COOL IDEA! Didn't think of that!



__________________
kvn


Newbie

Status: Offline
Posts: 1
Date:

PetriK! adzio! I make an appeal to you! Please, contact with me. I need your help in Yamaha ECU protocol. qnx@list.ru

__________________
Page 1 of 1  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard