a complete guide to hacking your vehicle bus on the cheap & easy – part 2 (interpreting the data)

OBD hackin part deux

in part 1 of this series, i covered the basics for how to interface with a vehicle bus using an inexpensive USB or Bluetooth ELM327-based scan tool. in part 2 below, i’ll go over how to actually use that hardware interface to collect and analyze data with the intention of discovering how to interact with the vehicle in some specific way.

for my own first project, i wanted to know how to intercept the steering wheel radio remote-control button press events. i replaced my factory radio with a Motorola Xoom 10″ Android tablet in order to have a bigger and better GPS (and OBDII app, and better entertainment options, etc). however, touching the screen precisely while driving can be difficult (especially when bouncing around off-road). hence why i wanted the factory steering wheel buttons to still control volume, track, play/pause, etc. i’ll use this goal as an example to walk through navigating the bus data.


 

what you’ll need

 

task 1: get a baseline

the first task is to gather some baseline data – i.e. what msgs are flying around the bus when your are NOT doing whatever particular interaction you are looking to find the msg for. i tested and found that with the vehicle not running, i could still use the steering wheel buttons to control the radio. that made things a little simpler since i would be able to gather all my sample data with the engine off and the key in “run” (there are way less msgs on the bus when the vehicle is not running).

  • issue the following commands (one at a time): ATL1, ATH1, ATS1, ATAL
  • be sure your serial terminal app is set to log to a text file.
  • issue ATMA to have the scan tool start reporting all of the bus msgs it sees.
  • just press enter after a minute to stop the stream of data.

 

task 2: log data from the event/interaction in question

the next task is to log the bus msgs when the action you are looking for occurs. this could be when something like when the radio changes tracks, when you press the sunroof close button, etc. i wanted to know the msg for each steering wheel button. i did a data collection run for each of the 6 buttons separately. for each run, i would press the same button 5 times, trying to space the presses evenly about 1 second apart. i wanted to create some sort of pattern that would hopefully stand out in the data stream.

  • repeat the steps from the previous task, while causing the event in question (or allowing it to happen if you have no control over it).

 

task 3: analyze the data

now you’re ready to analyze the data you collected in order to find just the bus msgs you care about. i used Excel, but you could go with any spreadsheet or database tool that you’re familiar with. the complete MS Excel spreadsheet for all the examples below can be downloaded here: 2003WJ-PCIBus-SWButtonData.xls

  • paste the data from each of your baseline/test runs into separate sheets of the spreadsheet. all the bus msgs should be in the first column. add a column header called “msg“.

sheetz

  • on the sheet with the baseline data, add a second column with the header “count“. just fill this column with a “1” for every row.

2-col

  • still on the baseline data sheet, create a pivot table that sums the count for each msg. this is just an easy way to give you a list of distinct msgs.

turn-n-pivot

  • now go to the sheet with your first sample data run. again use “msg” for the first column header and create a second column filled with 1’s called “count“.
  • for the third column add the header “not in baseline“. for the value of every row, specify a function that places the msg from the first column into this column ONLY if that msg is not in the baseline list. the function might look something like this (my baseline data pivot table is in the sheet named “baseline”, on column “D”):

=IF(ISNA(MATCH(A2,baseline!D:D,0)), A2, "")

you should end up with something like this, where the third column is a bunch of blank cells with only a few having msgs in them:

3-col

  • now create another pivot table similar to the previous. however, for this sample run sheet, use the “not in baseline” and “count” columns. this give you a list of distinct bus msgs that occurred during your test that were NOT duplicates of msgs from the baseline run. it also tells you how many times the msg occurred. you’ve basically removed the background noise from your data sample. if you’re after something really simple, this might be nearly the end of your journey. for my project, i needed to compare several of the buttons to really understand what was going on.

pivot once more

  • in the previous img, notice i had several distinct bus msgs that were not in my baseline. i had pressed the “up” button on the right side of the steering wheel 5 times for this test run, yet none of the distinct “not-in-baseline” msgs happened exactly 5 times! so i went ahead and repeated these steps for the other 2 buttons on the right side. below are the pivot tables i generated from each of the test runs.

dare to compare

  • now for some basic deductive reasoning and a little intuition. above i’ve highlighted in red all of the msgs that occurred at least 5 times – i knew that i definitely pressed the buttons distinctly and hard enough that they should have registered for each press, but perhaps they were sending multiple msgs if i held them down just a bit too long? next i crossed out any msgs duplicated between test runs (the 3 different buttons can’t be producing the exact same msg).

