[Babase] WeatherHawk design review
Niki Learn
nlearn at princeton.edu
Mon Jul 6 11:09:16 EDT 2009
> On the rain decimal thing:
<snip>
> Also, as I
> understand
> it the rain gauge only reads rain in whole mm and does not in fact
> take a
> reading if there is less than 1 mm of rain, a situation which has led
> us to
> wonder how much the weatherhawk is underestimating the amount of rain
> due to
> evaporation of small amounts of rain between rain events. Therefore
> there
> should not be decimals for rain measurements in any case.
Karl wrote:
I was bumping around the weatherhawk.com site and noticed that it
claims accuracy to 1mm. That does not mean that it does not report
with higher precision. Maybe it needs the higher precision to
avoid roundoff errors that would make it less accurate? I don't
work with instrumentation regularly and haven't spent a lot of
thought on this so maybe I'm wrong here. It would be nice to
get rid of the decimal points.
Niki wrote:
My recollection (and I can find no emails on this - it might have been
something discussed at the joint lab meeting) is that the machine measures
rain by having some kind of little container to catch it that is only
triggered to measure and pour out its contents if there is at least 1mm. I
believe it only measures anything if there is a minimum of 1mm and that it
then measures only in increments of 1mm. Given the typically dry nature of
the climate in Amboseli there was then a question of how much the rain was
being underestimated by the weatherhawk due to evaporation. Of course the
manual rain gauge is only read once a day so there is a similar limitation
there. Again the decimals only appear where there is screwy data so this
all seems to align with there being no decimals. Whew!
Let's see a manual I found on the weatherhawk website speaks of adjusting
the rain collector tip bucket size - so it sounds like you can set the
minimum measuring point and the default is 1mm. I'm willing to bet we
didn't change it and that we probably don't have a higher resolution rain
gauge to allow for smaller increments anyway. You'd think for that money it
would have a laser that could measure the position of the bottom of the
meniscus at least to a tenth of a mm...
"Weather Data - The Weather Data set-up screen (Fig. 10) enables you to
change the Weather
display update interval, log and set a real-time data logging interval with
Write data to database
setting and set the Rain collector tip bucket size."
" The Rain collector tip bucket size defines the resolution of the rain
gauge that is connected
to the weather station and the default is 0.04 inches (1 mm). If your
WeatherHawk has a
higher resolution rain gauge, select the input box with your mouse pointer
and click on the tip
bucket size of the rain gauge attached to your weather station. For rain
measurements to be
accurate the resolution set in software must match the resolution of the
attached rain gauge."
> There was no data provided for 2300 on 2005-07-02 - that row should be
> deleted. I was not aware of duplicate date/times occurring. A quick
> look
> at t29/05/2009 shows me identical data for the two dates. I will
> verify
> that the others are like the same and then we can delete the extra
> rows.
> Problem solved.
Karl wrote:
Yay! 700+ rows are a lot to delete manually. It might be
easier to delete with a sql delete statement and re-upload.
Maybe things got uploaded twice?
Niki wrote:
Those data are in the original Excel sheet twice. Each pair is right next
to each other too. They must have accidentally been pasted in twice and
then at some point the whole lot sorted by date and hour to land them next
to each other like that. I want to delete them from the Excel sheet in any
case. But after I verify that they are all identical duplicates it may well
be easier to delete them from babase using SQL.
> On YearRain: "The amount of rain since 12AM January 1st[133] in
> millimeters." Crazy question - wouldn't rain measured at 12am on
> January
> 1st actually be the last hour of rain for the previous year since the
> rain
> would have been collected between 11pm and 12am? Not sure if that's
> worth
> bothering with, especially since the weatherhawk counts it as a
> January 1st
> measurement (though really, at least for rain, it should belong with
> the day
> before). Feel free to tell me to stop overanalyzing...
Karl wrote:
We're overanalyzing now so that we get it out of the way
and don't have to do it repeatedly in the future. ;-)
My intention was that "The amount of rain since" is
"the rain that has fallen since that time", not
"the sum of the rain measurements starting at that
time". In other words, "since" is not supposed to
be inclusive.
I can't come up with better wording this hot minute,
and I'm not the one who the docs are written for
anyway. So this is where I stand back and take
suggestions for a better wording.
Niki wrote:
Let me confer with the bosses when they are available. We need to work out
how much solar data we are cutting and how to deal with a couple of other
oddities in the measurements soon anyway.
> Are we sure EV and ET are the same thing?
Karl wrote:
No. I'm not very sure of all that much when it comes
to some of these columns. I'm guessing that an older
version of the weatherhawk software reported evaporation
and the newer stuff now reports evapotranspiration.
My guess is that the computation did not change
and they were sloppy in their original column names.
I do know that either one or the other value is present,
never both, so it's not as if any data is actually lost
if we record the switchover date somewhere.
I'm making
these guesses because I don't see any reason to stop
reporting a value (evaporation) and replace it with
something different. If they're computing a new
value rather than just changing the name of the column
I can't think of a reason why they would not just
output another column. (Well, I couldn't at the
time. Now that you mention it I can.)
IIRC the weatherhawk.com marketing materials play
up the "manage your garden" aspect, which makes
me think that it was always evapotranspiration.
The way to find out is to either dig up the manuals,
on-line or physically, or contact the company.
If that does not work then it could be that we don't
know how the value is computed anyway and we may
as well not record the data in Babase. If it's
computed and not the output of an instrument
then there's no real point in storing it
because we could re-compute it anyhow.
(Maybe from temperature, windspeed, and relative humidity?)
Niki wrote:
I'll see if I can find anything.
The only reference to transpiration/ET was this on ETo and transpiration:
" ETo to adjust the value for different ground cover reflectivity and/or
transpiration. The ETo
calculation default in WeatherHawk is based on the ASCE-EWRI Standardized
Reference Evapotranspiration Equation as applied to a turf grass ground
cover."
Yeah, turf grass...very Amboseli-like... I don't suppose we (or the
weatherhawk people?) changed the calculation default for evapotranspiration
when one or both weatherhawks were set up?
> On Heat_lx_in: "The WeatherHawk data dump names this column "Heat Lx
> In"."
> It's actually Ix - I and l look practically the same in Excel but the
> I is
> shorter - I checked and it is definitely an I. Ix is probably short
> for
> index but I don't know what these "in" measurements are supposed to
> mean...
Karl wrote:
Ok. If we keep this column I'll fix it. I think I looked at
the data and found it to be either 0 or 17 or NULL, but
maybe I'm confusing it with something else.
Niki wrote:
Yeah those "In" columns seem to be something the weatherhawk uses to
calculate other things. As far as we can tell they are not useful to us.
Also they have not always been among the output data. I'm not really sure
how the output columns came to be changed but at least no important columns
were lost. The "In" columns are the ones I would be most in favor of
dropping from babase. Them and the crazy HourRain column since it mostly
makes no sense.
> On DayRain: "The amount of rain since midnight[136] in millimeters
> with 2
> decimal points of precision." The weatherhawk does reset this value
> at
> midnight (see for example Oct 18-19, 2004) but that means it is really
> rain
> since 2300 the day before - this goes back to that problem of the
> weatherhawk counting midnight with the am hours for rain even though
> it is
> really measuring rain in the last pm hour.
Karl wrote:
I suspect that the weatherhawk is reporting only 23 hours of rain.
(It stupidly clears the totals before it's midnight report instead
of after.) I ran the following query (in babase_copy,
you'll need to tweak if you want to use the babase_pending.whawk
table):
select whdaytime, hourrain, dayrain
from whawks
where extract('hour' from whdaytime) = '23'
and hourrain != 0
order by whdaytime;
and got no results. Is it possible that it never rained
in the 23:00 hour?
This is also interesting (although not accurate because
of the duplicate rows):
select extract('hour' from whdaytime) as hour, count(*), avg(hourrain)
from whawks
where hourrain != 0
group by hour
order by hour;
(Note that 23:00 does not show up.)
If I'm right you could test by setting the clock
on a weatherhawk to 23:00 (or 22:00?), using a watering can,
and waiting an hour.
I tried retrieving the 23:00 hour rainfall from the
lst24hrrain column but had no luck:
select wh2.whdaytime, wh2.lst24hrrain - wh1.lst24hrrain
from whawks as wh1, whawks as wh2
where wh2.whdaytime = wh1.whdaytime + '1 hour'::interval
and extract('hour' from wh2.whdaytime) = 23
and wh1.lst24hrrain = wh2.lst24hrrain
order by wh2.whdaytime;
Niki wrote:
April 27, 2004 has dayrain and hourrain at 2300 - the dayrain resets there
at 000 on the 28th. Hourrain seems to have actually been working correctly
then... October 14 & 18, 2004 also have dayrain at 2300 (but hourrain seems
to have gone caput by then) and reset at 000 the next day. This pattern
continues everywhere I see rain. I am also suspicious of the above code
(the first batch - I haven't tried the others - just looked at the Excel
data), because if you enter other hours of the day it almost always returns
106 lines of very similar, if not identical, data - not sure what it is
doing but I don't think it is doing what it is intended to. There's also
rain for 2300 hours in the Last24Hour and MonthRain columns where there
should be.
More information about the Babase
mailing list