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

[wk057]

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

Interesting! Give me a bit and I will inquire with my bench CID/IC setup about this message. I should be able to work out what is what.

I need to catch up on this thread too. Was out yesterday and seems I missed a bunch!

 

[Andyw2100]

My goal is to get the capability to log and then capture data before and then after my L upgrade.

I'm wondering if you might be interested in / willing to also use TeslaLog, and see how that data compares to the data you're going to be able to capture. I imagine the data you will capture is going to be of much higher quality, but it might be interesting to see just how much higher.

The thread on TeslaLog, still currently free, is here:

TeslaLog.com - Your hosted Tesla Data Logger - Announcement / Support threads

Logging can be turned on and off, so if you wanted to, you could only log at times that you were doing performance testing. I've only been using TeslaLog a couple of weeks myself. Below is a graph and data from a launch I recorded (P85D, fairly cold weather, snow tires, close to 90% SOC), so you can see the information available. I fully recognize that it may not be detailed enough for you guys that are much more sophisticated with respect to this stuff than I am, but I found it interesting, and would definitely be interested in seeing how good the data TeslaLog can record is as compared to the data your logger is going to be able to record.

 

[jrickard]

The idea of building an open source board specifically for the Tesla is interesting. Yes, it would not have to be directly compatible with Arduino shields which would allow for more freedom in how it is constructed. I'm afraid I probably can't help too much with that as I work at EVTV and so it'd sort of be a conflict of interest for me. I'm actually not entirely sure of the open source status of the candue 2.0 board design. I don't believe that the design is really available out in the open but really if you're going to build a new board the relevant bits are easy to see. The GVRET firmware is open source so you can easily see pin assignments and even use the same firmware on the new boards so long as they use a SAM3X microprocessor. So, there are decent ways to jump start the process.

I guess I don't see the point. The Tesla SavvyCAN box is a box, a harness, and the EVTVDue CAN Microcontroller. That board is $99. The expense comes in connectors, wiring hte harness, and the enclosure. Which is why the Tesla box is $299. If you want to do it yourself, the board is $99. One CANBUS but very quick with an 84MHz ATMEL SAM3x, Arduino compatible, and with an EEPROM as well. It's all on one board. What are you going to save doing boards onesy twosy?

CANDue, on the other hand, has two can ports, the EEPROM, the SWCAN which you all will discover why you need later I'm sure, AND an Arduino Due and USB cable. And an SD card slot for logging. So yeah, it's $149. Big deal.

Either will run GVRET and SavvyCAN, but either will also run the software we released to do the 6F2. The magic here, and the magic you have to make with a new board, is actually Collin's can_due library. For me, I don't even think Collin has a clue how good this is. I love interrupt driven CAN and he's put in all the tools. Your board doesn't do anything UNTIL a filtered CAN message arrives, or in the case of no filtering, ANY CAN message arrives. You can route the interrupt to entirely different functions based on messageID. Bottom line is anytime I try to do any CAN work now without can_due, I end the afternoon feeling slimed. I need a shower. Collin's programming style is still for polling and switching there so I don't think he truly appreciates the interrupt routing in can_due.

As I recall, that's how we met. Talking about putting all the hardware features of the 2515 in a library for a Recharge Car Arduino Mega with a single CAN channel. We like had a conversation and the next day he had the library DONE. And can_due has come a long ways since then.

If you want to work toward something useful, I can see a Teensey version in the future with CAN ina really SMALL package. Maybe a bluetooth connection to SavvyCAN. But I won't put any effort into it until Collin gets can_due ported over if he does.

And again his modesty. BusMaster and SavvyCan are like Microsoft Paint and Photoshop. It's not even close. He's duplicated all the good parts of Vector's $10K suite. There's nothing even close to it.

The truth is, to decode Tesla CAN traffic we first had to build the tools to decode the CAN traffic because what was out there was so lame. Collin is modest and likes to be nice to everybody. I don't get it. What's that all about?

BTW. The 12v on the Tesla Model Diagnostics connector is on the same line as the Instrument cluster. And the fuse is the fourth from the left on the back row of the left fusebox. Don't ask me how I know.

Jack Rickard

- - - Updated - - -

@W.Petefish

Not to be condescending, but unlike Tesla I don't need to be cloak and dagger about the details of how the CAN bus works. I document what connectors you need and what buses are on what pins over at my instructable page (posted a year ago now) showing anybody whose interested how they can access a car they bought and paid for.

Based on my research the bus speeds are as follow:
Powertrain (CAN3) = 500kbps
Chassis (CAN6) = 500kbps
Body Fault Tolerant (CAN4) = 125kbps
Body (CAN2) = 125kbps

Now that I think of it, I should probably update my article to include that...

@apacheguy @lolachampcar

I am flirting with two different options (I may end up doing both), one is using the Particle Electron (I backed it on KS so I should be getting one in a month or so) to make a completely wireless data logger that could transmit back to dropbox/custom server or the website Teslalogs (which I'm co-developer on) possibly all of the above, the nice part is that you don't have to remember to keep the car on when you bring it back to your home and make sure you have WIFI coverage where you park the car. The second option is an in car data logger with display that mimics Tesla's thermal and battery diagnostics screens (not all of us want to open our dash like wk057), this hardware stack is based on the Beaglebone Black with a 7" LCD touchscreen, below is a beta version of the python app that me and another owner have built, still lots of work to do, not enough hours in the day.

View attachment 108029View attachment 108030

So will you be publishing a doc like Jason's diagramming the CAN messages used to display this info?

 

[Ingineer]

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.

This one fits ALL the female Fakra 4-pin types in the Model S (Blue, Black, and White), no modifications needed: HSD RF Connector Fakra Water Blue Jack Female Pin Straight Vertical PCB Mount | eBay

This one directly fits the male black one (IC/CID link), but with a little knifework, can be made to fit into the others: Antenna Connector Fakra A Crimp Female Straight Connector for Dacar 535 4POLE | eBay

 

[jrickard]

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:

Well,....er.....we hope. Now if you fully DISCHARGE your car and take the same readings, I think you'll find things don't match quite as well. This offset/scalar combination or "linear equation" comes up a lot in CAN. I think we're pretty close. You're at 3072/2.379. At 392 volts 3047.0f)+2.385 works well. And so on. So I don't think we have a nail in it yet. But I hope to keep comparing at different voltages as I drive the car down this cycle and eventually arrive at something that works across the expected span of 300v to 405v.

Jack Rickard

 

[Kristoffer Helle]

Is there a way to disable TC etc when you have root?

 

[dirkhh]

Well,....er.....we hope. Now if you fully DISCHARGE your car and take the same readings, I think you'll find things don't match quite as well. This offset/scalar combination or "linear equation" comes up a lot in CAN. I think we're pretty close. You're at 3072/2.379. At 392 volts 3047.0f)+2.385 works well. And so on. So I don't think we have a nail in it yet. But I hope to keep comparing at different voltages as I drive the car down this cycle and eventually arrive at something that works across the expected span of 300v to 405v.

Jack Rickard

Can you send me a few samples of raw data and what you think the real values are? I have some experience reverse engineering dense data logging formats (from a very different environment... dive computer data) and would love to give it a try...

 

[obrien28]

So will you be publishing a doc like Jason's diagramming the CAN messages used to display this info?

Well that depends Jack, are you going to release all of your research from the countless hours spent tinkering on your Tesla test bench, because after watching about ten feature length movies worth of EVTV it seems like you intended to only sell what you have learned as a kit for a high price. How very capitalistic, maybe I should get in on the fun? About the only thing you have shared thus far has been an ID that Arthur Hebert found and @Kalud improved upon (we do appreciate the lesson in Object Oriented C++ though).

 

[supratachophobia]

