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

[marco2228]

Could anyone post a log of an empty or close to empty battery?
I'm trying to figure out how Tesla calculates the SOC and for that I want to do a voltage vs. SOC chart.

 

[wiztecy]

Adding some great diagrams of the (1.5) ESS and original link as reference (detailed "engineering diagrams" like this need to be archived/preserved on a wiki):

Roadster battery (ESS)

 

[spaceballs]

Could anyone post a log of an empty or close to empty battery?
I'm trying to figure out how Tesla calculates the SOC and for that I want to do a voltage vs. SOC chart.
...

Here is my current mapping over last few days, the car was not charged (12v battery disconnected) DC-DC converter is always on (so slowly draining ESS.)
Note the lower voltages/SOC bricks (are the ones I control) are draining a lot faster than the normal bricks (which is expected).

 

[spaceballs]

Latest aggregate of all logs I have including today.

 

[spaceballs]

If you remove my custom brick values (except for the lowest voltage point), I'm guessing the mapping look like this.

 

[djp]

More data points:

16% SOC = 3.66V = 62 ideal km
13% SOC = 3.63V = 51 ideal km

 

[Roadrunner13]

I'm trying to add some data points.
I've divided by 8192 and I have some numbers beyond 100% & 4.0V... assuming this is remnants of a Range Charge?

 

[spaceballs]

I'm trying to add some data points.
I've divided by 8192 and I have some numbers beyond 100% & 4.0V... assuming this is remnants of a Range Charge?

Yep I see the same thing with my data, I also assume it's Range charge too. I think it odd they report SOC 0-100 standard mode instead of range mode.

 

[Roadrunner13]

I think it odd they report SOC 0-100 standard mode instead of range mode.

We'll, if they bother using integer storage rather than float for optimization...
Storing values for quick display in 'standard' mode (most common) while doing additional number crunching only when displaying 'range' mode probably makes sense.

 

[spaceballs]

We'll, if they bother using integer storage rather than float for optimization...
Storing values for quick display in 'standard' mode (most common) while doing additional number crunching only when displaying 'range' mode probably makes sense.

True also there is more SOC resolution available when scaling this way.

 

[Roadrunner13]

True also there is more SOC resolution available when scaling this way.

Agreed!

On a different note, I'm wondering what's the time relationship between the 3 entries in the file?

I was looking at the three timestamps in the file and while the one labeled 'prevWhen' is always the smallest/oldest, the larger one is not always the same. Sometimes, the time stamp at the top of the file labeled 'When' is the bigger/more recent timestamp, other times, it's the last one (labeled 'presWhen' for 'present'?)

 

[djp]

I've been playing with the relationship between %SOC and displayed range, and I think I'm fairly close to the formula that Tesla uses:

Total Pack Wh = CAC * Nominal Voltage * Number of Bricks
Displayed Ideal Range (Range mode) = Total Pack Wh * SOC LIM / Ideal Wh/km
Displayed Ideal Range (Standard mode) = Displayed Ideal Range (Range mode) - 40 km
​

The numbers come out very close for my car by using these parameters:

Nominal Voltage: 3.7V
Number of Bricks: 99
SOC LIM: minimum %SOC for all bricks
Ideal Wh/km: 143Wh/km (or 230 Wh/mi)​

When looking at the energy accounting in my Trip screen the Ideal Wh/km is actually 146.6, which is a bit off from the 143 above, so I'm probably missing some other adjustment terms, but it's pretty close.

 

[wycolo]

On a Mac (OSX) just double click on ahr.log and you see:

No need to mess with Excel. I have Excel 2008 Mac, but it is not fun.

This is just showing the first ~25% of the log display.

Notice bricks 27 & 28 which are the lowest, significantly. They were also the lowest on June2013, my only other log-pull. Guess I should focus on these 2 bad boys as I try to get this battery in balance after 7 months of storage on the 120 volt cable.

Notice bricks 44 and 26 which are the highest, along with 62 & 98, but only slightly.
--

 

[wycolo]

One week later ahr.log shows definite improvement from being kept on 240 volts (standard charge) and making two 120 mile trips. Now all bricks are equal and a bit higher, with 27 & 28 as the only laggards. Perhaps in another week or two 27 & 28 will approach the rest of the bricks. Car had been in Storage Mode for previous 6 months. 2.0 vin 764 with 13k miles. During periods of active balancing there was a lot of contactor clunking going on!

