All messages seem to be corrupted (not fully parsable)

[iphands]

Hi folks, I used rtl_433 a long while ago to get weather data in my neighborhood and it worked very well. Today I am trying to use rtl_433 again but running into issues. As far as I can tell rtl_433 is trying to parse data its seeing but always seems to have some error parsing.

See script, logs, and cu8 captures here: https://drive.google.com/file/d/1zNTG4E4vsv2ygcsT9V3Eb3eNP7Z-KX1S/view?usp=sharing

I tried various gain levels (and 0) but alas I can never fully decode a message. In the scripted run I have digital_agc=true on all gain levels, but I find that does not make a difference.

Is this a pebcak (problem exists between chair and keyboard) issue? I was wondering if my SDR itself is going bad... though it does pick up FM and 850 Mhz signals just fine.

Anything else I can/should try? Cheers!

[iphands]

Oof I bought another device just in case, but same results. Nooelec NESDR SMArt v5 and RTL-SDR Blog v3 have same results :(

[gvanem]

A 470 MByte d/l just for this!? But it seems to be a SoapySDR issue. Does soapysdrutil --info=driver=rtlsdr or soapysdrutil --watch=driver=rtlsdr --rate=2E6 work?

Try a RTLSDR directly if you can (SoapySDR is a load of crap).

[iphands]

Try a RTLSDR directly if you can (SoapySDR is a load of crap)

But how :D Does simply specifying -d 0 instead of -d driver=rtlsdr bypass soapy lib?

[gvanem]

Does simply specifying -d 0

Yes. But I'm on Windows and this is how I run it (via a rtl_433_test.bat-file):

rtl_433.exe -c %~dp0\rtl_433.conf -f 434.00M -s 1M -g 40 -d0 -M protocol -M time:usec

Showing:

[iphands]

Even with -d 0 instead of -d driver=rtlsdr I still get errors decoding all detected pulse streams

Protocols] Registered 220 out of 253 device decoding protocols
[Input] The internals of input handling changed, read about and report problems on PR #1978
[SDR] Found 1 device(s)
[SDR] trying device 0: Nooelec, NESDR SMArt v5, SN: 00000001
Found Rafael Micro R820T tuner
[SDR] Using device 0: Nooelec, NESDR SMArt v5, SN: 00000001, "Generic RTL2832U OEM"
[R82XX] PLL not locked!
[SDR] Sample rate set to 1024000 S/s.
[Input] Bit detection level set to 0.0 (Auto).
[SDR] Tuner gain set to 40.200000 dB.
[Input] Reading samples in async mode...
[SDR] Tuned to 915.000MHz.
Allocating 15 zero-copy buffers
[Baseband] low pass filter for 1024000 Hz at cutoff 204800 Hz, 4.9 us
[fineoffset_WH25_callback] short package. Header index: 677
codes     : {653}f33366666649999999999999980000ffffff0ccc33333f01c3cc0cc330c00c3cfffccc0f3c0ce1801879fff9870f33f03300cfe0181e60006000060780c03f0cf00199e0199fe18798180061879e19e19f80
[fineoffset_WH51_callback] short package. Header index: 677
codes     : {653}f33366666649999999999999980000ffffff0ccc33333f01c3cc0cc330c00c3cfffccc0f3c0ce1801879fff9870f33f03300cfe0181e60006000060780c03f0cf00199e0199fe18798180061879e19e19f80
[fineoffset_wh1080_callback] short package. Header index: 677
codes     : {653}f33366666649999999999999980000ffffff0ccc33333f01c3cc0cc330c00c3cfffccc0f3c0ce1801879fff9870f33f03300cfe0181e60006000060780c03f0cf00199e0199fe18798180061879e19e19f80
[lacrosse_breezepro_decode] Sync word not found
[lacrosse_wr1_decode] Packet too long: 326 bits
[lacrosse_th_decode] Packet too long: 326 bits
[lacrosse_r1_decode] Packet too long: 326 bits
[honeywell_cm921_decode]
codes     : {1320}ff0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0000000000ffffffffffff00f0f0f01e1e1e1e1ffe000fe01fe1e001e1e01e1e01e00001e01fe1ffffffe1e1e001fe1fe001e1fc03c00003c03fc3ffffffc3c03fc03fc3c3ffc003c3c0003c3fffc0003c003fc3c000000780000000078007f8000780007ff80787f800000f0f0ff0000f0f0ffff00f00ff0f000f000000f00f00ff0ff00f0ff00f0fff00
[honeywell_cm921_decode] preamble_start=1320 start=1350 len=-30
[fineoffset_WH25_callback] short package. Header index: 693

