Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.16.1 (build 3183) - 06 May 2022

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

If you are interested in supporting Cumulus then maybe you would like to contribute to the maintenance of the Wiki? This need not take hours of your time - just a half hour here and there can make a big difference, particularly if many people are doing this. Any contributions are very welcome, whether they involve new content or editing of existing content. It will be very helpful to current and future users of Cumulus software if the Wiki is kept well-maintained and current. If you are interested then please contact forum user saratogaWX and ask for a Wiki account.

Wind rose time frame

From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).

Moderator: mcrossley

Post Reply
User avatar
billy
Posts: 191
Joined: Mon 30 Nov 2015 10:54 am
Weather Station: Davis VP2+
Operating System: RPi bullseye
Location: Gooseberry Hill, Western Australia

Wind rose time frame

Post by billy »

The standard wind rose gauge in the admin interface gives no indication of the time over which the wind rose data have been collected. It includes the last 3600 readings. I guess the time frame will be dependent on the frequency of the readings, which presumably vary with station type? Also, when mx has been recently started, it will take a little while to accumulate 3600 readings I guess?

I'm thinking it might be more useful if the time frame ... or start time ... could be added to the gauge but I can't see how the time frame or beginning/oldest observation can be ascertained? Dare I suggest maybe it needs a webtag?
User avatar
HansR
Posts: 3325
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: Wind rose time frame

Post by HansR »

billy wrote: Fri 28 Jan 2022 7:10 am The standard wind rose gauge in the admin interface gives no indication of the time over which the wind rose data have been collected. It includes the last 3600 readings. I guess the time frame will be dependent on the frequency of the readings, which presumably vary with station type?
I have been thinking about this wind rose recently as well. If it is indeed 3600 samples, it was originally probably meant to be just the last hour. As only the aggregates appear in realtimegauges.txt, maybe CMX just should normalise those values really to the last hour which does not seem to be the case now. If the wind changes in several hours the whole gauge becomes purple which is confusing.
billy wrote: Fri 28 Jan 2022 7:10 am Also, when mx has been recently started, it will take a little while to accumulate 3600 readings I guess?
I tried a CMX restart and the gauge did indeed reinitialise.
billy wrote: Fri 28 Jan 2022 7:10 am I'm thinking it might be more useful if the time frame ... or start time ... could be added to the gauge but I can't see how the time frame or beginning/oldest observation can be ascertained? Dare I suggest maybe it needs a webtag?
May I suggest - of course up to Mark ;) - to use the RecentData table in cumulusmx.db to initialise the realtimegauges.txt and have it consistent at a (re)start only to really initialise when data in the db are too old? Webtags are already very abundant and are for use as data source in websites, not for explanation of gauges. I think that would be quite confusing.

My two cents.
Hans

https://meteo-wagenborgen.nl
https://meteo-wagenborgen.nl/CMX4
CMX build 3182 ● Ecowitt GW1100/WS80/WH40 ● RPi 3B+ ● Raspberry OS 5.10.103 ● Mono 6.12.0.122
CMX build 40xx ● Ecowitt GW1100/WS80/WH40 ● RPi 4B ● Raspberry OS 5.15.32 ● .NET 6.0.1
AllyCat
Posts: 1108
Joined: Sat 26 Feb 2011 1:58 pm
Weather Station: Fine Offset 1080/1 & 3080
Operating System: Windows XP SP3
Location: SE London

Re: Wind rose time frame

Post by AllyCat »

Hi,
HansR wrote: Fri 28 Jan 2022 9:13 am If it is indeed 3600 samples, it was originally probably meant to be just the last hour.
No I don't think so. AFAIK the 3600 is correct and dates back to (the early days of ?) Steve's original Cumulus 1. That only "read" the data once each minute and typically logged it even less frequently. Since the rose "builds up" when downloading historical data (from the Console/Logger), I assumed that it covers 3600 x the Logging Interval, which is quite a "long time". ;)

I've always assumed that it was just "as big a number as is practical" and must admit that I've sometimes thought that it could be "useful" to make it "configurable". But having occasionally been at the "sharp end" of programming, I tend to refrain from making change/feature requests. :)

Cheers, Alan.
User avatar
HansR
Posts: 3325
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: Wind rose time frame

Post by HansR »

AllyCat wrote: Fri 28 Jan 2022 9:57 am But having occasionally been at the "sharp end" of programming, I tend to refrain from making change/feature requests.
Ah, Ok. So the logging interval is the determinant. Than it is a normalisation which has to take place to make it consistent which is more a 'bug fix' , configuring would be a change I assume.

On the other hand: from what I have seen Mark is a grown up, above average able programmer so we may give ideas, he may decide. ;)
Hans

