Search My Blog

Sunday, April 28, 2013

Auto Scantool ODB-II Hacking with Android Tablet a complete guide to hacking your vehicle bus on the cheap & easy – part 1 (hardware interface)

Here's an interesting article on adding an Android to your Dash and using the Steering Wheel Buttons to Control it. And if nothing else is interesting to you. It explains how all of this OBD-II standards and the physical connection to the Data Link Connector work...

Don

Jeep Tablet Steering Wheel Buttons Interface

Video link...

https://youtu.be/T3BidW0OYek

Kristoffer Smith·18 videos

Published on Mar 10, 2013

A demo of the Jeep's factory steering wheel remote buttons controlling the tablet based carputer. This concept might also work on newer vehicles that use CAN-BUS (with some changes to the code).

Source code for the app here: http://github.com/theksmith/Steering-...

More info on the tablet install here: http://www.mp3car.com/worklogs/155150...

Category

Autos & Vehicles
License

Standard YouTube License

a complete guide to hacking your vehicle bus on the cheap & easy – part 1 (hardware interface)

modern vehicles have internal networks that provide access to nearly every major component and accessory – everything from the transmission to the cd-changer.
why hack it? because you can! maybe you want to install your own car-puter that will replace the radio and climate controls. or maybe you'd like to make your key fob roll up windows or remote-start. i'm sure you can think of something.

so that's different

it seems people often approach this concept with an Arduino/NetDuino/PIC/etc, plus a shield or some custom circuitry, and a bit of custom code. depending on your end goal, a microcontroller could be the best approach. however, this article is about getting started quickly and cheaply by leveraging a standard ELM327-based OBD-II scan tool (~$25) and your laptop, tablet, phone, Raspberry Pi, etc.
note: we're not talking about "pulling codes" or clearing the check engine light, that's everyday stuff. we want to control and get info from accessories attached to the more interesting buses.

all aboard the short bus (background)
in 1996 a federal law took effect requiring most new consumer vehicles in the US to have standards-based On Board Diagnostics, called OBD-II. the OBD regulations were put in place by the EPA for monitoring emissions related components, but the systems have evolved to be much more capable.

the good thing about OBD-II was it defined a limited set of network types that a car maker could implement for the emissions related diagnostics. this meant that tools to interface with those networks could also become standardized and inexpensive. called scan-tools, they come in full-featured versions with built-in software/display/buttons, and dumb versions that must be connected to a PC/Mac/tablet/phone to be useful.
what follows is information on how to use one of these inexpensive scan-tools (the dumb USB, Bluetooth, or serial-port kind) to interface with a vehicle in ways it wasn't exactly intended.
a couple ones that i've personally had success with:

USB: ScanTool ElmScan 5 (from Amazon…)
Bluetooth: BAFX Products ELM 327 Bluetooth OBD2 scan tool (from Amazon…)

step by step
the challenge: OBD-II standards only apply to the emissions related portions of a vehicle bus. other systems often operate on an entirely different bus which may or may not use the same protocol as the OBD-II diagnostic bus. even worse, the non-emissions-related bus data is proprietary manufacturer info that can vary for each make/model/year.
the good news is that for simplicity and cost-savings, most manufactures only implement a single network type during certain year ranges. since they have to use one of the standard OBD-II protocols for the diagnostic bus, they might as well use the same protocol (or a slight variation) on the other buses. this is why we are sometimes able to use a scan-tool to interface with a non-OBD bus.
from a high level, we need to:

determine what protocol(s) our car uses
make the physical connection
test the interface
start hacking

now onto those details…

step 1: which protocol?
vehicles usually have at least 2 buses, the main diagnostic bus and an interior or comfort bus. the diagnostic bus often has access to all the drivetrain components as well as the OBD-II emissions stuff. the simplest vehicles to hack are the ones where all the buses use the exact same protocol and all relay messages to each other. some vehicles may have the secondary buses connected to the diagnostic bus through a gateway that may only relay information when queried with the correct command. other vehicles use the same overal protocol on all buses, but different speeds.
buy a Factory Service Manual for your vehicle if at all possible. it will almost always tell you what you need to know to at least get connected and is full of great info. you can get FSM's used on eBay if your vehicle is a few years old or get the PDF version if you can find it. online tech libraries like AllDataDIY may have complete service manual info too. public libraries sometimes have subscriptions to those services. don't forget to just Google for your make/model and "OBDII protocol", "OBD bus", etc.
we are ultimately looking for the exact protocol that our target bus uses and any information about the messages that components on that bus send/receive. if we don't have this info, we can still try connecting to the diagnostic bus and hope it relays from our target bus.
the OBD-II spec allows for the following protocols: SAE J1850 PWM, SAE J1850 VPW, ISO 9141-2, ISO 14230-4 KWP, ISO 15765-4 CAN, SAE J1939 CAN. if our target bus uses one of those, or if the target bus relays to the diagnostic bus, then we can continue with our hack of using a scan tool to interface with it.
example: i was able to find online that my 2003 Jeep Grand Cherokee (WJ) actually supported 2 different protocols for the OBD-II system (due to a factory mistake). the FSM cleared up which one was the native protocol for the "Chrysler PCI Bus" (SAE J1850 VPW). it also confirmed that the radio and steering wheel mounted remote-control buttons communicated via that PCI Bus. using those buttons to control something else was my personal end-goal.

step 2: physical connection
the OBD-II spec requires a standard diagnostic port to be located within 3 feet of the driver and be accessible without tools. usually it's under the dash, right above your feet, and looks like this:

this is often the simplest place to access a bus. these ports will have certain standard pins populated depending on which OBD-II protocol the vehicle uses. there are also pins left undefined by the spec. car makers often bring out access to other buses on these optional pins so that their own proprietary scan tools can interface with the entire vehicle. consult that Factory Service manual you bought for your connector pinout or wiring diagram. here's the standard vehicle-agnostic pinout info:

important note: at this point you should move on to step 3 and try the main diagnostic bus first. if that doesn't get you the info you want, then come back here for how to tap into the correct bus directly.
if your vehicle's diagnostic port does have pins with access to the target bus, then you can take apart your scan tool and swap wires from the standard pins to the target bus pins. otherwise you may need to actually splice into a wire harness somewhere in the vehicle. you can get an OBD-II extension cable from Amazon/eBay for cheap and hack off the vehicle end to give you raw wires to play with. tip: the radio wiring harness is often a great place to get at the interior/comfort bus.
example: my FSM told me that pin 3 of the diagnostic port went to the radio-related bus. since my Grand Cherokee uses the single wire J1850-VPW protocol, i only had to swap one wire inside my scan tool from pin 2 to pin 3 to get a direct connection to the bus i was interested in. i later found out that all the buses in my particular vehicle relay between each other and so i didn't really even need to do that.

step 3: basic first tests
Read More...
http://theksmith.com/technology/hack-vehicle-bus-cheap-easy-part-1/

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

https://theksmith.com/software/hack-vehicle-bus-cheap-easy-part-2/

Auto Scantool ODB-II Hacking with Android Tablet a complete guide to hacking your vehicle bus on the cheap & easy – part 1 (hardware interface)

ODB-II hacking using an Android tablet

Jeep Tablet Steering Wheel Buttons Interface - YouTube

a complete guide to hacking your vehicle bus on the cheap & easy – part 1 (hardware interface) | theksmith

ScanTool 423001 ElmScan 5 Compact OBD-II Scan Tool and OBDwiz Diagnostic Software : Amazon.com : Automotive

BAFX Products (TM) - ELM 327 Bluetooth OBD2 scan tool - For check engine light and other diagnostics - Android compatible : Amazon.com : Automotive

Adapting the Nexus 7 for a double DIN car dashboard opening

theksmith/Steering-Wheel-Interface · GitHub

Tinkering with ODB II and the CAN bus - Hack a Day

Saturday, April 27, 2013

Video Player Built from the TI Stellaris Launchpad

This is a cool Video Player Project, using the TI Stellaris Launchpad. He mentions setting it up for the MSP430. I have one, of those. You can read more about my first experience with the MSP430, here... Beginners Guide to The TI MSP-EXP430FR5739 Experimenter Board So, I wonder if I could do this too? That would be a fun thing to do, with it:)

Don

ELECTRONICS - THE KING OF HOBBIES!: Stellaris launchpad based video player

Monday, April 22, 2013

Stellaris launchpad based video player

(stellaris launchpad playing 320x140 color video at 25 fps video)

Hi,

I am introducing my new mad project, a video player using stellaris launchpad and a 320x240 color lcd which I got from seeedstudio. I tried the lcd shield by connecting on an arduino board and loaded some example codes for the arduino and it was working fine. I made a small video player few months ago using atmega32 and a 128x128 color lcd. This time my lcd resolution is larger. I want to make a better video player this time, so I selected a 32bit processor with more speed and ram, and I already have one arm cortex m4 based board, the texas instruments stellaris launchpad board which I bought for 4.9$ (limited time offer).

I checked the arduino library code and written the lcd code for stellaris. To display stuff more faster I connected 8 bits of portb of stellaris to the 8 bit bus of lcd. At first I have some problems and later I found that few bits of portb is shorted with some other bits using zero ohm resistor r9 and r10, so I removed those. This is for msp430 launchpad compatibilit and it started to work. I displayed some patterns on lcd and confirmed it is working.

Later I configured uart in stellaris and streamed the image pixel data from pc to stellais and displayed it on the lcd. I used python image library in pc to convert image to 320x240 resolution and to get the pixel data from it.