Yes, in fact, this is what I'm implementing on the CC1100 and CC2500 radio stacks. The trick is getting the transmit branch of the radio stack to hold off for awhile if a packet was recently received. This allows one node to completely dominate the channel while it sends back-to-back packets with acknowledgment gaps in between. Packet delivery and acknowledgment success rate goes up, collisions go down, and energy efficiency goes way up.
So far, this seems to work very reliable on my desk. I have yet to test it outside or in a real network, where any number of issues may come into play. -David _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Thursday, May 29, 2008 7:24 PM To: David Moss Cc: tinyos-help@millennium.berkeley.edu Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening 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
