More ELM327 Fun

On Friday I managed to do an alternator in the Sprinter, so I had the day off while one of the local auto electricians did an amazing job at putting me together a rebuilt one before close of business. In the end it cost me about $500AUD, but the absolute cheapest I could have found a new one for was $750AUD, and it would require a drive down to Tullarmarine and then I’d have to fit it myself if I wanted it running before Monday.

So since Friday was a wash, I basically spent Friday and Saturday fooling around with my ELM327 software. I got quite a bit done, including fixing up the buffering code to make sure I keep the interface in a sane manner, switching to higher baud and speeding up the polling considerably. Some folks claim on forums to be able to poll 45~50 PIDs/sec, and I’m still a good bit lower than that, so obviously far more work is to be done.

I’m still basically only working in mode 01. There’s code for pulling mode 03 diagnostic trouble codes, but I haven’t tested it yet because I don’t have a car that’s throwing codes, though I might just do something like unplug the MAF on my Commodore to see if I can get it to throw a code that way. I can definitely clear codes (mode 04), but that’s not really that interesting.

I’m planning on working on mode 09 next, along with making things nicer (like checking PID 00, to get a list of supported PIDs), but I figure I’ll just keep plodding along as I go. One of the primary problems I’m going to have to solve sooner or later is the fact that the various protocols will require different code paths to work with… do I split them out into classes? Children of the ELM327 class? How does one instantiate them as objects? OOP is still a new thing to me, and it doesn’t really make sense doing it that way.

Lots to think about.

Update: I got the PID 00/20/40/60/80 thing mostly working (I think so anyway, it looks like my Commodore only supports about 22 PIDs?), and set up the live data example to only poll supported PIDs - it’s significantly faster! I worked on reducing the timeouts for valid PIDs, but it turns out the ECU simply doesn’t respond at all if the PID is unsupported, so the ELM327 waits about 50ms before returning “NO DATA”… Removing all non-existent PIDs from the list we iterate through, and I believe I’m now at the point where Python itself is what’s actually slowing down the rates at which I can poll it (at least bumping the baud rate doesn’t seem to do anything).

Horsham, VIC, Australia

Author:

fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry