Topic: Atlas Has Arrived

[miraculon]

Miraculon, did another test today where I left the solar panels covered all day and registered 0 strikes until a thunderstorm came through tonight and it picked up legitimate strikes. Still only a little over 2 days of testing but I feel pretty confident the solar/fan system is the culprit.

Thanks for the update. It seems that the evidence is growing to support this theory.

I also wonder if there is a variability in the motor brushes. Has anyone experienced the false strikes during sunny (fan running) conditions that seems to settle down after time? I wonder if the brushes 'break in' and the noise reduces. Or, it could conceivably get worse. Don't know.

If it turns out to be the brush noise, there are ways to filter and reduce it. Also, Acu-Rite could take known noisy fans and tweak the AS3935 parameters to account for the worst case. This might be (probably would be) a trade-off in the actual detection of lightning.

It will be interesting to see how this all sorts out.

Greg H.

[Tylerpod]

What's with the atlas rain rate compared to the 5 in 1. In very heavy rainfall my 5 in 1 will say 2 inches an hour while my atlas will say something like .10

[galfert]

What's with the atlas rain rate compared to the 5 in 1. In very heavy rainfall my 5 in 1 will say 2 inches an hour while my atlas will say something like .10

There are two ways to report rain rate and they represent slightly different things. So just different ways to report the event.  One way is the rain rate at that moment as in if it had continued to rain at that rate for a whole hour straight how much rain would have totaled. The other way is called accumulated rain rate which shows how much has really accumulated that hour.

I prefer the first way which shows how fast it was raining at the moment. The other way is just a summary of what really happened. But since you always also have the total for the day and you can see the total increasing it is a bit redundant to report the actual accumulated rate for a given hour.

Here you can see the very same rain even captured by the same rain gauge but reported to WU with two different software to different station IDs for comparison.

 [ You are not allowed to view attachments ]
This is my preferred method that shows rain speed and shows passing showers and how fast it dumped. Using this method you can see that the rain this day came in 3 large waves and you can compare the rate of each wave. Using the other method you really can't make this determination.

 [ You are not allowed to view attachments ]
This method is just real accumulated rate for the past hour. Less informative I think and redundant because this information can be gotten by comparing previous accumulated amount (blue line) to whatever it climbs to (new blue line height). That is why on the first rain event of the day the blue line and the green line match up perfectly. ...It is the same information.

Unfortunately it seems like the Atlas Access uses the second method. I don't think there is a way for you to change that. Some software offer a choice in rain rate type.

[nincehelser]

What's with the atlas rain rate compared to the 5 in 1. In very heavy rainfall my 5 in 1 will say 2 inches an hour while my atlas will say something like .10

Rain rate isn't measured by the Atlas or 5n1 sensor.  It's calculated by the displays or whatever website is receiving the rain data.

A big problem is that different sites calculate it differently.  In the past, wunderground has seemed to vary randomly in how they calculate and graph rain rate, but since they've re-coded this year, things have gotten better.  However, there are currently some issues with what wunderground host name your Acurite gear sends data to.  Wunderground put in a temporary fix, but wunderground and Acurite still have some issues to work out.

I'm not aware of the Atlas display calculating rain-rate differently than the 5n1 displays, but I suppose it's possible.

[galfert]

Rain rate method has to do with the software uploading (or the device uploading like the Access), and does not have to do with the website receiving the data. At least that is the case for Weather Underground. As I've demonstrated, I can use Weather Underground and report rain rate with whatever method I want.

In the Meteobridge it is just a check mark to choose the method you prefer.
 [ You are not allowed to view attachments ]

With other software/hardware you may be limited to one method or the other.

Weather Underground does nothing with the rain rate data received other than plot it on a graph. They plot the exact number that they received. That is all they do. If you aren't happy with the rain rate method calculation then change the hardware/software that you use to upload to Weather Underground with.

[nincehelser]

Rain rate method has to do with the software not the website receiving the data. At least that is the case for Weather Underground. As I've demonstrated, I can use Weather Underground and report rain rain with whatever method I want.

In the Meteobridge it is just a check mark to choose the method you prefer.
 [ You are not allowed to view attachments ]

Wunderground takes two parameters.  "rainin" and "dailyrain". 

"rainin" is supposed to be the rainfall in the last 60 minutes.  Some programmers have misinterpreted that to be a fixed hour or some other time period they have chosen.

Weather Underground does nothing with the rain rate data received other than plot it on a graph. They plot the exact number that they received. That is all they do. If you aren't happy with the rain rate method then change the hardware/software that you use to upload to Weather Underground with.

