CN100430748C - 高灵敏度的不经常使用的服务器 - Google Patents

Abstract

一个导航卫星接收机依靠一台网络服务器不时的提供在初始化过程中所需要的关键信息。导航卫星接收机精密的维持位置的不确定度sigmaPos处于150km以下。因此，至少每五分钟，导航卫星接收机使用一个网络连接下载所有运行的SV’s的所有的天文历表信息。通过运行一个带有软件补偿的晶体振荡器参考的实时时钟，电源中断时间的不确定度sigmaTime被保存在毫秒级别下。当接收信号电平即使是对强的人造卫星也低于-150毫瓦分贝时，这个信息在启动时立即有效，减少产生第一个方位的必要时间。

Description

高灵敏度的不经常使用的服务器

发明领域

本发明涉及导航卫星接收机，尤其涉及支持原本不经常地在计算机网络中完全自动的客户的方法与系统。

背景描述

全球定位系统(GPS)是由美国国防部花费超过13亿美元建立与运行的基于卫星的无线导航系统。24颗人造卫星环绕在地球的2,200千米高度内，他们分布在轨道上以致于在任意时刻任何用户至少可以看到6颗人造卫星。每一颗人造卫星以一个原子时钟为参考发送一个精确的时间和位置信号。一个典型的GPS接收机锁定在这个原子时钟，然后可以非常精确的测量信号到达它的时间延迟，接着就可以计算接收机和卫星的距离。来自至少4颗人造卫星的测量允许GPS接收机计算它的位置、速度、高度和时间。

当初始化时间或配率不确定度非常大的时候，高密度GPS接收机存在问题。当信号能量极度微弱时，发现信号能量会产生更小的步骤，而且在每一步的停留时间更长。因此有一个更好的本地参考振荡器的初始估计可以改进第一次修补时间。

信号电平高于-145毫瓦分贝的GPS接收机可以容易地锁定到一个强GPS人造卫星来解码NAV数据。这样产生SV的天文历表与位置。然后，需要在硬件编码阶段上形成总的伪随机序列。传统的GPS接收机决定整数毫秒，因此叫做z计数。

当信号电平大概在-145毫瓦分贝与-150毫瓦分贝之间时，一个实际的高灵敏度GPS接收机对于任何位置的定位都可以使用模式匹配的方法得到一个z计数或整数毫秒。

发明内容

因此本发明的一个目标是提供一个可以在信号电平低于-150毫瓦分贝时运行的高灵敏度GPS接收机。

简单的说，本发明的导航卫星接收机实施例依靠一个网络服务器不经常的在它的初始化过程中提供需要的关键信息。导航卫星接收机严格的维持它的位置不确定度，开始位置不确定度(sigmaPos)在150km以下。因此，至少每5分钟，导航卫星接收机使用一个网络连接下载所有正在运行的SV’s的所有天文历表信息。通过运行一个带有软件补偿的晶体振荡器基准的实时时钟，电源关闭时间的不确定度，开始时间不确定度(sigmaTime)被保持在1毫秒下。即使是对于最强的SV当接收机信号低于-150毫瓦分贝，这种信息在电源打开时立即可用，减少产生第一次定位的必要时间。

本发明的一个优点是提供导航卫星接收机的更快初始化的一种系统和方法。

本发明的另一个优点是提供改进灵敏度导航卫星接收机的一种系统与方法。

在读完下面的在多个附图中阐述的优选的实施例后，本发明的这些和其它的目标与优势对于本领域的普通人员将毫无疑问的很明显。

附图说明

图1是本发明的一个网络系统实施例的一个功能块图，其中一个服务器支持一个通过互联网进行信息通信的客户；

图2是本发明的一个导航平台实施例的一个功能框图，和

图3是本发明的一个灵敏度接收机方法实施例的一个流程图。

优选实施例的详细描述

图1说明在本发明的一个实施例中，一个网络系统100包括一个参考站点服务器系统102，一个GPS测量平台104，一个居间计算机网络106，例如因特网。服务器系统102包括一个导航卫星接收机，锁定到并正在跟踪导航卫星(SV’s)108、110、112的星群，这里面有一些对于GPS测量平台104是可视的。导航卫星的另一个星座，包括114和116，对于客户系统104是可见的。GPS测量系统平台104包括它自己的导航卫星接收机，但这种可能还没有锁定到并正在跟踪其导航卫星112、114和116星群。

一般的，本发明的GPS测量平台的实施例通过判断它们可以怎样脱离服务器独立的运行而被分为4种。一个自动客户可以通过从服务器106得到的仅仅最少的帮助，例如不同的更正数据，为用户运行和提供导航的解决方案。一个半自动客户需要更多的帮助，例如简化的天文历表和时间偏离计算的多项式模型。一个瘦客户停止在服务器106上所有的导航计算，从它的对于SV星座观察点基本地提供仅仅的观察到的测量。如果一个用户在那并且想看到它们，返回导航的解决方案进行本地显示。

客户的第4种类型是一个作为客户104被连接的高灵敏度GPS接收机，在这里被称为OMNI。在这里主要关心第四种类型。

图2显示的是本发明的一个OMNI客户导航卫星接收机网络的实施例，这里由标号200表示。OMNI客户导航卫星接收机网络包括至少一个被网络服务器204支持的导航平台202。

每一个GPS测量平台202典型的包括一个GPS天线206，一个低噪声放大器(LNA)208，一个GPS表面声波(SAW)过滤器210，一个带有中频(IF)表面声波过滤器212的无线电频率(RF)特定用途集成电路(ASIC)，一个数字信号处理器(DSP)216，一个参考晶体218，一个参考晶体温度传感器220。

一个自动客户222可以不从服务器204获取任何帮助向一个用户实现功能和提供导航解决方案。一个半自动客户需要更多的帮助，例如简化天文历表和时间偏离的计算多项式模型。一个瘦客户226不用它的本地主机进行导航解决方案处理。它仅停止在服务器204上的所有导航计算，从它的对于SV星座的观察点基本地仅提供现察到的测量。如果一个用户在那想看到它们，返回导航的解决方案进行本地显示。在一个瘦客户226内，数字信号处理器是一个和一些其它非GPS应用程序共享的部分。由于这些，多线程应用程序在客户端不需要，只执行简单的程序循环。

