In order to detect packets, you first have to detect energy. The energy detect only happens once, so even if there is lots of energy to be detected the 100 ms timer will only get triggered one time unless packets are detected afterward. If packets are detected, those packets must be destined for your local node in order to keep the radio turned on. The detection of energy can take between 0.1-10 ms depending on the LPL implementation, while I have the detection of packets set to 100 ms. 100 ms is probably a little overkill for some applications, but works rather reliably.
Right now the CC2420 stack is not utilizing the byte detection. The idea there was first you would detect energy by performing the smallest radio on-time check possible (I've gotten the actual check down to 0.9 microseconds using a continuous modulation technique which is not available right now in the baseline). If energy is detected, you could remain on long enough to see if you're receiving bytes (i.e. the SFD line is high). If you're not receiving bytes then you could potentially go back to sleep - but that idea didn't prove to work well in a crowded network with multiple transmitters nearby. Another example there is if you start receiving a packet that is not destined for you, then the CC2420 will stop receiving bytes (the SFD line goes low) and you could shut off the radio. Again, that doesn't take into account the case where there are two transmitters nearby and only one of those transmitters is sending a packet to you while the other is sending packets to someone else. The packets are co-mingled on the channel in such a way that it's best to leave the radio on to receive a few packets to determine if there's something interesting on the channel. The highest level of detection is a packet detection which is what we're using now, where you actually receive a packet destined for your local node. At that point, you could leave the radio on for however long you want to potentially communicate at 100% throughput with whomever you're talking to. Yes, it's possible to set up different on-time delays based on the different types of detection levels, and I have yet to implement anything like that. But there's nothing stopping you from experimenting with it! Let me know if you have more questions, -David -----Original Message----- From: Murray, Ben [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 10:34 AM To: 'Mischa Weise'; David Moss Cc: [email protected] Subject: RE: [Tinyos-help] low power listening -- anomalous/random 100-200 ms delay/skew? 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: [email protected] > 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; '[email protected]'; '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: '[email protected]'; '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 > >> [email protected] > >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/t > > inyos-help > > > > > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/t inyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
