Fixing bad rain rate data in V3.0.1?

[Steve2Q]

Hello. I am having some rain today for the first time after installing V3.0.1. With loop_hilo = True, there is still the HIgh Rain Rate glitch of 18 in/hr. I used to be able to clear this by stopping Weewx, deleting stats.sdb, and restarting. Now I see stat.sdb no longer is present in /archives. Short of editing weewx.sdb is there anything else I can try?

Steve

[Thomas Keffer]

Use the tool wee_config_database with option --drop-daily.

-tk

On Wed, Dec 24, 2014 at 7:17 PM, Steve2Q <ste...@gmail.com> wrote:

Hello. I am having some rain today for the first time after installing V3.0.1. With loop_hilo = True, there is still the HIgh Rain Rate glitch of 18 in/hr. I used to be able to clear this by stopping Weewx, deleting stats.sdb, and restarting. Now I see stat.sdb no longer is present in /archives. Short of editing weewx.sdb is there anything else I can try?

Steve

--
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.
For more options, visit https://groups.google.com/d/optout.

[Steve2Q]

Tom:  Thank your and Happy Holidays and Happy New Year.

Will  I have to run the wee_config_database --drop-daily command every time I see the incorrect rain rate data? If that is the case, can it be "automated" so I don't have to be home when the rain event happens?

Steve

[Andrew Milner]

Steve - I do not know what kind of station you are using, but another option is that if you are using use loop hilo data in order to keep the wind peak/gust values, you could always modify the driver to force the loop rainrate to none - so that you get the best of all worlds.  I have a modified driver for FineOffset which tries to give a more realistic rain rate based on time of last rainfall - but can still give abnormal hourly rainrate readings when there are a couple of tips within a loop period.  There is, I feel, a fundamental flaw in deriving an hourly rate from a short time period such as a loop period - and one solution is for the loop data to not contain that dubious data but use the archive period instead to derive an hourly rate - which is a longer period and will be a little closer.  Ultimately however the archive rainrate should contain the actual rainfall in the preceding hour and the loop rainrate should not be quoted in terms of per hour - but instead in terms of per loop period.  This would at least be a little more meaningful I feel but would result in different data in the stats database - and ideally would need separation of loop high rainrate from archive high rainrate - since the rates would be for differing timeperiods.

[Steve2Q]

Andrew, thanks for the information. If possible, could you send me the FineOffset modified driver? I am using an Ultimeter, but by looking at your modified one, I may be able to do the same, or something equivalent, on mine.

Thanks,  Steve

[mwall]

On Wednesday, December 24, 2014 9:17:11 PM UTC-5, Steve2Q wrote:

Hello. I am having some rain today for the first time after installing V3.0.1. With loop_hilo = True, there is still the HIgh Rain Rate glitch of 18 in/hr. I used to be able to clear this by stopping Weewx, deleting stats.sdb, and restarting. Now I see stat.sdb no longer is present in /archives. Short of editing weewx.sdb is there anything else I can try?

Steve

steve,

why is 18 in/hr a glitch?  what rain rate are you expecting?

each bucket tip of your ultimeter is 0.01".  the default loop interval for the ultimeter is 1 second.  so that gives us the following rain rate:

36 in/hr = (3600 second/hour) * (0.01 inch) / (1 second)

since you see 18 in/hr, the loop interval is probably 2 seconds.

18 in/hr is not abnormal.

if you want a different rain rate calculation, then you will have to specify it.

take a look at StdWXCalculate.  you can use the rain_period to specify a window of time over which you want the rain rate to be calculated instead of the default loop (if you are doing software record generation) or archive interval (if you are doing hardware record generation).

for example, if you never want to see a high rain rate, then do this:

[StdWXCalculate]
    rain_period = 3600

that will sum up all of the rainfall in the past hour, then report that value as the rain rate in inches (or mm) per hour.

m

[Andrew Milner]

Matthew - the loop period/interval by itself is not sufficient for calculating the rain rate - it is necessary to use the time since last tip not just the loop interval time - ie one must total or include the non tipping loop intervals to obtain a high loop value.

[mwall]

On Friday, December 26, 2014 2:09:59 PM UTC-5, Andrew Milner wrote:

Matthew - the loop period/interval by itself is not sufficient for calculating the rain rate - it is necessary to use the time since last tip not just the loop interval time - ie one must total or include the non tipping loop intervals to obtain a high loop value.

sorry, i should have been explicit in the example: if you get one bucket tip at time t=t0 then you get another tip the next interval when t=t0+1, then the rain rate is 36 in/hr.  apparently steve got 1 bucket tip in a 2 second time period, so the rain rate is 18 in/hr.

the point is, 18 in/hr is expected behavior.  if it is not *desired* behavior, then please indicate what the desired behavior is.

a second point is that rainRate is no longer calculated in the driver (unless the hardware reports a rainRate).

the StdWXCalculate service provides 3 different calculations for rain rate:

1) use the loop interval as the basis for the time period (when record_generation=software) (this is the default for an ultimeter station)
2) use the archive interval as the basis for the time period (when record_generation=hardware)
3) use an arbitrary rain_period interval as the basis for the time period (when rain_period is specified)

m

[Andrew Milner]

matthew - how is the rate calculated when the loop records are:

tip at t=t0

no tip at t=t0+1

no tip at t=t0+2

no tip at t=t0+3

no tip at t=t0+4

no tip at t=t0+5

no tip at t=t0+6

tip at t=t0+7

no tip at t=t0+8

what is given for rainrate for the loop records generated at at t, t0, t0+1, t0+2, t0+3, t0+4, t0+5, t0+6, t0+7, t0+8?

This is example 1 in your response - loop interval is the basis (but not specified).  The actual time period is however known from the timestamps at which the readings were taken.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ySKeEGcF-7Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Andrew Milner]

Matthew - taking my previous question, I would expect the answers to be:

tip at t=t0 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+1 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+2 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+3 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+4 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+5 - rainrate = 1 tip in 1 hr (or none)

no tip at t=t0+6 - rainrate = 1 tip in 1 hr (or none)

tip at t=t0+7 - rainrate = 1 tip in 7 loop periods

no tip at t=t0+8 - rainrate = 1 tip in 7 loop periods (or none)

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Steve2Q]

Matthew: The reasons I call it a "glitch" are: 1. It will jump to 18 while I am watching the rain (and the monitor) and even though the Current Conditions rain rate is reasonable (for example 0.35 or 1.50), the Since Midnight high rain rate will jump to 18.  And 2. Even during a torrential downpour where 18 may not be unreasonable, it never goes over 18.00 or shows any other number say like 17.30.

While my Ultimeter rain gauge is not the tipping bucket type, it works by measuring drops at the gauge where 1 drop = .001 inch and a pulse counter in the gauge then sends a signal to the console every 10 drops (.01 inch). So I guess the situation is analogous to a tipping bucket.

I added the line to StdWXCalculate, and will see what happens.

In the mean time, I wish there was a way to have the loop_hilo parameter true for windspeed and false for rain rate, as each seems correct for the concurrent value.

Steve

[Andrew Milner]