Is there any collaboration tool out there for the 3-4 of you on this project where you could share the info you learn as it happens? The reason I ask, is because I'm hoping some of us can form a similar group to work on the SDK when it's licensed and released in the hopes that it will streamline the development of complimentary/replacement apps on the main screen.

 

[Kalud]

Well,....er.....we hope. Now if you fully DISCHARGE your car and take the same readings, I think you'll find things don't match quite as well. This offset/scalar combination or "linear equation" comes up a lot in CAN. I think we're pretty close. You're at 3072/2.379. At 392 volts 3047.0f)+2.385 works well. And so on. So I don't think we have a nail in it yet. But I hope to keep comparing at different voltages as I drive the car down this cycle and eventually arrive at something that works across the expected span of 300v to 405v.

Neither my factor nor yours fit both side of the curve. Still some work to do.
I'd like to be able to get that critical factor though, would be much more useful. At least the temperatures are straight through (/100).

Tested with my pack at 6% (26 rated km left)

3072/2.379: SOC from ID 0x102 321.98V, conversion from 0x6f2: 318.06V

3047/2.385 SOC from ID 0x102 321.98V, conversion from 0x6f2: 316.76V

Tested with my pack at 100% (415 rated km left) after charging completed (balancing)

3072/2.379: SOC from ID 0x102 401.58V, conversion from 0x6f2: 403.59V

