200701043 report

9
“WildCense”– ZigBit Based Design & Peripheral Integration Using BitCloud Stack Akshat Logar Dhirubhai Ambani Institute of Information Communication Technology (DA-IICT), Gandhinagar- Gujarat [email protected] Supervisor Prof. Prabhat Ranjan Abstract – The following paper discusses the new design of WildCense node. The work involves transition from a microcontroller to a microcontroller cum transceiver based design as a consequence of considerable improvement in three aspects: - Power consumption, Range and Size. Further the paper describes how the various components were integrated using the BitCloud SDK. At the end new design of the node is presented. Keywords BitCloud, ZigBit (ATZB-24-A2), Meshnetics Meshbean2, GPS – PA6B, SHT-11, AT45DB161D, ZigBee, FT232, MMA7660, AT86RF230 I. INTRODUCTION WildCense is a Wireless Sensor Network (WSN) system which attempts to monitor the behaviour and migration patterns of Barasingha (Swamp Deer). The system would collect the micro-climatic as well as positional information of the animal and communicate it to a base station through flooding of data using peer-to-peer network. The base station, using a gateway, will upload all the collected data to database server on Internet. Each node would monitor four parameters namely position (using GPS), temperature, humidity, head orientation. Also, the node will have a real time clock for the synchronization of the network and to keep timing information. An external data flash memory would be used to record the data collected from sensors and other peer nodes. A radio transceiver would transmit the data to the base station by using a peer to peer communication protocol. A solar energy harvesting system for recharging node’s power supply batteries is being added to prolong the lifetime of nodes. The system would be integrated in the form of a collar that can be easily fitted on the neck of animal. II. CHANGES FROM THE EXISTING WILDCENSE DESIGN The system existing before used an Atmega 1281v as the microcontroller and XBee Pro as the radio transceiver. The peripherals used were:- 1) GPS Receiver:- Lassen iQ GPS Receiver 2) Temperature & Humidity Sensor :-SHT-11 3) Accelerometer:-MMA6270QT 4) Data flash:- AT45DB161B 5) Real Time Clock :- DS3231B The present design involves migration from Atmega 1281v (simple microcontroller) to ZigBit based design which contains Atmega 1281v along with a radio transceiver – AT86RF230. The peripherals used in the new design are:- 1) GPS Receiver:- GPS-PA6B from Mediatek 2) Temperature & Humidity Sensor:- SHT-11 3) Accelerometer:- MMA7660 4) Data flash:- AT45DB161D 5) Real Time Clock:- BQ32000DR Figure1:- ZigBit (ATZB-24-A2) Block diagram III. REASONS FOR USING ZIGBIT The transition from Atmega 1281 based design to ZigBit (Atmega 1281 + RF Transceiver) was based on the basis of three parameters Power consumption, Size of the node, Programming efficiency – Use of Embedded Stack. A. Size of the Node Size of the WildCense node is one of the important parameters for the node deployment. According to the wildlife researchers the collar based design should be such that it should not become a sort of discomfort for the animal. Here using ZigBit is of considerable importance because of the reduction in size as a result of using ZigBit. In the previous design XBee Pro module was used as the RF transceiver thereby consuming large space. In ZigBit since it encompasses AT86RF230 chip hence considerable reduction in space is achieved. Figure2:- Ultra compact size (24 x 13.5 mm for ZDM-A1281-24- A2) comparisons with XBee + Atmega1281

description

Complete Btech Report on Wildcense

Transcript of 200701043 report

Page 1: 200701043 report

“WildCense”– ZigBit Based Design & Peripheral Integration Using BitCloud Stack

Akshat Logar Dhirubhai Ambani Institute of Information Communication Technology (DA-IICT), Gandhinagar- Gujarat

[email protected]

Supervisor Prof. Prabhat Ranjan

Abstract – The following paper discusses the new design of WildCense node. The work involves transition from a microcontroller to a microcontroller cum transceiver based design as a consequence of considerable improvement in three aspects: - Power consumption, Range and Size. Further the paper describes how the various components were integrated using the BitCloud SDK. At the end new design of the node is presented. Keywords – BitCloud, ZigBit (ATZB-24-A2), Meshnetics Meshbean2, GPS – PA6B, SHT-11, AT45DB161D, ZigBee, FT232, MMA7660, AT86RF230

