This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ27510-G3: Reading "State of Health" command returns values greater than 100%

Part Number: BQ27510-G3

In the SLUUA97 I read this:

The bq27510-G3 fuel gauge uses a series of 2-byte standard commands to enable system reading and
writing of battery information. Each standard command has an associated command-code pair, as
indicated in Table 2-1. Because each command consists of two bytes of data, two consecutive I2C
transmissions must be executed both to initiate the command function and to read or write the
corresponding two bytes of data.

(emphasis mine)

As we can see, it is said that all standard commands require two bytes of data to be read or written.

So, naturally, I read two bytes from State of Health command and got 0x160 == 352%. I thought it can't be right so I went to BQ Studio and read all values in there. State of Health was shown as 96%.

Then I used logic analyzer to see how Bq Studio reads this command. And I saw this:

That is a one byte read. 0x60 is indeed 96 percent. I made two reads and I read lower byte 0x60 (which was correct) and then I read higher byte 0x01 (which is not).

My question is:

1) Who is to blame - documentation or Bq Studio?

2) Is there any more one-byte commands that I should be aware of?

  • State of Health is of data type U1, which is unsigned int 1 byte. The data immediately following it is SOH status which per TRM gives you what type of state of health reading was taken.

    0x29 SOH status: this read-only function returns an unsigned integer value, indicating the status of the
    SOH percentage. The meanings of the returned value are:
    • 0x00: SOH not valid before initialization
    • 0x01: Instant SOH value ready
    • 0x02: Initial SOH value ready. The calculation is based on unlearned Qmax and is updated at the first
    grid point during discharge after cell insertion.
    • 0x03: SOH value ready. The calculation is based on an updated learned Qmax value.
  • Sorry, I'm afraid I don't quite follow this line of thought.

    As per SLUUA97:
    StateofHealth( ): 0x1C and 0x1D - so reading 0x1C should give State of Health, doesn't it?

    But this is followed by your quote (more or less) and I don't really understand what are these 0x29 and 0x28. I was reading command 0x1C, not 0x28.

    And can you please point me to where in documentation it is said that State of Health is of data type U1? Tables 4-3...4-10 do not directly mention SOH and Table 4-2. Data Type Decoder - wich defines type U1 - in my view describes only types in the internal flash. I can't see any direct relation to I2C commands.
  • 0x1C and 0x1D are 28d and 29d in decimal. You're reading 2 bytes, SOH is combined with SOH Status. So when you read 2 bytes, both are returned, 1 byte for SOH and another for SOH Status.
  • I'm sorry but it is written 0x28 and 0x29, even you wrote it that way. And 0x usually stands for "hex", not "decimal".

    I believe thats a misprint in the documentation and it should be corrected.

  • Yeah, you're right.
  • Okay, than I think this issue is resolved. Thank you for your help. I hope this misprint will be fixed :)