CR2032 battery voltage with BLE

[jmaja]

I have made a sensor prototype using cypress cyble-022001 BLE module. It's power from a CR2032 battery. While measuring it draws on average about 110 uA with about 2 uA sleep and then 27 uAs during each measument/BLE RX/TX cycle. The interval is 250 ms and it last about 4 ms wiht maximum current around 25 mA (measured without external to module capasitance, now I have 47 uF MLCC, which takes most of the peak).

I tested the sensor last night connected to my IPad recording data with my app (IPad was locked). I got a bit worried about the battery voltage curve (attached). It is measured by the CPU while it is active, thus it's about 0.1-0.2 V lower than what I get with a multimeter.

What could cause the drop and new level at around 5 hours? Is that typical to CR2032 (Varta) or is it more likely my sensor is doing something stupid. It should disconnect automatically, if for some reason IPad would shorten the BLE connection interval and thus increase the power consumption. I don't have the means to measure the power consumption, but I can use an oscilloscope to measure how much the voltage drops at BLE RX/TX.

One possibility is also that I damaged the battery while I soldered it. I couldn't find a CR2032 with correct solder tabs for the proto, thus I used just one without. It did still show 3.2 V after soldering. The battery recovers to 2.95 V (with multimeter) when the sensor stops measuring.

[jmaja]

I checked with the oscilloscope that the voltage is 2.80 between the events and drops down to 2.44 V at the peak. The app shows now 2.65 V and multimeter 2.82 V. Based on what the app does and the oscilloscope shows the sensor is not doing anything abnormal. The voltage peaks are shown at 250 ms intervals and the peak looks the same as it did when I measured to power consumption with a shunt resistor.

I also have a test point to show the power state of the CPU and it does stay in deep sleep mode outside the event.

Based on how adding capacitance changed the voltage curve I have estimated the internal resistance of the battery to be about 15 ohm (that was a few days a go with almost fresh battery). So 0.36 V drop would equal to 24 mA. The oscilloscope shows 2.70 V average for 10 ms window. Thus 0.1 V drop. That would equal to 6.6 mA average current and 66 uAs/event, which is more than double what it should be. Has the IR already gone up to more than 30 ohm?

I guess I have to go back to lab power + shunt resistor to really know is there something strange going on with the power consumption. But I would appreciate some info about what can happen with a CR2032. I have read a few articles: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwiAsKaZmIvhAhXw_CoKHXOrCk8QFjAAegQICRAC&url=https%3A%2F%2Fe2echina.ti.com%2Fcfs-file%2F__key%2Fcommunityserver-discussions-components-files%2F104%2F7510.swra349-Coin-cells-and-peak-current-draw.pdf&usg=AOvVaw1YV8JY83r1_Hx8-c7xCakn and
https://www.dmcinfo.com/Portals/0/Blog%20Files/High%20pulse%20drain%20impact%20on%20CR2032%20coin%20cell%20battery%20capacity.pdf

[Rerouter]

That sounds about correct for a CR2032, if your using one of these and want to really get everything you can out of a battery you need to build to deal with at least 50 ohms of ESR,

I've built low power sensors using them in the past, a key thing is, learn what your cutout voltage is, e.g. most transceivers tend to be about 1.8V, so you need to make sure that at no point in the transmission it can fall under that,

The other thing is the ESR gets a lot worst at temperatures under 5C, My approach was internally buffer until the temps rose, but that may not work for your application,

Pretty easy to set up in something like falstads circuit simulator, a voltage source, a resistor, your capacitor and a switched load, Its what I used to plan mine, but I was only running 12mA for 5ms, and ended up at 47uF, so I suspect your math might not be quite right,

The only other point I can make is look at the leakage spec of the capacitors, the best SMD 47uF capacitor I could buy still ended up being half of my sleep current.

[jmaja]

I had already done a LTSpice simulation when I first noticed that the voltage dropped much more with CR2032 than with my test setup with 3 V lab power + 10 ohm shunt resistor. That's why I went for the 47 uF cap, which is quite big (1210 and the thickest component).

I attached the simple LTSpice model (sorry about the messy layout). There are three resistors 100 ohm for BLE RX/TX, 1k for some CPU activity and 6k for sensor left measuring in between (just from 0.35 to 0.6 s). With this model I get no problems with 2.8 V battery voltage and 100 ohm ESR. The lowest peak goes to 2.4 V with this. With 15 ohm it goes to 2.55 V.

But I'm not quite sure how much capacitance should I actually use in LTSpice to model a 47 uF MLCC. In the simulator by Kemet this capacitor (C1210C476M4PACTU) should have minimal DC bias loss (-3% at 3 V). When I measure it (just a separate chip) I get 38 uF at 100 Hz and 35 uF at 1 kHz. Doesn't also small AC amplitude make real capacitance smaller?