I. INTRODUCTION WildCense is a Wireless Sensor Network (WSN) system which attempts to monitor the behaviour and migration patterns of Barasingha (Swamp Deer). The system would collect the micro-climatic as well as positional information of the animal and communicate it to a base station through flooding of data using peer-to-peer network. The base station, using a gateway, will upload all the collected data to database server on Internet. Each node would monitor four parameters namely position (using GPS), temperature, humidity, head orientation. Also, the node will have a real time clock for the synchronization of the network and to keep timing information. An external data flash memory would be used to record the data collected from sensors and other peer nodes. A radio transceiver would transmit the data to the base station by using a peer to peer communication protocol. A solar energy harvesting system for recharging node’s power supply batteries is being added to prolong the lifetime of nodes. The system would be integrated in the form of a collar that can be easily fitted on the neck of animal.

II. CHANGES FROM THE EXISTING WILDCENSE DESIGN The system existing before used an Atmega 1281v as the microcontroller and XBee Pro as the radio transceiver. The peripherals used were:-

1) GPS Receiver:- Lassen iQ GPS Receiver 2) Temperature & Humidity Sensor :-SHT-11 3) Accelerometer:-MMA6270QT 4) Data flash:- AT45DB161B 5) Real Time Clock :- DS3231B

The present design involves migration from Atmega 1281v (simple microcontroller) to ZigBit based design which

contains Atmega 1281v along with a radio transceiver – AT86RF230. The peripherals used in the new design are:-

1) GPS Receiver:- GPS-PA6B from Mediatek 2) Temperature & Humidity Sensor:- SHT-11 3) Accelerometer:- MMA7660 4) Data flash:- AT45DB161D 5) Real Time Clock:- BQ32000DR

Figure1:- ZigBit (ATZB-24-A2) Block diagram

III. REASONS FOR USING ZIGBIT The transition from Atmega 1281 based design to ZigBit (Atmega 1281 + RF Transceiver) was based on the basis of three parameters Power consumption, Size of the node, Programming efficiency – Use of Embedded Stack.

A. Size of the Node Size of the WildCense node is one of the important parameters for the node deployment. According to the wildlife researchers the collar based design should be such that it should not become a sort of discomfort for the animal. Here using ZigBit is of considerable importance because of the reduction in size as a result of using ZigBit. In the previous design XBee Pro module was used as the RF transceiver thereby consuming large space. In ZigBit since it encompasses AT86RF230 chip hence considerable reduction in space is achieved.

Figure2:- Ultra compact size (24 x 13.5 mm for ZDM-A1281-24-A2) comparisons with XBee + Atmega1281

Page 2: 200701043 report

B. Power Consumption Factors AT86RF230 (RF

Transceiver in ZigBit) XBee Pro Series 2

Current Consumption

TX :- 18mA TX:- 215 mA RX :- 19mA RX:- 55mA Sleep Current:- ~.2uA

Sleep Current:- ~10uA

TX Power -17 – 3dBm 1-3dBm Sensitivity -104dBm -96dBm Table1.1:- Comparisons made using the respective datasheets of AT86RF230 and XBee Pro Series 2.

The above comparison between the two RF modules clearly shows the difference in current consumptions and in turn the effect in the power consumptions levels. In the WildCense node design the parameter which is of the most concern is the power consumption since we require a large lifetime of the node. RF communication consumes significant amount energy (~60 %) hence optimizing this significant chunk can save us a lot of power and thus make the system more efficient.

C. Programming Efficiency – Use of Embedded Software Stack

Due to the availability of BitCloud SDK specifically developed by ATMEL the task of integrating the various components especially the RF transceiver. Since the RF transceiver is already integrated in ZigBit this relieves us from the task of integrating RF Transceivers, like XBee in the earlier versions. Efficient use of the RF transceivers and the software interoperability is one of the major factors for using ZigBit. The BitCloud SDK has been explained in the following section. Support for AT commands is also provided through Serialnet.

