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

[chickensevil]

Can someone explain why there is so much traffic? I mean why do we need to know motor rpm 100 times a second? Seems crazy. 10 Hz should be the maximum frequency sent out. Interpolation is arguably just as robust if finer scale is needed, but frankly I don't see the need. Most cars have bus rates that are much, much less than the Model S from what I gather.

To echo wk057, things like TC and ESP are so amazing on this car simply *because* of the response times on their devices. You want to change the RPM of the motor in order to adjust for loss of traction. If you were only getting data every 10th of a second then you could only make adjustments at that rate. And since you would get a piece of data, and then issue an adjustment, and then have to wait for the data to come back saying it had changed, if you were dealing at each thing happening every say, 10th of a second, then you are talking 3/10ths of a second to receive, send, and receive back again. This is a terribly high response time if you are trying to make adjustments on the fly to keep the car from losing control. Instead all of that can happen in 3ms, which is why you can feel the car making adjustments while driving in slippery conditions, but it doesn't even have time to light up the TC/ESP alarms on the instrument cluster because the changes are happening too fast.

Note that TC/ESP is just one area where faster message rates would be helpful.

 

[scaesare]

To echo wk057, things like TC and ESP are so amazing on this car simply *because* of the response times on their devices. You want to change the RPM of the motor in order to adjust for loss of traction. If you were only getting data every 10th of a second then you could only make adjustments at that rate. And since you would get a piece of data, and then issue an adjustment, and then have to wait for the data to come back saying it had changed, if you were dealing at each thing happening every say, 10th of a second, then you are talking 3/10ths of a second to receive, send, and receive back again. This is a terribly high response time if you are trying to make adjustments on the fly to keep the car from losing control. Instead all of that can happen in 3ms, which is why you can feel the car making adjustments while driving in slippery conditions, but it doesn't even have time to light up the TC/ESP alarms on the instrument cluster because the changes are happening too fast.

Note that TC/ESP is just one area where faster message rates would be helpful.

And for context, at 60MPH, that 3/10ths of a second is 26.4 feet.... more than an entire car length's worth of travel before the very first feedback of any attempt at controlling things.

For high-speed corrections, the bus is capable of the speeds, so why not take advantage of it?

 

[Cyclone]

To echo wk057, things like TC and ESP are so amazing on this car simply *because* of the response times on their devices. You want to change the RPM of the motor in order to adjust for loss of traction. If you were only getting data every 10th of a second then you could only make adjustments at that rate. And since you would get a piece of data, and then issue an adjustment, and then have to wait for the data to come back saying it had changed, if you were dealing at each thing happening every say, 10th of a second, then you are talking 3/10ths of a second to receive, send, and receive back again. This is a terribly high response time if you are trying to make adjustments on the fly to keep the car from losing control. Instead all of that can happen in 3ms, which is why you can feel the car making adjustments while driving in slippery conditions, but it doesn't even have time to light up the TC/ESP alarms on the instrument cluster because the changes are happening too fast.

Note that TC/ESP is just one area where faster message rates would be helpful.

This (plus the next point) is exactly how I explain why my RWD S is better on the snow/ice than my 4WD 4Runner (and yes, I know 4WD does nothing for stopping). The intricate control the S has, coupled with the fact that the computer could override my throttle inputs puts its TC/VSC far ahead. The 4Runner can redirect power to each of the 4 wheels, it can deploy braking, but it cannot control the idiot pressing the pedal to the floor. The S can.

 

[wk057]

So, coming back to this thread's original topic....

I've been working off and on with an idea for instrument cluster augmentation. So, I've started with native code that runs on the IC that picks out the variables I want from the ethernet frame broadcasts (which are basically CAN encapsulated in UDP). Pretty sure I have everything I could need from there, except I haven't exactly worked out the steering controls.... mainly because I don't have a steering wheel on my bench. lol. But my goal is to basically take over the display on the IC. There's tons of data available, so should be fun.

I suck at UIs, though, so my IC will probably look more like a linux command line when I'm done vs something a UI/graphic designer came up with. But, I intend to have tons of data displaying. An example is going to be basically a built in VBOX type of thing where it'll graph 0-60 runs and such. Should be awesome when I'm done. I'm also going to make it so I can pull up stuff on the CID via the browser to go through data.

