possibly the wind direction in the picture above is "N/A" because the wind velocity is so low or zero. Also the time "__NOW__" should be 2 * 2min + 1 min not 2 * 1min + 1min.
On Sunday, February 6, 2022 at 8:31:05 AM UTC-8 William Garber wrote: > the separate points on the line are gone and it is all joined-up > continuous lines now. fixed. one problem; wind direction is not perfect > yet ... I think I'm still getting some "NULL" data there. Maybe increase > archive_interval some more. > See beautiful plots attached. > > On Sunday, February 6, 2022 at 8:15:05 AM UTC-8 William Garber wrote: > >> NOTE: I ordered the clone of the Fine Offset WH25 (barometer; humidity; >> temperature) for indoor measurements. The main point is that this is on >> 433mhz frequency so it will save time with the noise level estimation when >> rtl_433 hops frequencies. Since the atlas is on the same frequency it will >> not need to hop frequency. Then what do I do? >> __NOW__ ... >> The time period minimum for 433mhz atlas complete data set is 30 sec. >> The time period minimum for 915mhz WH32B data set is 60 sec. >> Since rtl_433 hops frequencies and spends the *same time* on each >> frequency, the formula is "archive_interval = 2 * max(T(atlas), >> T(WH32B))+(time overhead for automatic noise estimation) = 2 * 1min + >> 1min. Note: leave 1min overhead for automatic noise estimation, so >> archive_interval = 5min. >> ____WITH WH25 ON 433mhz____ ... >> "archive_interval = max(T(atlas), T(WH25))" I think this is the right >> formula not T(atlas)+T(WH25) since it can read both packet sequences >> intertwined (as they come in at the same time). >> by the way weewx is a wonderful program. >> On Sunday, February 6, 2022 at 7:15:18 AM UTC-8 matthew wall wrote: >> >>> On Sunday, February 6, 2022 at 9:26:38 AM UTC-5 [email protected] >>> wrote: >>> >>>> may have fixed it. used rtl_433 set only to 915mhz to time interval of >>>> WH32B ... it is 1 minute between packets. >>>> atlas is much faster than 1 minute. >>>> need to add time for rtl_433 finding "minimum detection level based on >>>> noise" for each frequency hop. >>>> set "hop_interval 120" in rtl_433.conf. set "archive_interval = 300" >>>> in weewx.conf. >>>> 300 sec = two times 120 ... one for atlas and one for WH32B plus an >>>> extra minute for "minimum detection level based on noise". >>>> This fixed the problem. Now weewx draws lines not points when >>>> plotting. >>>> >>> >>> excellent! as you discovered, there are two approaches: either get more >>> data samples, or adjust the 'line_gap_fraction' to connect the dots (as >>> explained in the weewx user guide: >>> http://weewx.com/docs/usersguide.htm#dots_in_plots) >>> >>> i am not familiar with the internals of belchertown skin, but i think >>> that 'gapsize' is the parameter that the belchertown skin uses for a >>> similar purpose to line_gap_fraction. >>> >>> as for record_generation, when using the SDR driver you want >>> 'software'. but it won't matter. the SDR driver cannot do hardware-based >>> record generation (that only works if there is a hardware data logger), so >>> it tells this to weewx when it is loaded. so weewx uses >>> record_generation=software, even if 'hardware' is specified in the config >>> file. you should see this in the log file during startup. >>> >>> >>> >>> -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/6ed361ab-3589-4cf1-bb5f-38cf2abcffc2n%40googlegroups.com.
