Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: KDS Protocol


Member

Status: Offline
Posts: 6
Date:
KDS Protocol


 Kawasaki ECU seems to use KWP2000. I initiate communication with a ZX6R 2003/2004 successfully.

 

Now I need to decode and convert the raw values returned by the ECU when I send the ReadDataByLocalID command.

 

Anyone has already done this ?



__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hi.

I'm working on the same thing on my bike in these days.
I have a kawasaki Z750R 2011 (ECU model 21175-0341)with a GPT gear indicator on the K-LINE of KDS BUS:

http://www.gpt.it/GPT_Grand_Prix_Technology/PNP_KAWASAKI_ENGLISH.html

Since none of my laptops support arbitrary baudrate on their RS232 ports, I'm programming a small microcontroller to "sniff" data passing between the ECU and the GEAR INDICATOR.

The micro has two serial ports:
- 1 port is set to RX at 10417 baud 8N1 from the K-LINE with a small level-converter.
- 1 port is set to TX at 38400 baud 8N1  to the RS232 of my laptop.

This gear indicator looks RPM, SPEED and IDLE SWITCH and it reconize the right gear from the RPM/SPEED rate.

As soon as I finish my tests (few days, I hope...), I will report you the results, drawings and firmware.

The addresses should be the same for ZX6R since the gear indicator supports your bike too.

Bye.




-- Edited by MXP on Tuesday 14th of January 2014 07:42:09 PM



-- Edited by MXP on Tuesday 14th of January 2014 07:43:56 PM



-- Edited by MXP on Tuesday 14th of January 2014 08:12:50 PM



-- Edited by MXP on Wednesday 15th of January 2014 05:42:59 AM



-- Edited by MXP on Wednesday 15th of January 2014 08:26:59 AM



-- Edited by MXP on Thursday 16th of January 2014 11:04:45 AM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hello everybody.

I have completed "the sniffer" and these are the results:

First of all, I confirm protocol of KDS is KWP2000 (ISO-14230).
Nominal baudrate is 5000000 / 480 = 10417 (10400).  8 BIT NO PARITY 1 BIT STOP.

The gear is calculated by the ECU, not by the gear indicator as I supposed.
So, only one information is exhanged between the two parts is GEAR POSITION (0...6).

As described from protocol specifications, structure of messagges are these ones:

Messagge (request) sent periodically from the GEAR INDICATOR (constant):    80 11 F1 02 21 0B B0

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte            0x80        Address mode: with address information, physical addressing
1    Target Byte             0x11        Address of target devide (ECU)
2    Source Byte            0xF1        Address of source device (GEAR INDICATOR)
3    Length Byte            0x02        Two byte following...
4    Service ID               0x21        ReadDataByLocallIdentifier
5    Parameter name    0x0B        "Gear position" Parameter
6    Checksum              0xB0        Checksum = 80+11+F1+02+21+0B module 0xFF (OK)

Messagge replied by the ECU:       

80 F1 11 03 61 0B 00 F1     (IDLE)
80 F1 11 03 61 0B 01 F2     (GEAR 1)
80 F1 11 03 61 0B 02 F3     (GEAR 2)
...
80 F1 11 03 61 0B 06 F7     (GEAR 6)

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte           0x80        Address mode: with address information, physical addressing
1    Target Byte            0xF1        Address of target devide (GEAR INDICATOR)
2    Source Byte           0x11        Address of source device (ECU)
3    Length Byte           0x03        Three byte following...
4    Service ID              0x61        Positive reply to Request ReadDataByLocallIdentifier
5    Parameter name    0x0B        "Gear position" Parameter
6    Parameter value    n              n = gear position value
7    Checksum              0xF1+n    Checksum = 80+F1+11+03+61+0B+n module 0xFF (OK)

Bye!



-- Edited by MXP on Friday 17th of January 2014 12:54:20 AM



-- Edited by MXP on Friday 17th of January 2014 12:55:29 AM



-- Edited by MXP on Sunday 19th of January 2014 02:53:31 AM



-- Edited by MXP on Sunday 19th of January 2014 03:03:28 AM



-- Edited by MXP on Sunday 19th of January 2014 03:04:17 AM



-- Edited by MXP on Sunday 19th of January 2014 03:04:47 AM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Initialisation Procedure
------------------------

Before "talking" the communication, must be initialised.
That's what happens:

1. The GEAR INDICATOR put the K-LINE low for 25ms and high again for other 25ms (fast initialisation).

2. START COMMUNICATION REQUEST is sent by the gear indicator with frame: 81 11 F1 81 04

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte           0x81        Address mode: with address information, physical addressing (message is 1 Byte long)
1    Target Byte           0x11        Address of target devide (ECU)
2    Source Byte           0xF1        Address of source device (GEAR INDICATOR)
3    Request service ID    0x81        START COMMUNICATION REQUEST
4    Checksum           0x04           Checksum 04 = 81+11+F1+81 module FF

3. ECU replies with ok: 80 F1 11 03 C1 EA 8F BF

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte           0x80        Address mode: with address information, physical addressing
1    Target Byte           0xF1        Address of target devide (GEAR INDICATOR)
2    Source Byte           0x11        Address of source device (ECU)
3    Length Byte           0x03        3 Bytes following...
4    Response              0xC1        START COMMUNICATION REQUEST ACCEPTED
5    Key Byte 1           0xEA        Header with targe and source address information
6    Key Byte 2           0x8F        Additional length byte used
7    Checksum           0xBF        Checksum BF = 80+F1+...+8F module FF

4. Gear indicator asks for starting diagnostic sessione with frame: 80 11 F1 02 10 80 14

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte           0x80        Address mode: with address information, physical addressing
1    Target Byte           0x11        Address of target devide (ECU)
2    Source Byte           0xF1        Address of source device (GEAR INDICATOR)
3    Length Byte           0x02        2 Bytes following...
4    Request service ID    0x10        START DIAGNOSTIC REQUEST
5    diagostic mode       0x80        manufacterSpecific
6    Checksum           0x14        Checksum

5. ECU replies with OK: 80 F1 11 02 50 80 54

Byte    Name                Value        Description
-----------------------------------------------
0    Format Byte           0x80        Address mode: with address information, physical addressing
1    Target Byte           0xF1        Address of target devide (GEAR INDICATOR)
2    Source Byte           0x11        Address of source device (ECU)
3    Length Byte           0x02        2 Bytes following...
4    Request service ID    0x50        START DIAGNOSTIC REQUEST ACCEPTED
5    diagostic mode       0x80        manufacterSpecific
6    Checksum           0x54        Checksum

