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