A few people have suggested there would be a market for this kind of mod, but I don't think that I'm going to go there with it. I also don't know of a reasonable way to make this possible for others without just giving Tesla a simple way to make it impossible/difficult by patching to make it harder to get root. Someone suggested selling a modded instrument cluster with a steep core charge, since to do this you have to remove the IC anyway.

I have a few projects I need to finish before I get back to this one, but should be fun times ahead.

 

[TheBlackKnight]

To echo wk057, things like TC and ESP are so amazing on this car simply *because* of the response times on their devices. You want to change the RPM of the motor in order to adjust for loss of traction. If you were only getting data every 10th of a second then you could only make adjustments at that rate. And since you would get a piece of data, and then issue an adjustment, and then have to wait for the data to come back saying it had changed, if you were dealing at each thing happening every say, 10th of a second, then you are talking 3/10ths of a second to receive, send, and receive back again. This is a terribly high response time if you are trying to make adjustments on the fly to keep the car from losing control. Instead all of that can happen in 3ms, which is why you can feel the car making adjustments while driving in slippery conditions, but it doesn't even have time to light up the TC/ESP alarms on the instrument cluster because the changes are happening too fast.

Note that TC/ESP is just one area where faster message rates would be helpful.

Just a quick correction: the fastest frames are sent every 10ms not every 1ms. Still, that is 100 times per second. Receiving a frame that indicates a problem then sending a reply can be done in about 11ms - that is probably the lower bound for response time. If my math is correct that would seem to indicate that the amount of distance the car can cover in that time span (at 60MPH) is about a foot. Also, the inter-frame timing is not set in stone. If a module in the car believes the dung is about to hit the fan it is free to send an emergency message *NOW*. That's partly the reason for the priority scheme in can traffic - lower IDs take precedence over higher IDs. So, things like traction control, steering, and airbags have low IDs and thus can barge onto the bus any time they feel like and override anything else that was being sent. But, normal CAN traffic that relates to traction and such will probably keep its time slot except in emergencies. Still, they can cheat by having replies get triggered by reception such that it isn't really 10ms and you get a frame, 10ms later you send one, 10ms later they send a reply. Instead it is more likely that every 10ms one device sends an important message, another device receives it and instantly replies, then 10ms later the cycle repeats. You'll see that a lot in traffic where things go in bursts. So, likely the time delay is 20ms not 30ms. And, not a lot happens in 20ms.

 

[Denarius]

So, coming back to this thread's original topic....

I've been working off and on with an idea for instrument cluster augmentation. So, I've started with native code that runs on the IC that picks out the variables I want from the ethernet frame broadcasts (which are basically CAN encapsulated in UDP). Pretty sure I have everything I could need from there, except I haven't exactly worked out the steering controls.... mainly because I don't have a steering wheel on my bench. lol. But my goal is to basically take over the display on the IC. There's tons of data available, so should be fun.

I suck at UIs, though, so my IC will probably look more like a linux command line when I'm done vs something a UI/graphic designer came up with. But, I intend to have tons of data displaying. An example is going to be basically a built in VBOX type of thing where it'll graph 0-60 runs and such. Should be awesome when I'm done. I'm also going to make it so I can pull up stuff on the CID via the browser to go through data.

A few people have suggested there would be a market for this kind of mod, but I don't think that I'm going to go there with it. I also don't know of a reasonable way to make this possible for others without just giving Tesla a simple way to make it impossible/difficult by patching to make it harder to get root. Someone suggested selling a modded instrument cluster with a steep core charge, since to do this you have to remove the IC anyway.

I have a few projects I need to finish before I get back to this one, but should be fun times ahead.

I wouldn't want a fancy UI. Give me raw data! Tesla should really give us an easy way to do this, otherwise they are going to end up with a bunch of Frankenstein cars driving around so people can get the data they want.

 

[MikeBur]

So, coming back to this thread's original topic....

I've been working off and on with an idea for instrument cluster augmentation. So, I've started with native code that runs on the IC that picks out the variables I want from the ethernet frame broadcasts (which are basically CAN encapsulated in UDP). Pretty sure I have everything I could need from there, except I haven't exactly worked out the steering controls.... mainly because I don't have a steering wheel on my bench. lol. But my goal is to basically take over the display on the IC. There's tons of data available, so should be fun.

I suck at UIs, though, so my IC will probably look more like a linux command line when I'm done vs something a UI/graphic designer came up with. But, I intend to have tons of data displaying. An example is going to be basically a built in VBOX type of thing where it'll graph 0-60 runs and such. Should be awesome when I'm done. I'm also going to make it so I can pull up stuff on the CID via the browser to go through data.

