Cumulus 1.8.4 beta

[TNETWeather]

I just loaded the 552 verison and turned on the solar stuff.

It is a little to late to see UV, but Solar radiation matched WD's output so that part is working.

Will check in the morning on the other.

[steve]

Thanks, Kevin. It seems to be working OK for Jozef too, so far.

Steve

[broadstairs]

Solar on its own is fine as well, UV shows correctly as zero as I dont have that....

Stuart

[steve]

Thanks.

[Micrex]

Hi Steve,

I have recently purchased a Watson W-8681, this came with Version 2 of Easyweather which suffered with the monsoon rain problem. I download version 4.16, same problem and have now installed version 5. This also suffers the rain issue. I installed Cumulus and initially used the Easyweather (using .dat file) option. Doing this resulted in both Eayweather and Cululus reporting massive rainfall. I reconfigured Cumulus to use the Fine Offset option and just used Cumulus. This seemed to be fine, however yesterday morning I noticed that the rainfall graph was showing 2 peaks of 25mm of rain when in fact there had been no rain. I closed Cumulus and started Easyweather which promptly downloaded the data from the Watson display unit. This did not show the 2 peaks of rain.

It would seem to me that the rain issue is nothing to do with either software programs and likely to be some type of corruption occurring during the data transfer. Quite why this should only happen on odd occasions is a mystery. Perhaps its some kind of interference on the USB bus. Anyone got any ideas.

As a registered blind person I find Cumulus much easier to view with my limited vision. I really like the feature that allows me to set the colours for the display, a very useful facility for the visually impaired. It would be nice if it were possible to change the text to Bold font, and a graphical representation of the temperature onscreen would be nice.

I tried version 1.8.3 Beta and had problems with it as it would not read the data from the weather station I have also tried version 1.9.4, but again the program hung while downloading data. After trying several combinations of loading the latest versions I eventually managed to get version 1.8.4 build 552 to work. I achieved this by uninstalling all versions, and deleting the Cumulus directory from Program files, re-booting the computer, re-installing build 552 and finished the install with the Launch Cumulus box UNTICKED. I then re-booted and run the program and this time the data was retrieved ok.. To prove the point I un-installed again, then re-installed Cumulus with the Launch Cumulus box ticked and again the data was not found and the program hung..

Regards,

Mike (Micrex)

[steve]

Mike,

It's becoming apparent that the headers on the data sent by the Fine Offset stations varies quite a bit, making it difficult for Cumulus to check that it's receiving what it expects to receive. I put a change into 1.8.3 to cope with a case where one of the headers was repeated. Someone fell over this because the algorithm for detecting the repeated header didn't work on their system, due to the differing format of the headers in their particular case. I put a change into build 552 which worked for them.

It sounds like your headers are in a similar format to the one where it failed with 1.8.3, but works with build 552. I really can't explain why it doesn't work when you run it from the install. Could you send me the file from the Diags folder for the case where it failed and one where it worked?

Steve

[harrym1byt]

> It would seem to me that the rain issue is nothing to do with either software programs and likely to be some type of corruption occurring during the data transfer. Quite why this should only happen on odd occasions is a mystery. Perhaps its some kind of interference on the USB bus. Anyone got any ideas.

Hi Mike,

The rain record problem has quite a history. EasyWeather V1 and V2 suffered from it quite regularly. You could have it download bad data from the display, see that the rainfall was corrupted, delete just that latest data, download it again and find there was no problem - so the corruption was definately a problem with the download or the USB. The problem was more likely, if you had not run EasyWeather for some time and there was a lot of data to be downloaded.

V4 then V5 seemed to not be troubled by the problem, but today I did notice some rain data corruption for the first time in V5. Not quite to the extent noticed in V1 and V2, but none the less it was corrupted. The easy way to spot it is in the rain graph, where the thin red line becomes much thicker and if you zoom in on it you see the line is actually a tight up and down zig zag causing the thickening.

[TNETWeather]

UV is now showing since there is some UV to show. The W/m2 value is proper as well.

There should be two values for Solar, one is W/m2 the other should be a % of solar. Percentage can be used to discover cloud cover as W/m2 will vary based on sun angle and the time of year. This time of year for example the W/m2 values would be lower than say during the middle of summer.

[steve]

The Davis DLL only gives me the W/m2 value for solar. Presumably the software has to calculate the %, but won't it be based on a complicated calculation like the sunshine hours?

Steve

[broadstairs]

The Davis DLL only gives me the W/m2 value for solar. Presumably the software has to calculate the %, but won't it be based on a complicated calculation like the sunshine hours?

Steve

Steve sadly yes it does need a complicated calculation because the % is the % of actual versus expected max for that lat/long and time of day. Once you have that the sunshine hours are the easy bit!

