motes without direct connection do not keep up sending data

[ArcticSnow]

The motes that rely on other to relay their data to the Meshpi do not keep paste for sending data. We think that the relay motes xbee turn off too early to allow all motes on the mesh to send data. As power does not seems to be a major concern at the moment, we need to improve our network design to allow for "remote" motes have enough time to push their data.

Ideas:

• keep xbees on at least 40sec or more at every network loop
• specify relay stations for which the xbee remains on longer at every loop
• send meta frames about how many frames are in queue for sending
• use LIFO by default

[ArcticSnow]

Quick fix. I changed in the file program_network.cpp, line 166 to CR_DELAY(45000); // Keep the network open at least for 45s. Previously it was 8s

[jdavid]

you have not pushed that change I think

[jdavid]

About the LIFO queue.

Now we send the mote name only in the first frame to save frame size in the subsequent frames. Then in the Pi we add the mote name information to the frames that don't have it.

If we're going to use LIFO we will have to send the name in every frame, making the frames bigger, sometimes sending 2 frames when 1 was enough before.

I'm very strongly against using LIFO, as it makes everything more complicated in the Pi and the server. Troubleshooting would be much harder for instance.

[jdavid]

• send meta frames about how many frames are in queue for sending

Which is the point of this? It may increase network traffic, so degrade the network instead of improve it.

[jdavid]

Let me update the list, I've removed the LIFO and added the item from issue #57 :

• keep xbees on at least 40sec or more at every network loop
• specify relay stations for which the xbee remains on longer at every loop
• send meta frames about how many frames are in queue for sending ?
• bring the network action at the end of the loop

But I think we should instead do issue #70:

• run network and sample sensors in different loops

Also, I already made a change to improve the network, in commit 60d1d48 increasing the number of software retries to 2. Actually there're two kind of retries, software and hardware. Hardware retries are by default 10, so the number of real retries is 2 x 10.

[jdavid]

TODO list:

• bring the network action at the end of the loop (issue bring network action at the end of the loop #57)
• keep xbees on at least 40sec or more at every network loop
• run network and sample sensors in different loops (issue absolute time schedule #70 )
• specify relay stations for which the xbee remains on longer at every loop
• send meta frames about how many frames are in queue for sending

[jdavid]

Now it's possible to define the number of seconds the XBee will remain On, with the var xbeewait 0-255 command. The value 0 means use the default, which is 45s right now.

From the original description there're 2 things not done:

1. use LIFO by default
2. send meta frames about how many frames are in queue for sending

I'm strongly against LIFO, unless we've very good reasons to use it.

Since the original issue is maybe fixed now, I'm going to move this to To verify status, and will wait for feedback to continue.