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.

  • Resolved

[FAQ] BQ34Z100-G1: Frequently Asked Questions

Part Number: BQ34Z100-G1

This thread contains frequently asked questions for the bq34z100-G1 gauge.

  • Why are there two Cycle Count parameters in Data Memory?

    Configuration>Data>Cycle Count increments whenever accumulated discharge is greater than or equal to CC Threshold. The value stored at Configuration>Data>Cycle Count is returned by the CycleCount(): 0x2C/0x2D command pair.

    When Qmax updates, Gas Gauging>State>Cycle Count is set equal to the value stored in Configuration>Data>Cycle Count.

    MaxError(): 0x03 is incremented internally by 0.05% for every increment of CycleCount() after the last QMAX update, e.g., ( ( Configuration>Data>Cycle Count - Gas Gauging>State>Cycle Count ) * 0.0005 ).

    CC Gain and CC Delta are both used for calibrating the sense resistor, but what is the difference between CC Gain and CC Delta?

    CC Gain is the gain factor for calibrating Sense Resistor, Trace, and internal Coulomb Counter (integrating ADC delta sigma) errors. It is used in the algorithm that reports Average Current.

    CC Delta is the gain factor for calibrating Sense Resistor, Trace, and internal Coulomb Counter (integrating ADC delta sigma) errors. It is used in the algorithm that reports charge and discharge in and out of the battery through the Remaining Capacity register.

    The difference between CC Gain and CC Delta is that the algorithm that reports Average Current cancels out the time base because Average Current does not have a time component (it reports in mA) and CC Delta requires a time base for reporting Remaining Capacity (it reports in mAh).

    CC Gain and CC Delta do not need to be modified directly by the user. They are modified by the current calibration function from Calibration mode.

    How do I perform Floating Point Conversion for the bq34z100-G1 on a machine with x86 type processor?  Are there number pairs I can use to verify?

    General info about the floating point format for many of our gauges (like bq27xxx, bq34z100, and bq34110):
    The double is not IEEE compliant; it is in big endian order, with the exponent first.  The next 3 bytes are the mantissa with an implied first bit of 1, thus squeezing out one extra bit in the precision of the number.  However, note the MSB of the first byte of the mantissa is the sign bit.
     
    Here’s the ‘C’ code to take the 4 bytes and convert from the gauge's big endian to a double on a typical Intel based machine (little endian).
     

    uchar p[] = { 82, 20, 21, 22};   // hypothetical bytes with the starting float
    int s, e;
    double x;
    union int_byte {
        UINT i;
        UCHAR c[4];
    } d;
     
    e=*p++;                          // exponent
    s=(*p)&0x80;                     // sign of number
    d.c[3]=0;                        // because mantissa only has 3 bytes
    d.c[2]=(*p++)|0x80;              // flip the endianess
    d.c[1]=(*p++);
    d.c[0]=(*p++);
     
    x=d.i * pow(2,e-128-24);         // 128 because of implied sign of exponent and the 24 because of the implied 1 as the high bit in the mantissa
    if (s)
        x=-x;                        // has the correctly signed value as a double in Intel (IEEE) format

    To verify, here are some example outputs:

    // Example outputs:
    // Hex Float
    00000000 1.46936793853e-39
    81800000 -1.0
    81000000 1.0
    8b1a522b 1234.56774902
    8e88f5ba -8765.43164062
    94452578 807511.5
    7f5e9624 0.434739232063
    977b2169 8229044.5
    7d063fa8 0.0655511021614
    9b2b2e2a 89747792.0
    7f3efd94 0.37302839756
    962f2f49 2870226.25
    9b2f7784 91995168.0
    906c32dc 60466.859375
    963b28db 3066422.75
    7e703f1e 0.234615772963
    873a005e 93.0007171631
    841683fb 9.40722179413
    8225884f 2.58644461632
    8b22d71e 1302.72241211
    93270dbd 342125.90625
    9c158969 156800656.0
    8847c72f 199.778060913
    893d0bbf 378.091766357
    9c72e870 254707456.0

  • Thanks for the FAQ

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.