Cumulus Support

steve wrote:

glen.day wrote:1. Unit doesn't display the current rain rate, I miss this feature which I recall being on my WH1081

I don't think any Fine Offset stations display rain rate? I know they definitely don't make it available to software, but I didn't think they even displayed it. Mine doesn't seem to.

From the WH1081 display you can set rain for last 1hr, 24 hrs, week or month.

My apologies not sure what I was thinking - I pulled out my WH1081 and yes that is correct the older unit doesn't display the current rainfall rate.

Disregard my comment about the rain rate.

Steve

Could I put forward a suggestion?

Would it be possible for you to set up an area of the Forum where members could write reviews of the units they've owned or used (only the ones that run Cumulus of course ) Maybe break it down into Manufacturer, Model etc.

I found Glen's comments on the new Fine-Offset unit very helpful. (Thanks again Glen )

All the best

Ian

No worries Ian - sounds like someone is going to purchase a WH3081 .

I ordered mine from eBay last night.


EDIT: Decided to purchase a VP2 instead.

Potential WH3080/3081 buyers and new users, please read my below post for a possible wide spread issue with these units.

https://cumulus.hosiene.co.uk/viewtopic.php?f=13&t=4100

steve wrote:"Pro" eh? Time to think about adding that to Cumulus, perhaps...

Thanks, but it wouldn't really be any use. I'll need a few memory dumps taken at the same time as noting the current UV and solar radiation readings. I'll have to write a 'dumper' - although I guess someone else has already done that; Jim Easterbrook, perhaps.

I'm a late arrival at this thread. A couple of pywws users have recently asked me to add support for the 3080 class weather stations. What I know so far is
1/ the 256 byte 'fixed block' appears to be the same, but a few of the previously vacant memory addresses now appear to be occupied.
2/ each logged data record is 20 bytes long - the additional 4 bytes are 3 for illuminance, 1 for UV index (one of my users tells me)
3/ the logged data starts at location 256
4/ it is possible to have logged data at locations that are not (256 + (n * 20))
This last item is a surprise to me. I'm hoping that careful logging of the data pointer will reveal what's going on.

jim-easterbrook wrote:4/ it is possible to have logged data at locations that are not (256 + (n * 20))
This last item is a surprise to me. I'm hoping that careful logging of the data pointer will reveal what's going on.

That comes as a surprise to me too! I haven't seen that in any of the data I've looked at. It would throw my logger download code out, as that works backwards from the latest entry, and to do that you have to assume the previous entry is 20 bytes away. How do you follow the chain of logger entries if they're not all 20 bytes apart?

A consequence of the increase in entry size means that these stations would to appear to hold only 3264 entries rather than 4080.

By the way, apologies for not passing on what I'd learned (the same as you, apart from point 4). I thought that I had posted the information in the forum, but clearly I didn't

steve wrote:How do you follow the chain of logger entries if they're not all 20 bytes apart?

That's what I hope to find out.

A consequence of the increase in entry size means that these stations would to appear to hold only 3264 entries rather than 4080.

Although the Fine Offset website http://www.foshk.com/Weather_Professional/WH3080.htm still says 4080.

By the way, apologies for not passing on what I'd learned (the same as you, apart from point 4). I thought that I had posted the information in the forum, but clearly I didn't

No problem. I'd probably have missed it anyway. I've only just got interested in the 3080s.

jim-easterbrook wrote:

steve wrote:How do you follow the chain of logger entries if they're not all 20 bytes apart?

That's what I hope to find out.

I've assumed they're 20 bytes apart and so far have no complaints of garbage data.

steve wrote:I've assumed they're 20 bytes apart and so far have no complaints of garbage data.

Yes, it may just be that my one user who has reported the strange current position pointer has a defective station. Somehow his pointer value has slipped by eight bytes from what I'd expect. I hope to get a full data dump from him soon.

I've updated my description of the memory layout with what I know so far about the 3080 family of stations: http://www.jim-easterbrook.me.uk/weather/mm/

jim-easterbrook wrote:

steve wrote:I've assumed they're 20 bytes apart and so far have no complaints of garbage data.

Yes, it may just be that my one user who has reported the strange current position pointer has a defective station. Somehow his pointer value has slipped by eight bytes from what I'd expect. I hope to get a full data dump from him soon.

I have noticed, that I get nasty readings for Solar and UV, caused when there is no sensor contact

Snupple wrote:I have noticed, that I get nasty readings for Solar and UV, caused when there is no sensor contact

Which build? I put checks in for bad data, the 'sensor contact' flag doesn't seem to apply to solar data.

steve wrote:

Snupple wrote:I have noticed, that I get nasty readings for Solar and UV, caused when there is no sensor contact

Which build? I put checks in for bad data, the 'sensor contact' flag doesn't seem to apply to solar data.

Build 977