High Level Design
Rationale
Our rationale for project was that it is often tedious to open up a browser on a PC to look up the current weather on sites like weather.com. We thought it would be useful to have a stand-alone device where all one would have to do would be enter an airport code and immediately receive the most updated weather information. The project was also a proof of concept for many topics in ECE 476, such as UART, video, and SPI. Therefore, we focused on breadth rather than depth in the project, integrating various technologies into a system that performed a specific function.
Background Math
The project required no background math past that which one would consider basic in a course like ECE 476 (e.g. simple arithmetic).
Logical Structure
We had to use two MCUs because all of the keyboard.c processing could not occur with video being blasted to the tv at the same time from the same chip. Using one MCU cause severe flicker on the screen so we broke our program up into keyboard.c and tv.c, eith tv.c loaded onto the custom board’s Atmel Mega32 chip. We used the Serial Peripheral Interface to communicate between the two MCUs, rather than say another UART connection, because this was easiest to implement and it lent itself best to this situation in which the two chips were in close proximity to each other. On the PC side, we had to have a server called ApacheFriends running in order to run the PHP script which would perform the internet query. We had the PHP script write back to a text file because the VB program could easily open and read the results using existing VB file management commands.
Hardware/Software
Tradeoffs
The major hardware tradeoff of our design was using two MCUs for the keyboard and video portions of our project. Using one MCU would have been a more elegant solution, although much more difficult to implement (if not impossible) with the Mega32. We had to contend with timing limitations from using only one MCU and were forced to solder together an MCU protoboard to use along our SDK500. The SPI interface used to communicate between the two MCUs, on the other hand, proved to be the most effective and fastest means of serial communication.
One of the major software tradeoffs of our design was in using airport ICAO codes to identify locations for weather information, instead of a zip code or city name. Originally, we wanted the user to be able to input a zip code or city name on the user interface, and have the PC lookup weather data for that location from the Internet. However, we found that the METAR reports we mentioned above are specified for an airport location, which is identified by its ICAO (International Civil Aviation Organization) code. The PHP script we used to retrieve and parse weather information also required an ICAO code as input. Ideally, we would have created a database to map zip codes or city names to the nearest airport (and its respective ICAO code,) to allow for a more intuitive user interface. While these databases are available online, we felt that this would have been beyond the scope of this project's main objectives.
Standards
WeatherDog made use of four standards, PS/2, RS232, ANSI, and IEEE 802.3. First of all, the keyboard for the device had a PS/2 connection, so we needed to be able to work with the PS/2 standard in interpreting keyboard outputs. This allowed us to interface to the keyboard so that the keyboard MCU could receive data from it. The reason we used the PS/2 standard for the keyboard was it was the way the standard keyboard we used was sending the MCU data, so we were not be able to realize direct conversion to other data forms, e.g. RS232. Furthermore, we only had to decode scan code Set 2, which made our keyboard code much simpler since it only had to work with the most common type of keyboard. Secondly, we used the RS-232 standard for the serial communication between the chip’s UART and the PC at 9600 baud. Thirdly, we write the code for the chip in ANSI C, an obvious standard necessary for the project. Fourthly, we used the SPI standard to communicate between the two MCUs. Lastly, although we did not deal with this directly, the ethernet connection required to obtain the data over the Internet demanded the employment of the 802.3 standard for carrier sensing multiple access (CSMA) protocols.
Patents, copyrights,
and trademarks
Because our design for looking up weather information from the internet on a PC relied on some freely-distributed programs and other available code, we needed to be well aware of issues in using someone else's intellectual property. The beta version of Visual Basic 2005 Express (running on the .NET 2005 platform) is distributed by Microsoft Corporation. Beta versions of any software package are usually distributed freely before a final release in order to get new users to report bugs in the software and become familiar with the new interface. Since we did not make any modifications to the software or distribute it ourselves, we did not violate any copyrights. Similarly, we followed the same guidelines in using the software package for the Apache Web server made available from Apache Friends.
The weather services PHP script we used was distributed by "The Pear Group" and was written by the voluntary contributions of a number of individuals. The license agreement form included with this code specified that "[r]edistribution and use in source and binary forms, with or without modification, is permitted" under a number of guidelines, including that "[r]edistributions of source code must retain the above copyright notice." Since we did not actually modify this code (and instead wrote our own PHP script to interface with the one we obtained,) we did not need to contend with any copyright violations.