Real Time Weather Station

Update: January 27, 2010

Another total rewrite. The program had been growing and I was less and less comfortable about using VB.net - C Sharp would have been a much better choice. Just before Christmas, I froze development and converted the whole thing. I found an on-line converter - you paste the source code in and hit a button, it gives you back the converted code. The conversion process is not very precise - when I did the first compile I had over 1,300 errors. Many were simple to fix and after about eight days I was down to 13 errors, none of them easy to fix at all. At day 11 I finally had a clean compile. The first test runs were complete disasters but after fighting for another couple days I was able to get the date and time from the station! Nothing else, but it's a start, right? Actually, it only took about another few days to get the program reading everything correctly (except the delay until the next update, that doesn't look right at all).

Having accomplished that, I spent the rest of the following month moving the last bits of missing functionality into the new code base. It now tracks minimum/maximum values, it draws graphs, it creates web pages and everything seems to work fine. As of last night, the old VB6 program is shut down and everything has been switched over.

On the hardware side, the anemometer is acting flaky - I need to look at that. Several months ago I tidied up all the wiring: cut out all the excess cable; dog proofed everything; and hid everything from view. In the process, I ended up with maybe a pound of cable all tied up and essentially hanging off the jacks in the sensor unit. I think this was a mistake and it's making the wind reading erratic. I'm also getting a zero humidity reading two or three times a day. The code ignores those but it might be related to the wiring. Finally, I think the sensor is in direct sun for about a half hour these days and the temperature seems to go up by three/four degrees around 2:30.

