Excessive Current Consumption in Blank Sketch

@cmod
You can share the current measurments here.

Hi @beegee first all, thanks for Wisblock API, I’m currently in progress to integrate it to my project. Looks promising.
My message is about power consumption. Similar to @cmod I got

My test code is very simple, no LoRa task, just BLE advertising, and then idle. Yet, during idle I got >500uA current consumption on average. So, far below your 40-ish uA.

#include <Arduino.h>
#include <Wire.h>

#define API_DEBUG   1
#include <WisBlock-API.h>

// Just logging library, nothing special
#include "AppLog.h"
#undef LOG_GROUP
#define LOG_GROUP "MAIN"

char g_ble_dev_name[10] = "ST-GNSS";

void setup_app() {
    Serial.begin(115200);

    time_t serial_timeout = millis();
    // On nRF52840 the USB serial is not available immediately
    while (!Serial)
    {
        if ((millis() - serial_timeout) < 5000)
        {
            delay(100);
            digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
        }
        else
        {
            break;
        }
    }
    digitalWrite(LED_BUILTIN, LOW);

    LOG_VERBOSE("App starts!");

    // Disable power for attached GNSS block
    pinMode(WB_IO2, OUTPUT);
    digitalWrite(WB_IO2, LOW);

    pinMode(WB_IO1, INPUT_PULLUP); // I don't know if this necessary

    // Enable BLE
    g_enable_ble = true;

    // Set firmware version
    api_set_version(SW_VERSION_1, SW_VERSION_2, SW_VERSION_3);
}

bool init_app() {

    Serial.end();
    return true;
}

void app_event_handler() {

    // Timer triggered event
    if ((g_task_event_type & STATUS) == STATUS) {

        // Reset
        g_task_event_type &= N_STATUS;

        LOG_VERBOSE("Timer wakeup");
    }
}

/**
   @brief Handle BLE UART data
*/
void ble_data_handler(void)
{
    if (g_enable_ble)
    {
        /**************************************************************/
        if ((g_task_event_type & BLE_DATA) == BLE_DATA)
        {
            // BLE UART data arrived
            // in this example we forward it to the AT command interpreter
            g_task_event_type &= N_BLE_DATA;

            while (g_ble_uart.available() > 0)
            {
                at_serial_input(uint8_t(g_ble_uart.read()));
                delay(5);
            }
            at_serial_input(uint8_t('\n'));
        }
    }
}

void lora_data_handler() {}

Hi @andri
The problem is the empty lora_data_handler(). It needs at least to clear the events, otherwise the loop will run forever. Try

void lora_data_handler(void)
{
	// LoRa data handling
	if ((g_task_event_type & LORA_DATA) == LORA_DATA)
	{
		g_task_event_type &= N_LORA_DATA;
	}

	// LoRa TX finished handling
	if ((g_task_event_type & LORA_TX_FIN) == LORA_TX_FIN)
	{
		g_task_event_type &= N_LORA_TX_FIN;
	}

	// LoRa Join finished handling
	if ((g_task_event_type & LORA_JOIN_FIN) == LORA_JOIN_FIN)
	{
		g_task_event_type &= N_LORA_JOIN_FIN;
	}
}

Make as well sure that LoRaWAN auto join is disabled, Otherwise the module tries to connect to a LoRaWAN server.

Hi @beegee thanks for responding. Sorry for just reporting back.
I did what you suggest. It’s indeed reducing current consumption, by a little. Now, it’s 405 uA.
Not sure why it’s not as your number. I’ve double checked, no LED is ON, and seems nothing to run.
I did connect accelerometer and BME680 sensor. Is it because of quotient current?

Any advice to check will be very appreciated. Thanks.

Just throwing in my experience, this is about the greatest extent in power savings I could achieve as well, wasn’t able to get it lower than this point. I didn’t try stopping and restarting the SPI bus however, this could be the trick to getting down to a more respectable 50uA.

There is a small trick with the RAK1904 accelerometer :grin:

Try to add


	// Set low power mode
	data_to_write = 0;
	acc_sensor.readRegister(&data_to_write, LIS3DH_CTRL_REG1);
	data_to_write |= 0x08;
	acc_sensor.writeRegister(LIS3DH_CTRL_REG1, data_to_write);
	delay(100);

	data_to_write = 0;
	acc_sensor.readRegister(&data_to_write, 0x1E);
	data_to_write |= 0x90;
	acc_sensor.writeRegister(0x1E, data_to_write);
	delay(100);

in the initialization of the RAK1904.

I used that in my WisBlock Kit 2 code. This gave me last uA savings.

1 Like

Thanks @cmod
Any sample code to do that? Thanks!

Hello,
sorry for digging up, I have RAK4631 + RAK5005, uploaded “Deepsleep LoraWan”, the sleep current with base is about 120uA, I tried to measure it without the base but without it the program doesn’t start, just take about 900uA.
For power I used 2.54 mm goldpins for programming - connected 3V3 and GND, (in my RAK4631 is already 10k resistance between RST and 3V3 - anyway additonal 10k resistor doesnt’t help). Here are screens with base and without:

So looks like in base it has something that needs, maybe need some additional pins?

Welcome to the forum @zolax
The RAK4631 needs more than the 3.3V supply on the SWD connector to work. The 3.3V pin on the SWD connector is just for JLink adapters to detect the correct voltage.
The RAK4631 is not designed to work without the base board, it requires the VBAT voltage which supplying some parts inside the module.

If you want to use the RAK4630 (WisDuo Stamp Module without the WisBlock Core PCB), please check the RAK4630 documentation which supply pins have to be connected.

1 Like

Hello @beegee , thank you, clear :). Have couple RAK4630 but RAK4631 will be easier for the test (all pins for VBAT and GND already connected).

Edit: Already tested, have 10uA - more than happy with this result :slight_smile:

Hi @beegee . Our application (on 4631/5005-O) sends a LoRa message every 2 minutes after processing an analogue signal for a few seconds. The rest of the time the device is idle (we put “Delay” to try to save power during the idle time). But should we send the “Radio.Sleep()” command before initiating the Delay, in order to save power on the SX1262? Or does the transceiver enter sleep mode automatically after the second RX window has closed, following the transmission?

Welcome to the forum @greigmj

The LoRaWAN stack puts the LoRa transceiver into sleep mode after the RX window if you have setup the device as Class A. However, in Class C the LoRa transceiver will stay in RX mode.

In general when using LoRaWAN, you should not use the Radio.xxx() functions at all, because you might interfere with the LoRaMAC stack which runs in it’s task in the background.