https://meteo-wagenborgen.nl
https://meteo-wagenborgen.nl/CMX4
CMX build 3182 ● Ecowitt GW1100/WS80/WH40 ● RPi 3B+ ● Raspberry OS 5.10.103 ● Mono 6.12.0.122
CMX build 40xx ● Ecowitt GW1100/WS80/WH40 ● RPi 4B ● Raspberry OS 5.15.32 ● .NET 6.0.1
User avatar
mcrossley
Posts: 9987
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Buster Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Wind rose time frame

Post by mcrossley »

You have the correct summary, the answer to the what time period it covers - it depends.

During normal running, it is 3600 samples, each taken from station readings, so for a WLL station it will be 3600 * 2.5 seconds, for an EasyWeather station it will be 3600 * 60 seconds.

During catch-up it will be 3600 * archive interval.

And for a period after catch-up it will be a mixture of the two until the archive records are overwritten.

I think the wind rose was really intended to be an indication of recent conditions rather than a scientific display.
sfws
Posts: 1106
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: Wind rose time frame

Post by sfws »

billy wrote: Fri 28 Jan 2022 7:10 am I can't see how the time frame or beginning/oldest observation can be ascertained? Dare I suggest maybe it needs a webtag?
Existing web tag <#WindSampleCount> gives number of samples, so to work out time frame you need time between samples.

If you look at existing web tag <#nextwindindex> and compare its current value, to its value say 2 minutes ago, you can calculate the interval time between samples.

