Announcement

Collapse
No announcement yet.

RF300 SleepyMesh non-operational

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • RF300 SleepyMesh non-operational

    I am trying to run the sleepyMesh scripts on a SYNAPSE RF300 module. Are there some compatibility concerns that I need to be aware of other than the differing pin layouts?

    When I load the scripts it functions as intended ONCE and then never again seems to work. I followed the procedure outlined in the Sleepy Mesh application note [doc # 628-0003]. After running initSleepyMesh() on portal my node will report that it is online and sensor is False. After one sleep cycle, it will then report as being offline and in the portal log it will note that portal did not receive a response from the node. The log also gets filled up with nodes are asleep messages and portal is putting nodes to sleep early messages.

    I have also populated a sleepyStub.py script with custom code that does only one operation (very simple code) and couldn't get that to work any differently.

    There doesn't seem to be a good link between portal and the nodes. Once I start the script, I am not able to pause sleeping using the portal functions. The RPC calls to pause the nodes get queued and sometime sent out of the portal queue but the nodes never stop sleeping. This is a pain because then I can never change the running script on them either.

    I am not putting my bridge node to sleep. Only the remote nodes sleep. The bridge node has no script loaded. Portal has sleepyMonitor.py loaded (with correct addresses updated into the polling function).
    Last edited by STwingad; 06-28-2011, 03:09 PM.

  • #2
    Here is some more information that I found about the behavior of sleep() on the RF300. It doesn't appear that there is anything that makes the sleepyMesh scripts (eg. sleepyTemplate.py sleepMonitor.py) incompatible.

    Built-in function sleep():
    The Si100x supports two sleep modes. Mode 0 provides a slightly “deeper” sleep (lower power consumption) than mode 1. However mode 0 requires an additional 300 ms to wake up, and does not maintain state for IO17 or IO18.

    The first timed sleep executed after a node boots requires approximately 80 milliseconds of additional configuration time to initialize the clock. Subsequent timed sleeps will not have this overhead.

    On the Si100x, zero indicates “untimed sleep.” Positive numbers indicate how long to sleep in 1.0s “ticks” (regardless of mode), and negative numbers indicate the following fractions of a second:

    Ticks Sleep time
    -1 .... 16ms
    -2 .... 31ms
    -3 .... 63ms
    -4 .... 125ms
    -5 .... 250ms
    -6 .... 500ms
    -7 .... 1000ms

    Maximum allowed sleep: 32767 seconds, or 9:06:07.

    Performance Metrics
    Here are the results of some recent performance measurements, which may help you gauge if SNAPpy
    can address your application’s timing requirements.

    Time to awaken from sleep (mode 0):
    340 ms

    Time to awaken from sleep (mode 1):
    1.2 ms

    Time to startup from power-on:
    677 ms

    Comment


    • #3
      It should be operational with any type of RF Engine. We'll try and setup a test-bed here over the next few days.
      sigpic
      Proven Solutions for the Internet of Things
      www.synapse-wireless.com

      Comment


      • #4
        I have spent more time troubleshooting this problem. Before I was using only two sleeping nodes and one bridge node and it seemed like the behavior was completely unsynced. I then added more sleeping nodes to the mesh and have discovered some interesting behavior.

        I believe that the problem is that the leader node is not sending the sleep command until after it wakes up from its own sleep (i.e. the node sleeps before the multicast RPC is sent). I believe this because if I add more nodes to the network, all of the slave nodes will sleep in unison with each other, but the sleep will initiate only once the leader node wakes thus the leader and slaves are perfectly out of phase.

        I am using the sleepyMesh scripts provided on this forum. There is no rpcSent hook used in these scripts. Should the code function correctly without needing this hook?

        [edit] I created a new thread titled 'RF300 SNAP Sniffer non-functioning' for this issue:
        Sorry to fork the thread, but while I was trouble shooting I tried to use the SNAP Sniffer program. I tried loading both the RF300_SnifferV1.2.0 and the Si1000_SnifferV1.2.0 firmwares on my SYNAPSE RF300 module. The snap sniffer program identified and successfully connected to node (under both firmwares) but I never got any output on the GUI. I set the channel and pressed the start button in the snap sniffer program and it did not appear that the program reacted at all. Is there a problem using the SNAP Sniffer with RF300 nodes?

        [edit] solution was to update the sniffer firmware
        Last edited by STwingad; 07-07-2011, 10:33 AM.

        Comment


        • #5
          Now that I have the sniffer working I have confirmed what I suspected from observing the operation of the nodes. The sleep command and the meshUp command are sent out with only 20ms delay between them (rather than 5 seconds of sleep time delay between them) as the sleep command for remote nodes does not get sent out before the local sleep command is executed.

          Attached is a copy of the sniffer log. I am still using the defaults set up in the script as 5 seconds sleep followed by max 2 seconds wake. Portal is not running so as to be able to put the nodes to sleep early. In the log there is approximately 7 seconds between sleep commands as expected by these parameters (plus a few ms for CPU run time). The first sleep command isn't sent out by the leader node until after it wakes up from its own sleep followed immediately by a meshUp command telling Portal to start polling. The remote nodes are asleep however at this time so a timeout occurs.

          It is apparent that for my application the code needs to improved to prevent this. Was this not an issue with the RF100 nodes? Have other people been successful with using the sleepMesh scripts as provided?

          If I have the permission of the Synapse developers, I will make the changes to the sleepyTemplate.py script and can post my updated script. I envision the changes being simply adding some hooks to lock the script in place until the mcastRpc() is confirmed sent. Currently the script looks like this:

          Code:
          def sendSleep():
              """tell everyone else to go to sleep, and go to sleep ourself"""
              global sleepTicks
              mcastRpc(1,5,'gotoSleep',sleepTicks)
              doSleep(sleepTicks)
          
          def doSleep(dur):
              """this is the actual "going to sleep" code"""
              global isLeader, wakeTimer, electTimer, sleepMode
          
              beforeSleep(dur)
              sleep(sleepMode, dur)
              afterSleep()
          
              if isLeader:
                  mcastRpc(1,5, 'meshUp', localAddr())
          and apparently the mcastRpc('gotoSleep') does not get out before the sleep() is ran because both the gotoSleep and the meshUp commands come out at the same time.
          Attached Files
          Last edited by STwingad; 07-07-2011, 11:35 AM.

          Comment


          • #6
            apparently this issue was brought up a year ago: forums.synapse-wireless.com

            and it affects all models.....

            Comment


            • #7
              Correct. Did you see the updated script that rbreesems posted (see attached for a copy).

              This is a case of the older firmware having slightly different timing that allowed the mcastRpc to get out before the node went to sleep. The scripts (and all like them) should have used the RPC Sent HOOK.

              We can make sure this gets incoroporated into an update version of the app note.
              Attached Files
              sigpic
              Proven Solutions for the Internet of Things
              www.synapse-wireless.com

              Comment


              • #8
                Originally posted by Jheath View Post
                Correct. Did you see the updated script that rbreesems posted (see attached for a copy).
                Yes, I am analyzing his script now to make sure that everything there is satisfactory for my application and then I will test it.

                I tried to implement my own solution using the rpc_sent hook to change a global variable and running a loop on that variable but it didn't work.

                Code:
                @setHook(HOOK_RPC_SENT)
                def rpcSentHook(bufRef):
                    global sendComplete
                    sendComplete = True
                
                def sendSleep():
                    """tell everyone else to go to sleep, and go to sleep ourself"""
                    global sleepTicks, sendComplete
                    sendComplete = False
                    mcastRpc(1,5,'gotoSleep',sleepTicks)
                    
                    loop()
                    
                    doSleep(sleepTicks)
                    
                def loop():
                    global sendComplete
                    if not sendComplete:
                        # just sit here doing nothing until the send is complete
                        loop()
                The sleep still happened before the rpc was sent. I liked this because I could program the delay in only where needed and didn't have to worry about checking to see which rpc was the one that just completed. Is there a reason that you can see why this didn't work?
                Last edited by STwingad; 07-08-2011, 12:45 PM.

                Comment


                • #9
                  I couldn't get my method to work, but I implemented the method that rbreesems designed and the nodes are behaving properly finally. I am still not satisfied by the way Portal is interacting with them so I'll spend some more time looking at that.

                  One thing that I still don't like about this method is that you have to call a new function at the end of the hook to continue. Is there a way that I can have the RPC in the middle of a function, but have the progress through the function paused until after the RPC_SENT hook runs?

                  Comment

                  X