The WeatherStation 2004 allows the user to view, graph, and analyze temperature, pressure and humidity sensor data over extended periods of time.
For information on using color in Hyper Terminal, click here.
The data can be graphed or easily viewed, while also storing record maximum/minimums. Calculations of dewpoint and barometric pressure rise/fall allow for some minimal forecasting as well.
2.1 Rationale and Sources of Project Idea
In trying to decide what our final project would be, we wanted to choose a project that had a nice mix of both hardware and software aspects. The temperature sensor lab we did in class seemed to be a good idea, but of course a final project would have to be more extensive than that. This inspired the idea of the weather station. It has several sensors (including two temperature sensors) which collect data useful for predicting and evaluating the weather. This flushed out the hardware side. On the software side, we thought it would be neat and useful to be able to sample data over a long period of time, and process and graph it.
2.3 Logical Structure
Three sensors (the two temperature sensors and the pressure sensor) each generate an analog signal representing their respective state, which connect to the microprocessor via the analog to digital connector (port A). The last sensor, the humidity sensors interfaces with the processor through external interrupts (port D.2). Our project can run completely independently of the user while collecting/storing data from sensors during normal operation. In order to view, edit, reset, or process this data, the user must connect to the microprocessor via RS232 9600 baud serial. Using an intuitive text-based interface, the user can easily navigate the entire system's array of functions.
2.4 Hardware/Software Trade-Offs
For the most part, there was little leeway in terms of deciding which parts would be accomplished with software and which with hardware. The sensors (hardware) would pass an analog voltage to the analog-to-digital converter (ADC), and from there the software would take the data and process it. An exception to this type of data collection was the humidity sensor. The sensor itself acts as a variable capacitor, so there was no voltage output we could translate into humidity. We considered writing complicated code to check the charge time on the capacitor after switching ports, but quickly decided we could simplify the task using hardware. We used a TLC555 2.1 Mhz timer IC with several resistors to output a square wave that was dependant on the frequency. This frequency varied very linearly between 6000Hz and 7200Hz representing 0% to 100% humidity respectively and could be easily read using microprocessor external interrupts.
2.5 Standards
Our project uses several standard interfaces to allow for easy connectivity.
-EIA RS232: The RS232 connection is based on 9-PIN asynchronous operation using a transfer rate of 9600 baud. The only pins we will be concerned about are the transmit data, receive data and signal ground. We use this protocol to easily allow HyperTerminal access to the program's user interface.
-ANSI Color Standard: Using escape characters ( ^[ ), following by specific standard ANSI/VT100 color codes we are able to allow the user to change specific color display options for graphing data.
-ASCII: ASCII (American Standard Code for Information Interchange) representation is a format to represent characters (example: ‘0,' ‘a' or ‘@') as numbers (between 0 and 127). We use ASCII characters to communicate with the user over a terminal connection.
3.1 Program Details / What parts were tricky to write?
Our program's user interface driven menu/options functionality is completely state machine driven. When a user enters a command via RS232, a UDR interrupt handles the user's command and stores it into a command[] array. That command is checked for validity, and then the appropriate state is entered to process their request. In order to make the menus very easy to use, several different sub states are often required for navigating options menus. By default and while not running any user commands, the program sits in an idle state, checking any flags have been changed which will affect its state.
Data collection runs using hardware interrupt based ISRs. This allows the core of the program to run completely independently of and at the same time as the user interface. Timer1 ISR runs every 1ms and is used to keep track of time and as a counter for storing data. Humidity sensor data is read by the external interrupt ISR and humidity is calculated using timer1. The other ISR we use is the ADC interrupt, to process new sensor data and assign it to the correct variables in converted form.
Many separate functions control sub tasks such as graphing, printing data, and changing options. By far, the most difficult part of the program to write was the graphing routines. Because the output is simply an ASCII 48 x 20 graph made up of asterisks, we felt we had to enhance the graphs as much as possible. The temperature graph auto-scales its Y axis based on the maximum and minimum data it has to output. The graphs, and data are fully configurable with difference colors, units, and X-Axis time scale. Making a static graph was our first approach, but adding all of this functionality got complicated fast.
3.2 Hardware Details
The four most important components of the hardware are of course the sensors themselves. There are two temperature sensors, both LM34's. One is attached closely to the breadboard, while the other is held at a distance from the breadboard and connected by wires; this sensor held at a distance is designed to simulate an outdoor temperature sensor. The output of each temperature sensor goes to its own LMC7111 op-amp. We arranged the op-amp with the appropriate resistor values to give it a non-inverting gain of two. This amplifies each of the temperature sensor's outputs, allowing the ADC to produce a value with higher resolution.
The third sensor in our weather station is the pressure sensor. This sensor, the SenSys ASCX15AN works in a rather straightforward manner. It outputs a voltage from 0 to 4.6V that is directly proportional to the absolute pressure, from 0 to 15 psi. We take this voltage and feed it directly to the ADC for conversion.
The fourth sensor is the humidity sensor. This sensor, as stated above, is simply a capacitor with a humidity-sensitive capacitance. It does not directly output a simple voltage like the other sensors of the weather station. Instead, it is connected to a TLC555 chip, along with a few resistors. The output of the setup is fed directly into the microcontroller. The output takes the form of a square wave which has a frequency modulated by the capacitance, which is in turned modified by the humidity. Thus, the microcontroller can extract the humidity by counting rising edges.
3.3 Things Tried Which Did Not Work
One of the things we tried which did not work was some kind of wind indicator. We found several different possible solutions, but none of them seemed like they would be a very realistic solution. We found several products online that were either way over our budget and/or they were completely self contained and impossible to interface with. We investigated using a hall sensor to measure rotation of a wheel blown by wind, but this was complicated enough to be a final project by its self.
Screenshots of our application in action:
Picture of Circuit:
4.1 Results of Design - Speed of execution:
Our program's backend, the part controlling data collecting runs without any hesitation or delays and is actually configurable to allow different sampling intervals. The only time limitation we put on the data is that each of the four sensors are only updated every second because we failed to see a need for anything faster. The code could easily be modified to make this happen on any faster time scale.
The user interface terminal is completely driven by RS232, which is only limited by the 9600 baud data rate we used. The only noticeable problem this presents is that full screen data or graphs have a small (less than 1 second) hesitation while printing.
4.2 Accuracy
Our sensors are accurate enough for our application, but we feel that more calibration and smaller steps between digital readings would be ideal for more commercial application.
We attempted to use 10 bit accurate ADC conversations, which seem to be fairly stable, but even 10 bits limits the precision of the readings. Our LM34 temperature sensors use an op amp gain of two to allow for up to .2 degrees F steps, but the temperature sensor is only accurate to plus or minus .8 degrees according to the data sheet. Our pressure sensor's analog output is incredibly accurate, but with ADC, we are able to read the barometric pressure to within .02 “ Hg. For weather this is accurate enough for basic forecasting and rise/fall calculations. Most weather media sources report to within .05 Hg. The humidity sensor claims to be +- 5% accurate, but the data sheet highly recommends calibration. Because we do not have easy access to the ambient conditions calibration requires, we tested the unit as it arrived, and found it to be very close (within 5%) to a commercial humidity sensor we had.
4.3 Safety
Our software is simply a tool for sampling weather data, and therefore the software does not control any moving parts or hardware that could endanger the user. The only real safety concern would be if we attempted to package or commercialize our project. Weather sensors must be made to withstand moisture and more rugged conditions than our breadboard can simulate. In a dynamic environment, all connections would have to be heat shrunk and kept water resistant.
4.4 Interference with other designs
Our circuit does not generate any RF signals except for minimal CPU noise, which could be eliminated by faraday caging the circuit if deemed necissary. It worked fine in a static envoirment outside the lab, as well as on a busy lab day.
4.5 Usability
Usability was an important concern for our software. Because the hardware is static, it is simple to operate by definition and just sits taking measurements. Our software is very dynamic and gives the user great flexibility with how they wish to view or process the data collected.
When designing the user interface, we wanted any person off the street to be able to sit down and understand what the program was doing, and how they could access it's functions. When the program starts up, the user is presented with a welcome message and told they can use the help menu for more information. The help menu is easily accessible, and presents the user with a thorough list of all available functions and details about them. Each option or function is completely text menu driven and asks the user exactly what they want. We actually had roommates who had no idea what our project was test our interface to make sure nothing was left unclear.
5.1 Expectations vs. Results, Improvements
For the most part, our expectations of the project were not too different from the results of our work. There were occasional setbacks in programming the software side, but nothing insurmountable. If we had more time, we would have tried to do a few more things. First, we would see if we could make some kind of “homemade” wind-detector, since we could not find any purchasable hardware that fitted our needs. We would also see if we could make some kind of UV detector, using a UV LED. Ideally we would have liked to have packaged the system up into a neat package, able to be hung outside, or on a wall by a door/window, but without our own LCD and because several parts were borrowed or donated, this was not possible.
5.3 Intellectual Property Considerations
Intellectual property considerations do not really play into our project too much. We did not reuse code or someone else's design, except for perhaps the temperature sensor's amplification idea. We did not use an code in the public domain. We did not reverse-engineer anything. We did not have to sign any non-disclosures to get sample parts, but we did promise to return the TLC555 demo chip to the humidity sensor manufacturer. There are no real patent opportunities for such a weather station, as there seem to be similar devices widely available.
5.4 Ethical Considerations
To be honest and realistic in stating claims or estimates based on available data;
We are being 100% accurate with our report of this project. We are not fabricating any data or making any wild claims.
To improve the understanding of technology, its appropriate application, and potential consequences;
We hope that by providing the general public with this report, we can help people understand how to make a weather station, so that perhaps they can make one themselves. This is actually a very practical device; many people have manufactured versions of such devices is their homes.
To maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
We feel that our technical competence has indeed improved much while working on the project. Besides a few setbacks, the project was manageable. We also did not want to undertake a task that we were not qualified for, and felt that our weather station satisfied that condition.
To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
We would like to acknowledge the help we received from Humirel, the humidity sensor manufacturer. They sent us the demo board which has the TLC555, humidity sensor, and resistors all prepackaged and ready to go. The personnel at Humirel were very helpful when we called them with questions. We would also like to credit Prof. Land, because the entire weather station idea stemmed from the temperature sensor lab.
To avoid injuring others, their property, reputation, or employment by false or malicious action;
We hope that we have chosen a project that is relatively harmless. Using our weather station does not really carry any serious risk of electrical shock or other form of harm.
7. Schematic
10. References Used
10.1 Data Sheets
Humirel HS 1101 - http://rocky.digikey.com/WebLib/Humirel/HS1101.pdf
10.2 Vendor Sites
10.3 Background Sites / Referances
Website Used for Calculating Dewpoint:
0 comments:
Post a Comment