Inconsistent battery measurement

RE: Inconsistent battery measurement

Karl Ylvisaker — Mon, 07 Sep 2020 09:22:30 GMT

Hi,

[quote user="A.P"]The 5 multiple samples are there, as you say, to average out any outlier samples. I placed a 1 ms in between them to 'space out' the samples over a bit of time. There shouldn't be any peripherals drawing power before or during the sampling.[/quote][quote user="A.P"]Yes, we set up the SAADC channel as follows:[/quote][quote user="A.P"]The channel is set to NRF_SAADC_INPUT_VDD before init and #define HAL_SAADC_VBAT_CHANNEL 0.[/quote]

Great, thank you for clarifying.
The channel configuration seems all right to me, but you might not need the full 40 US ACQTIME. Not that it should matter in this case though, since you are not doing high-frequency sampling.

[quote user="A.P"]You're right. I copied this code from the example, and indeed we do not have a reverse current protection diode in place. Accordingly, we do not use this value in any of our calculations, it was placed there before we had decided whether to place a reverse current protection diode or not, and we had overlooked removing it from our code. Thank you for that point though, I will make a note of it in case we add a reverse battery protection diode to our PCB.[/quote][quote user="A.P"]We are using a custom board, not the DK. No reverse current protection is in place.[/quote]

Thank you for confirming this. So it sounds like it has not caused any inaccurate readings, which is good. The reverse current protection in place on the DK's is there mainly due to the multiple POWER options with different voltage ranges the DK's have available.

[quote user="A.P"]I'm afraid I still have not been able to catch this raising battery values while having a debugger attached to the board. I'll try to give you the data as soon as possible. Just so I'm sure we're on the same page, you need the ADC readings as well as the battery% calculated from every sample. Is there anything else you'd need?[/quote]

I will take a look at it whenever I get the data, no worries at all! Since I know which linearization scheme you have then I primarily need the SAADC readings and the interval in which they are taken ( i.e if there is 10 min between each sample ).

Best regards,
Karl

RE: Inconsistent battery measurement

A.P — Sun, 06 Sep 2020 08:19:26 GMT

Hi hmolesworth, Thank you for the input!

As Karl said, we do not need to be very accurate. A ball park estimate is more than enough for my use case.

In your experience, would I still need to measure the current under a predictable load to get a rough estimate of the battery %?

Could you point me to an example or a source I can read about how I should set this sequence up and how do I infer the approximate internal resistance of the coin cell from these two measurements?

[quote userid="65515" url="~/f/nordic-q-a/64757/inconsistent-battery-measurement/267293"]The difference between loaded and unloaded measurements allow inferring the approx internal resistance of the coin cell[/quote]

Thanks!

RE: Inconsistent battery measurement

A.P — Sun, 06 Sep 2020 08:04:52 GMT

Hi!

[quote userid="87869" url="~/f/nordic-q-a/64757/inconsistent-battery-measurement/267259"]Are you doing the 1 ms delay to avoid an outlier sample caused by high current draw from a peripheral, or is there some other reason for the 5 samples over 5 ms?[/quote]

The 5 multiple samples are there, as you say, to average out any outlier samples. I placed a 1 ms in between them to 'space out' the samples over a bit of time. There shouldn't be any peripherals drawing power before or during the sampling.

[quote userid="87869" url="~/f/nordic-q-a/64757/inconsistent-battery-measurement/267259"]I see you are referencing HAL_SAADC_VBAT_CHANNEL, is HAL_SAADC_VBAT_CHANNEL = NRF_SAADC_INPUT_VDD ?[/quote]

Yes, we set up the SAADC channel as follows:

nrf_saadc_channel_config_t channel_config;

    err_code = nrfx_saadc_init(&saadc_config, saadc_event_handler);
    APP_ERROR_CHECK(err_code);
    channel_config           = (nrf_saadc_channel_config_t)NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_VDD);
    channel_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_config.gain      = NRF_SAADC_GAIN1_6;
    channel_config.acq_time  = NRF_SAADC_ACQTIME_40US;

    err_code = nrfx_saadc_channel_init(HAL_SAADC_VBAT_CHANNEL, &channel_config);

The channel is set to NRF_SAADC_INPUT_VDD before init and #define HAL_SAADC_VBAT_CHANNEL 0.

