简介：这是一份面向软件无线电与阵列信号处理开发者的 GNU Radio 外置包，使用 C++ 编写，实现了 MUSIC 与根 MUSIC 两种到达角估计算法，并包含提供 USRP 设备相位同步所需的配套模块。该包解决多通道 USRP 采集时通道间相位不一致导致的测向偏差，适合有 SDR 基础、希望将算法从仿真部署到实机的中高级工程师。压缩包共 115 个文件、约 631KB，文件类型以 py 脚本、h/cc 源码、grc 流程块定义、yml 配置和 cmake/txt 构建说明为主，附带 readme/license 文档，目录结构完整，便于按模块编译与集成。核心模块包括 MUSIC 线性阵列、根 MUSIC、相位差计算、移相、相关运算、精确移动平均及带头复位，完整覆盖从多通道相位对齐、时延补偿到最终角度估计的链路，可作为 GNU Radio 二次开发与 USRP 实测的参考实现。页面已有 218 人学习浏览，适合需要把握完整工程结构、快速开展测向算法实测的工程师与研究者。

1. 为什么有人要把 MUSIC 和 root-MUSIC 塞进 GNU Radio：相位同步才是真正的门槛

做到达角（DOA）估计的人第一次听说“MUSIC 的 GNU Radio 包”时，多半以为重点在算法谱峰搜索。真正碰过 USRP 多通道采集的人会立刻反问：你的四个通道相位是同步的吗？没有相位关系，协方差矩阵里全是噪声，MUSIC 算法再精巧也只是把随机相位变成漂亮的假峰。这个项目标题真正值钱的地方不是 MUSIC 本身，而是把算法与 USRP 相位同步所需的模块打包到一起，让一套原本只活在 MATLAB 仿真里的测向流程，能直接跑在 GNU Radio 流图里，对着真实射频信号出角度。适合正在搭无源测向台架、做阵列信号处理验证、或者想用软件无线电替代专用测向设备的人。接下来我会按算法原理、OOT 包组织、相位同步配置、实测避坑和验证收尾的顺序，把这条路完整讲透。

2. 从阵列模型到 MUSIC/root-MUSIC：先搞清算法在算什么

2.1 接收信号模型与协方差矩阵：MUSIC 的输入不是 IQ 数据

我见过不少人拿到四路 IQ 流后，直接拼成一个多维数组扔给 MUSIC 谱函数，结果角度乱飞。MUSIC 的输入是协方差矩阵，不是原始 IQ 快照。它做的是对阵列输出的二阶统计量进行特征分解，所有到达角信息都藏在阵元之间的相位差里，而这个相位差只在协方差矩阵的跨通道项上有意义。

先约定模型。假设一个均匀线阵有 M 个阵元，间距为 d，来了 K 个远场窄带信号，入射角度为 θ。某个采样时刻 t 的阵列输出可以写成：

x(t) = A(θ)s(t) + n(t)

其中 A(θ) 是 M×K 的导向矩阵，每一列是某个角度对应的导向矢量。对均匀线阵，第 k 个信号在第 m 个阵元上的相位滞后是 (m-1)·(2πd·sinθ_k/λ)。把这一项写进工程代码时，我最常踩的坑是角度单位：Python 里三角函数默认弧度，而配置文件里写的度，转换错一次就是整体偏置。

协方差矩阵的标准估计式是：

R = (1/N) · Σ_{t=1}^{N} x(t)x^H(t)

放在代码里就是快照矩阵乘共轭转置再取平均。下面这段 Python 仿真代码可以在写 GNU Radio block 之前先验证算法链路：

import numpy as np def steering_vector(freq_hz, d_m, theta_rad, n_elements): """均匀线阵导向矢量，参考点为第一个阵元""" c = 299792458.0 wavelength = c / freq_hz phase = -2.0 * np.pi * d_m * np.arange(n_elements) * np.sin(theta_rad) / wavelength return np.exp(1j * phase) def cov_from_snapshots(snapshots): """snapshots: shape (n_elements, n_snapshots)，计算采样协方差矩阵""" return snapshots @ snapshots.conj().T / snapshots.shape[1]

这里有两个参数要强调。d_m是阵元间距，工程上一般取工作频率半波长以内，超过半波长会出现角度模糊，这对 root-MUSIC 尤其致命。n_elements是参与运算的通道数，它必须与实际射频通道数一致，而不是 GNU Radio 流图里虚拟通道数。计算协方差矩阵时，快照数 N 至少大于阵元数 M，否则矩阵不满秩，后面特征分解的信号子空间会污染噪声子空间。我一般把 N 取到 8M 以上，实测结果才稳定。

