Code Monkey home page Code Monkey logo

ina's People

Contributors

avaldebe avatar batarian711 avatar magnmci avatar nathancheek avatar per1234 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ina's Issues

Change maxBusAmp ::begin parameter from Amp to mA

I would like to be able to enter the maxBusAmp in mA (e.g. 819 mA) to achieve a better Calibration value on the INA226 when the shunt R = 100 mOhm; as is the case with most modules you can purchase (e.g. CJMCU-226, etc.).

Using INA in Teensy 3.x boards

I have been unable tu use the library in a teensy 3.2 board, I changed the include from Wire.h to i2c_t3.h. It compiles but at least the example file does not detect an INA226. I can detect it using a scanner sketch which runs OK in teensy.

Add INA3221 Support

The INA3221 device supports measuring 3 circuits simultaneously, at the cost of longer measurement times for the same accuracy. The library should be in a Position to Support this device as the Register structure is quite similar. The device has no calibration Register because it only measure bus and shunt voltages, so the Amps and Watts computation are to be done in the library.

The INA3221 will Show up as 3 distinct devices.

Update library.properties

Please update version number on library.properties. This is required to retrieve the latest version of this library trough PlatformIO.

Typo in #define for ESP8266

After a break, I am back working with INA devices. This time using ESP8266 processors, and have found another issue

In INA.cpp there is a typo on line 186
#if defined(ESP32) || defined(ESP2866)
should read
#if defined(ESP32) || defined(ESP8266)

The typo causes problems if there is more than one INA device.

The same typo is present in library.properties line 9
This causes the Arduino IDE to throw up a warning when compiling.

Thanks

Derek

Change case of the "Alert..." functions

Is your feature request related to a problem? Please describe.
These functions should be in lower case to conform to the other functions and applicable style standards

Describe the solution you'd like
Change to initial lowercase, but keep an overloaded definition in the library for backward compatibility

Describe alternatives you've considered
Keeping the current definitions would work, but is not elegant

Additional context

Zanshin Logo

INA3221 negative currents reported incorrectly