A few people have suggested there would be a market for this kind of mod, but I don't think that I'm going to go there with it. I also don't know of a reasonable way to make this possible for others without just giving Tesla a simple way to make it impossible/difficult by patching to make it harder to get root. Someone suggested selling a modded instrument cluster with a steep core charge, since to do this you have to remove the IC anyway.

I have a few projects I need to finish before I get back to this one, but should be fun times ahead.

I'm sure everyone has their GUI of choice, and after playing whack-a-mole with a bunch of my colleagues we aligned on one choice for game data visualization in demo/sample code, imGUI: GitHub - ocornut/imgui: Bloat-free Immediate Mode Graphical User interface for C++ with minimal dependencies

 

[garygid]

Apparently the Cell Voltage info is only on the CAN3 (500k) bus, right?

And, the only "exposed" CAN bus is on the OBD, and it is CAN2 (125k) pins 1 and 9, right?

So, to use Jim's Spy program, which gets data from an OBD dongle, usually bluetooth,
one needs an TDC to OBD adapter. I have a mating connector (and pins) for the TDC,
but not yet an OBD connector like one would find in the car.

However, assuming that I get the connectors and pins, and make a "short" adapter cable
with CAN3 wired to the OBD pins 6 and 14, and connect ground and the "12v", the difficult
part for me is to find a way to get the end of this adapter from behind the cubby out to
the left side of the passenger's footspace. Anybody investigated this aspect?

Thanks, Gary

 

[smac]

My 60 kWh pack behaves subtly differently, and I receive 0x6f2's for 0-20 and 24-30, so I couldn't cut and paste code that relied on the stream being contiguous or having 32 items.

I'm also working in C#, so maybe not the perfect tool for this sort of stuff.
Volts seem a little high seeing as I'm at 79% SOC (could be a 60 thing?). It's 2c ambient here, however the car was on charge overnight and not that long finished.

