Howdy! This has come up a couple of times, it seems. Here's the relevant bug report (resolved as "this is the intended behavior").
http://code.google.com/p/tinyos-main/issues/detail?id=8 Basically, you should have something wired to the relevant SendNotifier interface. If you're using a cc2420-based platform (like the telos), this is exposed by CC2420ActiveMessageC. So, in your configuration wiring, you'd have something like components ActiveMessageC, CC2420ActiveMessageC; components MyApplicationC; components new AMSenderC(SOME_AM_ID); MyApplicationC.LowPowerListening -> ActiveMessageC; MyApplicationC.Send -> AMSenderC; MyApplicationC.SendNotifier -> CC2420ActiveMessageC.SendNotifier[SOME_AM_ID]; and in your module implementation, you'd have something like: event void SendNotifier.aboutToSend(am_addr_t dest, message_t* msg){ call LowPowerListening.setRemoteWakeupInterval(&msg, yourNonDefaultLplWakeupInterval); } Where potentially you use "dest" to figure out what the appropriate wakeup interval is (e.g. if destination is an always-on basestation, this could be 0, if it's a duty-cycled mote, it would probably be some default value). I completely agree with you, this is really non-intuitive. I think that the root issue is that there's no good way in the current implementation to differentiate a packet that has had its remoteWakeupInterval set prior to the send call (via LowPowerListening.setRemoteWakeupInterval) from one that has not, so the default value is assigned lower down on the stack to be sure that there's some kind of meaningful value in there. I think that if calling Packet.clear() reset the wakeup interval to the default (and this is the only place that the wakeup interval is not explicitly set), then this would be a better approach (assuming developers always called Packet.clear before setting up a new transmission). Alternately, putting the parameterized SendNotifier into the platform-agnostic ActiveMessageC and exposing the specific instance through LplAMSenderC would at least give the developer some better hints. That being said, there's a ton of code out there using LPL, so any solution would have to be pretty careful to not break compatibility too badly. If you want to take a crack at fixing this/making it easier to work with, maybe direct that discussion to tinyos-devel. Thanks, Doug On Wed, Feb 6, 2013 at 3:00 PM, <[email protected] > wrote: > Send Tinyos-help mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Tinyos-help digest..." > > > Today's Topics: > > 1. Lpl.setRemoteWakeupInterval (Wilson Tan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 6 Feb 2013 14:37:32 +0000 > From: Wilson Tan <[email protected]> > Subject: [Tinyos-help] Lpl.setRemoteWakeupInterval > To: [email protected] > Message-ID: > <CAK0HUqZg2538o6NNiC+aPBSB= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi guys, > > In TinyOS 2.1.1, isn't it erroneous to have the line > > call Lpl.setRemoteWakeupInterval(msg, call > SystemLowPowerListening.getDefaultRemoteWakeupInterval()); > > inside LplAMSenderP.nc's AMSend.send? It would end up overriding the call > to Lpl.setRemoteWakeupInterval from inside the main application code, > usually called before invoking AMSend.send. > > With that line in there the wakeup interval of the receiver would always be > taken from the value of the compilation flag > -DLPL_DEF_REMOTE_WAKEUP(because of the call to > SystemLowPowerListening.getDefaultRemoteWakeupInterval()). Or, if that is > not set, the node would assume that the value of the receiver's wakeup > interval is 0, as set in Lpl.h. > > I discovered that the only wall to make the line > > call Lpl.setRemoteWakeupInterval > > from inside the application code have any effect is to comment out its > "doppelganger" inside LplAMSenderP.nc's AMSend.send. > > Is this correct, or am I missing something? > > Thanks! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20130206/6344d3e1/attachment-0001.htm > > ------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > End of Tinyos-help Digest, Vol 118, Issue 15 > ******************************************** >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
