It seems that merely setting "wgustTM" in 'gauge-data.txt' to the highest of the daily-high-gust-value from weewx and the current rtgd "wgust" value would be an easy fix. I am not fluent in Python, so this may not be technically correct, but in principle like this:
IndicatedDailyHigh = max(weewxDailyHigh, rtgdTenMinuteHigh) -Bob On Thursday, March 9, 2017 at 2:49:06 AM UTC-8, gjr80 wrote: > > I observed again at midnight just gone, yes the daily high gust pointer > does take a number of seconds before resetting, this is due to the > (default) 15 second delay weeWX has from an archive record being generated > until the data is saved to archive and the daily summaries updated (rtgd > uses a combination of the daily summaries and the loop data since the last > archive record to determine daily highs). I am working on a better method > of keeping various stats (highs/lows/avg etc) in a loop environment for a > separate project, when I get that working I may roll the new approach into > rtgd which may improve this. In the meantime the delay can be lessened by > reducing the archive delay using the archive_delay option in [StdArchive] > in weewx.conf. Whilst the option can be safely reduced from 15 how far it > can be safely reduced will, I expect, be station and system dependent. > > Gary > > On Thursday, 9 March 2017 17:19:06 UTC+10, tempus wrote: >> >> Each time the wind reaches a higher value than previously reached since >> midnight, both the gauge-hand and the 10-minute-gust-indicator move >> simultaneously to the new high, but the daily-high-wind-gust-pointer does >> not. It remains at the previous daily-high until expiration of the current >> weewx 300-second archive interval when it then also moves to the new high. >> >> I will be traveling the next 24-hours and not able to respond quickly. >> >> -Bob >> >> On Tuesday, March 7, 2017 at 4:04:37 PM UTC-8, gjr80 wrote: >>> >>> I would say that this will quite often be the case. >>> >>> The daily high wind gust pointer should always indicate the highest wind >>> speed seen after midnight at the start of the day and up to and including >>> midnight at the end of the day. In other words it will reflect the highest >>> wind speed indicated by the gauge hand throughout the day. At midnight the >>> daily high wind gust pointer is reset to 0 and it will again start tracking >>> the highest wind speed seen throughout the new day. On the other hand, the >>> 10 minute gust value is the highest wind speed seen over the last 10 >>> minutes, it is not constrained by day boundaries. So consider the first >>> packet that arrives after midnight, say at 2 seconds after midnight. >>> Assuming its windSpeed value is >0, the daily high wind gust pointer will >>> move the this new value. Now if the 10 minute wind gust value is currently >>> higher than this latest windSpeed (in other words the 10 minute wind gust >>> occurred some time in the last 10 minutes of the previous day), the daily >>> high wind gust pointer will not be affected by the 10 minute wind gust and >>> nor should it (because it occurred yesterday). If the 2 seconds after >>> midnight windSpeed value is higher than the 10 minute wind gust value, then >>> the 10 minute wind gust value will be updated to this new windSpeed value >>> and the daily high wind gust pointer will indicate the same value (as will >>> the wind speed gauge hand). >>> >>> The real check for correct operation of the daily high wind gust pointer >>> just after midnight is to verify that it tracks the highest speed indicated >>> by the gauge hand after midnight. If the gauge hand indicates say 5mph and >>> the daily high wind gust pointer indicates 4 mph then we have a problem. >>> >>> Gary >>> >>> On Wednesday, 8 March 2017 02:40:39 UTC+10, tempus wrote: >>>> >>>> The only issue I have noticed since upgrading to v0.2.9 is that for a >>>> short time period following midnight the daily high wind gust pointer was >>>> below the 10-minute high gust indication. However, I went to bed after >>>> that and haven't watched since. Based on that single observation it >>>> appears that periodic daily high wind speed values from the weather >>>> station >>>> aren't being updated to include latest wind speeds. >>>> >>>> -Bob >>>> >>>> On Tuesday, March 7, 2017 at 4:20:34 AM UTC-8, gjr80 wrote: >>>>> >>>>> Well I observed your wind speed gauge over a couple of continuous 10+ >>>>> minute periods this afternoon, there were 5 occasions where the gauge >>>>> indicated a speed higher than the present 10 minute gust and in each case >>>>> the 10 minute gust immediately jumped up to the indicated speed. I guess >>>>> this supports your observations under v0.2.9. I noticed a number of >>>>> changes >>>>> (daily max, gauges rescaling, windrun going to 0) at 6PM my time and >>>>> thought what? Then I realised it was midnight and change of day (I am +10 >>>>> UTC). So the chnage of day appears to works fine. >>>>> >>>>> Periods of lower wind speeds are more likely to include some 0 wind >>>>> speed packets than periods of higher wind speed. It's possible the old >>>>> method of calculating the 10 minute gust could have been upset by 0, I >>>>> don't believe that was the case but who knows. >>>>> >>>>> Staring at a gauge for 10+ minutes is incredibly boring so I will >>>>> leave that for now, let me know if you notice anything else that does not >>>>> appear right. >>>>> >>>>> Gary >>>>> >>>>> On Tuesday, 7 March 2017 17:24:58 UTC+10, tempus wrote: >>>>>> >>>>>> Sorry about the 403 Forbidden error. That is a test domain and public >>>>>> access is often blocked. I opened access a few hours ago when I saw your >>>>>> message, but didn't have time right then to post a response or upgrade. >>>>>> I >>>>>> have since upgraded to v0.2.9. You should now be able to see it working >>>>>> here: >>>>>> >>>>>> http://www.lablibrary.com/ss/newport.php >>>>>> >>>>>> This area recently had a several-day period of unusually light winds. >>>>>> The 'wgust" value anomalies occurred at those unusually low wind speeds. >>>>>> I >>>>>> don't know why functionality would be different at different speeds, but >>>>>> whatever the reason, v0.2.8 'wgust' anomalies occurred far less >>>>>> frequently >>>>>> today at higher speeds and I haven't seen them at all since upgrading to >>>>>> v0.2.9. >>>>>> >>>>>> Weather forecasts are not very reliable in this area, but there may >>>>>> be an opportunity to check higher-speed functionality tomorrow, because >>>>>> the >>>>>> National Weather Service has issued this High Wind Watch: >>>>>> >>>>>> "*South wind 30-40 mph with gusts to 65 mph, strongest near beaches >>>>>> and headlands but also possibly affecting coastal communities. Winds >>>>>> spreading northward late Tuesday morning, with peak winds from about >>>>>> noon >>>>>> to 4:00pm or 5:00pm. These winds could cause tree damage that could lead >>>>>> to >>>>>> power outages, and will cause hazardous driving conditions.*" >>>>>> >>>>>> My anemometer is 33-feet (*10 meters*) above ground, 204 feet (*62 >>>>>> meters*) above mean-sea-level, and line-of-sight to the sea, so it >>>>>> should be spinning rather quickly if the forecast is correct. The time >>>>>> here >>>>>> is 8 hours behind UTC. >>>>>> >>>>>> -Bob >>>>>> >>>>>> On Monday, March 6, 2017 at 2:26:22 PM UTC-8, gjr80 wrote: >>>>>>> >>>>>>> >>>>>>> On Sunday, 5 March 2017 06:11:53 UTC+10, tempus wrote: >>>>>>>> >>>>>>>> I have been traveling for a few days with only a SmartPhone to >>>>>>>> watch data. However, based merely on wind-speed-gauge indications >>>>>>>> there >>>>>>>> seem to be "wgust" value anomalies. The pink gust-area sometimes >>>>>>>> disappears >>>>>>>> even though there have been recent gusts into that speed-range. >>>>>>>> Furthermore, gusts above the indicated upper-gust-limit often do not >>>>>>>> cause >>>>>>>> the indicated gust-range to expand. >>>>>>>> >>>>>>> >>>>>>> I have been closely observing my wind speed gauge over the last few >>>>>>> days during various windy periods. I did notice periods where the red >>>>>>> gust >>>>>>> 'wedge' would disappear for a short period. I observed several >>>>>>> occasions >>>>>>> where the indicated wind speed went higher than the existing 10 minute >>>>>>> gust >>>>>>> value, on all occasions the ten minute gust value was immediately >>>>>>> increased >>>>>>> and the red gust wedge similarly increased in size immediately to match >>>>>>> the >>>>>>> indicated wind speed. >>>>>>> >>>>>>> >>>>>>>> It is my understanding that the value of "wgust" is supposed to be >>>>>>>> the speed of the highest gust over the last ten-minutes. If so, the >>>>>>>> ten-minute time-window should include recent "wlatest" values. >>>>>>>> >>>>>>> >>>>>>> That is my understanding as well and that is exactly what rtgd does. >>>>>>> The issue in this case was the method in which the ten minute wind gust >>>>>>> value was derived from the ten minute wind speed list. This has been >>>>>>> fixed >>>>>>> in v0.2.9. >>>>>>> >>>>>>> I have no solution for the gusts you observed that did not update >>>>>>> the ten minute gust value. I have not been able to replicate this issue >>>>>>> and >>>>>>> I have reviewed the code and am confident it is correctly capturing >>>>>>> windSpeed data and calculating 10 minute gust values. I suggest you >>>>>>> upgrade >>>>>>> to v0.2.9 and see if the issue remains, if so we need to determine the >>>>>>> conditions under which the issue occurs. If this is not possible >>>>>>> visually >>>>>>> then I have some wind speed debug code that will dump the windSpeed >>>>>>> history >>>>>>> list and other key values to log and we will need to wade through the >>>>>>> figures to determine the issue. >>>>>>> >>>>>>> I did go to your previously posted link to try to observe the issues >>>>>>> you describe myself but the link now gives me a 403 Forbidden error. >>>>>>> >>>>>>> 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
