Trying to understand rtl_433 frequency behavior

[Josh Taillon]

I'm a bit new to the RTL-SDR world, so apologies if I get any terminology wrong or am missing something obvious. I believe I'm observing some odd behavior, and I'm trying to understand what I'm seeing, so I'm hoping someone can either explain, or point me to some resources that might help.

I'm using a RTL-SDR Blog v3 dongle with rtl_433 to read from a few various RF sensors around my home (gas and electric meters (912-915M), soil moisture monitor (915M), and some Accurite thermometers (433M)).

As I understand it, the -f flag for rtl_433 sets the center frequency, while the -s flag sets the sample rate, which together define the range of frequencies monitored. My confusion comes from running rtl_433 at different frequencies, but seeing data from the same devices at those different (non-overlapping) frequency ranges.

For example, if I run the following:

$ rtl_433 -f 910M -f 911M -f 912M -f 913M -f 914M -f 915M -f 916M -f917M -s 2048k -H 60

I would expect that each of the ranges would be 908 to 912MHz, 909 to 913 MHz, and so on. However, if I look for one meter in particular (ID: 1519177), I see it showing up at all but one scan in the range, including 915M, 912M, 913M, 917M, 910M, 911M, 914M, and 912M. Assuming my gas meter is not jumping around in its transmission, I assume this means the RTL-SDR dongle isn't actually changing receiving frequency, although rtl_433 is reporting something like this every time it switches:

center_frequency: 916000000                        frequencies: 910000000, 911000000, 912000000, 913000000, 914000000, 915000000, 916000000, 917000000                   hop_times : 60
Allocating 15 zero-copy buffers
Failed to allocate zero-copy buffer for transfer 10
Falling back to buffers in userspace
Allocating 15 (non-zero-copy) user-space buffers

The range at 910M should definitely not overlap the one at 917M, yet the same meter is decoded from both ranges. Can anyone help me understand what's happening here? If I save some outputs using the -S option, the ranges match what rtl_433 is reporting, making it look like the transmissions for the same meter are happening at different frequencies depending on when I observe them (how very Schrödinger...).

Thanks,

Josh

[Christian Z.]

You are basically correct. With real sampling the frequency range would be half of the sampling rate (Nyquist sampling theorem), but here with complex I/Q sampling we get the full sample rate as range. For e.g. 2M rate this is center -1M to center +1M.

There was a bug concerning the printed device frequency -- make sure to use the latest git version. There might also be some overlap or confusion when a device is received exactly when switching the center frequency -- no good way to tell if the signal was received at the old or new frequency.

Use the verbose " -v " option to see messages about the actual hopping.

[Josh Taillon]

Thanks, Christian. I was previously using:

rtl_433 version -128-NOTFOUND branch master at 202211192216 inputs file rtl_tcp RTL-SDR SoapySDR with TLS

I've updated to the newest git version:

rtl_433 version nightly-30-g1bb6942e branch master at 202304211400 inputs file rtl_tcp RTL-SDR SoapySDR with TLS

and performed the same sweep with the -vvv option. Between hops, I saw output such as:

[SDR] rtlsdr_set_center_freq 913000000 = 0
[SDR] Tuned to 913.000MHz.

But no further details (aside from lots of output that looks like it has to do with the signal decoders). I noticed the same behavior of seeing the same meter (ID: 1519177) at different frequencies, and saved the captures. I've attached examples from the same meter ID detected at 910MHz, 911MHz, 915MHz, and 917MHz during 60 second hops on each frequency from 910 to 917 MHz.

- Josh

[Benjamin Larsson]

There are devices that hop frequencies. If you post a decode line we can determine if that is the case. But most likely this is buffer association bug in the frequency hop code.

MvH
Benjamin Larsson

21 apr. 2023 21:51:50 Josh Taillon <jat...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/1e2a1b3f-1b6d-45ce-bca0-d1da863b0878n%40googlegroups.com.

[Josh Taillon]

> If you post a decode line

Apologies for being a beginner with all this... how would I obtain a decode line?

[Benjamin Larsson]

I mean one of the json decode lines. It will tell what protocol is used.

MvH
Benjamin Larsson

