OBD MPGuino gauge

[Demonhawk]

OK, I have a quick noob question. How do I display individual PIDS? When going through the screen configuration I can see RPM and speed, but none of the others. All I see is Outing waste, Fuel consumed this trip, etc.

I went through the list of PIDs that i could select and the only ones from the ecu are: pid00-21, stat dtc, coolant t, rpm, speed and obd std.

[Froggy]

You're doing things right, but it looks like the car does not support some PIDs?

On startup, the OBDuino will poll the ECU and check which OBDII PID's are supported by the ECU. It logs these PID's that it can display, and when selecting PID's to display, it skips those that the car says it does not support...

Look in the code, and you will see a huge list of valid PID's that are currently available. The list ends with some 'fake' PIDs that we always have available.

Why is your car saying the others are not supported? Perhaps they are available from a custom tool that VW makes? Not sure. Is there a VW dealer you can check with?

[Demonhawk]

I know that VW cars have a special scan tool that they use called a VAG-COM, but from what I understand it is used for reprogramming certain things within the ECU such as the Automatic transmissions shift points, and other things.

I don't understand why my car only reports those 6 PID's. I displayed on one of the screens the Total amount of PID's available and it was actually fluctuating between 6 & 7 PID's available. I don't know if maybe there is something wrong with the data stream or what.

I'm pretty sure my car does report those other values because I just borrowed my buddies scanguage2 and hooked it up and drove for 20min and it appeared to be working.

I also have a quick question. Is there anyway to log the serial communications that is being made through the arduino? I know there is a serial monitor in the IDE itself but it doesn't support 10.4K baud.

[Froggy]

Since the ScanGauge reports fuel use, the data is available through the OBD port.

How ScanGauge got the data, I doubt they will tell (other than to 'buy the guage').

If you're good at code and wanna do some hacking, you could force the OBDuino to use the PID's anyways, and see what happens. Does it return a working value, garbage, or some strange value... (Just make the function to check supported PID's to always return a 'supported' value.)

You can dump the communications to the LCD if you wish (just disable the PID display in the code and instead display the chatter from the ECU when it comes in.)

As for saving the communications, you have a limited amount in eeprom (after the parameters).

You might be able to route data through the USB port to a laptop, but you would have a conflict with the OBDuino using those same TX and RX pins to chat with the ECU. More than one serial device is possible, but I've never attempted it.

[Demonhawk]

When I display i beleive it is PID_SEC, which displays the number of PIDs available it goes back and forth between 6 and 7 which seems unusual to me. But your suggest was what my next question was about to be. If there was a way to disable ECU polling and just force it to try to read the values anyways.

I wouldn't consider my self "good" at code per-se. I've taken a college course over programming C++ so much of the syntax is understandable to me, but since it's C it deals with memory addressing which isn't something I had to deal with in C++.

I didn't actually mean logging the serial data as much as I meant viewing it as it is being sent and received, I guess that would be sniffing the data. I know the actual arduino program allows you to do it but the baud rate jumps from 9600 to 14400 so when attempting to read the 10400 baud signal i just receive garbled information.

Also I would like to thank you for trying to assist me with this issue

[Froggy]

Ok, first PID_SEC will display how many PID requests the OBDuino has counted in the past second. A fluctuation is normal. It does not count how many PID's the car will answer to.

You can easily fudge up the program to try to display any PID's. The function is_pid_supported(), returns true if the PID is claimed to be supported by the ECU.

You can simply always return true, or you can add in a little code that allows one or more PID's to be always true.

if you added:

if (pid == MAF_AIR_FLOW) return true;
if (pid == FUEL_STATUS) return true;

before the long statement in the function, those two PIDs would always be allowed, even if the car did not actually support it. Asking for a PID the car does not support may or may not do something undesired. It should be harmless, but it's not my car...

With those or similar changes, you could try any PIDs you wish, even just a 'return true' to validate all PIDs as valid would work (though you would need to temporarily comment out the larger return statement.)

To sniff the data, just hijack the iso_read_data() function, and after you get a dataSize value other than zero, you could also stuff the data onto the LCD. To make it recognizable, format the data into hex format before sending it to the LCD (sprintf() would work). You could sniff the raw data, which would include header information, or just the returned data.
Using the header information, you could report only data you wanted to see. At 6 pid requests per second, there is a lot of data flying past...

[Demonhawk]

in the is_pid_supported function I'm going to try block quoting out the code in there and simply hard coding a return true; and seeing what that does. I'm about to go test it in my car and I shall return shortly with the results.

*Update: After commenting out the check I took the arduino and hooked it up to my car and tried it out. Didn't work so well. As soon as it tries to display one of the PIDs that weren't being shown as supported such as MAF or Fuel status it displays error and then a few seconds later it does a hard reset and begins trying to run the iso 9141 init again.

Also I figured out how to get it to connect to my car's ECU fairly reliably. The arduino needs to be doing a cold boot and as the ISO 9141 Init screen displays for the 1st time I start the car, or put the key in the ACC position and it seems to connect almost 100% of the time.

[dcb]

Did you try powering it from the car? I wonder if powering it from the laptop is isolating the signal ground path or something?

[Demonhawk]

I haven't tried powering it from the car yet. My biggest reason for this is that I am using a USB boarduino which has no 5v regulator. I purchased one but I am unsure of where I can apply the voltage. Unlike a regular arduino or even the standard DC boarduino; the power pins on this are not labeled 5v, gnd, vin. They are labeled 5v, gnd, 3v. I asked on their forums about it but the answers I've received aren't very helpful to me due to my complete noobness, lol.

You can see the response here adafruit industries • View topic - USB Boarduino - Quick Question

I don't know if it is bad or not, but I currently have everything sharing a common ground. I took the ground from the freescale chip and have it on the same line as the arduino ground.

[Froggy]

The restart after showing error, is likely a programming fault in the program, the function accu_trip() returns early when an error occurs, and perhaps it or something else is not setting a value, then another function uses that unset value and kablooey... Unintialized values are tricky to track down, and OBDuino uses a lot of globals...

One question here... if you are powering OBDuino from the USB port, what is powering the 33290 chip? If you are powering it from the USB port, it will likely be driving the K line at 5 and 0 volts, instead of 12 and 0 volts... The low voltage may be the crux of the problem. The chip should be powered via the OBDII cable, and the arduino board from the USB port. If that is what you are doing, then I don't know where to go next.