I am surprised ya bearings have lasted so long and ya reed switches for that matter 

I was speaking only of the ISS. The anny has been replaced, but not due to mechanical failure, but due to a large flying object hitting and destroying it. It was about 6.

Ive had my OS 968 since 2007, its had new anny's and outside temp still the same structure, my would deffo be up for debate
as to whether its still the same, console is mind

I am surprised ya bearings have lasted so long and ya reed switches for that matter 

It looks like WU have come to realise that the star means  a lot to many of its members and when some lost it for 5 days they
were complaining about that length of time so they shortened it or back to my original assessment, that if you start up your data
sending just at the right time that their servers are doing the check it will be less that the specified 5 days, just assumptions, no
one will ever know........... lol

Today I had an issue where my ObserverIP (attached to WS-1400-IP) lost its annual rain total from some 22" to 0. No problem I thought, I just edit it and set it back, and so I did. I did not think about it enough, apparently, because over the next hour I observed on my station's wunderground page that it registered a rain rate (which is really total rain in last 60 minutes), of 22", which staid for 60 minutes and then went back to 0.

This leads me to the conclusion that when MeteoBridge polls the ObserverIP it reads the annual total field and uses changes in the field to compute rain between two observations and then [rain0total-sum60] which I use (I am not using the standard WU support, but use my own template for reasons I'll leave out here) produces the observed behavior.

If we look at the ObserverIP when making such a change I see that the other rain fields remain at 0 (because it is not actually raining).

This is an interesting problem because editing a historical value on the ObserverIP causes that MeteoBridge to think rain actually fell.

If I am right, the question becomes: "What can be done to prevent this"? At the very least MB could add some sanity checking. I've seen it report that pressure readings appear out of range (in the log) and then ignoring them. In this case the rain0total sampled from one readout to the next changed by over 20". That cannot be right under any realistic circumstance.Observations are about 4 times a minute. In the most extreme circumstances rain rate will not exceed 20" per hour, or 20/(60x4) = 0.083" / observation. So perhaps MB could detect values over 0.01 or even 0.025 per observation interval and flag (and ignore them), but keeping the latest value for reference. In this example it would see the transition from 0 to 22 once (and reject it), keep 20 as the reference, and going forward would only see 0.

Of course this would not work if the edit in question was very small, but it would have to be smaller than the 0.01 or 0.025 suggested about. I doubt any real scenario would exist where a user would want to make that small an adjustment. However, there would be a workaround: Add 10.01 wait 30 seconds, and then subtract 10. MB would then ignore, but ObserverIP would effectively by incremented by 0.01.

Another option would be to get the ObserverIP firmware changed to have a field for reporting the amount of rain between two observations and have MB read that instead. The problem here is that the limits of the actual device would be reached. The tipping bucket on most stations has a size around 0.01" and thus for moderate rain rates the change between two observations would be 0 mostly.

Another alternative is to read the "Hourly rain rate" and numerically integrate that over the desired interval (template modifier can be any interval 0-60 seconds). That may not be very precise either though.

Other ideas?

Perhaps the sanity check idea is the best of all options in that it should be simple to implement, and is completely backwards compatible (but I would have to renew my MB license for it

Quote from: Old Tele man on Yesterday at 08:11:47 PM

Quote from: waiukuweather on Yesterday at 04:04:55 PM

my question is, will they have UV stabilised plastics and longer life stainless steel and bearings?

One-word translation: Reliability!


...or l-o-n-g MTBF.

Well, if they intend to charge Davis-like prices, they better have Davis-like quality.  That said, my 5-1 is going on three years now and neither rain, nor sleet nor hail or screaming hot has affected its lower class plastics.  How much longer, I dunno.  But for under a hundred bucks I can happily replace it all.

We certainly live in a disposable society now, my PWS isn't one of them. Spending money every other year to replace something that I expect to last much longer than that is a simple waste of time and money. Even if my VP2 was falling apart at the seams now (not even close after 10+ years in the Az. sun), I'd still pick up an another VP2 before the Atlas. The VP2 continues to prove itself to me and will take more than new AcuRite to change my mind, sensors included. Just my 2 cents...