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.

INA228: Periodic Error in Bus Voltage Measurement

Part Number: INA228

Hi - 

We have a design with several INA228 devices measuring the power supply voltages feeding our SOC (5 total voltages).  We've noticed as we sweep the power supply voltage to our SOC from -10% to +10%, there is a periodic non-linear variation in the INA228 bus voltage measurement.  This error has been repeatable across multiple boards and SOCs.

However, the periodic error is eliminated by increasing the conversion time.

I have included a chart showing the differences amongst a few different conversion times (CT) along with measurements from a Keithley DMM.  The error appears when the Conversion Time CT= 50 µs.  There appears to be very little difference compared to the DMM when CT=540 µs or CT=1052 µs.  In all cases, we are averaging 512 samples.

We chose a 50 µs conversion time because we were trying to capture short dynamic changes in the power supply load.

Could you please explain why increasing the conversion time removes this variation?

If this were just noise in the power supply, I would expect averaging to eliminate the noise.  On an oscilloscope, I am not able to clearly see this periodicity in the voltage.

Is it possible there is actually this variation as we adjust the power supply potentiometer and 50 µs conversion time accurately captures it?  ...or is it more likely this is some sort of aliasing or error in measurement due to the short conversion time?

Mostly, I'm trying to understand if I should simply increase the conversion time and disregard the variation, or if there is actually a periodic error in the voltage.

Thanks,

Tom

  • Hi Tom,

    looks like an aliasing error. Please specify the change rate of your bus voltage changes.

    It's like when a signal is superimposed by a 100Hz hum harmonic: When you sample the signal with a 101Hz sample rate you will see an aliasing artefact of 1Hz. Sample it with a sample rate of 200Hz and the aliasing effect is gone. A similar effect may occur with your sampling rate and the change rate of bus voltage change.

    Another cause could be that the circuit needs some time to stabilize after the change of digital trimpot.

    Kai

  • Hi Kai -

    Normally the supply is fairly low power and stable.  But, occasionally a dynamic load may happen with a significant increase in current over at least 35 µs.  Our intent was for the INA228 to detect the Vmin (minimum supply voltage value) during the dynamic load change.  So our hope was to detect this difference with the fastest conversion time possible.

    In the case mentioned above, however, we are not inducing these sorts of dynamic loads.  The SOC is idle and drawing minimal power.  The bus voltage is not dynamically changing during the measurement, yet we are seeing the error.  

    In the data shown above, the measurements were taken manually.  In other words, the digital pot was trimmed to the next value.  Then the INA228 was measured (alongside the DMM).  So there are literally seconds of time between digital trimpot change and measurement.

    Thanks,

    Tom

  • Hello Tom,

    Please see this video about power supply rejection error: https://training.ti.com/ti-precision-labs-current-sense-amplifiers-power-supply-rejection-error

    Also, the INA228 has a Delta-Sigma ADC, so increasing the conversion time is essentially like adding more averages. This is why you don't see as much ripple when you increase the conversion time.

    Regards,

    Mitch

  • Hi Mitch - 

    Regarding power supply rejection error, I'm trying to better understand how this would be related to my issue.  

    We have a completely separate linear regulator supply providing the 3.3V powering the INA228.  This supply is separate from the supplies to our SOC which we are measuring with the INA228.  In this case, for example, we have a 0.8V nominal switching supply to our SOC which we are measuring with an INA228 that is itself powered from an separate 3.3V linear regulator.  Perhaps, I'm misunderstanding?

    It makes sense that increasing the conversion time averages out the variations.  But, I'm not clear on why as this digital trim pot is incrementally adjusted which effectively increases our voltage (bottom of digital pot equates to 0.7V, top of digital pot 0.9V) why we'd see this periodic variation in the voltage measurement.  This variation is repeatable (i.e. I am manually changing the voltage from 1 trim pot setting to the next and the chart I show above replicates).  

    When I capture the ripple on a scope, I see something on the order of 17 mV of ripple (peak-to-peak).  But, as I monitor this 17 mV of ripple, it does not dramatically change as I sweep the voltage from 0.7V to 0.9V.  So I'm not seeing that the actual ripple is a function of the voltage, or that it has some periodicity in its magnitude.

    Thanks,

    Tom

  • Hey Tom,

    Sorry, I misread the original question to be that you were varying the power supply to the INA228s, not power supply that you were measuring with the INA228...

    In that case, I have a few follow-up questions:

    1. Could you please send a schematic for the circuitry around the INA228?
    2. What is the time scale on the plot/image you showed?
    3. Could you send the scope shot that you referenced of the ripple?
    4. Do you have a capacitor on the input pins?
      1. If not, could you try with a 0.1µF cap?

    Regards,

    Mitch

  • Hi Mitch -

    1. Could you please send a schematic for the circuitry around the INA228?
      1. Tom:  I attached the INA228 circuitry.  Note that this is measuring a supply, so there are lots of local decoupling (0.1µF) capacitors along with bulk capacitance.  Note the INA228 is using the VBUS net as we are measuring bus voltage only.
    2. What is the time scale on the plot/image you showed?
      1. Tom:  I don't think there really is a time scale.  Each point was a manual operation of setting the voltage via an in-circuit digital trimpot, and then making measurements (via INA228 reading, or via DMM, or via scope) all manually.  More or less, I just filled in a table of individual measurements.
    3. Could you send the scope shot that you referenced of the ripple?
      1. Tom:  Attached - this is a scope example of ripple.  Note that I've bandwidth-limited the scope to 20 MHz to filter high frequency noise.
      2. I captured the ripple for each point in the digipot range and the measurements are fairly consistent with no correlation to the variation in the chart I showed in my original message.
    4. Do you have a capacitor on the input pins?
      1. If not, could you try with a 0.1µF cap?
        1. Tom: As mentioned above, we aren't using the IN+ and IN- pins, but rather the VBUS pin.  But there are lots of 0.1µF caps on this net near the VBUS measurement point.

  • Hi Tom,

    I would not leave the shunt inputs float. I would connect IN+ and IN- both to the GND pin of INA228.

    And I would insert a low pass filter at the VBUS pin to remove the HF-noise.

    Kai

  • Hi Kai -

    As seen in the image above, the shunt inputs are grounded in my circuit.

    Tom

  • Hey Tom,

    Thanks for sending that info. I don't see anything wrong with the schematic....  I see that you have the averages set 512, does the ripple still happen when you use the longer conversion time with less averages?

    Regards,

    Mitch

  • As seen in the image above, the shunt inputs are grounded in my circuit.

    Thumbsup

  • Hi Mitch -

    From what I can tell, you do see variation when you turn the average way down but have the same conversion time.  For example, see the purple trace where the conversion time is 512, but the average is 1.

    As I repeatedly rerun this scenario with CT=512, Avg=1, the result bounces around within a reasonable range.  I'd expect this given we aren't utilizing the averages.  

    I think the distinction and still unexplained aspect is why with conversion time of 50 µs and even with an average of 512, there is repeatable periodicity in the variation.  If I were simply capturing random noise, I'd assume it wouldn't have the repeatable periodic pattern around what is measured with the DMM and longer conversion times. My guess is it that it is a function of the ADC. 

    Thanks,

    Tom

  • Hi Tom,

    since the error varies with the input signal at the VBUS pin, it definitely has to do with the input signal itself. And as you say that you have to limit the bandwidth of scope to 20MHz to filter out HF-noise -while keeping in mind that the ADC of INA228 is vulnerable against HF-noise close to the sampling rate and its harmonics- I think that what you see is aliasing artefacts. See section 8.1.4 of datasheet.

    Since the decimation filter on the output of ADC cannot prevent aliasing, the best remedy against aliasing is passive input filtering. So, I would add a low pass filter directly at the VBUS pin. Choosing a 100R filter resistance will keep the error in combination with the 1M input resistance of VBUS pin below 0.01%. And because the low pass filter at the VBUS pin has to be common mode (instead of the differential input low pass filtering at the IN+ and IN- inputs recommended in section 8.1.4) the low pass filter cap must be connected from the VBUS pin to signal ground. And since you intend to capture 35µs events, the time constant of low pass filter should be arround 1µs? 3 tau would be 3µs then which is less than 10% of 35µs. In this case a 10nF cap will do. This will give you a corner frequency of low pass filtering of 160kHz which should considerably improve the aliasing issue.

    Kai

     

  • You even could steepen the low pass filter by adding a 22µH inductance in series to the 100R resistor:

    Choose a 22µH inductance with low parasitic winding capacitance or, by other words, choose a 22µH inductance with a high self resonance frequency. Or mount two 10µH inductances in series.

    Kai

  • Thank you Kai.  

    I will see if we can rework our board.  It may be a bit tricky, but if it's feasible I will try.

    Thanks,

    Tom