首次定位時(shí)間（TTFF）是指從GNSS單元打開到能夠輸出具有給定性能級別的有效導(dǎo)航解決方案之間的時(shí)間。根據(jù)接收機(jī)的規(guī)格，用于驗(yàn)證導(dǎo)航解決方案的性能標(biāo)準(zhǔn)可以是跟蹤衛(wèi)星的數(shù)量（即用于2D或3D定位）/跟蹤星座或位置精度。該測試確定設(shè)備在各種潛在情況下對反復(fù)啟動(dòng)和關(guān)閉的反應(yīng)。

對于TTFF測試，接收機(jī)要測試的三個(gè)最重要的條件是冷啟動(dòng)、暖啟動(dòng)和熱啟動(dòng)。下表解釋了這三個(gè)啟動(dòng)條件的含義。

首次定位時(shí)間的測試建議：

• 每個(gè)接收機(jī)針對每個(gè)單元啟動(dòng)條件（冷、暖和熱）至少執(zhí)行200次TTFF測試，以確保有足夠的數(shù)據(jù)點(diǎn)來較為精準(zhǔn)的確定啟動(dòng)時(shí)間的典型值。（注意：GNSS接收機(jī)的規(guī)格通常需要平均值或95%置信度值）。通過自動(dòng)化測試，執(zhí)行的測試數(shù)量可以更高。

• 建議在不同的模擬場景（例如位置、歷書、時(shí)間）中評估接收機(jī)的TTFF，以應(yīng)對不同的星座配置。應(yīng)調(diào)整方案參數(shù)以匹配實(shí)際應(yīng)用的要求，如對于靜態(tài)或移動(dòng)車輛、存在多路徑和/或干擾的情況。

在有多個(gè)衛(wèi)星星座可用的時(shí)代（除了GPS以外，現(xiàn)在還有北斗、GLONASS，伽利略等衛(wèi)星導(dǎo)航系統(tǒng)），必須評估接收機(jī)支持的每個(gè)星座的TTFF。如果能夠在接收機(jī)上單獨(dú)激活每個(gè)星座，建議可以這樣測試接收機(jī)支持星座的TTF，但如果接收機(jī)沒有這個(gè)功能，也可以選擇在虹科Safran Skydel GNSS模擬器上進(jìn)行測試，一次啟用一個(gè)星座，但接收機(jī)的算法不會(huì)被優(yōu)化為搜索此可見星座的“僅信號”。

為了正確評估接收機(jī)的TTFF，有必要從大量場景點(diǎn)開始，并經(jīng)常更改模擬星座配置。為此，虹科Safran Skydel模擬器提供了強(qiáng)大的API，能夠自動(dòng)啟動(dòng)連續(xù)的Skydel場景，并向正在測試的接收機(jī)發(fā)送自動(dòng)關(guān)閉/啟動(dòng)命令。只需簡單的編程，就可以使用Skydel模擬器輕松實(shí)現(xiàn)TTFF測試的自動(dòng)化。

測試流程

在這個(gè)案例中，將評估u-blox? EVK-M8N接收機(jī)在多個(gè)TTFF場景中的性能。虹科Safran Skydel模擬器具備強(qiáng)大的靈活性，接收機(jī)可以很容易地在不同的星座模式和啟動(dòng)條件下進(jìn)行測試。例如，選擇驗(yàn)證單個(gè)星座（分別是GPS C/A和Galileo E1）以及混合模式（同時(shí)使用GPS和Galileo）在冷/熱啟動(dòng)條件下的性能。接收機(jī)性能還可以使用Skydel軟件的干擾功能在GNSS信號的采集和跟蹤期間激活干擾來進(jìn)行測量。對于每個(gè)性能點(diǎn)評估（一個(gè)星座在一個(gè)起始條件下），接收機(jī)將在200個(gè)不同的場景中啟動(dòng)5次。

測試設(shè)置

如下圖所示，設(shè)置虹科Safran Skydel模擬器的基本配置來進(jìn)行測試。GNSS 接收機(jī)使用USB電纜連接到控制器PC，由u-blox接收機(jī)的專有軟件界面管理連接。通過這種配置，Skydel模擬器和u-blox接收機(jī)可以在一臺(tái)PC上進(jìn)行輕松控制，而無需管理多個(gè)以太網(wǎng)接口。

系統(tǒng)設(shè)置完成后，首先使用Skydel GUI創(chuàng)建5種不同的模擬場景。每個(gè)場景都設(shè)置在地球上的不同位置，并使用不同的開始時(shí)間。這樣將確保在每個(gè)場景中都有一個(gè)單獨(dú)的GNSS星座。電離層和對流層傳播延遲是根據(jù)Klobuchar和STANAG模型定義的，所有其他誤差（如多路徑、時(shí)鐘隨機(jī)噪聲、偽距斜率）均被關(guān)閉。對于天頂上的GPS和伽利略參考衛(wèi)星，GNSS信號功率被設(shè)置為-50dBm（相當(dāng)于接收器輸入端的-110dBm），所有其他衛(wèi)星的功率會(huì)根據(jù)其仰角自動(dòng)調(diào)整。模擬持續(xù)時(shí)間是無限的，模擬場景的開始和停止時(shí)間將通過API進(jìn)行控制。

腳本概述

