firmware
firmware copied to clipboard
meshtastic
[Bug]: ina3221 inverts current over certain values (maybe signed int overflow?)
Category
Other
Hardware
Rak4631
Firmware Version
2.4.* to at least 2.5.15
Description
I have an ina3221 setup with input 1 showing power being used, input 2 showing solar being provided, and input 3 showing the actual current flowing in out of the battery.
The first two should always be positive, the third should be positive when drawing current from the battery and negative when it's being charged.
With low current this is always the case, when one of them goes over about 250mA it inverts that value.
I suspect this is a mismatch in int lengths between the library that's taking the values and where it's being stored as it's typical of a 2s compliment overflow (although strangely would seem to be 9 bits)
Relevant log output
Have you correctly changed the address of the INA3221 off the default so it is correctly recognized by the firmware? You need to bridge SDA.
You beat me to it, I was going to open a report about this soon... Same issue as you, but after a while it fixes by itself, idk if happen the same to you.
Have you correctly changed the address of the INA3221 off the default so it is correctly recognized by the firmware? You need to bridge SDA.
Yes, you don't get any values at all if you haven't changed the address.
You can see from the images here in getting values, and that they suddenly reverse ( particularly channel 2, the solar input)
This does seem very typical of a twos compliment overflow. Where large values cause the first bit of the word to become a 1 which is then interpreted as a negative value.
You beat me to it, I was going to open a report about this soon... Same issue as you, but after a while it fixes by itself, idk if happen the same to you.
From my limited observations, once it falls back below a threshold it reverts back to reporting correctly.
That seems slightly different to what we see in your graph.
I sent the dev a note about this back in Nov. I don't have the code in front of me, but the issue was something like shunt_uV becomes negative due to overflow the calculated current becomes incorrect.
The fix should be to use an int32_t in getshuntvolt
Had a quick look in the code and there is indeed a uint16 in there at the moment.
I sent the dev a note about this back in Nov. I don't have the code in front of me, but the issue was something like shunt_uV becomes negative due to overflow the calculated current becomes incorrect.
The fix should be to use an int32_t in getshuntvolt
I also had a look, before seeing your comment.
It's absolutely in need of an int32_t as the multiplication by 40 overflows the int16.
Going to try this on my local and see if it works
I've only just managed to try my change (been unwell), and for the first time I'm seeing higher values.
I've got about 40W of 12v solar which even in cloudy rainy Britain should generate more than 260mA, and it looks like it's working ok as the channel which monitors the power usage of the node is showing the same sort of value as before.
I've only just spotted that the code for the inna3221 code is from a different repo. That repo is a fork of another which already seems to have some sort of fix for this issue. I'll figure out where to PR
I've now managed to confirm the figure using a multimeter to monitor the current in line with one of the channels.
It is correctly reporting current up to an amp now.
I'll get the PR opened today.
I've now managed to confirm the figure using a multimeter to monitor the current in line with one of the channels.
It is correctly reporting current up to an amp now.
I'll get the PR opened today.
Thank you for staying on top of this, I've been meaning to check how I did it back in Nov, but... life. Will be nice not to have to worry about one more library during builds. Cheers!
has anyone been able to check if the INA3221 still works in .19, .20 or .21? I just tried and it didn't seem to work, but I'm running wonky custom hardware, and it could just be me.
I'm running a custom built .20, It works for power telemetry, but I've been having issues getting it to be used for battery %.
has anyone been able to check if the INA3221 still works in .19, .20 or .21? I just tried and it didn't seem to work, but I'm running wonky custom hardware, and it could just be me.
I flashed .21 on my NRF nodes and I noticed that Battery % from either INA3221 and 219 is broken. Also, idk if it related, but the INA219 values are no longer passed by ch3 curr/voltage. It stops broadcasting that packet, no problem with the INA3221...
Sounds like a different issue to this one, but worth comparing the source from an earlier version to .20 When did it work last?
Sounds like a different issue to this one, but worth comparing the source from an earlier version to .20 When did it work last?
I went back to the .18 code base and its working fine. Ill take a look at the later ones this weekend to see what's up.
i use .18 and had to switch android app option Power Config -> Battery INA_2XX I2C address value to 66 to get it to report channel 1 as battery, and channel 2 as solar power values in the right order. I also added these lines in my variant.h file #define INA3221_ADDR 0x40 #define INA_ADDR 0x42
~~INA3221 current reading seems to be broken on 2.6.0 anyone else get the chance to try it out?~~
Neverminded they seemed to have changed the shunt value.
I also use the INA3221 to measure currents in my solar node and unfortunately found that even in firmware 2.6.4 the issue with changing values from positiv to negative (or vice versa) still occurs.
As soon as a value exceeds a magic limit of approx. 326mA the the value changes to -326mA and rises back towards 0. (336mA will be shown as -316mA and so on...) This is very confusing if you want to check if the battery is charging or discharging.
Is there a chance to solve this issue in one of the next firmware versions?
All the best and thanks for your great work!
Should we fork the current INA3221, merge the PR from @sgtwilko and update the dependency on the platform.ini? It looks like the maintainer of the INA3221 is not responding for months.
Another option is to use Adafruit library (most of the other sensors use Adafruit), which uses floats for the measurements.
I am happy to work in any of those solutions. I am of course facing this issue too with my solar node.
I don't know if that's the best way to solve the issue but I modified the platformio.ini file in order to use @sgtwilko branch. I opened a pull request #7607
