[Ovmsdev] The search for Tesla Roadster CAC
Mark Webb-Johnson
mark at webb-johnson.net
Tue Apr 16 08:47:19 HKT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130416/abd86251/attachment.htm>
More information about the OvmsDev
mailing list