21 apr. 2023 23:06:45 Josh Taillon <jat...@gmail.com>:

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/53c08ab9-8cd8-4cc0-8dda-ba9f91da6bd6n%40googlegroups.com.

[Josh Taillon]

Oh gotcha, sorry for being dense!

This is the gas meter I'm trying to track (the one I attached the .cu8 files for previously):

{"time" : "2023-04-21 15:00:40", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC"}
{"time" : "2023-04-21 15:01:10", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC"}

{"time" : "2023-04-21 15:01:26", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC"}

{"time" : "2023-04-21 15:04:55", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC"}

And then this is the electric meter:

{"time" : "2023-04-21 14:59:21", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924451, "Tamper" : "0x0200", "PacketCRC" : "0x28D6", "MeterType" : "Electric", "mic" : "CRC"}

{"time" : "2023-04-21 15:00:22", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924443, "Tamper" : "0x0200", "PacketCRC" : "0x44D2", "MeterType" : "Electric", "mic" : "CRC"}

{"time" : "2023-04-21 15:02:22", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924442, "Tamper" : "0x0200", "PacketCRC" : "0x73E2", "MeterType" : "Electric", "mic" : "CRC"}

For completeness, this is the soil monitor I'm trying to monitor as well:

{"time" : "2023-04-21 13:52:29", "model" : "Fineoffset-WH51", "id" : "0d5b42", "battery_ok" : 1.000, "battery_mV" : 1600, "moisture" : 34, "boost" : 0, "ad_raw" : 195, "mic" : "CRC"}

Since I only have one RTL-SDR dongle, I was hoping to accomplish this using the hopping feature of rtl_433 (understanding that of course I'll miss some broadcasts if I'm not listening to the correct freq at the time it's broadcast).

[Christian Z.]

The 22.11 version you used earlier does not have the frequency misreporting bug. And the current version is okay too.

It's strange that we see the signal in all those bands. But it is also a very strong signal, it might be aliasing -- so no matter what frequency you always hear a "ghost" of that signal.

It would need to be a very strong signal and bad antenna though. But official consumption meters have a good chance of using hopping -- Benjamin knows more about that.

Just run rtl_433 as you do and add " -M level " to show the frequency, then post a longer log.

[Benjamin Larsson]

https://en.m.wikipedia.org/wiki/Encoder_receiver_transmitter

This page says that it frequency hops.

MvH
Benjamin Larsson

21 apr. 2023 23:28:46 Christian Z. <chri...@zuckschwerdt.org>:

--

You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/8522e613-3a9d-4e7e-a5a1-b33b3dd2dbe8n%40googlegroups.com.

[Josh Taillon]

Okay, now I'm beginning to understand a little bit more, I think. The meters do indeed change their transmission frequency. To confirm this is what I was seeing, I manually ran each frequency for two minutes (to hopefully eliminate any issues with the hopping code, if any) via calls such as the following:

$ rtl_433 -M level -T 120 -f 911M -s 2048k -F kv -F json:log.911.json -v -S known

Grepping through the output of manually sweeping from 910MHz to 917MHz, I see the following for the gas meter:

$ grep '1519177' log.91*.json
log.911.json:{"time" : "2023-04-21 15:48:55", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 910.639, "rssi" : -0.115, "snr" : 23.704, "noise" : -23.819}
log.911.json:{"time" : "2023-04-21 15:49:10", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 910.156, "rssi" : -4.729, "snr" : 19.634, "noise" : -24.363}
log.911.json:{"time" : "2023-04-21 15:49:56", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 911.383, "rssi" : -0.121, "snr" : 22.628, "noise" : -22.749}
log.912.json:{"time" : "2023-04-21 15:32:25", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 911.857, "rssi" : -0.120, "snr" : 22.886, "noise" : -23.006}
log.912.json:{"time" : "2023-04-21 15:32:56", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 911.657, "rssi" : -0.111, "snr" : 21.863, "noise" : -21.974}
log.912.json:{"time" : "2023-04-21 15:33:11", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 912.598, "rssi" : -0.139, "snr" : 23.432, "noise" : -23.571}
log.912.json:{"time" : "2023-04-21 15:33:25", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 911.283, "rssi" : -0.116, "snr" : 23.108, "noise" : -23.223}
log.913.json:{"time" : "2023-04-21 15:34:41", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 913.181, "rssi" : -0.137, "snr" : 24.298, "noise" : -24.436}
log.913.json:{"time" : "2023-04-21 15:35:55", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 913.751, "rssi" : -0.198, "snr" : 22.551, "noise" : -22.749}
log.914.json:{"time" : "2023-04-21 15:38:10", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 914.422, "rssi" : -0.132, "snr" : 21.444, "noise" : -21.575}
log.914.json:{"time" : "2023-04-21 15:38:40", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 914.630, "rssi" : -0.114, "snr" : 24.107, "noise" : -24.220}
log.914.json:{"time" : "2023-04-21 15:38:56", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 913.697, "rssi" : -0.116, "snr" : 20.210, "noise" : -20.326}
log.915.json:{"time" : "2023-04-21 15:41:10", "model" : "ERT-SCM", "id" : 1519177, "physical_tamper" : 1, "ert_type" : 12, "encoder_tamper" : 0, "consumption_data" : 21478, "mic" : "CRC", "mod" : "ASK", "freq" : 914.266, "rssi" : -0.106, "snr" : 22.643, "noise" : -22.749}

And the following for the electric:

$ grep -E '1552329929' log.91*.json
log.911.json:{"time" : "2023-04-21 15:49:32", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924355, "Tamper" : "0x0200", "PacketCRC" : "0xFE53", "MeterType" : "Electric", "mic" : "CRC", "mod" : "ASK", "freq" : 911.622, "rssi" : -0.110, "snr" : 22.396, "noise" : -22.506}
log.912.json:{"time" : "2023-04-21 15:33:27", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924410, "Tamper" : "0x0200", "PacketCRC" : "0xA567", "MeterType" : "Electric", "mic" : "CRC", "mod" : "ASK", "freq" : 912.029, "rssi" : -0.104, "snr" : 22.645, "noise" : -22.749}
log.913.json:{"time" : "2023-04-21 15:34:31", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924410, "Tamper" : "0x0200", "PacketCRC" : "0xA567", "MeterType" : "Electric", "mic" : "CRC", "mod" : "ASK", "freq" : 913.212, "rssi" : -0.119, "snr" : 21.456, "noise" : -21.575}
log.916.json:{"time" : "2023-04-21 15:42:01", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924382, "Tamper" : "0x0200", "PacketCRC" : "0xFF61", "MeterType" : "Electric", "mic" : "CRC", "mod" : "ASK", "freq" : 916.216, "rssi" : -0.103, "snr" : 21.667, "noise" : -21.770}
log.917.json:{"time" : "2023-04-21 15:44:01", "model" : "SCMplus", "id" : 1552329929, "ProtocolID" : "0x1E", "EndpointType" : "0x07", "EndpointID" : 1552329929, "Consumption" : 924373, "Tamper" : "0x0200", "PacketCRC" : "0x0F90", "MeterType" : "Electric", "mic" : "CRC", "mod" : "ASK", "freq" : 917.211, "rssi" : -0.111, "snr" : 22.077, "noise" : -22.188}

So the frequencies definitely do move around, which explains why I was sometimes seeing them and sometimes not at certain frequencies.

I think I would consider this solved as the original mystery now makes sense.

As a follow up question, is there any "rule of thumb" for picking the best sampling rate for a given situation? I have just sort of been picking it at random, currently.

[Benjamin Larsson]

On 21/04/2023 23:56, Josh Taillon wrote:
>
> As a follow up question, is there any "rule of thumb" for picking the
> best sampling rate for a given situation? I have just sort of been
> picking it at random, currently.
>

Well the demodulation code is generic so it can handle signals in a
large frequency range. But it can only handle one signal at a time. If 2
signals overlap it will most likely fail to decode. With a larger sample
rate the frequency range is also larger. The larger frequency range the
higher chance of signal overlap.

So it all depends on what signals are transmitted in the neighboring
bands. So best is a bit of trial and error and then just select
something that happened to work.

MvH
Benjamin Larsson