Tried a few different gain levels and auto

$ rtl_433 -vv -d 0 -s 1024k -g 40 -M protocol -M level -f 915M
$ rtl_433 -vv -d 0 -s 1024k -M protocol -M level -f 915M
$ rtl_433 -vv -d 0 -Y autolevel -s 1024k -M protocol -M level -f 915M
$ rtl_433 -vv -d 0 -Y autolevel -t digital_agc=true -s 1024k -M protocol -M level -f 915M

No luck

[iphands]

Devised a new test.... Running two devices in two separated parts of the house hopping channels and gain levels... then looking for decoded data later.

They have different channel hop times so hopefully they will be looking at different bands most of the time (observe more).

On the Pi:

mkdir -p ~/rtl
for var in 0 `seq 24 40`
do
  sleep 1
  rtl_433 -vv \
    -d 0 \
    -s 1024k \
    -t digital_agc=true \
    -Y autolevel \
    -M protocol \
    -M level \
    -M noise \
    -f 433M -f 315M -f 868M -f 915M -H 20 \
    -g $var \
    -T 120 2>&1 | tee -a ~/rtl/test.${var}.log
done

On the laptop:

for var in 0 `seq 30 40`
do
  sleep 1
  rtl_433 -vv \
    -d 0 \
    -s 1024k \
    -t digital_agc=true \
    -Y autolevel \
    -M protocol \
    -M level \
    -M noise \
    -f 433M -f 315M -f 868M -f 915M -H 30 \
    -g $var \
    -T 120 2>&1 | tee -a rtl/test.${var}.log
done

[iphands]

This all feels like overkill though I swear I used to just fire up rtl_433 with no args and shit "just worked :tm: " I'll see what the test results are after a few hours though.

[zuckschwerdt]

I'm not sure digital_agc is helpful, it will not improve levels, just shift them. But the long recordings you posted look good. The "30" has nice levels. Try it on https://triq.org/spectrogram-next/ and zoom in to see that the messages look good. Strangely nothing decodes. What sensor types should be /would you expect in those recordings?

[iphands]

I finally got some hits! Ford TPMS sensors in the 315Mhz area.

What sensor types should be /would you expect in those recordings?

I reeaaaallllly want to decode some of the existing weather devices in my area. Last year or so I had done so with great success. Im going to keep trying, but would love to chat with some expert. Github issues might not be the best forum... let me know if it isnt.

I'm not sure digital_agc is helpful

Now that you say this it makes sense. Its like cropping/zooming on an already capture digital photo eh? No more real bits to utilize, just zooming in on what is left... that kinda thing eh?

"30" has nice levels. Strangely nothing decodes.

In my longer term loop over gain levels I think I see that the low 30's are the only gains that have produced anything for me.

 ~/rtl] rg ^time
test.33.log
284:time      : 2024-03-10 16:47:52
319:time      : 2024-03-10 16:47:52
354:time      : 2024-03-10 16:47:52
389:time      : 2024-03-10 16:47:52

test.32.log
352:time      : 2024-03-10 16:45:58
990:time      : 2024-03-10 17:10:26
1025:time      : 2024-03-10 17:10:26
1060:time      : 2024-03-10 17:10:26

bak/test.30.log
661:time      : 2024-03-10 09:31:39
701:time      : 2024-03-10 09:31:40

So I think that low 30s might be the sweet spot for my device.

Any and all advice you can share please do! n00b here with a strong desire to decode all the things! :D

[iphands]

Closing!

I finally started picking up weather stations that I had seen nearby. It took a ton of testing though... Perhaps an RFE or helper script could be added to assist folks.

I used this as a brute force approach:

#!/bin/bash

mkdir -p ~/rtl

while true
do
  for chan in `seq 432 435`  `seq 912 916`
  do
    for gain in 0 `seq 30 48`
    do
      sleep 1
      rtl_433 -v \
        -d 0 \
        -s 2048k \
        -Y autolevel -Y minlevel=-30 -Y magest \
        -M protocol -M level -M noise \
        -g $gain \
        -f "${chan}M" \
        -T 90 2>&1 | tee -a ~/rtl/test.gain.$gain.freq.$chan.log
    done
  done
done

And eventually I found the perfect center, and gain to use to read all the things! @zuckschwerdt thanks for helping! and for all the rtl_443 contributions!

[zuckschwerdt]

Great to hear that it works! It usually works with just the defaults. Perhaps you had some interference to tune away from?