search

VijayaLakshmiMaurya / tinyos-main

Automatically exported from code.google.com/p/tinyos-main
0 stars 0 forks source link

TimeSync not working properly with LowPowerListening #120

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Set LPL_INTERVAL=250 for mote clients and a base station in both makefiles
2. Run mote clients with TimeSync and LowPowerListening on
2. Run a base station with TimeSync and LowPowerListening on, which sends time 
sync messages.
3. See if mote clients are time synced with the base station

What is the expected output? What do you see instead?
- The expected output is that all motes are time synced, but what I see is that 
some of motes are synced in time, but others are not although all motes are 
next to each other

What version of the product are you using? On what operating system?
- tinyos-main 
- Ubuntu

Please provide any additional information below.
- The TimeSync problem turned out to be that the resend() was not being called 
to send time sync messages for the duration of the LPL INTERVAL=250 because a 
LPL_INTERVAL value got overwritten by a default value "0" instead of using the 
user’s defined value "250".

Details:
Below is the code where the overwriting happens. 
The user’s LowPowerListening.setRemoteWakeupInterval() call  gets overwritten 
by the function AMSend.send() of the component LplAMSenderP. It calls the 
Lpl.setRemoteWakeupInterval() with a returned value from 
SystemLowPowerListening.getDefaultRemoteWakeupInterval(). This gets a default 
value of LPL_DEF_REMOTE_WAKEUP=0 in Lpl.h if it is not defined with a new value.

CODE  (LplAMSenderP.nc):
command error_t AMSend.send(am_addr_t addr, message_t* msg, uint8_t len)
  {
    call Lpl.setRemoteWakeupInterval(msg, call SystemLowPowerListening.getDefaultRemoteWakeupInterval());
    return call SubAMSend.send(addr, msg, len);
  }

CODE  (SystemLowPowerListeningP.nc):
uint16_t remoteWakeup = LPL_DEF_REMOTE_WAKEUP;

command uint16_t SystemLowPowerListening.getDefaultRemoteWakeupInterval() { 
return remoteWakeup; }

I am not sure whether I was supposed to use two flags for the TimeSync and 
LowPowerListening to work properly, but I want to report this problem as an 
issue so that someone can take a look at it and decide whether this is a bug or 
not since this was not clear.

One way to fix this issue is to define both CFLAGS += 
-DLPL_DEF_REMOTE_WAKEUP=250 and CFLAGS += -DLPL_INTERVAL=250 in makefile.

Original issue reported on code.google.com by kyeo...@gmail.com on 13 Feb 2012 at 10:15

GoogleCodeExporter commented 9 years ago 
If I'm not wrong, since 2.1.1, you should use DirectAMSenderC instead of 
AMSenderC to avoid default LPL values to overwrite your values. Is it possible 
that you are using AMSenderC component?

Original comment by ucolesa...@gmail.com on 14 Feb 2012 at 8:46

GoogleCodeExporter commented 9 years ago 
This is news to me. And if this is the case, then CC2420TimeSyncAMSend is at 
mistake, as it does still link to AMSenderC, and not DirectAMSenderC.

Original comment by thomas.s...@gmail.com on 14 Feb 2012 at 5:08

GoogleCodeExporter commented 9 years ago 
If someone would put this code into Lpl.h, that would resolve the backward 
compatibility:
#if !defined(LPL_DEF_LOCAL_WAKEUP) && !defined(LPL_DEF_REMOTE_WAKEUP) && 
defined(LPL_INTERVAL)
  #define LPL_DEF_LOCAL_WAKEUP LPL_INTERVAL
  #define LPL_DEF_REMOTE_WAKEUP LPL_INTERVAL
#endif
(I didn't check the code with compiler, so use with caution.)

Original comment by andras.b...@unicomp.hu on 14 Feb 2012 at 5:12

GoogleCodeExporter commented 9 years ago 
Thank you all for your responses. I am sorry for the late response. Somehow I 
received the comment 2 and 3 email notifications but didn't receive the comment 
1 notification. For the comment 1, yes, I am using AMSenderC, not 
DirectAMSenderC. It is good to know that I can also use DirectAMSenderC. Thank 
you. As the comment 2 indicated that there might be other components that are 
linked to AMSenderC, in my opinion it would be nice if something like the 
comment 3 solution is put into code to resolve this issue since Lpl.h is where 
the problem occurs. This might also helps for the backward compatibility. I am 
good for now, but for the future and other people, I hope a permanent solution 
is suggested or maybe implemented so that there won't be any confusion. Thank 
you.

Original comment by kyeo...@gmail.com on 14 Feb 2012 at 5:47

GoogleCodeExporter commented 9 years ago

Original comment by philip.l...@gmail.com on 8 Mar 2012 at 10:52