Mathew - for what it is worth here are the rainrates I got from FOUSB using my modification, using software generation, loop interval 54 seconds and archive interval 5 minutes:

   Dec 13 01:54:10 raspberrypi weewx[3232]: fousb: rainRate 0.000466349433904 rainTotal 7.68 raintime 1418428450
   Dec 13 02:38:51 raspberrypi weewx[3232]: fousb: rainRate 0.0402684563758 rainTotal 7.71 raintime 1418431132
   Dec 13 03:06:34 raspberrypi weewx[3232]: fousb: rainRate 0.0649819494585 rainTotal 7.74 raintime 1418432794
   Dec 13 03:07:27 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 7.77 raintime 1418432848
   Dec 13 03:26:13 raspberrypi weewx[3232]: fousb: rainRate 0.0959147424512 rainTotal 7.8 raintime 1418433974
   Dec 13 03:48:33 raspberrypi weewx[3232]: fousb: rainRate 0.0805970149254 rainTotal 7.83 raintime 1418435314
   Dec 13 04:28:46 raspberrypi weewx[3232]: fousb: rainRate 0.0447575631993 rainTotal 7.86 raintime 1418437727
   Dec 13 04:38:36 raspberrypi weewx[3232]: fousb: rainRate 0.183361629881 rainTotal 7.89 raintime 1418438316
   Dec 13 04:42:11 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 7.92 raintime 1418438531
   Dec 13 04:45:45 raspberrypi weewx[3232]: fousb: rainRate 0.504672897196 rainTotal 7.95 raintime 1418438745
   Dec 13 04:49:19 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 7.98 raintime 1418438960
   Dec 13 04:52:54 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 8.01 raintime 1418439175
   Dec 13 04:55:34 raspberrypi weewx[3232]: fousb: rainRate 0.675 rainTotal 8.04 raintime 1418439335
   Dec 13 05:08:59 raspberrypi weewx[3232]: fousb: rainRate 0.134328358209 rainTotal 8.07 raintime 1418440139
   Dec 13 05:13:27 raspberrypi weewx[3232]: fousb: rainRate 0.402985074627 rainTotal 8.1 raintime 1418440407
   Dec 13 05:17:02 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 8.13 raintime 1418440622
   Dec 13 05:22:23 raspberrypi weewx[3232]: fousb: rainRate 0.335403726708 rainTotal 8.16 raintime 1418440944
   Dec 13 05:24:10 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 8.19 raintime 1418441051
   Dec 13 05:27:45 raspberrypi weewx[3232]: fousb: rainRate 0.504672897196 rainTotal 8.22 raintime 1418441265
   Dec 13 05:31:19 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 8.25 raintime 1418441480
   Dec 13 05:33:06 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 8.28 raintime 1418441587
   Dec 13 05:37:12 raspberrypi weewx[3232]: fousb: rainRate 0.440816326531 rainTotal 8.31 raintime 1418441832
   Dec 13 05:46:08 raspberrypi weewx[3232]: fousb: rainRate 0.201117318436 rainTotal 8.34 raintime 1418442369
   Dec 13 05:59:32 raspberrypi weewx[3232]: fousb: rainRate 0.134328358209 rainTotal 8.37 raintime 1418443173
   Dec 13 06:03:07 raspberrypi weewx[3232]: fousb: rainRate 0.504672897196 rainTotal 8.4 raintime 1418443387
   Dec 13 06:07:35 raspberrypi weewx[3232]: fousb: rainRate 0.402985074627 rainTotal 8.43 raintime 1418443655
   Dec 13 06:12:03 raspberrypi weewx[3232]: fousb: rainRate 0.402985074627 rainTotal 8.46 raintime 1418443923
   Dec 13 06:20:05 raspberrypi weewx[3232]: fousb: rainRate 0.223602484472 rainTotal 8.49 raintime 1418444406
   Dec 13 06:22:46 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 8.52 raintime 1418444567
   Dec 13 06:28:08 raspberrypi weewx[3232]: fousb: rainRate 0.336448598131 rainTotal 8.55 raintime 1418444888
   Dec 13 06:30:48 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 8.58 raintime 1418445049
   Dec 13 06:34:23 raspberrypi weewx[3232]: fousb: rainRate 0.504672897196 rainTotal 8.61 raintime 1418445263
   Dec 13 06:36:10 raspberrypi weewx[3232]: fousb: rainRate 1.0 rainTotal 8.64 raintime 1418445371
   Dec 13 06:37:57 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 8.67 raintime 1418445478
   Dec 13 06:40:38 raspberrypi weewx[3232]: fousb: rainRate 0.675 rainTotal 8.7 raintime 1418445638
   Dec 13 06:42:25 raspberrypi weewx[3232]: fousb: rainRate 1.0 rainTotal 8.73 raintime 1418445746
   Dec 13 06:44:12 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 8.76 raintime 1418445853
   Dec 13 06:46:54 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 8.79 raintime 1418446014
   Dec 13 06:51:22 raspberrypi weewx[3232]: fousb: rainRate 0.402985074627 rainTotal 8.82 raintime 1418446282
   Dec 13 06:54:56 raspberrypi weewx[3232]: fousb: rainRate 0.504672897196 rainTotal 8.85 raintime 1418446496
   Dec 13 06:58:31 raspberrypi weewx[3232]: fousb: rainRate 0.502325581395 rainTotal 8.88 raintime 1418446711
   Dec 13 07:06:33 raspberrypi weewx[3232]: fousb: rainRate 0.447204968944 rainTotal 8.94 raintime 1418447194
   Dec 13 07:08:20 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 8.97 raintime 1418447301
   Dec 13 07:16:23 raspberrypi weewx[3232]: fousb: rainRate 0.223602484472 rainTotal 9.0 raintime 1418447784
   Dec 13 09:05:23 raspberrypi weewx[3232]: fousb: rainRate 0.0165137614679 rainTotal 9.03 raintime 1418454324
   Dec 13 09:48:49 raspberrypi weewx[3232]: fousb: rainRate 0.0414428242517 rainTotal 9.06 raintime 1418456930
   Dec 13 09:51:30 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 9.09 raintime 1418457091
   Dec 13 09:57:46 raspberrypi weewx[3232]: fousb: rainRate 0.288 rainTotal 9.12 raintime 1418457466
   Dec 13 10:00:26 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 9.15 raintime 1418457627
   Dec 13 10:03:07 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 9.18 raintime 1418457788
   Dec 13 10:46:00 raspberrypi weewx[3232]: fousb: rainRate 0.0419743490089 rainTotal 9.21 raintime 1418460361
   Dec 13 10:59:25 raspberrypi weewx[3232]: fousb: rainRate 0.134161490683 rainTotal 9.24 raintime 1418461166
   Dec 13 11:02:06 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 9.27 raintime 1418461327
   Dec 13 11:03:00 raspberrypi weewx[3232]: fousb: rainRate 2.03773584906 rainTotal 9.3 raintime 1418461380
   Dec 13 11:03:53 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 9.33 raintime 1418461434
   Dec 13 11:05:40 raspberrypi weewx[3232]: fousb: rainRate 2.01869158879 rainTotal 9.39 raintime 1418461541
   Dec 13 11:06:34 raspberrypi weewx[3232]: fousb: rainRate 4.0 rainTotal 9.45 raintime 1418461595
   Dec 13 11:07:28 raspberrypi weewx[3232]: fousb: rainRate 2.03773584906 rainTotal 9.48 raintime 1418461648
   Dec 13 11:09:15 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 9.51 raintime 1418461755
   Dec 13 11:11:02 raspberrypi weewx[3232]: fousb: rainRate 2.01869158879 rainTotal 9.57 raintime 1418461862
   Dec 13 11:11:56 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 9.6 raintime 1418461916
   Dec 13 11:12:49 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 9.63 raintime 1418461970
   Dec 13 11:13:43 raspberrypi weewx[3232]: fousb: rainRate 6.11320754717 rainTotal 9.72 raintime 1418462023
   Dec 13 11:14:36 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 9.75 raintime 1418462077
   Dec 13 11:15:30 raspberrypi weewx[3232]: fousb: rainRate 4.07547169811 rainTotal 9.81 raintime 1418462130
   Dec 13 11:16:24 raspberrypi weewx[3232]: fousb: rainRate 4.0 rainTotal 9.87 raintime 1418462184
   Dec 13 11:17:17 raspberrypi weewx[3232]: fousb: rainRate 4.0 rainTotal 9.93 raintime 1418462238
   Dec 13 11:19:04 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 9.96 raintime 1418462345
   Dec 13 11:19:58 raspberrypi weewx[3232]: fousb: rainRate 2.03773584906 rainTotal 9.99 raintime 1418462398
   Dec 13 11:20:51 raspberrypi weewx[3232]: fousb: rainRate 2.0 rainTotal 10.02 raintime 1418462452
   Dec 13 11:21:46 raspberrypi weewx[3232]: fousb: rainRate 6.0 rainTotal 10.11 raintime 1418462506
   Dec 13 11:23:32 raspberrypi weewx[3232]: fousb: rainRate 1.00934579439 rainTotal 10.14 raintime 1418462613
   Dec 13 11:26:14 raspberrypi weewx[3232]: fousb: rainRate 0.670807453416 rainTotal 10.17 raintime 1418462774
   Dec 13 11:51:15 raspberrypi weewx[3232]: fousb: rainRate 0.0719041278296 rainTotal 10.2 raintime 1418464276
   Dec 13 12:06:27 raspberrypi weewx[3232]: fousb: rainRate 0.11855104281 rainTotal 10.23 raintime 1418465187
   Dec 13 12:17:10 raspberrypi weewx[3232]: fousb: rainRate 0.167962674961 rainTotal 10.26 raintime 1418465830

As you see the rain rate varies tremendously even with single tips.  It is still not fantastic where there are multiple tips in consecutive loop periods - but there is nothing that can be done with the granularity of 54 seconds!!  But it gives an indication of what I keep on going on about!!

Andrew

[Andrew Milner]

And out of curiosity - I just looked at the rainrate table in the stats.  Prior to the mod the max rate always appears to be a multiple of .36, and there are always 288 readings.  Since I put null when the rate cannot be calculated you can easily see when my mod took effect, and following that the rate appears to be more variable!

[mwall]

andrew,

perhaps you could create a similar table using weewx v3 algorithms.  then you would understand how rain rate calculations work in v3.

this is how StdWXCalculate calculates rain rate:

if the hardware provides a rainRate, that is what StdWXCalculate returns.  otherwise it calculates rain rate as:

rainRate = 3600 * rain / period

if it is a loop packet, rain is the amount of rainfall during the loop period, and period is (nominally) the loop interval.

if it is an archive packet, rain is the amount of rainfall during the archive period, and period is (nominally) the archive interval.

if you specify rain_period in the StdWXCalculate section of weewx.conf, then the period used to calculate rainRate for archive packets is rain_period instead of the (nominal) archive interval.

i say 'nominally' because the period is not always precisely equal to the loop or archive interval.  look at the code to understand why.

