It may also be possible to specify different Timer settings for packets and
spurious energy rather than the current setup which signals the same event
and incurs the same 100 ms delay. Whether or not this would be a wise idea
I don't know though! :-)
PowerCycleP uses:
interface ReceiveIndicator as EnergyIndicator;
interface ReceiveIndicator as ByteIndicator;
interface ReceiveIndicator as PacketIndicator;
And signals:
signal PowerCycle.detected();
If either
call EnergyIndicator.isReceiving()
or
call PacketIndicator.isReceiving()
returns TRUE
Potentially the two different types of energy detections could signal
different length delays? I have had some vague success in signalling the
detection event inside my programme but will come back to that later once I
am sure what I'm doing is okay :-)
-Ben
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> Of Mischa
> Weise
> Sent: 27 September 2007 17:49
> To: David Moss
> Cc: tinyos-help@Millennium.Berkeley.EDU
> Subject: Re: [Tinyos-help] low power listening -- anomalous/random
> 100-200 ms delay/skew?
>
>
> Hi David,
>
> A follow-up question on this. If I assume that there are only
> broadcasts
> in my network I could lower this savely to 10ms without
> interfering with
> the receive event?
>
> cheers,
> Mischa
>
> David Moss wrote:
> > Ben -
> >
> > You're exactly right. When energy is detected - as long as
> the radio thinks
> > it's an 802.15.4 carrier signal, the DefaultLplP module
> gets a signal to
> > wake up and listen for a few moments. I have it set to 100
> ms 'listen
> > period' right now just for reliability reasons - i.e. maybe
> we have lots of
> > transmitters in the area and the message we're hearing
> right now is to
> > someone else, but there might be another message on the
> channel destined for
> > the local node in a moment.
> >
> > Because the one shot timer is restarted, the timer fires
> get shifted. This
> > may not work so well in the future if we want to implement
> a synchronous
> > layer on top of the asynchronous layer. Instead, we'd want
> the asynchronous
> > layer to use a periodic timer to keep the synchronous layer
> above happy.
> >
> > -David
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Murray, Ben [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, September 27, 2007 7:05 AM
> > To: Murray, Ben; 'tinyos-help@Millennium.Berkeley.EDU'; 'David Moss'
> > Subject: RE: [Tinyos-help] low power listening --
> anomalous/random 100-200
> > ms delay/skew?
> >
> > I think I may have found the answer to my own question :-)
> but I have a new
> > question now, but I will put that in a new e-mail
> >
> > ... when LPL is doing its CCACheck routine and the
> energyindicator signals
> > its .detected() event an "off" timer is started as a one shot with a
> > lifetime of 100 ms (set in defaultLPL.h with a definition of
> > DELAY_AFTER_RECEIVE 100. Assuming energy remained present
> in the Channel
> > during this time the "off" timer would be restarted.
> Energy is detected but
> > no packet was received this would simply cause a delay in
> the LPL routine.
> >
> > Regards
> > Ben
> >
> >
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] Behalf
> >> Of Murray,
> >> Ben
> >> Sent: 27 September 2007 11:18
> >> To: 'tinyos-help@Millennium.Berkeley.EDU'; 'David Moss'
> >> Subject: [Tinyos-help] low power listening --
> anomalous/random 100-200
> >> ms delay/skew?
> >>
> >>
> >> (TinyOS 2.0.2; Micaz; mib510; Cygwin)
> >>
> >> I have left a number of motes running in low power listening
> >> mode and have
> >> observed that occasionally one or more of the motes'
> LPL-receive-check
> >> experiences a sudden delay/shift of approximately 100 ms
> and shortly
> >> thereafter a second sudden delay/shift of approximately
> >> 100-120 ms. I am
> >> not running any transmitters although 2.4 GHz is quite a popular
> >> frequency... the first time I observed it two motes
> >> experienced the delay at
> >> the same time after three minutes of running, the second time
> >> I observed it
> >> a single Mote experienced the delay after approximately half
> >> an hour, and
> >> this morning one of the three motes I had left running had
> >> experienced this
> >> delay at some point overnight. One of the three motes
> >> experienced this
> >> delay in all three tests, one of the motes did not experience
> >> the delay at
> >> all, and the third Mote experienced the delay once in the
> >> first test but not
> >> again. When two motes experienced the delay, they
> >> experienced it at what
> >> appeared to be the same time and the delay was consistent
> >> between them.
> >>
> >> Is there a built-in function within low power listening that
> >> initiates a
> >> timeout/delay-of-start with regards to the sleep interval
> >> timer that lasts
> >> approximately 100 ms, perhaps to cope with noisy channels
> or received
> >> packets/suspected received packets? Signal detection as
> >> opposed to a random
> >> software/hardware error is because I have observed (using an
> >> oscilloscope)
> >> two motes undergoing the exact same delay at the exact
> same time. The
> >> receive event is not triggered and therefore I assume that
> >> this is some
> >> function to deal with a suspected packet when energy is detected.
> >>
> >> Would it be a trivial matter for me to find this function
> >> such that I could
> >> add an event trigger so that I know every time that LPL
> >> detects Channel
> >> energy but subsequently does not receive a packet (assuming
> >> this is what is
> >> causing the delay). Perhaps something like "FalseReceive" -
> >> this might
> >> allow me to correct the timing within my programme
> whenever this delay
> >> occurs.
> >>
> >> Also, if I could be directed to the exact function that would
> >> be very useful
> >> would as it might save me a lot of time trawling through
> code/editing
> >> something incorrectly ;-)
> >>
> >> Many thanks
> >> Ben
> >>
> >> **************************************************************
> >> *****************
> >> Please consider the environment before printing this email.
> >> **************************************************************
> >> *****************
> >> This email and any files transmitted with it are intended
> >> solely for the use of
> >> the individual or entity to whom they are addressed and may
> >> not be divulged to
> >> any third party without the express permission of the
> >> originator. Any views
> >> expressed in this message are those of the individual sender,
> >> except where the
> >> sender specifically states them to be the views of Thales
> >> Research & Technology
> >> (UK) Limited.
> >> **************************************************************
> >> *****************
> >>
> >> _______________________________________________
> >> Tinyos-help mailing list
> >> Tinyos-help@Millennium.Berkeley.EDU
> >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/t
> > inyos-help
> >
> >
> > _______________________________________________
> > Tinyos-help mailing list
> > Tinyos-help@Millennium.Berkeley.EDU
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/t
inyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
