3.

Approach

SNSL gives researchers the ability to collect soil data over long periods of time. Microprocessors,
wireless modules, batteries, and a data storage device are used to create the different physical setups. The
following sections describe the hardware and software systems comprising SNSL.

3.1 System Overview

In Figure 3.1, the final printed circuit board (PCB) layout of the collector node is shown. Everything
requiring any human interaction is located on this side of the PCB. The user of this product mainly needs
access to the batteries and the USB drive plugged into the VDIP, which can be seen in the figure. The
setup, power, and sleep switches, which can be seen in both Figure 3.1 and Figure 3.2, are used in the
initial setup of the network. Lastly the FTDI and PICKIT headers are shown on both PCBs and are used
when debugging or updating the code. Even though researchers do not physically interact with the
wireless SNAP modules, the modules are placed on the top of the PCB for better signal.

Figure 3.1: PCB Layout for Collector Node

Figure 3.2: PCB Layout for Sensor Node
The SNSL system incorporates two types of nodes that communicate together: a single collector node that
stores all of the data samples as well as controlling the wireless network, and multiple sensor nodes which
actually take the redox measurements. Each of these nodes collects data through the soil sensors and
sends that information to the microprocessor three times an hour. Then, once the wireless module
receives the signal to send the node’s data out, it wakes up the microprocessor and takes the data. Finally,
it transmits the soil data to the collector node before it gets the signal to return to a low power state. A
layout of the sensor nodes is shown below in Figure 3.3.

Figure 3.3: System Layout for Sensor Node

The second type of node is the collector node. Each system contains only one collector node. This node
transmits a request for data for each of the sensor node’s data samples. Once it receives every node’s
data, it transmits another signal saying the collection is done, putting the network and all of the sensor
nodes into a low-power sleep mode. Each node’s soil measurement is then saved onto the on board
storage device for later analysis. The layout of the collector nodes can be seen below in Figure 3.4.
 Figure 3.4: System Layout for Collector Node

3.2 Hardware Subsystems

The hardware components that are most important for our system are the microprocessor, wireless
module, and the persistent storage device. All of these subsystems are discussed in more detail later in
this section.

3.2.1 Microprocessor

The microprocessor is one of the most important parts of the SNSL system. For the sensor nodes, the
main job of the microprocessor is to accept the data and then send it out through the wireless module
when the collector node requests it. In the collector node circuit, the microprocessor must tell the
wireless module to send a request for data. Once this data is collected, the microprocessor pushes it to the
storage device to be saved. Since everyone in the SNSL group has experience using a PIC24 micro-
controller, the only choice was between different products in the PIC24 family.

The PIC24FJ64GA102 was chosen because of size and its low power state. Many other PIC24
microprocessors would have worked, but their size and power efficiency would not be as good of a fit.
3.2.2 Wireless Module

Table 3.1: Wireless Module Comparison

Advantages Disadvantages

Atmel A1281 [1] ● Up to 2.5 miles Line of Sight ● Programmed using C

● Lower cost ● Not as easy to program
● Lower overall current modules
● Processing power ● Lack of local resources

XBEE Pro [2] ● Low sleep current ● Communicate serially

● Online help ● Only 1 mile Line of Sight

Synapse RF100PD6 [3] ● Up to 3 miles Line of Sight ● Processing power

● Programming with Python
● Used in previous designs
● Touch-less script downloads

While reviewing wireless communication modules, our group discovered three possible modules that
could be used. The ones that were discussed include: Atmel A1281, Synapse RF100PD6, and XBEE Pro.
Each one has strengths and weaknesses that can help or hinder our project.

Atmel A1281 gives the benefits of a slightly lower cost, a significantly lower current during transmit,
receive and sleep modes, and much better processing power over the other two options. The Atmel
module also claims to have a signal that can reach two and a half miles in the line of sight, which is more
than enough distance for our project. Some of the downsides for the Atmel module are that they are not
as easy to reprogram as some of the other options. They must each be reprogrammed individually with a
physical connection, and for a large system, this would be very inconvenient. The actual programming
for the Atmel is also much more difficult because it is written in a complicated stack based C program.
Also no recent group that has included wireless modules in their projects has used Atmel modules, so we
have no personal resource for help [1].