this approach is patterned after the rest of the data collection, i.e., loop data and archive data.  it also fits the pattern for the use of loop_hilo.  it also provides the option of smoothing out rain rate by calculating over a sliding window instead of just the archive period (when you specify the rain_period), but at the cost of a database query on every archive interval.

m

[Andrew Milner]

Matthew - your description sounds exactly the same as the 2.7 algorithm, and is thus flawed in the same manner.  The time period for calculation should not be fixed by loops or archive points - but by times when buckets tip and the interval between tips.  \detecting a tip in a loop when the previous tip was 5 or 10 loop periods earlier does not mean the bucket tipped since the previous loop it means the rain fell in the time period since a tip was last detected.  Likewise, when 2 tips occur in an archive period but the previous 3 archive periods had no tips means that the time interval for calculating a rainrate is 4 archive periods and not just the archive interval. If we are going to calculate things which a station does not supply then let's at least do it in a meaningful manner! The numbers are just wrong if you try and look at arbitrary periods like an archive period or a loop period and do not take into account preceding periods where there was no reading.

What do you mean by 'create a similar table'?  The table I gave was the standard weewx rainrate table from v 2.7 as produced by 2.7 but populated by the fact that I insert None in place of rainrate in fousb as I modified fousb's rainrate calculation.  

The flaw lies in your assertion that

if it is a loop packet, rain is the amount of rainfall during the loop period, and period is (nominally) the loop interval.

when it should have said

if it is a loop packet, rain is the amount of rainfall during the period since there was last a bucket tip, and period is (nominally) one or more loop intervals.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ySKeEGcF-7Y/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[mwall]

imho, these are the things that we need to be able to report:

 - intensity of the rain, typically described as rain rate, e.g., mm/hr
 - amount of rainfall, described as rain over a period of time, e.g., mm in an hour, or mm in the past 24 hours
 - time of the last rain event
 - storm rain, i.e., amount of rainfall during the current/last storm

the ways to calculate intensity and storm rain are not obvious, nor are there necessarily only one way or even standards for the calculations.

also, not every instrument uses a tipping bucket, so 'rain event' is more appropriate than 'bucket tip' when referring to a report of rainfall measured.

wrt rainRate, there are many different ways to calculate the basis that is used to project a rate-of-change (rain rate) from an amount (rain).

here is some discussion:

http://www.localweather.net.nz/smf/hardware-software-and-technology/how-does-your-station-calculate-your-rain-rate/

http://help.wunderground.com/forums/176918-personal-weather-stations/suggestions/3472806-please-stop-hour-averaging-the-rainfall-rate

and here are the approaches used by various applications:

cumulus - per-period, where period is 5 minutes

http://wiki.sandaysoft.com/a/Rain_measurement
http://wiki.sandaysoft.com/a/FAQ#How_is_my_rain_rate_calculated.3F

weather-display - instantaneous based on time between events, with decay

davis - period based on last rain event, with a 15 minute window for decay.  max is 96 inches per hour.

http://www.davisnet.com/product_documents/weather/spec_sheets/6152_62_53_63_SS.pdf

weewx v2 - depends on the driver

weewx v3 - instantaneous or sliding window, as explained earlier in this thread

if the calculation were perfect, then the time integral of rain rate should yield the total rain for the period.

below is a portion of a spreadsheet that illustrates different methods.

the first three blocks show per-period basis with different values for the period: 1, 5, and 60 seconds.

the fourth block shows 5 different bases for the calculation: A,B,C,D, and E.
   A - rain reported in the latest period divided by the length of the latest period (5 minutes)
   B - amount of rain reported in the last event divided by the time since the last event, reported for only the latest event
   C - amount of rain reported in the last event divided by the time since the last event, with carryover
   D - amount of rain in the past 15 minutes divided by 15 minutes
   E - amount of rain in the past 30 minutes divided by 30 minutes

time	interval	rain	rainRate		time	interval	rain	rainRate		time	interval	rain	rainRate		time	interval	rain	A              B		C	D	E
	s	mm	mm/hr			s	mm	mm/hr			s	mm	mm/hr			s	mm	mm/hr	mm/hr	mm/hr	mm/hr	mm/hr
0					0					0					0
1	1	0	0		5	5	0	0		60	60	0	0		300	300	0	0.00	0.00	0.00	0.00	0.00
2	1	0	0		10	5	0	0		120	60	0	0		600	300	0	0.00	0.00	0.00	0.00	0.00
3	1	0	0		15	5	0	0		180	60	0	0		900	300	0	0.00	0.00	0.00	0.00	0.00
4	1	0	0		20	5	0	0		240	60	0	0		1200	300	0	0.00	0.00	0.00	0.00	0.00
5	1	0	0		25	5	0	0		300	60	0	0		1500	300	0	0.00	0.00	0.00	0.00	0.00
6	1	0	0		30	5	0	0		360	60	0	0		1800	300	0	0.00	0.00	0.00	0.00	0.00
7	1	0	0		35	5	0	0		420	60	0	0		2100	300	0	0.00	0.00	0.00	0.00	0.00
8	1	0.3	1080		40	5	0.3	216		480	60	0.3	18		2400	300	0.3	3.60	0.00	0.00	1.20	0.60
9	1	0.6	2160		45	5	0.6	432		540	60	0.6	36		2700	300	0.6	7.20	7.20	7.20	3.60	1.80
10	1	0	0		50	5	0	0		600	60	0	0		3000	300	0	0.00	0.00	7.20	3.60	1.80
11	1	0	0		55	5	0	0		660	60	0	0		3300	300	0	0.00	0.00	3.60	2.40	1.80
12	1	0	0		60	5	0	0		720	60	0	0		3600	300	0	0.00	0.00	2.40	0.00	1.80
13	1	0	0		65	5	0	0		780	60	0	0		3900	300	0	0.00	0.00	1.80	0.00	1.80
14	1	0	0		70	5	0	0		840	60	0	0		4200	300	0	0.00	0.00	1.44	0.00	1.20
15	1	0	0		75	5	0	0		900	60	0	0		4500	300	0	0.00	0.00	1.03	0.00	0.00
16	1	0	0		80	5	0	0		960	60	0	0		4800	300	0	0.00	0.00	1.03	0.00	0.00
17	1	0	0		85	5	0	0		1020	60	0	0		5100	300	0	0.00	0.00	0.80	0.00	0.00
18	1	0	0		90	5	0	0		1080	60	0	0		5400	300	0	0.00	0.00	0.80	0.00	0.00
19	1	0	0		95	5	0	0		1140	60	0	0		5700	300	0	0.00	0.00	0.65	0.00	0.00
20	1	0.3	1080		100	5	0.3	216		1200	60	1.5	90		6000	300	1.5	18.00	1.64	1.64	6.00	3.00
21	1	0	0		105	5	0.3	216		1260	60	0	0		6300	300	0	0.00	0.00	18.00	6.00	3.00
22	1	0	0		110	5	0.3	216		1320	60	0	0		6600	300	0	0.00	0.00	9.00	6.00	3.00
23	1	0	0		115	5	0.3	216		1380	60	0	0		6900	300	0	0.00	0.00	6.00	0.00	3.00
24	1	0	0		120	5	0.3	216		1440	60	0	0		7200	300	0	0.00	0.00	4.50	0.00	3.00
25	1	0.3	1080		125	5	0	0		1500	60	0	0		7500	300	0	0.00	0.00	3.60	0.00	3.00
26	1	0	0		130	5	0	0		1560	60	0	0		7800	300	0	0.00	0.00	3.00	0.00	0.00
27	1	0	0		135	5	0	0		1620	60	0	0		8100	300	0	0.00	0.00	2.57	0.00	0.00
28	1	0	0		140	5	0	0		1680	60	0	0		8400	300	0	0.00	0.00	2.25	0.00	0.00
29	1	0	0		145	5	0	0		1740	60	0	0		8700	300	0	0.00	0.00	2.00	0.00	0.00
30	1	0.3	1080		150	5	0	0		1800	60	0	0		9000	300	0	0.00	0.00	1.80	0.00	0.00
31	1	0	0		155	5	0	0		1860	60	0	0		9300	300	0	0.00	0.00	1.64	0.00	0.00
32	1	0	0		160	5	0	0		1920	60	0	0		9600	300	0	0.00	0.00	1.50	0.00	0.00
33	1	0	0		165	5	0	0		1980	60	0	0		9900	300	1.8	21.60	1.66	1.66	7.20	3.60
34	1	0	0		170	5	0	0		2040	60	0	0		10200	300	0	0.00	0.00	21.60	7.20	3.60
35	1	0.3	1080		175	5	0	0		2100	60	0	0		10500	300	0	0.00	0.00	10.80	7.20	3.60
36	1	0	0		180	5	0	0		2160	60	0	0		10800	300	0	0.00	0.00	7.20	0.00	3.60
37	1	0	0		185	5	0	0		2220	60	0	0		11100	300	0	0.00	0.00	5.40	0.00	3.60
38	1	0	0		190	5	0	0		2280	60	0	0		11400	300	0	0.00	0.00	4.32	0.00	3.60
39	1	0	0		195	5	0	0		2340	60	0	0		11700	300	0	0.00	0.00	3.60	0.00	0.00
40	1	0.3	1080		200	5	0	0		2400	60	0	0		12000	300	0	0.00	0.00	3.09	0.00	0.00
41	1	0	0		205	5	0	0		2460	60	0	0		12300	300	0	0.00	0.00	2.70	0.00	0.00
42	1	0	0		210	5	0	0		2520	60	0	0		12600	300	0	0.00	0.00	2.40	0.00	0.00
43	1	0	0		215	5	0	0		2580	60	0	0		12900	300	0	0.00	0.00	2.16	0.00	0.00
44	1	0	0		220	5	0	0		2640	60	0	0		13200	300	0	0.00	0.00	1.96	0.00	0.00
45	1	0	0		225	5	0	0		2700	60	0	0		13500	300	0	0.00	0.00	1.80	0.00	0.00
46	1	0	0		230	5	0	0		2760	60	0	0		13800	300	0	0.00	0.00	1.66	0.00	0.00

