Dear all, I instrumented task getCca() of PowerCycleP.nc (in tos/chips/cc2420/lpl) with some debug pin output. In doing so, I discovered some issues when testing with apps/tests/cc2420/LplUnicastPeriodicDelivery using a logic analyzer on Xbow MPR2600 nodes:
1. EnergyIndicator.isReceiving() is true for 4 iterations of the for loop. Therefore, PowerCycle.detected() is signaled immediately and we return to the caller. 2. Therefore, the node assumes that there is a transmission, stays on and tries to receive it. Thus, the off-time is reduced! 3. Increasing MIN_SAMPLES_BEFORE_DETECT to 4 already restores the wanted behaviour of the for loop, i.e. the next packet on the channel will trigger the PowerCycle.detected() signal. (I'm not sure what causes this wrong behaviour. The CCA pin delivers the "oscillator stable" signal at the beginning, after the pin goes high, the multiplexer is switched back to normal CCA behaviour. Maybe, it takes some time until this switch takes effect in the CC2420 chip?) 4. Now, when using unicast messages most of the get lost. The reason is that the transmitter sends a message and waits then for an ACK. But this wait time is 7,8 ms long, which is much longer than the normal time a receiver checks for a busy channel (approx. 3 ms). This wait time is determined by MAX_LPL_CCA_CHECKS, which is set to 400. 5. After increasing MAX_LPL_CCA_CHECKS to 1400 (and thus the wait time to more than 10ms) the receiver gets the packets again. Can anyone confirm this behaviour (first increase MIN_SAMPLES_BEFORE_DETECT, later MAX_LPL_CCA_CHECKS)? Is there a problem with LPL on CC2420 and unicast? Shall ACKs be disabled for unicasts? Will the default values for both constants be increased in the future? Best, Daniel -- Daniel Minder University of Duisburg-Essen, Networked Embedded Systems Bismarckstr. 90, 47057 Duisburg, Germany Skype: d.minder _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
