Sweet spot for driver update frequency

[DR]

I see there are various update frequencies for drivers, ranging from
every 2 seconds or so for Davis to as long as 15 seconds for a few others.

I know that WeeWx updates the data base at 5 minute intervals.


Is there a good choice, or is anything OK, for having the gen-loop code
report to WeeWx as it monitors the weather station?

Thanks.  Dale


Oh, the stuff I'm slowly working on uses a data logger which can
accumulate gust speeds etc which potentially could be missed if a
snapshot of time was the only source of speed, for example, over a
longer observation time.

[Vince Skahan]

I know some sensors/solutions don't like being queried too fast due to hardware/firmware constraints, but that's different than how frequently you write loop data out.

I guess my answer is I wouldn't write anything out unless the hardware emitted data you listen for (or alternately when you query the particular hardware for data).

Not knowing what hardware you are trying to support nor what you're supporting I couldn't even guess on a number.

Being needlessly crazy frequent would pound your weewx system and its disk accordingly which probably should be avoided.

[DR]

Vince,

Thanks, I get the drift and didn't know if there were some internal
design goals that were considered when the designers hatched WeeWx.

Since you are familiar with this program and have written things for it,
I take your advice seriously.

The hardware is Campbell Scientific datalogger  (both CR1000 and CR3000)
and can write as seldom as needed (which is of little value) or up to at
least 100/second, which is indeed excessive.


So far my test bed has been writing serial output every 20 seconds and
is pretty happy with that.  I will make sure that the gust data, which
could be missed if WeeWx were doing all the monitoring during that 20
second interval) is furnished by the datalogger, just to make sure.) 
I'm not so concerned about the occasional missed higher number and if I
read the discussions about what constitutes a gust, it might not be that
two second wind blast during a downpour.


Thank you for the info.  Dale

[Vince Skahan]

Wow pricey.   Picking a number might depend on which actual sensor is doing the logging as well.  I can find a few $$$$$$ vendors that can do sub 1-second measurements but not really anything in normal consumer cost ranges that are faster than Davis 2-sec wind if that helps any.

I can't speak to Tom's design goals other than to 'guess' that he wanted to support whatever the vendors provided.

[DR]

It's a hobby.

If I bought the stuff new, my divorce hearing would have been already.


The dataloggers were eBay over the years and now retired I have time to
put together stuff and play with it.  RM Young wind, temp, humidity,
baro etc were all picked up when they were plentiful (no more) on eBay
and almost all new for pennies on the dollar.


Anyway, the basic design has something to say on how other things were
implemented and from reading the info, much of the timing on the Loop
was due to Davis (very popular but now getting expensive, too) having
set what they did.  Fortunately the ability to write drivers for those
who can makes a wide variety possible.


What a hobby!  Thanks for guidance.  Dale

[Tom Keffer]

There's no hard and fast rule, but it is important that every observation type get sampled at least once an archive interval, especially with partial record instruments.

I've worked with Campbell loggers (primarily the CR6), and they are more oriented towards long-term climatological observations. You put one in the field, come back 6 months later, take the chip out, and the record highs, lows, etc. in a database. For that, sampling rates tend to be slow so as to preserve battery life.

I'm interested in how the logger integrates with WeeWX. I've never thought of using them that way. I've always seen them as an alternative to WeeWX, rather than a source of data for WeeWX.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/3c2025f9-74c4-4544-b9a1-bd0095e92702%40gmail.com.

[DR]

I am a rank amateur with Python coding but pretty good at CRBasic (the
Campbell Scientific programming language for many applications.)

In the last 6 years or so I have put my collection of sensors into the
Campbell data logger which then acts as a consolidation device to feed
Weather-Display and has pretty well for oh so many years.


There is so much  about WeeWx that I like I have been searching for a
solution, and having found no easy good one, have with trepidation
started trying to get a driver for WeeWx to read the serial output of
the data logger into a USB on my Raspberry Pi. So far things are looking
good and over the next few weeks (I'm old and don't write code as fast
as i used to decades ago) so whether or not I'll be successful, who
knows but I'm using the backbone of FileParse and a TWI driver written
by Matthew Wall for inspiration.


I've found the loggers are exactly as you mention, able to do research
level data collection very slowly over long time periods, but also have
been used to gather very rapid sensor inputs and of course those
meteorologic ones, too, which is about as fast as I can think.


I'll keep you posted.  I have lots of stuff to hang onto the logger. 
The ultrasonic snow depth is already been running for a couple of years,
along with every other basic wx parameter like wind, temp, humidity,
solar, etc.


I also have a field mill to measure the vertical electric field during
storms which is pretty fun for those who are out in left field, but
would doubt anyone other than a few lightning people would have interest.


Just saying this to let the WeeWx developers know there is great
interest in such a versatile program as WeeWx is to be able to do lots
of stuff.  Thanks for your help, I will let  you know if I'm having
progress.

It is a hobby!