Both frequencies problem :-(

[radzik2024]

Hello,

my configuration is:
Platform: Windows 11
RTL_433: 24.10

I use RTL_433 by running in command line:

D:\_OpenHAB_RTL_433\rtl_433-rtlsdr.exe -f 433.92M -f 868.95M -s 1000k -H 40 -M time:iso -C si -F mqtt://127.0.0.1:1883,retain=0,devices=sensors/rtl_433/ID[id]_[channel]/

I needs to read both frequencies from my devices.

I observe that it reads all devices on 433.92M frequency without any problem - regularly reads and everything is ok, but in parallel it does not read devices on 868.95M frequency.

Devices on 868.95M certainly work and transmit data, but it is often the case that once the data flows regularly, and other times “occasionally” such as once every 2 hours, or every 20 minutes (there is no rule here).

Where is the problem, are my RTL_433 launch parameters incorrect? Is it a problem of RTL itself?

[AkaBoing]

hi radzik2024,
pls give us a hint: which sensor/meters on 868M ?
try with only 868Mhz:
rtl_433 -C si -M level -f 868.95M -s 1024k > 868M.log
for 5 mins or so and post the log here

[zuckschwerdt]

Good advice, try to read 868M only and see if that helps. It might be the demod then.
Also in almost all cases -Y autolevel will help and -M level -M noise is always good to watch.

[radzik2024]

This is a electrycity meter, but also tire pressure sensors in the car - everything works on 868.

Murphy's Law worked :-) I wrote the post and the data began to be read.

Give me a moment, if there is a period again where they will not be read, I will run only with 868 and let you know.

[zuckschwerdt]

It might be a problem with the demod. For 433.92M the default is -Y classic and for higher frequencies like 868M it's -Y minmax. Only a single demod is active, you can try to force -Y minmax (but 433.92M might suffer).

[radzik2024]

Thank you I will check also with this option.

[radzik2024]

The last few days everything works very well. I am beginning to suspect that something from the outside/neighborhood is interfering/jamming the 868 frequency periodically.

I'll keep an eye on the situation, but to not keep the topic open, I'm closing it, because it looks like it's not an RTL_433 software problem.