IV. SOFTWARE DESCRIPTION Atmel BitCloud is a full-featured ZigBee PRO stack supporting reliable, scalable, secure wireless applications running on Atmel wireless platforms. The design software is completely standard compliant with the ZigBee PRO certified platform. [7]

A) Key Features Full standards compliance with the ZigBee PRO

certified platform. Easy-to-use C API and serial AT commands

available. Large network support for hundreds of devices,

optimized for ultra-low power consumption with 5 to 15 years battery life (application dependent).

Flexible, easy to use developer tools.

B) Software Stack Description

Figure3:- BitCloud Stack Architecture taken from Bitcloud Technical Documentation BitCloud SDK and the supported kits serve as the perfect vehicle to evaluate the performance and features of Atmel microcontrollers and radio transceivers as devices in a wireless sensor network. The SDK provides a complete software and documentation toolkit for prototyping, developing and debugging custom applications on top of Bit Cloud’s application programming interface (API) [7]. BitCloud internal architecture follows the suggested separation of the network stack into logical layers as found in IEEE 802.15.4™ and ZigBee. Besides the core stack containing protocol implementation, BitCloud contains additional layers implementing shared services (e.g. task manager, security, and power manager) and hardware abstractions (e.g. hardware abstraction layer (HAL) and board support package (BSP)). The APIs contributed by these layers are outside the scope of core stack functionality. However, these essential additions to the set of APIs significantly help reduce application complexity and simplify integration. BitCloud API reference manual provides detailed information on all public APIs and their use. [7]

C) BitCloud Programming Paradigm All the programming tasks that are carried out using BitCloud Architecture have to be carried out using an Event – Driven programming methodology. Event-driven or event-based programming refers to programming style and architectural organization which pairs each invocation of an API function with an asynchronous notification (and result of the operation) of the function completion is delivered through a call back associated with the initial request. Programmatically, the user application provides the underlying layers with a function pointer, which the layers below call when the request is serviced.

Page 3: 200701043 report

V. INTERFACING OF GPS RECEIVER – GPS-PA6B FROM MEDIATEK

Global Top Gms-u1LP is an all-in-one, high sensitivity, small SMD form factor, and low power consumption GPS antenna module. It utilizes Mediatek GPS MT3329 solution that supports up to 66 channels of satellite searching with -165dBm sensitivity and 10Hz maximum update rate for precise GPS signal processing under low receptive, high velocity conditions.

A) Comparisons with Lassen iQ GPS Receiver used in

previous Design:-

Factors Lassen iQ GPS – PA6B Current

Consumption 33mA tracking

42mA acquisition 24mA tracking

30mA acquisition Sensitivity Typically -

130dBm

-148dBm Acquisition -160dBm

Reacquisition -165dBm Tracking

Update Rate 1Hz Upto 10Hz Channels 12 66

Dimensions 26 x 26 x 6 mm 16 x 16 x 6 mm TTFF(Time To fix

first) Hot Start ~10s

Warm Start ~38s Cold start ~50s

Hot Start ~1s Warm Start~33s Cold Start~35s Reacquisition

time:- <1s VCC Ranges 3-3.6 V 3-3.6V

Table1.2:- Comparisons between Lassen IQ GPS Receiver and GPS-PA6B using the Respective Datasheets of the 2 GPS Receivers The above comparison shows the reason for selecting the GPS-PA6B module, the significant factors being the Sensitivity, Channels supported and TTFF values in comparison with the old GPS Receiver.

B) Programming the GPS-PA6B Receiver:- The GPS-PA6B module supports the NMEA 0183 v3.01 protocol. (Default : GGA, GSA, GSV, RMC, VTG).The GPS-PA6B supports MTK NMEA commands for giving instructions to the GPS Receiver. The following table gives the description of various output NMEA sentences:-

NMEA Output Sentences Option Description GGA Time, position and fix type data. GSA GPS receiver operating mode, active satellites

used in the position solution and DOP values. GSV The number of GPS satellites in view satellite

ID numbers, elevation, azimuth, and SNR values.

RMC Time, date, position, course and speed data.

Recommended Minimum Navigation Information.

VTG Course and speed information relative to the ground.

