[RAK3172/3372] Battery level measurement issue

LPWAN Modules / EVBs RAK3172
1

Hi,

I received some RAK3372 for testing and I meet a problem with battery level measurement : api.system.bat.get() always gives 4.19V or 4.20V

I’m using a RAK3172 with RAK15007v2 board with this code : RUI3-Best-Practice/RUI3-WisBlock-Kit-4 at main · RAKWireless/RUI3-Best-Practice · GitHub

Version : RUI_4.1.1_RAK3172-E

It joins well, I get BME680 values (but can’t monitor vbat).

I check all topics in forum and found nothing to help me.

Regards

2

Hi @Batto ,

Do you have connected battery in your setup or still disconnected?

If still no battery and USB is connected, the reading that you get is from the open circuit voltage of the charger IC. This is normal.

However, if there is battery connected and unit is not being charged, what voltage do you see on the battery and what is the retured value of the api.system.bat.get()?

3

Hi @carlrowan,

Yes I have a lithium battery and I get 4.19 or 4.20 in any situation (USB connected or not, when not I get result by LoRaWAN, battery connected or not).

It’s just like VREF is not well configured.

4

Hi @Batto ,

The internal ADC of STM32WL is not optimized since we do not comply on its required input impedance. This is needed as a comprise to achieve low power operation.

  1. If you can share me the actual voltage of the battery during these testing.
  2. If you can use a drained battery and do the test (so we have a low voltage reading).

These two items will be helpful for us to assess your findings and investigate.

5

Here is my discharge curve :

image
image938×554 22.6 KB

Finally it seems to drop. I did some measures, for example at 4.05V “real” I got 4.20V.

I don’t know if it’s linked, but for RAK4631, I have to multiply api.system.bat.get() by 1.07 to get the real value.

6

Hi @Batto ,

I did some test on my RAK3172 evaluation board and also seen some discrepancy. We are supposed to fixed this before already but it appears discrepancy still exist (I also around 0.2V which is really significant).

At the moment, I don’t think it will be useful to detect that the battery if fully charge. Maybe possible to detect if it is low. But either situation, if you need better accuracy, I suggest to detect the battery using lower resistor values (might compromise low-current operation) and use another ADC channel.

We will look into further and update you.

8

I don’t need an accurate measurement, I just need to know the roughtly the state of charge ( more or less 5% is good enough).

But if there is a “celling” around 4.20V it’s a problem because it let me think that 100%->20% = 100% and <20% = it drops quickly

9

Hi @carlrowan,

I’d like to drag this topic back into the light.

I’m using the RAK4631-R RUI3 on a 19007 base, and see a similar scaling requirement of around 1.07 (thanks @Batto) when near a fully charged state. With a single reference point I don’t know what part is linear scaling and what part is offset.

Is RAK able to provide any guidance on getting accurate reliable voltage measurements out of the system call return value?

(I know the original post was about the 3172, but the 4631 is referenced and it’s really the same issue. I thought it better to keep the questions together rather than start a new thread.)

Edit:

I’ve been down this rabbit hole some more.

In the function service_battery_get_batt_level from file “service_battery.c”, in amongst all the “if defined”, “ifdef” and “ifndef” that have accumulated, are the following lines:

    for (int i = 0 ; i < get_batt_table_size() ; i++) {
        *bat_lvl = batt_table[i].batt_vol;
        if (adc_value < batt_table[i].adc_val) {
            break;
        }
    }

This steps through a 40 element table to find a not greater than match for the ADC value and exports a battery voltage rounded to 0.1V. The result of this linear search is then immediately overwritten unless you have a RAK3372+RAK5005-0_V1.0 defined. With a RAK11720 or RAK5010 it is overwritten again. I hope the compiler is smart enough to remove the dead code that the preprocessed source provides.

In the end, the relevant section is this:

#ifndef RAK3372+RAK5005-O_V1.0
    *bat_lvl = ref_over_gain*(((float)adc_value)/max)*(5.0f)/(3.0f);
#endif

The ADC value is a 10bit value, and max is correctly chosen 1024.0. (*)

The 5.0/3.0 factor (correctly) represents the 1meg0/1meg5 resistor divider.

udrv_adc_get_mode() has (incorrectly?) returned UDRV_ADC_MODE_DEFAULT (0)
so ref_over_gain was set to 3.6V rather than 3.3V. (3.6/3.3 = 1.09)

I suspect that was where @Batto’s 1.07 comes from.

(* The variant.h file for RAK4631 should trigger 14bit ADC. Why this doesn’t happen is a topic for another rabbit hole)