Tom, 'roadsters', I'm searching for the CAC value on the Tesla Roadster. Here is a log extract. The first NOTE is just before we called up the diagnostic screen, and the second NOTE was after the screen had appeared. I also attach the matching diagnostics screen. 127.1062 NOTE PING: TD11 transmit 127.1236 400 01 01 00 00 00 00 4C 1D 127.1716 400 02 A3 01 80 C5 80 55 00 127.2220 400 01 01 00 00 00 00 4C 1D 127.2716 400 02 A3 01 80 C5 80 55 00 127.3220 400 01 01 00 00 00 00 4C 1D 127.3716 400 02 A3 01 80 C5 80 55 00 127.4220 400 01 01 00 00 00 00 4C 1D 127.4621 100 80 4B 92 00 64 00 7B 00 ->VDS Range (SOC 75%) (ideal 146) (est 123) 127.4633 100 9C 01 5C 01 ->VDS Trip->VDS (trip 34.8miles) 127.4716 400 02 A3 01 80 C5 80 55 00 127.5239 400 01 01 00 00 00 00 4C 1D 127.5687 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 127.5716 400 02 A3 01 80 C5 80 55 00 127.6236 400 01 01 00 00 00 00 4C 1D 127.6553 102 06 D0 07 00 00 00 00 40 VDS-> (message from VDS 06) 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) 127.6662 420 00 8A 8A 127.6665 588 00 00 84 127.6668 280 00 00 03 00 00 00 00 00 127.6670 1A0 00 00 00 00 127.6674 590 01 00 00 00 00 00 00 00 127.6717 400 02 A3 01 80 C5 80 55 00 127.7220 400 01 01 00 00 00 00 4C 1D 127.7716 400 02 A3 01 80 C5 80 55 00 127.8217 400 03 11 66 00 00 00 77 00 127.8719 400 01 01 00 00 00 00 4C 1D 127.9019 100 96 69 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits 69) 127.9217 400 02 A3 01 80 C5 80 55 00 127.9720 400 01 01 00 00 00 00 4C 1D 128.0244 400 02 A3 01 80 C5 80 55 00 128.0723 400 01 01 00 00 00 00 4C 1D 128.1253 400 02 A3 01 80 C5 80 55 00 128.1723 400 01 01 00 00 00 00 4C 1D 128.2221 400 02 A3 01 80 C5 80 55 00 128.2724 400 01 01 00 00 00 00 4C 1D 128.3221 400 02 A3 01 80 C5 80 55 00 128.3724 400 01 01 00 00 00 00 4C 1D 128.4221 400 02 A3 01 80 C5 80 55 00 128.4319 100 9B 2D 88 73 0C B9 C6 07 ->VDS (message to VDS 9B) 128.4724 400 01 01 00 00 00 00 4C 1D 128.5241 400 02 A3 01 80 C5 80 55 00 128.5388 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 128.5724 400 01 01 00 00 00 00 4C 1D 128.5939 NOTE PING: TD11 transmit Most likely candidate is the "102 06" being used to inform the VMS we are looking at the ESS SOC screen, then the VMS steaming a few message with the information requested. We've seen "102 06" a screen switch command, a few times in the past. It seems to awake dormant stuff in the VMS. Looking at the return data, we get: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) as likely candidates for the top part of the screen, and: 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) as the rest. For the 'rest', that it six pairs of A1 A2 lines, with an index value of 01 through 06, and then 12 bytes of data (2x6) for each. Kind of looks like the 6 lines of date based AH log. For the 9E, 9F and A0, we need to find: SOC LIM: 68% (0x44 single byte hex) SOC MIN: 68% (0x44 single byte hex) SOC MAX: 70% (0x46 single byte hex) CAC: 156.99Ah AR:91.54Ah #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) dRMS: 52A (0x34 single byte hex) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) Given: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) Here' s my working (both to show others how such a search is done, and also to document it): We can get rid of some easy ones: 127.6579 100 9E <SOCLIM?> FD 9C 8A 5B <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 B5 21 127.6590 100 A0 3B 34 00 30 02 11 01 Working: 5B8A(hex) = 23434(decimal) 9CFB(hex) = 40187(decimal) and 23434/40187 = 0..5831238957 while Ah/CAC (91.54/156.99) = 0.5833174026 So, those two seem to be good candidates. Interestingly: 40187 / 156.99 = 255.98 Could it be that? 9CFD(hex) = 40187(decimal). Then 40187/256 = 156.98 5B8A(hex) = 23434(decimal). Then 23434/256 = 91.54 Close, but no cigar. We're 0.01 off on the CAC. The Tesla loves bytes, and hates decimals (just like the PIC), so how about if we treat them as separate bytes (essentially rather than /100, try /256): 9C.FD (hex) = 156.99 5B.8A (hex) = 91.54 Woohoo! I think we may have a match. Plugging in these, and some of the other ones I found along the way, gives us: 127.6579 100 9E <SOCLIM?> <CACLSB> <CACMSB> <ARLSB> <ARMSB> <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 <kWhRLSB> <kWhRMSB> 127.6590 100 A0 3B <dRMSLSB> <dRMSMSB> <dAILSB> <dAIMSB> <dWhMLSB> <dWhMMSB> And the notes would be: SOC LIM: 68% (0x44 single byte hex) - 100 9E (B2) SOC MIN: 68% (0x44 single byte hex) - 100 9E (B7) SOC MAX: 70% (0x46 single byte hex) - 100 9E (B8) CAC: 156.99Ah - 100 9E (B4 . B3/256) AR:91.54Ah - 100 9E (B6 . B5/256) #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh - 100 9F (B8 . B7/256) RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) - maybe just from 100 80 (standard message) dRMS: 52A (0x34 single byte hex) - 100 A0 (B4-MSB B3-LSB) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) - 100 A0 (B6-MSB B5-LSB) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) - 100 A0 (B8-MSB B5-LSB) I did a search for '100 9E' in all my old logs, and find only one other: anon1_charge_heating049.txt: 0.0 100 9E 3F A1 9C 40 52 3F 42 ->VDS (message to VDS 9E) Not exactly surprising, as presumably that diagnostic screen would have had to be open, while the can log was being captured. Very rare. That is a charging log provided by one the the users here. I've labelled it anonymous, because I'm not sure if he publicised the data. Putting the same decode logic in, would give us for him: SOC LIM: 63% SOC MIN: 63% SOC MAX: 66% CAC: 156..63Ah AR: 82.24Ah I did a search for '9C FD' through the rest of my logs (including a large 20 minute one), and is did't show up anywhere apart from '100 9E'. So, my conclusion is that I'm pretty sure this is the CAC value, as well as a bunch of other techy metrics and the last six consumption history records. Nasty is that we have to request it (with a 102 06 D0 07 00 00 00 00 40). We could presumably stop the request (with a 102 06 10 …), but it times out after a while anyway. I think what I'll do is add that to the code for charge completion in vehicle_teslaroadster, and add a decoder to pick the CAC up off the bus and report it back. That way, we'll check the CAC every time a charge completes. If any other vehicles have a useful indication of overall battery health, they can use the same value. Regards, Mark. P.S. What is CAC? It is the "Calculated Amp-hour Capacity" and supposedly a very good indication of the capacity of the vehicle's battery.Tesla Roadster owners are using it to track long-term degradation of their batteries, and Tom Saxton will be very happy with me if I can get this back to him from a reasonable number of Tesla Roadsters. It will be my thank you to him for his work on charge completion time estimation, and definitely worth a few minutes CAN-bus logging in the car (but not so sure about the hours staring through those logs with a decimal-hex calculator :-)