There is no formal lower limit for the polling interval, though in reality it is effectively one second plus the time it takes for the driver to poll the GW1000, obtain the required data emit the loop packet (the one second limit comes from a one second delay in the loop that polls the GW1000). It's hard to put a value on the time taken to poll the GW1000 and emit the loop packet, largely because the driver runs the data gathering in a separate thread and queues data to the driver. I did some rough testing tonite on a RPi3B and a VM on my laptop and the driver thread was obtaining the necessary data from the GW1000 and presenting it within 0.05 to 0.7 seconds. I think that puts a practical lower limit around 2 seconds.
I have not tested the driver at such low polling intervals, other than setting the laptop VM just now to poll every two seconds. The driver and WeeWX appear to continue to operate correctly though I would hardly call this a conclusive test. You may well be able to drop the polling interval to 0 for 'as fast as possible' operation but I have not tested this. You are correct that socket timeouts, retry wait and max tries may have an impact, it really depends on your system and network. I can't vouch for what dropping these to zero will do, this could cause a crash should a timeout or retry occur. The other thing to bear in mind is that there is not just one call to the GW1000 API to obtain the data for a loop packet. There are multiple calls (I can think of at least three and potentially there are more), so if there is any contention on your network then you may experience multiple timeouts, retries etc. I guess at the end of the day it's a case of suck it and see. I would suggest running WeeWX directly so you can see the loop packets and their timestamps (and data). Gary On Wednesday, 20 January 2021 at 18:05:53 UTC+10 ward...@gmail.com wrote: > Question about shortening the poll interval an implications / > recommendations... > My setup is I’ve got 2x GW1000’s both reading lots of “shared” sensors but > one reading at WS80 and one reading a WS68. I then have 2x Raspberry Pi’s > concurrently, both running the API in driver mode and receiving data from > each GW1000 separately into separate Weewx 4 DBs on each Pi. > > My objective is to ensure that all the wind sensor’s data at the reporting > frequency it is produced (I mean seconds, not MHz) is captured and loaded > into weewx, so that it can get the statistics correct for max/mean etc over > the standard 5 min report periods. Otherwise AFAIK some sensor dat is lost > as the GW1000’s only make available the latest sensor data readings to own > stream services, if the frequency of that push/pull is lower than the > sensor frequency (see https://www.wxforum.net/index.php?topic=41201.0). > > So... I was planning to set the poll_interval of the API pointing at the > “WS80’s GW1000” to say 4s or 5s (WS80 updates every 4.8s), and the “WS68’s > GW1000” to 16s (WS68 updates every 16.5s). > > I could not see any restrictions on doing this in the wiki/docs, but I was > potentially concerned in overloading the servers particularly the GW1000’s. > I was wondering > - if this is feasible (e.g. no lower limit?), > - if you have tested this at higher frequencies, and > - if you have any recommendations on doing this or not, or other settings > changes with higher frequencies? E.g. socket_timeout, max_tries, retry_wait > (all which I was planning on leaving as-is) > > Thanks! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f4ef9069-b68c-40d9-8e0a-f8d2a585e0fbn%40googlegroups.com.
