CAP Water Fountain Measuring Ultra Low Current

Almost missed this

I was idly staring at the board and noticed this LED lit up very faintly. It probably affected my last battery test which demonstrated the setup could stay alive in standby for a month. This may mean the setup could have lasted longer. Either way the ultimate test is to measure, somehow, the actual current the whole thing actually consumes.

Faint LED, means my controller code needs a bit of tweaking.

Multimeter

I realized after going through all the gymnastics below, my multimeter was equipped to measure uA. 

Counting Coulombs

Looking around for a u-Ammeter, or some way to make an ultra-low current measurement, I was ultimately directed towards a Coulomb counter. Amplifiers for measuring ultra-low current were somewhat unavailable, and while there are schematics freely available to build these circuits, I didn't want to. I needed something a bit more off-the-shelf. Coulomb counters have become prevalent with IoT, as devices need a way to measure how much charge is actually left in their batteries. Basically the coulomb counter is an integrating current measurement device. As current flows across a shunt resistor, it creates a very small voltage which is amplified, and integrated. As the integrated current adds up, the coulomb counter outputs a pulse for each unit of charge it detects. The average current the counter is measuring is directly related to the time between these pulses. 

LTC 4150

Sparkfun makes an LTC 4150 breakout board, and they have a really nice hookup guide for it. So I got one of those and wired it up. I should see a pulse every 10-30 minutes if the circuit isn't hiding any other leaks. The hookup guide gives two ways to use this board, polling or interrupt. If you poll, they recommend you wire it up so you clear the "INT" pin, with the "CLR" pin. Otherwise you have to catch a very narrow pulse, polling, and that's tough. Also, polling isn't hardcore enough, so I left the solder blob. I could have set up another uC to do this, but I have a perfectly functional scope and logic analyzer, so I opted to use it to bag the pulse.

O-Scope API

When I went shopping for a new o-scope I knew I wanted a USB device. The Analog Discovery 2 had good specifications, a solid GUI, and promised a functional API. The idea of being able to use python to run my scope and acquisitions sounded awesome! Plus it had a built in logic analyzer. Sold.

A bit of hunting and I found the scope API in python. Works great! After some tweaking with the scope GUI I opened my python toolkit, conda, pip, ipython and finally jupyter notebook. Using jupyter notebook was really convenient. I separated the code so cells for opening, closing and configuring the input could be run separately from the code for actually measuring the current. Also I can make a few notes to myself for how to actually operate the thing. I might never go back to using the scope GUI!

Conclusions

I can clearly see an average consumption of up to 78mA while the controller is awake. In standby the consumption drops to 2.3mA average. Wow! Not bad, but not as great as I expected. Something somewhere is leaking... Next I'll start isolating the leak by removing elements of the controller.

CAP Water Fountain Power Consumption Limbo

Update

Since the last post I have been working a lot to continue to bring my current consumption below 1mA. My last post set the target to 5mA in standby, but first, that technically falls short of my original goal and second it's optimistic. I am not sure the battery actually has that capacity. Getting below 1mA is really tricky and it took a fair amount of scouring the internet for a solution. I actually managed to find a couple of solutions, and I've been running tests on one of them while I finish the design of the second.

Upfront disclosure: I am not going to reveal what I found just yet, as I want to be able to sell the solution first when I eventually give away all the details.

Leaks

As I ran lifetime tests, monitoring the battery voltage, I realized I had a leaky ship. Just looking at the above image you can see some of the issues, hint, they are bright.

The battery

First thing was the battery itself. There were two power consumers in the battery which meant the battery alone wouldn't even stay on without a load for more than a week or so. There are LEDs to indicate the level, and circuitry to measure the voltage and light the LEDs, and an inefficient (by this project's needs) linear regulator supplying the USB 5V (the battery is 12V). Instead of buying a new battery pack, I ripped this one open, disabled the LED status circuits (ripped up traces), and the regulator circuits. I left the battery management board in-place as it seemed to have a large diode in the way of it affecting standby draw.

I replaced the battery built-in regulator with a low quiescent current regulator on my board to convert the 12V to 5 for the thing-dev. (MCP1702)

With all of the extra junk from the battery gone, I ran another test with just the battery and it looks like there's still something eating the juice, but it's negligible for now.

Thing Dev

I ripped up the LED traces from the board, as they consume a nice ~5mA.

Conclusions and next steps

I made some progress reducing current consumption in the design, and this has extended the standby to 20+ days. But this can be improved further. I also realized some time ago I need to directly measure the current consumption, so I've been looking into the best way to do that.

Also, my venture has highlighted a bit of a hole in the realm of wake-up-receivers for ESPs and other IoT things. I think I can put together a board that will plug into the Thing Dev and enable wireless wakeup from a Pi for a close and medium range application. I figure I can't be the first person to wish for such a board. So I've been working on a design and I plan to order the PCB and make a first-article in the next month or so. Hopefully the short and medium range approach both pan out...