Bye!



-- Edited by MXP on Friday 17th of January 2014 01:47:24 PM



-- Edited by MXP on Sunday 19th of January 2014 02:57:11 AM



-- Edited by MXP on Sunday 19th of January 2014 03:01:03 AM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hello Again.

 

Today I have discovered that WATER TEMPERATURE is parameter number 0x06.

So, frame to send is :

 

80 11 F1 02 21 06 AB

 

Bye!



-- Edited by MXP on Sunday 19th of January 2014 02:58:28 AM



-- Edited by MXP on Sunday 19th of January 2014 02:58:51 AM



-- Edited by MXP on Sunday 19th of January 2014 02:59:13 AM

__________________


Member

Status: Offline
Posts: 6
Date:

This is what I found with the ECU disconnected from the bike and using a potentiometer instead of real sensors...

Read Data By Local ID
21 00 4 bytes
21 01 1 byte
21 02 1 byte
21 03 2 bytes
21 04 2 bytes TPS
21 05 2 bytes Air Pressure
21 06 1 byte ECT
21 07 1 byte Intake Air Temperature
21 08 2 bytes Abs Pressure
21 09 2 bytes
21 0A 1 byte
21 0B 1 byte
21 0C 2 bytes

But I actually have no idea of the conversion formula to get the real values.

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

I was interested in water temperature (ECT), and I have interpolated values from 40°C to 100°C

 

This equation seems to interpolate almost rightly the values:

 

TEMP = 50/75 * VALUE - 38,67

 

Example: Value 0xD0 -> 100°C

 

 



__________________


Member

Status: Offline
Posts: 6
Date:

MXP wrote:

I was interested in water temperature (ECT), and I have interpolated values from 40°C to 100°C

 

This equation seems to interpolate almost rightly the values:

 

TEMP = 50/75 * VALUE - 38,67

 

Example: Value 0xD0 -> 100°C

 

 


 For SDS protocol, Temperature is calculated using the formula below :

Temp = ( [Hex value] - 48) / 1.6

 

If I take your value 0xD0 (208 dec) I have : (208 - 48) / 1.6 = 100°C

 



__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Yes, probably that's the right equation.

I'm sure about 0xD0 corresponds exactly to 100°C because it's when the fan starts to run.

 

ciao

 

 

 

 



__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

At the end, I have implemented your equation.

 

Bye

 

 

 



-- Edited by MXP on Wednesday 5th of March 2014 05:33:49 PM



-- Edited by MXP on Wednesday 5th of March 2014 05:35:44 PM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

On my prototype, I decided to use your equation. It works perfectly!

ciao

 



-- Edited by MXP on Wednesday 5th of March 2014 05:34:11 PM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hello.

 

In this post you can find FIRMWARE and HARDWARE of the small board I have developed to communicate with KAWASAKI Z750R ECU using the KDS BUS.

Actually, the microcontroller initialises the communication with the ECU and then works as a "gateway" between the RS232 port (which is set at 38400Baud) and the KBUS (10417 Baud).

Maybe this could be helpful to someone else too.
The microcontroller I used is big for this purpouse but easy to be found on the market. You can also compile the source code for PIC18F24K22 which is cheaper and smaller...

Bye

----------------

 

// FILE ******* HEADER *********
// KWP2000 protocol for KAWASAKI KDS INTERFACE (tested on Z750R 2011)
// Author: Caliendo Domenico
// EMAIL: dcaliendo@tiscali.it

#include <p18f46k22.h>

// CONSTANT PARAMETERS

#define    BIT0    0x01
#define    BIT1    0x02
#define    BIT2    0x04
#define    BIT3    0x08
#define    BIT4    0x10
#define    BIT5    0x20
#define    BIT6    0x40
#define    BIT7    0x80

// LEDs PINOUT

#define    CPU_ON            (LATC |= BIT0)
#define    CPU_OFF            (LATC &= ~BIT0)
#define CPU_TOGGLE        (LATC ^= BIT0)

#define    LED_RX1_ON        (LATC |= BIT1)
#define    LED_RX1_OFF        (LATC &= ~BIT1)
#define LED_RX1_TOGGLE    (LATC ^= BIT1)

#define    LED_RX2_ON        (LATC |= BIT2)
#define    LED_RX2_OFF        (LATC &= ~BIT2)
#define LED_RX2_TOGGLE    (LATC ^= BIT2)

#define    LED_TX1_ON        (LATC |= BIT3)
#define    LED_TX1_OFF        (LATC &= ~BIT3)
#define LED_TX1_TOGGLE    (LATC ^= BIT3)

#define    LED_TX2_ON        (LATC |= BIT4)
#define    LED_TX2_OFF        (LATC &= ~BIT4)
#define LED_TX2_TOGGLE    (LATC ^= BIT4)

// K-BUS PIN

#define    K_HIGH            (LATD |= BIT6)
#define    K_LOW            (LATD &= ~BIT6)

// KWP2000 PARAMETERS

#define frame        (unsigned char)0x80
#define target        (unsigned char)0x11
#define source         (unsigned char)0xF1
#define leng         (unsigned char)0x02
#define    service     (unsigned char)0x21

// ******* END OF HEADER FILE ********

 

// FILE ******* SOURCE *********
// KWP2000 protocol for KAWASAKI KDS INTERFACE (tested on Z750R 2011)
// Author: Caliendo Domenico
// EMAIL: dcaliendo@tiscali.it

// NOTE: PIC18F46K22 is big for this project but easy to find. PIC18F24K22 is good too...

#include <p18f46k22.h>
#include <usart.h>
#include "../h/definizioni.h"

#define        N        128

unsigned char START_COMM_MSG[5] =     {0x81,0x11,0xF1,0x81,0x04};                // Messagge used to START COMMUNICATION SESSION...
unsigned char START_DIAG_MSG[7] =     {0x80,0x11,0xF1,0x02,0x10,0x80,0x14};    // Messagge used to START DIAGNOSTIC MODE...
unsigned char READ_TEMP_MSG[7] =     {0x80,0x11,0xF1,0x02,0x21,0x06,0xAB};    // Messagge used to GET TEMPERATURE VALUE...
unsigned char READ_GEAR_MSG[7] =     {0x80,0x11,0xF1,0x02,0x21,0x0B,0xB0};    // Messagge used to GET GEAR VALUE...