The XBEE Pro is a module that many hobbyists choose when designing projects with simple wireless
communication; therefore, we would have many online resources to turn to for help with this technology.
XBEE also has one of the lowest sleep currents that we could find while researching different wireless
modules. One shortcoming of the XBEE is that the maximum line of sight distance is one mile, which
might not be strong enough in certain situations without using extra transmitters to extend the signal. The
most important drawback to the XBEE module is that to control it we would have to send all the
commands using serial communications [2].

The last module that was reviewed is the Synapse RF100PD6. This module is very similar in size and
shape to the XBEE modules, but its technical specifications are much different. This module has the best
wireless range that we could find in the 2.4 GHz range; Synapse claims a distance of up to three miles
when the transmitters have line of site to each other. The RF100PD6 modules are also very easy to
reprogram when updating the code. Users can click one button on their computers and wirelessly
transmit the new code to update their system, rather than having to connect to it via a programming cable.
Another advantage of using Synapse in our system is that all the programming for the wireless modules is
in Python. The major benefit of using the Synapse modules is that Dr. Reese has a basic structure already
setup before we would even start working on it. Because of this, many other senior design students have
used Synapse modules for their projects using wireless, giving our group references when problems arise
[3]. Because of these benefits, our final choice for the wireless module is the Synapse RF100PD6.

3.2.3 Persistent Storage Device

All the data collected while the system is running is sent back to the collector node to be stored on a local
storage device. USB drives, Secure Digital (SD) cards, and microSD cards were all considered for the
collector’s storage device. Table 3.2 shows the benefits and drawbacks of each option.

Table 3.2: Storage Device Comparison

Storage Type Advantages Disadvantages

USB/Flash Drive ● Standard interface on all ● Size

computers ● Power usage
● Examples from previous
semesters

Secure Digital (SD) Card ● Power Usage ● Difficult to write to

● Size

microSD Card ● Size ● Difficult to write to

● Power Usage

The SD and microSD cards both provide less power usage, however they are much more difficult to write
to and less common among computing platforms. The microSD is also much smaller than SD cards and
any USB drive, but even the few platforms that have the hardware to read an SD card do not have the
ability to read a microSD card without an adapter.

Almost all modern computer systems have at least a single USB port, thereby ensuring that nearly any
computer can utilize a USB flash drive without any additional adapters. Another major advantage of using
a USB drive is that other senior design groups have already used a module that handles read/write
operations to a USB drive. Unfortunately, USB drives are the by far the largest option in both the storage
device itself, as well as the interfacing module. It also takes substantially more power than either the SD
or microSD cards. However, these drawbacks are not enough to overcome both the interoperability of the
USB drive and the vast experiences of past senior design teams. As such, we chose the USB flash drive,
using the Vinculum VDIP1 interface as our persistent storage mechanism.
3.2.4 Battery

Each node in the SNSL network is powered by on-board AA batteries. Every sensor node uses two AA
batteries. However, the monitor node uses three AA batteries to provide the extra power needed for the
USB drive. Ideally, each AA cell can provide 1.5 volts, thereby providing 3.0 V for each sensor node and
4.5 V for the collector node. However, this output drops steadily as both the load on the battery as well as
its deployment time increase. As such, each device must be able to operate within a range of power
supply voltages. Table 3.3 below shows the operational voltages for each of the three primary
components of the SNSL network.

Table 3.3: Operational Voltages

Device Datasheet Voltage (V) Minimum Operational Voltage (V)

PIC24FJ64GA102 3.3 2.3

Synapse RF100PD6 3.3 2.3

Vinculum VDIP1 5.0 3.5

A key portion of the design for the SNSL network is to function for a substantial period of time with little
or no intervention by its operators. Part of this is a requirement that the batteries in the nodes last a
minimum of three months before replacement. Because the layouts of the collector and senor nodes are
unique with each node type having a different quantity of batteries, they must be considered separately
when calculating current draw and overall battery life.

It is necessary to determine how long each node will be active before calculating the power drawn by its
individual components. Because SNSL is designed to be scalable, the only way to determine how long the
nodes will be active is to consider how many sensor nodes are present in the network, as well as how
many network hops are required to reach each node. When polling a sensor node, the collector continually
attempts to contact the node until a timeout expires (the polling timeout mechanism will be discussed in
section 3.3). By using this timeout value as part of the calculation to determine how long the collector will
be active, a worst-case measurement of power is achieved. Formula 1 below shows how the number of
nodes, as well as the timeout value and number of network hops, determine the maximum wake time for
the collector. Formula 2 shows that the maximum wake time for the sensor node is equivalent to the
maximum wake time for the collector node.

𝑊𝑎𝑘𝑒𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝑀𝑎𝑥 𝑠 = 𝑝𝑜𝑙𝑙𝑖𝑛𝑔 𝑡𝑖𝑚𝑒𝑜𝑢𝑡 ∗ 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑕𝑜𝑝𝑠 ∗ 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠 (1)

𝑆𝑙𝑒𝑒𝑝𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝑠 = 3600𝑠 − 𝑊𝑎𝑘𝑒𝐶𝑜𝑙𝑙𝑒𝑐 𝑡𝑜𝑟 𝑀𝑎𝑥

𝑊𝑎𝑘𝑒𝑆𝑒𝑛𝑠𝑜𝑟 𝑀𝑎𝑥 𝑠 = 𝑊𝑎𝑘𝑒𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝑀𝑎𝑥 (2)

𝑆𝑙𝑒𝑒𝑝𝑆𝑒𝑛𝑠𝑜𝑟 𝑠 = 3600𝑠 − 𝑊𝑎𝑘𝑒𝑆𝑒𝑛𝑠𝑜𝑟 𝑀𝑎𝑥

It is important to note that the polling timeout is a user-modifiable value. As the timeout increases, the
nodes remain on longer and the power draw increases. Tables 3.4 and 3.5 below show the current
measurements for the collector and sensor nodes.

Table 3.4: Collector Current Draw Measurements

Component Sleep Current Draw (mA) Wake Current Draw (mA)

PIC24FJ64GA102 0.003 17

Synapse RF100PD6 0.039 62

Vinculum VDIP1 0.0 70

Table 3.5: Sensor Current Draw Measurements

Component Sleep Current Draw (mA) Wake Current Draw (mA)

PIC24FJ64GA102 0.003 17

Synapse RF100PD6 0.039 62

Analog Circuitry 0.0 22

To calculate the overall current draw as well as the resulting battery life for each node, the following
equations are used:

3600𝑠
𝑆𝑙𝑒𝑒𝑝 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝐷𝑟𝑎𝑤 𝑚𝐴𝑕 = 𝑇𝑜𝑡𝑎𝑙 𝑆𝑙𝑒𝑒𝑝 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ (𝑆𝑙𝑒𝑒𝑝 𝑇𝑖𝑚𝑒/ )
1𝑚𝑖𝑛

3600𝑠
𝑊𝑎𝑘𝑒 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 𝐷𝑟𝑎𝑤 𝑚𝐴𝑕 = 𝑇𝑜𝑡𝑎𝑙 𝑊𝑎𝑘𝑒 𝐶𝑢𝑟𝑟𝑒𝑛𝑡 ∗ 𝑊𝑎𝑘𝑒 𝑇𝑖𝑚𝑒/
1𝑚𝑖𝑛

8100 𝑚𝐴𝑕
𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝑆𝑙𝑒𝑒𝑝 𝐷𝑟𝑎𝑤 + 𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝑊𝑎𝑘𝑒 𝐷𝑟𝑎𝑤
𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟 𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝐿𝑖𝑓𝑒 𝑀𝑜𝑛𝑡𝑕𝑠 =
24 𝑕𝑟𝑠 365 𝑑𝑎𝑦𝑠 1 𝑦𝑒𝑎𝑟
∗ ∗
1 𝑑𝑎𝑦 1 𝑦𝑒𝑎𝑟 12 𝑚𝑜𝑛𝑡𝑕𝑠

