Measuring current on a low power IOT device

[Maxlor]

I've built an IOT device using the Electric Imp. It gathers some environment data (temperature, humidity, pressure), and sends it off to the internet every couple of hours. It runs off a small 1000mAh lipo battery, and I hope to achieve a runtime of at least 6, but hopefully something closer to 12 months between charges.

Now I have some guesstimations of that runtime based on the current consumption values in the datasheets, but since those are a bit vague on occasion (particularly the imp's datasheet is rather sparse) I'd like to measure it. The difficulty is that during sleep, the consumption is about 60uA-ish, while taking measurements it's 1mA-ish, and while connected to the network I see values between 15mA and 120mA, with the imp's datasheet describing a worst case of 400mA for short intervals a couple of ms long. This large dynamic range makes things difficult.

What I want to know is the average current consumption of this device. Btw, the battery gives me between 3.7V 4.0V depending on charge state, and my Vdd is set to 2.8V. I have a switching regulator, so I can accept a burden voltage of up to 0.9V, although because it is a switching regulator, I have to subtract the power wasted in the meter from the overall measurement to get accurate results.

Given my somewhat limited equipment I've tried the following:

• using an Agilent U1241B in the 100mA range, which gives me 10uA resolution, and averaging. Problems: not really precise enough to measure the sleep current accurately, which skews the long term average, and measurements during wifi communication are clipped to 100mA.
• using an UT61E. Doesn't work, because the burden voltage is so high the board browns out as soon as the wifi module switches on.
• using the uCurrent in mA range. Works, but again doesn't give me the resolution to measure sleep currents accurately.
• using the uCurrent in uA range. Doesn't work, again because the burden voltage is too high when wifi is enabled.
• See how long it takes for the battery to be emptied. Would work well I suppose, but I'm hoping that there is another good method where it doesn't take me months to get a data point

What I can do is some clever calculations, e.g. measure the sleep current with the uCurrent's uA range, then measure overall consumption in mA mode and replace all sleep data points with the previously measured sleep current, something like that.

Measuring sleep current is a bid fiddly as well. Since when cold booting, the Electric Imp always switches on Wifi, the burden voltage of any device in uA range will cause a brown-out. I used a jumper, connected the meter to the jumper posts then pulled the jumper while the device was up and sleeping.

So I'd like to ask the experts, what's a good way to measure average current in such a situation? Is there a device where I can do a single connection and a single long-term measurement and it gives me accurate results? If so, does it fit into a hobby budget? I feel that with IOT becoming more popular, someone has to have figured out a good method for this...

[leppie]

I am in the same boat

I was thinking of perhaps trying a coulomb counter.

[doctormord]

A 24bit-ADC with an instrumentation-amplifier measuring a lowside-shunt will do. The point is to get the acquisition fast enough.

[Quiggers]

the key problem here is the dynamic range required to measure these differing operational states.
to have resolution at very small currents as well as the ability to record the systems maximum current draw.
the uCurrent seems like an ideal candidate until you hook it up to a 12bit ADC and realise the uA are in the noise
floor of the ADC and the mA are clipping, this is due to the uCurrent using linear gain to condition the signal
and the whole system being limited to 0-3v.

A log amp is a solution I've been looking into, but these seem to be current based devices, so I would need to use
a sense resistor to convert the DUT current drain into volts, then buffer it and convert it to a varying current,
gaining it through a log amp, to then pump it into an ADC, reverse the response of the log amp in code and store
time stamped values to a log file.



on looking at log amps I dropped this idea. but it is still a problem that needs a solution.
a rarity in electronics these days. Most of the time we end up with solutions requiring problems.

[bobcat]

Use a variable voltage power supply to compensate for burden voltage at your meter.
Operate the device in the various mode separatly to obtain measurements.
Compute the fraction of total time for each mode.
Add them up to get the power consumption.

[Rufus]

So I'd like to ask the experts, what's a good way to measure average current in such a situation?

A (very) big capacitor across the supply will average the current for you (remember to measure and consider leakage in the capacitor). Depending on the level, duration, and repetition rate of the increased current draw pulses the capacitor may need to be ridiculously large. For your once per hours high current events it might be possible to feed the capacitor with more of a current source than voltage and measure the droop on the capacitor at the end of the event.

[Maxlor]

Use a variable voltage power supply to compensate for burden voltage at your meter.

Oh, that's a good idea, hadn't thought of that. The regulator I'm using doesn't give me a lot of headroom there (Diodes Inc PAM2305, 5.5V input max), but I can go a bit higher than the lipo by itself. Of course, this adds a new problem: the PAM2305's efficiency depends on input voltage, at higher input voltages it's less efficient. This is only sketched in the datasheet, since they assume constant input voltage. So this would increase the error there.

Operate the device in the various mode separatly to obtain measurements.
Compute the fraction of total time for each mode.
Add them up to get the power consumption.

That's what I did so far, but it's difficult to clearly separate the stages. During measurement, a lot of different things happen, different sensors are woken up, and there's the communication between them, and all in about 0.2ms. I've tried doing measurements back to back but got wild value swings on the multimeter, couldn't really say what the average value would was.

I did the calculation based on datasheet values and guesses, it'd be nice to get a somewhat accurate average reading over a couple of hours or a day to make sure I'm not too far off in my estimation.

[bobcat]

The efficiency of the regulator will be the same. Just set the power supply to get the same input voltage to the same as the lipo.(remove the lipo)

Power averaging over a long time will not give accurate results. Averaging in each mode might be ok if the power is within say a decade min to max.

Using data sheets is the best way to calculate worst case power consumption. design for that and it will be a bonus when it last longer than expected.

[Marco]

Didn't TI have a kit for measuring power consumption based on the charge pulses from a switched power supply?

[jancumps]

Here's how Silicon Labs measures current on their Zero Gecko Starter kit:

https://eewiki.net/download/attachments/33882195/BRD2010A_B00_schematic.pdf?version=1&modificationDate=1401375823920&api=v2





R and S measure the voltage drop over a 4R7 resistor in series with positive power line.
There's an explanation of the mechanism @element14

[Mark_O]

The difficulty is that during sleep, the consumption is about 60uA-ish, while taking measurements it's 1mA-ish, and while connected to the network I see values between 15mA and 120mA, with the imp's datasheet describing a worst case of 400mA for short intervals a couple of ms long. This large dynamic range makes things difficult.

1)  Divide and Conquer:  It's only difficult if you expect one device to handle the entire range.  Parallel as many sensors as you need (at different sensitivities), to span the full range.