unsigned char rx_buffer1[N];
unsigned char rx_buffer2[N];

unsigned char L1 = 0;
unsigned char L2 = 0;

unsigned char M1 = 0;
unsigned char M2 = 0;

void InitMicrocontroller(void)
{
    ANSELA = 0;
    ANSELB = 0;
    ANSELC = 0;
    ANSELD = 0;
    ANSELE = 0;
   
    LATA = 0;
    LATB = 0;
    LATC = 0;
    LATD = 0;
    LATE = 0;
   
    PORTA = 0;
    PORTB = 0;
    PORTC = 0;
    PORTD = 0;
    PORTE = 0;
   
    TRISA = 0;
    TRISB = 0;
    TRISC = 0;
    TRISD = 0;
    TRISE = 0;
   
    TMR0H = 0;
    TMR0L = 0;

    RCONbits.IPEN = 0;

    INTCONbits.TMR0IF = 0;
    INTCONbits.TMR0IE = 1;
    INTCONbits.PEIE = 1;
   
    T0CONbits.T08BIT = 0;
    T0CONbits.T0CS = 0;
    T0CONbits.PSA = 0;
    T0CONbits.T0PS = 4;
   
    INTCONbits.TMR0IF = 0;
    INTCONbits.TMR0IE = 1;
   
    INTCONbits.PEIE = 1;
    T0CONbits.TMR0ON = 1;
}

void InterruptHandler(void);

#pragma code InterruptVector = 0x08
void InterruptVector (void)
{
  _asm
    goto InterruptHandler
  _endasm
}

#pragma code
#pragma interrupt InterruptHandler

void InterruptHandler (void)
{
    if (INTCONbits.TMR0IF)                                       
    {  
        CPU_TOGGLE;
        LED_RX1_OFF;
        LED_RX2_OFF;
         LED_TX1_OFF;
        LED_TX2_OFF;
        INTCONbits.TMR0IF = 0;                   
    }
   
    else
   
    if(PIR1bits.RC1IF)                        // RX da RS232   
    {
       LED_RX1_TOGGLE;
       rx_buffer1[L1++] = Read1USART();
      
       if(L1>=N) L1=0;
   
    }
   
    else
  
    if(PIR3bits.RC2IF)                        // RX da K-BUS   
    {
        LED_RX2_TOGGLE;
        rx_buffer2[L2++] = Read2USART();
       
        if(L2>=N) L2=0;
    }
}

void Ritardo(unsigned int r)
{   
    unsigned int i = 0;

    for(i=0;i<r;i++);
}

void Pulse25ms(void)
{
    K_HIGH;
    Ritardo(65000);
    Ritardo(65000);
    Ritardo(65000);
    Ritardo(65000);
    Ritardo(65000);
           
    K_LOW;
    Ritardo(11900);
       
    K_HIGH;
    Ritardo(11900);
}

void InitSerial(void)
{
    TRISC = 0xC0;
    TRISD = 0xC0;
   
    Open1USART( USART_TX_INT_OFF &
                USART_RX_INT_ON &
                USART_ASYNCH_MODE &
                USART_EIGHT_BIT &
                USART_CONT_RX &
                USART_BRGH_HIGH,
                64);                    // 38400 Baud
               
    Open2USART( USART_TX_INT_OFF &
                USART_RX_INT_ON &
                USART_ASYNCH_MODE &
                USART_EIGHT_BIT &
                USART_CONT_RX &
                USART_BRGH_HIGH,
                239);                    // 10417 Baud
}

void SendMSG(unsigned char * MSG, unsigned char len)
{
    unsigned char i = 0;

    for(i=0;i<len;i++)
    {
        while(Busy2USART());   
        Write2USART(MSG);
    }
}



void main(void)
{
    unsigned char i = 0;
   
    InitMicrocontroller();
   
    Pulse25ms();
    InitSerial();
   
    INTCONbits.GIE = 1;
   
    SendMSG(START_COMM_MSG,5);    Ritardo(65000);
    SendMSG(START_DIAG_MSG,7);    Ritardo(65000);
   
    while(1)
    {
        //SendMSG(READ_GEAR_MSG,7);    Ritardo(65000);    // Remove remark to read GEAR value and keep bus alive without external commands...
        //SendMSG(READ_TEMP_MSG,7);    Ritardo(65000); // Remove remark to read TEMP value and keep bus alive without external commands...
       
            while(M1!=L1)
            {
                LED_TX1_TOGGLE;
                while(Busy2USART());
                Write2USART(rx_buffer1[M1++]);
            }
           
            while(M2!=L2)
            {
                LED_TX2_TOGGLE;
                while(Busy1USART());
                Write1USART(rx_buffer2[M2++]);
            }
    }
}

// ******* END OF SOURCE FILE ********


 

 



-- Edited by MXP on Sunday 2nd of February 2014 09:02:02 AM

Attachments
__________________


Member

Status: Offline
Posts: 21
Date:

Hello Gents.

I would like to join you guys and help with this topic. I have ZX6R p8f and would like to learn how communicate with my Kawa and in the end, build device to read data from it.

I noticed that MXP and padFR already did great job. Good stuff guys! Respect.

Now what i think...(please correct me if I'm wrong, I still need to do learn some stuff and just started :( ).

1) I think there are some limitations how far we could work out the Kawasaki ECU (is quite obvious), Without Specification from Kawasaki we will stop soon :(,

2) hardware to talk with Kawa. I noticed that MXP did great pcb board! Cool man. In my opinion for most of guys it can be slightly to much, because instead of focusing on real task (cracking "Kawa's code") we trying to design device/translator. My idea is (I will test it on weekend) to use for this purpose Arduino Uno board (i have v3). Why?:

a) It has coms port build in already (to connect to USB port in PC) And it works as normal rs232 port (UART),

b) it is really small and flexible,

c) cheap

d) There is huge community using Arduino boards with plenty of source codes to use....

Additionally you have to use UART to RS232 converter (on ebay you can easy buy this kind of converter with open drain inputs :) ) so you just need to supply power from arduino and that is all.

