[Ovmsdev] The search for Tesla Roadster CAC
Tom Saxton
tom at idleloop.com
Tue Apr 16 09:19:30 HKT 2013
Mark,
That's great! I am very interested to see that graph, too. I will feature it
prominently in the Plug In America Roadster study report.
I'm also going to send email to all of the survey participants who haven't
yet submitted their CAC value and let them know they can now get the CAC
from OVMS, the Tattler, my log parser, and Doug's log parser.
Thanks so much for finding it on the CAN bus. That's a huge help to the
cause! Being able to check the CAC with OVMS made it much easier to work on
getting it from the log file.
Our Roadster is "redacted#3" at almost 4 years and over 32,000 miles with
the CAC at 149.97, so down 9% from a nominal new pack. We got a new battery
pack at 18 months and 14,000 miles, so we only have 18,000 on this pack, but
still I'm pretty happy with 9% loss after 4 years and a bunch of fun
driving.
Tom
on 4/15/13 5:47 PM, Mark Webb-Johnson wrote:
>
> The CAC starts to flow...
>
> C (redacted#1) rx msg S
> 98,K,-1,127,done,standard,282,262,13,-1,100,3,9,4,0,0,0,-1,145.51
> C (redacted#2) rx msg S
> 68,K,-1,127,done,standard,211,205,56,-1,100,24,7,4,0,0,0,-1,157.04
> C (redacted#3) rx msg S
> 95,M,-1,127,done,standard,178,154,32,-1,100,3,7,4,0,0,0,-1,149.97
> C (redacted#4) rx msg S
> 98,K,-1,127,done,standard,312,235,10,-1,100,11,1,4,0,0,0,-1,159.74
> C (redacted#5) rx msg S
> 96,K,-1,127,done,standard,285,218,16,-1,100,7,9,4,0,0,0,-1,146.18
> C (redacted#6) rx msg S
> 98,M,-1,127,done,standard,175,135,10,-1,100,4,9,4,0,0,0,-1,144.03
>
> The first six cars are reporting this. Lowest seems to be 144.03
> (corresponding to a 10% loss in battery capacity).
>
> It will be really interesting to see odometer vs cac, long-term.
>
> Regards, Mark.
>
> P.S. My only CAC just changed from 156.94 to 157.04, with the 2 year
> anniversary of the car coming up, so I'm happy :-)
>
> On 4 Mar, 2013, at 2:27 AM, Tom Saxton wrote:
>
>> Nice work, Mark!
>>
>> I'm very pleased to see CAC added to the OVMS toolset, both for the charge
>> time prediction algorithm and also so that owners will have a clean way to
>> get that important value.
>>
>> Being able to easily access the CAC value will also be quite valuable to the
>> Roadster survey.
>>
>> http://www.pluginamerica.org/surveys/batteries/tesla-roadster/
>>
>> Now I need to take another look at the log files. Knowing how it's encoded
>> on the CAN bus may make it easier to find the value in the log.
>>
>> Tom
>>
>> on 3/3/13 12:09 AM, Mark Webb-Johnson wrote:
>>
>>> 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 :-)
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list