轻松掌握基本GNSS测试——首次定位时间（TTFF）

最新推荐文章于 2023-11-02 23:16:30 发布

德思特

最新推荐文章于 2023-11-02 23:16:30 发布

阅读量431

点赞数

分类专栏：卫星通信车辆无线通信 GNSS模拟文章标签：无线通信通信射频工程网络 GNSS

本文链接：https://blog.csdn.net/hongke_weixin/article/details/131892553

版权

卫星通信同时被 3 个专栏收录

42 篇文章 6 订阅

订阅专栏

GNSS模拟

30 篇文章 4 订阅

订阅专栏

车辆无线通信

26 篇文章 0 订阅

订阅专栏

首次定位时间（TTFF）是指从GNSS单元打开到能够输出具有给定性能级别的有效导航解决方案之间的时间。根据接收机的规格，用于验证导航解决方案的性能标准可以是跟踪卫星的数量（即用于2D或3D定位）/跟踪星座或位置精度。该测试确定设备在各种潜在情况下对反复启动和关闭的反应。

对于TTFF测试，接收机要测试的三个最重要的条件是冷启动、暖启动和热启动。下表解释了这三个启动条件的含义。

首次定位时间的测试建议：

每个接收机针对每个单元启动条件（冷、暖和热）至少执行200次TTFF测试，以确保有足够的数据点来较为精准的确定启动时间的典型值。（注意：GNSS接收机的规格通常需要平均值或95%置信度值）。通过自动化测试，执行的测试数量可以更高。
建议在不同的模拟场景（例如位置、历书、时间）中评估接收机的TTFF，以应对不同的星座配置。应调整方案参数以匹配实际应用的要求，如对于静态或移动车辆、存在多路径和/或干扰的情况。

在有多个卫星星座可用的时代（除了GPS以外，现在还有北斗、GLONASS，伽利略等卫星导航系统），必须评估接收机支持的每个星座的TTFF。如果能够在接收机上单独激活每个星座，建议可以这样测试接收机支持星座的TTF，但如果接收机没有这个功能，也可以选择在虹科Safran Skydel GNSS模拟器上进行测试，一次启用一个星座，但接收机的算法不会被优化为搜索此可见星座的“仅信号”。

为了正确评估接收机的TTFF，有必要从大量场景点开始，并经常更改模拟星座配置。为此，虹科Safran Skydel模拟器提供了强大的API，能够自动启动连续的Skydel场景，并向正在测试的接收机发送自动关闭/启动命令。只需简单的编程，就可以使用Skydel模拟器轻松实现TTFF测试的自动化。

测试流程

在这个案例中，将评估u-blox™ EVK-M8N接收机在多个TTFF场景中的性能。虹科Safran Skydel模拟器具备强大的灵活性，接收机可以很容易地在不同的星座模式和启动条件下进行测试。例如，选择验证单个星座（分别是GPS C/A和Galileo E1）以及混合模式（同时使用GPS和Galileo）在冷/热启动条件下的性能。接收机性能还可以使用Skydel软件的干扰功能在GNSS信号的采集和跟踪期间激活干扰来进行测量。对于每个性能点评估（一个星座在一个起始条件下），接收机将在200个不同的场景中启动5次。

模拟器
Skydel	版本 17.1.7
软件定义无线电（SDR）	Ettus USRP X300
控制器电脑	Nvidia GeForce GTX 1080 Intel Core I7-6700K Windows 10 Pro

接收机

u-blox EVK-M8N

软件版本 EXT CORE 3.01

硬件版本 00080000

测试设置

如下图所示，设置虹科Safran Skydel模拟器的基本配置来进行测试。GNSS 接收机使用USB电缆连接到控制器PC，由u-blox接收机的专有软件界面管理连接。通过这种配置，Skydel模拟器和u-blox接收机可以在一台PC上进行轻松控制，而无需管理多个以太网接口。

系统设置完成后，首先使用Skydel GUI创建5种不同的模拟场景。每个场景都设置在地球上的不同位置，并使用不同的开始时间。这样将确保在每个场景中都有一个单独的GNSS星座。电离层和对流层传播延迟是根据Klobuchar和STANAG模型定义的，所有其他误差（如多路径、时钟随机噪声、伪距斜率）均被关闭。对于天顶上的GPS和伽利略参考卫星，GNSS信号功率被设置为-50dBm（相当于接收器输入端的-110dBm），所有其他卫星的功率会根据其仰角自动调整。模拟持续时间是无限的，模拟场景的开始和停止时间将通过API进行控制。

脚本概述

创建模拟器场景后，可以评估接收机的TTFF性能。可以使用功能强大的虹科Safran Skydel API来实现相同的结果，而无需手动执行此操作。这个案例中使用的是Python API，除此之外，Skydel也附带C++、C#以及Labview的API。以下Python命令作为示例提供，在实际使用中需要适应配置，尤其是控制接收机的功能。

