Gary, after carefully watching data from an anemometer and thinking about 
this issue more, I have decided that a 10-minute moving gust-window is more 
reasonable than I had thought. So unless you are already underway with what 
I described below, let's forget about it.

Bob

On Thursday, February 23, 2017 at 8:53:39 AM UTC-8, tempus wrote:
>
> With a 10-minute gust window, a high-velocity-gust 10-minutes ago still 
> determines the indicated gust level, even though gust velocities since that 
> time may have been much lower.  The gust indication in that case is 
> 10-minute-old information.  I am wanting gust information that is much 
> closer to real time.  A min_interval <= loop-period with min_interval set 
> to 3-seconds may be too short to provide useful data, because of the 
> high-frequency filtering-effect of cup-rotational-inertia.  If so, some 
> small multiple of that interval can be used instead.  What I am wanting is 
> a gust-window that is much shorter than 10-minutes, but of course long 
> enough to differentiate between very recent gust velocities and the 
> periodic latest-point-in-time wlatest velocity samples.
>
> Bob
>
> On Thursday, February 23, 2017 at 12:31:21 AM UTC-8, gjr80 wrote:
>>
>> On Thursday, 23 February 2017 17:55:12 UTC+10, tempus wrote:
>>>
>>> I am wanting glatest to be the peak gust over the moving rtgd 
>>> 'min_interval'. I realize wgust already provides peak gust over a 10-minute 
>>> moving window, but in contrast, glatest would provide near-real-time gust 
>>> information if min_interval is made short.
>>>
>>
>> I really am having a hard time coming to grips with this. I understand 
>> your definition of glatest; but *glatest would provide near-real-time 
>> gust information if min_interval is made short*? I don't see that a 10 
>> min gust calculated now or a 30 second gust calculated now are any more or 
>> less 'near-real time'. One uses a smaller window than the other but they 
>> are both just as near real time as each other. If decreasing min_interval 
>> makes glatest 'more near real-time' does reducing it to 0 may it as real 
>> time as it gets? On one hand you seem be advocating pumping out wind data 
>> as fast as you can (which implies min_interval == 0) but on the other hand 
>> you want max(windSpeed) over min_interval. On a Vantage, and I suspect most 
>> all of the other stations, glatest=wlatest for min_interval <= loop period. 
>>
>> Nothwithstanding, I will look at doing adding it.All of the data is being 
>> cached so it should be easy enough to do. 
>>
>> I realize SteelSeries Weather Gauges enhancement is beyond the scope of 
>>> rtgd.  However, standard installations would ignore glatest and remain 
>>> compatible and I can provide a modified gauges.js file with a 
>>> near-real-time gust pointer to weewx users who want it (*or ideally to 
>>> the SS Weather Gauges author if he is willing to incorporate it for weewx 
>>> users*).  Unrelated to the gust issue, I have fixed gauges.js coding 
>>> mistakes that should be submitted to him anyway.
>>>
>>
>> No problems, just wanted to make it clear I wasn't touching gauges.js.
>>
>> Gary
>>
>

-- 
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