That's what I did so far, but it's difficult to clearly separate the stages. During measurement, a lot of different things happen, different sensors are woken up, and there's the communication between them, and all in about 0.2ms. I've tried doing measurements back to back but got wild value swings on the multimeter, couldn't really say what the average value would was.

2)  Monitor the Time-domain:  Using a multimeter, with just a digital numeric readout, would be an exercise in frustration.  For timing-related values, use a display meter with a graphic trace data log.  Or a scope, at a slow timebase.  Multichannel would be helpful.  A 4+ channel Yokogawa with instrumentation modules  (each set to a different sensitivity range) is handy for these types of purposes.

Using data sheets is the best way to calculate worst case power consumption.  Design for that and it will be a bonus when it last longer than expected.

3)  Trust your suppliers expertise:  That's actually a pretty good suggestion.  Most problematic would be the durations of each draw phase, while the levels would be spec'ed fairly reasonably.

I've built an IOT device using the Electric Imp. It gathers some environment data (temperature, humidity, pressure), and sends it off to the internet every couple of hours. It runs off a small 1000mAh lipo battery, and I hope to achieve a runtime of at least 6, but hopefully something closer to 12 months between charges.

4)  Measure with what you already have:  For the purposes of testing, steal one of the data channels (T, H, or P) and redirect the sensor to monitor voltage on the battery.  Run it for a few days or a week, and examine the voltage curve it produces.  If you know the voltage level at which the device can no longer function (because the load from a 400 mA burst knee-caps it), you should be able to get a more accurate real-world evaluation directly from the device itself. 

Summing partial products with estimated durations is adequate, but using the real device provides true integration/averaging of actual power draw.

[Mark_O]