[quote userid="87869" url="~/f/nordic-q-a/64757/inconsistent-battery-measurement/267259"]I also register that you have the DIODE_FWD_VOLT_DROP_MILLIVOLTS define in place. This define is to account for the voltage drop over the reverse current protection diodes on some of the Development Kits. In your case, the nRF52840 DK instead uses power switches ( and no diodes ) so this voltage drop can be discarded.[/quote]

You're right. I copied this code from the example, and indeed we do not have a reverse current protection diode in place. Accordingly, we do not use this value in any of our calculations, it was placed there before we had decided whether to place a reverse current protection diode or not, and we had overlooked removing it from our code. Thank you for that point though, I will make a note of it in case we add a reverse battery protection diode to our PCB.

[quote userid="87869" url="~/f/nordic-q-a/64757/inconsistent-battery-measurement/267259"]Could you confirm whether you are using an nRF52840 DK or a custom board, by the way?
In the case that you are using a custom board, could you confirm for me whether you have reverse current protection, and in that case which type of reverse current protection you are using?[/quote]

We are using a custom board, not the DK. No reverse current protection is in place.

I'm afraid I still have not been able to catch this raising battery values while having a debugger attached to the board. I'll try to give you the data as soon as possible. Just so I'm sure we're on the same page, you need the ADC readings as well as the battery% calculated from every sample. Is there anything else you'd need?

Thanks!

RE: Inconsistent battery measurement

Karl Ylvisaker — Wed, 02 Sep 2020 08:29:05 GMT

Thank you very much for your input here @hmolesworth, these are all important aspects that you mention!
The implementation you describe could definitely yield a more accurate measurement of the remaining battery charge. If I could upvote your comment twice then I would have done it!

I personally have yet to see a consistent trend of increasing VDD readings for a battery, such as the numbers shared by A.P initially. For most use-cases similar to this, reading the VDD and making sure there is no big power draw at that instant is usually enough to get a good ballpark of the remaining battery charge, in my experience. However, the approach you describe could absolutely be a good addition to projects if higher accuracy is needed.

In applications where battery monitoring is critical, I would also recommend looking into the addition of a low-power battery fuel gauge IC to the project, in order to get precise battery charge measurements.

Best regards,
Karl

RE: Inconsistent battery measurement

hmolesworth — Mon, 31 Aug 2020 15:44:41 GMT

I looked through the posts in this thread and don't see one of the fundamental steps for getting a useful voltage measurement on a coin cell to infer capacity. Out of interest a (say) 270mAH coin cell which has supplied (say) 220mAH - so most of the capacity - can recover to 2.95 volts or higher after a significant period where the coin cell does not supply significant current (say few uA). When this cell is used to power a circuit which measures the voltage an erroneous reserve power indication can result, despite monitoring temperature and using compensation curves. The reason is the changing internal cell resistance as the chemistry of the battery changes over time and discharge.

One solution is to identify a part of the circuit which presents a predictable load each time it is turned on, perhaps a simple resistor driven by a port but also perhaps a small motor or voice coil or even a fixed code execution sequence such as code CRCC. Applying a fixed sequence of these battery load pulses during battery measurement allows measurement both under a known load and under relatively little load (the latter by sleeping during the SAADC sample). The difference between loaded and unloaded measurements allow inferring the approx internal resistance of the coin cell, and thus better estimation of remaining battery life using the temperature and curve fitting already presented. Simply put, the loaded measurement returns a much lower battery voltage than the unloaded measurement. Pulse time is affected by total reservoir capacitance, which props up the coin cell battery voltage; the more the capacitance the longer the required load test pulse.

RE: Inconsistent battery measurement

Karl Ylvisaker — Mon, 31 Aug 2020 13:16:09 GMT

Hello again,

[quote user="A.P"]I've been unsuccessful in trying to capture the ADC readings on RTT viewer with a board displaying this increase in power. While I keep trying to catch one red handed, I can pass the attached table onto you and hope it helps.[/quote]

Thank you for providing me the table of results. I have not heard of this behavior previously, so it would definitely be interesting to see the rising battery measurements if you should encounter them again.

[quote user="A.P"]Wake up, initiate the SAADC, calibrate it and take 5 measurements with 1ms sleep in between them.[/quote]

Are you doing the 1 ms delay to avoid an outlier sample caused by high current draw from a peripheral, or is there some other reason for the 5 samples over 5 ms?

[quote user="A.P"]So, you might notice slight inconsistencies between the ADC value in the table and its matching battery %- that is because the SAADC value is the first read, which the battery% is the average of 5 readings.[/quote]

