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
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