一个OMNI客户227几乎完全自动的运行，但是在计算机网络上阶段性的收集一个ephemeredes的完全集合。它在电源关闭阶段进一步运行保持在电源恢复后它的位置不确定度，sigmaPos在150km以下。这些条件允许高灵敏度操作，这里使用更好的搜索步骤找到信号功率，每一个步骤有一个长时间的停留。如果晶体振荡器218使用温度传感器220的温度测量进行了软件补偿，OMNI客户227也受益很大。每一次导航平台202电源打开时一个实时时钟被保持运行，精确到高于实际时间的一毫秒。

本地参考晶体振荡器218将有一个是温度的函数的频率偏差错误。参考晶体温度传感器220用来测量本地参考振荡器晶体218的温度。第一个用途是当导航平台202被初始化和跟踪SV’s时收集数据，在制造校准时建立曲线。随后的用途是在导航平台202在初始化并试图锁定到它的第一个SV时，提供一个索引值，因此一个九级多项式方程可以从存储的系数中计算。

服务器204典型的包括许多参考站点天线228和230，他们提供GPS信号输入到一个参考站管理器232。一个本地服务器234可以提供支持信息给半自动用户204、瘦用户226、OMNI用户227，以改善第一次定位时间和位置解决方案质量。在OMNI用户227运行在高灵敏模式的情况下，服务器204收集和发送的天文历表信息，在SV的信号电平在-150毫瓦分贝下时，能够定位任何位置。

本发明的一个实施例决定服务器204怎样和什么时候与一个OMNI用户联系，例如客户104和导航平台202。服务器联系在许多情况下一定是不经常和最小的，因为每字节通信花销很高或者网络仅是阶段性的可以接入。

基本的GPS时间单元被称作“z计数(z-zount)”。它是一个29比特的二进制数，它的十个最高有效位给出GPS星期数的二进制表示，它的十九个最低有效位给出以1.5秒为单位的星期时间(time-of-week)计数。在导航消息切换字中包括具有6秒时期(epoch)的TOW的缩短版本。当信号强度高的时候，z计数和导航数据比特转换时间(BTT)容易地通过收集NAV数据测量。BTT用来清除编码阶段的翻转。一般的低于20毫秒的部分应该适合。在BTT上的干扰比z计数的要多。但是z计数可以在编码阶段翻转时在一毫秒内关闭一小段时间。

OMNI用户需要一个好的时间资源减少sigmaTime到一毫秒之下。50赫兹的NAV数据可以用来做一个模式匹配，间接的找到时间。这样当在一个z计数不能被解调时可以提供一个具有足够时间资源的GPS接收机。如果在模式匹配时有足够的可信度，也可以决定在一个SV上的整数微秒，intMs。

如果开始时间的不确定度，sigmaTime大于+/-10毫秒，不得不在解决定位中使用所谓的大增量T术语(DT)。这样需要的SV的数量加一。当位置不确定度sigmaPos在150km以下，在SV上的intMs不可用时，可以使用一个gridfix方法。当sigmaTime大于10毫秒时一个非z定位类型被使用。

一个具有卫星历表(ephemeredes)的服务器发送一个完整的GPS历书，highAccAlm，而不是所有GPS SV’s的历书。服务器可以发送另一个完整的GPS历书mixAccAlm，包括目前没有跟踪的更老的ephemeredes。

更好的，实现一个WWserver服务器，它有整个GPS星座的持续观察能力。它有带有足够空间隔离的充足的参考站点，可以在同一时间观察世界上所有的SV’s。服务器204显示一个本地服务器LAserver有一个或多个参考站点，它可以现察整个GPS SV星座的一个子集。因此一个LAserver不可以提供highAccAlm，只可以提供mixAccAlm。

在启动后，历书将要包括实际历书的卫星历表(ephemeredes)。在一个12小时的循环后，一些历书将被以为卫星历表基础的历书取代。

可以收集信号电平直接下至-145毫瓦分贝的GPS SV的NAV数据。而且，可以在这个电平得出天文历表、z计数和BTT。在这个电平的SV’s可以脱离服务器独立运行，也可以在不需要开始位置的精确度时进行定位，例如任何位置定位时使用。模式匹配在于-145毫瓦分贝时开始时是必要的，可以在下至-150毫瓦分贝进行。可以因此获得一个z计数或者intMs，所以SV可以在任何位置的定位中使用。然而，在这种信号电平，天文历表需要在网络106上从服务器102上获取，或者从它们的其它资源中获取。在低于-150毫瓦分贝的信号电平时，NAV数据对于一个模式匹配不是足够可靠的。NAV数据必须从服务器102或204获取，这样微弱信号的SV’s只可以在不确定度少于150km时参与定位。

在初始的SV搜索期间，不需要天文历表级别的精确性。一个历书，或者降级的天文历表，足够预计预先定位所需的数据。定位也不需要天文历表级别的精确性。为定位的天文历表寿命定义一个超时。如果精确降级作为一个时间函数被适当地模型化，这种阈值可以被放松，仍旧保持重要的定位。寿命阈值可以是一个可以控制的参数，因此用户可以选择期望的性能的级别。

在第一次定位或者设置时间时需要来自服务器102的NAV数据的子帧数据。在那以后，客户104不再请求子帧。被客户104解码的NAV数据可以被发送给服务器102，用于服务器做模式匹配。

当三个或者更多的SV’s的信号电平高于-145毫瓦分贝时，OMNI客户104不需要一个服务器连接。如果一定要收集天文历表，第一次定位时间(TTFF)将更长。在一些情况下可以使用预先收集的卫星历表(ephemeredes)。

