odd high rainRates for reasonable rain in intervals

[vince]

Tom - how could weewx generate bizarre rainRate values in an archive record when the amount of rain in an interval period looks reasonable ?    The station is a VP2.

Here's one example related to that other long thread 'Correct Old and New Rain Records'.

sqlite3 query was:

echo "SELECT interval,datetime(dateTime,'unixepoch','localtime'), dateTime, rain, rainRate FROM archive where dateTime<1570838400 and dateTime>=1570752000 ORDER BY rainRate DESC LIMIT 10;" | sqlite3 ~/weewx-data/archive/weewx.sdb

Just the interesting archive records....

5|2019-10-11 21:45:00|1570830300|0.0|0.0
5|2019-10-11 21:50:00|1570830600|0.0|0.0
5|2019-10-11 21:55:00|1570830900|0.13|82.29   <==
5|2019-10-11 22:00:00|1570831200|0.09|64.0    <==
5|2019-10-11 22:05:00|1570831500|0.0|0.07
5|2019-10-11 22:10:00|1570831800|0.0|0.04
5|2019-10-11 22:15:00|1570832100|0.0|0.0
5|2019-10-11 22:20:00|1570832400|0.0|0.0

Total for that day was 0.23" so basically all was in that 10 minute period

Other than a possibly broken/chattering tipper sensor, can you think of anything ?

[Tom Keffer]

The VP2 has hardware generation. So, unless the user changes something, the database will record whatever comes off the console. As for how Davis calculates rain rate, here's what they have to say in their "Derived Variables" document.

RAINFALL RATE

Parameters Used: Rain Total (actually, rain rate is a measured variable in the sense that it is

measured by the ISS and transmitted to the display console, whereas all other calculated

variables are determined by the console from data received from the ISS.)

Formula:

Under normal conditions, rain rate data is sent with a nominal interval of 10 to 12 seconds.

Every time a rain tip or click occurs, a new rain rate value is computed (from the timer values)

and the rate timers are reset to zero.

Rain rate is calculated based on the time between successive tips of the rain collector. The rain

rate value is the highest rate since the last transmitted rain rate data packet. (Under most

conditions, however, a rain tip will not occur every 10 to 12 seconds.)

If there have been no rain tips since the last rain rate data transmission, then the rain rate based

on the time since that last tip is indicated. This results in slowly decaying rate values as a rain

storm ends, instead of showing a rain rate which abruptly drops to zero. This results in a more

realistic representation of the actual rain event.

If this time exceeds roughly 15 minutes, than the rain rate value is reset to zero. This period of

time was chosen because 15 minutes is defined by the U.S. National Weather Service as

intervening time upon which one rain "event" is considered separate from another rain "event".

This is also the shortest period of time that the Umbrella will be seen on the display console

after the onset of rain.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e4e40f72-528a-4962-85f9-206b4d6f1212n%40googlegroups.com.

[vince]

Thanks. I can only think of a loosely attached or vibrating tipper bouncing on and off the post it tips onto, perhaps in gusty wind or whatever it’s attached to shaking.  I see a lot of 82.29 in/hr rates which seems to be some Davis max they can come up with.

0.13” in 5 minutes is 1.56 in/hr if it was steady tipping rate, not 82.29 in/hr reported

0.09 in 5 minutes is 1.08 in/hr at steady tipping,  ot the 64.00 reported

Really odd. Would it be wise to define some StdQC item for this station ?

[S Phillips]

If the rain collector has debris in it and fills with water, could a constant trickle via seepage around the debris cause this? 

Likewise, if the collector is clear and then is filled full from a pitcher, could that cause the extreme in/hr rate?

[vince]

No - it only tipped 13 times in 5 minutes in the first example.  Also no on the pitcher question - it would tip once and stay in that position until all the water from the cone was gone enough for it to un-tip, so to speak.  (I've done the latter personally when cleaning mine)

I can't come up with math that results in 82.29 in/hour (that's over 2 tips/second).  I checked your db and it wasn't particularly windy that day either.  I can only wildly guess something electrical was going on, maybe a loose plug where the RJ11 plugs into the ISS board, I dunno.

[Greg Troxel]

vince <vince...@gmail.com> writes:

> I can't come up with math that results in 82.29 in/hour (that's over 2
> tips/second). I checked your db and it wasn't particularly windy that day
> either. I can only wildly guess something electrical was going on, maybe a
> loose plug where the RJ11 plugs into the ISS board, I dunno.

I have seen rates that are crazy high, maybe even that high. The
problem was indeed electrical connection, or so I concluded. I removed
the rain-ISS cable (pulled out the RJ11) and wiped down and cleaned and
reinserted/removed it a bunch and then things were ok.

You can get very high rates briefly when the ice melts, but then you
have a total that is not crazy, just a high rate briefly.

[vince]

Quick math says 82.29 in/hour is 27.43 tips/SECOND over a 5 minute archive period, so that's kinda crazy impossible.

Davis VP2 spec sheet says the max range for rate is 30 in/hour so I can't explain why his db shows many archive periods well over that number.   Looking at the archive data for 15 minutes on either side of the maxTime shown in the summary table I'm finding them impossible to believe.

Rainfall

Resolution and Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.01" or 0.2 mm (user-selectable) (1 mm at totals  2000 mm)

Daily/Storm Rainfall Range . . . . . . . . . . . . . . . . . . . . . . . 0 to 99.99" (0 to 999.8 mm)

Monthly/Yearly/Total Rainfall Range . . . . . . . . . . . . . . . . 0 to 199.99" (0 to 6553 mm)

Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . For rain rates up to 10"/hr (250 mm/hr): ±3% of total or ± one tip of the

