I have a obd urthttps://learn.sparkfun.com/tutorials/obd-ii-uart-hookup-guide/connecting-to-an-arduino board from sparkfun. It sends data to the Arduino via the serial pins. I want to pass this information to a processing sketch but I'm not sure the proper way to do it. I have used an arduino and processing before, but it only dealt with passing rotary encoder and button press information. Would I read the obdii via hardware serial then use software serial to pass the values to my sketch?
Additional information. The project will be using a pcduino for the final install, but I have an uno r3, mega and digix (due clone) at my disposal to use for testing or to add to the project if necessary)
It doesn't have to. Use two other pins and SoftwareSerial.
Would I read the obdii via hardware serial then use software serial to pass the values to my sketch?
You could, if you have an FTDI cable to use instead of the USB cable, or if you had a Leonardo. But, since the device doesn't need to connect to the hardware serial pins, it's simplest to just move it.
i've started with the sketch that sparkfun provided:
i'm have been searching the web and trying different configs in my car all day and haven't been able to figure this out.
as soon as i open the serial monitor it interrupts the communication with the obdii-urt board.
I'd love to get some guidance on how to be able to view the data in the serial monitor or better yet in a processing app.
would i have to create a slave arduino and communicate to the master via i2c in order to view the obdii data on a serial monitor?
i've started with the sketch that sparkfun provided
Which uses the hardware serial port to talk to the OBD device.
as soon as i open the serial monitor it interrupts the communication with the obdii-urt board.
Of course it does. Either don't do that, or use a SoftwareSerial port to talk to the OBD device. Which will be challenging when using SoftwareSerial to talk to an LCD too.
Really, the best thing you can do is to get a Mega, and forget about SoftwareSerial. Or, get a I2C LCD and eliminate the need to use SoftwareSerial to talk to the LCD.
as soon as i open the serial monitor it interrupts the communication with the obdii-urt board.
Of course it does. Either don't do that, or use a SoftwareSerial port to talk to the OBD device. Which will be challenging when using SoftwareSerial to talk to an LCD too.
Really, the best thing you can do is to get a Mega, and forget about SoftwareSerial. Or, get a I2C LCD and eliminate the need to use SoftwareSerial to talk to the LCD.
Thank you.
so part of my issue was the code i was using from sparkfun doesn't work for some reason. I am using another snippet of code i found and it's working! (using mega's serial1 to communicate with the obd-ii device) and now i can write to Serial0 and get a readout in the serial monitor... not a big accomplishment for most of you, but serial communication is very new to me.
getting an i2c lcd isn't an option because I'm creating a processing sketch for a digital dashboard to replace an instrument cluster in a classic car:
Thank you guys for your guidance
here is the code that i'm using:
//Set up ring buffer
char rxData[20];
char rxIndex=0;
void setup()
{
Serial.begin(9600); //
Serial1.begin(9600); //Hardware serial connection to the obdii uart
ODB_init();
}
void loop()
{
//Delete any data that may be left over in the serial port.
Serial1.flush();
Serial.print ("RPM: ");
Serial.println (getRPM());
Serial1.flush();
Serial.print ("TEMP: ");
Serial.println (getTemp());
// delay(10);//wait .5 seconds and grab another reading
}
void ODB_init(void)
{
//Wait for a little while before sending the reset command to the OBD-II-UART
delay(2);
//Reset the OBD-II-UART
Serial1.print("ATZ\r");
//Wait for a bit before starting to send commands after the reset.
delay(2);
OBD_read();
Serial1.print("ATE0\r");
OBD_read();
Serial1.flush();
}
int getRPM(void)
{
//Query the OBD-II-UART for the Vehicle rpm
Serial1.flush();
Serial1.print("010C\r");
OBD_read();
return ((strtol(&rxData[6],0,16)*256)+strtol(&rxData[9],0,16))/4;
}
int getTemp(void)
{
//Query the OBD-II-UART for the Engine Coolant Temp
Serial1.flush();
Serial1.print("0105\r");
OBD_read();
return strtol(&rxData[6],0,16)-40;
}
void OBD_read(void)
{
char c;
do{
if(Serial1.available() > 0)
{
c = Serial1.read();
if((c!= '>') && (c!='\r') && (c!='\n')) //Keep these out of our buffer
{
rxData[rxIndex++] = c; //Add whatever we receive to the buffer
}
}
}while(c != '>'); //The ELM327 ends its response with this char so when we get it we exit out.
rxData[rxIndex++] = '\0';//Converts the array into a string
rxIndex=0; //Set this to 0 so next time we call the read we get a "clean buffer"
}
if the title was with communications i didn't wrote about the title
one communication between 3 devices
before to read i saw one cable for 3 devices
sorry
It doesn't have to. Use two other pins and SoftwareSerial.
Would I read the obdii via hardware serial then use software serial to pass the values to my sketch?
You could, if you have an FTDI cable to use instead of the USB cable, or if you had a Leonardo. But, since the device doesn't need to connect to the hardware serial pins, it's simplest to just move it.
Pauls i appreciate your help/guidance. I have another question. You mentioned the Leonardo as an option. on the product page it states:
Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data using the ATmega32U4 hardware serial capability. Note that on the Leonardo, the Serial class refers to USB (CDC) communication; for TTL serial on pins 0 and 1, use the Serial1 class.
Would this mean that i could accomplish the same result as using the mega?
PaulS:
Where, in this classic car, is Processing going to run?
To ease your hesitation a bit... it's a pro-touring restoration. both rear qtr's and front fenders are getting new metal, it's getting modern suspension and a 6.0 ls engine. I didn't take a cherry example and restomod it
it's going in the dash of a 66 chevelle same location that the gauges are in now
If you don't need the extra memory, and only need 2 serial ports - one of which only talks to the PC - then, yes, the Leonardo would work, too.
yes memory isn't an issue. the arduino is going to handle passing obd-ii data to the host. Not sure that obd-ii is fast enough for tach and speed though. I may offload this to gps and counting a the pulses off the coil or reading the tach pickup wire (have to research that one more. not sure exactly what my engine will have available