首先，从虹科Safran Skydel 库中导入远程函数：

import skydelsdx

from skydelsdx.commands import Open

from skydelsdx.commands import Stop

from skydelsdx.commands import Start

from skydelsdx.commands import SetInterferenceChirp

创建Skydel远程模拟器的实例并连接到它：

sim = skydelsdx.RemoteSimulator(True)

sim.connect()

然后循环之前创建的 Skydel 场景，这里有5个不同的场景：

TTFFlist = []

for scnNumber in range(1, totalScnNumber + 1):

在循环中，在Skydel模拟器上打开第一个场景：

sim.call(Open(“yourScenarioPath {0}.sdx”.format(totalScnNumber), True))

在这个案例中，激活了以L1为中心的线性调频干扰，对于某些测试，其带宽1MHz，扫描时间为100μs，J/S功率比为24dB。干扰可能已直接添加到此场景中，但为了保持启用或禁用它的灵活性，可以使用远程命令添加干扰：

sim.call(SetInterferenceChirp(0, 0, 1.57542e+9, 24, 1e+6, 0.0001, True, "{8d18b359-1b21-44a6-b882-7b84e7dbadb4}"))

使用在计算所需TTFF启动量之间的函数来启动和停止Skydel场景。例如，这里对每个场景使用了40个启动：

对于所选星座
在定义的类型（冷、热或热条件）下

sim.start()

TTFFlist = TTFFlist + TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype)

sim.stop()

TTFFstart功能连接到u-blox接收机，设置星座模式，并通过内存擦除重新启动接收机。在启动时间异常的情况下（即如果由于干扰功率高于规格而找不到GNSS信号），则为每种启动类型定义超时，然后函数在暖启动和热启动条件下等待900秒，以从导航消息中检索所有数据：

def TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype):

u-blox = connectReceiver()

setReceiverMode(ublox, GNSSconstellation)

coldStart(ublox)

if TTFFtype == TTFFtypes.cold:

timeout = 90

time.sleep(900)

elif TTFFtype == TTFFtypes.warm:

timeout = 90

time.sleep(900)

elif TTFFtype == TTFFtypes.hot:

timeout = 15

sim.start()

TTFFlist = TTFFlist + TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype)

sim.stop()

然后，迭代所需的启动次数。在所选模式重新启动接收机之前，等待一段时间，以避免每次启动之间会出现的常见问题。然后，该函数等待接收机的修复并计算 TTFF。此功能将取决于对TTFF的定义（即位置计算中使用的卫星数量、PDOP条件或规范中的其他标准）以及接收机的能力。在这里使用u-blox接收机自动计算第一个2D修复的时间。

TTFFlist = []

for nb in range(1, runNumberForEachScn + 1):

if TTFFtype == TTFFtypes.cold:

time.sleep(random.uniform(0,30))

coldStart(ublox)

elif TTFFtype == TTFFtypes.hot:

time.sleep(random.random())

hotStart(ublox)

TTFF = waitForFix(ublox, timeout)

TTFFlist = TTFFlist + [TTFF]

disconnectReceiver(ublox)

return TTFFlist

TTFFlist包含200个启动中每个启动的TTFF值（即40个场景中每个场景的5个启动）。使用Python pickler保存此列表，以便后续使用其它的工具进行分析。在本文中使用了Pyplot，它为图形数据分析提供了强大的开源库。

测试结果

下图提供了u-blox接收机在无论有无干扰的情况下在GPS C/A、Galileo E1和混合模式下冷启动时的性能，在每种情况下，TTFF都以平均值和95个百分位值的形式提供。本文的目的不是详细分析u-blox接收机的性能，但在纯GPS模式下TTFF的特定分布也是非常有趣的，由于GPS C/A导航消息的特殊结构，其值集中在30秒左右。仅使用GPS的TTFF性能也优于仅使用伽利略，因为GPS星历数据分组在导航消息的开头，而它们分散在伽利略导航消息中。

最后，可以看到混合模式并没有提高整体性能，因为在每种情况下，都必须解码至少一个星座的星历表。当干扰被激活时，可以看到对性能的影响，在这种情况下，几次采集时间超过35秒时，GPS信号似乎比伽利略信号受到干扰的影响略大。整体性能下降在一定程度上可以通过信号采集期间更多的漏检来解释，但主要是由于导航消息解码中的位丢失或错误。（注：星历解码中缺少一个位可能意味着需要等待下一个星历周期）。

同样的分析可以在热启动条件或其他卫星采集模式下进行。

本文解释了如何使用虹科Safran Skydel GNSS模拟器评估TTFF（GNSS接收机与性能相关的关键功能）。本文通过一个简单的例子突出了Skydel远程API的优势，它使用户能够非常轻松的执行测试，而其他模拟器可能需要自定义工具或费力的手动测试程序。