当预先收集的SV的卫星历表(ephemeredes)到手且sigmaPos低于150km时，OMNI客户104不需要一个服务器连接。SV需要的最小数目取决于sigmaTime。这样的时间不确定度可以通过使用一个对于温度偏差做了软件补偿的实时时钟(RTC)得到减少。因此需要三个具有这样的RTC的SV’s和四个没有RTC的SV。

否则，解决一个定位将需要OMNI客户104联系服务器102并请求可靠的信息。当SV信号在-145与-150毫瓦分贝之间且sigmaPos大于150km时，NAV数据子帧是需要的。这些SV需要intMs用来解决第一次定位。如果只有三个-145毫瓦分贝或者更弱的SV’s可用、没有其它更好的精确时间的装置时，可以使用模式匹配。然后使用一个有四个SV的所谓的非z定位。

当SV的信号不强于-145毫瓦分贝、他们的天文历表已经超时时，天文历表不得不被请求。在这样的情况下，希望有可能的最快TTFF。

一个主要的程序应用可以周期性的打开GPS接收机得到一次定位。这样决定从上一次定位开始接收机已经移动了多远，或者简单的决定GPS接收机是否离开了一个预定的地区。选择定位间的时间间隔保持sigmaPos在150km以内，因此在低于-145毫瓦分贝的虚弱SV上不需要intMs。这样扩展了在不需要一个服务器连接请求NAV数据子帧的情况下保持高灵敏度定位的能力。服务器请求的时间是可以修改的。当有足够的性能而没有请求时需要这样做，来提供一个静态的客户/服务器连接。

OMNI客户一定要估算它的数据、数据的寿命、搜索成功的可能性，例如SV的数目和信号电平。然后OMNI客户决定是否建立连接，请求什么数据。适应性可以被禁止，服务器连接可用通过明确的指令建立。一个主程序可以决定每一个小时进行一次服务器连接。因此，对于每五分钟所做的定位，第十二次定位将进行一次服务器连接。

在主程序收集数据然后通过统一的API推进客户的地方可以使用一个广播类型天文历表服务。客户可以被授权在一个对话中的任何时间建立一个服务器连接。

图3阐明了一个OMNI客户包含几个步骤的方法实施例，在这里用300表示。首先，在步骤302中，分析天文历表的可用性，决定有多少用于定位的拥有有用的天文历表的high-N SV。这样假定服务器历书，ServerAlm很好，可以获取high-N和允许精确的预定位。

在步骤304中，SV通过它们的接收信号强度被分为“G1”(高于-145毫瓦分贝)，“G2”(在-145毫瓦分贝与-150毫瓦分贝之间)，或者“G3”(低于-150毫瓦分贝)。

在步骤306中，计算搜索的SV数目，使用sigmaTime与sigmaPos决定一个定位是否可能。

在步骤308中，计算基于自身的信号电平、sigmaTime、sigmaPos需要NAV数据子帧的SV的数目。如果需要这些SV得到第一次定位。

在步骤310中，决定是否请求一个服务器连接。如果不，执行步骤312。如果需要一个服务器连接，有两种选项：最小的网络数据流量和无限制的。

步骤314从服务器请求最小量的数据。例如，如果得到的天文历表是当前的，而且有足够的时间在将来可用，那么在目前的对话中不需要对于它的服务器请求。

步骤316从服务器请求最大量的数据。而且，一般情况下请求尽可能多的数据，最大程度地运送到将来。这样可以明白服务器连接的数目是否应是最小量的。但是一旦在一个服务器对话中，可以请求尽可能多的数据。

步骤318计算定位。

本发明的一些实施例使客户对服务器握手可以控制和可以选择。给主程序的一个状态信息被发送，指出(a)天文历表的寿命和在目前的high-N中的一些SV是否已经过期了，(b)将一个SV的跟踪分类成G1、G2、G3，是否每一个SV都需要子帧，和(c)sigmaTime和sigmaPos。

在室内，高灵敏度操作可以维持和被跟踪的SV的ephemeredes可用的时间一样长，位置不确定度小于150km，因此可以在没有一个z计数的情况下获取一个定位。推荐使用一个精确的时间资源，例如一个实时时钟(RTC)，因为非z定位方法使SV’s的数量加一。例如，五个做三维定位的SV，和四个做二维定位的SV。一个位置定位可以使用信号测量计算，它们原本十分微弱以致于不能解调50比特每秒的GPS导航数据流。

对于一个合理的第一次定位时间(TTFF)应该包括一个软件补偿的晶体振荡器(SCXO)。如果TTFF不是这么的重要，可以扩展频率搜索窗口搜索出一个更大的频率错误。如果信号足够强，可以可靠的解调接收机中的数据，那么位置范围可以扩展到150km以上。

RTC即使在客户程序没有运行的时候也可以维持一个从上一次定位获得的毫秒级别的精确性，仅有的代价是在睡眠电源消耗上的一个微小的增长。

在本发明的实施例中，如果信号足够强可以独立的解调导航数据。这样在目前的STI或全球定位设计中是不可能的，除非他们也添加了一个常规的跟踪能力。

没有服务器，高灵敏度位置定位只有在像最近观察到的信号一样露天的时候才能实现，例如在最后的四小时内。这是因为可视卫星不断改变，并且从上一个SV轨道获得的天文历表精确度将下降。每一个轨道的下降级别是一个重要的问题。宇宙飞船的轨道和卫星时钟的轨道都需要精确的模拟。一些有历史的模型可以扩展天文历表的可用性到12-16小时的范围。这样可以在某种程度上改善性能，但是定位的精确度仍旧很难预计。

以前的技术情况下高灵敏度接收机依靠到一个服务器的持续连接。这些设计从网络上获得频率，它们的硬件没有收集天文历表的能力。这种固定的服务器通信维持起来代价很大。

实际上没有服务器偶尔的帮助，很难一直维持高灵敏度GPS导航。服务器提供将来的天文历表和作为一个时间源的用于模式匹配的子帧。因此，在定位之间不使用RTC来节省一些电源消耗是有可能的，但是在电源上的节省相对很小。如果从上一次定位到现在已经是好多天，那么需要子帧作为可选择的时间源，因为RTC的精确度有可能开始下降。

