Let the hacking begin... (Model S parts on the bench)

[S4WRXTTCS]

The following link might be useful to those following this thread trying to visualize the systems in the car.

Hacking a Tesla Model S: What we found and what we learned | Lookout Blog

 

[green1]

On a slightly more sinister note, aren't you a little concerned that Vladimir Ripyakarof will turn up at your front door (as opposed to Tesla personnel), and in true villainous style, threaten members of your family until you hand over the necessaries to steal or modify cars?

It would be easier to steal one with a tow-truck, or by stealing the keys, the amount of effort required to take apart the dash and make the connections is simply not worth it for any villainous purpose.

 

[Cyberax]

I ordered 100 of these connectors from Alibaba, they should arrive in a couple of weeks. I can send you a couple of dozens if you want.

You can also try searching something local for "FAKRA 4-pin B" connectors, but I was not able to find a good supplier.

 

[zdre]

Collin, the CANDue 2.0 sounds interesting. Are there any schematics?

I think we should all team up and roll a Model-S specific board with logging, MITM, etc. No need to make it Arduino "shield" compatible. 2 CAN busses, one on the PT bus, with jumpers to select which bus the 2nd CAN xceiver is on. Micro SD slot. Maybe even a WiFi module on the back so it can be accessed remotely without opening the dash.

