Sharmistha,
Try first deploying it in a TOSSIM simulated environment with 4 nodes, that should clarify most of your doubts and then try on actual motes. Also use TinyViz to visualize debugging info, radio & UART pakets. I am doing the same stuff.
Arti
santosh dwivedi <[EMAIL PROTECTED]> wrote:
santosh dwivedi <[EMAIL PROTECTED]> wrote:
Oppps !! missed one thing:
as sycnhed shows not synchronised global time is not valid.
please look at TimeSyncDebuggerM.nc in ReceiveMsg.receive global time is assigned equal to local time
hope this helps
Santosh Dwivedi
On 12/6/05, santosh dwivedi <[EMAIL PROTECTED]> wrote:_______________________________________________Hello Sharmistha,
Answer below your questions:
On 12/6/05, Sharmistha Maitra < [EMAIL PROTECTED]> wrote: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: resynchronising1 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 0While 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 table1 21 22938250 22938250 0.0 0 65535 0 0I 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 a! nybody can give a hint why this is so ?1. Why I am getting Globaltime and localtime same ?
Perhaps node with TesttimesyncC application is elected as leader !! Did you assign it lower node id then TimeSyncPoller one ? as being is leader its local time is global time actually.But if it was route then Synched must have not been zero ,there is contradiction.. Switch off
and switch on the motes one by one is still both times same ? and synched showing zero ?
2. The skew is 0.0, that means no drift, is that the reason of global and local times being equal ?skew means ratio of clock speed 0.0 means clock of ! both the node runs with same speed, reason for being both time same explained above
3. But then why "Synched ?" shows 0 ? I thought 0 mean the nodes are unsynchronized.>>yes 0 means unsynchronised, zero is returned when there is not enough entries in regression table or node is not route , this should not happen,
4. Why "#msgs stored in regression table" is 0 even after so many time sync msgs ? Shouldnt it increase ?>>Perhaps Node with TimePollerC application is not sendingany sync message as sync message is sent when iether number of entreis in reg! ression table greater than a limit or send message route id is not nodes id. why TimePoller does not have enough entries I am not sure!!!
Have u assign both the nodes same node id?
try to assign TimePollerC lower address than TestTimeSync and reset latter node in middle and observe result
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.>>However its not problem, but u can test with more motes with different mote id.
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> > *From: < B>Matthew J Whelan [ [EMAIL PROTECTED]]
> >
> > 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 app! lication 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
&g! t; > 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
> >
> >
> >
> > -------------------------------------------------------------
> -----------> > <" target="l"> https://mail.millennium.berkeley.edu/cgi-
> > *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] c.com >
> > 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 appre! ciated. *
> > **
> > *// 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; *
> &g! t; *//--------/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 me! ssage 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
> 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
> > *
>
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