Stuart

[TNETWeather]

Sorry.... I'd not looked at the DLL code to see what was supported. Wasn't aware that was a calculated value. I had assumed (wrongly) that it was a value provided by the station. I see now, looking at both the DLL reference guide and looking at the Console itself, it only provides W/m2.

Thanks.

[TNETWeather]

I actually plan on playing around this vacation with Windows programming... something that I've got the tools for, but never actually tried them. I think I will upgrade the Studio Net that I have first though. I currently have 2005, will upgrade to 2008 first.

Vacation starts Dec 12th for the rest of the year... play time!

[garytx]

Steve -

I must say I'm impressed with the 1.8.4 beta (and the production release of 1.8.3 for that matter)! It is really a treat to now have solar and UV data in Cumulus, and, though I've only been running 1.8.4 for a few hours, the data seems to be spot on. One request would be (primarily for us non-standard Americans using Imperial measurements...) to have the ETo reading go to 3 decimal points. Even here in hot and dry central Texas, many a day we have less than 0.02 inches of ETo, and having the reading show just 0.01 all day (once ETo surpasses 0.005" anyway) doesn't quite tell the story. I realize the ETo calculation from the VantagePro is pretty coarse to begin with, but I'd like to see what is offers to the extent possible.

I'm also impressed with the forecast calculation now internal to Cumulus. I've used a PHP include statement to present the VantagePro's forecast below the Cumulus forecast just for grins and comparison (http://www.wilcowx.com/cumulus/indexf.php if anyone wants to see). It appears, at least from initial running, that the Cumulus forecast updates more frequently than the once per hour of the VantagePro (or perhaps that was just from the initial couple hours of running Cumulus with the internal forecast presenting.)

There appears to be a bug with the <#temptrendtext> tag. I was posting that one and the <#temptrend> tag together to show the trend and rate. The temptrendtext tag was processing as "Falling" but the rate was showing as "+2.5". I presume this is a bug unless perhaps the temptrendtext tag uses a period longer than an hour from which to derive the trend. [EDIT: You can see how these two tags present at http://www.wilcowx.com/cumulus/tags.html, which is a page taken from the Cumulus help file that processes all of the tag files that I upload for my own testing/validation.)

A final word and request. A couple developers (SoftWX, maker of the wonderful Virtual VP and VP Live and Brian Hamilton at Weather Display) have managed to come up with code that forces the VantagePro barometer to update once per minute instead of the factory default of a perplexingly infrequent once per fifteen minutes. Incorporating that feature into Cumulus would be an absolutely wonderful addition (and likely improve the forecast accuracy!) I only mention that others have cracked the code to show it's doable, not to suggest you're lagging behind anyone with the support and features of this wonderful product of yours. I'm proud and very appreciative of being able to count myself amongst Cumulus users, and thank you once again for your expertise, dedication, and support!!! (I'm pretty sure Steve at SoftWX would gladly share his technique for barometer forcing by the way.)

[steve]

Gary,

Thanks for those comments, they're very useful.

One request would be (primarily for us non-standard Americans using Imperial measurements...) to have the ETo reading go to 3 decimal points.

The station is only accurate to 0.01", so 2 dp is the best I can do.

It appears, at least from initial running, that the Cumulus forecast updates more frequently than the once per hour of the VantagePro

Yes, it updates whenever one of the readings that make up the forecast changes.

There appears to be a bug with the <#temptrendtext> tag. I was posting that one and the <#temptrend> tag together to show the trend and rate. The temptrendtext tag was processing as "Falling" but the rate was showing as "+2.5".

Yes, a rather strange bug which only appears if you're using degrees F

Fixed in the build I'm about to upload.

VantagePro barometer to update once per minute instead of the factory default of a perplexingly infrequent once per fifteen minutes.

I didn't realise it did that. Of course, it's only an issue if the pressure is changing quite rapidly, but I can see that it wouldn't have to be too unusual a situation for it to make a difference. I'll look into it.

Steve

[garytx]

Wonderful, Steve, thank you.

On the ETo, the station actually records (actually, calculates) evapotranspiration to three decimal points (in Imperial units), though the console only displays to two points. The same applies to barometric pressure - recorded to three decimal points (in inches of Mercury - though in hPa, it records to two decimal places though displays to only one). Some software apps display these values to three points (WxSolution for one - see live examples on mine at http://www.wilcowx.com/current.html for both ETo and barometric pressure), while others only use two. I wouldn't mind seeing barometric pressure to three decimal places either - not because the station's accuracy necessarily keeps up with its' precision, but seeing barometric presure to three points makes it easy to see change trends, though that's less important to me than is ETo, but even without that feature, Cumulus is an extraordinary program, and I am by no means complaining!!!