• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 48 subscribers
  • Views 220 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Spikes in voltage/current measurements

Mo Mir
Prodigy 10 points
Part Number: INA226
Other Parts Discussed in Thread: INA228

Hello,

I am currently utilizing five INA226 chips in conjunction with a single microcontroller to monitor voltage and current across five circuits. These chips are configured to average 16 data points, with a conversion rate of 204 microseconds. The voltage being measured is under 2V, and the current is less than 100 mA. However, during data logging, I'm observing unexpected spikes—voltage surges up to 100V and current spikes reaching 1A (sometimes -1A). Yet, when I use an oscilloscope to measure the voltage/current directly, these anomalies aren't present. Our system is designed to be low noise, with a maximum peak-to-peak voltage of 1 mV. I'm puzzled about what might be causing this issue and am considering whether switching to the INA228 could offer a better solution for our project.

Something on the side:

  • Increasing the average number/conversion rate could potentially help, but we don't like to slow down our system.

  • The fact that we continuously read from the chip, could this be the reason for the spikes?

We are not implementing any input filter for the INA chips.

Thank you for your time.


  • 0
    Prodigy 10 points

    Just to clarify, the noise of our system is below 1mV Vpp.

  • 0 in reply to Mo Mir
    TI__Mastermind 19385 points

    Hello Mo,

    I realize these spikes are not predictable, but is there any way you could get a scope shot of the I2C communication during the spike? This would help eliminate I2C decoding or software issues. 

    Also, if possible, could you get a readout of all register values at the time of the spike? 

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 10 points

    Hello Mitch,

    We're utilizing a powerful microcontroller, and to eliminate any potential noise from its digital section, we're employing an I2C digital isolator. We've conducted tests both before and after the isolator, confirming that all the bits correctly match. Regarding your recommendations, do you suspect bit flipping within the digital communication segment?

    Given that there's just a single ADC, we thought that the act of switching between voltage and current measurements might be the root of the problem. Consequently, we adjusted the settings to exclusively measure the voltage on one chip and current on another, yet the spikes persist.

    I will conduct more measurements and update you when done.

  • 0 in reply to Mo Mir
    TI__Mastermind 19385 points

    Hey Mo,

    It also may be work looking at the I2C digital isolator spec to ensure that the logic high and low levels work with the INA226 and your MCU. I have not seen any cases where the INA226 reports a wrong value, but I have seen some cases where isolator logic levels caused the device to not be properly communicated with. (In some cases, this was fixed by adding some capacitors to GND on both SCL and SDA for both sides of the isolator (~33pF). 

    Although individual bit flips could happen, I think it is more likely that the address did not reach the device. This would cause the MCU would read back 1's, causing a very large bus voltage or large (negative) current. For example, in your original message, you stated that there were voltage spikes up to 100V. The INA226 is only capable of reporting a register output value up to 40.96V. If you read back all 1's for the 16 bit register (which the INA cannot send, as it's first bit is always 0), then your code would interpret that as 81.92V (which is what I presume you rounded to 100V. I expect a similar thing with the shunt voltage. 

    If the error is logic level based, then switching to the INA228 may actually make it worse, since it has different thresholds than the INA226 in order to be compatible with 1.8V logic.

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 10 points

    Hello Mitch,

    We're employing the ISO1541QDRQ1. The digital logic level stands at 3.3V on the microcontroller side and 5V on the INA226 side. I'll add the capacitors to see if it alleviates the problem.

  • 0 in reply to Mo Mir
    TI__Mastermind 19385 points

    Hello Mo,

    I was mostly concerned with the low level voltage thresholds and outputs from the isolator. However, looking over the specs for the ISO1541QDRQ1, it looks like they should be compatible. I would still recommend looking at the full transmission for one of the bad measurements on both sides of the isolator to rule it out. Similarly you could add the capacitors and see if the problem goes away. 

    Here are a couple reference designs that use a digital isolator for reference:

     https://www.ti.com/tool/TIDA-00313 

    https://www.ti.com/tool/TIDA-01608 

    Regards,

    Mitch

  • 0 in reply to Mitch M
    Prodigy 10 points

    Hi Mitch,

    I incorporated 30pF caps at the INA side of the isolator on the SDA and SCL lines. Initially, during the voltage sweep, there was no spike in current .

    However, upon rerunning the same code, I observed multiple spikes in the current.

    Incorporating caps on the uController side consistently yields garbage values for both voltage and current.

     

  • +1 in reply to Mo Mir
    TI__Mastermind 19385 points

    Hey Mo,

    Ok, thanks for doing those tests. It's interesting that the communication didn't work with caps on the MCU side. It does seem like this is a communication issue and not an INA226 issue though. It may be good to watch the communication with a scope to watch the voltage levels to confirm they are getting low enough. I've also seen before where the MCU wasn't pulling the communication lines as low required. The fix for that case ended up just being a code change, as there was a setting in the MCU to allow it to pull down stronger (by changing the pull down current limit). What size pullup resistors are you using? And what is your communication speed? If the MCU is having a hard time pulling the lines low, you can use larger pullup resistors, but then you may need to slow down the communication for the test. (If this is the case though, you should be able to see it with an oscilloscope, so it would be good to use the scope to look at communication on both sides of the isolator).

    Regards,

    Mitch