Recently I thought it might be fun to try poking around the Model S CAN bus, since the car is basically one big computer with almost all of the controls accessed from the large centrally placed 17" touch screen. As I once heard someone say, "The only reason the wheels are there is to stop the computers from dragging along the ground"

Before we dive into the tutorial lets answer some basic questions that might be nagging at you.

What is CAN?

CAN is a vehicle bus standard first introduced in 1983 by Bosch, it was designed to allow microcontrollers and other sensors to communicate with each other within a vehicle without a host computer, greatly simplifying what had traditionally been a rats nest of wires for even the simplest of features, e.g. high and low beams required wires directly connecting the headlights to the driver high/low switch. This meant lots of wire, sometimes hundreds of pounds worth of copper, not cheap and not easy to fix it if anything went wrong, as it often did cough...vintage Jaguar...cough

The network structure is fairly simple, commands are sent out over the CAN network (or networks some cars can have 3 or more) and can be received by anyone on the bus, but only used by those that can actually do something with them, e.g. lets say you press the drivers side window down button, a command is sent out to all the devices on the network but only the window motor controller actually does anything with it, hopefully rolling down your window.

What is OBD/OBDII

On-Board Diagnostic systems are in most cars and light trucks on the road today. During the '70s and early 1980's manufacturers started using electronic means to control engine functions and diagnose engine problems. This was primarily to meet EPA emission standards. Through the years on-board diagnostics and control became increasingly more more sophisticated, so in the 1996 the next generation called OBD-II became a mandatory requirement in most American automobiles, this improvement provided almost complete engine control and also monitoring of the chassis, body and accessory devices, as well as enabling diagnostic error code checking and clearing. More information can be found at the links below.

Why would we want to do any of this?

If you have to ask that, you might be in the wrong place. My answer, because it's FUN! (if not slightly nerdy)

Legal Disclaimer:

TL;DR: YOU (and only you) are responsible for your own derrière, don't do anything dangerous or silly and say it's my fault.

The information contained in this document is based upon information that is believed to be accurate to the best of my knowledge, but is provided without guarantee or representation as to accuracy. I disclaim and make no guaranty or warranty, expressed or implied, as to the accuracy or completeness of the information published herein. Use of the final product resulting from the project is at your own risk. I disclaim all responsibility for any resulting damage, injury, or expense. While nothing truly dangerous can come of simply looking at data from your car, please be aware that by accessing this port you can gain access to safety critical, Powertrain and High Voltage systems, while not scary by themselves, caution, respect, and common sense are highly recommended.

Step 1: Connecting to the Car (not As Easy As You Might Think)

These days it seems I spend half my engineering time just figuring out what kinds of connectors I need to buy, what their pinouts are, and how I am going to design an enclosure around them, good grief! There is something to be said about the ease of point to point wiring (except when you have to go back and debug 6 months later)

Connecting to the Model S was no exception, based on what I had read my first avenue was trying to connect to the OBD-II port located under the steering wheel. Some of you may be asking why a car that produces no tailpipe emissions would need to a diagnostic connector designed around emissions testing? Good question, as with most things in the auto industry they didn't do it because it was fun (seatbelt's anybody?), federal law requires a port to be within 2 feet of the driver/steering wheel.

So Tesla had to put one there, of course like most useless federal laws it doesn’t mandate that the OEM put out any useful data to it, in fact you could get away with just hooking up the 12V and GND plus any necessary emissions info (which is not the case for us) and have your own super-secret diagnostic connector elsewhere, but laziness prevails, so most OEM's just use the available free pins to output their CAN data, usually pins 6 and 14 for CAN high/low, though that depends on the type of vehicle and the standard it uses.

As I found out the hard way, when you're build a paradigm shifting electric car from the ground up, you decided to take the hidden diagnostic connector route. My initial tests using a Beaglebone Black and TI's SN65HVD Series CAN transceivers ended in lots of colorful language and much head scratching, in short Tesla ain't putting out, at least on this connector. Onward and upward!

Step 2: Making the Real Diagnostic Connector Part 1

