Just playing around again looking at the log file dump from the Roadster and I totally missed this before, the ahr.log file. It shows the previous/current SOC and the previous/current voltage of each brick in the ESS numbered 0 to 99 (11 sheets, 9 bricks in each). Here's a sample clip from my old log file: brick prevSOC prevV presSOC presV 0 625459 31687 619510 31647 1 625459 31687 619510 31647 2 625459 31690 620691 31651 Just curious about when / what time they take these snapshots. But over time you can correlate your drop in CAC to the brick/sheet as long as you dump and save your logs regularly. This also looks familiar to the graphical ESS brick/sheet tool Tesla has in their arsenal that shows what's really going on inside the battery pack, all for the exception that Telsa's tool shows the Ah capacity of each brick as well as sheet.
Nice timing, I just did mine 10 mins ago, I'm also trying to figure out how often it updates, I think it creates it within a day or less. I control the voltages on bricks 45-53, so ignore those values. but I guess I can find out as I can change the voltage and then see when this ahr.log file gets updated with the new voltage. btw does anyone know the voltage offset of what is shows in the log and the actual voltage of the cell? brick soc v 0 742772 32288 1 734155 32289 2 742515 32289 3 765426 32408 4 767225 32409 5 773940 32449 6 781519 32449 7 781516 32488 8 789564 32528 9 742324 32288 10 734180 32249 11 742644 32289 12 759431 32368 13 767310 32409 14 774248 32408 15 774084 32449 16 781301 32488 17 789614 32488 18 742673 32289 19 734231 32289 20 742613 32289 21 765406 32368 22 767278 32409 23 773929 32449 24 781587 32449 25 781649 32488 26 789757 32488 27 742330 32328 28 734203 32289 29 750720 32328 30 765496 32408 31 773553 32448 32 773600 32448 33 781429 32488 34 781510 32488 35 789776 32528 36 740722 32322 37 742546 32289 38 750546 32328 39 765471 32408 40 766045 32408 41 773439 32448 42 781178 32448 43 781296 32488 44 789430 32528 45 287099 30727 46 293604 30733 47 403268 30887 48 403268 30887 49 317735 30767 50 473648 31012 51 469622 31007 52 492332 31052 53 596318 31407 54 742396 32288 55 734095 32289 56 750937 32329 57 767367 32369 58 773976 32408 59 774090 32449 60 781316 32448 61 781437 32488 62 789540 32528 63 734078 32288 64 725448 32248 65 742324 32288 66 759225 32369 67 766149 32408 68 774296 32409 69 774219 32448 70 781653 32449 71 781454 32488 72 742512 32328 73 742516 32289 74 750951 32329 75 767445 32369 76 774173 32448 77 774164 32448 78 781315 32488 79 789600 32528 80 797291 32528 81 742755 32288 82 742454 32289 83 742553 32329 84 759266 32369 85 773600 32448 86 773759 32449 87 781916 32449 88 781210 32488 89 789612 32528 90 742351 32288 91 742139 32288 92 750355 32328 93 765275 32408 94 773468 32448 95 780965 32448 96 780899 32488 97 781217 32488 98 789206 32528
Great find! That looks like the hands-down best info for pack health. The table gives you the full distribution of brick capacities, which is a lot more useful than the min and max from the standard log. From my logs I know bricks 19 and 20 take turns as the lowest brick, but I don't know if these two are outliers, or if other bricks are close behind. The ahr.log is exactly what we need to answer that. How did you extract it?
Is there anyway for us to determine the Ah of each brick and then calculate each script. We can write a unix or GUI script that'll do the conversions. Also its good to look at your messages and messages.0 logs, that way if there's an issue coming on with your flash dying you'll be able to flag it before it catastrophically fails on you. It may be greek to some, but I understand / work on Unix, one of my skills, as well as device drivers. It'll spew out errors if the flash is dying which should catch your attention. Another interesting file is vt.dat: It also shows a brick/sheet relation. What I don't understand are the temp readings in the second matrix, it has the sheets but only *6* columns. I don't know what the "6" things are, common cooling lines/feeds? #cat vt.dat vin: 5YJRE11B681000xxx time: 1286469357 voltages 0 33088 33088 33128 33168 33208 33208 33208 33208 33248 1 33128 33087 33127 33167 33207 33208 33208 33207 33207 2 33208 33208 33208 33208 33208 33208 33208 33208 33208 3 33128 33128 33168 33208 33248 33208 33207 33207 33207 4 33208 33207 33207 33207 33207 33207 33207 33208 33208 5 33208 33208 33208 33208 33208 33208 33208 33208 33208 6 33088 33087 33087 33127 33208 33208 33208 33208 33208 7 33088 33128 33168 33167 33207 33208 33207 33207 33207 8 33208 33207 33208 33208 33207 33208 33208 33207 33247 9 33208 33207 33207 33208 33208 33208 33247 33208 33207 10 33088 33047 33087 33127 33167 33208 33207 33207 33207 temps 0 4075 4011 4101 4026 4078 4140 1 4126 4166 4245 4156 4118 4123 2 4191 4127 4209 4225 4123 4166 3 4268 4104 4210 4190 4152 4154 4 4195 4201 4224 4291 4146 4209 5 4257 4180 4254 4235 4219 4172 6 4224 4209 4191 4255 4232 4250 7 4246 4202 4252 4280 4196 4212 8 4159 4217 4254 4274 4131 4273 9 4186 4147 4277 4283 4215 4208 10 4124 4146 4188 4232 4204 4264
I just took a look at my VDS, and looked at the voltages of certain bricks. i.e. #46 Vmin 3.74V #80 Vmax 3.96V The log shows #46 of 30733, guessing it might represents 3.0733v, then that would be an voltage offset of 0.6667v The log shows #80 of 32528, guessing it might represents 3.2528v, then that would be an voltage offset of 0.7072v Difference between the two is 0.0405v which could be in the realm of diode voltage drop tolerance.
Not directly, it looks like the ahr.log only gives us %SOC and voltage. It would be useful to find the max %SOC and voltage and show each brick relative to that. For example: 0 505390 31087 -1.56% (0.0045) 1 505390 31087 -1.56% (0.0045) 2 505390 31092 -1.56% (0.0040) 3 505390 31092 -1.56% (0.0040) 4 505390 31092 -1.56% (0.0040) 5 505390 31127 -1.56% (0.0005) 6 505390 31127 -1.56% (0.0005) 7 509188 31127 -1.18% (0.0005) 8 505390 31092 -1.56% (0.0040) 9 505390 31092 -1.56% (0.0040) 10 505390 31092 -1.56% (0.0040) 11 505390 31092 -1.56% (0.0040) 12 505390 31132 -1.56% - 13 505390 31132 -1.56% - 14 505390 31092 -1.56% (0.0040) 15 505390 31132 -1.56% - 16 505390 31132 -1.56% - 17 509191 31132 -1.18% - 18 493574 31087 -2.74% (0.0045) 19 488519 31047 -3.25% (0.0085) 20 492332 31092 -2.87% (0.0040) 21 505390 31087 -1.56% (0.0045) 22 505390 31087 -1.56% (0.0045) 23 505390 31092 -1.56% (0.0040) 24 505390 31087 -1.56% (0.0045) 25 509175 31127 -1.18% (0.0005) 26 505390 31087 -1.56% (0.0045) 27 505390 31087 -1.56% (0.0045) 28 505390 31092 -1.56% (0.0040) 29 521010 31127 0.00% (0.0005) 30 505390 31092 -1.56% (0.0040) 31 521010 31127 0.00% (0.0005) 32 509194 31127 -1.18% (0.0005) 33 509188 31127 -1.18% (0.0005) 34 505390 31092 -1.56% (0.0040) 35 505390 31132 -1.56% - 36 509194 31127 -1.18% (0.0005) 37 505390 31092 -1.56% (0.0040) 38 505390 31092 -1.56% (0.0040) 39 505390 31087 -1.56% (0.0045) 40 505390 31087 -1.56% (0.0045) 41 492332 31092 -2.87% (0.0040) 42 509188 31127 -1.18% (0.0005) 43 505390 31092 -1.56% (0.0040) 44 509188 31127 -1.18% (0.0005) 45 521010 31127 0.00% (0.0005) 46 505390 31087 -1.56% (0.0045) 47 505390 31127 -1.56% (0.0005) 48 505390 31127 -1.56% (0.0005) 49 505390 31087 -1.56% (0.0045) 50 505390 31087 -1.56% (0.0045) 51 505390 31092 -1.56% (0.0040) 52 521010 31127 0.00% (0.0005) 53 505390 31092 -1.56% (0.0040) 54 521010 31127 0.00% (0.0005) 55 505390 31092 -1.56% (0.0040) 56 505390 31087 -1.56% (0.0045) 57 509194 31127 -1.18% (0.0005) 58 505390 31127 -1.56% (0.0005) 59 505390 31092 -1.56% (0.0040) 60 509194 31127 -1.18% (0.0005) 61 521010 31127 0.00% (0.0005) 62 505390 31092 -1.56% (0.0040) 63 521010 31127 0.00% (0.0005) 64 505390 31092 -1.56% (0.0040) 65 505390 31087 -1.56% (0.0045) 66 505390 31087 -1.56% (0.0045) 67 505390 31092 -1.56% (0.0040) 68 505390 31087 -1.56% (0.0045) 69 521010 31127 0.00% (0.0005) 70 505390 31087 -1.56% (0.0045) 71 521010 31127 0.00% (0.0005) 72 509194 31127 -1.18% (0.0005) 73 505390 31092 -1.56% (0.0040) 74 505390 31087 -1.56% (0.0045) 75 505390 31087 -1.56% (0.0045) 76 505390 31087 -1.56% (0.0045) 77 505390 31087 -1.56% (0.0045) 78 505390 31087 -1.56% (0.0045) 79 505390 31087 -1.56% (0.0045) 80 505390 31092 -1.56% (0.0040) 81 521010 31127 0.00% (0.0005) 82 505390 31092 -1.56% (0.0040) 83 505390 31092 -1.56% (0.0040) 84 505390 31087 -1.56% (0.0045) 85 505390 31092 -1.56% (0.0040) 86 505390 31092 -1.56% (0.0040) 87 521010 31127 0.00% (0.0005) 88 505390 31087 -0.38% (0.0045) 89 505390 31087 -0.38% (0.0045) 90 505390 31087 -0.38% (0.0045) 91 509188 31127 0.00% (0.0005) 92 505390 31092 -0.38% (0.0040) 93 505390 31132 -0.38% - 94 505390 31092 -0.38% (0.0040) 95 505390 31092 -0.38% (0.0040) 96 505390 31132 -0.38% - 97 509188 31127 0.00% - 98 505390 31092 0.00% - - - - Updated - - - I agree with @spaceballs, the offset looks to be about 0.7V. At 50% SOC my brick voltage is 3.8V, the ahr.log is showing 3.1V at the same SOC.
No, you don't want an offset, you want to figure the binary point, as is done in the log parsers for many of the values. In this case, you want to divide these values by 8192: 30733 / 8192 = 3.75 32528 / 8192 = 3.97
Mine has some lines: when: 1102428636 ah: -229 prevWhen: 1088657224 prevAh: 8485901 presWhen 1093760654 presAh 1509816 Those don't look like unix timestamps, but are presumably some counter as to when the 'prev' and 'pres' are.
These files are contained within the log file that you download, like 201408120533.tar, which is an archive file. On a Mac, you can just double click it to unpack all the files into a directory named 201408120533. On Windows you can use one of the archive tools such as winzip.
Good catch! Looks like their adjusting the gain (in binary) to fit it in a non float variable. LOL you think I would have noticed that.. since I'm currently coding firmware to read I2C voltage from an LTC2990 chip and I'm basically doing the same thing.
What if we DO identify a bad brick ? How to have it replaced ? Well Done, Sir !! This is an awesome find. However, THE 'elephant in the corner' is: what happens if when we use such tools and DO identify a bad brick ? Will Tesla now replace it ? (depending on which, if any, warranty is on the car ref: Kevin Sharpe's experience even with a $22000 'bumper to bumper' warrantee) Can Tesla replace it ? (some sources suggest replacement 2.2Ah cells / spare bricks and sheets are getting rare) Will Tesla release enough technical info so that 'mortals' can replace our own cells/bricks/sheets (a nod to marco2228's electronic's skills and bravado The tread I am watching like a hawk is: Roadster parts becoming a significant problem?. I know, this may sound like paranoia (even tho I do have a 'bumper to bumper' warrantee !!) ... I think roadster owners, especially the majority in the USA, should bear this in Mind .........
My understanding from the tear down is the cells and bricks are glued into the sheets, and the sheet is the smallest replaceable part. Still a lot cheaper than replacing the pack, on the order of $4K instead of $40K. I'd be very interested to see Kevin's ahr log file. I expect his failure case will be typical as the Roadsters start aging. The bricks will lose capacity at different rates as they degrade. One brick will become consistently low and limit the rest of the pack. The ahr log answers the question of whether other bricks are close behind, and whether a sheet replacement will help or not.
Agreed: it will be interesting to see Kevin's ahr log. But ... Are there any $4K Sheets still available ? and if so for how long ? As for DIY re-bonding, why not ?
I would be careful with rebuilding the pack with the 18650 (the cells Tesla uses). These guys also used the 18650 cells and didn't have cell level fuses. They just laser welded the cell contacts to the busbar. Elektroporsche ging in Flammen auf - ooe.ORF.at
Ouch ... so a fusible link is essential (Tesla 1, Porsche 0 Joining cells is quite difficult, but not impossible - RC guys have been DIY'ing it for years. The point is I really hope we will not have to resort to such radical actions, to keep our cars on the road .... but if rumours are to be believed ... ??? Marco, do you have any more pictures of inside those sheets ? - your project gives some of THE best real battery info [kudos ]
My guess in Mark's case is that two sheets are pulled down lower than the rest. I've noticed this with my original ESS, the replacement / refurbished ESS. I complained about a low and abnormal drop in my CAC, became good friends with a kick ass engineer @ Tesla who was / is a mastermind at what he does. One of the best guys I've known in that area personally. And for I, knowing software/hardware, we could talk the same language and shared similar passions. We reviewed the logs on the Tesla ESS graphical utility and saw two sheets pulled way lower than the rest. He suspect that since the two sheets pulled low were managed by the same BMB (BMB manages 2 sheets except for that oddball 11th sheet that gets its own) had a faulty BMB. We had authorization to replace the BMB and the CAC stopped dropping. So I was happy with that. Then a year later I had an internal failure with the 12v system inside the ESS, so under goodwill and my complaining pointing out an issue that I was unhappy with the pack they replaced the ESS too. Well this refurbished ESS never reached the CAC of my original pack, nor did the ideal miles come close (166 vs 182). I complained again. But before that reviewed the logs running the refurbished pack through Tesla's ESS graphed utility. Again, two sheets managed by the same BMB were pulled low. I made an argument with the service manager that there appears to be a pretty bad bug floating around that's killing two sheets in the ESS. He showed me a Roadster that was there, a 1.5, and tried to say that the 1.5's only had 175 miles (std) of range when new. I said that's BS, and I know firsthand my Roadster after sitting for 4 years had 188 miles (std) and there's a bug there. The Roadster he showed me in the garage had 166 miles (std) with only 6k on the odometer and tried saying this is normal. I said, no way! This is most likely has the same bug I'm pointing out to you and invited him to review the logfiles via the parser. When I had my 3rd ESS, I got lucky (or they got sick of me complaining), this one was a very healthy one. It climbed all the way up to 160.00 CAC so essentially a new as healthy of a pack one can get. However, I'm still weary of hitting that 2 sheet pulled low bug. So getting back to Mark's ( really Kevin Sharpe's) issue, if the Roadster still moves under its own power, charges, and no catastrophic failure occurs, Tesla considers the pack to be within bounds of a working functional pack that's still healthy under their terms. As for me, I consider any sheets/bricks that are way out of bounds as a defect that needs to be understood why the failure is occurring and addressed. I pushed Tesla to analyze my 1st and 2nd pack to understand why these ESS packs/sheets are dropping their CAC abnormally the way they I observed. But the packs just get sent back to their test and rebuild facility, a quick bill of health done on them, they're refurbished, and then sent back out and installed in a Roadster when the time comes. Possibly with the knowledge and help of Jerry,Marco, Henry as well as other talented people on this forum, we can better understand my observed issue of the two sheets getting pulled low with the same BMB, try to address and manage this issue ourselves. As for finding the ahr.log, well, I was being persistent at trying to find some utility like Tesla's graphical ESS utility and it just started to make me dig around in the logfile stash again.... Thinking that somehow they're pulling this information out, knowing the 11 sheet/9 brick relation, reviewing log stash revealed what ahr.log was and the very usefulness of it. I'm sure that those who wrote the cool log parsers for us may have used /do use this log for some other purposes, but since I was trying to find a relation/health between the brick to sheet to ESS and saw the target/goal (Tesla's tool) I was after, this file jumped out clear as day.