多用户接入下的SDR通信性能测试：项目应用实录

多用户接入下的SDR通信实测：从理论到落地的完整技术复盘

最近完成了一个基于软件定义无线电（SDR）平台的多用户通信系统性能测试项目。整个过程从最初的设想，到搭建原型、调试问题、优化参数，再到最终获得稳定数据，经历了不少“踩坑”与顿悟时刻。

今天想把这次实战中的关键环节和深度思考梳理出来——不讲空泛概念，只说我们实际做了什么、遇到了哪些挑战、又是如何一步步解决的。如果你正在做类似的研究或工程验证，希望这些经验能帮你少走弯路。

为什么选 SDR？因为它足够“灵活”

传统无线设备一旦出厂，功能就基本固定了：比如一台对讲机只能跑模拟FM，一个Wi-Fi模块也只能按IEEE 802.11协议工作。但在科研或者专网场景中，我们常常需要快速尝试不同的调制方式、帧结构甚至自定义MAC协议。这时候，SDR就成了不可替代的选择。

简单来说，SDR 的核心是“硬件通用 + 功能软定义”。射频信号通过ADC/DAC数字化后，所有的编码、调制、同步、解调等操作都可以在FPGA或CPU上用代码实现。这意味着：
- 想换QPSK还是OFDM？改个配置就行；
- 要加CRC校验还是前向纠错？写段Python或C++即可；
- 实验失败了？不用换板子，重新部署flowgraph就好。

我们这次使用的正是Ettus USRP系列设备配合GNU Radio框架。这套组合虽然学习曲线略陡，但开源生态成熟，社区资源丰富，非常适合做高自由度的技术探索。

系统目标：构建一个可扩展的多用户TDMA网络

我们的具体任务是在2.4GHz ISM频段下，构建一个支持最多8个终端同时接入的无线网络，并评估其在高并发条件下的吞吐量、误码率和稳定性表现。

考虑到控制复杂度和确定性需求，我们没有采用CSMA这类随机竞争机制，而是选择了TDMA（时分多址）作为MAC层方案。原因很现实：
- TDMA天然避免冲突——每个用户独占一个时隙；
- 可预测延迟，适合工业监控类业务；
- 易于统计每个用户的信道质量，便于后续优化。

听起来很简单：主站发调度表，各用户按时上传数据。但真正在真实信道里跑起来，你会发现——理想很丰满，现实却到处是裂缝。

关键模块拆解：从物理层到MAC层

1. 平台能力边界：USRP到底能做什么？

先说清楚我们手里的“工具”有多强：

这意味着我们可以轻松覆盖Sub-6GHz主流频段，捕获带宽达40MHz以上的信号。但对于更高阶的MIMO或大规模OFDMA系统，千兆网会成为瓶颈——这点后面还会提到。

更重要的是，USRP本身只是一个“数字无线电引擎”，它不会自动组网、不会分配资源、也不会处理丢包重传。所有这些逻辑，都得靠你自己在GNU Radio里搭出来。

2. MAC层怎么设计？TDMA不只是“轮流说话”

很多人以为TDMA就是让每个用户依次发送数据包。但实际上，要让它在真实环境中可靠运行，必须解决几个根本问题：

✅ 时间同步：差1微秒就会出事

USRP自带的温补晶振精度约±2 ppm。听着不高？算一笔账就知道了：

在200 MS/s采样率下，1个样本 = 5 ns
2 ppm偏差 → 每秒相差2000个样本 ≈ 10 μs
运行100帧（每帧10ms）后，累计偏移可达1 μs —— 正好等于一个保护间隔！

结果就是：原本属于User A的时隙，慢慢“爬”进了User B的时间窗，造成严重干扰。

解决方案：外接GPSDO模块

我们将所有USRP连接至同一台GPS驯服振荡器（GPSDO），提供统一的10 MHz参考时钟和PPS脉冲。在GNU Radio flowgraph中启用：

usrp.set_time_source("external") usrp.set_clock_source("gpsdo")

同步后，各设备间时间误差控制在±50 ns以内，彻底解决了时隙漂移问题。

💡 小贴士：如果没有GPSDO，也可以用PTP协议+高性能交换机实现亚微秒级同步，但稳定性略逊一筹。

✅ 帧结构设计：别小看那几个字节的开销

我们设计的TDMA帧如下：

| Preamble | Header | Payload | CRC | Guard | 32μs 8μs 2500μs 8μs 2μs

其中：
-Preamble：用于接收端完成载波同步、定时估计；
-Header：包含用户ID、序列号、长度信息；
-Payload：有效数据（固定1024字节）；
-Guard Interval：预留2μs应对传播延迟与时钟抖动。

看似简单的结构，在低信噪比环境下却极大影响了解调成功率。尤其是preamble长度，太短则同步失败率高，太长又降低频谱效率。最终我们通过大量实测发现：32μs是一个比较理想的平衡点。

3. 核心调度逻辑：用Python写一个“交通指挥官”

GNU Radio本身不支持动态调度，所以我们开发了一个自定义的OOT模块来实现TDMA轮询机制。以下是简化版的核心逻辑：

class tdma_scheduler(gr.sync_block): def __init__(self, num_users=4, slot_duration_us=2500): gr.sync_block.__init__( self, name="TDMA Scheduler", in_sig=None, out_sig=[np.uint8]) self.num_users = num_users self.slot_len = int(slot_duration_us * 200) # 200MS/s → samples self.current_user = 0 self.tick = 0 def work(self, input_items, output_items): out = output_items[0] noutput = len(out) for i in range(noutput): current_slot = (self.tick // self.slot_len) % self.num_users if current_slot == self.current_user: out[i] = 0xFF # 模拟该用户发送数据 else: out[i] = 0x00 # 静默填充 self.tick += 1 self.current_user = (self.current_user + 1) % self.num_users return noutput