It could even be constructed so as to fit right into the connector as a little "dongle", thus making it cheap and compact. Here's my quick 'n dirty mock-up:
View attachment 108037
(Please excuse the crudity of this model. I didn't have time to build it to scale or paint it, but you get the idea.)

Thoughts? Who is interested in such a thing?

I would love something that could log to SD card with configurable filtering and automatic uploads of rolled logs to dropbox/Google spreadsheets or similar when connected to wifi. I was going to attempt something like this for myself but don't know if I will ever get to it.

 

[apacheguy]

I would love something that could log to SD card with configurable filtering and automatic uploads of rolled logs to dropbox/Google spreadsheets or similar when connected to wifi. I was going to attempt something like this for myself but don't know if I will ever get to it.

Right. I guess I have two design suggestions:

1. Ability to view all parameters on the fly. Ideally, the wifi antenna would be operated in access point mode and I could point my browser to a web page and see all voltages, pump speeds, temps, etc.

2. Ability to connect to my home wifi and upload stored logs to my home server.

 

[TheBlackKnight]

Looks like you're a little late to that party on that: Reading Battery Voltages and Temperatures via CAN on Model S

On that note, I haven't verified the EVTV findings on 0x6F2 just yet. Looks good, but I have a feeling the voltage is probably less convoluted than expected.

Yes and no. Yes, he started that thread long before I posted. But, the details changed. At that point we believed that the voltage was a simple question of dividing by something to get the proper cell voltage. It isn't. You'll see as you go through various states of charge that it isn't a simple divisor. Instead it appears to have some number as an offset and then a divisor (as in my post - reading/3072 + 2.385). Now, I believe that equation has since been tweaked a bit to be more accurate but it still does match the data we have. So, I'm fairly confident that it is accurate.

 

[TheBlackKnight]

Right. I guess I have two design suggestions:

1. Ability to view all parameters on the fly. Ideally, the wifi antenna would be operated in access point mode and I could point my browser to a web page and see all voltages, pump speeds, temps, etc.

2. Ability to connect to my home wifi and upload stored logs to my home server.

Since a wifi chipset can only be in one of those two modes at a time (either connecting to an AP or being an AP) I would suggest that you really don't want to muddy the waters too much by switching that often. Ideally a device should be in only one of those two modes 99% of the time. Mostly devices will work by being an AP for setup purposes and thereafter be in client mode forever more (or until your AP changes). But, putting in your car means that potentially you could be anywhere while testing. So, in that case you'd want AP mode. So, for simplicity it might be best to always be in AP mode. Then, if you need to download logs from the thing you just point your laptop or home server to the thing and pull them off. Being able to switch back and forth all of the time just sounds like a recipe for confusion.

 

[apacheguy]

Hmm. I don't see the confusion. If a known wifi network is in range, connect to it and behave as a client; else behave as AP. Seems fairly clear cut.

 

[TheBlackKnight]

Hmm. I don't see the confusion. If a known wifi network is in range, connect to it and behave as a client; else behave as AP. Seems fairly clear cut.

Yeah, that does sound like a reasonable plan. I suppose it wouldn't actually be confusing, anything connecting to it would just have to also know the options. Maybe first search for a known SSID that the device generates if it couldn't connect to an AP or use the connected AP to find it via some sort of broadcast ping?

 

[Cyberax]

Hmm. I don't see the confusion. If a known wifi network is in range, connect to it and behave as a client; else behave as AP. Seems fairly clear cut.

This requires some testing. A couple of years ago my laptop WiFi module couldn't act as an access point and scan for APs at the same time.

However, some new WiFi modules actually have two separate blocks - one for 2.4GHz and the other for 5GHz wireless. And you can actually program them separately, so you can have an AP constantly running at 5GHz and use 2.4GHz to connect to your network.

 

[lolachampcar]

Here is some data from my logger for a charge session to 220 rated (on a P85D).
Of note is-
data is currently at about 7 samples a second which will increase to the maximum speed allowed by 0x6F2 data frames (about one per three seconds)
I had to edit down the 272K file to get it within the 17K forum limit so I pulled out the end of charge and removed every other sample
The data conversion is as provided by WK which I assume is accurate because (1) he does not normally get stuff wrong and (2) he has the ability to feed CAN messages to the MS electronics and display the decoded results on Tesla's diag screen

I have added 0x102 supplied battery voltage and current to the above data set and will test this am. Getting a micro controller to build usable ASCII text files for direct viewing was a pain but it seems to be up and running. Once the battery health logging is done, I'm going to generate the burst performance data logging. It looks like the CAN data will support 100 Hz logging which should be good enough for performance analysis. My goal is to get the capability to log and then capture data before and then after my L upgrade.

 

[Kalud]

It seems that EVTV is releasing the full source for a program that reads this message so I see no harm in fully explaining that message here.

There are 32 messages in a constant loop. They transmit 96 voltages and 32 temperatures in series. The format is:
Byte 0 = The sequence # (0-31)
Thereafter, the data are stored as 13 bit values followed by a single bit value. The single bit specifies whether this value is a voltage or temperature. But, it's easier than that. The first 24 messages are all voltage and the next 8 are temperature. Each message has four values. For temperature it's easy. You divide the value by 100 and you have the temperature in centigrade. For voltage the situation is a bit weirder. It appears that the value returned is input to a linear equation. It looks sort of like the equation might be: cellVoltage = (Reading / 3072) + 2.385

There are 96 cell groups so the pack voltage is all 96 summed up.

If anyone knows of a better equation which is more accurate that'd be cool.

Hello Collin, thanks for your contribution.

For those playing with that ID, note that the temperatures reading are two's complement. The MSB is not a flag for temperature / voltage but rather a sign (in 2s complement).


-20.5C gives 11111100110011
+20.5C gives 00000011001101


As for the voltage reading, on my car (85kWh battery), after a 100% completed charge I found that comparing ID 0x6f2 with the different HV battery voltage reading in the car, the following equation works precisely:

cellVoltage = (Reading / 3072) + 2.379

ID 0x102: 102,8,DE,9C,B,A7,17,4E,59,1 -> HV Battery voltage 401.58V

ID 0x6F2:

- - - Updated - - -

Also, for those other data geeks out there.

Heating the battery pack from -6 degree Celcius with the battery coolant heater. Huge frozen mass, heating is about 2C/min Here's the temperature curve:

Cells before heating:

 

[jpet]

As for the voltage reading, on my car (85kWh battery), after a 100% completed charge I found that comparing ID 0x6f2 with the different HV battery voltage reading in the car, the following equation works precisely:

cellVoltage = (Reading / 3072) + 2.379

ID 0x102: 102,8,DE,9C,B,A7,17,4E,59,1 -> HV Battery voltage 401.58V

So at 100% SoC 401.58V / 16 / 6 = 4.183125V per cell on average

Earlier info that the cells are charged to 4.15 / 4.16V at 100% SoC does not seem to be correct.

 

[kennybobby]

That's interesting data champ, thanks for sharing. Can't wait to see your performance data with the L update, etc.


The CanIon android app for the Miev shows a bar chart of cell voltages for monitoring, for example to see when a cell lags and is starting to go bad.

Are the CAN H/L pins populated in the OBDII connector? If not then it might be possible to run the CAN wires out to those and then use an obd reader to send the data over wifi or blueteeth to a phone.

 

[LetsGoFast]

I'm copying over a useful post from jrichard that got moved to snippiness.

 

[jpet]

Here is some data from my logger for a charge session to 220 rated (on a P85D).

Interesting!

I've quickly analyzed the 22 samples and there's something strange happening at the end.
This is how the average cell voltage is increasing:

3,8991
3,9024
3,9051
3,9091
3,9123
3,9158
3,9188
3,9223
3,9253
3,9284
3,9319
3,9353
3,9382
3,9416
3,9448
3,9484
3,9514
3,9548
3,9578
3,9610
3,8687
3,8569

Look at the 2 last voltages? Are the 2 last lines in the wrong order?

 

[obrien28]

@kennybobby

Unfortunately in Tesla's infinite wisdom they decided to only output the CAN6 chassis bus to the OBD-II port, we are more interested in the Powertrain bus, so any hardware made will have to interface with the diagnostic connector.

@apacheguy
Personally I think the idea of having to constantly switch between AP and device is just fraught with things that "might" go wrong, as they say "the most reliable parts are the ones you leave out" alternatively KISS works too.

My approach is to use the Particle Electron (which has built in cellular) to connect to the internet and broadcast any data you please to a server of your choosing, that way you can access it on-the-go, but can still have it logging to a central location. If you or anyone else would like to contribute help with the software, I'm more than happy to workout some kind of hardware/PCB design (more my skill set). I don't receive my Electron for another month or so, but I figure for now I could get things running on a Photon (WIFI only) as a proof of concept, then it's only a matter of which device to flash it to (Particle takes care of the internet connection details), as another bonus Particle is dropping a new firmware version that support the STM32XX's onboard CAN controller sometime next week.

This approach has the advantages of being cheap, small, and easy. No cords, wifi connection issues, or tomfoolery to muck about with, just plain and simple logging (with a viewer of your choice), plus we could even add a MicroSD slot if people think it might be worthwhile. Whose with me?

 

[kennybobby]

Unfortunately in Tesla's infinite wisdom they decided to only output the CAN6 chassis bus to the OBD-II port, we are more interested in the Powertrain bus, so any hardware made will have to interface with the diagnostic connector.

Maybe use a pin extractor to take out CAN6 and put in CAN3-wired pins at the OBD-II, or connect or swap out the wires at the other end of the harness? Pins 6 and 14 in the OBD.

 

[obrien28]

Maybe use a pin extractor to take out CAN6 and put in CAN3-wired pins at the OBD-II, or connect or swap out the wires at the other end of the harness? Pins 6 and 14 in the OBD.

Seems like a bit of a pain given that a connector with everything we need and more is only 2 feet to the right, under the center console. Plus people would have to modify their vehicle which (unlike wk057) makes some uncomfortable (and the SC confused should they ever need to diagnose or repair something).

 

[jrickard]

Hmm! Lots going on here. I'll have to catch up on everything.

But, I figure I'll just come through and shake things up a bit, so: Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf

Well, if your interest is temperatures from the drive train, the Inverter actually has SIX sensors. I haven't had much luck mapping WHICH sensor is WHICH byte, but it looks pretty good.

0x306 1000 ms 8 bytes 4F 4D 6F 52 4D 4E AE 7D

The first six bytes all seem to be temperature values with byte 2 being the
Most volatile – probably motor temperature. It is transmitted once per second.
0x6F = 111 -40 = 71C

So single byte temperatures using a standard 40C offset. 0=-40C FF=215C

Excellent document Jason.

Jack Rickard