[Andrew Milner]

Mathew

1. Can you attach the spreadsheet file please or is it possible to use the same source data for all the examples eg the rain events at 1 second intervals are not (in the spreadsheet given) the same events that occur/reported at the 5 second interval which are not the same events that occur/reported at the 60 second interval and none are the same as occur/reported at the 300 second interval.

2. Can you clarify what is meant by carryover.

One thing that stands out is that the short intervals (1,5,60 seconds) produce 'rainrate' values that bear no relationship to any of the column A,B,C,D,E 'rainrate' values - yet within weewx the same column is used for for recording 'max' in the stats.

rainRate

[mwall]

1) you can see the effect of the interval size by comparing the second and third blocks.  the second block has 5 rain events, one in each of 5 intervals.  the third block has 5 rain events in a single 60 second period.  obviously interval size is significant - the smaller the interval, the bigger the changes in instantaneous rate.  similarly, the granularity of the sensor matters.  for a smaller period, a sensor with finer sensitivity will result in a closer approximation than a coarser one (e.g., 0.01 mm resolution vs 0.3 mm resolution).

2) with the carryover approach, the amount of rain from the last rain event is used in each period subsequent to the event.  contrast that with using the amount from the current rain event only for the current period and not for subsequent periods.

m

[Andrew Milner]

None of the first three blocks do it the Davis (and my) way - using the time from previous event (tip).  You have only shown different calculation methods for longer (archive) period of 300 seconds and not the shorter (loop) periods.  I dont think that any of ABCD and E are the Davis method either, but B is possibly close.

The Davis method says:

Rain Rate

Resolution and Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.01" or 0.1 mm (user-selectable) at typical rates (see Fig. 2 and 3)

Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0, 0.04"/hr (1 mm/hr) to 96"/hr (0 to 2438 mm/hr)

Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ±5% for rates less than 5" per hour (127 mm/hr)

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

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

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

This is pretty much what I have been arguing when I have said there is a flaw in the method by which weewx is calculating rain rates.  Weewx is using a time interval (pooling/loop period) to calculate rain rate when it should be using time since last event (tip) to calculate a rainrate for the loop records.  Notice also that Davis recognises there is a problem with having a rainrate when it is the first tip (I suggested weewx put None for rainrate when in this situation).

To be honest, having read this in the Davis specs, this is pretty much exactly what I have been saying when I say there is a flaw in the way weewx calculates rainrates.  The only differences between me and Davis are that I then went on to propose that the archive rainrate be done by averaging Loop rainrate values rather than trying to calculate a new one based on the archive period itself.

[Oz Greg]

Andrew,

This is the code for rainRate it is pretty straight forward to me..

        # Adjust the translation maps to reflect the rain bucket size:

        if self.rain_bucket_type == 1:

            _archive_map['rain'] = _archive_map['rainRate'] = _loop_map['stormRain'] = _loop_map['dayRain'] = \

                _loop_map['monthRain'] = _loop_map['yearRain'] = _bucket_1

            _loop_map['rainRate']    = _bucket_1_None

        elif self.rain_bucket_type == 2:

            _archive_map['rain'] = _archive_map['rainRate'] = _loop_map['stormRain'] = _loop_map['dayRain'] = \

                _loop_map['monthRain'] = _loop_map['yearRain'] = _bucket_2

            _loop_map['rainRate']    = _bucket_2_None

        else:

            _archive_map['rain'] = _archive_map['rainRate'] = _loop_map['stormRain'] = _loop_map['dayRain'] = \

                _loop_map['monthRain'] = _loop_map['yearRain'] = _val100

            _loop_map['rainRate']    = _big_val100

[Andrew Milner]

Greg,

Forgive my ignorance but the code segment you posted does not appear to actually do anything as far as I can tell, apart confuse me by referring to Stormrain which is a Davis entity not in the weewx schema and appears to set rainrate and rain to a common value (or type).  

I am unclear exactly what the segment does, where it is from and how it is used. It looks as though it is concerned with the transformation of Davis data to weewx schema - whilst I am concerned about the rainrates which are generated/calculated by software within weewx and do not actually come directly from a weather station.

Andrew

--

[Andrew Milner]

Matthew

The record rainfall rates recorded are:

1	min	38	Barot, Guadeloupe	26 Nov 1970
8		126	Fussen, Bavaria	25 May 1920
15		198	Plumb Point, Jamaica	12 May 1916
20		206	Curtea-de-Arges, Romania	7 Jul 1889
42		305	Holt, USA	22 Jun 1947
60		401	Shangdi, Nei Monggol, China	3 Jul 1975

giving mm/hr rates of

2280

945

792

618

435

401

so I respectfully suggest that the rates in your spreadsheet in excess of these figures have been calculated incorrectly.

a rainrate of 1080 mm/hr for a rainfall of 0.3mm is quite clearly outside the bounds of reality.

Similarly the rate of 2160, 432 and 216 are dubious.

In practice you would not get a rainfall of 0.3 in two consecutive loop records at 1 second or 5 second intervals - the events would be spaced further apart, and to obtain the correct time for calculating the rate it is essential to know the elapsed time since the previous event rather than the polling/loop interval.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[mwall]

andrew,

thank you for the data points - that is helpful for establishing sane values for StdQC.  limits defined by hardware would also be useful.  however, what are the columns in the table you posted?  and why is 1080 mm/hr outside the bounds of reality when you quote 2280 mm/hr as an actual rain rate?

the instantaneous, rain-per-period methods for calculating rain rate are not 'right' or 'wrong'.  in fact, some software does it that way.  some people *want* that calculation for their rain rate, because they have high-quality instruments with finer resolution than a fine offset 0.3 mm per event.

the davis algorithm may or may not be worth emulating.

i understand that you are proposing an algorithm based on a period between tips.  assuming that algorithm is fully defined for corner cases, that may or may not be appropriate for everyone.

i'd rather not over-engineer this, but i have not yet found an official standard for doing the calculation, and there are clearly multiple ways of doing it.

some of the variables that must be considered:
- hardware vs software record generation
- some hardware reports rainRate, some do not; some for LOOP and ARCHIVE, some only for LOOP
- how StdQC is applied
- resolution of the hardware
- interval size
- ability to report short, intense rainfall vs long, steady rainfall
- configurations with/without loop_hilo
- how it fits with existing weewx architecture

for exampe, the sliding window algorithm is a closer approximation to reality when reporting a slow, steady rain.  however, it is sensitive to the window size.  the instantaneous algorithms are closer to reality when reporting heavy downpours, but more often if you have quality instruments.

these would be useful:
- data about actual recorded rainfall
- descriptions of (or actual code for) implementations by various hardware and other software
- spreadsheet (or other) simulations/illustrations of how an algorithm behaves
- links to cogent discussions about rain rate
- links to official standards for calculating rain rate (noaa, australian met, uk met)

m

[Andrew Milner]

The table columns are:

Duration	Units	Rainfall (mm)	Location	Date

These are global records - highest recorded rain intensity globally - ever.

I converted the above to a common base of mm/hr to get the range of values I quoted.

The main problem with the current weewx calculation is very simple.  The time period which weewx is assuming the rain event covered is wrong.  The time period covering the rain event is from the last detected event.  It is a simple calculation, it requires no database lookups, it is not over-engineering, it is as simple as saying that if you say x amount of rain fell in y seconds you need to ensure that x is correct (a feature of the accuracy of the station) and that y has been measured as accurately as possible.  The current assumption is that y corresponds to a polling/loop interval (for loop data) - and this is wrong.  y should be the elapsed time since the last detected event which in all probability will be more than one loop period.  Most computers do not have time more accurate than the nearest second - so the minimum polling interval is therefore 1 second.

If weewx is going to cater for stations that are more refined than .3mm detection it may have to also consider how to record time more accurately than using standard epoch time at 1 second intervals.

You say you calculate the rain rate based on amount of rain which fell in a loop period.  I say you do not know how much rain fell in a loop period - it will be a fraction of the amount detected in most instances and not the whole amount since some of that rain will have fallen in the previous period(s).

