Announcement

Collapse
No announcement yet.

Sleep after forwarding multicast?

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

  • Sleep after forwarding multicast?

    Hello,

    When a SNAP node receives a multicast, it will also forward that multicast. I want to put the node to sleep as soon as the multicast is complete. How can I tell that multicast forwarding is complete?

    HOOK_RPC_SENT is documented as waiting for 'outgoing RPC call'. Will it also work for an outgoing forwarded multicast packet?

    e.g. in sleepy.py example: mcastRPC(1, 3, 'gotoSleep') -- I guess nodes will not forward multicast packets because they sleep before the forwarding transmission is done.
    Last edited by berwyn; 06-10-2014, 08:08 PM.

  • #2
    berwyn

    Repeaters/routing node usually need to be powered continuously because they don't know when they will be called upon to repeat a message for another node to hear.

    You may want to review the Sleepy Mesh Ap note because you will probably have to sync the mesh's up-time to include repeating/routing with sufficient awake time for nodes to do the repeating/routing. Not just send and sleep immediately.

    http://forums.synapse-wireless.com/showthread.php?t=79

    You may want to review the SNAP Primer also.
    http://forums.synapse-wireless.com/u...P%20Primer.pdf

    Comment


    • #3
      Yes, I know that, RPS. We are planning to time-sync the mesh wake-ups -- including routers.

      But you didn't answer my question. How can we tell when a multicast has been forwarded?

      HOOK_RPC_SENT would be nice if it works, but another option might be getStat(13) -- does this counter get updated when the multicast starts going out, or when it's finished going out?

      Comment


      • #4
        I do not believe that getStat(13) will provide the functionality for which you are looking.

        getStat(13) provides no information on *what* is being forwarded, so even doing multiple reads and confirming that the value has stabilized at 0 and is not periodically increasing still will not guarantee that you have specifically forwarded the mcastRpc(gotoSleep) about which you care.

        The best thing you could do off the top of my head is to keep track of a global in your nodes' gotoSleep() function that indicates whether or not a gotoSleep() command has been received. Then, instead of going to sleep, the function could just pass, to allow other things to happen such as the mcast forwarding. In a 1sec hook or similar, you would then check the global status variable to see if you had previously received a gotoSleep command, at which point you could then execute your sleep relatively confident that the mcast had already been forwarded prior to sleeping.

        Comment


        • #5
          @berwyn, is it an absolute requirement that you need to have your routers being battery powered (I am assuming you are using batteries since you are sleeping) as opposed to say having a repeater plugged into an outlet wherever your system is setup?

          korymc

          Comment


          • #6
            Yep, I'm afraid battery-powered routers are an absolute requirement. We're installing this for beekeepers out in rural Australia ... nearest power outlet could be hundreds of km away.

            Solar power is also not a good option.

            Comment


            • #7
              Can you designate certain nodes to be routers? Then you could make only those specific nodes stay awake longer and give them bigger batteries. That way you can get hopping and save money over everyone staying awake and needing more batteries.

              Are you at liberty to describe your application in more detail?

              BoB

              Comment


              • #8
                To answer your questions, rbelli1:
                • Our product is Hivemind, beehive scales reported by satellite. Our new version is to be SNAP wireless with each node reporting to a central satellite transmitter. We need to be able to handle up to 150 nodes per site, as most commercial apiaries in Australia are up to that largen. We only normally report data only once per hour, but need the sleepy mesh to awaken more frequently (once per minute) in case there are theft alarms or users wanting to interact with the network. It is those frequent wake-ups that need to sleep again as soon as possible if there is no network activity -- hence a 'sleep' multicast, and the node is to sleep immediately after repeating the multicast.
                • Our hive scale will fit only two AAA batteries, so no larger batteries for those. However, we do plan special router nodes with larger batteries for long distance hops in pollination scenarios, but there's no way we can make them large enough to stay on forever -- and solar power is not a good option for various reasons -- we've tried it already.


                And now to answer my own questions, I've done a little more research:
                • In this thread rbreesems says he used HOOK_RPC_SENT to fix sleepy mesh to delay sleep until after the multicast is finished forwarding. So according to him, it works for forwards. The docs say nothing, so it would be really good for someone at Synapse to confirm this from their source code.
                • My own tests found that getStat(13) (forwarded packets) does not do what we need here because the counter is incremented when the packet is queued, not when it is finished sending.

                Comment

                X