SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By djarmyssg
#144205
Hey guys, Well im running into some serious problems with my OBD project... Now I am really new at all this, but I like to think im a pretty fast learner. Heres my setup, Arduino Uno, connected to Sparkfun OBD to UART shield,(Tx,Rx, and ground), non serial LCD wired as in MPguino. programming code is OBDuino32K with ELM uncommented, and ISO commented. I can get everything to compile fine, upload fine (have to disconnect tx,rx) but no matter what I do I cant get any information BACK from the shield... Let alone the ECU. I've tried Hyperterminal, Tera Tel, and EZOBD, and no matter what commands I throw, I dont get ANYTHING back... Here are some pictures of my setup.... PLEASE HELP!!!!

Shield is wired like this..... LCD isnt wired like this.
Image

Image

Image

Let me know any ideas will be appreciated!
By djarmyssg
#144208
Mee_n_mac,

Heres a ink to the code Im using, But, Im beginning to think its not the coding due to the fact that I cant seen to connect to the Shield through Hyperterminal even when im not connected to the car.... I should get SOME kind of responce right? Or do I have to "CALL" for the response to be printede in hyperterminal??

http://code.google.com/p/opengauge/sour ... ino32K.pde
By Mee_n_Mac
#144233
A very quick glance at the code shows a lot of "prints" but they're all conditional on something happening (or not) from the OBDII board. I don't see s simple "I'm alive and connected" print. And perhaps I'm missing something but how are you getting the Uno to talk to it's serial/USB converter and the OBDII board at the same time ? You seem to have the shared Tx and Rx lines going to both at the same time. Is it your thinking that you should be able to see the messages going from the Uno to the OBDII via the USB/serial monitor ?
By rocketboy07
#144244
Have you tried hooking it up and using the arduino to just repeat what comes in through the serial port and send your own commands? This could rule out it being the obdII uart board.
By djarmyssg
#144271
Mee_n_mac, I think your right.. I definitly was under the impression that I could read the messages coming FROM the Shield, TO the Uno through my serial connection... But im guessing thats not the case? Im fairly new to this whole deal, so Im not 100% on the workings of things.

Rocket... I'd definitly love to do the repeat thing. I've been researching alot about serial connections, so i gotta figure out how to program the commands. My biggest thing is I want to make sure the Shield isnt bad.. Since i havent been able to get it to do ANYTHING (aside from flash a couple lights) I recorded a video of what shes doing, and I'll post it up here when I get home! That way U guys can see exactly what shes doing.... or not doing! Thanks again for all the help thus far!
By Mee_n_Mac
#144273
djarmyssg wrote:Mee_n_mac, I think your right.. I definitly was under the impression that I could read the messages coming FROM the Shield, TO the Uno through my serial connection... But im guessing thats not the case? Im fairly new to this whole deal, so Im not 100% on the workings of things.
I'm not sure how the OBDII board was intended to be used, my guess would be that it's intended to be connected to a PC (via a serial<->USB adapter) and then, running some software on the PC, allow you to see and fiddle with stuff. So replacing the PC with an UNO and an LCD and perhaps some other input device means the Uno should see (and output) the same serial communications that the PC would. But I think there's a problem with your setup. The Tx out from the OBDII goes through a resistor to the Rx in of the Uno. That same pin is tied to the Uno's onboard USB<->serial adapter and thus effectively to the PC's Tx out. I'm not sure what the onboard adapter does when it's not receiving traffic from the PC. If it doesn't tri-state it's output, it'll be pushing the Rx in of the Uno high or pulling it low. Given the OBDII has a resistor in it's path to that same pin, the PC will win that battle and the Uno won't see anything from the OBDII. If you never see anything on the LCD when connected to the car, this is one possible (of many) reason(s).

Then you have the Tx out of the Uno going through it's onboard adapter to the Rx in of the PC. Simultaneously that Tx out goes, through a resistor again, to the Rx in of the OBDII. You should be able to listen to the traffic sent by the Uno to the OBDII ... but that's the opposite of what you wanted above. And as I said earlier, it's not clear to me that the Uno sends anything all by itself, uninitiated by something else. I think I did see something about some buttons or joystick input ... which would make some sense in that as a standalone system (Uno, LCD, OBDII and input device) you'll need something to navigate among the various items to be read off the CAN bus. Perhaps the Uno only "talks" when this input device is tickled ??

BTW when you say "OBDII shield" do you mean this device ...
http://www.sparkfun.com/products/9555 ... which isn't strictly an Arduino sheild or are you using this device ...
http://www.sparkfun.com/products/10039 ... which is.
Given your diagram and connections I've been assuming it's the former.

What do you see on the LCD when the system is not connected to the PC and is connected to the car ?
By Mee_n_Mac
#144276
OK, I see via this tutorial that my guess above was correct.
http://www.sparkfun.com/tutorials/294

