Low Energy LoRaWAN sensor based on XIAO nRF52480 + SX1262

[michapr]

I want to share the experience with the XIAO nRF52840 & Wio-SX1262 Kit

If you want to build a really low energy LoRaWAN device - this could be a good kit for you.
You have as sample free I2C pins available...

While ("light") sleeping the kit take about 4.5µA only (!!) and while sending data the needed energy is very low.
Comparing with ESP32 solutions it is much more effective - also because the sleeping mode.

I have used the "RadioLib LoRaWAN End Device Reference Example" and have added the needed code.
Important is to

• set the flash into deep sleep mode
• use the internal DC/DC converter for REG1 stage (for XIAO modules possible)
• set the tranceiver in sleep mode

Using power supply on BATT connector (3.7V) and testing with Nordic PPK2 (connecting to ChirpStack gateway) :

sleep current 4.42µA:

reporting values:

Calculating summary energy:

So you can see that for 10 measurements per hour you will need only about 0.69mAh per day - or 65mAh for 180days (!)

Using solar/LiPo would be optimal...

Settings for config.h:

#define PIN_LORA_NSS  (4)
#define PIN_LORA_DIO1 (1)
#define PIN_LORA_NRST (2)
#define PIN_LORA_BUSY (3)
#define PIN_LORA_RFSW (5)

SX1262 radio = new Module(PIN_LORA_NSS, PIN_LORA_DIO1, PIN_LORA_NRST, PIN_LORA_BUSY);

Attached the ZIP sketch as reference.
Seed_nrf_SX1262_reference_sleep.zip

Using this reference I could build a simple Temp/Hum sensor (I2C) with battery reporting with nearly the same power reporting values and a sleeping current about 10.5µA.

I hope this can help somebody looking for an easy solution ;)

[StevenCellist]

I just looked back at your ESP32 measurements which showed peaks of well over 100mA. What is the TxPower and SF of this uplink, do you know? Because it looks very low. Impressive though, and amazing results :) team effort!

[RHolmes137]

Note that there is a risk of burning out one the pins if you don't enable the battery voltage divider.

https://forum.seeedstudio.com/t/xiao-nrf52840-battery-voltage-reading-circuit-increases-sleep-current/273177

[michapr]

@RHolmes137 - thank you for the hint, you are right, even the risk should be minimal as described in your link.
But I have not changed the default settings in this sketch - I thought voltage divider should be enabled by default?
Looks like not....
Have added:

#define PIN_VBAT_ENABLE 14 // P0.14 - LOW to enable divider
...
  pinMode(PIN_VBAT_ENABLE, OUTPUT);
  digitalWrite(PIN_VBAT_ENABLE, LOW); // Enable voltage divider

Now the sleeping current is about 6,9µA - still a very good value ;)
Alternate input at 3.3V power pin - give the same 4,5µA - if somebody have another power source...

@StevenCellist SF7/125000, TxPower - I have not changed it in your sample application, so should be default? Will check it later and tell you.

[michapr]

@StevenCellist : using state = radio.begin(); the output power should be 10dB by default, right?

[RHolmes137]

The default value in the method declaration is 10:

int16_t begin(float freq = 434.0, float bw = 125.0, uint8_t sf = 9, uint8_t cr = 7, uint8_t syncWord = RADIOLIB_SX126X_SYNC_WORD_PRIVATE, int8_t power = 10, uint16_t preambleLength = 8, float tcxoVoltage = 1.6, bool useRegulatorLDO = false);

[StevenCellist]

Oh dear peeps, LoRaWAN ignores all of that and takes full control of the radio. So it is whatever the stack dictates. EU868 it starts off at +16 but then the network server takes over and it could be +6 for all I know and care. It's all done through ADR.

[michapr]

@StevenCellist How can I detect the current used TxPower?

[StevenCellist]

Using the LoRaWANEvent_t information - see the reference example :)

[michapr]

@StevenCellist - sorry for delay, was busy...
I have tested the TxPower - you are right, of course ;)
In normal case my device send with 2 dBm only - that's why this low current. RSSI: -95dBm, SNR 9.25db
At beginning it start with 16dBm, then 10dBm, then 4dBm and final 2dBm

For 16dBm I get 6.96mC (1.41sec) for confirmed uplink - but 74mA max current - so the used power is not so much more because the small time frame (looking over the summary time with sleeping time).

Was (is) interesting to check the used TxPower ;-)

[StevenCellist]

See, that explains! Still great results though, thank you for sharing. It's a bit of a dark art but cool to see it working so well :)