I did small test and "wrote" (modify generic code) code for ATmega (Arduino) to translate from 19200 to 10400 (listed bellow). So basically transparent device-translator (picture). Just for this perpouse i used BT HC-06 modul insted of using my rs232 port in laptop (makes no difference, and in the end you could fit BT module in bike for gut and connect without cables...if required).

Obviously MXP used PIC uC but the C/C++ code can be translated.

Now, Some time ago I created library to communicate uC with PC with function detection...So for example if i will send "#start" to micro-controller, it will start communication with Kawa, but if I will send "$vblabla bal" the microcontriller will pass it from 1 port to other. (#-marker for commands with uC, $-marker for data to translate from 1 uart port to another). On this stage I think it will be the best solution, because you can use your PC, there will be no need to  reprogram uC every time you want to change something.

Now my question: (do not laugh, please :) ). How to connect to Kawasaki ECU? What is the physical layer of protocol? Is it like RS232? +-12V?

 

Thanks for reading, I will appreciate all critics and all Ideas! I will publish my results (hopefully Sunday night, with Arduino code).

 

Cheers guys!

Bartek

 

P.S.

Photos below.

 

Test Code:

/*
  Software serial multple serial test
 
 Receives from the hardware serial, sends to software serial.
 Receives from software serial, sends to hardware serial.
 
 The circuit:
 * RX is digital pin 10 (connect to TX of other device)
 * TX is digital pin 11 (connect to RX of other device)
 
 Note:
 Not all pins on the Mega and Mega 2560 support change interrupts,
 so only the following can be used for RX:
 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69
 
 Not all pins on the Leonardo support change interrupts,
 so only the following can be used for RX:
 8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).
 
 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example
 
 This example code is in the public domain.
 
 */
#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX

void setup() 
{
  // Open serial communications and wait for port to open:
  Serial.begin(10400);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }


  Serial.println("Atmega hardware UART !");

  // set the data rate for the SoftwareSerial port
  mySerial.begin(19200);
  mySerial.println("Virtual Port to kawasaki :)");
}

void loop() // run over and over
{
  if (mySerial.available())
    Serial.write(mySerial.read());
  if (Serial.available())
    mySerial.write(Serial.read());
}

 



Attachments
__________________
Reg B.
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

chszanek wrote:



Now my question: (do not laugh, please :) ). How to connect to Kawasaki ECU? What is the physical layer of protocol? Is it like RS232? +-12V?

 

Thanks for reading, I will appreciate all critics and all Ideas! I will publish my results (hopefully Sunday night, with Arduino code).

 

Cheers guys!

Bartek

 



Hello Bartek.

Of course, you can also use Arduino. In my case it was easier to use a PIC because that microcontroller was already available in my LAB. So I didn't need to buy anything else...

I used a piece of bread-board for the prototype (picture below). Not so difficult..

 

Anyway, regarding your questions:

- The physical layer is described by ISO14230-1. You can find on Google (or send me an email to have the PDF...). See also my diagram: Q1 and Q2 and RED LED make an interface you can use for Arduino too. It's just a level converter, pull up network and logical  inverter.

- Don't forget to implement in your code the initialise sequence (see Pulse25ms(); in my code) to start up the communication with the ECU. This must be done by your micro. a simple "gateway" is not enought because this sequence doens't correspond to any byte to be sent from your laptop. Otherwise you won't communicate.

- All PICs have diodes on input pins (one versus ground and one versus positive). These feature is used in my board but it's not easy to be understood from wiring. If your micro (ATMEL) doesn't have, you have to put them outside (1N4148).

- To connect the ECU you can use the diagnostic connector (female 4-pole deutsch). J1 in my schematic. WHITE / YELLOW += +12V , RED / YELLOW = K-BUS, BLACK/YELLOW = GND. Or you can directly to your ECU on KDS pin.

 

Good Luck.

 



 



-- Edited by MXP on Wednesday 26th of February 2014 10:06:00 AM



-- Edited by MXP on Wednesday 26th of February 2014 10:15:33 AM

Attachments
__________________


Guru

Status: Offline
Posts: 963
Date:

MXP wrote:

- Don't forget to implement in your code the initialise sequence (see Pulse25ms(); in my code) to start up the communication with the ECU. This must be done by your micro. a simple "gateway" is not enought because this sequence doens't correspond to any byte to be sent from your laptop. Otherwise you won't communicate.



Actually sending a 0x00 at 360 baud or using a timed break works. I've connected to KDS, SDS, and ADS using just an FTDI 232TTL with a Kline level converter.



__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:


Actually sending a 0x00 at 360 baud or using a timed break works. I've connected to KDS, SDS, and ADS using just an FTDI 232TTL with a Kline level converter.


Yes, this solution is good too since 0x00 @ 360Baud corresponds to a 25ms pulse.

If you a have a FTDI 232TTL converter or you don't have practise with bread-boards or you don't have a lab, this solution is better than mine for you.

In my case it was easier to find a PIC than a FTDI interface.  aww Moreover, at the beginning, my idea was to use free pins of the micro to drive a LCD display and some general purpose buttons.

Bye

 

 



-- Edited by MXP on Wednesday 26th of February 2014 04:43:44 PM



-- Edited by MXP on Wednesday 26th of February 2014 04:44:55 PM

__________________


Member

Status: Offline
Posts: 11
Date:

Hey guys, first off: great job of this project. Everyone has added great things to this thread. MXP ,RidgeRacer  and padFR are awesome

The work here has been very similar to what I have been doing as well. Like chszanek, I have constructed a setup using Arduino and I believe I'm a little more ahead in the project. To answer some of the questions, yes the KDS port is under the second seat, well on my Z1000. Sumitomo B4APT was the part number. To interface with the bike I'm building a voltage regulator to drop the 12v to something nice that the Arduino can play with. I'm also working on displaying the info on a 4 digit 7 segment display, and another display is a 2" color TFT. I have all my pieces, I'm just putting the code together.

So I believe we have enough people working on this to help out whenever needed. I hoping to finish the shell and get testing on the bike soon.



__________________


Member

Status: Offline
Posts: 8
Date:

Hi Guys,

First, thank you all great job done here. I managed to send and receive the first initialization frame described here to a 2013 zx636.

I guess the Sumitomo B4APT is the KDS connector reference? Is that correct?

How did you figure out the part number? I believe it is, as it's a 4 pole female connector, but I want to make sure of the part number before I order some connector.

