[riot-devel] Radio duty cycling
j.remmert at phytec.de
Wed Mar 18 10:15:33 CET 2015
>> 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 . 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.
More information about the devel