RIOT Power-Management-Strategy for Wireless-Sensor-Networking

Hello everyone, the sensors in a WSN-Environment need very often to save as much power as possible. Therefore you have normally a power-profile when which device is sleeping/power-down-mode etc.. Before I make some trials with implementing such a scenario I want to hear some opinions/thoughts about the correct way to handle this with RIOT. As far as I see a good starting point is the example "timer_periodic_wakeup". This example configures the MCU to be in a periodic sleep mode. Question 1: What is the correct way to integrate the external devices (sensors, radio modules) into this scenario. I think the user has to configure the device to get into sleep mode and to wake up inside the while(1) loop by himself - like this: while(1) {      make mesurement/send data      bring the device into power-down mode      xtimer_usleep_until......      wake up the device } Is this correct?

Question 2: How to handle the threads correctly in this scenario? For example you have a sensor and a radio modul. The sensor makes several measurements before the radio module sends data. If you make fork 2 threads - one for measurement and one for data-transmission - how could it be handled that the measurement thread should be invoked more often than the other thread.

Question 3: How to handle the threads in relationship with the "timer_periodic_wakeup" scenario.

Thank you for your hints! Best regards, Bernhard

1 Like

Hi Bernhard, There has been some previous discussion on this theme. I believe that if you want to use low power modes in a WSN you will need to implement a duty cycling MAC layer with synchronization, such as IEEE802.15.4e. Running the power duty cycling from a single thread like you propose will likely cause problems with synchronization between nodes and communication, as well as the difficulty you mentioned with multiple threads.

The current low power mode API in RIOT is designed around the idea that the idle thread will call the power save function whenever the CPU is idle. However, since peripherals may need the CPU to stay active there may be a need for some kind of wake-locks. I implemented a simple proof of concept for the Kinetis CPUs in but it needs some major refactoring based on some issues we discovered during testing (platform specific issues, UART misses some chars sometimes etc).

See these discussions for more thoughts on the subject of power management in WSN:

Best regards, Joakim