Outline

This page descirbes the suggested design for a basic weather reporting web site. To recap, this design calls for updatable weather observations (current temperature, pressure etc) to be embedded in graphic images. These 'data' images are generated by software such as Weatherview 32, supplemented by other utilities to assist  with quick and robust operation and uploading of the site.

To translate this outline design into a working OLAWS requires attention to a number of aspects of the system. To set the scene, consider the sequence of events when generating and uploading an update:

1. Running to a specified schedule, WV32 generates an updated image file containing the latest observation set;
2. The image file is further processed to optimise image file size and quality;
3. Running possibly to a separate schedule, a dialup FTP connection to the remote web server is attempted and, if successful, the image file upload is triggered. (Immediately thereafter the web server will, on request, serve the updated weather information);

This brief description has actually introduced several new issues. Perhaps the next key concept is that there are a number of detailed steps involved in an upload, which must all happen in the correct sequence and to a precise schedule.  We therefore need a co-ordinating 'ringmaster' utility which can call a set of diverse 'helper' software utilities (quite separate from WV32)  in a carefully orchestrated sequence, at the right time and will keep an eye on what they're doing. In functional terms, this equates to a Windows utility with both scheduling and 'macro' or batch capabilities. ('macro'   meaning the ability to store a set of commands which can be passed on to individual utilities in a prescribed order). Let's examine this requirement further:

Scheduling and co-ordination utilities

There are, or seem to be, 1001 different Windows schedulers available on a shareware basis. But, in reality, few of them match up to the flexibility that we ideally need. For example, operating on a small budget we might decide that having to pay the phone bill for uploads 24 hours a day is an extravagance. There are likely to be few visitors over the period 2300-0700 and it would save something to suspend uploads for this period. But from 0700-2300 we need uploads every two hours, but perhaps a few minutes past the hour to avoid clashing with other activities scheduled to happen on the hour. And if there was an interesting short-term weather event occurring, we might wish temporarily to be able easily to switch to hourly updates. This is actually quite a demanding scheduler specification.

Another important aspect concerns the extent to which it's helpful to combine the scheduling and co-ordination activities and there are two points of view on this. Some users may prefer to keep the software diversity to a minimum and accept some resulting constraints on the capabilities of the system. This school of thought would look for a scheduler that has some intrinsic co-ordinating functionality - a number of 'schedulers' have extra functions beyond launching an application at a specific time. For example, it's not uncommon for a scheduler to be able to monitor the characteristics of a specified file, eg its timestamp. When it spots that the timestamp has changed, ie an update to that file has occurred, the scheduler will trigger further actions. This type of scheduler would be paired with helper utilities which are programmable in that they can be set up their own script files to determine exactly what actions should be undertaken. This is a perfectly useable approach - and in some ways the easiest - but there will always be limitations in trying to use utilities for purposes beyond their primary function.

The alternative approach is to separate the scheduling and co-ordination functions and have them performed by distinct utilities. While this is potentially a little more complex, it is also undoubtedly much more flexible and powerful, and is the solution that I prefer. This approach therefore calls for a scheduler, which can be chosen simply for its power and flexibility in scheduling, to be used in conjunction with macros or batch files containing the co-ordinating commands. In practice, there are many software tools which could be used to perform these functions and anyone with some experience in automating Windows activities may have their own favourites. For example, the batch files could, in principle, be something as simple as DOS batch files provided they were set up to be executable within the Windows environment. However I have chosen to use a batch utility called Ground Control which is designed to control Windows applications (at least to the extent that they will, individually, allow external control). This is an interesting utility with a large command set, including a number of specific commands for opening/closing windows etc and, generally, for being able to perform all sorts of actions, including DDE control, on a conditional basis. I use Ground Control in conjunction with a Windows scheduler called LaunchPad. These two utilities are ostensibly from different companies, but are co-promoted and seem to be designed to work harmoniously together. For further details, please see:

As with most of the utilities mentioned in these notes, LaunchPad and GroundControl are shareware utilities which are available free for evaluation for a nominal 30 days, but which need to be bought to be legally used thereafter. I do very much recommend that you do buy them if you decide to use them - for reasons beyond the ethics of using unregistered software - the unregistered versions have nag screens and similar devices which can disrupt the smooth running of automated systems. Note that most of the utilties described here are relatively inexpensive ($20-50 - all tend to be from the US) and buying all of the recommended set shouldn't add more than £50-100 to the total price of the OLAWS system.

Scheduling in practice

There are, in practice, several distinct timing cycles which may be running in parallel in an OLAWS system. To start with, most AWS consoles continuously (eg every 2-3 secs) update certain weather values across the PC interface, which will be reflected in the real-time screen display of the local AWS PC when it is running, for example, WV32. The console will usually then additionally have a logging setting, which specifies the time at which the system will refresh and log a complete data set. This might typically be on a 5 minute setting.

A third cycle, relevant to the AWS software saves the new observational data in a format suitable for web uploads eg WV32, will be the frequency with which this process occurs. The timing of this cycle will generally be set within the AWS software and will not be responsive to the separate scheduler. In principle, this AWS cycle does not need to run any more often than the subsequent server upload cycle, although the timing does need to slightly ahead of the upload cycle to ensure that the newest available data is always uploaded. But there are minor advantages to running the AWS cycle more frequently. For example, it's often handy during system testing to have relatively frequent updates available and, on occasions when the AWS PC may have been switched off eg overnight or for system maintenance, it's a nice idea to be able to upload the latest available data set, rather than one which may be 1-2 hours old. I've chosen to generate new AWS web data every 30 mins, even though the upload cycle is 2 hourly.

The fourth and final cycle is the upload cycle which refreshes the data on the web server. This is the cycle controlled directly by the separate scheduler. In the context of this UK-based website (where users have to pay for Internet phone connection) the frequency of updates will usually be determined by the costs involved. A single update will, taking full account of standard discounts, cost around 3p. Serious enthusiasts and small organisations will probably accept a running cost of 8-10 updates a day or around £8-10 monthly, though even half this frequency might still be considered worthwhile. As noted above, I have settled on a 2 hourly update cycle, but switching off the updates overnight (2301-0659) which the LaunchPad scheduler enables me to do. This gives me a standard 9 updates daily.