TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker or making a Paypal contribution here: paypal.me/SupportTMC

ahr.log file - seems useful for keeping an eye on your brick/sheets health

Discussion in 'Roadster' started by wiztecy, Aug 27, 2014.

  1. wiztecy

    wiztecy Active Member

    Joined:
    Apr 29, 2012
    Messages:
    2,721
    Location:
    Santa Cruz, California, United States
    #1 wiztecy, Aug 27, 2014
    Last edited: Aug 27, 2014
    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.
     
  2. spaceballs

    spaceballs Member

    Joined:
    Sep 17, 2013
    Messages:
    538
    Location:
    Sammamish
    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
     
  3. djp

    djp Roadster 2.0 VIN939

    Joined:
    Aug 28, 2011
    Messages:
    1,108
    Location:
    Toronto, Canada
    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?
     
  4. spaceballs

    spaceballs Member

    Joined:
    Sep 17, 2013
    Messages:
    538
    Location:
    Sammamish
    It's in the tar file under the Flash directory (I use winrar).
     
  5. wiztecy

    wiztecy Active Member

    Joined:
    Apr 29, 2012
    Messages:
    2,721
    Location:
    Santa Cruz, California, United States
    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
     
  6. spaceballs

    spaceballs Member

    Joined:
    Sep 17, 2013
    Messages:
    538
    Location:
    Sammamish
    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.
     
  7. djp

    djp Roadster 2.0 VIN939

    Joined:
    Aug 28, 2011
    Messages:
    1,108
    Location:
    Toronto, Canada
    #7 djp, Aug 27, 2014
    Last edited: Aug 27, 2014
    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.
     
  8. djp

    djp Roadster 2.0 VIN939

    Joined:
    Aug 28, 2011
    Messages:
    1,108
    Location:
    Toronto, Canada
    Or better yet:

    SOC

    SOC.png

    Voltage

    Voltage.png
     
  9. slcasner

    slcasner Member

    Joined:
    Feb 20, 2011
    Messages:
    563
    Location:
    Sunnyvale, CA
    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
     
  10. djp

    djp Roadster 2.0 VIN939

    Joined:
    Aug 28, 2011
    Messages:
    1,108
    Location:
    Toronto, Canada
    Ah, same with the SOC as well.

    488519 / 8192 = 59.6% SOC
     
  11. markwj

    markwj Moderator, Asia Pacific

    Joined:
    Apr 10, 2011
    Messages:
    3,664
    Location:
    Hong Kong
    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.
     
  12. hcsharp

    hcsharp Active Member

    Joined:
    Jun 7, 2011
    Messages:
    2,537
    Location:
    Vermont
    This is so cool. How come nobody found these files before now? (I still don't know where they are:confused:)
     
  13. slcasner

    slcasner Member

    Joined:
    Feb 20, 2011
    Messages:
    563
    Location:
    Sunnyvale, CA
    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.
     
  14. spaceballs

    spaceballs Member

    Joined:
    Sep 17, 2013
    Messages:
    538
    Location:
    Sammamish
    #14 spaceballs, Aug 27, 2014
    Last edited: Aug 27, 2014
    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.
     
  15. Mark77a

    Mark77a Member

    Joined:
    Jul 7, 2012
    Messages:
    292
    Location:
    Poole, Dorset, UK
    #15 Mark77a, Aug 28, 2014
    Last edited: Aug 28, 2014
    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 .........
     
  16. djp

    djp Roadster 2.0 VIN939

    Joined:
    Aug 28, 2011
    Messages:
    1,108
    Location:
    Toronto, Canada
    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.
     
  17. Mark77a

    Mark77a Member

    Joined:
    Jul 7, 2012
    Messages:
    292
    Location:
    Poole, Dorset, UK
    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 ?
     
  18. marco2228

    marco2228 Roadster Signature #34

    Joined:
    Nov 19, 2010
    Messages:
    185
    Location:
    Cologne/Bremen , Germany
    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
     
  19. Mark77a

    Mark77a Member

    Joined:
    Jul 7, 2012
    Messages:
    292
    Location:
    Poole, Dorset, UK
    Ouch ... so a fusible link is essential (Tesla 1, Porsche 0 :)
    p2.5257545.jpg

    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 :) ]
     
  20. wiztecy

    wiztecy Active Member

    Joined:
    Apr 29, 2012
    Messages:
    2,721
    Location:
    Santa Cruz, California, United States
    #20 wiztecy, Aug 28, 2014
    Last edited: Aug 29, 2014
    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.
     

Share This Page