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