Page 1 of 126
Cumulative Report Document
Web Based Ajax Enabled SQL Query Utility
for
XBee Wireless Sensor Array System
Henry T. Grimmick
CEN 4935 Spring 2009
Dr. Janusz Zalewski
Page 2 of 126
Table of Contents
1 Introduction 5
2 Problem Description 7
3 Software Requirements Specification 9
3.1 Purpose 9
3.2 Scope 9
3.3 Definitions 11
3.4 Overview 11
3.5 Description 12
3.6 Product Perspective 13
3.7 Utility Functions 15
3.8 User Characteristics 15
3.9 Requirements 16
3.10 External Interface Requirements 16
3.11 Input Requirements 16
3.12 Output Requirements 19
3.13 Non-Functional Requirements 19
3.14 Design Constraints 19
4 Software Design Description 21
4.1 Purpose 21
4.2 Scope 21
4.3 Definitions 22
4.4 Module Decomposition 23
4.5 SQL Table Presentation Module 23
4.6 SQL Field Presentation Module 25
4.7 Value Presentation and Validation Module 25
4.8 Query Submit Module 26
4.9 Query Display Module 26
4.10 Interface Decomposition 27
4.11 Interface Description 27
4.12 Screen Images 27
Page 3 of 126
5 Implementation 29
6 Testing 59
7 Conclusion 65
Appendix A. Prototype Source Code Processing Loop Module 67
Appendix B. Source Code Examples Sensor Query Modules 69
Appendix C. Faircom Supported JDBC Metadata Methods 80
Appendix D. Common JDBC Methods Not Supported in FairCom JDBC 93
Appendix E. Source Code Example Web Based SQL Query Utility 96
Appendix F. Users Manual 107
Appendix G. References 126
Page 4 of 126
This page intentionally left blank.
Page 5 of 126
1. Introduction
In the previous project paper Serial Based Wireless Sensor Arrays for Use in
Construction, Land Surveying and Agriculture [1] we introduced a system of wireless
sensor arrays which collected various soil, plant moisture and atmospheric readings on a
periodic basis and submitted these readings to an SQL database system.
Fig 1 System Overview Diagram
Figure 1 summarizes the wireless sensor array system developed in this project. A central
computer located in a main facility houses both the data acquisition program and the SQL
database engine. Attached to this central computer is the Xbee Pro Base Unit which is a
2.4ghz transceiver. The Base Unit communicates with a single Xbee Pro Remote Unit at
Page 6 of 126
a time by switching communication channels to that of the desired remote unit. With the
proper antennas communication between the Xbee Pro Base and Remote unit can be
achieved from up to one mile away. Once communications between the Base and Remote
unit has been established, a virtual RS-232 serial port is emulated allowing for direct
communication to a serial device attached to the Xbee Pro Base unit. For this system the
1-Wire DS9097U serial to 1-Wire Network adapter was attached to each Xbee Pro Base
unit. Attached to each DS9097U were various, weather, soil moisture and plant moisture
sensors which used the 1-Wire communication protocol.
At regularly scheduled intervals, the data acquisition software located on the central
computer would initiate communications with the desired Xbee Pro Remote unit, open
the serial link between the base and remote units, activate the 1-Wire DS9097U serial to
1-Wire network adapter, query each of the sensors attached to the DS9097U and record
these values to the SQL database for future analysis. This future analysis was envisioned
to be achieved by allowing remote access to the database by a third party GIS system
where the data would be queried on a regular basis to help provide the agricultural
operator with a complete picture of the operation to assist in determining irrigation needs
and crop performance.
Page 7 of 126
2. Problem Description
While the Xbee based data acquisition system was stable and reliable, it was only a self
contained one-way system which pulled data from the remote sensor array and recorded
the readings from the sensor units to a SQL database. There was no facility to control the
flow of the readings from each sensor array nor was there any ability to present the data
to the system user in a meaningful format. All access to the data was designed on a pull
basis from a third party GIS system where it would be integrated with other related data
and then presented to the user or via an ODBC connection to the system database engine.
However as the data needed to be pulled from the system and manipulated by a third
party, there was a realistic probability that once the data finally made it back to the field
operator, it was outdated as field conditions may have changed significantly during the
time it took to process the report.
What was needed in this system was the addition of a real time reporting, status and
control module. Additionally this module should be accessible from the Internet not only
from the standpoint of convenience for the operator, such that they do not need to
physically go directly to the central computer system but also for instantaneous access to
the data wherever the operator may be located.
The goal of this project is to produce a web based reporting and control utility designed
for use by a non-technical operator. The utility should facilitate ease of reporting by the
end user and prevent the end user from entering query selections which are invalid. The
utility should also have the look and feel of a real time desktop application and not the
Page 8 of 126
look and feel of a typical block mode web application. To achieve this functionality,
Ajax technologies will be used.
Ajax, Asynchronous Java and XML, is a blending of several programming techniques
which allows developers to create web based applications that have more of a real time
application behavior rather than the historical static web page look and feel. Rather than
having to redraw the entire web page between user operations, Ajax inserts an additional
layer between the user’s browser and the web server which handles communications in
the background that handles submitting server requests and processing the returned data.
The Ajax processing is what allows new elements, components or data to be displayed in
a web page or application without having to redraw the entire page. Besides a smoother
user experience, a secondary advantage of Ajax is that a well written Ajax application
will prevent unnecessary graphics and other elements of a web page from being
repeatedly downloaded from the web server, thus reducing bandwidth requirements of the
web application. [2]
Page 9 of 126
3. Software Requirements Specification
3.1 Purpose
The purpose of this document is to present the reader with detailed requirements for the
Web Based Ajax Enabled SQL Query Utility. This document explains the purpose and
features of the utility, the connections of the utility to the XBee Wireless Sensor Array
System, the behavior of the utility and the requirements for the utility to function
correctly. This document is intended for both the end user of the utility and the technical
staff responsible for installing, configuring and supporting the utility.
3.2 Scope
The XBee Wireless Sensor Array System is designed to provide the manager of an
agricultural facility real-time statistics on atmospheric conditions, soil moisture and plant
moisture. This data is stored in an SQL compliant database for reporting and analysis.
Page 10 of 126
3.3 Definitions
Grid Object: A table containing data elements presented to the user in a grid like fashion.
Similar to the data formatting used in an Excel spreadsheet
SQL: A programming language for querying and modifying data and managing
databases.
AJAX: Asynchronous JavaScript and XML), or AJAX, is a group of interrelated web
development techniques used for creating interactive web applications or rich Internet
applications.
XBee: An lo power wireless networking technology, Zigbee is designed for wireless
automation and other and remote monitoring.
Utility: Refers to the software designated in the SRS document which performs data
acquisition and control functions on the XBee Wireless Sensor Array System.
Result Set: The set of rows from a database, as well as details about the query such as the
column names, and the types and sizes.
Page 11 of 126
3.4 Overview
Section two, the Description section, gives an overview of the features and behavior of
the utility. This section describes the informal requirements of the utility and is as an
overview for the technical requirements specification in the section three.
Section three, the Requirements section, is written primarily for the technical and support
staff and describes in detailed terms the technical information of the utility.
Page 12 of 126
3.5 Description
This utility will be a Web Based Ajax Enabled SQL Query Utility to connect to the XBee
Wireless Sensor Array System. This utility will be designed to allow the user to quickly
query and sort data collected by the XBee Wireless Sensor Array System, which
normally would be performed manually using external system components such as
Microsoft Excel or Crystal Reports. By eliminating the need for expensive third party
software the utility will allow the end user sorting and reporting capability while reducing
expenses.
Specifically, this utility is designed to for a low skilled field operator to retrieve sensor
readings from the XBee Wireless Sensor Array System SQL database in order to
determine field conditions and trends.
Page 13 of 126
3.6 Product Perspective
Figure 2. XBee Wireless Sensor Array Network
Page 14 of 126
The utility is downloaded and activated on the Client PC [Fig. 2] when the end user
connects to the Web Server connected to the XBee Wireless Sensor Array System. When
the client browser connects across the Internet through the System Firewall to Web
Server a small Java applet is downloaded to the Client PC. This small applet initializes
connectivity between the Web Server and SQL Database Server and allows the end user
query and sorting functionality in a grid based object. [Fig. 3] The utility shall not
support computation options at this release.
Figure 3. Connectivity between the Utility and the XBee Wireless Sensor Array System
Servers
Page 15 of 126
3.7 Utility Functions
The section summarizes the major functions of the utility. The utility will perform the
following:
• Establish an SQL connection to the system SQL server.
• Provide user suggestion during data entry. Similar to that of Google Suggest
• Allow the user to query data by sensor, range of sensors or by values recorded by
sensors.
• Allow the user to control the sensor polling interval time of the XBee Wireless
Sensor Array System.
3.8 User Characteristics
The utility is designed for unskilled staff with minimal expertise in SQL. The utility will
provide the user with a limited set of options and not allow free form entry of query
requests.
Page 16 of 126
3.9 Requirements
The utility shall allow the end user the ability to query the XBee Wireless Sensor Array
System database, provide data reporting capabilities and control capabilities.
3.10 External Interface Requirements
The utility communicates directly with the Web Server and SQL Database Server of the
XBee Wireless Sensor Array System only. [Fig 4]
Fig. 4 Connection logic between end user and system servers.
3.11 Input Requirements
3.2.1 The utility shall accept input from the user through the use of selection lists which
display the primary field to query and radio buttons for the sorting sequence.
3.2.2 The selection list shall include the field names from the SensorData table of the
Xbee Wireless Sensor Array System.
Page 17 of 126
3.2.3 The utility shall use SQL (Structured Query Language) to communicate with the
system database.
3.2.2 The utility shall sort the returned data by the first column in the grid object and
have a radio button to change the sequence of the data between ascending and descending
order based upon the first column.
3.2.3 The utility shall use a pull down select menu [Fig. 5] to allow the user to choose the
field from the database to display in the grid object. This is equivalent to the select field
in an SQL query.
3.2.3 The utility shall use a pull down select menu [Fig. 5] to allow the user to choose the
field from the database to filter in the SQL query. This is equivalent to the where field in
an SQL query.
3.2.3 The utility will use a pull down select menu [Fig. 5] to allow the user to choose the
field from the database to sort in the SQL query. This is equivalent to the order by field in
an SQL query.
3.2.4 The utility shall to connect only to the SQL server of its parent XBee Wireless
Sensor Array System. The connection information and login credentials are set from
within the utility and can not be changed by the end user.
Page 18 of 126
Fig 5. Representation of utility in Browser
Page 19 of 126
3.12 Output Requirements
3.3.1 The utility shall return the result set from the SQL server into a formatted grid
object.
3.3.2 The grid object shall not be resizable but shall instead have page forward and page
back scrolling capability.
3.13 Non-Functional Requirements
Security issues are not addressed at the utility level but are left to that of the Web Server
and/or Network Firewall administrator.
3.14 Design Constraints
The utility is required to run on a Microsoft Windows IIS based Web Server and use the
Faircom JDBC SQL driver for connectivity to the back end database engine server
running Faircom cTree SQL.
Page 20 of 126
*** End of the SRS **
Page 21 of 126
4. Software Design Description
4.1 Purpose
The Web Based Ajax Enabled SQL Query Utility is a Java applet the runs in a standard
Internet web browser. It accepts and validates user input to assist the user in building up a
standard SQL query for reporting from the Faircom SQL database engine which is the
datastore for the XBee Wireless Sensor Array System.
While the functions in the project could have been hard coded into the applet it was
decided to use AJAX technologies to provide the user with a more real-time user
experience. If the functions in the application were hard coded the developer would have
to update the applet each time a new table or field was added to the back end SQL
database. The use of AJAX technologies in this applet negate the need for the developer
to constantly modify the applet to display the new tables or fields.
4.2 Scope
The XBee Wireless Sensor Array System is designed to provide the manager of an
agricultural facility real-time statistics on atmospheric conditions, soil moisture and plant
moisture. This data is stored in an SQL compliant database for reporting and analysis.
The Web Based Ajax Enabled SQL Query Utility is a Java based reporting tool designed
to assist the end user with basic reporting and control functions within the XBee Wireless
Sensor Array System.
Page 22 of 126
4.3 Definitions
Grid Object: A table containing data elements presented to the user in a grid like fashion.
Similar to the data formatting used in an Excel spreadsheet
SQL: A programming language for querying and modifying data and managing
databases.
AJAX: Asynchronous JavaScript and XML), or AJAX, is a group of interrelated web
development techniques used for creating interactive web applications or rich Internet
applications.
XBee: An lo power wireless networking technology, Zigbee is designed for wireless
automation and other and remote monitoring.
Utility: Refers to the software designated in the SRS document which performs data
acquisition and control functions on the XBee Wireless Sensor Array System.
Result Set: The set of rows from a database, as well as details about the query such as the
column names, and the types and sizes.
Page 23 of 126
4.4 Module decomposition
4.5 SQL Table Presentation Module
The SQL Table Presentation Module returns the list of available tables from the XBee
Wireless Sensor Array System SQL server. The list of available tables is accessed from a
pull down menu inside the Web Based Ajax Enabled SQL Query Utility user interface.
Selecting a table from the list is the equivalent of creating the FROM statement in an
SQL query. [Fig. 6]
Fig. 6. SQL Table Presentation Module
Page 24 of 126
4.6 SQL Field Presentation Module
The SQL Table Presentation Module sends the currently selected table to the SQL server
and requests the associated fields for the table. A list of the available fields for the
requested table is returned from the SQL server. The list of available fields is accessed
from a pull down menu inside the Web Based Ajax Enabled SQL Query Utility user
interface. Selecting a field from the list is the equivalent of creating the WHERE
statement in an SQL query. [Fig. 7] This same module is used in the field selection table
for the SORT By sequence of the query.
Figure 7 SQL Field Presentation Module
Page 25 of 126
4.7 Value Presentation and Validation Module
The Value Presentation and Validation Module monitors the data being entered in the
query TO, FROM ranges in the user interface. As the user enters data into these fields the
Value Presentation and Validation Module uses Ajax technologies to dynamically query
the SQL server and present the user with validated values as they key in the data. [Fig 8]
Fig. 8. Value Presentation and Validation Module
Page 26 of 126
4.8 Query Submit Module
The Query Submit Module takes the data from the Table Presentation, Field Presentation
and Value Presentation modules, builds up the SQL query string and submits it to the
SQL server for processing. [Fig. 9]
Figure 9 Query Submit Module
4.9 Query Display Module
The Query Display Module receives the SQL result set from the SQL server and is
responsible for displaying the data in the user interface. [Fig. 10]
Fig. 10 Query Display Module being returned a result set for display.
Page 27 of 126
4.10 Interface Decomposition
4.11 Interface Description
The user interface will be implemented as a Java applet which is loaded to the user’s
browser via the built in web server of the XBee Wireless Sensor Array System. The
applet contains the required connection information to the SQL server and no additional
user interface is required to establish a data connection to the SQL server. The interface
contains a number of selection fields to allow the user to build up their reporting criteria,
a two buttons to scroll through the result set in the grid display area. [Fig. 11]
4.1.12 Screen Images
Fig 11 Representative screen image of query utility.
Page 28 of 126
End of SDD
Page 29 of 126
5. Implementation
The first step in the implementation is to develop prototype code to use Ajax technologies
to query the value of one know field in the last row of a known table in the Xbee
Wireless Sensor Array database. The field should be queried and the result should be
displayed on the web page in such a manner that only the portion of the web page which
contains the SQL result set is redrawn. This code will be built upon the existing reporting
tool produced in the prior project. [Fig. 12.]
Fig. 12 SQL Reporting Tool From Prior Project
Page 30 of 126
Migration of Development Area:
The Xbee Wireless Sensor Array project has been developed over multiple semesters
using multiple operating systems and multiple personal computers. Additionally multiple
Java version updates, API updates and database engine updates have occurred over the
life of the project.
Two critical issues have been discovered when attempting access components of the
Xbee Wireless Sensor Array project for the development of the SQL query utility. The
codebase from the prior semester was restored from archive, the Xbee RF modules and 1-
Wire sensor arrays were attached to the development computer and a test cycle was
performed with the following items verified.
• The database engine could be started and was listening on TCP port 6597.
• The database tables were accessible in both read and write modes using both the
Faircom ODBC and JDBC drivers.
• The Xbee modules were accessible via the manufacturers test utility.
• The 1-Wire modules were accessible via the manufactures test utility.
• The Xbee modules could be accessed using the prototype code from the prior
project.
• AT commands were being sent properly by the serialIO.com Java serial port
driver.
• The 1-Wire modules could be accessed using the prototype code from the prior
project.
• Access to the system via the Web failed. [Fig. 13]
Page 31 of 126
Fig.13. Failure of Web Access to the System Database
This error poses a significant problem as web access to the system is a major design
component. Agricultural staff must be able to have real time access to the field conditions
and not be required to return to a central computer to query information and status.
To insure that this was not an isolated incident the entire Xbee Wireless Sensor Array
System, development area, manufacturer utilities, and required libraries were transferred
to a second Windows XP based computer. The same diagnostic steps as on the primary
Page 32 of 126
system were performed and unfortunately the same error result was returned when
attempting to access the system via the web interface.
When comparing both personal computer platforms it was discovered that both of the XP
platforms had automatic updates enabled and had been upgraded to Windows XP Service
Pack 3. At the completion of the initial prototype web client it was noted and confirmed
that the main development system was at Windows XP Service Pack 2.
To further diagnose the error condition, the original Windows 2000 Professional based
development system was recovered from archive and an entire copy of the project was
transferred to the system. It was confirmed that access to the database via the web was
possible. Initially this indicates that the problem may be related to updates to the
Windows XP base operating system since the initial development of the prototype web
utility. Unfortunately it was also discovered that the current code base, libraries and
API’s could not be used on the Windows 2000 Professional based system as the version
of Java on the machine at this time was out of date and not compatible with the current
libraries. While it may be possible to fail back to this system for project development it
will not be investigated at this time as the base operating system is considered outdated
technology and is no longer supported by the manufacturer.
To further diagnose the condition encountered, an attempt was made to run the applet
code directly from the embedded applet viewer functionality in the IDE used throughout
the entire project. As shown in Fig. 14, the applet viewer was able to run the web query
Page 33 of 126
program, connect to the database without error and return a value queried from the
system database. This indicates possible security or behavior level changes in the
operating system at the browser level.
Fig. 14 Applet Viewer executing web query utility without error
A technical support case was reported to FairCom Corporation regarding this condition
and at the time of this writing there has not been any resolution.
Page 34 of 126
Resolution of Thread Creation Issue:
Through continued diagnostics and with the assistance of FairCom Corporation, this issue
was finally resolved. It was discovered that on both the primary development machine
and the university shared student development system, that the Java runtime had been
updated. Updating the Java runtime caused the default security file used, java.policy, to
be replaced. For the original prototype web query system a modified version of the
java.policy file was used with permitted unrestricted access by Java web applets on the
local machine. During the update process of the Java runtime this file was replaced and
default applet security was enabled. To continue with the testing process the new
java.policy was modified as in Figure 15. The standard “grant codebase” section was
replaced with a global “grant” section allowing all permissions for the Java runtime.
Fig. 15 Modified java.policy security file
Page 35 of 126
What is AJAX?:
AJAX is an acronym for Asynchronous JavaScript and XML. In itself it is not a true
unique technology as it mixes common programming techniques in an uncommon way to
enable web programmers to develop internet based applications with a user experience
much more similar to a real time desktop application versus a block mode web page
application. (2)
AJAX integrates into a web based application in a number of ways or concepts. First,
AJAX can be used as a display management technology where only the required or
changed components of a web page are reloaded as the user navigates the site. Objects
and text that are unchanged are not updated when using AJAX in this manner. Current
web page development technologies require that the entire web page be sent back out to
the user’s browser. This increases the response time and bandwidth requirements of not
only the user but also the web site provider as unnecessary components are continuously
resent to the user.
AJAX can also integrate into a web application as a middle layer between the user’s
browser and the site web server. This middle layer handles server communications in the
background, submitting server requests and processing the returned data. These results
can be integrated into the page currently being viewed by the user without the entire page
needing to be refreshed or a resulting page with shared components entirely reloaded.
Page 36 of 126
To provide a the user a more desktop application look and feel, the use of Ajax
components will be evaluated for use in this project.
Page 37 of 126
Enhancement of Prototype Web Query Utility
In the section we look at the enhancement of the original prototype web based query
utility. [Fig. 16.]
Figure 16. Original Prototype Web Query Utility
The original utility required the user to first manually establish a connection to the
FairCom database engine and then manually execute a fixed SQL query. While this
prototype proved that developing such an application was possible the multiple manual
steps, antiquated interface and lack of flexibility for user queries left this design criteria
undesirable.
Page 38 of 126
What was needed, as described in the original SDD was a flexible query utility that
allowed the user to select data from tables as required and present that data in a readable
format. [Fig. 17]
Figure 17. Proposed user interface from System Design Document
Unexpected Real World Feedback
A unique opportunity presented itself during the development of this project as access
was granted, a meeting and prototype demonstration, to a local palm tree grower was
granted. The grower expressed positive feedback regarding the wireless sensor arrays and
advised that in their environment a sensor array in an enclosure mounted on a post in the
field would not present a problem with harvesting or farm equipment as tree harvesting is
a one by one operation and the equipment could be easily avoided unlike harvesting corn
or wheat where the entire field is harvested quickly be large mechanized equipment. The
grower also expressed that it would be very unlikely to have a condition where an entire
Page 39 of 126
field would be harvested and the remaining soil would be regarded, forcing removal of or
damage to the sensor arrays, as there extensive irrigation lines spread throughout the
field. Normal operation of the palm farm involves a constant cycle of tree harvesting and
immediate replanting.
The grower also expressed interest in the system’s ability to track and maintain large
amounts of data in the SQL database. This would allow the grower to track long term
conditions and trends, giving the grower the ability to forecast future field and weather
conditions.
What was surprising was the lack of acceptance for the design of both the original web
based prototype and the proposed version from the SDD. The grower presented the
following concerns:
• Access to a computer with a web browser was required by unskilled farm staff.
• Web browsing is not permitted at the grower and is blocked in the network level.
• Javascript is disabled on systems at the corporate network
• A web based applet may not work on multiple moble devices.
• Flexibility in the SQL queries would not be required as staff would not have the
database or SQL experience.
• Query selections should be “canned” and accessible only from buttons not
freeform entry. Queries such as the following would be preferred:
o Where is it the hottest?
o Where is it the coolest?
Page 40 of 126
o Where is it the driest?
o Where is it the wettest?
The grower advised that as the system incorporated a standard SQL database with an
ODBC client included, a standard off the shelf ODBC report tool could be used to
perform advanced queries and analysis. The grower advised that in their operation a
simple Java applet, installed locally on a device or downloaded and executed on the client
device would be a preferred method in their environment.
Additionally it should be noted that the change this logic would negate the requirement of
having to manually modify the java.policy on each client PC. The would require that each
time a Java runtime was updated someone would need to manually reconfigure the
device.
Page 41 of 126
Page 42 of 126
Development of the Java Applet Based Upon Real World Feedback
In this section we look at the development of a GUI Java applet based upon the real
world feedback from a local palm tree grower. The utility will address the concerns given
by the palm grower and attempt to provide a simple, self contained reporting tool that
does not require local user knowledge of the database, its structure and complex SQL
query syntax.
In addition to the simplicity requirements presented by the grower, the utility should also
provide error handling capability for events such as, connectivity issues, login/password
issues, query syntax issues, query function/driver issues and also system timeout issues.
The query utility uses Java Swing graphics technologies in order to provide a more
operating system look and feel to the end user.
The first phase of development was to establish a connection to the SQL database,
perform a static query and support error handling. Figure 18 shows the first
implementation of the utility.
Page 43 of 126
Figure 18. Version 2 of the Query Utility
This version of the utility uses standard JDBC connection and query functions and
supports expected features of automatically sizing and presenting the number of columns
based upon the data queried by the user. In the example above note that as the user
performed a “Select *” query all five columns from the sensor data table are presented. If
the user explicitly defines the columns to query the appropriate number of columns are
presented in the utility as seen in Figure 19 below.
Figure 19. Query performed with only two columns selected.
Page 44 of 126
Error handling was also introduced in this version of the utility. In the examples below
the user has attempted to query a column in a table which does not exist. [Fig. 20]
Figure 20. Example of error handling for query of a column in a table that does not exist.
Page 45 of 126
The query utility also supports error handling for SQL syntax errors entered by the user.
[Fig. 21]
Figure 21 Example of syntax error handling
At application startup the utility supports error handling in the event the utility can not
connect to the system database. [Fig. 22]
Figure 22. Utility unable to connect to system database.
Page 46 of 126
The utility supports error handling for incorrect login credentials and database access.
Although these functions are not part of the final design, handling these error conditions
were useful in the development and testing process. [Fig. 23]
Figure 23. Bad login credentials passed to the SQL server.
While the FairCom JDBC driver supports standard JDBC connectivity methods it was
discovered that the JDBC driver from FairCom is lacking in some of the expected
functions that exist in more mature drives. Specifically the FairCom driver is lacking the
ability to use resultSet.last() function which allows the developer to move to the end of
the result set in order to interrogate the number of rows in the result set. This logic was
used to determine the number of times to execute the routine to process loading the result
set into the table of utility. This design logic was based off of standard JDBC drivers such
as MySQL, Oracle SQL, and MSSQL. However it was discovered that the FairCom
JDBC driver returns the result set in using non-standard logic by returning the result set
in an array. To process the contents of the array, FairCom recommends using a while
loop. [Fig. 24] While this approach may work, it should be noted that it is quiet
cumbersome as the size of the array may change based upon the number of columns
queried by the user.
Page 47 of 126
// Fetch the data from the query result set
while (rs.next()) { System.out.println(" " + rs.getString(1) + " " + rs.getString(5)); }
Figure 24. Code Example from FairCom showing result set returned as an array.
To confirm that indeed a valid result set was being returned, code to display the result set
to the console was added to the utility. This code will be removed once a resolution to the
issue with returning a result set as an array is resolved. [Fig. 25]
Figure 25. Debug window showing result set returned properly but not being displayed in
the utility.
Page 48 of 126
Result Set Testing and Manipulation
As stated in the prior section, it appears that the Faircom JDBC driver does not support
the same level of functionality as in other JDBC drivers such as Oracle and MySQL.
Additionally it was discovered that limited documentation for the Faircom JDBC driver
existed, [Appendix C] which provided minimal insight into the supported functions
within the JDBC driver and result set.
The SQL Query Utility was developed using standard logic and functions supported in
common JDBC drivers such as MySQL and Oracle. The unity expected to be able to pass
the SQL server a query and then interrogate the result set to determine the number of
columns and rows returned then use this information to populate the column headers and
also determine the size of the table where the result set was to be returned into.
It was determined that the Faircom JDBC driver does not support the JDBC function
resultSet().last which returns the last row number in a result set. [Fig 26]
Page 49 of 126
Figure 26 Showing source code calling resultSet.last() and JDBC driver returning error.
Without the integer information from resultset.last() it would not be possible to determine
the number of rows in the result set and properly size the table in the SQL Query Utility.
However it was noted that the driver supported the resultSet.next() function which may
be useful in providing a solution to this problem.
The resultSet.next() function returns a boolean value if a row exists in the next position of
the result set. If a row in the result set exists, the function advances to the next row in the
result set and returns a true value. Should a row not exist, the function does not exist and
returns a false value. This behavior will be explored in the next section as it may be
useful in determining the number of rows in the result set and reporting this information
to the table display mechanism.
Page 50 of 126
Determining the Number of Rows in the Result Set.
In this section we look at determining the number of rows in the result set returned from
the SQL server after successfully executing the user’s query. We specifically address
using the resultSet.next() function to determine this information. It should be noted that
once the value of the last row in the result set is determined we will need to unroll the
behavior used to determine the result so that the pointer in the result set is back at the first
row. The row count of the result set will be used to determine the number of rows in the
table may possibly be required in extracting the information from the result set returned
from the FairCom SQL server.
The pseudo code for this operation will be as follows:
If a result set exists
Number of rows = 0
While resultSet.next true
Number of rows = number of rows + 1
resultSet.next
// Reset the loop
While resultSet.previous true
End loop
Return Number of rows
Page 51 of 126
The actual code for this test was written as follows:
try{ while (resultSet.next()) {
output1 = resultSet.getString(1)+ " " + resultSet.getString(2)+ " " + resultSet.getString(3) + " " + resultSet.getString(4);
System.out.println(numberOfRows + " ----- " + output1); } } catch (Exception e) { System.out.println("Exception in Faircom Loop Example: " + e.getMessage()); } ////////////////////////////////////////////////////////////////////////////////// try{
while (resultSet.previous()) { output1 = resultSet.getString(1)+ " " + resultSet.getString(2)+ " " + resultSet.getString(3) + " " + resultSet.getString(4);
System.out.println(numberOfRows + " ----- " + output1); } } catch (Exception e) { System.out.println("Exception in Faircom Loop Example: " + e.getMessage()); }
Unfortunately it was now discovered that the Faircom JDBC driver did not support the
JDBC function resultSet.previous() function.
To test in a proof of concept functionality only, the try block containing the
resultSet.previous() function was removed from the utility and a line of code to increment
the numberOfRows counter was added in the resultSet.next() block of code. The figure
below [Fig. 27] shows the results of this change using a query designed to return three
rows of data. In the figure you can see a table created for three rows however it has not
been populated. Looking at the figure in the “Results” window of the IDE you can see the
three rows from the result table displayed using debug output and that it has been
discovered that the FairCom JDBC driver does not support yet another common JDBC
function.
Page 52 of 126
Figure 27 Table created but not populated and JDBC driver showing yet another
unsupported function.
FairCom corporation was contacted regarding functionality of their JDBC driver and
what standard functions are embedded. The list of unsupported functions in the FairCom
JDBC driver is significant and is listed in Appendix D. It is suggested that the reader of
this document familiarize themselves with these limitations before continuing work on
the project.
Page 53 of 126
Addressing the Limitations of the FairCom JDBC Driver
As mentioned prior and detailed in Appendix D, the FairCom JDBC driver is lacking
support for a number of common JDBC functions. A majority of these missing functions
are in the area of result set handling. Common JDBC drivers such as MySQL allow the
developer to access, traverse and manipulate the result set returned from the SQL query
while in memory whereas the FairCom JDBC driver only supports one forward pass
through the result set. The recommendation from FairCom documentation is once the
result set is returned the developer use a while loop to extract the data. This approach
required that the developer know the number of columns requested by the user for each
SQL query. See code example in [Fig 28]:
ResultSet rs = stmt.executeQuery("SELECT TOP 1 sensordatetime, sensornumber, sensortype, sensorreading From sensordata ORDER BY sensortimestamp DESC "); output2 = "executed query"; String clear =" "; // Fetch the data from the query result set while (rs.next()) { output1 = rs.getString(1)+ " " + rs.getString(2)+ " " + rs.getString(3) + " " + rs.getString(4) ; System.out.println(output1); } } catch (Exception e2) { System.out.println("Exception 2: " + e2.getMessage()); }
Fig 28. Code Example of Recommended FairCom Result Set Handling
The limitations of the FairCom JDBC driver posed two significant challenges during
development of the Web Query Utility. The utility used a JTable to display the data and
perform sorting functions. Normal use of the JTable when using the MySQL JDBC
driver requires passing the number of columns and rows to the JTable and then passing
through the result set again row by row, column by column using the
Page 54 of 126
resultSet.getObject() function to return the value at that specific field in the result set
back to the JTable. Unfortunately the FairCom JDBC driver does not support the
getObject() function to return the value at the specific point in the result set nor does it
support the resultSet.absolute() function to position the cursor at the desired row in the
result set. However the Faircom JDBC driver did support the getColumnCount() function
which returned the number of columns in the result set.
To get around these limitations and unsupported functions a simple but effective
technique was used in the next revision of the utility. When the result set was returned
from the query a while loop was executed, outputting the data in the result set into a large
array. Every iteration of the loop incremented a numberOfRows counter variable which
was later used to tell the JTable the number of rows to create in the grid object to display
to the end user. The getColumnCount() function was used to determine the number of
columns in the result set. To populate the contents of the JTable, the function that
positions the cursor at the desired row and column and calls resultSet absolute was
modified the return the value of the array at the desired row and column. See sample code
below. [Fig. 29]
Page 55 of 126
table = new String[100][100];
try{ numberOfRows = 0;
while (resultSet.next()) { table[0][0] = resultSet.getString(1); // + " " + resultSet.getString(2)+ " " + resultSet.getString(3) + " " + resultSet.getString(4); //System.out.println(numberOfRows + " ----- " + output1);
//System.out.println("getObject" + " " + resultSet.getObject( 1 ) + " " + resultSet.getObject( 2 ) + " " + resultSet.getObject( 3 ) + " " + resultSet.getObject( 4 ));
numberOfRows++; } } catch (Exception e) { System.out.println("Exception in Faircom Loop Example: " + e.getMessage()); }
Figure 29. Sample Code to Read the Result Set and Properly Size the JTable Object
Handling the population of the result set in this manner allowed for proper sizing of the
grid object in the utility based upon the number of rows in the query. In [Fig. 30] below
two queries are shown, the first with a three row result set and the second with a ten row
result set.
Page 56 of 126
Figure 30. Query Results With Properly Sized Grid
The next revision of the utility will address populating the entire grid with the returned
data and dynamically sizing the array object for efficiency. Depending on the capabilities
or limitations of the Faircom JDBC driver the array will be properly sized in length based
upon the number of rows returned in the result set or it will be sized to the maximum
number of records in the database table at the time of the query to avoid array out of
bounds errors.
Page 57 of 126
End User Version Development
In this section we look at the development of the end user version of the Web Based SQL
Query Utility. As discussed earlier, real world feedback suggested development of a more
simplistic end-user only version than what was originally proposed. The reasoning for
this was that end user staff would be non-skilled labor that would not have the expertise
in SQL or the sensordata database to produce accurate or relevant queries related to field
conditions. To address this requirement change a more simplistic user interface was
produced using the technologies developed in the prior sections.
To address the real world requirements, the SQL query entry panel was removed and a
series of buttons was added across the top of the utility. Each button activates a
predefined SQL query and returns the results to the grid object in the utility. [Fig 31.]
Figure 31 End user version of the SQL query utility.
Page 58 of 126
Additionally basic control capabilities were added to the prototype software. A row of
buttons was added at the bottom of the utility to control the cycle time between wireless
arrays. When a user clicks on one of the four cycle speed buttons a SQL query is
executed which writes the desired value, in seconds, to the table sensorControl in the
Xbee Wireless Sensor Array database. It should be noted at the time of this writing that
the sensorControl database table does not exist in the Xbee Wireless Sensor Array
project. This will be discussed further in the future work section of this document. In the
interim, should a user select on of the Cycle Speed control buttons the SQL query is built
up but not submitted to the SQL server. Instead the output is displayed as a notification
message to the user advising that this feature is not yet implemented. [Fig. 32]
Figure 32. Informational message displayed to user when accessing Cycle Speed buttons.
Page 59 of 126
6. Testing
Introduction:
This document outlines the testing procedures for the Xbee Wireless Sensor Array Web
Query Utility. The utility is designed to be a self contained reporting and analysis tool to
be used by low skilled workers in an agricultural environment. The utility is loaded from
the Xbee Wireless Sensor Array System web site and using JDBC makes a connection to
the system SQL server as required. Query results are returned to a grid object that has the
ability to sort data by the desired column in ascending or descending format. As
mentioned prior, the utility is designed to be self contained and does not require any user
inputs. Additionally the utility has extensive error handling and messaging options to
inform the user when a non standard condition has been reached.
Requirements:
The testing PC System requires the following:
• Java JRE version 1.6.0_11 or equivalent
• Access to the public Internet on TCP port 80
• Access to the public Internet on TCP port 6597
• The Java Console enabled to display prototype debug output.
Testing Proceedure:
Access to the Xbee Wireless Sensor Array Web Query Utility can be obtained by opening
the following URL: http://69.88.163.18/grimmick.html. The user will be presented with
the following web page. [Fig. 33]
Page 60 of 126
Figure 33. Web Page to Access the Query Utility for Testing
For testing purposes the highest revision number should be used. At the time of this
writing, prototype version 3 was the most current version. To access the utility, click on
the appropriate link.
Each revision of the prototype has its own informational web page with current status,
instructions and general information related to the status of the prototype. At the time of
this writing the informational page for prototype version 3 was as follows. [Fig. 34]
Page 61 of 126
Figure 34. Informational Page for Prototype Version 3.
After this page loads the Xbee Wireless Sensor Query Utility will be loaded on the client
computer. Upon loading the utility automatically makes a connection to the system SQL
server located at 69.88.163.18 and executes a default query. The query results are
returned to the utility from the system SQL server, loaded into the sortable grid object
and displayed to the user. [Fig. 35]
Figure 35. Default Query Loaded Into Grid Object
Page 62 of 126
Informational display for each prototype revision is output to the standard Java Console
window. This allows the tester to see the syntax of the SQL query being executed, any
errors returned from the runtime and also the progression through the grid object as it is
being populated. [Fig. 36]
Figure 36. Java Console Output of the Query Utility
To complete the testing cycle the operator must scroll through each of the available
queries and perform a sort on each of the columns in the grid object. The utility will
automatically disconnect from the sensor database SQL server upon close by the
operator.
Page 63 of 126
Error Handling:
The query utility has extensive error handling and operator messages included in the
standard functionality. Several of the error handling conditions have been avoided, such
as incorrect login, incorrect SQL query syntax, and incorrect column or field definition,
as this version is self contained and no user input is required or allowed. It should be
noted that these features may be tested in prototype version 2.
Two common errors can occur when working with the current version of the prototype
utility:
Connecton Reset: The client has lost its connection to the SQL server since
the initial load. [Fig. 37] This can occur when networking
problems exist between the client and the server. Check the
Internet connectivity between the client and the server.
Figure 37. Connection Reset Error
Access Denied: The client has not properly communicated or authorized
with the system SQL server. [Fig 38.] After prototype 3 the
login and host information of the SQL server is hard coded
in the client. Check that the SQL server process is running
Page 64 of 126
on the main sensor system. Verify that the original IP
address of the system has not changed. Verify that the
account credentials used in the utility still exist on the SQL
server.
Figure 38 Invalid Credentials Error Message
This completes the testing procedure of the Xbee Wireless Sensor Array Query Utility.
Page 65 of 126
7. Conclusion and Future Work
This project has shown that the combination of the Xbee wireless RF modules combined
with the Maxim-IC 1-Wire sensors can be used to create a functional wireless sensor
network for use in an agricultural environment. Further research and development would
be required to make this work into a viable end user product offering. It is suggested that
the following areas be evaluated for future addition or enhancement to the project.
• Migration to a more common database engine and JDBC driver.
o While the issues with the FairCom server were resolved the known lack of
support and features in their JDBC offering may present future problems
and programming challenges.
• Develop logic to define sensor and array configuration programmatically and
stored in the database.
• Develop a management console which allows for input of query requests,
definition and configuration of sensors and arrays.
• Enhance the management console to provide control functions such as sensor to
query, direction to query, cycle time management.
• Develop an alert system based on parameters stored in the SQL database for each
sensor and array module.
Page 66 of 126
-- This Page Intentionally Left Blank --
Page 67 of 126
Appendix A. Prototype Source Code
import java.io.*; import Serialio.*; public class TermTestCLI { static String banner = "Copyright (c) 1996-2003 Solutions Consulting, All Rights Reserved."; static String ver = "TermTest Ver 1.9"; public static void main(String args[]) { SerialPortLocal sp; String devName = ""; String[] names = null; if (args.length == 0){ PrintUsage(); System.out.println(""); try { names = SerialPortLocal.getPortList(); } catch (Exception e) { System.out.println(e); System.exit(1); } System.out.println("Serial ports reported by system:"); for (int i = 0; i < names.length; i++) { System.out.println(names[i]); } System.exit(1); } else { devName = args[0]; SerialPortLocal.addPortName(devName); } try { System.out.println("Create port object with name="+devName); SerialConfig serCfg = new SerialConfig(devName); serCfg.setBitRate(SerialConfig.BR_9600); sp = new SerialPortLocal(serCfg); sp.setDTR(true); //some modems will not respond if DTR is low int verLib = sp.getLibVer(); short vMajor = (short)(verLib >> 16); short vMinor = (short)(verLib & 0xffff); System.out.println("DLL version: "+vMajor+"."+vMinor); TermRcvTask rcv = new TermRcvTask(sp); TermSndTask snd = new TermSndTask(sp); rcv.start(); snd.start(); System.out.println("\nUse ^C to quit..."); } catch (Exception e) { System.out.println(e); System.exit(1); } } static int PrintUsage() { System.out.println(ver); System.out.println(banner); System.out.println("\nThis is a very simple serial port terminal program written in Java."); System.out.println("It uses native methods to communicate with the serial port."); System.out.println("The parameters are 9600 bps, No Parity, 8 data bits, 1 stop bit."); System.out.println("\nEnter the serial device name as the first parameter."); System.out.println("To use COM2, enter this command: java TermTestCLI COM2"); System.out.println("\nNote: If you use this program with a modem you may"); System.out.println("want to issue the ATE0 command to cancel modem echo"); return 0;
Page 68 of 126
} } /*----------------------------------------------------------------------------- * This thread reads the Recieve buffer and displays the values on the * console as characters *---------------------------------------------------------------------------*/ class TermRcvTask extends Thread { TermRcvTask(SerialPortLocal sp) throws IOException { if (sp.getPortNum() == -1) throw new IOException("TermSndTask: serial port not initialized"); p = sp; } public void run() { int b; // System.out.println("TermRcvTask running..."); for (;;) { try { // System.out.println("p.getByte()..."); while((b = p.getByte()) != -1) { if (b < 32 || b > 126) //System.out.print("<"+b+">"); System.out.print(""); else System.out.print((char)b); } try {Thread.sleep(100);} catch (InterruptedException e){} } catch (Exception e) { System.out.println("Error in TermRcvTask "+e); } } } SerialPortLocal p; } /*----------------------------------------------------------------------------- * This thread reads the keyboard for input and sends the keystrokes to * the serial port transmit buffer *---------------------------------------------------------------------------*/ class TermSndTask extends Thread { TermSndTask(SerialPortLocal sp) throws IOException { if (sp.getPortNum() == -1) throw new IOException("TermRcvTask: serial port not initialized"); p = sp; } public void run() { int b; for (;;) { try { // System.out.println("Input..."); b = System.in.read(); // blocks if input not available // System.out.println("b=("+b+")"); if (b == 10) p.putByte((byte)13); else p.putByte((byte)b); } catch (Exception e) { System.out.println("Error in TermSndTask "+e); } } } SerialPortLocal p; }
Page 69 of 126
Appendix B. Source Code Examples All Source Code Examples in this Document are provided for exaple use only. Copyright 2008 Grimmick Consulting, Inc. and may not be used without permission.
Page 70 of 126
Page 71 of 126
Page 72 of 126
Page 73 of 126
Page 74 of 126
Page 75 of 126
Page 76 of 126
Page 77 of 126
Page 78 of 126
Page 79 of 126
Page 80 of 126
Appendix C. Faircom Supported JDBC Metadata Methods
Page 81 of 126
Page 82 of 126
Page 83 of 126
Page 84 of 126
Page 85 of 126
Page 86 of 126
Page 87 of 126
Page 88 of 126
Page 89 of 126
Page 90 of 126
Page 91 of 126
Page 92 of 126
Page 93 of 126
Appendix D Unsupported Functions in the FairCom JDBC Driver
From: [email protected] [mailto:[email protected]] Sent: Mon 4/6/2009 6:56 PM To: Hank Grimmick Subject: RE: Supported methods in JDBC driver. WAS (RE: jdbc - Thread Creation denied)
Hello Hank, Here are the main limitations we have 1. Our cursor support is for "Forward only", "Read only" cursors 2. No support for Array, Ref, or URL types. 3. No support for java.util.Map or java.util.Calendar transformations on Object and date/time types 4. No autogenerated key support. 5. No named parameter support. The following functions are not supported: resultSet: beforeFirst afterLast first last isLast absolute relative previous setFetchDirection updateXXX insertRow updateRow deleteRow refreshRow cancelRowUpdates moveToInsertRow moveToCurrentRow /*map not supported, generate a warning. other getObject() calls work*/ getObject(int i, java.util.Map map) getObject(String colName, java.util.Map map) /*calendar not supported, generate a warning. other get Calls work */ getDate(int columnIndex, java.util.Calendar cal) getDate(String columnName, java.util.Calendar cal)
Page 94 of 126
getTime(int columnIndex, java.util.Calendar cal) getTime(String columnName, java.util.Calendar cal) getTimestamp(int columnIndex, java.util.Calendar cal) getTimestamp(String columnName, java.util.Calendar cal) /* unsupported datatypes */ getRef getArray getURL /* others */ setFetchSize getFetchSize CallableStatment: getBlob getClob getRef getURL getArray getXXX(String parameterName) setXXX getObject (int i, java.util.Map map) getTime(int parameterIndex, java.util.Calendar cal) getDate(int parameterIndex, java.util.Calendar cal) getTimestamp(int parameterIndex, java.util.Calendar cal) registerOutParameter Connection: setSavepoint rollback(Savepoint savepoint) releaseSavepoint prepareStatement(String sql,int autoGeneratedKeys) prepareStatement(String sql, int[] columnIndexes) prepareStatement(String sql, String[] columnNames) setTypeMap(java.util.Map map) PreparedStatement: setTime(int parameterIndex, java.sql.Time x,java.util.Calendar cal) setDate(int parameterIndex, java.sql.Date x, java.util.Calendar cal) setTimestamp(int parameterIndex, java.sql.Timestamp x, java.util.Calendar cal) setArray setRef setURL
Page 95 of 126
Statement: getMoreResults( int myvar) getGeneratedKeys executeUpdate(String sql,int autoGeneratedKeys) executeUpdate(String sql, int[] columnIndexes) executeUpdate(String sql, String[] columnNames) execute(String sql, int autoGeneratedKeys) execute(String sql, String[] columnNames) execute(String sql, int[] columnIndexes)
Page 96 of 126
Appendix E Xbee Wireless Sensor Array System Query Results Prototype V.5 Source Code
Page 97 of 126
Page 98 of 126
Page 99 of 126
Page 100 of 126
Page 101 of 126
Page 102 of 126
Page 103 of 126
Page 104 of 126
Page 105 of 126
Page 106 of 126
Page 107 of 126
GX1: Grimmick Xbee 1-Wire
Prototype Sensor Array System
Setup Document
Purpose This document outlines the steps required to configure, install and use the
Grimmick Xbee 1-Wire Prototype Sensor Array System on a personal
computer.1
This document does not discuss the general component
configuration. Which is detailed in the manufacturer’s documentation.
This document makes the following assumptions:
• The reader has at least version jdk1.6.0_06 of the Sun Java JDK
installed. [5]
• The reader has installed the Maxstream (Digi) Xbee drivers and
utilites from the manufacturer’s CD and can perform the range test
as described in the manufacturer’s documentation. [6]
• The reader has installed the Dallas Semiconductor 1-Wire API
from the Windows executable setup file included in the project ZIP
file. [7]
• The reader has run the OneWireViewer Java utility as described in
the Dallas Semiconductor documentation to test one connected 1-
wire sensor
• The host PC for the system has at least one USB 2.0 port.
1 This document is written under protest by the author as the author is working on developing this project into a commercial solution.
Page 108 of 126
• The host PC has Microsoft IIS installed.
• The reader is familiar with IIS and knows how to create a virtual
directory.
• The reader has extracted the contents of the supplied ZIP file
DevAreaForZ.zip as described in this document.
Page 109 of 126
Overview The Grimmick Xbee 1-Wire Prototype Sensor Array System is a proof of
concept system which uses common of the shelf components (COTS) to
create a network of wireless sensor arrays for collecting data about soil,
plant and atmospheric conditions. The data from each sensor array are
stored in an SQL database and made available on the web and via standard
ODBC connections. The system uses the following hardware and software
components, as illustrated in figure 37.
Figure 37 Xbee Wireless sensor array with 1-Wire network card and sensor attached.
Page 110 of 126
Hardware Components
1. Digi Xbee Pro Development Kit (contains)
• 3 Xbee Pro modules
• 2. Xbee modules
• 1 USB Xbee interface master unit board
• 4 RS-232 Xbee interface remote unit boards
• 4 9vdc external power supplies.
• Wireless RF Networking Modules and API [8]
2. Dallas Semiconductor (Maxim IC) [9] [10]
• T3-R1-A: Temperature sensor
• CHT-R1-A: Temperature sensor housing
• DS9097U-A: 1-Wire Serial Adaptor
• CABLE-A-P: 1 meter RJ-11 to RJ-45 1-Wire Interface Cable
Software Components
1. SerialIO Serialport
An open source serial port driver for Java named RXTX [11] can
be used but in this project it has been substituted by the
commercial serial port driver SerialIO [12]
2. Database Engine
Database engine CtreeSQL and JDBC API is available from
Faircom Corporation. (Currently CtreeACE) [13]
Page 111 of 126
Server Side
Base Install: The first step is to install the Maxstream Xbee drivers and utilities as
provided on the manufacturer’s CD and then perform a simple
communications test to verify proper installation. The process is described
in the previous report. [1]
The second step is to install the Dallas Semiconductor 1-Wire API and
Windows drivers. This file may be downloaded from the manufacturer’s
website [7] and is also included in the project ZIP file. Once the 1-Wire
API is installed perform a communications test as described in the
previous report [1].
In addition to the above mentioned system software components, the
following additional system software has to be installed:
• FairCom database engine and JDBC drivers.
• Serial port drivers for RXTX or SerialIO.
Page 112 of 126
Zip Install: To facilitate the installation process the project ZIP file DevAreaForZ.zip
should be saved and extracted to the users Windows system desktop. The contents of the
zip file are as shown in [Fig 38]:
Figure 38 Contents of DeveAreaForZ.zip
• The folder 1-WireAPI contains the documentation, sample
programs and source code for the Dallas Semiconductor API.
• The folder FairCom contains the FairCom database engine and
database for the project.
Page 113 of 126
• The folder FilesForExt [Fig 39] contains the following files:
o ctreeJDBC.jar
FarCom JDBC jar: The Java JDBC driver for the
FairCom database engine.
o ctreeSQLSP.jar
Faircom SQL jar: The Java SQL driver for the
FairCom database engine.
o OneWireAPI.jar
Dallas Semiconductor 1-Wire jar: Provides the
functions for the 1-Wire network card and attached
sensors.
o RXTXcomm.jar
RXTX open source serial port driver jar: Used by
default in the 1-Wire API.
o Serialio.jar
Commercial java serial port driver jar: Used in the
project to handle communications with the Xbee
Pro RF boards.
(license required)
o Readme.txt
Specifies the location where the jar files should be
copied to. Default is in your JDK \jre\lib\ext
directory
Page 114 of 126
Figure 39 Contents of the FilesForExt folder.
• The folder javasamples contains the prototype project source
and compiled java code [Fig 40].
o callJava1 is the main control program for the system. It
is responsible for creating the JDBC connection to the
Faircom server, creating the database if required,
inserting the records in the database and calling the
communication program for each sensor array.
callJava1 calls methods in the next three programs
TermTestCLI1, TermtestCLI3 and xbeetemptest
o TermTestCLI1 and TermTestCLI3 are responsible for
communications, configuration and switching between
each of the Xbee Pro modules.
Page 115 of 126
o xbeetemptest is responsible for starting the 1-Wire
network, querying the 1-Wire temperature sensor and
converting the returned value to Fahrenheit.
o sensorWeb is the web based query applet from the
database. For the purpose of this prototype project the
user should create a virtual directory in IIS to the
javasamples directory.
Figure 40 Contents of the javasamples folder containing the prototype project code.
Page 116 of 126
Startup: 1. Connect the Xbee Pro USB master unit to the local PC and power up
the two Xbee Pro Wireless remote units as described in the prior report.
[1]
2. Start the FairCom SQL database engine. Navigate to the location where
the zip file DevAreaForZ.zip was saved from the prior section then into
FairCom\V8.27\ctreeServers\ctreeSQLServer folder and execute the
ctreesql.exe program. This will start the database engine. Successful
startup is shown in the screenshot below [Fig. 41]. On successful startup
the function monitor window may be closed. The server window and
message monitor should remain open but can be minimized to the desktop.
Figure 41 Successful startup of the Faircom CtreeSQL server.
Page 117 of 126
3. Navigate to the javasamples folder and execute the main control
program callJava1. It will result in the output shown below with a
successful connection to the FairCom server and initiating
communications on the serial port. [Fig. 42].
Figure 42 Successful execution of callJava1
Page 118 of 126
4. Open a web browser on the local PC and execute the following URL:
http://localhost/NameOfVirtualDirectory/sensorWeb.html This
will make a SQL connection to the FairCom server and execute the web
based query applet [Fig. 43].
Figure 43. Execution of the test query applet.
Page 119 of 126
Shutdown: Shutdown is performed in the following three steps.
1. Close the web browser.
2. Stop the execution of callJava1
3. Properly shutdown the Faircom Server. This is critical! [Fig 44]
Navigate to the FairCom server control window
Figure 44 Control console for the FairCom ctreeSQL server.
Click on “Control”
Select “Shutdown”
Enter ADMIN for the user (case sensitive)
Enter ADMIN for the password (case sensitive)
Click on OK [Fig.45]
Page 120 of 126
Figure 45 Shutdown console for the FairCom ctreeSQL server.
When prompted to confirm insure there are 0 users on the
system and click OK. [Fig 46]
Figure 46 Confirmation prompt to shutdown the FairCom ctreeSQL server.
This will properly shutdown the server.
Page 121 of 126
Client Side
Installation of the Xbee Wireless Sensor Array SQL Query Utility
To install the Xbee Wireless Sensor Array SQL Query Utility, extract the contents of
Prototype5.zip into an accessible web server directory on a web server as shown in figure
47.
Figure 47 Contents of Prototype5.zip
Until the user is completely familiar with the entire Xbee Wireless Sensor Array System,
it is recommended that all the system components, Xbee Master, polling software,
database engine, SQL query utility and web server all be located on the same host. The
reason for this is that there are multiple network communication protocols in use.
Page 122 of 126
The required protocols are discussed in each manufacturer’s documentation and the
installation of the system on multiple hosts is outside the scope of this document.
Accessing the Xbee SQL Web Query Utility
To access the SQL Web Query Utility simply open a web browser and access the test
system at http://69.88.163.18/grimmick.html as shown in figure 48.
Figure 48 Prototype Version Access Page
The next step is to click on the hyperlink for the desired version of the prototype utility.
At the time of this writing, version 5 was the most current prototype. Accessing the
hyperlink for version 5 will launch two windows on the user’s computer. The first
window spawned is the version information window. This is a standard HTML page that
displays prototype version specific installation information. [Fig 49]
Page 123 of 126
Figure 49 Prototype version specific informational page.
The second window spawned is the SQL query utility itself. Upon execution the utility
establishes a TCP connection with the defined FairCom SQL server, logs in to the server
using the defined user credentials and executes the default query as defined in the source
code as shown in figure 50.
Figure 50 Xbee Wireless Sensor Array Query Prototype V5
Page 124 of 126
Usage Instructions
As discussed in prior sections, this version of the utility is designed to be an low skilled
end user application so ease of use has been prevalent in its design. The utility supports
two core functions, status reporting and system control. To access the status of the system
simply select one of the four available status reports from the top row of buttons on the
query utility, to control the sampling cycle speed of the system, simply select one of the
four cycle speed options from the bottom of the utility, as shown in figure 50.
Future Project Enhancement
Since the inception of this project several semesters ago, significant enhancements have
been made to the technologies used in this project such as:
• The Dallas/Maxim API has been significantly enhanced such that it supports
configuration changes to the Xbee Pro modules via the API thus negating the use
of AT commands via the serial port. This also eliminates the need for the SerialIO
serial port libarary.
• FairCom has released version 9 of the ctreeSQL server, now called ctreeACE.
FairCom advises that more standard support for SQL has been added to this
product version, however this has not been verified.
Page 125 of 126
The following suggestions are offered for future work on this project:
• Addition of the ability to add and remove sensor array modules to the system by
adding or removing records in the database.
• Creation of an alert module to delivery warnings to the administrator via SMTP
e-mail.
• Replace the FairCom SQL server with a more mainstream product such as:
mySQL, MS-SQL, Oracle, or DB2.
• Create a control module to control items such as sprinkler valves based upon
alerts or system parameters.
Technical Suppport
Technical support of the GX1: Grimmick XBee 1-Wire Prototype Sensor Array System is
available via e-mail to [email protected] or [email protected].
Page 126 of 126
Appendix G: References
1. H. Grimmick, Serial Based Wireless Sensor Arrays for Use in Construction, Land
Surveying and Agriculture, CEN 3213 Class Project, FGCU, April 21, 2008
2. Phill Ballard, Ajax in 10 Minutes, 2006 Sams Publishing
3. Faircom Corporation, http://www.faircom.com
4. Digi International, http://www.digi.com
5. Sun Microsystems, http://java.sun.com/javase/downloads/index.jsp
6. Digi International,
http://www.digi.com/support/productdetl.jsp?pid=3249&osvid=0&s=315&tp=1
7. Maxim-ic, http://www.maxim-
ic.com/products/ibutton/software/1wire/1wire_api.cfm
8. Digi International, http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-
module.jsp
9. Maxim-ic, http://www.maxim-ic.com/products/1-wire/
10. Hobby Boards, http://www.hobbyboards.com
11. RXTX, http://users.frii.com/jarvi/rxtx/
12. SerialIO, http://serialio.com/products/serialport/serialport.php
13. Faircom Corporation, http://www.faircom.com/ace/download_t.php