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.

INA226: Accurate readings at fixed intervals

Part Number: INA226

Hello E2E community!

I am planning to use the INA226 for a battery application as a real time monitor and Coulomb counter. I am asking for best practices to get as high precision as possible for the voltage and current reading.

My goal is to have accurate values for average voltage and current over 100 ms intervals, continuously. This is so I can display those values, but also so the Coulomb counter works well (accumulated energy over time)

Initially I planned to set the AVG and VBUSCT registers as close to 100 ms as possible, for example AVG=64, VBUSCT=1.1 ms: 1.1 ms x two conversions x 64 = 140.8 ms. Then program my MCU to read from INA226 at exactly 100 ms intervals over I2C. But then I realized that I will read the same value twice at irregular intervals. Also, the conversion time is specified with low precision (can vary 10%), which makes things more complicated. So if there happens to be a large current spike at the moment I read the same value twice, it will distort my long time average, making the Coulomb counter less accurate.

At each read I could also read the CNVR (conversion ready) bit, then estimate how far out of phase my read is, and then do a weighted average between the new and the previous value. Or I could read at 1 ms intervals, then let the MCU calculate an average every 100 values, but that would result in a lot of I2C activity. Perhaps better to ask the community first about the best practice for this.

Using a conversion ready interrupt from the alert pin is not an option in my case. If I can't find a good solution, I could fall back on using the INA226 accumulated power register, but I'd prefer to use my MCU to do the power calculations.

Regards,
Bjorn Moren

  • Hello BjornM,

    Thanks for considering to use Texas Instruments. I discussed this with some of my colleagues and we think the that using the trigger mode and reading the conversion ready bit would be good approach. With this approach you can synchronize with your microcontroller as the conversion should begin as soon as you write to the configuration register. However, if you are planning on having a measurement ready every 100ms you will need to modify either the conversion time or averaging such that it collectively takes less than 100ms.
  • Hi Patrick,

    Thanks for your answer! I could use a conversion time of 588 us and an averaging of 64. Using the trigger mode, this should make the conversion ready bit give a signal after 75 to 83 ms. Well, I wouldn't even have to check this bit, because if I read at 100 ms intervals, it would always have a result ready. 

    However, the INA226 will only be monitoring the shunt/bus voltages 75% of the time. 25% of the time no measurements are taken. What if a current spike occurs during that time?

    Figure 21 of the data sheet shows an example of input filtering, with components chosen to reject noise about 500 kHz. I guess I could modify the R/C values to to a time constant around 100 ms. I this the preferred way to it, or do you have other suggestions?

    Somehow it feels like I am not using the INA226 the way it is intended.

    Regards,
    Bjorn

  • Hello BjornM,

    As you cannot use the alert pin to trigger reading from the INA226, I think you will always be faced with the compromise of either missing data or sampling some data twice. The front end R/C might be a good compromise depending on the expected duration of your transient. However, I think if your time constant is around 100ms you will actually be greatly attenuating any spikes you want to measure. I think you should probably have your cutoff at 10x your highest desired spike frequency. Also one other issue you may encounter with the RC would be the initial charge up. The longer the RC constant or lower your pole, the longer it will take for the cap to charge and this could skew your initial measurements.

    Since you are considering an RC filter, perhaps you can go back to the originally scenario of possibly oversampling. In this case you would never lose any data and if your spike is of relatively low duration the converted and averaged value should only increase a little. This is what one of my colleagues recommended.

  • Thanks for your answer Patrick!

    I'll most likely go with R/C filter together with oversampling.

    Regards,

    Bjorn