Author Topic: Coulomb counting in firmware and on display  (Read 1151 times)

hatte

  • NewMember
  • *
  • Posts: 2
Coulomb counting in firmware and on display
« on: October 25, 2019, 11:24:01 AM »
The subject of Coulomb counting has been briefly touched in this forum before, but I would like to inquire about whether it would require anyhing other than firmware changes to achieve the ability for the MCU to keep count of the number of (micro/milli) Coulombs that have passed through the shunt since, and make the value available on the display and on the BT link. And while at it, it would be handy to also have a Maximum_Current (positive and/or negative value).

The Coulomb counter (and maximum current) would be really useful to have to be able to predict battery life of a system with very irregular current consumption, e.g. an IoT device that sleeps for most of the time (10µA), runs for short periods, at regular intervals reading sensors (10mA), and rarely transmits data via WiFi, LoRa etc (100mA). With the auto-ranging feature enabled, the CurrentRanger could sum all ADC readings (current_in_amps * delta_time_in_seconds), and thus keep track of the Coulombs that has been consumed by the device under test, over long periods of time (hours), allowing you to estimate the expected battery life of a system.

I realize that the accuracy of the Coulomb count may be fairly poor, due to current spikes with durations shorter than the ADC reading interval (200mS), but for the purpose of estimating battery life, an accuracy of +/-10% would be plenty accurate.

Unless someone knows of a good reason why Coulomb counting cannot be implemented purely by firmware, I will make an attempt to make an implementation. It would clearly also require changes to the UI, being able to reset the counter, and possibly enabling/disabling the display of the Coulomb counter, and the maximum (positive/negative) current since last reset, alongside the instant current, on the tiny OLED display. But I am sure something can be worked out, using the existing touch pads (long-press, double-click, hold-A-and-click-B, ...). Suggestions are obviously welcome.

My alternative would be to add a separate Coulomb counter to the CurrentRanger (or µCurrent/tinyCurrent) device, but I believe it would be difficult to take advantage of the auto-ranging feature. Alternatively, it could possibly be achieved by reading the BT serial output and interpolating readings, but it would not be as neat, as an integrated feature.

I look forward to hearing ANY feedback on this!

/Morten

PS
For those, who asks "what is a Coulomb"... It is an SI unit equal to A * s (Current in Amperes * time in seconds), or exactly -1/(1.602176634×10−19) electrons (approximately -6.2415090744×1018), which means that a C float variable would actually be able to hold the (approximate) count of the number of electrons that have passed through the shunt of the CurrentRanger, although that would be a very silly thing to do.
« Last Edit: October 25, 2019, 11:48:16 AM by hatte »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6867
  • Country: us
    • LowPowerLab
Re: Coulomb counting in firmware and on display
« Reply #1 on: October 25, 2019, 11:34:03 AM »
Coulombs  ;D ... if you can name me 10 people that understand what a coulomb means, in terms of battery life, i will be very impressed  ;)

The way you can achieve this is by integration of the readings. The CR could do this fairly accurately, with the normal caveats of lost readings between range switching and things like that.
If you have a steady power supply then from the amp hours you can get watt hours and more useful numbers.

Also you can display whatever you want on the OLED. The default firmware is by no means extensive in features. That is why it's released to you so you can customize, experiment, learn and do fun stuff.

hatte

  • NewMember
  • *
  • Posts: 2
Re: Coulomb counting in firmware and on display
« Reply #2 on: October 25, 2019, 11:59:29 AM »
Coulombs  ;D ... if you can name me 10 people that understand what a coulomb means, in terms of battery life, i will be very impressed  ;)

The way you can achieve this is by integration of the readings. The CR could do this fairly accurately, with the normal caveats of lost readings between range switching and things like that.
If you have a steady power supply then from the amp hours you can get watt hours and more useful numbers.

Also you can display whatever you want on the OLED. The default firmware is by no means extensive in features. That is why it's released to you so you can customize, experiment, learn and do fun stuff.

Good to hear. It would obviously be very easy to count/convert to Ah (Ampere * hours) or mAh, which would clearly be a more suitable value, when discussing battery capacities. Although Wh (Watt * hours) or Joule would be a better value to count, as it would compensate for current being consumed at a different voltage to the battery, it is not possible, as the device does not know the voltage.

Do you have any suggestions/preferences when it comes to expanding the UI (three touch buttons), providing more "gestures"? I would prefer to implement something that could be back-ported with a pull-request. I will most likely fork the repository and create/work in a feature branch, making it easy to make merges.

Now all I need is to buy a CurrentRanger, and hope I don't brick it in the process of adding the Coulomb counting feature  ;)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6867
  • Country: us
    • LowPowerLab
Re: Coulomb counting in firmware and on display
« Reply #3 on: October 26, 2019, 08:56:14 PM »
Adding more UI interfacing means expanding the product, bigger PCB, bigger case, fewer in a panel, more overhead, and more cost which is really what people care for.
OR making it into a little menu where you navigate on the small OLED, which I've done for other testing purposes, and it works ok ... but would folks really appreciate a multi level menu on a tiny screen, with 3 buttons?
There is the exposed GPIO on the board which could be used for an external keypad, or perhaps a USB host that runs at 3.3V, but that won't be within USB spec.