2. UWB定位基础
系统架构设计，说白了就是决定「谁放哪、谁跟谁说话、数据怎么跑」。
我见过不少项目，硬件选型挺高端，结果组网方案没想清楚，现场一跑全是坑。今天咱们就把基站、标签、定位引擎这三块掰开揉碎聊透。
2.1 基站选型：不是越多越好，是放对地方才好
基站是UWB系统的骨架。选型时我习惯先问三个问题：
- 供电方式：现场有没有POE交换机？还是只能拉220V？
- 通信回传：用网线、Wi-Fi还是4G？
- 防护等级：室内洁净环境还是室外粉尘/潮湿？
目前主流基站分三类，我列个表方便你对比：
| 类型 | 供电 | 回传 | 典型场景 | 我踩过的坑 |
|---|---|---|---|---|
| POE基站 | 网线供电 | 有线以太网 | 室内、已布网线 | POE交换机功率不够，基站反复重启 |
| Wi-Fi基站 | DC适配器 | 2.4G/5G Wi-Fi | 改造项目、不便布线 | Wi-Fi信道干扰导致测距抖动 |
| 4G基站 | DC适配器 | 4G蜂窝 | 室外、无网线区域 | 流量费比设备贵，后期运维成本高 |
2.2 标签选型：功耗、尺寸、刷新率，三者只能选两个
标签是戴在人身上的。选型时我一般按这个优先级排序：
- 刷新率要求：0.1Hz（定位打卡）还是10Hz（轨迹追踪）？
- 电池续航：一天一充还是半年一换？
- 尺寸与佩戴方式：工牌式、腕带式、还是头盔式？
这里有个经验公式：刷新率每提高一倍，功耗大约增加40%。我做过一个化工厂项目，客户要求1Hz刷新率，结果标签电池只能撑8小时。后来降到0.5Hz，续航直接翻到20小时。嗯，有时候妥协是必要的。
2.3 定位引擎：算法选型与部署位置
定位引擎是大脑。它负责把基站测到的距离数据算成坐标。目前主流算法就两种：
- TDOA（到达时间差）：基站之间时间同步，标签只发信号。适合大容量场景，但同步精度要求高。
- TOF（飞行时间）：标签与基站双向测距。精度更高，但标签容量受限。
我个人的建议是：
- 如果现场超过100个标签同时跑，优先选TDOA。
- 如果精度要求±10cm以内，且标签少于50个，TOF更稳。
部署位置也有讲究。定位引擎可以跑在：
- 本地服务器：延迟低，适合实时控制场景。
- 边缘网关：减少网络依赖，适合工厂产线。
- 云端：方便运维，但延迟高，不适合高速移动定位。
核心原则：定位引擎离基站越近，系统实时性越好。我一般推荐本地部署，除非客户明确要求云平台统一管理。
2.4 组网方案：一张图看懂三种典型架构
组网方案决定了系统能不能稳定跑。下面这张图是我自己总结的三种典型架构：
2.5 避坑指南：我踩过的三个大坑
做UWB系统集成这些年，有些坑我印象特别深，写出来你参考：
坑一：基站时间同步没做冗余
我曾经在一个仓库项目里，所有基站靠一台交换机做PTP时间同步。结果交换机挂了，整个系统定位全部失效。后来我改成双交换机冗余，一台主一台备，再没出过问题。
坑二：标签电池容量算少了
有个客户要求标签厚度不超过8mm，我选了薄电池。结果实际续航只有标称的60%。后来发现是低温环境导致电池性能下降。现在我做选型时都会留30%的余量。
坑三：定位引擎部署在云端
一个化工厂项目，客户坚持要把引擎放云端。结果现场网络延迟50ms，定位刷新率死活上不去。最后还是在本地加了一台边缘服务器才解决。记住：实时定位系统，延迟就是精度。
2.6 小结
系统架构设计没有标准答案，但有一条铁律：从现场条件出发，倒推选型。
你想想看，如果现场连网线都拉不了，你选再好的POE基站也没用。反过来，如果现场有现成的POE交换机，就别折腾无线方案了。
我个人习惯是：先画拓扑图，再列设备清单，最后做一次现场勘查确认。这套流程走下来，80%的问题都能提前规避。