For the legacy Cumulus, the interval was fixed for any one weather station, so you could work out the start time from that information (calculated sample interval times <#WindSampleCount>).

For that legacy software, IIRC the array was not populated during catch up, so your choice of station logging interval was irrelevant. MX works differently, it does populate the array during catch-up. So the above calculation only works when MX has been left running for at least 12 hours with Oregon Scientific stations, less for other types, not when MX recently restarted:
mcrossley wrote: Fri 28 Jan 2022 10:45 am for a period after catch-up it [the interval] will be a mixture of the two until the archive records are overwritten
EDIT: added blue text about 12 hours above, and made layout of text about existing web tags clearer
=============================================================================
AllyCat wrote: Fri 28 Jan 2022 9:57 am No I don't think so. AFAIK the 3600 is correct and dates back to (the early days of ?) Steve's original Cumulus 1. That only "read" the data once each minute and typically logged it even less frequently.
The wind rose was introduced in Cumulus Version 1.3 on 18th January 2005, Steve Loft did not retain his release announcement forum posts from that time, so it is unlikely that the reason for choosing 3600 still exists anywhere. What we do know is that Steve changed from time to time the weather station type he used, and in those early days, it was Steve's own needs that determined what the legacy software did, not demands from other users.

Steve's design for his legacy software tried to minimise variations by weather station type, so many types were read once a minute, but from what I remember, the legacy Cumulus read the original Davis stations every few seconds (because it suited Steve when he used one of those). The original Fine Offset clones, all transmitted wind data at 40 second intervals, so only reading them at 60 second intervals meant some wind readings were missed from that rose, it was never intended to be taken too seriously!
Last edited by sfws on Sat 29 Jan 2022 7:12 am, edited 1 time in total.
User avatar
PaulMy
Posts: 3042
Joined: Sun 28 Sep 2008 11:54 pm
Weather Station: Davis VP2+ Cumulus1 / CummulusMX
Operating System: Windows8 / Windows10
Location: Komoka, ON Canada
Contact:

Re: Wind rose time frame

Post by PaulMy »

Not sure if this helps? viewtopic.php?p=37#p37

p.s. I didn't realize Cumulus was available in 2005. I stumbled on it in 2008 and thought that was the start. Still learn something every day>
I remember reading Steve's intro at the time saying it was free for non-profit and since I was involved with a non-profit I though I am ok on using it, even though I had no clue...

Enjoy,
Paul
sfws
Posts: 1106
Joined: Fri 27 Jul 2012 11:29 am
Weather Station: Chas O, Maplin N96FY, N25FR
Operating System: rPi 3B+ with Buster (full)

Re: Wind rose time frame

Post by sfws »

PaulMy wrote: Fri 28 Jan 2022 6:01 pm Not sure if this helps? viewtopic.php?p=37#p37

p.s. I didn't realize Cumulus was available in 2005. I stumbled on it in 2008 and thought that was the start. Still learn something every day>
Thanks Paul for finding that post, certainly clarification that 3600 length is not same period for all.

I am surprised to be teaching you, if you look at the file in your Cumulus 1 installation labelled "changes.txt", although content may depend on your download, first public release 1.0 was dated 27 January 2004.

Steve has documented somewhere, he developed Cumulus in summer 2003, after buying his first weather station, an Oregon Scientific weather station, that was before he moved to Orkney (Sanday).
User avatar
PaulMy
Posts: 3042
Joined: Sun 28 Sep 2008 11:54 pm
Weather Station: Davis VP2+ Cumulus1 / CummulusMX
Operating System: Windows8 / Windows10
Location: Komoka, ON Canada
Contact:

Re: Wind rose time frame

Post by PaulMy »

Still learn something every day>> Thanks!
I've often referred to the updates.txt in CumulusMX but had never looked in the Cumulus1 changes.txt as I just tried to keep up to date with each release and read Steve's release notes.

Paul
User avatar
billy
Posts: 191
Joined: Mon 30 Nov 2015 10:54 am
Weather Station: Davis VP2+
Operating System: RPi bullseye
Location: Gooseberry Hill, Western Australia

Re: Wind rose time frame

Post by billy »

Thanks for a very interesting discussion.

I should point out my reason for posting was not because I have much invested in using the admin's and standard website wind rose ... virtually none! ... but rather a curiosity in just how it is constructed and therefore what it shows. This came about because I am in the process of tidying up my sql-based version ... which has some value given the marked diurnal shifts in wind direction and speed we experience here.

The bottom line I take away from the discussion - given my initial question - is that in contrast to all the other gauges, the interface/mx website wind rose is a pretty picture ... but without any indication of what constitutes "recent" it's also pretty useless ;). Just imagine for a moment if the wind run had some sort of undefined starting point or temperature was stated without the units etc.

An obvious way it could be brought into some sort of meteorological "respectability" is to indicate the time frame. From the discussion, there doesn't seem to be any momentum for that so maybe the gauge could be transformed to a wind run gauge? :o

Of course one of it's problems is it is more a graph/plot/chart (depending on the realm you think in) than a measure taken in the previous few seconds like the other gauges - except rainfall of course, but there we have a clearly defined starting point.
User avatar
mcrossley
Posts: 9987
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Buster Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Wind rose time frame

Post by mcrossley »

I'll add it to a "think about doing list" to make the wind rose use a fixed time period. As it is supposed to be "recent" rather than an official 24 hour rose, I'd propose a 12 hour time span.
If it was a fixed time span it would probably also move to fixed 1 minute intervals.
User avatar
HansR
Posts: 3325
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: Wind rose time frame

Post by HansR »

mcrossley wrote: Sat 29 Jan 2022 10:22 pm I'll add it to a "think about doing list" to make the wind rose use a fixed time period. As it is supposed to be "recent" rather than an official 24 hour rose, I'd propose a 12 hour time span.
If it was a fixed time span it would probably also move to fixed 1 minute intervals.
May I suggest a 6 hr or maybe even a 3 hr timespan?
Hans

https://meteo-wagenborgen.nl
https://meteo-wagenborgen.nl/CMX4
CMX build 3182 ● Ecowitt GW1100/WS80/WH40 ● RPi 3B+ ● Raspberry OS 5.10.103 ● Mono 6.12.0.122
CMX build 40xx ● Ecowitt GW1100/WS80/WH40 ● RPi 4B ● Raspberry OS 5.15.32 ● .NET 6.0.1
water01
Posts: 2503
Joined: Sat 13 Aug 2011 9:33 am
Weather Station: Ecowitt HP2551
Operating System: Windows 10 64bit
Location: Burnham-on-Sea
Contact:

Re: Wind rose time frame

Post by water01 »

I would personally vote for the longer of the four proposed so far i.e. 24/12 hr as I like to see where the wind has been over those longer periods. CWOP uses 36/2 hrs and others vary.
David
Image
User avatar
billy
Posts: 191
Joined: Mon 30 Nov 2015 10:54 am
Weather Station: Davis VP2+
Operating System: RPi bullseye
Location: Gooseberry Hill, Western Australia

Re: Wind rose time frame

Post by billy »

mcrossley wrote: Sat 29 Jan 2022 10:22 pm I'll add it to a "think about doing list" to make the wind rose use a fixed time period.
Given it has not had a defined starting point for the best part of two decades - without being questioned - I don't think this is a pressing matter. 12 hours seems about right.
User avatar
billy
Posts: 191
Joined: Mon 30 Nov 2015 10:54 am
Weather Station: Davis VP2+
Operating System: RPi bullseye
Location: Gooseberry Hill, Western Australia

Re: Wind rose time frame

Post by billy »

These may be of interest - 3 wind roses over the same time and time frame ... 90 minutes. From the left

(1) the current standard rose - my console seems to get an update from the wind sensors every 1.5 sec (it took ~90 minutes from cmx startup to fill the data set), so n = 3600 data points covering the previous 90 minutes.
(2) the data are from my sql realtime file which records current conditions at 1 minute intervals, so n = 90. The wind direction & speed are the latest values, equivalent to the webtags currentwdir and wlatest.
(3) from same sql realtime file with n = 90 but wind direction & speed are the 10 minute averages (wdir & wspeed) so each of the 90 data points are running means. This has the disadvantage that much of the variation in wind stats are lost but maybe some would like the simplicity.

... I prefer (2) over (3).

The two on the right use adaptations of Mark's php files.

Roses.jpg
You do not have the required permissions to view the files attached to this post.
Post Reply