Would a tantalum capacitor be a better choice? You can get higher capacitance and ESR of 1-2 ohm should still be OK. Was your leakage problem with MLCC? How much was it? During normal operation deep sleep is about 2 uA, but the device can also be put to stop when it consumes well below 1 uA. I haven't measured those after I put the 47 uF MLCC.

The BLE module can operate down to 1.9 V with radio on and 1.8 without radio. The sensor will be a problem before that, I have to test it.


 Do you think the voltage drop at 5 hours is normal? There was no change in temperature (indoors) and there should not have been any change in sensor current consumption.  The sensor is still on and the voltage doesn't seem to drop more. I was a few hours outside with it at 5 C and then the voltage dropped to 2.49 V (measured by CPU), but now it has been inside for an hour and it has risen back to 2.6 V.

The device will be used outside and should function down to 0 C. It must send BLE data all the time it is used.

[jmaja]

Interesting that I found quite different values for insulation resistance of C1210C476M4PACTU. I first found this from Farnell: http://www.farnell.com/datasheets/652158.pdf It says 21.28 Mohm that would be just 0.14 uA at 3 V. Then at Kemet home site: https://api.kemet.com/component-edge/download/specsheet/C1210C476M4PACTU.pdf it says only 2 Mohm, this 1.5 uA. Which is still almost OK, but much more than stop current and about the same as deep sleep. The latter is inline with 100 Mohm * uF specified for bigger MLCC: http://www.kemet.com/Lists/ProductCatalog/Attachments/19/KEM_C1006_X5R_SMD.pdf

Are the real leakage currents close to the specs or is that the worst case?

[Rerouter]

My leakage problem was with a MLCC, my sleep current was 300nA,

As for your problem, Spend 5 minutes tweaking battery voltage, ESR resistor and you capacitor value, easy enough to get it.

Falstad Simulator


As to measuring currents, I took to using a 0.1 ohm resistor and an amplifier, even with a 8 bits scopes more limited resolution, if you scale things correctly you can get a pretty good integration on the amount of power consumed during each stage of the transmission,

0C you may be OK, but check the datasheet if they provide the info, (you can request it from some manufacturers), a few types happily shoot over 110 ohms at 50% depletion,

Have not read too deep into your trancievers datasheet, but the best time to sample stuff is actually after the transmission, the transceiver should be what chews down the capacitor voltage, then the lower current micro can sample the next lot of data at its end, before going to sleep itself, and other fun stuff like that,

[jmaja]

The Falstad simulation had 25 mA on for 4 ms. That's much worse than my case. That equals to 100 uAs per event (400 uA average) and had only 27 uAs. 25 mA is only taken when the radio is on. Most of the 4 ms the current consumption is much less.

With simple capacitance calculation dV=dQ/C = 27uAs/47uF=0.57V. That's assuming all the current comes from the cap and battery is just used for charging the cap in between. As long as ESR is small enough to charge the cap back to battery voltage during 246 ms the voltage drop shouldn't be more than that.

The limit comes from lefting the sensor on once a minute between BLE events. It takes 500 uA and after that the cap will not be fully charged as shown in the LTSpice I attached.

Here is the datasheet for the battery. Varta should be a quality brand. https://www.google.com/url?sa=t&source=web&rct=j&url=http://products.varta-microbattery.com/applications/MB_DATA/DOCUMENTS/DATA_SHEETS/DS6032.pdf&ved=2ahUKEwjir9OG-IvhAhUstIsKHdMlC_sQFjAAegQIAxAB&usg=AOvVaw2_5NI6m0VmoUYhS-Js6L_2

[jmaja]

I found the problem! There was a stupid overflow error in the software causing the sensor to be left on all the time thus taking 500 uA extra current. It worked OK for about 5 hours leaving the sensor on only once in 64 seconds for 250 ms (2 uA average) and after that it was never shut down. This is used to measure a secondary data. Primary data is measured at 250 ms intervals.

How stupid of me, but I'm very happy it was an easy thing to solve not requiring hardware mods.

Why would it be better to measure at the end of the BLE event? I need to get rapid feedback thus I very much prefer measuring just before the BLE event. Actually I start the measurent when the BLESS starts the oscillator for BLE. After that the sensor measures while CPU goes back to deep sleep for a few hundred us. Then I read the fresh measurement and make a notification, which sends fresh data out at BLE event. Seems to give low power consumption. Not much more than Cypress example case just for plain BLE connection with all the low power tricks. The example draws about 70 uA at 250 ms interval without notifications. I get about 90 uA including sensor and communicating to it without notifications. The sensor takes about 12 uA of that so just 8 uA extra due to CPU being more awake and doing I2C communications + calculations.

