• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

INA260: How to get most accurat reading for flukturating motor and battery readings

Arne Steinstad
Prodigy 10 points
Part Number: INA260

INA260 have two fetures to average and make the signal better the time to take the sample and the oversampling of the signal. How to combine this to the software. 

I have a signal that is from a motor and this signal is quite jumping up and down. key for me is to get the most accurate average reeding and hopfully can calculate the Wh it consumes as close as posible. 

So the question is :

What is the best aproche to make this? have the fast sampling and 1024 averaging or to have both the long sampling and 1024 averaging. Then how to tie this to the software ? should i sample 1 pr ms or should i sample like if i have 8.244ms sampling time and 64 times oversmapling then only read the sensor 1 time in the combined 8.244ms*64 + some delay to secure tolerances for the reading or should i sample still at 1ms ? 

My hope was that by having 8.244ms sampling time and then 1024 i can cover the full time of this 8.244ms*1024 and only read it once in this cycle to get a accurate average current! 

  • 0
    TI__Mastermind 34130 points

    Hi,

    I think the best approach for this application is to use the fastest sampling rate, and average over the longest period possible. If desired, a moving average over multiple measurements can further be calculated.

    When delay is included in reading measurement results, the controller will miss samples. The longer the delay, the more missed samples over a fixed length of time. Even without delay at all and the controller samples exactly every 8.244ms*64 (citing your numbers), there is still going to be missed samples. This is due to the fact that INA260 runs independently and the actual conversion time is not exactly 8.244ms.

    To have better synchronization, you could instead use triggered conversion. But this mode inherently means the measurement is blanked out periodically.

    Longer conversion and greater averaging don’t always work in our favor when dealing with time-varying signals. An example is shown in this report, even though the application is different.

    Regards, Guang