Table 1.3:- Table showing various NMEA output sentences The GPS Receiver outputs each of these default NMEA sentences at a frequency which is equal to the update rate frequency on Serial port, i.e, UART port. Out of all these NMEA output sentences only GGA & RMC messages are essential since they give Latitude, Longitude, and Time & Date respectively. The above information can be obtained by parsing the GGA & RMC messages. Each of the NMEA message code can be of 82 bytes (max).

C) GPS-PA6B connections with ZigBit :-

The GPS Receiver is connected to ZigBit using the USART interface .ZigBit is programmed using a FT232 USB to UART converter .UART port is connected with the FT232 chip whereas GPS is connected to USART port of ZigBit. Following is the schematic for the appropriate connections:-

Figure4:- Eagle Schematic showing GPS Receiver connections with ZigBit

D) Basic NMEA Codes & GPS Terminologies Hot Start - The GPS receiver remembers its last calculated position and which satellites were in view, the almanac used, and the UTC Time. This is the quickest re-acquisition of a GPS lock. Warm Start - The GPS receiver remembers it’s last calculated position, almanac used, and knows the UTC Time, but not which satellites were in view. This takes longer than a Hot Start but not as long as a Cold Start.

Page 4: 200701043 report

Cold Start - The GPS receiver dumps all information and resets. It then attempts to locate satellites and then calculate a GPS lock. This takes the longest because there is no known information. Whenever GPS is powered on it tries to achieve fix using COLD start. If the TTFF has to be changed then the corresponding MTK packet command has to be issued to have WARM start. Having WARM start correspondingly saves large amount of time required to achieve a fix.

Figure5:- MiniGPS software snapshot showing GPS Fix Achieved

The Following table shows the cold start times obtained for the GPS Receiver at different Testing Locations.

Location Cold Start Time Remarks Lab202 (outside) 83.4s Open space, Not

full line of sight Outside the Hostel 123.4s Obstructions

from various trees, buildings

Football ground 42.1s Clear sky, open space

Table1.4:- Cold start times obtained in various locations

Figure6: GPS-PA6B Breakout board connected with a Meshnetics Meshbean2 kit through UART0 for testing

Figure7:- Terminal showing Parsed data

VI. INTERFACING OF SHT-11 TEMPERATURE & HUMIDITY 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 ZigBit. 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.

A) Differences between two wire serial interfaces of ZigBit and SHT11

ZigBit 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. ZigBit 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

Page 5: 200701043 report

sending the start sequence. This sequence involves sending 9 high clock pulses while keeping the data line high. ZigBit 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.

B) Interfacing the Sensor

Figure8:- EAGLE schematic showing the SHT11 connections with ZigBit

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 3.6V. 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 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.

SI No. Register value

Operating Mode

1. 0x00 Heater Off; 12 bit RH/14 bit Temp. 2. 0x04 Heater On; 12 bit RH/14 bit Temp. 3. 0x01 Heater Off; 8 bit RH/12 bit Temp. 4. 0x05 Heater On; 8 bit RH/12 bit Temp.

Table 1.5: Various operation states of SHT11 SI No. Command byte Command

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.6: Various Commands available in SHT11

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 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 Temp. / 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 3.6V supply and 12 bit RH/14 bit Temp was used:-

C1 = -4 C2 = 0.0405 C3 = -0.0000028 D1 = -4 D2 = 0.01

Figure9:- Connection Reset Sequence followed by transmission start

sequence on a DSO

Page 6: 200701043 report

VII. INTERFACING ATMEL AT45DB161D (DATA FLASH) WITH ZIGBIT

The Data flash is required for the storage of readings obtained from the sensors used in design, i.e, GPS, Temp. /Humidity sensor and the Accelerometer. For this purpose ATMEL’s AT45DB161D was found suitable for our requirement.

A) Salient Features of Atmel AT45DB161D 16Mbit storage space Single 2.5V -3.6V supply 66Mhz maximum frequency SPI compatible modes of operation , compatible

with SPI Mode 0 and Mode 3 Page size is user configurable (512/528 bytes) Two SRAM buffers (512/528 bytes) allows