如果GPS接收机查询它的可用数据，服务器升级间的时间可以是最短的。一个呼叫只有在下面情况下发送给服务器：天文历表数据已经过期，信号微弱，从上次定位到现在的时间超过了限制。如果GPS接收机正在跟踪强SV’s，那么服务器呼叫被延期，观察是否可以收集天文历表和计算定位。

z计数和BTT通过收集NAV数据进行测量。OMNI客户使用BTT来清除编码阶段的翻转。一般的低于20毫秒的部分应该适合。在BTT上的干扰比z计数的要多。但是z计数可以在编码阶段翻转附近在一毫秒内关闭一小段时间。

需要50Hz的NAV数据子帧进行一次模式匹配。这样可以在OMNI客户不能解调一个z计数时提供一个接收机时间源。如果在匹配中有足够的可信度，也可以潜在地提供一个在一个SV上的整数毫秒。OMNI客户需要定义一个将提供这个可信度的模式匹配条件。

整数毫秒(intMs)来自于OMNI客户，或者通过解调一个z计数，或者通过一个高可信度模式匹配。sigmaPos是开始定位不确定度。sigmaTime是开始时间不确定度。当大于+/-10毫秒时，OMNI客户不得不在定位中包括大增量T项(DT)。这样使SV的需要的数量加一。当位置不确定度-sigmaPos在150km以下，OMNI客户在SV’s上没有intMs时，gridfix-cancel b：定位方法可以使用。

非z定位：这是当sigmaTime大于10毫秒时的定位类型。OMNI客户解决在定位中的大增量T项(DT)。

highAccAlm：这是一个由服务器发送的完整的GPS历书，但是它是带有卫星历表(ephemeredes)而不是所有GPS SV的历书。

mixAccAlm：这是一个由服务器发送的完整的GPS历书，但是它带有的是目前没有跟踪的SV的以前的天文历表。

WWserver：这是一个有整个GPS星座的持续观察能力的服务器，因为它有带有足够空间隔离的充足的参考站点，可以在同一时间观察所有的SV’s。

LAserver：这是一个有一个或多个参考站点的本地服务器，它仅仅可以观察整个GPS SV星座的一个子集。它不可以提供highAccAlm，只可以提供mixAccAlm。在打开后，历书将要包括实际历书和卫星历表(ephemeredes)。在一个12小时的循环后，一些历书将被以天文历表为基础的历书取代。

ServerAlm：这是一个完整的历书，可以是一个highAccAlm，或者一个mixAccAlm，这取决于OMNI客户有一个WWserver还是一个LAserver。

降级的天文历表：在一个关于天文历表Toe(天文历表时间)的预定义的寿命后，OMNI客户忽略天文历表中的正弦阶段，历书的精确度模式降低到历书的有效精确度。

定义下面的信号级别和可以收集什么数据：

G1：OMNI客户可以收集高达-145毫瓦分贝的NAV数据。OMNI客户在这个级别也可以收集天文历表、z计数和BTT。在这个级别的SV’s可以脱离服务器独立运行，也可以在不需要开始位置精确度的定位中(任何位置定位)使用。

G2：OMNI客户可以做上至-150毫瓦分贝的模式匹配。这意味着OMNI客户可以得到一个z计数或者intMs，因此SV可以参与一个任何位置的定位。然而在这个级别，OMNI客户需要从一个可选择的资源得到天文历表。

G3：在-150毫瓦分贝级别下，NAV数据对于一个模式匹配不是足够可靠。OMNI客户一定要从服务器得到NAV数据，这些SV’s只可以参与不确定度是150km或者更好的定位。

对于搜索来说，OMNI客户不需要天文历表级别的精确度。一个历书(或者降级的天文历表)足够预计预定位所需的数据。

对于定位来说，OMNI客户不需要天文历表级别的精确度。OMNI客户目前对于定位的天文历表寿命定义一个时限。如果OMNI-客户能够适当地模型化作为时间函数的精确度降低，OMNI用户可以放宽这个阈值，而仍旧保持可信的定位。OMNI客户可以使寿命阈值是一个可以控制的参数，因此用户可以选择期望的性能级别。

对于第一次定位或者设置时间，为了做一个模式匹配需要来自服务器的子帧数据。在那次以后，OMNI客户不需要继续请求子帧。

OMNI客户应该考虑发送解码的NAV数据到服务器，让服务器做模式匹配，将结果发送回来。这样会有更少的数据。OMNI客户应该请求这个工作被计划为一个服务器项目，对于半自动客户也一样。为了灵活性OMNI客户应该保持两种方法。

OMNI客户不需要一个服务器连接的情况：

OMNI客户有3个或更多的G1 SV’s。TTFF太长，当然是在如果OMNI客户需要收集天文历表的情况下。

在一些情况下，OMNI客户可以重新使用以前收集的天文历表。

OMNI客户有足够的G1-G3 SV’s，OMNI客户对于这些SV’s有以前收集的ephemeredes，sigmaPos低于150km。

SV’s的最小数量：

三个带有RTC的SV’s

四个不带有RTC的SV’s

如果不满足这些上面的条件，那么OMNI客户将需要联系服务器获得一次定位。然后OMNI客户定义需要请求什么数据。

OMNI客户需要请求子帧的情况：

OMNI客户有G2 SV’s且simmapos大于150km。OMNI客户需要得到这些SV’s的intMs，为了使它们能够参与第一次定位。

OMNI客户仅有3个G2或者更虚弱的SV’s，OMNI客户没有其它精确时间的装置。如果可能的话OMNI客户将通过模式匹配来完成。

[OMNI客户可以进行带有四个SV的非z定位]

OMNI客户不得不请求天文历表的情况：

OMNI客户有G2或者更虚弱的SV’s，它们的天文历表已经超时。

OMNI客户想得到可能的最快TTFF。

