Arduino Forum

Topics => Device Hacking => Topic started by: o5i_ on Apr 27, 2014, 12:20 am

Title: Bike interface OBD
Post by: o5i_ on Apr 27, 2014, 12:20 am
Hi

I hava a suzuki gsx-r 1000 and want to log the serial data that the bike transmits over the k-line diagnostics interface called SDS:..
First step ist to attach a pc and log the comunication between pc and ecu. I want to use an arduino board if it ist possible...
Is it possible to connect each serial line to an rx line of the arduino and log them to sd?
I dont know exactly the baud rates, this is what i neet to find out...
(http://fish.x64.me/doc/serial_data.jpg)
Later i want to use the logged information to create a file definition and write direktly to ecu and store the recieved data to sd and maybee monitor it to an tft or webserver...
There are people who did this, i have a lot of definitions from them, but im not sure about the comunication...
Title: Re: Bike interface OBD
Post by: robtillaart on Apr 27, 2014, 10:21 am
please replace the BMP image with a JPEG as it now take almost 3MB for a relative simple image.
a jpeg for this would be (estimate)  30x smaller.

you need a logic analyzer to determine the baudrate and to see the data.
another point of attention is what voltage comes out of the ECU as Arduino and the (USB) PC uses 0..5V levels.
The ECU might use real rs232 which uses higher voltages.



Title: Re: Bike interface OBD
Post by: o5i_ on Apr 28, 2014, 11:19 am
Ok..
About the Voltage, i need to add some ics, because the data is transfered by K-Line.. It is not problematic...
But i dont know if the sketch work.
I put a serial read of both serials in loop an than a print command... Is the arduino fast enough to write every single bit or i need to write first into ram? I think it sounds a litlebit strange, but im new here :D
Later i post the sketch i have made...
Title: Re: Bike interface OBD
Post by: robtillaart on Apr 28, 2014, 02:47 pm
probably the speed of the OBD is low to medium speed to be 100% reliable. You could use MAX speed for your print command

What board are you using UNO/MEGA?
Title: Re: Bike interface OBD
Post by: o5i_ on Apr 28, 2014, 10:13 pm
Ok it works, i used the 10400 baud as described for kwp2000 on the RX Serial Ports.
First i connect to the print port whit 9600 and of course it was to slow, i changed it to 57600 and it was ok :D
Now i have send and response data...
Here my sketch
Code: [Select]

void setup() {
  // initialize serial ports:
  //console
  Serial.begin(57600);   
  // Serial PORT 1
  Serial1.begin(10400);
  // Serial PORT 2
  Serial2.begin(10400);
  // Welcome Message
  Serial.println("##################################################");
  Serial.println("###########  Serial Logging Interface  ###########");
  Serial.println("##################################################");
  Serial.println();
}
void loop() {
    if (Serial1.available()) {
      Serial.print("ECU: ");
      Serial.print(Serial1.read(), HEX);
      Serial.println("");
    if (Serial2.available()) {
      Serial.print("PC: ");
      Serial.print(Serial2.read(), HEX);
      Serial.println("");
  }
}

But now i neet to know how the initialiton works... I saw something in the obduino sketch an i think i try that...
Title: Re: Bike interface OBD
Post by: o5i_ on Apr 28, 2014, 10:53 pm
This is the Logfile:
I think the pc writes a lot of strings whitout reading answeres at the same time.  The Ecu at this point is much slower answering because the string is longer...
Ex.
PC     Startpoint: bla bla bla bla bla bla
ECU   Startpoint: blablablablabla blablablablabla blablablablabla blablablablabla blablablablabla blablablablabla
Code: [Select]
PC: 80
ECU: 12
PC: 12
ECU: F1
PC: F1
ECU: 2
PC: 2
ECU: 21
PC: 21
PC: 80
ECU: 80
PC: 26
ECU: 26
ECU: 80
ECU: F1
ECU: 12
ECU: 66
ECU: 61
ECU: 80
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 57
ECU: 6B
ECU: 62
ECU: FF
ECU: FF
ECU: FF
ECU: 80
ECU: 15
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 80
ECU: 0
ECU: FF
ECU: 80
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: 80
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 80
ECU: 80
ECU: 80
ECU: 80
ECU: 0
ECU: D
ECU: 0
ECU: D
ECU: 0
ECU: D
ECU: 0
ECU: D
ECU: FF
ECU: FF
ECU: 80
ECU: 0
ECU: 15
ECU: 0
ECU: 1D
ECU: 0
ECU: 17
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 80
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 80
ECU: 80
ECU: 80
ECU: 80
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 8C
ECU: 80
ECU: F0
ECU: C1
ECU: FF
ECU: FF
ECU: FF
ECU: FF
PC: 80
ECU: FF
PC: 12
ECU: FF
PC: F1
ECU: 16
PC: 2
ECU: E5
PC: 21
ECU: 5
PC: 8
ECU: 0
PC: AE
ECU: 0
ECU: FF
ECU: FF
ECU: 14
ECU: 80
ECU: 12
ECU: F1
ECU: 2
ECU: 21
ECU: 8
ECU: AE
ECU: 80
PC: 80
ECU: 12
PC: 12
ECU: F1
PC: F1
ECU: 2
PC: 2
ECU: 21
PC: 21
PC: 8
ECU: 8
ECU: AE
PC: AE
ECU: 80
ECU: F1
ECU: 12
ECU: 34
ECU: 61
ECU: 8
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 3A
ECU: A1
ECU: 52
ECU: 4E
ECU: A1
ECU: 0
ECU: FF
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: 40
ECU: 40
ECU: 40
ECU: 40
ECU: FF
ECU: F4
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 4
ECU: 8
ECU: FF
ECU: FF
ECU: 2B
ECU: 80
PC: 80
ECU: 12
PC: 12
ECU: F1
PC: F1
ECU: 2
PC: 2
ECU: 21
PC: 21
ECU: 8
PC: 8
ECU: AE
PC: AE
ECU: 80
ECU: F1
ECU: 12
ECU: 34
ECU: 61
ECU: 8
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 3A
ECU: A1
ECU: 52
ECU: 4E
ECU: A1
ECU: 0
ECU: FF
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: 40
ECU: 40
ECU: 40
ECU: 40
ECU: FF
ECU: F4
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 4
ECU: 8
ECU: FF
ECU: FF
ECU: 2B
ECU: 80
PC: 80
ECU: 12
PC: 12
ECU: F1
PC: F1
ECU: 2
PC: 2
ECU: 21
PC: 21
ECU: 8
PC: 8
ECU: AE
PC: AE
ECU: 80
ECU: F1
ECU: 12
ECU: 34
ECU: 61
ECU: 8
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 3A
ECU: A1
ECU: 52
ECU: 4E
ECU: A1
ECU: 0
ECU: FF
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: 40
ECU: 40
ECU: 40
ECU: 40
ECU: FF
ECU: F4
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 4
ECU: 8
ECU: FF
ECU: FF
ECU: 2B
ECU: 80
PC: 80
ECU: 12
PC: 12
ECU: F1
PC: F1
ECU: 2
PC: 2
ECU: 21
PC: 21
ECU: 8
PC: 8
ECU: AE
PC: AE
ECU: 80
ECU: F1
ECU: 12
ECU: 34
ECU: 61
ECU: 8
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 3A
ECU: A1
ECU: 52
ECU: 4E
ECU: A1
ECU: 0
ECU: FF
ECU: 0
ECU: FF
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: 0
ECU: FF
ECU: FF
ECU: 40
ECU: 40
ECU: 40
ECU: 40
ECU: FF
ECU: F4
ECU: FF
ECU: FF
ECU: FF
ECU: 0
ECU: 0
ECU: 4
ECU: 8
ECU: FF
ECU: FF
ECU: 2B
ECU: 80
Title: Re: Bike interface OBD
Post by: robtillaart on Apr 29, 2014, 11:12 am
small remark
Code: [Select]
      Serial.print(Serial1.read(), HEX);
      Serial.println("");


==>

Code: [Select]
      Serial.println(Serial1.read(), HEX);
Title: Re: Bike interface OBD
Post by: o5i_ on Apr 29, 2014, 10:53 pm
;)
Title: Re: Bike interface OBD
Post by: robtillaart on Apr 29, 2014, 11:01 pm
try to change loop to
Code: [Select]

void loop()
{
    if (Serial2.available())
    {
        Serial.print("PC:\t");
        while(Serial2.available())
        {
            int b = Serial2.read();
            if (b < 10) : Serial.print("0");
            Serial.print(b , HEX);
            Serial.print(" ");
        }
        Serial.println();
    }

    if (Serial1.available())
    {
        Serial.print("ECU:\t");
        while(Serial1.available())
        {
            int b = Serial1.read();
            if (b < 10) : Serial.print("0");
            Serial.print(b , HEX);
            Serial.print(" ");
        }
        Serial.println();
    }
}

might give you more insight in the handshakes
Title: Re: Bike interface OBD
Post by: o5i_ on May 01, 2014, 11:20 pm
Now i need to do this whit the arduino, dont know where begin, maybee by decoding it?
I have a question, the digital outputs, if state is not defined are they on high resistance? There are some pins on the ecu e want to switch but i only know that they can be switched by switches, if i put them from 0-5V maybee it want work.. 2 are switched to 0V one to 5V... Is it possibe to use the arduino as serial to usb converter? If i put a switch the inputs from usb / serial 0 to an other port... Or is it dangerous for the arduino because it is the programing interface?
Title: Re: Bike interface OBD
Post by: o5i_ on May 04, 2014, 01:51 am
Hi, i did some work...
But i added only some analog inputs and one serial for the Wideband Lambda...
How is the best way to get the code? I think an array would be the best way to go?
How can i create the checksum of an array whit 61 values?

Code: [Select]
#include <SD.h>
#include <UTFT.h>

#define CONSOLE Serial                      // CONSOLE PORT
#define CONSOLEBAUD 57600
#define WBL Serial1                          // WIDEBAND LAMBDA PORT
#define WBLBAUD 9600
#define SDS Serial2                          // SDSPORT
#define SDSBAUD 10400

const int chipSelect = 53;                  // SD CS Pin
const int startlog = 8;                     // Start stop
const int mode = 9;                         // Logger - Flash mode

float sensors[99];
String name_sensors[99];

int inputpin;
int numbersensors;
int lineposition;
int sensornumber;
int SDPRESENT;
int SDDETECT;

extern uint8_t SmallFont[];
extern uint8_t BigFont[];

UTFT myGLCD(SSD1289,38,39,40,41);

void getvalues();
void clear_console();
void sd_print();
void console_print();
void tft_printvalues();
void sd_init();

void setup() {
  CONSOLE.begin(CONSOLEBAUD);
  WBL.begin(WBLBAUD);
  SDS.begin(SDSBAUD);

  pinMode(startlog, INPUT);
  pinMode(mode, INPUT);
  pinMode(10, OUTPUT);

  myGLCD.InitLCD();
  myGLCD.clrScr();
  myGLCD.setFont(SmallFont);
  myGLCD.fillScr(0, 0, 150);
  myGLCD.setBackColor(0, 0, 150);
  myGLCD.setColor(255,255,255);
}

void loop() {
  getvalues();
  sd_init();
  sd_print();
  console_print();
  tft_printvalues();
  clear_console();
}

void getvalues () {
  sensornumber = 0;
  inputpin = 3;
  name_sensors[sensornumber] = "Abgas Temp (analog) [C]";
  sensors[sensornumber] = float(analogRead(inputpin)) / 1.5 - 200;

  sensornumber = 1;
  inputpin = 4;
  name_sensors[sensornumber] = "Motor Temp (analog) [C]";
  sensors[sensornumber] = float(analogRead(inputpin)) * 0.1;

  sensornumber = 2;
  inputpin = 5;
  name_sensors[sensornumber] = "Drosselklappe (analog) [%]";
  sensors[sensornumber] = float(analogRead(inputpin)) * 0.103 ;

  sensornumber = 3;
  name_sensors[sensornumber] = "Gemisch (seriell) [LAMBDA]";
  if (WBL.available() > 0) {
    sensors[sensornumber] = WBL.read();
  }

  numbersensors = sensornumber;
}

void tft_printvalues() {
  for (sensornumber = 0;sensornumber <= numbersensors; sensornumber = sensornumber + 1) {
    myGLCD.print(name_sensors[sensornumber], LEFT, lineposition);
    myGLCD.print(String(int(sensors[sensornumber])), RIGHT, lineposition);
    lineposition = lineposition + 20;
  }
  lineposition = 0;
}
void console_print() {
  for (sensornumber = 0;sensornumber <= numbersensors; sensornumber = sensornumber + 1) {
    CONSOLE.print(name_sensors[sensornumber]);
    CONSOLE.print(": ");
    CONSOLE.println(sensors[sensornumber]);
  }
}
void clear_console() {
  CONSOLE.write(27);
  CONSOLE.print("[2J");
  CONSOLE.write(27);
  CONSOLE.print("[H");
}
void sd_init() {
  while (!SDDETECT) {
    CONSOLE.println("###### Detecting SD Card ######");
    myGLCD.print("###### Detecting SD Card ######", CENTER, 220);
    if (!SD.begin(chipSelect)) {
      CONSOLE.print("#### SD Card not found ######");
      myGLCD.print("###### SD Card not found ######", CENTER, 220);
      SDDETECT++;
    }
    else {
      CONSOLE.print("###### SD Card Initialized ######");
      myGLCD.print("###### SD Card Initialized ######", CENTER, 220);
      SDDETECT++;
      SDPRESENT++;
    }
  }
}
void sd_print() {
  if ((SDPRESENT)&&(SDDETECT)) {
    File datafile = SD.open("LOGFILE.TXT", FILE_WRITE);
    if (datafile) {
      CONSOLE.println("###### Writing into LOGFILE.TXT ######");
      myGLCD.print("###### Writing into LOGFILE.TXT ######", CENTER, 220);
      datafile.print(millis());
      for (sensornumber = 0;sensornumber <= numbersensors; sensornumber = sensornumber + 1) {
        datafile.print(":");
        datafile.print(sensors[sensornumber]);
      }
      datafile.println(":");
      datafile.close();
    }
    else {
      CONSOLE.println("###### SD Card writing ERROR ######");
      myGLCD.print("###### SD Card writing ERROR ######", CENTER, 220);
      SDPRESENT = 0;
    }
  }
}
Title: Re: Bike interface OBD
Post by: robtillaart on May 04, 2014, 10:04 am
Quote
How can i create the checksum of an array whit 61 values?

a for loop over all 61 values
- either with a defined formula
- or your own formula  (simplest is to add all the values and see if the sum matches)
Title: Re: Bike interface OBD
Post by: o5i_ on May 08, 2014, 10:44 am
Ok, i have managed the formula.. Now, at the start of the communication i need to do a fastinit how it ist described in kwp protocol.. I need to put the Serial output for 300ms high than 25ms low and again 25ms low before i can start the serial communication whit 10400baud... or slowinit is 0x33 @ 5 baud...
Can i do "serial.begin(baud)" more than 1 time?
Title: Re: Bike interface OBD
Post by: robtillaart on May 08, 2014, 08:44 pm

Ok, i have managed the formula.. Now, at the start of the communication i need to do a fastinit how it ist described in kwp protocol.. I need to put the Serial output for 300ms high than 25ms low and again 25ms low before i can start the serial communication whit 10400baud... or slowinit is 0x33 @ 5 baud...
Can i do "serial.begin(baud)" more than 1 time?

Yes you can but this sounds more like you need a dedicated handshake , setting high and low "manually".
in my (limited) experience the very low baud rates are not that reliable
Title: Re: Bike interface OBD
Post by: o5i_ on May 08, 2014, 09:52 pm
How can i manage it?
I want to do fastinit how described in kwp2000 ISO 14230 ...
here are a lot of snippets i have found in posts
http://fish.x64.me/doc/infos.txt
Title: Re: Bike interface OBD
Post by: robtillaart on May 09, 2014, 07:56 pm
use digitalWrite(1, HIGH/LOW);
and use delay to time the pulses.
Be sure your serial buffer is empty when starting
Title: Re: Bike interface OBD
Post by: o5i_ on May 12, 2014, 11:05 pm
I have a lot of trouble get this done..
Somone want to help me?
I tried to read the data while it is connected to the pc but it won`t work... But i earn only a lot of bugs...
same whit init... Dont know whats wrong... Im shure there are people who did this successfull...
But whitout skills no way...
Title: Re: Bike interface OBD
Post by: cyclegadget on May 13, 2014, 08:06 pm
I have some parts and information that could be helpful. I'm not at home right now.  What country or area are you from? I will try to post more later on.
Title: Re: Bike interface OBD
Post by: o5i_ on May 13, 2014, 09:10 pm
Hi, im from north italy.. If you can help me would be great  :)
Title: Re: Bike interface OBD
Post by: cyclegadget on May 14, 2014, 03:34 am
o5i,

  The first thing you will need is the hardware to connect your 5 volt arduino to your 12 volt motorcycle communication line. I have a circuit board that uses a LM393 as a level shifter. I had a bunch of circuit boards made and I was selling an interface that goes from computer USB to the bikes computer.....I have a few boards left over. They work with 07 GSXRs and newer as far as I know. Personally, I have an 08 GSXR and it works well on it. If you want to go the computer route, let me know. Otherwise, I will help you with your Arduino project.

I have put a lot of work on getting an Atmel 1284 chip to talk to the motorcycle computer and I have had some success but, the project is not completed. I will share some of my hard work with you to get you started.

Here is the initiation part of the code that works well for me. I am providing you with a snippet to get you started. After the initiation part of the code, you are going to need read incoming data. Add you coding ideas, put in effort, and I will help more.

You will need to define your TX and RX pins based on the board you are using. In my case, my board is the Bobuino with a 1284 chip.

Code: [Select]

//variables
byte message[6] = {
  0x81,0x12,0xF1,0x81,0x05};
int mode = 0;
/////////////////DATA START///////////////
void datastart(){
  mode = 0;                 //reset mode to 0 for first step of logging
  digitalWrite (TX, HIGH);  // makes K-line high 3
  digitalWrite(ledPin,HIGH);
  delay(2000);             // wait for K-line to be clear 3
  digitalWrite (TX, LOW);  // makes K-line low  3
  delay(25);
  digitalWrite (TX, HIGH); // makes K-line high  3
  delay(25);               //last delay before first message
  Serial1.begin(10400);  // baud rate of the OBD
  //send package 0x81,0x12,0xF1,0x81,0x05
  for (int i = 0; i < 5; i++){
    Serial1.write(message[i]);
    byte inByte = Serial1.read();
    delay(1);                 //inter byte delay for to match k-line spec. changed from 15ms to 1, tune as needed
  }
}



 
Title: Re: Bike interface OBD
Post by: o5i_ on May 14, 2014, 08:20 am
Thanks, i try if it works... I have a code that send something but the ecu didnt reply... I tried to log the data when ecueditor is running but it looses some data...
I have an BC547 level shifter like this one http://fish.x64.me/doc/INTERFACE_RUFER.pdf (http://fish.x64.me/doc/INTERFACE_RUFER.pdf)
But i want to use one like yours whit LM393 on it because it is smaller.
I think it is going forward...
You know if it is possible to connect the digital out pins directly to the pins of the  ecu like "mode (map switch)" "reset" "fwe" "dealer mode" and of course the programing pins? In case of that it can be used als programing interface too...

Title: Re: Bike interface OBD
Post by: cyclegadget on May 14, 2014, 12:27 pm

You know if it is possible to connect the digital out pins directly to the pins of the  ecu like "mode (map switch)" "reset" "fwe" "dealer mode" and of course the programing pins? In case of that it can be used als programing interface too...




I think that the answer is "yes" because you can connect directly to the 5 volt FTDI cable to the ECU on the "reset" "fwe" pins .  I have only logged with the Arduino, and I have never made any attempts to program using the Arduino. I would exercise caution when connecting to the map switch and dealer mode by using resistors to limit current.
Title: Re: Bike interface OBD
Post by: o5i_ on May 14, 2014, 07:31 pm
I have a problem, i tried the code and put an other serial on it to see waht the ecu responds but the ecu only replies the same as i have send...
I think there is something wong, maybee the pin 18/19 on mega are not the serial ones or i need to use the serial0? Last time i tried whit same result...
Code: [Select]

#define TX 18
#define RX 19
#define ledPin 10
#define console Serial
#define cbaud 14400
#define sds Serial1
#define sdsbaud 10400

//variables
byte message[] = {
  0x81,0x12,0xF1,0x81,0x05};
int mode = 0;

void setup() {
}

void loop() {
  datastart();
}


/////////////////DATA START///////////////
void datastart(){
  mode = 0;                 //reset mode to 0 for first step of logging
  digitalWrite (TX, HIGH);  // makes K-line high 3
  digitalWrite(ledPin,HIGH);
  delay(2000);             // wait for K-line to be clear 3
  digitalWrite (TX, LOW);  // makes K-line low  3
  delay(25);
  digitalWrite (TX, HIGH); // makes K-line high  3
  delay(25);               //last delay before first message
  console.begin(cbaud);    // test ---------------------------------------------------------------------------------------
  sds.begin(sdsbaud);  // baud rate of the OBD
  //send package 0x81,0x12,0xF1,0x81,0x05
  for (int i = 0; i < 5; i++){
    Serial1.write(message[i]);
    byte inByte = sds.read();
    console.println(inByte,HEX);  //test -----------------------------------------------------------------------------------
    delay(1);                 //inter byte delay for to match k-line spec. changed from 15ms to 1, tune as needed
  }
}
Title: Re: Bike interface OBD
Post by: robtillaart on May 14, 2014, 07:41 pm
Quote
maybee the pin 18/19 on mega are not the serial ones


- http://arduino.cc/en/Main/ArduinoBoardMega2560 -

check for pinMapping
Title: Re: Bike interface OBD
Post by: o5i_ on May 14, 2014, 08:46 pm
Dont know whats wrong here... I think it should work? Why the ecu responds whit the same string?
I have tried to send whit the arduino and recieve whit the ftdi but it shows nothing usefull... Maybee there is something wrong whit the arduino? Its a mega 2560..
Title: Re: Bike interface OBD
Post by: robtillaart on May 14, 2014, 10:08 pm

Code: (???) [Select]

void datastart()
{
  mode = 0;
  digitalWrite (TX, HIGH);  // <<<<<<<<<<<<<
  digitalWrite(ledPin, HIGH);
  delay(2000);
  digitalWrite (TX, LOW);
  delay(25);
  digitalWrite (TX, HIGH);
  delay(25);
  console.begin(cbaud);    // <<<<<<<<<<
  sds.begin(sdsbaud);   //  <<<<<<

  for (int i = 0; i < 5; i++)
  {
    Serial1.write(message[i]);  // <<< byte array ?
    while (sds.Available() == 0); // blocking wait for byte to arrive
    byte inByte = sds.read();
    console.println(inByte, HEX);
  }
  console.println();
}

Some questions
is TX the transmitpin of Serial1, console or from sds or something else ?
why are those two baudrates initialized in the middle of this function ?

I have added auto tuning for the byte reception, assuming SDS implements an Available() function.
and assuming there will arrive 5 bytes.

Dont know if this helps,

you could try to write some minimal sketches that just test single functions hjust to verify.
- 3 sketches for the 3 serial ports
- etc
diagnostics step by step
Title: Re: Bike interface OBD
Post by: o5i_ on May 14, 2014, 11:21 pm
Hi, i have read some things, according whit somebody who knows how it works the arduino maybee have problems to get the right timing. The protocol has a tolerance of +-1ms....  Is there a way to test?
The replys probably are echos, the data is transmitted throug one wire...
Title: Re: Bike interface OBD
Post by: cyclegadget on May 15, 2014, 03:17 am
Quote
The replys probably are echos, the data is transmitted throug one wire...


You are correct, you will get echo. My answer for this was to read the bytes available until they equal the amount sent. In the first part of the code, I sent this:
Code: [Select]
byte message[6] = {0x81,0x12,0xF1,0x81,0x05};

To get around the echo problem, I read 5 bytes, if the fifth by equals 0x05, then the next byte is coming from the ECU.

Quote
The protocol has a tolerance of +-1ms....  Is there a way to test?


I started with "extra" time between bytes sent and I gradually reduced the delay between bytes and I watched for loss of communication. I used a potentiometer in my sketch to make my timing adjustable on the fly.  
Title: Re: Bike interface OBD
Post by: cyclegadget on May 15, 2014, 03:26 am

o5i_

I also thought you should know that you do not want to use Software Serial for communicating with the ECU. In my case, I found that it was far easier to use Hardware Serial.

Also, in my case, I used Serial1 for communication with ECU and Serial0 to repeat the data to my computer during testing.
I would recommend doing the same with your Mega if it is possible.
Title: Re: Bike interface OBD
Post by: o5i_ on May 15, 2014, 10:34 pm
Hi, i had sucess, i got some AE 8F replys, but they were somewhere between the echos..
i only need to add
pinMode(TX, OUTPUT);
:D
But it is not working everytime i try..
Title: Re: Bike interface OBD
Post by: cyclegadget on May 15, 2014, 11:55 pm

Post the code you are using and maybe we can find some improvements.

Another tip, I made the baud rate from my Arduino to my computer 115,200 which is the fastest setting the Serial Monitor allows. The reason I did this was to insure that I was not taking up too much time sending data to the computer.
Title: Re: Bike interface OBD
Post by: o5i_ on May 16, 2014, 08:03 pm
Hi

I did this;
Code: [Select]
#define TX 18
#define console Serial
#define cbaud 115200
#define sds Serial1
#define sdsbaud 10400

//variables
byte message[6] = {
  0x81,0x12,0xF1,0x81,0x05};

void setup() {
  console.begin(cbaud);
  pinMode(TX, OUTPUT);
}

void loop() {
  datastart();
}

/////////////////DATA START///////////////
void datastart(){
  digitalWrite (TX, HIGH);  // makes K-line high 3
  delay(2000);             // wait for K-line to be clear 3
  digitalWrite (TX, LOW);  // makes K-line low  3
  delay(25);
  digitalWrite (TX, HIGH); // makes K-line high  3
  delay(25);               //last delay before first message
  sds.begin(sdsbaud);  // baud rate of the OBD
  //send package 0x81,0x12,0xF1,0x81,0x05
  for (int i = 0; i < 5; i++){
    sds.write(message[i]);
    byte inByte = sds.read();
    console.print(inByte,HEX);
    delay(1);
  }
  console.println();
  while (!sds.available());
  while (sds.available()) {
    console.println(sds.read(),HEX);
  }
}



And recieved this:
Code: [Select]
FFFFFFFFFF
FF8112F181
5
80F1123C1
EA
8F
C0
81
12
F1
81
5
FF8112F181
5
FF8112F181
5

Title: Re: Bike interface OBD
Post by: o5i_ on May 16, 2014, 09:18 pm
This one works good:
Code: [Select]
#define TX 18
#define console Serial
#define cbaud 57600
#define sds Serial1
#define sdsbaud 10400

//variables
byte message[6] = {
 0x81,0x12,0xF1,0x81,0x05};
int length = 5;
int counter;
int mode;

void setup() {
 console.begin(cbaud);
 pinMode(TX, OUTPUT);
}

void loop() {
 fastinit();
 sendrequest();
 recievedata();
}

void fastinit(){
 if (!mode) {
   digitalWrite (TX, HIGH);  // makes K-line high 3
   delay(2000);             // wait for K-line to be clear 3
   digitalWrite (TX, LOW);  // makes K-line low  3
   delay(25);
   digitalWrite (TX, HIGH); // makes K-line high  3
   delay(25);               //last delay before first message
   sds.begin(sdsbaud);  // baud rate of the OBD
   mode++;
 }
}
void sendrequest() {
 if (counter < length) {
   sds.write(message[counter]);
   // delay(1);
   counter++;
 }
}
void recievedata() {
 if (sds.available()){
   console.print(sds.read(),HEX);
 }
}

Reply:
Code: [Select]
8112F181580F1123C1EA8FC0
Hope there are no problems if the code became longer...
Title: Re: Bike interface OBD
Post by: o5i_ on May 17, 2014, 12:56 am
Litle update
Code: [Select]

#define TX 18
#define console Serial
#define cbaud 57600
#define sds Serial1
#define sdsbaud 10400

//variables
int dotdelay = 1000;
int timeout = 10000;
int timeold;



int messagelength = 5;
byte message[5] = {
  0x81,0x12,0xF1,0x81,0x05
};
int responselength = 8;
byte message_response[8] = {
  0x80,
  0xF1,
  0x12,
  0x03,
  0xC1,
  0xEA,
  0x8F,
  0xC0
};


int mode;


void setup() {
  console.begin(cbaud);
  pinMode(TX, OUTPUT);
}

void loop() {
  fastinit();
  sendrequest();
  recievedata();
}

void fastinit(){
  if (!mode) {
    console.println("starting comunication (fastinit)");
    digitalWrite (TX, HIGH);  // makes K-line high 3
    console.println("Set K-Line High");
    delay(3000);             // wait for K-line to be clear 3
    digitalWrite (TX, LOW);  // makes K-line low  3
    console.println("Set K-Line Low");
    delay(25);
    digitalWrite (TX, HIGH); // makes K-line high  3
    console.println("Set K-Line High");
    delay(25);               //last delay before first message
    sds.begin(sdsbaud);  // baud rate of the OBD
    console.println("starting serial comunication");
    mode++;
  }
}

void sendrequest() {
  console.println("send request");
  for (int i = 0; ((i < messagelength) & (mode == 1)); i++) {
    sds.write(message[i]);
    console.print("sending data: ");
    console.println(message[i], HEX);
  }
  console.println("request sent");
}

void recievedata() {
  int i = 0;
  int req = 0;
  int data = 0;
  int dataok = 0;
  console.println("waiting for data");
  while (!dataok) {
    int time = millis();
    if ((timeold + timeout) < time) {
      timeold = time;
      console.println("TIMEOUT");
      mode = 0;
      sds.end();
      return;     
    }
    if (sds.available()) {
      byte inByte = sds.read();
      console.print("recieving data: ");
      console.println(inByte,HEX);
      if (inByte == message[i]) {
        i++;
        console.println("OK");
        if (messagelength == i) {
          console.println("request ok");
          req++;
          i = 0;
        }
      }
      if ((req) & (inByte == message_response[i])) {
        i++;
        console.println("OK");
      }
      if (responselength == i) {
        data++;
        i = 0;
        dataok++;
        console.println("Communication OK");
      }
    }
  }
}


but how can i clear the array "message" and write "80 12 F1 02 21 08 AE" in it after "dataok"?
How can i print the numbers of databytes of an array?
I want to diff the request from the response... but i dont know how it can be the best way...
Of course there are needed some formula to calculate checksum, sended and recieved string ecc...
Title: Re: Bike interface OBD
Post by: cyclegadget on May 17, 2014, 05:05 am

  I read your code and it is a little difficult because you need to put more comments so that I can understand the purpose of each line of your code. Remember, that this project may take you awhile to reach perfection. You may need comments and notes in the code to remind yourself about the functions in the code.
Here are the steps that need to happen. In my case, I used a variable called mode to step through my code.

1. fastinit(); Using pinmode, and HIGH and LOW
2. send message =  0x81,0x12,0xF1,0x81,0x05
3. wait for response 80 F1 12 03 C1 EA 8F C0
4.  send data request  0x80,0x12,0xF1,0x02,0x21,0x08,0xAE
5.  read incoming data "I believe you will receive 56 bytes back
6.  store results
7. repeat steps 4 through 6 over and over as long as you are getting response from the ECU.

I am not sure how to properly stop communication but, I do know that there is a message that can be sent to do it.
Title: Re: Bike interface OBD
Post by: o5i_ on May 17, 2014, 05:16 pm
How can i calculate the checksum?
for example:
80 12 F1 02 21 08
has 08 as checksum, but how to calculate it from the other values?
Title: Re: Bike interface OBD
Post by: robtillaart on May 17, 2014, 05:53 pm
for checksum there are many formulas/techniques. It is not a trivial or / xor / addition.

What you can do is assume the checksum is right and ignore it (for now). First prio is to get the data.
Title: Re: Bike interface OBD
Post by: cyclegadget on May 17, 2014, 07:59 pm

I did not make any effort on using the checksum. In my case, I expected 56 bytes returned from the ECU. If I did not get 56 bytes in a reasonable time, I assumed that I lost communication. The ECU will only reply after a request. Therefore, I send a request, wait on 56 bytes, and then make another request.
Title: Re: Bike interface OBD
Post by: o5i_ on May 17, 2014, 09:58 pm
Hi
i did some work... It reads data and print value on console.. But i have problems to get the timout timer working because millis is switching to negative values.... Speed is up to 140ms, thats better than expected :D
Next i need to test writing on sd... I hope it doesnt slows to much...
Somone have maybee the definitions for the sensor values?
Code: [Select]

#define TX 18
#define console Serial
#define cbaud 57600
#define sds Serial1
#define sdsbaud 10400

////////////////////////////////////////////////////// some static options //////////////////////////////////////////////////////

int const debug = 0;
int const timeout = 2000;
int const cyclespeed = 50;
byte const source = 0xF1;
byte const target = 0x12;
byte const header = 0x80;

////////////////////////////////////////////////////// possible protocol values //////////////////////////////////////////////////////

byte const startinit[5] = {
  0x81,
  target,
  source,
  0x81,
  0x05,
};

byte const keepalive[1] = {
  0x01,
};

byte monitorsensordata[7] = {
  header,
  target,
  source,
  0x02,
  0x21,
  0x08,
  0xAE, 
};

////////////////////////////////////////////////////// variables //////////////////////////////////////////////////////

int datalength = 0;
int mode = 0;
int timeold;
int time;


void setup() {
  console.begin(cbaud);
  pinMode(TX, OUTPUT);
}

void loop() {
  fastinit();
  senddata();
  recievedata();
}

// KWP2000 Fast Init
void fastinit(){
  if (!mode) {
    console.println("Starting comunication (fastinit)");
    digitalWrite (TX, HIGH);                                       
    if (debug) console.println("Set K-Line High");
    delay(6000);                                                             
    digitalWrite (TX, LOW);                                                   
    if (debug) console.println("Set K-Line Low");
    delay(25);
    digitalWrite (TX, HIGH);                                                     
    if (debug) console.println("Set K-Line High");
    delay(25);                                                               
    sds.begin(sdsbaud);                                                     
    if (debug) console.println("starting serial comunication");
    mode++;
  }
}

// Send request to the ecu (message)
void senddata() {
  if (mode) {
    if (mode == 1) {
      for (int x = 0; x <= 4; x++) {                            // messagelength=number of parameters stored in array
        sds.write(startinit[x]);
        datalength = 4;
        if (debug) {
          console.print("sending data: ");
          console.println(startinit[x], HEX);
        }
      }
    }
    if (mode == 2) {
      for (int x = 0; x <= 6; x++) {                            // messagelength=number of parameters stored in array
        sds.write(monitorsensordata[x]);
        datalength = 6;
        if (debug) {
          console.print("sending data: ");
          console.println(monitorsensordata[x], HEX);
        }
      }
    }
  }
}

/*

if (mode == 1) {
for (int x = 0; x <= 4; x++) {                            // messagelength=number of parameters stored in array
sds.write(startinit[x]);
if (debug) {
console.print("sending data: ");
console.println(startinit[x], HEX);
}
datalength = 4;
}
}
if (mode == 2) {
for (int x = 0; x <= 6; x++) {                            // messagelength=number of parameters stored in array
sds.write(monitorsensordata[x]);
if (debug) {
console.print("sending data: ");
console.println(monitorsensordata[x], HEX);
}
datalength = 6;
}
}
}
*/
void recievedata() {
  int data = 0;
  int i = 0;
  int incomingdata[] = {
  };
  /*  time = millis();
   console.print("Monitoring speed: ");
   console.print(time-timeold);
   console.println("ms"); */
  if (debug) {
    console.println("waiting for data");
  }
  timeold = millis();
  while (!data) {                          // loop, it needs to be closed later if checksum and everything else is ok
    /*    if (timeout) {
     if ((timeold + timeout) <= time) {        // if time is higher than the time stored last timeout + the needet time it starts from begining
     console.println("Timeout");
     mode = 0;
     sds.end();
     return;     
     }
     } */
    if (sds.available()) {                   // reading data
      byte inByte = sds.read();
      incomingdata[i] = inByte;
      if (debug) {
        console.println(incomingdata[i],HEX);
      }
      byte numparam;
      byte checksum;
      /*      // Check if data was recieved sucessfull
       if (i == messagelength) {
       for (int  x = 0; (incomingdata[x] == message[x]); x++) {
       if (messagelength == x) {
       console.println("Data sent to ECU");
       }
       }
       }
       */
      if (i == datalength + 4) {
        numparam = incomingdata[i];
        if (debug) {
          console.print("Number of Parameters: ");
          console.println(numparam,HEX);
        }
      }
      if (mode == 2) {
        if (i == 20) {
          console.print("Throtle Position: ");
          console.println(incomingdata[i]*125/255);
        }
        if (i == 21) {
          console.print("Intake Air Pressure: ");
          console.println((incomingdata[i]-153)*133/4/255);
        }
        if (i == 22) {
          console.print("Engine Coolant Temp: ");
          console.println(incomingdata[i]*160/255 - 30);
        }
        if (i == 23) {
          console.print("Intake Air Temp: ");
          console.println(incomingdata[i]*160/255 - 30);
        }
        if (i == 28) {
          console.print("Intake Air Pressure2: ");
          console.println((incomingdata[i]-153)*133/4/255);
        }
        if (i == 47) {
          console.print("Second Throtle Valve: ");
          console.println(incomingdata[i]*100/255);
        }
      }
      if (i == datalength+5+numparam) {
        /* for (int x = datalength+1;x<i;x++) {
         checksum += incomingdata[x];
         console.print(checksum,HEX);
         }*/
        if (debug) {
          console.print("Checksum: ");
          console.println(incomingdata[i],HEX);
        }
        mode = 2;
        data++;
        delay (cyclespeed);
        /* if (checksum == incomingdata[i]) {
         data++;
         mode = 2;
         delay (cyclespeed);
         }  */
      }
      i++;
    }
  }
}
Title: Re: Bike interface OBD
Post by: cyclegadget on May 19, 2014, 05:34 am

I will try to get you some received data information tomorrow when I have more time.

Glad you are making progress!
Title: Re: Bike interface OBD
Post by: o5i_ on May 27, 2014, 09:11 pm
Hi, im working again on the program, i increased speed to 145 ms....
but i have trouble whit some array...
I want to do..
String array1[] = {
"RPM",
"SPEED",
"TEMP",
....
}
int array2[] = {
recievedata[10]*calculationneeded,
recievedata[11]*calculationneeded,
recievedata[15]*calculationneeded,
...
}
for (int x = 0;x < sizeof(array1);x++) {
Serial.print(array1
Title: Re: Bike interface OBD
Post by: o5i_ on May 27, 2014, 09:14 pm
Code: [Select]
   //////////////////////////////////////////////////////////// constant Values  ////////////////////////////////////////////////////////////
byte const source = 0xF1;
byte const target = 0x12;
byte const header = 0x80;
  //////////////////////////////////////////////////////////// mode 1  (init) ////////////////////////////////////////////////////////////
byte const startinit[5] = {
  0x81,
  target,
  source,
  0x81,
  0x05,
};
  //////////////////////////////////////////////////////////// mode 2  (get Values) ////////////////////////////////////////////////////////////
byte const monitorsensordata[7] = {
  header,
  target,
  source,
  0x02,
  0x21,
  0x08,
  0xAE, 
};
  //////////////////////////////////////////////////////////// not used for now  ////////////////////////////////////////////////////////////
byte const keepalive[1] = {
  0x01,
};




Code: [Select]
  //////////////////////////////////////////////////////////// create string /////////////////////////////////////////////
  data = 0;
  sendbits = 0;
  recievebits = 0;
  if (mode) {
    if (mode == 1) {
      for (int x = 0; x < sizeof(startinit); x++) {
        tx_data[x] = startinit[x];
        sendbits++;
      }   
    }
    if (mode == 2) { 
      for (int x = 0; x < sizeof(monitorsensordata); x++) {
        tx_data[x] = monitorsensordata[x];
        sendbits++;
      }
    }
  //////////////////////////////////////////////////////////// check read write delay //////////////////////////////////////////
    time = millis();
    if (time < read_write_delay + read_write_time) {
      if (debug) console.print("Im 2 fast, waiting....");
    }
    while (time < read_write_delay + read_write_time) {
      time = millis();
      if (debug) console.println(".");
    }
  //////////////////////////////////////////////////////////// send string /////////////////////////////////////////////
    for (int x = 0;x < sendbits;x++) {
      sds.write(tx_data[x]);
      delay (send_delay);
      if (debug) {
        console.print("Data tx: ");
        console.println(tx_data[x], HEX);
      }
    }


Code: [Select]
//////////////////////////////////////////////////////////// decoding protocol values  ////////////////////////////////////////////////////////////

  //////////////////////////////////////////////////////////// mode 2  (read Values)  ////////////////////////////////////////////////////////////
int const engine_value[9] = {
  ((rx_data[15] / 50.5) * 9.2) - 14.7,
  (rx_data[17]*256 + rx_data[18]) / 2.56,
  125*(rx_data[19]-55)/(256-55),
  rx_data[20]*4*0.136,
  1.1 * (rx_data[21] - 15),
  1.1 * (rx_data[22] - 15),
  rx_data[23] - rx_data[20]*4*0.136,
  rx_data[24]/12.7,
  rx_data[26],
};
String const engine_value_desc[] = {
  "boost ",
  "rpm ",
  "tps ",
  "ip ",
  "ect ",
  "iat ",
  "iap ",
  "bat ",
  "gear ",
};


Code: [Select]
  ////////////////////////////////////////////////// print values //////////////////////////////////////////////
  if (mode == 2) {
   for (int x = 0;x < sizeof(engine_value);x++) {
   console.print(engine_value_desc[x]);
   console.print(engine_value[x]);
   console.println();
   }
   }
  /////////////////////////////////////////////////// write on sd //////////////////////////////////////////////
Title: Re: Bike interface OBD
Post by: cyclegadget on May 29, 2014, 05:12 am

I am not sure how to fix your code without making lengthy changes but, I can give you an idea.

In my code I had two sets of variables. The first set, was constant and they defined what byte contained the information I wanted such as: RPM, Engine Temperature, Throttle Position, etc.

The second set of variables, contained the results of the bytes. For instance, I used lower case letters to tell the difference between the two sets. Below would be an example.

rpm = byte result RPM
temperature = byte result  Engine Temperature
throttle = byte result Throttle Position

I want to help you with your array problems but, they are not my strength. You may have to practice using arrays in a separate code for testing, and ask for help in the programming problems section.


Title: Re: Bike interface OBD
Post by: o5i_ on Jun 07, 2014, 11:05 pm
Hi, i did some soldering :D
But i have problem to read the serial data transmitted from wideband...
Code: [Select]

void setup() {
  Serial.begin(57600);   
  Serial1.begin(9600);
}
void loop() {
  if (Serial1.available()) {
    Serial.println(Serial1.read());
  }
}

Gives:
Code: [Select]

123
229
235
0
103
217
123
229
235
0
103
217
123
229
235
0
103
217
123
229
235
0
103
217
123
229
235
0
103
217
123
229
235
0

But if i try to connect the wideband directly to pc:
Code: [Select]

14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8

whats wrong?
Title: Re: Bike interface OBD
Post by: robtillaart on Jun 08, 2014, 10:59 am
you must interpret the 5 bytes that come in,
the 5 bytes are constant, the 14.8 is too => so the 5 bytes represent the value.
Do you have some manual/datasheet with a formula?

floats in the arduino are 4 bytes so it is definitely not a 1-1 conversion....

Title: Re: Bike interface OBD
Post by: o5i_ on Jun 11, 2014, 09:51 pm
I think i need to explain the problem.
If i use this code:
Code: [Select]

void setup() {
 Serial.begin(9600);    
 Serial1.begin(9600);
}
void loop() {
 if (Serial1.available()) {
   Serial.println(Serial1.read());
 }
}

i get:
Code: [Select]

103
217
123
229
103
217
123
229
103
217
123
229
103
217
123
235
103
217
123
0
103
217
123
0
103
217
123
235
103
217


But if i connect the wideband directly to the pc and printing values using Putty i get this:
Code: [Select]

14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8
14.8


If i do:
Code: [Select]
void setup() {
  Serial.begin(9600);   
  Serial1.begin(9600);
}
void loop() {
  if (Serial1.available()) {
    Serial.write(Serial1.read());
  }
}



i recieve this:
Code: [Select]
{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{åëgÙ{


Why putty shows me the right value but arduino does not??? Its just a serial connection... Is there a option for Serial read that can do that?
Title: Re: Bike interface OBD
Post by: robtillaart on Jun 11, 2014, 11:05 pm
void setup()
{
 Serial.begin(9600);    
 Serial1.begin(9600);
}
void loop()
{
 if (Serial1.available())
 {
   Serial.print(Serial1.read(), DEC); //  print as decimal might help
 }
}
Title: Re: Bike interface OBD
Post by: o5i_ on Jun 12, 2014, 07:10 pm
Hi, i tried, but its just the same...
I think something in reading function is wrong because if i do serial read  to serial write it should be the same as it shows if i connect it directly but it isnt.....
Title: Re: Bike interface OBD
Post by: robtillaart on Jun 12, 2014, 07:23 pm
the reading function returns an int  (2 bytes) and the write() wants a byte as param
That is why I proposed to use print () iso write() as print() can print int's
Title: Re: Bike interface OBD
Post by: o5i_ on Jun 12, 2014, 08:28 pm
dont know whats wrong... is it some ascii thing?
Title: Re: Bike interface OBD
Post by: o5i_ on Jun 28, 2014, 07:38 pm
Hi, im back from Holidays...
I added the cardslot to the board and tried if the sketch work but it didnt work, dont know why... If i try the sd example it works verry well and it is just the same... If i put everything in setup section it works but if i do the writing section to the loop it doesnt work...
I tested the circuit whit the z-diode but it is not the best choice, i think an opto-coupler work better...
http://fish.x64.me/doc/sdslogger01.ino (http://fish.x64.me/doc/sdslogger01.ino)
Title: Re: Bike interface OBD
Post by: o5i_ on Dec 08, 2014, 02:03 pm
Hi, i redo the sketch, now its working, it writes to sd...
But i have a problem to write the byte i read as BIN to String on the SD... It just writes in DEC...
Sometimes if it writes to sd it slows down... Why? I need to buy faster sd or is it because a buffer overflows...



Code: [Select]
#define TX 14
#define console Serial
#define cbaud 115200
#define sds Serial3
#define sdsbaud 50000
#define LED 9
#include <SPI.h>
#include <SD.h>

int const debug = 1;
int const send_delay = 1;
int const fastinitwait = 3000;
int const fastinitdelay = 24;
int const recive_send_delay = 25;
int const timeout = 50;
int loging = 0;
const int chipSelect = 53;

String datarec;
byte const source = 0xF1;
byte const target = 0x12;
long const baud[2] = {
  50000, 10400};
byte const dataSequence[2][7] = {
  {0x81, target, source, 0x81, 0x05},
  {0x80, target, source, 0x02, 0x21, 0x08, 0xAE},
};
int const dataSize[2] = {
  5,7};

int datalenght;
int mode;
int startup;
int baudrate;
unsigned long time;
unsigned long lasttime = 0;
unsigned long cycletime = 0;
unsigned long time1000;
word milliseconds;
byte seconds;
byte minutes;
byte hours;
byte days;
byte inByte[99] = {
};

void setup() {
  pinMode(LED, OUTPUT);
  console.begin(cbaud);
  if (debug) console.print("Initializing SD card...");
  pinMode(chipSelect, OUTPUT);   
  pinMode(10, OUTPUT);
  if (!SD.begin(chipSelect)) {
    if (debug) console.println("Card failed, or not present");
    return;
  }
  if (debug) console.println("card initialized.");
  loging = 1;
}

void loop() {
  fastinit();
  if (mode) {
    timestamp();
  }
  talkserial();
  createString();
  writetosd();
}

void fastinit(){
  if (!startup) {
    mode = 0;
    sds.end();                                                     
    pinMode(TX, OUTPUT);
    if (debug) console.println("Starting comunication (fastinit)");
    digitalWrite (TX, HIGH);                                       
    if (debug) console.println("Set K-Line High");
    delay(fastinitwait);                                                             
    digitalWrite (TX, LOW);                                                   
    if (debug) console.println("Set K-Line Low");
    delay(fastinitdelay);
    digitalWrite (TX, HIGH);                                                     
    if (debug) console.println("Set K-Line High");
    delay(fastinitdelay);   
    sds.begin(baud[baudrate]);                                                     
    if (debug) console.print("Starting Serial Comunication @ ");
    if (debug) console.println(baud[baudrate]);
    startup++;
  }
}

void talkserial() {
  datalenght = 0;
  int data = 0;

  time = millis();
  while (time < cycletime+recive_send_delay) {
    time = millis();
  };
  for (int x = 0;x < dataSize[mode];x++) {
    sds.write(dataSequence[mode][x]);
    delay (send_delay);
  }
  lasttime = millis();
  while (!data) {
    time = millis();
    if (time-lasttime > timeout) {
      startup = 0;
      baudrate++;
      if (baudrate >= 2) {
        baudrate = 0;
      }
      break;
    }
    if (sds.available()) {
      inByte[datalenght] = sds.read();
      //      if (inByte[datalenght] < 0x10) {
      //        if (debug)  console.print("0");
      //      }
      //      if (debug) console.print(inByte[datalenght],HEX);
      if (datalenght == dataSize[mode]+0x04+inByte[0x03+dataSize[mode]]) {
        cycletime = millis();
        if (!mode) mode++;
        break;
      }
      datalenght++;
    }
    digitalWrite(LED, HIGH);
  }
  digitalWrite(LED, LOW);
}


void timestamp() {
  time = millis();
  milliseconds = time-time1000;
  if (milliseconds >= 999) {
    time1000 = time;
    seconds++;
  }
  if (seconds >= 0x3F) {
    seconds = 0;
    minutes++;
  }
  if (minutes >= 0x3F) {
    minutes = 0;
    hours++;
  }
  if (hours >= 0x3F) {
    hours = 0;
    days++;
  }
  //  if (debug) {
  //    if (days < 0x10) {
  //      console.print("0");
  //    }
  //    console.print(days,HEX);
  //    if (hours < 0x10) {
  //      console.print("0");
  //    }
  //    console.print(hours,HEX);
  //    if (minutes < 0x10) {
  //      console.print("0");
  //    }
  //    console.print(minutes,HEX);
  //
  //    if (seconds < 0x10) {
  //      console.print("0");
  //    }
  //    console.print(seconds,HEX);
  //    if (milliseconds < 10) {
  //      console.print("0");
  //    }
  //    if (milliseconds < 100) {
  //      console.print("0");
  //    }
  //    if (milliseconds < 1000) {
  //      console.print("0");
  //    }
  //    console.print(milliseconds);
  //  }
}

void createString() {
  datarec = "";
  datarec += days,HEX;
  datarec += hours,HEX;
  datarec += minutes,HEX;
  datarec += seconds,HEX;
  datarec += milliseconds,HEX;
  for (int i = 0; i <= datalenght; i++) {
    datarec += inByte[i];
  }
  if (debug) console.println(datarec);
}


void writetosd() {
  if (loging) {
    File dataFile = SD.open("LOGFILE", FILE_WRITE);
    if (dataFile) {
      if (debug) console.println("writing to LOGFILE");
      dataFile.print(datarec);
      dataFile.close();
    }
    else {
      if (debug) console.println("error opening LOGFILE");
      loging = 0;
    }
  }
}
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 09, 2014, 12:33 pm
 
 For saving to the SD card, I recommend using SDFFat. https://github.com/greiman/SdFat

The SD library you are using is the old one and I have heard it has problems.

I will have to have more time to look for other issues in your program.


Good work so far,
Mark
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 09, 2014, 12:36 pm
Post deleted. I miss read part of the code. Too early in the morning I guess. )
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 09, 2014, 03:34 pm
 If you are having the most trouble during "debug" mode, it is probably because you are printing to the serial monitor a lot. If possible, I recommend using blinking leds for status, like one red blink per SD card write, one blue blink for a complete Obd2 message, and green for ready to start for example. Make sure to blink without delay of course. Then, review your SD card after your tests.



Your code has a lot of good things, keep it up!

Mark
Title: Re: Bike interface OBD
Post by: o5i_ on Dec 11, 2014, 10:07 pm
Hi.. thanx for the infos, i try the sd library first i can.. The code is verry simple, i think i can use functionpointers and some for to make it more complicated :D I need a lot of learning about that...
I switched back to the k5 ecu and 11400 baud now, on that i can adjust logging speed to about 135ms.. on the k7 ecu and 50000 baud are 55ms...
Title: Re: Bike interface OBD
Post by: o5i_ on Dec 13, 2014, 12:08 am
Hi, i updated the timestamp section which was wrong, now it works..
Code: [Select]
#define WB 0
#define TX 14
#define console Serial
#define c_baud 115200
#define sds Serial3
#define sds_baud 10400
#define LED 9
#include <SD.h>

// Konstant Values
boolean const debug = 1;
boolean const wideband = true;
int const send_delay = 1;
int const wait_before_ = 6000;
int const fast_init_delay = 25;
int const recive_send_delay = 43;
int const timeout = 150;
int const chipSelect = 53;
byte const dataSequence[2][7] = {
  {
    0x81, 0x12, 0xF1, 0x81, 0x05    }
  ,
  {
    0x80, 0x12, 0xF1, 0x02, 0x21, 0x08, 0xAE    }
  ,
};
int const dataSize[2] = {
  5,7};

// Dynamic
boolean loging = false;
boolean startup = false;
int mode = 0;
int datalenght = 0;
String datarec_csv = "";
String datarec_bin = "";
unsigned long lasttime = 0;
unsigned long cycletime = 0;
word milliseconds = 0;
byte seconds = 0;
byte minutes = 0;
byte hours = 0;
byte days = 0;
int afr = 0;
byte inByte[99] = {
};

void setup() {
  pinMode(LED, OUTPUT);
  console.begin(c_baud);
  if (debug >= 1) console.print("Initializing SD card...");
  pinMode(chipSelect, OUTPUT);   
  pinMode(10, OUTPUT);
  if (!SD.begin(chipSelect)) {
    if (debug >= 1) console.println("Card failed, or not present");
    return;
  }
  if (debug >= 1) console.println("card initialized.");
  loging = true;
}

void loop() {
  fastinit();
  talkserial();
  if (mode) {
    read_wideband();
    timestamp();
    createString();
    writetosd();
    while (console.available()) {
      console.read();
      startup = false;
      mode = false;
    }
  }
}

void fastinit(){
  if (!startup) {
    mode = 0;
    milliseconds = 0;
    seconds = 0;
    minutes = 0;
    hours = 0;
    days = 0;
    afr = 0;
    while(sds.available()) {
      sds.read();
    }
    sds.end();
    pinMode(TX, OUTPUT);
    if (debug >= 1) console.println("Starting comunication (fastinit)");
    digitalWrite (TX, HIGH);                                       
    if (debug >= 1) console.println("Set K-Line High");
    delay(wait_before_);                                                             
    digitalWrite (TX, LOW);                                                   
    if (debug >= 1) console.println("Set K-Line Low");
    delay(fast_init_delay);
    digitalWrite (TX, HIGH);                                                     
    if (debug >= 1) console.println("Set K-Line High");
    delay(fast_init_delay);   
    sds.begin(sds_baud);                                                     
    if (debug >= 1) console.print("Starting Serial Comunication @ ");
    if (debug >= 1) console.println(sds_baud);
    startup++;
  }
}

void talkserial() {
  datalenght = 0;
  unsigned long time = millis();
  unsigned long timediff = millis();

  while (time < cycletime+recive_send_delay) {
    if (debug >= 2) console.println("waiting");
    time = millis();
  }
  if (debug >= 2) console.println("sending some bytes...");
  for (int x = 0;x < dataSize[mode];x++) {
    sds.write(dataSequence[mode][x]);
    if (debug >= 2) {
      if (dataSequence[mode][x] < 0x10) {
        console.print("0");
      }
      console.print(dataSequence[mode][x],HEX);
    }
    delay (send_delay);
  }
  if (debug >= 2) console.println("recieving some bytes...");
  while (startup) {
    time = millis();
    if (time-timediff > timeout) {
      startup = 0;
      mode = 0;
      break;
    }
    if (sds.available()) {
      inByte[datalenght] = sds.read();
      if (debug >= 2) {
        if (inByte[datalenght] < 0x10) {
          console.print("0");
        }
        console.print(inByte[datalenght],HEX);
        console.print(",");
      }
      if (datalenght == dataSize[mode]+0x04+inByte[0x03+dataSize[mode]]) {
        cycletime = millis();
        if (!mode) mode++;
        break;
      }
      datalenght++;
    }
    digitalWrite(LED, HIGH);
  }
  digitalWrite(LED, LOW);
}

void read_wideband() {
  if (debug >= 2) console.println("reading analog Inputs");
  afr = analogRead(WB);
  if (debug >= 2) console.println(afr,HEX);
}

void timestamp() {
  unsigned long time = millis();
  if (!lasttime) lasttime = millis();
  unsigned long timediff = time - lasttime;
  lasttime = millis();
  milliseconds = milliseconds + timediff;
  if (milliseconds > 999) {
    int multi = milliseconds/1000;
    milliseconds =  milliseconds - multi*1000;
    seconds++;
  }
  if (seconds >= 0x3C) {
    seconds = 0;
    minutes++;
  }
  if (minutes >= 0x3C) {
    minutes = 0;
    hours++;
  }
  if (hours >= 0x3C) {
    hours = 0;
    days++;
  }
  if (debug >= 2) {
    console.println("create Time String");
    if (days < 0x10) {
      console.print("0");
    }
    console.print(days,HEX);
    console.print(":");
    if (hours < 0x10) {
      console.print("0");
    }
    console.print(hours,HEX);
    console.print(":");
    if (minutes < 0x10) {
      console.print("0");
    }
    console.print(minutes,HEX);
    console.print(":");
    if (seconds < 0x10) {
      console.print("0");
    }
    console.print(seconds,HEX);
    console.print(":");
    if (milliseconds < 10) {
      console.print("0");
    }
    if (milliseconds < 100) {
      console.print("0");
    }
    if (milliseconds < 1000) {
      console.print("0");
    }
    console.println(milliseconds);
  }
}



void createString() {
  if (debug >= 2) console.println("Create Datastring");
  datarec_csv = "";
  datarec_bin = "";

  if (days < 10) {
    datarec_csv += 0;
  }
  datarec_csv += days;
  datarec_csv += ":";
  if (hours < 10) {
    datarec_csv += 0;
  }
  datarec_csv += hours;
  datarec_csv += ":";
  if (minutes < 10) {
    datarec_csv += 0;
  }
  datarec_csv += minutes;
  datarec_csv += ":";
  if (seconds < 10) {
    datarec_csv += 0;
  }
  datarec_csv += seconds;
  datarec_csv += ":";
  if (milliseconds < 10) {
    datarec_csv += 0;
  }
  if (milliseconds < 100) {
    datarec_csv += 0;
  }
  datarec_csv += milliseconds;
  datarec_csv += ",";

  if (afr < 10) {
    datarec_csv += 0;
  }
  if (afr < 100) {
    datarec_csv += 0;
  }
  if (afr < 1000) {
    datarec_csv += 0;
  }
  datarec_csv += afr;  //AIR FUEL RATIO - From analog Pin 0
  datarec_csv += ",";
  /*
 
   /// remember HEX to DEC conversion forex. 0x14 = 20 starting from 0!!!!
   
   datarec_csv += inByte[dataSize[mode]+0x20];  //TPS
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x21];  //IAP
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x22];  //ECT
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x23];  //IAT
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x26];  //GEAR
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x47];  //STP
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x53];  //CLUTCH
   datarec_csv += ",";
   
   datarec_csv += inByte[dataSize[mode]+0x54];  //NEUTRAL
   datarec_csv += ",";
   */
  datarec_bin += days;
  datarec_bin += hours;
  datarec_bin += minutes;
  datarec_bin += seconds;
  datarec_bin += milliseconds;

  for (int i = 0; i <= datalenght; i++) {
    datarec_bin += inByte[i];
  }
  for (int i = 0; i <= datalenght; i++) {
    datarec_csv += inByte[i];
    datarec_csv += ",";
  }
  if (debug == 1) {
    console.println(datarec_csv);
 //   console.println(datarec_bin);
  }
}

void writetosd() {
  if (loging) {
    if (debug >= 2) console.println("Start opening SD");
    File dataFile = SD.open("LOG.csv", FILE_WRITE);
    if (dataFile) {
      if (debug >= 1) console.println("Writing to LOG.csv");
      dataFile.println(datarec_csv);
      dataFile.close();
    }
    else {
      if (debug >= 1) console.println("error opening LOG.csv");
      loging = false;
    }
  }
}

But i have a question..
How can i create a sting whit hex values and print than on file as binary or maybee print that directly to bin whitout converting it to string? for ex..i have 0x00 0x00 0x01 0x01 0x01 0x02 0x02 0x80 0x12 0xF1... i want to print as bin to logfile and create a string like 0:0:1:1:122,80,12,F1...
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 13, 2014, 06:36 pm
Your question about saving your results was a little confusing to me but, I will tell you what I am doing.
I receive the data and save it as a byte in an array using this snippet of code.
Code: [Select]
byte inByte = Serial1.read();
      buf[counter] = inByte;


 Then, I save to my SD card the variable that I want. They will always be in the same positions in the string that comes from the ECU. I shared those positions with you months ago when you started this project. When I look at my SD card I find decimal numbers that are easily readable.

I was looking over your code that you shared a few days ago, and I have a great time stamp function that I use for the SD card. At the moment, I am using a buffer for storing the values. Using SDFAT, I use....  sprintf(buffer, "%02d:%02d:%02d.%03d", h, m, s, ms);  to buffer time string.

Code: [Select]
void displayResult()
{
  int h,s,m,ms;              //hour, second, minute, milliseconds
  unsigned long over;
  elapsed = finished-start;
  h = int(elapsed/3600000);  //calculate the hour
  over = elapsed%3600000;
  m = int(over/60000);       //calculate the minute
  over = over%60000;
  s = int(over/1000);       //calculate the second
  ms = over%1000;           //calculate the millisecond

  char buffer[14];
  sprintf(buffer, "%02d:%02d:%02d.%03d", h, m, s, ms);  //buffer time string
  //file.print(buffer);        //print the time
  // log data and flush to SD
  logfile << buffer << flush;
  //Serial.println(" the header" );
}



Here is how I make my header for the SD file the first time that I save to the card.

Code: [Select]
void SDHEADER(){
 
  // use buffer stream to format line

  obufstream bout(SDbuf, sizeof(SDbuf));
  //  format data for sending to sd card

  bout << ("Log Time") << ',' << ("RPM") << ',' << ("TPS") << ',' << ("IAP") << ',' << ("HO2") << ',' << ("HO2 Wideband") << ',' << ("IGN") << ',' << ("STP")
    << ',' << ("GEAR") << ',' << ("CLUTCH") << ',' << ("NT") << ',' << ("BOOST") << ',' << ("IP") << ',' << ("AP") << ',' << ("CLT") << ',' << ("IAT")
      << ',' << ("BATT") << ',' << ("PAIR") << ',' << ("FUEL1") << ',' << ("FUEL2") << ',' << ("FUEL3") << ',' << ("FUEL4") << ',' << ("HOX_ON") << ',' << ("MTS AFR")
        << ',' << ("New Data Rate %");
  bout << endl;

  // log data and flush to SD
  logfile << SDbuf << flush;
  }


 Here is how I save my variables to the SD card. Notice that I am writing a CSV file so, I have "," commas saved between each variable saved.
Code: [Select]
void SDDATASAVES(){
  // use buffer stream to format line
  obufstream bout(SDbuf, sizeof(SDbuf));

  displayResult(); // save the timestamp first
  //  format data for sending to sd card
  bout  << ',' << (Rpm) << ',' << (tps) << ',' << (Iap) << ',' << (Ho2) << ',' << (HO2_Wideband)<< ',' << (ign) << ',' << (Stp) << ',' << (Gear)
    << ',' << (szClutch) << ',' << (szNeutral) << ',' << (Boost) << ',' << (Ip) << ',' << (Ap) << ',' << (Clt) << ',' << (Iat) << ',' << (Battery) << ','
      << (Pair) << ',' << (Fuel1) << ',' << (Fuel2) << ',' << (Fuel3) << ',' << (Fuel4) << ',' << (Hox_On) << ',' << (Mts_Afr) << ','
      << (New_Data_Rate);
  bout << endl;

  // log data and flush to SD
  logfile << SDbuf << flush;
  }

 
 I also wanted to let you know that this bit of your code is a complicated way of saying delay();, because nothing can happen during this time except this while loop.
Code: [Select]
while (time < cycletime+recive_send_delay) {
    if (debug >= 2) console.println("waiting");
    time = millis();
  }
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 13, 2014, 06:40 pm

 These libraries and code pieces have to be in the begging of the code.

Code: [Select]
#include <stdio.h>;  // this is for the timestamp counter
#include <SdFat.h>
// file system
// file system object
SdFat sd;

// text file for logging
ofstream logfile;
// store error strings in flash to save RAM
#define error(s) sd.errorHalt_P(PSTR(s))

// buffer to format data - makes it eaiser to echo to Serial
char SDbuf[512];
Title: Re: Bike interface OBD
Post by: cyclegadget on Dec 14, 2014, 01:21 am
 I wrote a sketch to help you understand how to send Serial and read Serial without blocking. In the sketch I use a "static int" to help me send "HELLO WORLD" one character at a time slowly. The LED 13 blinks at a separate rate during the whole sketch. Then, the user response with < 30 characters followed by "." and the Arduino will repeat the response. The Arduino then begins the process again, by saying HELLO WORLD again.

Code: [Select]
char request[11] = {
  'H','E','L','L','O',' ','W','O','R','L','D'};
char buf[30];  // buffer for received characters
int index = 0; // counter for received characters in buf

unsigned long currentMillis = 0;         // to save current millis()
unsigned long previousMillis = 0;        // will store delay time for EACH char of HELLO
long interval = 700;             // interval at which to transmitt
unsigned long callpause = 45;    // interval at which to transmitt
byte mode = 1;  //variable to shift between operations

//////////////////////////LED VARIABLES///////////////////////
int ledState = LOW;                // ledState used to set the LED
unsigned long blinkrate = 350;     // interval of blinks in millis
unsigned long previousblink = 0;   //last blink time
int ledPin = 13;                   // Uno onboard LED

void setup()
{
  pinMode(ledPin,OUTPUT);        //LAST SET TO 13
  digitalWrite(ledPin,LOW);
  Serial.begin(115200);
  delay(2000);            //Allow the user to get the serial monitor open
  Serial.println("The Arduino is going to say HELLO WORLD one Character at a time with 700 Millis between Characters.");
  Serial.println("Respond with less that 30 characters followed with a . period.");
  Serial.println("The Arduino will repeat what you have typed before saying HELLO again");
  Serial.println("LED 13 will blink at a rate of 350 Millis without being affected by other operations.");
}

void loop()
{
  ///////////////////////////////////////mark the time in millis//////////////////////
  currentMillis = millis();
  /////////////////////////////////////call heartbeat to blink LED13///////////////////////////////////////
  if(currentMillis - previousblink > blinkrate)
  {
    heartbeat();
    previousblink = currentMillis;
  }

  /////////////////////////////////////////HELLO MODE//////////////////////////
  if (mode == 1 && (currentMillis - previousMillis) >= interval)  //delay between transmits 700 Millis
  {

    previousMillis = currentMillis;
    //send "HELLO WORLD" one character at a time with out loosing place
    static int i = 0;
    Serial.print(request[i]);
    i++;

    if (i == 11) // if we sent the 11 Character HELLO WORLD lets move on
    {
      mode = 2;
      i = 0; // reset our static int i to 0 for use when we want to say HELLO again.
      Serial.println();
      Serial.print(" Respond to me with < 30 Characters followed by a .");
      Serial.println();
    }
  }


  /////////////////////READ A RESPONSE ENDING WITH A PERIOD/////////////////////
   //check the variable mode to see if it is time to check for a response
  if (Serial.available()&& mode == 2) {
    char inByte = Serial.read();   // read from Serial and store the characters to inByte
    buf[index] = inByte;
    index++;

    if(inByte == '.')
    {
      for (int i = 0; i < (index - 1); i++){ // print the respone you made
        Serial.print(buf[i]);
      }
      Serial.println();
      mode = 1;           //return to printing HELLO
      index = 0;          //reset buf index
    }
  }
}


/////////////////HEARTBEAT///////////////
void heartbeat()
{
  if (ledState == LOW)
    ledState = HIGH;
  else
    ledState = LOW;
  digitalWrite(ledPin, ledState);
}
















This sketch is performs in a similar manner at which your sketch needs to work.
You want to:
1. Send a request
2. Listen for a response
3. Save the data
4. blink LEDs, check buttons and update screens.
All of this without blocking. It is awesome when you get it to work!

Try the sketch, I had fun writing it.
Title: Re: Bike interface OBD
Post by: o5i_ on May 12, 2015, 09:15 pm
Hi, litle update from me, now it works good, i changed to Seeduino and added a GPS Brakeout.
Code (https://drive.google.com/open?id=0B1GutcZzC5ZvRVREbERvT21QVjg&authuser=0)
Have fun!
Title: Re: Bike interface OBD
Post by: songotag on May 24, 2015, 02:23 pm
Hello o5i_

Can you tell me more information about your board/projetc/schematic ?

I whant to make a OBD tool for my suzuki v strom 650 k8.

My board is an arduino nano v3.0.

thanks for your help
Title: Re: Bike interface OBD
Post by: songotag on Jun 11, 2015, 06:12 pm
here is my test program with an OLED SPI screen and arduino nano v3 ( china version ;-)  ).

I used the sofwareserial.



edit : you can post your comments and download my program test Here (http://forum.arduino.cc/index.php?topic=329607.0)


Title: Re: Bike interface OBD
Post by: Robert13 on Jun 11, 2015, 08:03 pm
Thank you Songotag,

I will try it. I have found some information about other sensors. Maybe those will also work on a Gee/Wee.
I have orderd some extra parts; SD card, 20x4 display, RTC, buttons . And made a generic PCB and orderd that one by Itead. First time I have made used Eagle PCB and orderd a PCB.
I hope that I will reaceive all soon, so I can build it.
Title: Re: Bike interface OBD
Post by: o5i_ on Jun 29, 2015, 12:54 pm
Hi, you mean the scematic of the K - Line transciever? There are few chips that can do that.. Si9241AEY or Si9243AEY or L9637D .. there are a lot, but smd... But you can use transistor or opv too... Here (https://drive.google.com/file/d/0B1GutcZzC5ZvTzZsWFVzVWpVZnc/view?usp=sharing) is my transciever scematic...
About Softwareserial... I have tried that too on my GPS but it doesnt work, i used hardwareserial because of that, its much faster... but it has some restrictions...
I have made a video  (https://www.youtube.com/watch?v=1dpbyCEGibE)using the logger and dashware...
Title: Re: Bike interface OBD
Post by: songotag on Jun 30, 2015, 09:12 pm
Hi, you mean the scematic of the K - Line transciever? There are few chips that can do that.. Si9241AEY or Si9243AEY or L9637D .. there are a lot, but smd... But you can use transistor or opv too... Here (https://drive.google.com/file/d/0B1GutcZzC5ZvTzZsWFVzVWpVZnc/view?usp=sharing) is my transciever scematic...
About Softwareserial... I have tried that too on my GPS but it doesnt work, i used hardwareserial because of that, its much faster... but it has some restrictions...
I have made a video  (https://www.youtube.com/watch?v=1dpbyCEGibE)using the logger and dashware...

Can you tell us  how did you do the synchronization between the received data Kline and the serial buffer. Sometimes I have bad data readings of the return frame.

Can you give us the reference of the gps receiver  you used ?

Is the SDS_Logger_0.0.2 your last revision of firmware  ?
Title: Re: Bike interface OBD
Post by: o5i_ on Jul 13, 2015, 05:46 pm
Hi
i dont sync the time from gps whit the "time", time is just a counter that starts when the bike starts...
I have updated some things.. You can see in chanlog...
In the latest Version the filename is assembled from date/filenumber, because of that gps is needed.. But i can make a timeout for no response..
I used the Adafruit Ultimate GPS (http://www.adafruit.com/products/746) but you can use whatever zou want..
Bad k_line readings can be caused from bad serial connections(chip) or because of the arduino built in serial library, i noticed that softserial cause a verry high delay, because of that i used hardserial library which works fine..

>>>>>>>>>>>SDS_Logger_0.0.6<<<<<<<<<<<<<< (http://dha.wha.la/doc/SDS_Logger_0.0.6.ino)
Title: Re: Bike interface OBD
Post by: o5i_ on Jul 13, 2015, 06:26 pm
ive made a github repo for this if you want to work together on this send me some infos and i add you...
https://github.com/o5i/Datalogger.git (https://github.com/o5i/Datalogger.git)
Title: Re: Bike interface OBD
Post by: songotag on Jul 14, 2015, 12:03 pm
ive made a github repo for this if you want to work together on this send me some infos and i add you...
https://github.com/o5i/Datalogger.git (https://github.com/o5i/Datalogger.git)
Hello o5i_, thanks for your sharing.

The repo is a good idea, you can put your schematics and datasheets.

I'll work on my project after my long hollidays.

Best regards ;)
Title: Re: Bike interface OBD
Post by: Robert13 on Mar 12, 2016, 08:20 pm
I have made the interface with the 2 BC547 transistors and made a scetch based on this subject (Songotag scetch). But I don't receive information from the ECU. When I connect my Scope on the K-line (Pin 3 on the dealer port) I'll see the my program does do the fast init en send all the deze to the ECU.

Question: Does the engine must me running?
Pin 3 on the dealer connector is the K-line, right?

Does anybodt know why I don't receive data?

Title: Re: Bike interface OBD
Post by: songotag on Mar 12, 2016, 08:31 pm
I have made the interface with the 2 BC547 transistors and made a scetch based on this subject (Songotag scetch). But I don't receive information from the ECU. When I connect my Scope on the K-line (Pin 3 on the dealer port) I'll see the my program does do the fast init en send all the deze to the ECU.

Question: Does the engine must me running?
Pin 3 on the dealer connector is the K-line, right?

Does anybodt know why I don't receive data?


Hello, which arduino board you use ??? if you use a softserial, you must change a file on arduino IDE to force the softserial to 10400.

You don't have to turn on the engine. Just power up the ECU
Title: Re: Bike interface OBD
Post by: Robert13 on Mar 12, 2016, 08:49 pm
I started with softserial, but o5i_ said to use the hardware serial, so I changed my program and hardware.
I use pin 5 as K-line. Right?

Could you tell me with line in software seriale has to be changed. That way is much easier for uploading an new sketch.

I usa a Chineese Nano R3 with a CH304 with a 20x4 LCD with I2c, a DS3231 RTC, a Micro SD-card and some buttons with resistors on analog port A1

I have a suzuki dl-650 K8 (yellow)
Title: Re: Bike interface OBD
Post by: songotag on Mar 12, 2016, 08:54 pm
I started with softserial, but o5i_ said to use the hardware serial, so I changed my program and hardware.
I use pin 5 as K-line. Right?

Could you tell me with line in software seriale has to be changed. That way is much easier for uploading an new sketch.

I usa a Chineese Nano R3 with a CH304 with a 20x4 LCD with I2c, a DS3231 RTC, a Micro SD-card and some buttons with resistors on analog port A1

I have a suzuki dl-650 K8 (yellow)

Don't forget that with the arduino nano, the hardware serial is share with the usb. If you whant multiple hardware serial, you have to use a arduino mega for example. Now i'm using an arduino mega core from ebay.

To test your code with the nano, you can use softserial.
Title: Re: Bike interface OBD
Post by: Robert13 on Mar 12, 2016, 09:11 pm
I know. That's why I cannot reprogram my Nano by using USB. I have to program it via the ICSP port.
I have ordered some L9637Ds and a experiment shield. That will make life much easier. Maybe I can test it first with a Mega and later with a Uno of Nano. I have all Arduinos.

With my program, I can see that the K-line is low and high from the arduino.

I have only connect 3 wires? like http://i39.servimg.com/u/f39/15/19/79/59/sds_to10.jpg

I did now know the Mega Core. Sounds interresting.

I can use your program as test.

Keep you informed.
Title: Re: Bike interface OBD
Post by: Robert13 on Mar 12, 2016, 09:44 pm
BTW What is the change to the softwareserial library to support 10400 baud?
Title: Re: Bike interface OBD
Post by: songotag on Mar 13, 2016, 08:42 am
BTW What is the change to the softwareserial library to support 10400 baud?
Have a lokk at this : http://www.tocpcs.com/newsoftserial-adding-a-baud-rate/

If i find my modified file, i'll send it to you. Let me your email by MP il you whant.

The best way, is to use the arduino mega with his hardware serail ;).

You can use whatever you whant for the TX pin.

I've made a "sniffer" with a arduino nano to see the byte on the Kline... and show the byte in a console.
Title: Re: Bike interface OBD
Post by: songotag on Apr 19, 2016, 10:30 pm
Hello Robert13,

With the last arduino IDE, you don't have to modify the file for sofserial's baudrate, it's already implemented in the new IDE

I tried the interface with the 2 BC547b and work with the softserial, the best way is the hardware serial..
Title: Re: Bike interface OBD
Post by: 1ExcalibuR2 on Sep 13, 2016, 03:34 pm
Hi, there

I want to make my DIY OBD to connect with ISO K-Line on my DLC connector but using MC33290, anyone in here can give me some recomendation about IC that I use ?
or give an advice about IC that I can use for my OBD beat injection

Thank You :D
Title: Re: Bike interface OBD
Post by: o5i_ on Sep 13, 2016, 09:33 pm
Hi, i have used the lm393? opamp circuit and it works well.. I use my bike every day and since 2 years no bugs or something..  I tested the bc547 too and it works..  But i think every chip that supports kline is enough, but i have no experience about.
Title: Re: Bike interface OBD
Post by: TriB on Sep 14, 2016, 01:44 pm
Hi guys,

I´ve seen the Kawasaki (KDS) Protocol is similar to Suzuki (SDS).
As you can see in my thread here (http://forum.arduino.cc/index.php?topic=334778.0).
I´d guess Suzuki also uses a Denso ECU. Both are communicating over K-Line via KWP2000, fastInit, ISO 14230, ect. But the PID´s are different, as I can see. 0x08 gives you a bunch of sensor data? KDS just takes on request and responds with a single value.

In my solution, I´m using a L9637D to convert K-Line to Serial signal.
That works great, until it seems to overheat or voltage drops. It just stops after 15-30 minutes.
Scissor (from the thread mentioned above) also got drops, but the connection restarts. Mine stays dead, until I restart the bike.
How did you wire up your solution and how did you regulate the supply voltage?



If interested, we can share some experience. You can take a look into my documentation, emulator and code on GitHub (https://github.com/HerrRiebmann/KDS2Bluetooth) to complete our work :)

Best regards!
Title: Re: Bike interface OBD
Post by: songotag on Sep 15, 2016, 11:08 am
Hi guys,

In my solution, I´m using a L9637D to convert K-Line to Serial signal.
That works great, until it seems to overheat or voltage drops. It just stops after 15-30 minutes.
Scissor (from the thread mentioned above) also got drops, but the connection restarts. Mine stays dead, until I restart the bike.
How did you wire up your solution and how did you regulate the supply voltage?


If interested, we can share some experience. You can take a look into my documentation, emulator and code on GitHub (https://github.com/HerrRiebmann/KDS2Bluetooth) to complete our work :)

Best regards!
hello, I´m using a L9637D too and i've no problem of overheating, it's probably a bug in your code... try to use a soft reset button to see that.
Title: Re: Bike interface OBD
Post by: TriB on Sep 16, 2016, 11:39 am
hello, I´m using a L9637D too and i've no problem of overheating, it's probably a bug in your code... try tu use a soft reset button to see that.
Thanks for your reply!
It is not related to the code. I´ve built an ECU-emulator, which runs for hours. Also I´ve added a Watchdog, which will store any error onto the eeprom.

Overheating is just a guess.
So you are not regulating any voltage? Just L9637D and a PullDown resistor between K-Line & GND?

I think, I´ll have to build another device, to be sure it´s not related to the Arduino or my circuit.
Title: Re: Bike interface OBD
Post by: songotag on Sep 16, 2016, 03:10 pm
Thanks for your reply!
It is not related to the code. I´ve built an ECU-emulator, which runs for hours. Also I´ve added a Watchdog, which will store any error onto the eeprom.

Overheating is just a guess.
So you are not regulating any voltage? Just L9637D and a PullDown resistor between K-Line & GND?

I think, I´ll have to build another device, to be sure it´s not related to the Arduino or my circuit.
As ou can see in the file attached ( the wiring i used ), it's not a pulldown resistor but a pullup ;-)
you can use 12V or 14v for the " hight" voltage and +5V or 3.3V for arduino level.

(http://img15.hostingpics.net/thumbs/mini_899922L9637D.jpg) (http://www.hostingpics.net/viewer.php?id=899922L9637D.jpg)
Title: Re: Bike interface OBD
Post by: aster94 on Sep 20, 2016, 06:35 pm
Hi trib

I m interested, but i had just discovered about k line i thought that was more difficult reading from suzuki. I have a gsx-r 600 2011 L1, i would like to help you, if you are sure that we also use this kind of comunication i ll buy the  l9637 and when it arrive we could discuss about it :D
Title: Re: Bike interface OBD
Post by: TriB on Sep 21, 2016, 10:20 am
Hi aster94,

the reading should not be more or less difficult.
Just the correct wiring (songotag is right, it´s a PullUp resistor), the fastInit-Process and afterwards, you have to start the communication.
The difference between Kawa and Suzi are the PID´s (Parameter identifier).

You´ll receive a dataset of values on a single request (PID 0x08) and have to separate the values you are looking for.
I´m gonne get RPM on 0x09, Speed on 0x0C, and so on.

First of all, I´d like to resolve my communication drops by adding a voltage regulator. That´s my only issue. Everything else is working like a charm!
Then I´ll see if I can make a friends 2004 650 Bandit work. I´m not sure if it has SDS...
Title: Re: Bike interface OBD
Post by: aster94 on Sep 21, 2016, 12:15 pm
Great in the next days i ll buy it, when it ll arrive (1.5 months) i ll write in your main post, then we ll see how is similar the protocol between the two bikes
Title: Re: Bike interface OBD
Post by: TriB on Sep 21, 2016, 01:27 pm
then we ll see how is similar the protocol between the two bikes
There is no need to, we already know :)

Both are KWP2000 (https://en.wikipedia.org/wiki/Keyword_Protocol_2000) / ISO 14230 (http://read.pudn.com/downloads118/ebook/500929/14230-2.pdf). The pdf in the second link will contain all information needed.

And everything according to Suzuki is discussed here in this thread or alternatively in the ECU-Hacking Board (http://ecuhacking.activeboard.com/).
The working Kawasaki solution is discussed here (http://forum.arduino.cc/index.php?topic=334778.0), with all of it´s challenges.

From my point of view, both sides are quite done. There is just space for optimization :)

Just read the ISO protocol description and this thread, right from the beginning. That makes it more clear!
Title: Re: Bike interface OBD
Post by: aster94 on Sep 21, 2016, 04:48 pm
Wow i arrived too late i wouldn t have the fun to link bytes and data together

Okkk i didn t read nothing since i think that in 2 months i ll forget everything when the chip will arrive i m going to read the full topics and documentation thank you :D
Title: Re: Bike interface OBD
Post by: 1ExcalibuR2 on Sep 22, 2016, 12:53 pm
Hi, i have used the lm393? opamp circuit and it works well.. I use my bike every day and since 2 years no bugs or something..  I tested the bc547 too and it works..  But i think every chip that supports kline is enough, but i have no experience about.
hi o5i, I use MC33290 but the chip was overheating
I just try to give 12V for the VCC on MC33290 and the chip was overheating, and then I try to built in om my motorcycle and arduino. I just make a simple code for reading the serial port but again the chip was overheating. I don't know what happen

this is my code

Quote
#include <SoftwareSerial.h>

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

void setup()
{
  Serial.begin(57600);
  while (!Serial) {
  }
  mySerial.begin(10400);
}

void loop() // run over and over
{
  if (mySerial.available())
    Serial.write(mySerial.read());
  if (Serial.available())
    mySerial.write(Serial.read());
}
Title: Re: Bike interface OBD
Post by: TriB on Sep 22, 2016, 03:33 pm
Hi 1ExcalibuR2,

the MC33290 datasheet (http://www.nxp.com/files/analog/doc/data_sheet/MC33290.pdf) says:
Quote
VBB Battery power through external resistor and diode
VBB Load Dump Peak Voltage 45 V
So you should regulate the power, but it can handle up to 45V. I don´t think it will overheat that fast.

Your code will not work and never receive any data.
The Diagnostic System has to be awaken by a fastInit Sequence.
On the second page, cyclegadget describes how to do it (also explained in the ISO 14230 documentation).

Code: [Select]

 Serial.end();

  //ISO 14230-2 "Fast Init" sequence:
  digitalWrite(K_OUT, HIGH);
  delay(300);
  digitalWrite(K_OUT, LOW);
  delay(25);
  digitalWrite(K_OUT, HIGH);
  delay(25);
  // Should be 10417
  Serial.begin(10400);


Then the ECU will listen for about the next 2 Seconds.
Afterwards you´ll have to activate the communication by sending:
0x81,0x12,0xF1,0x81,0x05
Now you will receive the first answer:
0x81, 0xF1, 0x12, 0xC1, 0xEA, 0x8F, + Checksum
which means C1 is 81 with 40 added. That means the submitted Service ID was succesful.
EA and 8F are decimal 243 & 143, which describe the supported format (Header type: Source, Target, Length & Checksum)

You can find all the required information here in this thread and on o5i_´s GitHub (https://github.com/o5i/Datalogger).
Title: Re: Bike interface OBD
Post by: 1ExcalibuR2 on Oct 11, 2016, 11:19 am
Quote
So you should regulate the power, but it can handle up to 45V. I don´t think it will overheat that fast.

Your code will not work and never receive any data.
The Diagnostic System has to be awaken by a fastInit Sequence.
On the second page, cyclegadget describes how to do it (also explained in the ISO 14230 documentation).
Hi Trib, thanks for your answer
I have fixed my MC33290, my fault is using diode for 5v which is power for MC33290 is 12V. But when I replace my diode for 15v it's not overheating again

Quote
Then the ECU will listen for about the next 2 Seconds.
Afterwards you´ll have to activate the communication by sending:
0x81,0x12,0xF1,0x81,0x05
Now you will receive the first answer:
0x81, 0xF1, 0x12, 0xC1, 0xEA, 0x8F, + Checksum
which means C1 is 81 with 40 added. That means the submitted Service ID was succesful.
EA and 8F are decimal 243 & 143, which describe the supported format (Header type: Source, Target, Length & Checksum)

You can find all the required information here in this thread and on o5i_´s GitHub.
I have read again to page 3, and I got the code


Code: [Select]

#define TX 18
#define console Serial
#define cbaud 115200
#define sds Serial1
#define sdsbaud 10400

//variables
byte message[6] = {
  0x81,0x12,0xF1,0x81,0x05};

void setup() {
  console.begin(cbaud);
  pinMode(TX, OUTPUT);
}

void loop() {
  datastart();
}

/////////////////DATA START///////////////
void datastart(){
  digitalWrite (TX, HIGH);  // makes K-line high 3
  delay(2000);             // wait for K-line to be clear 3
  digitalWrite (TX, LOW);  // makes K-line low  3
  delay(25);
  digitalWrite (TX, HIGH); // makes K-line high  3
  delay(25);               //last delay before first message
  sds.begin(sdsbaud);  // baud rate of the OBD
  //send package 0x81,0x12,0xF1,0x81,0x05
  for (int i = 0; i < 5; i++){
    sds.write(message[i]);
    byte inByte = sds.read();
    console.print(inByte,HEX);
    delay(1);
  }
  console.println();
  while (!sds.available());
  while (sds.available()) {
    console.println(sds.read(),HEX);
  }
}


but when I copy paste this code I have an error like this
(https://s12.postimg.org/q5naii5pl/error_arduino.png)

I add some softwareserial for handling this error Serial1 and it's ok
(https://s18.postimg.org/4db65o51h/fix_arduino.png)

I'm still confuse on how to MC33290 communicate with arduino. when I read the code my assumtion is Tx pin 18 is using for embed fastinit to communicate with MC33290. But for what console serial is ?
(https://s12.postimg.org/kn2zlvld5/MC33290_fix.jpg)
Title: Re: Bike interface OBD
Post by: TriB on Oct 11, 2016, 12:41 pm
Hello 1ExcalibuR2,

the code is incomplete. And very, very rudimentary.
First of all, you will have to initiate the SoftwareSerial with your matching Pins:
Code: [Select]
#include <SoftwareSerial.h>
SoftwareSerial sds(18, 19);

Serial instead, uses Pin 0 & 1 by default. Or the USB, if connected.

Then, the datastart()-method is called forever in the loop(). That´s quite bad and unnecessary.
Just do the initiating stuff only once! From then on, you can submit PID 0x08 within the loop and exclude the needed information from the response.

Something like (just pseudo-code):
Code: [Select]
loop()
{
  if(!Initiated)
  {
    datastart();
    Initiated = TRUE;
  }
  else
  {
    sendPid(0x08);
  }

  while (sds.available())
    Serial.println(sds.read(),HEX);
}

void sendPid(uint8_t pid)
{
  //Create Header:
  0x81,0x12,0xF1...
  //Attach pid
  + pid
  //Add Checksum
  + checksum
  //Send to sds
  sds.write()
}
Title: Re: Bike interface OBD
Post by: 1ExcalibuR2 on Oct 11, 2016, 02:27 pm
Code: [Select]
#include <SoftwareSerial.h>
SoftwareSerial sds(18, 19);


So the sds is a serial software Tx, Rx that connect into IC ISO-Kline, isn't it ?
When I browse about Serial1, Serial1 is just work on arduino Mega. So if I want to use Arduino UNO I must use software serial or pin 0 & 1 ?
which one is good ?
Title: Re: Bike interface OBD
Post by: TriB on Oct 11, 2016, 03:55 pm
Yes, sds is the SoftwareSerial.
It can nearly use every Pin on the Board. Exceptions are listed on the datasheet (Like 0 & 1, because they are used by Hardware-Serial).

You have 18 & 19 connected to IC´s Rx and Tx. So you can initialize it with sds(18,19).

The Mega has two Hardware Serial-Ports: Serial and Serial1.
Like CrossRoads says, it has 4. My bad :(

It is always better to use the hardware Serial. Because it can buffer some data and works faster. But I think for your use case, it does not matter at the first place.
To debug what you are doing, I´d use SoftwareSerial and leave the Serial (0,1) to the SerialMonitor, like your example does.
When everything works, you can change it to the Hardware Serial.
Title: Re: Bike interface OBD
Post by: CrossRoads on Oct 11, 2016, 04:02 pm
"The Mega has two Hardware Serial-Ports: Serial and Serial1."

Correction: The Mega has 4 hardware serial ports, Serial, Serial1, Serial2, Serial3
Title: Re: Bike interface OBD
Post by: o5i_ on Oct 12, 2016, 08:20 am
I had to change the timers for the Softserial, if you can i recomend use the HardwareSerial...
Here is the last updated code...
https://github.com/o5i/Datalogger/blob/master/SDS_Logger_0.0.7/SDS_Logger_0.0.7.ino (https://github.com/o5i/Datalogger/blob/master/SDS_Logger_0.0.7/SDS_Logger_0.0.7.ino)
Title: Re: Bike interface OBD
Post by: TriB on Jan 19, 2017, 11:01 am
Just bought a Suzuki Gsx R 600 K6 (2006)

So, I will keep up creating a Kawasaki and Suzuki compatible software :)

She (off course a baby girl) will be picked up next week. Then, the hacking will keep going on :D


In some different forums, it says the K-Series has a K-Line and OBD. This has to be investigated quite well! Also it should be possible to rewrite the ECU, as I read  :o But I´m afraid about doing things like that!

Another thing is, it has already has a PowerCommander, which also got an interface. I´m curious about all the possibilities!!!

I´ll keep you up to date  :smiley-cool:
Title: Re: Bike interface OBD
Post by: James4 on Jan 20, 2017, 03:07 am
Could you post some pictures of this project please? I like it and i wanna try it.
Title: Re: Bike interface OBD
Post by: TriB on Jan 20, 2017, 10:31 am
Hi James,

pictures from what exactly?
In this thread you will find several code-snippets and links to working solutions.
Also the schematics are discussed. To understand what´s needed, I recommend reading this thread.

Until now, I only have a working solution for Kawasaki (http://forum.arduino.cc/index.php?topic=334778.0). But next week I´ll start hacking my new owned Suzuki GSX R.

How the final result look like, you can see here:
Kawasaki KDS to Buetooth (https://www.youtube.com/watch?v=MKdlcnXseew)
Title: Re: Bike interface OBD
Post by: aster94 on Jan 21, 2017, 07:33 pm
Just bought a Suzuki Gsx R 600 K6 (2006)

So, I will keep up creating a Kawasaki and Suzuki compatible software :)

She (off course a baby girl) will be picked up next week. Then, the hacking will keep going on :D


In some different forums, it says the K-Series has a K-Line and OBD. This has to be investigated quite well! Also it should be possible to rewrite the ECU, as I read  :o But I´m afraid about doing things like that!

Another thing is, it has already has a PowerCommander, which also got an interface. I´m curious about all the possibilities!!!

I´ll keep you up to date  :smiley-cool:
I am happy to know about your new girl!

About the power commander i ve heard that it just modify the signal from the sensors. So no direct interface with the ecu. A well know mechanical said me that for this reason is "shit" compared to yoshimura

For now i stopped my project since i m waiting an arduino mega, i want to have two hardware serial port to check all and not damage nothings
Title: Re: Bike interface OBD
Post by: o5i_ on Jan 22, 2017, 12:21 am
You can do much more by reflashing the ecu.. But its difficult to find information about..
>>>Here (http://ecuhacking.activeboard.com/)<<< you go
Im curious to se your interfaces, nice work guys

Title: Re: Bike interface OBD
Post by: TriB on Jan 22, 2017, 05:25 pm
You can do much more by reflashing the ecu.. But its difficult to find information about..
>>>Here (http://ecuhacking.activeboard.com/)<<< you go
Im curious to se your interfaces, nice work guys
Yes, I´ve seen that already. The Suzuki seems to be completely rewritable.
Some Guys decompilated the whole firmware and are able to change the mapping.
Maybe I´ll try to investigate that later on. At the first place, I want to have my Kawasaki solution also running on the Suzi.


About the PowerCommander:
That´s right. It just fakes some sensor data to change injection and stuff. Not the finest way to tune, but the easiest and compatible to the most bikes.
It should have an interface, which probably allows to reuse my solution also at not supported manufacturers (bmw, ktm, honda, ect.).
We will see!
Title: Re: Bike interface OBD
Post by: aster94 on Mar 17, 2017, 05:59 pm
Using the l9637 i am facing some bouncing problems, some of you have had similar problems? I send a request and i receive the eco of my request with the answer from the ecu
How did you resolvered?
Title: Re: Bike interface OBD
Post by: o5i_ on Mar 17, 2017, 10:07 pm
You can use it to check the transmission by comparing it to the sended bytes...
Title: Re: Bike interface OBD
Post by: aster94 on Mar 18, 2017, 03:22 am
My goal would be to have an hardware polish of these ecos. In software i eliminated them with a simple Serial.read()
Title: Re: Bike interface OBD
Post by: TriB on Mar 21, 2017, 10:31 pm
There is a Sender and Receiver in the messages.
If you are the sender, ignore the response.

ECU: 0x11
You: 0xF1
Title: Re: Bike interface OBD
Post by: cyclegadget on Mar 29, 2017, 03:47 am
Using the l9637 i am facing some bouncing problems, some of you have had similar problems? I send a request and i receive the eco of my request with the answer from the ecu
How did you resolvered?
My answer was to Serial.read() the eco without saving any of it, until I read everything that I sent. I checked for my last byte of my message. You can use "if" statements to watch for any combination you want. Then, I knew the next bytes were from the ECU.

Title: Re: Bike interface OBD
Post by: Markino76 on Apr 06, 2017, 02:59 pm
Hi guys,
I'm working on similar project: I'm using an Arduino Nano V3 to get info from the k-line (OBD1) of my Honda motorbike.
I'd like to use the HW Serial to dump on the Serial Monitor of my PC what I'm getting from the ECU and I'd like to use SoftwareSerial to communicate with the ECU.
I'm also using an opto-circuit to de-couple the 0-5V of the Arduino signals from the 012V of the bike.

To make the story short... I can't find a way to use SoftwareSerial library with a baud of 10400.
I've connected, for test, two Arduino Nano with SoftwareSerial ports and I'm able to dump on the HW Serial Monitor of the second Arduino all I sent from the first but can't patch the SoftwareSerial code to add 10400 baud option.
Can you please help me?

PS: I saw that SoftwareSerial library works on my Arduino Nanos only till 38400baud, if I configure it at 57600 it doesn't works fine, is it normal?
Title: Re: Bike interface OBD
Post by: o5i_ on Apr 06, 2017, 05:56 pm
Hi, softsearial doesent work, i had the same issues on seeduino. You can fix it by using the other timers in the internal setup, i dont remember where to find them.. but there is a fix... But i recomend you to use the hardware serial for the transmission, works much better...
Title: Re: Bike interface OBD
Post by: mehran135 on May 05, 2017, 08:29 pm
I want to read my car ECU coolant Temp. with using this circuit , please help me to write program .
https://forum.arduino.cc/index.php?action=dlattach;topic=455232.0;attach=210665 (https://forum.arduino.cc/index.php?action=dlattach;topic=455232.0;attach=210665)
Title: Re: Bike interface OBD
Post by: songotag on May 31, 2017, 04:58 pm
Hello o5i_,

I noticed that when the connection is lost, the microcontroller can not reset the connection unless I switch off the circuit supply.

I think the problem comes from :

if (! Tr_3) {


Can you tell me how to make the connection reset (fast init sequence) without turning off the circuit?

thank you !
Title: Re: Bike interface OBD
Post by: songotag on May 31, 2017, 06:11 pm
Hello o5i_,

I noticed that when the connection is lost, the microcontroller can not reset the connection unless I switch off the circuit supply.

I think the problem comes from :

if (! Tr_3) {


Can you tell me how to make the connection reset (fast init sequence) without turning off the circuit?

thank you !
Title: Re: Bike interface OBD
Post by: o5i_ on Jun 01, 2017, 09:57 am
Hello o5i_,

I noticed that when the connection is lost, the microcontroller can not reset the connection unless I switch off the circuit supply.

I think the problem comes from :

if (! Tr_3) {


Can you tell me how to make the connection reset (fast init sequence) without turning off the circuit?

thank you !
Hi, i dont know whats the problem.. for me it works.. on every error or timeout it resets the communication and does a fast init.. i use the opamp circuit.. maybee u need to increase the timings?
Title: Re: Bike interface OBD
Post by: Scissor on Jun 01, 2017, 12:47 pm
Hello o5i_,

I noticed that when the connection is lost, the microcontroller can not reset the connection unless I switch off the circuit supply.

I think the problem comes from :

if (! Tr_3) {


Can you tell me how to make the connection reset (fast init sequence) without turning off the circuit?

thank you !
I found out that it is necessary to wait for 5000 ms after a communication error (wrong request, timeout etc.) occurs, at least for my Kawasaki Z750 2004. This means that you really have to halt communcation this long, and not try to reconnect inbetween.
Title: Re: Bike interface OBD
Post by: songotag on Jun 02, 2017, 05:37 pm
EDIT : I found the solution :

I have to add this line :
Code: [Select]
pinMode(TX, OUTPUT);   after 
Code: [Select]
if (time > tr_2 + t_03) {   in the Timeout function ;)

io_5, you can add my name to your code if you whant for the 0.7.1 revision ;-)
Title: Re: Bike interface OBD
Post by: Scissor on Jun 04, 2017, 12:43 pm
I use my own library for communication. And whenever I lose communication (for instance due to a wrong request that results in a timeout) I reinitiate the entire communication, also the fast init. You can find my library here: https://github.com/Eztys/SimpleKDS (https://github.com/Eztys/SimpleKDS)
Title: Re: Bike interface OBD
Post by: TriB on Jul 04, 2017, 11:50 am
@o5i_ I did use your code, removed all GPS and SD-card related stuff.
Changed your buffer storing to BlueTooth.println(K_BUFFER), but it did not work.

It always gave me a Timeout. There have been some values transferred from the bike after initialization, but it did not went further...

However, I took my Kawasaki-code, enhanced the buffer and removed the "Start diagnostic session"-command, which seems not needed. Now I successfully receive 64 values :)

I guess my code is a bit more flexible and refers more to the specifications (init response, error handling, timing, keepalive, ect.). Which does not mean, that my code is clean or even "good" :D
Probably I´ll try to create a small SDS solution, first. Then creating something, which works for Honda, Kawasaki & Suzuki.

I´ll keep you up to date! Can´t wait for weekend to come. Hopefully the weather is bad, to make it easier to stay in the garage ;)
Title: Re: Bike interface OBD
Post by: AndreKravcenko on Jul 07, 2017, 05:07 am
Scissor,

i was trying to use your sketch "SimpleKDSbasic", but i couldn´t to compile it.

I get this :
Title: Re: Bike interface OBD
Post by: Scissor on Jul 08, 2017, 02:56 pm
Scissor,

i was trying to use your sketch "SimpleKDSbasic", but i couldn´t to compile it.

I get this :

I bet you did'nt install the library properly!

OK, my mistake.. I updated the library but forgot to change the example script. :-X  I've just updated the example script, and it compiles on my computer.
Title: Re: Bike interface OBD
Post by: AndreKravcenko on Jul 09, 2017, 10:16 pm
Thanks man.... i´ll try again and post my results !! (I count with the help of all of you !! )
Title: Re: Bike interface OBD
Post by: artcore on Jul 12, 2017, 02:59 am
Anyone can give a code solution to read k line of injection motorcycle using the L9637D circuit? thank you
Title: Re: Bike interface OBD
Post by: TriB on Jul 12, 2017, 11:14 am
Anyone can give a code solution to read k line of injection motorcycle using the L9637D circuit? thank you
Serious?
Here are 8 pages about this topic. With tons of code snippets and detailed explanations.
And the minimum of 5 links to GitHub, with full solutions for SDS (Suzuki) and KDS (Kawasaki).
Attachments with *.ino-Files and so on...

Furthermore, there are even more threads about this topic.

We will help you out with any specific question, but please be a little bit proactive :)
I cannot read this thread for you :P
Title: Re: Bike interface OBD
Post by: artcore on Jul 13, 2017, 02:37 am
Well, thanks in advance, sorry for my first entry in this forum.
I want to read the communication on K-Line on Yamaha Vixion motor using IC L9637D circuit, thanks  :)
Title: Re: Bike interface OBD
Post by: TriB on Jul 13, 2017, 09:56 am
As far as I could understand the YDS (Yamaha Diagnostic Protocol) protocol, it is close to the Honda protocol.
There are no sender-/receiver-adresses 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.

Until now, we only have working solutions for Kawasaki and Suzuki here in the forum.
I think, you will have to create something by your own.

A great startingpoint will always be the ECU-Hacking (http://ecuhacking.activeboard.com/t38959479/yamaha-fi-diagnostics-tool/) forum. Thats where the most of us have our basic information from :)
Title: Re: Bike interface OBD
Post by: artcore on Jul 14, 2017, 08:18 am
Oh, well, I'm learning to try using the L9637D IC and Arduino codes, but the results I get are usually only able to generate hex numbers that are data of ECU and sometimes only a few parameters whose value is almost the same as the Yamaha diagnostic tool on Generally, such as the value of Battery Voltage, incoming/intake air pressure. Thank you
Title: Re: Bike interface OBD
Post by: TriB on Jul 21, 2017, 09:50 am
I was going on developing the Suzuki solution.
As I found out with my Kawasaki, the most calculations from ECU Hacking forum are wrong or not precise.
This seems equal to the Suzuki  ::)


Has somebody found the speed in data? It is 0xFF all the time.
And there is no other value, which seems to fit. My Gsx-R 600 is from 2006 and has a digital speedometer, which let me guess, the data should be there...
Title: Re: Bike interface OBD
Post by: cyclegadget on Jul 24, 2017, 01:38 am
Has somebody found the speed in data? It is 0xFF all the time.
And there is no other value, which seems to fit. My Gsx-R 600 is from 2006 and has a digital speedometer, which let me guess, the data should be there...
I am not positive, but I thought that the speed came from the pulse counter on the front sprocket, and then went directly to speedometer cluster. Certainly, the odometer information is stored in the speedometer cluster. You can change ECUs and your mileage will still be stored int he gauge cluster.

  I need to review the wiring to find the answer, Suzuki is pretty good with individual wire colors for everything.


Mark
Title: Re: Bike interface OBD
Post by: TriB on Jul 27, 2017, 04:37 pm
Thank you Mark!
That´s what I expected. But it does not really matter, because I also use GPS to record the track and measure my lap-times.


My current calculations are:
Gear
None :)

Engine coolant Temperature in degrees Celsius
((uint32_t)ecuResponse[17] * 160 / 256) - 30

Intake manifold absolute pressure (kPa)
All found calculations are not coherent. I am getting a 0xB9 = 185 dec.
My location is at about ~40 meters above sea level, which is


0m 29.9inch Hg 760mmHg 14.7psia 1.03kg/cm³ 101kPa

(Source (http://www.engineeringtoolbox.com/air-altitude-pressure-d_462.html))
Without having values from different heights, it is nearly impossible to get an approximated factor.

Engine Speed (RPM)
A*100+B is definitely wrong. All calculations base on 256 factor A*256+B
It is stored under double precision, I think:
(((uint32_t)ecuResponse[13] << 8 ) + ecuResponse[14]) / 2
(<< 8 is equal to *256)
[EDIT:] No it´s not. / 2.56 seems closer but still not right. Or my dashboard shows slightly different values. The RPM is at about 1,900 (The needle almost touches the 2000 on the scale) after starting up. /2 makes 2,191 and /2.56 - 1711.

Throttle Pos. Sensor
There are some calculation to degrees, which in my eyes aren´t very helpful.
That´s why I work with min & max values (max is actually not from my bike, due to loudness reasons in my garage)
maximum = 0xDD;
minimum = 0x39;
value = map(ecuResponse[15], minimum, maximum, 0, 100);

gives you the percentage.

Voltage
I expect it to be rather the dynamo output then the battery voltage.

(uint32_t)ecuResponse[20] * 20 / 256

Relative/Secondary Throttle pos. sensor
Should be adequate to TPS. but I didn´t got time to measure min & max values.

That´s what I guess, right now :) I´ll try to get TPS min & max values and try to measure my battery voltage, next time.
Title: Re: Bike interface OBD
Post by: TriB on Aug 16, 2017, 01:57 pm
Hi guys,

I´ve been on a racetrack, last weekend. During the breaks, I got some spare time to go on testing.
Again, the most calculations are still not right.
Voltage: Measured 12.44 and 13.9 was calculated
RPM: Seems to fit more or less. Probably the rev meter is not very accurate.
TPS: Enhanced the code with automatic adjustment, now it shows the right percentage (which is enough for me). Next step is to store min & max values to eeprom and make them readable via bluetooth.

Sadly I got dozens of break downs :(
With ignition on, I can listen to the ECU for hours. With engine on, I receive some values and run into a timeout. After 5 Seconds (Minimum time to wait from ISO protocol), it might gets initialized again.
10-20 Seconds data and again: timeout.

My loop checks the last request and if it is older then a second, it sends a keepalive message to the ECU.
Bluetooth asks constantly for single data (RPM, Temp, TPS, ect.), so I request the ECU on every RPM question. The remaining data comes from a buffer until RPM is asked again and "fresh"-data is obtained.

After the request is sent to the ECU, a timer is reset on every received byte. If the timer passes 55ms, the timeout is thrown (ISO specification says 40ms). That´s what happens right now.

Did someone also got breakdowns? Or is it related to my Code, device or bike? :(
Title: Re: Bike interface OBD
Post by: cyclegadget on Aug 16, 2017, 06:26 pm
Trib,

 Are you trying to use Bluetooth to communicate with the bike, or to the Arduino board on the bike?

 When the bike is off, the OBD voltage is +-12volts. When the bike is running you will get some switching spikes and alternator noise that would show up on an Oscope. Your circuit may need some capactors or more shielding.

 I can log my Suzuki with my laptop while riding on the road with no problems. I still need to finish my Arduino however.
Title: Re: Bike interface OBD
Post by: TriB on Aug 17, 2017, 05:21 pm
Hi cyclegadget,

I connected an Arduino to a HC-06 and created some kind of ELM327 compatible protocol.
Made that to transfer my data to my Garmin Virb camera, which is capable of OBD II recording.
You can, more or less, use every OBD II / ELM327 compatible device or app to see the data.

That works fine for my Kawasaki. Suzuki gets one PID to transfer all data, Kawa one PID for each value (RPM, Speed, TPS, ect.), so I changed the sketch a bit and added a small caching mechanism, like described in my previous post.


The voltage comes from the ECU data, it´s zero until the engine is started. The formula from here and from ECU Hacking Forum gives me a different value, then my multimeter. That´s why I expect it to be wrong. Like some other values.

Due to the fact, that it runs on my Kawa, I expect the cirquit to be right. The sketch goes on, but gets a timeout from the ECU, what can be anything, I guess  :smiley-roll:

PS: You can see it here (https://www.youtube.com/watch?v=7NzQdNrY6Ro) or here (https://www.youtube.com/watch?v=MKdlcnXseew) on YouTube.

(http://fs5.directupload.net/images/170818/lbjt7q6q.jpg) (http://www.directupload.net)
Title: Re: Bike interface OBD
Post by: JOTTDUINO on Dec 28, 2017, 11:59 am
I hope that someone may reads. I'm working on Suzuki Bking from a friend, and I'm not getting any response from the ECU. I read the entire post but nothing. Here is the code, just a simple Fast Init and the Starting packet. As the hardware interface I'm using the L9637D with a pull up resistor of 515 Ohms and K_line goes in and then RX and TX wire to RX and TX of arduino mega. Also using Serial(115200) to communicate with PC and Serial1(10400) to motorcycle

Code: [Select]
void loop() {
  //put your main code here, to run repeatedly:
   delay(3000);
   while(!Serial1.available());

   delay(500);
   IGNITION = true;
   if (IGNITION){Serial.println("K line available");}
   IGNITION = false;
   while(!ECUconnected){
      if(initPulse()){
        ECUconnected = true;
        toggleLed();
      }
   }
}

boolean initPulse(){ 
// This is the ISO 14230-2 "Fast Init" sequence.
Serial1.end();
digitalWrite(TX1,HIGH);
delay(750);
digitalWrite(TX1, LOW);
delay(25);
digitalWrite(TX1, HIGH);
delay(25);
Serial.println("\nFast Init DONE");
Serial1.begin(SDSbaud);
delay(200);
Serial.print("Sending to ECU: ");

for (int i = 0; i < 5; i++){
  Serial1.write(K_START_COM[i]);
  Serial.print(" 0x");Serial.print(K_START_COM[i],HEX);   
  delay(5);  //inter byte delay for to match k-line spec
}
Serial.println("\nStarting K Sequence DONE...");

delay(25); //Request-response delay


if(Serial1.available()){
 
  Serial.println("Recieving echo from ECU");

  for(int j=0 ; j < 8; j++){
    K_BUFFER[j] = Serial1.read();}
  }
   
}
  for (int j = 0; j < 8; j++){
     if (K_BUFFER[j] == ECU_RESPONSE[j]){
      Serial.println("Communication sucess");}
}
Title: Re: Bike interface OBD
Post by: o5i_ on Dec 28, 2017, 12:22 pm
I hope that someone may reads. I'm working on Suzuki Bking from a friend, and I'm not getting any response from the ECU. I read the entire post but nothing. Here is the code, just a simple Fast Init and the Starting packet. As the hardware interface I'm using the L9637D with a pull up resistor of 515 Ohms and K_line goes in and then RX and TX wire to RX and TX of arduino mega. Also using Serial(115200) to communicate with PC and Serial1(10400) to motorcycle

Code: [Select]
void loop() {
  //put your main code here, to run repeatedly:
   delay(3000);
   while(!Serial1.available());

   delay(500);
   IGNITION = true;
   if (IGNITION){Serial.println("K line available");}
   IGNITION = false;
   while(!ECUconnected){
      if(initPulse()){
        ECUconnected = true;
        toggleLed();
      }
   }
}

boolean initPulse(){ 
// This is the ISO 14230-2 "Fast Init" sequence.
Serial1.end();
digitalWrite(TX1,HIGH);
delay(750);
digitalWrite(TX1, LOW);
delay(25);
digitalWrite(TX1, HIGH);
delay(25);
Serial.println("\nFast Init DONE");
Serial1.begin(SDSbaud);
delay(200);
Serial.print("Sending to ECU: ");

for (int i = 0; i < 5; i++){
  Serial1.write(K_START_COM[i]);
  Serial.print(" 0x");Serial.print(K_START_COM[i],HEX);   
  delay(5);  //inter byte delay for to match k-line spec
}
Serial.println("\nStarting K Sequence DONE...");

delay(25); //Request-response delay


if(Serial1.available()){
 
  Serial.println("Recieving echo from ECU");

  for(int j=0 ; j < 8; j++){
    K_BUFFER[j] = Serial1.read();}
  }
   
}
  for (int j = 0; j < 8; j++){
     if (K_BUFFER[j] == ECU_RESPONSE[j]){
      Serial.println("Communication sucess");}
}

Maybee you try first the interface using ecueditor and a serial cable... If that works proceed to the code.. My last code is on github and works fine with the k6... just remove the gps and sdcard section if you dont need it..
https://github.com/o5i/Datalogger (https://github.com/o5i/Datalogger)
https://raw.githubusercontent.com/o5i/Datalogger/master/SDS_Logger_0.0.7/SDS_Logger_0.0.7.ino (https://raw.githubusercontent.com/o5i/Datalogger/master/SDS_Logger_0.0.7/SDS_Logger_0.0.7.ino)
But use the hardwareserial, the softserail doesent work.. I used the altsoftserial but had to use another timer to get it work..
Title: Re: Bike interface OBD
Post by: JOTTDUINO on Dec 28, 2017, 12:29 pm
Thanks for answering so fast. Yeah, I tried your code removing sdcard and gps sections but nothing happens.
I'll try ecueditor with the interfrace,thats a good idea.
Title: Re: Bike interface OBD
Post by: JOTTDUINO on Dec 29, 2017, 12:31 pm
Ok, I tried several times but ecueditor does not connect using this hardware setup..I don't know why.(https://camo.githubusercontent.com/b16299cbe97dce60a79a9a07e097864e1c0a8325/68747470733a2f2f7332372e706f7374696d672e6f72672f6379396770686530332f436972637569742e706e67)

Edit: Yeah, it's working now, I changed the FTDI...Let's see the code now
Title: Re: Bike interface OBD
Post by: JOTTDUINO on Jan 04, 2018, 05:38 pm
I'm getting little by little that starts working. Once you request the data from the sensors by sending the code, do you stay in a loop sending that code and reading or just reading over and over?

Cheers.
Title: Re: Bike interface OBD
Post by: o5i_ on Jan 05, 2018, 07:44 am
You need to send the request everytime.. but make sure you have 1-2 ms delay between answere and new request. I got a stable maximum speed working at 135ms per transaction.. on some bikes you can use ecueditor to flash the code using a different baudrate (50000) wich increases the speed to 55ms.. cheerz..
Title: Re: Bike interface OBD
Post by: JOTTDUINO on Jan 19, 2018, 01:03 pm
Ok, this is what I have after requesting the sensors data. I receive:

----------------------------------------------
80 12 F1 2 21 8 AE
----------------------------------------------
80 12 F1 2 21 8 AE
----------------------------------------------
80 F1 12 34 61 8 5 16 55 A0 16 50 A0 FF FF FF FF 0 0 39 AC 53 52 AD 0 FF 0 FF 66 2B FF 0 0 0 0 0 0 0 0 FF FF 40 40 40 40 FF FE FF 6B 1F 30 4 4 0 FF FF B1 80 12 F1 2 21 8

Can anyone confirm if is OK?
I doubting about the beginning 80 12 F1 2 21 8 AE and then at the end of the long message appears again but without the AE

YES!! I think I'm getting there,the only value is not 100% correct is the battery voltage and I dont get the speed either. Anybody knows?
Title: Re: Bike interface OBD
Post by: TriB on Jan 22, 2018, 11:28 am
Can anyone confirm if is OK?
Yes, that´s fine. You can be sure, when the Service ID is responded as SID + 0x40.
Then the request was right and the response will be valid.

Otherwise you are getting something like that:
0x80 0xF1 0x12 0x02 0x7F 0x21 0x10 as an Error. The second value might give you an idea what went wrong. But that seems to differ from ECU manufacturer to manufacturer.

Battery is quite complicated, I guessed a lot and don´t think it is the right value. It seems to be the loading voltage from the generator.
Title: Re: Bike interface OBD
Post by: CapFirepants on Feb 14, 2018, 07:22 am
Hey Guys
I've been reading through this post with great interest. I would like to adapt the software from 05i to work with a Honda CB500F 2013 Model. Has anybody tested this with a Honda bike, perhaps even with the same one I have?
Title: Re: Bike interface OBD
Post by: TriB on Feb 14, 2018, 10:56 am
Hello Cap,

as far as I know, the hardware and init-sequence will be the same.
But the protocol is quite different! No format within the message header, ect.

The ECU Hacking Forum is not very helpful about it. There is just one unanswered thread (http://ecuhacking.activeboard.com/t63511846/data-byte-from-honda-pcx-150/) about this topic.
And maybe this one (http://99460.activeboard.com/t42555375/hacking-ecu-honda-keihin/?page=1&sort=newestFirst).

Good luck!
Title: Re: Bike interface OBD
Post by: CapFirepants on Feb 14, 2018, 11:44 pm
Hello Cap,

as far as I know, the hardware and init-sequence will be the same.
But the protocol is quite different! No format within the message header, ect.

The ECU Hacking Forum is not very helpful about it. There is just one unanswered thread (http://ecuhacking.activeboard.com/t63511846/data-byte-from-honda-pcx-150/) about this topic.
And maybe this one (http://99460.activeboard.com/t42555375/hacking-ecu-honda-keihin/?page=1&sort=newestFirst).

Good luck!
Thank you.
Ive done some more searching and found this link: https://lunarflow.com/index.php?topic=15.0, which in turn links to this: http://projects.gonzos.net/ctx-obd/ looks to me like it could be the same protocol my 500f uses. Would you care to take a look and tell me what you think?
Title: Re: Bike interface OBD
Post by: TriB on Feb 15, 2018, 10:56 am
links to this: http://projects.gonzos.net/ctx-obd/
Yeahr, cool! That looks nice!

I´d say, with this information you can easily realize that.
The Honda data tables.pdf (http://projects.gonzos.net/wp-content/uploads/2015/09/Honda-data-tables.pdf) will show you which value is what and how it has to be calculated.
The schematic can be made easier using an L9637D (http://www.st.com/content/ccc/resource/technical/document/datasheet/4a/80/83/26/e0/78/4d/18/CD00000234.pdf/files/CD00000234.pdf/jcr:content/translations/en.CD00000234.pdf).
It will convert the single K-Line to serial Rx & Tx. No need for two separate converter.

You can take OSi´s work as a base. It fits better then mine, which is optimized to respond with a single value, not a data table.
Title: Re: Bike interface OBD
Post by: CapFirepants on Feb 20, 2018, 08:08 am
Alright! I've ordered some L9637Ds and will start looking for a solution when they arrive. I'll post again, either if I need some help or if I get it working.
Title: Re: Bike interface OBD
Post by: CapFirepants on Mar 07, 2018, 07:53 pm
Yeahr, cool! That looks nice!

I´d say, with this information you can easily realize that.
The Honda data tables.pdf (http://projects.gonzos.net/wp-content/uploads/2015/09/Honda-data-tables.pdf) will show you which value is what and how it has to be calculated.
The schematic can be made easier using an L9637D (http://www.st.com/content/ccc/resource/technical/document/datasheet/4a/80/83/26/e0/78/4d/18/CD00000234.pdf/files/CD00000234.pdf/jcr:content/translations/en.CD00000234.pdf).
It will convert the single K-Line to serial Rx & Tx. No need for two separate converter.

You can take OSi´s work as a base. It fits better then mine, which is optimized to respond with a single value, not a data table.
So the chip arrived today. Wasnt aware that its smd, dont have a board for it so I soldered some cables to the pins. Doesnt look nice but works I guess, at least for testing. Ill check to get some kind of pcb made or so when Im done.

@Trib: I've just noticed you list a Ceramic-Capacitor 10 nF 50 V/DC. I only have an electrolytic 3.3 uf 50v as the smallest size. Would it be ok to use that one instead?

What I really want is the gear, so I thought maybe starting with your code and working my way from there. I've pulled it but it seems to be in 4 different .ino files. Im a bit confused, do I need to merge them or something? Sorry for all the novice questions.
Title: Re: Bike interface OBD
Post by: TriB on Mar 08, 2018, 11:12 am
@Trib: I've just noticed you list a Ceramic-Capacitor 10 nF 50 V/DC. I only have an electrolytic 3.3 uf 50v as the smallest size. Would it be ok to use that one instead?

What I really want is the gear, so I thought maybe starting with your code and working my way from there. I've pulled it but it seems to be in 4 different .ino files. Im a bit confused, do I need to merge them or something? Sorry for all the novice questions.
Oh yes, it is really tiny! There are some SOIC boards, to make the implementation easier.

I didn´t calculate if you would still fit into the specification of L9637D. The costs are small and a capacitor is sent within a day. So I would go for sure and get a 10nF.

The *.ino files are belonging together. If you copy all of them into the same folder, just open one of them and the others will be opened in the Arduino IDE in seperate Tabs.
The IDE handle them internally as one code file.
Title: Re: Bike interface OBD
Post by: gsustek on May 10, 2018, 10:20 am
Hello, awese work! I have Honda VFR 1200 X and wanna to rewrite flash ECU. Is it generaly  k-line interface enough for that and what kind of software should i use(ecuflash)?
Title: Re: Bike interface OBD
Post by: TriB on May 10, 2018, 12:28 pm
I have Honda VFR 1200 X and wanna to rewrite flash ECU. Is it generaly  k-line interface enough for that and what kind of software should i use(ecuflash)?
Theoretically it would be possible to rewrite the mapping through K-Line.
Practically, there are some security layer, which will prevent you from doing that!

Also I don´t expect any expensive software to work with a self created adapter. The ecuflash-guys spent weeks or even years of work into their flashing tool and for sure, they won´t give it away for free.

For Suzuki there is a big community, which disassembled the ECU code and created an open source software, where you can easily flash the mapping or the whole software.
Kawasaki secured their ECU with an unique seller-code, which has to be purchase as an official seller.
I guess that Honda did something similar, due to the fact, they also use Denso Ecu´s.

Even owning a Suzuki and some self created adapters, I wont mess up my ECU without deep knowledge of mapping and stuff!
Title: Re: Bike interface OBD
Post by: gsustek on May 11, 2018, 09:00 am
Wise words:-)

So that is the state of ( opensource ) motorcycle ECU knowledge/physical accomplishment:-)

Thank you so much.
Title: Re: Bike interface OBD
Post by: TriB on Aug 29, 2018, 11:54 am
A little video with some sequences including RPM, speed, temperatures and throttle.

It did not work the whole time and often broke the connection after ~5 minutes. That´s why I did not used the overlays all the time.

This has to be investigated. My Kawasaki (with the same dongle but a slightly different protocol) works for hours. Maybe an overflow or something.


(http://fs5.directupload.net/images/180829/temp/d924ig9k.jpg) (https://youtu.be/KTrtMf_bz10)
YouTube\Zolder and Mettet 2018 (https://youtu.be/KTrtMf_bz10)
Title: Re: Bike interface OBD
Post by: aster94 on Oct 26, 2018, 09:16 pm
Hi guys!

I am veeery near to finish a project which i have worked since some times: a library to make the communication with motorbikes which uses the keyword protocol 2000 easy for everyone, in the last months i gained quite a good knowledge about this protocol and obviously i am ready to share it :D

this is my almost finished attempt:
https://github.com/aster94/Keyword-Protocol-2000 (https://github.com/aster94/Keyword-Protocol-2000)

I was wondering if someone would like to contribute with the kawasaki/honda/yamaha part, i know almost nothing about these bikes but they should be using the same protocol and all the code is already settled for them

Right now i am testing this on a suzuki GSX-R 600 L1 (2011) but it doesn't respond to the start sequence. I am not sure which is the problem but i guess some echo or maybe suzuki stopped using the KWP before 2011 :(

EDIT: be aware that the documentation on github is not up to date
Title: Re: Bike interface OBD
Post by: TriB on Oct 28, 2018, 12:56 pm
Hi,

nice to see how far you got!
I just throw an eye on you code and it will not be able to cover Suzuki and Kawasaki.
What you called PID, is the place of a specific value within the response data. Because Suzuki gives you all information in a single request. But in OBD II and KDS, the PID is per request.
Give me RPM out->0x0C  in<-2500rpm.
That is hard to combine and you more or less double the code with two different approaches. I´m somewhere on half way there. It works, but SDS is quite slow, due to the fact I does not store the values right now.

Right now i am testing this on a suzuki GSX-R 600 L1 (2011) but it doesn't respond to the start sequence. I am not sure which is the problem but i guess some echo or maybe suzuki stopped using the KWP before 2011 :(
Me also got everything running and then, from one day to the other my ECU did not respond to the init protocol anymore.
In my case, it was my datalogger. It sends all outgoing and incoming data to a second arduino, which does all the SD-stuff. Sending a single request took 0,012 secs. But it seems to be enough, that my Suzuki GSX-R600 K6 does not respond anymore. Deactivating that, instantly made it work again. Try it with you debugging-mode.
Title: Re: Bike interface OBD
Post by: aster94 on Oct 28, 2018, 03:17 pm
Hi trib,

I know that kawasaki needs to ask for every single sensor
this is the reason for a couple of defines in my code: see here (https://github.com/aster94/Keyword-Protocol-2000/blob/master/src/PIDs.h#L101) and then this (https://github.com/aster94/Keyword-Protocol-2000/blob/master/src/KWP2000.cpp#L543)

This way calling just one function which is requestSensorsData on both suzuki and kawasaki on suzuki will send just one request (0x21, 0x08) while in kawasaki it will send a group of request :smiley-razz:

EDIT: it seems that it wasn't my fault https://github.com/espressif/arduino-esp32/issues/2004
Title: Re: Bike interface OBD
Post by: Bullone on Jan 03, 2019, 02:16 pm
Hi guys,
thanks for all the great informations!
I have an Yamaha Tracer 900 2018 and I suppose my bike is using CAN bus on the diagnostic connector... can you help me to implement an Arduino based board to read some data (TPS, RPM...) via CAN? Is it possible?
Title: Re: Bike interface OBD
Post by: TriB on Jan 04, 2019, 10:29 am
Hi Bullone,

what makes you think that Yamaha uses CAN-Bus?
They are still on K-Line as Suzuki and Kawasaki.

But what changed due to the 2018 EURO6 is, that it is OBD2 compatible.

These are two different things!
CAN-Bus is the way data is sent between ECU, sensors / actuators and diagnostic plug.
K-Line is the way how the diagnostic plug sends and receives data via single line. Sensors and stuff is just communicating by it´s voltage/resistance.

OBD2 is only the language how it speaks to you.

What you can do is to connect a stock ELM327 OBD2 Plug to you diagnostic Plug. Since OBD2 is compatible, you can use it right from the start, like in a car.
No value calculations, no PID translations, ect.

You only need to know which wire is the K-Line, Ground and Voltage, to connect it equivalent to the ELM327 Dongle.

Good luck :)
Title: Re: Bike interface OBD
Post by: Bullone on Jan 04, 2019, 10:43 am
Hi Bullone,

what makes you think that Yamaha uses CAN-Bus?
They are still on K-Line as Suzuki and Kawasaki.

But what changed due to the 2018 EURO6 is, that it is OBD2 compatible.

These are two different things!
CAN-Bus is the way data is sent between ECU, sensors / actuators and diagnostic plug.
K-Line is the way how the diagnostic plug sends and receives data via single line. Sensors and stuff is just communicating by it´s voltage/resistance.

OBD2 is only the language how it speaks to you.

What you can do is to connect a stock ELM327 OBD2 Plug to you diagnostic Plug. Since OBD2 is compatible, you can use it right from the start, like in a car.
No value calculations, no PID translations, ect.

You only need to know which wire is the K-Line, Ground and Voltage, to connect it equivalent to the ELM327 Dongle.

Good luck :)
Wow! Thanks for the info!
I was supposed that on the DLC connector of the recent bike I have to "read" CAN bus data.... have you ever work on Yamaha DLC? I'd liek to do an Arduino board to read TPS, RPM and ECT from the DLC
Title: Re: Bike interface OBD
Post by: TriB on Jan 04, 2019, 01:19 pm
No, I haven´t. But since this is standardized, it should be easy as nuts!


Pinout can be found here (https://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II_diagnostic_connector) on Wikipedia.

And here (https://www.fz09.org/forum/6-fz-09-general-discussion/48121-obd2-diagnostic-tool-clearing-faults-3.html) is how to connect it onto your bike. There are several online-shops which sell a connector (for a lot of money). But you can do it by yourself for testing purpose.

Then install Torque, Car Scan or a simple Bluetooth Terminal on your phone, to test the connection.
Title: Re: Bike interface OBD
Post by: Bullone on Jan 04, 2019, 01:37 pm
Thank you so much!
Looking on the link you post it make me back confused.... the diagnostic connector has 4 pins: +12V, GND, CAN HI and CAN LOW.... also on the OBDII connector the pin6 and 14 are related to the CAN bus. That means that the diagnostic use CAN instead of k-line?

Sorry but I'm confused, probably my fault! :)
Title: Re: Bike interface OBD
Post by: Bullone on Jan 04, 2019, 01:44 pm
What about this post?
https://www.fz09.org/forum/6-fz-09-general-discussion/5491-data-logger-plug-play-devellopement.html
Title: Re: Bike interface OBD
Post by: TriB on Jan 08, 2019, 10:00 am
What about this post?
This is from 2010, as you can see. It also uses K-Line to communicate with the diagnostic interface, like we do here.
As you have said, the new bike from 2018 uses CAN. So how should that help?
And why you don´t follow my idea with an OBD2 dongle?

OBD2 dongles support several communication types (As K-Line and CAN).
Get your bikes diagnostic plug-pinout and combine it with my wiki-link to the ELM327 (OBD2 dongle) pinout.
That´s it!

The ELM327 makes everything for you. You won´t see if it uses K-Line or CAN.
Title: Re: Bike interface OBD
Post by: Bullone on Jan 08, 2019, 10:48 am
Thanks for all the info!
The DLC connector has 4pins: CAN+, CAN-, +12V and GND

Title: Re: Bike interface OBD
Post by: aster94 on Jan 10, 2019, 12:53 am
I am enough happy with my library and finally I am ready to promote it to version 1.0.0 and to pubblish it!

Keyword Protocol 2000 (https://github.com/aster94/Keyword-Protocol-2000)

This would help you make the interface between motorbikes/cars and arduino easier

Get me on github and tell me if you test it so i can upgrade the list of tested bikes!
Title: Re: Bike interface OBD
Post by: TriB on Jan 13, 2019, 11:37 am
Nice one, @aster94!
Really a lot of work in it.

Currently I am recreating my Gsx-R due to a little accident on a racettrack. But I´ll test your code on both, my K6 and my Kawasaki Z750r.

My solution also does both, but it got less interfaces. My goal was different, I made it OBD2 compatible, so there are plenty of duplicated codes (for conversion, clear diagnostic, and more).
Maybe I´ll try to combine the best of both worlds, when I got time for that.
Title: Re: Bike interface OBD
Post by: aster94 on Jan 14, 2019, 04:58 pm
Nice one, @aster94!
Really a lot of work in it.

Currently I am recreating my Gsx-R due to a little accident on a racettrack. But I´ll test your code on both, my K6 and my Kawasaki Z750r.

My solution also does both, but it got less interfaces. My goal was different, I made it OBD2 compatible, so there are plenty of duplicated codes (for conversion, clear diagnostic, and more).
Maybe I´ll try to combine the best of both worlds, when I got time for that.
I hope you are ok and I am sure that your bike will get better then before :D

when i started to write this i had to decide between OBDII and KWP2000, both had pro and cos but at the end i choosed for the KWP because it would be faster since it doesn't have to "traslate" request/responses, obviously this also means that my code is less portable!

I can confirm that there is a lot of work in it, it stated as a hobby project but I guess you can understand that soon it took me more time than expected ahahah
Title: Re: Bike interface OBD
Post by: CapFirepants on Mar 27, 2019, 07:08 pm
I hope you are ok and I am sure that your bike will get better then before :D

when i started to write this i had to decide between OBDII and KWP2000, both had pro and cos but at the end i choosed for the KWP because it would be faster since it doesn't have to "traslate" request/responses, obviously this also means that my code is less portable!

I can confirm that there is a lot of work in it, it stated as a hobby project but I guess you can understand that soon it took me more time than expected ahahah

Hey Aster
I posted here about a year ago and finally got around to trying out something. I loaded your library up onto my arduino uno and tried the example sketch you have on github.

My bike is a honda CB500F (PC45) 2013 Model.
I tried to uncomment the honda but got this error message while compiling:
-------------------------------------------------------------------------------------------------------------------

Code: [Select]
C:\Arduino\libraries\KWP2000\src\KWP2000.cpp: In member function 'void KWP2000::requestSensorsData()':

C:\Arduino\libraries\KWP2000\src\KWP2000.cpp:505:19: error: 'request_sens' was not declared in this scope

     handleRequest(request_sens, LEN(request_sens));

                   ^

Using library KWP2000 at version 1.1.0 in folder: C:\Arduino\libraries\KWP2000

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

I went to look into the code and saw your comment about the yamaha and honda being probably the same, so I tried uncommenting just the yamaha and was able to compile.

Next, I hooked up my setup to the bike and tried reading data. The output I got back is attatched. I'm not really sure that it's what I should be getting - as soon as the ECU turned on it would not stop sending out data...maybe you could advise me here?

I'd really like to get this working and help you to extend your library. If you could tell me where to start, that would be great!

Also, here some pictures of my setup. The mess of hotglue is the L9636 chip with dupont wires soldered to the appropriate pins. Crude, but it works. I didnt have any 510 Ohm resistors, so I took 2 1k in parallel - should be fine, right?
https://imgur.com/a/I1a5Yit (https://imgur.com/a/I1a5Yit)


Title: Re: Bike interface OBD
Post by: aster94 on Mar 29, 2019, 11:27 am
Hey Aster
I posted here about a year ago and finally got around to trying out something. I loaded your library up onto my arduino uno and tried the example sketch you have on github.

My bike is a honda CB500F (PC45) 2013 Model.
I tried to uncomment the honda but got this error message while compiling:
-------------------------------------------------------------------------------------------------------------------

Code: [Select]
C:\Arduino\libraries\KWP2000\src\KWP2000.cpp: In member function 'void KWP2000::requestSensorsData()':

C:\Arduino\libraries\KWP2000\src\KWP2000.cpp:505:19: error: 'request_sens' was not declared in this scope

     handleRequest(request_sens, LEN(request_sens));

                   ^

Using library KWP2000 at version 1.1.0 in folder: C:\Arduino\libraries\KWP2000

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

I went to look into the code and saw your comment about the yamaha and honda being probably the same, so I tried uncommenting just the yamaha and was able to compile.

Next, I hooked up my setup to the bike and tried reading data. The output I got back is attatched. I'm not really sure that it's what I should be getting - as soon as the ECU turned on it would not stop sending out data...maybe you could advise me here?

I'd really like to get this working and help you to extend your library. If you could tell me where to start, that would be great!

Also, here some pictures of my setup. The mess of hotglue is the L9636 chip with dupont wires soldered to the appropriate pins. Crude, but it works. I didnt have any 510 Ohm resistors, so I took 2 1k in parallel - should be fine, right?
https://imgur.com/a/I1a5Yit (https://imgur.com/a/I1a5Yit)



Hi! sure i would like to help!

so before starting do you have any possibility to get a board with two serial port? like an arduino mega or stm32f1?

the arduino UNO you are using is not well suited for this work because it has only one serial port and you are usint that serial to programming, serial monitor and comunication with the ECU, definitely too much.
You could use a software port, you should be able to get it working but a real serial would be almost error free

then we could figure out something to send only the 0x80 and 0x02 your bikes needs!

by the way that error is there because i never implemented the protocol for yamaha and honda, i will add a compile #error to prevent people to run it!
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 03, 2019, 12:39 pm
Hi! sure i would like to help!
Hey aster - I got the board today, what's the next step?
Edit: Does this mean TX from the L9637 should go to the arduino pin 13?
https://imgur.com/q51aoG9  (https://imgur.com/q51aoG9)?
Serial2 on the mega is on pins 18 and 19 though, if I'm correct?
http:// (http://)https://www.theengineeringprojects.com/wp-content/uploads/2018/06/introduction-to-arduino-mega-5-768x413.png (https://www.theengineeringprojects.com/wp-content/uploads/2018/06/introduction-to-arduino-mega-5-768x413.png)
Title: Re: Bike interface OBD
Post by: aster94 on Apr 04, 2019, 08:59 pm
that means that you said to the library that your TX is on pin 13, you should set it to the TX pin of the serial you are using with the motorbike, i "wrote" a documentation, you can see it if you have any doubt: https://github.com/aster94/Keyword-Protocol-2000/blob/master/documentation.md#public--kwp2000hardwareserial--kline_serialconst-uint8_t-k_out_pinconst-uint32_t-kline_baudrate

https://github.com/aster94/Keyword-Protocol-2000/blob/5f818a8ca7fbd0a6a7108e619a21f0b65f3fc844/examples/basic_working/basic_working.ino#L11

have you found any resources about the protocol used by the CB500F?
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 05, 2019, 10:15 am
that means that you said to the library that your TX is on pin 13, you should set it to the TX pin of the serial you are using with the motorbike, i "wrote" a documentation, you can see it if you have any doubt: https://github.com/aster94/Keyword-Protocol-2000/blob/master/documentation.md#public--kwp2000hardwareserial--kline_serialconst-uint8_t-k_out_pinconst-uint32_t-kline_baudrate

https://github.com/aster94/Keyword-Protocol-2000/blob/5f818a8ca7fbd0a6a7108e619a21f0b65f3fc844/examples/basic_working/basic_working.ino#L11

have you found any resources about the protocol used by the CB500F?
I see, thanks! It's clear now.

Yes, a few resources are here:
A quite similar project (I think) using a raspberry pi with python (https://gonzos.net/projects/ctx-obd/)
Project source (http://gonzos.net/obd/ctxobd.zip)
Data table for the protocol (http://projects.gonzos.net/wp-content/uploads/2015/09/Honda-data-tables.pdf)
ECU hacking thread with a bit of info (https://99460.activeboard.com/t42555375/hacking-ecu-honda-keihin/?page=1&sort=newestFirst)

I havn't really found anything on the CB500F in perticular but id think the protocol is the same?
Title: Re: Bike interface OBD
Post by: aster94 on Apr 07, 2019, 11:39 am
A quite similar project (I think) using a raspberry pi with python (https://gonzos.net/projects/ctx-obd/)

This is a good resource, it think it is better to start with a simple sketch using this:

put K-line low for 70msec
put K-line high for 120msec
Send: FE 04 FF FF
No response is expected
Wait 200msec
Send : 72 05 00 F0 99
respond: 02 04 00 FA

Could you write a sketch with this sequence? I will check it and make all the necessary changes :)

if the ECU responds probably it is using the same procotol, do you have a digital analyzer? It would be very useful and them are very cheap (https://it.aliexpress.com/item/Pi-nuovo-USB-ANALIZZATORE-LOGICO-SALEAE-24-M-8CH-logic-Analyzer-24-M-8-Canali-Buffer/32986676965.html?isdl=y&albslr=206232166&src=google&aff_platform=true&albcp=1750018938&aff_short_key=irey5Th&gclid=CjwKCAjwv6blBRBzEiwAihbM-VTTvRXzfnRVt_BS5_fRDdWlBpSbP9xkQbzu9-WIiN_vFAXT6pfXSxoCTcUQAvD_BwE&albad=340648237322&albag=76953555268&albch=apprmkt&albagn=1500039111)

Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 08, 2019, 07:26 am
This is a good resource, it think it is better to start with a simple sketch using this
.......
I tried writing such a sketch as follows:
Code: [Select]

Serial serial;
Serial2 bike;

// put K-line low for 70msec
digitalWrite(18, LOW); // Im not sure I can do it like this. Maybe I need to have another pin which is conneted to the kline directly, passing the L9637?
delay(70);
// put K-line high for 120msec
digitalWrite(18, LOW); // again, not sure if this would work
delay(120);
// Send: FE 04 FF FF
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
Serial2.write(message0, sizeof(message0));
// No response is expected
// Wait 200msec
delay(200);
// Send : 72 05 00 F0 99
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};
Serial2.write(message1, sizeof(message1));
// respond: 02 04 00 FA
for (int i = 0; i < 4; i++)
{
  while (!Serial2.available())
    ; // wait for a character
  int incomingByte = Serial2.read();
  Serial.print(incomingByte, HEX);
  Serial.print(' ');
}
Serial.println();

Im not sure I can really just write the tx pin on the L9637 low, I assume it would not work and I would need to have another digital pin that I can pull to ground with a beefy resistor to avoid frying my board?

I dont have a logic analyser sadly. Ordered one just now :)

Title: Re: Bike interface OBD
Post by: TriB on Apr 08, 2019, 03:49 pm
Im not sure I can really just write the tx pin on the L9637 low
Yes, that should be fine!

Looks like that in my code:
Code: [Select]
//Honda ISO-9141-2
void fastInit9141() {
  Serial.end();
  setKline(LOW);
  delay(70);
  setKline(HIGH);
  delay(120);  
  Serial.start(10400);
}


And then I "stole" a code, which I haven´t tested yet:
Code: [Select]
bool startCommHonda() {
  //http://projects.gonzos.net/ctx-obd/
  //  Send "Wakeup" message: FE 04 FF FF. No response is expected
  //  Wait 200msec
  //  Send "Initialise" message: 72 05 00 F0 99
  //  The ECU should respond with: 02 04 00 FA

  //72 07 72 11 00 14 F0 (RPM)
  //02 1A 72 11 00 00 00 18 00 62 57 EF 10 91 63 FF FF 77 00 00 00 80 63 1A 51 DA (ECU response)
  //1A = 26 = overall length
  //72 07 72 D1 00 06 3E (Speed)
  //02 0C 72 D1 00 03 00 00 00 00 00 AC (ECU response)


  /*
    This protocol is very similar to Honda PGMFI (car ECU)

    request : 72 07 72 11 00 14 F0
    72 : Cmd
    07 : frame length
    72 : Sender ID 1 (?)
    11 : Sender ID 2 (?)
    00 : start number of data to be read in RAM
    14 : end number of data to be read
    F0 : CheckSum

    reply : 02 1A 72 11 00 00 00 18 00 62 57 EF 10 91 63 FF FF 77 00 00 00 80 63 1A 51 DA
    02 : Cmd & 0F
    1A : frame length
    72 : duplicate Cmd ????
    11 : Receiver ID 1 (?)
    00 : Receiver ID 2 (?)
    00 00 18 00 62 57 EF 10 91 63 FF FF 77 00 00 00 80 63 1A 51 : 14 data
    DA CheckSum
  */

  /*
    72 05 00 F0 99 (Gear indicator request for Init comunication)
    02 04 00 FA (ECU response)

    72 07 72 11 00 14 F0 (Gear indicator request for RPM)
    02 1A 72 11 00 00 00 18 00 62 57 EF 10 91 63 FF FF 77 00 00 00 80 63 1A 51 DA (ECU response)

    72 07 72 D1 00 06 3E (Gear indicator request for Speed)
    02 0C 72 D1 00 03 00 00 00 00 00 AC (ECU response)
  */


  //Slow Init or:
  //k-line low for 70msg. and high for 130msg.

  //ECU Adress/Format ?
  //Overall lenght !
  //SID, ECU Adress ?
  uint8_t reqLen;
  uint8_t req[6];
  uint8_t respLen;

  // Start Communication Wakeup-Message
  req[0] = 0xFE;
  req[1] = 0x04;
  req[2] = 0xFF;
  req[3] = 0xFF;
  reqLen = 4;

  //Send Wakeup-Message without header or something:
  sendRequest(req, reqLen);

  delay(200);
  //No request to excpect

  req[0] = 0x72;
  req[1] = 0x05;
  req[2] = 0x00;
  req[3] = 0xF0;
  req[4] = 0x99;
  reqLen = 5;

  //Send "Initialise" message
  sendRequest(req, reqLen);

  respLen = receiveResponse();
  // Response should be 02 04 00 FA
  if ((ecuBufferIn[0] == 0x02) && (ecuBufferIn[1] == 0x04) && (ecuBufferIn[2] == 0x00)) {
    ECUconnected = true;
    return true;
  }
  // Otherwise, we failed to init.
  //Reset ECUConnected & LED + delay 5 Seconds
  ErrorAppeard(ERROR_StartCom);
  return false;
}

Off course the "sendRequest" & "receiveResponse" functions are just from my current solution. But it should be enough to understand how it should work.
Title: Re: Bike interface OBD
Post by: aster94 on Apr 10, 2019, 11:31 pm
Hi CapFirepants

This would be a good starting point:
to start the connection you should send a 'S' in the serial monitor (opened at 115200) and then you should read "Starting sequence" then hopefully you will see an answer from the ECU!

Code: [Select]

#define debug Serial
#define bike Serial2
#define TX_PIN 17
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
    debug.begin(115200);
}

void loop()
{
    char incomingCommand = 0;
    while (debug.available() > 0)
    {
        incomingCommand = debug.read();
        debug.println("Command: ");
        debug.println(incomingCommand);
    }

    if (incomingCommand == 'S')
    {
        initHonda();
    }

    while (bike.available() > 0)
    {
        char incomingByte = bike.read();    // i am not sure if char is correct, maybe byte is better
        debug.print(incomingByte, HEX);
        debug.print(' ');
    }
}

void initHonda()
{
    debug.println("Starting sequence");
    bike.end();
    pinMode(TX_PIN, OUTPUT);
    delay(10);

    // put K-line low for 70msec
    digitalWrite(TX_PIN, LOW);
    delay(70);

    // put K-line high for 120msec
    digitalWrite(TX_PIN, HIGH);
    delay(120);

    bike.begin(10400);

    // maybe a little delay the serial could be not ready

    bike.write(message0, sizeof(message0)); // the kwp2000 needs 10ms between two bytes, here we are sending them all together
    // No response is expected

    // Wait 200msec
    delay(200);

    bike.write(message1, sizeof(message1)); // same here
    // respond: 02 04 00 FA
    debug.println("Waiting response");
}


note that i changed the tx pin since the serial2 uses the number 17: https://www.arduino.cc/reference/en/language/functions/communication/serial/

as trib already said you the L9637 is completely able to manage 5V! (https://www.st.com/resource/en/datasheet/l9637.pdf)

i made a few comments in the sketch about things i am not sure if they would work

please paste here the output you get!

can't wait for your news :)

edit: i corrected little errors in the sketch
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 13, 2019, 04:40 pm
please paste here the output you get!

can't wait for your news :)

Yes, that should be fine!

Looks like that in my code:
Code: [Select]
//Honda ISO-9141-2
void fastInit9141() {
  Serial.end();
  setKline(LOW);
  delay(70);
  setKline(HIGH);
  delay(120); 
  Serial.start(10400);
}


Hey guys! I was finally able to try out the communication with the ECU just now after having a pretty busy week.
I used aster94's code with some slight modifications - I used serial 1 to communicate and changed the TX pin back to 18. I also used Bytes when recieving the response from the bike. However, I didn't get the expected 02 04 00 FA back, insted see the following output:

Motor on and in neutral
Code: [Select]

16:24:48.473 -> Command: S
16:24:48.473 -> Starting sequence
16:24:48.888 -> Waiting response
16:24:48.888 -> FC 0 FF 0 0


Motor off
Code: [Select]
16:25:05.469 -> Command: S
16:25:05.469 -> Starting sequence
16:25:05.847 -> Waiting response
16:25:05.847 -> F8 0 FF 0 0


The output confuses me a bit. Is the bike using a different protocoll?
Title: Re: Bike interface OBD
Post by: aster94 on Apr 13, 2019, 07:39 pm
I checked the source code of gonzo, and the initialize sequence is not as he described it, it is excatly the opposite!  :smiley-confuse:

see the file ctxobd.py, this is an extrac from there: he put the k line high for 70ms then low for 200ms then send the request
Code: [Select]

TIMEKLOW = 0.070 # Kline is pulled low for this time
TIMEKHIGH = 0.20 # quiet time after low pulse before wakeup
...
pfio.digital_write(KLINEOUT,1)
time.sleep(TIMEKLOW)
pfio.digital_write(KLINEOUT,0)
time.sleep(TIMEKHIGH)


so i rewrote the sketch using these values:

Code: [Select]

#define debug Serial
#define bike Serial1
#define TX_PIN 18
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
  debug.begin(115200);
}

void loop()
{
  char incomingCommand = 0;
  while (debug.available() > 0)
  {
    incomingCommand = debug.read();
    debug.print("\nCommand: ");
    debug.println(incomingCommand);
  }

  if (incomingCommand == 'S')
  {
    initHonda();
  }
  checkResponse();
}

void checkResponse()
{
  while (bike.available() > 0)
  {
    byte incomingByte = bike.read();
    debug.print(incomingByte, HEX);
    debug.print(' ');
  }
}

void initHonda()
{
  debug.println("Starting sequence");
  bike.end();
  digitalWrite(TX_PIN, HIGH); // this is not an error, it has to came before the pinMode
  pinMode(TX_PIN, OUTPUT);
  delay(70);

  digitalWrite(TX_PIN, LOW);
  delay(200);

  bike.begin(10400);

  // maybe a little delay the serial could be not ready, edit: no it is ready

  bike.write(message0, sizeof(message0)); // the kwp2000 needs 10ms between two bytes, here we are sending them all together
  bike.flush(); // wait to send all
  // No response is expected

  // wait 200ms and avoid echo
  debug.print("Echo: ");
  uint32_t start_time = millis();
  while (start_time + 200 > millis())
  {
    checkResponse();
  }

  bike.write(message1, sizeof(message1)); // same here
  // respond: 02 04 00 FA
  debug.println("\nWaiting response");
}


and I checked it with the logic analyzer, it is exactly as expected, see the attachments

anyway if you found more resources on the honda protocol send them because the gonzo website doesn't look very reliable anymore
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 13, 2019, 08:57 pm
Hey, thanks for the info regarding the pull up / down times.
I tried the new version of the sketch and got these outputs:

With motor on
Code: [Select]
20:50:06.546 -> Command: S
20:50:06.546 ->
20:50:06.546 -> Starting sequence
20:50:06.819 -> Echo: F0 0 FF
20:50:07.026 -> Waiting response
20:50:07.026 -> 0 0  


With motor off
Code: [Select]
20:50:21.833 -> Command:
20:50:21.833 ->
20:50:21.833 -> Starting sequence
20:50:22.108 -> Echo: F0 0 E1
20:50:22.315 -> Waiting response
20:50:22.315 -> 0 0


Similar to before, it seems to me.

I did find this pgmfi thread which has a bit of the info about the protocol. They have a different message to init the communication, the 02 04 00 FA pops up here as a response as well though: http://forum.pgmfi.org/viewtopic.php?f=57&t=22199&sid=73f41ea0c92683bdda995453fc7f0de2 (http://forum.pgmfi.org/viewtopic.php?f=57&t=22199&sid=73f41ea0c92683bdda995453fc7f0de2)
In this post (http://forum.pgmfi.org/viewtopic.php?f=57&t=22199&start=195#p140461) someone mentions he uses a 2016 CB500X abs, which is nearly the same as mine (The CB500F/X/R all have the same engine but a different body. F is a naked bike, X is a crossover and R a "sports" style bike. Im pretty positive the ECU is also the same.)
Title: Re: Bike interface OBD
Post by: aster94 on Apr 13, 2019, 09:46 pm
i registered and saw the first page where they say that the init sequence is:
Quote
k-line low for 70msg. and high for 130msg.
so similar to the values in gonzo description have you saw the other pages and could you confirm these?

I wrote a new version which waits 10ms between two bytes.
please test this:

Code: [Select]

#define debug Serial
#define bike Serial1
#define TX_PIN 18
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
  debug.begin(115200);
}

void loop()
{
  char incomingCommand = 0;
  while (debug.available() > 0)
  {
    incomingCommand = debug.read();
    debug.print("\nCommand: ");
    debug.println(incomingCommand);
  }

  if (incomingCommand == 'S')
  {
    initHonda();
  }
  checkResponse();
}

void checkResponse()
{
  while (bike.available() > 0)
  {
    byte incomingByte = bike.read();
    debug.print(incomingByte, HEX);
    debug.print(' ');
  }
}

void initHonda()
{
  debug.println("Starting sequence");
  bike.end();
  digitalWrite(TX_PIN, HIGH); // this is not an error, it has to came before the pinMode
  pinMode(TX_PIN, OUTPUT);
  delay(70);

  digitalWrite(TX_PIN, LOW);
  delay(200);

  bike.begin(10400);

  sendRequest(message0, sizeof(message0));
  // No response is expected

  // wait 200ms and avoid echo
  debug.print("Echo: ");
  uint32_t start_time = millis();
  while (start_time + 200 > millis())
  {
    checkResponse();
  }

  sendRequest(message1, sizeof(message1));
  // respond: 02 04 00 FA
  debug.println("\nWaiting response");
}

void sendRequest(uint8_t request[], uint8_t len)
{
  for (uint8_t i = 0; i < len; i++)
  {
    bike.write(request[i]);
    
    bike.flush(); // wait to send all
    if (i < len - 1)
    {
      delay(10);
    }
  }
}


if this doesn't work:

Code: [Select]

#define debug Serial
#define bike Serial1
#define TX_PIN 18
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
  debug.begin(115200);
}

void loop()
{
  char incomingCommand = 0;
  while (debug.available() > 0)
  {
    incomingCommand = debug.read();
    debug.print("\nCommand: ");
    debug.println(incomingCommand);
  }

  if (incomingCommand == 'S')
  {
    initHonda();
  }
  checkResponse();
}

void checkResponse()
{
  while (bike.available() > 0)
  {
    byte incomingByte = bike.read();
    debug.print(incomingByte, HEX);
    debug.print(' ');
  }
}

void initHonda()
{
  debug.println("Starting sequence");
  bike.end();
  pinMode(TX_PIN, OUTPUT);

  digitalWrite(TX_PIN, LOW);
  delay(70);

  digitalWrite(TX_PIN, HIGH);
  delay(130);

  bike.begin(10400);

  sendRequest(message0, sizeof(message0));
  // No response is expected

  // wait 200ms and avoid echo
  debug.print("Echo: ");
  uint32_t start_time = millis();
  while (start_time + 200 > millis())
  {
    checkResponse();
  }

  sendRequest(message1, sizeof(message1));
  // respond: 02 04 00 FA
  debug.println("\nWaiting response");
}

void sendRequest(uint8_t request[], uint8_t len)
{
  for (uint8_t i = 0; i < len; i++)
  {
    bike.write(request[i]);
    
    bike.flush(); // wait to send all
    if (i < len - 1)
    {
      delay(10);
    }
  }
}


You can check the logic analizer output with this program https://www.saleae.com/downloads/
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 13, 2019, 10:10 pm
I ran both sketches and always got this response:
Code: [Select]
21:58:53.815 -> Command: S
21:58:53.815 ->
21:58:53.815 -> Starting sequence
21:58:54.125 -> Echo: F0 0
21:58:54.367 -> Waiting response
21:58:54.367 -> 0 0 0 C0 0


Sadly my logic analyzer hasn't arrived yet.

I've also found this:
https://github.com/MCU-Innovations/HondaECU (https://github.com/MCU-Innovations/HondaECU)
It has the CB500R listed in the table which is 90% the same bike.
Also https://bitbucket.org/enly1/hondagearindicator/overview (https://bitbucket.org/enly1/hondagearindicator/overview) which is for a 1000RR and also uses the same init as gonzo.
Thoughts?
Title: Re: Bike interface OBD
Post by: aster94 on Apr 13, 2019, 10:33 pm
seems that the delay of 10ms between two bytes is not needed

Code: [Select]
#define debug Serial
#define bike Serial1
#define TX_PIN 18
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
  debug.begin(115200);
}

void loop()
{
  char incomingCommand = 0;
  while (debug.available() > 0)
  {
    incomingCommand = debug.read();
    debug.print("\nCommand: ");
    debug.println(incomingCommand);
  }

  if (incomingCommand == 'S')
  {
    initHonda();
  }
  checkResponse();
}

void checkResponse()
{
  while (bike.available() > 0)
  {
    byte incomingByte = bike.read();
    debug.print(incomingByte, HEX);
    debug.print(' ');
  }
}

void initHonda()
{
  debug.println("Starting sequence");
  bike.end();
  pinMode(TX_PIN, OUTPUT);

  digitalWrite(TX_PIN, LOW);
  delay(70);

  digitalWrite(TX_PIN, HIGH);
  delay(120);

  bike.begin(10400);

  sendRequest(message0, sizeof(message0));
  // No response is expected

  // wait 25ms and avoid echo
  debug.print("Echo: ");
  uint32_t start_time = millis();
  while (start_time + 25 > millis())
  {
    checkResponse();
  }

  sendRequest(message1, sizeof(message1));
  // respond: 02 04 00 FA
  debug.println("\nWaiting response");
}

void sendRequest(uint8_t request[], uint8_t len)
{
  for (uint8_t i = 0; i < len; i++)
  {
    bike.write(request[i]);
  }
  bike.flush(); // wait to send all
}


if this doesn't work the problem is in the wiring, please could you post some pictures and a schematics?
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 14, 2019, 09:19 am
seems that the delay of 10ms between two bytes is not needed

Code: [Select]
#define debug Serial
#define bike Serial1
#define TX_PIN 18
byte message0[] = {0xFE, 0x04, 0xFF, 0xFF};
byte message1[] = {0x72, 0x05, 0x00, 0xF0, 0x99};

void setup()
{
  debug.begin(115200);
}

void loop()
{
  char incomingCommand = 0;
  while (debug.available() > 0)
  {
    incomingCommand = debug.read();
    debug.print("\nCommand: ");
    debug.println(incomingCommand);
  }

  if (incomingCommand == 'S')
  {
    initHonda();
  }
  checkResponse();
}

void checkResponse()
{
  while (bike.available() > 0)
  {
    byte incomingByte = bike.read();
    debug.print(incomingByte, HEX);
    debug.print(' ');
  }
}

void initHonda()
{
  debug.println("Starting sequence");
  bike.end();
  pinMode(TX_PIN, OUTPUT);

  digitalWrite(TX_PIN, LOW);
  delay(70);

  digitalWrite(TX_PIN, HIGH);
  delay(120);

  bike.begin(10400);

  sendRequest(message0, sizeof(message0));
  // No response is expected

  // wait 25ms and avoid echo
  debug.print("Echo: ");
  uint32_t start_time = millis();
  while (start_time + 25 > millis())
  {
    checkResponse();
  }

  sendRequest(message1, sizeof(message1));
  // respond: 02 04 00 FA
  debug.println("\nWaiting response");
}

void sendRequest(uint8_t request[], uint8_t len)
{
  for (uint8_t i = 0; i < len; i++)
  {
    bike.write(request[i]);
  }
  bike.flush(); // wait to send all
}


if this doesn't work the problem is in the wiring, please could you post some pictures and a schematics?
No Luck. I got the same response as before:
Code: [Select]
09:11:34.417 -> Command: S
09:11:34.417 ->
09:11:34.417 -> Starting sequence
09:11:34.619 -> Echo: F8 0 FF
09:11:34.653 -> Waiting response
09:11:34.653 -> 0 0


Here's an album with pictures:
https://imgur.com/a/sWckoxa (https://imgur.com/a/sWckoxa)
Let me know if I can clarify anything with more pics.
Title: Re: Bike interface OBD
Post by: aster94 on Apr 14, 2019, 12:33 pm
Seems to be correct, a few question just to be sure:
The ground of the arduino board and the motorbike are connected?
The arduino tx go to the L9636 tx? (them don t have to be swapped)
Are you sure the L9636 is in the right position? The position of pin 1 is decided by this little line
https://postimg.cc/bd7471rj

If all of this are correct we should wait for the logic analyzer and then put a voltage divide to the k-line and check it

By the way in the future I suggest you to use adapters like these for the not-DIP packages, i bought a few of these with various size and them are perfect
https://images.app.goo.gl/FDRybwevtFbtuHGN6
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 14, 2019, 09:13 pm
Seems to be correct, a few question just to be sure:
The ground of the arduino board and the motorbike are connected?
The arduino tx go to the L9636 tx? (them don t have to be swapped)
Are you sure the L9636 is in the right position? The position of pin 1 is decided by this little line
https://postimg.cc/bd7471rj

If all of this are correct we should wait for the logic analyzer and then put a voltage divide to the k-line and check it

By the way in the future I suggest you to use adapters like these for the not-DIP packages, i bought a few of these with various size and them are perfect
https://images.app.goo.gl/FDRybwevtFbtuHGN6
Thanks for your reply.
The ground of the motorbike is connected to the second black cable seen here (yellow arrows) https://imgur.com/2AZnaCC.
I checked the TX and RX, they are not swapped.
I'm 99% positive the L9637D is in the correct position - It's not a L9636 chip though, it's the 9637D. Do you think this is a problem? I think this chip was recommended to me elsewhere.
I've already ordered some SOIC to DIP boards from Aliexpress, I hope they will arrive soon (along with the logic analyzer). Im pretty positive this should work. Thanks a lot for your help so far!
Title: Re: Bike interface OBD
Post by: aster94 on Apr 14, 2019, 11:36 pm
Quote
It's not a L9636 chip though, it's the 9637D.
it is the same! i didn't wrote the last "D"


Quote
Im pretty positive this should work
Me too  :)
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 21, 2019, 07:00 pm
it is the same! i didn't wrote the last "D"

Me too  :)
Alright - the logic level analyzer has arrived! Still waiting on the SOIC to DIP converters though.
Is there something I can already do now that I have the analyzer?
Title: Re: Bike interface OBD
Post by: aster94 on Apr 22, 2019, 11:36 am
better to wait, meanwhile you could see the schematics here (https://github.com/aster94/Keyword-Protocol-2000/raw/master/extras/Images/l9637_wiring.png?raw=true) and you should start to find the resisors for the voltage divider to check the k-line (12-14V) with the logic analyzer (max 5V) some value like 10k and 5k would works well
Title: Re: Bike interface OBD
Post by: CapFirepants on Apr 22, 2019, 12:34 pm
better to wait, meanwhile you could see the schematics here (https://github.com/aster94/Keyword-Protocol-2000/raw/master/extras/Images/l9637_wiring.png?raw=true) and you should start to find the resisors for the voltage divider to check the k-line (12-14V) with the logic analyzer (max 5V) some value like 10k and 5k would works well
I used 10k and 20k - the curiosity just got the better of me and I hooked up the logic analyzer to the bike.
I've attatched the whole analyzer file to the post (used Pulseview), but here is an overview of the interesting parts.
D0 is TX
D1 is RX
D2 is KLine with voltage divider. high was around 4.2 volts.
(https://i.imgur.com/NcALj98.png)
Pulling K-Line low works well (echo on RX).

Pulling K-Line high after ~70ms
(https://i.imgur.com/KMsfGb3.png)

After waiting ~120ms, the sending happens. I think this is where everything is somehow effed:
(https://i.imgur.com/9wZhWM9.png)
For some reason, it doesn't get to send the second FF. It should be sending "FE 04 FF FF", but the second FF gets cut off? It also echos F8 FF back right away for some reason. The K-Link also stays low for a long time during sending the 04, and looks like it doesn't react to the sent signals?

(https://i.imgur.com/Vzgv8Km.png)
Here, it should be sending "72 05 00  F0 99" but it looks like it's sending "78" as the first byte. Maybe the serial isn't ready yet? At other points in time I also got things like "72 02 00 F0 99" and other strange responses.  

I assume this confirms that we just need to wait for the SOIC to DIP adapter and that's fine, just wanted to share because I feel this confirms something wrong with my setup.
Title: Re: Bike interface OBD
Post by: aster94 on Apr 23, 2019, 02:41 pm
yes CapFirepants I confirm your thought, there is something not right, it looks like that the kline takes more time than needed to come back to HIGH

in the next days I would write a new sketch then I would suggest two other test:
1) run it without L9637D connecting the logic analyzer (LA) only to the tx and rx pin of the arduino board
2) run it with the L9637D but without motorbike (you would need to feed the L9637D VS pin [number 7] with 12v) and with the LA check tx, rx and k-line [pin 6]

then if everything is as expected we could move to the motorbike

I am suggesting these two test because i would like to be sure of the seput before getting to talk with the ECU. I know that this means more work, are you interested anyway in the project?
Title: Re: Bike interface OBD
Post by: Earendil86 on Apr 25, 2019, 07:19 pm
Hello,

I've read both this thread and the thread started by TriB on the KDS system and I have some questions and ultimately am hoping to determine if what I want is possible, followed by some next steps as I'm sure this will be a journey! First I'll list my bike and current hardware, a bit about myself, then what I want to accomplish followed by what I interpret as being already solved and then a required hardware list. Finally I'll get into a summary of my questions.

Bike and Hardware:

Bike: 2013 Suzuki GSX-R1000
OBD Reader: OBDLink MX - reads ISO 14230-4 KWP (5 baud init, 10.4 kbaud) and ISO14230-4 KWP (fast init, 10.4 kbaud) (at least in the Android app that it comes with OBDLink)
Android App for Track: RaceChrono Pro
Camera: GoPro Hero5

My skills:

A little about myself - I'm a mechanical engineer with a love for electronics and motorcycles, however have yet to use an Arduino. I'm sure I can pick it up pretty quick as I've done a variety of programming in the past and always learned fairly quickly. As for OBD, I worked with Vehicle information a few years ago and analyzed lots of the data logged from OBD readers but always had the calculations performed by the program and didn't have to program and of the requests myself.

What I want to accomplish:

I would like to create an adapter/unit that takes the k-line data, and processes it for the OBD reader that I have (OBDLink MX) which then would hopefully be able to transmit the data to RaceChrono Pro for overlaying onto my track videos. RaceChrono Pro interacts with the GoPro, external GPS sensors and OBD readers and allows quick and easy video exporting which is why I want to use it.

That being said, as long as it "fakes" the data such that an app like Torque can connect to it and read it like an OBD ELM then maybe it would work fine. The RaceChrono app can connect to any OBD ELM reader. So maybe I need to stick with existing solutions rather than trying to use the OBDLink MX. My only issue is that TriB's solution has Bluetooth but is KDS and O5i's is SDS but not Bluetooth.

So what I would like to do is create something similar to what TriB did for the KDS that will output the proper OBD required information to obtain SPEED, RPM, gear position and maybe a few more PIDS such as Oil temp, and coolant temp.

What I believe is solved:


TriB: KDS (Kawasaki) version on GitHub completed, working on an SDS version for Suzuki
O5i: Completed solution for SDS but not bluetooth

What hardware I need:

I'm honestly open to anything at this point as I do not currently own an Arduino so basically let me know which version is the best to get and I'll go forward with that. I would assume that TriB's hardware is probably what I need but if there is a better version please let me know:

Arduino Nano
HC-06 Bluetooth
L9637D
Ceramic-Capacitor 10 nF 50 V/DC
510Ohm Resistor

Questions:

1)   Is it possible to get the data to communicate via my OBDLink MX? Or would I be better off going with something similar to TriB's approach?
a.   Since my OBDLink MX has the K-2000 protocol does that help or simplify anything?

2)   What would be my first step after buying the parts and assembling the circuit?
3)   ECU Sniffing. Do I need to do this or would the results be the same as what you guys have already discovered? If I need to do it I would probably follow TriB's Sniffer from Github - Does that work for Suzuki's?
a.   Aster94 (post 69&71) on TriB's thread has some GSX-R600 2011 pids which I assume would line up to my 2013 GSX-R1000. That being said, I know they can differ greatly from my work experience so I should probably run the sniffer…
4)   TriB - How far did you get with your SDS version? If I can't use the OBDLink MX then I think yours is exactly what I want to do.

I just spend 3 hours reading the forum posts (and hours before on another night). If I'm not being clear or I'm out to lunch please just let me know!

Thanks,
Title: Re: Bike interface OBD
Post by: TriB on Apr 26, 2019, 02:11 am
Hello Earendil86,

nice to see that you are full into the topic and trying to get an overview rather then just asking stuff :)

First things first:
My current solution (not yet published) is capable of both, KDS and SDS. But some things are not working properly. I hope I can fix that next week on a 4 day racetrack vacation :D

If you go for that hardware design, you can easily convert the values and send them in OBD2 format.

But you can also use the OBDLink MX!
You just have to connect the K-Line, GND and V+. Then you need to reprogram the device via AT Commands, to make it SDS compatible.
Racechrono has a setup for that, where you can enter this commands (https://ecuhacking.activeboard.com/t22573776/sds-protocol/?page=5), and then will be sent to the OBDLink on startup.

Lucky you, I am in a personal conversaton with Antti from racechrono and sent him some testdata, so he can include a conversion interface to make it possible to translate the single dataset from Suzuki into several values.
This will take some time to be included in the next version and I´ll create more data to play around with, next week.

So, I´d reccommend to just create a cable adapter and try that approach first!
I cant, because I only own a cheap china clone ELM327 OBD2 Adapter, which is not capable of being reprogrammed and I think the K-Line is missing.

(https://s16.directupload.net/images/190426/4bgllww6.jpg) (https://www.directupload.net)
Title: Re: Bike interface OBD
Post by: Earendil86 on Apr 27, 2019, 11:47 pm
Hey TriB,

Thanks so much for your response! Glad to hear that you're still working on your KDS and SDS solution. It's pretty awesome what you've been able to accomplish. I'm very jealous of your 4 day racetrack vacation! Stay safe!

As for the hardware vs OBDLink, since there is an option to enter the commands and reprogram the device in OBDLink on startup I'll test that out! I had found that page long ago but didn't realize I could use that in the app.

I would like to run my understanding of it by you though.

I assume these are the commands you were linking to:

>ATZ
ELM327 v1.5
>ATWM8012F1013E  (set a special keep alive message)
OK
>ATSH8112F1  (set a header for first negotiaton)
OK
>ATFI  (initialize bus)
BUS INIT: OK
>ATSH8012F1  (set a header for data transaction)
OK
>1A9A   (Read ECU ID)
5A 9A 33 32 39 32 30 2D 30 .....
>2108   (Read Data by Local ID)
61 08 0F 02 01 A0 02 02 A0 .....
>82  (Close a connection)
C2
>ATPC  (ELM Protocl Close)
OK

If that's the case then in RaceChrono Pro I checked and it appears that this goes in the "expert settings" menu under "Initialisation commands" which states, "Enter additional ELM327 initialisation AT commands here, separated by \n. Example: ATSP4\nATIIA13\nATIB96\ATSH8113f1\nATSW00\nATAT2"

Based on that, I assume the text that I would enter would be:

ATZ\nATWM8012F1013E\nATSH8112F1\nATFI\nATSH8012F1\n1A9A\n2108\n82\nATPC

Or do I not need to enter anything after "Set a header for data transaction"? The next few lines are "Read ECU ID" and "Read Data by Local ID" followed by "Close a connection" and "ELM Protocl Close".
So if not, then I guess this is what I would enter?

ATZ\nATWM8012F1013E\nATSH8112F1\nATFI\nATSH8012F1

Also, once that is entered and I've built the cable and connected the OBDLink MX and started RaceChrono what will it give me vs what Antti and you are working on for this "Conversion interface?".

As an extra note:

For anyone who might be reading, the link in TriB's post to the data discussed above then links to a posters (kashima's) schematic for the Suzuki SDS to OBD cable. That image INCORECTLY lists:

SDS MALE SUMITOMO SEALED MT 090 6P #6189-6171 (Male connector)

The actual Suzuki connector to buy is:

SDS MALE SUMITOMO SEALED MT 090 6P #6187-6561 (Male connector)

This is true for at least my bike. I have not yet received the replacement but I can confirm the first one is incorrect.
Title: Re: Bike interface OBD
Post by: TriB on Apr 30, 2019, 10:40 am
You´re welcome :)

The "Initialisation commands" should be
Code: [Select]
ATWM8012F1013E\nATSH8112F1\nATFI\nATSH8012F1

Anything else is just additional information.

Now, the part is missing, where you can enter a custom PID (0x08) and translate the response to single values, like RPM, speed, etc.
This will definitely be a new feature, but I cannot tell you when this will be published in racechrono.

Until then, you can use a Laptop or a Smartphone to play around with it. Take a Bluetooth Terminal application and send the above values to your bike.
After initialization, you can transfer 21 08 to your bike and it should respond with 51 values of data at once.

Good luck :)
Title: Re: Bike interface OBD
Post by: richardtheboffin on May 02, 2019, 03:30 pm
Just found this thread!

I'm doing this for Marelli Magnetti 15M ECU as used on Ducati and Guzzi in the late 90's.

Just looking at different displays. Small OLED or larger TFT or maybe old school matrix LCD.

The ECU has limited data available on the K/L interface, so I have GPS for speed and am looking at directly measuring injector pulses to get fuel consumption.

Will post a few pics of my birds nest...
Title: Re: Bike interface OBD
Post by: Earendil86 on May 02, 2019, 04:58 pm
Thanks for the response again TriB!

I'm waiting on the connectors to arrive from China. It will probably be a month or two more before I make my cable since the first connectors were incorrect. Since I have a late start to my season this year (Aug) I'm not in a huge rush to start. As soon as I get the connector though I'll give it a test!

Thanks again.
Title: Re: Bike interface OBD
Post by: Bullone on May 03, 2019, 11:11 am
Hey guys, I'm working on acquiring RPM, TPS and ECT from my Yamaha 2019 bike (MT09/Tracer):
on the bike there is a DLC connector where I'm get connected on the CAN bus with MCP2515 module... I can read lot of CAN messages but since it support also the OBDII protocol I'm asking for the OBD PIDs and now I can succesfully get RPM and ECT (the value match the dashboard!) but I'm not sure about the TPS:
my bike has the ride by wire and I'd like to read the real TPS not the throttle/handle position because if I open full throttle the ride by wire may not open fully the "real throttle"... hope make sense for you.
In short: I'm asking the ODB PID 0x11 for Throttle position as described also in Wikipedia but I'm getting 14% value with throttle fully closed and aroound 28% at fully open (engine off). If I start the engine I'm getting 14% at idle and if I lightly open the throttle it get incresed but can't test at full gas...
The formula I use is simply : float tps = (100.0 / 255.0) * rxBuf[3];

Can you help me understand? I was expected 0% at least at fully closed
Title: Re: Bike interface OBD
Post by: TriB on May 09, 2019, 01:04 pm
Hi Bullone,

that indeed is a bit strange. The TPS mostly means the angle from the throttle valve, not the gas!
So it is right, that it is opened a bit on idle. But it must exceed 28% on full throttle.
Or the ride by wire does not change the valve, when the bike does not run?!?

Nice to see, that you have RPM and stuff already working :)
Title: Re: Bike interface OBD
Post by: Bullone on May 09, 2019, 02:09 pm
Yes it is strange but maybe the TPS is limited by the ride by wire maps on the ECU while not in gear and a very low RPM.... I have to test it on the road logging the value.

I'll let you know
Title: Re: Bike interface OBD
Post by: sabsteef on May 30, 2019, 10:25 pm
Hi,
I just got started with this library.
I got a vfr 1200 and want to create a new cockpit.

I've order the additional component. And started with the emulator on a pi 3. But I can't get it to work with the latest version of python.

It doesn't handle request.clear()
Can you help out with a new version?

Tnx,
Steef
Title: Re: Bike interface OBD
Post by: sudolea on Jun 03, 2019, 10:28 am
(Sorry, this post should have come in another thread on this forum)
Title: Re: Bike interface OBD
Post by: Earendil86 on Aug 02, 2019, 04:30 pm
Hey!

I finally got the OBDII port hooked up to my bike and want to test the 21 08 command that TriB mentioned in post 190. I am hoping for some assistance so that when I go to try i'm not stuck researching for hours to get it to work.

Initialization command (Post 190): ATWM8012F1013E\nATSH8112F1\nATFI\nATSH8012F1

Bluetooth Terminal App:

"Bluetooth Terminal" by Qwerty

My questions:

1) do I initialize through RaceChrono App and then use a bluetooth terminal to send the 21 08 command? Or do I send the Initialisation command directly through the bluetooth terminal application?

2) To send the 21 08 command what is the exact numbers that I have to type in the command prompt?

Thanks,
Title: Re: Bike interface OBD
Post by: TriB on Aug 02, 2019, 11:19 pm
If you want to configure RaceChrono to make it work, take a look at Anttis Forum:
RaceChrono/Forum/BikeOBD (http://racechrono.com/forum/discussion/1724/newbie-question-regarding-bike-obd)
There you will find all you need  8)
Title: Re: Bike interface OBD
Post by: swellracing on Sep 09, 2019, 03:53 am
Hey guys would this work on Yamaha? I sniffed some communication lines from the YDS scan tool and I cant seem to understand the protocol and format. See below

Line 1: Initializing ECU
FD 00 E5 ED E5 ED FE 10 FF 15 FE 10 FF 15

Line 2: Sensor Data Log
00 00 01 00 02 06 03 57 12 00 13 00 0A 00 0B 00 14 00 15 00 16 00 17 00 20 00 21 00 04 03 05 00 06 FF 07 FF 08 02 09 99 0E 00 0F 00 42 FF 41 F2 26 00 27 27 30 04 31 02 32 50 34 02 37 80

These 2 lines keep repeating over and over.

I dont know if any of this makes sense. But I need to figure out what is the Transmit command so I can get a reply from ECU

Thanks
Title: Re: Bike interface OBD
Post by: TriB on Sep 09, 2019, 10:15 am
Hello swellracing,

as far as I know, Yamaha does not work with a header. And I cannot see any kind of format with known SID and PID values, which Suzuki and Kawasaki are using.
So it is not a proper KWP2000 or ISO14230 protocol.

If both lines are getting repeated over and over, it seems to be a keepalive-value rather then a real message.

So to guess what this values means, we need:


Then move on to the next value like speed, temperature, pressure, etc.
Or reading diagnostic information.
Title: Re: Bike interface OBD
Post by: Dragondude on Sep 13, 2019, 12:19 am
Hi Guys,

I have had a quick read of this thread and it seems to be olong the lines of what I am chasing.

Firstly, I am just getting into this Arduino thingy so be gentle.

I have a Suzuki VZ1800, the tacho has crapped itself so I want to do a bit of a custom job with fancy effects on a colour disply. You guys have managed to play with the OBD code from the ECU, what I am specifically looking for is the data stream from the ECU to the tacho. I know what wire it is on and I have captured a couple of minutes of data with a logic analyser but it is all Greek to me. Where do I start? How do I pul apart this data? I am assuming there will be some sort of start byte. How would I recogonise it?

Would it be possible for one of the GSX owners be able to have a play and detemine what I am looking for or at least direct me in the right direction.

Thanks
Title: Re: Bike interface OBD
Post by: TriB on Sep 13, 2019, 09:14 am
Hi Dragondude,

it is possible to grab the cable from the ECU to the tachometer. There are several different approaches. It can be controlled by raising voltage on older bikes. But also by some kind of a bus-like system.
There are plenty of aftermarked speedometer, which also can show the milage and stuff.

This thread covers the diagnostic interface, only. Which will not cover what you want.

Me personally does not know enough about the communication between the ECU and tachometer-unit.
Title: Re: Bike interface OBD
Post by: Dragondude on Sep 19, 2019, 12:03 am
Thank TriB, I will keep slaving on with it. As far as buying a speedo it sort of defeats the purpose. My brain will cease up if it doesn't get used.
Title: Re: Bike interface OBD
Post by: TriB on Oct 09, 2019, 11:57 pm
Hello Guys,

I currently got a diagnostic interface borrowed and will sniff what it will exchange.

My approach will be to sniff the commands, which will be sent from the software to the bike for


Most of it is already known. But not everything and some PID´s are still unknown or the calculations are wrong.
So:


On top of that, I found several pieces of software which partially were open source or easily extracted  :smiley-roll: They even could set some values like speed limits, gear restriction, max RPM or write whole maps.
Nothing I´d do, but interesting to know.

It seems that this adapter is also capable of my Kawasaki. I´ll check that afterwards and go on with the same approaches, then.

Hopefully I can figure some things out, we currently do not know and make my Sketch more stable with this findings.
Title: Re: Bike interface OBD
Post by: TriB on Oct 12, 2019, 11:00 am
A small update about my current findings.
They are nothing totally new, but maybe give you some insights.

First of all: RPM
I was sure, it is easily calculated (A * 255 + B) * 2 but that not seem to be correct!
The right equation should be: (A * 255 + B) / 255 * 100.
This will explain my RPM drop over 14.000.

Manifold Pressure: A * 166.7 / 255 - 20 => kPa
Engine Coolant: A * 160 / 255 - 30 => °C

DTC works like that:
>>80 12 F1 04 18 00 00 00 9F
<<80 F1 12 0E 58 04 03 51 A0 03 53 A0 03 54 A0 16 55 A0 D9

You all know the header, so I will not deepdive into that!
04 Number of Errors
03 51 P0351 Ignition coil A circuit malfunction
03 53 P0353 Ignition coil C circuit malfunction
03 54 P0354 Ignition coil D circuit malfunction
16 55 P1655 Secondary throttle motor circuit malfunction
A0 Seperator

Now you have like 2 * 5 error storages:
80 12 F1 02 21 40 E6 -> 80 12 F1 02 21 45 EB
80 12 F1 02 21 50 F6 ->  80 12 F1 02 21 55 FB
This five "4X" requests give me values from the P1655 message. All equal.
The "5X" requests gives me slightly different values, because the malfunction appeard during a started engine. So it will give you some data, when the error happened:
80 F1 12 12 61 50 03 53 A0 FF 4A BD 62 AD B8 03 8F
03 53 Trouble Code P0353 All the same, not 0351 or 0354  ::)
A0 FF Placeholder, Space, idk. Equal on any message
4A BD RPM (74 * 255 + 189) 19133 / 255 * 100 = 7.503
62 Throttle Pos 98 / 255 * 100 = 38% || 98 / 2 = 49° (Not totally sure about the last calculation)
AD Manifold Pressure 173 * 166.7 / 255 - 20 = 93kPa
B8 Engine Coolant (184 * 160 / 255) - 30 = 85° Celsius
03 Gear 3
BF SecThrottle 143 / 255 * 100 = 56%

An open question is how the messages are related to each other. 4 Errors reported and 10 outputs displayed (6 different). And the "P"-Number is different in the 04 18 Message to what the error storage shows.
Sadly the Kawasaki DTC Table sparely fits to SDS. Just have several dozend codes, but not all like I got from Kawa.

Next stop: Activating the Fan, Solenoid and stuff.
Then I´d like to ensure the equations of the data from 21 08 message.

Stay tuned :)
Title: Re: Bike interface OBD
Post by: IgorShobik on Nov 21, 2019, 06:41 pm
Hi all. I carefully read this thread and have been trying to connect to my Kawasaki Versys 1000 2015 motorcycle for three weeks now. None of the existing projects are suitable.
I 100% claim that the diagnostic interface does not have the KWP2000 protocol.There is a very serious suspicion that kawasaki in 2015 made changes to the exchange protocol. Can anyone have any information about this?
Or, maybe someone will respond, who has a kawasaki of 2015 and above, and everything work with KWP2000 - then, maybe my motorcycle has a wiring problem.
Title: Re: Bike interface OBD
Post by: TriB on Nov 24, 2019, 09:22 pm
Hi Igor,

this thread is about Suzuki SDS. Which is also a KWP2000 protocol and close to Kawasaki, but not equal  ::)
Have you tried my code from my thread (https://forum.arduino.cc/index.php?topic=334778.0)?
AFAIK Kawa enhanced the system to OBD2, which is mandatory for EURO4.
But you can still talk to the ECU via KDS (Kawasaki Diagnostic System). Knowing that, I don´t expect it will be different to your Versys.
Do you know which ECU manufacturer your bike has?

Also, afaik it is equal to the Z1000 or Z1000SX, where I know it works with 2015 bikes.

Are you sure the bike has a wiring problem and not your very own schematics? The bikes cable-tree is protected against reverse polarity.
Title: Re: Bike interface OBD
Post by: ivashkoartem on Nov 25, 2019, 01:12 pm
I have z1000 my2012 from USA, in this ECU there is no immobilizer and there is no sensor lambda.

I cannot connect to the ECU via the k-line bus. I use k-line, GND and + 12V from the diagnostic socket. No connection even when using ELM327 and Torque app, but with another z1000 my2017 motorcycle the connection is ok.

Before that I used arduino to connect and the result was negative.

Can you tell me what idea to make a connection?
Title: Re: Bike interface OBD
Post by: IgorShobik on Nov 25, 2019, 04:44 pm
Hi TriB, thanks for the answer. I know that you are a doctor in these matters.
I tried  and your code too - not secess
I dont know ECU manufacturer in my bike. I know about Denso and Mitsubishi ECU manufacturer for Kawasaki.
Theoretically, the protocols may differ, but I do not understand why kawasaki needs this.
Title: Re: Bike interface OBD
Post by: IgorShobik on Nov 25, 2019, 06:24 pm
For information.
There is a suspicion, that the motorcycle protocols for the European and American markets are different. Everything is ok with European motorcycles - there is a problem with American motorcycles - now we will check the version with K and L line for connect.
Title: Re: Bike interface OBD
Post by: TriB on Nov 25, 2019, 09:22 pm
I have z1000 my2012 from USA, in this ECU there is no immobilizer and there is no sensor lambda.

I cannot connect to the ECU via the k-line bus. I use k-line, GND and + 12V from the diagnostic socket. No connection even when using ELM327 and Torque app, but with another z1000 my2017 motorcycle the connection is ok.

Before that I used arduino to connect and the result was negative.

Can you tell me what idea to make a connection?
Almost 110% of all ELM327 adapters are chinese clones and do not support proper programming (like setting the custom header, keepalive-message or initialization), nor do they support the K-Line properly.

My personal rule of thumb is: Below 50 bucks (€ or $) it´s a clone and will not work with motorbikes.
Purchasing a L9637D, some resitors and stuff will cost you 5 bucks and you will find out!

PS: My 2012 Z750r has the immobilizer but no lambda as well.
Title: Re: Bike interface OBD
Post by: ivashkoartem on Nov 25, 2019, 11:07 pm
Sorry, but I have only elm327 from aliexpress. This elm327 connect to bike my friend without trouble (z1000 my2010, but ecu z1000sx 2015+), my bike doesn't connect.

I am 100% sure in the elm327 device that it works with kawasaki using the iso14230 protocol.

I have arduino leonardo and L9637d, I could not connect to the ECU my bike.

If  use l-line additionally, there is also no result.

I don't understand which device to check the operation of k-line, except elm327
Title: Re: Bike interface OBD
Post by: Earendil86 on Feb 20, 2020, 03:47 pm
Hello! I'm back. I'm about a year delayed from where I wanted to be on this project. But here goes.

I finally managed to find the time to make my Suzuki SDS to OBD connector and install in permanently on my bike for easy access at the track. I downloaded a bluetooth terminal and sent the commands and at first I didn't get responses. Then, following another forum from Racechrono, I added a line and it worked. My first questions revolves around that extra line because after I entered it, the second time I did the codes I tried without and it worked. Do you only have to set this line once and the ECU remembers it? Or once every time a battery has been disconnected? Here is what I entered the first time:

ATZ (Determines ELM327 Version)
ATWM8012F1013E (set a special keep alive message)
ATSH8112F1 (initialize with 0x81 header)
ATFI (initialize bus. IE: start communication)
ATSH8012F1 (reset header to 0x80)
2108 (Read Data by Local ID)

did not get a response. Added ATSP5 and it worked:

ATZ (Determines ELM327 Version)
ATSP5 (manually setting the protocol to 5)
ATWM8012F1013E (set a special keep alive message)
ATSH8112F1 (initialize with 0x81 header)
ATFI (initialize bus. IE: start communication)
ATSH8012F1 (reset header to 0x80)
2108 (Read Data by Local ID)

Why is this necessary? And again, why did I not need to enter this afterwards after ended communication, switching to a different bluetooth terminal and reentering the first set of commands?

Continuing...

Second question. I tested two conditions with the ignition on but bike off. Throttle off and throttle full open and received the following results:

>2108 (Throttle closed)

61 08 01 17 69 A2 00 00 00 FF FF FF 00 00 00 39
BA 36 38 BB 00 FF 00 FF 7C 35 FF 00 00 00 00 00
00 00 00 FF FF 40 40 40 40 FF FF 00 74 15 30 04
05 28 FF FF

>2108 (Throttle full open)

61 08 01 17 69 A2 00 00 00 FF FF FF 00 00 00 E0
BA 36 38 BB 00 FF 00 FF 7C 35 FF 00 00 00 00 00
00 00 00 FF FF 40 40 40 40 FF FF 00 74 15 30 04
05 28 FF FF

So the top right value is for throttle position. That being said. I have zero idea as to what the rest of the string represents. Does anyone have a link to a site that has already explained each part of the 2108 Suzuki response and linked to what it represents? I did some searching and I can't (quickly) find that so I figured that I would ask to see if anyone has this information. The values that I'm most interested in are:

Speed
RPM
Throttle Position (Have)
Coolant Temp
Gear

But it would be great to at least know which each of those values means.

After that, I need to work on determining how to enter these into Racechrono to pull those values while riding and will continue in the thread that TriB already pointed me to:

https://racechrono.com/forum/discussion/1724/newbie-question-regarding-bike-obd (https://racechrono.com/forum/discussion/1724/newbie-question-regarding-bike-obd)
Title: Re: Bike interface OBD
Post by: TriB on Feb 24, 2020, 11:37 am
Hi,

that´s quite simple:
Why is this necessary? And again, why did I not need to enter this afterwards after ended communication, switching to a different bluetooth terminal and reentering the first set of commands?
The ELM327 has to determine the (ISO-)protocol on startup. It mostly starts with the most common and if this does not work, the adapter automatically tests all avaliable protocols, one after another.
But due to the init process with 0x80 & 0x81 header, the ELM327 never gets a response. So the automatic-feature does not work on you bike.

Setting the protocol now to 5, will be stored until the EML327 is powered off or resetted.

So the top right value is for throttle position. That being said. I have zero idea as to what the rest of the string represents. Does anyone have a link to a site that has already explained each part of the 2108 Suzuki response and linked to what it represents? I did some searching and I can't (quickly) find that so I figured that I would ask to see if anyone has this information.
You can find the infos here in this thread, on the ECU Hacking board or in osi´s GitHub.
But from my findings, the calculations are not completely correct.

1 Header
2 Dongle
3 ECU
4 Messagesize
5 SID
6 PID
7 No of DTC
8 Freezed Frame 1
9 Freezed Frame 1
10
11 Freezed Frame 2
12 Freezed Frame 2
13
14
15
16
17 Speed
18 RPM A
19 RPM B
20 TPS
21 Intake Air pressure
22 Engine Temp
23 Intake Air Temperature
24 EAP - hPa
25 Batt
26 O2 sensor Bank 1
27 Gear
28 Intake Air Pressure 2
29 Idle Speed
30 Idle Speed Control Valve Position
31
32 High Cylinder 1 injection time (ms)
33 Low
34 High Cylinder 2 injection time (ms)
35 Low
36 High Cylinder 3 injection time (ms)
37 Low
38 High Cylinder 4 injection time (ms)
39 Low
40
41
42
43
44
45
46
47 Sub-Throtle Sensor
48
49
50
51 Cooling Fan Relais
52 Exhaust Control Valve
53 Clutch / Starter Relais
54 Neutral
55
56
57 Checksum

The values from 50 above, are booleans inside of a byte.
The neutral switch, for example is byte 54, the second bit.
Exhaust Control selector is also byte 54, but bit 8.
Title: Re: Bike interface OBD
Post by: Earendil86 on Feb 26, 2020, 10:29 pm
Hello,

I compared your output to mine (and others that I've found through your links) and also compared the output to testing that I did and I believe that the PID assignments are identical if you start looking at 61 as the first byte and removing some others that I don't seem to have (TriB's 13-16). The tests that I did helped me uncover RPM, Speed, Engine coolant temp, Gear and throttle position locations. Then, reviewing your sheet to my results it appears as if they used the same spacing so I've done my best to fill it out below for my bike.

What I'm hoping to do is to clarify the names for each PID as I'm not actually 100% confident that I know the acronym as well as the formula's that people use (with Units) for conversion. I've taken the formulas that I've found from TriB's posts, O5i's GitHub, and Aster's GitHub.

If anyone has the time who has gone through the formula's themselves, I'd appreciate comments when there are multiple formula's as to what your thoughts are.

If you're in a rush and want to help, the main PIDS (and therefore formulas) that I'm concerned with are:

Speed (13), RPM (14/15), Throttle Position (16), Engine Coolant Temp (18)

Ultimately, I'd like to answer all of my questions though for my understanding before proceeding to RaceChrono and starting to enter the custom PIDs.

TriB - what's your process for refining formulas? Trial and error? Or are you able to get these somehow from the bike?

PID # LIST
* means that I have confirmed this PID for my 2013 Suzuki GSXR-1000 through testing

1 - 0x61 - Header (What is this?)
2 - 0x08 - Dongle (What is this?)
3 - 0x01 - ECU
4 - 0x17 - Message Size (What is this?)
5 - 0x69 - SID (What is this?)
6 - 0xA2 - PID (What is this?)
7 - 0x00 - Number of DTC (Diagnostic Trouble Codes)
8 - 0x00 - Freezed Frame 1 Byte 1(Assuming this stores data in two bytes when a DTC is registered?)
9 - 0x00 - Freezed Frame 1 Byte 2
10 - 0xFF - Not Used (or unknown)
11 - 0xFF - Freezed Frame 2 Byte 1
12 - 0xFF - Freezed Frame 2 Byte 2
13* - SPEED

[Aster94] Formula: SPEED = BYTE * 2 (km/h?)
I believe that this is actually just direct conversion to km/h with no formula? TriB?

14* - RPM High Byte (Rotations Per Minute)
15* - RPM Low Byte (Rotations Per Minute)

Formula:
[Aster94] RPM = HIGH BYTE * 10 + LOW BYTE / 10 (Appears incorrect for me)
[O5i] RPM = Value*100/255 (Can't be since only 1 value) (Appears incorrect for me)
[TriB] RPM = (HIGH BYTE * 255 + LOW BYTE) / 255 * 100 (Appears CORRECT for my data)

16* - TPS (Throttle Position Sensor)

Formula: (None of these seem to line up for me as they all show roughly the same %)
[Aster94] TPS = 125 * (BYTE - 55) / (256 - 55) (Unit? %?)
[TriB] Throttle Position % = BYTE / 255 * 100
[TriB] Throttle Position Deg = BYTE / 2
[O5i] Throttle position (°) = Value*125/255


17 - IP / IAP / MP (Intake Air Pressure)

Formula: (All similar results)
[Aster94] IAP = BYTE * 4 * 0.136 (kPa)
[TriB] Manifold Pressure: A * 166.7 / 255 - 20  (kPa)
[O5i] Manifold pressure = (Value*5 - 153)*133/4/255 (kPa)

18 - ECT (Engine Coolant Temperature)

Formula: (Why O5i has two separate formulas?)
[Aster94] ECT = (BYTE - 48) / 1.6 (°C)
[O5i] Temp °C = ( [Hex value] - 48) / 1.6 (°C)

[TriB] Engine Coolant: A * 160 / 255 - 30 => °C
[O5i] Temperature (C) = Value*160/255 - 30
[O5i] Temperature (F) = Value*288/255 - 22

19 - IAT (Intake Air Temperature)

[Aster94] Formula: IAT = (BTYE- 48) / 1.6 (°C)
[O5i] Temp °C = ( [Hex value] - 48) / 1.6 (°C)
[O5i] Temperature (C) = Value*160/255 - 30
[O5i] Temperature (F) = Value*288/255 - 22

20 - EAP/AP (Exhaust Air Pressure???)

[Aster94] Formula: AP = BYTE * 4 * 0.136 (Units??)
[TriB] - hPa (no formula? Just conversion then?)


21 - Batt (Battery Voltage)
Formula:
[Aster94] voltage = BYTE * 100 / 126 (Volts)
[O5i] Voltage = Value*20/255 (I like this one's results)

22 - O2 / H02 (Heated Oxygen Sensor Bank 1)
23* - Gear / GPS (Gear Position Sensor)

Formula: 0x00 = Neutral, 0x01 = Gear 1, 0x02 = Gear 2, 0x03 = Gear 3 etc.

24 - 0xFF - Not Used (or unknown) - TriB - has IAP 2 here
25 - IST (Idle Speed Target)
26 - ISC (Idle Speed Control Valve Position)
27 - 0xFF - Not Used (or unknown)
28 - Fuel Hi 1 (High Cylinder 1 injection time (ms))
29 - Fuel Lo 1 (Low)
30 - Fuel Hi 2 (High Cylinder 2 injection time (ms))
31 - Fuel Lo 2 (Low)
32 - Fuel Hi 3 (High Cylinder 3 injection time (ms))
33 - Fuel Lo 3 (Low)
34 - Fuel Hi 4 (High Cylinder 4 injection time (ms))
35 - Fuel Lo 4 (Low)
36 - 0xFF - Not Used (or unknown)
37 - 0xFF - Not Used (or unknown)
38 - IGN 1 - Ignition 1
39 - IGN 2 - Ignition 2
40 - IGN 3 - Ignition 3
41 - IGN 4 - Ignition 4

Formula: (PIDs: 38-41)
IGN = 0.4 * BYTE - 12.5

42 - 0xFF - Not Used (or unknown)
43 - STP/STPS/STVA (Secondary Throttle Position Sensor/Actuator)

Formula:
[Aster94] STP/STPS/STVA = BYTE * 100 / 255 (Units?)
[TriB] STP = BYTE / 255*100 (%)
[O5i] Secondary throttle position (%) and EXCVA sensor = Value*100/255

44 - ????
45 - ????
46 - ????
47 - CPR (Cooling Fan Relay)
48 - PAIR/ECV (PAIR Valve / Exhaust Control Valve)

[Aster94] Formula = BYTE (units?)

49* - Clutch (Indicates if the clutch is engaged)

Formula: 0x15 = Clutch engaged, 0x05 = Clutch disengaged

50* - Neutral/Gear (Indicates if the bike is in Neutral or Gear)

Formula: 0x28 = Neutral, 0x2A = In gear

51 - 0xFF - Not Used (or unknown)
52 - 0xFF - Not Used (or unknown)

Other formulas

(IAP = AP -IP)???
AFR - Air Fuel Ratio (IAP/ which fuel?)

TriB can you explain this in more detail? Maybe with an example?
The values from 50 above, are booleans inside of a byte.
The neutral switch, for example is byte 54, the second bit.
Exhaust Control selector is also byte 54, but bit 8.
Title: Re: Bike interface OBD
Post by: TriB on Feb 27, 2020, 11:48 am
Hi,

nice that you worked out the comparsion between all the formulas!
What have I done:
Gone to the racetrack and drove faster than ~125km/h and rised the RPM higher then 14.000.
Both leaded to drops (starting from a lower value again). So I started investigating!

On another thread about Kawasaki (https://forum.arduino.cc/index.php?topic=334778.0), I got dozens of conversations with Scissor about the calculations. He got the idea of the base of 256 for all values.
Tested a lot and compared it with the reality.

Last but not least, I got a Healtech SDS Tool and sniffed the data between the adapter and the software.
This finally made me creating a software, which can read the Healtech LOG-files and give me the results due to my calculations.
It is still not 100% right (but I think Healtech smoothen the values, so that you cannot always be sure).

The ECU´s are from the same manufacturer, so a lot is quite equal. But for me it seems that the base for Kawasaki is 256 and for Suzuki 255. Seems like a small difference, but makes huge drops!


I think you drifted on your
Quote
1 - 0x61 - Header (What is this?)
The header is always 0x80 or 0x81 and explains if the message is with length-information (which is only the case on initial protocol).
Dongle - The Receiver. The ID from your Diagnostic Adapter. Helps to see if the message is from you or from the ECU
ECU - Same like above. The Sender
Message Size - The number of the following bytes
SID - Service Identifyer
PID - Parameter Identifyer Just read this (https://en.wikipedia.org/wiki/OBD-II_PIDs) and you will understand anything :)

Freezed Frames - Both numbers leads you to the diagnostic trouble code, like 0105 -> Intake Pressure Sensor Error

Some values are unused or only for different bikes. Like desired RPM, which you can control via SDS, but not on my K6. If you need RPM 4.700, you can set it with a diagnostic command.
Or as you found yourself "Intake/Manifold Air Pressure (IAP)" & "Atmospheric Air Pressure (IAP 2)"

Battery - (A * 20 / 255)
EAP/AP - Exhaust Control Valve (A / 255 * 100)

The byte-thing is easy, if you understand it once!
When you have 0x04, you get this in binary
0000 0100

from right to left you have 128, 64, 32, 16, 8, 4, 2, 1
Bit 16 is uncheckt, so clutch is not pulled.
Bit 32 is the starter relais, which is also not used.

Pulling the clutch and press the starter will give you:
0011 0100
which is 0x34

This also seems to differ between the bikes. The Neutral-Switch on my bike seems to be on a different position.

Hope this helps for a bit of understanding!
Title: Re: Bike interface OBD
Post by: Earendil86 on Feb 29, 2020, 01:14 am
Thanks! That's great.

I'm going to switch to focusing on entering the custom pids now in racechrono. I won't be able to take the bike out for another 2 months for on road testing :(

I'll check back from time to time to see if you've gotten further in your SDS and your formulas TriB!

Title: Re: Bike interface OBD
Post by: junkienl on Mar 13, 2020, 05:48 pm
Hello,

I have been trying to get a response from the ECU of my Kawasaki Vulcan 900 for some time now. Until now without any success. This what I am currently trying:

Hardware

I am using a L9637D chip in a circuit similar to this one:
https://github.com/aster94/Keyword-Protocol-2000 (https://github.com/aster94/Keyword-Protocol-2000)

Which seems to be in accordance with:
https://www.st.com/resource/en/datasheet/l9637.pdf (https://www.st.com/resource/en/datasheet/l9637.pdf)

I added a voltage regulator circuit to power the nano and a (high resistance) voltage divider on the K-line to be able to use the logic analyzer.

This circuit plugs into the 4-pin plug under my seat. There I find power, ground, K-line and an unused pin. I am pretty sure I know which pin is the K-line and which is the unused pin, but just to be sure, I have tried them both.

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350847)

Code

My code is mostly a stripped-down version of:
https://bitbucket.org/tomnz/kawaduino/src/default/ (https://bitbucket.org/tomnz/kawaduino/src/default/)

At the moment I try to keep my code as simple as possible, because my aim for now is just getting any response from the ECU. For the initialization I use a sequence similar to:
https://github.com/HerrRiebmann/KDS2Bluetooth (https://github.com/HerrRiebmann/KDS2Bluetooth)

The KDS2Bluetooth shows it working for a Kawasaki Z750. On Amazon I can find gear indicators that plug directly into the ECU, which are indicated for both this bike and my bike. This makes me believe I should be able to connect to my Vulcan 900 using the same initialization sequence:

This seems to agree with:
http://read.pudn.com/downloads118/ebook/500929/14230-2.pdf (http://read.pudn.com/downloads118/ebook/500929/14230-2.pdf)

Code: [Select]
#define K_OUT 1 // K Output Line - TX (1) on Arduino
#define K_IN 0  // K Input  Line - RX (0) on Arduino
const uint32_t ISORequestByteDelay = 10;
const uint32_t ISORequestDelay = 40; // Time between requests.

void setup() {
  pinMode(K_OUT, OUTPUT);
  pinMode(K_IN, INPUT);
}  
  
void loop(){
  uint8_t buf[5];
  uint8_t bytesToSend;
  uint8_t bytesSent = 0;
  buf[0] = 0x81;
  buf[1] = 0x11;     // ECUaddr
  buf[2] = 0xF1;     // myAddr
  buf[3] = 0x81;
  buf[4] = 0x04;
  bytesToSend = 5;
  digitalWrite(K_OUT, HIGH);
  delay(2000);
  digitalWrite(K_OUT, LOW);
  delay(25);
  digitalWrite(K_OUT, HIGH);
  delay(25);
  Serial.begin(10400);
  for (uint8_t i = 0; i < bytesToSend; i++) {
    bytesSent += Serial.write(buf[i]);
    delay(ISORequestByteDelay);
  }
  delay(500); // enough to get response
  Serial.end();
  delay(5000);
}


Results

As can be seen in the attached images: The K-line is doing something, but there is no response from the ECU.

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350843)

There is also a closeup of the first byte:

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350845)

I am not sure how the signal on the K-line should look. I can see that the 1st and 4th byte on the K-line are similar.

Can someone confirm if this is how this signal should look or that maybe my chip is faulty?

I have already tried different ECU addresses: 0x10 to 0x17. (and changed checksum of course)

Am I overlooking something? What else could I try? Any help is appreciated.
Title: Re: Bike interface OBD
Post by: junkienl on Mar 13, 2020, 11:50 pm
Small update...

I decided to look at the K-line signal on the oscilloscope:

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350913)

After replacing the 100nF capacitor with 10nF it looked like this:

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350915)

That made the difference! I got the correct response from the ECU:

(https://forum.arduino.cc/index.php?action=dlattach;topic=236092.0;attach=350917)

It only works when the motor is not running, so reading rpm is a bit boring for now.
Title: Re: Bike interface OBD
Post by: TriB on Mar 16, 2020, 10:19 am
Hi junkienl,

Nice that you found the issue.
Why does it only work with engine not running?

Due to the fact I cannot see your current code, but see what you wrote about the initialization:

Kawasaki & Suzuki got exactly 3 (more or less big) differences:


What you did right is part 1. But you (might) missed the second:

// Start Communication is a single byte "0x81" packet.
81 11 F1 81 04
// Response should be 3 bytes: 0xC1 0xEA 0x8F
//243 & 143 (Explaines supported Header type: Source, Target, Length & Checksum)
// Success, so send the Start Diag frame
// 2 bytes: 0x10 0x80
80 11 F1 02 10 80 14

The documentations says you can stop the diagnostic session, but in my findings this does not work!
Just quit the communication, like you started it, but with 0x82
81 11 F1 82 05

The Kawasaki will definitely send you all the values with a running engine, then!

PS: Btw, this thread is about Suzuki. The Kawasaki thread is here (https://forum.arduino.cc/index.php?topic=334778.0) :)
Title: Re: Bike interface OBD
Post by: junkienl on Mar 16, 2020, 09:04 pm
Hi TriB,

Thank you for replying. I saw the other thread, but I did not notice the Suzuki/Kawasaki distinction. I just tossed a coin and ended up here... :)

My problem seems to be a power issue. I got some rpm readings, but only after the warm up time when the rpm drops to normal idle. Just after startup the voltage is about 14,5 V. This is the handshake that I witnessed:

TX: 81 11 F2 81 05 - start communication
RX: 80 F2 11 03 C1 EA 8F C0 - accepted
TX: 80 11 F2 02 10 80 15 - start diagnostic
RX: 80 F2 11 02 50 80 55 - accepted

Revving the engine slightly makes the connection fail again. This is what I have tried so far:

1st test: Power the L9637D directly from the diagnostic plug.

2nd test: Power the L9637D through a L7812 voltage regulator. (I don't have a better regulator available. This one has a voltage drop of 1,7 V.)

For both cases:
-Works when engine off.
-Works when engine idling or slightly revving.
-Does not work for revving >2500rpm

I am not sure how to fix this… I will look through the threads and see what others have done.
Title: Re: Bike interface OBD
Post by: TriB on Mar 17, 2020, 10:32 am
The most common issue is in deed, that voltage drops or peaks affect the Arduino.
On my first "design" it happened, that the connection stopped after about 10 Minutes. But it ran for hours, connected to my ECU-Emulator, which simulated the ECU via USB.

But I´m not an electronics pro. A friend of mine did the PCB design. So I cannot really tell you, how to create a reliable power supply  :-[
Title: Re: Bike interface OBD
Post by: uronour on Mar 20, 2020, 07:27 am
I've only skimmed these pages briefly but I was in the middle of doing the ground work for something like this on Kawasaki ninja zx10r 2004
I had previously strayed on an 07 plate that was unfortunately stollen last year...

I had very small success with the 07 but I used a cheap elm odbII adapter, it read commands mad the Bluetooth software actually picked it up briefly, anyway that said.

Would anybody have clear cut instructions of the simplest way to do this? I'm after building my own mini dash and diagnostics, possibly camera overlay data unsure yet, I did build the basic circuit as I said earlier using L9637D but I couldn't get it working, struggled with getting the pins right I couldn't get any read out at all
Title: Re: Bike interface OBD
Post by: TriB on Mar 20, 2020, 11:28 am
Hi uronour,

there is another Kawasaki specific thread (https://forum.arduino.cc/index.php?topic=334778.0).
And this is more specific to transfer OBD compatible data to a camera or something.

Due to the KDS Software you own a ZX10R C1? This is supported for KDS2, which is good 8)
AFAIK you have the same connector (https://github.com/HerrRiebmann/KDS2Bluetooth/tree/master/Documentation) like me. So pinout should not be a problem.

There are two ways to archive a connection:


No. 1 is the preferred and more flexible way.
No. 2 will not work with cheap china clones, which are not as configurable as original ones. Also most of them does not support the K-Line properly. Just the licenses for an official ELM327 is about 50 € / $. Just to have an idea about how to figure out a china clone.
And additionally to that, you have to reconfigure the adapter every time you want to use it, via AT-Commands.
Which means in the end, you have to be responsible to talk to it via bluetooth, yourself!
Or use at least an application, which is capable of using startup commands, such as RaceChrono.

How to reconfigure another device can be seen here (https://racechrono.com/forum/discussion/comment/10064/#Comment_10064).
Title: Re: Bike interface OBD
Post by: aster94 on Apr 05, 2020, 11:35 am
hi, I just released a library that can use both the KDS (kawasaki) and the SDS (suzuki): KWP2000 (https://github.com/aster94/Keyword-Protocol-2000)

I am looking for people with honda/yamaha because i can bring the library also to these bikes!
Title: Re: Bike interface OBD
Post by: TriB on Apr 06, 2020, 09:22 am
I am looking for people with honda/yamaha because i can bring the library also to these bikes!
After looking into some data from honda, I stopped my approach to get a "all in one" solution.
There is no header, nothing similar to Suzuki or Kawasaki. This would mean to write a completely new solution, and use it parallel.
I still have enough work to get the diagnostic things from Kawa & Suzi OBD2 compatible and more stable. So I removed Honda from my list.
But if I can help you in any way, let me know :)
Title: Re: Bike interface OBD
Post by: aster94 on Apr 06, 2020, 10:49 am
After looking into some data from honda, I stopped my approach to get a "all in one" solution.
There is no header, nothing similar to Suzuki or Kawasaki. This would mean to write a completely new solution, and use it parallel.
I still have enough work to get the diagnostic things from Kawa & Suzi OBD2 compatible and more stable. So I removed Honda from my list.
But if I can help you in any way, let me know :)
Thanks Trib :D

actually all i know about honda and yamaha cames from these few lines (which i found in this forum or on ecu hacking):

Quote
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.
From these few lines it is not clear if the start sequence is needed (i mean the 25ms low and then 25ms high)

then it looks that someone should just send: 0x80 and checksum
and at the end send: 0x02 and cheksum

Do you have more info?

Quote
I still have enough work to get the diagnostic things from Kawa & Suzi OBD2 compatible and more stable.
If you need any help tell me!
Title: Re: Bike interface OBD
Post by: Earendil86 on Apr 15, 2020, 04:03 pm
Hello again! It's getting warmer out so I've started working on this again. Last update I had decoded which bytes from 0x21 08 line up to what on my 2013 Suzuki GSXR1000 and compared to Aster's, TriB's and O5i's PIDs and formulas.

The next step for me was to enter equations into the Racechrono app since I already owned a OBDLink MX for car diagnostics so I figured that I would use that rather than build my own. I've been in discussion with AOL (Racechrono developer) and we are working on an updated version as we speak!

Unfortunately. It appears as if some of the equations will need modification. Suzuki seems to change something with every model since some of the equations are not even close to the ones suggested by Aster, TriB and O5i which is disappointing. I'll set out soon on the road with a camera on my gauges to then compare to the Racechrono data to see how far off they are and see if I can get better equations where needed.

On to my current question

I would like to record tire pressures and tire temperatures and I need something that will connect through bluetooth. Does anyone here already do that? I have no issue buying and building a circuit to make this happen if needed.

I would prefer an internal sensor similar to a car, however, I have seen lots of screw in types like the FOBO Bike 2. My issue with that is that it is external and I would want it installed for balancing which shops won't want to do (since they have to remove and reinstall (with the safety clips) and it uses a separate app. I want to integrate this into Racechrono.

A question as well. How different would internal tire temperatures be from external? Would their be much of a difference? I've seen examples of people installing external sensors in the mud flaps for temperature. My issue with that is that those would restrict tire warmers from going on. So I would prefer and internal sensor which does both Pressure and Temperatures.

Thoughts on how to do this???

Thanks!
Title: Re: Bike interface OBD
Post by: TriB on Apr 15, 2020, 10:18 pm
Hmm, I got a demo-file from a newer GsxR1000 and my own Gsx-R600 (2006).
Both are quite similar  :smiley-roll:
Just give us some examples, so we might find something.

What´s wrong with aol´s current solution? I worked it out with him in the past... But didn´t used it productive, due to my cameras, which are OBD2 compatible.

I got a tire temperature and pressure system, which replaces the valve cap.
This is rubbish! The temp is far from reliable! And the pressure mostly "okay". It was submitted by a 433mhz protocol, which I didn´t found out. But my attempts have been not very intense.
I guess it´s much better to have it inside of the tire! And bluetooth is more standard, so you might have an easier access.
Currently, I measure once or twice a day on a racetrack. With brand new tires more often. So I throw them away  :smiley-twist:
Title: Re: Bike interface OBD
Post by: Earendil86 on Apr 18, 2020, 01:41 pm
Hey TriB,

I was asking some questions on racechronos forum and Aol realized that there might be an issue for non obdII compliant vehicles using custom pids. He rewrote some code and the test version includes a new setting to switch on for bikes like mine.

Then I ran some tests for him and sent the data. It appears to be working great! Still formula issues, however, I plan on starting work on those in the next few weeks. Need to put water in radiator and fairings on and will hit the road to test! I'll post my results here and hopefully we can solve my eqn issues.

As for tire temps, AOL already supports RejsaRubber which is a diy sensor! So I'll most likely be doing that. Need to check clearances but there is a very good write up here:

https://github.com/MagnusThome/RejsaRubberTrac

As for pressure and internal temps, I found an internal Bluetooth sensor that I'm going to try. It's by Blu technology.

http://techbyblu.com/phone/index.html

I'll reverse eng the code and hopefully be able to add to Racechrono.
Title: Re: Bike interface OBD
Post by: oflatley on Apr 22, 2020, 04:31 am
A question as well. How different would internal tire temperatures be from external? Would their be much of a difference? I've seen examples of people installing external sensors in the mud flaps for temperature. My issue with that is that those would restrict tire warmers from going on. So I would prefer and internal sensor which does both Pressure and Temperatures.

Thoughts on how to do this???

Thanks!
Heya --

A couple of things:  I've been logging tire data starting last year for track/race.   Honestly, the middle of the tire is totally uninteresting -- most ppl put IR sensors under the rear hugger and front fender -- two per wheel, close to the outside edge of the tire.  There is enough room to get warmers on.  I use sensors made by Aim, and they are basic 0..5V output in a durable package. 

If you use a needle type pyrometer after you come in from a session, you can start to get a sense of the difference between logged IR surface temps and the rubber close to tire core.

If you are using 'slicks', logging tire temps is useful at the track, especially if you have cold/hot alarms configured on your dash. Slicks have a pretty tight useful operation range, and you can save yourself some drama and tire destruction if you warn yourself if out of range.  Then, you can usually adjust temperature by raising/lowering temp.

O


Title: Re: Bike interface OBD
Post by: oflatley on Apr 22, 2020, 06:19 am
Hey all,

I've seen posts by many of you. Thanks

So, I am trying to hack R6 Kline.  I sniffed data with a logic analyzer, and I think I have enough understanding to try tests.  As we all know, there's an initialization needed prior to regular communication.  The stream looks simple (although interpretation might need a little coffee-time), but the init phase looks non-standard -- not KWP slow/fast. 

First pass, I am writing two sketches -- one proxy for OEM Dash (which I want to replace) and one proxy for ECU replies. I'll get them working with each other, and then I can swap in and out to real HW.  In the initialization handshake, microsecond timing is required, and I figure it's easiest to just bit-bang. 

I've been writing code for some years, but I am new to AVR/Arduino.  Both sketches use timers & interrupts -- but i've been getting weird behavior for a couple of days -- interrupts are firing before expected.  I'm still at it, but I might post some code and ask for second-eyes if i stay stuck.

O

Title: Re: Bike interface OBD
Post by: rubensx on May 01, 2020, 12:06 am
hi Guys! I'm found this work and I need to say you all are awesome! Great work at all about K-line!

I'm with a L9637D, a arduino nano and some stuff...

My project is a K-line but is not a reader... And I'm here calling for help:

The issue:

I have a honda s2000 cluster 2007 (this is a k-line cluster) and not the entire s2000 honda (saddly :) ) and make this cluster runing in a old honda car.

The Goal:

All cluster work fine and some convertions about VSS or other signals are a simple "analog to digital converter" and this working good and shining but the ECT (engine cooling temperature) is over the K-line...

Without the ECU, I can't sniff codes and try to move the ECT bars...

But in google I,ve found some information (from TriB project) crossing some information about a S2000 tunners:

Brake pedal pressure (ID = 106 byte 3) streams at about 150 frames per second.
Throttle pedal position (ID=170 byte 1) streams at about 100 frames per second.
Steering Wheel Position (ID=198 bytes 1 & 2) and Lateral Accelleration (ID=198 byte 3) stream at about 100 frames per second.
Engine Coolant Temp (ID = 300 byte 1), Ambient Temp (ID = 300 byte 2), Engine RPM (ID = 300 bytes 5 & 6) stream at about 100 frames per second.
Wheel Speed (ID = 448 bytes 5 & 6) stream at about 60 frames per second.


You guys work hard in k-line decoder and I need to create the exactly messagens to send to the cluster... (maybe someone here can take me a light) and with the upper information "Engine Coolant Temp (ID = 300 byte 1)" maybe I can do that!

Ok All fine and clarify to all about what I do and if someone can help to guide me... my doubts:

(I'm attach 2 versions of L9637D schem but these 2 are readers and with BT, I don't need BT, only serial to debug and nothing more)

- 10400 Baud? Makes me sense use this for "almost a default ecu" format message sender (to the cluster waiting the messages)
- someone can show me a example exact to "Engine Coolant Temp (ID = 300 byte 1)" hex sender? Is not clear to me how I create a test message with this information in hex (all converison from analog I can do after confirm the cluster read the messages)


Thank you all, I'm not post any code to don't "over information" (and wrong) about this


Title: Re: Bike interface OBD
Post by: Ser_Ov on May 01, 2020, 11:54 am
Hello!
I have a Suzuki Bandit 1250 and thanks to this forum, I made a gear indicator.

You can see how it looks here: https://www.youtube.com/watch?v=5YgEoLSCkP8

Now, I want to add fuel rate to the indicator. Please help me, how can I calculate this?

I found these PIDs:

32 High Cylinder 1 injection time (ms)
33 Low
34 High Cylinder 2 injection time (ms)
35 Low
36 High Cylinder 3 injection time (ms)
37 Low
38 High Cylinder 4 injection time (ms)
39 Low

Is it real injection time? What is the formula for calculating in ms?

Thanks!
Title: Re: Bike interface OBD
Post by: TriB on May 02, 2020, 12:33 am
All cluster work fine and some convertions about VSS or other signals are a simple "analog to digital converter" and this working good and shining but the ECT (engine cooling temperature) is over the K-line...

Without the ECU, I can't sniff codes and try to move the ECT bars...
Hi,
that sounds tough! You want to emulate an ECU to change an analog value (from a temperature sensor) to a k-line signal, which provides a gauge or something?
Did I understand that right?
For me it sounds a bit strange, at the first place. Because k-line is more or less not a common communication protocol between the components, because it is quite slow.

For Suzuki and Kawasaki we have 10417 baud and a protocol which consists out of:


This is part of the KWP2000 / ISO 14320 protocol.
How the service identifier (SID) and protocol identifier (PID) work, is different from manufacturer to manufacturer.

So we all have no clue, how it might work for your S2000.
What I do know: Honda Motorcycles does not rely on that kind of protocol. The don´t have a Header (Format + Receiver + Sender) and I still did not completely understood it.

If you might have some data, we can take a look, but don´t promise anything. Sorry  :smiley-confuse:
Title: Re: Bike interface OBD
Post by: TriB on May 02, 2020, 01:02 am
I found these PIDs:

32 High Cylinder 1 injection time (ms)
33 Low
34 High Cylinder 2 injection time (ms)
35 Low
36 High Cylinder 3 injection time (ms)
37 Low
38 High Cylinder 4 injection time (ms)
39 Low

Is it real injection time? What is the formula for calculating in ms?
Hi,

yes, that will show you the ms per cylinder.
But not every bike will have that!
AFAIK you just have to add both bytes (A * 256 + B)
0x05 0x4C
5 * 256 + 76
1356 ms

at ~ 1200rpm
Good luck :)
Title: Re: Bike interface OBD
Post by: rubensx on May 02, 2020, 02:30 am
Hi,
that sounds tough! You want to emulate an ECU to change an analog value (from a temperature sensor) to a k-line signal, which provides a gauge or something?
Did I understand that right?
For me it sounds a bit strange, at the first place. Because k-line is more or less not a common communication protocol between the components, because it is quite slow.

For Suzuki and Kawasaki we have 10417 baud and a protocol which consists out of:
  • Format byte (always 0x80 except of initial message 0x81)
  • Receiver address (0x11)
  • Sender address (0xF1)
  • Length
  • Service idendtifier
  • Protocol identifier
  • Data
  • Checksum


This is part of the KWP2000 / ISO 14320 protocol.
How the service identifier (SID) and protocol identifier (PID) work, is different from manufacturer to manufacturer.

So we all have no clue, how it might work for your S2000.
What I do know: Honda Motorcycles does not rely on that kind of protocol. The don´t have a Header (Format + Receiver + Sender) and I still did not completely understood it.

If you might have some data, we can take a look, but don´t promise anything. Sorry  :smiley-confuse:
Thankyou for your help and attention TriB...

In attach I put a image from a Honda s2000 cluster!
Yes, all cluster work fine, some features (like a CHECK ENGINE light and other simple lights) I've make work in a civic EJ1 1995! These simple alerts don't need the CAN or K-line Protocol!

But this specific version (after 2006) the S2000 has a ambient temperature, engine coolant temp and oil temp... This parameters are calculated by ECU in delta and the result is showing in the cluster (Oil life and ECT gauge).

The ECT gauge only moves by a k-line/CAN messages and not a simple analog signal or digital pulse signal (like the tachometer and VSS in this case are digital pulse). This digital pulses I create "analog to digital" conversion with arduino pro micro and work fine.

Back to ECT, I started my research with a MCP2515 shield and tying to conect to the cluster or "read" somenthing... and "don't work".

With more deeply google research I've found the information:  Honda S2000 - 2007 year are K-line and not CAN... And... This moves-me to found you and some information...

In a S2000 Forum, I've found th information from a datalogger scanner called "racelog" (and this scanner can learn k-line and PIDs from ECU to use information in races logger etc...) - Engine Coolant Temp (ID = 300 byte 1), Ambient Temp (ID = 300 byte 2),

And my doubt are "how to create this message above to your code and library can be sended to the cluster...



With a L9637D + arduino Nano I'm create this board (in another image). I'll pretend test it

I strat from this code (completly clean still untouched):

Code: [Select]

nclude "Arduino.h"
// Be sure that the AltSoftSerial library is available, download it from http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html"
#include "AltSoftSerial.h"


#include "OBD9141.h"

#define RX_PIN 2  // connect to transceiver Rx
#define TX_PIN 3  // connect to transceiver Tx
//#define EN_PIN 10  //  pin will be set high (connect to EN pin of SN65HVDA100)

AltSoftSerial altSerial;

OBD9141 obd;


void setup(){
    Serial.begin(9600);
altSerial.begin(10400);
    delay(2000);
  //  pinMode(EN_PIN, OUTPUT);
  //  digitalWrite(EN_PIN, HIGH); // enable the transceiver IC.

    obd.begin(altSerial, RX_PIN, TX_PIN);

}
   
void loop(){
    Serial.println("Looping");

    bool init_success =  obd.init();
    Serial.print("init_success:");
    Serial.println(init_success);

   // init_success = true;
    // Uncomment this line if you use the simulator to force the init to be
    // interpreted as successful. With an actual ECU; be sure that the init is
    // succesful before trying to request PID's.

    if (init_success){
        bool res;
        while(1){
            res = obd.getCurrentPID(0x11, 1);
            if (res){
                altSerial.print("Result 0x11 (throttle): ");
                altSerial.println(obd.readUint8());
            }
           
            res = obd.getCurrentPID(0x0C, 2);
            if (res){
                Serial.print("Result 0x0C (RPM): ");
                Serial.println(obd.readUint16()/4);
            }


            res = obd.getCurrentPID(0x0D, 1);
            if (res){
                Serial.print("Result 0x0D (speed): ");
                Serial.println(obd.readUint8());
            }
            Serial.println();

            delay(200);
        }
    }
    delay(3000);
}



This code makes sense to me by the 9600 baud to my computer can show me what are sended and a altserial can up the 10400baud to the kline...

but I need some simple at now... send the message "ID = 300 byte 1" in hex to test if the ECT gauge restpind...

The time to respond in gauge are not much important, the ECT rise slow and the information is not much precise in bars...

maybe I make this more clear now...

thank you again
Title: Re: Bike interface OBD
Post by: TriB on May 02, 2020, 09:21 am
Hello rubensx,

alright! If you cannot get some further information about the exact protocol, you have to sniff it yourself.
That´s the solution how all of this started:
Someone got an external gear display, which was connected to the diagnostic port.
Then he took an arduino and put it in between, to pass all the data untouched through. But off course the data was also written onto an sd card!

That´s how the Kawasaki and the Suzuki solution founded. Afterwards, there have been several 3rd party diagnostic tools, which were analysed.

Long story short: If you can manage to find a working S2000, where you can get into the communication between those parts, try to sniff them.
Otherwise you have to find someone, who already did this.

I can just hardly guess, but the difference between Suzuki & Kawasaki is quite big. Honda even more and nobody knows, if the S2000 relies on that or due to it´s a car, it has a very own signature.

There are initiaization processes, the receiver id´s are different, the PID 300 is only the protocol, which SID must be requested?, afaik honda has a unique checksum calculation, etc.
Title: Re: Bike interface OBD
Post by: Earendil86 on May 20, 2020, 04:30 pm
Hello again. A quick update.

I've gone out and logged some data in a bunch of gears with my Racechrono setup. The purpose was to test 1) OBD Speed vs Speedometer vs GPS as well as to check 2) Oil Temp on cluster vs OBD and 3) Indicated Gear vs Gear from OBD, 4) RPM on cluster vs OBD Log and 5) throttle position values

Here are my findings:

1) The Speedometer always indicates high. For instance, at 120km/h the logged GPS and OBD are at 111 and 112 respectively. I did some research and it's very common for the speedometer to indicate wrong as the MFR's do it on purpose. So I'm happy with the formula kph = byte x 2

2) The Oil Temp is either bang on or 1 deg F off, so I'm very happy with the formula = (byte*160/255)-30

3) The indicated Gear is great. It does a weird value switch at times for instance showing 1,3,5,4,3,2 as gear in the spreadsheet when shifting from 1 to 2. But this is extremely quick and the value settles appropriately at gear 2 within a fraction of a second.

4) The RPM equation seems to be off by and average of 210. The cluster is not digital so the visual readings are very possibly off be 100-200, however, I am positive that they are off. At higher speeds it appeared to be approx 340 off. TriB, I know you're still looking into RPM and if you have any thoughts I'd be interested. The equation I'm using is:

= (byte(H)*255+byte(L))/255*100

5) The values for throttle I did not specifically check, however, I will be doing some comparisons later. OBD apparently usually shows 20-80% for throttle so I'm not sure what the equations range will show but I can determine that later. Racechrono has a great option for percentages and it can scale it. So as long as I hit 100% throttle and 0% then it will scale all the values appropriately in my video overlays.
Title: Re: Bike interface OBD
Post by: eraydagci on Sep 01, 2020, 04:42 pm
Hello, I read the forum from beginning to end. Does anyone read data from a Honda motorcycle? please help me i want to use Android realdash.apk on my engine.
Title: Re: Bike interface OBD
Post by: TriB on Sep 02, 2020, 09:33 am
Hi eraydagci,

I´ve reviewed some documentation and tools (like Healtech OBD Tool).
It is possible to communicate with Honda ECU´s.
The technical communication protocol is equal to Suzuki or Kawasaki.

So you should be able to use the same hardware.

But there are several differences, which made me stop developing one solution for three manufacturers.
The initialization protocol, checksum calculation and so on, refers on ISO-9141-2.
No big deal, but different!
The messages does not have a format, header, recipient, sender, echoed SID / PID. So they must be created totally different.
I´ve got several log-files from Honda and still did not understand, how they communicate.

Beside of the strange messages, the value calculations will be completely different, as well.

Long story short:
I do not own a Honda, so I stopped my attempts at that point.

Possible solution:
Buy a working diagnostic system (Healtech f.e.) and record the communication on the USB-Port. Then you possibly can translate the requests to what the software is showing.
Title: Re: Bike interface OBD
Post by: eraydagci on Sep 02, 2020, 12:29 pm
First of all, thank you very much. I wish we were close, I would leave my engine to you. I really want this project.
Title: Re: Bike interface OBD
Post by: eraydagci on Sep 02, 2020, 12:37 pm
https://gonzos.net/projects/ctx-obd/

Maybe this site can help you?
Title: Re: Bike interface OBD
Post by: TriB on Sep 02, 2020, 02:42 pm
Yes, this site looks pretty straight forward! Seems like the most important things are there.
The init protocol and checksum calculation was already included in my newest code, but I stopped going on with that, since I did not found a documentation like that.

I´ll step deeper into it, after my current project is finished.
Title: Re: Bike interface OBD
Post by: eraydagci on Sep 02, 2020, 05:37 pm
Thank you very much. I was very happy.