kris-kross

  • this left me with one unique msg to look at in 2 of the runs, and 2 unique msgs in the other run. however with this little data left, it was easy to spot a pattern – all 3 runs had a msg that was sent to bus ID 11. i guessed that 11 must be the radio’s ID, and the 3 distinct msgs sent  it must be my 3 buttons on the right side of the steering wheel.

 

task 4: test your hypothesis

  • you might next want to do a confirmation test, monitoring only the ID that you believe is sending the msg (ATMT#), or only the ID that the msg is destined for (ATMR#).

based on the deductions above, i thought i had the right 3 bus msgs. but why didn’t they occur exactly the number of times i pressed the buttons? i decided to perform another test, but only monitor ID 11 (the radio). hopefully my sample data would be small enough to look at directly and spot a pattern. again i tested each button separately, this time issuing the command ATMR11 to only see msgs destined for the radio. i pressed each button 5 times again, about a second apart. this time i was extremely deliberate and consistent in how i pressed each button. check out the results:

we have a GO

i think what is happening is a side-effect of mechanical switches known as contact bounce or chatter. i later saw that holding down a switch sends regular timed repeats of the msg, whereas a quick press can send from 1 to 3 msgs in rapid succession. this reinforces my suspicion of bounce.

  • another way to test your conclusions is to send the msg into the bus and physically verify the vehicle responds as expected. this would work for actions like locking/unlocking the doors, etc. i tried to replicate the “up” button on the right side of the steering wheel. if i was sending the right msg, then i would hear the radio increase volume (and see the display indicate the new level). the “up” button msg that i had monitored was 3D 11 04 00 C3, so i used the the command ATSH 3D 11 04 and then issued 00 C3. sure enough, it worked!

for all of the examples so far i’ve been working with the a SAE J1850 type bus. the msg structure and sample commands should work with most other protocols except CAN-Bus. you may have already inferred part of the msg structure:

3 byte header + up to 7 data bytes + checksum

the ELM327 reports the msgs in hex, so they look like this  (where PP = priority, RR = receiver ID, TT = transmitter ID, DD = data, CC = checksum):

PP RR TT DD DD DD DD DD DD DD CC

the msg structure for CAN is just a bit different, and the ELM327 has an entire set of commands specifically for working that protocol. check out the datasheet for complete info on msg structures and all the possible commands.

 

additional resources

  • walkthrough of a much more complex data gathering/analysis exercise (CAN-Bus, Mini Cooper)

http://bobodyne.com/web-docs/robots/MINI/CAN/MINI_CAN.pdf

  • Chrysler/Jeep/Dodge

http://www.canhack.org/

  • Audi/VW

http://secuduino.blogspot.com/2011/04/grupo-volkswagen-can-confort.html

http://www2.dasilvas.info/home/steering-wheel-buttons

  • BMW

http://web.archive.org/web/20041204074622/www.openbmw.org/bus/

http://www.reslers.de/IBUS/index.html

http://www.loopybunny.co.uk/CarPC/k_can.html

 

conclusions

you’ve likely surmised that vehicle bus hacking can prove non-trivial. it could be much more complex than my little example. i’ve read that some manufactures encode longer data across multiple standard msgs using custom schemes. deciphering something like that might be impractical. deciphering constantly changing data from a running vehicle is also challenging.

there are professional data collection and analysis tools/software, but you could also write your own. creating a simple application that time-stamps each msg in the log file would be a good start to help find patterns. adding the capability to graph msg frequency would be useful as well.

i came away from this project frustrated that the majority of data moving about in our vehicles is proprietary. it’s just another example of how society is moving away from a fix-it culture. if this type of information remains confidential, there is no hope of an individual or small repair shop fixing certain types of vehicle problems. we’re not far from a future where cars are as throw-away as iPads. one day i’ll have a Jeep that has to go to the Fiat/Chrysler Genius Bar. there i’ll find out that repairing whatever minor issue it has is too costly because everything is glued together, and that i’m better off buying the new model.

 

say something about this post

  • (will not be published)

31 responses to “a complete guide to hacking your vehicle bus on the cheap & easy – part 2 (interpreting the data)”

  1. Kenny Levinsen [website] Reply

    Hi!

    Nice writeup! I’m actually doing the exact same thing, in the exact same vehicle (Well, an ’02 2.7 CRD, but that doesn’t make much of a difference). I started a few months ago, and made my own J1850 implementation for a LeafLabs Maple, communicating with a Pi. Now it’s a Galaxy Note instead of a Pi (Didn’t really have the time to make my own UI, and can’t really compete with the tablets anyway), and I’m thinking of how to wire the things together.

    It’s very interesting to see how other people attack similar issues. Apart from my home-implementation of J1850, your data analysis approach was the exact same as mine. I also traced memory settings, mirror controls, speed, rpm, as well as other data. I need to implement a writing circuit for the Maple, as I think I might be able to control some of these things fairly easily (seats, mirrors, …).

    When I finally get ‘er wired up properly, I’ll do my best to trace out every last drop of data from the bus. I have some ideas in mind, such as increasing volume at speed, automatic play/pause on ignition, data logging, as well as completely useless but fun info, such as current gear ratio (including converter slip – Might be interesting if you’re towing, to estimate current transmission load? I have the feature, now I need to think of a use for it. ;) ).

    I completely agree with you on proprietary implementations. It’s the reason I rather prefer older vehicles with less fancy features, as it allows me to do it my way, instead of having to work around all the OEM crap (I really dislike having to bypass existing features – Either they’re going to be used, or they shouldn’t be there.)

    What amp are you using, btw? And in case you have the Infineon power amp, did you just tie amp enable to the acc line? I plan on having the tablet be in control of that line through the maple, allowing me to listen to music with acc off. Also, did you figure out a good way to have it turn on automatically, or do you simply allow it to go on standby when no power is connected (having the charger hooked to acc)?

    Anyway, I’ll share my findings… I’m sure I can find *something* of interest on that bus! (There’s *definitely* a lot of spam there… There HAS to be something)

    Have fun, and hack away!

    • theksmith [website] Reply

      i am using the factory infinity amp. i had to use a small pre-amp to get my bluetooth adapter’s output up high enough to drive the high-level inputs on that amp to sound good and have any bass. i used a small Lepai amp from Amazon, but i recently got a small Kinter from there too and i think it’s better (less noise at higher volumes) – i might swap it out.

      i plan to one day rip out all the factory audio stuff and put in a good aftermarket amp and speakers. then i can do away with the pre-amp. i’ll also use one of those 1/2 din EQ’s that have a single stereo input but 2 stereo outputs and a fader knob so i can get independent front/rear volume again. clarion makes an inexpensive one with good specs. i plan to mount the EQ inside the center armrest storage.

    • Brian Reply

      This is a great write-up. Does anyone have or know of a listing for the ID’s for the different systems? I know from this posting that the radio is “11” but I would like to know the locks, memory, etc…

  2. Trevor Cook [website] Reply

    Good Write Up.

    I seem to be linked in the BMW section of additional resources :)

    I have spent nearly a year now reverse engineering the Can ID’s of the BMW K-can bus. The BMW X1 contains 4 Canbus’s K-Can, D-Can, F-Can and PT-Can (this excludes the smaller k-bus, LIN-Bus and MOST media bus). Each bus deals with different application areas of the vehicle. The k-Can contains most of the ‘User’ controls, Air Con, Windows, steering wheel buttons, reverse sensors, dashboard display etc. The PT-Can links the engine management ECU, stability control and fuel pump etc. i.e the components you don’t really want to mess with!. However the buses are linked via gateway modules so some of the ID’s and data from the PT-can are available on the K-can.

    It is worth noting that the BMW does not send all commands across the PT-Can. This is the can bus that the OBDII connector is linked to. To use an elm232 to snoop things like steering wheel buttons you will have to tap into the K-Can bus at the rear of the stereo, at the PDC module in the boot or at the alarm sensor in the roof.

    From what I have seen my BMW X1 contains data packets that are very similar to E65, E90, E82, E87, BMW Mini’s etc…

      • LuCKy Reply

        Hi,
        is any way to configure ELM327 for reading/writing to BMW K-CAN bus (without gateway over PT-CAN bus)?
        Thank you.

        LuCKy

  3. Ryan Reply

    I’ve been thinking recently about a vehicle automation system and was considering replacing the in-built buttons (and radio, and… etc). This has given me a new insight on the project. Thanks!

  4. Matt [website] Reply

    Thanks for your write-ups! I, too, put an Android tablet in my dash. My goal was always to have it tap into the CAN-bus and I’m glad I have this info to reference. (oh my tab is the HTC Evo View 4G and the car is ’08 Subaru Legacy write-up here if anyone’s interested http://csmatt.com/notes/?p=5 )

  5. Ali KOTE Reply

    I like this job! Congratulations to you, Kristoffer. You are good.
    I own a Grand Cherokee 3.0 Overland. Your articles give me some ideas, they are the following:
    1. If possible, I would like to speak to the navigation system. The gps database of that system does not know my country (Senegal). I want to add an USB connector (there is not usb port on it) through which I can read my own database on an usb (external memory). I would also want to use this port for playing music and video clips in the car.
    2. Is it possible to tun some values in the motor to enhance it’s efficiency (more power and less fuel consum)?
    Thank you very much.
    A.KOTE

    • theksmith [website] Reply

      sorry i don’t know specifically how to do what you ask. these articles are meant to be an introduction to the topic and hopefully can help you get started if you choose to delve deeper into your vehicle. as far as tuning, something like a SuperChips module would probably be best.

  6. Manish Dwivedi Reply

    Really well written and useful blog. Really helpful. Thanks a lot.

    Also, I would like to understand if I want the output of my CAN bus on USB directly by opening the car wiring what would it take. Basically, as cars generally support only one of the several protocols, can I take the output on USB port and implement that OBD2 protocols on USB itself rather than OBD port ?

    • Frosty Reply

      Sorry mate, you wouldn’t be able just plug the can bus in to USB. you need something in between. hence the recommendation of the ELM based odb units. I remember seeing some work done direct to serial port, but there was still some circuit in place to aid in decoding.

      You’ll need something in place to interpret the car network (can bus) data into something the computer can understand. I picked up a cheap bluetooth ELM clone off ebay for 10 bucks, works like a charm.

  7. Frosty Reply

    Wow man, I’ve been toying with trying to snoop the button presses from the PCI bus for the steering wheel controls for a while now. I have an old Milestone i wanted to wire in for GPS/MP3/diagnotics but leave the factory sound system in place in my 2000 wj. You just made a major winter project into a weekend project!

    Great work man, great work!

  8. M.Wood Reply

    Outstanding! I found my way to your write up by blindly searching half cooked ideas to try on my ’03 WJ. Well done and thank you for posting it up for the rest of us. Now if you’d kindly turn your attention to the DRB III…LOL

    • theksmith [website] Reply

      thanks, yeah the DRBIII… i actually just purchased a Innova 3160 from Amazon for $200 so i could check the SRS code and clear my airbag light, and also needed to pull the extended codes for the transmission issue i was having. it worked perfectly for these 2 things, and compared to $3k for a DRBIII, it’s a bargain. of course it can’t do nearly all the tests and interactive stuff the DRB can – but at least i can do SRS, ABS and some extended codes on the WJ now. FYI – the Innova 3150 does nearly everything the 3160 does for $50 less.

      • M.Wood Reply

        I was just checking out the 3160 myself. Luckily, I have access to a similar unit for a small fee (usually beer). Now if there was an over the counter option for programming key fobs…I’d be all over it, dealerships are my only option around here. The cost of programming two remotes and one spare key is going to run me more than I would have ever imagined. Once again, great write up…keep up the hackin.

      • valentin Reply

        Hi, i’m french informatician and i think you’ve done a very good job! i’m actually triying to extract TCM’s DTC via OBD2, C-CAN or PCI Bus, and it’s hard to progress on it…. is that the 3160 have allowed you to get the transmission faults? and reset?

        • theksmith [website] Reply

          thanks! yes, on my 2003 Grand Cherokee i was able to read and reset DTC’s for the transmission. the options were under the “enhanced” menu after choosing Chrysler/Jeep for the vehicle make. the manual does say “Transmission DTCs are not supported on most Chrysler/Jeep vehicles manufactured prior to 2002″, but doesn’t mention any other makes/models specifically.

  9. Ahmet Reply

    Hi,
    I really liked your posts about CanBus and did many stuff on my car. Now, I want to control my android mobile phone with steering wheel buttons. Is there any chance for you to rewrite your steering wheel application so that it has bluetooth capability? Thanks.

  10. Sno Reply

    Excellent series of articles! Thank you for putting the time in to help the rest of us.

    I have just today started researching canbus hacking as I am planning a Nexus 7 install. One of the frustrations with a Nexus install is the requirement for a $85 radio adapter (just to turn the stock amp on through canbus), a $100 adapter to grab the canbus message from the steering wheel buttons, and another $50 adapter to convert the output of the adapter into key presses so android can recognize them. This info will likely condense all of those down into a single $20 OBD adapter. Granted, the software side of it gets more complicated, but that’s time not money. Add to that the ability to expand beyond just steering wheel buttons.

    And here I thought I was going to have to make some setup out of a beagle bone, compiled kernel, Linux canbus utilities, etc.

    • theksmith [website] Reply

      thanks, this is what i like to hear – someone that can directly use the info!

      the software side really isn’t hard. the time consuming part is figuring out the msgs you need to send/receive on the bus without buying all that hardware you mentioned and sniffing it’s conversations.

      hope to see you fork my github project. people keep asking me to do a bluetooth version but i just haven’t had the time.

  11. John Reply

    Have you ever been able to control the lights such as turn signals, stop or tail? That would be great when towing a vehicle behind another vehicle.

    • theksmith [website] Reply

      i never looked into that. my guess is not on older vehicles like mine.

      newer vehicles (usually CAN BUS based) often have “bulb out” warning systems so that tells me the control modules are at least aware of sections of lighting circuitry – but still unsure whether you could control individual bulb behavior with bus data.

      • John Reply

        I’d love to play with this but I can’t see sitting in the car with my IMac. Sure wish there was a simple program and cheep hardware where I could monitor and create messages from my iPad. Then I could just clip onto various busses and check it out.

  12. Shawn Reply

    Really great starter info here!

    I’ve got a 2008 Chrysler Aspen, picked up a bluetooth ODBII adapter, and your latest build. I’d love to contribute message info (doing a nexus 7 install!) to your database, but I can’t seem to get any data. When connecting a terminal app, I can successfully send AT commands to the interface, but an ATMA command (protocol = 0) always results in a “searching..” message and absolutely no data events come across. I know the adapter works as I was able to use other Android-based ODBII data apps to pull data in from various engine diagnostics/rpm/speed/gas, etc….

    Have you run into this? Nudge in the right direction?
    Once I can start seeing messages, I can start filtering down…

    • theksmith [website] Reply

      one of 2 problems likely…

      1) a lot of newer vehicles don’t return anything with ATMA because they are on a CAN bus system and have the diagnostic bus separated from the other more interesting ones. for those systems, the diagnostic bus only responds to specific queries and doesn’t just broadcast stuff all the time. in this case you have to wire directly into the bus you want to deal with – if it’s the “comfort” (interior systems) type bus, then you can splice in at the stereo harness.

      2) you might also just need to set the protocol manually. the “searching” msg usually indicates you don’t yet actually have communication with the vehicle. usually adapters start out with “auto” protocol detection (ATSP0), but if that’s not working then some of the other apps manually try each one (ATSP1, ATPS2, etc.) and issue a query after each one till they find a match – so you might need to do the same thing if you aren’t sure which protocol you need.

      i’m guessing you have both problems, i know 07 and above Wranglers are that way – sorry i don’t remember which protocol number you would need if you manually tap into the stereo harness, it’s one of the user-CAN protocols i think (maybe 6 or 7 or A or B depending on your ELM chip version).

      anyway, it’s a lot to have to tinker with just to get started i know – good luck!

  13. Carmelo Vella Reply

    Hi
    I am planing on removing all buttons from my car interior and to bond a tablet touch screen in the dash so that i can control everything via touch screen but i am not sure of what kind of components i need !!!
    My goal was to be able to control front wipers,rear wiper,electric windows,hazarts,ac,ecc !! but ineed to receive signals to deliver to the screen too like speed,fuel level,engine temp,ecc

    • theksmith [website] Reply

      sounds like a big project. what year/make/model vehicle? most of the information such as speed, coolant temp, etc. are all standard OBDII parameters that any OBD2 adapter and a program like Torque will give you.

      controlling everything depends greatly on your vehicle… on very new vehicles you might be able to control many components via the data bus, but on older vehicles you would have to wire up direct control of most circuits through some sort of electrical interface controlled by the tablet. there are bluetooth controlled 12v relay boards that might do much of this work (http://www.tinyosshop.com/index.php?route=product/product&path=141&product_id=371). however, if you have complex circuits like HVAC that need variable inputs to control them (and they can’t be accessed via the data bus), then you’ll need some sort of MCU like an Arduino to handle those.