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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev