Group 169
From ECE Department Wiki
Contents
|
Members
- Mike Schmitz
- Joe Schneider
- Rio Mascarenhas
- Dr. Katti
Project Files
Background
The United States alone experiences somewhere between 6 and 33 million cases of foodborne illnesses each year [1]. Safe food is therefore an important business for the world. One way in which the quality of food is compromised is by storing food in improper temperatures, both during transport and while awaiting consumption at a grocery store or in a domestic refrigerator or freezer. If food is not stored safely, meat or milk can spoil, frozen items can melt, and pathogens have the opportunity to grow to unsafe levels.
On another topic, wireless networks are a relatively recent innovation. These networks allow a number of devices, which for this report will be referred to as “nodes”, to communicate with each other over radio, removing the need for bulky cords necessary in earlier days. These networks are now being implemented in large numbers in the form of wireless local area networks (LANs) in the computer industry, as well as in sensor applications, on which this document focuses.
Sensor networks allow the remote collection of data without intervention from the user. This allows the measurement of stimuli in harsh, remote, or hard-to-reach locations. Sensor networks benefit from a wireless implementation in that this removes the need for bulky or expensive wires and allows the mounting of sensors in otherwise unfeasible locations such as on a rotating or flying device.
It has been found that there are generally two topologies used to implement a network of any kind: client-server and peer-peer connection. In a host-client network, multiple clients attach themselves to the host forming what is also known as a “star” topology. This type of network is in general use on the Internet, in which each computer is connected to a hub, switch, or router in the star formation. In a peer-peer network, each node of the network has the ability to connect to any other node, resulting in a “mesh” topology. Both topologies are used depending on application [2].
Problem Description
Because of the safety and liability issues involved with the storage of food, it is in the food providers’ best interest to closely monitor the temperatures in which food has been stored and to quickly correct improper temperatures should they occur. Often the measurement of temperatures is done manually, which is time-consuming, tedious, and has the ability to introduce error into the readings. A more reliable alternative proposed is a network of wireless sensors to monitor these temperatures automatically.
Wireless sensor networks of the past have had a few problems. The range of the radio transmitters has placed a limitation on how close one node must be to another one. The radio transmission power must be balanced so as to have enough power to reach the next node while also using an acceptable amount of battery power to do so. If a wireless network was in a star formation with each node connecting to a host, all nodes have to be in range of the host to communicate with the network at all. Two nodes might be right next to each other but unable to communicate because one cannot connect to the host. This issue needed to be addressed, and the obvious answer from above is to implement a peer-peer network, in which each node can effectively communicate with every other node within range.
However, implementing a peer-peer network is not as easy as it may look. Imagine a string or line of sensors all within the range of just two other sensors in the network. The node on one end of the string cannot directly communicate with the node on the other end of the line, but it can talk to its neighbor, who can talk to its neighbor, and eventually deliver the message to its intended destination. A network of this sort is called a hopping network because messages can be communicated to nodes in the network out of their range by hopping on those nodes that are close by. This is an easy idea, but complex to implement. Complicated routing tables are necessary for nodes to know if there is a route to another node, and even then the node must know if that route includes itself and to whom it should transmit to continue the sending of the message. Now, imagine that the string of sensors has changed to a blob of sensors, all of which are mobile and may be in the range of many sensors. The problem suddenly just got a lot harder. Add to this the ability for the network to form itself without any outside information (called an “ad hoc” network), as well as the ability to add additional nodes at any time and have them completely assimilated into the network, and the problem suddenly explodes.
Functionality of the Device
The device proposed in this project will consist of nodes capable of forming themselves into a multi-hop wireless ad hoc sensor network. This device will also have the ability to connect to a temperature sensor and will be capable of returning the readings from the temperature sensor to a base unit acting as a data logger, as well as a handheld device which may roam the network. The temperature sensor will have the proper range and precision to allow a useful and reliable reading of the food storage temperature to be used to ensure safe temperatures were maintained during storage. If a node fails and therefore can no longer act as a router for the remaining nodes in the network, the nodes will be able to compensate by discovering another path. The handheld device will be capable of querying and displaying the temperature readings from a requested node. The base unit will periodically poll the nodes for temperature readings, record the readings, and offer a connection to a computer for downloading data for analysis and record keeping.
Requirements
The following is an overview of the needs that must be satisfied by the project.
- The network must constitute a wireless, self-organizing, ad hoc topology.
- The temperature measurement must be accurate in the range of at least 0º F to 41º F.
- Data collection must occur often enough to accurately record temperature fluctuations.
- Radio transmitters must operate through metal objects.
- Nodes must be resistant to the environmental conditions encountered in a freezer (e.g. presence of moisture and humidity).
- Nodes should be resistant to minor shocks and impacts.
- Nodes must be a relatively small size.
- Power consumption should be kept to a minimum to prolong battery life.
- Setup and operation of the product must be easy and user friendly.
- Base unit should be portable.
- Base unit will have an LCD to display the data.
- The base unit must interface with a PC for easy storage and analysis of the collected data.
- The user can set temperature alarm levels.
- An alarm will sound when the temperature is outside of the set range.
- The cost must be low enough to allow for an affordable large sized network.
Proof of Concept / Testing
Three sensor nodes and a portable base unit that can also interface with a computer will be built to demonstrate satisfactory operation of the device. Transmitting temperature data wirelessly between the three nodes and eventually to the base unit will test proper operation. This data will then be displayed on the LCD and computer interface. Setting unacceptable temperature limits will test the alarm function. The ad hoc network topology will be tested by collecting data from a sensor node that is out of direct communication range with the base unit. Limitations in lab facilities and budget constraints will prevent the project’s requirements to be fulfilled to the maximum extent. Discrete components will be used in the construction of the device, however smaller surface mount components could be used to reduce the size and power consumption of the sensor nodes and base unit.
Risk Assessment
There are many inherent risks involved with designing an ad hoc network. Furthermore, the purpose for the network, to monitor food temperatures, raises additional concerns. These risks, along with possible solutions, are explored below.
Crosstalk
Crosstalk is defined as undesirable signals created by the coupling between transmission circuits. This can occur in an ad hoc network if two or more nodes in radio range of one another try to transmit data simultaneously. Their data streams will mix and produce a radio signal that is unusable by the receiver circuit. The primary solution to this it to ensure that if the nodes must operate on the same frequency, they don’t transmit data when other nodes are communicating. One way to do this is to wait a random amount of time before transmitting, and then have the transmission time very small compared to the listening time. Another solution is to have the nodes listen for other transmissions, and then only transmit themselves when it is determined that no other nodes are currently transmitting.
Mobility
The sensor nodes and the portable base unit that constitute the ad hoc network have the possibility to move. This mobility means that certain nodes will not always be in communication range with one another, and data pathways will not always be valid. To prevent the break up of the network, new data pathways must be built when the old pathways are destroyed. This can be accomplished by either rebuilding the pathways before every data transmission, which can generate a large amount of traffic in the network, or the pathways can be rebuilt only when it is necessary, which increases the complexity of the protocol but does save on the number of necessary transmissions.
Overbroadcasting
Each data transmission is intended for a particular receiver, however many nodes may receive the data. Therefore, the nodes must be able to identify which transmissions are intended for them and which they can ignore. A simple way to solve this problem is to assign each node a unique ID number. The transmitted packet will then contain the ID number of the node that is the destination for the transmission. Then any node that receives the data can check the included ID number and then process the data accordingly.
Environmental Concerns
The purpose of the sensor network is to monitor the temperature of refrigerators and freezers to ensure safe levels for food storage. For this to occur, the sensor nodes will be placed inside the cold storage unit and will thus be exposed to harsh conditions such as freezing temperatures and moisture contact. In order to guarantee proper operation, all sensor nodes must be able to withstand the environmental hazards either unprotected or through the assistance of protective packaging.
Detailed Block Diagrams
Both the nodes and the base unit involved in the network can be broken down in to logical sections, or blocks, which communicate with each other creating a functional unit. A fairly detailed block diagram for both the node and the base unit are presented and described.
Node Block Diagram
The block diagram of a node is shown above. The block on the left represents the microcontroller, a PIC16LF628, and associated discrete components to clock the microcontroller. The oscillator includes a crystal running at 4 MHz and two capacitors tied to ground. The microcontroller is able to communicate with the rest of the network by way of the RF transceiver, a RFM DR3000L. The transceiver is connected to the microprocessor through four lines: CNT0, CNT1, TX, and RX. The CNT0 and CNT1 lines are output only from the microcontroller, and are used to choose the mode of operation of the transceiver. Each CNT line is tied to VDD with a 10kΩ pull-up resistor. Modes of operation for CNT0:CNT1 are given in the table below.
| CNT0 | CNT1 | Mode |
|---|---|---|
| Low | Low | Sleep (low power) |
| High | Low | OOK (On-Off Keyed) transmit |
| Low | High | ASK (Amplitude Shift Keyed) transmit |
| High | High | Receive |
The transceiver is used in OOK (On-Off Keyed) mode for transmissions, as this is more power-efficient than the only other transmission option on the transceiver, ASK (Amplitude Shift Keyed) mode. The TX line is an output only line from the microcontroller, and is tied to the transceiver through a 3.3kΩ resistor. The resistor is used to limit the current to the transceiver, which in turn controls the amount of power with which the transceiver transmits. The TX line must be kept at logic low when the transceiver is in receive mode. The RX line is an input only digital line to the microcontroller, representing the demodulated signal received by the transceiver. The only other discrete component used for the transceiver is a 33kΩ resistor which can be optionally connected to pin 8 of the transceiver (the LPF_ADJ pin) to allow for up to 19.2 kbps data bandwidth. Without a resistor attached to pin 8, the transceiver can only transfer data at up to 2400 bps. This resistor changes the speed of the RF link by adjusting the characteristics of the built-in low-pass filter of the transceiver. Further information can be found in the DR3000 data sheet.
In order to simplify the hardware and code complexity involved with communicating wirelessly, the RX line is tied directly to a hardware USART included on the PIC16F628. This allows the microprocessor to sleep until the first byte of a packet is received, and additionally allows the processor to run other code while the rest of the bytes of the packet are clocked in. The TX line is not connected to the hardware USART, however, since the hardware USART idles at a logic high. Letting the TX line idle at logic high causes the transmitter to continuously transmit, which wastes valuable battery power. Instead, a software serial transmitter written to emulate the hardware USART is implemented. The idle high required by the hardware receiver is padded to the beginning and end of all transmissions, fooling the receiving node’s hardware receiver into thinking an idle high is being applied.
The temperature sensor, a DS1631, is connected to the microcontroller over a standard I2C two-wire bus. Both lines are tied to VDD by a 10kΩ pull-up resistor. The SDA line is a bi-directional line over which all data is transferred. The SDC line is a clock line controlled by the I2C master, which is the microprocessor. All address pins A0-A2 are tied to ground, resulting in an address of 0x90 after shifting the address left one bit as required by the I2C protocol. The DS1631 can convert temperatures with precision from 9-12 bits, with more bits requiring more time to convert. After the microprocessor requests that the sensor begin converting a temperature, it can determine when the conversion is done by polling the sensor and reading a flag bit. When the flag changes to represent a complete conversion, the microprocessor requests the value of the newly converted temperature, which is then transmitted to the microprocessor.
Base Unit Block Diagram
The base unit block diagram is shown above. The sections of the base unit block diagram which overlap the node block diagram, namely the microprocessor oscillator components and RF transceiver, will be omitted here. The one difference that should be noted here from the nodes is that the base unit microprocessor is a PIC16LF877 (or PIC18LF452). In addition to the components overlapped by the nodes, the base unit incorporates some components for data storage, accurate time keeping, and data input / output. Furthermore, all components on the base unit operate at 3V except for the LCD and RS-232 converter. The lower operating voltage helps to reduce power consumption.
In order to store data colleted from the network, the base unit includes a 32 kilobyte EEPROM, the 24LC256. This unit is connected to the microcontroller through the standard I2C two-wire bus. This is the same bus used to interface to the temperature sensors in the nodes, and thus both the SDA and SDC lines in the base unit require the same 10kΩ pull-up resistors that the nodes required. All address lines A0-A2 are tied to ground, giving the EEPROM an I2C address of 0xA0 after shifting the address left one bit as required by the I2C protocol. The SDA and SDC lines are tied to the built-in I2C hardware on the microprocessor. The microprocessor in the base unit, as in the node, acts as the I2C master, providing the serial clock on the output-only SDC pin, and receiving and sending data over the bi-directional data line, SDA.
The real time clock is used to accurately keep the time at which temperature readings are made. These times are then stored along with the temperatures in EEPROM. The real time clock used, the DS1302, requires a 32.768 kHz crystal to keep the time accurately. The time is read and set via a two-wire serial bus. The SCLK line is driven by the microprocessor to provide the serial clock, and the I/O line provides a data path between the RTC (real time clock) and the microprocessor. The RST line is an active-low line which is left at logic low while not accessing the RTC to save battery power. The RST line must be driven to logic high in order to communicate with the RTC.
The matrix keypad, used for data entry in the base unit, is connected to the microprocessor through 8 lines, 4 of which represent the 4 rows of the keypad, and the other 4 of which represent the 4 columns of the keypad. The microprocessor reads the keypad by driving each column line high individually, while keeping all others at logic low. By reading the row lines as inputs when a particular column is driven high, the microprocessor can deduce which key is being pressed. The microprocessor scans through the columns whenever input is expected, waiting for a key press to be detected.
The 20 character x 4 line LCD provides a means of communicating retrieved data from the network to the user. It uses a standard Hitachi 44780 compatible driver IC, and is controlled in the same manner as other LCDs implementing a 44780 driver IC. As many LCD’s require, contrast control must be connected to the module with the use of a variable resistor. The LCD module used requires 5V to operate properly, and since the microprocessor, which operates at 3V, needs to drive the lines of the LCD module, a transparent latch buffer was placed between the LCD modules and the microprocessor. The transparent latch buffer, a SN74HCT573, translates the 3.0V logic high of the microprocessor to the 5.0V logic high the LCD module requires. The latch buffer is not required to operate in a transparent mode, but does so since the active-low OE (Output Enable) is tied to ground and the active-high LE (latch-enable) is tied to high.
The RS-232 level converter is a standard MAX232N IC. This chip converts the idle-high TTL serial signals of the microprocessor to industry standard EIA-232 levels for communicating over a serial link with a PC. The MAX232N generates the negative and positive voltages required for EIA-232 by implementing a charge pump, which requires several capacitors. Additional capacitors are added to the circuit to filter the generated voltages, as well as the power supply to the IC. Furthermore, a voltage divider is required on the PC_RX line between the MAX232N and the microprocessor to lower the voltage from 5 V to 3 V to comply with the microprocessor input specifications.
The purpose of the alarm is to alert the user of collected temperatures that fall outside of a user definable range. The actual alarm component has yet to be selected. Therefore, the nature of the input signal is indeterminate. Ideally, an alarm will be selected that requires only a steady rather than oscillating voltage to produce sound, thereby reducing microprocessor consumption.
Protocol
The network protocol determines the format of all transmissions, the method of communication in the network, and the speed of the system. Therefore, proper protocol selection has a direct impact on the functionality of the network. Several current protocols were analyzed in Chapter 2 as means to determine the best possible solution for the project. However, none of these seamlessly matched the necessities of the proposed network. For this reason, a custom protocol loosely based on the Direct Source Routing (DSR) protocol was designed to meet the distinct needs of the project while keeping power consumption to a minimum.
For data to pass throughout the network, routes from the base unit to each node must be determined. The type of packet responsible for route identification is called Route Discovery. Once useable routes are identified, data can pass through the network without searching for appropriate routes. The packet used for this type of communication is called Route Aware. The general format of a packet is shown below. Each portion of the packet will be described in detail.
Packet retransmissions are also discussed. Methods are proposed for handling dropped packets, out of range nodes, and incorrect route information. Finally, cross talk and packet collisions are discussed along with the best methods for prevention.
Protocol Format
Both Route Discovery and Route Aware packets use the same general format shown in Figure 4.4.1.1. Each section of the packet is further dissected.
| Preamble | Address | Packet Code | Checksum | Length | Route Bytes | Data Bytes |
Preamble
The preamble is necessary for transmitter/receiver USART synchronization and receiver initialization. The first part of the preamble must consist of no less than 10 high bits, without any start or stop bits accustomed to USART communication. This causes the receiver’s USART to reset and therefore perceive the next high to low transition as a start byte. The rest of the preamble consists of 3 bytes with the binary value “01010101.” These three bytes are sent with the normal start and stop bytes and are necessary to charge the capacitor in the data slicer of the receiver to a specific level for optimum noise rejection during packet transmission. The three identical and consecutive bytes are also used to key the receiving node on the beginning of a packet transmission.
Address Byte
The address byte identifies the destination of the packet and the type of packet being transmitted. The most significant bit of the address byte is set if the packet is for Route Discovery, and it is cleared if the packet is for Route Aware. The lower seven bits are used to identify the address of the destination node. Thus, the protocol can accommodate 127 nodes and one base unit. If the packet is of type Route Discovery, the address contained in the address byte is the address of ultimate destination for the Route Discovery packet. On the other hand, the address byte identifies the next node in the included route if the packet is of type Route Aware. Two example address bytes are shown below.
- Route Discovery to node 3: 10000011h
- Route Aware passing through node 11: 00001011h
Packet Code Byte
The packet code byte is necessary to prevent the flooding of the network with Route Discovery packets. By definition, a Route Discovery requires every node receiving a Route Discovery packet to update the packet’s route cache with its own address and then retransmit the packet. However, this could create infinite communication loops which would clog the radio frequency and drain power. The packet code prevents this by including a random number in the packet to serve as a packet identifier. Therefore, if a node receives a Route Discovery packet but the packet code is identical to the previous packet code it received, the node will ignore the Route Discovery and not retransmit the packet.
Checksum Byte
The checksum byte is used for error detection in the packet. The checksum equals the exclusive- or of all bytes in the packet excluding the preamble and the checksum byte itself. The value of the byte is calculated by the transmitter, sent with the packet, recalculated at the receiver, and compared. If the checksums do not match, an error occurred in communication, and the receiver will reject the entire packet.
Length Byte
The length byte is necessary for the receiver to identify the number of routing addresses and data bytes contained in the packet, and the total length of the packet. The highest four bits of the length byte indicate the number of data bytes in the packet, anywhere from 0 to 15. Likewise, the lowest four bits of the length byte indicate the number of addresses contain in the route cache of the packet, anywhere from 0 to 15. With this information, the total length of the packet can be calculated as the sum of the address bytes in the route cache, the data bytes, the 4 overhead bytes, and the three bytes in the preamble.
Route Bytes
The route bytes comprise the packet’s route cache. During a Route Discovery, the route cache is where a relaying node would add its address, and thus build a route structure for the receiving node. For a Route Aware, the route cache contains the addresses of the nodes the packet must follow to reach its destination.
Data Bytes
The data bytes are the reason for the packet in the first place, to transfer information. Any type of information can be stored in this location, up to a maximum of 15 bytes.
Route Discovery
When the base unit needs to initiate communication with a given node, it first searches its memory for a suitable route. If no route is found or if the stored route no longer works due to an ever-changing network configuration, the base unit must generate and transmit a Route Discovery packet. The purpose of this packet is to travel throughout the entire network, collecting route data in the process, until it reaches the intended node. Upon reception, the desired node will analyze the collected route data and generate a Route Aware packet using the collected route data and, at the same time, append any necessary data. This packet will propagate through the network, passing only through the nodes specified in the route data, until it reaches the base unit. The base unit can then analyze the received Route Aware packet and store the included route data in memory. The base unit now has a working route to the given node. Any included data in the packet is also available for the base unit’s use.
Route information is collected by the Route Discovery by having every node receiving the packet modify it. When a node receives the Route Discovery, it first checks the address byte to see if it is the intended destination of the packet. If it is not, the node must update the route bytes. It does this by inserting its own address before the first route byte in the packet and incrementing the length byte.
Route Aware
Once the base unit acquires and stores to memory a working route to a node through the use of a Route Discovery, it can communicate to the node using the other type of packet called Route Aware. The benefit to using a Route Aware is that the packet already contains the route information necessary to directly deliver the packet to the intended node, whereas a Route Discovery would be transmitted throughout the entire network. Therefore, a Route Aware requires fewer transmissions thereby conserving power and reducing unnecessary noise in the network.
Likewise, a node can generate a Route Aware packet destined for the base unit. However, since nodes do not store route information in memory, a route back to the base unit must be collected from elsewhere. The easy solution to this is to use the route information contained in the Route Discovery or Route Aware packet received by the node from the base unit.
Packet Retransmissions
When the base unit initiates a Route Discovery, it has no way of knowing if the intended node is in range or even operational. Therefore, in order to establish a route in an acceptable amount of time, the base unit waits a predetermined length of time to receive a Route Aware packet in response to the generated Route Discovery. If no Route Aware is received in the allotted time, another Route Discovery is generated with a new packet code. This process is repeated a finite number of times. If, after several attempts, no Route Aware packet is obtained in reply, the base unit will conclude that the destination node is out of range or is not functioning properly. The base unit will cease all attempts to build a route to the node. However, because the node may later come in range or online, the base unit can try to establish a route again at a later time.
The same is true for Route Aware packets. When the base unit generates a Route Aware packet, it has no way of directly knowing if the designated node received the packet. Therefore, when the desired node receives the Route Aware packet, it must generate another Route Aware packet in response destined for the base unit. When the base unit receives this packet in response, it knows the node successfully received the original packet. Repeated attempts by the base unit similar to the methods used for Route Discovery to establish communication are implemented as well. Furthermore, because packets can become lost or corrupted anywhere in the network, the intended node may actually receive the Route Aware packet without the base unit receiving a Route Aware packet in response. Therefore, a drawback of this technique is that the node may receive the packet more than once.
If a Route Aware packet it being used by the base unit to establish communication with a node and it proves unsuccessful, the problem may be incorrect routing information. To solve this problem, the base unit can revert to using a Route Discovery packet to build a new route to the node.
Packet Collisions
To prevent packet collisions and cross talk in the network, especially during Route Discovery, steps need to be taken to prevent nearby nodes from transmitting at the same time. Two methods have been implemented to address the issue. One method is to have the node wait a random amount of time before transmitting the packet. Therefore, when several adjacent nodes receive a packet simultaneously, they won’t all retransmit it at the exact same time. The other method is to listen to the transmitter radio frequency for interference. Once the node determines that no other nodes are transmitting in the area and no other noise is present, it can begin transmitting the packet. Furthermore, the higher the baud rate, the less time it takes to transmit a packet. This in itself will help decrease the amount of collisions.
Example Packet Communication
To further illustrate communication between nodes, a few examples of packet communication are provided below. These examples show the content of a packet at each hop along the network for a Route Discovery and a Route Aware packet. Packets shown are missing the preamble, which is still necessary, but omitted here for brevity.
The following diagrams follow the same convention set forth previously in this document, where thicker green lines represent primary paths for data travel, thinner red lines represent a secondary data path, and blue dots represent a node. These figures extend the previous legend to include packets, which are presented in a mono-spaced font and given in standard hex representation of each byte, each byte being separated by a single space. Each packet is drawn above the node which is transmitting, and the direction the packet travels across data paths is shown by arrows for nodes within range of the transmitting node. PC is used as a generic packet code as described above, and in cases where transmission requires the use of two packet codes, the two different codes are identified by a box around the second PC. Similarly, a generic checksum byte is given just as CS, as the checksum will vary depending on the packet code and other included data bytes.
These examples assume ideal network operation in which no collisions occur, i.e. no nodes attempt to transmit at the same time. It is important the reader realizes this idealized communication is valid for most transmissions, but may fail under certain circumstances.
Route Discovery from Node #0 to Node #1
In the figure above, a route discovery packet is shown being sent from node #0 to node #1. The Route Discovery is identified by the 8 in the first nibble of the address byte. The 1 in the second nibble of the address byte represents the final destination of the Route Discovery, in this case, node #1. The fourth byte shows the byte has 0 data bytes and 1 route byte. Finally, the fifth packet represents the route that has been accumulated so far, only consisting of node #0.
Node #1 receives this packet and sees that the packet is indeed destined for itself. Seeing this, it adds itself to the route, changes the header of the packet to represent a route aware packet destined for the node originating the route discovery, generates a new packet code, and appends the temperature data to the end of the packet. Both nodes #3 and #2 receive this packet, but quickly ignore it because the header represents a route aware packet which is not destined for either of them. Node #0, on the other hand, receives this packet, stores the route data contained within, and retrieves the temperature data stored within. At this point, the transmission is complete.
Route Discovery from Node #0 to Node #3
This is quite a bit more complex than the previous example since it adds both multiple hops and multiple paths to the example. In this example, a packet is first sent from node #0 to node #1 representing a route discovery for node #3, shown by the first byte 83. As in the previous example, there is only 1 route byte in this packet, representing the node originating the route discovery, node #0. Node #1 receives this packet, sees that it is a Route Discovery not destined for it, adds its address to the route information, and retransmits the packet with augmented route information. Node #0 receives this information, and ignores it because it recognizes the packet code as the same code it recently sent to node #1. Nodes #2 and #3, however, see this packet and act upon it differently. Node #2 sees the packet is not destined for itself and begins to change the packet to include itself as a hop in the route. Meanwhile, node #3 has received #1’s transmission, realizes this is a route discovery destined for itself, creates a new Route Aware packet containing the newly acquired route information, and begins a temperature conversion to include with the packet in the data bytes. More than likely, this temperature conversion will take longer than node #2 will take to retransmit, and node #2’s transmission will not be heard by node #3. However, node #1 will hear node #2 and will quickly ignore this packet, as it recognizes the packet code. Eventually, node #3 will finish converting the temperature and will finally send the Route Aware packet specifically destined for node #1 with a new packet code. This packet will be ignored by node #2 because it sees the packet is destined for node #1 only, represented by the second nibble in the address byte. However, node #1 will see the packet as a Route Aware packet destined for itself and will pass it on using the route information contained within the packet, setting the destination of the packet to node #0, the next node in the route. Nodes #2 and #3 will hear this packet, but will ignore it because they recognize the packet code. Node #0 will receive this packet, see it is destined for itself, store the route to memory for future use, and receive the temperature data contained within the data bytes. With this reception, the transmission is complete.
Route Aware from Node #0 to Node #2
The above figure demonstrates a Route Aware communication from node #0 to node #2. This example assumes that node #0 has previously acquired the correct route to node #2, and is now utilizing that information to create and send a Route Aware packet. In this case, node #0 creates a Route Aware packet destined for the first node in the route, node #1. This is shown in the first byte, 01. Node #1 sees this route aware packet destined for it and retransmits it, changing the destination to the next node in the route, which is node #2. Node #3 sees the packet and ignores it since it is not destined for itself. However, node #2 sees that the packet is destined for itself. Node #2 then generates a Route Aware in reply by flipping the route information in the packet, setting the destination of the packet to the first node in the return route, node #1. Node #2 also generates a new packet code for the packet and tacks on its temperature data to the data byte portion of the packet. Node #3 hears the transmission from node #2, but quickly ignores it because the packet is not destined for node #3. Node #1 sees the packet is destined for itself, changes the address byte to reflect the next node in the route, and retransmits it. Nodes #3 and #2 hear this transmission, and ignore it because the transmission is not destined for either of them. Node #0 hears the transmission and sees it is destined for itself. It can then use the data bytes of the packet to discern the temperature at node #2. With this, the transmission is complete.
Protocol Implementation in the Wireless Temperature Network
The constructed temperature network uses the ad hoc protocol in the exact format provided. When the base unit is instructed to collect a temperature from a given node, it first searches the microprocessor's internal EEPROM memory for a route to the node. The routes are stored in EEPROM so the base unit does not waste power and time rebuilding routes every time the base’s power is cycled. If the base unit finds a route in EEPROM for the given node, it constructs a Route Aware packet. Otherwise, it builds a Route Discovery packet. Once the necessary packet is created, the base unit waits for communication and interference on the network to cease by monitoring the receiver for any incoming data. At that point, the base unit will transmit the packet once, and wait for a preset amount of time, currently approximately one second, for a response from the given node. During this waiting time, the base unit will ignore all other packets it receives except for packets from the node it transmitted to.
If the base unit does not receive a reply form the node after the first attempt, the base unit will transmit another packet of the same type containing a new packet code. The base unit will once again wait for approximately one second for a response from the node. If communication fails again, the base unit will transmit a Route Discovery for the given node as the third attempt. Furthermore, if a route for the node was stored in EEPROM, it will be erased because it has proved ineffective in establishing communication. If communication fails for the third time, a Route Discovery will be sent one last time in attempt to reach the node. If a response is not received, the base unit will halt all attempts and deem the node a failure until further notice. Therefore, the maximum number of attempts at communication the base unit will make is four.
If or when a response is received, the base unit confirms the packet is correct by checking the packet code, checksum, and that only two data bytes are included. If the packet checks out, the base unit copies the routing information contained in the packet to the microprocessor's EEPROM for use next time communication with the same node is desired. The two data bytes, which contain the temperature from the node, are either converted and displayed on the LCD for viewing or copied to the external EEPROM on the base unit along with the date and time of reception provided by the real time clock chip for later access. The base allows large chunks of data to be displayed on the LCD or downloaded to a personal computer for analysis.
Base Unit Memory Management
The base unit contains EEPROM memory in both the microcontroller and external memory chip. These two sections of memory are used to store the collected temperatures from nodes, the corresponding times of collection, the routes to nodes in the network, the nodes from which to collect temperatures, and the minimum and maximum temperature alarm levels. Only the temperature alarm levels are stored in the microcontroller EEPROM, whereas everything else is stored in the external chip. The configuration of the external memory is shown at right. The Route Buffer contains the routes to all nodes the base unit has communicated with. The Node Buffer contains the nodes the base unit should request temperatures from while performing periodic collection. The Location Counters identify where in memory the next temperature reading will be stored and how many readings are stored for each node. The Collected Data block contains the temperatures and corresponding collection times for the nodes identified in the Node Buffer. When the memory is full, incoming temperatures for a node will replace the oldest temperatures for the same node. Therefore, the most recent temperatures are always available.
The external memory configuration is hard coded in the microcontroller for the maximum possible number of nodes and cannot adjust depending on the usage. For example, if less then the maximum number of nodes are polled during periodic temperature collection, part of the Collected Data block will remain empty. This is because part of the block is reserved for the nodes that are not being polled. It would be more efficient to use a dynamic memory configuration to utilize this wasted space, but the code overhead needed to do so would overwhelm the microcontroller.
PC Software User Interface
The base unit can be connected to a computer for additional functionality and logging capabilities. Using a Java application, the user can collect node temperatures on demand from an intuitive user interface, as well as setup a standard collection, save collected data to a file, print collected data, or even graph temperatures over time.
The main network monitor screen is shown above. There are three main panels: the node status pane in the upper-left, the status / log pane in the lower-left, and the control pane on the right.
The node status pane displays the results of the last communication with a particular node. Each node in the network is identified, and relevant information is given. As can be seen, node 2 has not been queried yet and so does not have any information available. Node 3, however, has been queried and has returned a temperature of 25.0 °C. The Java code can be easily modified to include more information with each node. The node status pane also allows the user to query any particular node at any time, by double-clicking on its information. The information in the status pane is then updated when the base unit receives a response from the node.
The status / log pane below describes the current status of the program and records actions taken by the program. The log in wireless network monitor shows that a base unit with firmware version 1.0 was first connected to the computer. Next, node 3 was queried by double-clicking on its information in the Node Status pane, shown by the “Retrieving temp at node 3” message on the next line. The last line in the log shows that a response has been received from the base unit and gives the information contained within the message.
The control pane is where network configuration is setup and where data is manipulated. The first button, “Node Collection…”, initiates a node collection similar to the node collection function available on the stand-alone base unit, including a customizable delay for periodic collection. The “Save Collected Data…” button allows a user to download data from the base unit and save it to a file for further analysis or record keeping. “Print Collected Data…” will allow the user to print out a summary or detailed logs of sensor data. “Configuration…” allows the user to add or remove node number from the network. “Disconnect!” stops all current operations to and from the base unit and closes all open log files.
The “Configuration…” button opens the configuration dialog window shown above and provides an easy way to add and remove nodes from the network. From this dialog, users can easily configure the network for the current set of nodes available, or a subset to focus on a particular group of sensors.
Functionality of the base unit PC software is still in its infancy, and will likely be expanded to include the capability to graph previous temperature readings, alert the user if temperatures drift beyond a predefined boundary, provide network route information for network reliability analysis, and set and check the clock.
Base Unit/Computer Protocol
The PC software that is associated with the base unit requires a standard method of data transfer in order to successfully communicate with the base unit. A custom protocol has been developed for this purpose. It dictates how a connection is initiated, what type of functions can be performed, and the format for all transfers. Before any function can be performed, the PC and base unit must first establish a connection. This is initiated by setting the base unit to connect mode.
Experimental Results
The project meets most if not all of the design specifications:
- It accurately measures the ambient temperature of the sensor. While a cheaper, more accurate and more responsive solution is a thermocouple or RTD, the IC temperature sensor was a cheap and fairly accurate solution.
- It collects a large number of temperature points under control of the computer or as a stand-alone device. An alarm sounds if any collected temperature falls outside a set range. A time stamp is stored with each temperature to aide in logging.
- It hops information across nodes if a given node is not directly within range of the base unit, hence the “ad hoc” part of this project.
Battery life and the wireless range are slightly lower than were anticipated at the beginning of the project, with the wireless range being the more worrying of the two. Also, there are some problems with and suggestions for the wireless portion of the project.
Specifications
Wireless Range: Ideal conditions ~30 feet Obstructions / noise ~10 feet Wireless Frequency: 916.5 MHz Wireless Modulation: OOK (On Off Keyed) Temperature range: -55 °C to +125 °C Temperature accuracy: accurate to ± 1 °C Max number of nodes: 127 Max number of hops: 16 Baseunit memory: 32k Power supply: Baseunit 9V battery or 9V DC input Node 2 x AA batteries Battery Life: Baseunit 72 hours Node ~360 hours, depending on frequency of usage Physical dimensions: (WxLxH) Baseunit 5 ½” x 7” x 2 ½” Node 2 ¼” x 3” x 1 ½”