这个模块本质上是个“虚拟发射器”，按预设时序激活对应用户的通道。实际应用中，它会与PHY层输出对接，注入真实的调制符号流。

⚠️ 注意陷阱：work()函数的执行是非实时的！如果主机负载过高，可能导致输出缓冲区断流。为此我们启用了RT Kernel + FIFO缓存机制，确保数据连续性。

实战中遇到的三大“坑”及应对策略

❌ 问题1：室内多径导致EVM恶化至-18dB以下

我们在实验室内部署时发现，尽管使用QPSK调制，但接收端的误差矢量幅度（EVM）长期低于-18dB，远超标准要求（通常需优于-25dB）。

排查后确认是多径反射引起的符号间干扰（ISI）。尤其是在金属柜体、玻璃墙附近，信号来回反弹形成多个延迟副本，破坏了正交性。

对策：引入循环前缀 + 信道均衡

虽然这不是OFDM系统，但我们借鉴了其思想，在每个数据包前添加一段循环前缀（CP），长度设为符号周期的1/4（约800ns）。接收端利用导频进行LS信道估计，并用频域均衡器补偿相位失真。

效果显著：EVM回升至-26dB以上，误包率下降近一个数量级。

📌 经验总结：哪怕你跑的是单载波系统，在NLOS环境下也一定要考虑ISI问题。加一点CP成本很低，收益巨大。

❌ 问题2：用户数增加后吞吐量非线性下降

当我们将接入用户从4个扩展到8个时，预期总吞吐量应翻倍。但实测结果令人失望：平均速率反而下降了30%，部分用户PER（误包率）飙升至30%以上。

深入分析发现两个主要原因：

1. 固定时隙浪费严重：某些用户数据量很小，但依然占用完整时隙；
2. 控制平面延迟堆积：主站在处理完一轮接收后才能开始下一帧调度，CPU忙不过来。

改进方案：引入动态TDMA + ARQ机制

我们不再静态分配时隙，而是允许用户通过短控制报文申请资源。主站维护一个优先级队列，根据历史信道质量和紧急程度动态分配时隙。

同时加入滑动窗口ARQ机制，对丢失的数据帧进行选择性重传。虽然牺牲了一定的确定性，但整体吞吐量提升了45%，且公平性更好。

❌ 问题3：千兆网络接近饱和，导致数据丢包

这是最容易被忽视的问题之一。USRP在满采样率下每秒产生约800 Mbps原始IQ数据。当我们试图将多个设备的数据汇聚到一台PC时，网络瞬间被打满。

后果是：UDP丢包 → 缓冲区断裂 → 同步失败 → 整个系统崩溃。

应对措施：
- 改用10GbE交换机 + 支持Jumbo Frame的网卡；
- 或者采用“分布式采集”架构：每台USRP配一个边缘计算节点（如NVIDIA Jetson），本地完成初步处理后再上传摘要数据；
- 在GNU Radio中启用零拷贝（zero-copy）和DMA传输，减少内存复制开销。

工程实践建议：那些手册不会告诉你的细节

经过几周高强度调试，我们总结出一些非常实用的经验，都是从血泪教训中换来的：

1. 尽量使用同一批次的USRP设备
   不同批次的RF前端增益响应可能存在差异，导致RSSI读数不一致，影响链路预算判断。

2. 注意电源噪声干扰
   USRP X系列功耗较高，多个设备共用电源时容易互相干扰。建议使用独立供电模块或带滤波的PDU。

3. 散热不容忽视
   FPGA长时间满负荷运行温度可达70°C以上。我们加装了小型风扇后，EVM稳定性明显提升。

4. 模块化设计，便于隔离调试
   把MAC调度、PHY处理、GUI监控拆成独立模块，不仅能并行开发，还能单独压测某一部分性能。

5. 建立心跳机制与自动恢复流程
   加入UDP心跳包检测连接状态，一旦发现设备离线，自动触发重启脚本，保障长期运行可靠性。

实测性能数据一览

在优化后的系统上，我们进行了为期2小时的压力测试，结果如下（N=8用户，QPSK，10MHz带宽）：

可以看到，在良好同步和合理调度下，基于SDR的多用户系统完全可以达到准工业化水平的性能表现。

写在最后：SDR的价值不在“替代”，而在“探索”

有人问：既然现在有成熟的Wi-Fi 6、5G NR，为什么还要折腾SDR？

我的回答是：SDR的意义从来不是去替代商用芯片，而是去做那些“还没人做过”的事情。

比如：
- 在偏远地区搭建低成本私有网络；
- 训练AI模型识别未知信号；
- 构建认知无线电系统，实现动态频谱共享；
- 为下一代6G试验新型波形或接入机制……

在这个过程中，你会被迫理解每一个比特是怎么被调制、传输、解调的。这种“通透感”，是任何SDK封装都无法提供的。

未来我们计划进一步融合机器学习，让MAC层具备自适应决策能力；同时也尝试用FPGA加速关键路径，减轻主机负担。

如果你也在玩SDR，欢迎留言交流。毕竟，搞通信的人最不怕的就是“连不上”——只要方向对了，总会收到回应。