Any interest in developing an open source fuel economy gauge/computer?

[dcb]

Is your code posted somewhere? I've got the rs232 elm thing and a serial duino, I could at least see if it works any better for me, especially if it works with a guino compatable LCD hookup. Eventually I'd like to dissect my rs232 thing and package the elm chip with a duino, but for now it is rs232.

Edit: you might want to start a guinobd thread or something to collect the obd bits.

[jmonroe]

Well, I never got past a few tests.

I was using some test code which simply requests RPM when a button is pressed. It also uses my serial LCD using the software serial library.

Before I experienced some hardware problems, I could send ELM specific commands and receive the output but, the OBD commands would result in "BUS INIT:...>" with no error or anything but then the next command would do the same thing.

#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3
#define fButtonPin 4
#define keyWait 200

SoftwareSerial LCD = SoftwareSerial(rxPin, txPin);

void setup() {
  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  
  // start serial connections
  LCD.begin(9600);
  Serial.begin(9600);
  
  // setup button and turn on the internal pull-up resistor
  pinMode(fButtonPin, INPUT);
  digitalWrite(fButtonPin, HIGH);
  
  // set ELM to formated data
  Serial.println("ATFD");
  // turn off command echo
  Serial.println("ATE0");
  
  LCD.print("?a?fELM OUT:?n");
  // reset the ELM
  Serial.println("ATZ");
}

void loop() {
  char temp;
  // if there is something waiting on the serial connection, get that and send to LCD
  while(Serial.available()) {
    temp = Serial.read();
    LCD.print(temp);
  }
  
  // if the front button was pressed, send the ELM command
  if(digitalRead(fButtonPin) == LOW) {
    delay(keyWait);
    LCD.print("?a?f"); // clear the LCD and reset cursor
    Serial.println("010c"); // ask for the engine RPM
  }
}

[dcb]

Originally Posted by jmonroe

It also uses my serial LCD using the software serial library.

Aha! The serial LCD is conflicting with the serial elm323?

Edit, oops, no different pins. Let me see if I can adapt it to the parallel lcd...

Edit 2: That SoftwareSerial looks handy.

[jmonroe]

Originally Posted by dcb

That SoftwareSerial looks handy.

It doesn't work very well for receiving because it doesn't have Serial.available(). Instead, Serial.read() waits till it has input.

[dcb]

Ok, well I'm getting something.
the first 010c gives me the BUS INIT:

but the subsequent 010c calls are giving me a string with some hex numbers on the end that seem porportional to RPM. There are some strange characters in the string, but definately a rpm signal too.

Hmm... Have you tried any other OBD devices on your car lately?

edit, also, the E0 is being reset to E1 by the ATZ.

Edit, also the bus can take a little while to initialize.

[jmonroe]

The only OBD device I have used on my car was the ELM323 connected to a computer and it worked with no problems.

I hope to do some work on it tonight.

So, you were using the Serial Freeduino with the RS232 connector connected directly to the ELM's output. I may have to get a Serial Freeduino to give that a shot if I can't get my Deciema with MAX233 to work.

[jmonroe]

I got my hardware working again. If others are attempting the same thing, make sure you note that the MAX233 needs to have the internal capacitors wired differently than the MAX233A.

I am still getting the same issue with bus initialization. I don't get an OK or FAILED. I just get the prompt character again and then it repeats on the next command.

dcb, could you post the code that you used or message it to me.

[dcb]

I couldn't PM it to you, it was too big, it was basically your code grafted over mpguino for all the parallel lcd stuff. Given the strange characters I saw, I wonder if a test with laptop receiving the data from the duino via the softwareserial object, instead of the lcd, might help narrow down the problem.

I'm sure you have tried other pins for SoftwareSerial.

[jmonroe]

Originally Posted by dcb

I couldn't PM it to you, it was too big, it was basically your code grafted over mpguino for all the parallel lcd stuff. Given the strange characters I saw, I wonder if a test with laptop receiving the data from the duino via the softwareserial object, instead of the lcd, might help narrow down the problem.

I'm sure you have tried other pins for SoftwareSerial.

Hmm, I don't get any strange characters. My communication with the ELM appears to be perfect but, the ELM's communication with the car ceases to work when I am connected to the arduino, it works just fine however, when connected to the PC.

[dcb]

I just wonder if there is a way to rule the softwareserial out.

Like teach pin 13 LED morse code instead and send the data there without the LCD or anything else but the elm connected?

[jmonroe]

I think I might wire up the LCD in parallel and try to cut out the SoftwareSerial completely if I can.
Actually, I might be able to test without the LCD. Once the ELM has established a connection with the ECU, it will send a signal ever second or two to keep the connection alive and the OBDTX light flashes. If I run the code without software serial or an LCD, I should be able to see that light flash and the ELM maintain a connection even though I can't view the data.