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 <mailto:[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 [mailto:[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
        
<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
*
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to