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
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help