Start with a receiver.
Finish with evidence.
A capable RF lab is not the one with the most expensive radio. It is the one where you can explain what changed, reproduce it, and say what the result does not prove.
Part 1 mapped the attack surface. Part 2 examined the physics behind a capture. Now we build a practical receive-side workflow: choose suitable hardware or an offline sample, configure one application, observe a baseline, and preserve the context needed to revisit it.
The main hardware example is an RTL-SDR-style receiver. Exact capabilities, menus, drivers, and supported sample rates vary by model and software version. These browser exercises are synthetic planning tools; they do not detect devices, install drivers, receive radio, or transmit.
Receive-only is enough to start learning. It reduces interference risk, but it does not remove legal, privacy, equipment, or authorization requirements.
- Choose a simple, compatible receive-side setup
- Recognize gain, metadata, and configuration traps
- Plan storage and troubleshoot methodically
- Save an experiment another researcher can repeat
A small lab. A clear purpose.
A basic lab has an antenna, a receiver, a computer, and an application. The antenna couples RF energy into the front end; the receiver presents digital samples; software filters, visualizes, or demodulates those samples where supported. Your notes turn an interesting display into a reproducible observation.
The receiver
Its tuning range, filters, clock, usable bandwidth, and converter limits determine what can be captured. A software setting cannot create a hardware capability.
The antenna
Frequency, connector, polarization, placement, and nearby objects affect reception. Keep it fixed while establishing the software baseline.
The computer
A stable USB connection, sufficient processing, and sustained storage throughput matter. Nominal specifications do not guarantee loss-free recording.
The recording
A lawful, well-described I/Q sample lets you process the same data again without receiving or transmitting anything new.
Choose a receiver, not a complication.
RTL-SDR devices are common receive-only entry points, but the label is not a full specification. Confirm the exact model, chipset, connector, supported range, clock behavior, driver, and application backend before buying or changing a setup.
| Decision | Check first | Keep in mind |
|---|---|---|
| Receiver | Exact model and supported band/rate | “RTL-SDR” does not guarantee identical capabilities. |
| Antenna | Band, connector, passive/active requirements | No single supplied whip is ideal for every frequency. |
| USB | Stable direct port and exclusive access | Hubs, competing applications, and local noise can complicate diagnosis. |
| Computer | CPU load, available storage, sustained writes | A recording can drop samples even when there is plenty of free space. |
Transceiver capability is not transmission permission.
HackRF One is a half-duplex transceiver within its specified capabilities. That makes it useful for other scoped work, but adds legal and operational responsibilities. This chapter remains receive-only. You do not need an active transmitter to learn its lessons.
Start with a suitable passive antenna and a stable USB port. Avoid changing antenna, cable, driver, application, and gain at the same time: if the result changes, you will not know which variable mattered.
One application. A known baseline.
Choose one compatible receiver application first. SDR++ is a common option for spectrum and waterfall observation. GNU Radio is useful for explicit signal-processing workflows. Universal Radio Hacker supports inspection of certain signals and protocol structures; it is not an automatic decoder for every transmission.
Download from official projects. Follow the documentation for your exact operating system, receiver, and version. If a device is missing, check detection, permissions, backend support, and exclusive access before assuming it is defective.
A local planning checklist, not hardware detection, permission, or a safety certification. Offline work needs no receiver driver. This browser never powers an antenna, changes a driver, or transmits.
Bias tee deserves its own check.
A bias tee can inject DC through an RF connector to power compatible active accessories. That setting is not a general “improve reception” switch. Leave it disabled for a basic passive antenna unless the manufacturer explicitly requires otherwise. Wrong power assumptions can damage connected equipment.
Know what each control changes.
- 01Tuning and view span
- Tuning selects a center region. The receiver captures only a limited span, and the displayed zoom is not necessarily the complete captured bandwidth.
- 02Sample rate and filter
- Use a supported rate and a suitable filter. A nominal rate does not guarantee the same amount of clean usable bandwidth or that the computer can sustain it.
- 03Receiver gain
- Amplification changes signal and noise levels and can overload the receive chain. More gain is not always more usable information.
- 04DC and frequency correction
- DC correction can reduce an artifact near the tuned center. Frequency correction compensates for oscillator error, often specified in ppm. Neither repairs a protocol security weakness.
A synthetic two-tone waveform and small deterministic background are amplified together, then limited at ±1. The dashed trace is the original input. This models digital clipping only—not a real front end, calibrated dBm, quantization, AGC, or reception quality. Linear gain does not magically improve the input SNR.
In the gain experiment, a stronger synthetic tone can push the amplified waveform beyond digital full scale even though the wanted component is relatively small. Reduce gain and compare. A real analog front end can overload before these digital samples are available; this simple clipping model does not represent every receiver limitation.
Observe, change, restore, repeat.
Use a permitted signal, a compliant purpose-built lab source, or a lawful sample recording. Record the setup before interpreting the display. Observe long enough to distinguish persistent energy from intermittent activity.
Short bursts from low-power devices are common in this region. Allocations and permitted uses vary by country. This is an unshifted, single-sided real-signal FFT whose bins are mapped onto illustrative RF labels, not a physical I/Q capture. Exact Hann coherent-gain normalization gives a unit-peak coherent real tone 0 dBFS; this is a tone-amplitude scale, not power spectral density or calibrated dBm. The synthetic background is deterministic, not a measured thermal-noise floor. No radio is received or transmitted.
- 01
Freeze the baseline.
Record the source, hardware/software versions, antenna arrangement, sample rate, filter, tuning, and gain. Keep the receiver conditions consistent.
- 02
Change one setting.
A small gain adjustment or visualization-scale change is a useful first comparison. Do not mix it with an antenna move and a different sample rate.
- 03
Restore and repeat.
Return to the baseline and see whether the earlier observation returns. If not, note what else might have changed rather than forcing a conclusion.
- 04
Bound the claim.
Describe energy, persistence, bursts, or a changed level. Identify the extra evidence needed before naming a protocol or claiming a vulnerability.
The spectrum above is synthetic and scaled in relative dBFS, not calibrated dBm. It receives no RF. A spectrum shows energy over frequency; a waterfall adds time. Neither view alone decodes a message or authenticates its source.
Keep the samples and their context.
I/Q files preserve sampled information so you can process the same capture repeatedly offline. That is valuable for repeatability, but only if the representation and relevant metadata are known.
Check complex I/Q versus real audio, sample rate, component precision, signedness, byte order, I/Q ordering, and any documented center frequency. A raw file may not contain these facts itself. Do not guess missing values until a waterfall looks convincing.
Raw complex samples include I and Q, in decimal MB/GB; no headers, compression, or filesystem overhead. The 20% storage reserve is a planning choice, not a streaming guarantee. Select rates supported by the actual receiver. The JSON checker uses a small teaching schema, not a complete file-format validator or SigMF implementation. No samples are recorded or uploaded.
A storage estimate is not a recording guarantee.
At 2 MS/s with 16-bit I and 16-bit Q, raw data requires 8 MB/s before headers and other overhead. A minute is about 480 MB in decimal units. Your USB path, CPU, buffers, filesystem, and sustained writes still need to keep up.
Preserve the source identifier, format, actual sample rate, relevant tuning metadata, settings, and any drop indicators. Keep unmodified originals where appropriate, and record analysis steps separately. A short documented file is more useful than a long mystery file.
When practical, preserve an unmodified acquisition file and record a cryptographic file hash, provenance, analysis-tool versions, and processing steps. A hash can help detect later file changes; it does not prove that the claimed source, permission, or interpretation is genuine. Never disable endpoint protection or operating-system security features merely to make a receiver appear.
Write a repeatable experiment.
Begin with a one-sentence objective. Name the source and authorization. State the baseline, the single change, what you observed, whether it repeated, and what remains uncertain.
Saved only in this browser, with an in-memory fallback when storage is blocked. Export before clearing browser data. Record only authorized observations; do not include secret keys, credentials, or unrelated private communications.
These Part 3 notes are separate from Part 2 and shared with this installment’s standalone lab. Treat browser storage as a convenience, not secure evidence storage or a backup. Export authorized notes and protect any real recordings according to the agreed handling rules.
“A similar burst appeared several times in the sample.”
“The captured data contains a repeating-looking pattern under these settings. This does not establish protocol identity, replay acceptance, or unauthorized control.”
Diagnose before you guess.
Work from the nearest observable failure. Is the device absent from the operating system, missing from the application, producing samples with little visible energy, or producing data the chosen decoder cannot interpret? Those are different starting points.
A missing device is not automatically broken hardware.
0 / 4 checks reviewed
A guided checklist, not automatic detection or a confirmed diagnosis. Use official documentation for your exact hardware and software. Do not invent file metadata, change unrelated drivers, or transmit to “test” whether a receiver works.
Use logs and known baselines rather than changing everything at once. If a proposed fix requires transmission, indiscriminate monitoring, unrelated driver replacement, or permission bypass, stop and redesign the experiment.
A boundary before a breakthrough.
Written scope identifies devices, locations, sources, techniques, time windows, evidence handling, stop conditions, and who can approve a change. Passive reception, recording, and redistribution can also be restricted by law, privacy obligations, or service rules.
Capture only what you are authorized to handle. Keep recordings secure, minimize unrelated data, and do not publish raw communications or sensitive operational details merely because they appeared on a receiver.
Build a lab another researcher can reproduce
Turn setup, storage, and troubleshooting into a controlled process rather than a collection of screenshots.
Case file: a receiver that is not listed
The application’s device list is empty. Before replacing drivers or buying new hardware, identify the nearest failure you can actually observe. Operating-system detection and application-backend access are not the same test.
- Physical and operating-system layer
- Check the exact device, direct USB connection, and operating system’s device list. A missing physical connection cannot be fixed by changing the spectrum scale.
- Application layer
- Confirm support for the exact receiver/backend, correct permissions, and whether another application holds exclusive access. Read logs instead of guessing at the cause.
- Change control
- Alter one variable and record the result. Follow official, model-specific instructions; do not replace unrelated USB interfaces or run an entire graphical application as root as a shortcut.
- A clean alternative
- Use a known synthetic source or lawful offline recording to separate learning the application from diagnosing the USB chain. That is a useful baseline, not a failed lab.
Troubleshoot from observable boundaries. A guided checklist is neither automatic hardware detection nor a confirmed diagnosis.
Worked example: can the recording actually fit?
Plan 2.4 million complex samples per second, with 16-bit I and 16-bit Q, for five minutes. Each complex sample needs four bytes, so the raw write rate is 9.6 MB/s and the planned data size is 2.88 GB in decimal units.
- Storage budget
- With 8 GB available and the planner’s chosen 20% reserve, the working budget is 6.4 GB. The 2.88 GB example fits that budget.
- A changed assumption
- With only 1 GB available, the budget is 0.8 GB and the same recording does not fit. Reduce duration/rate or provide suitable storage; do not ignore the warning.
- Throughput versus capacity
- Enough free space does not prove that USB, buffers, CPU, filesystem, and disk can sustain 9.6 MB/s without dropped samples. Review actual application indicators.
- The capture context
- Keep representation, sample rate, source/permission, tuning metadata where known, versions, settings, and dropped-sample information with the file. A large unlabeled file is not strong evidence.
Plan capacity, sustained throughput, and metadata separately. The browser calculator estimates bytes; it does not record, benchmark, or certify hardware.
Questions worth keeping beside the experiment.
Why leave the bias tee off at the start?
A bias tee injects DC into the RF connection. Receive-only operation does not make that DC harmless. For a basic passive antenna, leave it off unless the exact manufacturer’s instructions require compatible active equipment to be powered.
What makes an A/B comparison repeatable?
Write the baseline A, change only one variable for B, restore A, and compare the repeated observation. If A does not return, document environmental or system changes. A real setup may vary; do not force the result to match a preferred explanation.
Should unknown recording metadata be guessed?
No. A wrong sample rate or representation can produce a plausible-looking but misleading display. Recover trustworthy metadata from the source or record the uncertainty. An unknown center frequency is different from an invalid sample datatype or unusable rate.
Put the chapter to work.
Three controlled assignments connect the explanation to a repeatable observation. Record a prediction, change one variable, compare the result, and check the reasoning.
Build a receive-side preflight
Choose a legitimate offline or receive-only workflow and record the applicable checks.
Procedure
- Compare Offline samples with Receive-only SDR.
- For the receiver workflow, select the operating system and read the model-specific cautions.
- Record the source, bias-tee, device access, metadata, baseline, and stop-condition checks. Do not mark an unverified real check as done.
Expected observation
The offline workflow has five applicable checks and the receiver workflow has nine. Completing the browser checklist does not establish legal permission or actual hardware readiness.
Read the related chapterExperiment record
Predictions, observations, and answer-check progress stay in this browser. Export before clearing site data. Do not enter secret keys, credentials, or unrelated communications. Passing a check is a learning result, not a certification or real-world security finding.
Check the lab habits.
Three practical decisions to make before advanced analysis. Your Part 3 best score is stored separately from earlier installments.
Take the workflow with you.
A useful first lab produces more than an interesting display. It gives you a known source, a documented setup, a repeatable observation, and a carefully bounded conclusion. Those habits make later signal analysis and protocol validation more accurate and safer.
Observe first.
Keep the evidence clear.
Follow the official instructions.
Adapted and expanded from your Beyond the Wire — Part 3: Software-Defined Radio: Building Your First RF Security Lab manuscript. The planning tools and plots are synthetic teaching aids, not hardware measurements or a software installer. The unedited source is retained separately and downloadable below.
Original source archive201 source paragraphs retained separately.
The edited reading edition above includes the technical clarifications and corrections. This Word document is preserved as supplied for provenance; its wording, illustrations, code formatting, and external setup advice are not silently rewritten. Treat it as an unedited source archive, not a second corrected edition.
Download the original Word documentRead the pattern. Test the guess.
Signal analysis and modulation identification using controlled samples, clear evidence, and documented uncertainty.