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

對于TTFF測試，接收機要測試的三個最重要的條件是冷啟動、暖啟動和熱啟動。下表解釋了這三個啟動條件的含義。

首次定位時間的測試建議：

• 每個接收機針對每個單元啟動條件（冷、暖和熱）至少執(zhí)行200次TTFF測試，以確保有足夠的數(shù)據(jù)點來較為精準的確定啟動時間的典型值。（注意：GNSS接收機的規(guī)格通常需要平均值或95%置信度值）。通過自動化測試，執(zhí)行的測試數(shù)量可以更高。
• 建議在不同的模擬場景（例如位置、歷書、時間）中評估接收機的TTFF，以應對不同的星座配置。應調整方案參數(shù)以匹配實際應用的要求，如對于靜態(tài)或移動車輛、存在多路徑和/或干擾的情況。

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

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

測試流程

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

測試設置

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

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

腳本概述

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

首先，從虹科Safran Skydel 庫中導入遠程函數(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遠程模擬器的實例并連接到它：

sim = skydelsdx.RemoteSimulator(True) sim.connect()

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

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

在循環(huán)中，在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啟動量之間的函數(shù)來啟動和停止Skydel場景。例如，這里對每個場景使用了40個啟動：

• 對于所選星座
• 在定義的類型（冷、熱或熱條件）下

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

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

然后，迭代所需的啟動次數(shù)。在所選模式重新啟動接收機之前，等待一段時間，以避免每次啟動之間會出現(xiàn)的常見問題。然后，該函數(shù)等待接收機的修復并計算 TTFF。此功能將取決于對TTFF的定義（即位置計算中使用的衛(wèi)星數(shù)量、PDOP條件或規(guī)范中的其他標準）以及接收機的能力。在這里使用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保存此列表，以便后續(xù)使用其它的工具進行分析。在本文中使用了Pyplot，它為圖形數(shù)據(jù)分析提供了強大的開源庫。

測試結果

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

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

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

總結

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