2.2 特征分解与噪声子空间：MUSIC 谱峰是怎么来的

拿到 R 之后，标准 MUSIC 的核心动作是对协方差矩阵做特征值分解，然后把特征向量按特征值大小分成两组：大特征值对应的特征向量张成信号子空间，剩余特征值对应的特征向量张成噪声子空间。信号个数 K 是两者的分界线，所以算法需要预先知道信号源数量。实际系统里 K 往往靠信息论准则估计，但我建议第一版先写死，等谱峰稳定后再做 AIC/MDL。

MUSIC 谱定义为：

P(θ) = 1 / (a^H(θ) E_n E_n^H a(θ))

其中 E_n 是噪声子空间特征向量构成的矩阵，a(θ) 是 θ 方向上的导向矢量。谱峰位置就是信号入射角。这个式子看着简单，但有一个隐藏前提：导向矢量必须用与数据相同的阵元相位参考，且通道间已经做过幅度校准。否则分母不会在真实角度处趋近于零，而是在某个错误角度处变小。

下面是在 Python 里实现谱搜索的核心段落：

def music_spectrum(cov, n_sources, n_elements, freq_hz, d_m, angle_grid_deg): eigval, eigvec = np.linalg.eig(cov) # 把特征值从大到小排序，特征向量跟着重排 idx = np.argsort(eigval.real)[::-1] eigvec = eigvec[:, idx] # 取小特征值对应的向量作为噪声子空间 noise_subspace = eigvec[:, n_sources:] spectrum = [] for deg in angle_grid_deg: theta = np.deg2rad(deg) a = steering_vector(freq_hz, d_m, theta, n_elements) denom = a.conj() @ noise_subspace @ noise_subspace.conj().T @ a spectrum.append(1.0 / abs(denom)) return np.array(spectrum)

注意n_sources传错时，噪声子空间里混进了信号分量，整个谱会变成“没有峰”，或者峰出现在完全不可信的位置。还有一个细节：np.linalg.eig对协方差矩阵返回的特征向量列不一定按特征值排列，必须先排序再取列。我用这段代码时遇到过把大特征值分给噪声子空间的事，就是因为没排序。谱搜索的栅格密度也值得注意，0.1° 的步长在 M=8 阵元下谱峰已经够锐，再细只会增加计算量，不会提高真实分辨率。

2.3 root-MUSIC 为什么是多项式求根而不是扫描：计算量差的不是一个量级

标准 MUSIC 每估计一次角度就要在整个角度栅格上做一次导向矢量乘法，实时系统里非常不划算。root-MUSIC 的思路是把角度搜索换成多项式求根：把噪声子空间投影矩阵 F = E_n E_n^H 的二次型写成关于 z 的多项式，角度信息被编码到多项式系数里，求根后根据根的相位直接算出角度。

它要求阵列是均匀线阵，因为只有均匀线阵的导向矢量才能写成 z^m 的形式。多项式构造如下：

P(z) = Σ_{l=-(M-1)}^{M-1} C_l z^{-l}

其中 C_l 是 F 矩阵副对角线上元素的累加和。具体实现中，直接对 F 的第 (m,l) 个元素按对角索引求和，得到一个长度 2M-1 的系数序列。然后求多项式零点，选择单位圆内且距离单位圆最近的 K 个根，到达角由根的辐角和阵元间距推出：

θ = arcsin(-arg(z) · λ / (2πd))

这里我复制过一段可以直接跑的构造代码：

def root_music_angles(cov, n_sources, freq_hz, d_m): eigval, eigvec = np.linalg.eig(cov) idx = np.argsort(eigval.real)[::-1] eigvec = eigvec[:, idx] noise_subspace = eigvec[:, n_sources:] F = noise_subspace @ noise_subspace.conj().T n_elements = F.shape[0] # 按对角索引累加，得到多项式系数 coeff = np.zeros(2 * n_elements - 1, dtype=complex) for i in range(n_elements): for j in range(n_elements): coeff[i - j + n_elements - 1] += F[i, j] roots = np.roots(coeff) # 只保留单位圆内的根 inside = roots[np.abs(roots) < 1.0] inside = inside[np.argsort(-np.abs(inside))] # 按幅度从大到小排 angles = np.arcsin(-np.angle(inside[:n_sources]) * 299792458.0 / (2 * np.pi * freq_hz * d_m)) return np.rad2deg(angles)