If at first you fail, try and try again

After rooting around the TMC forums and some liberal Google searching (including images, very handy) I found that Tesla puts out their CAN bus info to a connector located behind the center cubby underneath the 17" touch screen (which you can access by giving a firm tug with both hands on opposite sides, see photos for more detail)

I then found a pinout shown in the included picture from a project some Tesla Roadster owners had cooked up to allow them to access their cars vitals over SMS (see the link in the References section).

These were the droids I was looking for, eager to see if my searching had been fruitful I thought to test the 12V and GND pins using my multimeter, which was a good idea and sure enough it showed 12V, then like the ham-fisted monkey that I am the two leads touched and shorted out, producing a nice arc followed by a puff of magic blue smoke, as a veteran of the magic smoke, I wasn't bothered until I noticed the drivers heads-up display was completely black, ugh oh...

I remembered from some of my earlier reading that another adventurous Tesla owner had tapped into the same 12V port for power and pulled more current than the connector could handle, thankfully Tesla had put a fuse on the heads-up screen so instead of smoking a very expensive piece of kit, it just tripped one of the automotive fuses under the front access panel, my bacon was saved. Sadly I didn't have any 5A fuses on hand and no NAPA or Ripoffshack stores close by, so my MacGyver style patch involved using a 15A fuse I had handy for the 12V cigarette lighter port, everything worked just fine until I got one shipped.

Step 3: Making the Real Diagnostic Connector Part 2

Lets get down to the details of the connector and how you can make one for yourself.

Parts List:

Note: You must buy the metal pins as well as the plastic connector, since they come separately, don't ask why.

Both parts are available from Mouser and I'm sure many other electronics retailers. Depending on what you have lying around you might also want to pick up some stranded 22AWG wire while you are shopping, I already had some hook-up wire so I just bought the connector.

Crimp your wires to the metal sockets, see photos 6-7, make sure the wire is snug, if you do it right the connection should be better than soldering, if you are extra paranoid you can add a drop of solder.
Slide sockets into the holes on the plastic connector until you hear a click
Take note of what wires correspond to what CAN buses using the pinout table
Thats it! Yay!

Step 4: Sniffing the Bus

Not wanting a repeat of magic blue smoke, I decided to take it cautiously with the poking and prodding of the diagnostic port by hooking up the Saleae logic analyzer. Since the CAN bus uses differential signaling (just like USB) there is no ground and signal wire, just CAN-H and CAN-L. Since the Logic doesn’t support that by default you need to hook your scope ground to the ground pin in the center of the car connector and then one of your signal cables to the CAN-Low, I found this out by perusing Saleae's website. Then you need to add a CAN decoder in their Logic software, I won't go over the details of these steps, since you can find lots a great documentation on Saleae's website. Plus most of you will just want to interface directly with a CAN chip and skip this step entirely, but I thought I would mention this as an alternative in the case that you had a logic analyzer handy but no CAN transceiver.

Quick Note: If you intended to save the data you logged to a CSV file from Logic make sure to save it from the CAN decoder menu (see screenshot 4) otherwise you will be reading your results in binary, not recommended for ones sanity.

Step 5: Installing Can-utils

We now return to the original goal of my project which was to use the Beaglebone Black to send and receive CAN messages. My main rational being that I am working on an electric car project and thought it might be prudent to learn the "how and what" of CAN networks to interface with gauges and like in a more professional manner, plus it's cool and thats reason enough for me.

In order to interface with the CAN bus on the Beaglebone you need to install can-utils, they are a set of the helpers written in C to make talking to a can system dead simple.

To install this you will need a Beaglebone Black running the latest version of Debian, (which comes stock on all new boards you might buy) some kind of internet connection (wifi dongle, ethernet, USB sharing) and a way to power your BB, I used my USB cable.

Step 1 is to SSH into your BB, do this by typing (on a Mac)

ssh root@192.168.7.2

into your terminal, this IP will only work if you are connected via USB and have the drivers installed.

Step 2:

Then run this set of commands, each line begins with a #, don't type that in your terminal though.