5400 𝑚𝐴𝑕
𝑆𝑒𝑛𝑠𝑜𝑟 𝑆𝑙𝑒𝑒𝑝 𝐷𝑟𝑎𝑤 + 𝑆𝑒𝑛𝑠𝑜𝑟 𝑊𝑎𝑘𝑒 𝐷𝑟𝑎𝑤
𝑆𝑒𝑛𝑠𝑜𝑟 𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝐿𝑖𝑓𝑒 𝑀𝑜𝑛𝑡𝑕𝑠 =
24 𝑕𝑟𝑠 365 𝑑𝑎𝑦𝑠 1 𝑦𝑒𝑎𝑟
∗ ∗
1 𝑑𝑎𝑦 1 𝑦𝑒𝑎𝑟 12 𝑚𝑜𝑛𝑡𝑕𝑠
Table 3.6 shows the sleep and wake times in seconds per hour for both the collector and sensor nodes:

Table 3.6: Sleep and Wake Time Calculations

Node Type Sleep Time (s) Wake Time (s)

Collector 3511.8 88.2

Sensor 3511.8 88.2

Table 3.7 shows the current draw calculations and the total battery life calculations:

Table 3.7: Total Current Draw and Battery Life Calculations

Operating Mode Total Sensor Current Draw (mAh) Total Collector Current Draw (mAh)

Sleep 0.04 0.041

Wake 2.515 3.651

Battery Life 2.94 3.00

(months)

Just for simplicity and ease of reading, Table 3.8 below shows all of the assumed and default values used
to calculate the battery life for each node type:

Table 3.8: Default and Assumed Values for Calculations

Collector Battery Capacity (3xAA) 3 x 2700 = 8100 mAh

Sensor Battery Capacity (2xAA) 2 x 1100 = 5400 mAh

Number of Network Hops 7

Total Number of Sensor Nodes 14

Polling Timeout Value 300 ms

3.2.5 Soil Sensors

Every sensor node contains nine soil sensors connected to the microprocessor. These soil sensors are
used to collect soil redox and temperature levels. Data is collected here at a rate of three times per hour to
show the different levels in redox and temperatures at all different times, temperatures, and precipitation
levels.
3.3 Software Subsystems

The software subsystems, on a general level, consist of wireless communication, microprocessor

functionality, and persistent data storage. The following sections elaborate more on each individual
section.

3.3.1 Synapse Software

The Synapse wireless modules are the primary subsystem in the SNSL network. There are two pieces of
technology that factor into the usability and maintainability of the wireless modules. The first is the
Synapse developer tools. These pieces of software allow the developer to easily control, debug, and
monitor all of the nodes in their network as well as allow the programming of the nodes wirelessly,
without having to physically access the module. Additionally, the Synapse tools include a utility for
monitoring and recording network traffic. This is essential for development and debugging as the designer
can directly monitor what data gets sent to each node.

The second piece of technology is the Python script that runs on each wireless module. By using Python,
these scripts can be easily and quickly developed and deployed without the need of a separate compiler or
IDE. These scripts manage all of the mesh maintenance actions as well as processing data coming from or
being sent back out to the PIC.

Maintenance of the mesh is divided into three sections: leader election, sleeping and waking. These
operations are controlled solely by the wireless module, and function without any interaction with the
PIC. Once powered on, the mesh cannot directly being its cycle of sleeping and waking. This is because
there must be one node in the network that is in control, or “leads” the mesh, telling all the nodes to sleep
or wake at the correct times. To select this leader, the mesh enters a state of election.

There are specific factors that determine whether a node can act as mesh leader or not. The collector node
is required to be the leader when it is present. However, when it is not, certain sensor nodes can act as
mesh leader. Each sensor node has a hardware switch, set by the user, that allows the network to know if
it can be a leader or not. When deployed, a minimum of two sensor nodes must be leader-eligible so that
the mesh always has a leader.

