The issue is not only at midnight. It occurs throughout the day whenever the wind speed reaches a new daily high.
Bob On Thursday, March 9, 2017 at 10:08:15 PM UTC-8, gjr80 wrote: > > That would give you (in most cases) the same result. The issue is that > 'weewxDailyHigh' does not reset until weeWX saves the 00:00 archive record > to database which (by default) occurs at 00:00:15. After that 15 second > period everything is as it should be. The issue can certainly be fixed but > for a small issue that presents itself for 15 seconds at midnight I am > loathed to spend more time altering an already complex system of loop > stats. The new approach I am working on should do away with the > (continuous) reliance on the the weeWX daily summaries and I will wait > until I have that nailed down before dealing with this issue. > > Gary > > On Friday, 10 March 2017 15:55:52 UTC+10, tempus wrote: >> >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
