Real deployment advice

Before real deployments there are several points to study:

• Test your final code for several days "in laboratory" before the final installation. This will help to discover hidden bugs in your code or possible error sources.

• In the testing process, rise the number of your cycles by decreasing the time to sleep to a few seconds (instead of sleeping 10 minutes, sleep 10 seconds). This way, the user can simulate many "virtual days" in few hours. Anyway, we suggest to simulate as much time as possible with the real sleep time.

• The final code is written and tests were successful. Alright. But did the developer consider things which could go wrong and did not happen (or could not be reproduced) in the performed tests? For example, it is highly improbable that an XBee module, once it is configured (normally in the setup() function), is mis-configured, but it could happen. A good way to prevent that can be to configure the XBee in every loop or after a certain number of loops. Really robust code works well not only in normal conditions, but also when strange effects happen. Be sure to add code to check if everything goes as planned; and if not, you should have an alternative piece of code for it.

• The use of the Watchdog feature is always recommended. This mechanism can save a Waspmote or Plug & Sense! unit if it gets stuck by restoring the normal operation.

• Another example for the tip above could be the strange possibility that the destination Meshlium is temporally unavailable (link down because of interferences? electrical supply fail?). In this case, frames sent towards it would be lost. In this case, you can write a piece of code to write in the SD card the frames which are not being received. Afterwards, you can go to that node and get the SD card in person. You could even write all the frames in the SD card as a security measure.

• It is impossible to know if 2 nodes will be in range or not by reading a map. There are so many variables: distance, obstacles, materials, weather, reflection, multipath effect,... The only way to know the best places to deploy nodes for a project are real tests: try the nodes on the field. Maybe the lab tests you performed said 'x' meters, but you will get other distance on the street.

• It is also difficult to know the life expectancy of the battery for each node in real life. Take into account that there could be retransmissions, high/low temperatures affect to the battery performance, batteries have a significant self-discharge rate, etc. All that makes that battery life estimations obtained in the lab may not suit with real deployments results. Consider a certain factor which divides the estimated life expectancy.

• In the final code which will be executed by the installed nodes, we advise to do the first 10 loops (for example) with a very short sleep time (seconds and not minutes). To do so, you can have a loop counter and place an if() to make a shorter sleep time if the loop counter is lower than 10. This practice enables the people installing the nodes to check in few minutes if the first 10 frames are arriving to destination correctly, which is a good sign (better than just 1-2 received frames!). If some incident may occur, they are still in place to take measures.

• You can also use the LEDs to signal important events inside those first 10 loops.

• For maximal robustness in final codes, the programmer may find interesting to experiment with the PWR.reboot() function. As a matter of fact, many code errors happen when the code has been executed many times, due to low-level, memory or weird microcontroller reasons. This is why it could be good to reset Waspmote in a software way when a certain number of loops have been executed. After the software reset, the microcontroller will be fresh to start again, just like in many electronic devices. It is not an elegant practice, but it could be an effective measure for your project.

• Anyway, the best way to get really robust and reliable nodes is to perform periodic hardware-type resets. This can be done using the hibernate sleep mode and is more effective than the process explained above. In practice, the hibernate function acts switching off everything in Waspmote (except the RTC) flushing all variables and processes. After hibernate, everything starts from 0, it is like pressing the physical reset button. This avoids possible problems due to bad programming or long-term microcontroller issues, etc: we can focus on just the first loop. Just remember hibernate is only available for Waspmote, but not for Plug & Sense!.