General advice

• Plan your project and divide it into the parts of Waspmote (or Plug & Sense!) you need to use. With "one part" we mean a feature (RTC, sleep modes, ...), a sensor (CO2, temperature, ...) or a communication module (802.15.4, GPRS, ...).

• Always go step by step. First, study one feature/sensor/module, read the manual, read the examples, experiment with the examples in the IDE and even play with all that Once you understand it, do the same with the next feature/sensor/module you need. Once you understand all the parts and you have working codes for all of them, then try to merge one code with another. Once they fit, add the following piece of code. At the end you will have the final code working, ready to pass the testing phase. Do not try to put all together from the beginning.

• "Keep it simple". Do you really need OTA operations? Do you really need interruptions? Any feature you are adding to your project will improve it, but bear in mind it will also add complexity, increasing the issues chance.

• The testing phase is crucial: for debugging tasks, we advise the use of the USB line, and not the communications module.

• Place as many debug messages as you need. This will help to know which part of the code (or which code line) is an error source. You can see it via the USB line, in the IDE's Serial Monitor. You can use logger programs (CuteCom or Hyperterminal for example) to save the serial monitor output or the packets sent to allow you analyze the information afterwards. You can also use the SD card to store logs, or even the EEPROM for very specific data.

• Related to the tip above, you can use the #ifdef + #endif flow instructions to enable (or not) an advanced and thorough debug mode, as done in some of our libraries (GPRS Pro or 3G).

• A global loop counter is very useful. It will say how many times the loop has been executed.

• Also, a frame counter is useful. It will say how many times Waspmote has built a frame (and how many times Waspmote has tried to send a frame). The number of received frames will be obviously equal or lower than the number of sent frames. Due to communication problems, some frames will never arrive to destination, but at least you will know they were sent.

• With the global counter and the frame counter you can get the packet loss rate easily and check the health of each RF link.

• Use the if() condition to control the code flow and make more efficient. For example, you will not want to send an SMS with the GPRS module if the connection to the GPRS network was not possible. You can build nested if() structures to do things only when you need to do it. Take a look to the API, many functions deliver 0/1 as an output to show if the execution was successful.

• In order to save battery, you may avoid sending frames in certain situations. Anyway, a good code will send frames always after a certain number of loops or after a certain time. This avoids the possibility of never sending frames, which could lead to the doubt "Is this node not working, or it is up but just does not send frames?".

• Never use functions or conditions which could be waiting forever. For example, any while() loop is suitable to be stuck because the exit condition is never satisfied. Instead of putting a single exit condition, add a second one with the OR (||) operator. This second condition can be a counter which is incremented in each while loop. This will help to implement a kind of timeout: "if this while loop was executed 100 times, then exit". A second strategy to avoid infinite while loops is to use break inside the while loop.

• If your code does something that you want to check, it advised to do it before the sleep part. This will avoid waiting for the sleep time to expire to see if you get the expected results/action. This means that the sleep mode should be always placed at the end of your code.

• We advise to use the RTC in almost any project, it is needed to set timeouts or alarms for the sleep modes. However, we suggest that the RTC time is considered in a relative way, and not absolute. That is to say, it does not matter if it is 07:27 or 15:28 inside one Waspmote; the important thing is that the sleep alarm will ring within 10 minutes. Time-stamping should be done in reception (Gateway's PC or Meshlium): time will always be more accurate there (internet time). Considering relative time avoids the need of setting the exact time before running a code. Also, bear in mind that if you reset Waspmote and you set the RTC time in the first initialization, then your will lose the exact time.

• The millis() function measures the execution time since Waspmote is turned ON. It can be very useful to measure how much time your functions spend carrying out their tasks (subtracting the value after something with the value before). It can be a sign of malfunction: if a loop normally takes 4 seconds to be executed and now it took 10 seconds... something could go wrong.

• You can use the LEDs to signal important events in the developing or debugging phase. LED signaling is not recommended for the final code since LEDs have a significant energy consumption.

• All the software system is Open Source, we are proud of that. The libraries are available for anyone who wants to study them and even modify them for a better performance. However, unless the developer is an expert in Waspmote and C coding, we do NOT advise to make changes in the libraries. That practice can lead to unexpected behaviours, data collisions, memory leaks and many other issues. We only recommend to use the official libraries created and verified by Libelium.

• As said all along the documentation, please remember to work with the battery always connected and charged. Always.

• You should attach the battery to Waspmote with a nylon clamp (and never remove it) to avoid broken battery cables.