Cumulus Support

Hi,

The weather forecast as we know is based upon the Zambretti algorithm and this is driven by 2 main factors (I think beteljuice added a tweak for summer/winter and also which hemisphere) pressure and wind direction. I’m sure that many have noticed the odd occurrence when the forecast fluctuates frequently this is mainly due to the wind direction which in it’s present guise can alter the forecast from 1 to 3 options e.g. Rather Unsettled Clearing Later to Showery Becoming more unsettled and back again. There is an ini file which one can use for pressure thresholds which can help but this doesn’t improve the wind direction issue. I know that the WH1081 is cheap and prone to a weather vane that is skittish; however, I did observe similar forecast behaviour from a Davis Vantage site, albeit not so extreme.

What I don’t know (Is a great deal!!) is, over what period the wind direction heading is measured/averaged. If it’s 10 mins then for forecasting this would seem too short a period given that we are looking at a forecast for the next 6 to 12 hours. I would think that having an option in the ini file to alter this period (anything from 30 mins to 2 hours) would improve the stability of the forecast and possibly the confidence of the user…. Just a thought open to feedback.

Yes, the interval for the average direction is 10 minutes (and takes speed into account). I don't know how easy it would be for me to do an average over an increased period, or indeed, whether this would help the forecast (since it only uses 16 compass positions as input anyway). Perhaps beteljuice could comment, as he is much more familiar than I am with the way the forecast works...

I've had a look at the code and it would be an easy enough change. The only slight complication is that the way it works is that I keep the last 300 readings and use the most recent 10 minutes worth to calculate the average, so there's a limit to the length of the period depending on the station type, because the read interval is different for each. For Fine Offset it's 10 seconds, so 300 readings covers 50 minutes. For Davis stations, 300 readings is only about 12 - 15 minutes. Yes, I could increase the 300 limit if required.

I'm assuming that there would still only be one average, not a special one calculated for the forecast.

It's more devious than that I'm afraid (forecasting-wise), that is one of the reasons it would be difficult to implemement the Sager algorithm for (home) auto wx.

What we really want to know (for forecasting) is wind direction 'trend' over eg. the last FOUR hours, and also if it is 'following' or 'leading' the Sun (Unclear if this logic reverses for Southern hemisphere). Actually only four wind directions are considered 'important', anything else is considered on the way to one or the other, I have tried (sucessfully ?) to rationalize that and take a best guess

.... no wonder MetO has problems

Hi Steve,

I’m not sure where this leaves you in deciding if and what should be done regarding the forecasting feature within Cumulus. It would seem that extending the period for the wind direction trending will improve the forecast and for me this is worth having (but I like milk in my coffee and others like it black!!).
What is clear is that there is a very big difference between 10 mins and having 4 hours – If it were easy for you to average the 300 readings then I would be happy to test this rather than forcing it on all users. Could it be an option turned on by the ini or the (more work) Station settings?

The forecasting feature probably falls into two camps – The “Don’t care, it’s not why I have a PWS” and the “Yes, It is one of the reasons why I have a PWS so I don’t have to tap my Barometer”. I don’t know which camp the majority fall into but I guess all PWS users have an innate interest in what the weather is doing and what it is likely to do; If not, then why not just listen to the weather forecasters on the TV/Radio and save ourselves money and time…. Hopefully others will put in their two penneth.

My position on the forecast feature is that it's for novelty use only. But the possibility of doing forecasts does interest me, and while I'm very grateful to beteljuice for not complaining when I stole his code, without which Cumulus wouldn't have a forecast at all, I am sure there is a lot of room for improvement over the Zambretti algorithm.

Having said that, I'm prepared to put this in as an ini-file option, because it's fairly easy to do, and may have the added benefit of smoothing out even further the average direction for the erratic Fine Offset wind vane.

So, I propose to increase the number of stored readings to 360 and add an ini-file option to specify the number of minutes over which the average wind direction is calculated - default 10 as now. This will give a maximum of 60 minutes for Fine Offset stations. You can then have a play with it, and if it looks useful, we can consider storing more values and increasing the period further. OK?

Steve - you're a star

While we are on the subject of the Cumulus Forecast.....
Would it be possible to have it base a forecast on the readings taken throughout the day and night and send out One forecast at 9am/10am summer every day?

I agree on the wind issue.

Guys - you didn't read what I wrote ...

At the moment there is NO wind 'trend' over any period of time it is an average. but even when you have that, the next problem is ..

and also if it is 'following' or 'leading' the Sun (Unclear if this logic reverses for Southern hemisphere).

... then you need to re-code the algorithm and it's input to make use of this additional data.

As Steve said .. this is a 'fun' add-on to Cumulus.

.... Forecasting is not that easy, man has been trying for many hundreds of years and still can't get it right !

beteljuice wrote:At the moment there is NO wind 'trend' over any period of time it is an average.

Yes, understood, but what we're trying to achieve here is a better (more stable) average direction value for the flappedy-about Fine Offset wind vane by increasing the period of the average, hence making it slower to change. I think.

I'm assuming that there would still only be one average, not a special one calculated for the forecast

.. but wait, didn't someone request a 2min average.

At the moment there is some sort of conformity on the figures / graphs, both within Cumulus and the 'weather community'. If you only have the one (avg) value and it's sample period is in freefall ....

beteljuice wrote: .. but wait, didn't someone request a 2min average.

Yes, for the wind speed but in any case I think they have a VP2 with a 2-3 second sample rate. A 2-minute average for wind direction with a Fine Offset with its 48 second sample rate would be pretty pointless. But still better than the 'raw' direction, possibly.

At the moment there is some sort of conformity on the figures / graphs, both within Cumulus and the 'weather community'. If you only have the one (avg) value and it's sample period is in freefall ....

Some sort of conformity... there are 10-minute averages out there, 2-minute averages, 1-minute averages. The stations which Cumulus supports all have different ways of measuring and presenting wind data... 2.5 second samples, 14-second samples, 48-second samples...

Anyway, I used to argue against adding options that I thought were silly, but it tired me out, and in many not-too-silly cases I gave in anyway. This request seems not unreasonable and is easy to do.

I've uploaded a new build (901) with this change. To use, edit cumulus.ini and add a line in the [Station] section:

AvgBearingMinutes=10

Where 10 is the default; change as required.

I've increased the max number of samples to 720, so the maximum effective value for this for Fine Offset stations is 120 (2 hours).

Note: the way this works at start up (and has always worked) is that Cumulus includes any new data downloaded from the logger in the calculation, but doesn't 'backfill' from the data log, which is somewhat inconsistent but a pain to do anything about.

Tried using build 901 but Cumulus fails to start. Bug report attached

Have you set the new value? If so, what have you used? It's possible that the way I'm encoding the time might not work for values >59