分类： 网络&硬件

产品规格 Products specification

代号 Code	型号 Model	安装方式 Mounting  type	外形尺寸 Dimensions (mm	参数 Sections	最大可变容量 Max.var.Capacitance(pF)	最小容量 Min.Capacitance(pF)	容量公差 Tolerance of Capacitance(pF)
009	CBM-223P	1	20.5×20.5×12.5	AM-2	(o):59.2 (A):141.6	(O):5±2 (A):5.5±2	(O):±（2pF+2%） (A):±(2pF+2%)

技术特性 Specifications

型号 Model	绝缘电阻 Insulation Resistance (MΩ)	动片接触电阻 Rotor Contanct Resistance (MΩ)	耐电压 Voltage Proof (V.D.C)	Q             (1MHz 50pF)	转动力矩 Operating Torque (gf.cm)	止端力矩 End Stop Torque (kgf.cm)	微调增量 Trimmer Cap.Swing (pF)	转动方向 Rotation Direction	转动角度 Rotation Angle
CBM-223P	≥250	≤10	≥100	≥150	50~400	≥3	≥8	.

电容量曲线 Capacitance curve

型 号        Model	联别Section		转角关系及电容增量   Coeff  of  Rotation and  Cap   Swing   (%pF)
			100	90	80	75	70	60	50	40	30	25	20	10	（3）
CBM-223P	AM	OSC	59.2	55.2	50.9	48.5	46.2	41.0	35.0	28.4	21.0	16.9	12.9	4.8	0
		ANT	141.6	126.3	111.2	103.7	96.1	80.4	64.3	48.5	33.2	25.7	18.5	6.2	0

外形尺寸 Outline dimensions

参考链接

---

• SJ 2706-1986 CBM-223P双联薄膜介质可变电容器
• CBM-223P-Hong Da Industrial (HK) LTD

本文介绍了 Intel QAT 技术方案，通过 Multi-Buffer 技术和 QAT 硬件加速卡的两种方式实现对 TLS 的加速

一、背景

当前 TLS 已经成为了互联网安全的主要传输协议，TLS 带来更高的安全性的同时，也带来了更多的性能开销。特别是在建连握手阶段，TLS 的 CPU 开销，相对于 TCP 要大很多。

业界在优化 TLS 性能上已经做了很多软件和协议层面的优化，包括：Session 复用、OCSP Stapling、TLS1.3等。然而在摩尔定律"失效"的今日，软件层面的优化很难满足日益增长的流量，使用专用的硬件技术卸载 CPU 计算成为目前通用的解决方案。本文将介绍 Intel 在 TLS 加速领域提供的 QAT 技术方案。

二、Intel QuickAssist Technology（QAT）技术方案

Intel 提供了 TLS 异步加速的完整解决方案: Intel QuickAssist Technology（QAT），简称 Intel QAT 技术。

如下图所示，QAT 支持加速的密码算法覆盖了 TLS 的整个流程，包括：握手阶段的签名、秘钥交换算法，数据传输的 AES 加解密算法等。

QAT 提供了对称与非对称两类密码算法的支持，主要包括：

1. 非对称加密算法：RSA, ECDSA, ECDHE
2. 对称加密算法：AES-GCM(128,192,256) 

注：QAT 加速的优势主要体现在非对称加密上，从官方的整体性能数据看，非对称算法性能提升 1.6~2 倍，对称算法性能提升 10%~15%

2.1 QAT Engine 软件栈

QAT Engine 是 QAT 技术方案的核心模块，主要的作用是作为应用程序和硬件之间的中间层，负责 “加解密操作的输入输出数据” 在用户应用程序与硬件卡之间进行传递，主要操作就是IO的读写。

QAT Engine 是以 OpenSSL 第三方插件的方式提供给用户，这个意味用户可以使用 OpenSSL 标准的 API，就可以实现对 TLS 的加速，只需要对原有代码做 OpenSSL 异步改造，就可以享受 QAT 技术带来的 TLS 性能加速，业务侵入性较小。

如上图所示，QAT  Engine 支持两种加速方式：

• 软件加速（qat_sw）：使用 Multi-Buffer （SIMD）技术，对密码算法进行并行处理优化。
• 硬件加速（qat_hw）：使用 QAT 硬件加速卡，将密码算法计算从 CPU OffLoad 到硬件加速卡。

下面将介绍软件和硬件两种加速路径的实现方式。

三、软件加速：采用 Intel Multi-Buffer 技术

Intel 从 Whitely 平台开始加入了新的指令集，结合 Intel Multi-Buffer 技术，实现对密码算法的 SIMD 优化方案。

3.1 Intel Multi-Buffer 技术

Intel Multi-buffer 基本原理就是使用 CPU 的 SIMD 机制，通过 AVX-512 指令集并行处理数据，来提升RSA/ECDSA算法性能。

• SIMD (Single Instruction Multiple Data) 即单指令流多数据流，是一种采用一个控制器来控制多个处理器，同时对一组数据（又称“数据向量”）中的每一个分别执行相同的操作从而实现空间上的并行性的技术。简单来说就是一个指令能够同时处理多个数据。
• Multi-Buffer 技术基于 SIMD AVX-512 指令集，通过队列和批量提交策略，结合 OpenSSL 的异步能力，每次可以最多并行处理8个密码算法操作。

Intel 的 Multi-Buffer 方案，实际上是对应 Intel 两个开源工程（ Multi Buffer 技术实现的通用密码算法底层lib库），集成在 QAT Engine 里，从而实现软件加速。

1、IP SEC lib

• 提供了 Multi-Buffer 技术优化的对称加解密算法，如：AES-GCM
• 开源项目：https://github.com/intel/intel-ipsec-mb

2、IPP CRYPTO lib

• 提供了 Multi-Buffer 技术优化的 RSA/EDCSA/EDCHE 算法接口，基于 Intel® Advanced Vector Extensions 512 (Intel® AVX-512) integer fused multiply-add (IFMA) 指令实现SIMD优化。
• 开源项目：https://github.com/intel/ippcrypto/tree/develop/sources/ippcp/crypto_mb

简而言之，QAT 的软件加速的本质就是通过 AVX-512 指令集进行并行处理优化，针对并发场景性能有显著提升（下文有针对 Multi-Buffer 优化场景的性能测试）。

四、 硬件加速：采用QAT硬件加速卡卸载

除了通过 Multi-Buffer 技术进行软件加速外，QAT Engine 还支持 QAT 硬件加速卡，通过将密码算法的计算卸载（OffLoad）到硬件加速卡，实现性能加速。

硬件加速核心是将 TLS 中的非对称加解密操作剥离出来，放到硬件加速卡里计算，即解放了 CPU，同时专用的硬件加速卡也提供了更高的加解密性能，这是典型的硬件 OffLoad 技术方案。

下图为典型的 Nginx+ Intel QAT Software Stack + QAT 硬件加速卡的典型应用场景：

这个典型应用场景包括四个部分：

1. Nginx （Async Mode）:  Intel 基于官方 Nginx（Version 1.18）提供了 Patch，支持 Nginx 工作在 OpenSSL 的异步模式。Patch开源在：https://github.com/intel/asynch_mode_nginx
2. OpenSSL（支持Async Mode）:  OpenSSL-1.1.1 新增了 async mode 特性，应用层软件可以通过标准的 OpenSSL 接口，实现异步调用，提升性能。
3. QAT Engine:   OpenSSL Engine 插件。向下和 QAT API 交互，将处理请求提交给硬件。详见项目开源地址: https://github.com/intel/QAT_Engine
4. QAT Driver：QAT 加速卡的驱动程序。分为用户态和内核态两个部分。用户态的 LIB 库提供 QAT API，内核态的driver则直接和 QAT 硬件加速卡打交道。

Intel QAT 依赖了 OpenSSL 的两个特性 OpenSSL Async Mode 和 OpenSSL Engine：

• OpenSSL Async Mode 能够在 async_job 执行过程中，在等待加速卡结果的时候，将 CPU 让出去；如果没有开启 async 模式，调用 OpenSSL 函数会阻塞，CPU 会阻塞等待。
• OpenSSL Engine 则是提供了自定义注册加解密的方法，可以不使用 OpenSSL 自带的加解密库，指定调用第三方的加解密库。

基于两个特性，应用程序的加解密操作只需要保持使用原来相同 OpenSSL API，只需要做异步模式的兼容。另外，可以在调用 OpenSSL 的 API 时，指定到 Engine QAT上就行，不需要做任何额外的修改，就可以使用 QAT 卡进行加解密加速。

4.1 OpenSSL 的Async Mode特性

通过上面的介绍，我们可以看到 QAT 卡的本质是让一部分原本由 CPU 进行的计算转移到 QAT 卡上进行，因此提高 QAT 的利用率，降低 CPU 的切换开销和等待时间是性能最大化的核心工作。

OpenSSL 未启用异步ASYNC模式时，OpenSSL 调用是同步阻塞的，直到QAT_Engine返回结果。如下图的同步模式，在并发处理执行流的场景，大量CPU处于空闲等待的状态（图中虚线表示CPU处于空闲状态），无法有效地利用CPU。

OpenSSL 开启异步 ASYNC 模式后，OpenSSL 调用是非阻塞的。如下图的异步模式，OpenSSL 的调用不需要等待QAT_engine的处理完成，可以有效地利用 CPU，提高 QAT 的利用率，提升并发处理性能。

通过 OpenSSL 的同步和异步模式的对比，可以看到 OpenSSL-1.1.1 新增的异步 Async 特性，支持了异步非阻塞调用，提高了 QAT 的利用率，可以显著提升加解密性能。

4.2 QAT Engine ASYNC运行流程

接下来还有一个问题，CPU 如何知道 QAT 卡完成了计算呢？ 

Async模块为了达到并行的目的，在单线程中实现了协程（async job）。加解密操作抽象为job，多个job同时运行，使用协程进行调度。

在async job执行的过程中，当计算操作提交给QAT卡后，CPU 可以把当前任务暂停，切换上下文（保存/恢复栈，寄存器等）返回给用户态。

用户态需要主动去poll这个async job的状态，是否是ASYNC_FINISHED状态。如果是，说明之前的任务已经完成，则可以继续后面的操作（取回加密/解密结果）。

注：QAT Engine 通过轮询来获取QAT卡的计算状态，基本原理是启动一个线程，不停的调用qatdriver的polling api，轮询获取qat的计算状态，得到相应结果后，写入eventfd，唤醒async job。

如上图所示，QAT Engine Async的基本流程为：

1. 主 job 调用 SSL_accept，等待 TLS 客户端发起 TLS handshake。
2. SSL 内部组织了一个状态机，将握手，读写等操作抽象为两个job，ssl_io_intern(读写), ssl_do_handshake_intern(握手), 统一通过api ASYNC_start_job()进行job调度。这里启动了一个握手的job协程。
3. 握手job执行 RSA_sign 签名操作时，将sign算法卸载到硬件上计算。调用 ASYNC_pause_job()  切回主job, 并将job状态设置为 ASYNC_PAUSE ，这个时候 CPU 会交还给主 job 进行其它计算工作，同时 QAT 并行的进行自己的计算。
4. 主job通过SSL_waiting_for_async() 接口获得的一个eventfd，并epoll这个eventfd。当 QAT 卡计算完成，会执行回调写入eventfd，通知主job计算已完成。
5. 主job切换回握手job，握手job的完成剩余流程后，再调用ASYNC_pause_job()切换主job，并将job状态设置为ASYNC_FINISH，结束协程完成握手动作。

五、QAT 性能评测

通过上面的介绍，我们了解了 QAT 技术方案的基本原理，下面我们看下 QAT 的实际加速效果。

QAT Multi-Buffer 加速方案，依赖的 OpenSSL、QAT Engine、ipp-crypto、 Intel-ipsec-mb 软件栈都是开源项目，我们可以方便的使用 OpenSSL Speed 原生加解密算法对 Multi-Buffer 方案进行性能评估。

硬件环境

• Intel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHz
• CPU(s): 8

软件环境

• Linux Kernel: 4.19.91-24.1.al7.x86_64
• OpenSSL 1.1.1g
• gcc (GCC) 8.3.0
• cmake version 3.15.5
• NASM version 2.15.05
• GNU Binutils 2.32
• 安装 QAT Engine
• 安装 ipp-crypto、 Intel-ipsec-mb 开源lib库

测试数据

• numactl -C 0 ./openssl speed rsa2048
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 rsa2048

• numactl -C 0 ./openssl speed ecdhp384
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 ecdhp384

• numactl -C 0 ./openssl speed aes-256-cbc
• numactl -C 0 ./openssl speed -engine qatengine -async_jobs 8 aes-256-cbc

TLS 握手阶段的签名和秘钥交换算法

• RSA 2048 Sign/Verify  提升 4.9/2.9倍
• ECDH Key Exchange 提升 12倍

对称加解密算法

• AES-256-CBC 性能持平

根据性能测试结果，QAT 的加速优势在于 TLS 握手阶段的签名和秘钥交换算法，适合频繁进行 TLS 建连的应用场景，比如：Nginx 网关、长连接网关等。

六、总结

本文介绍了 Intel QAT 技术方案，并讨论了方案提供的 Multi-Buffer 软件加速以及 QAT 硬件加速两种方式。同时，通过性能评估测试，我们可以看到 QAT 技术对 TLS 握手阶段的加解密算法有显著的性能提升。

最后，我们讨论一下 Intel QAT 技术的优缺点和应用场景：

6.1 优点和缺点

主要的优点

• 高性能：可以显著提高计算密集型任务的性能，减少 CPU 的负载，提高系统吞吐量和响应速度。
• 低功耗：可以将计算密集型任务卸载到专用硬件上，降低系统功耗，提高能效比。

主要的缺点

• 成本较高：需要额外的硬件支持，增加了系统的成本。
• 应用范围受限：主要适用于计算密集型任务，对于其他类型的任务可能没有显著的性能提升。
• 不支持所有处理器：只支持 Intel 特定系列的处理器，需要特定的硬件和软件支持。
• 改造成本高：需要对应用程序进行 QAT 异步化改造，需要一定的学习成本和技术支持。

6.2 应用场景

除了加解密算法之外，Intel QAT 还支持压缩和解压缩、随机数生成、数字签名、视频编解码等算法。Intel QAT 主要可以用于以下场景：

• 接入网关：比如 Nginx 网关、长连接网关。QAT 可以加速 TLS 协议处理，提升网关的性能
• 虚拟私人网络（VPN）：QAT 可以加速 VPN 流量的加密和解密过程，提高吞吐量，减少延迟
• 存储加速：QAT 可以加速数据压缩和解压缩，减少需要传输和存储的数据量
• 视频编解码：QAT 可以加速视频编解码算法，提高视频处理的效率和质量

总的来说，Intel QAT 可以将计算密集型任务从 CPU 中分离出来，显著提高系统的性能和能效比，可以广泛应用于计算密集型任务的加速，包括网络安全、数据处理、云计算、存储加速、视频处理等多个领域。

参考资料

---

• Github：intel/QAT_Engine
• Intel® QuickAssist Technology (Intel® QAT)
• Intel® QuickAssist Technology & OpenSSL-1.1.0: Performance
• TLS
• Intel® Processor Architecture: SIMD InstructionsSIMD Instructions
• [openssl] openssl async模块框架分析
• TLS 加速技术：Intel QuickAssist Technology（QAT）解决方案
• Keyless SSL: The Nitty Gritty Technical Details
• TLS 加速技术：Intel QuickAssist Technology（QAT）解决方案

一. 引言

现在低功耗蓝牙（BLE）连接都是建立在 GATT (Generic Attribute Profile) 协议之上。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范，这些很短的数据段被称为属性（Attribute）。

二. GAP

详细介绍 GATT 之前，需要了解 GAP（Generic Access Profile），它在用来控制设备连接和广播。GAP 使你的设备被其他设备可见，并决定了你的设备是否可以或者怎样与合同设备进行交互。例如 Beacon 设备就只是向外广播，不支持连接，小米手环就等设备就可以与中心设备连接。

2.1 设备角色

GAP 给设备定义了若干角色，其中主要的两个是：外围设备（Peripheral）和中心设备（Central）。

外围设备：这一般就是非常小或者简单的低功耗设备，用来提供数据，并连接到一个更加相对强大的中心设备。例如小米手环。
中心设备：中心设备相对比较强大，用来连接其他外围设备。例如手机等。

2.2 广播数据

在 GAP 中外围设备通过两种方式向外广播数据： Advertising Data Payload（广播数据）和 Scan Response Data Payload（扫描回复），每种数据最长可以包含 31 byte。这里广播数据是必需的，因为外设必需不停的向外广播，让中心设备知道它的存在。扫描回复是可选的，中心设备可以向外设请求扫描回复，这里包含一些设备额外的信息，例如设备的名字。（广播的数据格式我将另外专门写一个篇博客来讲。）

2.3 广播流程

GAP 的广播工作流程如下图所示。

从图中我们可以清晰看出广播数据和扫描回复数据是怎么工作的。外围设备会设定一个广播间隔，每个广播间隔中，它会重新发送自己的广播数据。广播间隔越长，越省电，同时也不太容易扫描到。

2.4 广播的网络拓扑结构

大部分情况下，外设通过广播自己来让中心设备发现自己，并建立GATT连接，从而进行更多的数据交换。也有些情况是不需要连接的，只要外设广播自己的数据即可。用这种方式主要目的是让外围设备，把自己的信息发送给多个中心设备。因为基于GATT连接的方式的，只能是一个外设连接一个中心设备。使用广播这种方式最典型的应用就是苹果的iBeacon。广播工作模式下的网络拓扑图如下：

三. GATT

GATT 的全名是 Generic Attribute Profile（姑且翻译成：普通属性协议），它定义两个 BLE 设备通过叫做 Service 和 Characteristic 的东西进行通信。GATT 就是使用了 ATT（Attribute Protocol）协议，ATT 协议把 Service, Characteristic遗迹对应的数据保存在一个查找表中，次查找表使用 16 bit ID 作为每一项的索引。

一旦两个设备建立起了连接，GATT 就开始起作用了，这也意味着，你必需完成前面的 GAP 协议。这里需要说明的是，GATT 连接，必需先经过 GAP 协议。实际上，我们在 Android 开发中，可以直接使用设备的 MAC 地址，发起连接，可以不经过扫描的步骤。这并不意味不需要经过 GAP，实际上在芯片级别已经给你做好了，蓝牙芯片发起连接，总是先扫描设备，扫描到了才会发起连接。

GATT 连接需要特别注意的是：GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接。一旦外设被连接，它就会马上停止广播，这样它就对其他设备不可见了。当设备断开，它又开始广播。

中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。

3.1 GATT连接的网络拓扑

下图展示了 GTT 连接网络拓扑结构。这里很清楚的显示，一个外设只能连接一个中心设备，而一个中心设备可以连接多个外设。

 一旦建立了连接，通信就是双向的了，对比前面的GAP广播的网络塔扑，GAP通信是单向的。如果你要让两个外围设备能通信，就只能通过中心设备中转。

3.2 GATT 通信事务

GATT通信的双方是C/S关系。外设作为GATT服务端（Server），它维持了ATT的查找表以及service和characteristic的定义。中心设备是GATT客户端（Client），他向Server发起请求。需要注意的是，所有的通信事件，都是由客户端（也叫主设备，Master）发起，并且接收服务端（也叫从设备，Slava）的响应。
一旦连接建立，外设将会给中心设备建议一个 连接间隔（Connection Interval），这样，中心设备就会在每个连接间隔尝试去重新连接，检查是否有新的数据。但是，这个连接间隔只是一个建议，你的中心设备可能并不会严格按照这个间隔来执行，例如你的中心设备正在忙于连接其他的外设，或者中心设备资源太忙。

下图展示一个外设（GATT服务端）和中心设备（GATT客户端）之间的数据交流流程，可以看到的是，每次都是主设备发起请求：

3.3 GATT 结构

GATT事务是建立在嵌套的Profiles，Services和Characteristics之上的，如下如所示：

• Profile Profile并不是实际存在于BLE外设上的，它只是一个被Bluetooth SIG或者外设设计者预先定义的Service的集合。例如心率Profile（Heart Rate Profile）就是结合了Heart Rate Service和Device Information Sercvice。所有官方通过GATT Profile的列表可以从这里找到。

• Service Service是把数据分成一个个的独立逻辑项，它包含一个或者多个Characteristic。每个Service有一个UUID唯一标识。UUID有16bit的，或者128bit的。16bit的UUID是官方通过认证的，需要花钱购买，128bit是自定义的，这个就可以自己随便设置。

  官方通过了一些标准Service，完整列表在这里。以Heart Rate Service为例，可以看到它的官方通过16bitUUID是 0x180D，包含3个Characteristic：Heart Rate Measurement，Body Sensor Location和Heart Control Point，并且定义了只有一个第一个必须的，它是可选实现的。

• Characteristic 在GATT事务中的最低界别的是Characteristic，Characteristic是最小的逻辑数据单元，当然它可能包含一个组关联的数据，例如加速度计的X/Y/Z三轴值。与Service类似，每个Characteristic用16bit或者128bit的UUID唯一标识。你可以免费使用Bluetooth SIG官方定义的标准Characteristic，使用官方定义的，可以确保BLE的软件和硬件能相互理解。当然，你可以自定义Characteristic，这样的话，就只有你自己的软件和外设能够相互理解。

  举个例子，Heart Rate Measurement Characteristic,这是上面提到的Heart Rate Service必需实现的Characteristic，它的UUID是 0x2A37。它的数据结构是，开始8bit定义心率数据格式（是UINT8还是UINT16？），接下来就是对应格式的实际心率数据。

  实际上，和BLE外设打交道，主要是通过Characteristic。你可以从Characteristic读取数据，也可以往Characteristic写数据。这样就实现了双向的通信。所以你可以自己实现一个类似串口（UART）的service，这个Service中包含两个Characteristic，一个被配置只读的通道（RX），另一个配置为只写的通道（TX）。

更多内容

• Bluetooth SIG 官方文档

  • 蓝牙核心协议文档
  • Bluetooth Developer Portal
  • 官方通过的 BLE Profile
  • 官方通过的 BLE Service
  • 官方通过的 BLE Characteristic

• 移动开发资源

  • Android BLE GUIDE - Android developer 官网的入门文章，里面有实例代码和讲解视频。
  • Application Accelerator Kit - iOS, Android or Windows Phone 移动开发样例
  • 视频: Core Bluetooth 101 - WWDC 2012 关于 BLE 开发的视频。

参考链接

---

蓝牙BLE: GATT Profile 简介(GATT 与 GAP)

UWB中TOF测距法的公式推导

UWB常用测距方法有两种：飞行时间测距法（TOF）和到达时间差法（TDOA）。这里说一下TOF。

TOF

飞行时间法（Time of Flight，TOF）是一种双向测距技术，它通过测量UWB信号在基站与标签之间往返的飞行时间来计算距离。根据数学关系，一点到已知点的距离为常数，那么这点一定在以已知点为圆心，以该常数为半径的圆上。有两个已知点，就有两个交点。以三个已知点和距离作三个圆，他们交于同一个点，该点就是标签的位置。

TOF定位方式需要基站和标签往返通信，因此就造成了TOF功耗大大提高，续航时间相对较短.

TOF又分为两种：单边双向测距和双边双向测距。

单边双向测距

单边双向测距(Single-sided Two-way Ranging: SS-TWR)是对单个往返消息时间上的简单测量，设备A主动发送数据到设备B，设备B返回数据响应设备A。如下图所示：

单边双向测距的流程是这样的：设备A（Device A）主动发送（TX）数据，同时记录发送时间戳，设备B（Device B）接收到之后记录接收时间戳；延时 $T_{reply}$ 之后，设备B发送数据，同时记录发送时间戳，设备A接收数据，同时记录接收时间戳。

所以可以拿到两个时间差数据，设备A的时间差 $T_{round}$ 和设备B的时间差 $T_{reply}$ ，最终得到无线信号的飞行时间 $T_{prop}$ 如下：

$T_{prop}=\frac{1}{2}(T_{round}-T_{reply})$

两个差值时间都是基于本地的时钟计算得到的，本地时钟误差可以抵消，但是不同设备之间会存在微小的时钟偏移，假设设备A和B的时钟偏移分别为 $e_A$ 和 $e_B$ ，则飞行时间测量值为：

${\hat{T}}_{prop}=\frac{1}{2}[T_{round}(1+e_A)-T_{reply}(1+e_B)]$

于是测距误差如下：

$Error={\hat{T}}_{prop}-T_{prop}=\frac{1}{2}(T_{round}\cdot e_A-T_{reply}\cdot e_B)=\frac{1}{2}{T}_{reply}(e_A-e_B)+T_{prop}\cdot e_A$

因为 $T_{reply}>>T_{prop}$ , 所以可以忽略后一项，得到

$Error={\hat{T}}_{prop}-T_{prop}\approx \frac{1}{2}{T}_{reply}(e_A-e_B)$

由此可以看出，随着 $T_{reply}$ 和时钟偏移的增加，会增加飞行时间的误差，从而使得测距不准确。因此单边双向测距（SS-TWR）并不常用，但对于特定的应用，如果对于精度要求不是很高，但是需要更短的测距时间可以采用。注意 $T_{reply}$ 不仅仅是设备B接收到发送的时间，也包括装载数据和发送数据耗费的时间（UWB除了支持定位之外，也可以传输数据，标准可以装载128字节，扩展模式可以装载1024字节数据）。

双边双向测距

双边双向测距（Double-sided Two-way Ranging）是单边双向测距的一种扩展测距方法，记录了两个往返的时间戳，最后得到飞行时间，虽然增加了响应的时间，但会降低测距误差。

双边双向测距分为两次测距，设备A主动发起第一次测距消息，设备B响应，当设备A收到数据之后，再返回数据，最终可以得到如下四个时间差：$T_{round1}$ 、$T_{reply1}$ 、$T_{round2}$ 、$T_{reply2}$ ，如下图所示：

双边双向测距飞行时间计算方法：

由单边双向测距方法可得

$T_{prop}=\frac{1}{2}(T_{round1}-T_{reply1})$
$T_{prop}=\frac{1}{2}(T_{round2}-T_{reply2})$

所以

$\begin{array}{r}{T}_{round1}\times T_{round2}=(2T_{prop}+T_{reply1})(2T_{prop}+T_{reply2})=4T_{prop}^2+2T_{prop}(T_{reply1}+T_{reply2})+T_{reply1}{T}_{reply2}\end{array}$
$\begin{array}{r}{T}_{round1}\times T_{round2}-T_{reply1}{T}_{reply2}=4T_{prop}^2+2T_{prop}(T_{reply1}+T_{reply2})\\ =T_{prop}(4T_{prop}+2T_{reply1}+2T_{reply2})\\ =T_{prop}(T_{round1}+T_{round2}+T_{reply1}+T_{reply2})\end{array}$

于是可以得到如下计算 $T_{prop}$ 的公式：

$T_{prop}=\frac{T_{round1}\times T_{round2}-T_{reply1}\times T_{reply2}}{T_{round1}+T_{round2}+T_{reply1}+T_{reply2}}$

以上测距的机制是非对称的测距方法，因为他们对于响应时间不要求是相同的。下面分析双边双向测距飞行时间的误差：

$\begin{array}{r}{\hat{T}}_{prop}=\frac{T_{round1}(1+e_A)\times T_{round2}(1+e_B)-T_{reply1}(1+e_B)\times T_{reply2}(1+e_A)}{T_{round1}(1+e_A)+T_{round2}(1+e_B)+T_{reply1}(1+e_B)+T_{reply2}(1+e_A)}\\ =\frac{(4T_{prop}^2+2T_{prop}(T_{reply1}+T_{reply2}))(1+e_A)(1+e_B)}{4T_{prop}+2(T_{reply1}+T_{reply2})+(2T_{prop}+T_{reply1}+T_{reply2})(e_A+e_B)}\\ =\frac{2(1+e_A)(1+e_B)}{(1+e_A)+(1+e_B)}{T}_{prop}\end{array}$

于是

$T_{prop}=\frac{(1+e_A)+(1+e_B)}{2(1+e_A)(1+e_B)}{\hat{T}}_{prop}$
$\begin{array}{r}Error={\hat{T}}_{prop}-T_{prop}=(1-\frac{(1+e_A)+(1+e_B)}{2(1+e_A)(1+e_B)}){\hat{T}}_{prop}\\ =\frac{e_A+e_B+2e_A{e}_B}{2(1+e_A)(1+e_B)}{\hat{T}}_{prop}\end{array}$

因为 $e_A<<1$，$e_B<<1$，略去高次项，可得

$Error\approx \frac{e_A+e_B}{2}{\hat{T}}_{prop}$

由此可以看出，误差仅与钟漂和飞行时间有关。

假设一个使用场景：使用20ppm的晶体，UWB的工作距离范围为300m，则无线信号空中飞行时间大概为$1\mu s$，误差为$20\times {10}^{-6}\times 1\times {10}^{-6}=20\times {10}^{-12}=20ps$时钟误差是在ps级别的，换算为距离之后仅为6mm。

注意：响应时间是不需要相等的，也就是 $T_{reply1}$ 不一定要等于 $T_{reply2}$ ，这样对于MCU系统的处理带来了很多便利。

若双边双向测距方法响应时间对称，也就是 $T_{reply1}$ 和 $T_{reply2}$ 相等，飞行时间计算方法如下：

$T_{prop}=\frac{1}{4}(T_{round1}-T_{reply1}+T_{round2}-T_{reply2})$

这种方法比较简单，只是需要一些时间戳做加减法，但其难点在于，怎么保证 $T_{reply1}$ 和 $T_{reply2}$ 是相等的。

此种方法的误差分析如下：

$\begin{array}{r}{\hat{T}}_{prop}=\frac{1}{4}[T_{round1}(1+e_A)-T_{reply1}(1+e_B)+T_{round2}(1+e_B)-T_{reply2}(1+e_A)]\end{array}$
$\begin{array}{r}Error={\hat{T}}_{prop}-T_{prop}=\frac{1}{4}[(T_{round1}-T_{reply2})e_A+(T_{round2}-T_{reply1})e_B]\\ =\frac{1}{4}[2(e_A+e_B)T_{prop}+(e_A-e_B)(T_{reply1}-T_{reply2})]\end{array}$

因为 $T_{reply1}-T_{reply2}>>T_{prop}$ ，可忽略$T_{prop}$项，从而得到

$Error\approx \frac{1}{4}(e_A-e_B)(T_{reply1}-T_{reply2})$

可见此误差与响应时间差成正比。

参考链接

---

• UWB中TOF测距法的公式推导
• 基于UWB的增强非对称双边双向测距算法研究
• 基于UWB的增强非对称双边双向测距算法研究