一个主程序可以决定周期性地打开接收机，得到一次定位。一般的它尽力决定从上一次定位开始接收机已经移动了多远，或者GPS接收机是否离开了一个预定的地区。

选择定位间的时间间隔保持sigmaPos在150km以内，因此OMNI客户在虚弱的SV’s(G2，G3)上不需要intMs。这样扩展了在不需要一个服务器连接请求子帧的情况下保持高灵敏度定位的能力。

服务器请求是可以修改的。当有足够的性能而没有请求时需要提供一个安静的客户/服务器连接。这意味着客户一定要估算它的数据、它的寿命、搜索成功的可能性(SV的数目和信号电平)。基于这个数据，它决定是否建立连接，请求什么数据。

可修改性可以被禁止，服务器连接可用通过明确的指令建立。一个主程序可以决定每一个小时进行一次服务器连接。因此，OMNI客户每五分钟进行一次定位，第十二次获得一个服务器连接。

在主程序收集数据然后通过统一的API推进客户的地方，OMNI客户可以执行一个广播类型天文历表服务。

OMNI客户也可以使客户在一个会话中的任何时间建立一个服务器连接。

在位置sigma已经增长到150km以上的情况下，可以使用模式匹配计算整数毫秒。OMNI客户组合下面的数据放到一个算法，计算整数毫秒。一个模式匹配的偏差是及时搜索使解调数据比特与服务器提供的子帧数据相关的结果。OMNI客户将使用估计器中的重复的结果。每次OMNI客户得到一个模式匹配就产生一个匹配格式好比特计数器，OMNI客户可以看到多少比特是一致的。OMNI客户使用这个来衡量每个模式匹配的可信度。然后OMNI客户将组合这些结果做一个全面的估算。

BBT的结果和状态从TSM直方图中形成。BTT是整数毫秒中的低于20毫秒部分的一个估算。它可以用来过滤模式匹配中计算的intMs或者作为独立的验证器。OMNI客户可以监视编码阶段寻找翻转。OMNI客户需要这个来允许整数毫秒改变1毫秒。OMNI客户可以使用多普勒效应确认整数毫秒改变的方向。

当sigmaPos大于150km时，OMNI客户将采用下面的策略。

OMNI客户首先看OMNI客户是否具有带有能够测量z计数的天文历表的足够强的SV’s。OMNI客户可以在下至-145毫瓦分贝做这件事。如果OMNI客户有足够的这种SV’s，OMNI客户将不会做一个服务器请求。

如果OMNI客户没有足够强的SV’s(-145毫瓦分贝和更高)，OMNI客户正在跟踪更弱的SV’s，那么OMNI客户一定进行一个服务器请求，因为格式模式方法是OMNI客户不得不计算intMs的唯一方法。

当sigmaPos低于150km时OMNI客户将采用下面的策略。

如果OMNI客户基于我们的时间资源具有足够的SV’s，它们的天文历表是最新的，OMNI客户不作一个服务器请求。

如果OMNI客户具有强SV’s并且能收集天文历表，那么OMNI客户不会进行一个服务器请求。这样会使TTFF慢下来。因此，OMNI客户可以忽略这个，总是请求天文历表加快TTFF。

OMNI客户首先定义一个最小时间间隔(OMNIminRequestInterval)以致于OMNI客户请求数据不会比这个周期更快。这仅提供给同样的对话。应该使用周期性的定位速率限制会话间的请求。

OMNI客户决定OMNI客户正在跟踪的SV’s的状态。OMNI客户通过或不通过更新的天文历表来计算SV’s的数量。OMNI客户还可以根据SV是否足够强到收集好NAV数据来计算数量。

OMNI客户决定RTC是否是新的。如果是而且sigmaPos低于150km，那么它减少OMNI客户需要进行定位的SV’s的数量。

OMNI客户也检查一个二维定位对于OMNI是不是对的。如果配置了，那么OMNI客户也减少OMNI客户需要的SV’s的数量，可能最小化服务器业务。然而，根据客户操作接收机的位置，OMNI客户的位置精确性也可能降低。

如果sigmaPos少于150-km，OMNI客户计算所需的SV数。

如果天文历表数足够，则OMNI客户不联络服务器。

如果OMNI客户有足够的强的SV，OMNI客户等待收集数据并且OMNI客户不联络服务器。如果一个较快的TTFF被请求，则noServerIfStrong比特被置位，并且OMNI客户将请求天文历表而不是等待收集它。

如果OMNI客户没有足够的可用SV，则OMNI客户先等待一段时间，以确保OMNI客户已经给了完成的搜索时间。等待之后，OMNI客户继续逻辑。

现在OMNI客户已经确定没有来自服务器的一些数据OMNI客户不能进行定位。如果有足够的SV跟踪，OMNI客户只和服务器连接，使得服务器通信将保证OMNI客户能进行一次定位。可是，如果OMNI客户仅跟踪一个或者两个SV’s，那么一个服务器连接无论如果也没有帮助，因此OMNI客户只能等待条件改变。

如果OMNI客户正在跟踪的带有新天文历表的SV’s和OMNI客户正在跟踪的没有新天文历表的SV’s的组合足够得到一个定位，那么OMNI客户决定连接到服务器。然后OMNI客户决定收集什么数据。

一个选项是请求所有天文历表。这样优化将来的定位时间，也可以最小化OMNI客户再一次快速请求的可能性。

第二个选项是仅请求所有不是新的天文历表，全部来自于32。这样将减少服务器业务，但是可能意味着当一个新的SV被看到时OMNI客户不得不很快的再选择。

第三个选项是仅请求那些目前可见的但不是新的。这样会进一步减少服务器流量，但是将意味着OMNI客户将不得不很快请求数据。

然后OMNI客户决定OMNI客户是否需要子帧数据。只有当sigmaPos低于150km时，OMNI客户有下面提供的选项：

