Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

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

This site may earn commission on affiliate links.
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.
 
Last edited:
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?

bricksocv
0
74277232288
173415532289
274251532289
376542632408
476722532409
577394032449
678151932449
778151632488
878956432528
974232432288
1073418032249
1174264432289
1275943132368
1376731032409
1477424832408
1577408432449
1678130132488
1778961432488
1874267332289
1973423132289
2074261332289
2176540632368
2276727832409
2377392932449
2478158732449
2578164932488
2678975732488
2774233032328
2873420332289
2975072032328
3076549632408
3177355332448
3277360032448
3378142932488
3478151032488
3578977632528
3674072232322
3774254632289
3875054632328
3976547132408
4076604532408
4177343932448
4278117832448
4378129632488
4478943032528
45
28709930727
4629360430733
4740326830887
4840326830887
4931773530767
5047364831012
5146962231007
5249233231052
5359631831407
5474239632288
5573409532289
5675093732329
5776736732369
5877397632408
5977409032449
6078131632448
6178143732488
6278954032528
6373407832288
6472544832248
6574232432288
6675922532369
6776614932408
6877429632409
6977421932448
7078165332449
7178145432488
7274251232328
7374251632289
7475095132329
7576744532369
7677417332448
7777416432448
7878131532488
7978960032528
8079729132528
8174275532288
8274245432289
8374255332329
8475926632369
8577360032448
8677375932449
8778191632449
8878121032488
8978961232528
9074235132288
9174213932288
9275035532328
9376527532408
9477346832448
9578096532448
9678089932488
9778121732488
9878920632528
 
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?
 
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?

It's in the tar file under the Flash directory (I use winrar).
 
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.
 
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.

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 - - -

btw does anyone know the voltage offset of what is shows in the log and the actual voltage of the cell?

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.
 
Last edited:
Or better yet:

SOC

SOC.png


Voltage

Voltage.png
 
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.

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
 
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.

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.
 
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

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.
 
Last edited:
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 .........
 
Last edited:
[*]Will Tesla release enough technical info so that 'mortals' can replace our own cells/bricks (a nod to marco2228's electronic's skills and bravado :)

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 :)
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 :) ]
 
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.
 
Last edited: