Reference handbook · BNC-HB-001 · Rev A

SDRs in the real-time spectrum analyzer field

Where software-defined radio and calibrated measurement meet, what each one gives up at the boundary, and how to work across it without losing the number.

Download the handbook (PDF, 42 pages) Read it in the browser Talk to an RF engineer

Software-defined radio and instrument-grade measurement grew up in different rooms. The open ecosystem gives an engineer every sample and no absolute reference; the instrument gives an absolute reference and, usually, no way in. This handbook is about the boundary between them.

It sets out what a software-defined receiver is and where its programmable edge falls, derives what real-time analysis guarantees that a swept receiver cannot, documents the SoapySDR hardware abstraction layer in enough detail to write acquisition code from, reviews the ICX-FieldHawk against seven requirements derived before any product is named, and then walks six signal chains built in GNU Radio against a calibrated front end. It closes with the practice, the troubleshooting and the quick reference a working engineer needs on the bench.

42 pagesFive parts, 26 sections, 20 figures and 22 tables, every one referenced from the text.

6 signal chainsAM, FM, QPSK, 16-QAM, Wi-Fi OFDM to a packet capture, and ADS-B, each drawn and given its full parameter set.

Every number checkableEach specification carries its measurement condition, and the derived figures show the arithmetic that produced them.

Honest limitsA verification note lists every value that is documented or demonstrated rather than published on a datasheet.

What is in it

Part I. The field

2. Why software-defined radio arrived in measurement
3. Anatomy of a software-defined receiver
4. What separates a reading from a measurement
5. Real-time analysis, and what gap-free actually guarantees
6. SoapySDR in depth
7. What the abstraction deliberately leaves out

Part II. The ICX-FieldHawk, reviewed

8. The family: form factors and frequency tiers
9. The front end and the published performance
10. The real-time engine
11. IQ capture, streaming and triggering
12. The measurement set, and what it costs
13. Reference and timing
14. Where this instrument is not the answer

Part III. Building on it: GNU Radio

15. How a flowgraph actually works
16. The source block, parameter by parameter
17. Getting the environment right
18. Six chains, drawn and explained
19. The arithmetic that has to close
20. Making a flowgraph produce a defensible number

Part IV. Applications

21. Ten applications, reviewed

Part V. Practice and reference

22. Measurement practice
23. Troubleshooting
24. Proving the amplitude path, and a reproducibility checklist
25. Quick reference
26. Definitions, symbols and further reading
1. **Let it warm up.** The published accuracy figures assume ten minutes. Measurements from a cold start are covered by no specification on any datasheet.
2. **Set the reference level deliberately.** Amplitude accuracy, intermodulation performance and displayed noise floor all move with it, and an automatic reference level during a comparison invalidates the comparison.
3. **Check the sample format before parsing an IQ file.** Interleaving order, component width and scaling silently corrupt an otherwise perfect capture.
4. **Choose the antenna before the analyzer.** The antenna factor has to be entered before any field-strength number means anything at all.
5. **Fix the cable and leave it fixed.** Loss in flexible assemblies runs to several decibels per meter at 40 GHz and changes when the cable moves, so swapping one mid-campaign is an uncalibrated step in the middle of the record.
6. **Record the resolution bandwidth with every noise figure.** A displayed average noise level per hertz becomes a real floor only after ten times the log of the bandwidth is added, and the two get confused constantly.
1. Lock the receiver and a calibrated source to a common reference.
2. Inject a continuous-wave tone at a known level, well inside the display range and at least 20 dB above the noise floor in the resolution bandwidth in use.
3. Read the level on the instrument's own display. Record it.
4. Read the same tone through the flowgraph, using a power measurement over a whole number of cycles, with device automatic gain control off and no scaling block in the path.
5. Compare. The two should agree inside the published amplitude accuracy bound for the band in use. If they do not, the fault is almost always a gain or reference-level setting that differs between the two paths, or a scaling constant left in the graph.
6. Repeat at three frequencies across the range in use and at two levels 20 dB apart, then record the six results as the campaign's amplitude evidence.
1. Instrument model and serial number.
2. Calibration date.
3. Ambient temperature, and warm-up elapsed before the first reading.
4. Center frequency, span and bandwidth.
5. Sample rate **as read back from the device**, not as requested.
6. Decimation, transform size, window and detector.
7. Reference level, attenuation and preamplifier state.
8. Device gain, and confirmation that automatic gain control was off.
9. Antenna, its antenna factor, and the cable assembly used.
10. Software versions: the abstraction layer, the framework, and every out-of-tree module.
11. Overflow events with timestamps, or an explicit statement that none occurred.
12. The amplitude-path result from the procedure above, with the date it was taken.

Who it is for

RF and systems engineers building measurement or monitoring systems on open software. Researchers and teaching staff who need a result that survives peer review rather than a demonstration. Product architects deciding how much of a receiver to build. Test engineers who already own an analyzer and want to reach the samples underneath it.

Download the handbook (PDF, 42 pages) Talk to an RF engineer about your application