如果OMNI客户有RTC而且OMNI客户被配置为当RTC是正常的时候永不请求子帧，那么OMNI客户不会请求子帧。这通过subframeRequestConfig的noSubframeWithFreshRTC比特选择。如果OMNI客户有一个强SV，那么OMNI客户可以等着接收一个z计数，如果OMNI客户设置subframeRequestConfig的noSubframeWaitForZcount比特。

如果OMNI客户有5个SV’s，那么OMNI客户可以强制一个非z定位，如果subframeRequestConfig的noZfixInsteadOfPatternMatch比特被设置，可以不请求子帧。

OMNI用户也可以设置subframeRequestConfig的noSubframesEver比特，以致于OMNI客户永不请求子帧。

在OMNI客户有好的三维定位后OMNI客户也永不请求子帧，因为OMNI客户在这点以后不需要测量intMs。

如果OMNI客户决定收集子帧，那么OMNI客户有下面选项：

请求所有使用在subframeRequestConfig的allHighNsubframes比特的所有子帧。

仅请求带有onlyStrongestSV比特的最强SV的子帧。这样将明显只有在sigmaPos低于150km时提供。

请求带有具有onlyAboveThresh比特的一个指定范围的EMU的SV’s的子帧。这样是有用的，因为OMNI客户对于最强的SV’s不需要子帧，除非OMNI客户努力加快TTFF，因此OMNI客户可以减少服务器量。

如果sigmaPos＞150km，主要的不同是OMNI客户需要在第一次定位中任何卫星的整数毫秒。OMNI客户或者通过解码一个z计数、或者通过弱SV’s的一个专门的模式匹配算法得到它。因此，如果太多的SV’s是虚弱的，或者没有足够的强度，OMNI客户被强制与服务器通信。

OMNI客户基于二维比特fix2Dokay计算SV’s的数量。因为OMNI客户不作非z计数，OMNI客户仅需要4颗SV’s做一个三维定位或者3颗SV’s做一个二维定位。

如果OMNI客户有足够强的SV’s，OMNIconfig比特noServerIfStrong被设置，那么OMNI客户可以做一个没有服务器的定位。

否则，OMNI客户不得不连接到服务器。可是，在sigmaPos低于150km时，OMNI客户只在OMNI客户正在跟踪足够的SV’s且有可能得到一个定位时连接。

如果OMNI客户没有足够的可用SV’s，那么OMNI客户首先等待一个阶段期确保OMNI客户已经给出要完成的搜索时间。在等待以后，OMNI客户继续这逻辑。

现在OMNI客户已经决定OMNI客户不能进行一次定位。OMNI只有在有足够多SV’s跟踪的时候与服务器连接，以致于服务器通信会确认OMNI客户可以进行定位。但是，如果OMNI客户仅跟踪一个或者两个SV’s，那么一个服务器连接无论如何也没有帮助，因此OMNI客户只有等到条件改变。

如果没有天文历表的SV’s跟踪的数量与有天文历表的数量足够进行定位，那么OMNI客户将与服务器连接。否则OMNI客户会等待。

如果数量够用，OMNI客户首先检查OMNI客户需要什么天文历表。正如在低于150km情况的描述的情况下，OMNI客户为选择的requestAllEphem、requestAllNotFresh、requestTrackNotFresh的调节提供比特掩码。

既然OMNI客户没有在进行定位，那么OMNI客户对于虚弱的SV’s也要收集一些子帧。OMNI客户提供两个比特掩码(allHighNsubframes，onlyAboveThresh)决定调节这个应用程序。

OMNI客户查看配置决定怎样请求校正模型，例如得到OMNI客户的DGPS定位。OMNI客户有三个配置。

OMNI客户总是请求一直在correctionsRequestConfig字节中的比特DGPS的校正，即使OMNI客户决定不连接到卫星历表或者子帧的服务器。

可选择的，可以请求带有DGPSnormal比特DGPS校正，只有当OMNI客户已经决定对于卫星历表或者NAV数据进行服务器连接。

通过在OMNIconfig比特中的requestSPV和requestASPV比特得到SPV和ASPV数据。

下面的伪代码描述了一个客户可以在四种不同的基本下使用服务器：AUTO、半自动、THIN和OMNI。

Pseudocode

If(OMNImodeControl & OMNIno)＝0

     not in omni mode

     If(auto client)never make server request

     Else if(半自给)always make server request

     Else if(thin)always make server request

     Return

}

/*在运行OMNI模式时提供下面的逻辑。可选择的服务器请求基于

/*检查最小的服务器请求间隔*/

if(delta time since last server request＜OMNIminRequestInterval){

         /*在请求间等待一个最小时间*/

         return

}

/*计算目前OMNI客户所在的强SV′s的数量*/

num TrackStrong＝0

for(I＝0；I＜trackListCnt；I++)

        if(SV[I]is tracking &&(outdoor EMU[I]＞thresh to collect NAV-data))

                       numTrackStrong++

/*计算带有和没有卫星历表的跟踪SV′s的数量*/

numTrackWithEph＝0

numTrackStrongWithEph＝0

numTrackWeakWithEph＝0

numTrackWithoutEph＝0

numTrackStrongWithoutEph＝0

numTrackWeakWithoutEph＝0

for(I＝0，I＜trackListCnt；I++){

       if(SV[I]is tracking){

              if(ephemAge[I]＜fresh ephem threshold)){

      /*卫星历表为新*/

      numTrackWithEph++

      /*也要辨别带有ephem的强弱*/

      if(outdoor EMU[I]＞thresh to collect NAV-data))

             numTrackStrongWithEph++

      else

             numTrackWeakWithEph++

else{

      /*卫星历表不是新的*/

      numTrackWithoutEph++

      /*也要辨别带有ephem的强弱*/

      if(outdoor EMU[I]＞thresh to collect NAV-data))

             numTrackStrongWithoutEph++

      else

             numTrackWeakWithoutEph++

      }

   }

}

/*定义RTC精确度足够好，可以设置时间到+/-10msec.*/

if(time RTC has been running＜thresh)freshRTC ＝TRUE

else freshRTC＝FALSE

/*确定现在OMNI客户是否连接*/