During the election process, the collector node and any leader-eligible sensor nodes broadcast their
addresses to the mesh. The scripts are written such that the node with the address closest to zero is
selected as leader and takes control of the mesh. To guarantee that the collector is elected as leader when
it is present, its script is configured such that it always broadcasts an address of \x00\x00\x00 during
election, regardless of its actual physical address. Figure 3.5 below shows the exact steps of the election
process.
 Figure 3.5: Mesh Leader Election

Once a leader is elected, the mesh enters its normal operational mode of sleeping and waking every 20
minutes. When the mesh is asleep, the other components on each node are also asleep, including the PIC.
Once the mesh leader wakes the mesh, a signal is sent to the PIC, waking it up.

When the collector node wakes up, it broadcasts a message to the rest of the mesh telling it to remain
awake. This is a safety measure to prevent the mesh from going back to sleep before all of the sensors
have been polled. Once the wireless module confirms that the mesh is held awake, the collector begins to
poll each sensor node sequentially. A message is sent from the collector to the specified sensor via the
mesh to return the current data reading. The sensor replies, along with a message notifying the collector
of any other data samples that it has. If there are additional readings, the collector continues polling the
same sensor until it no longer reports additional readings.

Once all of the sensor nodes have been polled, the collector broadcasts a message, putting all sensor
nodes to sleep until the next polling interval. Figure 3.6 below shows the exact steps of the polling
process:
 Figure 3.6: Polling

To facilitate communication between the PIC and wireless modules, as well as communication between
the collector and sensor, a set of data packets is defined. The structures of these packets are defined below
in Figures 3.7, 3.8 and 3.9:

0x1E Packet_Length (1) 0x01 0x00 TTL (1) 0x02 Function_Name (var)
Figure 3.7: Broadcast Packet Structure (Type 1)

0x1E Packet_Length (1) Node_Address (3) 0x03 Message to PIC (var)

Figure 3.8: PIC Data Packet Structure (Type 2)

0x1E Length 0x04 Remaining Timestamp Temp Redox Vref Node Name
(1) Polls (1) (6) (10) (8) (2) (12)
Figure 3.9: Polling Data Packet Structure (Type 3)
Packet type 1 is used by the collector to keep the mesh awake during polling. This is a safety precaution
so that the mesh will not sleep before polling is complete. When the packet is received by a wireless
module, it immediately executes whatever function is contained in the Function_Name field. This
function is not executed by the module that sends the packet. If it is desired that the packet be executed by
the sending module, additional code must be written in the Python script to handle this.

Packet type 2 is used by the wireless modules to forward data to the PIC. This packet is not a broadcast
message, so it requires the physical address of the destination module. Once received by a wireless
module, the contents of the PIC message field are transmitted immediately to the PIC. The collector uses
this packet to poll each sensor node, telling the PIC to respond with its current data sample.

Finally, packet type 3 is the data packet sent from the sensor nodes back to the collector when polled.
Once received, the entirety of this packet is forwarded on to the PIC by the wireless module. The structure
of this packet is of particular note because of the fields it contains and is described below.

Table 3.9: Polling Data Packet (Type 3) Description

Field Size (Bytes) Description

0x1E 1 This is the packet header, shared by all packet types.

Length 1 Packet length not including the header and length fields (Max 40B)

0x04 1 This is the packet type identifier. It is used by the wireless module to
determine how to handle the packet.

Remaining Polls 1 This value tells the collector how many data samples the sensor has
stored (Max 5) that have not been collected yet.

Timestamp 6 Time that the data sample was taken. (MM/DD/YY HH:MM:SS)

Temp 10 Temperature readings from each of the 4 soil sensors as well as one
additional ambient sensor.

Redox 8 Soil redox potential readings from each of the 4 soil sensors.

Vref 1 This is the reference voltage used to take the redox readings.

Node Name 0 - 12 This is a 12 character user-defined name for the sensor node (not
required)

3.3.2 PIC24 Code

