Legacy Cumulus 1 release 1.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
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).
I've noticed an issue that seems to occur after a restart which causes a large spike in average wind speed. I have attached a screenshot showing two instances of this occurring after a restart today. The diags file is also attached, and line 271 appears to be where things go wrong:
The average wind speed then steadily decreases until it levels out at the correct value.
I have noticed that something similar seems to happen when cumulus does not receive any broadcasts from the WLL (ie, when the "No Broadcast Data Received from the WLL for 30 Seconds" error appears) - I end up with inflated 10-min average wind speed readings until the connection is restored. Worth noting that I had this same issue in Cumulus V3 as well. Possibly something to do with the way Cumulus tries to ensure it does not miss a peak gust when packets are not received? Just speculating. In any case, it causes me to have to manually correct my wind speed records from time to time.
You do not have the required permissions to view the files attached to this post.
A couple additional things that are happening on an unplanned PC restart. Daily rain seems to jump by the monthly rain to date, and all daily info up to the point of restart is erased. Wind run restarts from 0, daily highs/lows all reset as though the station just rolled over at midnight. I have attached my rain graph for the last two days showing two large jumps in recorded rainfall after a restart. Sorting out why my computer is constantly needing to restart on its own is another story.
You do not have the required permissions to view the files attached to this post.
This is probably one for Mark really who is away at present until about Tuesday of next week.
i would suggest however you install the latest build (4019) since you are running 4017 at present. make sure debugging is still on and run for a while, see if the same issue resides and post a new mxdiag log file for him to take a look at. Thanks.
can you confirm the CMX interval is the same as your WLL interval?
Regards Simon
https://www.conligwx.org - @conligwx
Davis Vantage Pro2 Plus with Daytime FARS • WeatherLink Live • Davis AirLink • PurpleAir • CumulusMX v4.0.0
A few logs attached to this message. Cumulus/WLL was acting up at least twice in this period, once around 13:15 and again at 19:40 on May 1. Both instances were times when no broadcast data was received for an extended period, which for some reason causes the average wind speed to increase significantly. No idea what cases the WLL broadcast data to stop being received, as the WLL continues live updates to weatherlink during this time (ie. I can go on my phone and see 2.5 second wind updates on the app). Wouldn't bother me much if the recorded data remained correct during these times.
You do not have the required permissions to view the files attached to this post.
And here is the wind speed chart for this period. Not exactly the same issue as I described in my original post, but I'm thinking the two might be related.
You do not have the required permissions to view the files attached to this post.
I took a look at this yesterday, I think I can make an improvement to the WLL station code, but only so much.
The basic problem is the WLL provides two very different types of data.
The broadcast data contains the last instantaneous (2.5 second) wind speed, but no average speed.
The "current" data is not actually the current data, but the last record that was created for upload to weatherlink.com and so is a minute out of date.
The current data contains maximum gust values, and average wind speed values.
Normally MX runs by reading each broadcast packet and calculating the average speed from the instantaneous values (like the WLL does itself). It also reads the "current" values periodically and checks the maximum gust value to ensure a gust was not missed from the odd missed broadcast message.
If no broadcasts are being received, then MX falls back to using the out of date "current" data and uses the gust and average speed value from there.
This is fine if broadcasts are always received, or they are never received. In your case however broadcasts are received intermittently which causes a big problem. Because during the long periods no broadcasts are received MX populates its internal data with just max gust values and averages. When broadcast start being received again it switches back to calculating the average - but the last 10 minutes is now full of max gust values not instantaneous, so the average comes out much higher than it should until those max gust time out of the buffer.
I have a possible solution to that I want to test out, but it does not solve your underlying problem - you are not receiving the broadcast reliably, in fact they are extremely unreliable! That will be down to your local network. The broadcasts are UDP so not fire and forget, there is no guaranteed delivery.
I'd suggest you look at the computer connectivity - hopefully ethernet rather than WiFi - and your router in the first instance, plus traffic congestion (UDP packets are dropped if connections are too busy), router CPU usage etc.
Appreciate you looking into this Mark. I think the underlying issues I'm having are related to my ancient laptop having connectivity issues lately. If I am understanding everything correctly, the same UDP packets that CMX uses are used by the Weatherlink mobile app to give 2.5 second wind updates as long as your device is on the same wifi network as the WLL. During extended periods of missed packets by CMX, the WLL app on my phone continues displaying 2.5 second updates without missing a beat, which tells me the packets are being broadcast to the network successfully, but the computer running Cumulus is not picking them up for one reason or another. I have Cumulus running on my main desktop PC for the time being to see if I can get a better % of good packets received.
In any case, some sort of built-in safety to prevent these wind speed spikes when resuming live data after a period of missed packets would still be a good thing to have.
The next build of v4 has a rewritten broadcast handling routine that recovers from missed packets much better. The current version seems to take its time to start seeing them again every so often.