receiving of data while reprogramming the flash Flexible erase options :- Page Erase , Sector

Erase and Chip Erase Low power dissipation: - 7mA active read

current, 25uA standby current, 15uA Deep power down mode.

Figure10:- AT45DB161D Block diagram taken from

AT45DB161D Datasheet

Figure11:- Architecture Diagram of AT45DB161D taken from

AT45DB161D datasheet

The memory array of the AT45DB161D 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. All programming operations to the Data Flash occurs on a page by page basis.

B) Hardware Interfacing with ZigBit The AT45DB161D 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).

Figure12:- EAGLE schematic showing the connections of AT45DB161D with ZigBit

In the experiment performed VCC used is 3.6V. One of the problems faced during the experiment was that SPI pins of ZigBit were reserved for stack operation since we used BitCloud and hence were not available for programming. The Data flash supported the SPI protocol only hence in order to use SPI protocol we had to use USART0 of the ZigBit in SPI mode for programming the Flash.

C) Communication Sequence with ZigBit

The Flash operation is controlled by instructions from the microcontroller. A valid instruction starts with the falling edge of (~CS) followed by the appropriate 8bit 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 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.

Commands Opcode

Main memory Page Read 0xD2 Buffer 1 Read 0xD4 Buffer 2 Read 0xD6 Buffer 1 Write 0x84 Buffer 2 Write 0x87

Buffer 1 to Main memory page program 0x83

Page 7: 200701043 report

with built in Erase Buffer 2 to Main memory page program

with built in Erase 0x86

Page Erase 0x81 Block Erase 0x50 Sector Erase 0x7C

Status Register Read 0xD7

Table 1.7:- Different Opcodes for Data Flash

Figure13:- SPI Mode0 waveform taken from AT45DB161D

datasheet

Figure14:- SPI Mode3 waveform taken from AT45DB161D

datasheet

Figure15:- ATMEL AT45DB161D connections with Meshnetics

Meshbean2 kit for testing

VII. ESTABLISHING NODE TO NODE COMMUNICATION USING BITCLOUD ZIGBEE STACK In the Networking aspect of WildCense, experiment showing Node to Node communication of the GPS data from one node to other node was performed using BitCloud ZigBee stack provided by ATMEL. BitCloud stack provides API’s for creating a network and further send data packets from one node to another node as well as multihop communication aspects are handled by the ZigBee Protocol which uses IEEE 802.15.4 at the MAC layer.

Using the API’s of the BitCloud one of the nodes was configured as the coordinator and other node was configured as a router. The GPS module was connected on the router and the coordinator was acting as the base station. The router node was parsing the incoming NMEA codes and extracting the corresponding Latitude, Longitude, Date & Time values further sending the packet to the base station node.

Components Size(in bytes) Latitude + N/S indicator 10

Longitude + E/W indicator 10 UTC Time 10

Total 30 Total size of data obtained after parsing =30 bytes which is < 84 (bytes) which is the max payload that can be sent using the ZigBee protocol. This 30bytes was combined into a single packet and transmitted from router to coordinator. For the purpose of networking experiment two Meshbean2 kits were used.

Figure16:- Networking Experiment conducted using 2 Meshnetics Meshbean2 Kits with the GPS Receiver connected on the Router node and the other node acting as coordinator The peer to peer protocol as described in the original WildCense architecture has not been implemented. For the network discovery, network formation & network join functions ZDO layer of the Bitcloud stack was used which evoked the appropriate functions of the NWK layer. Data request, Data Transmission and Data Reception from the network layer was done using the appropriate functions of the APS layer of the Bitcloud stack.

VIII. SYSTEM OVERVIEW & SCHEMATIC DESIGN Design of the new node makes use of ZigBit (Atmega 1281v + AT86RF230 – RF transceiver) hence this eliminates the need of using XBee as the RF transceiver. The various peripherals used in the new design are:- GPS Receiver:- GPS-PA6B module from Mediatek instead of the Lassen IQ GPS Receiver from Trimble. Temperature / Humidity Sensor:-

Page 8: 200701043 report