Not true.  There is no "rain rate" parameter to send.

[galfert]

In Weather Underground:
rainin = green line
dailyrain = blue line

I disagree as to what it is "supposed to be." I feel rainin should be the rain rate at that moment in time...not how much rain occurred in the past hour. This is analogous to your speedometer. You want to know how fast you are traveling at the moment in time. It doesn't matter how far I drive (that is what the odometer is for). What I want to know is how fast I'm driving. Likewise I want to know how fast it is raining. It gives you an idea for at that moment if it was a flash flood or if it was more gradual. If you report the total for the past hour well that is just redundant because you can extract that information from the blue line.

But I suppose the option is there for you to have it your way.  You just need to use the right hardware/software combination to get the results you want to see. The same goes for me. So lets agree to disagree.

[nincehelser]

In Weather Underground:
rainin = green line
dailyrain = blue line

I disagree as to what it is "supposed to be." I feel rainin should be the rain rate at that moment in time...not how much rain occurred in the past hour. This is analogous to your speedometer. You want to know how fast you are traveling at the moment in time. It doesn't matter how far I drive (that is what the odometer is for). What I want to know is how fast I'm driving. Likewise I want to know how fast it is raining. It gives you an idea for at that moment if it was a flash flood or if it was more gradual. If you report the total for the past hour well that is just redundant because you can extract that information from the blue line.

But I suppose the option is there for you to have it your way.  You just need to use the right hardware/software combination to get the results you want to see. The same goes for me. So lets agree to disagree.

I'll stick with the protocol. 

https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298

[galfert]

In Weather Underground:
rainin = green line
dailyrain = blue line

I disagree as to what it is "supposed to be." I feel rainin should be the rain rate at that moment in time...not how much rain occurred in the past hour. This is analogous to your speedometer. You want to know how fast you are traveling at the moment in time. It doesn't matter how far I drive (that is what the odometer is for). What I want to know is how fast I'm driving. Likewise I want to know how fast it is raining. It gives you an idea for at that moment if it was a flash flood or if it was more gradual. If you report the total for the past hour well that is just redundant because you can extract that information from the blue line.

But I suppose the option is there for you to have it your way.  You just need to use the right hardware/software combination to get the results you want to see. The same goes for me. So lets agree to disagree.

I'll stick with the protocol. 

https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298

Okay. You are right. But doesn't mean the definition can't be changed or updated to reflect the possibility to accept either method. This is already happening anyway by practice for it to be either way. Every Ambient Weather device has always only done it with the method I prefer. And Davis Weatherlink also does it the way I prefer.

[nincehelser]

Okay. You are right. But doesn't mean the definition can't be changed or updated to reflect the possibility to accept either method. This is already happening anyway by practice for it to be either way. Every Ambient Weather device has always only done it with the method I prefer. And Davis Weatherlink also does it the way I prefer.

Do you have details on this "method" you are espousing?

Is everyone tweaking "rainin" on wunderground the same way?

It's bad enough "gusts" aren't reported in a standard way...

[galfert]

I don't think I have any more details that what I've already shared. If you pull up any Ambient Weather or Davis (on Weatherlink) station on WU you'll notice that the rain graphs look like my example. It is easy to spot. Just look at where the first rainfall started that day and you'll notice the blue line gradually ramps up while the green like is quick spike with larger slope than the blue line. You can easily tell which stations are using one method or the other.

You ask if everyone is doing it the "same way." Well that is a good question. But I don't think it is so black and white. It would seem to me that since different stations report at different intervals (16 seconds, or 30 seconds, or every minute...etc). Then the rain rate calculation in my preferred method could be different just because of the data available. So is it considered different because the sampling rate is different or is it still the same because given the available data points rain rate per hour would be the same calculation. I think the end result is the same. I'm sure one car manufacture can sample wheel speed a different number of times versus a different manufacture...but in the end speed = speed. The calculation is the same...just the sampling rate is different. You can be more precise if you have more samples per time lapse.
 

[nincehelser]

I don't think I have any more details that what I've already shared. If you pull up any Ambient Weather or Davis (on Weatherlink) station on WU you'll notice that the rain graphs look like my example. It is easy to spot. Just look at where the first rainfall started that day and you'll notice the blue line gradually ramps up while the green like is quick spike with larger slope than the blue line. You can easily tell which stations are using one method or the other.

