Excessive Current Consumption in Blank Sketch

I agree, developing a base PCB to implement the peripherals I want while remaining low power is certainly a feat in and of itself, which is why Iā€™m really trying to nail down expectations now.

So far Iā€™ve been reporting values for the starter kit (core + base), powered off of the coreā€™s 3V3 and GND pins with the PPK2 at 3300mV. When I try to power just the core (detached from the base) using the same sketch without reuploading, I donā€™t see the LoRa functionality or any other peaks aside from the startup current peak. (see below). Am I doing something wrong? Please let me know if I should make another thread for this.

Not sure what exactly the problem with your WisBlock is.
Just two thoughts:

  • Did you try to power the module over the battery connector (like I showed here)? Because you are sourcing the system on the wrong side of the power regulators and I am not sure what leakage you can get with it.

  • Running the RAK4631 without the base board, just supplying with 3.3V should work, but to be honest, I never tried it. I will give it a try later today.

Disregard and do not setup the power supply of the RAK4631 as shown below. It is not safe to use it.

The RAK4631 is designed to work with a WisBlock Base Board only and needs VBat and 3.3V supply to work correct.

About running the RAK4631 without the base board. I just tested it and it works just fine.
Required connections:
3.3V, GND (obvious) and RST pulled to 3V3.
RST is not pulled up inside the RAK4631, so without pulling it up, the MCU doesnā€™t start.

I tested a new firmware for low power consumption that connects to LoRaWAN server. So it is not like LoRa P2P.

Getting ~7.6 uA when running the RAK4631 separate from the Base board. LoRaWAN join and packet sending works:


Woo Hoo!

This is definitely in the good enough zone to crack on - there may be some optimisations to do with disabling the serial and other peripherals on the MCU, but thatā€™s definitely in the zone.

To put it in context on doing low power on a board with ā€˜bitsā€™ on, the best I can squeeze out of an Arduino MKR WAN 1310 is 13uA after Iā€™ve detached all the voltage reg / battery charger etc circuitry.

If you need a voltage regulator to cap any over zealous batteries, I use the MCP1703 from Microchip - adds just 2uA to a sleeping device and is cheap & easy to implement.

Further context, the self-discharge of good Alkaline AA batteries is ~10uA.

Thatā€™s fantastic! Running my own experiment using the same plain-LoRa TX only send sketch as before but with RST pulled high this time led to a sleep current of ~16.5uA! Exciting stuff, truly. As nmcc said it seems the core will be sufficient for projects moving forward.

@beegee could you please let me know the low power sketch youā€™re using for LoRaWAN? Iā€™ll need to tackle that soon for the final application Iā€™m developing.

After that, Iā€™ll start tackling getting ultra low power using BLE as well. Any tips there would be appreciated, though I might make another thread for that.

Thank you so much for your help everyone, if I hit another wall Iā€™ll be sure to reach out again. Likewise @nmcc Iā€™ll let you know when I could start using battery estimations, thank you again for your offer there as well.

@cmod

I will share the code on my Github repo. But I have to write some documentation first because it includes a lot of different stuff.

  • Fully event driven, no delay() or endless running loop()
  • Separation of user app and LoRa/BLE event handling
  • AT command interface to setup LoRaWAN credentials
  • BLE interface to setup LoRaWAN credentials
  • Programmable periodic user function call every xxx milliseconds

And the code is made a PlatformIO project. I didnā€™t try it yet with Arduino IDE.

1 Like

@cmod
Documentation is far from complete, but I put the code I used during the power measurements in my Github repo

It is for sure not a simple and easy to understand code, but it tries to have LoRaWAN and BLE standardized (like an API) so that the user can concentrate on the main application.

@beegee Thank you! Seems like an excellent framework, looking forward to giving this a shot. If youā€™d like, I can return with some current measurements using that code here, or send them to you some other way if youā€™re interested.

@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.