Thank you David for your detailed explanation. I fully agree with you regarding safety and robustness for applications.
One more question, looking at the initial backoff (0x4) and congestion backoff (0x3) applied in the packetized wake-up transmission, I'm wondering there is any theory in choosing those backoff constants. What's the backoff strategy? intentionally to allow multiple wake-up transmissions mixed at the same time. What if we allows only one wake-up transmission at a time in medium by treating separately the first packet and the following resended packets in the packet train, i.e. the standard backoff is applied for the first packet and almost 0 backoff is used for the resended packets. Do you have any history or experience? Thanks, Jongkeun On Thu, May 29, 2008 at 8:54 AM, David Moss <[EMAIL PROTECTED]> wrote: > Hi Jongkeun, > > > > The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The > receive check is currently implemented through polling the CCA pin a number > of times in PowerCycleP. This polling method will be transformed into an > alarm/interrupt receive check for greater accuracy and efficiency, as soon > as someone has time to do it. The goal of the receive check is to be as > short as possible, and is the length of the time between packets in a > packetized wake up transmission strategy. I've had these receive check > perform reliably at 5 ms or less, but the current implementation makes the > receive check last ~11 ms for reliability across everyone's systems and > platforms. Only after activity is detected – either by transmitting a > packet or receiving a packet – does the radio remain on for the time defined > by DELAY_AFTER_RECEIVE, which is currently 100 ms. > > > > You'll notice the DELAY_AFTER_RECEIVE is #ifdef'd, so you can override it. > I agree, 50 ms – or even 20 ms – is a better value for leaving the radio on > after activity. The 100 ms value was chosen because highly congested > networks need further optimization with the packetized wake up transmission > in the default low power communication implementation. In fact, we need to > connect a bunch of nodes to a logic analyzer to 1) improve acknowledgment > success rate, 2) decrease packet collisions, and 3) optimize these timing > values before it will make sense to decrease that value for the entire > community. > > > > Right now the emphasis is on safety and robustness on everyone's > applications. Once the items above are solved, we should be able to safely > improve energy consumption while maintaining this level of robustness. > > > > -David > > > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Jongkeun > Na > *Sent:* Wednesday, May 28, 2008 4:02 PM > *To:* David Moss; tinyos-help@millennium.berkeley.edu > *Subject:* DELAY_AFTER_RECEIVE in CC2420 Low Power Listening > > > > Hi David, > > I have a question about a parameter used in CC2420 LPL module. > > * DELAY_AFTER_RECEIVE=100ms defined in DefaultLpl.h > This value is used to stretch the radio's ON time after receiving or > sending a packet, and also detecting some CCAs at check time. I think that > the cca detection related delay time should be seperated with the first two > cases (after sending/receiving). If CCA detection is a false positive > meaning that no packet is being transmitted to node, keeping radio ON during > 100ms is too wasteful when we use a short check interval such as 100ms. Even > though we use a shorter delay time such as 50ms, according to my experiment, > there is no problem because radio is supposed to receive a packet after > detecting CCAs, otherwise the radio should be OFF right after waiting an > expected time for packet reception. I do not feel 100ms should be sticked > for this case, a shorter delay would be fine if it is enough to guarrantee > the packet reception at valid CCA detection. Am I missing something? > > Thanks, > -- > Jongkeun > -- Jongkeun
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