I have already given you real live data which I had available in a tabular form from my WH2080 weather station which gave you loop and corresponding archive data calculated Davis/my fashion and weewx fashion.

If weewx were to decide not to do software rain rate or software record generation then so be it.  If it is going to do it then it should do it correctly.  Rainrates in weather stations are of course software derived anyway by the software code running in the weather station itself.

 Using time between events gives a way of measuring intensity.  Using event in a period gives a constant value ie .3 mm detected will always give the same mm/hr result regardless of how intense the rainfall is.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ySKeEGcF-7Y/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Steve2Q]

Just to add to the discussion: The Ultimeter, while it does not output the rain rate apparently does it internally, as one can set a rain rate alarm. The following is the description of how the alarm is set. I put it here as one example of how it could be calculated. It appears to use a 15 minute interval.

" This instrument provides a rain rate alarm, intended for use
where there is danger of local flooding or downstream flash
flooding. Flash flooding can result when heavy rainfall occurs
at higher elevation, and water rushes toward low-lying areas.
The rain rate alarm warns that heavy rainfall has occurred,
which could result in impending local flood conditions, or flash
flooding within your vicinity (or possibly downstream, outside
of your vicinity). Bear in mind that your success in predicting
flash flooding depends upon many factors, in addition to rain
rate: terrain, elevation, drainage, etc.
Before setting the rain rate alarm, be sure to select rainfall
units according to the type of rain gauge you are using.
The rain rate alarm is set in inches-of-rain or mm-of-rain per
hour. An alarm will sound of a specified minimum amount of
rain (called the threshold) falls at a rate equal to or greater
than the rain-rate setting. The default threshold value is 0.5
in, or 12.7 mm.
EXAMPLE: If you set an alarm for a rain rate of 2 inches per
hour, the alarm will sound if 0.5 inches of rain (the default
threshold value) falls within 15 minutes, which equals an
hourly rate of 2 inches per hour."

Steve

[Andrew Milner]

So they have a default rain rate alarm of 12.7 mm per hour - whilst we can record rainrates allegedly of 1000 mm per hour in gentle drizzle.  Sounds wrong to me.

I think that like most of these things, there's no universal standard. The UK Met Office use the following:

For Drizzle (= rain drops less than 0.5 mm diameter (!))

Slight = negligible run off from roofs
Moderate = up to 1 mm/hr
Heavy = more than 1 mm/hr

For rain other than showers:

Slight = less than 0.5 mm/hr
Moderate = 0.5 to 4 mm/hr
Heavy = more than 4 mm/hr

For showers:

Slight = 0 to 2 mm/hr
Moderate = 2 to 10 mm/hr
Heavy = 10 to 50 mm/hr
Violent = more than 50 mm/hr

 and

Intensity

	Heavy rain in Glenshaw, PA MENU 0:00 The sound of a heavy rain fall in suburban neighborhood
Problems playing this file? See media help.

Rainfall intensity is classified according to the rate of precipitation:

• Light rain — when the precipitation rate is < 2.5 mm (0.098 in) per hour
• Moderate rain — when the precipitation rate is between 2.5 mm (0.098 in) - 7.6 mm (0.30 in) or 10 mm (0.39 in) per hour^[103][104]
• Heavy rain — when the precipitation rate is > 7.6 mm (0.30 in) per hour,^[103] or between 10 mm (0.39 in) and 50 mm (2.0 in) per hour^[104]
• Violent rain — when the precipitation rate is > 50 mm (2.0 in) per hour^[104]

Both these tell me that if we record values > 50 mm/hr it had better be exceedingly violent monsoon style rain to be in any way credible - and the calculations given by matthew had many instances of rainrate > 50 mm/hr

Hence why I say the method of calculation (for loop data at least) is incorrect, and the software calculation for archive records is dubious.

.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ySKeEGcF-7Y/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[mwall]

On Wednesday, January 7, 2015 9:12:38 AM UTC-5, Andrew Milner wrote:

The main problem with the current weewx calculation is very simple.  The time period which weewx is assuming the rain event covered is wrong. 

andrew, it is not 'wrong', especially when there is no definition of 'right'.  it is an approximation.
 

The time period covering the rain event is from the last detected event.

defining the period wrt the last event is also an approximation.
 
let's say your instrument reports 10 mm of rain in a 5 minute archive interval.  is that a rain rate of 120 mm/hr? or is it 10 mm/hr?  or is it higher than 120 mm/hr?  what if the instrument has a LOOP interval of 0.5 seconds and it reported 90% of that rain in less than a minute?  what if the 10 mm of rain was evenly distributed over the 5 minute interval?

this is standard product development: enumerate the options, prototype/simulate/test the options, do an implementation, and document it.  iterate as necessary.  it sounds like you are at the 'do an implementation' phase, but i am still at 'enumerate the options'.

m

[Andrew Milner]

Matthew

I give up.  Getting an accurate time period is not possible I agree.

To totally disregard time periods which are clearly part of a timeframe is just wrong - it is not an approximation error when there has been no attempt at getting it more correct.

YOU CANNOT CALCULATE A RAIN RATE FROM A SINGLE EVENT.  FROM A SINGLE MEASUREMENT POINT THE RATE IS N/A.  YOU NEED TWO POINTS AT LEAST TO EVEN ATTEMPT TO CALCULATE A RATE.

So if the instrument records 10mm in an archive period WE KNOW NOTHING ABOUT RAIN RATE from the instrument and cannot give a rain rate.

If we know when it recorded 10 mm and we know when it recorded 11mm we can approximate the time interval during which the 1mm fell, and can approximate a rain rate.

Will you please stop thinking archive, and think loop instead - since this is the cause of the problems on FineOffset stations and any other non rainrate providing station using weewx as most of the time the rainfall is detected in non consecutive polls and it is this erroneous calculation which is populating the stats database most of the time.  

If I have one event every 2 minutes (which would be moderate rain) there will be 2 or 3 events per 5 minute archive period.  If this is steady constant rainfall weewx will calculate .6mm per 5 minutes for the archive which would be 7.2 mm per hour recorded in the database.  However, in the stats database there would be recorded a high of .3mm in 1 minute = 18mm per hour.  

The 18 bears no relationship to the 7.2 whatsoever, and therefore any person who does not know the specifics of the station would think WOW - that was heavy rain they had.  It wasn't.  If we actually let the constant rain run for the full hour we would indeed have collected only 7.2 mm - whichever way you look at it.

[mwall]

On Wednesday, January 7, 2015 10:46:41 AM UTC-5, Andrew Milner wrote:

YOU CANNOT CALCULATE A RAIN RATE FROM A SINGLE EVENT.  FROM A SINGLE MEASUREMENT POINT THE RATE IS N/A.  YOU NEED TWO POINTS AT LEAST TO EVEN ATTEMPT TO CALCULATE A RATE.

So if the instrument records 10mm in an archive period WE KNOW NOTHING ABOUT RAIN RATE from the instrument and cannot give a rain rate.

if the instrument has a tipping bucket, and each bucket tip is 0.5 mm, and the instrument reports a single bucket tip at 13:00:00, then another bucket tip at 18:00:00, and other at 22:00:00, the rain rate all day is always undefined?  zero?  undefined for the first one, but 0.08 mm/hr for the second, and 0.125 mm/hr for the third?  with zero rain rate between events?  with some kind of davis-like decay/carryover between events?  what if there is one bucket tip per day?  one every 3 days?

fwiw, the sliding window approach does provide an estimate of rain rate from a single rain event.

does one approach work better for one type of weather than another?  for one time of year versus another?  for one kind of instrument versus another?

how does noaa calculate rain rate?

how does the australian bureau of meteorology calculate rain rate?

how does the uk met office calculate rain rate?  you posted the uk met office classification of rain rates, but how do they calculate rain rate?

do you use emacs or vi, and why? ;)

m

[Andrew Milner]

Feel free to complicate it if you wish.  The more complex you try to make an algorithm the more arguments it will cause  In your example N/A would be acceptable for such sporadic rainfall.  At worst case it would be 0.5mm recorded at 1300, 1800 and 2200 with zero recorded at other times because so little rain was falling that any number becomes meaningless anyway.

The old fashioned way of measuring rain would be to measure the rainfall in a collection jar every hour and empty the jar for the next period.  There would be no attempt at intermediate readings, so historical records have no doubt been gathered in that manner..

Met office rainrate is based on observations being recorded on the hour, and cover the period HH-70 minutes to HH-10 minutes.  In other words the hourly rainfall expressed as mm per hour is the rainfall from the preceding hour to the nearest .1 mm  It is measured, not calculated.  As far as I can ascertain there is no rainrate available for intermediate periods other then the established hourly observation recording times.

https://badc.nerc.ac.uk/data/ukmo-midas/ukmo_guide.html#2.4

ie it is actual rainfall during an hour's observation period, and is neither estimated nor calculated - it is measured.  It may be recorded automatically or manually but is reported hourly.

--

[Steve2Q]