Thank you for the thorough explanation.

[quote user="A.P"]If you need anything else, I'd rather we switch the ticket to private before sharing more specific code.[/quote]

I can set the ticket to private at any time, if you wish to share more code.
As it stands right now, I do not see anything in your configuration that could cause rising measurements. I do however have two comments to the above:
I see you are referencing HAL_SAADC_VBAT_CHANNEL, is HAL_SAADC_VBAT_CHANNEL = NRF_SAADC_INPUT_VDD ?
I also register that you have the DIODE_FWD_VOLT_DROP_MILLIVOLTS define in place. This define is to account for the voltage drop over the reverse current protection diodes on some of the Development Kits. In your case, the nRF52840 DK instead uses power switches ( and no diodes ) so this voltage drop can be discarded.
This might actually have quite an impact on your battery measurements, in the case that you are accounting for the voltage drop without having reverse current protection diodes present - because it will shift the samples further out on the discharge curve.
Could you confirm whether you are using an nRF52840 DK or a custom board, by the way?
In the case that you are using a custom board, could you confirm for me whether you have reverse current protection, and in that case which type of reverse current protection you are using?

Best regards,
Karl

RE: Inconsistent battery measurement

A.P — Sun, 30 Aug 2020 12:59:14 GMT

Hi again!

I've been unsuccessful in trying to capture the ADC readings on RTT viewer with a board displaying this increase in power. While I keep trying to catch one red handed, I can pass the attached table onto you and hope it helps.

What this table shows is as follows:

1. Wake up, initiate the SAADC, calibrate it and take 5 measurements with 1ms sleep in between them.

2. On the first measurement, save the ADC read value.

3. Average the 5 measurements and report them as the battery %.

4. Do the rest of the relevant logic (advertise, connect report measurements, other stuff and go to sleep for 10 minutes).

repeat these steps.

So, you might notice slight inconsistencies between the ADC value in the table and its matching battery %- that is because the SAADC value is the first read, which the battery% is the average of 5 readings.

devzone.nordicsemi.com/.../Battery-increase-measurements-example.xlsx

The saadc setup / configuration is as follows:

#define ADC_REF_VOLTAGE_IN_MILLIVOLTS 600 //
#define DIODE_FWD_VOLT_DROP_MILLIVOLTS   270 //
#define ADC_RES_10BIT 1023 //
//#define ADC_RES_12BIT 4095 //
#define ADC_PRE_SCALING_COMPENSATION 6 //
#define ADC_RESULT_IN_MILLI_VOLTS(ADC_VALUE) ((((ADC_VALUE)*ADC_REF_VOLTAGE_IN_MILLIVOLTS) / ADC_RES_10BIT) * ADC_PRE_SCALING_COMPENSATION)

The SAADC init function is this:

nrfx_saadc_config_t saadc_config = NRFX_SAADC_DEFAULT_CONFIG;

    nrf_saadc_channel_config_t channel_config;

    err_code = nrfx_saadc_init(&saadc_config, saadc_event_handler);
    APP_ERROR_CHECK(err_code);
    channel_config           = (nrf_saadc_channel_config_t)NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_VDD);
    channel_config.reference = NRF_SAADC_REFERENCE_INTERNAL;
    channel_config.gain      = NRF_SAADC_GAIN1_6;
    channel_config.acq_time  = NRF_SAADC_ACQTIME_40US;

    err_code = nrfx_saadc_channel_init(HAL_SAADC_VBAT_CHANNEL, &channel_config);

If you need anything else, I'd rather we switch the ticket to private before sharing more specific code.

Thanks!

RE: Inconsistent battery measurement

Karl Ylvisaker — Thu, 27 Aug 2020 09:01:58 GMT

Hi,

[quote user="A.P"]Here is the linearization scheme as it is in our code, as well as the discharge curve for the batteries we use.[/quote]

Thank you for providing it. This linearization is the exact one we use in our cr2032 dependent battery service examples.
To my knowledge there has never been an issue before in which the readings have increased so steadily.
With your configuration I would expect ~8 ENOB, with the remaining being noise.
Could you perhaps increase the resolution to 12 bit, and see if you are seeing the same fluctuations?

Could you also share with me the saadc setup / configuration and usage code?
So I may see how the aquired samples are processed.

[quote user="A.P"]I've yet to capture an increasing battery % while recording the SAADC readout, so I'll try and get that to you as soon as I catch it.[/quote]