相比谱扫描，root-MUSIC 的优势是精确角度不受栅格限制，也不会因为扫描步长太粗而丢峰。代价是多项式求根对浮点误差比较敏感，阵元数越多，高次多项式系数越容易病态。另一个坑是np.roots返回的根顺序没有意义，必须按模长筛选，否则角度是乱的。在 GNU Radio 里做实时处理时，我倾向于让 block 同时保留两种模式：默认跑 root-MUSIC 降低 CPU 占用，调试时切到 MUSIC 谱峰确认结果，防止多项式病态引入不可见的偏置。

3. 在 GNU Radio 里搭 MUSIC 测向流图：从 USRP 源到 DOA 估计

3.1 用 gr_modtool 生成 OOT 模块骨架

MUSIC 和 root-MUSIC 在 GNU Radio 里的正确载体是 OOT（Out-of-Tree）模块。常见做法是先用 gr_modtool 生成模块骨架，再往里面加 block。不要在 GRC 里用一堆现成 DSP block 拼一个 MUSIC，矩阵运算在里面根本表达不了。

我一般会这样初始化：

gr_modtool newmod music_doa cd gr_music_doa gr_modtool add -t python -n doa_estimator --no-grc

这里-t python生成 Python block，适合前期验证算法。C++ 版本可以后面再把核心矩阵运算抠进去。--no-grc是指不生成图形化配置界面，但如果你要直接在 GRC 里拖 block，那就不带这个参数。生成的目录里有python/放 Python 实现，有grc/放 XML 定义，有lib/放 C++ 源码位置。

注意：GNU Radio 3.8 和 3.9/3.10 的 gr_modtool 参数略有差异，老版本用-t python，新版本有时要求指定--block-name。如果你在 3.10 上执行报参数不对，先跑gr_modtool add --help看当前版本支持哪些选项。别照抄老博客，我在 3.10 上栽过一次。

3.2 在 Python block 里实现流式 DOA 估计

OOT 里的 Python block 核心是继承gr.sync_block或gr.general_block，在work()函数里处理输入流。输入是 M 个通道的 IQ 流，buffer 长度按快照数累积。我的设计是：输入矢量长度为n_elements * vector_length，每个元素是复数。work()每次调用累积一段快照矩阵，攒够 N 个快照后计算协方差矩阵，再跑 MUSIC 或 root-MUSIC，把角度作为消息发出去。

简化版的核心代码长这样：

import numpy as np from gnuradio import gr from .music_algo import root_music_angles class doa_estimator(gr.sync_block): def __init__(self, freq_hz, d_m, n_sources, n_snapshots, mode): gr.sync_block.__init__(self, name="doa_estimator", in_sig=[np.complex64] * n_sources, # 注意：这里写死了通道数 out_sig=None) self.freq_hz = freq_hz self.d_m = d_m self.n_sources = n_sources self.n_snapshots = n_snapshots self.buffer = [] self.mode = mode self.message_port_register_out(pmt.intern("angles")) self.set_history(n_sources) def work(self, input_items, output_items): n_elements = len(input_items) n_new = len(input_items[0]) for i in range(n_new): snapshot = np.array([input_items[ch][i] for ch in range(n_elements)]) self.buffer.append(snapshot) if len(self.buffer) >= self.n_snapshots: snap_matrix = np.array(self.buffer).T cov = snap_matrix @ snap_matrix.conj().T / self.n_snapshots angles = root_music_angles( cov, self.n_sources, self.freq_hz, self.d_m) self.message_port_pub( pmt.intern("angles"), pmt.from_double(angles[0])) self.buffer = [] return n_new

有几个参数必须说清楚。freq_hz是射频工作频率，不是基带采样率；导向矢量用的是载波频率。d_m是天线阵元间距，单位是米。n_sources是来波信号数量，我建议先手动指定，因为自动估计需要另外写一整套模型阶数选择逻辑。n_snapshots决定协方差矩阵质量，但也会引入延迟：快照数越大，估计越稳，但角度输出越滞后。实际系统里这个积压延迟要控制在可接受范围，否则实时测向没有意义。

m = n_sources 的in_sig写死是个坏味道，因为如果你有 8 个通道但只有 4 个信号，这个设计会把通道数当信号数。正确做法是单独传n_channels参数，信号数单独给。我实际写的时候把in_sig和参数分开，避免误导。

3.3 把 block 接入 GRC 流图

block 写好后，在 GRC 里从 USRP 源到 DOA block 的连接长这样：每个天线通道对应一个 USRP 输出端口，统一接入 doa_estimator 的多个输入。流图里另一个关键模块是相位同步模块，下一章专门讲。

在 GRC 中配置 USRP 源时，常用属性有：

连接完成后，先不要直接跑真实天线。在流图里插入一个 Signal Source 作为单通道测试信号，另外几个通道用经过移相器的同一信号源，验证 block 能不能正确解出相位差。这一步能过滤掉大量硬件接线问题，而不是等算法输出崩溃再回头找原因。

4. 相位同步模块：多通道 USRP 的时钟与相位对齐

4.1 为什么多通道相位同步不是“插同一根线”就能解决

MUSIC 算法对通道间相位差极其敏感，但多通道 USRP 的每一个接收通道都有一条独立的射频链路，独立的本振、独立的 ADC、独立的时钟域。如果两个通道的本振频率不完全一致，相位差会随时间线性漂移，协方差矩阵里的相位关系每毫秒都不一样。如果采样时钟不同源，快照之间的对齐起点也在滑。这里有一个常见误区：所有通道插在同一台 USRP 设备上，不等于同步。板内通道之间可能已经具备良好的共同时钟，但跨设备、跨子板时，必须显式配置参考源和触发信号。

UHD 驱动里，关键是把时钟源和时间源都设为外部参考。时钟源用外部 10 MHz 参考信号锁定所有 PLL，时间源用 PPS 使所有设备的抽样时刻对齐。实现层面，GNU Radio 的 UHD USRP Source 在构造参数里直接暴露了这些选项。推荐在流图里用属性面板配置，但更可复现的方式是写在启动脚本中。

常见做法是先用 UHD 自带的工具检查同步状态：

uhd_usrp_probe --args="addr=192.168.10.2"

关键看输出的clock source和time source是否显示为 external。如果显示 internal，后面数据再花哨也不能用。还有一个我现在一定会查的指标是Mboard和TX/RX子板是否报告同样的参考锁定状态，某块板子的 lock 状态异常时，UHD 会打印 warnings，但流图照常运行，角度输出却是错的。

4.2 在 GNU Radio 流图里配置同步参考源

在 GRC 里，双击 UHD USRP Source 打开属性配置。除了上一章的通道参数，同步相关的设置集中在Sync区域。我的标准配置如下：

• Clock Source: external
• Time Source: external
• Sync Source: 如果有这个选项，选external或multi_usrp，让 UHD 自动对齐设备时间
• Channel Map: 按天线编号固定顺序，不能软件里乱映射

如果你在自定义 Python 流图里直接构造 USRP 源，也可以这么写：

from gnuradio import uhd import sys usrp_source = uhd.usrp_source( ",".join(["addr=192.168.10.2", "addr=192.168.10.3"]), uhd.stream_args(cpu_format="fc32", channels=[0, 1]) ) usrp_source.set_clock_source("external", 0) usrp_source.set_clock_source("external", 1) usrp_source.set_time_source("external", 0) usrp_source.set_time_source("external", 1)

逻辑说明：set_clock_source对每个主板设置 10 MHz 参考；set_time_source设置 PPS 同步事件时间。这个顺序不能反，必须先保证时钟锁定，再对时。否则设备之间频率差还没稳定，时间戳对上了也是白搭。

参数注意：stream_args里的channels=[0,1]是逻辑通道编号，它和物理通道 MAP 的关系由每个设备内部映射决定。我遇到过逻辑通道 1 实际对应物理 RF B 端口的情况，导致两个阵元的数据整体互换。用uhd_usrp_probe查看每个通道的antenna配置可以避免这种问题。

4.3 用一个专门的同步检查 block 固化状态

标题里说的“提供 USRP 设备相位同步所需的模块”，我一般会做成一个独立的phase_sync_monitorblock，而不是把同步逻辑塞进算法 block。它的作用是周期性读取 UHD 的同步状态并输出：

import pmt from gnuradio import gr from gnuradio import uhd class phase_sync_monitor(gr.sync_block): def __init__(self, usrp_source, check_interval_ms=1000): gr.sync_block.__init__(self, name="phase_sync_monitor", in_sig=None, out_sig=None) self.usrp_source = usrp_source self.message_port_register_out(pmt.intern("sync_status")) self.set_auto_update_interval(check_interval_ms / 1000.0) def work(self): time_src = self.usrp_source.get_time_source(0) clock_src = self.usrp_source.get_clock_source(0) ok = (time_src == "external") and (clock_src == "external") self.message_port_pub(pmt.intern("sync_status"), pmt.from_bool(ok)) return 0

这段代码不直接参与信号处理，但它会持续向外发布同步状态。下游可以接一个 Message Debug，也可以接到流图的停止逻辑，一旦失步就自动暂停采集。我通常还会在这个 block 里读一次get_time_last_pps的差值，验证两板时间误差是否在采样周期以内，这样能在相位漂移早期发现问题，而不是等 MUSIC 角度出来了才发现不对。

要注意，set_auto_update_interval只在gr.sync_block的 Python override 里可用，版本差异可能导致该接口不存在。另一种写法是使用定时器线程。这里是示意，工程上请以你装的 GNU Radio/UHD 版本 API 为准。如果 API 对不上，宁可在 GRC 里用Add组件处理状态消息，也别强行调用一个不存在的接口。

5. 从仿真到实采的避坑记录：相位漂移、阵列标定与谱峰假象

5.1 频谱上明明有尖峰，MUSIC 角度却全部落在设备偏置方向

现象：用信号源发一个 5.8 GHz 单载波，MUSIC 谱搜索出的峰值角度稳定，但无论如何调整发射位置，计算角度都比真实角度偏了十几度。

原因：通道间存在固定相位差。常见来源是射频前端滤波器、混频器、AD 引线长度差异。这个差值不随时间漂移，但也不为零，算法默认通道相位一致，于是被整体计入导向矢量。

解决：在正式测向前做一次相对相位校准。固定信号源位置，采集 N 个快照，计算各通道与参考通道的互相关相位，得到一组复数校正系数。把这组系数做成一个前置 block，对 IQ 逐点补偿：

calibration_coeff = np.array([1.0, 0.98*np.exp(1j*0.12), ...]) def work(self, input_items, output_items): # 数值按实际测量值回填 for ch in range(n_channels): output_items[ch][:] = input_items[ch] * calibration_coeff[ch] return len(output_items[0])

注意校准系数必须随工作频率和子板配置重新测量，带宽内不同频点的相位差并不完全一致。

5.2 谱峰出现但宽度骇人，多方向混成一片

现象：两个来波方向相差 20 度，MUSIC 谱只看到一个馒头状峰，无法分辨两个信号。

原因：信噪比不足或快照数太少，协方差矩阵的信号子空间没有完全收敛；也可能是两个信号相干，例如同一信号的多径版本同时进入阵列。

解决：先把快照数从 M 的 2 倍提高到 8 倍以上，观察谱峰变锐。如果仍不分开，考虑空间平滑。前向平滑会把阵列分成若干子阵，对子阵协方差求平均，能够解相干，代价是有效阵元数减少。工程上我常用前向-后向平滑，能同时利用反向阵列共轭对称性增加平均次数。平滑阶数不要超过阵元数的三分之一，否则方位分辨力下降得比解相干带来的收益还快。

def forward_backward_smoothing(cov, n_subarrays): """n_subarrays 是子阵数量，平滑后每子阵阵元数 = M - n_subarrays + 1""" M = cov.shape[0] L = M - n_subarrays + 1 smoothed = np.zeros((L, L), dtype=complex) for i in range(n_subarrays): sub_cov = cov[i:i+L, i:i+L] smoothed += sub_cov # 反向平滑需要共轭反对角变换 J = np.fliplr(np.eye(L)) smoothed += J @ sub_cov.conj() @ J return smoothed / (2 * n_subarrays)

这里的n_subarrays如果传 1，等于不做平滑。实际代码里要先验证平滑矩阵是 Hermitian，再进 MUSIC，否则特征值可能出现复数 0 阶问题。

5.3 root-MUSIC 的根乱跳，结果时而正确时而错得离谱

现象：同一组静态数据，root-MUSIC 输出的角度序列在正确值和一个完全不合理的值之间跳变。

原因：np.roots对高次多项式的根计算不稳定，尤其是噪声子空间估计误差较大时，部分零点落在接近单位圆的位置，根的选择逻辑把微弱靠近圆的噪声根当成了信号根。

解决：不要只看离单位圆最近的前 K 个根。先用 MUSIC 谱做一次粗搜索，找出大致角度范围，再从 root-MUSIC 的候选根里挑选与粗搜索峰值最接近的那个。或者是增大快照数，让噪声特征值更收敛。我自己的工程代码里会在 root-MUSIC 之后加一个合理性校验：计算每个候选根的角度，再用该角度计算导向矢量与噪声子空间的内积，保留内积谱值小于阈值的根。这个校验只多 20% 计算量，但能把跳变问题基本消灭。

5.4 多通道 USRP 采出来的数据相位随时间漂移

现象：静态场景下，MUSIC 角度在几分钟内缓慢偏移，随后突然跳到错误值；再把数据抓下来做离线分析，协方差矩阵的特征值结构随时间变化。

原因：外部 10 MHz 参考没有真正锁住所有板卡，或 PPS 对齐后采样时钟存在微小频差。还有一种隐蔽情况：只设了Clock Source = external，忘了设Time Source = external，导致通道间采样起点用了不同时间原点。

解决：在流图启动阶段强制同步一次时间戳：

# 对所有设备 uhd_usrp_source.set_time_unknown_pps(uhd.time_spec(0.0))

然后在采样前等待至少两个 PPS 边沿。如果设备支持，再开启time source为 external 且clock source为 external。同步后抓一小段恒定位相信号，用互相关验证相位差是否稳定。若仍然漂移，多半是参考时钟线分线质量或阻抗问题，换一条短分线重新测。

5.5 GNU Radio 流图运行时持续 overrun，角度输出像掉帧

现象：流图跑起来后 USRP 源不断输出 overrun 警告，DOA 输出角度更新的实际频率远低于理论值，且角度序列不连续。

原因：算法 block 在work()里同步执行矩阵特征分解和多项式求根，处理时间超过了采样块积累速率，底层采样缓冲溢出。

解决：把算法块改成非同步处理模式。最常用的是先用一个“快照累积器”按块积累，攒够后发布消息，再由单独线程做矩阵运算。GNU Radio 里可以利用 message passing 格式：

class snapshot_accumulator(gr.basic_block): # 每个输入快照直接推入 buffer # 攒够后 message_port_pub 到 doa_estimator

DOA estimator 此时变为异步处理，不阻塞实时流。如果 CPU 仍然吃紧，把 MUSIC 谱搜索的栅格从 0.1° 放宽到 0.5°，或者直接切到 root-MUSIC。特征分解可以用np.linalg.eigh代替通用eig，前者专门处理 Hermitian 矩阵，速度快且数值稳定。实测相同数据量下，eigh比eig快 30% 以上。

6. 把算法包用起来的最后一公里：实时性调优与现场验证

DOA 算法接进 GNU Radio 后，第一件事不是搬去室外测向，而是回到可控信号环境做端到端验证。我会把一个信号源通过功分器分成两路，经过不同长度的射频线连接两个天线端口，这样相位差是已知的，算出的角度也应该是已知的。如果这一步都不准，问题大概率在相位校准或同步配置，而不是算法本身。

验证通过后再做实时性压力测试。给流图接入一个仿真信号源，调整来波角度每秒变化 10 度，观察 DOA 输出是否能平滑跟踪。重点看三个指标：输出延迟、角度连续性、CPU 占用。延迟超过 200 ms 就说明快照积累过长；角度跳跃则多半是 root-MUSIC 根选择问题。我习惯在这种测试里同时开一个 MUSIC 谱峰模式作对照，把两个结果画在同一张图上，差异超过 0.5° 就回到参数检查。

最后才是现场环境。现场验证最有效的方法是固定几个已知角度位置，各采集 30 秒数据，离线统计 DOA 估计的均值和方差，而不是只看一秒的瞬时值。如果你的测试环境有金属围栏或墙壁反射，多径会让 MUSIC 谱同时出现多个峰，这时不要急着调算法，多一些角度位置的平均能显著改善。

我在这个项目里踩得最深的一个坑，是把同步状态检查放在算法块内部，结果一旦 USRP 失步，算法还在拿旧协方差矩阵硬算，根本没有提示。后来我把同步检查独立成 block，任何失步都触发流图停止，问题才真正暴露出来。这个习惯我后来一直保留：能前置的状态检查绝不后置，能显式输出的状态绝不隐式消化。

另外，根 MUSIC 的实现在不同矩阵库之间数值差异很大。我在 Python 下用np.roots和在 C++ 里用多项式求根库得到过明显不同的结果，这不是算法问题，而是浮点舍入和求根策略的差异。如果你要迁移到 C++，务必用同一组静态数据对比验证，不要假设结果完全一致。希望这些经验能帮你在自己的 GNU Radio 测向工程里少走一段弯路，更早跑出可信的 DOA 结果。

本文还有配套的精品资源，点击获取