Goal
The original motivation for the tool stems from a WSN deployment we are pursuing in collaboration with biologists studying the social behavior of wildlife. Asked to design a WSN working in the forest, we faced the question of how wireless communication behaves in such an environment, considering factors like trees and foliage, as well as intense weather conditions such as snow. Moreover, we needed to test links in a network composed by also by mobile nodes. Using a wired infrastructure to coordinate such tests would be definitely not feasible. Therefore, we have built TRIDENT, which allows experimenting "in the wild" with nodes that might be freely placed or moving, and might be left unattended for several days. To reduce the burden of running tests in the wild, all interactions with the network can be done wirelessly, including node configuration, experiment status check and downloading of the collected measurements.
Description
TRIDENT covers the entire experiment workflow, from planning the experiment to presenting the results in a graphical or machine-readable form. The tool relies on the local non-volatile (Flash) memory of the devices to store the experiment parameters and collected measurements. Results are retrieved from the nodes over-the-air or using a USB connection. This page presents a brief description of the tool, a more thorough one can be found in TRIDENT: In-field Connectivity Assessment for Wireless Sensor Networks.
A TRIDENT experiment consists of a sequence of rounds, each characterized by a set of parameters. These parameters include the radio channel and transmit power, number of messages sent per node and several timing parameters. Each node can be configured to behave as a sender or just listener.
The tool measures properties of communication links at the physical layer by having the nodes transmit messages in round-robin to avoid collisions, and record received packets. Depending on the hardware platform in use, the nodes record several metrics associated with transmitted and received packets, e.g. RSSI, LQI and noise floor. The noise floor is an RSSI value registered right after the packet transmission or reception. This information is stored in persistent memory, either individually per packet or aggregated per test round. Moreover, on TMotes, the environmental properties might be logged periodically and the battery level might be recorded at the beginning and the end of each round.
Typical workflow
 |
Test design.: The user designs an experiment defining node placement, radio channel, TX power, number of probe messages, timing of the probes (bursts or single shot), number of test repetitions and the type of logging (per-message, or per-round statistics). |
 |
Node configuration. Once the tests are designed, the experiment configuration is loaded onto the master node. |
 |
Test execution. Now the experiment can be started and the network might be left alone for the whole duration of the tests. During the experiment the data is stored in the persistent memory of the nodes. |
 |
Trace download. When the tests are done, the user retrieves the results from the nodes, over-the-air or via USB. The results are presented to the user in the graphical form. |
 |
Results and trace sharing. Finally, the experiment results might be exported to well-structured text files (CSV) or a data base. |
TRIDENT Components
Experiment planner
The "experiment planner" is a component allowing the user to define new experiments.
In-field assistant
With the help of in-field assistant, the operator can do all interactions with the network wirelessly: request the current status of the nodes, check the battery level, wake up and put nodes to sleep, configure the network, download the traces from the nodes, erase the flash or just passively sniff the running experiment. These wireless operations are currently supported only for the TMote Sky platform.
Results viewer
The results tab of the TRIDENT main window presents the experiment results in a convenient graphical form, so that the user can quickly review them.
The database
The main goal is to have a database allowing the storage of traces of experiments and sharing them. The database can be used to facilitate the communication between the various tools developed such as data collection and reporting component. One schema was defined to store the information about an experiment and its rounds and traces collected during the experiment. We store information describing the experiments, time and location, hardware platform used, node placement, rounds parameters, and collected traces: statistics, packets, environmental data from nodes and from data loggers or meteo station if available on site.