4)  Measure with what you already have:  For the purposes of testing, steal one of the data channels (T, H, or P) and redirect the sensor to monitor voltage on the battery.  Run it for a few days or a week, and examine the voltage curve it produces.  If you know the voltage level at which the device can no longer function (because the load from a 400 mA burst knee-caps it), you should be able to get a more accurate real-world evaluation directly from the device itself. 

Summing partial products with estimated durations is adequate, but using the real device provides true integration/averaging of actual power draw.

And to anticipate the followup on this... if you suspect that the curve will drop off more rapidly at the end of the battery charge (which may well be the case), use your initial data curve to calculate the intercept, and project the shutoff time.  Find the voltage value from say a week before that, and pre-drain the lipo battery to that level.  Then run it and capture the tail of the curve, which will take less than the 7-days from the low-slope projection. 

Once you have the head and the tail, the rest of the curve fills itself in.

[Mark_O]

Lastly,

5)  Accelerate the process: if you don't want to relax for 2 weeks while the more comprehensive data is being gathered, you could speed things up by capturing data for a day at a time (must be long enough to see some measurable dropoff, which will depend on your voltage sensor resolution).  Then discharge the battery to simulate an estimated month or two of usage, and sample for another day.  Connect the piece-wise linear segments (with temporal shifts) to reconstruct the full curve.

One thing to keep in mind is that while your original question was how to measure current, that's not really what you wanted to know.  That was just a metric to help you calculate what you really did want, which was lifespan per charge.  Once you do know that, you can reverse calculate the average current draw... if you still care.

[doctormord]

A 24bit-ADC with an instrumentation-amplifier measuring a lowside-shunt will do. The point is to get the acquisition fast enough.

Gives you the dynamic you want. If you need more dynamic, use 2 different gain stages or a PGA.

But this wont be a weekend project.

[kwass]