You ask if everyone is doing it the "same way." Well that is a good question. But I don't think it is so black and white. It would seem to me that since different stations report at different intervals (16 seconds, or 30 seconds, or every minute...etc). Then the rain rate calculation in my preferred method could be different just because of the data available. So is it considered different because the sampling rate is different or is it still the same because given the available data points rain rate per hour would be the same calculation. I think the end result is the same. I'm sure one car manufacture can sample wheel speed a different number of times versus a different manufacture...but in the end speed = speed. The calculation is the same...just the sampling rate is different. You can be more precise if you have more samples per time lapse.

And that's the reason wunderground does the rain rate calculation themselves.  It may not be the result you want, but at least the results are comparable between stations.

[galfert]

And that's the reason wunderground does the rain rate calculation themselves.  It may not be the result you want, but at least the results are comparable between stations.

Looks like I lost you in the conversation. WU does not do any calculation of rain rate themselves. WU only reports the numbers exactly as you submit them and they do nothing with that data other than store it and graph it without any calculations (except unit conversion). I get the results I want by choosing one of 2 calculation methods in my software. The results are comparable between stations that use the same method. There are only two methods. You can compare any two that use the same method. Much like you can compare the speed of two vehicles even if the manufactures decides to take different sampling rates of wheel spin....the results are still the same, speed is speed, as in mph is mph, or inches of rain per hour is inches of rain per hour no matter what the sampling difference is between stations. I'm talking about rain rate as in speed of rainfall.

[nincehelser]

And that's the reason wunderground does the rain rate calculation themselves.  It may not be the result you want, but at least the results are comparable between stations.

Looks like I lost you in the conversation. WU does not do any calculation of rain rate themselves. WU only reports the numbers exactly as you submit them and they do nothing with that data other than store it and graph it without any calculations (except unit conversion). I get the results I want by choosing one of 2 calculation methods in my software. The results are comparable between stations that use the same method. There are only two methods. You can compare any two that use the same method. Much like you can compare the speed of two vehicles even if the manufactures decides to take different sampling rates of wheel spin....the results are still the same, speed is speed, as in mph is mph, or inches of rain per hour is inches of rain per hour no matter what the sampling difference is between stations. I'm talking about rain rate as in speed of rainfall.

If wunderground does no massaging of the numbers that you send, then why were plotting changes apparent after the recent re-code?   After the re-code, the rain rate plots made consistent sense again, just like they did in "wunderground classic". 

During the period when wunderground was supporting both graph styles, you could compare them side-by-side and see they were not always graphing the same way.  What was up with that?  Same data, but different graphs?

Regardless, the protocol definition remains.  "rainin" is the rain accumulation of the last 60 minutes.  That's a rate, of course, but it's not an "instantaneous rate" like you see on a car speedometer.  Then there's also the issue of "rtfreq" and what, if any, impact that has.

You can adjust "rainin" to manipulate the graphs to whatever pleases you.  You claim there are only "two methods", but how can that be when there are all kinds of ways you could change "rainin" to fit your fancy?

What is the other definition of "rainin" you suggest be followed?  Have Davis, Ambient, and Meteobridge agreed upon this same definition?  I hate having to know what the reporting software is (and what settings it has) to know if the graphs are comparable.

[galfert]

You are talking about WU recode that occurred before I ever looked at WU. I've only been following WU for about two years and I don't think it has changed in that time frame. I never experienced WU classic. So I don't know about what you experienced before. I suppose it is possible that at one point (or even still) if your station only reports daily rain as it occurs and not rainin then WU was (or is) then calculating the missing rate for you.

Yes rain rate by the definition of rate per the last 60 minutes is a rate, and the sampling is once every hour for the rate, even if the rate is reported every minute in that fashion it is always determined for once per the previous hour. Hence it isn't instantaneous as you said. The measured time interval is always 1 hour. Doesn't matter how fast or slow it was. All that matters is the total for that measurement period.

When you decrease the measured time interval you are increasing the resolution of the rate reported. Hence it is more instantaneous. More samples per interval. At a certain sampling rate it becomes precise enough. So comparing one station to another with different sampling rates that are high enough to begin with amounts to the same thing. This allows the rate to be more instantaneous.

I have compared my Meteobridge reporting to my Ambient console reporting (simultaneously to different WU IDs) and the rain rates match 100%. I have also compared it to nearby Davis stations and when we report the same rain totals (as in we got the same rain) the rain rates also match.

[CW2274]

Whether this is helpful or not, Davis calculates rain rate on the fly, nothing to do with time parameters. Each successive tip recalculates the rate.

[radioman61]

Isn’t this the classic precision vs accuracy paradox?