# apt-get update && apt-get install git   
# cd /tmp   
# git clone https://github.org/linux-can/can-utils.git   
# cd can-utils/   
# make   
# make install
# cd ~

At this point if there are no errors then you should have can-utils installed. Try running the command "candump" if you see a help guide come up, then you are ready to roll.

Step 6: Setting Your Phasers Correctly

After insuring I got the right port, I then hooked up the Beaglebone black with my homebrew CAN transceiver cape (see my other instructable for more details on how to make that)

Before you start the CAN interface you will have to enable the device tree overlay for it, since my simple cape doesn’t have EPROM to pass the Beaglebone any settings. For details on that please see this tutorial.

To start the CAN interface and set the communication speed, type the following commands

ip link set can0 type can bitrate 500000 listen-only on
ifconfig can0 up

The first sets your CAN interface as can0 and your transmission rate at 500Kb/s, the second brings it online.

Note: to take your interface down just type down instead of up for the second command.

Step 7: Logging Some Data

To start seeing some data just enter the following command in your terminal after following the previous step.

candump -cae can0,0:0,#FFFFFFFF

This will output all of the CAN messages (including errors) to your terminal window.

If you see something like this scroll across your screen, you can pat yourself on the back, everything is working normally.

(1423606588.555165) can0 00E#1E563FFF08FFA066<br>(1423606588.555434) can0 102#CA98F8FFEEFF
(1423606588.555881) can0 202#845E6B9D00007102
(1423606588.556169) can0 6F2#1634B40D1D43C3D0
(1423606588.556193) can0 212#5800227400
(1423606588.556455) can0 23A#000B001200050000
(1423606588.556678) can0 21A#FE0000FE000000B7
(1423606588.556902) can0 222#0000DA98F01070
(1423606588.557139) can0 29A#0000FE0000000000
(1423606588.557481) can0 27A#292903DC092600

It may look like your car just hurled a metric ton of information at you but that's normal, depending on the number of devices on the bus and how often they update there could be A LOT of messages to sift through. But its a little hard to sort through when they are flying by Matrix style in a command prompt, so just hit Ctrl-C to exit the program.

Next lets type the same command but change a few parameters:

candump -l any,0:0,#FFFFFFFF

This will log out all the data to a file in your current working directory, with a name that looks something like this candump-2015-02-10_221628 2.log

Once you have that, it's time to start looking at whats going on in the vehicle.

Step 8: More to Come

This is only the first phase of the project, currently I am still working on decoding the various CAN ID's and what their messages are. So please check back often for new data and information.

Update 03/11/15

After some very preliminary work I think I have figured out some of the ID's:

Frequency: Once a second

268, looks like a temperature on byte 3

412, data on 6 bytes, rolling and repeat on total of 16*6=96 bytes (after some research it appears not to be the VIN)

7E2, counter + data, looks promising

302, related to supercharging

Update 03/24/15

After gaining access to some Tesla documentation I managed to breakout what each of CAN the buses controls, this should hopefully speed up the decoding since I now know what I'm looking at.

CAN 2 - 10 Modules

Radio Head Unit
Door Control
Sunroof

CAN 3 - Powertrain - 9 Modules

Thermal Controller
DC-DC Converter
Charger 1 and 2
HV BMS
Charge Port

CAN 4 - Body Fault Tolerant

RCCM (Remote Climate Control Module)
PTC (Positive Temperature Coefficient) Air Heater
Memory Seat Module

CAN 6 - Chassis - 14 Modules (depending on options)

Power Steering
Stability Control and Braking
Air Suspension
Instrument Cluster and LIN Bus
Blind Spot and Parking Aid
TPMS
EPB(electronic parking break) ECU

Update 03/29/15

After some extensive internet searching, I managed to find this page from a Github project which decoded about 10 ID's and messages, I am still working on double checking these findings but I can confirm the following ID's:

Headlights ID:266
Charge Level ID:2C8
Country Code ID:398
Climate Control ID:268

I am still working on what bits in the string correspond to the different states.

Update 04/06/15

