5.3 GNU Radio 流图入门

5.3 GNU Radio 流图入门

本节摘要：本节在 GRC 里从零搭出最小可用的接收流图：SoapySDR Source 采集、Throttle 或硬件时钟定速、FFT 与频谱显示。重点讲清三个新手必踩的概念——源块与汇块的边界、采样率的全局一致性、变量与参数的联动——并给出"流图跑不通"的六条速查。

流图的语法：块、端口、类型

打开 GRC，界面分三块：右侧块库、中央画布、下方控制台。每个块有输入输出端口，端口旁的小数字标注数据类型——complex 是青色、float 是橙色、byte 是紫色。连线的规则只有一条：类型必须一致，GRC 会拒绝异色端口相连，并在生成时报类型错误。这个约束值得感激而非抱怨：它把"样本流语义"编码进了连接本身，错误连接在画布阶段就暴露。

块的执行模型值得用一句话记住：调度器反复调用每个块的 work 函数，喂输入缓冲、收输出缓冲。你拖的每个块都是第 4 章手写循环的一个泛化版本——比如 Multiply Const 块就是 x * k，Low Pass Filter 块就是 firwin 加 lfilter 的工程封装。流图不是魔法，是标准件。

第一个流图：实时频谱仪

按下面的清单拖块连线，五分钟得到一台实时频谱仪：

1. SoapySDR Source（右键搜索 soapy）：Device 参数填 driver=rtlsdr；Sample Rate 设 samp_rate 变量；Frequency 设 98e6；Gain Mode 改 Manual，Gain 设 30。输出端口 complex。
2. Variable（默认已有）：id 改为 samp_rate，值 2048000。所有用到采样率的地方都引用这个变量——单一真相源。
3. Frequency Xlating FIR Filter：可选，用于把中心移偏后的信号拉回零频；入门阶段先不用，保持信号居中即可。
4. QT GUI Frequency Sink：FFT Size 4096，Center Frequency 设 98e6。接 Source 输出。
5. QT GUI Waterfall Sink：同样接上，与频谱图同看。

运行（画布上的播放按钮），你得到与第 3 章离线脚本完全一致的实时画面。此时值得做一个对照实验：把 Gain 从 30 拉到 0，看噪声底塌下去、信号消失；再拉回 40，看强台削顶出谐波——第 2 章的增益口诀在 GUI 下变成了一秒一次的实时反馈。

图：最小接收流图的块连接示意

三个新手必踩的坑

**坑一，忘了 Throttle 或 hardware 定速。**如果流图里没有任何硬件源，也没有 Throttle 块限速，调度器会全速空转吃满 CPU。规则：有真实硬件源的流图不需要 Throttle（硬件时钟就是节拍器）；纯仿真流图必须放一个。两者都放反而会冲突——Throttle 与硬件源同时限速会导致样本堆积。

**坑二，采样率前后不一致。**SoapySDR Source 输出 2.048 MSPS，若下游块声明以别的速率处理（比如音频块按 48 kHz 假设），频率参数全部错位。GRC 不做自动换算，速率的正确性是流图作者的责任。习惯做法：samp_rate 变量定义一次，所有频率类参数都写成表达式（如 cutoff 用 samp_rate 乘比例），改一处全图联动。

**坑三，把 GUI 块当处理块。**QT GUI Frequency Sink 只显示不改变数据，它不能"顺便滤波"。想滤，请明确放 Filter 块——显示与处理分离，是流图可读性的底线。

流图跑不通的六条速查

跑不起来时按序检查：类型不匹配（看端口颜色与报错行号）；设备被占用（关掉其他 SDR 程序）；采样率不合法（RTL-SDR 只接受特定档位，2.048e6 最稳）；参数越界（增益上限 49.6 dB，频率范围 24 至 1766 MHz）；变量名打错（控制台的 NameError 会直接给出行号）；Python 环境不对（GRC 生成代码用的是它自己的解释器路径，装了库却报缺模块时先查这个）。

第六条尤其常见于 Windows：装了多个 SDR 套件后，GRC 的 Python 可能指向另一个环境的 site-packages。解法是统一用 Radioconda 或在 GRC 设置里指定解释器路径。环境类问题占新手流图故障的三成以上，且与信号处理毫无关系——别在算法里找原因。

常见问题

问题：QT GUI Frequency Sink 的 dB 刻度能换成功率吗？

GUI 显示的是相对 dB 刻度，供观测比较用。需要绝对数值时应把信号接入 Probe Signal 或 Message Debug 块做数值读取，或导出样本到 Python 里做统计——显示块归显示，测量归测量，两个用途分开做才不出错。

问题：流图里块的顺序可以随便换吗？

不可以。信号处理是有序流水线：滤波在解调前是限带（防止带外噪声进入鉴频），解调后再滤波就是音频整形；抽取在变频前后的意义完全不同。改顺序前先问"这一级的输入输出速率与频谱位置变了，下一级还成立吗"。

问题：怎么把 GRC 流图变成不依赖 GUI 的可执行程序？

GRC 的 Generate 按钮旁选 No GUI 模式（或直接删掉所有 QT GUI 块）重新生成，得到纯 Python 脚本，可在无显示环境（如树莓派监测节点）运行。参数改为命令行传入，一个无人值守采集站就成型了——这是从实验走向部署的标准一步。

问题：块之间为什么需要缓冲？缓冲多大合适？

调度器按块为单位搬运数据，缓冲是生产者与消费者速率抖动的减震器。GNU Radio 默认的缓冲策略偏保守（保证不丢数据），代价是内存占用与端到端延迟。手动调缓冲属于进阶操作：低延迟场景用 head 块或调小输出倍数，但必须确认下游吞吐跟得上，否则缓冲不足又会丢样本——延迟与稳健是一对价。

问题：变量和参数控件能联动到什么程度？

可以做出接近商用软件的交互：QT GUI Range 控件绑定变量后，拖动滑块实时改频率、增益、截止带宽，流图无需重启。进阶做法是用 Probe Function 定期读取信号统计量、自动调节增益——一行参数框就是一个自动化开关。GRC 的交互层远比"画块连线"丰富，值得在流图熟练后回头深挖。

本节要点回顾

• 流图三要素：源块、处理链、汇块，类型一致性由端口颜色把关。
• 硬件源自带节拍：有源无 Throttle，无源必加 Throttle，两者不可兼得。
• 变量单一真相源：samp_rate 定义一次全图引用，改一处联动全局。
• 环境故障占三成：解释器路径与库安装环境不一致是 Windows 第一坑。

频谱仪只是开胃菜。下一节把第 4 章的 FM 接收机完整搬进 GRC，配上调谐旋钮与音量滑块——你的第一台"软件收音机"。