Acurite Atlas with Ambient (Fine Offset) WH32B for indoor pressure/temp/hum SETUP

[William Garber]

Using rtl-sdr; rtl_433; weewx-sdr; weewx.

The Acurite Atlas is on 433mhz.  The Ambient WH32B is on 915mhz.

(1) I am not sure how to configure weewx and rtl_433 for two frequencies both

used by weewx; see my config for both.

(2) There are a lot of "almost" duplicate packets.

(3) The time period between packets is different for WH32B and Atlas.

so what, should I use the larger of the two for the archive_interval in weewx.conf ?

(4) if you look at the output, especially for the barometer (WH32B), the graph is just a lot of dots.  Also a lot of the graphs are just dots.  I think they should be connected by lines.  So I set line_gap_fraction = 0.99999999 in skin.conf but it didn't make any obvious difference.  Also it would be nice if there were no disconnected vertical discontinuities (jumps); weewx should draw a vertical line for a vertical jump (a suggestion).

(5) acurite atlas sends three (or more?) different types of packet.  WH32B sends one type of packet, but has a much longer period between packets.  so how does weewx combine the multiple different packets, eliminate duplicates and form a single archive record?

this could be made more obvious in the documentation (a suggestion)

otherwise weewx is a wonderful awesome program.

[William Garber]

note plots for day are just disconnected points.  plots for week and year look like continuous curves or lines.

is this relevant? 

https://groups.google.com/g/weewx-user/c/uGk23BPOPHk

[William Garber]

rtl_433 spends a lot of time whenever it hops from 433mhz to 915mz adjusting the minimum detection level based on noise (automatically).

I purchased a fine offset clone WH25 today which is on 433mhz to avoid this problem.

Perhaps what is happening is a lot of the archived results are getting nulls because the slower (WH32B) is not done communicating by the end of the archive_interval.

Note the short archive_interval = 30 or 120 seconds.  Is this way too short especially in my case?

[William Garber]

also this:

https://github.com/poblabs/weewx-belchertown/issues/158

not sure what "gapsize" is; is this now the same as "line_gap_fraction" in skin.conf ?

[William Garber]

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. 

I assume this means there are no nulls in archive records due to archive interval expiring faster than complete packets arriving.

next question:  should have in weewx.conf "record_generation = hardware" or "record_generation = software" ?

[matthew wall]

On Sunday, February 6, 2022 at 9:26:38 AM UTC-5 william...@att.net 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.

[William Garber]

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.

[William Garber]

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.

[William Garber]

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.

[Kevin Crivelli]

where were you able to find that fine offset clone WH25?