For the record, the process of converting from VB.net to C Sharp (or C#) had the following problems:

Update: March, 2009

I find it hard to believe that it's been over four years since the LaCrosse went online but there you go.

The weather station is not running wireless any more, this was just too much of a pain; and a good set of expensive batteries lasts around one, maybe two months when it's bitter cold. I've got a cable running out to the collector and am pulling in the current values every 15 seconds or so. The anamometer has been moved up to the roof where it can give me a much more accurate idea of wind speed and direction. The VB 6 program has been sort of half retired.

There's now a front-end data collection program written in VB.Net that is responsible for talking to the base station. It writes out an intermediate file that the main VB6 program picks up and VB6 still does all the reporting. The dot net program also updates a MicroSoft SQL Server database with the current values - the idea is that eventually all of the reporting functions will be moved over to dot net and SQL server.

There was a LOT of code in the old program to update three main MS Access database tables: kind of a scratchpad that holds one reading for each ten minutes going back over the last 24 hours; a table ("History") that holds the readings for each hour going back over ... well, as long as the station has been running; and a table ("Almanac") that holds min/max values for each day, again going back as far as it's been listening.

Access is a good solution for many things but it starts to suffer when the database gets above 2 Gig. In four years, the database got above 2 Gig. Also, Access doesn't support stored procedures or triggers or a lot of what makes a database a database. Moving to SQL Server let me write some triggers so when I write a value into the scratchpad table, it fires some triggers and pushes the values out to the daily and almanac tables automatically.

The data collection front end is heavily based on work by Shell M. Shrader, who released the code into the wild under the GPL. I'm preparing a package of my vision of it (minus the SQL Server bits) that I will release as well. Soon. My ultimate goal is to get it rewritten in C sharp, we'll see how well that goes.

Update: January, 2005

Total rewrite: This page is 100% new as of Jan 2005. The Radio Shack WX200 was showing its age and the layout of the current house didn't let me really place the cabling or sensors in optimal locations. As a result, reporting was compromised - the temperature would regularly spike up to either +75C or down to -39C; the rain sensor probably wasn't reporting anything at all any more; the wind sensor was reporting direction but not always actual wind speed. Time for a major update.

I'm now the proud owner of a La Crosse Technology WS2315 weather station. Does everything the WX200 did and: it's mostly wireless. You have a stylish base station along with external temperature/humidity/barometric pressure/wind speed and direction/rain gauge sensors. The trick is, you must cable connect the various outside sensors together but the outside package sends the readings over a radio link to the base station. The theory is, you can place the sensors somewhere around 80 feet (for radio reception) plus another 30 feet (for the interconnect cables) away from the base station. Good stuff. The data stream that it sends back is completely, 100% really, really different from the data stream from the WX200 but a few years ago I couldn't spell programmer but now I are one. Right?

Challenge the first: the claim of 80 foot transmission is a guidline subject to "real world conditions". As in, 80 feet if there are no walls, no trees; shubbery or small animals in the way. And, if there are no power lines or cordless phones within half a mile. Oh, according to the manual, the base station must be more than five feet away from any computers. Connected by a six foot serial cable. Riiiiiight. Actual range is more like twenty feet. 'K. Twenty feet for the transmiiter I can work with and then you have 30 feet of cable for the anemometer and rain gauge. Rain gauge is no problem, anemometer is ... more than 30 feet. Manual sez that you just buy a ordinary telephone extension cord to go further. I was dubious but tried it and am happy to report that it works. 30 feet of factory cable plus another 25 feet of el-cheapo extension cord and everything is working fine.

Challenge the second: how do you communicate with this beastie? The only relevant web sites I can come up with are either in German or French. By far, the most useful is published by my soon to be best friend Claude here. There is an english page describing the overall communication protocal if you hunt around for it.

There's also some brilliant sample code from Shell M. Shrader at {insert link here}. He's released a general communications 'glue' module under the GPL that I've adapted to work with my own code. Will be in touch with him soon to pass my changes back and see if he can do anything with them.

The remote transmitter provides the temperature and humidity readings, and there is a seperate anemometer (on a 30 foot cable) for wind speed and direction. There's also a seperate rain gauge that again has a 30 foot cable. The readings come back about every two minutes if the winds are light or about once a minute if it's windy. You also have the option of running a cable (30 foot, provided - what is it about 30 feet, anyway?) between the base station and the temperature sensor in which case the readings are done every 20 seconds. If the two minute reporting becomes an issue, I can always run a cable out to the sensor and get more real-time readings. So far, I'm thinking two minutes won't be a problem. The one day graph, for example, only has one data point every ten minutes.

The final issue is the outside cable. I've got it sort or temporarily hung on the fence but this is: unsightly; and prone to damage or vandalism. I've bought a whack of plastic electrical conduit that I'm going to attach to the fence and run the cables inside that. Half inch conduit was $3.19 per ten foot section, for the record. Cheap. Of course, the angles and the clamps and such brought the price up a bit but it was all still very affordable.

Technical Details

The program is implemented in Visual Basic 6. At one point I took a shot at migrating to VB.net but the migration tool MicroSoft provides is not exactly ideal. To do it properly, I'd pretty much have to rewrite the whole thing. It works fine in VB6 so I'm not planning on messing with it.

As of this version, the program can receive data from either a Radio Shack WX200, or a La Crosse WS23xx. I have a WS2315 but the same code should work fine with a WS2300 or a WS2310. The WX200 actively sent data every 5 seconds and it was just a matter of listening to the comm port and decoding the data when it came in. The WS23xx line is passive - you have to ask for the data. Right now, my code asks for data every minute more or less.

The data is displayed in a local window and there's an option to create web pages based on a template you design. The pages created this way can be written to a network share (what I do) or can be FTPed to a server on schedule you set.

The program starts a custom server on a TCP port and responds to requests from, for example, an active server page. The page can read the value of any data element as it's reported now. This was done to reduce network traffic - instead of creating a static page every minute, the server lets me create a page only when it's requested.

Every ten minutes, the program creates a set of graphs. There a set summarizing the last 24 hours; another set summarizing the last week; and a final set summarizing the last 12 months. Each set has a graph for temperature, humidity, barometric pressure, rainfall and windspeed. These graphs can also be created on demand by the TCP server.

I made the program as customizable as I could - you can choose wether to report in Celcius or Farenheit, in Miles/Hr or Km/Hr and so on. The original thought was to make the thing shareware or commercial but I lost interest.

Regarding the 'once a minute, more or less' comment above - the program starts requesting data at the top of the minute, i.e., when the seconds hit zero. Often, getting the readings takes 4 to 5 seconds. Equally often, it takes much longer - up to 2 minutes in some cases. One problem is if you're trying to read when the remote sensors are transmitting in, the base station won't talk to you until it's updated itself. Recovering from this seems to take considerable time, I'm going to go back and try to fix that. Other times, though, there's no obvious reason for the delay - it just takes a long time to respond. To be fixed ...

Things To Do:

Dog proof the outdoor cabling. Really, this must be done

This:

Negative Maximum?

The graphs go really funny if the top value is negative, apparently. Sadly, that happens a lot here with the temperature

There's a month or so missing in the almanac. I've got enough data to fill in the gap, just haven't gotten around to getting it into the new database.