Posts Tagged ‘weather station’

Weather Station Part 2 – System Architecture

Monday, August 2nd, 2010

This is the second post in a series discussing the development of a home weather station using Storyboard as the embedded user interface.

In the first post we discussed the general product idea and principle features.  In this post we are going to put together a general system architecture.  We can do this in block diagram format independent of our final hardware or operating system selection.

Without knowing the specific configuration of our hardware, we keep the design modular.  We expect to create a controlling process for each of the local temperature, barometer and wind speed monitors.  Each of these monitors will likely require a custom device driver interface, or use functionality from an existing device driver.  These monitors will generate information that is consumed, and displayed, by the user interface.  The user interface will not send information to these processes so the communication is one way from these modules.

The remote weather feed process is a more dynamic module.  It receives configuration information that is generated by selections made in the user interface and then transmits data back to the user interface relating to the requested weather information.  Initially we will only support long term forecast display for the current location, but in the future additional information may be generated and sent to the user interface module.  This module will communicate over the standard network socket interface and the associated network stack.  The specific details of how the information will be retrieved, i.e. using HTTP directly, an RSS feed or some other known service, are not important at this stage.

In order to continue application development while the final hardware and operating system decisions are made, we will leverage the Storyboard IO communication API.

In the next post we will define the system independent messages and their information payload.  This definition will help to separate our embedded GUI design from the specific details of the platform it is running on and potentially allow us to start prototype development in a simulation environment.

Thomas

Weather Station Part 1 – Initial Design

Thursday, July 29th, 2010
This post is the first in a series that will walk through a complete embedded application design using Storyboard for the user interface component.
The product goal is to design and implement a home weather station.  Like any commercial product, it will evolve from a general concept to specific software and hardware implementations.  During the evolution we’ll talk about how Storyboard can help to keep the development going, even in the face of software or hardware uncertainty.
Weather Station Concept Design
The weather station that we want to build is designed to be a wall or counter mounted unit containing an integrated LCD touchscreen display.  It will communicate with several locally[1] connected probes to measure temperature, barometer, wind speed and direction changes.
An additional feature that we would like to incorporate would be the ability to provide access to long term forecasts using online weather services.
This is the initial product, but our design should accommodate a  future evolution that could use the online weather services to offer remote weather information as well as satellite imagery.

As a reference, we really like the design of uControl’s home security and automation panels:

uControl demo

The display size we would like to use is 800×480, but the final selection will be dictated by the market price point.  We also do not have a particular hardware platform or operating system configuration selected, but expect that our mythical engineering and procurement team will be evaluating those to figure out where we get the best value so that we can introduce the weather station product at a competitive price point.
Next time we’ll lay out the general product components and architecture and incorporate our peripheral devices into that design.
Thomas
[1] In this case local doesn’t mean that we will necessarily have wired inputs, but that the information is gathered locally.  It may be that the implementation uses a wired, wireless or combination of approaches.