I found when using INA3221, negative currents were always reported incorrectly. I traced the problem to the function INA_Class::getShuntMicroVolts
The function uses a '&' bitwise operator when it should use '|' to set the top 3 MSB high for negative voltages.

  if (shuntVoltage&0x8000) {                                              // If the shunt is negative, then   //
    shuntVoltage = (shuntVoltage>>3) | 0xE000;                            // shift over 3, then 3 MSB to 1    //
  } else { 

Thanks for a most useful library.

Derek

Issues with ESP32

I found two issues with using the INA library with an ESP32 processor.

First

ESP32 allows programmable selection of I2C pins and while pins 21,22 are the default, those pins do not appear on many development boards. My workaround was to hardwire SDA, and SCL into the Wire.begin statement in INA.begin.

Second

INA.begin tests to see how much space is available in the EEPROM. But ESP32 returns EEPROM.length as zero by default, and begin fails. My workaround was simply to skip the test.

documentation: more clearly indicate how to clear interupt flag

Hi there,

working with the lib I literally just spend over an hour looking for a bug until I realised that when using OnConversion-Alert, I have to call waitForConversion to clear the Interrupt in the device. This wasn't intuative for me as I thought I replaced the waitForConversion usage with an interrupt handler.
I was somehow expecting, that reading the data registers does reset the flag.
I assume calling waitForConversion in this case does not acutually wait and loose any time.

Maybe this case could be made clearer in the documentation of alerts and the waitForConversion-Function.

cheers, Daniel.

STM32F01 support

Do not know the exact reason, but the EEPROM library on the stm32f01 core has not updated to its interface to the new version the avr core.

STM32F01 microcontrollers have no flash, and the EEPROM library uses flash memory to emulate it. The EEPROMClass on this old version of the library does not have the get, put and length methods. These methods are only available on the new version of the library.

Reduce EEPROM footprint

inaDet struct is no longer 96 bites long, as in INA226. Now it is 248 bytes (please correct my math if wrong). Therefore the maximum number of devices on a ATmega328 is 4, and 2 on ATmega168.
This not enough for the application I have in mind.

I was planning to implement some of the following reductions, and would appreciate your opinion.
If you are interested, I'll submit a PR once I have tested my changes.

As far as I can see, only address, type, operatingMode, maxBusAmps, microOhmR and virtualDeviceNumber need to be saved to EEPROM. The rest can be inferred from the type when needed. Then each INA devise would only use 72 bits,

Furthermore, type, operatingMode and virtualDeviceNumber can be packed on a single uint8_t using bit fields. This would bring down the size to 56 bits.

typedef struct {
    uint8_t  address;
    uint8_t  type: 3;                 // possible values 0 .. 8
    uint8_t  virtualDeviceNumber: 2;  // possible values 0 .. 4
    uint8_t  operatingMode: 3;        // possible values 0 .. 8
    uint8_t  maxBusAmps;
    uint32_t microOhmR;
  } inaDet;

Finally, address, microOhmR and maxBusAmps could be pack into a single uint32_t using bit fields. This would bring down the size to 40 bits, but it turn out to be an overkill. address and maxBusAmps have to be cast to the appropriate type before use...

typedef struct {
    uint8_t  type: 3;                 // possible values 0 .. 8
    uint8_t  virtualDeviceNumber: 2;  // possible values 0 .. 4
    uint8_t  operatingMode: 3;        // possible values 0 .. 8
    uint32_t address: 7;              // possible values 0 .. 127
    uint32_t maxBusAmps: 5;           // possible values 0 .. 31
    uint32_t microOhmR: 20;           // possible values 0 .. 1.048.575
  } inaDet;

There is a detailed list of the reductions I mentioned earlier.

  • deviceName (save 64 bits): switch case on getDeviceName
  • current_LSB (save 32 bits): private function
  • power_LSB (save 32 bits): private function
  • shuntVoltage_LSB (save 16 bits): private function
  • busVoltage_LSB (save 16 bits): private function
  • currentRegister (save 8 bits): switch case on getBusMicroAmps
  • shuntVoltageRegister (save 8 bits): switch case on getShuntMicroVolts
  • type, operatingMode and virtualDeviceNumber (save 16 bits): use bit fields
  • address, maxBusAmps and microOhmR (save 16 bits): use bit fields

Please let me know what you think it makes sense, and what would you your like to see on a PR.

No way to check ConversionReadyFlag only waitForConversion is possible.

To coordinate reading of data from ina226 registers is necessary to read ConversionReadyFlag,
but it can done only calling waitForConversion,
that function in not cooperative multithread friendly (in esp8266 is necessary to call yeld or delay function when waiting).
I suggest same function whit single device target without loop and return cvBits.

small bug in header definition

Hi there,

i was trying to use the library with the eclipse arduino plugin sloeber.
However I got multiple error on redefinition of symbols.
Turns out in you header file there is a typo in the guard code:

#ifndef INA_Class_h                                                           // Guard code definition            //
  #define INA__Class_h                                                        // Define the name inside guard code//

should be

#ifndef INA__Class_h                                                           // Guard code definition            //
  #define INA__Class_h                                                        // Define the name inside guard code//

(extra underscore missing).
Now it compiles fine.

INA226 Current Reading Saturation

When setting up a 75A 75mv shunt using INA.begin(75,1000) the current reading saturates at 10.999A
Trialing INA.begin(31,1000) works correctly at 30.999A
Trialing INA.begin(32,1000) saturates at 0A
Trialing INA.begin(33,1000) saturates at 0.999A
Its possible there is a variable that is reaching its limits and rolling over in the INA.begin() function causing the wrong maxCurrent to be written
I can work around this issue by changing INA.begin(75,1000) to INA.begin(7.5,10000) then multiplying the current by 10

[ESP8266] Conflict if EEPROM is used in main code.

I use in my esp8266 emulated EEPROM in main code and begin it with (4096) in size for main
code purpose(only 1024 byte used), is possible to avoid in library eeprom size call and add start pointer so i can initialize bigger area and put ina2xx data upper o lower main code data?

Add support for ultra low-power measurement

I'm using INA-226 to measure the power consumption of ultra low power chip, which is ~100uW. This lib now limits max shunt resistor to ~1.05 Ohm, and the unit to specify max bus current is Amp. I understand that this is quite enough for a typical condition where shunt is at mOhm level and bus current is from 0.x ~ 1xx Amp; however it won't fit my case, that I'm using a 10 Ohm shunt and I want to set max bus current to 1 mA.

Currently I've made these modifications to fit my case:

  • extend bitwidth of microOhmR to 25, allowing a 10 * 1000 * 1000 micro Ohm shunt;
  • change current_LSB to maxBusAmps * 1000000 / 32768, which actually means change maxBusAmps to maxBusMilliAmps;

The mesurement result seems ok comparing to a 7(1/2) digit multimeter, and I guess it could be better if:

  • directly specify current_LSB, instead of div from max bus current;
  • add getBusNanoAmp(Watts), to preserve more effective digits;
  • (probably) some calculation be optimized to reduce rounding error

I'm not sure whether these will break the existing code, or bring any other side effect; so I hope that a more compatible and robust solution could be included to this lib to support low power measurement.

INA219 uses lower range of 0-16V for bus voltage

The Bus Range bit (BRNG) is set at device instantiation to the voltage range of either 0-16 or 0-32V depending upon the voltage at that point in time. Since the only difference using the lower range is a very slight gain in accuracy it makes more sense to hard-code the full range into the device.

small errors

  1. Do not call Wire.begin(). It is up to the system to set up the bus not the library. (With this call you reset the bus and all other devices get stuck uninitialized) esp8266/Arduino#2607
  2. wiki: The operation mode 100 is missing, copy-paste-error

Wrong VBUS Reading

The device gives wrong vbus reading .
for example please see the table below
DMM reading................... INA226 Reading
2.467.........................................2.60
4.976.........................................5.24
7.64............................................8.05
10.00.........................................10.53
the current reading is correct.

wrong I2C_MODES type

the I2C_MODES are defined as uint16_t. The type too small to hold their actual values,
which triggers several overflow warnings like the following:

INA/src/INA.h:88:52: warning: large integer implicitly truncated to unsigned type [-Woverflow]
const uint16_t I2C_STANDARD_MODE            =  100000;                    // Default normal I2C 100KHz speed  //
^

The type be uint32_t as in the Wire.setClock definition.
The argument to INA_Class.setI2CSpeed argument should also be uint32_t.

getId() to return dec/Hex value of the Id

Is your feature request related to a problem? Please describe.
i can not allways determine which INA219 is read as Id's are incrementaly created.

Describe the solution you'd like
I wold like to see the example displayreadings.ino to show the Hexadecimal or Decimal id of the read shunt.

Describe alternatives you've considered
Don't know if thats possible. No alternatives.

Additional context
bildschirmfoto 2019-02-08 um 13 39 38

bildschirmfoto 2019-02-08 um 13 41 24

Incorrect bit mask for INA226_CONFIG_SADC_MASK

The INA226 shunt voltage conversion time is specified in bits 3-5 of the config register (from datasheet) but INA.h has the mask as bits 3-4.

The bitmask should be:
const uint16_t INA226_CONFIG_SADC_MASK = 0x0028; ///< INA226 Bits 3-5

A related thing: I don't think it makes any difference as the config register MSB (reset bit) is always 0 in normal operation, but configRegister probably should be unsigned.

Initializing INA device does reset RTC DS3231M (RTClib)

Hi !

I have an I²C bus with an INA226 and an RTC DS3231M. I'm using RTClib. When in my code I initialize my INA
INA.setI2CSpeed(INA_I2C_STANDARD_MODE);
INA.begin(3, DEFAULT_R_SHUNT ,0); //Init INA device
INA.setBusConversion(8500); // Maximum conversion time 8.244ms
INA.setShuntConversion(8500); // Maximum conversion time 8.244ms
INA.setAveraging(128); //Average 128 readings
INA.setMode(INA_MODE_CONTINUOUS_BOTH);
It does something weird with my RTC, it resets the minutes and the seconds from the RTC which I don't get at all. What I've read from the source code is that it "scans" the I²C bus from the address 0x40 to 0x80 (my INA device has 0x40 as address) and the RTC address is 0xD0...

I could track down to problem and reproduce it with this pseudo code :
DateTime dt = RTC.now();
print(dt);
InitINA()
dt = RTC.now()
print(dt);

which output something like this:
8h43m15s
Initializing INA
8h0m0s

Note that this happens only when initializing the chips, when after that I read both Bus Voltage and Bus Current the RTC works perfectly fine.

I have a tight deadline so I wasn't able to find which of the INA method produces this but when I get the time i'll update this post.

Thanks a lot for this great library, It helped me a lot ! Have a great day,

Anthony

Power calculation inconsistent between ina219 and ina3221

Expected Behavior

Have connected a ina219 in series with the three sections of an ina3221 and using the test code expected to see the same current, voltage and power readings for each device. Taking into account the shunt tolerance and the voltage drop across each shunt.

Actual Behavior

Screen dump below of displayed readings.

15:03:32.408 -> Nr Adr Type Bus Shunt Bus Bus
15:03:32.408 -> == === ====== ======== =========== =========== ===========
15:03:32.408 -> 1 64 INA219 4.6000V 4.9400mV 49.4080mA 227.0530mW
15:03:32.448 -> 2 66 INA3221 4.6000V 4.9200mV 49.2000mA 28.7500mW
15:03:32.448 -> 3 66 INA3221 4.6160V 4.9600mV 49.6000mA 30.6960mW
15:03:32.448 -> 4 66 INA3221 4.6320V 4.9600mV 49.6000mA 30.8020mW

Note that the power reading for the ina219 is about expected given the ~5v @ 50mA draw (ie ~250mW)

Steps to Reproduce the Problem

Explain what needs to be done in order to reproduce the problem.

  1. Wire the ina3221 current shunts in series followed by the ina219 shunt.
  2. Run the test code and see outputs

Specifications

Suspect that there is an overflow in the power calc somewhere

Add a tips about MaxBusAmps

Hi,

I use INA226 with 2mΩ shunt resistor
Because the Calibration Register only have 15bit, when I set MaxBusAmps=5, Calibration=33554. It will overflow and output a error result.

Please add a description that the MaxBusAmps can't smaller than (0.00512/ShuntR(Ω))

Thanks for your high performance INA lib

Function "getBusMicroWatts" limited to +/- 2147 Watts

The return datatype for this function is a 32-bit integer in microWatts; hence the limitation. Changing the return datatype to a 64-bit integer will allow sufficient Watts to be returned by the function.

This was raised in issue #54, but that issue was closed without resolving this problem, hence the new issue for tracking purposes.

Duplicate conversion triggering

getShuntMicroVolts() calls getShuntRaw() which checks the device mode and triggers a conversion if appropriate.

However, after this call, getShuntMicroVolts() proceeds to also check device mode and trigger a conversion if appropriate. This results in 2 conversions being requested instead of 1.

getBusMilliVolts() seems to do this properly. It calls getBusRaw() which triggers the conversion, and does NOT try to trigger a conversion itself.

Hardcode EEPROM size

I think there should be a posibility to set EEPROM size in begin() method. Before your last merged I did a test with an EEPROM_offset and works correctly but changing the line

EEPROM.begin(512).

For example, If I need 400 bytes for my main project and I want another 512 bytes for INA library the begin method should set EEPROM to 912. Right?. You can expose antoher variable to set EEPROM size and initializate to a default value to have backwards compatibility.

In the other hand, you calculate max_devices including the EEPROM_offset variable ,If the library is not allowed to use the offset, the maximum devices should be:

maxDevices = (EEPROM_size - _EEPROM_offset ) / sizeof(inaEE);

instead of

maxDevices = (_EEPROM_offset + EEPROM_size) / sizeof(inaEE);

I did all the tests with an ESP32. Hope something of that help you to improve the library,

inconsistent unit on setBusConversion

The convTime input to INA_Class::setBusConversion has inconsistent units between INA219 and other INA devices.

Table 5 on the ina219 datasheer shows conversion times between 84 μs and 68.10 ms. As far as I can tell, this correspond to lines 256-266 on setBusConversion. The upper limit of 68100 implies that the variable convTime is on μs, which is consistent with the wiki.

Table 7 on the ina226 datasheer shows conversion times between 140 μs and 8.244 ms.
Which corresponds to lines 272-279 setBusConversion. The upper limit of 82440 implies an unit of 0.1 μs.

As far as I can tell the same problem is present on INA_Class::setShuntConversion.

In concussion, I think that there is an error on the INA226 settings.
That 82440, 41560, 21160 and 11000 setBusConversion and setShuntConversion are one order of magnitude too big.

Change EEPROM functionality for non-AVR systems

Currently the library only works for AVR-Based processors because use is made of the EEPROM calls on the Arduino. The EEPROM is used to store information for the INA devices found because this information is static per run and space for program memory can freed up by moving this data to EEPROM.

On non-AVR processors there is generally a lot more memory available, so the EEPROM data space can be reserved once at startup from the heap and read directly.

Implement "clang-format" to format c++ using a standard style

Describe what the feature request is and if it solves an issue or adds functionality
Currently the formatting of the library and example programs is non-standard. Using a standardized tool such as "clang-format" allows for a more legible source code and makes applying pull requests from multiple contributors much easier

Describe the solution you'd like
Add "clang-format" to the GitHub actions to automatically format on commit

Describe alternatives you've considered
none

Additional context
While I like working on a wide screen with the current 120-column width, it is non-standard.

Accommodations for bigger current and power

Thanks for the nice library. I'm looking to make my own battery monitoring system for our sailboat. What better library to use than the SV Zanshin library?

It would appear that this library was written with much lower currents in mind, despite https://github.com/SV-Zanshin/INA/wiki/begin() saying: "For example, a 200Amp / 50mV shunt which has a resistance of .25 mOhm and which is initialized as "begin(200,250);" ". This is the exact shunt I am using.

It would appear that the inaEEPROM structure limits maxBusAmps to 7 bits, or 0-127 Amps, correct? So if I used your example above in the wiki, this would fail, wouldn't it? Is it as simple as changing the inaEEPROM typedef from uint32_t maxBusAmps : 7; to : 8 (255A) or : 10 (1023A)(for even larger boats, lol)?

I'm also concerned about the overflow of getBusMicoWatts. If I understand correctly, this long would overflow above 2147 watts, which would be very possible if using a 2000W inverter (or larger). How best to handle this?

This is what I've found so far. Are there other pitfalls I have to be aware of and change?

Thanks,
Chad
S/V Kookaburra

Trying to understand implementation of INA3221

I've implemented example programs using the INA3221. They seem to work, with one part I don't understand: Currently, when a single INA3221 is connected (using ESP32), it is discovered as 3 devices on address 64. In the DisplayReadings example program, it lists three devices, and it appears that all three devices have the same readings.

How does one differentiate between the three channels of the INA3221?

Possible error with INA226

Taras sent in the following:

Hi there. I used your library for INA226. Found an error. In the example DisplayReadings.ino
power is not calculated correctly. I add a screen.
V = 8,843 V
A = 35.736 mA
V * A = 8.843 * 35.736 = 316mW
, and in the example it turns out 253 mW.
Could this be a library error? Maybe it's my fault?

--
INA226 ERROR

The Shunt is 0.1Ohm and the original DisplayReadings.ino settings were used.

Logo

Hi. I am a graphic designer. I volunteer to design a logo for open source projects. I can design it for you to use it in the text file. What dou you say?

Will not compile for Teensy

Function readInafromEEPROM() calls EEPROM.read() if the device is a Teensy. However, if the device is a Teensy, the EEPROM.h library is not included. Problematic calls to EEPROM exist elsewhere in the library as well.

This leads to the error 'EEPROM' was not declared in this scope.

The EEPROM.h library needs to be included if the program is being compiled for a Teensy. This can be accomplished by adding defined(CORE_TEENSY) to the list of checked devices on the following line:
https://github.com/SV-Zanshin/INA/blob/3133e28761f823a3bd51ebc29b29620c3dd0972b/src/INA.cpp#L11

begin does not set values on subsequent calls

I call begin with 2 parameters to discover the devices. I passed the maxamps and microohms arguments and those are applied to all devices. I then call begin with 3 parameters to set the 2 values on device 1 to be different than what I set for device 0, but those values do not take.

I believe that the fix is:

if (_DeviceCount == 0) // Enumerate all devices on first call
{
...
} else {
readInafromEEPROM(deviceNumber); // Load EEPROM to ina structure
inaEE.maxBusAmps = maxBusAmps > 1022 ? 1022 : maxBusAmps; // Clamp to maximum of 1022A
inaEE.microOhmR = microOhmR;
ina = inaEE;
initDevice(deviceNumber);
} // of if-then-else first call

This change seems to work for me. I did not spend the time to be confident that I understand the code.

However, this seems like a poor design. Why not have begin() take no arguments and return the number of devices and have a separate setXXX to set the 2 values for each device?

I2C connection in not working on Wemos D1 (Esp8266) + INA226

HI Arnd!
I have INA226 and Wemos D1 mini. They are propperly connected and working with example code

but when i try to use your example DisplayReadings i can make them connect.
I have looked though code of INA.cpp in place:

if (_DeviceCount==0)                                                        // Enumerate devices in first call  //
  {                                                                           //                                  //
    #ifndef ESP8266                                                           // I2C begin() on Esplora problems  //
      Wire.begin();                                                           // Start I2C communications         //
    #endif                                                                    //                                  //
    #ifdef __STM32F1__                                                        // Emulated EEPROM for STM32F1      //
      uint8_t maxDevices = EEPROM.maxcount() / sizeof(inaEE);                 // Compute number devices possible  //
    #else                                                                     // EEPROM Library V2.0 for Arduino  //
      uint8_t maxDevices = EEPROM.length() / sizeof(inaEE);                   // Compute number devices possible  //
    #endif                                                                    //                                  //
    #ifdef ESP32                                                              //                                  //
      EEPROM.begin(512);                                                      // If ESP32 then allocate 512 Bytes //
      maxDevices = 512 / sizeof(inaEE);                                       // and compute number of devices    //
    #endif                                                                    //                                  //
    for(uint8_t deviceAddress = 0x40;deviceAddress<0x80;deviceAddress++)      // Loop for each possible address   //
    {                                                                         //                                  //
      Wire.beginTransmission(deviceAddress);       ```



seems it does everything correct but still no connection ... 
Could you advice something, please. 
I2C scanner shows address of INA226 - 0x40

EEPROM.h doesn't get loaded on STM32F1xx devices

Hello,

EEPROM.h doesn't get loaded on STM32F1xx devices and errors out. (PlatformIO/maple buildcore)

Suggested change:
11 #if defined(AVR) || defined(ESP32) || defined(ESP8266) || defined(STM32F1)

Greetings,
Emile

I2C_FAST_MODE conflict with STM32F1 core

I'm building a multi-channel voltage/current logger based on the INA library. I'm currently testing the code on a 3.3V pro-mini board (ATmega328p at 8 MHz) and soon will start testing on a bluepill board (stm32f103c8 at 72 MHz).

While building the tests for my project, I found the following problem. The STM32F1 core defines I2C_FAST_MODE as a bit mask. This triggers an the following error message when I target the bluepill board:

In file included from ~/.platformio/packages/framework-arduinoststm32/STM32F1/libraries/Wire/utility/WireBase.h:45:0,
from ~/.platformio/packages/framework-arduinoststm32/STM32F1/libraries/Wire/Wire.h:42,
from test/test_main.cpp:2:
~/.platformio/packages/framework-arduinoststm32/STM32F1/system/libmaple/include/libmaple/i2c.h:197:33: error: expected unqualified-id before numeric constant
#define I2C_FAST_MODE           0x1           // 400 khz
^
lib/INA/src/INA.h:104:20: note: in expansion of macro 'I2C_FAST_MODE'
const uint32_t I2C_FAST_MODE                =  400000;                    // Fast mode                        //
^~~~~~~~~~~~~

IMO the simplest solution would be to rename the I2C_MODES. However, I'm aware that STM32F1 support is been tested on a separate branch, and that it might not make it into the main branch... Just met me know if you are interested on a PR for this issue.

In the meantime, I'll solve the issue on my project (by defining suitable I2C_MODES for the STM32F1)
and continue with my testing.

Board description details

This document from TI I just found has all the differences listed in table 2 on page 2, I thought you might want to add it as not all are identical as your current table shows. like the INA219 has no separate voltage pins vs the INA219 which does. Maybe you can just copy/paste their table?
http://www.ti.com/lit/an/sboa203/sboa203.pdf

Thanks on the detailed library! I may use it on the Arduino Zero / Itsybitsy M4 which are both Atmel SAMD (Atmel + ARM :)

getBusMicroAmps giving 2x actual current on a INA226

It appears that the function getBusMicroAmps is giving a current value which is 2x higher than the actual current measured with a multimeter. I'm using a cheap INA226 breakout board from China which has a built-in resistor of 10 mOhm.
I have also tested it with the DisplayReadings example with the 10A, 10 mOhm settings and the problem still occurs.

Did I overlook something or is it a bug?

Thanks for the great Library btw!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.