OBD MPGuino gauge

[Demonhawk]

The freescale chip is being powered from the obd port. The only difference I have in the diagram is rather than having the power from the obd go to freescale chip and the arduino I just have it going to the freescale chip. All the grounds from the obd port are grounded to the freescale chip and the arduino as per the diagram. I don't know if it makes much of a difference but the power from the obd connector in my car is 13v instead of 12v.

[Froggy]

Sounds good. The 13 volts from the car shouldn't affect the K line communications. The chip may clamp it down to 12, or may let it flow at 13, whichever, the car should be happy with it.

Do all the attempted PID's result in a reset of the device? (Set three PID's to a PID that you know works, then try the others. Note which work, and which causes a reset. There may be several that cause a reset.

Any 'fudged' ones that carry back any result? An error is an expected result if the the car does not wish to handle the PID request.

[Demonhawk]

If i have all 4 PIDS as "fudged" ones the top two will show as an error and then the bottom two will not show up and the arduino will lock up and shortly there after it will do a hard reset. If i have 3 unsupported PID's showing and 1 real one its about a 50/50 toss up. sometimes it will crash other times it won't. If i have only 2 "fudged" ones showing and 2 allowed ones showing it seems to be stable most of the time.

I'm thinking maybe a memory overflow is what causes the crashes? The more "fudged" PIDs I have showing the more likely it is to crash.

I'm still at a loss as to why my car won't report the data for MAF, and others, but the scangauge has no problem. :\

[Froggy]

Do any of the unsupported PID's display ANY data other then ERROR?

What about running the same unsupported PID four times (one in each corner), does it still show two ERRORs, nothing on the next two and lock up?

Yeah, it's odd how ScanGauge gets data that the ECU is not supplying through generic OBDII commands. Not sure how they are doing it...

[Demonhawk]

i haven't tried all of the unsupported ones. I'll test it out and see what happens. I'll also test and see what happens when i have the same PID 4 times.

[Demonhawk]

Well I tried all of them and none of them returned anything useful, they all just say error. When I tried the same PID for all 4 corners of the screen it just says ERROR in all 4 corners, but it doesn't crash. It seems that if I have 4 completely different PIDs that are "fudged" up at the same time the arduino will crash, but if I have atleast 1 real PID, or 1 duplicate PID the arduino doesn't crash it just sits there and displays ERROR as necessary.

[Froggy]

If all you get is ERROR or any of the unsupported PIDs, then the ECU is simply not responding to the PID requests. There is no use in querying unsupported PID's.

Best route now is to find out how to get that data we need since the ECU will not respond through the generic method.

[Demonhawk]

I think I might have an idea. My car meets the "ISO" specification regarding the pinouts and such. From what I've read online though the VAG-COM reader which is used for reprogramming the ECU in the VW/AUDI's actually connects using KWP2000- which is iso 14230. Only thing is my car will not INIT with either 14230 fast or slow, but it will connect to the 9141. Maybe my issue is that the actual protocol that is being used is the 14230 and not the 9141 which is why I'm unable to access those other PIDs.

Only problem is that it only init's with 9141 and not the others so I don't know.

[Froggy]

I was looking at the init code, and I am not suprised it won't connect up with 14230. I made an error in the code (I don't have a 14230 car to test it with...)

I will correct it in the next check in or two...

Until the update, try this:

replace this line of code (it's in the code twice):
iso_write_data(dataStream, dataStreamSize);

with this block of code (once for fast and once for slow inits):

for(byte i = 0; i < dataStreamSize; i++)
{
iso_write_byte(dataStream[i]);
}

There is still another error in the code (reading the response), but that should not be hazardous to init functions which does not validate the response anyways.

See what happens...

[Demonhawk]

ok i'll try it. Maybe the reason that it would connect with 9141 is because the protocols are extremely similar.


Edit: Update- I tried the updated code and neither 14230 fast/slow would connect.