[riot-devel] Radio duty cycling

Ken Bannister kb2ma at runbox.com
Tue Mar 17 16:31:59 CET 2015


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

On 03/17/2015 02:58 PM, Oleg Hahm wrote:
> 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.
I think your idea to cut its stack at the MAC layer is a good fit for 
both projects.
Use OpenWSN for its efficient and reliable 15.4e and 6TiSCH 
MAC/adaptation layers,
and RiOT for its higher level layers and libraries.


More information about the devel mailing list