3047/2.385 SOC from ID 0x102 401.59V, conversion from 0x6f2: 401.59V (adjusted factors for that, that's why it fits 100% here)

- - - Updated - - -

I don't have much time today for further work, but if someone wants to play with the data:

6% real HV Voltage 321.98V
Voltages values without conversion factors (as read in the registers)

100% real HV Voltage 401.58V
Voltages values without conversion factors (as read in the registers)

 

[TheBlackKnight]

Neither my factor nor yours fit both side of the curve. Still some work to do.
I'd like to be able to get that critical factor though, would be much more useful. At least the temperatures are straight through (/100).

Thank you for the updated data. This data suggests that the equation would be more accurately:

CellVoltage = (Reading / 3274) + 2.49

So, that's my next guess. Is it the truth? Well, it seems like a bias of 2.5 would make more sense. That would bring the divisor to 3311. But, that seems a little less accurate.

I think that reading/3274 + 2.49 is the most accurate equation yet but might not really be the "correct" answer.

 

[jrickard]

Well that depends Jack, are you going to release all of your research from the countless hours spent tinkering on your Tesla test bench, because after watching about ten feature length movies worth of EVTV it seems like you intended to only sell what you have learned as a kit for a high price. How very capitalistic, maybe I should get in on the fun? About the only thing you have shared thus far has been an ID that Arthur Hebert found and @Kalud improved upon (we do appreciate the lesson in Object Oriented C++ though).

So, not to be condescending, but it would appear my inquiry has indeed hit a nerve. I'll drop it. It appears it is you with product plans...

Your characterization as to my contribution in all of this displays kind of an all encompassing ignorance of the thread. I've been working with Jason on some of this stuff for weeks and indeed took 6F2 to code from a vague description from Arthur Hebert, whom I certainly credited. At some point I brought Collin into it over some difficulties with bit shifting in the blind. Kalud has joined this rather recently, although productively I think.

In any event, you've made the potential of YOUR future contributions and plans very clear. I was curious.

As you have watched the last ten episodes of our video, you must be one of our most avid viewers. So I gather you are very much avid to GET CAN information, but unlikely to provide anything useful. We run into these. Getters. It's all good. I'm sure you'll do well with all that.

Jack Rickard

- - - Updated - - -

Neither my factor nor yours fit both side of the curve. Still some work to do.
I'd like to be able to get that critical factor though, would be much more useful. At least the temperatures are straight through (/100).

I agree. Still some work to do and it would certainly be nice to get this pinned down. Collin is very good at it if we can get him different data like this.

Unfortunately, I fear we have the same issue with temperatures. 100 doesn't work very well at all methinks. I'm currently using 76.0 but it is difficult to shoot the actual temperatures of the pack. Leaving the car sit for a couple of hours still, then comparing to ambient at floor level, I was at 17.7C measured and 76.0 seemed to work very well.

But if I charge hard to raise the temperature, I'm at a little loss as to what to compare it to. IR temperatures of the pack case at various points kind of vary. And inserting a probe in a pack in a car is non-trivial. The program does produce an average pack temperature so that's what I'm matching to with the ambient. But I think we'll find the same kind of linear equation with the temperatures. Just a guess. But the only way I know of reversing these is to map them to a series of points using actual values. On battery pack temperature, I'm a little lost as to what to use....



Jack Rickard

 

[Kalud]

Thank you for the updated data. This data suggests that the equation would be more accurately:

CellVoltage = (Reading / 3274) + 2.49

So, that's my next guess. Is it the truth? Well, it seems like a bias of 2.5 would make more sense. That would bring the divisor to 3311. But, that seems a little less accurate.

I think that reading/3274 + 2.49 is the most accurate equation yet but might not really be the "correct" answer.

Thanks for this, I did test another data point. 66% SOC, HV Voltage from 0x102 being 383.44V. With your new conversion factor I get 373.55V...

Summary:

SOC%  Real V  Converted
  6   321.98   321.96
 66   383.44   373.55
100   401.58   401.56

- - - Updated - - -

I agree. Still some work to do and it would certainly be nice to get this pinned down. Collin is very good at it if we can get him different data like this.

Unfortunately, I fear we have the same issue with temperatures. 100 doesn't work very well at all methinks. I'm currently using 76.0 but it is difficult to shoot the actual temperatures of the pack. Leaving the car sit for a couple of hours still, then comparing to ambient at floor level, I was at 17.7C measured and 76.0 seemed to work very well.

But if I charge hard to raise the temperature, I'm at a little loss as to what to compare it to. IR temperatures of the pack case at various points kind of vary. And inserting a probe in a pack in a car is non-trivial. The program does produce an average pack temperature so that's what I'm matching to with the ambient. But I think we'll find the same kind of linear equation with the temperatures. Just a guess.

Jack Rickard

I've observed the temperatures around 0C and it looks good to me so far, regen limitation from 0C to 10-12C seems to match the temperatures. I think the best would be to insert a probe in the coolant loop or something like that. Also. the various temperatures values on the drive unit should also match, lets say in a permanent regime with stable outside temperature, car ON (neutral + parking brake) for a little while with limited energy consumption. Everything should be about the same (coolant inlet vs outlet). And the cells should pretty much match that temperature.

EDIT:
I need to add that if the passive cooling target is still set to 30C in this software version, I have the fans kicks in when charging and cells getting to 30.0C (with a /100 factor). Someone wk057/Ingineer could you please post the current Passive, Active cooling and active heating targets from the Thermal Management screen.

 

[wk057]

I hadn't included 0x6F2 in my document partly because I hadn't been able to verify the way the values work. I'm going to work on that and temperatures tonight. I'll be pretty simple to figure out playing values to my bench one bit at a time.

 

[Kalud]

I hadn't included 0x6F2 in my document because I hadn't been able to verify the way the values work. I'm going to work on that and temperatures tonight. I'll be pretty simple to figure out playing values to my bench one bit at a time.

Awesome thanks, pretty useful!

 

[wk057]

OK, spent 30 seconds on it before dinner. Voltages start at 0.0V and are in increments of 0.000305V. No crazy formulas, as expected. Edit/update: Yep, looks like someone wanted a 0-5V range to fit in 14 bits.

- - - Updated - - -

Temperatures are similarly simple. 14-bit signed value, no offset, 0.0122C scaling. Gives a range from -100 to 100C

Edit: Lets see if I can identify Jack's temperature value before my wife calls me...

 

[Kalud]

OK, spent 30 seconds on it before dinner. Voltages start at 0.0V and are in increments of 0.000305V. No crazy formulas, as expected. Edit/update: Yep, looks like someone wanted a 0-5V range to fit in 14 bits.

- - - Updated - - -

Temperatures are similarly simple. 14-bit signed value, no offset, 0.0122C scaling. Gives a range from -100 to 100C

Edit: Lets see if I can identify Jack's temperature value before my wife calls me...

Great!

This gives me the following:

SOC%  Real V  Converted
  6   321.98   322.66
 66   383.44   374.18
100   401.58   402.15

 

[wk057]

Here you go, Jack:

0x0306

Temperatures are 1C scaling, -40C offset




byte0 = inverter PCB temp
byte1 = inverter temp
byte2 = stator temp
byte3 = DC capactitor temp
byte4 = heat sink temp
byte5 = coolant inlet temp
byte6 = inverter temperatue percentage - 0.4% scaling
byte7 = stator temperature percentage - 0.4% scaling

I'll stage this stuff for inclusion in my next document revision.

- - - Updated - - -

This gives me the following:

SOC%  Real V  Converted
  6   321.98   322.66
 66   383.44   374.18
100   401.58   402.15

Looks like my reported pack voltage doesn't always match the sum of the cell groups either. Probably a measurement margin of error there somewhere, for sure. However, the scaling I came up with 0x6F2 is completely accurate and verified on the display playing values from 0 to 0x3FF and watching it increment from 0 to 5V on the bench diagnostic screen.

 

[tom66]

inverter temperatue percentage

What does a "temperature percentage" mean? Is it scaled down?

 

[obrien28]

So, not to be condescending, but it would appear my inquiry has indeed hit a nerve. I'll drop it. It appears it is you with product plans...

Your characterization as to my contribution in all of this displays kind of an all encompassing ignorance of the thread. I've been working with Jason on some of this stuff for weeks and indeed took 6F2 to code from a vague description from Arthur Hebert, whom I certainly credited. At some point I brought Collin into it over some difficulties with bit shifting in the blind. Kalud has joined this rather recently, although productively I think.

Do you watch your own videos? Because if you did you might understand why I'm "touchy" on the subject of just sharing it all, given that you have done so little with the Model S. Your offering of Arthurs work (which was anything but vague) with a C program doesn’t strike me as much of an offering (at least you credited him), given the VAST NUMBERS of ID's that you have CRACKED (your words, from your video titles). I have been working on this stuff for months and Kalud and I have been working on ID 6F2 for almost a week and a half, trust me, we didn't just stumble onto the scene yesterday.

Regarding my commercial plans, yet again your own ignorance stands in the way, my intention (along with that of my co-developers) is to provide the hardware configuration and software free of charge and open source to the community (once we have it in a presentable state, might take a while given this is somewhat of a nights and weekends thing).

In any event, you've made the potential of YOUR future contributions and plans very clear. I was curious.

As you have watched the last ten episodes of our video, you must be one of our most avid viewers. So I gather you are very much avid to GET CAN information, but unlikely to provide anything useful. We run into these. Getters. It's all good. I'm sure you'll do well with all that.

As for being an avid viewer, I watch your videos with the same interest as the US does with North Korea and their bomb tests, curious to see what you are bragging about now but not interested enough to watch it from start to finish (unless it's at 2x speed). Your notion that my intentions are all about GETTING FREE STUFF are somewhat off the mark, given that I wrote the first publicly available article about connecting to the Tesla and getting information off the CAN bus in February of last year. Since then I have updated it with decodes as my work progressed and collaborated with almost a dozen Model S owners from every corner of the globe to track down the different configurations of software and options. Lately though, after hearing one too many times about how much the Dear Leader Jack knows, I decided to keep parts of my research private for now, sharing it only with owners I trust. Currently I have a google docs spreadsheet with ID decodes from three of the most prominent buses and extra information on hardware from research, trial and error and lots of work. Much like wk057 once I feel comfortable I will be releasing this entire spreadsheet to anyone who is interested. For now, I hope your paranoid fantasies that everyone is out to take stuff from you let you sleep at night.