Great, I look forward to seeing the results, thanks!

Best regards,
Karl

RE: Inconsistent battery measurement

A.P — Wed, 26 Aug 2020 13:56:37 GMT

Hi Karl!

Here is the linearization scheme as it is in our code, as well as the discharge curve for the batteries we use. I've yet to capture an increasing battery % while recording the SAADC readout, so I'll try and get that to you as soon as I catch it.

Here is something to get things rolling

devzone.nordicsemi.com/.../Sener-CR2032.pdf

Linearization scheme:

static __INLINE uint8_t battery_level_in_percent(const uint16_t mvolts)
{
    uint8_t battery_level;

    if (mvolts >= 3000)
    {
        battery_level = 100;
    }
    else if (mvolts > 2900)
    {
        battery_level = 100 - ((3000 - mvolts) * 58) / 100;
    }
    else if (mvolts > 2740)
    {
        battery_level = 42 - ((2900 - mvolts) * 24) / 160;
    }
    else if (mvolts > 2440)
    {
        battery_level = 18 - ((2740 - mvolts) * 12) / 300;
    }
    else if (mvolts > 2100)
    {
        battery_level = 6 - ((2440 - mvolts) * 6) / 340;
    }
    else
    {
        battery_level = 0;
    }

    return battery_level;
}

RE: Inconsistent battery measurement

Karl Ylvisaker — Mon, 24 Aug 2020 14:59:39 GMT

Hello again,

[quote user="A.P"]Have I accidentally created a Perpetuum mobile device[/quote]

Now that would have been quite the marvel!
Sadly, I fear that this is related to the SAADC configuration and usage, more so than a sure-fire Nobel physics prize.
While the output may not be Nobel-grade, it is still some interesting percentages you are seeing, with a particular device seemingly increasing in power.

[quote user="A.P"]The only thing I can think of is that during the night the air conditioner is turned off, so some change in temperature is to be expected. However, I don't expect the temperature to change by much. Lets say about 10 degrees C.[/quote]

Temperature is the biggest cause of offset error, but you say you calibrate it before every measurement, so that should be fine.
Could you share with me the exact implementation of your battery discharge curve model?
Perhaps could you also provide the raw SAADC readouts, so that I may see that fluctuation in the measurements directly.

With your configuration I would expect some LSB fluctuation in your SAADC output - and if your linearized discharge curve is incorrect, it might be the source of these wild measurements ( i.e it is just coincidental that the measurements seems to be increasing ).

Looking forward to getting to the bottom of this!

Best regards,
Karl

RE: Inconsistent battery measurement

A.P — Mon, 24 Aug 2020 07:18:44 GMT

I've observed the same behavior in other devices. They may take longer, or rise by a different amount, but a steady increase in battery over the span of a few hours, maybe days does occur in a few of my devices.

Have I accidentally created a Perpetuum mobile device 🙂?

RE: Inconsistent battery measurement

A.P — Thu, 20 Aug 2020 12:01:03 GMT

Hi Karl!

I've added the two points we've discussed to my code-
1. I now calibrate the SAADC upon initialization, which means on every wake-up, before the ADC measurement is performed.
2. I've eliminated the possibility of measuring after advertising. I now measure only before advertising and before any peripherals draw current.

I ran ~10 devices throughout the night and read the battery values every 10 minutes or so. The result is that I see much more stable values from my ADC reads, which is good news. One device does seem peculiar in that it seems to report an increase in power. The measurements are very consistent, but they rise by from ~40% to ~70% in about 10 hours, then start dipping again.

Here are the results, they are measured every ~10 minutes, the SAADC is calibrated before each measurement.

Battery %
37
39
38
39
39
41
40
40
40
45
43
44
43
45
46
47
49
51
51
50
52
52
48
52
51
54
56
55
55
56
58
56
53
57
55
56
56
60
60
60
60
62
62
63
58
57
60
65
63
62
60
63
65
63
57
64
62
61
65
60
65
65
65
68
60
61
67
65
63
66
65
66
67
68
68
68
72
64
68
68
70
64
63
57
60
59

The only thing I can think of is that during the night the air conditioner is turned off, so some change in temperature is to be expected. However, I don't expect the temperature to change by much. Lets say about 10 degrees C.

Do you have any other ideas I could test?

RE: Inconsistent battery measurement