Andrew: the Ultimeter does not have a default of 2"/hour. I left off a piece of the description. The alarm rate is adjustable from 0.1 to 10.0 inch/hr in 0.1 inch/hr increments (2.5 to 254.0 mm/hr in 2.5 mm/hr increments). I may send them an email and ask what the basic algorithm is that they use to calculate the rate (of course, it may be proprietary).

Personally, I think a standard way of calculating the rate for units that do not output that data has to be decided on. As you say, the old way (and apparently still the UK method) of measuring is to chop the day into 24 hours (always starting at say 0001), measure the rainfall in that set interval and spit out a rate. Another way would be to use set 15 minute intervals (again starting at 0001) and multiply each rate x 4. Having "sliding" interval windows possibly yields better results, but it overly complicates things.

I attempted to look up the NOAA definition, and with the advent of radar, networking, and advanced measuring instruments there are now multiple and complex ways of calculating the rate. One site did point out that with "tipping buckets" there is an inherent measurement error while the buckets are changing position.

Since we are hobbyists who, for the most part do not have lab grade equipment, I really think a simple way should be agreed on, which at the same time will solve the LOOP problem. Also, one method should be settled on so every user of Weewx, whether or not their station emits rain rate (the algorithm is probably different for each manufacturer), will have consistency. The drivers for those units would ignore the rain rate from the station and use the common "Weewx solution".

Just my 2 cents (pence?)

[Andrew Milner]

Steve - I tend to agree with all that you say. If the alarm can be set to any value between 0.1 Nand 10 inch/hr (2.5 to 254 mm/hr) then that implies they would never expect to have a rate exceeding 254 mm/hr - which just about matches what you said originally - in that 2"/hr is somewhere in the bottom half of the scale and further implies that it is a reasonable value at which one should require alerting ie it is approaching heavy rain and a possible cause for concern.

The 'ideal' goal for the measurement is of course the actual amount of rain which occurred in the measured time interval.  I woud just about put money on the fact that there is no elaborate proprietory calculation going on within the weather stations - it will be the simplest calculation possible.  The simplest calculation possible.

Davis update their rain rate every 20 to 24 seconds.  They take the time between tips on the rain gauge and calculate a rain rate from that.  They regard a time interval greater than 15 minutes or a calculated rate < 1mm/hr or a single tip in 15 minutes as being a rain rate of 0.  This seems to me to be simple and reasonably accurate and all that they require to do the measurement is a timer able to measure the time between tips.  What is not clear however is when there are multiple tips in the update period do they just give the latest value, an average of the values obtained during the update period, or use the time from first to last and the number of tips.

Whichever way they do it the underlying method uses the time of a tip.  My argument with Matthew is that weewx's software calculation does not use the time (or even approximate time) of a tip as part of its calculation method and therefore cannot possibly be an approximation to a rainrate.  Weewx's version is approximately correct if, and only if, the preceding interval contained a rain event.

I agree completely it should be simple.  I believe that if the station provides a rainrate it should be used and not be amended by weewx since I believe that only those manufacturers who have the necessary timers in the station provide a rate anyway, and their value is probably the most accurate.  When weewx receives a rainrate from the station the archived record should, as for all other readings, archive the average of readings obtained during the archive period.

Therefore - for compatability purposes, and to fit in with the rest of weewx's architecture, for those stations that do not provide a rain rate weewx can calculate one for them based on information received, and inject this value into the LOOP record as though it had come from the station itself.  The key therefore is to ensure the LOOP values are as accurate/approximate as possible and must therefore use the time between tips.  If rainfall during a loop period appears to be one tip one needs to know 'the other end' of the time period to make any calculation.  If rainfall during a period is more than one tip then we know with absolute certainty that (number of tips -1) occurred within the loop time period - and could calculate a rate based on that which would be accurate to within one tip'sworth.

As a hobbyist and curious bystander edging towards 100% accuracy is not what I seek, and I suspect few others do either.  However when there is no attempt made to use a time which is even close to the real time between tips I regard that as a bug and not just an academic exercise.  Loop interval cannot, in itself, provide the basis for calculating a rate unless preceding 'non-event' intervals are taken into account.  I would not mind if it was complex to incorporate - but it isn't.  All that is necessary is to store the time of a rain event when one is seen and use that in the calculation instead of storing the time of the previous loop event and using that.  

If weewx's new sliding window allows one to specify 'since last rain event' rather than a fixed time window then that is probably also 'problem solved' when applied to Loop data.

I've done with this discussion I think, and for now will stick with what I have - my modified driver within weewx 2.7 which attempts to use time between tips to generate loop rainrate values and lets weewx archive the average of the calculated loop values during the archive period into the archived record as per other readings.

Sorry Steve - this has done my head in!!!!

Enjoy V3 - maybe one day I will also get to use it - or maybe I will take the plunge and come up with a mod to V3 to achieve the same ends - but don't hold your breath.

 

[Oz Greg]

Everyone lets take a big breath here..

Firstly I checked the vantage.py code, rainRate code is the same since 2.6 so unless we are taking about a different driver, the code is the same..

I also checked the Davis manual says that rain rate calculations are based on the interval of time between each bucket tip hardly what I would call scientific but that is the value that Davis is putting into the record and this is the value that the vantage driver is putting that value into the DB..

The variable is if you set the rain bucket size (use the rain rate for that) or else it defaults to the generic record..

./wee_config_device --info

Using configuration file /home/weewx/weewx.conf

Rain bucket type:             0.2 MM

my weewx.conf also has

[StdWXCalculate]

    rainRate = prefer_hardware

If you do not like the (Davis) rainRate subclass [StdWXCalculate] make up your own weewx has the capability to do so..

[Andrew Milner]

Greg

Not all of us are Davis users - many of us get rainrate ONLY from software generation within weewx, and do not have a hardware option.

Those of us with FineOffset etc have the software generated rainrate in Loop and archive records.

The rate in the Loop data, transferred to the stats, is the main issue.  If Loop data is not used in stats there is no rainrate issue to speak of, but then we also lose the fine granularity for max wind data and other readings.

[Oz Greg]

What is the station driver you are using I will look into the code to understand how it is calculating it..

[Andrew Milner]

fousb. Read all the threads on the subject and it will be clear to you what it is doing, and why it is not correct IMO.

Looking at the code will not enlighten you any more - as the code is exceedingly simple and not at all complicated.  It is the basis that is wrong.

[Oz Greg]

Guez after looking at the code I think you be better off throwing out the station and getting something else with some decent hardware support..

I would suggest you all set DEBUG_RAIN = 1 and post your logs

[Steve2Q]

"Throwing out the station" is not a productive answer. There are many stations that do not output rain rate; they are dependent on the software to make that calculation, and the software is not doing it correctly. This is not to disparage Tom and Matthew's fantastic job, rather an attempt to hopefully work out a solution.

Steve

[Andrew Milner]

Greg

Mathew's and Tom's sw support is fantastic.  hw support is not an issue.  Throwing out the cheaper stations without internal rainrates is not going to solve anything.  I was always told and I always told my staff that time should not be spent on problems but on solutions, and whilst changing the hw may be a solution it is not an option in this case. 

The problem is clear - how to define an amount of rainfall and the duration of the corresponding measurement timeframe in order to be able to calculate a theoretical amount of rainfall per hour. In the current implementation of fousb (and probably other station types) the timeframe used most of the time does not correspond with the measured quantity which results in an invalid calculation for the theoretical rainfall per hour.

Problem defined - now let's spend the time productively working out the solution.

Andrew

[Oz Greg]

I have given you the solution subclass [StdWXCalculate] with your own rateRate calculation. You have the power to fix this yourself..

A number of us already do exactly this.

[Andrew Milner]

If a number are already doing exactly what you suggest and others are removing rainrate from their webpages doesn't that make you think that perhaps the base underlying code should be amended?

Yes, I have the theoretical power but I do not have the practical knowledge and if I do create a new version (as I currently have based on 2.7) I render myself open to problems in future updates (a situation in which I currently find myself) and ongoing maintenance.  Implementing new base releases can cause enough issues without having to re-implement and keep track of customised amendments - just look at the forum and the issues associated with many of the add-ons and extensions which are great but come with maintenance hazards.

I gave up sw development environments 14 years ago, and gave up actual development programming 30 years ago. Enough is enough in my books - the weather is an interest and a hobby rather than a worklife extension!!

P.S.  I still don't understand classes, subclassing and what the code snippet you posted before actually did - since it appeared to do nothing and there were no comments to assist with the understanding.

[vds]

On Thursday, January 8, 2015 at 9:36:40 PM UTC-8, Andrew Milner wrote:

If a number are already doing exactly what you suggest and others are removing rainrate from their webpages doesn't that make you think that perhaps the base underlying code should be amended?

Andrew - with all due respect, I think you perhaps should take a deep breath and chill out a bit on further rain rate diatribes.  We're not trying to cure cancer here. 

This is a volunteer project, so your choices seem to be:

• live with as is
• change the code yourself to an algorithm you'll accept
• switch your hardware to one that has an existing driver that uses an algorithm you'll accept
• get somebody else to do the coding for you, to specifications of the algorithm you want
• switch your software to something other than weewx that uses an algorithm you like

