pcmhacking.net

Greetings!

I know this is primarily a GM community, but it seems like y'all have a better grasp of things OBD-II than most everywhere else I've been around the web.

The case I'm working on right now is with my 2009 Lancer GTS and an ELM327 USB dongle that I have. I've written some simple python code to work with the ELM, and I thought I had a fairly robust setup that would grab the supported mode $01 PIDs and verify against the processed list before requesting another mode $01 PID. What's odd though is that when I tried to grab PID $0C after parsing $00, $20, and $40, my app said that $0C wasn't supported. I knew this was wrong and commented out the validation bit and tried again, and sure enough, I got the data back that I was expecting.

This lead me to try another experiment: in a loop, grab $01$00 repeatedly and print the result. The outcome? It seems to waver between 2 different responses erratically.

Is this a common issue? If so, is there a better way to get the supported PIDs than hitting every 32nd PID in mode $01?

It sounds like buggy ecu code to me. You could handle it like torque on android.. list the pids you could support and put a * next to the ones the ecu claims it supports but allow the user to pick any so if they know a pid is supported and the list is wrong they can still select it.

Or in your case, maybe try and read if each pid is supported 2 or 3 times and if any of them say yes, treat it as a yes.

I dont think that behavior from the pcm willl be something your likely to see on other cars.

Yeah, that's what I was thinking about. The other thing I considered was to just do a sweep of all standard mode $01 PIDs a couple of times then base the support on whether or not they respond with anything. Both seem kinda hack-ish, but I guess that's what it takes here. :-/

Thanks for the feedback!

Just wanted to share what I've found while sitting in my car right now: Same thing happens for $01$20: This is really annoying.