I continue to find it almost impossible to conceive a situation where an 
archive interval of under 5 minutes serves any useful purpose.  As long as 
a gust value is recorded for the 5 minute period the average speed 
value/direction over the period is more than sufficient - even for an 
airfield - and the other readings are unlikely to alter over 5 minutes 
anyway.  So with a Pi a 5 minute interval is more than sufficient.

I found the following whilst googling wind gust which I thought useful 
since the implication is that wind measurements over short periods of time 
(if the rest of the world is right) are error prone anyway:

"Wind gusts (which last only a few seconds) make it hard to determine the 
overall wind speed of storms whose winds don't always blow at constant 
speeds. This is especially the case for tropical cyclones and hurricanes. 
To estimate the overall wind speed, the wind and wind gusts are measured 
over some period of time (typically 1 minute) and are then averaged 
together. The result is the highest average wind observed within the 
weather event, also called the *maximum sustained wind speed*. 

Here in the U.S., maximum sustained winds are always measured by 
anemometers at a standard height of 33 feet (10 m) above ground for a 
duration of 1 minute. The rest of the world averages their winds over a 
period of 10 minutes. This difference is significant because measurements 
averaged over just one minute are about 14% higher than those averaged over 
the course of ten minutes."


On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote:
>
> Yes the NoneType error is certainly due to the realtime clientraw 
> extension not handling a None value correctly, by the looks of it a wind 
> related field so quite possibly brought on by your battery/connectivity 
> issue. That extension was written over 2 years ago and never formally 
> released (and judging by the lack of user questions I assume not used by 
> too many). So that means it is probably not too robust. It maybe easiest to 
> just disable it until I can get to have a look at it in the next 2-3 weeks 
> (as per other thread).
>
> Some good advice above about getting a machine to work reliably, the only 
> thing I would add is chose your archive interval carefully as that also has 
> an impact on stability when you start to add in a number of extensions. A 5 
> minute archive period means there is 5 minutes between report cycles so 
> arguably WeeWX has around 5 minutes to get all of its report processing 
> completed, cut that down to 1 minute and WeeWX now only has 1/5 the time. 
> You don't want your reports taking longer to run than your archive 
> interval, that would be bad on many fronts. Some folks think that having 
> the shortest possible archive interval is essential, that may be the case 
> in some circumstances but there are other secondary effects that need to be 
> kept in mind. Basically, to run a 1 minute archive WeeWX needs to be fairly 
> lean extension wise.
>
> Gary
>
> On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote:
>>
>> On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote:
>>>
>>> Noted the use of skins and mqtt on a pi, i kind of assumed it was up to 
>>> the job, i do like the weewx system so may well move up to a more useful 
>>> machine - coming from Windows into this world means i know little beyond 
>>> Dells and Win 10 which is what i have been trying to avoid due to frequent 
>>> updates and crashes of other systems.
>>>
>>> Any advice on what sort of system weewx needs to run would be good 
>>> (again i should Google this first!).
>>>
>>
>> here are some suggestions:
>>
>> https://github.com/weewx/weewx/wiki/hardware
>>
>> data collection is almost never a problem.  uploading data is not cpu, 
>> i/o, or network intensive.  most reports will run just fine on a pi or 
>> other low-power machine - you should have no problems with 1 or 2 reports.  
>> however, you might have issues if you try to run 3 or 4 query-intensive 
>> reports with a short archive interval.
>>
>> in some configurations, the crt (cumulus realtime) and wdcr (clientraw) 
>> extensions can be problematic on low-end hardware, since they query the 
>> database each report cycle (archive interval) to get the data they need.  
>> if you run them on archive intervals you should be ok, but if you run them 
>> on loop packets you can easily run into the 'database locked' problems.
>>
>> the NoneType error is almost certainly due to a bug in rtcr.py - it is 
>> getting a value of None but does not handle it properly.
>>
>> m
>>
>

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

Reply via email to