Re: [riot-devel] Radio duty cycling
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
Re: [riot-devel] Radio duty cycling
On Tue, Mar 17, 2015 at 4:31 PM, Ken Bannister wrote: > Oleg, > > >>> 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. +1 Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Radio duty cycling
Oleg, 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. Ken ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Radio duty cycling
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
--
panic("do_trap: can't hit this");
linux-2.6.6/arch/i386/mm/extable.c
pgppiqJ16f3Gu.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Radio duty cycling
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 2015-03-17 10:05 GMT+01:00 Joakim Gebart : > 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. > > [1]: http://dunkels.com/adam/dunkels11contikimac.pdf > > Best regards, > Joakim Gebart > Eistec AB > www.eistec.se > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Radio duty cycling
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. [1]: http://dunkels.com/adam/dunkels11contikimac.pdf Best regards, Joakim Gebart Eistec AB www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
