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.

I’ve always enjoyed tinkering with operating systems and finding ways they improve day-to-day life. I’m not a cloud hater. Cloud services are useful and I still use them. I self-host because it’s fun.

With most SaaS tools, you’re limited by design choices you had no part in. My biggest self-hosted system is a Plex machine. I watch what I want, how I want, for roughly the cost of electricity. There’s also been a serious learning component: networking, security, general IT practice. That alone has made it worth running.

Topology

Starting at the internet edge and working inward:

Router / Firewall I settled on OPNsense. It met and exceeded what I needed. The box runs intrusion detection, Unbound DNS, and a handful of other security-focused services.

Switching Traffic hits a 24-port unmanaged gigabit switch with SFP ports. Nothing exotic, but most ports are in use.

Flat Network The network is currently flat, so traffic flows directly to access points, servers, Raspberry Pis, NVR systems, gaming consoles, and everything else.

The topology is simple. The interesting part is what the devices are doing, not how complex the diagram looks.

Core Infrastructure

Alecto

Hardware

• Ryzen 7 1700X
• 1 TB NVMe
• 4 TB HDD
• GTX 1050 Ti

Nothing exotic, but it handles everything I need with around 85% idle time.

Software Ubuntu LTS as the host OS, Docker for everything else: media acquisition, media consumption, networking, local services, metrics, and automation.

Docker makes backing up and restoring critical services significantly easier, which is the main reason I keep everything containerised.

Services

Media Acquisition

The pipeline follows a simple request, acquire, process, library chain.

• Overseerr
• Prowlarr
• Sonarr / Radarr
• qBittorrent
• Deluge
• Unpackerr
• cross-seed

Prowlarr manages indexers. Private trackers have far less fake or malicious content than public ones, which matters later in the chain.

Sonarr and Radarr handle TV and movies. Quality profiles are simple: HD and 4K. That has covered everything so far. Both monitor RSS feeds from configured indexers and push matched torrents to the downloader automatically.

I run two download clients. qBittorrent handles the entire arr stack. Deluge handles manual downloads and non-media content. Dynamic save paths split movies and TV cleanly for Plex.

Unpackerr handles automatic extraction for downloads that arrive as archives. cross-seed finds identical or near-identical torrents across trackers and advertises that I already have the data, which improves speeds and availability for others.

The only recurring issue is Sonarr or Radarr occasionally grabbing a fake title. Aggressive regex-based filters have mostly resolved it.

Media Consumption

• Plex
• Tautulli
• Overseerr
• Homepage

Plex is the primary player. Mature, stable, available on every device, and accessible for non-technical users. I’ve tested Jellyfin and like it, but haven’t switched.

Tautulli gives visibility into Plex usage: playback activity, per-user bandwidth, transcoding load. That data makes decisions around limits and capacity easier.

Overseerr lets users request titles themselves rather than messaging me. Requests still require approval, but that takes seconds instead of a back-and-forth conversation.

Homepage is a single customisable dashboard with a high-level view of everything running. It doesn’t replace Zabbix or Grafana for monitoring, but it’s useful for day-to-day glancing.

Networking and VPN Containment

Torrent clients are routed through Gluetun, a dedicated VPN container running WireGuard. The downloaders have never touched my LAN directly and never see my public IP.

Gluetun runs in strict kill-switch mode. If the VPN drops, traffic stops. There’s no fallback to my home connection. Given the provider’s SLA, this hasn’t been an issue in practice.

No inbound ports need to be open, which reduces exposure further. Speed degradation from the VPN hasn’t been noticeable.

Observability

Prometheus, Node Exporter, cAdvisor, and Grafana cover system-level metrics: CPU load, memory usage, container behaviour. Critical alerts go to Telegram. I’m refining thresholds so only actionable issues send a notification.

Automation

Watchtower handles container updates on a schedule at 03:00. If an update breaks something, rolling back means redeploying from the same configuration paths. Docker’s stateless container model makes that straightforward.

Portainer handles anything that needs a UI.

Network Edge

OPNsense

OPNsense sits between the internet and all internal systems. UPnP is disabled. No device exposes itself automatically. Only explicitly required services are permitted outbound or inbound.

All traffic is statefully inspected. DNS is forced through Unbound. Suricata monitors inbound and outbound traffic for known malicious patterns. Devices can’t quietly phone home, bypass DNS filtering, or accept unsolicited inbound connections without generating an alert.

Services get published deliberately, not accidentally exposed.

Boreas

A Raspberry Pi running Nginx Proxy Manager and WireGuard. This started as a workaround for a previous router that lacked VPN support. After moving to OPNsense, the separation made enough sense to keep.

Boreas is my remote access point back into the LAN. Nginx Proxy Manager exposes Overseerr to friends and family outside the local network. Both services sit behind Cloudflare, primarily to obscure my real IP.

The throughput on the Pi is better than you’d expect for the hardware.

Chronos

A Tor middle relay running as a small contribution to online privacy. No exit node: the ISP complaints and CAPTCHA overhead aren’t worth it. A middle relay provides value without the operational noise. It’s low-maintenance and largely invisible once configured.

Failures and Lessons

In the past year, two things actually broke:

• Disks filled up from log spam. Entirely my fault. Log rotation is properly configured now.
• Incorrect or fake titles downloaded. Better filters and denied extension lists resolved most of it.

Beyond that, issues have been minor misconfigurations and occasional reboots.

What I’d Do Differently

I’d spread services across more hosts if I could go back. Some hardening measures were probably over-engineered, but I don’t regret that trade-off. Deploying the arr stack earlier would have saved time.

What’s Next

Hardware: managed switch, better access points, a more capable GPU for transcoding.

Monitoring: a consolidated Zabbix dashboard with proper alerting.

Networking: VLANs.

Self-hosted AI models aren’t on the list. Cloud tools cover what I need without the overhead.

Closing

Running this lab has mostly taught me patience. Getting multiple devices, containers, and services working together takes iteration. It’s improved my understanding of networking and containerised systems more than any course I’ve taken.

I keep running it because it’s fun and I learn from it. That’s enough reason.