Thanks,

Ben

__________________


Member

Status: Offline
Posts: 21
Date:

Hi Guys,
Sorry for long delay, right now I'm working hard ;) far away from my home (no access to zx6r).

MXP mentioned that check sum is made by adding values of message and the modulo 0xFF, in my opinion it is modulo 0x100. Just do simple calculation in windows calculator.
0xFf=255 when 0x100=256 (I think i found it somewhere in KDS Spec).

With end of this week I will supply here my "firmware" for arduino:
this is the plan:
Commend are send from PC to Arduino via usb (COM port in the end):
case help : {
mySerial.println("ecuhacking.activeboard.com/t56234221/kds-protocol/");
mySerial.println("and:");
mySerial.println(" ");
mySerial.println("| singe commands >");
mySerial.println(" 99 = dev_statusprints on PC port : various information about dev and firmware");
mySerial.println(" displays: KDS BDrate, PC bdrate, firmware rev, KDS diagnostic mode has been established");?,KDS initialisation has been established?");
mySerial.println(" 98 = help - prints on PC port : display this help");
mySerial.println(" ");
mySerial.println("| singe commands >");
mySerial.println(" 01 = start_init- send command to ecu: starting the ECU<>dev communication");
mySerial.println(" 02 = start_diagnostic - send command to ecu: starts diagnostic mode");
mySerial.println(" 03 = read_gear- send command to ecu: reads gear from ECU and returns int");
mySerial.println(" 04 = read_eng_temp- send command to ecu: reads temperature");
mySerial.println(" ");
mySerial.println("| combined commands >");
mySerial.println("50 = start_kde - send command to ecu: it is start_init + start_diagnostic first initalizate");
mySerial.println(" communication and switch to diagnostic mode");
}break;

The command from PC is in format "#99" or "#01"... (taping from pc) and then Arduino does the job and analyses the returning data from ECU, next forwards it to PC (in native format and text format). "#" is indicating beginning of commend for Arduino, 2 digits are no of command.

Any suggestions about commands? Should i include something more?

>>
After return (April) I will check it on my Kawasaki. I'm planning to create "sniffer" which will log data from ECU via Blue Tooth on the PC during ride (just to find more addresses in ECU). Does any one else tried to sniff random registers?
my test/sniffing arrangement:
Motorbike(ECU)->KDE physical layer translator->Arduino -> Blue Tooth HC06 module <- PC in the backpack with software terminal to log data + GPS:)
is this good idea? What do you think guys.
I know that I will read a loot of "strange" data, but with GPS signal i could related some with, speed or revs for example.

regards
Bartek




__________________
Reg B.
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Yes, you are right. Module is 256,of course.
Bye
chszanek wrote:



MXP mentioned that check sum is made by adding values of message and the modulo 0xFF, in my opinion it is modulo 0x100.





 



__________________


Newbie

Status: Offline
Posts: 1
Date:

padFR wrote:

This is what I found with the ECU disconnected from the bike and using a potentiometer instead of real sensors...


Do I have to perform any magic tricks to connect to the ECU off-bike? I provided supply voltage to pin 16 (W/Y), ground to pin 34 (BK/Y) and connect K-line to pin 32 (R/Y). The service manual is a bit unclear here, it mentions 2 diagnostic lines for immobilizer-equipped bikes (pin 50, LT/BK, too), but according to one of MXP's layouts, pin 32 seems to be the one to aim for. Still no connection. K-line has ~11 volts when powered up, all pins I would expect powered up for sensors are up also. 

I am using an ELM327 clone, which works fine with my BMW ECU (BMS-K). Apparently, from what I saw using my ancient scope, there's no response to the fast init at all, but I will go an connect a L9637 for eavesdropping tomorrow.

Anyway, any help to proceed is really appreciated!



__________________


Member

Status: Offline
Posts: 8
Date:

I did it with a L9637 and it worked fine. I'm not quite sure, but I think the KLINE pin was the one at 6V.

Anyway, I put the picture of the connections. Red is +12V, blue is Ground and the green on is the GND. 

I had to put a pull up resistor (~5k) as it does not seem to be included on the ECU. 



Attachments
__________________


Member

Status: Offline
Posts: 8
Date:

on my side, the localid 3 answer with a general reject code. 

I'm looking for the RPM code. Would Anyone have it worked out?

 

I guess padFR could not find it because it's an inductive sensor. Plugin a variable resistance does not do the job.

 

Cheers,

 

Ben

 



__________________


Member

Status: Offline
Posts: 21
Date:

Hi Guys,

Small update. I managed to find Speed register. Could someone verify it, please?

The equation is:

Speed=[hex value]/(2*x), x=1 speed in kph, x=1.64 speed in mph (I'm leaving in UK).

Request to ECU:        0x80 0x11 0xf1 0x2 0x21 0xc 0xb1

Response from ECU:  0x80 0xf1 0x11 0x4 0x61 0xc 0x0 0x9c 0x8f

=> 9c=156 => 156/2/1.64=47.6mph (this is more or less what i had on the clock. Motorbike was standing on paddock stand).

I'm not really sure about 1'st value, maybe for higher speeds? don't know yet :). Tomorrow i have some spare time, will try to work it out.

p.s.1

For those which start, in matter of hardware, go for L9637 chip. Is really easy to use, just 1 extra element (~550 Ohm resistor).

p.s.2

I have software for Arduino and my configuration (Kawasaki zx6r p8f + Arduino + Bluetooth (set up to 115200) + L9637D) but had few bugs. I need to modify, if. Then will post it here :)

 

Cheers Bartek

 question:

I have strange problem. After initialization i can read data but sometimes after few request to read data, ECU is not responding. Anyone know why? Then I need to reset Arduino, re initialize. It can by problem with my software, but maybe you came across the same issue. Cheers for help. 

 

 

...... hmmm maybe is rpm? need to check it tomorrow, just need to go somewhere where i can rev it :), good night

-- Edited by chszanek on Monday 5th of May 2014 08:13:42 PM



-- Edited by chszanek on Monday 5th of May 2014 08:56:25 PM

Attachments
__________________
Reg B.
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

chszanek wrote:

 question:

I have strange problem. After initialization i can read data but sometimes after few request to read data, ECU is not responding. Anyone know why? Then I need to reset Arduino, re initialize. It can by problem with my software, but maybe you came across the same issue. Cheers for help. 



 