So far all I'm reading is complaints, not solutions.  I'd suggest perhaps you take this one offline and find yourself a nice smart CompSci major who wants to trade a couple cases of beer for a little coding work.  Give some kid your specs.  Contribute your alternate algorithm and/or driver to the community if it reaches fruition.

[Andrew Milner]

With respect a solution was proposed and the code for my original change to fousb was posted together with loop and archive records before and after implementation, and there are several members of the forum in agreement with what I am saying.

Of your outcomes I am indeed currently living with it as is, I have changed the code (on 2.7), the sw generation calculation within weewx means that if the calculation is implemented in wxcalculate (as in V3 but not V2.7) then all stations that do not generate the rate in the hw are affected.  In 2.7 such calculations were driver dependent. There is no 'algorithm' to code - the issue is as simple as relating a quantity to a timeframe and ensuring the two go together and are not apples and pears as is currently the case.

A bug is a bug is a bug.  If you truly believe that sw which generates a theoretical rainrate of 1080 mm per hour from a single bucket tip of 0.3mm rainfall occurring in an hour is correct then you have my sympathy.

  .

[Liz]

On Thu, 8 Jan 2015 22:50:25 -0800 (PST)
vds <vince...@gmail.com> wrote:

> So far all I'm reading is complaints, not solutions.

I appreciate this, but I do see Andrew's point of view.
Right now I have what is most likely a hardware generated rain rate,
telling me that today my maximum rain rate was 195mm/hr.
That is 6 months rain, in a good year.
I'm interested in creating an alternate solution. I've paid for the
education of the CompSci PhD already, and might be able to get a return
on my investment!

Liz

[mwall]

On Friday, January 9, 2015 at 5:30:36 AM UTC-5, Liz wrote:

I appreciate this, but I do see Andrew's point of view.
Right now I have what is most likely a hardware generated rain rate,
telling me that today my maximum rain rate was 195mm/hr.
That is 6 months rain, in a good year.
I'm interested in creating an alternate solution. I've paid for the
education of the CompSci PhD already, and might be able to get a return
on my investment!

liz,

what follows is my distillation (dissertation? :) of the situation.  please give it some critical review.


executive summary:

a sliding window algorithm provides the best approximation to real rain rates, probably with a window size of 15 minutes.  this will sometimes result in low estimates for rain rate (e.g., during short, torrential rainfall), but more often result in more accurate estimates (e.g., especially for long, low-intensity rainfall).  it provides smooth changes to rainrate, whereas other methods result in spikes that are a function of the characteristics of the recording instrument.


what is the problem?

we need an algorithm that works across a range of instruments, weewx configurations, and rainfall conditions.

any rain rate estimate is going to be based on a formula that normalizes the rate to a quantity per hour:

  rainRate = 3600 * rain / period

  rain - rainfall amount in mm, inches, hogs heads, or whatever
  period - time period in seconds

the most immediate illustration of the problem is the algorithm in weewx v3 when applied to loop packets.  using the loop interval for the period tends to over-estimate the rain rate, especially for instruments with bad resolution (e.g., a bucket that can only measure down to 0.3 mm).

since the same algorithm is used for archive records, it would also be an issue if the archive interval were small.  a 5 minute interval usually results in reasonable estimates of rain rate, but a 1 minute interval would probably over-estimate (it depends on the instrument and the actual rain intensity).


what are the options?

1) sliding window

  t0 = now - period
  rainRate = 3600 * rain_total_since_t0/(now - t0)

  issues:
    - under-estimates maximum rain rate if period is large
    - under-estimates rain rate of short, intense rainfall
    - requires a db query, or caching of recent rain events


2) reporting interval

  rainRate = 3600 * rain_reported_in_loop_packet / loop_period
  rainRate = 3600 * rain_reported_in_archive_record / archive_period

  issues:
    - over-estimates in loop packets on instruments with low resolution
    - results in spikes, even during prolonged, steady rainfall
    - spikiness depends on instrument


3) time-since-last-report

  rainRate = 3600 * rain_reported_in_loop_packet / (now - last_rain_ts)
  rainRate = 3600 * rain_reported_in_archive_record / (now - last_rain_ts)

  issues:
    - under-estimates or completely misses during intermittent rainfall
    - first event reports zero rain rate
    - requires definition of what 'first event' is
    - results in spikes, even for steady rain
    - spikiness depends on instrument


4) time-since-last-report with decay

  rainRate = 3600 * rain_last / (now - t_last)

 issues:
    - first event reports zero rain rate
    - results in spikes with decay, even for steady rain
    - spikiness depends on instrument
    - lags the rain event by a full period


5) davis algorithm

  rainRate = f(rain_last, t_last, transmitter_period)



references:

davis approach

the davis approach is a variation of a time-since-last-report (type 3), with decay that is a function of the iss calculation period and transmitter period.

the davis approach does not work generically.  it might be possible to emulate it, but probably not for every type of hardware.  vantage stations do the rainrate calculation at the instrument cluster (in the iss), not the console.  the calculation depends on a 10-12 second interval (tracked in the iss) as well as the send-data-to-console interval (is that the same as LOOP?).  it uses time between bucket tips, and it uses the send-to-console interval to determine when to reset.  the problem with emulating the algorithm on other stations (and perhaps davis) is getting the actual timestamp of a tip vs the timestamp of a LOOP packet or archive packet.

http://www.davisnet.com/product_documents/weather/app_notes/AN_28-derived-weather-variables.pdf


cumulus approach

the cumulus approach is a sliding window approach (type 1), with interval of 5 minutes. when reading archive data, it uses a reporting interval approach (type 2).  (note that type 2 and type 1 are identical when the period is an archive interval)

"For stations which supply a rain rate, Cumulus uses that. For stations which don't supply a rain rate (e.g. Fine Offset and La Crosse), Cumulus simply takes the rain total from the last five minutes and calculates a rate based on that; e.g. a single tip of 0.3mm in 5 minutes is a rate of 3.6mm/hr. When data from the station's logger is used, a similar calculation is performed, but the interval used is the logger interval rather than five minutes."

http://wiki.sandaysoft.com/a/Rain_measurement
http://wiki.sandaysoft.com/a/FAQ#How_is_my_rain_rate_calculated.3F


weather display approach

weather display uses a time-since-last-event approach, with some kind of decay

according to brian (author of weather display):

"WD uses the time between bucket tips and the rate then starts dropping when the next time is longer than the time before (that data is updated every second)

so WD is providing an instantenous rain rate

the mm/hour is just that mm/min exptrapolated out to 1 hour (i.e *60)

that is different to the rain in the last immediate 1 hour period

a rain rate in WD of 2mm/minute is heavy rain

note that the Met service classivy sustain rain totals of 10mm every hour as heavy rain and enough to warrent warnings (120mm in 12 hours or so at that rate)

but you get times when the rain rate is much higher, i.e if 2mm/min was sustained then that would be 120mm in 1 hour

I have seen the instantenous rate rate (i.e time between tips) each 6mm/minute

the WD rain rate generally works very well for the Davis stations because that station udpates the bucket tip info frequently

other station types the rain gauge info is passed along at much less frequent intervals, which makes the time between tips not as usefull and in accurate"



reaction to weather underground algorithm

apparently wu changed to a rolling window of 1 hour to calculate rain rate.  user r75173 proposed an instantaneous calculation using the reporting period. the reporting period is typically 5 min or 15 min.

http://help.wunderground.com/forums/176918-personal-weather-stations/suggestions/3472806-please-stop-hour-averaging-the-rainfall-rate

[mwall]

sorry for the double post, but i forgot to make explicit the (multiple, sometimes-competing) objectives.  there are at least two ways to measure the quality of the algorithm.  not every measure will be appropriate for every use case, user, instrument, or type of rainfall.

the algorithm should provide:

1) a rain rate that approximates total rainfall.  if you integrate the rain rates over time, the total should equal the total rainfall over that time.

2) a close approximation to the maximum rain rate.  the rain rates of both short, intense cloudbursts and long, slow drizzle should be reported properly.

are there others?

imho, (1) is the more common use case, but this depends on the local climate.

m

[Steve2Q]

Matthew: an earlier post you made in this thread stated:

"this is how StdWXCalculate calculates rain rate:

if the hardware provides a rainRate, that is what StdWXCalculate returns.  otherwise it calculates rain rate as:

rainRate = 3600 * rain / period

if it is a loop packet, rain is the amount of rainfall during the loop period, and period is (nominally) the loop interval.

if it is an archive packet, rain is the amount of rainfall during the archive period, and period is (nominally) the archive interval.

if you specify rain_period in the StdWXCalculate section of weewx.conf, then the period used to calculate rainRate for archive packets is rain_period instead of the (nominal) archive interval."


If I add a line in StdWXCalculate that says rain_period = X, will X represent a constant for the rainRate = 3600 * rain / period ? So, if I let X = 900, then every 15 minutes the rain that fell in that 15 minute period will yield an "/hour rate IRREGARDLESS of loop_hilo = True ?
And if so, does the first period start on the hour, or when the first rain is measured?

