rtl_433
rtl_433 copied to clipboard
merbanan
Bresser Weather Station - sporadic reception issues
Hi,
I have a Bresser 7-in-1 and two 6-in-1 sensors (pool + indoor) and I'm experiencing outages in the data, even though the weatherstation and the antenna are completely stationary. The outages take from 10 min to 1 hour.
What could be causing this? How could I improve the reception? Is it a software issue, or a radio issue?
Attached is the SNR Graph over the past 7 days, the big outages can be ignored, there the power was off. Also the graph with noise values.
I'm using a RTL-SDR with this antenna: https://www.amazon.de/gp/product/B07CZMCJ8Z/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
Config options for rtl_433 are: RTL_433_OPTIONS= -f 868.3M -M level -M noise -s 1024k -Y autolevel -Y minmax -Y magest -F mqtt://127.0.0.1:1883
Could it be interference? Can you record (-w file_868.3M_1024k.cu8 -T 120) a few minutes of the band while the reception isn't working?
The weird part is, that it's not all sensors at the same time. All of them should be sending on 868.3M.
Here also the received messages chart:
I will try to record it.
Sometimes sensors sync up and will shadow each other for a short time. Regular outages point to that.
Oh, so that they themselves create the interference. Is there anything I could do to improve such situations?
@zuckschwerdt Uploaded the file here: https://github.com/Thoro/rtl433-dumps/blob/master/file_868.3M_1024k_2.cu8.gz
There is no issue with that capture, the band looks fine and the Bresser-6in1 is found every 12 seconds. Did you record that randomly or when you saw the reception as broken?
I recorded it when the message rate of the weather station Bresser-7in1 (!) fell
Oh sorry, okay, so there should be a 7-in-1 among the 6-in-1's there?
We see 22 transmissions in that capture (rtl_433 -S all file_868.3M_1024k_2.cu8 to split).
Removing the 6-in-1 that leaves 12 unknown transmissions.
- g001_868.3M_1024k.cu8 (43019 samples) faint FSK
- g003_868.3M_1024k.cu8 (41943 samples) FSK (A)
- g004_868.3M_1024k.cu8 (147675 samples) FSK (B)
- g006_868.3M_1024k.cu8 (41943 samples) FSK (A)
- g008_868.3M_1024k.cu8 (41942 samples) FSK (A)
- g009_868.3M_1024k.cu8 (147672 samples) FSK (B)
- g011_868.3M_1024k.cu8 (41943 samples) FSK (A)
- g013_868.3M_1024k.cu8 (147675 samples) FSK (B)
- g015_868.3M_1024k.cu8 (41942 samples) FSK (A)
- g017_868.3M_1024k.cu8 (41943 samples) FSK (A)
- g018_868.3M_1024k.cu8 (147675 samples) FSK (B)
- g021_868.3M_1024k.cu8 (147712 samples) FSK (B)
(A) seems to be a 10 µs (100 kbps) PCM signal
(decode with rtl_433 -Y minmax -R 0 -X 'n=name,m=FSK_PCM,s=10,l=10,r=200' g003_868.3M_1024k.cu8)
(B) seems to be a 30 µs (33 kbps) PCM signal
(decode with rtl_433 -Y minmax -R 0 -X 'n=name,m=FSK_PCM,s=30,l=30,r=200' g004_868.3M_1024k.cu8)
Both are very fast and contain a long payload, not TPMS and unlikely to be a weather sensor.
The 7-in-1 would be a 125 µs (8 kpbs) PCM signal. And it's not seen anywhere in the capture.
For reference, the 10 µs packets are:
-
{899}15555555550f5d0ab640996113312e11ee905cc8d786bb6c953277b06702661ddc3bca5c95b2351e8e36161cd58b478f0fcd0f001cbbad0023e690ae63e690ae5343170018fda3e690ae0287b641d7911c7c40ff0f1bf6a17a2673d69f126a7d7ea040abc3d1eaaf6692246d8f8500460 -
{898}6aaaaaaaaa1eaa89875b032b1c5d08c24620a941ced5ccf6c4b7fc85ea7387481dfa131c8880d4b72310ed076bfcfb1ad4a89e00143bda0047cd215cc7cd215c9f21ae001303c7cd215c690dbc9a40549118986934ea0add0f68fb2103f323ba2b51af6326d541245c68d822e39200880 -
{900}aaaaaaaaaa87a66c5ae8fa206ac6d0d3e22826c9e77aa6d0f62a8d0e80b67bdb958366e5c23f53adc6961edf3f9b65459741a78003c0168011f3485731f348572210cb80035511f348573cc2e92ca7af539a1c6c9c66ecb7d450588ac8875a43ce77f98e784f07b9c31da28e829980220 -
{900}8aaaaaaaaa87ae855b204cb089989708f7482e646bc35db64a993bd83381330eee1de52e4ad91a8f471b0b0e6ac5a3c787e687800e5dd68011f3485731f3485729a18b800c7ed1f348570143db20ebc88e3e207f878dfb50bd1339eb4f89353ebf502055e1e8f557b3491236c7c280220 -
{898}2aaaaaaaaa1eaa89875b032b1c5d08c24620a941ced5ccf6c4b7fc85ea7387481dfa131c8880d4b72310ed076bfcfb1ad4a89e00143bda0047cd215cc7cd215c9f21ae001303c7cd215c690dbc9a40549118986934ea0add0f68fb2103f323ba2b51af6326d541245c68d822e39200880 -
{902}feaaaaaaaaa1e99b16ba3e881ab1b434f88a09b279dea9b43d8aa343a02d9ef6e560d9b9708fd4eb71a587b7cfe6d95165d069e000f005a0047cd215cc7cd215c88432e000d5447cd215cf30ba4b29ebd4e6871b2719bb2df5141622b221d690f39dfe639e13c1ee70c768a3a0a6600880
The 30µs payload are:
-
{451}aaaaaaab32473244b6044b0ee95f6ab99c8f648dd41a7908be9fc15cef650de7ab9137696abe52edd291a4e2ba9f54443e943072669f79780 -
{426}aaaaaaab32473244b60485d16561412863b15378aaca9ab9757e4cd289321158b5e55ca9774fa70f557d88d51aaf2071d29b2dd2900 -
{448}aaaaaaab32473244b607fb69e16f6bdc64eb7c3885aa86930940b439692b72cf087bcae4cc41bcaa79ae74d4758eed4160754aec4b8950c0 -
{450}aaaaaaab32473244b6040bd1d315ad5914e96d59d6dc26a13f6435d3902cb488c3fdeeb27f37d4cbbdf7c5adcd1caca6c0d4705d43ebfdb00 -
{451}55555555992399225b02a6e5464e22a575cafef93a1188c942d5956d159db8948e1b65a646aef57729762b8ecf0d8ac32df624667fd285380
and seem regular and with a sync word of cc91 cc91
That should be Wireless M-Bus, Mode C&T, 100kbps for the 10 µs, and Wireless M-Bus, Mode S, 32.768kbps for the 30 µs.
interesting that there's soo many additional items, probably they are encrypted and therefore not detected and not reported to the MQTT Broker?
Since I do not have any Wireless M-Bus devices they must be from somewhere in the neighborhood.
And based on the capture it would mean the station is actually not sending, or the antenna is blocked from the signal?
Interestingly enough, after the dump ended, it came back just as normal.
If you can, grab a sample of the 7-in-1. It might be more towards the edge of the band and thus unreliable to detect. Perhaps -f 868.4M or so might work better. But it could also just be the AGC on the RTL-SDR that doesn't recover fast enough for faint signals between those very frequent strong signals.
New sample with 7-in-1: https://github.com/Thoro/rtl433-dumps/blob/master/file_868.3M_1024k_3.cu8.gz
I confirmed with the command from above, and it printed the 7-in-1 samples, haven't seen any 6-in-1 though.
Ah ok, I did find that in the original capture now. It's just slightly to faint because the strong signals drown out the hardware AGC and our autolevel.
Compare the files below in https://triq.org/pdv/
Also run rtl_433 -Y minlevel=-24 file_868.3M_1024k_2.cu8 to uncover the 7-in-1.
Your band looks perfectly noise-free, you might want to replace autolevel with a fixed lower level like that.
g005_868.3M_1024k.cu8.zip g117_868.3M_1024k.cu8.zip
Thanks for analyzing this! Absolutly not sure how to read the spectrogram .. - Does it mean the data is sent on 868.360 and 868.237 Mhz ?
I will try with -Y minlevel=-24 and see if it helps!
Will report back tomorrow if it happened again.
not sure how to read the spectrogram
just note that both shapes are the same and the second one is fainter ;) Nothing more to see there really, except that it's FSK, which means there are two Frequencies the carrier Shifts between to Key the data :)
Sadly it also happened again with -Y minlevel=-24.
Can I record samples, while also writing them to mqtt via -F ? Then I could record everything and pinpoint where the signal "cuts-out".
You can do that, but storage needed is 2 MB per second…
Pretty sure that we found the cause. The 7-in-1 signal is there but others around it are too strong.
Use -M level to keep an eye on the levels and go down to maybe -Y minlevel=-28
What's the idea regarding the -M level vs -Y minlevel ?
I have logs like this:
Aug 28 10:42:50 raspberrypi rtl_433[1868]: Current signal level -28.0 dB, estimated noise -33.0 dB Aug 28 10:50:20 raspberrypi rtl_433[1868]: Current signal level -28.8 dB, estimated noise -33.0 dB Aug 28 10:51:50 raspberrypi rtl_433[1868]: Current signal level -24.0 dB, estimated noise -32.6 dB Aug 28 10:53:00 raspberrypi rtl_433[1868]: Current signal level -19.4 dB, estimated noise -32.5 dB
Should I try to match the current signal level?
It's -Y autolevel vs Y minlevel=-N -- if autolevel works, as in the output above all is well. If the levels get too high despite the clear band then fix them at a lower level (somewhere like -24 to -28). The -M level will just show you the signal level (RSSI) with each transmission:
model : Bresser-7in1 id : 32070
...
RSSI : -21.1 dB SNR : 11.5 dB Noise : -32.6 dB
Sorry can't follow, the logs from above are with -Y minlevel=-24 and -Y level=-24
The noise level and estimated noise are always around -32.9 db (changes by +1).
Aug 28 11:01:50 raspberrypi rtl_433[7875]: Current noise level -32.9 dB, estimated noise -32.9 dB
Aug 28 12:08:00 raspberrypi rtl_433[7875]: Current noise level -33.2 dB, estimated noise -32.9 dB
Aug 28 12:13:20 raspberrypi rtl_433[7875]: Current noise level -33.2 dB, estimated noise -32.5 dB
I tried with -Y minlevel=-28 and had more frequent outages almost immediately.
Can I further limited the received frequencies? Based on the logs I would need 868.35 - 868.40 and 868.20 - 868.25
-Y level=N is not useful at all, don't use. The parameter is named -Y minlevel=N. Autolevel will set that and report, e.g. adjusting minimum detection level to -15.2 dB but you can just set a fixed level yourself (instead of autolevel). Set it too low and reception will suffer.
The -f 868.3M is already optimal.
Ok, removed the -Y level=N
Oh, okay:
Estimated noise level is -19.3 dB, adjusting minimum detection level to -16.3 dB
Estimated noise level is -21.0 dB, adjusting minimum detection level to -18.0 dB
Estimated noise level is -22.5 dB, adjusting minimum detection level to -19.5 dB
Estimated noise level is -23.8 dB, adjusting minimum detection level to -20.8 dB
Estimated noise level is -24.9 dB, adjusting minimum detection level to -21.9 dB
Estimated noise level is -26.7 dB, adjusting minimum detection level to -23.7 dB
Estimated noise level is -28.2 dB, adjusting minimum detection level to -25.2 dB
Estimated noise level is -29.3 dB, adjusting minimum detection level to -26.3 dB
Estimated noise level is -30.5 dB, adjusting minimum detection level to -27.5 dB
Estimated noise level is -31.5 dB, adjusting minimum detection level to -28.5 dB
Estimated noise level is -32.5 dB, adjusting minimum detection level to -29.5 dB
so that's the autolevel!
So setting it to -24 or so is way higher than autolevel would set it to.
I have made now an additional capture and listened at the same time to the mqtt topics.
The file is here: https://github.com/Thoro/rtl433-dumps/blob/master/file_868.3M_1024k_4.cu8.gz
Every 12 seconds I got a message from the 6-in-1 Bresser Pool Thermometer Every 60 seconds I got a message from the 6-in-1 Bresser Inside Thermometer
And there should be ever 12 seconds a message from the 7-in-1, but it was never logged!
I think the 7-in-1 would be at 58.2s, 70.2s, 83.2s
and the stronger 6-in-1 (pool) at 62.6s, 74.7s, 86.7s (still seen with -Y minlevel=-12 down to -34)
the slow 6-in-1 (indoor) at 79.3s, 139.37s (still seen with -Y minlevel=-13 down to -34)
Current settings are as following: RTL_433_OPTIONS= -f 868.3M -M level -M noise -s 1024k -Y minlevel=-24 -Y minmax -Y magest -F mqtt://127.0.0.1:1883
What's the status on this? Generally intermittent reception turns out to be not a bug, and collisions or noise.
