DE60109702T2

DE60109702T2 - Systemempfänger und Verfahren zur Satellitennavigation

Info

Publication number: DE60109702T2
Application number: DE60109702T
Authority: DE
Inventors: Paul W. San Francisco McBurney; Arthur N. Cupertino Woo
Original assignee: Seiko Epson Corp; Eride Inc
Current assignee: Seiko Epson Corp; Eride Inc
Priority date: 2000-10-11
Filing date: 2001-10-10
Publication date: 2005-08-25
Anticipated expiration: 2021-10-11
Also published as: HK1046552B; JP3574429B2; CN1350183A; EP1197761B1; DE60109702D1; US6437734B1; JP2002196066A; EP1197761A3; EP1197761A2; CN100430751C; HK1046552A1

Description

Die vorliegende Erfindung bezieht sich auf Satellitennavigations-Empfänger und -Systeme sowie insbesondere auf Vorrichtungen und Verfahren für einen Betrieb in Bereichen mit äußerst geringer Signalstärke und jene, die Positionslösungen sehr schnell initialisieren und ausgeben können.
GPS-Empfänger (GPS/Global Positioning System = Globales Positionierungssystem) verwenden Signale, die sie normalerweise von mindestens drei die Erde umkreisenden Satelliten empfangen, um Navigationsdaten, wie etwa die Position und die Geschwindigkeit zu ermitteln. GPS-Signale sind weltweit kostenfrei verfügbar und werden derzeit routinemäßig genutzt, um den Aufenthaltsort von Kraftfahrzeugen innerhalb eines Stadtblocks oder mit höherer Genauigkeit zu ermitteln. Dualfrequenzträger-GPS-Empfänger verfolgen normalerweise zwei Hochfrequenzträger L1 und L2, die den GPS-Satelliten zugeordnet sind, um akkumulierte Deltabereichsmessungen (ADR) aus der P-Code-Modulation auf diesen Trägerfrequenzen zu erzeugen und führen gleichzeitig eine Zeitverfolgung des L1-C/C-Codes aus, um Codephasenmessungen durchzuführen. Die Trägerfrequenz L1 ist 1.575,42 MHz zugewiesen und die Trägerfrequenz L2 befindet sich bei 1.227,78 MHz. Kostengünstigere Empfänger stimmen lediglich eine Trägerfrequenz ab und verfügen daher nicht über geeignete Informationen, um die lokalen troposphärischen und ionosphärischen Signalausbreitungsverzögerungen zu berechnen, die als Positionsfehler auftreten. Bei derartigen Frequenzen breiten sich die Hochfrequenzträgersignale quasioptisch aus. Somit können Gebäude, Gebirge und der Horizont den Empfang blockieren und Mehrwegereflexionen einen guten Empfang stören.
Jede einzelne Konstellation von GPS-Satelliten im erdnahen Orbit sendet einen von 32 einzigartigen Kenncodes in einer CDMA-Anordnung (CDMA/code-division multiple access = Codierter Mehrfachzugriff). Dies ermöglicht es sämtlichen der zahlreichen GPS-Satelliten, im Signalspreizungsmodus auf derselben Frequenz zu senden, plus oder minus einer Dopplerfrequenz-Verschiebung dieser Frequenz, wie sie aus der Relativgeschwindigkeit des Satelliten resultiert. Bestimmten Satelliten werden aus einem dadurch entstehenden Durcheinander von Signalen und Rauschen durch Korrelieren eines 1.023-"Chip"-Codes mit einem der 32 Pseudozufallszahl-(PRN-)Sequenzcodes geortet, die einzelnen GPS-Satelliten zugeordnet sind. Diese Codes werden nicht unbedingt phasengleich zueinander gesendet. Daher beinhaltet das "Auffinden" eines GPS-Satelliten zunächst das Absuchen unterschiedlicher Trägerfrequenzen, um der Dopplertrequenz-Verschiebungen und Oszillatorungenauigkeiten Rechnung zu tragen, und das Suchen nach einer Codeübereinstimmung unter Verwendung 1.023 unterschiedlicher Codephasen und mindestens 20 möglicher Korrelationscode-Vorlagen.
In großen Städten mit hohen Gebäuden können einer oder mehrere der GPS-Satelliten, die von einem bestimmten Empfänger verfolgt werden, vorübergehend blockiert sein. In manchen Situationen können derartige Blockierungen eine Verfolgung sämtlicher darüber befindlicher GPS-Satelliten verhindern, wobei derartige Ausfälle einige Minuten andauern können. Zudem sind die GPS-Signale für Fahrzeuge, die sich durch Untertühren unter Land oder unter Wasser bewegen, nicht verfügbar.
Wenigstens ein herkömmlicher GPS-Fünfkanalempfänger bündelt beim Einschalten sämtliche seiner Kanäle auf einen Satelliten. Damit wird dem Problem der Unsicherheit der Satellitensignalfrequenz Rechnung getragen, die infolge von Dopplereffekten und lokalen Oszillatorungenauigkeiten im Empfänger existiert. Eine Suche nach einem speziellen Satelliten im scheinbaren Dopplertrequenzspektrum wird parallel ausgeführt. Beispielsweise durch Segmentieren des möglichen Dopplerfrequenzspektrums in genau so viele Segmente, wie Empfängerkanäle vorhanden sind. Daraufhin wird jeder der zahlreichen Empfängerkanäle angewiesen, eine Suche innerhalb eines bestimmten Segments durchzuführen.
Die einzelne größte Ungenauigkeit stammt von den Zufallsfrequenzen, die infolge typischer lokaler Oszillatorungenauigkeiten bei der Inbetriebnahme auftreten. Da her ist die scheinbare Dopplerfrequenz nur innerhalb weiter Suchgrenzen bekannt. Das Wissen um die tatsächliche Dopplerfrequenz ist nicht sehr hilfreich, da der lokale Oszillator an sich so weit vom Nominalwert entfernt sein kann.
Vom Standpunkt des Benutzers aus, sind wenigstens zwei Betriebseigenschaften der GPS-Empfgänger des Standes der Technik nicht zufriedenstellend. Derartige herkömmliche Empfänger versagen in geschlossenen Räumen häufig ihren Dienst, da die Gebäude den lokalen Signalfeldstärkepegel unter die maximale Empfindlichkeit des Empfängers absenken. Und die meisten Empfänger benötigen sehr viel Zeit, um einen Positionslösung ab einem Kaltstart zu erzeugen.
Aufwendige Berechnungen in GPS-Empfängern erfordern hohe Taktraten und sehr viel teuren Speicherplatz. Dadurch wird wiederum teure und umfangreiche Hardware notwendig. Hersteller wie auch Benutzer würden leichtere und dünnere Navigationslösungen schätzen, die kostengünstige Plattformen nutzen oder bereits vorhandene Plattformen anderer Applikationen nutzen können.
Das Internet bietet zudem individuellen GPS-Empfängern die Möglichkeit, Differential-Korrekturdaten in ihren Bereichen zu überwachen und rechenintensive Aufgaben an regionale Webserver abzugeben, die über Hochleistungsprozessoren verfügen.
SnapTrack Inc. (San Jose, CA) ist ein kommerzieller Anbieter drahtlos unterstützter GPS-(WAG-)Systeme. Zeit, Frequenz und ungefähre Aufenthaltsortsdaten werden aus einem drahtlosen Netzwerk extrahiert, um bei einer GPS-Signalverarbeitung in einem Navigationsempfänger unterstützend mitzuwirken. Einer derartige Technologie ist in einer Reihe von US-Patenten beschrieben, die SnapTrack erteilt sind, wie etwa: 5.945.944; 5.663.734; 5.781.156; 5.825.327; 5.831.574; 5.841.396; 5.812.087; 5.874.914; 5.884.214 und dergleichen. Siehe auch das US-Patent 6.078.290.
US-A-4 445 118 beschreibt ein Satellitennavigationssystem in einem GPS-System, bei dem ein Ortungshilfssignal, das von einer Bodensteuerstation erzeugt wird, zu den mobilen Endgeräten weitergeleitet wird, um die Datenverarbei tungsfunktionen zu vereinfachen, die in diesen Endgeräten ausgeführt werden. Das Hilfssignal reduziert das Benutzergerät durch Vereinfachung der Signalspreizungs-Signaldemodulation und durch reduzierte Datenverarbeitungsfunktionen, die zuvor im Benutzerendgerät ausgeführt wurden.
Ein Ziel der vorliegenden Erfindung besteht darin, ein Satellitennavigationssystem anzugeben, das mit äußerst geringen Signalstärkepegeln arbeiten kann.
Dieses Ziel wird durch den Gegenstand des unabhängigen Anspruchs 1 erreicht.
Bevorzugte Ausführungsformen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Ein weiterer Aspekt der vorliegenden Erfindung besteht darin, einen Satellitennavigationsempfänger anzugeben, der Positionslösungen unmittelbar nach jedem Kaltstart erzeugt.
Ein weiterer Aspekt der vorliegenden Erfindung besteht darin, ein Satellitennavigationssystem anzugeben, das kostengünstig ist.
Ein weiterer Aspekt der vorliegenden Erfindung besteht darin, ein Satellitennavigationssystem anzugeben, das mit dem Internet zusammenarbeitet.
Ein Aspekt der vorliegenden Erfindung besteht darin, ein System anzugeben, dessen verbesserte Genauigkeit und Leistungsfähigkeit über Zeitdifferenz- und Frequenzdifferenzinformationen unterstützt werden kann, die in einem Netzwerk verteilt werden.
Kurz gesagt beinhaltet ein GPS-Positionierungssystem gemäß einem Aspekt der vorliegenden Erfindung einen System-On-Chip-Empfänger, einen Netzwerk-Client und einen Webserver. Der Webserver kann die Betriebsart einer einfachen Beobachtungsplattform unterstützen, bei der der System-On-Chip-Empfänger Informationen lediglich weiterleitet, oder kann eine halbautonome Betriebsart unterstützen, bei der der System-On-Chip-Empfänger in der Lage ist, seine Position für 15 Minuten seit seinem letzten Kontakt mit dem Webserver zu berechnen. Der Webserver enthält seine eigenen lokalen GPS-Konstellations-Messplattformen, um eine Datenbank von GPS-Messfehlern, Ephemeris-, Alamanach- und anderen Satellitendatennachrichten aufzubauen. Informationen von unzureichend arbeitenden Satelliten mit Problemen werden ausgefiltert. Der Netzwerk-Client ist von traditionellen rechenintensiven Aufgaben unter Verwendung ganzzahliger Arithmetik und kommunizierender Binärzahlen anstelle von Flieskommazahlen und der Benutzung transzendenter mathematischer Funktionen befreit. In einer Betriebsart werden Positionsfixierungen vom Webserver aus Daten bereitgestellt, die vom Netzwerk-Client zugeführt werden. Der System-On-Chip-Empfänger enthält Schaltkreise, um die Empfängerempfindlichkeit und die Suchgeschwindigkeit zu verstärken.
Ein Vorteil der vorliegenden Erfindung besteht darin, dass ein System und ein Verfahren angegeben werden, mit denen die Kosten des Navigationsgerätes des Benutzers verringert werden.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass ein System und ein Verfahren angegeben werden, die die Empfindlichkeit und die Zeit zu ersten Fixierung in ausreichendem Maße für Straßenschluchten und die Benutzung in geschlossenen Räumen verbessern.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass ein System und ein Verfahren angegeben werden, die Datenbankdienste höherer Ordnung über das Internet verfügbar machen, die sich auf Benutzer-Positionsfixierungen in Echtzeit und bereits abgelaufener Zeit beziehen.
Diese sowie andere Ziele und Vorteile der vorliegenden Erfindung werden dem Fachmann ohne Zweifel verständlich sein, nachdem er die folgende detaillierte Beschreibung der bevorzugten Ausführungsformen gelesen hat, die in den unterschiedlichen Zeichnungen dargestellt sind.
1 ist ein Funktionsblockschaltbild einer Ausführungsform eines Benutzer-Navigationssystems der vorliegenden Erfindung, das auf ein Benutzergerät, einen Netzwerk-Client und einen Webserver verteilt ist;
2 ist ein Funktionsblockschaltbild einer Ausführungsform eines digitalen Signalprozessors der vorliegenden Erfindung, der eine hardwareimplementierte Statusmaschine, die den Betrieb der Empfänger-Mischer aufrechterhält, und eine softwareimplementierte Statusmaschine enthält, die den Datenbedarf der hardwareimplementierten Statusmaschine deckt;
3 ist ein Funktionsblockschaltbild der höchsten Ebene des Firmware-Betriebssystems, das von einem eingebetteten RISC-Prozessor ausgeführt wird, sowie dessen Schnittstelle zur Navigationsplattform; und
4 ist ein Funktionsblockschaltbild der Takterzeugung und der Steuerung, die Bestandteil des Empfängers von 1 ist.
Eine Ausführungsform des Positionsbestimmungssystems der vorliegenden Erfindung ist in 1 gezeigt und ist im folgenden mit dem allgemeinen Bezugszeichen 100 gekennzeichnet. Das System 100 beinhaltet einen Empfänger 102, einen Netzwerk-Client 104, der dem Empfänger zugeordnet ist, sowie einen Webserver 106, der vom Empfänger und vom Client entfernt ist. Eine Mikrowellenantenne 108 empfängt Signale für den Empfänger 102, die von GPS-Satelliten im Orbit gesendet werden. Ein zweite Mikrowellenantenne 110 empfängt Signale lokal am Webserver 106, die von einigen dieser GPS-Satelliten im Orbit gesendet werden.
Obwohl der Empfänger 102 vom Webserver 106 entfernt ist, befindet er sich im selben geographischen Gebiet und kann weiterhin von differentialen, ionosphärischen und troposphärischen Korrekturen profitieren, die vom Webserver 106 berechnet werden.
Der Empfänger 102 enthält eine Hochfrequenz-(HF-)Stufe 112, einen digitalen Signalprozessor (DSP) 114 und einen Mikrocomputer (μC) 116. Der μC enthält einen RAM (Random Access Memory), einen ROM (Read Only Memory) und einen Mirkoprozessor, der auf Befehle höherer Ordnung vom Client 104 reagiert. Ein derartiger RAM und ROM haben normalerweise eine geringe Größe, um die Herstellungs- und Betriebskosten zu senken. Daher ist es bei den Ausführungsformen der vorliegenden Erfindung von Bedeutung, dass nichts im Empfänger 102 verwendet wird, um Satelliten-Ephemeris- oder Almanachdaten zu speichern. Bei wenigstens einer Betriebsart hängt der Empfänger 102 in bedeutendem Maße von periodischen Aktualisierungen einer Gruppe von Polynomen durch den Webserver 106 ab, die jeweils eine Position und Geschwindigkeit des sichtbaren Satelliten anzeigen.
Bei einer Ausführungsform der vorliegenden Erfindung ist der DSP 114 vorzugsweise als dedizierter Logik-Gate-Aufbau einer Statusmaschine, wie etwa als applikationsspezifischer integrierter Schaltkreis (ASIC), oder mit einer Gate-Anordnung implementiert. Der μC 116 ist dazu programmiert, eine zweite Statusmaschine, die eine Firmware oder Software verwendet, wie etwa eine softwareimplementierte Statusmaschine, zu implementieren. Die beiden Statusmaschinen arbeiten in einer symbiotischen Beziehung, um die phasengleichen Abtastungen und die Quadratur-Abtastungen, die von der HF-Stufe 112 zugeführt werden, in Navigationsmessungen zu konvertieren, die vom μC 116 konstruiert und weitergeleitet werden. Serielle Kommunikationsverbindungen 116 und 120 transportieren diese Messungen zu einer Navigationsplattform, z. B. entweder zum Client 104 oder durch diesen zum Webserver 106. Eine derartige Navigationsplattform sendet den suchenden Satelliten die vorzunehmenden Messungen und dergleichen zurück.
Kommunikationsverbindungen 122 und 124 zwischen dem Client 104 und dem Webserver 106 beinhalten vorzugsweise das Internet und verwenden die Transfer-Control-Protocol-/Internet-Protocol-(TCP-/IP-)Technologie. Drittbenutzer haben vorzugsweise wenigstens Zugriff auf den Webserver 106.
Ein Teil oder sämtliche der Kommunikationsverbindungen 118, 120, 122 und 124 können drahtlos sein. Spezielle Applikationen können von diesen drahtlosen Verbindungen abhängen oder durch diese ermöglicht werden. Dies würde insbesondere dann zutreffen, wenn der Empfänger 102 batteriebetrieben ist und von einem Benutzer oder Fahrzeug getragen bzw. transportiert wird.
Bei allen Ausführungsformen der vorliegenden Erfindung ist es wichtig, dass keine Flieskommaarithmetik oder Basis-10-Berechnungen vom Empfänger 102 ausgeführt werden. Einfach-präzise und natürlich doppelt-präzise Flieskommaoperationen sind zu prozessorintensiv für den geringen Energieverbrauch und die geringen Taktraten, die vorzugsweise ein untrennbarer Bestandteil des Empfängers 102 sind. Anstelle dessen müssen sämtliche Berechnungen und Lösungen der Empfängerposition in einer ganzzahligen Basis-2-Arithmetik, wie etwa 32 Bit binär, ausgeführt werden. Dies erfordert wenigstens eine Betriebsart, in der der Webserver 106 troposphärische, ionosphärische, selektiv verfügbare (SA) und differentielle Korrekturdaten berechnet und weiterleitet, die als ganze Zahlen auf der Basis 2 formatiert sind. Ist dies nicht möglich, muss der Client 104 diese Aufgaben ausführen.
Der GPS-Navigations-Almanach und die -Ephemeris werden vom Webserver 106 mit seinem eigenen Referenzstations-GPS-Empfänger erworben und reduziert, um einfache Polynome bereitzustellen, die jeweils die Position und Geschwindigkeit jedes Satelliten kennzeichnen. Derartige Polynome veralten natürlich im Laufe der Zeit, wobei jedoch periodische Kontakte zwischen dem Client 104 und 106 über das Internet in kritischem Maße davon abhängig sind, um ausreichend aktuelle Orbitdaten bereitzustellen. Der Empfänger 102 ist somit von der speicherintensiven Aufgabe befreit, die momentanen Ephemeris- und Almanachdaten im lokalen RAM/ROM zu halten und muss nicht die 258-intesive Arbeit des RISC-Prozessors ausführen, in doppelt-präziser Flieskommamathematik die Satellitenorbitpositionen für jede Positionsfixierung lokal zu berechnen.
Bei einer gewerblichen Ausführungsform der vorliegenden Erfindung gehört der Webserver 106 einem unabhängigen Dienstanbieter und wird von diesem betrieben. Abonnenten- oder nutzungsgebundene Gebühren werden Benutzern in Rechnung gestellt, die den Empfänger 102 und/oder den Netzwerk-Client 104 benutzen. Der Empfänger 102 ist alternativ dazu weiterhin in ein IP-(Intellectual-Property-)Paket für integrierte Halbleiterschaltkreisvorrichtungen applikationsspezifischer Netzwerk-Clients 104 eingebunden. Eine derartige IP wird für eine Lizenzgebühr und Hardwarekosten OEMs (Original Equipment Manufacturers = Originalzubehör-Herstellern) der Netzwerk-Clients 104 verkauft.
Die Hochfrequenzstufe 112 und der DSP 114 bilden einen "Hardware-Enabler", der kommerziell als Verilog-Code in einem Bündel mit Software für den μC einem OEM verkauft werden kann, damit dieser in seinen Produkten enthalten ist. Ein derartiger Hardware-Enabler ist vorzugsweise in einem einzigen integrierten Schaltkreis (IC) als SOC (System-On-Chip) implementiert. Es können zudem andere Arten einer HDL (Hardware Description Language) und eines Softwareprogrammiercodes, wie etwa C++, Visual-Basic und dergleichen verwendet werden.
Der Client 104 kann in einer von wenigstens vier Betriebsarten betrieben werden: autonom, halbautonom, "dünn" und super-dünn. In der autonomen Betriebsart ist der Client 104 die Navigationsplattform und deckt den Informationsbedarf des Empfängers 102 selbst ohne die Hilfe eines Webservers 106. Bei allen anderen Betriebsarten fungiert der Webserver 106 als Navigationsplattform.
In der halbautonomen Betriebsart zieht der Client 104 den Webserver 106 periodisch für Informationen hinzu. In der dünnen Betriebsart leitet der Client 104 die Daten zwischen dem Empfänger 102 und dem Webserver 106 einfach weiter. Die dünne Betriebsart wird bevorzugt, da sie die einzige ist, die es am besten ermöglicht, die Kosten zur Herstellung und des Betriebs des Clients 104 auf ein Minimum zu reduzieren. In der super-dünnen Betriebsart werden Zeitdifferenz- und/oder Frequenzdifferenz-Informationen, die von anderen Beobachtern beigesteuert werden, über ein Netzwerk kommuniziert, um die Unsicherheiten der lokalen Zeit und der lokalen Frequenz zu verringern.
Während des Betriebs muss der Empfänger 102 simultan nach GPS-Mikrowellensignalen in zwei Domänen suchen, wie etwa der Frequenz- und der Code-Phase. Der lokale Oszillator und die Doppler-Verschiebung, die von der Satellitenrelativgeschwindigkeit verursacht wird, erzeugen Trägertrequenz-Unsicherheiten, die gestreut sind. Die augenblickliche GPS-Satelliten-Pseudozufallszahl-(Pseudozufallszahl-)Codephase ist eine weitere Unbekannte. Empfangssignale, die sich über dem "Grundrauschen" befinden, sind relativ einfach und schnell zu suchen. Schwache Signale in Gebäuden gehen jedoch in einem Rauschen in der Größenordnung von 20 dB unter. Jeder Besuch bei einer Frequenz-/Codephasen-Binärdatei muss dort lange genug andauern, um das Grundrauschen mit Verarbeitungsgewinnen zu "unterdrücken", die von Codekor relatoren erzeugt werden. Schwache Signale erfordern es zudem, dass die Such-Binärdateien feinere Schritte zwischen Binärfrequenzen und Binär-Codephasen beispielsweise wegen des Aliasing haben. Somit muss eine größere Zahl von Binärdateien durchsucht werden, wobei jede Binärdatei mehr Verarbeitungszeit erfordert, was die Durchsuchungszeit exponential erhöht.
Der Webserver 106 gibt Echtzeit-Navigationsdaten an das Internet aus. Es existieren derzeit andere Dienste, die Navigations- und Initialisierungsdaten im Internet bereitstellen, die teilweise oder nicht in Echtzeit sind, wobei diese zum Teil anstelle von Echtzeit-Navigationsdaten, die zum Empfänger 102 gesendet werden, oder zu deren Gültigkeitsprüfung verwendet werden können. Eine primäre und wichtige Aufgabe des Webservers 106 besteht in der Entlastung des Empfängers 102 hinsichtlich der Navigationsberechnungsarbeiten. Der Umfang, in dem eine derartige Entlastung erfolgen kann, hängt von der Regelmäßigkeit des Kommunikationskontaktes ab, die zwischen dem Empfänger 102 und dem Webserver 106 realisiert werden kann. Die tatsächlichen Messungen, die der Empfänger 102 erhält, werden zum Webserver 106 weitergeleitet.
Alternative Ausführungsformen der vorliegenden Erfindung beinhalten Webserver 106, die eine Datenbankverarbeitung zu Abstraktionen und Zwecken einer höheren Ordnung ausführen. Beispielsweise enthält die Serverplattform eine Bereitschafts- und Qualitätsüberwachungseinrichtung, die die statischen Beobachtungen prüft und eine Einbeziehung falscher Informationen in die Datenbank von Messfehlern und Satellitendatenmeldungen verhindert. An einer anderen Stelle könnte der Webserver 106 Positionslösungsinformationen im Verlauf der Zeit für das Muster der Orte sammeln, die der Empfänger 102 über einen Zeitraum von Stunden, Tagen, Wochen, Monaten, Jahren und dergleichen besucht. Derartige Informationen können anschließend verarbeitet werden, um zu schätzen, wo sich der Benutzer des Empfängers 102 befindet, wo der Benutzer gewesen ist, oder wo der Benutzer wahrscheinlich in der Zukunft sein wird. Derartige Informationen sind für Versand, Uhrzeit, Hausarrest, Personaleinsatz, Bestandsaufnahmen, Anlagenverwaltung, Militär, Sicherheit und andere Arten von Anwendungen nützlich. Positionsinformationen können interpretiert werden, um intelligent darauf zu schließen, was der Benutzer zu einem beliebigen Zeitpunkt tut. Wenn beispielsweise die Po sition des Benutzers mit der eines örtlichen Gemüsehändlers übereinstimmt, könnte davon ausgegangen werden, dass der Benutzer beim Einkaufen ist. Es können auch Markierungen vom Benutzer im Webserver 106 erzeugt werden, wie etwa durch die Stadtverwaltung, die mit der elektronischen Datenbank den unveränderbaren Ort von Löschhydranten, Netzstromwandlern oder Fahrbahnen und dergleichen zuordnet und in dieser "kennzeichnet".
Die Präsenz von Informationen im Internet über eine Benutzerposition kann von Werbe- und Marketingfirmen genutzt werden, um Kontextnachrichten an den Benutzer in Echtzeit zu senden. Derartige Daten werden bei einer gewerblichen Ausführungsform der vorliegenden Erfindung in Echtzeit verkauft.
Bei einer Ausführungsform der vorliegenden Erfindung trägt ein Benutzer den Empfänger 102 und verbindet sich über Funk mit dem Client 104. Ein Schilauf des Benutzers könnte beispielsweise aufgezeichnet und später an einem Kiosk wiedergegeben werden. Ein Jogginglauf könnte bei einem weiteren Beispiel von einem persönlichen Trainer analysiert werden, um spezielle Übungsanweisungen zu überprüfen. Bei derartigen Anwendungen könnte der Empfänger 102 vollständig in einer Armbanduhr mit Stromhalbleitertechnik integriert sein.
Ausführungsformen der vorliegenden Erfindung erhöhen die Empfindlichkeit des Empfängers und verringern gleichzeitig Suchzeiten, indem Signalabtastungen, die man vom SOC-Empfänger 102 erhält, für zahlreiche Prozessoren kopiert werden, die unterschiedliche Binärfrequenz-/Codephasen-Hypothesen parallel ausführen. Im Durchschnitt wird die korrekte Binärfrequenz-/Codephasen-Hypothese selbst in geschlossenen Räumen und in Fahrzeugen sehr schnell gefunden.
Im allgemeinen verwenden Ausführungsformen der vorliegenden Erfindung Internet-Webserver, um Daten, die von entfernten GPS-Empfängern gesammelt werden, derart zu verarbeiten, dass die Signalempfindlichkeit erhöht und Suchzeiten im Vergleich zu herkömmlichen Empfängern und Verfahren verkürzt werden.
2 zeigt eine System-On-Chip-(SOC-)Ausführungsform der vorliegenden Erfindung und ist im folgenden durch das Bezugszeichen 200 gekennzeichnet. Das SOC enthält zwei Basisteile, die in einem Stück Silizium integriert sind, eine hardwareimplementierte Statusmaschine und eine softwareimplementierte Statusmaschine. In 1 sind diese beiden Funktionshälften separat als DSP 114 und μC 116 dargestellt.
Die hardwareimplementierte Statusmaschine gibt Abtastungen von der HF-Stufe 112 (1) ein. Sie verwendet eine zugewiesene Gate-Logik, um mit dem Betrieb der Empfängermischers schrittzuhalten. Eine softwareimplementierte Statusmaschine, die auf einem eingebetteten RISC-Prozessor ausgeführt wird, versorgt den Echtzeitdatenbedarf der hardwareimplementierten Statusmaschine. Ein derartiger eingebetteter RISC-Prozessor kann mit der kommerziellen Vorrichtung XEMICS coolRISC^® CR816 (Schweiz) implementiert werden. Die softwareimplementierte Statusmaschine kommuniziert normalerweise mit dem μC 116 (1) über serielle Kommunikationskanäle.
Das SOC 200 stellt einen Taktoszillator 202 und einen Taktmanager 204 bereit, die einen numerisch gesteuerten Codeoszillator (NCO) 206, einen Codegenerator einen 18-teiligen Codespeicher 210, einen lokalen Digitaloszillator 212, einen Träger-NCO 214, einen zehnteiligen Trägergenerator 216 und einen zehnteiligen Trägermixer 217 ansteuern. Eine finite Statusmaschine (FSM) 218 erzeugt Daten, um 352 zehnteilige Codehypothesespeicher 220, 352 Codemisch-Korrelatorenpaare 222 und 352 Verriegelungsspeicherpaare 224 zu versorgen. Ein Hypothesespeicher 226 bildet eine Schnittstelle mit einem Leistungssummenregister 228, das Informationen empfängt, die aus den Verriegelungsspeicherpaaren 224 stammen. Eine Gruppe von M1-, M2- und M3-Orten 230, 232 und 234 sowie Leistungsregister führen ihre Ausgaben dem μC 1116 zu.
Ein Verstärkungscontroller 236 führt einem Multiplexer 238 phasengleiche Abtastungen ("I") und Quadratur-("Q"-)Abtastungen zu. Eine Datenwähleinrichtung 240 schaltet periodisch zwischen durch Bezug gespeicherten Abtastungen aus einem Abtastspeicher A 242 und einem Abtastspeicher B 244 hin und her. Ein Abtaststeuersignal 246 bestimmt, welcher Speicher in einem Zeitraum gefüllt wird und aus welchem gelesen wird. Der Verstärkungscontroller 236 stellt ein "I"-Gleichstrom-Verschiebungssignal 247 über einen ersten Impulsfrequenzmodu lator 248 bereit. Ein "Q"-Gleichstrom-Verschiebungssignal 250 wird über einen zweiten Impulsfrequenzmodulator 252 rückgemeldet. Ein AGC-Rückmeldungssignal 254 wird über einen dritten Impulsfrequenzmodulator 256 ausgegeben.
Die softwareimplementierte Statusmaschine des μC 116 als Teil des SOC 200 basiert vorzugsweise auf einem RISC-Prozessor 258 geringer Leistung mit einem XEMICS coolRISC^® (Schweiz) RISC-Mikroprozessor. Zudem werden eine Digitalzellenbibliothek CooLib^® und ein 8-Bit-RISC-Kern CoolRISC^® als IP-Produkte vertrieben. Siehe "http://www.xemics.ch". Die Firmware der softwareimplementierten Statusmaschine benutzt einen DROM (Random Access Memory) 260, einen SRAM (Static Random Acccess Memory) 262 sowie einen Flash-Speicher 264. Eine Einschalt-Rücksetzlogik 266 erzeugt Einschalt-Rücksetzungen. Ein temperaturkompensierter Kristalloszillator (TCXO) 268 erzeugt eine stabile Zeitgabebasis für den RISC-Prozessor 258. Kommunikationen zwischen dem RISC-Prozessor 258 und dem Client 104 (1) werden durch eine serielles Eingangs/Ausgangs-(SIO-)Peripheriegerät 270, wie etwa RS-232, einen Universal Serial Bus (USB), ein Ethernet und dergleichen verwaltet.
Ein Frequenzdifferenz-Kommunikationsanschluss 271 nimmt an der Verteilung von Informationen über ein Netzwerk Teil, die bei der Verringerung der lokalen Frequenzunsicherheiten des SOC 200 hilfreich sind. Ein Zeitdifferenz-Kommunikationsanschluss 272 nimmt in ähnlicher Weise bei der Verteilung von Informationen über ein Netzwerk teil, die bei der Verringerung der lokalen Zeitunsicherheiten des SOC 200 hilfreich sind. Eine oder beide werden bei der Formulierung von Suchstrategien verwendet, die die Zeit zur ersten Fixierung, die Empfängerempfindlichkeit und die Lösungsgenauigkeit verbessern können. Derartige Verbesserungen werden normalerweise bei der Nachbearbeitung durch stromabwärtige Datenverbraucher erreicht, wie etwa den Netzwerkserver.
3 zeigt die Ausführungsform eines Statusmaschinen-Steuerprogramms der vorliegenden Erfindung, das im folgenden mit Bezugszeichen 300 gekennzeichnet ist. Das Statusmaschinen-Steuerprogramm 300 enthält eine Einschalt-Initialisiereinrichtung 302, einen Taktgenerator- und -controller 304, eine Betrieb sartblockanordnungs-Programmsteuerschleife 306, einen Vorberechnungs- und Wiedergabeblock 308 und einen für einen Verriegelungsspeicher verfügbaren Block 310. Das FSM 300 bildet normalerweise eine Schnittstelle mit einer Navigationsplattform 312 und arbeitet in deren Abhängigkeit. Eine derartige Navigationsplattform 312 wird auf dem Client 104 in der vollständig autonomen Betriebsart und auf dem Webserver 106 in den schmalen Client- und den halbautonomen Betriebsarten versorgt. Die Navigationsplattform befindet sich im wesentlichen an der Stelle, an der die Navigationslösungen berechnet werden.
Das Statusmaschinen-Steuerprogramm 300 versetzt die unterstützende Hardware normalerweise nach dem Einschalten und der Initialisierung in einen Tiefschlaf, in dem sie beispielsweise Takte manipuliert und einen Halt-Befehl im RISC-Prozessor 259 (2) ausführt. Eine Unterbrechung auf einer seriellen Eingangsleitung weckt den Taktgenerator und -controller 304 auf. Dadurch wacht die softwareimplementierte Statusmaschine auf. Es beginnt die Erzeugung einer Unterbrechung von einer Millisekunde (MSEC=On), die mit der Erhöhung eines Master-Zeitgebers Msec24 beginnt. Ein Temperatursensor, ein Zeitdifferenzzähler und ein Frequenzdifferenzzähler nehmen jeweils eine Ausgangsmessung vor. Der HF- und der Abtasttakt (SCLK=on) werden eingeschaltet, wodurch eine AGC-Programmsteuerschleife aktiviert wird. Ein Abtastspeicher A oder B muss darauf warten, dass die AGC-Programmsteuerschleife initialisiert ist und stabil wird.
Der Abtastspeicher wird manuell ein- und ausgeschaltet, indem beispielsweise ein "sampleMemoryControl"-Kennzeichen eingeschrieben wird. Ein Wert "1" schaltet des Speicher ein, und ein Wert "0" schaltet ihn ab. Der Abtastspeicher wird vorzugsweise immer dann automatisch eingeschaltet, wenn eine neuer gültiger Betriebsartblock definiert wird. Die Navigationsplattform kann auch andere Betriebsarten befehlen, indem beispielsweise das "RF"- und das "Msec"-Kennzeichen jeweils ein- oder ausgeschaltet wird. Die RF=OFF- und die Msec=ON-Betriebsart wird verwendet, um die Zeit beizubehalten, jedoch die Verfolgung von Satelliten auszusetzen. Dadurch wird weniger Energie verbraucht, wenn die GPS-Fixierrate, wie etwa alle zehn Sekunden, niedrig ist. Die RF=OFF- und Msec=OFF-Betriebsarten gestatten es der finiten Statusmaschine 300 in die Tiefschlafbetriebsart zurückzukehren. Die RF=ON-, Msec=ON- und sample memory=OFF-Betriebsarten halten die RF-AGC aktiv, wobei keine Satelliten verfolgt werden.
Die Einschalt-Initialisierungseinrichtung 302 stellt die Ausgangszustände für eine Zahl von Variablen der finiten Statusmaschine ein. Variable, die lokal sind, das heißt, die sich nicht in einem Betriebsartblock befinden, werden im Code ausdrücklich in ihrer ersten Verwendung identifiziert. Andernfalls befinden sich sämtliche Variablen im Betriebsartblock. Tabelle "I" zeigt einen Weg, um die Einschalt-Initialisierungseinrichtung 302 in der Software zu implementieren. Zwei Variable MBP und LAP werden initialisiert, bevor der die Wiedergabetakt gestartet wird.
Tabelle "I"
Die Logik des Taktgenerators und -controllers 304 ist detaillierter in 4 dargestellt. Ein Taktgenerator und -controller 400 enthält einen Mastertakt (MCLK), der beispielsweise mit 27.456 MHz arbeitet. Eine MSEC-Datenwähleinrichtung 404 gestattet die Softwaresteuerung einer Mastertakt-(MCLK-)Ausgabe durch den RISC-Prozessor 258. In ähnlicher Weise gestattet eine PCLK-Datenwähleinrichtung 406 die Softwaresteuerung einer Wiedergabetaktausgabe. Eine "÷ 13"-Dividiereinrichtung 408 reduziert die Mastertaktfrequenz auf die Abtasttaktfrequenz. Eine programmierbare Abwärtszähleinrichtung 410 reduziert den Mastertakt auf einen Takt von 13,0 KHz, wenn sie geladen ist, um von 2.111 auf 0 herabzuzählen. Eine SCLK-Datenwähleinrichtung 412 gestattet die Softwaresteuerung einer Abtasttakt-(SCLK-)Ausgabe. Eine "÷ 64"-Dividiereinrichtung 414 und eine "÷ 33"-Dividiereinrichtung 416 sind in Reihe geschaltet und verringern die Mastertaktfrequenz auf eine 1-ms-Impulsfrequenz. Eine programmierbare Aufwärtszähleinrichtung 418 zählt 16.777.215 Zyklen des Mastertaktes. Eine "÷ 10"-Dividiereinrichtung 420 reduziert die Mastertaktfrequenz auf eine 10-ms-Impulsfrequenz, um sie beispielsweise als Unterbrechung zu verwenden. Der Taktgenerator und -controller 400 enthält weiterhin eine Aufwärtszähleinrichtung 424, eine Zustands-Ein/Aus-Wähleinrichtung 426 für schreibbare Daten, eine programmierbare 12-Bit-Aufwärts-/Abwärts-Zähleinrichtung 428 und ein beschreibbares Initialisierungswertregister 430.
Für einen gültigen Betriebsartblock muss die softwareimplementierte Statusmaschine einen Betriebsartblock initialisieren. Lediglich die softwareimplementierte Statusmaschine kann Daten in den Betriebsartblock schreiben, der die Parameterzahl definiert. Die FSM 300 kann derartige Daten nach der Initialisierung nicht schreiben. Die softwareimplementierte Statusmaschine stellt blockWriteFlag=1 ein, so dass dieser Block nicht von der finiten Statusmaschine gewählt wird, bis das Kenzeichen gelöscht ist. Nach dem Schreiben der geeigneten Daten stellt die softwareimplementierte Statusmaschine blockWriteFlag=0 ein.
Jedesmal wenn die softwareimplementierte Statusmaschine ein blockWriteFlag (geändert von "1" auf "0") löscht, zeichnet die finite Statusmaschine diese Ereignis mit newModeBlockFlag auf. Dies ist eine Variable der finiten Statusmaschine, die global, d. h. nicht spezifisch für einen Betriebsartblock ist.
Die Betriebsartblockanordnungs-Programmsteuerschleife 306 repräsentiert eine Hauptprogramm-Programmsteuerschleife der finiten Statusmaschine 300. Die oberste Ebene der Programmsteuerschleife wird immer dann erreicht, wenn ein startOfNewRecord-Ereignis stattfindet, und zudem immer dann, wenn die Programmsteuerschleife im Leerlauf ist und ein newModeBlockFlag eingestellt ist. Einige Variable sind für die finite Statusmaschine 300 global. Eine "MBP"-Variable ist ein 5-Bit-Betriebsartblock-Adressverweis, wobei 0 bis 16 mögliche Werte sind. Eine "numModeBlocks"-Variable speichert die Zahl der definierten Betriebsartblöcke in der Betriebsartblockanordnung (MBA). Ein "recordToggle"-Kennzeichen ist eine Ein-Bit-Zähleinheit, die sich alle 10 Millisekunden ändert. Eine "Msec4"-Variable ist eine Vier-Bit-Zähleinheit, die sich jede Millisekunde ändert und eigentlich gleich den vier niedrigstwertigen Bits der "Msec24"-Variablen ist.
Die beiden Variablen "playbackState" und "playbackStateCnt" werden verwendet, um die Zahl der Mastertakte zu überwachen, die bei jedem Schritt der finiten Statusmaschine verbraucht werden. Diese Variablen werden hauptsächlich verwendet, um zu beobachten, wie die finite Statusmaschine arbeitet. Sie können jedoch ebenfalls verwendet werden, um Race-Zustände zu vermeiden, wie sie bekannt sind, wenn sich die finite Statusmaschine in bestimmten kritischen Bereichen befindet, in denen globale Daten geschrieben werden, die von mehr als einem finiten Statusmaschinenblock verwendet werden. PlaybackState wird gemäß dem Ort in der Statusmaschine geändert. Die Zähleinrichtung kann entweder eine Aufwärts- oder Abwärtszähleinrichtung sein, abhängig davon, wie die Zähleinrichtung initialisiert ist. Eine Initialisierung auf null macht aus der Variablen eine Aufwärtszähleinrichtung, wohingegen eine Initialisierung auf Werte ungleich null aus der Variablen eine Abwärtszähleinrichtung macht. Befindet sich playbackState im Null-Zustand, ist playbackStateCnt zwangsläufig im Leerlauf.
Tabelle II
NweModeBlockFlag muss mit Vorsicht gelöscht werden. Die Löschung der Variablen darf durch eine softwareimplementierte Statusmaschine nicht im selben Takt erfolgen wie die Löschung von blockWriteFlag. Dies würde verhindern, dass der Betriebsartblock in dem Fall ausgeführt wird, in dem MBP=numModeBlocks oder die Betriebsartblock-Adresse, die geschrieben wird, geringer ist als der momentane MBP.
Der Vorberechr ungs- und Wiedergabeblock 308 wird immer dann ausgeführt, wenn modeBlockPointer auf einen neuen aktiven Betriebsartblock eingestellt wird. Die Steuerung springt von der Betriebsartblockanordnungs-Programmsteuerschleife hierher und kehrt nach Erledigung zur Programmsteuerschleife zurück. Ein Herausspringen kann erfolgen wenn ein startOfNewRecord-Ereignis eintritt. Ein Blockstatus im Betriebsartblock wird mit einem stoppedPlayback-Kennzeichen markiert. Die softwareimplementierte Statusmaschine entscheidet, wie auf eine derartige Situation reagiert werden soll.
Tabelle III
Die Verriegelungsspeicherverfügbarkeits-Programmsteuerschleife 310 reagiert auf neue Verriegelungsspeicherdaten. Die Verriegelungsspeicher werden niemals gelöscht, sondern es wird in sie am Ende jeder Wiedergabe geschrieben. Werden sie vor der nächsten Wiedergabe nicht verarbeitet, gehen die Daten verloren und werden nicht als Fehler mitgeteilt. Die Verfügbarkeit von neuen Verriegelungsspeicherdaten wird mitgeteilt; wenn die latchActivePointer-(LAP-)Variable auf einen gültigen Betriebsartblockwert eingestellt ist, der geringer ist als die Zahl von Betriebsartblöcken (numModeBlocks). Somit ist der Betrieb des Verriegelungsspeicher-Verfügbarkeitsblocks ereignisgesteuert. Sobald latchActivePointer unter einen geringeren Wert als numModeBlocks fällt, läuft der Block: Wenn jedoch die Initialisierung der Verriegelungsspeicherverfügbarkeits-Verarbeitung länger als einige wenige Takte dauert, muss die Initialisierung erfolgen, bevor die Daten tatsächlich verfügbar werden.
HyPMem verfügt über ein neues Verfahren, das die Speicherbank- und Zelladressblöcke verwenden kann, die automatisch umbrechen, ohne tatsächlich die Speicherzellen zu benutzen. Auf diese Weise können bei Ausführung der Freilandbetriebsart, die nicht hypHem benutzt, weiterhin diese beiden Register zum Wiederfinden des Ortes von maxData verwendet werden. Dieses Verfahren ist France's hypMem-Macro-Beschreibung hinzugefügt.
Werden maxData abgerufen, werden sie bei jedem Eintrag aktualisiert. Somit wird maxdataUpdateRate zu einem Ein-Bit-Wort und wird durch die Arbeit maxDataUpdate ersetzt. MaxDataReportRate wird entfernt und in der Software bearbeitet.
Es wird angenommen, dass, wenn eine Wiedergabe beendet ist, die arbeitenden Korrelatoren in die Korrelator-Verriegelungsspeicher kopiert werden, latchAvail auf eins eingestellt und der Verriegelungsspeicher-Verfügbarkeitsverweis (LAP) als Arbeitsbetriebsartblock-Verweis (MBP) eingestellt wird.
Wenn maxData nicht verarbeitet wird, werden neue Wiedergaben gemeldet, wenn sämtliche Wiedergaben für einen Betriebsartblock abgeschlossen sind. Diese Überprüfung könnte im Vorberechnungs- und Wiedergabeblock erfolgen, wobei es jedoch vorgezogen wird, diesen Schritt nur in einem Abschnitt auszuführen. Dies wird im Verriegelungsspeicher-Verfügbarkeitsblock durchgeführt, da wir auf die Aktualisierung von maxData warten, bevor wir der softwareimplementierten Statusmaschine mitteilen, das ein Betriebsartblock für einen weiteren Eintrag bearbeitet wurde.
Sobald der neue Betriebsartblock begonnen wird, besteht die Wahrscheinlichkeit, das die Verriegelungsspeicherdaten weiterhin von der letzten Wiedergabe des vorangehenden Betriebsartblocks verarbeitet werden. Somit können die Daten, die der maxData-Analyse im normalen Vorberechnungsabschnitt zugeordnet sind, nicht initialisiert werden. Daher muss eine Initialisierungsprogramm-Steuerschleife für jeden Betriebsartblock bei jedem Eintrag aufgerufen werden.
Tabelle IV
Ein Problem tritt dann auf, wenn der LAP auf den Ruhezustand von numMode-Blocks rückgesetzt wird, sofern der Wiedergabeblock ebenfalls den LAP auf den MBP im selben Takt einstellt. Oben war im Wiedergabeblock playbackState auf sieben unmittelbar vor dem Schreiben des neuen LAP eingestellt. Somit sollte jede Änderung an den LAP aufgeschoben werden, sofern playbackState=7 ist.
Um eine hohes Maß an Parallelität zu erzielen, wird eine große Bank von Hypothesen parallel implementiert, die dieselbe Trägermischung benutzen. Zur größtmöglichen Flexibilität werden virtuelle Codegeneratoren zum Synthetisieren eines höchst wahrscheinlichen _ Chipabstandes für die "search"-Betriebsart und eines schmaleren Abstandes für die "timeTrack"-Betriebsart bevorzugt. Für eine große Zahl von Codehypothesen kann jedoch die Implementierung mit virtuellen Codegeneratoren zu teuer sein.
Die Periode des 2.112-MHz-Abtasttaktes beträgt etwa die Hälfte einer Chip-Zeit. Um genau zu sein, ist sie 31/64 oder 1/64 kürzer als ein halber Chip. Für diesen Abstand ist die Zahl von Codehypothesen zur Abdeckung des 1.023-Chipbereiches 2.112. Dies erfordert drei Prozent (66 zusätzliche Codeorte) mehr Speicherplatz als die 2.046 Orte für einen perfekten Chipabstand benötigen.
Jüngste Testdaten zeigen an, dass der A-priori-Grenzfall-Modelliertehler für eine typische Kristallfrequenz etwa bei ±0,5 PPM (±787 Hz) bei Temperaturmodellierung liegt. Um sicherzugehen und eine bestimmte Unsicherheit für den Benutzerpositions-Fehlereffekt auf der Frequenz einzuräumen, wird vorzugsweise ein Frequenzbereich von ±1.000 Hz für den ersten Satelliten gesucht. Gibt es ein hohes Maß an Sicherheit über die Frequenzinformationen, die man bei einer ersten Suche gewonnen hat, kann der Frequenzsuchbereich nachfolgender Satelliten eingeschränkt werden, um Zeit und Aufwand zu sparen. Alternativ dazu können derartige Suchzeiteinsparungen mit einer geringeren Taktgeschwindigkeit getauscht werden, wie man sie in kostengünstigerer Hardware vorfindet.
Ein "Prädiktionsintervall" (PDI) ist die kohärente Integrationsperiode eintreffender und lokal erzeugter Signale; die unmittelbar vor dem Quadrieren endet, um die Potenz zu erhalten. Für ein Prädiktionsintervall von 10 ms ist das Frequenzverhalten der Trägertrequenzmischung eine Synchronfunktion mit den ersten Nullstellen bei ±100 Hz. Normalerweise ist der Frequenzsuchschritt derart gewählt, dass die nächste gesuchte Frequenz ihren Spitzenwert bei der Nullstelle der vorangehenden Frequenz hat. In diesem Fall wird alle 100 Hz gesucht, wobei die 1,5-dB-Bandbreite jedes Frequenzsuchschrittes ±50 Hz beträgt. Es werden 20 vollständige Codesuchen benötigt, um den gewünschten Bereich von ±1.000 Hz abzudecken.
Bei einem Zwei-Puffer-HF-Abtastschema wird jede Codehypothese, die durch eine Bank von Korrelatoren definiert ist, für ein vollständiges 10-ms- Vorhersageintervall in nur 2.112 Takten, wie etwa der Zahl von Abtasttakten in einer Millisekunde, aktualisiert. Die HF-Abtastungen werden mit derselben Teil-Millisekundenzeit in allen zehn Millisekunden vorgenommen. Diese werden anschließend gemischt und auf einen einzigen Abtasttakt korreliert, weshalb ein neuer Satz von Abtastungen zu jedem Abtasttakt gelesen wird. In zehn Millisekunden und bei 27.456 MHz gibt es 27.456 Mastertakte, die 130 Gruppen von 2.112 Abtastungen erzeugen können. Eine Gruppe von 2.112 Abtastungen, die eine spezielle Code- und Frequenzhypothese mischt, wird hier als "Wiedergabe" bezeichnet.
Wenn 20 vollständige Codesuchen in 120 Wiedergaben mit einigen verbleibenden Takten ausgeführt wurden, die für die Einrichtung benötigt wurden, dann ist die Zahl (N) von Wiedergaben, die erforderlich ist, um ein Codespektrum (1.023 Chips) zu ergeben 20*N = 120. In diesem Beispiel ist N = 6. Die Anzahl von "I" und "Q" Korrelatorenpaaren ist somit 2.112/6 = 352 für eine Gesamtzahl von 704 Korrelatoren. Dies ist in 2 gezeigt.
Eine alternative Ausführungsform erhöht die Mastertaktgeschwindigkeit um einen Faktor zwei, um beispielsweise eine Gesamtzahl von 260 Wiedergaben zu erreichen. Die Zahl von Wiedergaben kann auf zwölf erhöht werden, um ein vollständiges Codespektrum zu erreichen. Auf diese Weise werden lediglich 126 Korrelatorenpaare für eine Gesamtzahl von 352 einzelne Korrelatoren benötigt. Für dieses Beispiel sind 176 Korrelatoren mit einer Wiedergabegeschwindigkeit von 2*(27.456 MHz) = 54.912 MHz gewählt.
Der Code-NCO 206 ist eine 6-Bit-Addiereinrichtung, die 2.112 MHz Abtasttakte in 1.023 MHz konvertiert. Sie erzeugt einen Codetakt und ein div3-Signal, wenn es drei Abtastakte, die für einen Codetakt benötigt werden, anstelle der beiden normalen Abtasttakte gibt. Es gibt keine Verschiebungsmöglichkeit, aber die Phase kann durch Festlegen einer Ausgangszustandsvariablen "ncolnitialCondition" eingestellt werden.
Der Codegeneratorblock 208 verwendet zwei 10-Bit-Verschieberegister, um eine bestimmte Pseudozufallszahl zu erzeugen. Dieser Block beinhaltet drei Tabellen suchen auf der Basis der gewünschten Chipphase und der Pseudozufallsnummer; dies sind G1, G2 und G2-Verschiebung.
Der Code- und div3-Speicher 210 verwendet zwei Verschieberegister, um die Codegenerator- und div3-Ausgabesignale auf denselben Abtasttakt einzutakten und zu verzögern. Die Verzögerungstiefe ist im Grenzfall 17 1-Bit-Zustände für jedes Signal. Diese sind die Eingangssignale in die virtuellen Codegeneratoren für die Suche oder "meas-mode".
Der virtuelle Codegeneratorblock kann eine relative Verzögerung von ±31 64-Chips relativ zum Code im Verzögerungsspeicher synthetisieren. Positive Verzögerungen verwenden eine Kombination aus dem punktuellem Taktschlag und dem spätem Taktschlag. Frühe Verzögerungen verwenden eine Kombination aus dem punktuellen und dem frühen Taktschlag. Es gibt eine Gruppe von fünf virtuellen Codegeneratoren, die in der "search"-Betriebsart verwendet werden, und dann einen weiteren Vorrat von 15*5 virtuellen Codegeneratoren für eine Gesamtzahl von 16*5 = 80, die in der "timeTrack"- Betriebsart verwendet werden.
Ein Satz von fünf virtuellen Codegeneratoren wird hier als "Supervirtueller Codegenerator" bezeichnet. Dieser erzeugt die Phasen, die über einen 10-ms-Eintrag erforderlich sind, um die Doppler-Trajektorie zu kompensieren.
Der virtuelle Codegeneratorspeicher 208 enthält einen Satz von fünf 1-Bit-Verschieberegistern mit einer Länge von 176 am Ausgang der fünf virtuellen Codegeneratoren, die verwendet werden, um den Code-Doppler für das 10-ms-Prädiktionsntervall in der "search"- Betriebsart zu erzeugen. Die früheste Zustand 0 ist die direkte Ausgabe des virtuellen Codegenerators. Der letzte Zustand "175" ist 175 Abtasttakte vom Zustand 0 verzögert.
Der Codeverschiebespeicher wird verwendet, um den Zustand des gesamten Codeerzeugungsblocks auf einen bestimmten Abtasttakt einzutakten. Diese Daten werden bei einer nachfolgenden Wiedergabe erneut geladen, um eine virtuelle Codeverschiebung zu erzeugen.
Der digitale lokale Oszillator (DLA) 212 dividiert den Abtasttakt durch 16 und erzeugt eine 16-Zustandsvariable, die dloState genannt wird und von null bis 15 bei 132 kHz aufwärts zählt. Sie wird zur Erzeugung der letzten IF der Signalausgabe aus der letzten HF-Stufe verwendet.
Der Träger-NCO 214 oder der MasterTräger-NCO ist ein 24-Bit-Register, bei dem der Abtasttakt als seine Eingabe (528 kHz) durch vier dividiert wird, wobei die vier höchstwertigen Bits als ncoState decodiert werden, der von null bis 15 bei einer Frequenz aufwärts oder abwärts zählt (abwärts bei einer negativen Frequenz), die dem TrägerNcoValue entspricht.
Der SumState ist eine 4-Bit-Zahl, die die Summe von dloState und ncoState ist. Sie steht für die Phase, die durch die Summe des Doppler und der letzten IF erzeugt wird.
Die realStateCount-Variable zählt die Zahl der aufeinanderfolgenden Abtasttakte, wobei sich der Zustand des MasterTräger-NCO nicht ändert. Die Variable kann zudem verzögert werden, indem der Zähler vordividiert wird, bevor die Zählung erhöht wird. Dies ist erforderlich, um dem begrenzten Bereich der 4-Bit-Verzögerung gerecht zu werden, wenn der Doppler sehr klein ist.
Ein supervirtueller Träger-NCO ist eine Gruppe virtueller Träger-NCOs, die dieselbe Frequenz wie der MasterTräger-NCO erzeugen, jedoch bei Phasenverschiebungen, die modulo eine Millisekunde von der Masterträger-NCO-Phase verzögert sind. Jeder virtuelle Träger-NCO hat zwei 4-Bit-Register, wie etwa die "Verschiebung" und die "Verzögerung". Jeder virtuelle Träger-NCO erzeugt eine 4-Bit-Phasenverschiebung von der Phase des sumState. Die Verzögerungsvariable kann ein Additionsbit der Verzögerung addieren, wenn die momentane realState-Count die Verzögerungsvariable überschreitet, oder fortschreiten, wenn der Doppler negativ ist.
Der Träger-Mischer 216 mischt die HF-Abtastungen mit der Trägerphase, die von jedem der zehn NCOs erzeugt wird. Es gibt nur einen Träger-Mischer. Alle zehn Millisekunden der Abtastungen werden zugleich in derselben Teil- Millisekundenphase gemischt.
Der Code-Mischer erzeugt eine massive Parallelität, wobei bis zu 176 unterschiedliche Codehypothesen pro Mischung in der "search"- Betriebsart erzeugt werden können. In der "timeTrack"- Betriebsart, sind lediglich 16 verfügbar, da elf Korrelatoren erforderlich sind, um die Mischung in unterschiedlichen Zeitabschnitten zu isolieren. Für jede Hypothese gibt es einen Mischer sowie einen Phasengleich- und Quadratur-Integrator, wie etwa die "I"- und "Q"-Korrelatoren 222.
Die Hypotheseverriegelungsspeicher 224 sind Haltregister für "I" und "Q" der letzten Hypothese. Die Verriegelung wird derart angewendet, dass die nächste Mischung beginnen kann, ohne dass darauf gewartet werden muss, dass der RISC-Prozessor 258 die Daten liest. Jede neue Mischung überschreibt die alten Daten, so dass die Lesevorgänge des RISC-Prozessors 258 bis dahin die verriegelten Daten abrufen müssen.
Die digitale Signalverarbeitung wird durch eine Anzahl unterschiedlicher Variablen gesteuert, die geschrieben werden können. Die Variable der Satelliten-Pseudozufallszahl (SV:PRN) wird geschrieben, um eine neue Suche zu definieren. GPS-Satelliten im Orbit verwenden Pseudozufallszahlencodes 01–32. WAAS und Pseudolite sind im 33–4x-Bereich definiert. Eine Wortlänge von sechs Bits ist die minimale Anforderung. Die Codestartphasenvariable ist die "StartingCodePhase" und definiert die relative Startphase in 64 Teilen eines Chips. Dies ist ein vorzeichenloses 2-Byte-Wort und steht für die Phase rechts vom aller ersten Codefenster in der "search"- Betriebsart und links vom Codefenster in der "meas"- Betriebsart. Der Codephasenbereich ist 0–(1.023*64 – 1) = 0 bis 65.471. Es gibt 64 unbenutzte Werte, die berücksichtigt werden, wenn die Codephase ein gestellt wird. Die StartingCodePhase-Zahl kann auf einfache Weise in Chips und 64-tel gebrochen werden.
Tabelle V
Beispielsweise hat eine Codephase von 100 Chips und 17/64 eines Chips eine startingCodePhase=6.417. Wenn eine Obergrenze durch Addieren von mehr als 1.023*64 überschritten wird, wird lediglich ein Chip der Phase addiert, da die tote Zone einen ganzzahligen Chip bei einem Rollover von einer großen Phase zu einer kleinen Phase borgt.
Wenn in ähnlicher Weise eine positive Phase von einer kleinen startingCodePhase abgezogen wird, führt das Verfahren einen Rollunder aus und belegt die tote Zone um zu einer großen Phase überzugehen. Die Korrektur besteht darin, 1 zu subtrahieren, da die unkorrigierte Phase um 1 zu groß ist, um von der kleinen Phase zur großen Phase überzugehen.
Die Doppler-Start-"CarrierNcoValue"-Variable ist in Träger-NCO-Einheiten von Bits definiert. Ein mit einem Vorzeichen versehenes 3-bit-Wort wird verwendet, um den Träger-Doppler in einer Zykluszahl pro Sekunde darzustellen. Eine finale Zwischenfrequenz (IF) von 132 kHz braucht in dieser Variablen nicht enthalten zu sein, da die finale IF durch einen digitalen lokalen 16-Status-Oszillator außerhalb des Träger-NCO demoduliert wird. Der Träger-NCO hat 24 Bits mit einem Eingangstakt, der der Abasttakt geteilt durch vier ist. Der Skalierungsfaktor für die Konvertierung des TrägerNcoValue von Bit zu Hertz ist
CARRIER_NCO_HZ_PER_BIT = 2.112 MHz/4/2^24 = 0,031471252 Hz/Bit.
Um einen Träger-Doppler von 5.000 Hz in Träger-NCO-Einheiten umzuwandeln, wird der Doppler durch die oben erwähnte Konstante dividiert, um Biteinheiten zu erhalten und einen TrägerNcoValue=158875 zu erreichen. Somit gilt CarrierNco-Value=Carrier-Doppler in Hz/CARRIER_NCO_HZ_PER_BIT. Diese Division erfolgt im Navigationsprozessor und wird zum DSP in einer normalen Steuernachricht gesendet.
Es gibt normalerweise drei DSP-Betriebsarten, (1) "search"-Betriebsart (nicht ko härent), (2) "weakMeas"-Betriebsart (nicht kohärent) und (3) "timeTrack"-Betriebsart (kohärent). Die momentane Betriebsart ist mit der DSPmode-Variablen definiert. Wenn ein Code in der DSPmode = "search"-Betriebsart erzeugt wird, erzeugt ein am weitesten rechts gelegener Korrelator eine Phase, die durch die startingCodePhase definiert ist. Ein derartiges Übereinkommen vereinfacht den Vorbereitungsbetrieb.
In zwei Betriebsarten gibt es nur eine Frequenzmisch-Annahme, wobei sämtliche Korrelatoren mit dem Ergebnis der 1-ms-Trägerfrequenzmischungen arbeiten, die mit den zehn VNCO erzeugt wurden. Die virtuellen Träger-NCO erzeugen die kohärente Phase einer Sinuswelle für eine bestimmte Millisekunde über ein 10-ms-Prädiktionsintervall.
Das es nur eine Frequenzhypothese pro Mischung gibt, wird die erforderliche Parallelität in der Codedomäne unter Verwendung einer Anzahl paralleler Codephasenhypothesen erzeugt. In diesem Fall nimmt jedes Korrelatorenpaar denselben Ausgang der Trägerfrequenzmischung und mischt anschließend eine unterschiedliche Codephasen-Annahme.
In der "search"-Betriebsart (nicht kohärente Betriebsart) erfolgt die Codeverschiebung für jeden Korrelator auf der Rechtes seine oder später durch Verzögern des Codes um einen Abtasttakt, wie beispielsweise exakt 31/64. Somit ist in der "search"-Betriebsart der hypothesisSpacing unveränderbar und nicht steuerbar. Es gibt ein Korrelatorpaar für jede Codehypothese, die die phasengleichen Ergebnisse und Quadratur-Ergebnisse für eine vollständige 10-ms-Korrelation enthalten.
Um eine Code-Dopplerverschiebung, die über eine 10-ms-Mischung auftritt, und die erforderliche Phasenspanne aufzunehmen, werden fünf virtuelle Codegeneratoren mit fünft 176-Status-1-Bit-Verschieberegistern benutzt. Diese werden mit einem Abtasttakt getaktet, um die 31/64 eines Chipzwischenraumes zu erzeugen.
Der virtuelle Codegenerator erzeugt einen Phasenverschiebung relativ zur Referenzphase, die durch den Mastercode-NCO und den Codegenerator definiert ist.
Jeder virtuelle Codegenerator erzeugt die Phasenverschiebung über zwei Millisekunden, um eine 10-ms-Spanne mit fünf virtuellen Codegeneratoren abzudecken. Die Trägermischung für zwei Millisekunden verwendet dieselbe Codemischung. Ein virtueller Codegenerator ist zu viel, da es keine Langzeit-Bias gibt, wenn der Code-Doppler-NCO ordnungsgemäß gehandhabt wird.
Für einen Träger-Doppler von 20 kHz müssen die virtuellen Codegeneratoren lediglich ±10/64 eines Chips einer Phasenänderung infolge des Code-Doppler über zehn Millisekunden erzeugen. Diese relative Phasenverschiebung kann mit nur drei Codeversionen erreicht werden. Die frühe Codeverschiebung, 10/64 eines Chips aufwärts verwendet einen frühen Code-Taktschlag und den punktuellen Taktschlag, wenn die Zählvariable des virtuellen Codegenerators null ist. In ähnlicher Weise wird die späte Codeverschiebung unter Verwendung des punktuellen Code-Taktschlag und des späten Taktschlag erzeugt, wenn die Zählvariable des virtuellen Codegenerators null ist.
Es werden lediglich drei Zustände des Code- und div3-Speicherblocks für die "search"-Betriebsart verwendet.
Die Ausgabe jedes der fünf virtuellen Codegeneratoren wird in dessen eigenes 1-Bit-Verschieberegister eingegeben, das 176 Zustände lang ist und mit dem Abtasttakt getaktet ist. Der frühe Taktschlag ist tatsächlich die Ausgabe des Generators.
Im Detail werden bei jedem Abtasttakt und nach der Aktualisierung des codeNco und des Zustandes des Codegenerators, die Verschieberegister getaktet, wodurch sich die Inhalte der Register um eine Zelle nach rechts bewegen. Die vorherigen fünf Zustände auf der rechten Seite werden verworfen.
Der Zustand des virtuellen Codegenerators wird als Startphase (früheste Phase) betrachtet und direkt in das erste Korrelatorpaar weitergegeben. Die Vorbereitung des Codeerzeugungsblocks für die "search"-Betriebsart umfasst zwei Schritte, die Vorbereitung des Code- und div3-Speichers und anschließend die Vorbereitung des Speichers in Gestalt der Verschieberegister am Ausgang der virtuellen Codegeneratoren. Details der Vorbereitung sind im Vorbereitungsabschnitt erläutert.
Beträgt die gewünschte Codephase 100 Chips und 17/64 eines Chips, dann ist eine geringfügige Einstellung an der Hardwarephase erforderlich, um den frühen, punktuellen und späten Verzögerungen Rechnung zu tragen, so dass die gewünschte Codephase in der punktuellen Verzögerung beim ersten Takt der Wiedergabe erzeugt wird und zudem sämtliche Verzögerungen gültig sind, wenn die Wiedergabe beginnt. Um dies zu tun, wird die gewünschte Codephase um das abgeändert, was der Vorbereitungseffekt ist, was im Fall er "search"-Betriebsart, wenn lediglich drei Zustände vom Code- und div3-Speicherblock verwendet werden, der Umstand ist, dass der Code-NCO und der Codegenerator für die erforderliche Taktzahl betrieben werden, bis die frühesten drei der Register gefüllt sind.
Der punktuelle Code im 176-Zustand wird durch Verschieben der Register um 1 beim ersten Abtasttakt der Wiedergabe initialisiert. Der Verzögerungsblock, der 176 tief ist, wird in zwei Schritten vorbereitet. Der erste bereitet den Verzögerungsblock vor, der verwendet wird, um die virtuellen Codegeneratoren zu versorgen. Die zweite Vorbereitung füllt anschließend den Verzögerungsblock, der die Ausgabe aus den virtuellen Codegeneratoren verwendet.
Für die zweite Vorbereitung werden die virtuellen Codegeneratoren die erforderlich Zahl von Abtasttakten getaktet, um den zweiten Verzögerungsspeicher zu füllen. Die gewünschte punktuelle Phase befindet sich im rechtesten Verzögerungsregister bei einem ersten Abtasttakt der Wiedergabe.
Auf die "weakMeas"-Betriebsart wird nach einer Serie fehlgeschlagener Suchen nach einer Gruppe von Satelliten ausgeweicht. Die Leistungsspitzen einzelner Suchen werden erneut besucht, diesmal mit einer feineren Suchauflösung. In der "weakMeas"-Betriebsart wird ausreichend Zeit darauf verwendet, eine große Zahl von Satelliten parallel zu suchen, weil sich dadurch die Unsicherheit verringert.
Es kann eine weitere Art des Korrelatorenabstandes implementiert werden, so dass das Ergebnis ausreichend genau ist, um eine Positions- und eine Geschwindigkeitsfixierung vorzunehmen. Bei einer Simultansuche von acht Satelliten können beispielsweise fünfzehn Frequenzen für jeden Satelliten durchsucht werden, wobei 120 der 130 verfügbaren Hypothesen verwendet werden. Dies spart genügen Mastertakte für die Vorberechnung zwischen Hypothesen ein. Die Mittenfrequenz kann auf die beste Frequenz zur Suchzeit eingestellt werden, wobei sich acht Frequenzen auf jeder Seite befinden. Eine Schrittgröße von 50 Hz bietet einen Bereich von ±425 Hz. Für ein 1-g-Beschleunigungsmodell, d. h. somit 10 m/s² in zehn Sekunden, ist die maximale Geschwindigkeitsänderung g*10 = 100 m/s = 500 Hz. Eine Schrittgröße von 50 Hz führt zu einem maximalen Frequenzfehler von 25 Hz, was etwa fünf m/s der Geschwindigkeit ist. Dies liegt auf der Grenze eines akzeptablen Rauschverhaltens für eine Geschwindigkeitsfixierung. Somit kann die Schrittgröße verringert werden, wenn bekannt ist, dass die Benutzerdynamik kleiner ist.
In der Codedomäne werden alle 176 Korrelatoren verwendet, um eine weitere Codesuche mit einem sehr geringen Abstand zwischen jeder Codehypothese zu erzeugen. Ein Schema verwendet 2/64 eines Chipabstandes, so dass der schwerstwiegende Fehler 1/64 eines Chips, etwa 4,5 Meter ist. Dies erfüllt die Sollbereichsgenauigkeit für schwache Signale.
Es wird ein Codehypotheseabstand erzeugt, wobei 16 supervirtuelle Codegeneratoren bestehend aus jeweils fünf virtuellen Codegeneratoren verwendet werden, um das Code-Dopplerprofil über den 10-ms-Eintrag zu erzeugen. Der Abstand der virtuellen Codegeneratoren beträgt 2/64 eines Chips. Auf diese Weise wird ein Fenster einer Codehypothese erzeugt, das 0, 2, 4, 6, 10, 12; 14, 16, 18, 20, 22, 24, 26, 28, 30 Vierundsechzigstel eines Chips von einem Referenz-Code-Taktschlag ist. Die Ausgaben der virtuellen Codegeneratoren werden um einen Abtasttakt (31. Teile) verzögert, um ein sehr langes feines Codehypothesefenster zu erzeugen.
Die Verschiebung zwischen jedem supervirtuellen Codegenerator ist vorzugsweise immer dieselbe. Ein erster virtueller Codegenerator in jedem supervirtuellen Codegenerator gibt 1 = 0/64, 2 = 2/64, 3 = 4/64, 4 = 6/64, 5 = 8/64, ..., 16 = 30/64 eines Chips aus. Die Verschiebungen aufeinanderfolgender virtueller Codegeneratoren in jedem supervirtuellen Codegenerator sind dieselben wie bei den vorangehenden virtuellen Codegeneratoren, mit Ausnahme der Doppler-Trajektorie über das 10-ms-Prädiktionsintervall. Diese Daten werden in einem Virtuell-Codegenerator-Vorberechnungsschritt programmiert.
Die Ausgabe jedes virtuellen Codegenerators wird zu einem 11-Bit-Verschieberegister gesendet. Ein am weitesten links gelegener Zustand jedes Verschieberegisters ist derselbe Wert wie die momentane Ausgabe des virtuellen Codegenerators, d. h. der Zustand 0 hat eine Verzögerung von null. Ein finaler Zustand auf der rechten Seite ist zehn Abtasttakte von der Ausgabe des virtuellen Codegenerators verzögert.
Die Korrelatoren sind der Codeerzeugung zugeordnet. Ein erster Korrelator nimmt einen Code, der in einem ersten Zustand eines ersten Supervirtuell-Codegenerator-Verzögerungsregisters vorhanden ist. Ein 16. Korrelator nimmt einen Code, der in einer ersten Verzögerung des 16. supervirtuellen Codegenerators vorhanden ist. Anschließend nimmt der 17. Korrelator den zweiten Zustand des Verschieberegisters des ersten supervirtuellen Codegenerators, und der 32. Korrelator nimmt den zweiten Zustand des Verschieberegisters des 16. supervirtuellen Codegenerators, etc..
Die supervirtuellen Generatoren werden verwendet, um 2/64 eines Chipabstandes zu erzeugen. Jeder virtuelle Codegenerator gibt die Code-Doppler-Trajektorie über einen 10-ms-Eintrag aus. Alle 16 supervirtuellen Codegeneratoren erzeugen einen Phasenbereich von 30/64 eines Chips bei 2/64 Abstand. Durch Verzögern der Ausgabe jedes supervirtuellen Codegenerators kann der Kamm des Phase, die mit 31/64-Schritten erzeugt wird, repliziert werden. Die maximale Zahl möglicher Verzögerungen ist durch die Zahl von Korrelatoren begrenzt. Die magische Zahl ist 11 da 176 = 16*11. Dies führt zu einem maximalen Bereich von 1.
1/32 einer Chip-Suchmaschine wird erzeugt, indem die Ausgabe der supervirtuellen Codegeneratoren durch mehrere Abtasttakte verzögert wird. Der Gesamtbereich bei Verwendung sämtlicher elf Verzögerungen ist 340/64 = 5 Chips und 2/64 eines Chips. Die größeren Linen haben eine Verschiebung, die modulo 31 ist.
Alle Verzögerungen, die größer als 30/64 sind, werden durch die Verzögerungsregister erzeugt. Sämtliche Verzögerungen zwischen null und 30 werden von den Verzögerungsregistern erzeugt.
In der "timeTrack"-Betriebsart werden feinere 2/64-Korrelatorabstände aus 1/64 bis 3/64 erzeugt, wie etwa für ein Maximum von 16 individuellen Codehypothesen. Es werden weniger Hypothesen erzeugt, so dass die Korrelatoren für die Möglichkeit einer kohärenten Integration genutzt werden können. Die Mischung kann für jeden von zehn Codezeitabschnitten getrennt werden, anstelle zehn separate Millisekunden in unterschiedliche Korrelatoren zu trennen.
Dadurch wird eine Synchronisation mit den 50-Hz-Navigationsdaten bei der GPS-Sendung ermöglicht, so dass nicht über eine Datenbitgrenze integriert werden muss. Dadurch werden Verlusste verringert und die Möglichkeiten einer ganzzahligen Millisekundenzeitgabe verbessert.
Ausführungsformen der vorliegenden Erfindung können derart ausgebildet sein, dass sie einem herkömmlichen Verfolgungsempfänger mit einer unbegrenzten zahl von Kanälen gleichen. Dies wird hier als "timeTrack"-Betriebsart bezeichnet, wobei die Zeit durch Beobachten des Datenbits ermittelt werden kann und anschließend die Navigationsdaten demoduliert werden, um die Zeit vom GPS zu erhalten. Dies ist in den beiden anderen Betriebsarten nicht möglich, da das Signal zu schwach ist, um die Navigationsdaten zu beobachten. Um zehn Millisekunden abzudecken, werden elf Korrelatoren benötigt, um eine optimale Erfassung einer Navigationsdaten-Bitgrenze zu gestatten. Die maximale Zahl verwendeter Korrelatorenpaare ist (15*2 + 11) = 41, vorausgesetzt alle 16 Codehypothesen werden benutzt. In diesem Fall verwenden 15 Codehypothesen zwei Korrelatorenpaare, und eine Codehypothese verwendet elf Paare. Es können so wenig wie 16 Paare und 32 Paare in anderen Betriebsarten verwendet werden.
Während der herkömmlichen Verfolgung ist normalerweise ein Codehypothese auf einem Code-Autokorrelations-Funktionsspitzenwert zentriert. Das entsprechende Korrelatorpaar steht für den besten Signalrauschabstand und ist das beste Mittel, um halbzyklische Trägerfrequenz-Phasenänderungen zu beobachten.
Die anderen Codehypothesen können ebenfalls derartige Änderungen beobachten, wobei jedoch die Zahl der Korrelatoren, die von der softwareimplementierten Statusmaschine gelesen werden müssen, zu groß wäre.
In der "timeTrack"-Betriebsart steht lediglich eine Codehypothese pro Wiedergabe für eine Option von elf Korrelatoren. Der relative Ort dieser Codehypothese ist variabel. Die Zahl der Codehypothesen, die auf jeder Seite des Spitzenwertes verwendet werden sollen, kann verändert werden.
Die anderen Codehypothesen in der "timeTrack"-Betriebsart teilen den 10-ms-Eintrag in ein oder zwei Korrelatorpaare. Es gibt zwei Optionen für die Zwei-Korrelatoren-Betriebsart. Bei der ersten wird der 10-Millisekundenblock in zwei 5-Millsekungsnblöcke geteilt. Bei der zweiten wird der 10-Millisekundenblock gemäß einer Schätzung des Ortes der Navigationsdaten-Phasenumkehrung geteilt.
Die Korrelatoren abseits des Spitzenwertes werden für die Verzögerungsverriegelungs-Programmsteuerschleife verwendet. Der Leistungsunterschied wird zwischen den Codehypothesen auf jeder Seite der zentralen Codehypothese untersucht, um Steuerinformationen zu bilden.
Das Fortschreiten von der Suche zur Verfolgung beginnt mit der Benutzung der Suchlogik, um einen Codespitzenwert zu finden. Die "search"-Betriebsart übergibt zur "timeTrack"-Betriebsart Sämtliche Korrelatoren sind derart konfiguriert, dass sie in zwei 5-Millisekunden-Blöcke ausgeben, bis der Codespitzenwert geklärt ist. Sobald der Code bekannt ist, erfolgt eine Nebenkeulenprüfung des Frequenzspitzenwertes. Eine 11-Korellatoren-Option kann einen großen Frequenzfehler in den 1-ms-Ausgaben erfassen. Nachdem der Codespitzenwert und die Frequenzspitzenwerte geklärt sind, wird die 11-Korrelatoren-Codehypothese auf dem Spitzenwert plaziert und Zeit darauf verwendet, nach einem Phasenumkehrpunkt zu suchen. Das Ergebnis kennzeichnet die Millisekunde, bei der ein Bitübergang auftritt.
Die anderen Korrelatorenpaare verbleiben in einer 5-Millisekunden-Blockoption, bis der Bitübergang bekannt ist. Die Korrelatoren schalten um, um die Daten auf jeder Seite des Bitübergangs in die beiden Korrelatoren einzugeben.
Als Beispiel dafür dient die Ziehharmonika-Betriebsart, mit 16 Codehypothesen, getrennt durch einen _ Chip für einen Bereich von acht Chips. Der Bereich ist zwei Chips für den _ Chipabstand. Es ist ein engerer Abstand bis auf 1/64 möglich, wobei Mehrfachwiedergaben verwendet werden können, um breitere Codemischungen mit sehr geringen Abständen zu erzeugen.
Eine zusätzliche Gruppe von 15*5 virtuellen Codegeneratoren wird verwendet, um die Ziehharmonikaverschiebung über die 16 Codehypothesen zu erzeugen. Eine relative Phasenverschiebung wird aus 0–15*32/64 eines Chips erzeugt. Wenn jedoch der Code-Dopplereffekt von ±10/64 enthalten ist, gibt es einen Bereich eines ungünstigsten Falls von –10 bis 15*32 + 10, wie etwa –10 bis 490 (< 16*31). Somit werden nur ein frühes Register, ein punktuelles Register und 16 späte Register benötigt. Der Codegeneratorstatus wird als das frühe Register benutzt.
In der "serach"-Betriebsart werden die Code- und div3-Speicherregister derart vorbereitet, dass der vollständige Block beim ersten Abtasttakt der Wiedergabe gültig ist. Die Codeerzeugung für die "time-Track"-Betriebsart unterscheidet sich von der "search"-Betriebsart dadurch, dass es keine zusätzlichen Verzögerungen an den Ausgängen der virtuellen Codegeneratoren gibt. Es existiert lediglich die Vorbereitungsphase, so dass es einfacher ist festzulegen, dass ein punktueller Korrelator die zweite Verzögerung ist und die anderen Verzögerungen später erfolgen. Die erste wahre Verzögerung als frühe Verzögerung ist tatsächlich direkt die Ausgabe des Codegenerators. Die niedrigeren Korrelatorzahlen stehen für die frühere Phase.
Es gibt zwei Korrelator-Betriebsarten in der "timeTrack"-Betriebsart. In der "before BTT-detection"-Betriebsart wird das 10-ms-Prädiktionsintervall in elf Teile gebrochen, die anstelle der Millisekunde den CA-Code-Zeitraum als Grenzlinie haben. Da nur eine Millisekunde abläuft, tritt der erzeugte Zeitraum zum exakt selben Zeitpunkt in jeder Millisekunde ein. Der Zeitraum könnte für jede zu kompensierende Millisekunde verzögert werden. Dies ist nicht wirklich erforderlich, da ein Fehler lediglich dann auftritt, wenn es eine Phasenumkehr gibt, die durch die Navigationsdaten bewirkt wird, und dies im schlechtesten Fall nur fünf Abtasttakte in der Millisekundenintegration beeinflusst, in der die Umkehrung aufgetreten ist.
Die "before BTT-detection"-Betriebsart ist bei der Einrichtung der Phase des Navigationsdatenbit von Bedeutung. Anschließend ist es ausreichend, in einem Bereich einer erwarteten Bitübergangszeit in nur zwei Korrelatorpaare zu korellieren. Anschließend kann eine zweite Betriebsart "after BTT-detection" aktiviert werden. Die Prozessorfirmware erhält die identifizierte Millisekunde und sendet diese als Korellations-Teilungslinie. Sämtliche vorherigen Daten einer linken Seite des Zeitraums in einer derartig festgelegten Millisekunden gelangen in einen Korrelator auf der linken Seite (LHS). Alle nachfolgenden Daten auf einer rechten Seite des Zeitraums in der festgelegten Millisekunde gelangen in einen Korrelator auf der rechten Seite (RHS). Die Daten in der festgelegten Millisekunde vor dem CA-Code-Zeitraum gelangen in den LHS-Korrelator, wohingegen die Daten nach dem CA-Code-Zeitraum in den RHS-Korrelator gelangen.
Eine BTTmode-Variable ist nur in der "timeTrack"-Betriebsart, d. h. DSPmode=3 ("timeTrack"-Betriebsart), wirksam. Ist BTTmode=0, dann verwenden alle Codehypothesen lediglich einen oder zwei Korrelatoren in Abhängigkeit einer weiteren Variablen. Ist BTTmode=1–15, arbeitet eine Codehypothese in der Vor-Erfassungs-Betriebsart. Die elf Korrelatoren, die in der Codehypothese verwendet werden sind gleich BTTmode. Wenn beispielsweise BTTmode=7 ist, dann arbeitet die Codehypothese mit dem Index 7 in der Vor-BTT-Erfassungs-Betriebsart. Es wird angenommen, dass die Indizierung von 0 bis 15 erfolgt, was bedeutet, dass die 0-te Codehypothese nicht in der Vor-Betriebsart laufen kann. Dies ist zulässig, da die Vor-Option zwischen einem Satz von Nach-BTT-Erfassungsbetriebsart-Korrelatorpaaren zentriert ist.
Eine BTT-Millisekunden-Variable legt einen erwarteten Datenbit-Übergangspunkt fest. Ist BTT-Millisekunde=0 oder 11 bis 14, dann wird lediglich ein Korrelator für die Codehypothesen in der Nach-Erfassungs-Betriebsart unabhängig von einer Millisekunde oder dem Zeitraum verwendet. Ist BTT-Millisekunde=1, 10, dann werden zwei Korrelatoren für die Codehypothesen in der Nach-BTT-Erfassungs-Betriebsart verwendet. Zudem basiert die Trennung auf dem Zeitraum innerhalb dieser festgelegten Millisekunde. Wenn beispielsweise BTT-Millisekunde=3 ist, dann ist der Teilungspunkt der Zeitraum in der dritten Millisekunde.
Ist BTT-Millisekunde=15, dann wird die Korrelation in zwei Korrelatoren in der Mitte des 10-ms-Eintrags unabhängig vom Zeitraumsort geteilt. BTTmode und BTT-Millisekunde erzeugen sechs "timeTrack"-Betriebsart-Verarbeitungsoptionen. Die beiden Variablen BTTmode und BTT-Milllisekunde können fünf unterschiedliche Arten der Mischung für die "timeTrack"-Betriebsart erzeugen. Der Mischer hat drei Optionen, die Mischdaten können allesamt addiert, zwischen zwei Korrelatoren geteilt oder durch den Zeitrum getrennt werden. Es können wenigstens sechs Verfahren bei der Implementierung Anwendung finden.
Ein erstes Verfahren hat die geringste Zahl zu lesender Korrelatoren, keine BTT und ein 10-ms-Prädiktionsintervall je Korrelator. BTTmode=0 und BTT-Milliskunde=0. Jede Codehypothese wird an einen Korrelator ausgegeben. Dies ist in Wahrheit dasselbe wie die Mischung für Such- und "weakMeas"-Betriebsarten. Diese Betriebsart ist geeignet, wenn ein großes Codefenster betrachtet wird, um die Leistung nach einer Freiland-"search"-Betriebsart zu finden und keine Zeitgabeinformationen vorhanden sind, um die geringste Zahl zu lesenden Korrelatoren zu erzeugen.
Es gibt einen gewissen Datenverlust, da die Navigationsdaten-Phasenumkehr innerhalb eines 10-ms-Eintrags auftreten kann. Jeder andere 10-ms-Eintrag erfährt jedoch keinen derartigen Verlust. Der Eintrag geht vollständig verloren, wenn sich die Phasenumkehrung exakt in der Mitte einer 10-ms-Periode befindet. Die Hälfte der verfügbaren Leistung geht verloren, wenn sich die Phase alle 20 Millisekunden in der Mitte eines Eintrags ändert.
Ein zweites Verfahren hat die zweitgeringste Zahl zu lesender Korrelatoren, keine BTT und zwei 5-ms-Prädiktionsintervalle je Korrelator. BTTmode=0 und BTT-Millisekunde=15. Jede Codehypothese wird an zwei Korrelatoren ausgegeben, die jeweils eine Dauer von exakt fünf Millisekunden haben. Diese Betriebsart ist geeignet, wenn ein großes Codefenster betrachtet wird, um die Leistung beispielsweise nach einer Freiland-"search"-Betriebsart zu finden, wenn keine Zeitgabeinformationen verfügbar sind und der Verlust infolge der Phasenumkehrun gen minimiert werden soll.
In gewisser Weise kann eine 5-ms-Leistungsberechnung ausgeführt oder die Phasenumkehr gekennzeichnet werden, so dass nicht über diese integriert wird. Eine 5-ms-Prädiktionsintervall-Option ist ebenfalls hilfreich, um eine Frequenzspitze infolge einer größeren Frequenzbandbreite, wie etwa 200 Hz anstelle von 100 Hz, zu finden.
Ein drittes Verfahren sucht nach BTT-Informationen der Vor-BTT-Erfassung und hat zwei 5-ms-Prädiktionsintervalle je Korrelator. BTTmode=(1 bis 15) und BTT-Millisekunde=15. Sämtliche Codehypothesen mit Ausnahme der einen, die durch BTTmode erfasst wurde, werden an zwei Korrelatoren ausgegeben, die eine Dauer von exakt fünf Millisekunden haben. Die Codehypothese gleich der BTTmode wird in elf Korrelatoren ausgegeben. Diese Betriebsart eignet sich, nachdem die Code- und Frequenzspitzen geklärt wurden und wenn nach Phasennavigationsdaten von Phasenumkehrungen gesucht wird.
Eine viertes Verfahren sucht nach BTT-Informationen der Vor-BTT-Erfassung, wobei ein 10-ms-Prädiktionsintervall in jedem Korrelator verwendet wird. BTTmode=(1 bis 15) und BTT-Millisekunde=0. Jede Codehypothese wird an einen Korrelator ausgegeben, mit Ausnahme der Codehypothese, die durch BTTmode festgelegt wurde. Diese Betriebsart ist etwas eigenartig, minimiert jedoch die Zahl von Korrelatoren, die durch die softwareimplementierte Statusmaschine zu lesen sind.
Ein fünftes Verfahren behält BTT bei, wobei der Korrelator an einem Zeitraum von BTT-Millisekunde geteilt ist und BTTmode=(1–15) und BTT-Millisekunde=(1–10). Sämtliche Codehypothesen, außer der einen, die durch BTTmode festgelegt wurde, werden an zwei Korrelatoren ausgegeben. Der Teilungspunkt ist der Zeitraum der Millisekunde, festgelegt durch die BTT-Millisekunde. Die Untersuchung der einen Millisekunden-Korrelatorwerte hält an, um zu beobachten, wann der Umbruch des Zeitraums über die Grenze einer Millisekunde erfolgt. Dadurch wird die beste ganzzahlige Millisekundenbereichs-Leistungsfähigkeit erzeugt. Die Verfolgungslogik kann zu einem 20-ms-Prädiktionsintervall zu Verfolgungsmöglichkei ten eines maximal schwachen Signals mit einer wahren kohärenten 20-ms-Integrationsperiode umschalten.
Ein sechstes Verfahren stoppt die Suche von BTT, wobei der Korrelator an einem Zeitraum von BTT-Millisekunde geteilt ist. BTTmode=0 und BTT-Millisekunde=(1–10). Sämtliche Codehypothesen werden an zwei Korrelatoren ausgegeben, wobei der Teilungspunkt der Zeitraum der Millisekunde ist, festgelegt durch BTT-Millisekunde.
Dieses Verfahren eignet sich, wenn die Ziehharmonika-Betriebsart verwendet wird, um Spitzenwerte mit sehr geringen Abständen genauer zu untersuchen. Der Spitzenwert wird für die reflektierte Leistung untersucht und um zu verifizieren, dass sich kein größerer Strahl in der Nähe befindet.
Die Verfolgungslogik kann zu einem 20-ms-Prädiktionsintervall zu Verfolgungsmöglichkeiten eines maximal schwachen Signals Dank einer wahren kohärenten 20-ms-Integrationsperiode umschalten.
Eine numHypotheses-Variable steuert die Zahl von Codehypothesen, die bei jeder Wiedergabe ausgeführt wird. Diese eine vorzeichenlose Byte ist die Zahl von Korrelatoren, die in der Mischung verwendet werden. Diese Verfahren kann zusammen mit der Nach-Erfassungs-BTT-Betriebsart verwendet werden, um eine herkömmliche Verfolgungsbetriebsart geringer Leistung zu erzeugen.
NumHypotheses ist zudem in mehr als einer Betriebsart gültig. Es kann ein schmalerer Bereich durchsucht werden, um Zeit und Leistung zu sparen, indem keine ungeeigneten Codehypothesen gesucht werden. Für die "search"-Betriebsart bedeutet dies, wie viele der Verschiebeverzögerungsregister aktiv sind. In diesem Fall ist die Zahl der aktiven Korrelatoren gleich numHypotheses.
Für die "weakMeas"-Betriebsart bedeutet dies, wie viele der Verzögerungen am Ausgang der virtuellen Codegeneratoren aktiv sind. Die Zahl der aktiven Korrelatoren ist (16*numHypotheses), da die 16 supervirtuellen Codegeneratoren aktiv gehalten werden. Ist numHypotheses eins, erstreckt sich der Bereich, der abge sucht wird, von startingCodePhase zu startingCodePhase plus 30/64 eines Chips. Für die "timeTrack"-Betriebsart bedeutet dies, wie viele der supervirtuellen Codegeneratoren aktiv sind. Die Zahl der aktiven Korrelatoren ist eine Funktion der BTT-Betriebsart, die oben erläutert wurde.
Eine hypothesisSpacing-Variable steuert den Abstand in 1/64 eines Chips zwischen jeder Codehypothese. In der "search"-Betriebsart ist der Abstand fest mit 31/64 eines Chips verbunden, so dass diese Variable ignoriert wird. In der "weakMeas"-Betriebsart wird der Korrelatorabstand automatisch auf 2/64 eines Chips programmiert. Somit wird die hypothesisSpacing-Variable hauptsächlich in der "timeTrack"-Betriebsart verwendet. Dies ist eine vorzeichenlose 5-Bit-Zahl mit einem Bereich von 1–32.
Eine numCodeWindows-Variable repräsentiert die Zahl der Häufigkeit, mit der eine Codehypothesen-Öffnung zu einer neuen Phase für einen gegebene Frequenz verschoben wird. Um eine vollständige Codeabtastung sämtlicher möglicher Codehypothesen zu bekommen, hat diese Variable einen Wert von zwölf. Somit ist dies eine 4-Bit-Zahl mit einem Bereich von 1 bis 16. Sie wird lediglich in der "search"-Betriebsart verwendet und sowohl in der "weakMeas"- als auch der "timeTrack"-Betriebsart ignoriert.
Eine windowShift-Variable steuert die Verschiebung der Codephase, die zwischen aufeinanderfolgenden Codefenstern auftreten muss, wenn numCodeWindows größer als eins ist. Da das Codefenster in der "search"-Betriebsart wiederholt wird, ist der Abstand einfach das Produkt aus (numHypotheses*31). Dies kann im DSP 114 als eine Verschiebung nach links um fünf und anschließendes Subtrahieren der originalen Zahl, wie etwa (x*31 = x*32 – x), berechnet werden. Eine timesTwoMode-Variable schaltet bei Bedarf eine schnellere Wiedergabemöglichkeit ein, wie etwa wenn ein größerer Frequenzbereich abgesucht werden muss.
Eine Dividierbetriebsart kann erforderlich sein, um den Takt langsamer laufen zu lassen und Betriebsleistung in der "timeTrack"-Betriebsart zu sparen, wie etwa wenn nur einige wenige Wiedergaben ausgeführt werden müssen. Eine numRecords-Variable ist die Zahl aufeinanderfolgender Einträge, um den momentanen Satz von Hypothesen auszuführen. Jeder Wert größer als 1 bedeutet, dass wir wirklich jeweils nur nach einem Satelliten suchen, und somit können wir bei dem momentanen Hypothesensatz bleiben, da wir nicht zu anderen Satelliten umschalten. Davon wird lediglich in der "search"-Betriebsart Gebrauch gemacht. Beispielsweise, um bei einem Satelliten für eine Sekunde zu bleiben. In diesem Fall hätte die Variable einen Wert von 100. Dies ist eine vorzeichnlose 8-Bit-Zahl für einen Bereich von bis zu 2,55 Sekunden.
Eine numFreq-Variable ist die Zahl von Frequenzen, die mit den momentanen Codehypothesen durchsucht werden soll. Dies ist eine vorzeichenlose 5-Bit-Zahl mit einem Bereich von 1–20. Sie arbeitet zusammen mit einer Schrittgrößen-Variablen, um eine Frequenzsuche zu definieren.
Eine fregStep-Variable repräsentiert den Frequenzabstand zwischen aufeinanderfolgenden Suchfrequenzen. Die Schrittgröße sollte im allgemeinen die Frequenz entsprechend dem Prädiktionsintervall sein. Es können jedoch kleinere Größen bei der Messung verwendet werden, um die Frequenzspitze feinabzustimmen.
Eine Suche beginnt auf der Seite der kleinsten Frequenz und setzt sich zu einer größten Frequenz fort. Sie deckt denselben Bereich wie eine Suche ab, die in der Mitte beginnt und sich in beiden Richtungen ausbreitet. Ein derartiges Verfahren kann im DSP 114 einfacher implementiert werden.
Es wird beispielsweise angenommen, dass wir ±400 Hz bis etwa 1.000 Hz absuchen wollen. Wir würden die Startfrequenz auf 650 Hz einstellen und anschließend acht Schritte von 100 Hz ausführen, um die verbleibenden Frequenzen zu erzeugen, wie es unten dargestellt ist. In diesem Fall entspricht carrierNcoValue 650 Hz, ist numFreq = 8 und sind fregStep 100 Hz.
Wir gehen davon aus, dass wir keinen doppelten Speicher für supervirtuelle Träger-NCO-Variable Verschiebung und Verzögerung wie auch für virtuelle Codegenerator-Variable C1, C2bit, Zählzahl und Zustand haben. Auf diese Weise wird der Bedarf an einem zusätzlichen Speicher vermieden. Dies bedeutet, dass sich der DSP im Leerlauf befindet, wenn diese berechnet werden, was eine längere Einrichtungszeit aber eine geringere Anzahl von Gates bedeutet. Wenn später eine Beschleunigung entschieden wird und zusätzliche Gates erschwinglich sind, sollte die Pufferung der vorberechneten Konstanten bei der Berechnung der Wiedergabe in Erwägung gezogen werden.
Dieser derzeitige Ansatz ist zulässig, da die ±1.000-Hz-Frequenzsuche eine sehr geringe Vorberechnung zum Ausführungszeitpunkt erfordert. Tatsächlich tritt sie lediglich beim ersten 10-ms-Eintrag auf. Es müssen ausreichend Ressourcen vorhanden sein, um die 20 Vorberechnungen in den 20 verbleibenden Wiedergabetakten vorzunehmen. Ist dies nicht der Fall, kann zusätzlicher Bedarf erforderlich sein, um die Vorberechnungsergebnisse zu speichern, bevor sie tatsächlich in die Bestimmungsregister geladen werden.
Der Aufbau der Statusmaschine des DSP 114 beinhaltet normalerweise die Entscheidung, wie der Wiedergabetakt gewählt und gesteuert wird. Es wird eine startPlayback-Variable verwendet, um einen Wiedergabetakt zu starten und eine Wiedergabemischung zu beginnen. Eine Variable playbackSamplesToGoCount definiert die Zahl von verbleibenden Abtastungen, die in einer Mischung verarbeitet werden sollen. Sie wird mit 2.112 plus der Zahl der Vorbereitungstakte initialisiert und bei jedem Abtasttakt verringert, der verarbeitet wird. Die Verarbeitung ist abgeschlossen, wenn der Ausgangswert null erreicht. Eine Variable playbackClock-Selector wählt eine Wiedergabetaktgeschwindigkeit. Wenn der Wert null ist, wird der Mastertakt direkt verwendet. Ist der Wert eins, wird der Mastertakt mit zwei multipliziert. Ein playbackClock-Takt wird benutzt, um sämtliche Laufzeitblöcke zu betätigen. Ein primingComplete-Signal zeigt an, wann die Vorbereitung abgeschlossen und die Mischung zum Starten bereit ist. Es ist während der Vorbereitung null. Ein playbackComplete-Signal zeigt an, wann eine vollständige 2.112-Abtastmischung fertig ist und die Korrelationsergebnisse in den Halteverriegelungsspeichern gültig sind. Es ist während der Vorbereitung ebenfalls null, oder wenn eine Wiedergabe vom RISC-Prozessor 258 gelöscht worden ist.
Drei mögliche Zustände können dieselbe Statusmaschine benutzen. Die typischste Suche besteht darin, sämtliche Codephasen über einen Mehrfachfrequenzbe reich zu suchen. Dies erfolgt, bevor die Zeit oder die Position des Benutzers bekannt ist. Die Statusmaschine führt automatisch eine 10-ms-Mischung bei allen Codes und Frequenzen für den definierten Bereich aus.
Jede Suche verwendet das gesamte Wiedergebpotential, so dass verhindert werden muss, dass andere Hypothesen parallel abgespielt werden. Dies würde andernfalls den Fortbestand der Mischung zerstören, solange nicht alle Zustände gesichert und wiederhergestellt wurden. Diese Autonomie ist erforderlich, so dass ein Block mit voller Geschwindigkeit gefahren werden kann, ohne dass Takte dadurch verschwendet werden, dass darauf gewartet werden muss, bis der Mirkoprozessor den nächsten Zustand versorgt. Die Codesuche kann festgelegt werden, indem der Startcode, der Abstand zwischen jedem Code und die Zahl der zu suchenden Codes definiert wird. Auf der Basis des 176-Korrelatorenmodells mit 31/64 eines Chipabstandes können wir die vollständigen 1.032 Chips in zwölf Schritten durchsuchen. Der Befehl an den DSP 114 besteht darin, sämtliche 176 Hypothesen zu verwenden und zwölf aufeinanderfolgende Mischungen auszuführen, wobei der Code um 176 Abtastakte zwischen jeder Mischung verschoben wird, um einen weiteren Abschnitt des Codespektrums zu durchsuchen. Ist die erste Wiedergabe vollständig, verschiebt der DSP 114 automatisch den Code, beginnt mit der nächsten Verschiebung und fährt mit dem Vorgang fort, bis die Zahl der Suchen, die bei einer Frequenz erforderlich sind, erschöpft ist. Eine Frequenzsuche wird durch Wiederholen des Vorgangs für eine Anzahl von Frequenzen und die Schrittvariablen "numFreq" und "fregStep" ausgeführt.
Eine erste Suchtechnik verwendet sämtliche Wiedergaben für eine Satellitenvorrichtung (SV) bei allen Codephasen, ±1.000 Hz und einer Sekunde. Eine weitere Technik besteht darin, lediglich einen kleinen Bereich des Codespektrums zu durchsuchen, so dass weniger als alle Codehypothesen verwendet werden. Es wird nur eine Wiedergabe für eine breite nicht-köhärente Durchsuchung verwendet. Dadurch wird Betriebsleistung gespart, wenn der ungefähre Codeort bekannt ist, wobei auf der Basis eines Unsicherheitszunahme-Modells nicht weiter als notwendig gesucht werden muss.
Die "timeTrack"-Betriebsart verwendet eine Wiedergabe für eine schmale kohä rente Suche. Eine derartige Suche richtet eine Integrationsgrenze mit einer Navigationsdatenbit-Phasenumkehr aus. Die "timeTrack"-Betriebsart ist von herkömmlicher Art, wobei eine Integrationsperiode mit einem lokal erzeugten Verlaufsübernahme-(CA-)Zeitraum und nicht mit der Millisekunde synchronisiert ist. Das Ziel besteht darin, die Integration über ein Phasenintervall hinaus zu vermeiden, und verlangt eine größere Zahl von Korrelatoren an einer gegebenen Phase, um individuelle Integrationen in unterschiedlichen Zeiträumen zu sichern. Für ein 10-ms-Prädiktionsintervall werden elf Korrelatoren benötigt, um die Daten für zehn Zeiträume ordnungsgemäß zu sichern. Die Zahl erforderlicher Codehypothesen ist auf 16 verringert, da 16*11 = 176.
Die "timeTrack"-Betriebsart kann wie eine Ziehharmonika zusammengezogen und ausgedehnt werden. Der Abstand zwischen jeder Codehypothese kann zwischen 1/64 und 32/64 eines Chips eingestellt werden. Dies wird durch 16 virtuelle Codegeneratoren ermöglicht. Die unterschiedlichen Codehypothesen werden aus 17 Codegenerator-Ausgabeverzögerungs-Taktschlägen und einem "div3"-Signal aus einem Code-NCO simuliert. Die "timeTrack"-Betriebsart kann alle Zeiträume eines 10-ms-Prädiktionsintervalls für eine separate Ausgabe oder eine Ausgabe wählen, die in zwei Teile um den Zeitraum geteilt ist.
Die Statusmaschine höherer Ordnung hat vorzugsweise drei Haupt-Programmsteuerschleifen. Eine Aufzeichnungs-Programmsteuerschleife läuft lediglich in der "search"-Betriebsart und befiehlt eine Suche über einen großen Frequenzbereich. Sie verbraucht sämtlichen verfügbaren Hypothesenraum, wobei keine weiteren Steuerschleifen dazwischen laufen können.
Eine Frequenz-Programmsteuerschleife wiederholt dieselben Codehypothesen bei Mehrfachfrequenzen und bietet einen schnellen Weg, um Mehrfachfrequenzen zu erzeugen. Der Prozessor greift lediglich ein, um eine nächste Suchfrequenz anzuweisen. In Kombination mit der Aufzeichnungs-Programmsteuerschleife, stellt sie eine sehr leistungsfähige Suchmaschine bereit. Die Code-Doppler-NOC können für jede Frequenz unabhängig aktualisiert werden.
Eine codeWindow-Programmsteuerschleife wird verwendet, um aufeinanderfol gende Codesuchen durchzuführen. Ein erstes Codefenster wird mit einer Tabellensuche festgelegt, die eine Start-Absolutphase einstellt, und alle nachfolgenden Suchen erzeugen eine Codephase durch relatives Verschieben des Codes.

