¿how can i automatically recovery a Wisblock Box from a low battery scenario?

WisBlock
1

Hello friends,

Im working in a field deploy with more than 250 wisblock boxes at a first stage (RAK4630+Arduino Framework + sensors) and we are testing how it works after the battery it’s completely drained.

In our tests, we confirm that the Wisblock boxes don’t wake up and start to work automatically when the battery was completely drained and then was charged by the sun using the included solar panel. I measured 3.7 volts in the battery but the Wisblock box don’t start to work until i press the reset button.

¿how can i solve that? the field sensors will be in a dangerous and tall place (DC High Voltage lines) so i can’t to go and press the restart button if the battery it’s drained.

2

What type of battery are you using?
What Bootloader are you using?
Are you using Meshtastic firmware?

I run tests with Li-Ion batteries with deep-discharge protection and the RAK4631 always wakes up when the voltage goes above 3.7V.
This seems to work if using our latest bootloader.
But I heard from Meshtastic firmware users that they see the same problem. But as said, we could never reproduce the problem.

3

Run a test this morning. Using a small battery and an application that draws high current I emptied the battery.
Then I plugged in the USB and the device restarted as expected.
Arduino BSP, latest Bootloader on RAK4631

Here is the video

4

Thanks for the answer.

I’m using a 2500mAh Li-Ion Battery with protection circuit module (PCM). I first discharged the battery until the PCM cut the energy, then i installed in the Wisblock Box and then i installed in a place with open sky to charge the battery using the included solar panel.

The bootloader that was installed it’s the following:

UF2 Bootloader 0.4.2 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-293-gaf8e5a90) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: WisBlock RAK4631 Board
Board-ID: WisBlock-RAK4631-Board
Date: Dec  1 2021
SoftDevice: S140 6.1.1

I’m not using Meshtatic Firmware, i’m using Arduino Framework with an modified LoraWAN Low Power code runing above FreeRTOS (like your examples).

I read this https://github.com/RAKWireless/WisBlock/tree/master/bootloader/RAK4630 so i know that i havent the lastest firmware. I will install and repeat the test.

5

Started a second test, closer to your scenario.

RAK19007+ small Li-Ion battery (400mAh), maybe 30% charged.
RAK12037 CO2 sensor, all time on gives me a quite high current
Solar panel connected, but at the moment reversed, so no charging

It should drain the battery over night, so tomorrow I can get it out, expose the solar panel to the sun and see what happens.

For the bootloader, that is an older version.

Can you download the latest bootloader from our WisBlock repo
The easiest way is to download the UF2 file. Double push reset button while connected to a computer, drag the UF2 file to the new drive called RAK4631 and it will flash the latest bootloader.

I’ll keep you posted with the test results tomorrow.

1 Like
6

Start

image
image977×830 56.7 KB

7

What version of the WisBlock Base Boards are you using?
What other modules do you use? What Sensor modules, what IO modules?

First finding:
With RAK19007 Ver.B and the RAK12037 CO2 sensor (draws a lot of current when not shut down)

After battery was down to 1.7V over night, I put the device into the sun.
It did not complete boot up. The green LED went on, the blue LED stayed off, the device did not try to join the network. This indicates the firmware started, but because of low voltage on the battery and insufficient current it got stuck, LoRaWAN transceiver could not be initialized, CO2 sensor could not be initialized.

Possible reason:
The power control (WB_IO2) of the RAK19007 Ver.B is an imperfect solution. Some tests I did showed that 3V3_S (powering the CO2 sensor) was on, even WB_IO2 is floating.
This might be the reason for the device not be able to boot properly, because the CO2 sensor was powered on and drawing more current than available.

Next test, switched the Base Board to RAK19007 Ver.C:
This new version (produced and sold now) has an improved control of the 3V3_S supply and even if WB_IO2 is floating, it shuts down the 3V3_S supply.
With this Base Board I drained the battery again until the device switched off.
Then I put the solar panel under the sun.
The device booted up, First green LED, then blue LED, then it connected to LoRaWAN.
CO2 sensor was not initialized tho, most likely to low battery voltage (measured 2.8V directly at the battery) and still insufficient current.

But I did not see a complete hanging of the device that would require a reset to start it.
That’s why I ask which modules you are using, so I can adjust the test better.

As a first idea:

First thing in setup(), measure the battery voltage. If below 3.7V, do not try to initialize any modules or to connect through LoRa/LoRaWAN. Instead put the LoRa transceiver into sleep mode, then send the MCU into sleep as well for a longer time, before measuring the battery voltage again.

8

Update.

With the RAK19007 Ver.C and some code check the battery during setup(), the restart works without problem and the sensor is detected properly because my code waits for a higher battery voltage before it tries to power-up the sensor and join the LoRaWAN network.

The code is a little bit lengthy:
Battery check functions:

/** Millivolts per LSB 3.0V ADC range and 12-bit ADC resolution = 3000mV/4096 */
#define VBAT_MV_PER_LSB (0.73242188F)
/** Compensation factor for the VBAT divider */
#define VBAT_DIVIDER_COMP (1.73)

/** Real milli Volts per LSB including compensation */
#define REAL_VBAT_MV_PER_LSB (VBAT_DIVIDER_COMP * VBAT_MV_PER_LSB)

/** Analog input for battery level */
uint32_t vbat_pin = WB_A0;

/**
 * @brief Initialize the battery analog input
 *
 */