[David Hess]

https://www.embedded.com/electronics-blogs/break-points/4434661/Coin-cell-voltage-droop

[jmaja]

After fixing the software and letting the battery rest for a while I get now 2.94 V with multimeter, 2.78 V with CPU and oscilloscope shows 310 mV drop at the BLE event. Let's see what happens during a longer period.

Comparing to LTSpice this should equal to about 25 ohm ESR with 47 uF, but if I only use the measured 38 uF ESR would be about 18 ohm. The average voltage drop during 10 ms is 80 mV measured with the oscilloscope. Since it should be 27 uAs the average current should be 2.7 mA, which gives 30 ohm ESR.

With 50 uF (+4.7 uF behind a 10R resistor) and 30 ohm LTSpice shows very close to what I measure. There are some caps on the BLE module, thus 50 uF might be accurate. Quickly looking at the datasheet shows maybe 4.5 uF in total in the module power lines connected directly to the battery.


Thanks David for the link. Lot to read.

This one deals with MLCC leakage: https://www.embedded.com/electronics-blogs/break-points/4430050/Using-a-capacitor-to-sustain-battery-life
Is it really that bad. Since I don't have one on board for easy measurement, I tried with a multimeter. It loads the capacitor first showing low resistance values, but after a few minutes it showed 40 Mohm and was still going up. Doesn't that mean the leakage current would be below 0.1 uA at 3 V? That was for a similar 47 uF MLCC I have on the proto. The resistance I measured was much higher than the 2 Mohm given by Kemet. But it is a lower limit, not a typical value.

[jmaja]

This paper shows that the actual leakage currents are quite small: https://nepp.nasa.gov/files/24732/2013_n239_Teverovsky_ESTEC_MLCCs_paper.pdf

Typical currents are order of magnitude smaller than specs. And even then it is mostly absorption current, which will level down to the actual constant leakage current. E.g a 22 uF 1206 6.3 V MLCC had only a few nA leakage after one hour at constant 6 V. Due to absorption the current was about 1 uA at 1 s and 0.1 uA at 10 s.

How did Rerouter measure the leakage, since it seems to be a function of time? One hour is a short while, if the device is left to sleep for days.

[David Hess]

Thanks David for the link. Lot to read.

I was too much to repeat here so I just gave the link which includes all of the links.

[jmaja]

Here is a new battery voltage graph. It includes the earlier one. The spikes to 2.4 V are not real, I just used them to mark where the sensor was not active and therefore started again with normal current consumption. At about 19 hours there is a spice up, which is caused by the programmer. After that the bugfixed software is used. Betweeen 10 and 12 hours the device was outdoors in 5 C and with the software not working as expected. This can actually be seen by the too frequent battery voltage variations. It should have measured only once per 64 s, but it measured at 4 Hz.

Now with the software working OK the voltage dropped only to 2.75 V in 12 hours. With multimeter it is now 2.93 V and oscilloscope shows 380 mV voltage drop and 10 ms average being 120 mV below the average. It seems ESR has increased again. 44 ohm? The peak fall time to 1/e delta is about 1.65 ms, which should be RC. From that R would be 33 ohm (using 50 uF). Anyway rather high value for a battery that should be almost full.

[Rerouter]

I measured my leakage by having the 2 active IC's lifted off the PCB and powering the board through a clone of a uCurrent, I only checked it for about 20 minutes at a few different temperatures, (-15 to 65C)

It may have been other factors, and may well have improved with age, but It was mostly idiot checking, To make sure that I put the other chips in there correct sleep / power down modes after recording the baseline.

Also how exactly are you calculating your math,

Using my little falstads calc, its looking pretty close to 15 ohms ESR to match the drop your seeing, though arguably seeing the scope screen shot would help,

[Psi]

There is quite a range of ESR between different brands of CR2032 cells

When new they can be from 20ohms to as high as 120 ohms.
And they get much worse when they start to get flat.
(Panasonic brand cells are quite good and around 20ohms new)

The high ESR makes your voltage readings very inaccurate especially if you measure it at the end of a high current period.

Add some smarts into the code so it only reads that battery at a known time when nothing else is running.

[jmaja]

Here is a picture from my scope. Yellow is the reversed battery voltage. White was stored when I had the 10 ohm shunt and no external capacitance, except for 2x100 nF at the sensor. Note that white has 500 us/div while yellow had 1 ms/div.

Have you done the Falstad with correct current profile?

[jmaja]

