[Ovmsdev] The search for Tesla Roadster CAC

Tom Saxton tom at idleloop.com
Mon Mar 4 02:27:18 HKT 2013


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





More information about the OvmsDev mailing list