I too have this measurement problem and really like the new the Keithley 2280S ( http://www.farnell.com/datasheets/1840495.pdf ) but it's very expensive.  The Maynuo M8831 ( http://www.maynuo.com/english/pro.asp?tid=70 ) might work too but the spec sheet doesn't  give enough details to determine this.

What I've been doing is using my (ebay deal) Fluke 8846.  While it has the needed resolution on the 400ma current range, it's needs 10 PLCs (power line cycles) to achieve that, so can miss a fast high current burst.

[electr_peter]

Do measurement in steps and calculate two main parameters - average current draw and time taken (in % od some large period). Sum all these up and get a true result for a full period.

Low current mode - use available methods to accurately measure low current. Use scope to estimate how long does it take.
Medium current mode - measure and get time estimates
...
---all possible power modes---
...
High current mode - measure and get time estimates.
Force a device to be in low/medium/high power mode if possible. USe scope to determine real timing in % of low/medium/high currents.

If time parameters are variable for some mode, record all the data and then calculate both average expected current and expected maximum.

This is not that hard if you do it in steps. Direct measurement would probably fail or be inaccurate due to massive scale differences.

[BradC]

I've built an IOT device using the Electric Imp. It gathers some environment data (temperature, humidity, pressure), and sends it off to the internet every couple of hours. It runs off a small 1000mAh lipo battery, and I hope to achieve a runtime of at least 6, but hopefully something closer to 12 months between charges.

I see a lot of discussion on the consumption of the device itself, but nobody seems to have mentioned the temperature and charge state dependent self-discharge of the lipo. Have you looked at that?

[zapta]

I am in the same boat

I was thinking of perhaps trying a coulomb counter.

I had good results with ltc2943.

[brycheiniog]

I have a project similar to the original poster, except it is using BLE. The peak current draw will be <20ma and the minimum will hopefully be a handful of uA so it will have similar issues with dynamic range. My plan at the moment is to use a Keysight 34411a DMM and log current at high speed to a PC where the numbers can be crunched at leisure..  Clearly the different states will need to be captured on different ranges..

We shall see how it goes!

Jonathan

[victor]

Could you run the device of a smaller battery and log depletion of the battery. Then characterize your cell and work out your calculations from there. I would not say accurate but it should give you a rought estimation of the runtime. And data should agree with estimations you have got so far.

[Maxlor]

I see a lot of discussion on the consumption of the device itself, but nobody seems to have mentioned the temperature and charge state dependent self-discharge of the lipo. Have you looked at that?

No, but it won't be an issue, the device is for indoor use only. This because the SD card version of the Electric Imp has a limited temperature range to begin with (0°C-55°C), and I'm using the same enclosure technique that Dave used for the uCurrent, i.e. PCB front panel on plastic box. Building an enclosure that can both expose the sensors and pushbuttons yet protect the electronics from the elements (or simply condensation) seems not at all trivial; I don't have the skills or tools to do it.

That said, LiPo batteries are actually fairly robust. According to battery university, they still have approximately 50% capacity at -20°C, and maybe 75% around the freezing point. Temperatures are about 0°C on average, and only very rarely dip below -10°C, so low temperatures shouldn't be a big problem if I were to use the device outside, battery wise. Moderately high temperatures of say 40°C don't seem to affect it too much either, and we have only a couple of days per year where it gets that hot, and then for a few hours each day.

Overall, I'd guesstimate a 20%-30% reduction in runtime between charges if it were used outside in this (moderate) climate.

Self-discharge of LiPo cells is about 2% per month when nearly full, and drops to 1% per month when about half full. 1% would be about 13uA with my 1000mAh cell. Probably only becomes an issue if you're aiming for more than 2 years, below that increasing the cell size seems good enough to counter that.

[Maxlor]

Could you run the device of a smaller battery and log depletion of the battery. Then characterize your cell and work out your calculations from there. I would not say accurate but it should give you a rought estimation of the runtime. And data should agree with estimations you have got so far.

I thought about that, using one of those 20mAh cells used for toy helicopters. The problem with that is maximum discharge current that the battery is capable of. There can be 400mA spikes that last 4.7ms. There are RC batteries that can do discharge currents that high, but the discharge curve then looks rather different, since the battery's internal resistance becomes quite noticeable at that point.

I wonder if supercaps might work in this scenario though. They also have high internal resistance (maybe use several in parallel), but their logarithmic discharge curve makes it easier to accurately measure an energy delta.

[trevwhite]

The Keithley 2110 DMM can make 2000 measurements consecutively from an external trigger and store these in its internal buffer at a very decent sample rate in the order of microseconds. This can enable you to build up a good picture of current usage for various aspects of the cycle. I recently used it to measure the high current pulses seen on GSM modems. These things draw 10s of mA and then have 1.5A current spikes on transmission bursts.

I have not timed the sample rates but you can programme this from several predefined values. I do not know how close to the programmed value it measures and if there are delays when storing each reading to memory but this can be calibrated by measuring a trace on a scope and syncing it with the data.

I have attached the spreadsheet of the data and graph for the gsm spike measurement. With this kind of data you can perform your calculations to find average current use. As said the only bit is to figure out the actual sample rate. The unit can sample to a PC at 200 samples per second. I think you can set it up to make sample times in the order of 5ms or something so it would probably log the average currents well enough I think?

Trev



 

[gmb42]

Could you run the device of a smaller battery and log depletion of the battery. Then characterize your cell and work out your calculations from there. I would not say accurate but it should give you a rought estimation of the runtime. And data should agree with estimations you have got so far.

I thought about that, using one of those 20mAh cells used for toy helicopters. The problem with that is maximum discharge current that the battery is capable of. There can be 400mA spikes that last 4.7ms. There are RC batteries that can do discharge currents that high, but the discharge curve then looks rather different, since the battery's internal resistance becomes quite noticeable at that point.

Really?

Although I've no experience with very short current pulses such as you describe, I have a lot with continuous high power use for RC planes and helicopters and don't think the behaviour will be too different.

Even with the exaggerated ratings by some vendors of RC batteries, a constant 20C discharge rating is easily obtainable, e.g. here.  For this 60mAH battery a 400mA discharge is ~6.5C and seems well within the  (nominal) 45C rating.

[fcb]

I had the same problem on a wearable device I designed recently.  I built my own solution (24 bit ADC, low burden shunt, in. amp), as I couldn't find anything affordable.