Steve

[mwall]

On Friday, January 9, 2015 at 4:56:34 PM UTC-5, Steve2Q wrote:

If I add a line in StdWXCalculate that says rain_period = X, will X represent a constant for the rainRate = 3600 * rain / period ? So, if I let X = 900, then every 15 minutes the rain that fell in that 15 minute period will yield an "/hour rate IRREGARDLESS of loop_hilo = True ?
And if so, does the first period start on the hour, or when the first rain is measured?

steve,

for a 15 minute window, do this:

[StdCalculate]
    rain_period = 900

it is a sliding window, so it uses the latest 15 minutes of rainfall (any number of bucket tips or drops or whatever) to estimate the rain rate.

the calculation for loop packets will still use the loop interval as the time period.

if you do not want that behavior, try the attached wxservices-2837.py

it uses a sliding window for both loop packets and archive records.

m

[Steve2Q]

Thank you Matthew. I will try the rain_period = 900 change first, then the wxservices.py file if necessary. Now just have to wait for rain.

Steve

[Andrew Milner]

Matthew

If I understand your last post correctly would I be correct in saying that if window = 300, AND if your revised version is used, that both LOOP and archive data will be working on the same sliding window of 300?  If so then this is 'problem solved' by a workaround.  The effect of this as a workaround would be that the archive rate would be virtually unchanged from the present version, the loop data would be based on the same period and would be pretty much the same values as the archive values, and the daata recorded in the stats database would therefore be pretty much the same as turning off hi_low for rainrate.  In other words we have virtrually achieved what was being sought and have 'turned off' max values in stats being derived from individual loop records whilst retaining the capability to gather loop data for other readings from individual loop records.

If my understanding is correct then all is greatly improved if not actually solved as we have moved away from using the time period of a single loop interval for loop calculation. 

It would also be an acceptable option to just be able to turn off loop hi_lo for rainrate completely by a setting in weewx.conf.

On 10 January 2015 at 02:16, Steve2Q <ste...@gmail.com> wrote:

Thank you Matthew. I will try the rain_period = 900 change first, then the wxservices.py file if necessary. Now just have to wait for rain.

Steve

[mwall]

On Saturday, January 10, 2015 at 12:01:03 AM UTC-5, Andrew Milner wrote:

If I understand your last post correctly would I be correct in saying that if window = 300, AND if your revised version is used, that both LOOP and archive data will be working on the same sliding window of 300?

as of r2837, the rainRate for loop packets and the rain rate for archive packets is the same.  it is calculated using a sliding window with a default size of 15 minutes.  the window size can be specified using the rain_period option.  i have tested it using an acurite 5in1 weather station that has a tipping bucket with resolution of 0.01 inches.

there is no database query.

in order to satisfy both the steady-state objective (no spikes during steady rainfall) and the max rain rate objective (capture the high rates of short, intense cloudbursts), it might be more accurate to use a smaller window size for loop packets and a larger window size for archive packets.  although that implementation would not be difficult, it would introduce additional, possibly confusing, configuration options.  someone should do some analysis/simulation first to see whether it would be worth it.

critical feedback would still be appreciated before the r2837 changes make it into a release.

m

[Steve2Q]

Matthew: I would like to try the new wxservices2837.py as we are supposed to have rain in the next 24 hours.

 If I use the wxservices, should I NOT have rain_period = 900 under StdCalculate as you say the default sliding window is 15 min (900 secs)?

Steve

[Andrew Milner]

Matthew - this sounds fantastic.

I will now try and do the upgrade to 3.0.1 since I believe the other parts of the jigsaw (mesowx, nicks gauges and history) are all now available also - so I think everything is now in place to be able to give 3.0.1 a go as soon as I can get my head clear and get around to it.  Since we now have a standard approach to rainrates between archive and loop, and which does not rely only on the short loop time interval, I expect great improvements and cant wait to see the results!!! 

PS - the 0.01 inch accurite and 0.3mm fineoffset are the same size - and pretty much the 'standard' resolution for buckets I think (davis is the same too I think although they do have another option available also), so should behave much the same

Will keep you posted, and look forward to Steve's findings from the new r2837 as he should get to use it before me I think.

--

[Steve2Q]

Hi. I had rain this evening, and unfortunately the new changes did not appear to work. Here is what I did and my observations. Before it rained I deleted the line rain_period = 900 that I had placed in weewx.conf under StdWXCalculate. I then replaced wxservices with the new one. Here is what I observed:

I was out, but when I got back it had rained, and Weewx showed the following: the total rain was 0.05 inch with a High Rain Rate of 12.00 inch/hr at 04:11 PM. I stopped Weewx, rain the drop-daily routine and re-started. When Weewx was going again it now showed a High Rain Rate = 0.62 inch/hour at 04:14 PM. A rate of 12 for a total of .05 means that the .05 inch had to fall in 15 seconds, and I know that didn't happen. A rate of 0.62 for a total of .05 yields a time of 4.8 minutes which is much more realistic.

I then had another rain event, and was able to watch what happened. When the Total Rain went from 0.05 to 0.06, the rate jumped back to12 inch/hour. However the Current Conditions Rain Rate = 0.32 inch/hr, which although I did not time how long it actually took to now go from 0.05 to 0.06 total rain, this figure appeared to be a more accurate picture of what was happening.

I left and when I came back after several hours, the Total Rain was now 0.08 inch and the rate was back to 12.00 in/hour. I then ran drop-daily again, and now the rate is (again) 0.62 at 04:14 PM. Again, this is consistent with the actual times and amounts of rainfall.

I am not sure if there is any other data I can supply that may help, but I did make copies of weewx.sdb before and after the two times I ran drop-daily. This may be useful, if so, let me know.

Steve  (I am running V 3.0.1 with a RasPi.)

[mwall]

On Sunday, January 11, 2015 at 10:57:46 PM UTC-5, Steve2Q wrote:

Hi. I had rain this evening, and unfortunately the new changes did not appear to work. Here is what I did and my observations.

steve, it sounds like you are still running the wxservices.py that came with weewx v3.0.1.  did you restart weewx?

the latest wxservices.py is here:

https://svn.code.sf.net/p/weewx/code/trunk/bin/weewx/wxservices.py

m

[Steve2Q]

Matthew; I downloaded wxservices.py r 2837 as posted in this thread. I stopped Weewx, renamed the existing wxservices.py and .pyc to wxservicesold.py and pyc. I then copied the new wxservices.py into the /bin/weewx directory and restarted Weewx.

Steve

[mwall]

On Sunday, January 11, 2015 at 11:49:33 PM UTC-5, Steve2Q wrote:

Matthew; I downloaded wxservices.py r 2837 as posted in this thread. I stopped Weewx, renamed the existing wxservices.py and .pyc to wxservicesold.py and pyc. I then copied the new wxservices.py into the /bin/weewx directory and restarted Weewx.

Steve

steve,

run weewx directly so you can see the loop packets.  tip the bucket.  what happens?

m

[Steve2Q]

Matthew: My Ultimeter does not use a mechanical tipping bucket. Mine essentially counts the drops that fall between 4 sensor needles, and then every time enough drops have flowed thru, a circuit within the rain gauge tells the console to increment .0.01 inch. Therefore I can't "tip the bucket"; I will have to wait for more rain (the gauge is not easily accessible).

I will let you know later today, as more rain is supposed to be on its way.

Steve

 

[Steve2Q]

Matthew: I think it is working! When I was doing my initial tests yesterday, I would shut Weewx down with the "stop" command, make the changes and then start back up with "start". The last time I made a change, I used the "restart" command. I don't know if this is what did it or not, but early this AM there was rain, and this is what Weewx  says:  Today's rain = 0.07 inches  High Rain Rate = 0.28 in/hour at 3:06 AM. So looks good!

I will keep you updated, and hopefully others with Ultimeters or other consoles that don't output rain rate will give this a try.

Thank you!

Steve

[Andrew Milner]

Steve

Out of curiosity over what time period did the .07 actually fall, and what are the rainfall and rainrates from the archive records during the period of rainfall?  Knowing this would help correlate what has been stored/archived against what actually occurred.

Andrew

[Steve2Q]

   Andrew: Here are the times, Rain Rate, and Rain snipped from weewx.sdb. The times range from 2:56 AM to 3:20 AM in 2 minute increments (my archive period). I cannot interpret this as to why the rate went to .28 for 3 periods when the rain was 0, but maybe this is due to the "sliding window?"

Anyway, hope it is useful.

Steve

All 0 before this time
1421135760    0.0350574712643679    0.03
1421135880    0.145821325648414    0.01
1421136000    0.204827586206897    0.02
1421136120    0.24    0.0
1421136240    0.245533141210375    0.01
1421136360    0.280000000000001    0.0
1421136480    0.280000000000001    0.0
1421136600    0.280000000000001    0.0
1421136720    0.178904899135445    0.0
1421136840    0.105977011494253    0.0
1421136960    0.0489655172413788    0.0
1421137080    0.0399999999999997    0.0
1421137200    0.014367816091954    0.0
All 0 after this time