Accuracy refers to the closeness of a measured value to a standard or known value. For example, if in lab you obtain a weight measurement of 3.2 kg for a given substance, but the actual or known weight is 10 kg, then your measurement is not accurate. In this case, your measurement is not close to the known value.

Precision refers to the closeness of two or more measurements to each other. Using the example above, if you weigh a given substance five times, and get 3.2 kg each time, then your measurement is very precise. Precision is independent of accuracy. You can be very precise but inaccurate, as described above. You can also be accurate but imprecise.

For example, if on average, your measurements for a given substance are close to the known value, but the measurements are far from each other, then you have accuracy without precision.

A good analogy for understanding accuracy and precision is to imagine a basketball player shooting baskets. If the player shoots with accuracy, his aim will always take the ball close to or into the basket. If the player shoots with precision, his aim will always take the ball to the same location which may or may not be close to the basket. A good player will be both accurate and precise by shooting the ball the same way each time and each time making it in the basket.

[CW2274]

Whether this is helpful or not, Davis calculates rain rate on the fly, nothing to do with time parameters. Each successive tip recalculates the rate.

I'm quoting myself because it's not every tip that recalculates, it's every rain packet that's sent from the ISS, which is about every 20 seconds.

[galfert]

Seems like Acurite is the only one playing by the official WU published rules for rain rate.

Well to be fair I've also noticed that some stations reporting with Cumulus, do also do it like Acurite. But I don't know if Cumulus offers the two options. I just haven't taken notice.

Before WU rapid fire and back when stations were only reporting every 5, 10 or 15 minutes, I think the rain rate for the past 60 minutes rate made sense. Now that we have 5, 10, or 15 second rapid fire, I think it is fitting that the rain rate also be an instantaneous rate. So I feel WU should update the definition of rain rate. Or at least amend it to officially be either method, as it is already happening anyway.

[CW2274]

official WU published rules for rain rate.

I don't consider WU to be "official" at anything, whether they are or not.

[nincehelser]

You are talking about WU recode that occurred before I ever looked at WU. I've only been following WU for about two years and I don't think it has changed in that time frame. I never experienced WU classic. So I don't know about what you experienced before. I suppose it is possible that at one point (or even still) if your station only reports daily rain as it occurs and not rainin then WU was (or is) then calculating the missing rate for you.

I know exactly what my stations report to wunderground as I've either monitored the network traffic or written the code myself.

If you follow the protocol, the rain rate graphs are comparable on wunderground.  Again, that's the whole point.

If you don't follow the protocol and do your own thing for "rainin" reporting, they won't be.

Console reporting is a whole different matter as it depends the hardware specifics. 

Through the manipulation of "rainin" on wunderground, you can mimic the behavior of a particular brand of console's rain rate reporting, but I've never heard of that extolled as a sanctioned alternative standard on wunderground.

The protocol is what it is.

[nincehelser]

official WU published rules for rain rate.

I don't consider WU to be "official" at anything, whether they are or not.

It's "official" only within the scope of wunderground.  Console reporting from different brands aren't necessarily going to match it (and probably won't).  It only makes the graphs more consistent regardless of hardware differences on wunderground.

[CW2274]

official WU published rules for rain rate.

I don't consider WU to be "official" at anything, whether they are or not.

It's "official" only within the scope of wunderground.  Console reporting from different brands aren't necessarily going to match it (and probably won't).  It only makes the graphs more consistent regardless of hardware differences on wunderground.

Understood. That, at least to me, certainly doesn't make it desirable.

[galfert]

Isn’t this the classic precision vs accuracy paradox?

Yes this is accuracy versus precision. By playing by the official WU rules then we lose precision by reducing the sampling rate to once per hour. We don't know at any given moment how fast it is raining by WU rules. But we do know that it is a certain amount within the last hour. That is still precise to the hour but not precise to the minute or seconds.

Here is my favorite picture to summarize what you said:
 [ You are not allowed to view attachments ]

Whether this is helpful or not, Davis calculates rain rate on the fly, nothing to do with time parameters. Each successive tip recalculates the rate.

I'm quoting myself because it's not every tip that recalculates, it's every rain packet that's sent from the ISS, which is about every 20 seconds.

Good to know. Thanks. If Davis wanted though they could still recalculate every 20 seconds but instead report on the previous 60 minute's totals. But I'm glad they don't do it that way.

[radioman61]

Excellent representation of precision vs accuracy!  Probably explains why my chosen home defense weapon is a shotgun...

In reality, it’s only software we’re dealing with.  Would it be that difficult for them to give us an option to select pinpoint or averaging?