spoon (0.01"/0.2mm), whichever is greater.

Update Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 to 24 seconds

Storm Determination Method . . . . . . . . . . . . . . . . . . . . . 0.02" (0.4 mm) begins a storm event, 24 hours without further accumulation ends

a storm event

Current Display Data . . . . . . . . . . . . . . . . . . . . . . . . . . . Totals for Past 15-min

Current Graph Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . Totals for Past 15-min, Past 24-hour, Daily, Monthly, Yearly (start date user-

selectable) and Storm (with begin date); Umbrella is displayed when 15-minute

total exceeds zero

Historical Graph Data . . . . . . . . . . . . . . . . . . . . . . . . . . . Totals for 15-min, Daily, Monthly, Yearly (start date user-selectable) and Storm

(with begin and end dates)

Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High Threshold from Latest Flash Flood (15-min. total, default is 0.50", 12.7 mm),

24-Hour Total, Storm Total,

Range for Rain Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . 0 to 99.99" (0 to 999.7 m

Rain Rate

Resolution and Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.01" or 0.1 mm (user-selectable) (See Figure 1 on page 9)

Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0, 0.04"/hr (1 mm/hr) to 30"/hr (0 to 762 mm/hr)

Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ±5% for rain rates up to 10"/hr (250 mm/hr)

Update Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 to 24 seconds

Calculation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Measures time between successive tips of tipping spoon. Elapsed time greater

than 15 minutes or only one tip of the rain collector constitutes a rain rate of zero.

Current Display Data . . . . . . . . . . . . . . . . . . . . . . . . . . . Instant

Current Graph Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instant and 1-min. Reading; Hourly, Daily, Monthly and Yearly High

Historical Graph Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-min Reading; Hourly, Daily, Monthly and Yearly Highs

Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High Threshold from Instant Reading

echo "select datetime(dateTime,'unixepoch','localtime'),rainRate from archive where rainRate>10 order by rainRate limit 300 ;" | sqlite3 weewx.sdb

2022-02-22 12:35:00|11.29
2020-07-11 19:45:00|14.77
2021-08-30 22:20:00|15.57
2020-02-17 22:35:00|26.18
2023-08-10 12:10:00|57.6
2019-10-11 22:00:00|64.0
2019-10-11 21:55:00|82.29
2020-05-17 17:05:00|82.29
2021-06-25 02:25:00|82.29
2022-07-08 13:05:00|82.29
2023-08-10 12:05:00|82.29

Here's a couple rain+rainRate instances

2022-02-22 12:25:00|0.0|0.0
2022-02-22 12:30:00|0.0|0.0
2022-02-22 12:35:00|0.03|11.29    <== looks bogus
2022-02-22 12:40:00|0.0|0.09
2022-02-22 12:45:00|0.0|0.05

2020-05-03 02:20:00|0.0|0.05
2020-05-03 02:25:00|0.06|2.35
2020-05-03 02:30:00|0.46|9.44     <== dunno, at least there's a ramp up/down
2020-05-03 02:35:00|0.09|7.02
2020-05-03 02:40:00|0.0|0.1

[Greg Troxel]

vince <vince...@gmail.com> writes:

> Quick math says 82.29 in/hour is 27.43 tips/SECOND over a 5 minute archive
> period, so that's kinda crazy impossible.

2.29? But it does seem physically impossible. The highest I've seen is
I think 7 or 8" per hour, or maybe only 6".

> Davis VP2 spec sheet says the max range for rate is 30 in/hour so I can't
> explain why his db shows many archive periods well over that number.

There's the highest actual rate that will measured correctly, and then
there's the rate that the instrument is guaranteed not to report. I'd
expect 30 in/hour to be the highest real rate that will result in valid
data. I find that rate to be comfortably 4x the highest rain rate I've
ever experienced, and it seems a good design point.

> Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . . . 0, 0.04"/hr (1 mm/hr) to 30"/hr (0 to 762 mm/hr)

That's almost a tip per second. No reason the computer couldn't count
it. Starts to be physically hard with water draining and inertia.

> echo "select datetime(dateTime,'unixepoch','localtime'),rainRate from
> archive where rainRate>10 order by rainRate limit 300 ;" | sqlite3 weewx.sdb
>
> 2022-02-22 12:35:00|11.29
> 2020-07-11 19:45:00|14.77
> 2021-08-30 22:20:00|15.57
> 2020-02-17 22:35:00|26.18
> 2023-08-10 12:10:00|57.6
> 2019-10-11 22:00:00|64.0
> 2019-10-11 21:55:00|82.29
> 2020-05-17 17:05:00|82.29
> 2021-06-25 02:25:00|82.29
> 2022-07-08 13:05:00|82.29
> 2023-08-10 12:05:00|82.29

Multiple 82.29 indicates some runaway process maxing out some limit. I
think this is electrical bad connection.

> Here's a couple rain+rainRate instances
>
> 2022-02-22 12:25:00|0.0|0.0
> 2022-02-22 12:30:00|0.0|0.0
> 2022-02-22 12:35:00|0.03|11.29 <== looks bogus
> 2022-02-22 12:40:00|0.0|0.09
> 2022-02-22 12:45:00|0.0|0.05
>
> 2020-05-03 02:20:00|0.0|0.05
> 2020-05-03 02:25:00|0.06|2.35
> 2020-05-03 02:30:00|0.46|9.44 <== dunno, at least there's a ramp up/down
> 2020-05-03 02:35:00|0.09|7.02
> 2020-05-03 02:40:00|0.0|0.1

Bogus and very suspicious indeed.