if(sigmaPos＜150-km){

       /*

       在这个级别，OMNI客户将使用grid搜索方法。这不需要每个SV的整数毫秒。

因此只要OMNI客户不需要子帧得到时间，OMNI客户不会请求它们

       */

/*

确定使用grid搜索会得到一个三维定位需要的SV′s的数量。如果OMNI客户有一个足够强SV得到一个z计数，或者有好的RTC时间，只需要4个。否则OMNI客户使用需要五颗SV′s进行三维定位的非z定位方法。

*/

if(strongCnt or freshRTC)numNeeded＝4

else numNeeded＝5

/*如果API可以输入高度或者二维定位是确定的，将需要的数量减一。*/

if(userInputAltitude or fix2Dokay)numNeeded＝numNeeded-1

       /*

       在OMNI客户有足够的带有天文历表的SV′s或者很强可以收集天文历表的SV′s的处的处理情况。

       */

       if((numTrackWithEph＞＝numNeeded)||((OMNIconfig & noServerIfStrong)

       &&(numTrackWithEph+numTrackStrongWithoutEph＞＝numNeeded))))

           /*无需联络服务器*/

           needServerContact＝FALSE

       else{

           /*OMNI客户需要从服务器获取数据*/

           needServerContact＝TRUE

           /*

           首先确定在OMNI客户请求之前对于所有的high-N SV′s，OMNI客户至少已经等了整个搜索范围一遍。好处在与在OMNI客户请求一个服务器升级之前OMNI客户已经努力获得了在定义的第一次搜索上的所有SV′s。

           */

           if(has not received didOnePass for first search of high-N with indoor

           sensitivity){

                    wait before contacting server

                    return

           }

           /*

           只有在OMNI客户正在跟踪SV′s和它有很高的可能性给我们足够的SV′s得到一个定位的时候提出请求。

*/

if((numTrackWeakWithoutEph＞0)

&&((numTrackWeakWithoutEph+numTrackWithEph)＞＝numNeeded)))

     /*

     联系服务器会有帮助。现在OMNI客户需要决定OMNI客户需要收集什么。

     */

     /*根据配置的情况得到卫星历表。*/

     if(ephemRequestCodig & requestAllEphem)

            request all current ephemeris

        else if(ephemRequestConfig & requestAllNotFresh)

               request all SV′s whose ephem age is old

        else if(ephemRequestConfig & requestTrackNotFresh)

               request all SV′s tracking whose ephem age is old

        else

               don’t request any ephemeris

        /*寻找避免得到子帧的原因*/

        If(((freshRTC＝TRUE)&&(subframeRequestConfig

                     & noSubframeWithFreshRTC))

        ||((numTrackStrong＞0)&&(subframeRequestConfig

                     & noSubframeWaitForZcount))

        ||((numTracking＞＝5)&&(subframeRequestConfig

                     & noZfixInsteadOfPatternMatch))

    ||(subframeRequestConfig & noSubframesEver))

    ||(has first confident three-dimensional fix)){

                    don’t collect subframes

           }

           else{

                  /*可根据配置的情况得到子帧*/

           if(subframeRequestConfig & allHighNsubframes)

                  request subframes for all SV′s in high-N

           else if(subframeRequestConfig & onlyStrongestSV)

                  request subframes for strongest SV only

           else if(subframeRequestConfig & onlyAboveThresh)

                  request subframes for any tracking SV with an

                  (subframeLowEMUthresh＜EMU[I]＜

           subframeHighEMUthresh)

           else

                  don’t request any subframes

    }

    }

  }

}

else{/*sigmaPos＞150-km*/

/*

我们的位置总和高的时候的解决情况。在这种情况下，要得到一个定位，对于每一个参与第一次定位的SV，OMNI客户不得不具有intMs。在第一次定位以后，OMNI客户可以计算不在第一次定位中的其它SV′s的intMs。因此从OMNI客户已经通过z计数测量到intMs的强SV′s，或者OMNI客户使用格式匹配产生一个intMs的弱SV′s得到一个定位是一个挑战。这样会从服务器请求子帧。

*/

/*

确定得到一个三维定位需要的SV′s的数量。因为所有的SV′s需要有intMs，OMNI客户假设OMNI客户重分的确信时间。

*/

numNeeded＝4

/*如果API可以输入高度或者二维定位是确定的，将需要的数量减一*/

if(userInputAltitude or fix2Dokay)numNeeded＝numNeeded-1

        /*

        在OMNI客户有足够的带有天文历表的SV′s或并且信号强OMNI客户可以不用服务器得到intMs的SV′s的地方的处理情况。

        */

        if((OMNIconfig & noServerIfStrong)

        &&(numTrackStrongWithEph＞＝numNeeded)))

             /*不需要联系服务器*/

             needServerContact＝FALSE

        else{

             /*OMNI客户将需要从服务器得到数据*/

             needServerContact＝TRUE

             /*

             首先确定在OMNI客户请求之前对于所有的high-N SV′s，OMNI客户至少已经等了整个搜索范围一遍。好处在与在OMNI客户请求一个服务器升级之前OMNI客户已经努力获得了在定义的第一次搜索上的所有SV′s。

             */

             if(has not received didOnePass for first search of high-N with indoor

             sensitivity){

                      wait before contacting server

                      return

             }

             /*

             只有在OMNI客户正在跟踪SV′s和它有很高的可能性给我们足够的SV′s得到一个定位的时候提出请求。

             */

             if((numTrackWithoutEph＞0)

             &&((numTrackWithoutEph+numTrackWithEph)＞＝numNeeded)))

                   /*

        联系服务器会有帮助。现在OMNI客户需要决定OMNI客户需要收集什么。

        */

        /*通过配置情况得到卫星历表。*/

        if(ephemRequestConfig & requestAllEphem)

               request all current ephemeris

        else if(ephemRequestConfig & requestAllNotFresh)

               request all SV′s whose ephem age is old

        else if(ephemRequestConfig & requestTrackNotFresh)

               request all SV′s tracking whose ephem age is old

        else

               don’t request any ephemeris

        /*

        对于所有被跟踪的弱SV′s，OMNI客户需要请求子帧。

        /*寻找避免得到子帧的方法。*/

    if(has first confident three-dimensional fix){

                    don’t collect subframes

        }

        else{

                    /*通过配置情况得到子帧。*/

        if(subframeRequestConfig & allHighNsubframes)

               request subframes for all SV′s in high-N

        else if(subframeRequestConfig & onlyAboveThresh)

               request subframes for any tracking SV with an

               (subframeLowEMUthresh＜EMU[I]＜

        subframeHighEMUthresh)

        else

               don’t request any subframes

    }

    }

  }

}