Did you try to modify the real simple sketch in that tutorial to send data to your LCD ? That would be worth a try to get started and see if things are all working. Ideally I think you'd see an ATZ command being sent by the Uno on your monitor (assuming the PC's com port is setup properly). Not very useful info but it would show the Uno is booting and working as expected. Hopefully if you've got the new LCD coded up, and if that onboard USB adapter isn't screwing things up, you'd also see the speed and RPM data on the LCD.

If you happen to have a USB<->serial/TTL (not RS232 !) cable/adapter, you could try what was done in Example #1. That's even simpler and would verify the OBDII board is functional and talking to your car.
By djarmyssg
#144282
Mee_... You are correct on ALL accounts. I Have the actual UART-OBD.... Oddly enough, I ALSO have the CANBUS shield... But im not working with that currently since I dont have a CANBUS vehicle to test on right now. I did take the sample schetch and ATTEMPT to convert it to nonserialLCD. I got it Kinda working, but cant find the right location where the responses will print.. I definitly will keep trying though... But I ALSO have a serialLCD on its way (itll be here saturday). so if i cant get the LCD coding right, I'll just use the SERIALLCD just to make sure the shield is working corrrectly. But either way... Im uploading the video I took earlier, and It should be up soon!
By Mee_n_Mac
#144284
djarmyssg wrote:I did take the sample schetch and ATTEMPT to convert it to nonserialLCD. I got it Kinda working, but cant find the right location where the responses will print.. I definitly will keep trying though...
If you still have it, post that code and perhaps it can be easily fixed. As it happens I've got the non-serial Arduino LCD library fresh in my mind from another project.
By djarmyssg
#144285
This is the one I JUST adjusted! Its alined the Speed and RPM... I'll keep working on it!
#include <LiquidCrystal.h>

#define LCD_RS 4
#define LCD_ENABLE 5

#define LCD_DATA1 7
#define LCD_DATA2 8
#define LCD_DATA3 12
#define LCD_DATA4 13

LiquidCrystal lcd(LCD_RS, LCD_ENABLE, LCD_DATA1, LCD_DATA2, LCD_DATA3, LCD_DATA4);
#define ContrastPin 6
#define BrightnessPin 9


//This is a character buffer that will store the data from the serial port
char rxData[20];
char rxIndex=0;

//Variables to hold the speed and RPM data.
int vehicleSpeed=0;
int vehicleRPM=0;

void setup(){
//Both the Serial LCD and the OBD-II-UART use 9600 bps.

Serial.begin(9600);
lcd.begin(16, 2);
//Clear the old data from the LCD.
//lcd.print( BYTE);
// lcd.print( BYTE);

//Put the speed header on the first row.
lcd.print("Speed: ");
lcd.print(BYTE);
//Put the RPM header on the second row.
lcd.setCursor(0, 1);
lcd.print(BYTE);
lcd.print("RPM: ");

//Wait for a little while before sending the reset command to the OBD-II-UART
delay(1500);
//Reset the OBD-II-UART
Serial.println("ATZ");
//Wait for a bit before starting to send commands after the reset.
delay(2000);

//Delete any data that may be in the serial port before we begin.
Serial.flush();
}

void loop(){
//Delete any data that may be in the serial port before we begin.
Serial.flush();
//Set the cursor in the position where we want the speed data.
lcd.print(254, BYTE);
lcd.print(128+8, BYTE);
//Clear out the old speed data, and reset the cursor position.
lcd.print(" ");
lcd.print(254, BYTE);
lcd.print(128+8, BYTE);
//Query the OBD-II-UART for the Vehicle Speed
Serial.println("010D");
//Get the response from the OBD-II-UART board. We get two responses
//because the OBD-II-UART echoes the command that is sent.
//We want the data in the second response.
getResponse();
getResponse();
//Convert the string data to an integer
vehicleSpeed = strtol(&rxData[6],0,16);
//Print the speed data to the lcd
lcd.print(vehicleSpeed);
lcd.print(" km/h");
delay(100);

//Delete any data that may be left over in the serial port.
Serial.flush();
//Move the serial cursor to the position where we want the RPM data.
lcd.print(254, BYTE);
lcd.print(128 + 69, BYTE);
//Clear the old RPM data, and then move the cursor position back.
lcd.print(" ");
lcd.print(254, BYTE);
lcd.print(128+69, BYTE);

//Query the OBD-II-UART for the Vehicle rpm
Serial.println("010C");
//Get the response from the OBD-II-UART board
getResponse();
getResponse();
//Convert the string data to an integer
//NOTE: RPM data is two bytes long, and delivered in 1/4 RPM from the OBD-II-UART
vehicleRPM = ((strtol(&rxData[6],0,16)*256)+strtol(&rxData[9],0,16))/4;
//Print the rpm data to the lcd
lcd.print(vehicleRPM);

//Give the OBD bus a rest
delay(100);

}

