WISENET
WISENET is a wireless sensor network that monitors the environmental condition (such as light, temperature, and humidity) of labs and offices in Jobst Hall. This network is comprised of nodes called “motes” that form an ad-hoc network to transmit this data to a computer that functions as a server. The server stores the data in a database where it can later be retrieved and analyzed via a web-based interface. The project works successfully with an implementation of one sensor mote.
INTRODUCTION
The technological drive for smaller devices using less power with greater functionality has created new potential applications in the sensor and data acquisition sectors. Low power microcontrollers with RF transceivers and various digital and analog sensors allow a wireless, battery-operated network of sensor modules (“motes”) to acquire a wide range of data. The TinyOS project at University of California, Berkeley has created a real-time operating system to address the priorities of such a sensor network (low power, hardreal-time constraints, robust communications), MIT even recognized wireless sensor networks and TinyOS as one of the ten emerging technologies that will change the future (Technology Review, 1 February 2003). “Wireless Sensor Networks for Habitat Monitoring” (See the Reference section) describes an in-depth study of implementing wireless sensor networks for real-world habitat monitoring using TinyOS and the then current Micamotes.
The first goal of WISENET was to create a new hardware platform to take advantage of newer microcontrollers with greater functionality and more features. This involved selecting the hardware, designing the motes, and porting TinyOS. Once the platform was completed and TinyOS wasported to it, the next stage was to use this platform to create a small-scale system of wireless networked sensors. The purpose of this system was to monitor environmental in the labs and offices in the ECE department at Bradley University.
SYSTEM DESCRIPTION
The overall system block diagram is shown in figure. There were two primary subsystems (Data Analysis and Data Acquisition) comprised of three major components (Client, Server, Sensor Mote Network)
Primary Subsystems:
There were two top-level subsystems Data Analysis and Data Acquisition.
Data Analysis:
This subsystem was software only (relative to WISENET). It relied on existing internet and web (HTTP) infrastructure to provide communications between the Client and Server components. The focus of this subsystem was to selectively present the collected environmental data to the end user in a graphical manner.
FIGURE
Data Acquisition:
The purpose of this subsystem was to collect the store environmental data for later processing by the Data Analysis subsystem. This was a mix of both PC & embedded system software, as well as embedded system hardware. It was composed of both the Server and Sensor Mote Network components.
System Components:
There were three primary system components: Client, Server, and Sensor Mote Network. Each is described below, complete with an input-output clock diagram.
Client :
The Client component was necessary but external to the development of WISENET. That is, any computer with a web browser and Internet access could be a client. It served only as a user interface to the Data Analysis subsystem.
Server :
The Server was a critical component as the link between the Data Acquisition and Data Analysis subsystems. On the Data Analysis side was an web (HTTP) server hosting a web application. When a page request came in, the web server executed the web application, which retrieved data from the database, processed it, and returned a web-page which the web server transmitted to the Client. For the Data Acquisition system there was a daemon (WiseDB) running to facilities communication with the Sensor Mote Network. This daemon was responsible for collecting raw data packets from the Sensor Mote Network. These packets were then processed to convert the raw data into meaningful environmental data. This processed data was then inserted into the database. Thus the database was the link between the Data Analysis and Data Acquisition subsystems. The Server also had the potential to send commands to the Sensor Mote Network (via the gateway mote), although this functionality was not explored in WISENET. It should be noted that since the SQL database connections can be made via TCP/IP, only the web server and web-program (see figure) needed to be located on the same physical machine.
FIGURE
The web server, the database, and WiseDB could all be on different physical machines connected via a LAN or the Internal. This allowed a flexible Server component implementation that was useful during WISENET development.
Sensor Mote (Figure)
The primary focus of WISENET was the development of the Sensor Mote Network component. It was the component responsible for collecting and transmitting raw environmental data to the Server. There was also the potential for the motes to receive commands from the Server, although that functionality was not implemented in WISENET. Uses of this feature would include server based synchronization and wireless network reprogramming.
FIGURE
This component consisted of two parts. The first was the sensor mote. The primary purpose of the sensor mote was to collect and transmit raw environmental data. When not doing this, it went into a low-power idle mode to conserve energy. Another aspect of the sensor motes involved ad-hoc networking and multi-hop routing; however, due to limited resource WISENET was not able to test these functions. See Figure for the block diagram of a standard sensor mote. Specific hardware details will be discussed in the Hardware Design section. The gateway mote was the second part of the Sensor Mote Network. Its purpose was to serve as the liaison between the Server and the Sensor Mote Network and deliver all the data packets to WiseDB. In theory both standard and gateway motes could be implemented on the same hardware PCB and with the same software. For WISENET, however, resource and time constraints necessitated the use of slightly different hardware and software configurations for gateway versus standard motes.
HARDWARE DESIGN
The selection of components for the sensor motes was a critical process in the early development of WISENET. Great functionality and low power were two of the highest priorities in evaluating the fitness of both the microcontroller and the sensor candidates. Thanks to Honeywell, Inc. WISENET was introduced to the new state-of-the-art Chipcon CC1010 microcontroller with integrated RF transceiver. After a little research it was decided the CC1010 could make the perfect microcontroller.
It had the following feature list:
1. Optimized 8051-core
2. Active (14.8mA), Idle (29-a) and sleep (0.2-A) power modes
3. 32 KB flash memory
4. 2kB+128 bytes SRAM
5. Three channel 10-bit ADC
6. Four timers/Two PWMs
7. Hardware DES encryption/decryption
8. Hardware random bit-generator
9. Fully integrated HUF RF trans reciever (433 MHz/868 MHz nominal)
a. Programmable output power (-20 to 10dBm)
b. Low current consumption (11.9 mA for RX, 17.0 mA for TX at 0dBm)
c. RSSI output that can be sampled by the sampled by the on chip ADC
Honeywell generously provided a development kit for WISENET which included a socketed evaluation board (CC1010EB) and two evaluation modules (CC1010EM). The evaluation board provided access to all of the analog and digital pins on the CC1010, as well as two serial ports, a parallel programming port, RF network analysis ports, and other peripherals. Each evaluation module featured the CC1010 RF network required functionality, First, sensirion released the SHT11, a digital temperature and humidity sensor with hardware, an antenna port, and an analog temperature sensor. The modules connected to the evaluation board via two TFM-D sockets. These sockets also allowed the possibility of designing a custom expansion board.
Choosing the sensors involved additional research. WISENET was designed to measure light, temperature, and humidity. There were many digital temperature sensors available, but there was a much smaller selection of digital humidity and light sensors. A larger selection of analog sensors was available; however, analog sensors tended to require more power and be less precise than their digital counterparts, in addition to requiring more complex circuitry. For these reasons, digital sensors were given higher priority. Two new sensors provided the ultra low power consumption (550 _A while measuring, 1 _A when in sleep mode), a 14 bit analog to digital converter, and the desired accuracy (±5% relative humidity, ±30C). It also featured a simple serial interface. The light sensor chosen was the Texas Advanced Optoelectonic Solutions (TAOS) TSL2550 ambient light sensor with SMBus interface. This sensor also featured ultra-low power(600_A active, 10 _A power down), a 12-bit analog to digital converter, and dual photo diodes. The TSL2550 uses both photo diodes to compensate for infrared light and to produce a measurement that approximates the human eye response. Interestingly, both of these sensors were also used on a Mica mote sensor board design by the TinyOS development team.
The final stage of hardware design involved creating the add on module. The final WISENET Add- On Module is shown with attached CC1010EM in figure. The PCB layout was done using Orcad Layout Plus, a program that is part of the standard Orcad Package. The netlist as imported into Layout Plus and then the traces were routed using that software.
The Add-On Module PCB is 2 layers and has a 50 pin TFM-D connector which plugs into the CC1010 evaluation module. The WISENET Add-On Module has the two digital sensors described above. The Sensors SHT 11 humidity and temperature sensor has a 2-wire proprietary serial interface. The TAOS TSL2550 digital light sensor uses an SMBus serial interface. SMBus is a standardized 2-wire serial interface. The layout was carefully designed such that the light, temperature and humidity sensors were not underneath the evaluation module when it was plugged into the board, which would make them useless. The board included a DC-DC converter and battery monitor from Maxim-IC called the Max1676. An RS-232 to CMOS level converter chip, the Max 3221, was added to enable a sensor mote to function as a gateway mote. A jumper was included so that the Max 3221 could be enabled or disabled to save power if a particular mote was not configured to use the serial port. Thee status LED’s were placed on the boardfor troubleshooting purpose. Due to resource and time constraints, through – hole components were used for their availability and case of wiring.
SOFTWARE COMPONENTS-COMMERCIAL OFF THE SHELF PRODUCTS
The server used for WISENET had four commercial off the shelf applications installed on it that worked together to create the Data Analysis portion of the Server component. Apache, MySQL, and PHP are open –source products freely available on the Internet. In addition, Chart Director the trial version of the commercial application Chart-Director was used.
o Apache is a standard web-server which makes a web document available on the Internet.
o PHP is a web programming language which allows dynamic web pages. It is also designed to be used with a database and included many built in functions for interfacing with MySQL.
o MySQL is a database that can contain any type of data and is accessed by a TCP/IP (Internet) call.
o Chart-Director is a program that generates a graph from raw data. It is available in many languages such as PHP, ASP, C++, and others.
The server for WISENET was set up very similarly to the setup described in the tutorial described above. In addition, it used the Chart Director Software. The documentation on how to install Chart Director is available under the documentation folder inside the zip file available at this location (choose the PHP version for Windows)
SOFTWARE COMPONENTS
WISENET was also composed of three custom software components: the web program, WiseDB, and a port of TinyOS. Each of these will be discussed in more detail. WISENET’s web program was written in PHP and utilized the Chart-Director charting software. The web application queried MySQL database for the data in the requested date range, then used Chart Director to generator a graph of that data. A screen shot of the form interface is shown in figure. The interface was self explanatory. The ‘Moteid’ field allowed the data from a single mote to be displayed, or checking the box allowed data from all the motes to be displayed on the graph. Pushing the ‘Generate Graphs’ button showed three graphs on the page (or a text message if there was no data for the date range). Figure shows a screen-shot of a sample graph of temperature data obtained on Feb, 2010. the data was retrieved using built-in functions of PHP. PHP was developed to have tight integration with MySQL, and thus interfacing the two is very simple. An example in of code from PHP is as follows:
Datatyppedesc +mysql_query (SELECT DESCRIPTION from data types WHERE data_type = $data_type);
WISENET DATA RETRIVAL PAGE
FIGURE
The above statement gets the text field contained in the description field that is linked to the data_type field with the quantity equal to a local PHP variable called $data_type. With the exception of the PHP variables (which makes it easier to use), everything contained inside the mysql_query (“”) is SQL standard syntax, and given that the SQL syntax is known, interfacing with the database is very simple.
MOTE DATA VALUES
FIGURE
WiseDB is the custom software component that interfaced with the Sensor Mote Network via a serial link to the gateway mote and with the MySQL database via a TCP/IP link to the MySQL server application. See Figure for more information about how WiseDB interfacted with the rest of the system. WiseDB was written in C++ and utilized two open source API’s (application programming interface). The first API used was MySQL++ for MSVC++. The source for this API was available from MYSQL’s website.
The MySQL++ API allow for a connection to the MySQL database with reasonably simple code. C++ was not as easy to use as PHP, so the code to perform a query is a little less elegant, but still not too complex: query <<”select data_type from data_types where description =”<< description;
Result res=query.store();
Result::iterator I;
I=res.begin();
Row row=*I;
Data_type=row[“data+type”];
The query shown here gets the integer field contained in the data_type field that is linked to the description field with the text matching a local string variable called description. Everything contained inside the mysql_query (“”) is SQL standard syntax, and given that the SQL syntax is known interfacing with the database is somewheat simple. As shown, once the query is performed by the line: Result res=query.store(); an iterator must be used to parse that data stored in the result data block.
The second API used in WiseDB was a C++ serial API written by Ramon Klein. This API allowed a very simple interface to the serial port. An example of code used in Wise DB is shown; serial. Real(&header.packettype,sizeof(unsingedchart));
The packettype variable is passed by reference from the Read function. The above line of code is used to read a character from the serial port. (The size of (unsingned chart) is used to represent the length of a byte) The write operation was just as simple to use. Clearly this API made it easy to use serial communication in a C++ program. The main flow of WiseDB was to wait until a packet was received and then calculate light, temperature, and humidity values from the raw data. These values were then inserted into the MySQL database.
The final custom software component involved porting TinyOS to the CC1010-based hardware platform described in the Hardware Design section. As previously mentioned, TinyOS was a realtime operating system designed for use in sensor network applications where low power, limited resources and hard real-time constraints are critical parameters. See J. Hiill’s Master Thesis (listed in the References Section) for more information about the theory and design of TinyOS. The newest version of TinyOS (1.x) has been re-written using nesC, which is an extension to the C language that is designed based on the structure and core concepts behind TinyOS. For more information about nesC see the nesC Language: A Holistic Approach to Network Embedded Systems in the Reference section.
Language: A Holistic Approach to Network Embedded Systems in the References Section.
Thanks to highly modular architecture of TinyOS, all of the hardware functionality was abstracted in components. Components were then ‘wired’ together to form more complex components and complete applications. See Figure for a diagram of this hierarchical approach. One important goa of WISENET was to completely replace the lower level functionality (the layers enclosed in the dashed-line box in Figure 11) to permit existing higher-level components and applications to be immediately implemented on the new hardware platform without modification. Existing low-level code for the Mica mote was used was used as a template for the CC1010 code where applicable.
One significant component not implemented on the CC1010 was the default radio communications (REM) stack. Instead a newer and more flexible radio communications stack was used. The S-MAC, a medium access control (MAC) protocol designed for sensor networks, featured reduced energy consumption was well as improved scalability and collision avoidance. See An Energy-Efficient MAC Protocol for Wireless Sensor Networks (listed in References) for more information. The SMAC code also featured a compatibility component that allowed applications based on the S-MAC protocol to use the Active Messaging components in TinyOS, ensuring core compatibility with all the communications components.
APPLICATIONS
• Lab/office monitoring
• Spouts field monitoring.
• Security application.
• Extreme weather survey
• Potential medical application.
ADVANTAGES
• Smart power saving process
• Complete hardware design
• Digital Sensors.
• Based on open source software.
DISADVANTAGES
• External battery backup required.
• Code-optimization required.
• Debugger required.
• Multiple mote network slows performance.
FUTURE WORK
There are a number of avenues for future extension of this project.
1. Expand the sensor mote network by adding more motes. This would allow the development and testing of advanced network-layer functions, such as multi-hop routing.
2. Create a new PCB design that integrates the CC1010EM design with the sensors and power hardware on a single board. Another interesting feature would be to develop or adopt a standard expandable plug in sensor interface in both hardware and software.
3. Research alternative energy sources to extend mote battery life. Possibilities include solar cells and rechargeable batteries.
4. Continue the development of TinyOS in general and 8051-based systems in particular. This could include improving the tools or optimizing component code (especially chipcon-supplied library code).
5. Improve web interface – this could take many facets, from simply increasing the flexibility of the charting options to making it more graphical (e.g a map of motes and physical locations) to performing complete data analysis (highs/low, day/week/month/yarly averages, etc.)
CONCLUSION
Wireless sensor networks are getting smaller and faster, increasing their potential applications in commercial, industrial, and residential environments. As the technology improves and new low power digital sensors become more readily available, motes will increases without increasing power consumption and will expand the wireless sensing market.
Every component of the project used. The open nature of the software encourages developer participation and communication. WISENET demonstrate power of wireless tech power of wireless sensor network technology. This is a field that will see tremendous growth in the near future as microcontrollers and sensors improve their performance while lowering their energy consumption.
TinyOS is an operating system designed to meet the needs of wireless sensing applications; its modular design methodology and open source development are keys to its success. Finally, the emphasis on web-based interfaces allows complex graphical user interfaces to be rapidly designed and tested on a variety of platforms, simplifying the end-user experience.
WISENET is a wireless sensor network that monitors the environmental condition (such as light, temperature, and humidity) of labs and offices in Jobst Hall. This network is comprised of nodes called “motes” that form an ad-hoc network to transmit this data to a computer that functions as a server. The server stores the data in a database where it can later be retrieved and analyzed via a web-based interface. The project works successfully with an implementation of one sensor mote.
INTRODUCTION
The technological drive for smaller devices using less power with greater functionality has created new potential applications in the sensor and data acquisition sectors. Low power microcontrollers with RF transceivers and various digital and analog sensors allow a wireless, battery-operated network of sensor modules (“motes”) to acquire a wide range of data. The TinyOS project at University of California, Berkeley has created a real-time operating system to address the priorities of such a sensor network (low power, hardreal-time constraints, robust communications), MIT even recognized wireless sensor networks and TinyOS as one of the ten emerging technologies that will change the future (Technology Review, 1 February 2003). “Wireless Sensor Networks for Habitat Monitoring” (See the Reference section) describes an in-depth study of implementing wireless sensor networks for real-world habitat monitoring using TinyOS and the then current Micamotes.
The first goal of WISENET was to create a new hardware platform to take advantage of newer microcontrollers with greater functionality and more features. This involved selecting the hardware, designing the motes, and porting TinyOS. Once the platform was completed and TinyOS wasported to it, the next stage was to use this platform to create a small-scale system of wireless networked sensors. The purpose of this system was to monitor environmental in the labs and offices in the ECE department at Bradley University.
SYSTEM DESCRIPTION
The overall system block diagram is shown in figure. There were two primary subsystems (Data Analysis and Data Acquisition) comprised of three major components (Client, Server, Sensor Mote Network)
Primary Subsystems:
There were two top-level subsystems Data Analysis and Data Acquisition.
Data Analysis:
This subsystem was software only (relative to WISENET). It relied on existing internet and web (HTTP) infrastructure to provide communications between the Client and Server components. The focus of this subsystem was to selectively present the collected environmental data to the end user in a graphical manner.
FIGURE
Data Acquisition:
The purpose of this subsystem was to collect the store environmental data for later processing by the Data Analysis subsystem. This was a mix of both PC & embedded system software, as well as embedded system hardware. It was composed of both the Server and Sensor Mote Network components.
System Components:
There were three primary system components: Client, Server, and Sensor Mote Network. Each is described below, complete with an input-output clock diagram.
Client :
The Client component was necessary but external to the development of WISENET. That is, any computer with a web browser and Internet access could be a client. It served only as a user interface to the Data Analysis subsystem.
Server :
The Server was a critical component as the link between the Data Acquisition and Data Analysis subsystems. On the Data Analysis side was an web (HTTP) server hosting a web application. When a page request came in, the web server executed the web application, which retrieved data from the database, processed it, and returned a web-page which the web server transmitted to the Client. For the Data Acquisition system there was a daemon (WiseDB) running to facilities communication with the Sensor Mote Network. This daemon was responsible for collecting raw data packets from the Sensor Mote Network. These packets were then processed to convert the raw data into meaningful environmental data. This processed data was then inserted into the database. Thus the database was the link between the Data Analysis and Data Acquisition subsystems. The Server also had the potential to send commands to the Sensor Mote Network (via the gateway mote), although this functionality was not explored in WISENET. It should be noted that since the SQL database connections can be made via TCP/IP, only the web server and web-program (see figure) needed to be located on the same physical machine.
FIGURE
The web server, the database, and WiseDB could all be on different physical machines connected via a LAN or the Internal. This allowed a flexible Server component implementation that was useful during WISENET development.
Sensor Mote (Figure)
The primary focus of WISENET was the development of the Sensor Mote Network component. It was the component responsible for collecting and transmitting raw environmental data to the Server. There was also the potential for the motes to receive commands from the Server, although that functionality was not implemented in WISENET. Uses of this feature would include server based synchronization and wireless network reprogramming.
FIGURE
This component consisted of two parts. The first was the sensor mote. The primary purpose of the sensor mote was to collect and transmit raw environmental data. When not doing this, it went into a low-power idle mode to conserve energy. Another aspect of the sensor motes involved ad-hoc networking and multi-hop routing; however, due to limited resource WISENET was not able to test these functions. See Figure for the block diagram of a standard sensor mote. Specific hardware details will be discussed in the Hardware Design section. The gateway mote was the second part of the Sensor Mote Network. Its purpose was to serve as the liaison between the Server and the Sensor Mote Network and deliver all the data packets to WiseDB. In theory both standard and gateway motes could be implemented on the same hardware PCB and with the same software. For WISENET, however, resource and time constraints necessitated the use of slightly different hardware and software configurations for gateway versus standard motes.
HARDWARE DESIGN
The selection of components for the sensor motes was a critical process in the early development of WISENET. Great functionality and low power were two of the highest priorities in evaluating the fitness of both the microcontroller and the sensor candidates. Thanks to Honeywell, Inc. WISENET was introduced to the new state-of-the-art Chipcon CC1010 microcontroller with integrated RF transceiver. After a little research it was decided the CC1010 could make the perfect microcontroller.
It had the following feature list:
1. Optimized 8051-core
2. Active (14.8mA), Idle (29-a) and sleep (0.2-A) power modes
3. 32 KB flash memory
4. 2kB+128 bytes SRAM
5. Three channel 10-bit ADC
6. Four timers/Two PWMs
7. Hardware DES encryption/decryption
8. Hardware random bit-generator
9. Fully integrated HUF RF trans reciever (433 MHz/868 MHz nominal)
a. Programmable output power (-20 to 10dBm)
b. Low current consumption (11.9 mA for RX, 17.0 mA for TX at 0dBm)
c. RSSI output that can be sampled by the sampled by the on chip ADC
Honeywell generously provided a development kit for WISENET which included a socketed evaluation board (CC1010EB) and two evaluation modules (CC1010EM). The evaluation board provided access to all of the analog and digital pins on the CC1010, as well as two serial ports, a parallel programming port, RF network analysis ports, and other peripherals. Each evaluation module featured the CC1010 RF network required functionality, First, sensirion released the SHT11, a digital temperature and humidity sensor with hardware, an antenna port, and an analog temperature sensor. The modules connected to the evaluation board via two TFM-D sockets. These sockets also allowed the possibility of designing a custom expansion board.
Choosing the sensors involved additional research. WISENET was designed to measure light, temperature, and humidity. There were many digital temperature sensors available, but there was a much smaller selection of digital humidity and light sensors. A larger selection of analog sensors was available; however, analog sensors tended to require more power and be less precise than their digital counterparts, in addition to requiring more complex circuitry. For these reasons, digital sensors were given higher priority. Two new sensors provided the ultra low power consumption (550 _A while measuring, 1 _A when in sleep mode), a 14 bit analog to digital converter, and the desired accuracy (±5% relative humidity, ±30C). It also featured a simple serial interface. The light sensor chosen was the Texas Advanced Optoelectonic Solutions (TAOS) TSL2550 ambient light sensor with SMBus interface. This sensor also featured ultra-low power(600_A active, 10 _A power down), a 12-bit analog to digital converter, and dual photo diodes. The TSL2550 uses both photo diodes to compensate for infrared light and to produce a measurement that approximates the human eye response. Interestingly, both of these sensors were also used on a Mica mote sensor board design by the TinyOS development team.
The final stage of hardware design involved creating the add on module. The final WISENET Add- On Module is shown with attached CC1010EM in figure. The PCB layout was done using Orcad Layout Plus, a program that is part of the standard Orcad Package. The netlist as imported into Layout Plus and then the traces were routed using that software.
The Add-On Module PCB is 2 layers and has a 50 pin TFM-D connector which plugs into the CC1010 evaluation module. The WISENET Add-On Module has the two digital sensors described above. The Sensors SHT 11 humidity and temperature sensor has a 2-wire proprietary serial interface. The TAOS TSL2550 digital light sensor uses an SMBus serial interface. SMBus is a standardized 2-wire serial interface. The layout was carefully designed such that the light, temperature and humidity sensors were not underneath the evaluation module when it was plugged into the board, which would make them useless. The board included a DC-DC converter and battery monitor from Maxim-IC called the Max1676. An RS-232 to CMOS level converter chip, the Max 3221, was added to enable a sensor mote to function as a gateway mote. A jumper was included so that the Max 3221 could be enabled or disabled to save power if a particular mote was not configured to use the serial port. Thee status LED’s were placed on the boardfor troubleshooting purpose. Due to resource and time constraints, through – hole components were used for their availability and case of wiring.
SOFTWARE COMPONENTS-COMMERCIAL OFF THE SHELF PRODUCTS
The server used for WISENET had four commercial off the shelf applications installed on it that worked together to create the Data Analysis portion of the Server component. Apache, MySQL, and PHP are open –source products freely available on the Internet. In addition, Chart Director the trial version of the commercial application Chart-Director was used.
o Apache is a standard web-server which makes a web document available on the Internet.
o PHP is a web programming language which allows dynamic web pages. It is also designed to be used with a database and included many built in functions for interfacing with MySQL.
o MySQL is a database that can contain any type of data and is accessed by a TCP/IP (Internet) call.
o Chart-Director is a program that generates a graph from raw data. It is available in many languages such as PHP, ASP, C++, and others.
The server for WISENET was set up very similarly to the setup described in the tutorial described above. In addition, it used the Chart Director Software. The documentation on how to install Chart Director is available under the documentation folder inside the zip file available at this location (choose the PHP version for Windows)
SOFTWARE COMPONENTS
WISENET was also composed of three custom software components: the web program, WiseDB, and a port of TinyOS. Each of these will be discussed in more detail. WISENET’s web program was written in PHP and utilized the Chart-Director charting software. The web application queried MySQL database for the data in the requested date range, then used Chart Director to generator a graph of that data. A screen shot of the form interface is shown in figure. The interface was self explanatory. The ‘Moteid’ field allowed the data from a single mote to be displayed, or checking the box allowed data from all the motes to be displayed on the graph. Pushing the ‘Generate Graphs’ button showed three graphs on the page (or a text message if there was no data for the date range). Figure shows a screen-shot of a sample graph of temperature data obtained on Feb, 2010. the data was retrieved using built-in functions of PHP. PHP was developed to have tight integration with MySQL, and thus interfacing the two is very simple. An example in of code from PHP is as follows:
Datatyppedesc +mysql_query (SELECT DESCRIPTION from data types WHERE data_type = $data_type);
WISENET DATA RETRIVAL PAGE
FIGURE
The above statement gets the text field contained in the description field that is linked to the data_type field with the quantity equal to a local PHP variable called $data_type. With the exception of the PHP variables (which makes it easier to use), everything contained inside the mysql_query (“”) is SQL standard syntax, and given that the SQL syntax is known, interfacing with the database is very simple.
MOTE DATA VALUES
FIGURE
WiseDB is the custom software component that interfaced with the Sensor Mote Network via a serial link to the gateway mote and with the MySQL database via a TCP/IP link to the MySQL server application. See Figure for more information about how WiseDB interfacted with the rest of the system. WiseDB was written in C++ and utilized two open source API’s (application programming interface). The first API used was MySQL++ for MSVC++. The source for this API was available from MYSQL’s website.
The MySQL++ API allow for a connection to the MySQL database with reasonably simple code. C++ was not as easy to use as PHP, so the code to perform a query is a little less elegant, but still not too complex: query <<”select data_type from data_types where description =”<< description;
Result res=query.store();
Result::iterator I;
I=res.begin();
Row row=*I;
Data_type=row[“data+type”];
The query shown here gets the integer field contained in the data_type field that is linked to the description field with the text matching a local string variable called description. Everything contained inside the mysql_query (“”) is SQL standard syntax, and given that the SQL syntax is known interfacing with the database is somewheat simple. As shown, once the query is performed by the line: Result res=query.store(); an iterator must be used to parse that data stored in the result data block.
The second API used in WiseDB was a C++ serial API written by Ramon Klein. This API allowed a very simple interface to the serial port. An example of code used in Wise DB is shown; serial. Real(&header.packettype,sizeof(unsingedchart));
The packettype variable is passed by reference from the Read function. The above line of code is used to read a character from the serial port. (The size of (unsingned chart) is used to represent the length of a byte) The write operation was just as simple to use. Clearly this API made it easy to use serial communication in a C++ program. The main flow of WiseDB was to wait until a packet was received and then calculate light, temperature, and humidity values from the raw data. These values were then inserted into the MySQL database.
The final custom software component involved porting TinyOS to the CC1010-based hardware platform described in the Hardware Design section. As previously mentioned, TinyOS was a realtime operating system designed for use in sensor network applications where low power, limited resources and hard real-time constraints are critical parameters. See J. Hiill’s Master Thesis (listed in the References Section) for more information about the theory and design of TinyOS. The newest version of TinyOS (1.x) has been re-written using nesC, which is an extension to the C language that is designed based on the structure and core concepts behind TinyOS. For more information about nesC see the nesC Language: A Holistic Approach to Network Embedded Systems in the Reference section.
Language: A Holistic Approach to Network Embedded Systems in the References Section.
Thanks to highly modular architecture of TinyOS, all of the hardware functionality was abstracted in components. Components were then ‘wired’ together to form more complex components and complete applications. See Figure for a diagram of this hierarchical approach. One important goa of WISENET was to completely replace the lower level functionality (the layers enclosed in the dashed-line box in Figure 11) to permit existing higher-level components and applications to be immediately implemented on the new hardware platform without modification. Existing low-level code for the Mica mote was used was used as a template for the CC1010 code where applicable.
One significant component not implemented on the CC1010 was the default radio communications (REM) stack. Instead a newer and more flexible radio communications stack was used. The S-MAC, a medium access control (MAC) protocol designed for sensor networks, featured reduced energy consumption was well as improved scalability and collision avoidance. See An Energy-Efficient MAC Protocol for Wireless Sensor Networks (listed in References) for more information. The SMAC code also featured a compatibility component that allowed applications based on the S-MAC protocol to use the Active Messaging components in TinyOS, ensuring core compatibility with all the communications components.
APPLICATIONS
• Lab/office monitoring
• Spouts field monitoring.
• Security application.
• Extreme weather survey
• Potential medical application.
ADVANTAGES
• Smart power saving process
• Complete hardware design
• Digital Sensors.
• Based on open source software.
DISADVANTAGES
• External battery backup required.
• Code-optimization required.
• Debugger required.
• Multiple mote network slows performance.
FUTURE WORK
There are a number of avenues for future extension of this project.
1. Expand the sensor mote network by adding more motes. This would allow the development and testing of advanced network-layer functions, such as multi-hop routing.
2. Create a new PCB design that integrates the CC1010EM design with the sensors and power hardware on a single board. Another interesting feature would be to develop or adopt a standard expandable plug in sensor interface in both hardware and software.
3. Research alternative energy sources to extend mote battery life. Possibilities include solar cells and rechargeable batteries.
4. Continue the development of TinyOS in general and 8051-based systems in particular. This could include improving the tools or optimizing component code (especially chipcon-supplied library code).
5. Improve web interface – this could take many facets, from simply increasing the flexibility of the charting options to making it more graphical (e.g a map of motes and physical locations) to performing complete data analysis (highs/low, day/week/month/yarly averages, etc.)
CONCLUSION
Wireless sensor networks are getting smaller and faster, increasing their potential applications in commercial, industrial, and residential environments. As the technology improves and new low power digital sensors become more readily available, motes will increases without increasing power consumption and will expand the wireless sensing market.
Every component of the project used. The open nature of the software encourages developer participation and communication. WISENET demonstrate power of wireless tech power of wireless sensor network technology. This is a field that will see tremendous growth in the near future as microcontrollers and sensors improve their performance while lowering their energy consumption.
TinyOS is an operating system designed to meet the needs of wireless sensing applications; its modular design methodology and open source development are keys to its success. Finally, the emphasis on web-based interfaces allows complex graphical user interfaces to be rapidly designed and tested on a variety of platforms, simplifying the end-user experience.
Comments
Post a Comment