Here is another picture. Blue shows the test point now and white was the voltage over a shunt. Scales are the same. The test point is set low just before deepsleep is activated and high just after wake up. It is also set low when BLESS is called with a new notification.

The first rather short peak is when BLESS starts the chrystal oscillator and sensor is activated with short I2C. The second peak is when the oscillator is stable and the sensor is read. The zero in between is for the notification. CPU does not go the deep sleep there.

Length of the wakeups still match the earlier current profile, which was 27 uAs/event. Much higher capacitance just smooths the current taken.

[jmaja]

I don't really care much about the voltage reading accuracy. All I need is some kind of indication of battery level. It will never be accurate for CR2032, since voltage changes so little with remaining capacity and show much with temperature and current taken. I'm more keen to make the battery measurement with the least current used and as simple as possible.

ADC is now measured while sensor is read with I2C. Both events take about the same time. The current consumption is about 7 mA during that. It is the flat section in the white curve starting at about where the red dot for "Stop" is in the header. Probably it gives quite good indication of the remaining battery life.

[jmaja]

Here is still one more showing current profiles at the same scale and starting point. Timing is clearly indentical.

[jmaja]

User flash area write is going to be the last operation the device can do. Attached is a normal BLE event followed by flash write, which take about 150 uAs based on voltage drop comparison to normal event. Capasitance won't help anymore.

What are my options there? I need to store some variables like device name and calibrations. Totally about 50 bytes. The calibrations may need to be changed any time. Addiotionally I write flash at every boot. There will likely be just tens of boots during lifetime of the device, but most likely the battery will die at boot flash write.

[jmaja]

I looked at a bit bigger batteries CR2430 and CR2450. Despite bigger capacity they don't show much improvement on ESR.

I could maybe skip writing to flash by using the few bytes storage available in the sensor or with an external eeprom. But there is also a problem with connection. My android phone forces the connection interval to 7.5 ms during connection time. My device sends connection parameter update request whenever it notices the connection interval is not close to 250 ms. When connecting with my phone it starts with 50 ms then goes to 250 ms after 700 ms. After 2.5 s it goes to 7.5 ms and finally after 440 ms back to 250 ms.

I don't think I have any control over that behavior from my device or from my android app. This means the cap has not enough time to charge. Now I can see that the voltage is at max about 50 mV below the idle and amplitude is about 300 mV during that 440 ms period.

In LTSpice I get about the same with a bit over 40 ohm ESR. About 100 ohm would be the limit. Then the voltage drops 0.2 V at max level and 0.5 V at min level. With 250 ms interval I could survive 250 ohm after the once in 64 s measurement. Without that even 1 kohm would be OK. With flash write the 0.5 V limit is at 40 ohm.

If I allow 0.7 V drop 7.5 ms interval equals to 180 ohm and flash write to 60 ohm. That would be OK for 2.7 V idle voltage.

Maybe I'll try to get rid of flash write or at least limit it to very seldom changed variables, which are most like changed only when new.

[Psi]

I don't really care much about the voltage reading accuracy. All I need is some kind of indication of battery level. It will never be accurate for CR2032, since voltage changes so little with remaining capacity and show much with temperature and current taken. I'm more keen to make the battery measurement with the least current used and as simple as possible.

ADC is now measured while sensor is read with I2C. Both events take about the same time. The current consumption is about 7 mA during that. It is the flat section in the white curve starting at about where the red dot for "Stop" is in the header. Probably it gives quite good indication of the remaining battery life.

You can create a system in code to keep track of all events that occure (led flash etc) and code into it how much current/time they use.
Then sum this all up to keep a running count of mAh used by storing, say, micro amp seconds, for example.
Its really the only way to get decent battery capacity. The voltage will tell you if it is a brand new cell or if its flat. Trying to get more info out of the voltage than just  new/ok/dead is very tricky.

[Rerouter]

If you want to measure "Is my battery dying", easiest measure is to measure at the transmission point, you know your device will start misbehaving at 1.9V, thats the only parameter you need to know for the question "Do I have to replace the battery?",

[jmaja]

I'm already counting the current consuming events, but I don't really know how many mAh I will get out of the battery. Since this is still a prototype the counting and measuring voltage is more targeted to me than the end user.

The device needs to be rather small, very thin and water thight. I don't think the battery will be replacable. At least I haven't figured out how to make it replacable and still keep the thickness with the enclosure at 6 mm while keeping the construction simple and not too expensive to design and make. The enclosure needs to be transpararent to IR and visible light at many spots on both sides and of course also for BLE radio.

Measuring at the peak current is an interesting idea and should give some warning before the device stops working. I'm hoping even CR2032 would last long enough for most users.

[GeorgeOfTheJungle]

I like this thread...