I would really appreciate if anyone would eyeball my parsing. (I'm basically assuming the 7 bytes sent by the logger are a reverse order bit stream, split in 4 x 14 byte segments.) This seems to give the expected results, with the cells appearing balanced, but I could be missing something.


Msg 01 : 6B 74 1B FD 46 BF D1 11010110001011 10110110001011 11110110001011 11110110001011 4.093v 4.093v 4.094v 4.094v
Msg 02 : 6F 34 1B DD 46 B3 D1 11110110001011 00110110001011 10110110001011 00110110001011 4.094v 4.093v 4.093v 4.093v
Msg 03 : 6C 34 1B CD 46 AF D1 00110110001011 00110110001011 00110110001011 11010110001011 4.093v 4.093v 4.093v 4.093v
Msg 04 : 6B 74 1B FD 46 B3 D1 11010110001011 10110110001011 11110110001011 00110110001011 4.093v 4.093v 4.094v 4.093v
Msg 05 : 6F 34 1B BD 46 B3 D1 11110110001011 00110110001011 11010110001011 00110110001011 4.094v 4.093v 4.093v 4.093v
Msg 06 : 6D 34 1B CD 46 AF D1 10110110001011 00110110001011 00110110001011 11010110001011 4.093v 4.093v 4.093v 4.093v
Msg 07 : 6B 74 1B DD 46 B3 D1 11010110001011 10110110001011 10110110001011 00110110001011 4.093v 4.093v 4.093v 4.093v
Msg 08 : 6B F4 1A BD 46 B7 D1 11010110001011 11010110001011 11010110001011 10110110001011 4.093v 4.093v 4.093v 4.093v
Msg 09 : 6B B4 1A AD 46 AF D1 11010110001011 01010110001011 01010110001011 11010110001011 4.093v 4.092v 4.092v 4.093v
Msg 10 : 6B 34 1B 0D 47 BF D1 11010110001011 00110110001011 00001110001011 11110110001011 4.093v 4.093v 4.094v 4.094v
Msg 11 : 6E 34 1B BD 46 B7 D1 01110110001011 00110110001011 11010110001011 10110110001011 4.094v 4.093v 4.093v 4.093v
Msg 12 : 6D 34 1B ED 46 AF D1 10110110001011 00110110001011 01110110001011 11010110001011 4.093v 4.093v 4.094v 4.093v
Msg 13 : 6B 34 1B FD 46 C3 D1 11010110001011 00110110001011 11110110001011 00001110001011 4.093v 4.093v 4.094v 4.094v
Msg 14 : 6E 34 1B DD 46 BF D1 01110110001011 00110110001011 10110110001011 11110110001011 4.094v 4.093v 4.093v 4.094v
Msg 15 : 6D 34 1B BD 46 B3 D1 10110110001011 00110110001011 11010110001011 00110110001011 4.093v 4.093v 4.093v 4.093v
Msg 16 : 69 34 1B FD 46 BF D1 10010110001011 00110110001011 11110110001011 11110110001011 4.092v 4.093v 4.094v 4.094v
Msg 17 : 6B F4 1A AD 46 B7 D1 11010110001011 11010110001011 01010110001011 10110110001011 4.093v 4.093v 4.092v 4.093v
Msg 18 : 6C F4 1B CD 46 B3 D1 00110110001011 11110110001011 00110110001011 00110110001011 4.093v 4.094v 4.093v 4.093v
Msg 19 : 6B 34 1B DD 46 BB D1 11010110001011 00110110001011 10110110001011 01110110001011 4.093v 4.093v 4.093v 4.094v
Msg 20 : 6B B4 1A AD 46 B3 D1 11010110001011 01010110001011 01010110001011 00110110001011 4.093v 4.092v 4.092v 4.093v


Msg 24 : 20 82 90 B0 20 4C 09 00000100010000 01000010010000 11010000010000 11001010010000 6.64c 7.05c 6.38c 7.26c
Msg 25 : 07 82 8D 20 20 E4 08 11100000010000 01101100010000 01000000010000 10011100010000 6.33c 6.91c 6.27c 6.94c
Msg 26 : 00 02 8C 30 20 F0 08 00000000010000 00001100010000 11000000010000 00111100010000 6.25c 6.83c 6.28c 6.98c
Msg 27 : E8 01 87 B0 1F 58 08 00010111100000 00111000010000 11011111100000 01101000010000 5.95c 6.59c 6.19c 6.51c
Msg 28 : 14 82 89 60 20 B0 08 00101000010000 01100100010000 01100000010000 00110100010000 6.49c 6.71c 6.32c 6.78c
Msg 29 : 02 82 88 A0 20 A8 08 01000000010000 01000100010000 01010000010000 01010100010000 6.27c 6.66c 6.37c 6.76c
Msg 30 : 1F 82 8F 70 20 EC 08 11111000010000 01111100010000 11100000010000 11011100010000 6.62c 7.00c 6.33c 6.97c

 

[Turbo3]

smac, Thanks for posting that data it allowed me to understand the mapping and update TM-Spy so it now correctly displays voltage and temp data taken from a real Tesla.

I am impressed with how well the battery pack is balanced. Temps also show the difference between inlet and outlet temps.

 

[wk057]

I'm basically assuming the 7 bytes sent by the logger are a reverse order bit stream, split in 4 x 14 byte segments

Hmm... not sure how your logger works, but I don't think there is anything reversed. I ran this through my parser and got the same results you did, though. However, are the values you are pasting here altered? This is what I reconstructed from your info above using the hex values (I may have the indexes wrong):

000006F2 00 6B 74 1B FD 46 BF D1
000006F2 01 6F 34 1B DD 46 B3 D1
000006F2 02 6C 34 1B CD 46 AF D1
000006F2 03 6B 74 1B FD 46 B3 D1
000006F2 04 6F 34 1B BD 46 B3 D1
000006F2 05 6D 34 1B CD 46 AF D1
000006F2 06 6B 74 1B DD 46 B3 D1
000006F2 07 6B F4 1A BD 46 B7 D1
000006F2 08 6B B4 1A AD 46 AF D1
000006F2 09 6B 34 1B 0D 47 BF D1
000006F2 0A 6E 34 1B BD 46 B7 D1
000006F2 0B 6D 34 1B ED 46 AF D1
000006F2 0C 6B 34 1B FD 46 C3 D1
000006F2 0D 6E 34 1B DD 46 BF D1
000006F2 0E 6D 34 1B BD 46 B3 D1
000006F2 0F 69 34 1B FD 46 BF D1
000006F2 10 6B F4 1A AD 46 B7 D1
000006F2 11 6C F4 1B CD 46 B3 D1
000006F2 12 6B 34 1B DD 46 BB D1
000006F2 13 6B B4 1A AD 46 B3 D1
000006F2 18 20 82 90 B0 20 4C 09
000006F2 19 07 82 8D 20 20 E4 08
000006F2 1A 00 02 8C 30 20 F0 08
000006F2 1B E8 01 87 B0 1F 58 08
000006F2 1C 14 82 89 60 20 B0 08
000006F2 1D 02 82 88 A0 20 A8 08
000006F2 1E 1F 82 8F 70 20 EC 08

Outputs:

BMS_brick01_V_UI: 4.092795 V
BMS_brick02_V_UI: 4.093405 V
BMS_brick03_V_UI: 4.094015 V
BMS_brick04_V_UI: 4.094015 V
BMS_brick05_V_UI: 4.094015 V
BMS_brick06_V_UI: 4.0931 V
BMS_brick07_V_UI: 4.093405 V
BMS_brick08_V_UI: 4.0931 V
BMS_brick09_V_UI: 4.0931 V
BMS_brick10_V_UI: 4.0931 V
BMS_brick11_V_UI: 4.0931 V
BMS_brick12_V_UI: 4.092795 V
BMS_brick13_V_UI: 4.092795 V
BMS_brick14_V_UI: 4.093405 V
BMS_brick15_V_UI: 4.094015 V
BMS_brick16_V_UI: 4.0931 V
BMS_brick17_V_UI: 4.094015 V
BMS_brick18_V_UI: 4.0931 V
BMS_brick19_V_UI: 4.092795 V
BMS_brick20_V_UI: 4.0931 V
BMS_brick21_V_UI: 4.093405 V
BMS_brick22_V_UI: 4.0931 V
BMS_brick23_V_UI: 4.0931 V
BMS_brick24_V_UI: 4.092795 V
BMS_brick25_V_UI: 4.092795 V
BMS_brick26_V_UI: 4.093405 V
BMS_brick27_V_UI: 4.093405 V
BMS_brick28_V_UI: 4.0931 V
BMS_brick29_V_UI: 4.092795 V
BMS_brick30_V_UI: 4.092795 V
BMS_brick31_V_UI: 4.092795 V
BMS_brick32_V_UI: 4.093405 V
BMS_brick33_V_UI: 4.092795 V
BMS_brick34_V_UI: 4.09249 V
BMS_brick35_V_UI: 4.09249 V
BMS_brick36_V_UI: 4.092795 V
BMS_brick37_V_UI: 4.092795 V
BMS_brick38_V_UI: 4.0931 V
BMS_brick39_V_UI: 4.09432 V
BMS_brick40_V_UI: 4.094015 V
BMS_brick41_V_UI: 4.09371 V
BMS_brick42_V_UI: 4.0931 V
BMS_brick43_V_UI: 4.092795 V
BMS_brick44_V_UI: 4.093405 V
BMS_brick45_V_UI: 4.093405 V
BMS_brick46_V_UI: 4.0931 V
BMS_brick47_V_UI: 4.09371 V
BMS_brick48_V_UI: 4.092795 V
BMS_brick49_V_UI: 4.092795 V
BMS_brick50_V_UI: 4.0931 V
BMS_brick51_V_UI: 4.094015 V
BMS_brick52_V_UI: 4.09432 V
BMS_brick53_V_UI: 4.09371 V
BMS_brick54_V_UI: 4.0931 V
BMS_brick55_V_UI: 4.093405 V
BMS_brick56_V_UI: 4.094015 V
BMS_brick57_V_UI: 4.093405 V
BMS_brick58_V_UI: 4.0931 V
BMS_brick59_V_UI: 4.092795 V
BMS_brick60_V_UI: 4.0931 V
BMS_brick61_V_UI: 4.092185 V
BMS_brick62_V_UI: 4.0931 V
BMS_brick63_V_UI: 4.094015 V
BMS_brick64_V_UI: 4.094015 V
BMS_brick65_V_UI: 4.092795 V
BMS_brick66_V_UI: 4.092795 V
BMS_brick67_V_UI: 4.09249 V
BMS_brick68_V_UI: 4.093405 V
BMS_brick69_V_UI: 4.0931 V
BMS_brick70_V_UI: 4.094015 V
BMS_brick71_V_UI: 4.0931 V
BMS_brick72_V_UI: 4.0931 V
BMS_brick73_V_UI: 4.092795 V
BMS_brick74_V_UI: 4.0931 V
BMS_brick75_V_UI: 4.093405 V
BMS_brick76_V_UI: 4.09371 V
BMS_brick77_V_UI: 4.092795 V
BMS_brick78_V_UI: 4.09249 V
BMS_brick79_V_UI: 4.09249 V
BMS_brick80_V_UI: 4.0931 V
BMS_BMBtemp01_UI: 6.6368 C
BMS_BMBtemp02_UI: 7.0516 C
BMS_BMBtemp03_UI: 6.3806 C
BMS_BMBtemp04_UI: 7.259 C
BMS_BMBtemp05_UI: 6.3318 C
BMS_BMBtemp06_UI: 6.9052 C
BMS_BMBtemp07_UI: 6.2708 C
BMS_BMBtemp08_UI: 6.9418 C
BMS_BMBtemp09_UI: 6.2464 C
BMS_BMBtemp10_UI: 6.832 C
BMS_BMBtemp11_UI: 6.283 C
BMS_BMBtemp12_UI: 6.9784 C
BMS_BMBtemp13_UI: 5.9536 C
BMS_BMBtemp14_UI: 6.588 C
BMS_BMBtemp15_UI: 6.1854 C
BMS_BMBtemp16_UI: 6.5148 C
BMS_BMBtemp17_UI: 6.4904 C
BMS_BMBtemp18_UI: 6.71 C
BMS_BMBtemp19_UI: 6.3196 C
BMS_BMBtemp20_UI: 6.7832 C
BMS_BMBtemp21_UI: 6.2708 C
BMS_BMBtemp22_UI: 6.6612 C
BMS_BMBtemp23_UI: 6.3684 C
BMS_BMBtemp24_UI: 6.7588 C
BMS_BMBtemp25_UI: 6.6246 C
BMS_BMBtemp26_UI: 7.0028 C
BMS_BMBtemp27_UI: 6.3318 C
BMS_BMBtemp28_UI: 6.9662 C

So, basically the same as you, assuming your hex values above are exactly from the logger and not reversed in some way. 4.09V seems very high for 79% SoC unless the car was charging or otherwise had the charger enabled (running the heat from shore power or something). Mind sharing the raw log for 6F2 (one of all indexes) and 102 (a couple would be fine)?

 

[Ingineer]

Apparently the Cell Voltage info is only on the CAN3 (500k) bus, right?

And, the only "exposed" CAN bus is on the OBD, and it is CAN2 (125k) pins 1 and 9, right?

So, to use Jim's Spy program, which gets data from an OBD dongle, usually bluetooth,
one needs an TDC to OBD adapter. I have a mating connector (and pins) for the TDC,
but not yet an OBD connector like one would find in the car.

However, assuming that I get the connectors and pins, and make a "short" adapter cable
with CAN3 wired to the OBD pins 6 and 14, and connect ground and the "12v", the difficult
part for me is to find a way to get the end of this adapter from behind the cubby out to
the left side of the passenger's footspace. Anybody investigated this aspect?

Thanks, Gary

Easy, just pull off the 2 panels on the side of the console and the footwell area, then it will be an easy matter to route the cables.

 

[obrien28]

Easy, just pull off the 2 panels on the side of the console and the footwell area, then it will be an easy matter to route the cables.

I was just going to suggest the same thing, llavale did something similar because he had a center console in the way (I later found out why after reading a service bulletin), here is a photo if it helps Gary.

 

[smac]

So, basically the same as you, assuming your hex values above are exactly from the logger and not reversed in some way. 4.09V seems very high for 79% SoC unless the car was charging or otherwise had the charger enabled (running the heat from shore power or something). Mind sharing the raw log for 6F2 (one of all indexes) and 102 (a couple would be fine)?

Sure no problem (GVRET raw output, though probably not the same exact frames)

137229312,000006F2,false,Rx,0,8,00,6F,F4,1B,ED,46,B3,D1,
137329317,000006F2,false,Rx,0,8,01,6A,74,1B,FD,46,BB,D1,
137429311,000006F2,false,Rx,0,8,02,6E,34,1B,ED,46,B7,D1,
137529311,000006F2,false,Rx,0,8,03,6C,B4,1B,ED,46,AF,D1,
....


and a 102:
137531470,00000102,false,Rx,0,8,41,86,05,A7,09,4E,EC,00,



Finally the C# code (sorry being lazy with LINQ and iteration)

public override void Init(byte[] data)
{
// Get 7 bytes of real data, and turn them into bits
var ba = new BitArray(data.Skip(1).Take(7).ToArray());



var vs = new double[4];
// we are looking for 4 values
for (int j = 0; j < 4; j++)
{
int v1 = 0;
// loop thru 14 bits and add each bit value in its correct place.
for (int i = 0; i < 14; i++)
{
if (ba[(j * 14) + i])
{
v1 += (1 << i);
}
}

// perform scaling. Voltages in message parts < 24, otherwise temperature.
if (data[0] < 24)
vs[j] = v1 * 0.000305;
else
vs[j] = v1 * 0.0122;
}

- - - Updated - - -

And at 89% SOC



Msg 00 : 8B F5 61 5D 58 1B D6 11010001101011 11100001101011 10100001101011 01100001101011 4.181v 4.179v 4.179v 4.179v
Msg 01 : 85 35 61 7D 58 23 D6 10100001101011 00100001101011 11100001101011 00010001101011 4.179v 4.179v 4.179v 4.180v
Msg 02 : 88 F5 61 6D 58 17 D6 00010001101011 11100001101011 01100001101011 10100001101011 4.180v 4.179v 4.179v 4.179v
Msg 03 : 86 B5 61 6D 58 13 D6 01100001101011 01100001101011 01100001101011 00100001101011 4.179v 4.179v 4.179v 4.179v
Msg 04 : 83 B5 61 9D 58 1B D6 11000001101011 01100001101011 10010001101011 01100001101011 4.178v 4.179v 4.180v 4.179v
Msg 05 : 8B 35 61 3D 58 17 D6 11010001101011 00100001101011 11000001101011 10100001101011 4.181v 4.179v 4.178v 4.179v
Msg 06 : 84 35 61 5D 58 13 D6 00100001101011 00100001101011 10100001101011 00100001101011 4.179v 4.179v 4.179v 4.179v
Msg 07 : 83 75 61 6D 58 1B D6 11000001101011 10100001101011 01100001101011 01100001101011 4.178v 4.179v 4.179v 4.179v
Msg 08 : 86 F5 60 5D 58 17 D6 01100001101011 11000001101011 10100001101011 10100001101011 4.179v 4.178v 4.179v 4.179v
Msg 09 : 83 F5 60 3D 58 0F D6 11000001101011 11000001101011 11000001101011 11000001101011 4.178v 4.178v 4.178v 4.178v
Msg 10 : 83 35 61 9D 58 23 D6 11000001101011 00100001101011 10010001101011 00010001101011 4.178v 4.179v 4.180v 4.180v
Msg 11 : 88 B5 61 7D 58 27 D6 00010001101011 01100001101011 11100001101011 10010001101011 4.180v 4.179v 4.179v 4.180v
Msg 12 : 86 F5 61 7D 58 1B D6 01100001101011 11100001101011 11100001101011 01100001101011 4.179v 4.179v 4.179v 4.179v
Msg 13 : 85 75 61 7D 58 23 D6 10100001101011 10100001101011 11100001101011 00010001101011 4.179v 4.179v 4.179v 4.180v
Msg 14 : 87 B5 61 5D 58 33 D6 11100001101011 01100001101011 10100001101011 00110001101011 4.179v 4.179v 4.179v 4.181v
Msg 15 : 86 F5 61 7D 58 1F D6 01100001101011 11100001101011 11100001101011 11100001101011 4.179v 4.179v 4.179v 4.179v
Msg 16 : 85 B5 61 CD 58 2F D6 10100001101011 01100001101011 00110001101011 11010001101011 4.179v 4.179v 4.181v 4.181v
Msg 17 : 86 35 61 5D 58 13 D6 01100001101011 00100001101011 10100001101011 00100001101011 4.179v 4.179v 4.179v 4.179v
Msg 18 : 83 35 61 7D 58 0F D6 11000001101011 00100001101011 11100001101011 11000001101011 4.178v 4.179v 4.179v 4.178v
Msg 19 : 83 75 61 3D 58 13 D6 11000001101011 10100001101011 11000001101011 00100001101011 4.178v 4.179v 4.178v 4.179v
Msg 20 : 85 F5 60 3D 58 17 D6 10100001101011 11000001101011 11000001101011 10100001101011 4.179v 4.178v 4.178v 4.179v
Msg 24 : 58 03 DA 80 34 04 0E 00011010110000 00010110110000 00010010110000 10000001110000 10.44c 10.64c 10.25c 10.94c
Msg 25 : 47 C3 DA 40 34 D4 0D 11100010110000 11010110110000 00100010110000 10101110110000 10.24c 10.68c 10.20c 10.80c
Msg 26 : 32 C3 D4 90 32 94 0D 01001100110000 11001010110000 10010100110000 10100110110000 9.98c 10.38c 9.87c 10.60c
Msg 27 : DE 82 C9 80 31 60 0C 01111011010000 01100100110000 00011000110000 00011000110000 8.95c 9.83c 9.66c 9.66c
Msg 28 : 48 83 D1 80 34 78 0D 00010010110000 01100010110000 00010010110000 01111010110000 10.25c 10.22c 10.25c 10.52c
Msg 29 : 46 03 D7 D0 34 94 0D 01100010110000 00111010110000 10110010110000 10100110110000 10.22c 10.49c 10.31c 10.60c
Msg 30 : 5E 43 DC E0 33 88 0D 01111010110000 10001110110000 01111100110000 01000110110000 10.52c 10.75c 10.13c 10.57c


Example GVRET item:
109195540,000006F2,false,Rx,0,8,00,8B,F5,61,5D,58,1B,D6,

And next 102:
109187754,00000102,false,Rx,0,8,FF,88,05,A7,08,4E,F9,00,

 

[smac]

I was just going to suggest the same thing, llavale did something similar because he had a center console in the way (I later found out why after reading a service bulletin), here is a photo if it helps Gary.

View attachment 111309

OT, but I had to double take there!

 

[kennybobby]

...snip
And at 89% SOC

Msg 00 : 8B F5 61 5D 58 1B D6 11010001101011 11100001101011 10100001101011 01100001101011 4.181v 4.179v 4.179v 4.179v...

The code looks good to me, just striping off 14 bits at a time in the order received, and then packing them together to form the value.

What looks confusing to me is that the printing routine is displaying the binary value in reversed bit order, i.e. the lsb is at the left and msb to the right.

For example take the first binary listed above, 11010001101011b, = 13419d = 4.095 Volts, but you are showing cell 1 to be 4.181 V.

If i reverse the displayed bit order, 11010110001011b, = 13707d = 4.1806 V, which is your cell 1 voltage value.

And another way to check, looking at the hex bytes value for cell one should be 0x358B = 13707d.

Your voltages may be higher for a given SOC since you have the high capacity 60 pack...lol

 

[apacheguy]

@wk, @Ingineer - What's going on here? From earlier in this thread, the passive cooling target was 30 C. Now it's at 52 C?! This is on 7.1.

 

[cynix]

@wk, @Ingineer - What's going on here? From earlier in this thread, the passive cooling target was 30 C. Now it's at 52 C?! This is on 7.1.

See this post by wk: Let the hacking begin... (Model S parts on the bench) - Page 43

wk said Max Battery Power increases cooling targets to 50/52ºC, not sure why this screenshot shows 52/55ºC.

 

[smac]

The code looks good to me, just striping off 14 bits at a time in the order received, and then packing them together to form the value.

What looks confusing to me is that the printing routine is displaying the binary value in reversed bit order, i.e. the lsb is at the left and msb to the right.

Aha! It's the C# BitArray class. (Something I admit I never use in my day job)
{0x01, 0x02, 0x04} => {1,0,0,0,0,0,0,0, 0,1,0,0,0,0,0,0, 0,0,1,0,0,0,0} (so yes lsb is leftmost, and I'm just iterating this to produce a string for the binary output)

Your voltages may be higher for a given SOC since you have the high capacity 60 pack...lol

Well that is certainly an interesting point, do the 60's use more of the voltage range, or have I misinterpreted the data (I worry more about the latter as this stuff is quite a way from my area of expertise.)

 

[garygid]

I was just going to suggest the same thing, llavale did something similar because he had a center console in the way (I later found out why after reading a service bulletin), here is a photo if it helps Gary.

View attachment 111309

Ok, this MS has the center console installed, but the cubby/shelf is gone, right?

What if there is no console ... then remove the cubby, bend the TDC cable to the
right, and put the TD Connector through some large hole?

And, how does one get the two rear clips of the cubby back in place, please?

I will try again today, but suggestions for the no-console case welcomed.
Thanks