創(chuàng)建模擬器場景后，可以評估接收機(jī)的TTFF性能?？梢允褂霉δ軓?qiáng)大的虹科Safran Skydel API來實(shí)現(xiàn)相同的結(jié)果，而無需手動(dòng)執(zhí)行此操作。這個(gè)案例中使用的是Python API，除此之外，Skydel也附帶C++、C#以及Labview的API。以下Python命令作為示例提供，在實(shí)際使用中需要適應(yīng)配置，尤其是控制接收機(jī)的功能。

首先，從虹科Safran Skydel 庫中導(dǎo)入遠(yuǎn)程函數(shù)：

import skydelsdx from skydelsdx.commands import Open from skydelsdx.commands import Stop from skydelsdx.commands import Start from skydelsdx.commands import SetInterferenceChirp 創(chuàng)建Skydel遠(yuǎn)程模擬器的實(shí)例并連接到它： sim = skydelsdx.RemoteSimulator(True) sim.connect()

然后循環(huán)之前創(chuàng)建的 Skydel 場景，這里有5個(gè)不同的場景：

TTFFlist = [] for scnNumber in range(1, totalScnNumber + 1):

在循環(huán)中，在Skydel模擬器上打開第一個(gè)場景：

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

在這個(gè)案例中，激活了以L1為中心的線性調(diào)頻干擾，對于某些測試，其帶寬1MHz，掃描時(shí)間為100μs，J/S功率比為24dB。干擾可能已直接添加到此場景中，但為了保持啟用或禁用它的靈活性，可以使用遠(yuǎn)程命令添加干擾：

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

使用在計(jì)算所需TTFF啟動(dòng)量之間的函數(shù)來啟動(dòng)和停止Skydel場景。例如，這里對每個(gè)場景使用了40個(gè)啟動(dòng)：

• 對于所選星座

• 在定義的類型（冷、熱或熱條件）下

sim.start() TTFFlist = TTFFlist + TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype) sim.stop()

TTFFstart功能連接到u-blox接收機(jī)，設(shè)置星座模式，并通過內(nèi)存擦除重新啟動(dòng)接收機(jī)。在啟動(dòng)時(shí)間異常的情況下（即如果由于干擾功率高于規(guī)格而找不到GNSS信號），則為每種啟動(dòng)類型定義超時(shí)，然后函數(shù)在暖啟動(dòng)和熱啟動(dòng)條件下等待900秒，以從導(dǎo)航消息中檢索所有數(shù)據(jù)：

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()

然后，迭代所需的啟動(dòng)次數(shù)。在所選模式重新啟動(dòng)接收機(jī)之前，等待一段時(shí)間，以避免每次啟動(dòng)之間會(huì)出現(xiàn)的常見問題。然后，該函數(shù)等待接收機(jī)的修復(fù)并計(jì)算 TTFF。此功能將取決于對TTFF的定義（即位置計(jì)算中使用的衛(wèi)星數(shù)量、PDOP條件或規(guī)范中的其他標(biāo)準(zhǔn)）以及接收機(jī)的能力。在這里使用u-blox接收機(jī)自動(dòng)計(jì)算第一個(gè)2D修復(fù)的時(shí)間。

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個(gè)啟動(dòng)中每個(gè)啟動(dòng)的TTFF值（即40個(gè)場景中每個(gè)場景的5個(gè)啟動(dòng)）。使用Python pickler保存此列表，以便后續(xù)使用其它的工具進(jìn)行分析。在本文中使用了Pyplot，它為圖形數(shù)據(jù)分析提供了強(qiáng)大的開源庫。

測試結(jié)果

下圖提供了u-blox接收機(jī)在無論有無干擾的情況下在GPS C/A、Galileo E1和混合模式下冷啟動(dòng)時(shí)的性能，在每種情況下，TTFF都以平均值和95個(gè)百分位值的形式提供。本文的目的不是詳細(xì)分析u-blox接收機(jī)的性能，但在純GPS模式下TTFF的特定分布也是非常有趣的，由于GPS C/A導(dǎo)航消息的特殊結(jié)構(gòu)，其值集中在30秒左右。僅使用GPS的TTFF性能也優(yōu)于僅使用伽利略，因?yàn)镚PS星歷數(shù)據(jù)分組在導(dǎo)航消息的開頭，而它們分散在伽利略導(dǎo)航消息中。

最后，可以看到混合模式并沒有提高整體性能，因?yàn)樵诿糠N情況下，都必須解碼至少一個(gè)星座的星歷表。當(dāng)干擾被激活時(shí)，可以看到對性能的影響，在這種情況下，幾次采集時(shí)間超過35秒時(shí)，GPS信號似乎比伽利略信號受到干擾的影響略大。整體性能下降在一定程度上可以通過信號采集期間更多的漏檢來解釋，但主要是由于導(dǎo)航消息解碼中的位丟失或錯(cuò)誤。（注：星歷解碼中缺少一個(gè)位可能意味著需要等待下一個(gè)星歷周期）。

同樣的分析可以在熱啟動(dòng)條件或其他衛(wèi)星采集模式下進(jìn)行。

總結(jié)

本文解釋了如何使用虹科Safran Skydel GNSS模擬器評估TTFF（GNSS接收機(jī)與性能相關(guān)的關(guān)鍵功能）。本文通過一個(gè)簡單的例子突出了Skydel遠(yuǎn)程API的優(yōu)勢，它使用戶能夠非常輕松的執(zhí)行測試，而其他模擬器可能需要自定義工具或費(fèi)力的手動(dòng)測試程序。