--

 

[Strib]

I've been going through the files and have read this thread a few times, and I'm still puzzling. No offense here - just trying to resolve some doubts.

First, regarding the voltages, it may be exactly right that we need do divide by the power-of-two 8192. For my highest voltage brick it then matches my service display; for my lowest voltage brick it's a bit off.

But... why that division? Maybe not for the reasons that have been conjectured. For me, the voltage values are in the 33448 range, so they require a full 16 bits to represent (15 bits will not quite get there). But for the FW folks, that still fits in an 'unsigned int' so no real need to manipulate it.

Where do these values come from with 16 bits? Surely not directly from the BMB's analog-to-digital converters. Linear Tech has a good 14 bit device, but it's for low voltages and probably not automotive use. There are some good 12 bit ADC's for current, voltage, and temp. I don't know what Tesla is using - do any of you? My point is that this many bits (and they won't remain significant) must derive from some computation or even just accumulating (summing) a large number of reading samples. Does anyone know? Certainly they use a resistive divider from the battery pack to feed the ADC inputs, so we need to be aware of the effective gain or the equivalent weight per LSB . So, yes, we need to apply a gain factor, and maybe 1/8192 is correct - I'd just like to know what's behind it.


Some have commented on the VT.dat file, and that its contents somewhat resemble the ahr.log file. I also find this intriguing, including the 6 values of temperature per sheet... but I'm also curious that for mine the contents, and the file date, haven't changed for a couple of years.

All the best!

 

[slcasner]

You're right, the voltage going into the ADC has to be from a resistive divider off the full voltage. But the output of that divider in your case resulted in 33448 coming out of the ADC, which is not a useful number by itself. It has to be scaled to put it into the commonly understood units. It would be possible to choose any scaling factor for the resistive divider that gives a good balance of range and resolution within the number of bits in the ADC. The reason for choosing a power of two is so that division is not required to prepare the number for presentation.

If your point is that there are unused bits at the bottom, so why not right-justify the value and reduce the scaling factor by the same number of bits, I can't say. Maybe the way the ADC fits into the circuit is with the bits left-justified (that is, MSB justified).

 

[hcsharp]

You're right, the voltage going into the ADC has to be from a resistive divider off the full voltage. But the output of that divider in your case resulted in 33448 coming out of the ADC, which is not a useful number by itself. It has to be scaled to put it into the commonly understood units. It would be possible to choose any scaling factor for the resistive divider that gives a good balance of range and resolution within the number of bits in the ADC. The reason for choosing a power of two is so that division is not required to prepare the number for presentation.

If your point is that there are unused bits at the bottom, so why not right-justify the value and reduce the scaling factor by the same number of bits, I can't say. Maybe the way the ADC fits into the circuit is with the bits left-justified (that is, MSB justified).

Exactly. They worked backwards from the end result (volts in base 10). They needed to multiply 4.15 volts by the highest power of 2 possible to get a 16 bit number. That turns out to be 8192. The next higher power of 2 would result in more than 16 bits. The next lower, 4096, would not result in the highest 16 bit number possible, so you would lose some resolution or accuracy. Then they picked the resistor-divider values so they would produce 10 or 12 or 14 bit ADC values that when added up would produce the high 16 bit numbers we need. The reason the ADC readings are added/accumulated is to increase accuracy by essentially averaging multiple samples. Then again maybe they just used a 16 bit ADC and use 1 sample at a time.

(I think slcasner might have explained this better now that I've typed it all out )

 

[Strib]

Hi SL and HC, Thanks for the sage responses. I agree with you both, did so beforehand. Of course they need to scale, and of course they need to drop a bunch of lower bits that are not significant.

My puzzle has been: where did all those extra bits come from (some computation they didn't bother to truncate); and, since they went to the trouble of casting the values to ASCII numeric characters to write the file, they could have, just as easily, have written the values for the true volts (to maybe 2 1/2 significant digits).

Anyway, I think it's always healthy to more fully understand these great machines we love.

BTW, Henry - have now received and used the CAN-JR and CAN-SR. Great work!