normalize routine in setMaxCurrent not working?

[morrowwm]

I am setting the calibration register using

INA.setMaxCurrentShunt(5, 0.097563559322034, false);

added to setup() in your INA226_demo sketch and seeing values that match what my multimeter measures fairly closely.

I uncommented and augmented the debug print statements in setMaxCurrentShunt():

  // normalize the LSB to a round number
  // LSB will increase
  if (normalize)
  {
     Serial.print("Initial current_LSB:\t");
     Serial.println(_current_LSB, 10);
    uint32_t factor = 1;
    while (_current_LSB < 1)
    {
      _current_LSB *= 10;
      factor *= 10;
    }
    _current_LSB = 10.0 / factor;
     Serial.print("factor: "); Serial.println(factor); 
     Serial.print("current_LSB:\t");
     Serial.println(_current_LSB, 10);
  }

This showed:

Initial current_LSB:	0.0001525879
factor: 10000 current_LSB:	0.0010000001
Calibration:	34
Current_LSB:	0.0010000001192092 uA / bit

The _current_LSB value has shifted by a factor of 10

It looks like

_current_LSB = 10.0 / factor;

should be

_current_LSB = 1.0 / factor;

I made that change and see:

Initial current_LSB:	0.0001525879
factor: 10000
current_LSB:	0.0001000000
Calibration:	20D
Current_LSB:	0.0000999999904632 uA / bit

Thank you for this library, and figuring out the calibration process.

[RobTillaart]

Thanks for reporting the issue, might take a few days

[RobTillaart]

Will start investigating today.

[RobTillaart]

No setup to test. Your analysis is looks correct.

[RobTillaart]

@morrowwm
Created a PR - see develop branch. Can you check this branch?

[morrowwm]

It looks good. The current calculated by the INS226 is very close to that measured by my multimeter.

[morrowwm]

Alternatively, what do you think of this approach to forcing current_LSB to be an integer, i.e. normalized?
INA226.cpp.txt

Starting at line 217, calculate calib, forcing no fractional part with round(). Then recalculate current_LSB using that calib.

This approach does not change the max current allowed as much.

Initial current_LSB:	0.00015259
Normalized current_LSB:	0.00015255 uA / bit
Max current:	5.00 A

[RobTillaart]

Then recalculate current_LSB using that calib.

why didn't I think of that!
Very good point as that way the internal variables stay way more consistent.

forcing current_LSB to be an integer

Would make sense to me if one could do the whole math in integer units.
Can you name some advantages?
I make a note in the future section in the readme,

[morrowwm]

Would make sense to me if one could do the whole math in integer units. I agree, integer would align better with reality in the 16 bit registers. I haven't really figured out how to do it, though.  I think the suggested approach is close to that. You could think of it as:1) determine the factor between one bit and current, measured in amperes. Max current is 15 bits, 0x7FFF. The factor is     maxCurrent / 0x7FFF  <-- you'r already doing this.2) but we want factor to be an integer, so round it3) recalculate maxCurrent using the rounded factor On Wednesday, February 2, 2022, 11:59:36 a.m. AST, Rob Tillaart ***@***.***> wrote: Then recalculate current_LSB using that calib. why didn't I think of that! Very good point as that way the internal variables stay way more consistent. forcing current_LSB to be an integer Would make sense to me if one could do the whole math in integer units. Can you name some advantages? I make a note in the future section in the readme, — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[RobTillaart]

Just pushed a new version of .cpp file.

I added some #ifdef at the start of the function for switching on/off print statements.
furthermore it includes your suggestion to calculate current_LSB back from rounded calib.

give it a try.

[RobTillaart]

Doing all the math in integer will need more testing and I have so HW nearby (and enough time)
Note in readme to keep the thought

[morrowwm]

give it a try.

I had to remove the old normalize lines, starting at about line 235. Then I defined printdebug and also added more digits to the _maxCurrent debug:

With normalize = false:

normalize:	 false
initial current_LSB:	0.00015259 uA / bit
factor:	1
Final current_LSB:	0.00015259 uA / bit
Calibration:	344
Max current:	5.00000000 A
Shunt:	0.09756356 ohm

BUS	SHUNT	CURRENT	POWER
6.984	-4.600	-47.150	331.879
6.986	-4.600	-47.150	331.879
6.986	-4.600	-47.150	331.879

And with normalize = true:

normalize:	 true
initial current_LSB:	0.00015259 uA / bit
Prescale current_LSB:	0.00015255 uA / bit
factor:	1
Final current_LSB:	0.00015255 uA / bit
Calibration:	344
Max current:	4.99889278 A <--- no longer 5.0, but an integer multiple of current_LSB
Shunt:	0.09756356 ohm

BUS	SHUNT	CURRENT	POWER
6.986	-4.603	-47.139	331.805
6.985	-4.600	-47.139	331.805

[morrowwm]

Here's my test version. I should learn how to use git more completely.  On Wednesday, February 2, 2022, 01:52:30 p.m. AST, Rob Tillaart ***@***.***> wrote: Just pushed a new version of .cpp file. I added some #ifdef at the start of the function for switching on/off print statements. furthermore it includes your suggestion to calculate current_LSB back from rounded calib. give it a try. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[RobTillaart]

So the new version works and still mayches your multimeter?

[morrowwm]

So the new version works and still matches your multimeter?

Yes, it works well. Matches my multimeter to about 1 part in 400, both normalized and not.

I'll see if I can find a setup that will hold a stable, higher current and get more than three digits to measure.

[RobTillaart]

You might need to check the datasheet if you can get much better than 1 in 400 in terms of precission.

[morrowwm]

My multimeter is not very good. I will need to increase amperage to get any more precision. On Wednesday, February 2, 2022, 05:50:59 p.m. AST, Rob Tillaart ***@***.***> wrote: You might need to check the datasheet if you can get much better than 1 in 400 in terms of precission. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[RobTillaart]

You might need to check the datasheet if you can get much better than 1 in 400 in terms of precision.

The datasheet mentions several causes of small errors (see below) which in the end add up so a difference of 0.25% is not bad at all, given that most multimeters are in the 0.2% range themselves. You need a DMM with 0.02% or better to make better measurements (professional or lab equipment)

[RobTillaart]

@morrowwm
Are there other (serious) bugs that must be fixed?
Otherwise I merge this version and start a new branch for other issues if they appear.