[Tinyos-devel] DutyCycle vs SleepInterval
Geoffrey Werner Challen
challen at eecs.harvard.edu
Fri Apr 3 12:56:27 PDT 2009
I also vote for sleep interval.
Duty cycle implies some notion of how long the radio is going to be on for
when it comes on, right? I never remember how long the check interval is so
I probably couldn't even compute the duty cycle without scratching my head
and poring through the code a bit. Sleep interval as the distance between
two channel checks seems much more intuitive. At least to me.
-gwa-
On Fri, Apr 3, 2009 at 1:25 AM, Omprakash Gnawali <gnawali at usc.edu> wrote:
> I vote for sleep interval.
>
> - om_p
>
> On Sun, Jan 11, 2009 at 7:20 AM, Miklos Maroti <mmaroti at math.u-szeged.hu>
> wrote:
> > Hi!
> >
> > I vote for sleep interval (less portable, but much more predictable)
> >
> > Miklos
> >
> > On Sat, Jan 10, 2009 at 2:56 AM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
> wrote:
> >> Hi!
> >>
> >> The current LowPowerListening [1] interface contains two sets of
> >> commands: one using intervals expressing sleep intervals and another one
> >> using percentages expressing duty-cycles. What I would like to bring
> into
> >> discussion is the duty-cycles.
> >>
> >> For reference here is the interface:
> >>
> >> interface LowPowerListening {
> >> command void setLocalSleepInterval(uint16_t sleepIntervalMs);
> >> command uint16_t getLocalSleepInterval();
> >> command void setRxSleepInterval(message_t *msg, uint16_t
> sleepIntervalMs);
> >> command uint16_t getRxSleepInterval(message_t *msg);
> >>
> >> command void setLocalDutyCycle(uint16_t dutyCycle);
> >> command uint16_t getLocalDutyCycle();
> >> command void setRxDutyCycle(message_t *msg, uint16_t
> dutyCycle);
> >> command uint16_t getRxDutyCycle(message_t *msg);
> >>
> >> command uint16_t dutyCycleToSleepInterval(uint16_t dutyCycle);
> >> command uint16_t sleepIntervalToDutyCycle(uint16_t
> sleepInterval);
> >> }
> >>
> >>
> >> So for intervals we have 64K possible values. The duty cycles are
> >> expressed in 1/100 increments so for them we have 10000 possible values.
> >> For CC2420 these 10000 values actually corresponds only to about 650
> >> unique sleep intervals.
> >>
> >> Another issue is the fact that the duty-cycle is not guarantee. The
> >> current LPL doesn't track the achieved duty-cycle and dynamically adjust
> >> the sleep intervals in order to meet a certain one. What happens is a
> >> fixed sleep interval is picked by translating the duty-cycle to a sleep
> >> interval using a fixed knowledge about how much the probing should take.
> >> So basically the semantics is that that duty-cycle will be achieved only
> >> if there is no traffic and no false wakeups. I find this definition
> >> cumbersome and not very attractive to work with.
> >>
> >> So my questions are: what do people think about this? Do you usually use
> >> intervals or duty-cycles in your LPL applications? How does sliming down
> >> the LowPowerInterface to only 4 calls sound? :-)
> >>
> >> [1]
> http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/tep105.html
> >>
> >> All the best!
> >> Razvan ME
> >> _______________________________________________
> >> Tinyos-devel mailing list
> >> Tinyos-devel at millennium.berkeley.edu
> >>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >>
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
--
geoffrey werner challen (né werner-allen) :: 617.694.7261 ::
www.eecs.harvard.edu/~werner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090403/89d9087f/attachment.htm
More information about the Tinyos-devel
mailing list