[riot-devel] Radio duty cycling

Jonas Remmert j.remmert at phytec.de
Wed Mar 18 10:15:33 CET 2015


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


More information about the devel mailing list