1
wildCENSE – Sensor Network for wildlife monitoring Project Mentor Dr. Prabhat Ranjan Professor DA-IICT, Gandhinagar Ph. D., University of California, Berkeley
Project Team Prabhat K. Saraswat B. Tech., DA-IICT, Gandhinagar
Ashish Kumar B. Tech., DA-IICT, Gandhinagar
Swetha Polana B. Tech., DA-IICT, Gandhinagar
Amit Singh B. Tech., DA-IICT, Gandhinagar
Dhirubhai Ambani Institute of Information and Communication Technology, Gandhinagar, Gujarat, India
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
2
Abstract The aim of wildCENSE is to create a wireless sensor network for wildlife monitoring. In the system proposed, specially designed collars with sensor node attached would be put on wild animals. These collars would collect data about the desired parameters from the vicinity of the animal and transmit it to the base station so that the information could be used by the scientists/wildlife officials for their studies. The components of the sensor node, to be mounted on the collar include Global Positioning System (GPS) receiver, temperature sensor, humidity sensor, orientation sensor and light sensor. A microcontroller would collect data from these sensors and write it on an off‐chip flash memory. When a node comes close to another node due to the movement of animals, the two nodes would exchange data using their respective radio transceivers. The power requirements of the sensor node would be met by a battery which would be re‐charged by the solar film attached to the collar. The base station of the system would be mobile and would be able to collect data whenever a collared animal comes within the communication range of the base station antenna. The system thus developed would be used to monitor the habitat, movement pattern and behavior of Indian Nilgai (Boselaphus tragocamelus). This report discusses the methodology and experiences of designing and implementing the functional model of the project and also suggests devices and methods, which would optimize the performance when scaled.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
3
Acknowledgements We would like to thank Prof. Prabhat Ranjan for conceptualizing wildCENSE and providing us an opportunity to work on the project. It was his enthusiastic outlook towards the project which inspired us throughout our work during this semester. He closely followed the progress of the project and was always available for guidance. We would like to make a special mention of his availability for field testing and his late‐evening visits to the laboratory. We would like to thank Mr. Udayan Kumar, Research Engineer, DA‐IICT for sharing his knowledge about the components involved in the project and assisting in the development of the system. We thank Mr. Bharat Jethwa, Gujarat Ecological Education and Research Foundation for providing practical information about project requirements and taking the team to Wilderness Park, Gandhinagar where we could see Indian Nilgai in its natural habitat. We would like to thank Mr. Gerald Dahlmann, Sensirion for sending samples of SHT11 and providing help in the interfacing of the sensor.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
4
Contents Abstract Acknowledgements List of Tables List of Figures List of Appendices 1.
Introduction
________12
Background
2.
_
2.1.
Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2.
Wireless Sensor Networks (WSN) in wildlife research . . . . . . . . . . . . . . . .
14
Previous related work in monitoring wildlife using WSN . . . . . . . . . . . .
15
2.3.1. Great Duck Island project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.
2.4.
2.3.2. Zebra Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.3. Electronic Shepherd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.4. Televilt (commercial project) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.5. UC Davisʹs Southern California Puma Project . . . . . . . . . . . . . . . . . . .
18
Indian Nilgai and its habitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .
18
3.
Design of the sensor node
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Issues/Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
__ 20 21
3.2.1. RF Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.2. Energy Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.2.3. Physical Design of the collar/belt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3. Learnings from Zebranet experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4. Architecture of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.5. Architecture of the node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Implementation of GPS/Sensors/System Software
__
4.
4.1. Global Positioning System Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.2. Working of GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.2.1. Determination of Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.2.2. Measuring Distance from Satellite . . . . . . . . . . . . . . . . . . . . . . . .
26
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
5 4.1.2.3. Locating GPS Satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.3. Interfacing GPS receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.4. Receiving data from the receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1.5. Calculating distance from GPS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.6. Power Requirements and regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.1.7. Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2. Humidity and Temperature Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2.1. Difference between two‐wire serial interface of ATmega 32 and SHT11
33
4.2.2. Interfacing the Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2.3. Power Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3. Orientation Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.4. Light Dependent Resistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5. System Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5.1. Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5.1.1. Internal Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5.1.2. External Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.5.2. Microcontroller Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.
Flash Memory
__________
5.1. Memory Requirements of wildCENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.2. Flash Memory of wildCENSE: AT45DB321B . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3. Hardware Interfacing with Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.4. Communication with Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.
Data Compression
__________
6.1. Temperature Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.2. Humidity Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.3. Orientation Sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.4. GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.5. Format of Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.6. Deletion of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.7. Saving Erase/Program Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
7.
Power Supply
__________
7.1. Power profile of wildCENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
7.2. Battery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7.3. Voltage regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.4. Power saving techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.5. Recharging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.5.1. Electromagnetic induction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.5.2. Solar energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.6. Charging circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.7. Battery capacity monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
6 8.
Communication Protocol
8.1. Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
__ 55
8.1.1. Issues in choosing a communication module . . . . . . . . . . . . . . . . . . . .
55
8.1.2. Reasons for selection of XBee‐PRO over other choices. . . . . . . . . . . . .
56
8.1.3. XBee‐PRO Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
8.1.4. Module Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
8.1.5. Module Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
8.1.6. Design of Breakout board for XBee module . . . . . . . . . . . . . . . . . . . . . .
58
8.2. Proposed protocol 8.2.1. Issues/Design Goals in node discovery. . . . . . . . . . . . . . . . . . . . . . . . . .
59
8.2.2. Issues/Design Goals in data exchange between nodes . . . . .. . . . . . . .
60
8.2.3. Proposed probabilistic slot contention based approach . . . . . . . . . . .
60
8.2.4. Functional Specification of the protocol . . . . . . . . . . . . . . . . . . . . . . . .
62
8.2.4.1. Packet header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
8.2.4.2. Node Discovery phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.2.4.3. Data Exchange phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
8.3. Simulations and Results 8.3.1. Architecture of the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
8.3.1.1. Random value generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
8.3.1.2. Main Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.3.1.3. Configuration manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
8.3.2. Results and Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
9.
Hardware Implementation of wildCENSE Node_
__
9.1. Design issues in the hardware design of the node . . . . . . . . . . . . . . . . . . . . .
72
9.2. Design of the hardware board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.2.1. Initial designs on breadboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.2.2. Design on a general purpose PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.2.3. Design of the base station hardware . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
10. Radio Frequency – Discussion
__
10.1. RF Communication Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
10.2. RF Communication System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
10.3. Fresnel Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
10.4. Losses due to environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
10.5. Antenna Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
10.5.1 Antenna Connection Option for XBee Pro . . . . . . . . . . . . . . . . . . . . . . .
85
10.5.2 Beamwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
10.6. RF Communication in Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
11. Test Reports
__
4.1 Brief detail of RF Communication and GPS Testing . . . . . . . . . . . . . . . . . . . . .
88
4.2 Test conducted in Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
7 4.3 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1
Test 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90 90
4.3.2
Test 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.3.3
Test 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
12. Conclusions
98
References
99
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
8
List of Tables Table 1.1
Biologist’s wishlist and design of ZebraNet
17
Table 1.2
General Characteristics of Indian Nilgai [8]
19
Table 1.3
Pin description for GPS Receiver
27
Table 1.4
Register values for initiating USART
28
Table 1.5
Test Results of start time and mean error of GPS
32
Table 1.6
Test Results of using Battery Back‐up of GPS
32
Table 1.7
Various states of operation of SHT11
35
Table 1.8
Commands available in SHT11 Sensor
35
Table 1.9
Data profiles of various sensors
38
Table 1.10
Compressing GPS Data
43
Table 1.11
Format of Data Byte
44
Table 1.12
Power Profile of wildCENSE
47
Table 1.13
Specifications of the XBee‐PRO OEM RF Modules
57
Table 1.14
Relevant Pin connections for XBee‐PRO module
57
Table 1.15
A sample configuration to modify destination address
57
Table 1.16
Wiring conventions followed in the implementation
73
Table 1.17
Fresenel Zone Diameter Chart
84
Table 1.18
Details of RF communication and GPS testing
88
Table 1.19
Details of Test 5‐ RF Communication between node to node
91
Table 1.20
Details of Power received at the fixed base station
93
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
9
List of Figures Fig 1.1
Radio Tracking of condor movements
15
Fig 1.2
GDI’s base station
16
Fig 1.3
Zebranet Nodes [Courtesy: http://www.princeton.edu/~csadler/ ]
17
Fig 1.4
Architecture of wildCENSE
24
Fig 1.5
Block diagram describing the architecture of wildCENSE node.
25
Fig 1.6
Navman GPS Receiver
27
Fig 1.7
Pin Connections for GPS Receiver
28
Fig 1.8
Outputs from GPS Receiver
30
Fig 1.9
SN754410 IC
31
Fig 1.10
Pin connections: SN754410
31
Fig 1.11
SHT11 Sensor
33
Fig 1.12
SHT11 Pin Connections
34
Fig 1.13
Connection Reset Sequence followed by transmission start sequence
34
Fig 1.14
MMA6270Q Sensors
36
Fig 1.15
Architecture of the flash memory
39
Fig 1.16
Pins of Flash
40
Fig 1.17
Interfacing Flash with microcontroller
41
Fig 1.18
Dataflash on the node
41
Fig 1.19
LM317 Regulators
48
Fig 1.20
Shakelight
49
Fig 1.21
I/V graph of solar cell
50
Fig 1.22
RU 6715
50
Fig 1.23
Battery charging circuit
51
Fig 1.24
MAX 856 DC Converter and MAX 982 Dual Comparator
52
Fig 1.25
Implemented battery charging circuit
52
Fig 1.26
Battery Gas Gauging circuit
54
Fig 1.27
XBee‐PRO Module
56
Fig 1.28
XBee‐PRO Module’s Mechanical Drawing
57
Fig 1.29
Breakout board for XBee
59
Fig 1.30
State of the system at t=0
63
Fig 1.31
State of the system at t=TS
64
Fig 1.32
State of the system at t=SL
64
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
10 Fig 1.33
State of the system at t=2SL
65
Fig 1.34
Minislot reservation for BS
66
Fig 1.35
Architecture of the simulator
68
Fig 1.36
Simulation Results‐1
70
Fig 1.37
Simulation Results‐2
71
Fig 1.38
LCD Implementation of the node.
75
Fig 1.39
Schematic of the design where XBee and GPS share ports.
75
Fig 1.40
Connections between data flash and the microcontroller
76
Fig 1.41
Connections for the on board programmer for ATMega32
76
Fig 1.42
Schematic showing the final implemented design
78
Fig 1.43
Photograph of CENSE node’s PCB’s reverse side
78
Fig 1.44
Photograph of the node
Fig 1.45
79
Photograph of the node working
80
Fig 1.46
Base station of wildCENSE
80
Fig 1.47
Football shaped zone between TX and RX
83
Fig 1.48
Antenna is raised at one of the ends
83
Fig 1.49
Some of the antenna used in our project
87
Fig 1.50
Received Power vs distance graph for the GPS data at the BS
93
Fig 1.51
Graph of Power Received vs Distance of test II
95
Fig 1.52
Graph of Power Received vs Distance with different antennas
95
Fig 1.53
BS at bridge on Sabarmati
Fig 1.54
River bed (path of node for range test)
96
96
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
11
List of Appendices Appendix I:
102
Opcodes of AT45DB321B Clock Pulse to interface Flash Memory with Atmega32 Appendix II:
103
104
List of Suggested Components Appendix III:
GPS Data Transmitted by the Node to the Base Station in Test ‐ II
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
12
Chapter 1 _ ___________
Introduction The wildCENSE project is an attempt to monitor the habitat of Indian Nilgai or Bluebull (Boselaphus tragocamelus) using wireless sensor networks. The proposed solution would collect the microclimatic as well as positional information of the animal and it would be sent to a base station. The system would contain five sensors namely position (Global Positioning System), temperature, humidity, head orientation and light to observe the aforementioned parameters for the animal. A microcontroller would drive the system to record the input from these sensors after specified intervals of time, and write it in the data flash. The system would be integrated in the form of a collar that can be easily fitted on to the neck of animal. The collar would be designed for inconspicuous operation so that the normal activities of the animal are not disturbed. The communication will be between nodes themselves and with the base station. Base station can be both stationary as well as mobile (on a van). The data from each node (collar) would be aggregated and presented in a meaningful format at the base station and at an online portal. This will help the researchers in their studies regarding the monitoring of habitat of Indian nilgai. The proposed solution would be general and portable enough to be used on other animals as well. As our B. Tech project, we have tried to develop the aforementioned system – wildCENSE. This document describes the design and implementation of the system. The rest of the document is as follows. Chapter 2 describes the concept of sensor networks and the suitability of sensor networks in wildlife research. It also describes some of the existing projects that are doing similar kind of work as ours. Indian Nilgai and its habitat is also described for better understanding of the scenario. Chapter 3 illustrates the design of the sensor node. Various issues and challenges involved in the node design are discussed. We have had continuous interaction with Chris Salder (Zebranet Project), Princeton University and learnt a lot from their experiences. These learnings are also mentioned. The architecture of the system and sensor node is described. Chapter 4 describes interfacing of various sensors with the microcontroller, development of the system software for the sensor nodes and a proposal for the physical design of the collar. Chapter 5 describes the Memory Requirements of wildCENSE. Implementation details of interfacing of the flash memory with the microcontroller are presented.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
13 Chapter 6 describes the compression of data of various sensors and GPS. The systematic deletion of data is also presented. Chapter 7 describes the power supply issues of wildCENSE node. Various power saving techniques are discussed and circuits to monitor the battery power status are also shown. Chapter 8 describes the communication protocol for wildCENSE. The XBee‐PRO module used in wildCENSE is also described in detail A new probabilistic slot contention based protocol is proposed. The protocol is tested using a self written simulator. Architecture of the simulator and results are described with conclusions. Chapter 9 explains the hardware implementation of the node. Various intermediate designs are illustrated along with the learnings from each design. Various conventions and standards followed during the implementation are also described. Base station’s hardware is also described. Chapter 10 describes the Radio frequency issues. Various design constraints on the antenna are discussed. Chapter 11 tabulates the results of various field tests done to check the radio communication range. Interesting inferences are discussed. Chapter 12 describes the conclusions and future goals of this live project.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
14
Chapter 2 _____ ___________
Background
2.1 Sensor Networks Sensor networks have been identified as one of the most important key technologies of the 21st century [1]. Akyildiz et.al [2] describes sensor network to be composed of a large number of sensor nodes that are densely deployed either inside of the phenomenon or very close to it. The position of the sensor nodes need not be pre determined and engineered. This allows random deployment in inaccessible terrains or disaster relief operations. On the other hand, this also means that sensor network protocols and algorithms must possess self‐ organizing capabilities. Wireless communications and these small sensor nodes are often combined to form wireless sensor networks (WSN). Another unique feature of sensor networks is the cooperative effort of sensor nodes. Sensor nodes are fitted with an on‐board processor. Instead of sending the raw data to the nodes responsible for the fusion, they use their processing abilities to locally carry out simple computations and transmit only the required and partially processed data. The above described features ensure a wide range of applications for sensor networks. Some of the application areas are health, military, and home. In military, for example, the rapid deployment, self‐organization, and fault tolerance characteristics of sensor networks make them a very promising sensing technique for military command, control, communications, computing, intelligence, surveillance, reconnaissance, and targeting systems. In health, sensor nodes can also be deployed to monitor patients and assist disabled patients. Some other commercial applications include managing inventory, monitoring product quality, and monitoring disaster areas.
2.2 Wireless Sensor Networks in wildlife research
Wildlife researchers and biological scientists study living organisms and their relationship with their habitat. They research problems dealing with life processes and living organisms. Zoologists and wildlife biologists study animals and wildlife—their origin, behavior, diseases, and life processes. Some experiment with live animals in controlled or
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
15 natural surroundings where they have to constantly monitor their interaction with the environment. Ecologists study the relationships among organisms and between organisms and their environments, examining the effects of population size, pollutants, rainfall, temperature, and altitude. Most of the times, these studies are helpful in preserving animals which are on the verge of extinction. Sometimes it also enunciates the effect of some major projects (for e.g. building a dam, canal etc.) on the migratory path of animals. The challenges posed by wildlife research are many. Generally, the area under the surveillance is quite large (of the order of 10,000 sq miles), the terrain is difficult and infrastructure less environment adds to the complexities. There are traditional techniques which are used to monitor wildlife but often they are primitive, the results are inconsistent and invalid at times. Current telemetry solutions, Fig. 1.2, are too expensive in terms of both money and manpower. They often involve a device which gives out radio signals; researchers track it with antenna in a mobile van or fixed base stations. Commercial trackers are also available which use GPS technology and ARGOS satellites for information dissemination. Fig 1.1 Radio Tracking of condor movements [Courtesy: Ventana Wildlife Society]
Peer to peer technology based wireless sensor networks seems to be a very attractive option. Cheap and small nodes can be put on animals which communicate among themselves and thus disseminate information through the self organized network. This enables them to work even in infrastructure less environments. Continuous monitoring of wildlife is possible as the data is transmitted to a base station at regular intervals. The positional data, biometric and activity information along with photographic images can be transmitted too. Thus wireless sensor networks is a very attractive, feasible and the best solution for wildlife research applications. Some of the relevant case studies are provided in the next section which purports the popularity of WSN in wildlife research applications.
2.3 Previous related work in monitoring wildlife using Wireless Sensor Networks Initiatives have been taken at various different institutes to use wireless sensor networks for wildlife/habitat monitoring. Some of these initiatives are done as a research projects at universities like Princeton, University of California Berkeley. Some of the projects have commercial interests and corporate firms are involved in the design and manufacturing. Brief description of some of the projects is given on the next page:
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
16 2.3.1 Great Duck Island project [3] The Great Duck Island (GDI) project addresses the requirements for habitat monitoring in general. It proposes architecture for monitoring seabird nesting environment and behavior. The currently deployed network consists of 32 nodes on a small island off the coast of Maine streaming useful live data onto the web. The application driven design exercise serves to identify important areas of further work in data sampling, communications, network retasking, and health monitoring.
Fig 1.2 From top(clockwise) GDI’s base station, Motes to be placed in the petrel nests, Kits in the lab before deployment, Satellite imagery of GDI [Courtesy: http://GreatDuckIsland.net]
2.3.2 ZebraNet [4] The Princeton’s ZebraNet Project is an inter‐disciplinary effort with thrusts in both Biology and Computer Systems to track zebra behavior at Mpala Research Centre, Kenya. The goals are to develop, evaluate, implement, and test systems that integrate computing, wireless communication, and non‐volatile storage along with global positioning systems (GPS) and other sensors so that the systems can be used to perform novel studies of animal migrations and inter‐species interactions. The final goal is to make a collar to be put on zebra’s neck so that continuous logs of whereabouts of zebra can be recorded at the base station. ZebraNet is all about realizing a biologist’s wishlist to a technological design. Following table will explain this in a nice way: Biologist’s Wishlist Lightweight Detailed 24/7 archival position logs Mobile No fixed base station (No cellular Infrastructure)
Technological Answer ( ZebraNet design) Energy‐Efficient GPS‐enabled Wireless Peer‐to‐peer routing and data storage
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
17 Restricted human access to the systems (inconspicuous design)
Plan 1 year of autonomous operation
Table 1.1 Biologist’s wishlist and design of ZebraNet The design goals for ZebraNet are very similar to wildCENSE so we decided to look up to ZebraNet as a first pit‐stop point in the project plan. We were in touch with Cris Sadler, a PhD scholar at Princeton, who is a part of ZebraNet project. The learnings from this interaction are described later in the document. The design goals of the ZebraNet project were to take GPS position every 3 minutes followed by a detailed activity log for 3 minutes every hour. As mentioned in the table above, it was planned to have one year of autonomous operation. The system has to work for over 100s or 1000s of sq km. Latency is not critical but all the data should be delivered with high probability. It was decided that zebra’s collar weight should be limited to 3‐5 lbs. The protocol has to be kept simple, thus it was decided that individual collars will record location and store it in memory. It will exchange data with another collar, when in communication range. ZebraNet team finally developed a fully‐functional, highly‐mobile, energy‐efficient sensing system that determines accurate positional data and can propagate it through the network. Several system level energy management techniques were deployed to reduce energy consumption. The hardware utilized a solar array to recharge the batteries.
Fig 1.3 From top(clockwise) ZebraNet Nodes (shown over a credit card for size comparison) , A collared zebra, Zebra during the process of collaring, base station at Mpala research centre, Kenya [Courtesy: http://www.princeton.edu/~csadler/ ]
The system was first tested on January 12, 2004 where seven zebras, six females and one male were collared. Position logs were generated for these zebras. The area covered was around 36 square km’s as described in [4].
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
18 2.3.3 Electronic Shepherd [5] The ES project started with an inquiry from a local farmer in Lyngen, Norway, who was seeking a system that could be used to keep track of his sheep whilst they were out on grazing land during summertime. Each year, at the end of May, the sheep are left out on their own to graze up in the mountains, and they return at the beginning of September. Unfortunately, some of the sheep never return. Some are caught by predators, some fall off of cliffs in the precipitous terrain, and some remain in the mountains until the snow comes. Keeping track of the sheep is also important to document food safety and food control. The system was developed as a low‐power, low‐bandwidth application since simple and low price equipment was an important factor. The system supports flock behavior, which means that it is well suited for applications where a number of objects belonging to a flock can be equipped with low‐cost radio communication equipment. These objects communicate to a flock leader that has a global communication channel to the Internet. The technologies implementing the system consist of GPRS, GPS and UHF radio communication.
2.3.4 Televilt (Commercial Project) [6] Televilt in Sweden has built telemetry systems and mounted them on reindeer, grizzly bears, roe deer and wolf [6]. These are terminals that include GPS and VHF radio communication equipment. Obviously, battery lifetime is of special concern for these devices, as the animals are not easily captured. Also, robustness and weatherproof packaging are important issues. While some of their equipment can be bought ready to use, the terminals built for the purpose of research are very expensive, the cost being much higher than the value of the sheep. The terminals also use VHF radio as an access network, and the range is limited to a few kilometers. However, the main challenges are more or less same as those in the wildCENSE project, namely the need for small, low‐power devices able to get their own positions and transfer the data through a wireless communication channel to a central bas station.
2.3.5 UC Davisʹs Southern California Puma Project [7] This was part of a study conducted by researchers from University of California, Davis, in conjunction with the Zoological Society of San Diego. As part of the research cougars and deer were being captured and affixed with radio collars that will help scientists keep track of their travels and, in the case of deer, learn if they have fallen prey to lions. Bighorn sheep in the area already were affixed with radio collars, and more will be collared in the near future. The collars directly communicated to satellites, regularly transmitting their locations. The researchers were able to examine the pumasʹ beds, dens, kill sites and food caches, creating both intimate individual portraits and general overviews of the local puma population.
2.4 Indian Nilgai and its habitat In order to understand the proposed design goals for wildCENSE, it is imperative to understand Indian nilgai and its habitat as it would help in physical design of the collar. Nilgai or Blue‐bull (Boselaphus tragocamelus) is a large mammal found in large parts of India. It is about 1.5 meters at the shoulder and weighs around 170 kilograms. Female nilgai are yellow‐brown while males have horns and are gray‐blue in colour. It is estimated that the total population of Nilgai in India would be around 100,000. The gestation period of the
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
19 animal is around 8 months while the life span is around 21 years and they feed mainly on leaves, buds, grass and fruit. Movement The nilgai is mainly diurnal, with peaks in activity in the early morning and late afternoon. They avoid densely wooded areas, nilgai inhabit relatively dry areas of flat to rolling country with a moderate cover of thin forest or scrub. The sense of sight is also well developed among these wary species. When chased, nilgai can run up to 48 kmph / 29 mph i.e. (13 mps). Normally they don’t walk while grazing. Occasionally they have been seen grazing and walking simultaneously. The typical speeds are 0.5 – 1 kms/hr (i.e. 8 meters per minute). Social Behavior Nilgai typically herd in small groups of about 10 animals although larger Fig 1.4 Indian Nilgai at Gandhinagar groups of 20‐70 are occasionally seen. Males and females remain segregated for most of the year, with bulls joining the cow‐calf groups only for breeding. Most mating activity occurs from December through March; however, breeding can occur throughout the year. Habitat In India, Nilgai occur from the foothills of the Himalayas southward to Mysore. They live on a variety of land types from hillsides to level ground with scattered grass steppes, trees, and cultivated areas, but not in thick forests. Their habitats are characterized by paths, water holes, defecation sites, and resting cover. Body Length Shoulder Height Tail Length Weight Gestation Period Young per Birth Weaning Sexual Maturity Life span Diet Main Predators
180‐200 cm / 6‐6.6 ft. 120‐150 cm / 4‐5 ft. 40‐45 cm / 16‐22 in. 120‐240 kg / 264‐528 lb About 8 months Generally 2 (over 60% of births), sometimes 1 or 3 By 10 months Around 18 months Up to 21 years Leaves, buds, grasses, fruit Tiger, leopard, wolf
Table 1.2 General Characteristics of Indian Nilgai [8]
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
20
Chapter 3 _____________.
Design of the sensor node
3.1 Design goals Every wildlife monitoring application is governed by some specific design goals. There are some defined expectations from a project analogous to ‘biologists’ wishlist’ in ZebraNet project. Further more, there are some constraints on the final design imposed by the habitat and animal. We had some of the design goals in our mind, and these were purported by some meetings with wildlife experts. These design goals are mentioned below: 1. Positional data required by the researchers at the base station to be able to track the nilgais. The typical requirement was 3‐5 position fixes for a day. This data can be stored on the node itself to be transmitted later to the base station or some other node. 2. Indian nilgais are shy in nature, due to their vegetarian nature they are difficult to tranquilize, thus the human intervention should be minimum after the collar is fixed on them. This leads to a design goal that nodes remain powered for at least one year, which falls in their typical breeding cycle. 3. As it has been seen that they are rough creatures, generally tend to fight (ref. section 2.4), thus the physical design of the collar should be strong and invulnerable to disruptions. 4. Along with the positional information, the microclimatic information should also be provided. Temperature humidity and luminosity information is essential for wildlife research. Head tilt was identified as possible information needed as it can indicate weather the animal is grazing or not. Ideas of having an image sensor on the collar were also brainstormed on but it is not included in this design. 5. The frequency of data collection from different sensors should be configurable on runtime and independent of each other so that the user of the system can change the frequency at which data is recorded from the sensors to suitably match his/her requirements. For example, a user may like to selectively disable some of the sensors
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
21 or take more frequent readings from a sensor as compared to another. The system should allow such functionality. 6.
To efficiently utilize energy, it is desirable that the components which are not being used at a particular instance should be kept in power‐save or shut‐down mode. If none of the interfaces are active, the microcontroller should also go to power‐save mode and should wake up only when it is the turn to use any peripheral.
7.
The data collected from the different sensors is recorded on a data flash. For efficient storage and to reduce the communication costs, the raw data should be processed and compressed.
8.
The payload of data packet to be transmitted should be variable in size in accordance to the sensors which are active at the particular timestamp when data is written in the data flash.
3.2 Issues/Challenges
Some of the challenges faced during the design process are mentioned below:
3.2.1 RF Communication The frequency proposed to be used in the RF communication is 2.4 GHz (available ISM band in India) which is very high, thus resulting in severe limitation in the range. The 900 MHz module has 2.67 as much range as the 2.4 GHz modules. However, there are certain advantages of using 2.4 GHz over 900 MHz:‐
Lower Power Consumption
Size of the antenna to be connected with RF module reduces at high frequency. This is important for project set up as very small antenna is needed for the node.
Diameter of the fresnel zone (region between transmitting and receiving site) reduces at high frequency due to which the height of the antenna from the ground is less as compared to the same at 900 MHz.
To minimize free space and fading losses of transmitting waves the antenna at Receiving and Transmitting sites needs to be at some height above the ground. The nodes in the project would be collared to animals and thus can’t be raised above the ground. This would also be a limitation.
3.2.2 Energy Constraints As it has been mentioned in the last section that the nodes should remain powered for at least one year, thus it is very important that energy should be spent in a very economical way. System level power savings on both software and hardware domain should be made. It was decided to keep the operating voltage of the node at 3.3V, since this would lead to less power consumption for the same current flowing in the components. All the components are chosen such that they work on 3.3V. As it can be seen later in the document that the communication protocol is designed such that the energy consumption is minimized.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
22 3.2.3 Physical Design of the collar/belt The system requires the GPS antenna and RF antenna to be at the top of the belt. It is also required that the belt should fit comfortably in the neck of the animal. Thus, a mechanism needs to be developed such that the collar is firm in orientation while not being rigidly fixed to the body of the animal. Attaching a load weight or an insulating skeleton could be considered for solutions. The belt and the components of the node must be protected from physical damage by climatic conditions or peer‐attacks. Damage of the belt of some animals may disrupt the network. The node needs to be protected from dust, water and mud. The humidity sensor needs to be in direct contact with the air. The solar film and light sensor need to be protected by a transparent covering. The sensor node is proposed to be collared to the neck of the animal. So, the weight of the node should be as less as possible not causing any physical damage to the animal. The project aims to have the weight of the collar to be less than 500 g.
3.3 Learnings from the ZebraNet experience We had some initial discussions with Cris Sadler, a PhD scholar at Princeton, who is involved with the ZebraNet project. Some of the issues that were common to both wildCENSE and ZebraNet were discussed. The discussions can be summarized in following points: 1. We are planning to incorporate orientation sensor as a part of our design to monitor the head movement. They, at Princeton, tried the similar thing; the problems faced were of packaging and waterproofing. The collar has to be made loose because the neck muscles of the animals are tensed during grazing and when they are standing upright. A tight collar would actually hurt the animal. 2. The collar should be able to survive the day to day life of the animal. Often the other animals chew on other’s collar to take it off. 3. The absorption of 2.4 GHz radio frequency by animal’s body was discussed. It was found out that 2.4 GHz should not hurt the animal, but it will absorb a lot of energy radiated from antenna. They used a mesh as a ground plane to minimize the amount of energy lost. 4. The design of their belt was discussed. The outer covering is butyl but the inner covering was made as leather as it is more comfortable to the animal. 5. The placement of components on the belt was discussed. GPS antenna, the radio antenna and the solar cells, all perform the best at the top of the collar. In their design they have placed GPS antenna on the top of the belt and the solar cells are on the side. Radio antenna, however has been placed towards the lower side of the collar. It is guessed that this might be one of the reasons for the low performance of their system.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
23 6.
A new material, tefzel was introduced to protect the solar cells from the rough climatic conditions. However, dirt and dust still blocks the solar cells leading to a degraded performance.
3.4 Architecture of the system
The architecture of the proposed system is described as below: 1. 2.
Each of the collars is fitted with a sensor node which has a microcontroller, GPS, Data flash, XBee radio module, various sensors and a solar film for charging the batteries. The collar is fitted with some of the nilgais, as nilgais show flock behavior, often the leader of the flock is chosen to carry the sensor node.
3.
The nodes mostly keep on sleeping. They are synchronized on global time scale by GPS, thus they all wake up simultaneously and then the node discovery protocol kicks into action (see the next chapter for more details). After the nodes are able to discover each other, an intelligent data exchange is done. Accumulation of duplicate data on each node is avoided as described in next chapter.
4.
The nodes thus exchange each other’s data and keep on exchanging the data until they come in the vicinity of a base station. The data of all the nodes is transferred to the base station. Base station instructs the node to initiate the deletion of that particular data after it has reached the base station.
5.
Base station is allotted a slot in every node discovery slot when every node listens to any broadcast from base station.
6.
The nodes go back to sleep and wake up again at a scheduled time and then node discovery protocol kicks into action.
7.
The information is processed at the base station and meaningful data (relevant for wildlife researchers) is generated.
This schematic (fig 1.4 on the next page) clearly explains the architecture of the proposed system. The nilgais that are in the vicinity of each other communicate to each other and exchange data. The nilgais near the base station transmit the stored data of other collars.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
24
Fig 1.4 Schematic explaining the architecture of wildCENSE. Yellow area around the animals indicates that they are in the radio vicinity of each other. The schematic is not scaled in relationship with the real world coordinates.
3.5 Architecture of the node Each collar is fitted with a sensor node which contains various components. This section would describe the components chosen for our design and the interfacing issues. The proposed components that would make a single node are as follows: ATMega32L Microcontroller [9] Initially ATMega128L [10] was chosen to be used as the processing unit of our sensor node. The main reason was the availability of two usarts (serial ports) which could be easily used to interface both the radio module and the GPS simultaneously. However due to unavailability of two ATMega128L’s (one for each node in a two node model) and difficulty in prototyping the node on a breadboard (ATMega128 is a Surface Mount Device‐SMD thus difficult to use on a breadboard) it was decided that the design to be shifted to ATMega32L. The operating voltage of both microcontrollers is 3.3V thus compatible to the proposed design goal. The hardware interfacing of the microcontroller with other components and the programming circuit is described in section 5. However, shifting to ATMega32 left us with
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
25 only one usart and two serial devices to connect to. This was resolved by using a multiplexer as a switch as described in section 5. Lassen IQ GPS Receiver with embedded antenna [11] This receiver is the only stamp‐sized GPS product that supports the four most popular protocols: DGPS (RTCM), TSIP (Trimble Standard Interface Protocol), TAIP (Trimble ASCII Interface Protocol) and NMEA 0183. The energy consumption of this module is quite low as compared to its other counterparts. However due to unavailability of this module, NAVMAN Jupiter’s GPS module which was available with the institute was used. More information about this can be found in B. Tech. project report of Mr. Ashish Kumar. XBeePro Zigbee RF Module [12] This module works on Zigbee/IEEE 802.15.4 standard and addresses the unique needs of low‐cost, low‐power wireless sensor networks. The modules require minimal power and provide reliable delivery of critical data between devices. The operation, interfacing and configuration of these modules is described in the next section ATMEL AT26DF081A Dataflash [13] As the memory requirements of our application are quite high, a dataflash of high memory capacity is a good choice. Atmel’s AT26DF081A was chosen since it can be interfaced through SPI and a lot of good documentation is available for its operation. More on this can be found in B. Tech. project report of Ms. Swetha Polana. SHT 11Temperature and Humidity Sensor [14] The serial interface with the aforementioned sensor provides a good interface for data acquisition. Both Temperature and Humidity can be measured by giving separate commands. The output is a 2 bit digital output. Small size and low power consumption makes it a good choice for the system. The sensor node can be pictographically represented by the following block diagram:
Fig 1.5 Block diagram describing the architecture of wildCENSE node.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
26
Chapter 4 _______________________.
Implementation of GPS Sensors and System Software 4.1 Global Positioning System Receiver
4.1.1 Introduction The Global Positioning System (GPS) is a worldwide radio‐navigation system formed from a constellation of 24 satellites and their ground stations to calculate positions on earth accurate to a matter of meters. Created by the U.S. Department of Defense, it is in fact the only fully‐functional satellite navigation system of Earth. With advanced forms of GPS, one can make measurements to better than a centimeter.
4.1.2 Working of GPS
4.1.2.1. Determination of Position To determine the position on the earth, signals from three GPS satellites is required. Knowing the distance from a particular satellite means that one could be on the surface of a sphere that is centered on this satellite and has a radius equal to the measured distance. Measuring the distance from a second satellite tells about one’s possible position on a second sphere. Thus, the position is narrowed to somewhere on the circle where these two spheres intersect. Measurement from a third satellite narrows the position down even further, to the two points where this third sphere cuts through the aforementioned circle. One of the two points is a ridiculous answer (either too far from Earth or moving at an impossible velocity) and can be rejected without a measurement. 4.1.2.2. Measuring Distance from Satellite Distance from a satellite is calculated by measuring the time it takes for a signal sent from the satellite to arrive at the receiver. Pseudo‐random signals are used for this by satellites and receivers. Each satellite has its own unique Pseudo‐Random Code which is known to the receiver as well. The codes make it possible to use information theory to
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
27 amplify the GPS signal and thatʹs why GPS receivers donʹt need big satellite dishes to receive the GPS signals. Distance to a satellite is determined by measuring how long a radio signal takes to reach us from that satellite. 4.1.2.3. Locating GPS Satellites GPS satellites have been inserted into very precise orbits. All GPS receivers have an almanac programmed into their computers that tells them where in the sky each satellite is, moment by moment. The Department of Defense uses very precise radar to check each satelliteʹs exact altitude, position and speed to measure errors that are caused by gravitational pulls from the moon and sun and by the pressure of solar radiation on the satellites. Once the DoD has measured a satelliteʹs exact position, they relay that information back up to the satellite itself. The satellite then includes this new corrected position information in the timing signals it broadcasts.
Fig 1.6 Navman GPS Receiver
4.1.3 Interfacing GPS receiver The receiver available at the institute is Conexant Jupiter TU30‐D410‐041 GPS module now known as Navman Jupiter GPS board. The receiver is connected to an antenna through an OSX connector. The output of the GPS is fixed at 4800 bps, 8 data bits and 1 stop bit. The pin description and required pin connections are being provided here:‐ Pin #
Name
Description
Pin #
Name
Description
1
PREAMP
Antenna preamp voltage input
11
SDO1
Serial data output port #1
2
PWRIN_5
Primary +5 V DC power input
12
SDI1
Serial data input port #1
3
VBATT
Battery backup voltage input *See Note 2
13
GND
Ground
4
PWRIN_3
Primary +3.3 V DC power input
14
SDO2
Serial data output port #2
5
M_RST
Master reset input (active low)
15
SDI2
Serial data input port #2
6
GYRO
Heading rate gyro input or reserved (no connect) (Note 1)
16
GND
Ground
7
GPIO2
NMEA protocol select/backup sensor (Note 1)
17
GND
Ground
8
GPIO3
EEPROM default select
18
GND
Ground
9
GPIO4
Speed indication or reserved (no connect) (Note 1)
19
TMARK
1PPS time mark output
10
GND
Ground
20
10KHZ
10 kHz clock output
Table 1.3 Pin description for GPS Receiver Note 1: Pins 6, 7, and 9 have dual functions depending on the specific Jupiter receiver configuration. Note 2: VBATT of 3.3 V works for all models. 5.0 Volts may be used for 5.0 Volt models.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
28
Fig 1.7 Pin Connections for GPS Receiver
4.1.4 Receiving data from the receiver The receiver can output GPS data in NMEA 4800 8N1 message format or Rockwell binary message format. However, since NMEA protocol is the recommended standard protocol, data was collected in this format itself for the project. The data from the receiver can be read on the UART of the microcontroller. To be able to do so, it is required to enable the UART receiver, which can be done by setting the bit RXEN in UCSRB register. The GPS receiver transmits serial data at a baud rate of 4800 and the configuration used is 8N1 in asynchronous mode. Similar configuration should be done for the microcontroller UART receiver as well. This can be done by setting the bits of UCSRC register as follows. URSEL should be set to 1 to access UCSRC as this register shares the same I/O address as UBRRH. UMSEL should be set to 0 to denote asynchronous operation. UPM1 and UPM0 should be set to 0 to denote that the parity mode has been disabled, while USBS should be set to 0 to set the no. of stop bits as 1 and UCSZ2:0 should be set as 011 to denote 8‐ bit character size. To use the asynchronous mode, we need to set U2X bit in UCSRA as 1. The baud rate can be specified in the registers UBRRH and UBRRL. Thus to conclude, following should be the values in the various registers discussed.
Sl. No.
Register
Value
1
UCSRA
0x02
2
UCSRB
0x98
3
UCSRC
0x86
Table 1.4 Register values for initiating USART
When there is some unread data in the USART buffer UDR, the RXC bit of UCSRA becomes set. This condition could be used to check if data has been received or not.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
29 The GPS receiver does not provide correct output immediately after switching it on. The data displayed initially is:‐ $GPGGA,,,,,,0,00,,,,,,,*66 $GPGSA,,,,,,*42 $GPRMC,23950,V,2311.2438,N,07237.6952,E,0.000,0.0,170600,0.3,W*7D $PRWIZCH,13,0,13,0,13,0,13,0,13,0,13,0,13,0,13,0,13,0,13,0,13,0,13,0*4D The format of these strings is as per the NMEA protocol [15]. As is visible, the GPS receiver operating mode (GSA) shows null values for IDs of Satellite Vehicles used in position fix. It is because the receiver has not yet been able to identify the satellites which is reflected in incorrect values of date, time and other GPS data in $GPRMC. $GPGGA is also not able to provide any other information except for the checksum. After some time, the data output changes, when correct Greenwich Mean Time is displayed in $GPRMC string. However the other information including the date is still incorrect. There is a new string which is displayed after $GPGSA which is $GPGSV,1,1,01,13,,,36,,,,,,,,,,,,*7F This provides information about the satellites in view. As per this line, only one GPS satellite is currently in view of the receiver. The SNR of the signal received is 36. After a further delay, there is another change in the string being displayed and now the correct date is also visible. Now, three strings corresponding to $GPGSV are visible which is correct as per the format where the first number, which is the no. of messages in a cycle increases from 1 to 3. Now, the receiver is receiving signals from 12 satellites. The second parameter in $GPRMC indicates the status of Navigation receiver warning. An ‘A’ indicates a valid position while a ‘V’ implies a warning and thus the data is not dependable. For an application to receive a correct data, it should wait till this parameter is changed to A. After this is received, the GPS receiver stabilizes. The screenshot on the following page shows the output after the stabilization of GPS receiver. The program written for the project checks if the incoming string from the GPS receiver is valid and records it only when it is found so.
4.1.5 Calculating distance from GPS Data The receiver used in the project gives latitude and longitude values to the precision of 6 places of decimal. This data can be converted into meters, but it is not advisable to do this calculation at the microcontroller due to the following reasons:‐ • Floating point calculations of 6 places precision are not available in avr‐gcc for ATmega32 even with the data type double. • Distances of the ranges of kilometers can not be stored as integers or double
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
30
Fig 1.8 Output from GPS Receiver
The logic of the program written to calculate the distance between two points, given their latitude and longitude is according to the Haversine formula [16]. It has been verified that the program gives the same difference between two locations, given their latitude and longitude as the interface [17] developed at Northern Arizona University and some similar tools [18] developed elsewhere. The program can give the distance and angle between two points given their latitudes and longitudes, and was used to calculate the distance of the node from the base station while testing the various antenna for the RF module. A discussion on this and the corresponding graphs plotted from the output given by the program can be found later in the document.
4.1.6 Power Requirements and regulation The GPS receiver used draws a constant current of 180 mA at 5 V irrespective of the warning parameter in the data received being ‘V’ or ‘A’. If pin 3 of the receiver, which is its battery back‐up, is connected to 5V, it does not draw any power from it when the main supply is on. However, if the main power is disconnected, a current of 38 μA is drawn to keep the SRAM and RTC on so that the GPS almanac and ephemerics is saved. This helps the receiver to reduce its Time To First Fix (TTFF). For the project requirements, it is desirable that the GPS receiver be switched off when the micro‐controller is not reading any data from it. The microcontroller should be able to control the power supply to the receiver, but without driving the required current from its I/O pins.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
31 This objective has been achieved by driving the GPS receiver through SN754410 Quadruple Half‐H driver. It is a quadruple high‐current half‐H driver designed to provide bidirectional drive currents up to 1 A at voltages from 4.5 V to 36 V. All inputs are compatible with TTL‐and low‐level CMOS logic. Drivers are enabled in pairs with drivers 1 and 2 enabled by 1,2EN and drivers 3 and 4 enabled by 3,4EN. When an enable Fig 1.9 SN754410 IC input is high, the associated drivers are enabled and their outputs become active and are in phase with their inputs. When the enable input is low, those drivers are disabled and their outputs are off and in a high‐impedance state. A separate supply voltage (VCC1) is provided for the logic input circuits to minimize device power dissipation. Supply voltage VCC2 is used for the output circuits. It was experimentally found that a drop of 1 V comes in the output of the chip as compared to the input provided, on connecting the GPS. Thus an input voltage of 6V is required to be given to drive the GPS with 5V. The pin connections made for using the chip is as mentioned in the diagram. The pin1 (1, 2 EN) is connected to an I/O pin of the microcontroller. When the pin is made high, pin3 (1Y), which is connected as the supply to GPS, attains the same voltage level as pin2 (1A). It was experimentally verified that the GPS does not practically draw any current from the I/O pin in this process. When pin1 is made low, pin3 comes at a potential level of 0, thus switching off the GPS receiver. Since pin9 (3, 4 EN) and pin10 (3A) are always kept high, pin11 (3Y) is always Fig 1.10 Pin connections: SN754410 high. So, whenever the GPS is switched off, it starts drawing current through its VBATT pin which is connected to 3Y of SN754110 to keep the SRAM and RTC which helps the receiver to find a fix in less amount of time in its next duration.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
32
4.1.7 Test Results Apart from the use of GPS receiver for the tests done to measure the specifications of RF antenna independent tests were conducted to record the specifications of this receiver. The results of the same are being mentioned in this section. (i) To measure the starting time of GPS receiver and the mean error in GPS receiver Location
# of Reading s
# of Starts
Avg Start Time(s)
Max Start Time(s)
Mean Coordinates
Mean Dev (m)
Max Dev (m)
Clear Sky, Open Space, Antenna suspended Clear sky, crowned plantation
104
6
62
93
23.11439 N 72.37623 E
7.32
16
86
5
103.4
120
23.1136 N 72.37628 E
23.68
444 (1) 59 (2)
Lab 202 window
Open space opposite to the window
148
6
66
113
23.11215 N 72.37682 E
10.24
26
Sports Ground
Clear Sky, Antenna kept upwards
82
5
72.4
114
23.1138 N 72.37612 E
7.06
26
Sports Ground
Plantation besides SAC1
Remarks
Table 1.5 Test Results of start time and mean error of GPS
(ii) To find the difference in Time to First Fix on connecting Pin 3 to battery back up from that of without the battery back‐up. The location of the tests was Lab 202 window.
Sl. No.
1 2 3 4 5 6 7 8 9 10 11 12
Time taken by receiver to give valid data (sec) 75 21 51 47 52 107 101 125 17 19 18 98
Time interval for which receiver is kept off (sec) Initial 14 51 83 16 596 436 563 510 531 460 537
Back Up Battery Connected
Table 1.6 Test Results of using Battery Back‐up of GPS
9
9 9 9
Evidently, the time required for the GPS receiver to provide valid data after being started up significantly decreases on using the battery backup.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
33
4.2 Humidity and Temperature Sensor The sensor used for measuring the humidity and temperature for the project node is Sensirion SHT11 which is a single chip relative humidity and temperature multi sensor module comprising a calibrated digital output. The device is interfaced with the microcontroller using a 2‐wire serial interface which is different from the two wire serial interface supported by ATmega 32. This made it necessary to program the microcontroller to send the appropriate pulses on data and clock lines of the sensor through the I/O pins of the microcontroller. Since, the device does not use any standard protocol; the clock frequency for communication with the sensor can be configured by the programmer. For the project, a clock frequency of 1 KHz was used. Fig 1.11 SHT11 Sensor The clock pulses were generated by precise delay functions which used the internal clock of ATmega32. To start communicating with SHT11 or to receive temperature or humidity values from it requires sending specific pulse sequence to be sent on data and clock lines. The sensor also has a built‐in heater, which can be activated by writing a specific word in the status register of the sensor.
4.2.1
Differences between two wire serial interfaces of ATmega32 and SHT11
ATmega32 has a support for two wire serial interface (TWI) which is provided through its SDA (data) and SCL (clock) pins. Although the protocol used by SHT11 for serial communication uses the same name, the protocol used is significantly different. This section highlights the difference between the two. ATmega32 starts communication through its TWI by sending a start sequence which is lowering the data line while keeping the clock high. While in SHT11, a start sequence involves lowering the data line at the center of a high pulse on clock line and making the data line high at the center of next high clock pulse. The clock line should remain low for five clock cycles before this next high pulse is sent on it. When the communication is established for the first time after SHT11 is powered on, a connection reset sequence should be sent before sending the start sequence. This sequence involves sending 9 high clock pulses while keeping the data line high. ATmega32 has a 7‐bit address space to support 128 different slave addresses. The 8th bit is to indicate whether a read or write mode is being used. This can be followed by one or multiple bytes of data until a stop sequence is sent. A stop sequence is generated by taking the data line from low to high while keeping the clock line high. SHT11 has a fixed 3‐bit address of 000. The rest of the 5 bits of the byte are used to send the command to the sensor. After the command is sent, the sensor sends an acknowledgment by lowering the data line during the next clock pulse. After this, the sensor controls the data line and sends the temperature data on this line which is right justified on the byte. If the microcontroller does not send an acknowledgment (lowering of data line) during the next clock pulse, the transmission is ended.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
34 4.2.2
Interfacing the Sensor
The connections to be made for interfacing the sensor are shown in the adjoining picture. The operating range of the sensor is from 2.4 V to 5.5 V. In the experiment conducted, it was operated at 5 V. The clock pin (SCK) needs to be connected to the ground by a 1MΩ resistor while there should be a 1KΩ resistor between the data pin and VCC. This is to drive the values on the data pin of the sensor. As mentioned in the preceding section, to initiate a communication with the sensor, a connection reset sequence needs to be sent. This must be followed by a transmission start sequence. For the project, the data and clock pins were connected to PINA4 and PINA5 of ATmega32. For changing SCK, values were directly written on PINA5; while for the SDA pin, only the data direction of PINA4 was changed, and the value was changed due to its connection with VCC through the resistor. The adjoining picture shows the connection reset sequence followed by the transmission start Fig 1.12 SHT11 Pin Connections sequence, where the Channel 1 is the SDA line and Channel 2 is the SCK line.
Fig 1.13 Connection Reset Sequence followed by transmission start sequence
This is followed by writing appropriate commands into the status register. The status register is used to choose between the two operating modes of 8 bit RH/12 bit temperature resolution or 12 bit RH/14 bit temperature resolutions. It also controls the heater of the sensor. The following table shows the possible values which can be written in the status register of SHT11.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
35 Sl. No. 1. 2. 3. 4.
Register Value 0x00 0x04 0x01 0x05
Operating Mode Heater Off; 12 bit RH/14 bit Temp. Heater On; 12 bit RH/14 bit Temp. Heater Off; 8 bit RH/12 bit Temp. Heater On; 8 bit RH/12 bit Temp.
Table 1.7 Various states of operation of SHT11 The commands to be written are sent serially through the data pin to the sensor. Every bit of data sent should be followed by one complete pulse of 1 and 0 on the clock line. After sending the complete byte, the data pin should be released by the microcontroller for the sensor, and a high clock pulse sent. The sensor should now send a 0 on the data line to acknowledge the command. The following table shows the various commands in SHT11 and the corresponding byte which should be written on the data line to use them:‐ Command Sl. No. Command Byte 1. 0x06 Write to status register 2. 0x07 Read from status register 3. 0x03 Measure Temperature 4. 0x05 Measure Humidity 5. 0x1e Reset sensor Table 1.8 Commands available in SHT11 Sensor After issuing a measurement command, the controller has to wait for the measurement to complete. To signal the completion of a measurement, the SHT11 pulls down the data line and enters idle mode. The controller must wait for this signal before restarting SCK to readout the data. The measured data is stored until readout. Two bytes of measurement data and one byte of CRC checksum will then be transmitted. The uC must acknowledge each byte by pulling the DATA line low. All values are MSB first, right justified. Communication terminates after the acknowledge bit of the CRC data. The device automatically returns to sleep mode after the measurement and communication have ended. However, the data recorded by the sensor and transmitted to the microcontroller is not the actual temperature/humidity measurement. This is a raw data, which needs to be converted into accrual temperature/humidity values by using the following formula:‐ RH = C1 + C2 x SORH + C3 x (SORH)2 T = D1 + D2 x SOT where the value of these parameters vary according to the resolution selection and the voltage supply to the sensor. For the project configuration, where 5V supply and 12 bit RH/14 bit Temp. was used:‐ C1 = ‐4 C2 = 0.0405 C3 = ‐0.0000028 D1 = ‐4 D2 = 0.01
4.2.3
Power Requirements
The sensor draws a current of 550 μA while measuring the data and 0.3 μA in the sleep mode. When the heater is turned on, the current consumption of the device increases to 8 mA.
4.3 Orientation Sensor As a part of the project goal, it is intended to track the orientation of the head of the animal. This can be achieved by measuring the tilt of the sensor node from static acceleration using
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
36 low‐g and high‐sensitivity accelerometer. The accelerometer used in the project is MMA6270Q. The device provides facility for choosing from four sensitivity states. A low value of sensitivity (1.5 g) can be selected by grounding both the pins g‐select1 and g‐select2. The appropriate connections of the device were made and the two outputs XOUT Fig 1.14 MMA6270Q Sensor and YOUT were connected to the PINA0 and PINA1 respectively of ATmega32. These pins are among the eight Analog to Digital Convertor (ADC) channels provided by ATmega32. The conversion of data from these two channels is done one after another by selecting appropriate MUX4:0 bits. To enable the ADC, start the conversion and enabling the conversion complete interrupt, ADEN, ADSC and ADIE bits of the ADC control and status register ADCSRA. On receiving the interrupt, the 10 bits of digital data corresponding to the analog output of the sensor can be received in the ADCH and ADCL. Setting the ADLAR bit of ADMUX register would make the data left adjusted in these registers and thus the 8 most significant bits can be read from ADCH register. A value of 255 in ADCH would imply that the analog value in the ADC input channel is equal to the reference voltage. In the experiment conducted, the reference voltage was kept at 5 V, the input voltage to the microcontroller. Thus, the output of the sensor can be found by VOUT = a * 5.1 / 255, where a is the value received in ADCH This value can be used to calculate the angle of tilt by using the following formulae:‐ Angle = arcsin {(VOUT ‐ VOFFSET)/ (∆V / ∆g)} Experimentally, the sensitivity (∆V / ∆g) for the given sensor was found out to be 800 mV/g while VOFFSET for XOUT and YOUT were found to be 960 and 1440 mV respectively.
4.4 Light Dependent Resistor In absence of a digital light sensor, a Light Dependent Resistor (LDR) is being used to measure illumination near the node for the project. Normally the resistance of an LDR is very high, but when they are illuminated with light, resistance drops dramatically. Being an analog sensor, it should also be connected to the ADC pin of the micro‐controller.
4.5 System Software
4.5.1 Timer By design, wildCENSE nodes would have a dependence on time for completion of several tasks, which would be carried after pre‐specified intervals of time. It is thus required to maintain a system time on the node. This section describes the tasks done to realize this goal on ATmega128. 4.5.1.1 Internal Clock ATmega128 has an internal clock of 1MHz frequency. This was used to create the system time for sensor nodes. The program uses the timer overflow interrupt of Timer1 to measure time as this keeps the main program free from any constraints. Timer 1 is a 16 bit counter. To have a clean start of the timer, the program first stops the Timer 1 by making CS12:0 bits of TCCR1 0. Now, the settings corresponding to the timer are done. First, the timer overflow Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
37 interrupt for Timer1 are enabled by setting the TOIE1 bit of TIMSK. Following this, the timer value is set to zero by making TCNT1 as 0. Setting the value of the register ICR1 would determine the time interval after which the overflow interrupt would take place. The clock frequency is 1 MHz and the desired period of timer overflow is 1 sec. Thus overflow value becomes 1000 000. But, register ICR1 has only 16 bits. Thus, we need to divide this number to make it a 16‐bit number. Dividing 1000 000 by 65536 (2^16) gives 15.26, which means a pre‐ scaler of 64 needs to be used. Dividing 10,000,000 by 64 gives 15625 as the quotient. Thus, the value of ICR1 would be 15625. To be able to use ICR1 with fast PWM and all three channels, we need to set TCRR1A register as 0xfe. Next, it is required to set the value of register TCCR1B to prescribe the details of the counter to be used. Since no comparison of the timer is done with any other value, the Input Capture pins would not be used. To use the internal clock with a pre‐scaler of 64, as mentioned above, the clock select value should be 011. With this, the clock would start and the timer overflow routine would be called after every second after the interrupts have been enabled. It should be noted that using interrupts without proper routines to handle them may lead to resetting of the microcontroller. 4.5.1.2 External Clock It is desired that the node should sleep for a specified duration of time and then wake to measure and record the sensor readings. However, the internal clock can not be used to measure the time, as it does not work when the microcontroller is in sleep mode. It is thus required to use an external crystal oscillator to determine as to when the microcontroller should get up from its sleep. The on‐board 32.768 KHz crystal on STK501 was used to measure this time. This crystal was used to drive the Timer0 of ATmega128, which is an 8‐bit timer. It was later implemented using an external 32.768 KHz crystal which was connected between PC6 and PC7 of ATmega32. In ATmega32, only Timer2 can be clocked using this external source. Activating this timer is similar to the process described in 4.6.1.1; however, there are some minor differences. The process starts by stopping the Timer0 writing TCCR0 as 0. This is followed by disabling the output compare interrupt and overflow interrupt by writing 0xfc in TIMSK. The counter is set to 0 by making TCNT0 equal to 0. The next step is to write the appropriate compare value in OCR0. The clock frequency is 32.768 KHz and the desired period of timer overflow is 1 sec. Thus overflow value becomes 32,768. But, register OCR0 has only 8 bits. Thus, we need to divide this number to make it an 8‐bit number. Dividing 32,768 by 256 (2^8) gives 128. To be on a safer side, a pre‐scaler of 256 is used. Thus, dividing 32768 by 256 gives us the value of OCR0 which is 128. Timer/Counter0 Output compare match interrupt Enable is not activated by setting OCIE0 as 1 in TIMSK. To indicate that the timer would be clocked from the crysal oscillator connected to TOSC1 pin, the AS0 bit in ASSR is set to 1. To use Fast PWM Mode along with normal port operation with a pre‐scaler of 256, TCCR0 should be set as 0x4e.
4.5.2 Microcontroller Sleep Mode To preserve the energy of the system, it is desired that the microcontroller should sleep while the data from the sensors is not being used. To use the power‐save mode where only Timer0 is kept activated while the rest of the components of the microcontroller are switched off, the SM2:0 bits of MCUCR register should be set as 011. Now, whenever it is required to enable the power‐save mode, SE bit should be enabled in the MCUCR register. The microcontroller wakes up again whenever any of the enabled interrupts take place.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
38
Chapter 5 _______________________.
Flash Memory Flash memory is a form of EEPROM (Electrically Erasable Programmable Read‐Only Memory) that allows multiple memory locations to be erased or written in one programming operation. It is an example of Non‐Volatile Read Write Memory (NVRWM)—a form of rewritable memory chip that, unlike a Random Access Memory chip, holds its content without the need of a power supply. It needs power only while writing/reading/erasing its contents. A 32MB Flash memory is used in wildCENSE to store the data collected by sensors and GPS. A detailed analysis of the memory requirements of the network is done and presented here.
5.1 Memory Requirements of wildCENSE Every node in the network has a unique Identification Number, which makes the data communication more effective and avoids transfer of redundant data. The size of the identification number, which is permanently stored in the memory of the node, varies depending on the number of nodes in the network. One byte of the flash memory has been allocated to store identification number, which means a maximum of 256 nodes can be used in the network. This can be varied depending on the number of nodes required in the network. The information about the various sensors used and the memory space occupied by the data collected by them before and after data compression is tabulated below. Sensor Number of Bytes Number of Bytes
GPS
before compression 38
after compression 12
Humidity
6
2
Orientation
6
2
Temperature
7
2
Total
57
18
Table 1.9 Data profiles of various sensors
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
39 Along with the data from any of these sensors, the time at which this data has been collected should also be stored i.e. every piece of data stored should be time‐stamped.
Each sensor can have a different frequency of collecting samples. All the sensors may not be active at the same time. But to analyze the worst‐case requirements, if we consider that all the sensors are working at one time, the number of data bytes would be 57. On applying suitable compression techniques, all this data has been reduced to just 18 bytes!! The compression algorithm is discussed in detail in the next section. Taking the other case, the minimum number of data bytes could be 7 which include 5 bytes of the time stamp. 3 bytes of meta‐data are included along with the data stored always. Thus, with all the sensors in active mode, if we take 8 readings in 24hrs, (8*21) =168 bytes are needed in one day. In one year, 168*360=60480bytes =60KB. This 32MB Flash would hence last for around 533 years!! Deletion of the data from the flash is also discussed in the later sections.
5.2 Flash Memory of wildCENSE: AT45DB321B The following features of the 32MB Flash, AT45DB321B have been considered while choosing a data memory for the node. • It needs a single 2.7V‐3.6V supply, which suits the system’s common supply of 3.3V. • It is SPI compatible and hence can be interfaced easily with the microcontroller, Atmega32. • The lower cost difference when compared to memory size makes it more cost efficient to use a 32MB flash than one with a lower memory capacity. • Maximum clock frequency of 20MHz increases the reading and writing speed. • Along with the 32MB memory, it also has two 528‐byte SRAM Data buffers, which can be used to store any temporary data if required. • Erase operations can be carried out both page wise and block wise. This flexibility in erase operations allows energy conservation by erasing the required amount of memory when required. • The memory can be reprogrammed even while read operations are being carried out on the Data buffers. • The lower current consumption of 2uA in standby mode, 4mA while reading and 10mA while programming also make it attractive to use in a network with severe energy constraints. • It takes 20ms to program/erase one page and 10ms to read one page from the memory. • A continuous data stream can be read or written which is more useful while transmission or reception of data between nodes. Fig 1.15 Architecture of the flash memory
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
40 The memory array of the AT45DB321B is divided into three levels of granularity comprising of sectors, blocks and pages. The buffers allow receiving of data while a page in the main memory is being reprogrammed, as well as reading or writing a continuous data. It has been advised by the manufacturers, not to erase the most significant page of the memory. In other words, the contents of the last page should not be filled with FFH. All programming operations to the Data Flash occur on a page by page basis. Figure 1.15 shows the division of the memory space into sectors, blocks and pages.
5.3 Hardware Interfacing with Microcontroller The AT45DB321B is enabled through the chip select pin (~CS), and accessed via a three‐wire interface consisting of Serial Input (SI), Serial Output (SO), and the Serial Clock (SCK). Figure 5 shows the schematic of the architecture of the Flash. The VCC and GND pins of the Flash are connected to the pins VCC and GND respectively of the microcontroller. The pins (~CS), SI, SO and SCK are connected to the Pins PB4, PB5, PB6, PB7 respectively of the microcontroller as shown in Figure 1.16.
Fig 1.16 Pins of Flash
5.4 Communication with microcontroller The Flash operation is controlled by instructions from the microcontroller. A valid instruction starts with the falling edge of (~CS) followed by the appropriate 8‐bit opcode and the desired main memory address location. While the (~CS) pin is low, toggling the SCK pin controls the loading of the opcode and the desired buffer or main memory address location through the SI (serial input) pin. All instructions, addresses and data are transferred with the most significant bit (MSB) first. Buffer addressing is done using the terminology BFA9 ‐BFA0 to denote the ten address bits required to designate a byte address within a buffer. Main memory addressing is referenced using the terminology PA12 ‐PA0 and BA9 ‐BA0 where PA12 ‐PA0 denotes the 13 address bits required to designate a page address and BA9 ‐BA0 denotes the ten address bits required to designate a byte address within the page. Figures of
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
41 clock pulses to connect are provided in Appendix I. Figure 1.17 shows AT45DB321B with the required pins connected to the Microcontroller, ATMEGA32. Figure 1.18 shows the data flash which has been put on the node.
Fig 1.17 Interfacing Flash with microcontroller
Fig 1.18 Dataflash on the node
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
42
Chapter 6 _______________________.
Data Compression The compression method used is very simple, which takes into consideration the maximum value that the sensor reading can attain. The method of compression for the various sensors is explained below. With this compression algorithm, 57 bytes are reduced to 18 bytes.
6.1 Temperature Sensor The range of readings for temperature is ‐40 to 123 (Celsius) and has a typical resolution of 0.01 Celsius. One bit is allocated to denote the sign of the temperature value. Since the value cannot exceed 124, 7 bits are used to denote the value before the decimal place and 7 bits to denote the value after decimal place. In all, it gets compressed to 2 bytes from 7 bytes (characters).
6.2 Humidity Sensor The range of readings for humidity is 0 to 100 %RH and has a typical resolution of 0.03% RH Celsius. 8 bits are used to denote the value before the decimal place and 8 bits to denote the value after decimal place. In all, it gets compressed to 2 bytes from 7 bytes (characters).
6.3 Orientation Sensor The range of readings for orientation in both X and Y Directions is (+/‐) 0‐90 degrees. 7 bits are used to denote the value before the decimal place and 7 bits to denote the value after decimal place. So, it gets compressed to 2 bytes from 7 bytes.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
43
6.4 GPS GPS fix has 38 characters which gives time, data, latitude, longitude and direction. The format is hhmmss, aaaa.aaaa, N, ttttt.tttt, E, ddmmyy 1. hhmmss represents the hours, minutes and seconds each two characters (6 characters). Since hour cannot have a value more than 24, 5 bits would be sufficient. Minutes and Seconds range from 0 to 60, hence 6 bits would be sufficient. In all, 5(hour) +6(minute) +6(second) = 17 bits. 2. aaaa.aaaa represents the latitude value e.g. 1234.5678 denotes Latitude 12.345678. (9 characters). These 8 digits can be represented in 28 bits (7 bytes for two digits since a two digit value is always less than 99). 3. N/S denotes North or South, (1 character). This can be stored as either 0 or 1 (one bit) instead of a character. 4. ttttt.tttt represents the longitude value, e.g. 83829.2939 denote Longitude 83.8292939. 10 characters). Again, the same way as Latitude and the last digit as 4 bits. So, totally 32 bits (4 bytes). 5. E/W denotes East or West (1 character) .This can be stored as either 0 or 1 (1 bit) instead of storing it as a character. 6. ddmmyy denotes Date, month and year. (6 characters). Date will always be less than 31, and hence 5 bits. Month is always less than 12, hence 4 bits. Year takes 7 bits. Totally, 5+4+7 =16 bits =2 bytes The compression of the GPS data is also explained in Table 1.10.
Table 1.10 Compressing GPS Data
6.5 Format of storage The data has to be compressed and stored in a definite format for optimizing the number of read/program operations in the memory. The data has to be written on to the off‐ chip flash in a proper order to avoid fragmentation of memory. In this memory, only page operations are possible i.e. to write these 21 bytes, the whole page should be erased. Thus the data at different time stamps is stored in different pages. The next free page address is also stored in the memory in the 2nd page. So whenever, data has to be written, the page address is read from the 2nd page and the data is written to the page given by the page address. Apart from storing the data in different pages, an index is maintained in Page 3 to find out the page number in which a particular node’s data is stored. This data includes the node id, the time stamp and the page number in which its data is stored. This is required for the node to find out the data of its neighbors in the memory to send data whenever required. Each node’s metadata takes 8 bytes. (Node id‐1 byte+ Time stamp – 5bytes + Page Address ‐2 bytes). A total of 65 time stamps can be stored in one page. This page would be periodically erased and filled by the meta data of the data which has to be sent. The meta data of the data which has been transmitted would be erased from the page.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
44 Since the data from all the sensors is not collected at the same time as the GPS fix is obtained, the time stamp has to be calculated by the microcontroller. Including the orientation and light sensor, the maximum number of bytes would be 22. These 22 bytes also include the time stamp stored to know the exact time at which this data has been collected. It is also necessary to know which all sensors have their data to be stored at one instance. One byte can be allotted to store this information. The byte in Table 4 shows the list of components whose data is stored in the next few bytes. The maximum number of bytes required storing data from the sensors and GPS is thus 23 bytes. The byte shown in Table 1.10 indicates that the next few bytes include the data collected by the temperature & Humidity sensor preceded by the time stamp. There is no GPS data available at that time. But, the data must be time‐stamped for their future reference. So, the timestamp of the microcontroller is being stored which takes 5 bytes. After the byte in the Table 1.10, next 5 bytes contain the microcontroller’s time stamp, 2 bytes store temperature and 2 bytes store humidity value. By storing the data in the above mentioned method, i.e. writing one set of data in each page, leads to fragmentation of memory. Each page has only first few bytes written in it and the rest of the bytes are free. A maximum portion of the memory is being wasted in this method. So, a function has been written to defragment the memory and hence create more free pages. Whenever data is collected at any point, it is immediately written to a new page along with other data which is collected at that time stamp and the page address pointer is incremented. Along with the page pointer, another variable is used to store the total number of bytes written to the memory till now and it is incremented after every page write. After incrementing, it is checked if this number of bytes can fill one page, if so, all this data in different pages is written to one page and the page address pointer is updated. Thus periodically, the memory is checked for fragmentation to make more space for the coming data. Whenever the node has to communicate with the neighbors, it checks for the data with the latest time stamp. This can be obtained from the function get_metadata(). The function get_metadata() gives a list of nodes, with their latest time stamps. The data corresponding to this node and the time stamp is then looked for in the 3rd page which stores the metadata. It finds the page number and reads the required data from that page which is then transmitted ‐ ‐ ‐ Orientation Humidity Temp Time Stamp GPS 0 1 1 1 0
Table 1.11 Format of Data Byte
While reading the data, the data byte shown in Table 1.11 is used to find the number of data bytes in that set. Since no delimiters are used between two sets of data, the number of data bytes is used to uncompress the data packet excluding the header. The same data byte can also be used to know the list of sensors whose data has been collected at that time stamp.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
45
6.6 Deletion of Data The data stored in the memory has to be deleted once the base station has collected the data. The node may either transfer the data directly or through the neighboring nodes when they come within a given range. The data which has been transferred should be stored on the node at least until it gets a confirmation message that the data has been received by the base station. This algorithm has not been implemented in the functional model but can be implemented later. In this model, data from the flash is deleted if there is no enough space to write new data. A First in First out algorithm is followed to delete the data. Since the data is written in an order starting from the 4th page, the deletion is carried out in the same order. Every time, when new data has to be written, the program checks if the address pointer points to the last byte of memory. If so, the 5th page is erased and the new data is stored there and the address pointer is reset. The first 4 pages are not erased as they contain the node ID and address pointer. 2 pages are left for future use.
6.7 Saving Erase/Program Cycles Every component of the network has to save energy whenever possible to reduce the total energy consumption of the node. Every program/erase operation takes 20ms and 15mA of current. Every read operation consumes 4mA of current and 10ms time. Instead of writing one set of data in one page, it can also be done that the data is stored in the buffer until it is filled. Once the buffer is full, all this data can be once written to the Flash memory. But this method has one limitation that the data flash should not be switched off else the data in the buffer is lost. This method would save around 20 erase/program cycle as nearly 20‐25 sets of data can be written in one page. This would greatly save the energy of the node.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
46
Chapter 7 _______________________.
Power Supply The power supply block consists of a battery which powers the sensor node. It is also possible to extend the life of the battery by recharging it using alternate sources like solar energy, electromagnetic energy etc. The functional model implemented has only the battery without any recharging facility. The battery charging and monitoring circuits have been implemented separately which can be used with the suitable components.
7.1 Power Profile of wildCENSE The power consumption of various components on the node is tabulated in Table 1.12.
Component
Mode
Voltage Range In V
Current
Power Consumed
Atmega32
Power
2.7 – 5.5
3.8mA (Vcc=3V)
11.4 mW
Power Down
‐
25uA (Vcc=3V)
‐
GPS
Normal
5
182 mA
910mW
Sleep
‐ 2.7‐ 3.6
35uA
Read
4mA
‐ 13mW
Program/Erase
2.7‐ 3.6
15mA
45mW
Standby
‐
2uA
‐
XBee Pro
Transmit
3.3
270mA
891mW
Receive
3.3
55mA
181.5mW
Flash Memory
Sleep Mode Normal
‐ 2.4‐5.5
10uA
Temperature & Humidity Sensor
4mA
‐ 13.2mW
Off
‐
10uA
‐
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
47 Orientation Sensor
Normal
‐0.3‐3.6
500uA
1.65mW
Sleep
‐
3uA
Light Sensor
‐
GPS Switch
Normal
6V
10uA
60uW
Multiplexer
Normal
5V
Minimal
‐
Total
~500mA (normal)
~1.2W
Table 1.12 Power Profile of wildCENSE
From the table it can be observed that the total current consumed when all the components are working in the normal mode is approximately 500mA and the power consumed is approximately 1.2W. It can also be noticed that three different voltages are required to run the functional model of wildCENSE. This can be avoided and the system can run with a single supply of 3.3V if the suitable components are available. The list of suitable components is listed in Appendix II.
7.2 Battery Choosing the chemistry is also a part of the design of the node as it effects the functioning of the system in the long run. Batteries are classified according to the material used for electrodes such as Lithium‐Ion, NiCd, NiMH, NiZn etc. Among the rechargeable types, NiMH is the only chemistry which is environment friendly. NiMH is similar to NiCd but has a hydrogen absorbing alloy for anode instead of cadmium and hence more environment friendly. A NiMH battery can have 2‐3 times the capacity of a NiCd battery and at the same time, lesser memory effect. But, a NiMH battery has limitations while charging/discharging as it gets damaged easily if over charged or discharged. Proper monitoring mechanisms should be employed while recharging the battery. A Battery Monitoring Circuit has been discussed using BQ2014H, a Gas Gauge Chip. The size and volume of the battery have also been taken into consideration while choosing the 3.6V NiMH battery. The battery is the heaviest of all the components of the node. So, it is important to keep the size and weight of the battery as low as possible. While fully charged, the NiMH battery can give upto 3.6‐3.8V. But due to the unavailability of the required components, the battery used in the implementation of the functional module is a different one, 12V, 7A/20HR Rechargeable Sealed Lead Acid Battery.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
48
7.3 Voltage Regulation It can be learnt from the table that three different voltages are required to run the node efficiently. It should again be noted that these components correspond to the functional model, which we developed in the project. We suggested the desirable components in Appendix II using which the entire node could run with one single voltage. In this model, a battery of 12V powers both the GPS and Multiplexer directly. It is being up‐ down‐converted to 5V, 6V and also 3.3V using the LM317 regulator.
Fig 1.19 LM317 Regulator
LM317 is an adjustable three terminal voltage regulator which supplies more than 1.5A of load current with an output voltage adjustable over 1.2 to 37V. Three LM317 regulators are used, one to down‐convert from 12V to 6V to power the GPS Switch, one to down convert 12V to 5V to power GPS and another to down convert 12V to 3.3V to power the majority of the components on the node. Maximum amount of current at any point of time consumed by the node is 500mA, which is far lower than the maximum load current (1.5A) that can be taken by LM317. The circuit implemented to down convert 12V to 3V is show in Figure 1.19.
7.4 Power Saving Techniques wildCENSE has severe energy constraints like any other sensor network. Saving the battery power and recharging it should go hand in hand. Dynamic power saving algorithms need to be implemented depending on the capacity of the battery. The microcontroller should be programmed such that it goes into the sleep mode both periodically and whenever required. When in sleep mode, the current consumed by the microcontroller is very low (25uA). Similar is the case with the other sensors and GPS. It has been decided to take 8 samples per day (one sample every 3 hours) of the GPS and other sensors. After every three hours, the microcontroller wakes up from the sleep mode, takes the readings, stores them, communicates with other neighbors in the network and sleeps again. The gas gauge chip proves very useful to save power because; the microcontroller can know the remaining battery capacity periodically. When the battery capacity goes below a pre‐ definite voltage, the microcontroller goes to the sleep mode thus saving energy .The gas gauge chip has been discussed in detail in the later sections.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
49
7.5 Recharging One of the main objectives of this project is to recharge the battery with an alternate source of energy to avoid any human intervention for a very long period of time. Once the collars are put on the animals, it is highly difficult to find them again to recharge their batteries. Two methods to recharge the battery have been discussed in this report. While one of them has been implemented, it is not integrated with the functional model due to lack of the suitable components.
7.5.1 Electromagnetic Induction Electromagnetic induction is the production of an electrical potential difference (or voltage) across a conductor situated in a changing magnetic flux. The idea is to create this potential difference by moving a magnet to and fro an inducting coil. The changing flux then generates a voltage which can be used to recharge the battery. It has been thought to place this equipment to the neck of the animal so that when it moves, the magnet would also move. To move the magnet to and fro, two magnets with opposite polarity are placed on either side as shown in Figure 1.20.
Fig 1.20 Shakelight
The blue coil which can be seen in the Figure‐1.20 is an inducting coil whose thickness varies depending on the voltage to be produced. This idea has not been carried forward because it was decided that this equipment would become too heavy to be hanged to the neck of the animal, apart from the sensor node which would be collared to the animal.
7.5.2 Solar Energy The most reliable source which generates limitless energy is the sun. With the advent in technology, the solar cells have become less expensive and provide a practical means of converting the sun’s power into electricity. The output current for a typical solar cell depends on the amount of incident sunlight. In full sun, one cell provides a typical open circuit voltage 0.55V and a short‐circuit current of 0.3A.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
50
Fig 1.21 I/V graph of solar cell Varying sunlight has less effect on the open‐circuit voltage but has a direct effect on the maximum available current. The solar panel, RU6715 used in the circuit is shown in Figure 1.23. It gives a maximum voltage of 6.7V and 15mA current. The circuit implemented in the project works more effectively with the 4.2V, 22mA flexible solar panel . The dimensions of the flexible panel are 3.3ʺ X 1.5ʺ. The flexibility of the panel makes it easier to put along the surface of the collar of the node .
7.6 Charging Circuit The charger has two key functions, charging and terminating. The circuit to charge the battery from the solar panel includes a switch‐mode step‐up converter and a comparator. The switch‐mode converter works in two cycles. It first connects an inductor to the solar panel, allowing a buildup of inductor current that stores energy in the inductor. In the second cycle, a change in current path enables the inductor to transfer its accumulated energy to the battery.
Fig 1.22 RU 6715
By monitoring voltage on this capacitor, we turn on the switch‐mode converter only when the panel output is optimum, that is, 0.484V times the number of (ranks of) series‐connected cells in the panel. This input is adequate to start the converter, and the capacitor provides a low‐ impedance path for the inductor current. When the capacitor voltage drops below a predetermined level (the converterʹs minimum operating voltage or higher), the converter shuts down until the capacitor again charges to the optimum voltage. The desired output voltage is not constant but depends on the batteryʹs charge condition. When charging, we always want to apply a fast charge unless the battery is already fully charged. During fast charge, the converter operates as a current source, forwarding inductor energy to the battery without checking the output voltage. The batteryʹs fast‐charge‐current requirement should therefore determine the values for the inductor and for the current‐sense resistor. After reaching a certain battery voltage, the above burst‐conversion scheme does not hint at when the next conversion cycle will occur. If it occurs within milliseconds, one should probably
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
51 stop the fast charge. If it occurs within hours or days (when sunlight is scarce), the fast charge should continue, because the battery can otherwise drain long before the next cycle. The battery voltage at discharge is greater than 3.0V, and the optimum flexible solar‐panel output is around 3V (3.8V), so the circuit requires a step‐up DC‐DC converter. MAX 865 has been used as the converter in this circuit. The dual comparator MAX 982 controls shutdown and charge termination. IC2A (Figure 1.23) directly controls shutdown, holding the converter in shutdown until the solar panel charges C1 to 2.9V. The converter MAX 856 then becomes active, and hysteresis allows the operation to continue until the voltage drops below 2.5V. Regulation first begins when the battery voltage reaches 5.0V, but the output comparator (IC2B) (Figure 14) terminates the charge cycle at 4.8V. The design handles termination not by controlling the shutdown pin, which requires additional logic, but by the unconventional approach of driving the 3/5V‐select pin high.
Fig 1.23 Battery charging circuit
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
52
Fig 1.24 MAX 856 DC Converter and MAX 982 Dual Comparator
Because the output is at 4.6V, selecting a 3V output (actually 3.3V) causes the converter to turn off. Again, comparator hysteresis ensures that the converter remains off until the battery voltage decreases to 4.2 V. It then resumes operation, providing a simple form of idle charging that does not overcharge the battery. The schematic charging circuit is shown in Figure 1.23. The circuit has been implemented by taking a fixed dc‐power supply of around 2.9‐ 3.3 V which is shown in Figure 1.24. The same can be implemented using the flexible solar panel but is not implemented using the available solar panel as the voltage levels do not match. However the circuit has been tested using the available panel only as inside the laboratory, the panel produces an output voltage in the required range.
Fig 1.25 Implemented battery charging circuit
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
53
7.7 Battery Capacity Monitoring The network has to be deployed in a forest where some nodes may be located in interior locations which makes it difficult to access them frequently. Hence, the nodes must recharge their batteries from an alternative source to be free from human intervention for a longer period of time. A circuit has been assembled but could not been implemented to recharge the batteries on the node by solar power, which would be available in abundance during daytime. This circuit has not been included in the functional model as the batteries charged by this circuit provide lesser voltage than required for the functional model. It can be integrated with the suggested components later. While ensuring uninterrupted power supply, the usage of power should also be monitored simultaneously. This report includes the study of a gas‐gauging chip, which communicates with the microcontroller the details of the power consumed from the battery. This would allow the microcontroller to reduce the power consumption whenever necessary by going to the sleep mode and acting accordingly. It has been observed that more batteries are damaged by bad charging techniques than all other causes combined. So, safer techniques have to be implemented to recharge the batteries and avoid any serious damage. The charging algorithm is a combination of the charging and termination methods. Once a battery is fully charged, the charging current is dissipated as heat and gases, both of which are bad for batteries. The essence of good charging is to be able to detect when the reconstitution of the active chemicals is complete and to stop the charging process before any damage is done while at all times maintaining the cell temperature within its safe limits. Detecting this cut off point and terminating the charge is critical in preserving battery life. In every charging circuit, this predetermined upper voltage limit is often called the termination voltage. The bq2014H NiCd/NiMH Gas Gauge IC is intended for the battery pack to maintain an accurate record of available battery capacity. The IC monitors a voltage drop across a sense resistor connected in series between the negative battery terminal and ground to determine charge and discharge activity of the battery. Compensations for battery temperature, self‐ discharge, and rate of discharge are applied to the charge counter to provide available capacity information. The main counter, Nominal Available Capacity (NAC), represents the available battery capacity at any given time. Battery charging increments the NAC register, while battery discharging and self‐discharge decrement the NAC register and increment the DCR (Discharge Count Register). This chip communicates with the microcontroller by a protocol called HDQ. The bq2014 includes a simple single pin serial data interface. The microcontroller sends a command byte to the bq2014H to either store the next eight bits of data received or output the eight bits of data specified by the command byte. The circuit has been made as shown in Figure 1.26, but this protocol could still not be implemented.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
54
Fig 1.26 Battery Gas Gauging circuit
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
55
Chapter 8 _ ___________.
Communication Protocols
8.1 Communication Module This section will describe XBee‐PRO, the communication module used in the project. Some of the issues in choosing a communication module for an application would be discussed first followed by reasons of choosing XBee‐PRO over other choices. Various specifications and configuration options are provided towards the later part of the section.
8.1.1 Issues in choosing a communication module Some of the issues to be taken into account while choosing a communication module for a wireless sensor network application are discussed below: 1. Most of the times nodes just have to transmit the information to a centralized entity (e.g. a Base Station). In those cases radio communication is essentially half duplex. Thus only using a RF transmitter on the nodes will do. 2. In cases where the node have to act both as a receiver and transmitter (e.g. wildCENSE), it is advisable to use a transceiver, however, a combination of receiver and transmitter can also be used and a switch can be used to select from one. Often this leads to a bulky design. 3. In applications, like wildlife monitoring, the radio frequency is often the issue. It is always desirable that the module operates in the free ISM band, so that the operation is legal and does not disrupts the essential transmissions on other frequencies. It should be checked that the module is FCC certified for remote and base radio applications. 4. Often, the MAC layer issues are resolved by writing extra code for CRC, retransmissions etc. Some of the modules provide solution to these MAC layer problems of lost ACK, and packet collision. Thus the radio operations are more reliable.
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
56 5.
It is always desirable to be able to measure the power of reception and transmission of radio signals. The module should provide an interface to control the transmitted power to be able to implement cluster based protocols.
6.
Though frequency hopping characteristics like Bluetooth might not be possible with most of the available modules, but it is desirable to have at least 2 frequency of operation within ISM band.
7.
Last but most important issue is of power, it should be easy to turn off the module when not in use, and typically modules provide this sleep mode which can be controlled using just a single pin. The transmit and receive powers are also important. In applications where nodes have to wait in the receive mode for longer periods of time, the power consumption due to receive mode dominates. Thus protocols should be designed to minimize that too.
8.1.2 Reason for choosing XBee‐PRO over other choices After studying various features of different wireless communication systems it has been found that most of these technologies were deigned with specific applications in mind. The example can be Bluetooth which is useful for communication between different devices like PCA, PC to printers. Another example can be wireless LAN. Zigbee is a standardized base set of solutions for sensor and control systems. It is a wireless network standard that meets the unique needs of sensor and control devices. It does not provide high bandwidth but it surely provides low latency and often the energy consumption is low making it suitable in applications where long operational life is required. Thus for wildCENSE Zigbee was an obvious choice. MaxStreams’s XBee‐PRO OEM RF module is a ZigBee/IEEE 802.15.4 compliant solution that satisfies the unique needs of low‐cost, low‐power wireless sensor networks. The modules are easy‐to‐use, require minimal power and provide reliable delivery of critical data between devices. The module operates within the ISM 2.4 GHz frequency band. This solution nearly solves all the issues posed in the above section. This transceiver is easy to use and easily configurable using AT commands. This was available on hand in the institute thus making it the best available choice. However, only a lower part of the ZigBee protocol stack (below MAC layer) is implemented in the hardware. The rest of the protocol has to be implemented on the software. Fig 1.27 XBee‐PRO Module
Dhirubhai Ambani Institute of Information and Communication Technology, Gujarat
57 8.1.3 XBee‐PRO Specifications
Specification Performance Indoor/Urban Range Outdoor RF line‐of‐sight Range Transmit Power Output RF Data Rate Reciever Sensitivity Power Requirements Supply Voltage Transmit Current (typical) Receive Current (typical) Power‐down current General Operating Frequency Number of Channels
XBee‐PRO Up to 100 m Up to 1200 m 60mW(18dBm), 100 mW EIRP 250,000 bps ‐100 dBm (1% packet error rate) 2.8 – 3.4 V 270 mA (@3.3 V) 55 mA (@3.3 V)