ID266 bit 1
Lights on, DRL running. on = 89 off = 8A.

Lights on, no DRL. off = 89 on = 88

ID268: Please see update in the post below

ID 268 Climate

bit 1 00=off 55=on 01=noise?
bit 2 00, 193, 232 7
bit 3 26 4D 74 9B C1 E8 07 26 45 68 87 A6 C9 2A 49 48 68 67 8B 8A AA A9
bit 4 Possible fan, 00 ramps to 02 then back, consistent with fan sound
bit 5 C1, C2, C3, C4 (193 194 195 196 in Decimal) possibly very steady temp in °C maybe 19.3?
bit 6 Also maybe fan 00 01 02 03 04 05 06 07 08 or outside temp
bit 7 Most likely set temperature in °C
bit 8 sample 00 40 50 60 70 80 90 A0 B0 C0 D0 EO 00 10

Update 05/17/15

After quite a lot of in-car time and some new hardware (kindly provided by the folks at TowerTech) I have managed to decoded almost all of the convenience bus (CAN2 for those keeping track) and a couple key devices on the chassis (CAN6). Below is a rough list of my findings:

Power mirrors + emergency flashers + turn signals
Passenger front/back window, though strangely not the drivers side
Radio unit
partial sunroof
VIN on two different buses
steering wheel position
brake pedal status
charging status and charge limit settings

Files:

CAN2 ID Decode

CAN3 ID Decode

Coming soon, CAN6

Also, after more research it appears that ID 268 is not related to the climate control.

Update 11/12/15

Sorry for the lack of any updates for several months, I have been quite busy with several other projects, plus I've been working on certain aspects of the MS CAN research that I'd like to keep private for now.

But here is what I can tell you, LOTS of progress has been made when it comes to the drivetrain system and related parts, including some noteworthy additions.

motor RPM
gear selector commands
charge port status
dc to dc converter voltages
main pack voltage
individual module voltages
charging current and voltage measurements, including some related to supercharging
HVAC temp and statuses
powertrain and battery cooling systems
and most interesting, a counter for the battery that tracks the lifetime Wh discharge of the battery since leaving the factory, very helpful for long term efficiency calculations

This is the result of many owners all sharing their ideas and car logs to get a better understanding of the variation between car models and firmware versions (of which there seems to be be a lot of in some cases), this game of "whack a mole" has made things a bit more difficult then expected but overall most core features seem to be relatively consistent among cars (even in different markets).

Many hours have been spent sitting cramped in the car, laptop in hand trying to intuit what the various ID's mean and how they relate to one another (lots of staring at graphs like the one above). Part of this situation has been improved by some better tools, first and foremost the CANtact, which has enabled me to write custom python apps for data logging and sending (including another killer app that I will hopefully be sharing soon). Also more recently I acquired a Kvaser Leaf Light which has spoiled me with professional grade software and reliable hardware, it sure is nice on the other side of the tracks.

There is a lot more to talk about but this is just a brief "heartbeat" status update to let you know that I am still working on the project and making headway. Stay tuned...

Step 9: References and Documentation (or Lack There Of)

Finding details on the Tesla CAN bus was tricky at best, not very surprising since most companies have tons of proprietary codes and addresses, which take time and patience to reverse engineer. Since there have only been (at the time of posting 02/19/15) some 50,000 Model S's made, there isn't a large mass of dedicated and able users to spend the time futzing around. Though to give credit where due, it seems there have been a fair number of projects that have tapped into the CAN bus, but few are well documented. Almost all my details have been scrounged or inferred from other projects and most involved a fair number of reverse engineering, including plenty of time spent on the logic analyzer.

Here is a small list of my sources to get you started in your research.

Open Vehicle Monitoring System mainly based on the Roadster but still applicable
Does the Model S have an OBD-II Connector
Roadster iPhone app project
Center Console Wiring Harness
Model S ethernet port
Strechla LIN Bus Hacking

I would also like to thank some of the generous members of the Tesla Motors Club forum for their invaluable support and expertise, you know who you are ;-)