Talking to my car's OBDII port with an ELM327, a Raspberry Pi and Device::ELM327

Tweet

So my latest project involves trying to talk to my car via the OBD II port.

I found an ELM327 USB interface module for sale online for $15.  I figured for 15 bucks I can't go wrong.   I ordered it form FocalPrice.com, but I've checked recently and they don't seem to offer it anymore.  I guess I was lucky...

What I received was fairly basic: the cable and a mini CD with drivers and software on them.  I quickly discarded the CD as useless.

Being a software guy, I discovered the module for Perl that allows communication with the ELM327 (Device::ELM327).  You can download it through CPAN directly or from here: http://search.cpan.org/~aperrott/Device-ELM327-0.08/lib/Device/ELM327.pm  (Thanks to Alister Perrott for all his work developping this module)

My first thought was that I would install the ELM327 perl module on my Macbook and then be able to run fancy scripts and display cool graphics.  However, I quickly found out the my Mac would not talk to the ELM327.  Not sure why and I never got it to work.

On to plan B.

I have a spare Raspberry Pi (Rev A) that was doing nothing.  So I placed the Pi in my garage with a WiFi dongle and the ELM327 plugged into it via a USB hub.  Then I can log into the Pi remotely from my laptop anywhere in the house.  No need to be sitting in the cold garage.

The ELM327 Perl module worked out of the box, but it needed some cleaning up and extra error checking added.  What I discovered at first is that you don't need to have the ELM327 plugged into your car to be able to talk to it.  However, the Perl module would only go far enough to check that it was talking to the ELM327 and not if the unit was actually plugged into the car's OBDII port.  Along the way, I also cleaned up the handling of the debug print levels to make the output more usable.

Just a note (which is obvious, but worth pointing out).  In order to talk to your car, the ignition needs to be on.  If you want meaningful numbers for Engine RPM (for example), then the engine obviously needs to be running too.  But if you only have the ignition on (without the engine running), remember that you are draining your car's battery.  I forgot and had to jump it the next morning.

I've also learned that there is a whole set of standard information that can be read from your car that all car manufacturers follow.  A short but good description of the various PIDs can be found here: https://www.scantool.net/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=32
And there are a whole bunch of extra PIDs that are proprietary to the car manufacturer and are not visible nor not publicly available.

 My original reason for starting this project was because I have tire pressure sensors installed on my summer tires and on my winter tires.  So, each season, I need to take the car to the dealer to get him to swap the codes in the computer.  For some reason, it's not able to store more than one set of codes.  However, this falls in the area of Manufacturer Specific and I'm not sure yet if I'll be able to do it.  Fortunately I have a copy of both sets of codes, so theoretically I should be able to find them by scanning through all the PIDs.

UPDATE:

So I scanned through all the PIDs of Mode 21 (Toyota specific) and got back LOTS of data.  However, I don't know how to decode any of it.  Since the dealership was nice enough to provide me with a copy of my TPMS codes for both summer and winter tires, I thought I would be able to spot the codes in all the data.  But no such luck.  The codes are 7 digit hex numbers (73B7392 for example).  I didn't see this hex number anywhere in all the data I got.  I tried converting each character form ASCII into HEX but still no luck.  I've already tried sending the 0xHH00 codes for each mode (00 through 30) so I'll take a crack at dumping data from these other modes and see if anything pops up.

Check out my YouTube channel:    www.youtube.com/KedarWarriner