//The getResponse function collects incoming data from the UART into the rxData buffer
// and only exits when a carriage return character is seen. Once the carriage return
// string is detected, the rxData buffer is null terminated (so we can treat it as a string)
// and the rxData index is reset to 0 so that the next string can be copied.
void getResponse(void){
char inChar=0;
//Keep reading characters until we get a carriage return
while(inChar != '\r'){
//If a character comes in on the serial port, we need to act on it.
if(Serial.available() > 0){
//Start by checking if we've received the end of message character ('\r').
if(Serial.peek() == '\r'){
//Clear the Serial buffer
inChar=Serial.read();
//Put the end of string character on our data string
rxData[rxIndex]='\0';
//Reset the buffer index so that the next character goes back at the beginning of the string.
rxIndex=0;
}
//If we didn't get the end of message character, just add the new character to the string.
else{
//Get the new character from the Serial port.
inChar = Serial.read();
//Add the new character to the string, and increment the index variable.
rxData[rxIndex++]=inChar;
}
}
}
}
By Mee_n_Mac
#144286
djarmyssg wrote:Ok Heres the video!
Well that's interesting. Obviously the Ardiuno OBD code knows how to talk to the LCD. The sequence of LEDs on the OBDII board must mean something. I'm not sure what to make of your ground experiement. :think: I assume the laptop is running off it's battery and therefore not plugged into the car in any way other than via the Arduino via the OBDII board. If I have some spare time tonight I'll see if I can figure out any thing smart to do.

You do see the ATZ command from the Arduino, so the OBDII board should be getting that as well. In cases like this it's best to simplify. I'd recommend trying to get the simple code from the Tutorial working on the Arduino & LCD and see what happens then. The other code is too complicated to figure out what's wrong with your setup, be it hardware or software or ???
By djarmyssg
#144287
My thoughts Exactly!!!! Im working on getting the LCD to print to the right lines.... Like i said though... If I cant get it figured out... I';ll have the serial LCD on saturday... so I hopefully can use the original code!!! But Dude... Im liking how were on the same page as far as ideas... Now If i can just get on ur Knowledge level... I'd be good!!! LOL
By Mee_n_Mac
#144288
Here's my take on the video ...

I see from the schematic of the OBDII that there's 4 LEDs and these are driven from the OBD controller IC. Two indicate status (Tx, Rx) of the UART comm port (your Arduino comm) and one (LED4) seems to be to indicate a reset is being done (and also to reset any non-volatile memory that may be present) as well as indicating comm to the car, and the last (LED3) seems to indicate comm from the car and perhaps also serves as an interrupt acknowledged indication (guessing from the names).

Your vid shows the UART Tx and Rx lines flash and I think this is due to the ATZ reset message being received by the OBD IC. It might be that the OBD then also sends some response message, that you don't get to see ... now. Then there's the Knight Rider ripple of all the LEDs, which I think is the OBD controller saying it's doing a reset. My conclusion from this is that the comm from your Arduino to the OBD is working (yea !) but I don't think the OBD is connecting to your car (crap !).

That the UART LEDs flash every so often when you disconnect some ground wire ... I think this is just noise tricking the OBD into thinking it's getting a message (probably one it thinks is invalid). I note you can see the ATZ reset message sent by the Arduino and I'll assume (since you don't mention anything) that you don't see any other messages on the PC monitor when the ground is removed and the UART status LEDs are flashing. This lack of visible messages from the Arduino tells me that it's not sending anything to the OBD and so the LED that indicates this (messaging) is happening at the OBD end is due to noise. I'll also guess that probably that any message sent by the OBD to the Arduino is not getting received by the Arduino (or it's deemed invalid at the Arduino end). My conclusion ... I'd leave the ground attached for further testing. The 9 pin DB on the OBDII board would seem to carry a ground from the car to the OBDII board. You'll need a single ground reference from the OBDII board to the Arduino for comm btw the two to work (I believe this is the wire you removed). I assume you're powering the Arduino of the PCs USB port so disconnecting the PC is not an option right now. Just be sure the PC isn't tied to the car in any other way and there should be no ground loop problems but but leave a common ground reference for eveything to talk to everything else.

Right now I'd have just the PC, the Arduino and LCD tied together and try to get a simple "Hello World" added to the Tutorial sketch working to show that sketch isn't missing something to talk to the LCD. I'm going to look at that now.

BTW if you use the full editor you'll find a code tag button that will allow you to paste code in a nice scrolling box with indentation preserved. Makes it mucho easier to read.
Code: Select all
This is in the code box.
  See the indentation !
    Rejoice !!
EDIT : I note from the tutorial page ...
This command will cause the OBD-II-UART board to reset. On the board you'll see some LEDs flash, and then you'll receive the start-up prompt in the terminal window.

Does the simple tutorial code send the "start up prompt" to the LCD ? If not, yours should. That'll verify 2 way comm btw the Arduino and OBDII as well as a working LCD display !