Hello!

Do you need just to re-init the ECU or hardware reset?

Because in the first case, maybe you are not "pinging" the ECU enough with requests: without requests for a while it goes back to normal mode and you need to re-initialise the communication with ECU again.

On the other side, with HW reset, it could be a problem of your firmware: I ask values continuosly and I never need to restart or reset comm.

BYe!!



__________________


Member

Status: Offline
Posts: 21
Date:

Thank MXP, I think the ping is important :).

I checked it and it is Speed, just someone could confirm.

Cheers


__________________
Reg B.


Member

Status: Offline
Posts: 8
Date:

Hi,

 

I will probably be able to confirm you data over the weekend. I have a gps on my setup, so I will probably be able to corelate the result ofyour eqation with gps measured speed.

 

Cheers,

 

Ben



__________________


Member

Status: Offline
Posts: 21
Date:

Good News Everyone!!

It's Saturday :) hehe and it rains like hell down here in UK :(....

Any way.

Small update. I managed to make "almost" good hardware (please have look on the photo). Next week I'm starting logging data. That means that probably will came with some new questions, data or maybe if will be lucky .... some registers.

 

For those which starting with Arduino, I placed Test Code which is really simple (something like MXP's code for PIC). I'm still working on the proper code.

P.S.

If someone is from West Yorkshire (UK), I have spare L9637D, I can share.

example of use this code:

1) Open putty

2) open BT with your speed (in my firmware 19200)

3) send press 1 (send no 1), it will send connection request to ECU

4) you will see incoming messages

5) send "2"- gear, "3"-temp, "6"-speed

this is copy of putty:

