On Sunday, 30 April 2023 at 13:42:56 UTC+10 william...@att.net wrote: Just one question please :-). Suppose the read of the arduino could possibly take a relatively long time, and you want to have a timeout after which it gives up and saves None/NULL for the indoor data.
What is the max timeout that would be reasonable relative to the archive interval ? I would be more concerned about the loop packet interval than the archive interval. Your initial post indicated the Atlas emits packets every 7 seconds so the SDR driver will be emitting loop packets every 7 odd seconds. If you have a plain vanilla WeeWX install WeeWX will not be doing much else during the loop packet interval other than calculating derived obs so dwelling for up to, say, a second should have no significant effect. What happens if the delay goes past the end of the main archive interval the event you are handling was in? Delaying past the end of the archive interval will not have a significant impact (within reason). Say your service delays 20 seconds past the end of the archive period, when the driver gets it's turn again it will emit another loop packet which will cause an archive record to be generated by WeeWX and ultimately the report cycle is run maybe 20+ seconds later than usual (note the exact behaviour of the driver is very much driver dependent; some drivers may skip loop packets, others may emit a loop packet immediately and yet others may delay emitting a loop packets - the SDR driver is threaded and I believe it is the former). So really you will probably only noticed delayed report output. Where you will probably get more problems from delaying the WeeWX main loop is in the generation/processing of loop packets. As mentioned above driver behaviour varies from driver to driver. For example, the vantage driver obtains loop packets every 2 odd seconds; if a loop packet is missed it is gone forever. Other drivers poll the hardware much less frequently, say every 50 odd seconds, in that case there could be an entire minute might go by with no data. The consequences of a missed loop packet depends on the system config. A vantage station with a five minute archive interval would see around 120 loop packets per archive period, so the loss of one loop packet will have no real impact. Consider the second system with loop packets arriving every, say, 50 seconds; if it had an archive interval of one minute, you could conceivably see no loop packets in an archive interval and hence no archive record is generated and no report cycle occurs. Remember loop packet data is accumulated by WeeWX and many obs in the resulting archive record are simply the average value of the obs from all loop packets seen during the archive interval. So for slow changing obs, such as air temperature/atmospheric pressure, losing the odd loop packet during an archive interval will have no real impact on the archive record data provided there are numerous other loop packets received in the archive interval. This may not be the case for rapidly changing obs such as wind speed and direction or cumulative obs such as rainfall, in these cases it may be important not to lose loop packets. One way to deal with sources that have significant latency is to place the code that interacts with the source in it's own thread, this usually entails one or more queues to pass data to the driver/service which adds complexity. The non-threaded approach has simplicity, but risks delaying the WeeWX main loop. I think what is happening is I usually get very fast reads from the arduino but once in a while I get a really slow one. Could be something independent like me reading the database while weewx is trying to write it? Possible I guess, if WeeWX was doing some substantial report generation at the time, otherwise not likely. Do the slow response occasions align with WeeWX report generation? What happens if you take WeeWX out of the equation and run a simple python script to poll the Arduino every so many seconds and output the time taken to obtain a response? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/bbdb6854-fdb8-4e91-b3bc-4970c48da551n%40googlegroups.com.
