Annual Battery Inspection - Seekrit Data Report

[lukati]

Why go to three decimal places, and then apparently not use any? I can't believe it is exactly 24,756.000 miles.

All data is 2 bytes wide (i.e. 4 hex digits), except for the milage. Two bytes would not be enough to hold enough miles (65,535), so more digits are needed. They may have gone for another 2 byte unit although they only needed one more digit. That wastes 3 digits but keeps the memory well organized.

[TickTock]

FMCGTORUNTIME: from charge to run time (time sitting after charge completion before operating)?
FMRUNTOCGTIME: from run to charge time (time sitting after running before starting charge)?

[Nubo]

I'll take a guess at the units being metric and in 0.1 meters for 6300.7 miles.

Metric makes sense since the temps all seem to be.

But a leading zero doesn't make sense to me.

If I assume a reversed order, then the three leading zeros might make sense, then assume one digit for tenths...

4b06.0 = 19206.0 kM (11934 mi).

[Nubo]

FMCGTORUNTIME: from charge to run time (time sitting after charge completion before operating)?
FMRUNTOCGTIME: from run to charge time (time sitting after running before starting charge)?

Makes sense, except the report has all zeros for FMRUNTOCGTIME ..?

[Smidge204]

I'll take a guess at the units being metric and in 0.1 meters for 6300.7 miles.

Interesting... could also be 101,400,576 feet = 19,204.6545 miles Truncating also possible but it's actually more difficult to handle 3 bytes of data than 4. They just used a 32bit INT instead of a 16bit INT.

If I assume a reversed order, then the three leading zeros might make sense, then assume one digit for tenths... 4b06.0 = 19206.0 kM (11934 mi).

I've never seen hexadecimal reversed like that. At worst the byte order would be reversed (little vs big endian), not the nybble order!

06 0B 40 00 becomes 00 40 0B 06 or 4,197,126. If we assume that's meters, it works out to 2,607.97 miles. If we leave the byte order as is, then 101,400,576 meters = 63,007.3968 miles which may be possible (No clear reason to shift the decimal like Nekota did). I suspect, though, that byte order is NOT reversed. If it was then you'd expect the reversal to be used throughout - so that means he's used quick charge (QUICKCG) a total of 256 times (0100) instead of just once (0001) and a normal charge (NORMALCG) 56,832 times (DE00) instead of 222 times (00DE).

----

I converted the table into CSV and HTML versions (HTML has hex converted to decimal assuming no byte order reversal).
=Smidge=

[lukati]

I'll take a guess at the units being metric and in 0.1 meters for 6300.7 miles.

That would be a little odd, but might just be true. The report has 1 QC and 222 L1/L2 events under NUMBER_OF_QC_AND_NC. This number is close to a total of 216 charging events under SOC_AT_GC. Depending on whether these charging events went to 80% or 100% SOC and using a range of 3-5 miles/kWh, the total milage should be in the 3,400-10,900 mile range. So 6,300 miles looks about right.

Using the entire width of the data block certainly makes more sense than truncating it. Given that the three least significant digits are zero, the counter probably increments in units of 1000, or about 410 m. The total milage that can be displayed would be 429,497 km. Totally reasonable.

[DaveinOlyWA]

Guessing unknown parameters to be time between charge complete and next time driven maybe and miles measured by tire rotations which is about like what 400 rotations per mile? Or so since that is how most cars determine distance

[Ingineer]

Looks like the mileage figure is KM if divided by 0x4000 (decimal 16384) or bit shifted right 14 places. Or you can divide it by 0x66F6 (26358 decimal) to directly derive miles.

So this report's 0x060B4000 = 6189 km or 3847 miles.

-Phil

[sandeen]

Phil, can you say where this report came from? Would be awesome to be able to do a "self-check" for battery health using these stats. Was this extracted from the car?

[dwl]

Phil, can you say where this report came from? Would be awesome to be able to do a "self-check" for battery health using these stats. Was this extracted from the car?

I understand this is from a CSV file that is created by the Nissan Consult 3 tool when the battery report is run. If you know where to look it is sitting in a subdirectory. Others smarter than me can probably extract this data from the car using other tools.