Karl Ylvisaker — Mon, 17 Aug 2020 12:41:35 GMT

[quote user="A.P"]I'm not performing calibration before sampling, I'll try adding it to my flow so it will occur upon initialization of the SAADC.[/quote]

Great! This is recommended practice.

[quote user="A.P"]What I meant by 'relevant peripherals' is that I do perform some operations before sampling the battery, but I don't think they are relevant as they should not draw any significant power. For example, I feed the watchdog, check some flags, configure some GPIOs to input/output etc.[/quote]

Well, any peripheral that draws current at the time of measurement could offset your samples.
For example as Turbo mentions, logging does exactly this. Another big source of error here could be if the radio was active at the time of sampling - this would most definitely offset your CR2032 measurements.

[quote user="A.P"]I'll add all of these to my code, test it and let you know if this fixes the problem.[/quote]

I look forward to hearing if this resolves your issues, please let me know!

[quote user="A.P"]In the meantime, I noticed there is an SAADC 'version 2' in SDK 17.0.0 (nrfx_saadc_v2). Could you explain what the difference is between version1 and version 2 please? Could version 2 help me get more accurate results? and are there any examples using SAADC version 2?[/quote]

There is indeed a SAADC version 2 in the SDK 17, yes. This is nrfx v2.2. The main difference here is that the newest driver is easier to understand, more intuitive both in naming and function.
Performance-wise it is the same, so it will not increase your accuracy.
If you are already familiar with the nrfx_saadc v1 then you might just very well continue using it, but then I would also think that you will appreciate the improved naming of the updated version.
Unfortunately there are no examples using the SAADC version 2 driver as of yet, sorry.

Best regards,
Karl

RE: Inconsistent battery measurement

Turbo J — Sun, 16 Aug 2020 09:37:27 GMT

Put an oscilloscope on the battery and watch the voltage fluctuating wildly.

Reason: CR2032 has significant internal resistance.

Note that logging via UART consumes about 1mA constant, and RTT may consume even more (the JLink debug connection disables sleep).

RE: Inconsistent battery measurement

A.P — Sun, 16 Aug 2020 08:36:47 GMT

Hi Karl!

I'm not performing calibration before sampling, I'll try adding it to my flow so it will occur upon initialization of the SAADC.

What I meant by 'relevant peripherals' is that I do perform some operations before sampling the battery, but I don't think they are relevant as they should not draw any significant power. For example, I feed the watchdog, check some flags, configure some GPIOs to input/output etc.

I had considered oversampling, but after sampling 5 consecutive times (with 1 ms in between each sample) and getting more or less the same result, I've concluded that the sampling is relatively consistent within a short period of time.

I have found a scenario where if a few conditions are met, I sample the battery (again) after having advertised for a minute or more. So I need to issue a fix for this and test if this helps solve the problem.

I'll add all of these to my code, test it and let you know if this fixes the problem.

In the meantime, I noticed there is an SAADC 'version 2' in SDK 17.0.0 (nrfx_saadc_v2). Could you explain what the difference is between version1 and version 2 please? Could version 2 help me get more accurate results? and are there any examples using SAADC version 2?

RE: Inconsistent battery measurement

Karl Ylvisaker — Thu, 13 Aug 2020 12:11:13 GMT

Hello,

That does sound strange.

[quote user=""]While I understand the curve may be inaccurate in terms of it matching reality for my specific battery, I should still expect it to give me consistent readouts- i.e, that the battery % values given should be ballpark accurate, should not increase sporadically, with minor fluctuations etc.[/quote]

Your understanding here is correct, the measurements should be fairly accurate - accurate enough for most use-cases. The fluctuations you are seeing is larger than expected.

[quote user=""]its only between different reads in different wake ups, where I see this large gap between measurements.[/quote]

Are you performing a calibration before you begin sampling? It is recommended to perform a calibration upon every initialization of the SAADC, and when there has been a significant change in temperature.

[quote user=""]No relevant peripherals draw current until after the SAADC read is completed.[/quote]

What do you mean by 'relevant' here?

The fluctuations you are seeing might indeed be the result of another peripheral / the SoftDevice drawing a lot of power right at the time of sampling.
You say that nothing else is happening on the device when the measurement is taking - how have you verified this?
Is the SoftDevice enabled?
How many samples are you basing the BAS update on? You might benefit from taking multiple samples over a small period, or enabling oversampling for this.

Looking forward to resolve this issue together!

Best regards,
Karl