void init_batt(void)
{
	// Set the analog reference to 3.0V (default = 3.6V)
	analogReference(AR_INTERNAL_3_0);
	// Set the sampling time to 10us
	analogSampleTime(10);
}

/**
 * @brief Read the analog value from the battery analog pin
 * and convert it to milli volt
 *
 * @return float Battery level in milli volts 0 ... 4200
 */
float read_batt(void)
{
	float raw;

	// Get the raw 12-bit, 0..3000mV ADC value
	raw = analogRead(vbat_pin);

	// Convert the raw value to compensated mv, taking the resistor-
	// divider into account (providing the actual LIPO voltage)
	// ADC range is 0..3000mV and resolution is 12-bit (0..4095)
	return raw * REAL_VBAT_MV_PER_LSB;
}

And then at the very beginning of setup() I included this code to check the battery level:

void setup(void)
{
	// Make sure 3V3_S and the LED's are off
	pinMode(WB_IO2, OUTPUT);
	pinMode(LED_GREEN, OUTPUT);
	pinMode(LED_BLUE, OUTPUT);
	digitalWrite(WB_IO2, LOW);
	digitalWrite(LED_GREEN, LOW);
	digitalWrite(LED_BLUE, LOW);

	// Check battery level
	init_batt();
	float batt_level_f = read_batt();
	for (int idx = 0; idx < 10; idx++)
	{
		batt_level_f += read_batt();
	}
	batt_level_f = batt_level_f / 10.0;

	if (batt_level_f < 3700.0)
	{
		// Battery below 3.7V, try to initialize the LoRa transceiver
		lora_rak4630_init();
		// Set LoRa transceiver to sleep
		Radio.Sleep();
		// Sleep for 10 minutes
		delay(600000);
		// Reset device and try again
		sd_nvic_SystemReset();
	}

	// Battery voltage is good. Enable the sensors
	digitalWrite(WB_IO2, HIGH);

	// Rest of setup code
}

Little explanation for the code.

  • Read battery voltage 10 times to get an average
  • If battery voltage is too low:
    • Initialize LoRa transceiver
    • Force LoRa transceiver into sleep (by default after power up it is stand-by which uses higher current)
    • Wait (sleep) 10 minutes
    • Restart the RAK4631 and check battery again
  • If battery voltage seems to be ok (check for your system if 3.7V is good enough)
    • Continue with the setup()
9

Mr Beegee, sorry for the delay, we only works in business days and we haven’t professional instruments to make the battery discharge (electronic load or voltage configurable discharge battery equipment) so we discharge the battery using motors, buzzers and things like that, so it’s very slow.

My Wisblock Box includes RAK12500 GPS and RAK1904 Accelerometer that start to works in the setup function and for that make me a lot of sense that this it’s the reason that don’t start to work automatically in a “empty battery scenario”, because the GPS init requires a lot of energy to connect with the satellite.

I will try your code because i think that it’s the best way to solve that: don’t init the sensors until the battery it’s completely charged.

10

Bernd,

Thank you very much for taking the time to reproduce this issue that has been affecting many users. Is there any solution for RAK19007 Rev.B, as there are many already purchased, deployed, and delivered to resellers? I’m happy to know Rev.C fixed this issue but regrettably that does not resolve it for the many Rev.B boards already deployed.

Tony

1 Like
11

Sorry, no solution for Ver.B board beside of controlling WB_IO2 as soon as possible.

12

Ah well, they are still great boards!

13

Hello. I only see the rak19007 listed as “second generation”. How do I know if I have a rev c board?

14

Welcome to the forum @nagu

It is printed on the Base Board:

image
image640×689 93.1 KB

15

I wonder if I might offer a different conclusion to your test? I might be completely wrong so please let me know if that’s the case.

I’ve built many RAK solar radios that use Meshtastic (more than 50). I almost never use additional modules or power from 3V3_S but I can easily simulate this issue where the RAK requires physical intervention (reset) after a low battery. I’m not sure IO2 power control is the problem that you provided a solution for.

I think you did find a solution though: wait to enable the radio until the battery voltage is higher (until the battery has had time to store more energy). I think the primary issue is related to battery voltage sag and the nRF52 brownout condition.

What I’ve heard about the nRF52 is that the brownout condition is triggered by an unstable power supply to the chip. This can easily happen if the battery doesn’t have enough energy to handle the relatively large amount of current that is required from a radio transmission. It would cause a type of power loop:

  • Battery is drained so low the RAK/nRF52 shuts down
  • Battery starts to receive a charge, the voltage rises, and the nRF52 wakes up
  • The nRF52 enables the radio and tries to send a transmission
  • The radio tries to pull too much current from the battery and the battery voltage sags
  • When the battery voltage sags too low the nRF52 shuts down
  • With the nRF52 off, the battery rests for awhile and the voltage rises again until the nRF52 turns back on
  • The process repeats

At some point the nRF52 decides the power source is unstable and triggers a brownout or power lock that requires intervention (a physical reset).

Your solution, to wait for higher battery voltage before turning on the radio, solves the brownout issue because the battery now has enough stored energy to supply transmission current without the voltage being pulled too low.

1 Like
16

@KeithMon
I think you are correct with the high current peak when the transceiver start sending a packet, I can see up to 150mA with max TX power.
I did not measure, but I guess Meshtastic is having RX on all the time which would cause a permanent draw of ~6mA (RX consumption of the SX1262) on top of it.