SHT-11 dual (Temp cum Humidity) sensor as used in the original design. Accelerometer:- MMA7660 digital I2C based accelerometer is used in place of MMA6270QT which was an analog accelerometer. Data flash:- Atmel’s AT45DB161D 16Mbit data flash is used in place of AT45DB161B. Real Time Clock (RTC):- BQ2000DR is used in place of DS3231which was used in the previous design because DS3231 was becoming obsolete.

MCP1640:- MCP1640 is Buck/Boost converter from Microchip is used in place of TPS630001 which was used in the earlier design. MAX3373:- MAX3373 is an I2C accelerator which is used for signal conditioning. MCP111:- Voltage detecting chip designed to keep the uC in reset state until the system voltage has stabilized for suitable operation. TPS2092:- Acts as a power switch as in original design.

Figure17:- Block Level Diagram of New Design node

IX. CONCLUSIONS The GPS Receiver GPS-PA6B, Temperature / Humidity sensor SHT11, Data flash – AT45DB161D were successfully integrated with ZigBit using the BitCloud SDK. Accelerometer – MMA7660 has been tested as it had already been interfaced with ZigBit. Node to node communication was tested using ZigBit however the Communication protocol needs to be implemented .Once all the peripherals have been integrated they have to be combined and the device has to be integrated. RTC also has to be integrated.

ACKNOWLEDGEMENT Special thanks to Prof. Prabhat Ranjan for guiding and mentoring at every stage of the project in order to streamline the workflow. Also thanks to Sainath Nambiar [RA], Juhi Ranjan [RE], Hiren Shah [RE], Jay Kapasi and Firoja Sheikh [Lab Assistant] for constant helping hand throughout the entire duration of the project.

REFERENCES [1]WildCense: GPS based Animal Tracking System By Vishwas Jain, Ravi Bagree, Aman Kumar, #Prabhat Ranjan.

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4762058 [2] Atmel ATMega32 Datasheet [HTTP Online Document] http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf [3]SHT11‐Temperature and Humidity Sensor [Datasheet] http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf [4] NMEA Protocol [HTTP Online Document] http://www.kh‐gps.de/nmea‐faq.html [5]GPS-PA6B – GPS Receiver [Datasheet] http://www.4dsystems.com.au/downloads/GPS/GPS-PA6B-DS.pdf [5]ATMEL AT45DB161D – [Datasheet] [Data flash] http://www.atmel.com/dyn/resources/prod_documents/doc3500.pdf [6]ATZB-24-A2 – ZigBit [Datasheet] http://www.atmel.com/dyn/resources/prod_documents/doc8226.pdf [7]Complete BitCloud SDK http://www.atmel.com/forms/bitcloud_rzraven.asp?category_id=163&family_id=676&subfamily_id=2124&fn=dl_BitCloud_ATAVRRZRAVEN_1_11_0.zip

Page 9: 200701043 report

[8]BQ32000DR – Real Time Clock [Datasheet] http://www.ti.com/lit/gpn/bq32000 [9]TPS2092 – Power Switch [Datasheet] http://www.ti.com/lit/gpn/tps2092 [10]MCP1640 – Datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/22234B.pdf [11]MAX3373 – Datasheet http://pdfserv.maxim-ic.com/en/an/AN4096.pdf [12]MMA7660 – Datasheet http://cache.freescale.com/files/sensors/doc/data_sheet/MMA7660FC.pdf?pspll=1

[13]MeshBean2 - User Guide http://www.meshnetics.com/netcat_files/Image/P-MB2P-461~02-(WDB-A1281-A2%20Schematics).pdf [14 Atmel ATMega128 Datasheet [HTTP Online Document] http://www.atmel.com/atmel/acrobat/doc2467.pdf [15] XBee Pro Series 2 [Datasheet] http://ftp1.digi.com/support/documentation/90000976_C.pdf [16]EAGLE Schematic Design – Spark fun Tutorials http://www.sparkfun.com/tutorials/108 [17]Meshnetics Meshbean2 [Datasheet] http://www.meshnetics.com/netcat_files/Image/P-MB2P-461~02-(WDB-A1281-A2%20Schematics).pdf

Figure18:- WildCense ZigBit based new Design Schematic designed in EAGLE