Sleep mode

[l091]

I have been trying to get the network up and running in low power mode using the sleepy mesh low power routing guide 628-001. But it seems to me that de modules are not being synchronized very well. I believe they are supposed to go to sleep together at (about) the same time for 5 ticks in this demoprogram. But it seems to mee that every modules wakes up and goes to sleep on its own pace. I didnt change anything about the scripts, just used them and installed them as provided on the website from Synapsi.

Are there maybe some kind of important checkpoints I missed so I can determine what is wrong. Because it makes no sense that modules go to sleep and there is no synchronzation at all.

[kbanks]

Are there maybe some kind of important checkpoints I missed so I can determine what is wrong. Because it makes no sense that modules go to sleep and there is no synchronzation at all.

1) You need a quiet channel for the demo to work.

The demo uses multicast messages for some of it's operations (like the leader node telling the other nodes to go to sleep). If you have a busy channel (for example, a pair of LinkQualityRangers jabbering at each other), then some of the multicast messages might be missed, resulting in a loss of synchronization.

If you have other stuff going on, moving the sleepy mesh to a different channel might help.

2) Have you configured things so that at least one node is eligible to be the leader? Which one is it? (Who has an "L" on their seven-segment display?). Reversing the question - did you configure things so that NO node was eligible to lead?

3) If you are having touble with the examples in 628-0001, take a look at application note 628-0003 and it's separate set of example scripts. Something may "click" when you look at that second document that didn't when you used the first one.

If this doesn't get you going, make a follow-up post and try to describe what you are seeing the nodes do, including what they are displaying on their seven-segment displays.

[l091]

Ok, i have them all in the same channel. But how can I verify that the channel actually is clear?

I use the scripts provided in de zipfile with 628-001. Only i modified the adress for the burst(n) function. They should all be allowed to become leader (no?).

So what happens is at follows:

I install all the scripts on the modules. Then I do initSleepyMesh() on the Portal. Next I try startSleeping() and then i noticed that only some of the modules are listening and start sleeping synchronously. The others are just doing on their own.

After I click stopSleeping() and then resumeSleeping() the modules start waking up and going to sleep like random. They are not waiting and sometimes there are more leaders than 1 or they call an election when the other modules are sleeping.

[Jheath]

Ok, i have them all in the same channel. But how can I verify that the channel actually is clear?

There is a tool within Portal called 'Channel Analyzer' that scans all 16 channels for energy. It can be found under the 'View' menu.
You can also use a lightweight spectrum analyzer to determine if there is an abundance of RF interference.


They should all be allowed to become leader (no?).


Only a single node should be elected as the leader if all the nodes can communicate with one another. Have you modified any other portion of the script besides the address?


After I click stopSleeping() and then resumeSleeping() the modules start waking up and going to sleep like random.

If you issue the stopSleeping() command (so that all nodes can here it), do all nodes remain awake or are some still alternating between sleep and wake? How many nodes are in your current sleepy mesh network?

[l091]

OK, I checked and I have chosen the most clear channel available. But still the same problem.

When I do stopSleeping() some modules stay alive but other modules do not. They just keep waking up and going to sleep on their own. Even when they are next to each other on the same table.

Only one node should be elected, I know, but it looks like they are not communicating at times and I do not understand how this is possible. I just want them to go to sleep at same time and then wake up for short period and then go back to sleep. Synchronous obviously. It looks like this example script is not quite fit to do it. I am using only 4 modules and the pc-bridge node for this test.

I only changed the adress in de burst() definition of the script.

Actually when you look at the status for longer period it is like they just do not actually have a connection. Like the mesh network doesnt reconstruct well enough after waking up. that is maybe why some modules are dropping out and remain desynchronised forever.

[kbanks]

With your scripts already loaded, and everything ready to go, try rebooting all the modules at the same time (it doesn't have to be exactly the same time, but all within the same second).

See if a normal election takes place, resulting in one leader, the rest followers, and a synchronized mesh.

If not, you have something fundamental wrong, like having some of the nodes on the wrong channel and/or Network ID. Also check to make sure all the nodes have compatible Mesh Routing settings.

If they do sync up (and stay in sync), then the problem is in how you are kicking things off.

There is a "grace" timeout in the example scripts. This timeout affects how quickly nodes decide the current leader must have died, and when they hold another "election".

If some of your nodes are initiating a sleep cycle before the rest of the nodes are ready to go, then they can become unsynchronized as you describe. (Individual sub-groups form, that are unaware of each other). Because the nodes all show their status on their seven-segment displays, you should be able to follow along with what they are doing.

If you are unable to get all the nodes started close enough together, try increasing the "grace" timeout (look in the script). It may need to be longer, relative to the sleep timeout specified by the script.

Also double-check that you are using sleep mode 1 in your experiments. Mode 0 has a +/- 30% inaccuracy that makes it unsiutable for sleepy mesh synchronization.

[l091]

Here is what happens with only 2 modules and the pc bridge:

I do as you say: load the script, same channel, same network, clear channel. I turned both of the modules on at the same time. Then there is an election but after the election both modules become leader and after that it is desynchronized. Sometimes when one is leader and the other one isnt the leader goes to sleep and the follower node keeps waiting a long time.


...

sleepTicks = 5 # this one represents "ticks", as used by the sleep() function

...
# The rest of these are in milliseconds
wakeTime = 2000
graceTime = 1000
electTime = 2000

...

How to do this:
Also check to make sure all the nodes have compatible Mesh Routing settings.
I checked the mesh configuration parameters and for all the modules they are the same.

[kbanks]

Then there is an election but after the election both modules become leader...

1) It sounds like they are not "hearing" each other in some way. (?) You say you've already confirmed all the communications settings so I am out of ideas there.