"""""""""

A
B
_1
 0x81 0x11 0xf1 0x81 0x4 0x80 0xf1 0x11 0x3 0xc1 0xea 0x8f 0xbf 0x80 0x11 0xf1 0x2 0x10 0x80 0x14 0x80 0xf1 0x11 0x2 0x50 0x80 0x54_2_gear=
 0x80 0x11 0xf1 0x2 0x21 0xb 0xb0 0x80 0xf1 0x11 0x3 0x61 0xb 0x1 0xf2_2_gear=
 0x80 0x11 0xf1 0x2 0x21 0xb 0xb0 0x80 0xf1 0x11 0x3 0x61 0xb 0x1 0xf2_2_gear=

 0x80 0x11 0xf1 0x2 0x21 0x6 0xab 0x80 0xf1 0x11 0x3 0x61 0x6 0x43 0x2f_3_temp=
 0x80 0x11 0xf1 0x2 0x21 0x6 0xab 0x80 0xf1 0x11 0x3 0x61 0x6 0x43 0x2f_2_gear=

0x80 0x11 0xf1 0x2 0x21 0xc 0xb1 0x80 0xf1 0x11 0x4 0x61 0xc 0x0 0x0 0xf3
_4_speed-
"""""""

I know, it is total mess. But it is  not the point. This is just to test hardware.

<code>________________________________________________________________

#include <Arduino.h>
#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11); // RX, TX for BT

#define BDR_pc 19200
#define BDR_zx6r 10400

//int MYUBRR=0;
int zx6r_rec_char=0;
char buf[3];
char temp=0;
char pc_char=0;

//initialisation
char start_kds[]={0x81, 0x11, 0xF1, 0x81, 0x04};   //5 signs
//ECU replies with ok: 80 F1 11 03 C1 EA 8F BF
char start_diagnostic_mode[]={0x80, 0x11, 0xF1, 0x02, 0x10, 0x80, 0x14}; //7 signs
//ECU replies with OK: 80 F1 11 02 50 80 54

char ask_gear[]={0x80, 0x11, 0xF1, 0x02, 0x21, 0x0B, 0xB0};// 7 signs
char ask_temp[]={0x80, 0x11, 0xF1, 0x02, 0x21, 0x06, 0xAB}; //7 signs


void serial_write_c(char c)
{
while (!( UCSR0A&(1<<UDRE0)));
    UDR0 = c;
}

void kds_start_sesion()
{
    char i_kds_start;

    Serial.end();
    pinMode(13, OUTPUT);
    for(i_kds_start=0; i_kds_start<15; i_kds_start++)   //waiting for kawa to wake up
        {
        digitalWrite(13, HIGH);
        delay(50);
        digitalWrite(13, LOW);
        delay(50);
        }

    pinMode(1, OUTPUT);
    digitalWrite(1, HIGH);
    delay(750); //in ms
    digitalWrite(1, LOW);
    delay(25);  //in ms
    digitalWrite(1, HIGH);
    delay(25);  //in ms

    Serial.begin(BDR_zx6r);
    mySerial.println("A");
    serial_write_c(0x81);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x81);
    serial_write_c(0x04);
    delay(200);

    mySerial.println("B");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x10);
    serial_write_c(0x80);
    serial_write_c(0x14);
    delay(200);

}

void setup()
{
mySerial.begin(BDR_pc);
}

void loop()
{


 if (Serial.available() > 0)
    {
    zx6r_rec_char = Serial.read();
    itoa(zx6r_rec_char, buf, HEX);
    mySerial.print(" 0x");
    mySerial.print(buf);
    }

if(mySerial.available())
    pc_char=mySerial.read();

if(pc_char==49) // 1 start initialisation
    {
    kds_start_sesion();
    pc_char=0;
    mySerial.println("_1");
    }

if(pc_char==50)//2 request gear no.
    {
    //0x80, 0x11, 0xF1, 0x02, 0x21, 0x0B, 0xB0
    mySerial.println("_2_gear= ");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x21);
    serial_write_c(0x0B);
    serial_write_c(0xB0);
    //delay(200);
    pc_char=0;
    }

if(pc_char==51)//3 request temp
    {
    //0x80, 0x11, 0xF1, 0x02, 0x21, 0x06, 0xAB
    mySerial.println("_3_temp= ");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x21);
    serial_write_c(0x06);
    serial_write_c(0xAB);
    //delay(200);
    pc_char=0;
    }

if(pc_char==52)//4 request SPEED
    {
    int i=0;
    //speed 0x80, 0x11, 0xF1, 0x02, 0x21, 0x0C, 0xAB
        mySerial.println(" ");
        mySerial.println("_4_speed-");
        serial_write_c(0x80);
        serial_write_c(0x11);
        serial_write_c(0xF1);
        serial_write_c(0x02);
        serial_write_c(0x21);
        serial_write_c(0x0C);
        serial_write_c(0xB1);
        mySerial.println(" ");
        //delay(200);
    pc_char=0;
    }


if(pc_char==53) //5 - all above in series
    {
    /*
    mySerial.println(" ");
    mySerial.print("_2_gear= ");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x21);
    serial_write_c(0x0B);
    serial_write_c(0xB0);
    delay(400);

    mySerial.println(" ");
    mySerial.print("_3_temp= ");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x21);
    serial_write_c(0x06);
    serial_write_c(0xAB);
    delay(400);
    */
    mySerial.println(" ");
    mySerial.print("_4_speed-");
    serial_write_c(0x80);
    serial_write_c(0x11);
    serial_write_c(0xF1);
    serial_write_c(0x02);
    serial_write_c(0x21);
    serial_write_c(0x0C);
    serial_write_c(0xB1);
    mySerial.println(" ");
    //pc_char=0;
    delay(125);
    }

}

</code>________________________________________________________________

small.jpg



Attachments
__________________
Reg B.


Senior Member

Status: Offline
Posts: 350
Date:

chszanek wrote:

question:

I have strange problem. After initialization i can read data but sometimes after few request to read data, ECU is not responding. Anyone know why? Then I need to reset Arduino, re initialize. It can by problem with my software, but maybe you came across the same issue. Cheers for help. 


K-line generally need a keep alive command in a certain time interval, else it will close the connection and you will need to re-init.
Anyone tested with an ELM327 yet?



__________________


Member

Status: Offline
Posts: 21
Date:

Quick update.

If you will ask about wrong register, ECU is sending error message:

80 F1 11 3 7F 21 10 35
where
7F- negative Response Service Identifier
21- request sent to ECU
10- "generalReject. The service is rejected but the server (ECU) does not specify the reason of the rejection. The communication timing is not affected by this response code!".

Any news about confirmation of Speed register?

 

regards

Bartek



__________________
Reg B.


Member

Status: Offline
Posts: 8
Date:

Hi Guys,

@chszanek, Sorry but I could not confirm the speed measure. I will explain the reason next line.

 

I thought on the 4 wires connector I would fine ground, supply, kline and probably unused lline. I connected my setup with this assumption. I can connect the ECU and read data. At some point the board just shutdown. It looks like power disappear. 

 

The question then is: Is this really a power supply? Anyone has this kind of experience?

 

I will try to connect directly to the battery to check the speed. Hopefully before the week-end.

Thanks,

 

I attached a picture of the connection. Blue is GND, RED is +12V (supposedly), GREEN is kline

 

 

Ben

 

zx6r-636 2013.

 

 



Attachments
__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hello!
Yes, It's power supply coming from ECU Main Relay.
This is a summary of connections on Z750R :
- GREEN / BLACK: (not used)
- WHITE / YELLOW: +12V from ECU Main Relay
- BLACK / YELLOW: GND
- RED / YELLOW: DATA BUS
coolben wrote:

The question then is: Is this really a power supply? Anyone has this kind of experience?


 



__________________


Member

Status: Offline
Posts: 8
Date:

Thanks for the quick reply. I just realized the problem comes from my pcb. The LDO shutdown for some reason  :(



__________________


Member

Status: Offline
Posts: 9
Date:

Hi,

could you please upload a Wiring Diagram of the Arduino? I build this thing but i can't get it to work.

I attached my Wiring. I use the L9637D.

Is it correct you have some LED or something on Pin13? If not where did your Pin13 go?

 

Thanks Phil



-- Edited by philro on Wednesday 21st of May 2014 01:11:48 PM

Attachments
__________________


Member

Status: Offline
Posts: 9
Date:

Hi,

i solved the Problem. I used a wrong Pullup.

 

Thanks 

Phil



-- Edited by philro on Wednesday 21st of May 2014 02:06:47 PM

__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

Hello Philro! those are not replies but all requests. 

They are sequences to start diagnostic communication. (from 0x11 to 0xF1)

Look at my post above. smile

What you see are the VIOLET bytes. You miss the GREEN ones coming from ECU.

The bus is one-wire: so what send is also received...

 

Bye



-- Edited by MXP on Wednesday 21st of May 2014 02:12:23 PM

__________________


Member

Status: Offline
Posts: 9
Date:

Hello MXP,

 

first i thought i missed RX/TX on the Arduino to the L9637. But you're right. Its an One-Wire Bus. That means my ECU doens't replay at all. Any idea what i've missed?

 

Thanks

Phil



__________________
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

- Did u remember the 25ms pause before start communication? bus should be kept LOW for 25ms and then HIGH for other 25ms before starting communication.

- It would be better to verify at the oscilloscope this timing sequence.

- You should also verify the unusual baudrate on the bus (10417 baud) with the oscilloscope. Bit-period should be exaclty 96us long.

Bye!



-- Edited by MXP on Wednesday 21st of May 2014 02:33:04 PM

__________________


Member

Status: Offline
Posts: 9
Date:

Hi,
i copied the code fom chszanek he posted 10 days Ago. The only difference to him is i use a cable connection, no Bluetooth.
Greets
Phil


__________________


Member

Status: Offline
Posts: 21
Date:

Hi Philro
Let start from beginning, please, draw the schematic firs, maybe hardware is wring.
this "layout" is not so useful. I use interrupts on this one, please check if your uC use the same interrupt registers.


cheers.
bartek

to > MXP

I don't have any problems with Arduino and 10400bdr, and the clock is 8MHz. I think that the error is quite small, it shouldn't be more then 7.6% (please refer to ATmega328 datasheet, 19.11 Examples of Baud Rate Setting section). i don't have problems with that.



-- Edited by chszanek on Friday 23rd of May 2014 01:47:25 PM

__________________
Reg B.


Member

Status: Offline
Posts: 9
Date:

Hi chszanek,

 

i hope this picture makes it more clear. 

Thanks for Help

Phil



Attachments
__________________


Member

Status: Offline
Posts: 21
Date:

2 things:
1) you dont need 7805... and it should have some capacitors if you really want it. Trow it away and connect +12 to he RAW pin apparently it has voltage stabilizer(double check), read :

"There is a voltage regulator on board so it can accept voltage up to 12VDC. If you're supplying unregulated power to the board, be sure to connect to the "RAW" pin on not VCC.

The power pins are as follows:

RAW. For supplying a raw voltage to the board.
VCC. The regulated 3.3 or 5 volt supply.
GND. Ground pins.
" (from Aduino web site, http://arduino.cc/en/Main/ArduinoBoardProMini "),


2) You dont have +5v supplied to Vcc on L9637(pin 3), read manual.

Double check interrupts settings (the should be the same but...).

after this, try again. let me know what happened.

reg
b.



__________________
Reg B.


Member

Status: Offline
Posts: 9
Date:

Hi chszanek,

 

thanks for the hint with the 5 Volts. I connect the 5 volts and get one step further.

I can communicate with the ECU now.

I could start the communication and a diag-session and the ECU replies "OK" to both. But after that comes nothing. The ECU didn't reply to any other request (Gear, Temp, Speed)

Should the Engine be running or is ignition enough?  Any other Idea?

 

Thanks

Phil



__________________


Member

Status: Offline
Posts: 21
Date:

Hi,
this (old one) software is not automatic, just o check if hardware work, so after establishing the diag ses. straight away start to ask for gear or other things, I noticed that if you dont ask frequently enough (even gap around 2 seconds) the ecu is cutting off diag session (please read MXp post below, he did pointed it to me).

you could modify his firmware to start "pinging" ecu all the time... up to you:) I'm working on the "whole package firmware". But i have still around two weeks to release it here :)


reg
Bartek

read:
"MXP>
Hello!

Do you need just to re-init the ECU or hardware reset?

Because in the first case, maybe you are not "pinging" the ECU enough with requests: without requests for a while it goes back to normal mode and you need to re-initialise the communication with ECU again.

On the other side, with HW reset, it could be a problem of your firmware: I ask values continuosly and I never need to restart or reset comm.

BYe!!
"



-- Edited by chszanek on Sunday 25th of May 2014 11:06:54 AM



-- Edited by chszanek on Sunday 25th of May 2014 11:08:12 AM

__________________
Reg B.


Member

Status: Offline
Posts: 9
Date:

Hi,

 

the ping did the trick! Thank you very much! Now its working as supposed. Would you tell me how i get the answers of Gear and Temp in an Integer Variable? My Arduino knowledge seems not so good as i thought.  

Or did i have to wait since you release your whole Software?

Thanks 

Greets Phil



__________________


Member

Status: Offline
Posts: 21
Date:

Hi Phil,
Don't wait :), try to crack it by yourself, it will benefit you (your knowledge).
But I will release it shortly. I will release 2 revisions, one on Arduino Uno (as second) and for Arduino Mega (as first one).
I migrated to Arduino Mega because i added to my design SD card, GPS, and LCD (as per photo attached) so i needed a loot of memory and extra 3 UART's :).

cheers.

Regard
Bartek

CAM00261.jpg

 

CAM00263.jpg



Attachments
__________________
Reg B.


Member

Status: Offline
Posts: 9
Date:

Hi Bartek,

this looks great! It seems we have almost the same project. But i do it with the Minis. One Mini to get Gear and Temp on a Display and another Mini to Log GPS, Altitude, Speed and lean angle to a microSD. 

I had a look at the code yesterday and think i got a step further. But far away from a working version. Im looking forward to your release. 

 

cheers

Phil



__________________


Member

Status: Offline
Posts: 21
Date:

Hi Guys i think I fond another register, Throttle opening:

reg is 0x04;

0x80 0xf1 0x11 0x4 0x61 0x4 0x0 0xd8 0xc3 = 0%

0x80 0xf1 0x11 0x4 0x61 0x4 0x3 0x7f 0x6d = 100%

i did small interpolation and used equation:

=(val1*255+val2-offset1)/(3*255+offset2-offset1)*100 = throttle [ %];

offset1=216 (0x8D); (value for 0% throttle from ECU)

offset2=117 (0x7F); (Value for 100% throttle from ECU)

please have a look in to the attached table. Those it make any sense?

 Could someone verify 0x04 reg and 0x0C reg as well, please?

registered from my zx6r:

 :) I just noticed that padFR passed this info before :) sorry.

So in this case i can just confirm that 0x04 is throttle position. I was just wondering if the offset values variates with bike model...? does anyone knows?

 

cheers



-- Edited by chszanek on Sunday 1st of June 2014 09:55:02 PM

__________________
Reg B.
MXP


Veteran Member

Status: Offline
Posts: 28
Date:

chszanek wrote:

Hi Guys i think I fond another register, Throttle opening:

reg is 0x04;

0x80 0xf1 0x11 0x4 0x61 0x4 0x0 0xd8 0xc3 = 0%

0x80 0xf1 0x11 0x4 0x61 0x4 0x3 0x7f 0x6d = 100%

i did small interpolation and used equation:

=(val1*255+val2-offset1)/(3*255+offset2-offset1)*100 = throttle [ %];

offset1=216 (0x8D); (value for 0% throttle from ECU)

offset2=117 (0x7F); (Value for 100% throttle from ECU)

please have a look in to the attached table. Those it make any sense?

 Could someone verify 0x04 reg and 0x0C reg as well, please?

registered from my zx6r:

 :) I just noticed that padFR passed this info before :) sorry.

So in this case i can just confirm that 0x04 is throttle position. I was just wondering if the offset values variates with bike model...? does anyone knows?

 

cheers



-- Edited by chszanek on Sunday 1st of June 2014 09:55:02 PM


 

Hello friend!

Since it's a two-byte value (an unsigned integer), I think you'd better consider your equation in this form:

- offset2 is [3*256 + 0x7F]  (and not only 0x7F which is lower than offset1)

- denominator should be [offset2 - offset1] (without 3*255 that should be 3*0x100)

In my opinion that has more sense! ;)

Anyway you did a great job!

Bye



-- Edited by MXP on Tuesday 3rd of June 2014 01:10:11 PM



-- Edited by MXP on Tuesday 3rd of June 2014 01:15:29 PM



-- Edited by MXP on Tuesday 3rd of June 2014 01:31:22 PM

__________________


Member

Status: Offline
Posts: 21
Date:

Thx for tip,
MXP did you had chance to check(confirm) 0x0c?

cheers

__________________
Reg B.
1 2  >  Last»  | Page of 2  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