Odd SAADC readings

RE: Odd SAADC readings

JPMorganJeremy — Sat, 16 Feb 2019 18:33:55 GMT

Thank you Einar, I wasn't aware that the initial drop was that steep. I will adjust the battery level in percent function to better represent the actual value.

RE: Odd SAADC readings

Einar Thorsrud — Fri, 15 Feb 2019 08:51:53 GMT

Hi,

The discharge curve for typical CR2032 batteries is such that there is a steep decline in battery voltage initially, then the voltage is quite stable, before it starts to fall of rapidly again. You can for instance refer to the graph here.

If your firmware is not power optimized, then it might draw a couple of mA on average, and that together with the typical discharge curve and a bad discharge curve model probably explain what you are seeing.

RE: Odd SAADC readings

JPMorganJeremy — Fri, 15 Feb 2019 02:00:34 GMT

So I checked the voltage on SB10 of the USB powered DK and got 3.3v, just to confirm i got the right reading.

Then I measured the voltage of SB11 on the peripheral that was powered by a cr2032. My multi-meter read 2.64V (the battery_level_in_percent() was returning 13%).

If we plug 2.64 into the "else if (mvolts > 2440)" :

battery_level = 18 - ((2740 - 2640) * 12) / 300 = 14.... so only one percent off.

Then i took the coin cell out of the peripheral and measured it's voltage at 2.70V. It had previously measured 3.1V only a couple hours before use.

So it seems that saadc is relatively accurate, but I just don't understand how a cr2032 could go from 3.1V to 2.7V in less than an hour. Then not drain any further (at the same rate), running the heart rate sampler example. This scenario can be duplicated with any new cr2032 I put into the DK.

Any ideas as to what could be going on?

RE: Odd SAADC readings

Einar Thorsrud — Thu, 14 Feb 2019 09:35:41 GMT

I see your point. It might be that the battery is depleted quickly for some reason, and probably the discharge curve used in battery_level_in_percent() does not match the battery. Can measure some points with a multimeter as well, and do the battery_level_in_percent() calculations to see if you get the same numbers?

The only other factor I can think of is that you have not calibrated the SAADC, but that should just give you a fixed offset.

RE: Odd SAADC readings

JPMorganJeremy — Wed, 13 Feb 2019 15:57:31 GMT

Thanks for the reply Einar.

That makes sense that the default value is used until an actual reading is given. What still doesn't make sense is that the first saadc reading starts around 90% and reaches about 16% in a matter of minutes (what appears to be a rapid drain), yet doesn't drain any further than that point. I don't see how this could ever actually occur.

Are the new battery's I'm buying actually that depleted, and it's taking saadc a few minutes to give the accurate representation of their battery percentage, or could something be off with the way I'm implementing the saadc reading?

Going from 90% to 16% in a matter of minutes, but not draining any further doesn't make sense.

RE: Odd SAADC readings

Einar Thorsrud — Wed, 13 Feb 2019 13:18:25 GMT

Hi,

The proximity example (which you have based the battery measurement code on) does not meassure the battery immediately, but rather waits until the first app timer timeout. Until then, the default value (initial_batt_level) of 100% is used. The subsequent percentage number is calculated from the SAADC measurements by battery_level_in_percent(), so this has to be updated to match your battery.