The PIC24 microprocessor has varied functions in both the sensor and collector nodes. In both nodes, the
microprocessor relies on the Synapse wireless modules to know when to sleep and wake, as well as
provides communication between the sensors and collector.

The sensor nodes contain the soil and temperature sensors which acquire the data that is transmitted
wirelessly to the collector node for persistent storage. The microprocessor, along with some analog
circuitry, is responsible for taking the required measurements and storing them until the collector retrieves
the data. Each data sample consists of the following pieces: a timestamp of when the sample was taken,
four soil redox measurements, five temperature readings (one for each redox value and one ambient
measurement), the reference voltage used by the PIC24 analog to digital converter (ADC), and the 12
character node name. This measurement occurs immediately after the wireless module wakes the PIC.

The collector node’s PIC24 acts as a communication bridge between the wireless module and the USB
storage drive. The PIC24 is responsible for polling the sensor nodes and then formatting the responses
into a human readable state before writing it to the USB drive for persistent storage.

The polling process begins as the PIC24 tells the wireless module keep the mesh awake. Once the
wireless module broadcasts this message to the mesh and replies back to the PIC24, the list of sensor node
addresses is read from the USB drive. This list can be updated at any time when the collector is not active,
so that sensors can be added and removed from the SNSL network without affecting the rest of the
network.

In addition to the list of sensor nodes, a count of every time a sensor fails to respond to a polling message
is also read in from the USB drive. This is a mechanism that allows SNSL to stop attempting to poll a
sensor that is no longer responding but is still in the sensor node list.

As noted in section 3.2.4, SNSL employs a timeout system to prevent the collector from wasting too
much time polling unresponsive nodes. A default value of 300ms per network hop is used unless
otherwise changed by the user. If, for any reason, a node fails to respond to a polling request and the
timeout expires, the number of response failures for that node is incremented and the next node in the list
is polled. The next time the mesh wakes and polling begins, the failure count for each node is compared
to a failure threshold value. If the failure count is higher, the node is not polled at all, and the PIC24 polls
the next node in the list. This threshold value is also modifiable by the user.

Finally, once polling is complete, the PIC24 tells the wireless module to return the mesh to its normal
operation, turns off power to the USB drive, and then goes to sleep.

3.3.3 VDIP

This subsystem essentially stores the information gathered from each sensor node. The information is
transmitted to the collector node where the VDIP is physically stored. Data is then stored to a USB drive
connected to the VDIP module on the collector node. The information stored on the USB is easily
accessible for a user not familiar with the technical aspects of the project. The files are stored in a .CSV
format so that they are interoperable with most computer software spreadsheet programs. The VDIP
basically provides a way to easily store and transfer the necessary data in an organized manner to
researchers.
3.3.4 Usage Cases

The core of the system is the collector node, which basically controls all the procedures. These
procedures have a certain order in which they should be used. Figure 3.10 displays when each process
should run and the ideal communication between the microcontroller and the wireless on the collector
node along with the exchanges between the collector and sensor wireless modules.

Figure 3.10: Sunny Day Usage case for SNSL

Under unfavorable conditions, the collector node might become unresponsive for a variety of reasons. If
this occurs, one of the eligible sensor nodes becomes the temporary leader. After becoming the
temporary leader, it acts as the collector node did; however, it does not record data. It simply serves to
maintain the mesh without recording the data. This is demonstrated in Figure 3.11.

Figure 3.11: Rainy Day Usage case for SNSL

 References
[1] (2010, October 1) Synapse Wireless Inc. [Online]. Available: http://www.futureelectronics.com/
en/technologies/semiconductors/wireless-rf/rf-modules-solutions/802154-zigbee/Pages/7782840-
RF100PD6.aspx

[2] (2010, October 1) MeshNetics [Online]. Available: http://www.adaptivemodules.com/assets/File/

zigbit_amp_module_product_datasheet.pdf

[3] (2010, October 1) SparkFun [Online]. Available:http://www.sparkfun.com/commerce

/product_info.php?products_id=8768

[4](2010, October 12) IEEE 802.15.4. [Online]. Available:

http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf