Sharmistha,
The goal of FTSP is to provide a global time in the network. That is, if
you call GlobalTime.getGlobalTime() on multiple nodes at the very same time, it
should give you the same value (with some error, of course).
The global time in the network is actually the local time of a
designated node, the timesync root. The timesync root is chosen with a simple leader
election algorithm.
Needless to say, only those nodes participate in the synchronization, which
have the TimeSyncC component compiled in and started. In your case, this is
holds only for one of your motes, the one running TestTimeSyncC. Hence this
mote is going to be the timesync root, and the global time will be the local
time of this mote.
You would need at least four motes in order to do some meaningful
testing: at least two of them running TestTimeSyncC, a poller and a base
station. The poller generates messages periodically, which are timestamped with
the global time when they are received by the motes running TestTimeSyncC. It
is assumed that the messages are received at the same (physical) time, and that
the motes are synchronized, therefore, the timestamps should be equal.
Obviously, because of various errors, they are somewhat different; nevertheless
you should get approximately the same numbers.
Regards,
Janos Sallai
-----Original Message-----
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Sharmistha Maitra
Sent: Monday,
December 05, 2005 6:15 PM
To:
[EMAIL PROTECTED]
Subject: Re: [Tinyos-help] Testing
FTSP
Hi All,
Thanks for your suggestion Michael and Santosh. I
reworked from a more basic level and could verify the radios of 433 and 900
separately. As you suggested I found that the 433Mhz radio motes are
unable to talk to 900.
In the meantime I ran the FTSP algorithm with three
433 motes. One loaded with TOSbase, another with TestPollerC and another with
TestTimeSyncC. I have captured the time sync messages on my PC using
PrintDiagmsgs and they look like below:
[EMAIL PROTECTED]
/opt/tinyos-1.x/tools/java/net/tinyos/tools
$ java net.tinyos.tools.PrintDiagMsgs
Testingargs.length=0Platform COM1:57600 decoded into 1
Built a Packet source for avrmote
[EMAIL PROTECTED]:57600: resynchronising
1 3 6744190 6744190 0.0 0 65535 0 0
1 3 6744190 6744190 0.0 0 65535 0 0
1 6 9446499 9446499 0.0 0 65535 0 0
1 9 12137048 12137048 0.0 0 65535 0 0
1 9 12137048 12137048 0.0 0 65535 0 0
1 12 14838498 14838498 0.0 0 65535 0 0
1 21 22938250 22938250 0.0 0 65535 0 0
1 21 22938250 22938250 0.0 0 65535 0 0
While trying to understand the
above (example: the last line), I came to know that following mean
this :
Nodeid Seq#Polling msg
Globaltime
Localtime skew synched
? rootid seq# #msgsstored in
regression table
1
21
22938250 22938250
0.0
0
65535 0 0
I know I have to study the code in detail to
understand the above fully but I have already read the basic scheme
in the VU paper but donot understand somethings above. So would like to
ask incase anybody can give a hint why this is so ?
1. Why I am getting Globaltime and localtime same ?
2. The skew is 0.0, that means no drift, is that the
reason of global and local times being equal ?
3. But then why "Synched ?" shows 0 ? I
thought 0 mean the nodes are unsynchronized.
4. Why "#msgs stored in regression table" is
0 even after so many time sync msgs ? Shouldnt it increase ?
I havent changed the code in anyway. The only
undesirable thing I am doing is using 1 node with TesttimesyncC whereas I
should have some more loaded with this application to see how the timesync msgs
tally with each other. But I donot think that should affect the above.
Thanks for your patience,
Will appreciate if you kindly help me...
Regards,
Sharmistha.
----- Original Message -----
From:
Michael Schippling <[EMAIL PROTECTED]>
Date:
Tuesday, November 29, 2005 8:25 pm
Subject:
Re: [Tinyos-help] Testing FTSP
> yup, mixing and matching frequencies don't work
too good...
>
> You might try setting up your system from a more basic level
> first. The apps/MicaHWVerify program will test radio connectivity
> when used with a TOSBase mote in the programmer. Also, once you are
> rolling, I suggest that you use the contrib/xbow code tree (download
> from xbow support) because it has better compile time radio support.
>
> MS
>
>
> Sharmistha Maitra wrote:
> > Dear All,
> >
> > I am testing the Flooding TimeSync Protocol by VU using
> TestTimeSync
> > application that is there in the VU apps library. I have loaded
> one mote
> > with TOSBase , another with TestTimeSyncPollerC and two others
> with
> > TesttimeSyncC. I am running PrintDiagMsgs.java on my PC to which
> TOSbase
> > is connected and I am getting a message like this :
> >
> > TestingPlatform COM1:57600 decoded into 1
> > Built a Packet source for avrmote
> > [EMAIL PROTECTED]:57600 <:')" >[EMAIL PROTECTED]:57600>:
resynchronising
> >
> > This is all. I am not getting any timesync messages frm the
> nodes. Can
> > anybody guide me what can be the reason ? The mica motes that I
> am using
> > are a mixture of 433Mhz and 900Mhz. Could that be the reason
> that a 433
> > cannot talk to a 900 ? Also TOSbase code says that
> green/red/yellow LED
> > will toggle when the node with TOSbase receives radio message or
> sends
> > it. I am seeing none of these.
> >
> > Anybody helping me I will apreciate. Thanks very much,
> >
> > Smaitra.
> >
> >
> >
> >
> > -----------------------------------------------------------------
> -------
> >
> > Matt,
> >
> > You have the change in your code snippet, though don't modify
> the
> > MSP430ClockM, add the changes into your own application module.
> For
> > example:
> >
> > In your application you reach the point that you want to
> increase the
> > clock to 4MHz:
> >
> > BCSCTL2=0x00;
> >
> > the clock will change rates at the next rising edge.
> >
> > When you want to change back to 1MHz, insert:
> >
> > BCSCTL2=DIVS1;
> >
> > Regards,
> > Matt
> > -----"Matt Orlofsky" <[EMAIL PROTECTED]> wrote:
-----
> >
> > To: "Matthew J Whelan" <[EMAIL PROTECTED]>
> > From: "Matt Orlofsky" <[EMAIL PROTECTED]>
> > Date: 11/29/2005 04 00PM
> > cc: <[EMAIL PROTECTED]>
> > Subject: RE: [Tinyos-help] Tmote SCLK Change Effects Deluge
> >
> > Matt,
> > Interesting. Is changing the clock rate in an application more
> > complex then a simple write to BCSCTL2? If so, would you be
> willing> to send me a code snippet?
> > Thank you for the quick response.
> >
> > Matt Orlofsky
> > ______________________
> > RLW, Inc.
> > Phone: 814-689-1833
> > Cell: 585-233-8243
> >
> >
> >
> > -------------------------------------------------------------
> -----------
> > *From: < B>Matthew J Whelan [EMAIL PROTECTED]
> > *Sent: *Tuesday, November 29, 2005 3:50 PM
> > *To: *Matt Orlofsky
> > *Cc: [EMAIL PROTECTED]
> > *Subject: *Re: [Tinyos-help] Tmote SCLK Change Effects Deluge
> > **
> > *
> > **
> > *Matt, *
> > * *
> > *I have also developed applications in which I increased the SPI
> > clock (SMLCK) to the MCLK rate for faster writting of data
> to the
> > flash memory chip. I have had problems with using the SMLCK
> at the
> > MCLK rate in my applications which do not use deluge. It
> appears to
> > be related to the radio or UART transmission. If I change
> the rate
> > to 4MHz only when writing to the flash and then revert back
> to 1MHz
> > for radio communication I am ok though. Unless you are
> trying to
> > communicate with the CC2420 at a faster SPI rate, I would
> suggest> this approach, as I have not had any problems with this
> > implementation. *
> > *DIV> *
> > *Regards, *
> > *Matt
> > *
> > [EMAIL PROTECTED] wrote: ----
> -
> >
> > *
> >
> > *To: <[EMAIL PROTECTED]>
> > From: "Matt Orlofsky" <[EMAIL PROTECTED]>
> > Sent by: [EMAIL PROTECTED]
> > Date: 11/29/2005 03:39PM
> > Subject: [Tinyos-help] Tmote SCLK Change Effects Deluge
> >
> > *
> > *All, *
> > **
> > *I changed MSP430ClockM.nc (see source code snippets
> below) such
> > that the SCLK would run at the same speed as the MCLK (
> MHz). I
> > did this to improve the maximum clock rate of the SPI
> bus. The
> > change appears to have worked in my application however
> Deluge> does not work properly. I'm using Deluge 2.0.
> Any idea what
> > the problem is? Perhaps there is a delay loop in the Deluge
> > code that is effected by the change in clock rate? Any help
> > would be greatly appreciated. *
> > **
> > *// Snippet from MSP430ClockM.nc v1.14 near line 60 *
> > **
> > *//--------before--------// *
> > * // BCSCTL2
> > // .SELM = 0; select DCOCLK as source for MCLK
> > // .DIVM = 0; set the divisor of MCLK to 1
> > // .SELS = 0; select DCOCLK as source for SCLK
> > // .DIVS = 2; set the divisor of SCLK to 4
> > // .DCOR = 0; select internal resistor for DCO
> > BCSCTL2 = DIVS1; *
> > *//-------/before--------// *
> > **
> > *//---------after---------// *
> > * // BCSCTL2
> > & bsp; // .SELM = 0; select DCOCLK as source for MCLK
> > // .DIVM = 0; set the divisor of MCLK to 1
> > // .SELS = 0; select DCOCLK as source for SCLK
> > // .DIVS = 0; set the divisor of MSCLK to 1
> > // .DCOR = 0; select internal resistor for DCO
> > BCSCTL2 = 0x00; *
> > *//--------/after---------// *
> >
> > *Matt Orlofsky **
> > ____________________
> > RLW, Inc.
> > Phone: 814-689-1833
> > Cell: 585-233-8243 *
> >
> > *
> >
> > ---------------------------------------------------------
> ---------------
> > Disclaimer: This message is intended only for the use of the
> > noted recipient(s) and may contain information that is
> > priviledged, proprietary and confidential. *
> >
> > *If you received this message in error, you must not,
> directly> or indirectly, distribute, use, disclose, print,
> or copy any
> > part of this message. Please notify the sender if you have
> > received this message by mistake and erase this email
> and its
> > contents from your system. Note that any views or opinions
> > expressed in this message are solely those of the author
> and do
> > not necessarily represent tho e of the company. Finally,
> note> that email transmission cannot be guaranteed to be
> secure or
> > error-free. Information could be intercepted, corrupted,
> lost,> destroyed, received late or incomplete, or infected
> with a
> > virus. Therefore, the sender does not accept liability
> for any
> > errors in the content of this message which arise as a
> result of
> > email transmission. *
> >
> > *_______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> > https://mail.millennium.berkeley.edu/cgi-
> bin/mailman/listinfo/tinyos-help
> > <"
target="l">https://mail.millennium.berkeley.edu/cgi-
> bin/mailman/listinfo/tinyos-help>
> > *
> >
> > *
> > *
> >
> > *
> > *
> >
> > *
> > *
> > -----------------------------------------------------------------
> -------
> > *
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> > https://mail.millennium.berkeley.edu/cgi-
> bin/mailman/listinfo/tinyos-help
> > *
> >
> > *
> > *
> > -----------------------------------------------------------------
> -------
> > *
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> > https://mail.millennium.berkeley.edu/cgi-
> bin/mailman/listinfo/tinyos-help
> > *
>
