I’ve started digging into RF, meaning anything noisy in the air that my SDR can see. This is a quick log of the first sessions using an RTL-SDR (cheap, RX-only) and a HackRF One (wider bandwidth, TX-capable, which stays off outside a legal setup).

This isn’t a decoding write-up. The goal for now is observation: watch the spectrum, log activity, and build something useful.

The kit

• RTL-SDR (RTL2832U + R820T): cheap receive, wide community support, good for learning.
• HackRF One: wider tuning range, bigger bandwidth, better lab potential.

Antennas matter more than most people want to admit. A random wire will pick something up, but it’ll also mislead you.

What I’m trying to do (v1)

Three things:

1. Scan a band, starting with the 433 MHz junk drawer
2. Log energy and activity over time to CSV
3. Watch live when a remote is pressed or something triggers

No demodulation, no protocol reversing yet. Just what’s alive and when.

RTL-SDR: first scans and the empty CSV problem

rtl_power is the right starting point for band surveys:

rtl_power -f 430M:440M:50k -i 1 -g 30 -e 15s /tmp/rtl_433_test.csv
head -n 3 /tmp/rtl_433_test.csv

Two things showed up immediately:

• Frequency hops, FFT bins, the tool doing its job.
• This line:

[R82XX] PLL not locked!

It looks bad. In practice it’s common with these dongles and the data is often usable anyway. If it looks broken, try adjusting the frequency range slightly, dropping the gain, swapping the USB port or cable, or ruling out power starvation.

The other thing: the numbers move even when you think nothing is happening. Your receiver sees something constantly. The job is separating signal from noise and logging it so you can compare runs over time.

HackRF: the access denied wall

hackrf_info

hackrf_open() failed: Access denied (insufficient permissions) (-1000)

Linux has the hardware, you don’t. Fix it with udev rules.

The fix

Add yourself to the plugdev group:

sudo usermod -aG plugdev $USER
# log out and back in after this

Check whether HackRF udev rules exist for your distro. If not, create them:

sudo nano /etc/udev/rules.d/53-hackrf.rules

Rule:

SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", MODE="0666"

Reload:

sudo udevadm control --reload-rules
sudo udevadm trigger

After that, hackrf_info works.

Driver detach and reattach noise

RTL tools print this during normal operation:

Detached kernel driver
...
Reattached kernel driver

The SDR tooling takes temporary ownership of the USB device. It becomes a problem when another service grabs the device at the same time, or when you switch tools quickly and the reattach doesn’t complete cleanly. Unplug and replug is a valid fix.

Current workflow

1. Quick band scan

Pick a known band, collect a short sample, inspect.

rtl_power -f 430M:440M:50k -i 1 -g 30 -e 60s ./rf_433_1min.csv

2. Trigger devices while logging

Press a remote, ring a doorbell, whatever you own and are allowed to test. Watch what shows up.

3. Passive logger

A script that samples a band, writes a CSV row with timestamp and strongest bins, and repeats for hours or days. The goal is trend visibility: activity spikes at these times, at these frequencies.

4. Long runs in screen

screen -S rfwatch
# run your loop / script
# detach: Ctrl+A then D
screen -r rfwatch

Lessons from the first two hours

• Antenna placement matters more than gain settings. Move it 30cm and signal becomes noise.
• Gain is not volume. Too much gain makes every bin look busy and kills your ability to compare runs.
• 433 MHz is crowded. Good for learning, bad for clean data.
• A CSV you can graph beats ten live waterfall sessions.
• Fix udev permissions before you need them, not during a session.

RTL-SDR vs HackRF

RTL-SDR: default always-on receiver. Cheap enough to leave plugged in and logging. Good for band surveys and learning.

HackRF One: used for broader coverage and lab work. TX stays off unless the environment is controlled and the use is legal.

What’s next

• A 24-hour monitor for 433 MHz, then other bands
• Lightweight analysis: top active frequencies, time-of-day patterns, spikes worth investigating
• Mapping RF fingerprints in the environment: gates, remotes, alarms, sensors. What’s constant vs what’s event-driven.

Legal

I’m monitoring what I’m allowed to monitor, on equipment I own, in environments where I have permission. RF gets murky fast if you treat it like network recon without thinking about it first.