/*

现在决定OMNI客户是否应该请求更正。在OMNI客户不需要为了天文历表或者子帧进行连接但是OMNI客户仍然想得到DGPS精确度时的解救情况。

*/

if(correctionsRequestConfig & DGPSalways)&&(needServerContact＝＝FALSE)

        request corrections only

       needServerRequest＝TRUE

else if((correctionsRequestConfig & DGPSnormal)&&(needServerContact＝＝TRUE))

       /*和其它被请求的数据一起请求更正。*/

/*检查SPV模型请求*/

if(needServerContact＝＝TRUE)&&(OMNIconfig & requestSPV)

       request SPVs for high-N

/*检查SAPV模型请求*/

if(needServerContact＝＝TRUE)&&(OMNIconfig & requestASPV)

       request SPVs for high-N

OMNI API Parameters

Summary of OMNI parameters defined in this algorithm：

Data for corrections request

CorrectionsRequestConfig  /*通过下面的比特掩码控制字节*/

Values：

DGPSalways＝0×01               /*请求每一个会话*/

DGPSnormal＝0×02               /*只有当请求eph或者subf时请求*/

Data for subframe requests

subframeRequestConfig           /*通过下面的比特掩码控制字节*/

only set ONE of these bits：

allHighNsubframes          ＝0×01

onlyStrongestSV            ＝0×02/*只有当sigmaPos＜150-km时提供*/

onlyAboveThresh            ＝0×04

noSubframesEver            ＝0×08/*只有当sigmaPos＜150-km时提供*/

can set any combination of these bits：

noSubframeWithFreshRTC     ＝0×10/*只有当sigmaPos＜150-km时提供*/

noSubframeWaitForZcount    ＝0×20/*只有当sigmaPos＜150-km时提供*/

noZfixInsteadOfPatternMatch＝0×40/*只有当sigmaPos＜150-km时提供*/

subframeLowEMUthresh              /*一个字节0-255*/

subframeHighEMUthresh             /*一个字节0-255*/

Data for ephemeris request

ephemRequestConfig         /*具有下面的比特掩码的控制字节*/

only set ONE of these bits

requestAllEphem     ＝0×01

requestAllNotFresh  ＝0×02

requestTrackNotFresh＝0×04

General data for OMNI mode

OMNIconfig

OMNImodeON         0×01    /*关键的控制比特。否则默认为OMNI客户*/

fi×2Dokay         0×02    /*意味着第一次二维定位是好的*/

requestSPV         0×04    /*根据需要请求SPVs*/

requestASPV        0×08    /*根据需要请求ASPVs*/

noServerIfStrong   0×10    /*如果设置，OMNI客户有强SV′s，OMNI客户等待收集数据而不是与服务器连接。这样减慢了TTFF但是减少了服务器请求。*/

                                                               */

Other OMNI parameters

OMNIminRequestInterval      /*请求不超过这个间隔::0-255secs*/

尽管本发明已经按照目前的优选实施例进行了描述，还应该理解透露的内容不能仅仅被上述有限的描述解释。经过对上述描述的阅读，各种对本发明的替换和修改对于这些本领域的普通技术人员来说无疑的是显而易见的。因此，意味着附加权利要求被解释为覆盖了所有的全部在本发明的“实质”的精神和范围中的替换和修改。

Claims (4)

1.一个通过网络连接到一台服务器的导航卫星接收机的高灵敏度操作的方法，包括：

测量每一个人造卫星的接收信号的强度；

如果人造卫星的信号强度超过-145毫瓦分贝，则从一个相应的人造卫星下载NAV数据，以收集天文历表、z计数和导航数据比特转换时间以使得能够计算导航定位；

如果人造卫星的信号强度在-145毫瓦分贝和-150毫瓦分贝之间，则使用一个NAV数据模式匹配来得到z计数或者整数毫秒，并从一台服务器获取相应的天文历表以使得能够计算导航定位；

如果人造卫星的信号强度小于-150毫瓦分贝，则从所述的服务器中获取GPS导航消息数据和天文历表，以使得能够计算导航定位；以及

计算导航定位。

2.如权利要求1中所述的方法，还包括步骤：

在初始的人造卫星信号搜索期间，不需要已经被获取的天文历表信息来预计用于预定位的数据；以及

使用年历或降级的天文历表为人造卫星搜索计算预定位。

3.如权利要求1中所述的方法，还包括步骤：

在计算一个导航定位之前限制天文历表信息可以使用的时限。

4.利用不经常的和最小的与服务器联系的高灵敏度导航定位的方法，这个方法包括步骤：

分析天文历表可用性；

通过人造卫星的接收信号强度将它们分类为高于-145毫瓦分贝，在-145毫瓦分贝与-150毫瓦分贝之间，或者低于-150毫瓦分贝；

用估计的GPS时间和接收机位置计算获取的人造卫星数，以确定是否可以获取最小数量的人造卫星来进行可能的导航定位；

基于人造卫星各自的信号电平、估计的GPS时间和接收机位置来计算需要间接从服务器获取的GPS导航消息数据子帧的人造卫星数量；

决定是根本上请求一个服务器连接，还是从所述的服务器连接中请求最小的数据，还是从服务器中请求最大的数据，以便与服务器的最小联系仍然将使得能够计算导航定位；以及

根据获得的数据计算一个导航定位。

Images