2) When an election happens, priority is based on SNAP address. Do all of your units still know their correct address (compare what Portal shows to the stickers on the nodes)?

3) Since you are somewhat "stuck" anyway, how about taking a look at the second Sleepy Mesh application note. See if you have better luck with those examples. (The second app note includes scripts that have been refactored from the original ones to make it easier to customize for your own application).

[l091]

Maybe I didnt check the configuration parameteres correct.

How should they look like? Because now I didn't touch them, I only noticed that all the modules have the same configuration parameters. I checked the adresses and network ID's and they all match the stickers.

I will try with the other script 003, but to me it actually looks very similar.

[l091]

Just finished checking the version 003 of the sleepy mesh scripts, but actually the modules behave just the same.

More specifically it seems that when a module becomes a follower he misses the broadcast from the leader, because I get a timeout every time a module becomes a follower. So after this timeout this module holds an election (on its own) and then there are 2 leaders...

It must be something with the configuration of the module. Do you know any more specifics about how the modules schould be set-up? (apart from the algorithm)

[l091]

Maybe my problem here is related to TTL of the multicast messages? gotosleep or election rpcs keep hanging around and therefore make synchronisation impossible...

[kbanks]

Have you changed the TTL settings from what they were in the original scripts?

[l091]

No I did not change the TTL parameter i left it at 5.

mcastRpc(1,5,'gotoSleep',sleepTicks)

But I was just wondering that 5 maybe to big TTL for a small network with 4 nodes that are only few inches positioned away from each other.

[kbanks]

5 is not too big, the default script TTL settings should be fine.

[kbanks]

I just loaded up four nodes with 2.2.12 (the latest BETA release) and put the original sleepyMesh.py script into all 4 nodes.

They formed a sleepy mesh with just one leader, and behaved normally. All of the nodes (as a single group) slept for 5 seconds, stayed awake for 2 seconds, slept for 5 seconds, etc.).

I forced different nodes to assume the leadership node by powering off the current leader, I never saw multiple "sleepy groups" form. When those nodes were later powered back up, they correctly rejoined the groups as followers.

I still think if your sleepy mesh cannot "form up", then you have a fundamental communications problem.

I'm leaving an overnight test running...

Note - We will be revisiting all of the app notes in the future, and revising them as needed to deal with any changes in SNAPpy, plus to deal with the new issues around multi-platform support. If there is an issue with "sleepy mesh" on SNAP 2.2, we will catch it then.

[l091]

They formed a sleepy mesh with just one leader, and behaved normally.
...

Maybe you can send me the configuration settings of your nodes? I left mine factory default settings. I tried everything you suggested in fact. Still no good results.

Maybe there is only one or two parameters wrong set...


I still think if your sleepy mesh cannot "form up", then you have a fundamental communications problem
...

How can I verify if there is a communications problem? I really believe that the symptoms of my failing sleeping mesh like you say must have trouble communicating. Is it possible that in my evaluation kit there are 'bad' modules?

[kbanks]

Maybe you can send me the configuration settings of your nodes?

I'm at the factory default settings except for my channel and network ID. With multiple developers running their own private networks, we can't ALL be on channel 4, Network ID 0x1C2C. I'm on channel 7, Network 0xFADE if you want to exactly match my setup.

Is it possible that in my evaluation kit there are 'bad' modules?

It's unlikely. Modules are tested over-the-air on our factory test station, if their radios were bad they would not "hear" the test commands, and would automatically fail the test.

Try using the example script LinkQualityRanger.py in different pairs of units, and see if they all seem to be able to hear each other well.

Notice I said "different pairs"... LinkQualityRanger is meant to be run in only two units at a time, you will get confusing results if you run it on more than two units simultaneously. (Just erase it from each unit when you are done with it.)

[l091]

Just to be sure I provide you with the information of my modules:

200101.01C
WO#
90324480 -> *83

FCC ID:U9O-RFET
IC: 7084A-RFET

I will try the linkquality tests later. I will keep you updated.

[l091]

The linkqualityranger script works perfectly between all my modules. I get good quality readings at different distances.

I'm really getting out of clues, I am exactly following your instructions and those from the application note. I tried both notes 001 and 003 and none of them gives me good result.

[l091]

Maybe you can describe exactly what steps you took to get this script working? Are you sure you sleepyMesh.py is the same as mine?
Maybe it is not working because I do not have the boards and I am only reading ledstates (awake, asleep).

I have reset all factory nv params and verified that my nodes are the latest firmware version 2.2.12 debug.

I must have missed a crucial step, maybe the same one every time again and again...

[kbanks]

Are you sure you sleepyMesh.py is the same as mine?


There's a good question. I will attach mine (straight from my Portal\snappyImages directory). You can take a look and see.

I didn't follow any special procedure. After I loaded up the scripts, they were all in sync. I also did several tests where I just power-cycled the entire group, and they re-formed correctly a few seconds after startup (they show "L?" on their displays while they are deciding who will be in charge.)

You mentioned LEDs... are you not trying these demos on boards with seven-segment displays?

[l091]

You mentioned LEDs... are you not trying these demos on boards with seven-segment displays?

I connected some leds directly to the modules, so I can see it blinking while awake and no leds while sleeping. Different numbers of leds light up for the different states of the node (L,F,L?).

[l091]

I'm leaving an overnight test running...

How was the test result?

[kbanks]

My sleepy mesh behaved itself (one group, all in sync).

Also, yesterday we had a power-blink, and the group correctly reformed after that.

What results do you get with just two nodes?

[RoSz]

Hi I091,

Did you have any further luck with the sleepy mesh synchronization?
We suspect that some of the problems we also are facing is due to that the messages are not received by the nodes, and that is why new elections takes place now and then... But the big problem for us is that the leader seems to be awake after the followers...