Radio duty cycling

Development archive
1

Hello RIOTers, What is the current state of radio duty cycling in RIOT? I know that radio drivers implement on and off functions for the chip, but how do we make the best use of them?

​In order to reduce power consumption it will be necessary to duty cycle the radio​ ​. ​

​For comparison, in ​Contiki there are multiple RDC drivers that can be switched​ between at compile time, the most well-known is ContikiMAC 1. Something similar would be very useful in battery powered scenarios for RIOT.

Best regards, Joakim Gebart Eistec AB www.eistec.se

2

Hello Joakim, currently there are no specific plans to utilize the power modes of the radios to my knowledge, except that mostly MAC/link layers will implement it. So if you have any idea: feel free to speak about it.

Cheers, Martine

3

Hi Joakim!

What is the current state of radio duty cycling in RIOT? I know that radio drivers implement on and off functions for the chip, but how do we make the best use of them? ​In order to reduce power consumption it will be necessary to duty cycle the radio​

I would agree with Martine: usually, duty cycling should be rather part of the MAC layer than of the driver. However, embedded transceiver devices usually are designed for one particular MAC layer and splitting this up in a sensible way is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio transceiver the driver (netdev) API should provide?

​For comparison, in ​Contiki there are multiple RDC drivers that can be switched​ between at compile time, the most well-known is ContikiMAC [1]. Something similar would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as part of the OpenWSN stack. As far as I know, at least two people are currently working on MAC layer implementations for RIOT. I will also take a look into this topic with the goal to use only the MAC layer part of the OpenWSN stack as a standalone module in RIOt.

Cheers, Oleg

4

Oleg,

I'm a contributor to OpenWSN, making a first post here based on your mention below.

5

+1

Emmanuel

6

Hi Joakim,

What is the current state of radio duty cycling in RIOT? I know that radio drivers implement on and off functions for the chip, but how do we make the best use of them? ​In order to reduce power consumption it will be necessary to duty cycle the radio​

I would agree with Martine: usually, duty cycling should be rather part of the MAC layer than of the driver. However, embedded transceiver devices usually are designed for one particular MAC layer and splitting this up in a sensible way is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio transceiver the driver (netdev) API should provide?

We are facing the same problem. Without radio duty-cycling, a battery powered operation seems not useful. Most transceivers consume a current of at least 10mA in receive mode (excluding MCU).

I implemented a CSMA/CA-MAC layer using the ng_netdev interface. It should fit for most transceivers. But up to a certain part, hardware support in the transceiver is neccessary.

I have done some HW tests on that topic:

1. Approach: There was a problem when I triggered CCA in software and in case of an idle channel the TX-state was triggered. The timespan between CCA-ready and TX-begin turned out to be too long. The result was interruptions in the middle of the transmit process, which leads to garbage on the channel.

2. Approach: Most transceivers support automatic CCA before TX, even most old ones. The approach to do it in Hardware works very well. I tested this with using the default values for backoff-intervalls, retry counts... defined in the IEEE 802.15.4 standard.

I will update the CSMA-MAC PR in the end of the week, maybe after Thomas opened the PR for the Atmel driver.

​For comparison, in ​Contiki there are multiple RDC drivers that can be switched​ between at compile time, the most well-known is ContikiMAC [1]. Something similar would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as part of the OpenWSN stack. As far as I know, at least two people are currently working on MAC layer implementations for RIOT. I will also take a look into this topic with the goal to use only the MAC layer part of the OpenWSN stack as a standalone module in RIOt.

If the CSMA-MAC layer and the ng_radio driver for the KW2x device is ready I will focus on implementing a beacon enabled MAC layer according to the IEEE 802.15.4 standard. I discussed that already with Johann, maybe we will face some problems there. The problem could be to find a timer that runs in sleep modes, consumes very low power and has a sufficently high resolution for the beacon enabled mode. Using a high resolution timer (32mHz or so, depending on the hardware) will not work, as it consumes to much power. Maybe a 32kHz clock in combination with an RTC or so could work.

Best Jonas