前一篇文章主要描述了UWB测距过程中的蓝牙时间同步流程,本文主要研究在蓝牙时间同步过程中,手机端通过Procedure 0/1返回给车端的相关参数。可详见CCC规范的19.3.3章节。
在蓝牙时间同步过程中,无论是Procedure 0或1,均传递了7个参数给车端,具体如下表:
Message | Message ID | Patameters |
Time_Sync | 0x0D | DeviceEventCount, |
1、参数: DeviceEventCount
参数名称 | 长度(bytes) | 取值范围 | 描述 |
DeviceEventCount | 8 | 0 – | Procedure 0: Event count is 0 or in case of retransmission, close to 0. |
关于该参数我的理解是来源于BLE的event count参数,但蓝牙的event count才2个字节,这个参数有8个字节。所以我的理解应该是基于event count进行累计的一个参数。即当BLE的event count由0xFFFF滚回0时,该DeviceEventCount参数进位为0x10000,以此类推。
在Procedure 0流程中,Event count一般取值为0,或在重传的情况下取尽可能接近0的Event count。
在Procedure 1流程中,取LL_PHY_UPDATE_IND链路层消息使用的Event count。另外0xFFFFFFFFFFFFFFFF表示设备上的DeviceEventCount无效。
2、参数2: UWB_Device_Time
参数名称 | 长度(bytes) | 取值范围 | 描述 |
UWB_Device_Time | 8 | 0 – | UWB Ranging clock value in microseconds. This is running clock and shall remain valid for the entirety of the session. |
CCC标准中还有这么一句话:“UWB_Time0 (provided in the Ranging Session Setup Response or Ranging Recovery Response message) shall be consistent in time to the reference UWB_Device_Time. ”
关于该参数我的理解是在蓝牙时间同步阶段,手机端会将UWB_Device_Time发送给车端,达到车端与手机端时钟同步的目的。
之后,当要进行UWB测试时,手机端再将未来某个时刻打算发出prepoll的时刻(UWB_Time0 )告知车端 ,故车端可以在该时刻提前打开RX,以保证双方可以正常进行UWB信号交互。
3、参数3: UWB_Device_Time_Uncertainty
参数名称 | 长度(bytes) | 取值范围 | 文档描述 |
UWB_Device_Time_Uncerta | 1 | 0 – 0xFF | Time uncertainty between the anchor point of connection event and UWB Clock domain mapping. |
我的理解是,关于蓝牙时间同步,是通过蓝牙的LL层进行时间同步的。但是软件在不同层级,不同任务中是会存在一些时间误差(例如任务调度导致的误差)的,故会引入一定的时间不确定性,如下图。
即该时间来源于车端锚点的蓝牙连接事件与UWB时钟域映射之间的时间不确定性。
UWB_Device_Time_Uncertainty取值0-0xFF。
其对应的物理意义值为value[µsec] =2 (UWB_Device_Time_Uncertainty /8)
故其实际物理意义取值范围为20 - 2(255/8) µs,即即值范围为:1 µs - 1.094 hour
4、参数4: UWB_Clock_Skew_Measurement_available
参数名称 | 长度(bytes) | 取值范围 | 文档描述 |
UWB_Clock_Skew_Measure | 1 | 0 – 0x1 | This is used to inform the vehicle if the device has a clock system which allows the vehicle to estimate and correct for the UWB clock skew, based on DeviceEventCount and UWB_Device_Time information. In particular this requires that the device UWB clock is available at Procedure 0 and Procedure 1. |
我的理解是,通过该参数,手机端可以告诉车端,手机端是否允许车辆基于DeviceEventCount和UWB_Device_Time信息,来预估并纠正UWB时钟偏差。
这要求设备端的UWB时钟在Procedure 0 and Procedure 1必须是有效的。
值= 1:表示UWB时钟偏差测量有效
值= 0:表示UWB时钟偏差测量无效
5、参数5: Device_max_PPM
参数名称 | 长度(bytes) | 取值范围 | 文档描述 |
Device_max_PPM | 2 | 0-0xFFFF | Worst case clock skew of device UWB clock (with respect to nominal time). |
最大时钟偏差。该参数应该是用于手机端与车端彼此进行时钟纠偏。CCC标准中有明确说明,车端锚点必须进行时钟纠偏。具体描述如下:
After the first successful UWB packet is received by vehicle, the vehicle should use this to resynchronize the UWB clocks between device and vehicle. Therefore, the vehicle should apply worst-case PPM based on the smallest duration between:
- Latest successful UWB packet exchange until now
- Latest time sync until now
6、参数6: Success
参数名称 | 长度(bytes) | 取值范围 | 文档描述 |
Success | 1 | 0-0x2 | 0: The “Bluetooth LE Timesync” procedure has failed and the timesync message parameters are invalid. The vehicle should ask again to perform the “Bluetooth LE Timesync” after RetryDelay |
手机端反馈给车端,是否指示时间同步是否成功。
0:Procedure1 失败
1:Procedure1 成功 或 Procedure0 成功
2:Procedure0 失败
CCC标准19.4.4及19.4.5有相关示例与描述,具体可详见标准。
7、参数7: RetryDelay
参数名称 | 长度(bytes) | 取值范围 | 文档描述 |
RetryDelay | 2 | 0-0xFFFF | Unsigned 16bits. Value in milliseconds for minimum delay required by device until the vehicle should trigger a new “Bluetooth LE Timesync”. |
设备所需的最小延迟值(以毫秒为单位),直到车辆触发新的“蓝牙LE时间同步”。
即手机端通过该信息,告诉车端最快多久可以重新触发BLE时间同步流程。
微信号:耐思时刻
## 一起每天进步一点点 ##