my CAC climbed back to more then 143Ah from a little less then 140Ah 5000km ago after traveling that distance within 6 weeks time and plenty of time between charges to balance the batterie pack out. Because of the distances, if charged several times in range mode too, making it sure to leave just after finishing charging leaving little time to balance. The reason, why my batterie pack appears in a relative good shape, i always traveled my long distance with average of 55mph while consuming 120-130Wh/km. Less consumption per miles means less degradation for the battery pack. Currently my reading is 143.09 Ah after more than 131.000km.
That sort of goes against the physics of lithium cells and why Tesla limits the use of higher SOC. Electrolyte solvent breakdown increases at higher voltages, independent of temperature, though higher temperatures can increase that breakdown as well. It is a chemical reaction after all. What you may be seeing is that cars with more time at higher SOC are not actually spending that much more time at those levels compared to other cars to show much of a difference.
"VMSParser.exe -b *.tar >output.txt" You'll need all of your log tar files in the same directory. It outputs in seconds. I know that my battery gets hotter in the summer than in the winter, but I think it's more about how hard you drive and then how long you let the car sit before charging (which cools the battery).
I have a theory on where the CAC is stored in the log file. I need values from a v2.x Roadster to test my theory, which requires capturing CAC values and log files at specific times. If you're interested in helping, send me a PM. I think the thing that hurts the battery is high current flow when the batteries are hot. Even short times there, like tens of minutes, may be a significant factor. In order to test for that, we need Roadsters with complete log file sets. How many owners have complete log sets?
What if each cell is fused (as in has an individual fuse) rather than switched? If a cell shorts, then a lot of current will want to go through that one cell which can easily blow an individual fuse isolating that bad cell from the brick. If a cell fails open then it's out of the loop anyways. Why have active control (via a transistor) vs passive (via a fuse)?
In the discussion subthread being referenced, it was proposed that the Roadster can balance 69 strings of single cells, one from each brick. Having a fuse on each cell won't do that. Each cell does have a fuse. See Tesla's 2006 white paper on battery design, "The Tesla Roadster Battery System" by Gene Berdichevsky, Kurt Kelty, JB Straubel and Erik Toomre. I wonder if these safeties would help Boeing.
My belief is that each brick has 69 cells in parallel. Each sheet (which has 9 bricks) can reconfigure itself into either series or parallel arrangements of its bricks. When the bricks are in series, the sheets have 36v each so with 11 sheets you get about 396v. When the bricks are in parallel, the sheets have 4v each and the 11 sheets together get you 44v. When the Roadster is On, the brick mode is series giving the high voltage. When the Roadster is Off or charging, the brick mode is parallel. When the bricks are in parallel all the cells in a sheet are effectively in parallel which allows them to balance all those cells in the sheet when the car is off. When charging, the charger can supply up to 400A at 44v to the sheets. This works out nicely. When the car is on, we have up to 600A at 396v drain possible; when charging we have up to 400A at 44v via a buck converter with input from 100vac to 250vac; when off each sheet of cells can balance. Note that 400A and 600A make the wiring work out nicely. Each brick when charging is getting about 44A @ 4v then each cell is getting about 0.65 A at 4v which is a comfortable rate of charge. Even if couple cells are dead it seems ok. The charging numbers are 70A @ 250vac giving 17.5kW which converted to DC and voltage lowered by buck conversion is about 400A @ 44v.
From your previous post, I thought you were arguing that the individual cells don't need to be switched. How do you propose that the pack can reconfigure itself without having switches/transistors on each cell? Of course this discussion belongs on its own thread, it has nothing to do with RichKae's battery study.
I'm convinced all Boeing needs to do is lower the operating voltage of the pack since even battery packs that did not catch fire had swollen cells, evidence of overcharging.
We now believe we can extract the CAC from the log files, plus or minus 0.03 Ah. Using the latest version of VMSParser, there's enough resolution on the data extracted to get a full CAC history, which is the same as the min brick amp-hours, but using a slightly different scale factor. So now, Rich's study has both CAC and the "seconds at temp" data.
I've been pulling CAC values using OVMS for a few months now. My current value today, after 24,642.6 miles and 28 months is 157.43. That makes my battery quite the outlier (see previous chart below). Note that it had dipped into the 153's back in Jun, but has been steadily rising ever since. My last few full Standard Charges have resulted in 185 miles of Ideal Range after sitting for several hours. Here's my recent data: Apr 23, 21,007.7miles: 154.96 Apr 24, 21,053.7miles: 154.96 May 12, 21,381.7miles: 155.35 May 16, 21,579.3miles: 155.70 May 20, 21,647.2miles: 155.17 May 30, 22,050.0miles: 155.36 Jun 12, 22,515.1miles: 153.62 Jun 14, 22,673.2miles: 154.07 Jun 19, 22,861.0miles: 154.32 Jun 28, 23,054.4miles: 153.79 Jul 03, 23,196.1miles: 154.17 Jul 11, 23,351.9miles: 154.67 Aug 09, 24,544.6miles: 157.03 Aug 14, 24,642.6miles: 157.43
Wow, very cool. I so wish we could extract this info for the Model S. It sucks that Tesla is so secretive about this stuff.
How do you do that? Do you send an SMS command? I saw a CAC value once when I received a text after stopping a charge by unplugging, but I wasn't sure if there was another way to get the CAC. Thanks.
FYI Here is some anon data from weekly Tattler v2 service posts; Car#1 Odometer 31,649mi CAC=150.60 Car#2 Odometer 27,637mi CAC=150.18 Car#3 Odometer 37,094mi CAC=147.02 You can manually get the cac value with, not surprisingly, the 'cac' command. Perhaps more useful: 'odo. cac' to get the mileage (or kilometers if you prefer) at the same time.
Is there a way to get historical values? I'd love to see where I started out and get the in between values. I was told the CAC should have been 160 when the car was new 5/2011. The first reading I got was when I had my car serviced 12/2011 CAC=153, next service 12/2012 CAC=147. My first reading off the OVMS was 4/2013 at CAC=146. Now CAC=145. Not as good as Smorg's great numbers!
The CAC detection logic has been back-ported to the log file parsers, so you might have some luck there.
Smorg--Help! I'm only a biology type. How do I translate this into English? i.e. is there a manual or directions to follow?
I think this might help: Tesla Graphical Log Parser - Page 11 and instructions for pulling logs: Tesla Graphical Log Parser and Tom's excellent command-line VMSparser: VMS Log Parser for Tesla Roadster Regards, Mark. P.S. Biology is all greek to me.