自从前公司停止 UWB 定位项目，我就停止了 UWB 精确定位方面的工作。前段时间写的一些相关文章，也只是介绍之前所做的工作。最近突然有了继续 UWB 精确定位方面研究的想法。 做一个下行 TDOA 的系统，是个不错的方向。下行 TDOA 需要多级时钟同步，多级时钟同步的效果怎么样，以前一直有些怀疑。 我想把新的系统做成开放式的架构，支持多模式定位，换句话说，就是支持上行 TDOA、下行 TDOA、TOF 等等。将来换成 DW3000，把 PDOA 也用上。当然 MUC 肯定换成 ESP32，这跟是不是国产没关系，而是 ESP32 实在是一款优秀的芯片，又便宜性能又好，功能还多。
重要名词
星历： 主要指基站的坐标信息，包括该信息的版本号
PANID： 系统中所有基站使用相同的 PANID，以保证标签能收到基站的数据。
基站
基站硬件配置：
- MCU ESP32, 可能会选 ESP32, 或 ESP32 S3, 具体选择要经过测试，性能够用就好
- UWB DW1000, 主要是成本低，可以考虑与 DW3000 兼容
- Ethernet IP101, 提供 Ethernet 接入
- 高亮 LED，用于识别基站
- POE，可选 12V/5V 电源
我们不需要再区分基站和时钟源，因为它们的职责几乎完全相同，对标上行 TDOA，基站已经不仅仅只是接收，还要发送信号，所以，它跟时钟源是一样的了。
基站的特征：
- 发送定位数据包(时间戳/基站坐标)
- 发送时钟同步包(时间戳/基站坐标/基站级别)，似乎可以跟定位数据包合并
- 发送星历数据(全部基站的坐标信息/坐标版本)
- 接收时钟同步包
- 接收星历数据
- 两种型号：联网的，不联网的
联网的基站与上行 TDOA 的一样，好处当然是有什么配置变动，可以直接设置基站；基站侧收到标签的消息，也可以直接发给服务器。缺点是联网会增加成本，无论 wifi 还是 ethernet，都会增加成本。
不联网的基站，好处是成本低，只是单纯的 uwb 收发。缺点则是通讯不太可靠，交互机制复杂。时钟同步必须通过 UWB，这没什么好说的，但是其他的消息，如星历/配置/标签消息等等，都需要基站与服务器间的交互，如果不联网，只能通过 uwb，这涉及到效率/带宽/可靠性的问题。
接收和发射
每一个基站都会有一个接收窗口，一个发射窗口。 实际上，基站平时应该处于接收状态，有数据包需要发射的时候才切换到发射状态去发射数据包，然后又进入接收状态。
时钟同步流程
时钟同步很重要，我们要保证所有基站有统一的时间。 时钟同步使用传播方式，类似于相互污染，逐步扩散。
对基站分级/分区(以应对大型区域，分多个小区，多区域间时钟隔离)。 每个区域会有一个顶级基站，它是本区域的总的时钟的源头，所有基站的时钟都以它为准。 每个基站只接收来自指定(上级)基站的时钟同步消息。
基站分级：
- 顶级基站的级别为 0
- 普通基站的级别它 99
- 时钟中继的级别为 1~98，每个基站只接收比它级别它的基站的数据包
也许基站不用分级，而是指定上(下)级基站，每个基站只接收它的上下级发送的数据。它发送的数据也只是给上下级。
基站分区： 对于大型系统，可能无法保证所有基站的时钟一致，例如有些地方是孤立的，只能分多个区，每个区内有自己的一套时间标准。如果不分区，无法把时钟同步给那些孤立的基站。 所以，我们需要分区，并给每个区域设置单独的顶级基站(时钟源)。
星历传播
基站坐标信息要有版本号，当坐标信息有变动时，通过版本号可以保证各个基站使用的是最新的坐标。
由于无线信号的传播是不可靠的，要么重复发送，要么需要一个确认机制。 假设我们使用确认机制，那么星历的传播路径应该是这样的：
服务器通知顶级基站
顶级基站广播每一条星历数据
次级基站接收并发送(转播)上一级基站的发送的星历数据
每一个基站如果收到自己的星历数据，会立即发送一个确认包
每一个基站收到下一级基站的确认包，会转发
顶级基站收到确认包，标记对应星历已发送成功
顶级基站过 n 秒未收到确认包，再次发送星历数据
网络接口
- 基站的网络硬件有两种: WIFI/Ethernet，甚至有的版本可以无网络
- 软件接口，不再支持二进制数据包接口(???)， 使用 Json 格式传送数据
- 基站配置不再使用桌面程序，由服务器配置
- 作为 Webserver，支持直接配置???，但是用户鉴权是个麻烦的事情，也不便于批量设置
- 作为 Rest client，向服务器发送数据
MQTT 支持 基站发往服务器的消息使用 MQTT
基站配置
之前的系统使用专门的基站配置程序，这个是比较方便的，但是需要一个专门的桌面程序。
如果使用服务器程序对基站进行配置，有一个问题是如果服务器程序在外部网络，就没法搞了。还有一种方法是基站提供 webserver，让用户可以在浏览器中访问，通过网页配置，但是怎么知道基站的 ip 是多少。
梳理一下：
- 如果服务器不在局域网，必须要用专门的桌面程序配置基站
- 必须要有鉴权，这是安全性保证
- 如果基站作为服务器端，webserver 因为是非连接的，需要每次都提供 user/pass，或 session/token，会带来一些麻烦，但方便的地方是可以使用浏览器访问
- 如果使用 tcp 长连接，可以只在开始的时候鉴权，后面就不用管了，缺点是必须要专门的桌面程序
- 网络中有哪些基站，这个不清楚，所以 udp 协议自动发现基站是必须的
- 如果使用专门的桌面程序，一定不能与服务器(定位引擎)使用相同的端口，这是考虑到易用性
- 如果需要批量配置，必须要有专门的桌面程序
综上所述，专用的桌面程序是必须的，至少有一条理由：局域网无服务器时的配置。基于使用专门的基站配置程序，那么基站配置程序应该有的功能大致如下：
- 侦听某个 udp 端口，让基站主动报告自己；广播 udp 基站发现包
- 可选：侦听某个 tcp 端口，让基站连过来?
- 使用 tcp 带 user/pass 连接基站
- 使用 json 数据包交互配置数据
- 允许批量配置基站
基站允许配置修改来自服务器 其实，在缺省的配置下，基站会自动发现网络中的服务器，并建立连接，然后服务器就可以配置基站了。这是最便捷的方式。 使用专门的基站配置程序，是出于完备性考虑。
标签
- 标签的 MCU 使用 ESP32，可以支持 WIFI，还有大容量 RAM/FLASH，可以支持显示屏
- 坐标在标签侧计算。
- 标签定期收集基站坐标(星历)，记录在内存中，并定期更新。
- 标签平时休眠，定期醒来进行坐标计算。工作过程类似 GPS。
基本上，标签在接收 UWB 定位数据的过程中，不会同时收到多个基站的数据，会有一个时间区间，在这个时间区间内收到足够计算坐标的 UWB 数据包，然后再计算。如果用 GPS 来形容，相当于是单通道的。
我们需要控制这个区间的时间长度，如果标签在移动中，而区间的时间跨度太大，会导致不不准确。
标签配置程序
- 类似老版本，可以 USB 连接标签
- 使用 json 交互数据
回传标签坐标
- 标签坐标回传到服务器，有两种方式：通过 WIFI，通过 UWB。
- 如果通过 UWB，会有一个比较长的路径：标签->基站 A -> 基站 B –> 顶级时钟源 -> 服务器， 或者：标签 -> 基站 A -> 服务器
- 使用 WIFI 会简单得多，直接通过 WIFI 就传给服务器了
使用哪种方式回传坐标，应该允许配置。有些特殊的场景下，没有 WIFI，只能通过 UWB 回传
如果通过 UWB 回传坐标，在最后那个基站那里可能会导致数据堵塞。因为有太多的标签的坐标要通过这个顶级基站。
多区域
系统中可能会有多个区域，类似 GPS 是一个区域，北斗是一个区域。。。。区域之间不相干。 因为各区域使用的时间不统一，所以计算坐标时各区域的基站不混用。
但是也许会有同时收到多个区域的信号的情况，会计算出多个坐标，对于这种情况，我们可以简单按哪个区域的基站多，就权重大。
UWB 数据包分类
总体来说，UWB 数据包分为 3 类：上行数据包、下行数据包、广播数据包
- 下行数据包是指上级基站发送给下级基站的数据包(可能会有多个下级，其实也是通过广播的方式发送)
- 上行数据包是指下级基站发送给上级基站的数据包
- 广播数据包是指所有基站(或标签)都可以接受的数据包
时钟同步包(下行)
这个数据包从顶级基站开始，发送给它的全部下级基站。 这个数据包不需要确认，因为时钟同步是短周期的、经常性的，错过就错过了，下次再同步就可以了。
所有基站，如果它有下级基站，就一定要自己的时钟同步到下级基站。 所有基站，如果它有上级基站，就接收上级基站发来的时钟同步包并同步自己的时钟。
理论上，一个区域中应该只有一个标准时间。 孤立的一群基站可以单独划分为一个区域，因为这群基站无法与其他区域的基站之间通讯，只好使用自己单独的时间。似乎 GNSS 中 GPS/北斗/GLOSS 之类的，大家不互通。
基站坐标(星历)(下行)
每一个基站都定期发送自己数据库中的星历 UWB 数据。 每一个基站并不刻意记录自己的坐标。 星历数据因为数量会比较多，所以每一个数据包只包含一个基站的坐标。 大致上每秒发送 1 条，如果有 100 个基站，那么需要 100 秒才会更新完成。
基站坐标的来源是服务器，人工在服务器的地图上设定基站的坐标，然后发送给顶级基站，或某些基站。
对于顶级基站，它不接收星历的 UWB 数据包，只接收星历的网络数据包。 对于普通基站，它接收上级基站发出的的星历 UWB 数据包，更新自己的数据库。
标签收到星历数据包后，会记录在自己的数据库中。
基站发送星历数据，应该要有一个权重。对于最近更新的基站坐标要优先，频度也要密集一些，以确保下级基站和标签得到新版本的坐标信息。
基站坐标(星历)查询(上行)
有大的系统中，基站数量会比较多，有可能有些基站的坐标一直无法传播到标签，对于标签来，这些未知坐标的基站没法用。所以允许标签对未知基站的坐标进行查询。
任何基站，收到星历查询数据包后，如果自己的数据库中有对应的数据，应该立即回复。 如果自己的数据库中没有对应的数据，应立即向上级基站查询。
某一个具体的基站，它一旦回复过某个星历查询之后，在某个时间内不应该再次回复该星历的查询。
基站信息查询(下行)
基站信息查询有两种：网络/UWB
对于某个基站，收到上级基站或服务器发来的这个数据包，应该立即报告自己的基站信息，并向下级基站发出查询。
基站信息报告(上行)
基站应该是被动的，不主动报告自己的信息。 当收到上级基站或服务器的查询要求后，才向上级基站或服务器报告自己的信息。
似乎需要一个确认机制，以保证基站信息顺利被服务器收到
最小化定位数据包(下行)
其实所有的下行 UWB 数据包都可以用于定位。 尽管如此，我们还是定义一个最小化的专门的定位数据包，让标签能据此计算坐标。
带坐标的定位数据包(下行)
这个数据包带有发送该数据包的基站的坐标信息。 以避免因为星历收集不全而导致无法计算坐标。 其实如果有这个数据包，标签应该不会再需要发出星历查询了。
应用场景
设想一下这个系统的应用场景。
在某个需要使用 UWB 精确定位的场所，部署了这套下行 TDOA 的定位系统。在某栋大楼的某一层，安装了很多基站，这些基站之间通过上级下关系的配置，形成一棵树状的逻辑形态，树根是根时钟源，其他全部基站的时钟逐级与之同步。
这些基站中，有些使用 POE 供电并接入局域网；有些通过 WIFI 接入局域网；有些本联网。
有一些标签以工牌的形态挂在工作人员胸前，有一些标签以手环的形式戴在工作人员手腕，有一些标签安装在移动的设置上(如自行走小车)。标签上有显示屏(TFT/OLED/墨水屏)，标签上还带有喇叭和振动马达，在收到消息时提示。收到的信息显示在屏幕上，屏幕平时显示当前北京时间。 标签计算自己的坐标，与 GPS 终端类似。标签通过 WIFI 把自己的坐标发给服务器，该服务器是应用服务器，可以与定位系统无关。也许，标签也可以通过 UWB 发送自己的坐标到服务器，这个会麻烦一点(路径较长、可靠性低、某些环节有瓶颈)。
在系统安装阶段，有一个配置用的电脑，可以对基站的坐标和硬件属性进行配置，配置完之后就可以关闭，平时不使用。对于不联网的基站，硬件属性可以在事先配置好后再安装。基站的坐标信息有两种方式发布：(1)、发布到根时钟源，再由根时钟源通过 UWB 传播到其他基站；(2)、配置电脑直接把各基站的坐标通过局域网发送给对应的基站。
总体来看，这个系统与 GPS 类似，定位系统本身与应用系统分离。定位系统只负责各个基站的管理，甚至连标签都不用管，就像 GPS 系统只管保证天上的卫星工作正常，它不管 GPS 终端。有多少 GPS 终端它不管，GPS 终端计算出自己的坐标后怎么用它也不管。
在应用层面，标签计算出坐标之后，把坐标提供给应用系统，怎么使用这些坐标，与定位系统无关。就像 GPS 终端计算出自己的坐标后，可能只是单机使用来导航，或者通过 4G/5G 网络发送给应用服务器用来做车辆跟踪等等，与 GPS 的运营方无关。
这样的话，实际上我们可以把定位系统做成模组化的子系统，基站部分由厂家做成黑箱，可以封闭式管理；把标签部分做成开放式的，提供给应用方的集成公司做二次开发。
现在还没有下定决心做下行 TDOA 的研发，主要是不知道东西做出来之后卖给谁。如果有公司愿意赞助，马上就可以开工。 看过 DecaWave 的 DW3000 的 Datasheet，这个芯片似乎很不错。等以后机会把 DW1000 换成 DW3000。