Claims

Mobiles Teilnehmer-Satellitennavigationssystem (100) zur Bereitstellung von Navigationslösungen bei Betrieb in Gebieten mit sehr niedriger Signalstärke, wobei das System (100) umfasst: einen ersten Empfänger (102, 108), der so eingerichtet ist, dass er direkt Pseudostreckenmessungen von umlaufenden Navigationssatelliten erfasst, einen zweiten Empfänger (106, 110), der so eingerichtet ist, dass er Satelliten-Almanach- und Ephemeris-Daten erfasst, um Positionslösungen aus den von dem ersten Empfänger (102, 108) ermittelten Pseudostreckenmessungen zu berechnen, wobei das System (100) dadurch gekennzeichnet ist, dass es des Weiteren umfasst: eine Navigationsplattform (312), die so eingerichtet ist, dass sie Navigationslösungen bereitstellt, die aus einer Kombination der direkt von dem ersten Empfänger (102, 108) ermittelten Pseudostreckenmessungen und indirekt ermittelten Satellitennavigations-Daten berechnet werden, die von einem Netzwerk-Server (106) bereitgestellt werden, der den zweiten Empfänger (106, 110) umfasst, wobei: ein Polynom-Modell das Datenkommunikationsvolumen und den Rechenaufwand an der Navigationsplattform (312) durch Näherung und Reduzierung der direkt erfassten Navigationssatelliten-Konstellations-Almanach-, Ephemeris-, Differenzialkorrektur-Daten und Client-Dienste entsprechend einem Polynom-Modell reduziert, wobei das Polynom-Modell Polynome mit ganzzahliger Arithmetik verwendet; eine Netzwerk-Client-Einrichtung (104), die so eingerichtet ist, dass sie mit der Navigationsplattform (312) und dem ersten Empfänger (102, 108) sowie dem zweiten Empfänger (106, 110) kommuniziert, wobei die Netzwerk-Clienteinrichtung so eingerichtet ist, dass sie Zugriff des Polynommodells von dem Netzwerk-Server (106) ermöglicht, und der Netzwerk-Server (106) so eingerichtet ist, dass er die umlaufenden Navigationssatelliten überwacht, und in der Lage ist, ausreichend Daten zu erfassen, um das Polynommodell periodisch zu konstruieren und über ein Netzwerk (118, 120, 122, 124) zuzuführen.
System nach Anspruch 1, wobei die Navigationsplattform (312) des Weiteren so eingerichtet ist, dass sie autonome Positionslösungs-Berechnungen für eine begrenzte Zeit nach einer periodischen Anforderung von Hilfsdaten von dem Netzwerk-Server (106) bereitstellt.
System nach Anspruch 1 oder 2, wobei der Netzwerk-Server (106) eine Messplattform für statische Beobachtungen einer Navigationssatelliten-Konstellation umfasst, und so eingerichtet ist, dass er eine Datenbank von Messfehlern und Satellitendatenmeldungen aufbaut.
System nach Anspruch 3, wobei der Netzwerk-Server (106) eine Bereitschafts- und Qualitäts-Überwachungseinrichtung umfasst, die die statischen Beobachtungen prüft und eine Einbeziehung falscher Informationen in die Datenbank von Messfehlern und Satelliten-Datenmeldungen verhindert.
System nach einem der Ansprüche 1 bis 4, das des Weiteren umfasst: eine Kommunikationsverbindung zwischen dem Netzwerk-Server (106) und den Navigationsplattformen (312); und ein Kommunikationsformat, das über die Kommunikationsverbindung angeboten wird und Almanach- sowie Ephemeris-Satellitenmeldungen an dem Netzwerk-Server (106) auf einfache Polynome entsprechend dem Polynommodell reduziert, die eine momentane Satellitenposition und -geschwindigkeit darstellen, die an der Navigationsplattform (312) verwendet werden, um eine aktuelle Positionslösung mit Echtzeitdaten zu berechnen.
System nach einem der Ansprüche 1 bis 4, das des Weiteren umfasst: eine TCP/IP-Kommunikationsverbindung, die wenigstens einmal zwischen dem Netzwerk-Server (106) und der Navigationsplattform (312) besteht; und ein Informations-Datenpaket-Format, das periodisch wenigstens einmal über die Kommunikationsverbindung angeboten wird und Almanach- sowie Ephemeris-Satellitenmeldungen an dem Netzwerk-Server (106) auf einfache Polynome entsprechend dem Polynommodell reduziert, die eine momentane Satellitenposition und -geschwindigkeit darstellen, die an der Navigationsplattform (312) verwendet werden, um eine aktuelle Positionslösung mit Echtzeitdaten zu berechnen.
System nach einem der Ansprüche 2 bis 6, wobei die Hilfsdaten von dem Netzwerk-Server (106) dem ersten Empfänger bereitgestellt werden und die Hilfsdaten sämtliche Datenspeicherung bezüglich Almanach und Ephemeris aufheben, und wobei nur ganzzahlige Festkommaarithmetik verwendet wird, um die Benutzerposition an der Navigationsplattform (312) zu lösen.