WisBlock API or RUI3 for Lowest Power Consumption

Question -

I am building a simple battery powered temperature/humidity sensor Using RAK19003 + RAK4631 + RAK1901.

Is there guidance on which code path yields the lowest energy consumption (assume same transmit intervals/criteria, same sensor value checking intervals) when sending the values via LoRaWAN?

I have a power profiler kit, so can (and will) check the power consumption, but if it is known that one is better for power consumption than the other, I would rather just start there as I don’t have infinite time.

Thanks!!!

Well in quick testing I found that I can get very good power usage with WisBlock API…

During the 15s data transmit = 1.6 milliA average
Idle power = 22 microA

Transmit:

Idle:

22uA is a good result already.

To keep the RAK4631 in idle/sleep mode, I am using some FreeRTOS features (giving and taking semaphores) with my WisBlock-API.

Example codes can be found in my Github repos like the RAK4631-Kit-1-RAK1901-RAK1902-RAK1903

1 Like

That’s the exact example code I started with (deleted out the RAK1902 and RAK1903), then I added some value versus previous value checking, as on this device I only want it reporting values if the new value is greater than a threshhold.

I also noticed that I save a lot of power if I disable BLE as well, with the obvious side effect of no BLE programming/configuration…

The BLE should stop 60 sec after boot up and restarts advertising for 15 seconds on each wake-up.
You can change this in app.cpp.

(1) in void setup_app(void) you can change g_enable_ble = true; to false and the BLE will not be initialized.

(2) in void app_event_handler(void) you can remove the restart_advertising(15); and it will not restart BLE on wake-up.

(1) permanently shuts off BLE, so no firmware update over BLE possible.
(2) would give you the chance to do a firmware update after you reset the device.

On some of my devices I use a RAK1904 accelerometer to detect if you tap with your fingers on the enclosure and then I start BLE advertising. I did that in my RAK4631-RAK12014-Waterlevel application.

2 Likes

Good point. I may use path 2, then at least I could do 1 time config on the devices via BLE (or more than 1 time with a manual reset, of course).

@Botched1

For RUI3 consumption (RAK4631-R)
Tested RAK4631-R on RAK19007 with RAK1906 environment sensor and RUI3 custom firmware.
Bluetooth switch off automatically after ~30 seconds. During advertising (2 phase, fast and normal) the average current is 6mA/3.4mA. After BLE off and in sleep the device takes around 17uA. Tested with this code https://github.com/beegee-tokyo/RUI3-Sensor-Node-Air-Quality but only RAK1906 plugged in, no CO2 or VOC sensor.

That’s great information! I appreciate you taking the time to do that.

So probably a bit better than non-RUI, but as I’m already at 27 at idle now it might not be worth chasing.

When I get some more modules I’ll test this myself, though, as I’ve been wanting to understand the difference of using RUI3 anyway.

EDIT: Just ordered 3x more base/module/sensors, so hopefully in a few weeks I’ll be able to test the RUI3 version of my code with just base + 4631 + 1901. Maybe using this as the starting point (?):

Well… Maybe not.

The RUI3-Sensor-Node RAK1901_temp.cpp references a <rak1901.h> that I can’t find anywhere?

Any pointers @beegee ?

Hi @Botched1 ,

I think you can get that library from here . You have to add it as a zip.

1 Like

That was it, not sure how I missed that!

Thank you.

Well, I guess it was a mistake to use the general sensor project as a starting point. I never could find all the references/libraries.

Last one I couldn’t find when I gave up was:

#include <nRF_SSD1306Wire.h>
in
RAK1921_display.cpp

I just started ripping out the unneeded code/modules so I can get this tested.

Could be this library - https://github.com/beegee-tokyo/nRF52_OLED

1 Like

That took care of that one.

EDIT: Using v3.1.0 (instead of 3.2.1) of Sensirion Gas Index Algorithm library let it compile correctly.


(this is what happens if you use v3.2.1 of the Sensirion Gas Index Algorithm library ---- below)

When I compile I get an error on the gas libraries/functions though. I probably have a bad/incorrect library somewhere:

RAK12047_voc.cpp:18:59: error: use of deleted function 'VOCGasIndexAlgorithm::VOCGasIndexAlgorithm(VOCGasIndexAlgorithm&&)'
   18 | VOCGasIndexAlgorithm voc_algorithm = VOCGasIndexAlgorithm();
      |                                                           ^
In file included from C:\Users\Jason\Documents\Arduino\RUI3-Sensor-Node\RAK12047_voc.cpp:13:
C:\Users\Jason\Documents\Arduino\libraries\Sensirion_Gas_Index_Algorithm\src/VOCGasIndexAlgorithm.h:37:7: note: 'VOCGasIndexAlgorithm::VOCGasIndexAlgorithm(VOCGasIndexAlgorithm&&)' is implicitly deleted because the default definition would be ill-formed:
   37 | class VOCGasIndexAlgorithm : public SensirionGasIndexAlgorithm {
      |       ^~~~~~~~~~~~~~~~~~~~
C:\Users\Jason\Documents\Arduino\libraries\Sensirion_Gas_Index_Algorithm\src/VOCGasIndexAlgorithm.h:37:7: error: use of deleted function 'SensirionGasIndexAlgorithm::SensirionGasIndexAlgorithm(const SensirionGasIndexAlgorithm&)'
In file included from C:\Users\Jason\Documents\Arduino\libraries\Sensirion_Gas_Index_Algorithm\src/VOCGasIndexAlgorithm.h:35,
                 from C:\Users\Jason\Documents\Arduino\RUI3-Sensor-Node\RAK12047_voc.cpp:13:
C:\Users\Jason\Documents\Arduino\libraries\Sensirion_Gas_Index_Algorithm\src/SensirionGasIndexAlgorithm.h:42:5: note: declared here
   42 |     SensirionGasIndexAlgorithm(const SensirionGasIndexAlgorithm&) = delete;
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~

OK, I tried it using the Smart Farm example as the starting point, removing the RAK1902 code, and turning off BLE, and I see a very similar power.

RAK5005 + RAK4631 (flashed to -R) + RAK1901.

Idle (no sensor checks - just seeing min power with that hardware) = 14.97 uA

So for my application, using RUI3 lowers average idle power (with periodic sensor checks) from 27 uA to 21 uA. Doesn’t sound like a lot, but on a % basis it is about a 23% reduction in idle power. Not too bad!

Pure idle (no sensor checks):

Idle with sensor checks every 15s (application only sends values if sensor reading is > threshold):

1 Like