diff --git a/0_Bezeichnungen.tex b/0_Bezeichnungen.tex index f59c76a..706f1e3 100644 --- a/0_Bezeichnungen.tex +++ b/0_Bezeichnungen.tex @@ -1,4 +1,4 @@ -Es wurde versucht in dieser Arbeit durchgehend die selben Symbole für Signale mit der selben Bedeutung zu nehmen. Die selben Symbole wurden auch in den Blockschaltbildern verwendet. +Es wurde versucht in dieser Arbeit für Signale mit der selben Bedeutung im Text und in den Blockschaltbildern durchgehend die selben Symbole zu nehmen. Einige generelle Konventionen denen in dieser Arbeit gefolgt wird: \begin{itemize} diff --git a/0_Glossar.tex b/0_Glossar.tex index 10a10dc..6acc33d 100644 --- a/0_Glossar.tex +++ b/0_Glossar.tex @@ -88,7 +88,7 @@ \newglossaryentry{CA}{% name={C/A}, -description={Ein Code dessen Codewörter die Eigenschaft haben Orthogonal zueinander zu sein (d.h. geringe Kreuzkorrelation der Codewörter). Der C/A Code verwendet sogenannte \emph{Gold Folgen} die durch \gls{LFSR} erzeugt werden. C/A steht hierbei für \emph{Coarse/Acquisition}. Der C/A Code wird zur Spreizung des zivil nutzbaren GPS Signals benutzt \cite{specification2010gps}.} +description={Ein Code dessen Codewörter die Eigenschaft haben Orthogonal zueinander zu sein (d.h. geringe Kreuzkorrelation der Codewörter). Der C/A Code verwendet sogenannte \emph{Gold Folgen} die durch \gls{LFSR} erzeugt werden. C/A steht hierbei für \emph{Coarse/Acquisition}. Der C/A Code wird zur Spreizung des zivil nutzbaren GPS Signals benutzt \cite{specification2010gps}} } \newglossaryentry{PY}{% @@ -140,7 +140,7 @@ \newacronym{TCXO}{TCXO}{\gls{l_TCXO}} \newglossaryentry{l_TCXO}{% name={Temperature Controlled Oscillator}, - description={Ein Quarzoszillator, der zur verbesserten Frequenzstabilität temperaturkompensiert ist.} + description={Ein Quarzoszillator, der zur verbesserten Frequenzstabilität temperaturkompensiert ist} } \newacronym{PGA}{PGA}{Programmable Gain Amplifier} @@ -148,25 +148,25 @@ %\newacronym{zword}{Z-Word}{\gls{l_zword}} \newglossaryentry{zword}{% name={Z-Word}, - description={Anzahl der Sekunden seit dem \emph{zero-time point}. Der \emph{zero-time point} ist der Zeitpunkt um Mitternacht vom 5. Januar 1980 auf den 6. Januar 1980.} + description={Anzahl der Sekunden seit dem \emph{zero-time point}. Der \emph{zero-time point} ist der Zeitpunkt um Mitternacht vom 5. Januar 1980 auf den 6. Januar 1980} } \newacronym{TOW}{TOW}{\gls{l_TOW}} \newglossaryentry{l_TOW}{% name={Time-of-Week}, - description={Die Time of Week gibt die Anzahl der Sekunden seit dem letzten Sonntag an. Verkürzte Version des \gls{zword}.} + description={Die Time of Week gibt die Anzahl der Sekunden seit dem letzten Sonntag an. Verkürzte Version des \gls{zword}} } \newacronym{HOW}{HOW}{\gls{l_HOW}} \newglossaryentry{l_HOW}{% name={Hand-over-Word}, - description={Teil der vom GPS \gls{SV} gesendendeten NAV Daten. Der im HOW übertragene Wert gibt die \gls{TOW} zum Zeitpunkt des Beginn des nächsten Subframe an. HOW ist eine verkürzte Version von \gls{TOW}, da ein Subframe \SI{6}{\second} dauert.} + description={Teil der vom GPS \gls{SV} gesendendeten NAV Daten. Der im HOW übertragene Wert gibt die \gls{TOW} zum Zeitpunkt des Beginn des nächsten Subframe an. HOW ist eine verkürzte Version von \gls{TOW}, da ein Subframe \SI{6}{\second} dauert} } \newacronym{DMA}{DMA}{\gls{l_DMA}} \newglossaryentry{l_DMA}{% name={Direct Memory Access}, - description={Technik bei der Daten zwischen Geräten, die an den gemeinsam genutzten Daten- und Adressbus angeschlossen sind, ohne Mitwirken des Prozessors ausgetauscht werden können.} + description={Technik bei der Daten zwischen Geräten, die an den gemeinsam genutzten Daten- und Adressbus angeschlossen sind, ohne Mitwirken des Prozessors ausgetauscht werden können} } \newacronym{AMC}{AMC}{Asynchronous Memory Controller} @@ -176,13 +176,13 @@ \newacronym{FSM}{FSM}{\gls{l_FSM}} \newglossaryentry{l_FSM}{% name={Finite State Machine}, - description={Endlicher Zustandsautomat.} + description={Endlicher Zustandsautomat} } \newacronym{FCW}{FCW}{\gls{l_FCW}} \newglossaryentry{l_FCW}{% name={Frequency Control Word}, - description={Steuerwort, dass die Ausgangsfrequenz eines \gls{NCO} bestimmt. Dabei ist das Steuerwort nicht notwendigerweise \emph{gleich} der Ausgangsfrequenz, sondern lediglich proportional dazu.} + description={Steuerwort, dass die Ausgangsfrequenz eines \gls{NCO} bestimmt. Dabei ist das Steuerwort nicht notwendigerweise \emph{gleich} der Ausgangsfrequenz, sondern lediglich proportional dazu} } \newacronym{LUT}{LUT}{Look-Up-Table} @@ -191,7 +191,7 @@ \newglossaryentry{Primitive}{% name={Primitive}, - description={Herstellerspezifisches Hardware Element in einem FPGA oder ASIC das eine spezielle Funktion bereitstellt. Beispiele sind PLL, Hardwaremultiplizierer, aber auch Flip Flops und Logik Gatter.} + description={Herstellerspezifisches Hardware Element in einem FPGA oder ASIC das eine spezielle Funktion bereitstellt. Beispiele sind PLL, Hardwaremultiplizierer, aber auch Flip Flops und Logik Gatter} } \newacronym{ELF}{ELF}{Executable and Linking Format} diff --git a/0_hyphenation.tex b/0_hyphenation.tex index e0689c8..6f6f866 100644 --- a/0_hyphenation.tex +++ b/0_hyphenation.tex @@ -14,4 +14,7 @@ Ac-qui-si-tion Track-ing-loop seg-ment-wei-se +Lo-kal-os-zil-la-tor +Re-chen-kno-ten +Sys-tem-ab-sturz } \ No newline at end of file diff --git a/0_shortcuts.tex b/0_shortcuts.tex index 58cd223..cf95ed5 100644 --- a/0_shortcuts.tex +++ b/0_shortcuts.tex @@ -21,13 +21,13 @@ \newcommand{\gpsfbit}{f_{bit}} % Informationsrate \newcommand{\gpsLcode}{L} % Codelänge \newcommand{\gpsfsamp}{f_S} % Frontend samplingrate -\newcommand{\gpsfcw}{\emph{FCW }} +\newcommand{\gpsfcw}{\emph{FCW}\xspace} \newcommand{\ifft}[1]{\mathcal{F}^{-1}\left\{#1\right\}} % FFT{} \newcommand{\fft}[1]{\mathcal{F}\left\{#1\right\}} % inverse FFT{} \DeclareMathOperator*{\argmax}{arg\,max} % argmax -\newcommand{\comboard}{\emph{COM Board }} -\newcommand{\comfpga}{\emph{XCS6LX9} } -\newcommand{\dscubesat}{\emph{Dragsail-Cubesat} } \ No newline at end of file +\newcommand{\comboard}{\emph{COM Board}\xspace} +\newcommand{\comfpga}{\emph{XCS6LX9}\xspace} +\newcommand{\dscubesat}{\emph{Dragsail-Cubesat}\xspace} \ No newline at end of file diff --git a/1_Einleitung/0_Einleitung_main.tex b/1_Einleitung/0_Einleitung_main.tex index ffb7d4b..2ed1791 100644 --- a/1_Einleitung/0_Einleitung_main.tex +++ b/1_Einleitung/0_Einleitung_main.tex @@ -4,9 +4,9 @@ \chapter{Einleitung} Der Hardware-Teil des GPS Empfängers wurde bereits in vergangen Arbeiten entwickelt. Die Entwicklung des Software-Teils und die Integration auf das COM Board des \dscubesat standen jedoch noch aus. Die Software des GPS Empfängers teilt sich auf den FPGA und den DSP des COM Board auf. Im DSP werden vor allem weniger zeitkritische, aber speicher- und rechenintensive Teile implementiert. Im FPGA werden zeitkritische, gut parallelisierbare Teile implementiert. In der programmierbaren Hardware des FPGA wurde außerdem ein Softcore Prozessor integriert, der Aufgaben erledigt, deren Implementierung in reiner programmierbarer Hardware sehr umständlich wäre. -Die Arbeit gliedert sich in drei Teile. Nach einer kurzen Beschreibung zur Motivation des Projekts und einem Blick auf ähnliche Projekte werden im ersten Teil einige Grundlagen zum GPS Signal und GPS Empfängern besprochen. Ein wichtiger Parameter bei der Demodulation ist die Dopplerverschiebung des Signals, der durch die hohe Geschwindigkeit des \dscubesat im Orbit noch verstärkt wird. Deshalb wird eine Formel hergeleitet, mit der sich näherungsweise die maximale Dopplerverschiebung berechnen lässt. Ein weiterer Abschnitt gibt eine Übersicht über die für diese Arbeit relevanten Teile des COM Subsystem auf dem der GPS Empfänger implementiert wird. +Die Arbeit gliedert sich in drei Teile. Nach einer kurzen Beschreibung zur Motivation des Projekts und einem Blick auf ähnliche Projekte werden im ersten Teil einige Grundlagen zu GPS Signal und GPS Empfängern besprochen. Ein wichtiger Parameter bei der Demodulation ist die Dopplerverschiebung des Signals, der durch die hohe Geschwindigkeit des \dscubesat im Orbit noch verstärkt wird. Deshalb wird eine Formel hergeleitet, mit der sich näherungsweise die maximale Dopplerverschiebung berechnen lässt. Ein weiterer Abschnitt gibt eine Übersicht über die für diese Arbeit relevanten Teile des COM Subsystems, auf dem der GPS Empfänger implementiert wird. -Im zweiten Teil wird zuerst der Entwurf des Empfängers besprochen. Danach werden die Teile des Entwurfs besprochen, die bisher realisiert wurden. Abschließend werden einige Versuchsergebnisse präsentiert. +Im zweiten Teil wird zuerst der Entwurf des Empfängers besprochen. Danach werden die Teile des Entwurfs besprochen, die bisher realisiert wurden. Abschließend werden relevante Versuchsergebnisse präsentiert. Ein wichtiger Teil der Entwurfsphase für die Software war die Umsetzung der Berechnungen in Festkomma Arithmetik. Im Appendix wird deshalb eine Einführung zu der hier verwendeten Notation und dem Festkommaentwurf gegeben. diff --git a/1_Einleitung/30_Motivation.tex b/1_Einleitung/30_Motivation.tex index 8f4dce9..bd0c237 100644 --- a/1_Einleitung/30_Motivation.tex +++ b/1_Einleitung/30_Motivation.tex @@ -1,12 +1,12 @@ \section{Motivation} -Der \dscubesat ist ein kleiner \gls{LEO} Satellit, der im Rahmen mehrerer Abschlussarbeiten an der FH Aachen und der RWTH Aachen entstanden ist\footnote{Einige der vorangegangenen Arbeiten zum Kommunikations-Subsystem sind z.B. \cite{DragsailKaiMA}, \cite{DragsailRalfMA}, \cite{DragsailAndrejMA}, +Der \dscubesat ist ein etwa \SI{10x10x30}{cm} großer \gls{LEO} Satellit, der im Rahmen mehrerer Abschlussarbeiten an der FH Aachen und der RWTH Aachen entstanden ist\footnote{Einige der vorangegangenen Arbeiten zum Kommunikations-Subsystem sind z.B. \cite{DragsailKaiMA}, \cite{DragsailRalfMA}, \cite{DragsailAndrejMA}, \cite{DragsailUweMAGroundDataHandling}, \cite{DragsailVolkerMACommstandard}, \cite{DragsailGeorgMAGroundSDR}, \cite{DragsailNeelamMAGroundDSP} und weitere.}. Um \enquote{Weltraumschrott} zu vermeiden ist das Ziel, dass Cubesats nicht länger als 25 Jahre im Orbit verbleiben sollten. Die Verweildauer wird unter anderem durch die Höhe des Orbits festgelegt in dem die Satelliten ausgesetzt werden. Die Orbithöhe in der ein Satellit von der Größe eines Cubesat maximal 25 Jahre bleibt wird von der NASA als etwa \SI{600}{\kilo\meter} angegeben \cite{NASAOrbitalDebris}. -Cubesats werden üblicherweise als Beiladung beim Start kommerzieller Satelliten in den Weltraum geschickt. Daher ist der Orbit nicht beliebig frei wählbar, sondern hängt davon wo der kommerzielle Satellit ausgesetzt werden soll. +Cubesats werden üblicherweise als Beiladung beim Start kommerzieller Satelliten in den Weltraum geschickt. Daher ist der Orbit nicht beliebig frei wählbar, sondern hängt davon ab wo der kommerzielle Satellit ausgesetzt werden soll. -Deshalb ist eines der Experimente an Board des Satelliten das Entfalten eines Segels am Ende der Lebenszeit des Satelliten um den Wiedereintritt zu beschleunigen und so die Verweildauer auch bei höheren Orbits zu begrenzen. Für das Experiment sind die Orbitdaten, bzw. die Änderung der Orbitdaten durch das Entfalten des Segels von Interesse. Die Orbitdaten werde durch Organisationen wie NORAD veröffentlicht. Die Genauigkeit dieser Orbitdaten für kleine Satelliten wurde in anderen Arbeiten untersucht, beispielsweise in \cite{TLEAccuracyKahr} oder \cite{TLEAccuracyDoyle}. Bedingt durch die geringe Größe ist sind diese Daten nicht immer sehr genau und weichen je nach Parameter um bis zu \SI{1.29}{\percent} oder \SI{370}{\percent} ab \cite{TLEAccuracyDoyle}. +Deshalb ist eines der Experimente an Board des Satelliten das Entfalten eines Segels am Ende der Lebenszeit des Satelliten um den Wiedereintritt zu beschleunigen und so die Verweildauer auch bei höheren Orbits zu begrenzen. Für das Experiment sind die Orbitdaten, bzw. die Änderung der Orbitdaten durch das Entfalten des Segels von Interesse. Die Orbitdaten werde durch Organisationen wie NORAD veröffentlicht. Die Genauigkeit dieser Orbitdaten für kleine Satelliten wurde in anderen Arbeiten untersucht, beispielsweise in \cite{TLEAccuracyKahr} oder \cite{TLEAccuracyDoyle}. Bedingt durch die geringe Größe sind diese Daten nicht immer sehr genau und weichen je nach Parameter um bis zu \SI{1.29}{\percent} oder \SI{370}{\percent} ab \cite{TLEAccuracyDoyle}. Da GPS Signale auch von \gls{LEO} Satelliten empfangen werden können, bietet es sich an, dass der Satellit selbst seine Position und damit seinen Orbit berechnet. Aufgrund von Waffenexportbeschränkungen funktionieren jedoch die wenigsten GPS Empfänger Chips im Weltraum. Für den \dscubesat musste deshalb ein alternativer Weg gegangen werden. Die Rechenleistung auf heutigen Embedded Systems wie dem COM Board des \dscubesat reicht aus, um GPS Empfänger vollständig in Software zu implementieren. Der benötigte Hardware Teil beschränkt sich damit auf ein HF Frontend, was ein digitalisiertes Basisband Signal liefert. diff --git a/1_Einleitung/60_Abgrenzung.tex b/1_Einleitung/60_Abgrenzung.tex index aca3d0e..c40ce2a 100644 --- a/1_Einleitung/60_Abgrenzung.tex +++ b/1_Einleitung/60_Abgrenzung.tex @@ -5,7 +5,7 @@ \section{Ähnliche Arbeiten} Eine weitere interessante Arbeit ist \cite{Birklykke2010}, die das Ergebnis eines mehrsemestrigen Projekts ist, welches sich speziell mit der Implementierung eines GPS Empfängers für kleine \gls{LEO} Satelliten beschäftigt hat. Der Quellcode des in der Arbeit entwickelten GPS Empfängers ist leider nicht verfügbar. -Es gibt auch mehrere kommerzielle Software Defined GPS Receiver, von denen das SwiftNav Piksi \cite{SwiftNavPiksi} dadurch hervorsteht, dass ein großer Teil der Software unter GPL Lizenz frei verfügbar ist. Ein elementarer Bestandteil, die FPGA Firmware ist allerdings nicht veröffentlicht. Für zukünftige Weiterentwicklung der hier vorgestellten Arbeit sollte jedoch untersucht werden ob die Open Source Teile des SwiftNav Piksi Projekts hilfreich sein können. +Es gibt auch mehrere kommerzielle Software Defined GPS Receiver, von denen das SwiftNav Piksi \cite{SwiftNavPiksi} dadurch hervorsteht, dass ein großer Teil der Software unter GPL Lizenz frei verfügbar ist. Ein elementarer Bestandteil, die FPGA Firmware ist allerdings nicht veröffentlicht. Für zukünftige Weiterentwicklung der hier vorgestellten Arbeit sollte jedoch untersucht werden, ob die Open Source Teile des SwiftNav Piksi Projekts hilfreich sein können. Abseits von Realisierungen für Embedded Systeme ist auch das GNSS-SDR Projekt \cite{gnss-sdr} interessant. GNSS-SDR ist ein Open Source Framework mit dem sich SDR GNSS Receiver realisieren lassen. Der Schwerpunkt liegt dabei aber im Bildungs- und Forschungsbereich um Algorithmen zu testen und zu vergleichen. Für eine Echtzeit-Positionsbestimmung in einem Embedded System hat GNSS-SDR zu hohe Leistungsforderungen. Mit einem leistungsfähigen PC ist jedoch auch mit dem GNSS-SDR Receiver Echtzeit-Positionsbestimmung möglich. diff --git a/2_Grundlagen/0_Grundlagen_main.tex b/2_Grundlagen/0_Grundlagen_main.tex index 0e492c6..96f7b48 100644 --- a/2_Grundlagen/0_Grundlagen_main.tex +++ b/2_Grundlagen/0_Grundlagen_main.tex @@ -1,5 +1,5 @@ \chapter{Theoretische Grundlagen} -Dieses Kapitel gibt zuerst einige einführende Informationen über das GPS Signal und über die Demodulation. Danach wird der Einfluss des Dopplereffekts, mit besonderem Bezug auf die hohe Orbit Geschwindigkeit eine \gls{LEO} Satelliten untersucht. Zum Schluss wird ein Überblick über die Hardware des COM Board gegeben. +Dieses Kapitel gibt zuerst einige einführende Informationen über das GPS Signal und über die Demodulation. Danach wird der Einfluss des Dopplereffekts, mit besonderem Bezug auf die hohe Orbit Geschwindigkeit von \gls{LEO} Satelliten untersucht. Zum Schluss wird ein Überblick über die Hardware des COM Board gegeben. \input{2_Grundlagen/10_GPS_Signal} diff --git a/2_Grundlagen/10_GPS_Signal.tex b/2_Grundlagen/10_GPS_Signal.tex index 636418b..29fc5e0 100644 --- a/2_Grundlagen/10_GPS_Signal.tex +++ b/2_Grundlagen/10_GPS_Signal.tex @@ -1,5 +1,5 @@ \section{GPS Signal} -Der GNSS Empfänger der im Rahmen dieser Arbeit entwickelt werden soll verwendet das \gls{GPS} als Quelle für Navigationsdaten. In diesem Abschnitt soll ein Überblick über die Eigenschaften des Signals, sowie ein Überblick über die Demodulation Signals gegeben werden. Dabei wird sich auf die für diese Arbeit wichtigen Teile beschränkt: Das GPS verwendet mehrere Frequenzen und in neueren Versionen auch mehrere Modulationsverfahren \cite{specification2010gps}. Der im Rahmen dieser Arbeit entworfene Empfänger verwendet lediglich das zivil nutzbare Signal auf der L1 Frequenz mit C/A Kodierung\footnote{Beginnend mit dem Jahr 2016 sollen auch weitere Übertragungskanäle für zivile Anwendungen zur Verfügung stehen. Siehe \cite{interface1gps}, \cite{specification2010gps} und \cite{navstar2006space}}. Für die anderen Teile des Standards sei auf die offizielle GPS Spezifikation verwiesen (\cite{specification2010gps}) verwiesen. Weiterhin gibt \cite{borre2007software} eine sehr gute Einführung zu \gls{SDR} Empfängern für \gls{GPS} und Galileo. +Der GNSS Empfänger der im Rahmen dieser Arbeit entwickelt werden soll verwendet das \gls{GPS} als Quelle für Navigationsdaten. In diesem Abschnitt soll ein Überblick über die Eigenschaften des Signals, sowie ein Überblick über die Demodulation des Signals gegeben werden. Dabei wird sich auf die für diese Arbeit wichtigen Teile beschränkt: Das GPS verwendet mehrere Frequenzen und in neueren Versionen auch mehrere Modulationsverfahren \cite{specification2010gps}. Der im Rahmen dieser Arbeit entworfene Empfänger verwendet lediglich das zivil nutzbare Signal auf der L1 Frequenz (\SI{1575.42}{\mega\hertz}) mit \gls{CA} Kodierung\footnote{Beginnend mit dem Jahr 2016 sollen auch weitere Übertragungskanäle für zivile Anwendungen zur Verfügung stehen. Siehe \cite{interface1gps}, \cite{specification2010gps} und \cite{navstar2006space}}. Für die anderen Teile des Standards sei auf die offizielle GPS Spezifikation verwiesen (\cite{specification2010gps}). Weiterhin gibt \cite{borre2007software} eine sehr gute Einführung zu \gls{SDR} Empfängern für \gls{GPS} und Galileo. Auch wenn GPS aus Sicht des Empfängers kein Netzwerkprotokoll ist, orientiert sich die folgende Beschreibung grob am OSI Modell: Zu Beginn wird die Bitübertragungsschicht (\emph{Physical Layer}) diskutiert. Im zweiten Unterabschnitt wird das verwendete Multiplex Verfahren beschrieben (\emph{\gls{MAC} Layer}). Abschließend werden die übertragenen Nutzdaten beschrieben. Einige Zahlenwerte zu Parametern sind in \TR{TabGPSSignalParams} angegeben. Die Bedeutung wird in den folgenden Abschnitten noch erklärt. @@ -34,7 +34,7 @@ \subsection{Bitübertragungsschicht} Auf dem Satelliten befindet sich eine hoch genaue Taktquelle mit \SI{10.2299999954326}{\MHz}. Durch relativistische Effekte erscheint diese Frequenz für einen Beobachter auf der Erde wie \SI{10.23}{\MHz}. Von dieser Taktquelle sind alle weiteren Frequenzen abgeleitet. Ein Frequenzsynthesizer generiert aus dem Referenztakt durch Vervielfachung mit dem Faktor 154 den Träger für das \gls{PY} Signal für die sogenannte L1 Frequenz ($\gpsfcarr=\SI{1575.42}{\MHz}$). Der Träger für das zivil genutzte \gls{CA} Signal wird aus dem \gls{PY} Träger durch \SI{90}{\degree} Phasenverschiebung gewonnen. \paragraph{Modulation} -Die von der darüber liegenden Schicht erhaltenen Daten werden auf den Träger mittels \gls{BPSK} moduliert. \gls{BPSK} bietet, verglichen mit 2ASK und 2FSK, bei gleichem \gls{SNR} die geringste Bit-Error-Rate \cite{dixon1998radio}. Die Zuordnung der $1$en und $0$en zu den Phasenlagen bezieht sich auf das gleichzeitig übertragene \gls{PY} Signal\footnote{Das \gls{PY} Signal ist das militärisch genutzte GPS Signal auf der L1 Frequenz. Wie jedoch später beschrieben wird, ist es zur Dekodierung des \gls{CA} Signals nicht notwendig das \gls{PY} Signal dekodieren zu können}: Die Phasenlage die der \gls{PY} Träger annimmt wenn eine $0$ übertragen wird ist als \SI{0}{\degree} definiert. Wenn das \gls{CA} Signal den Wert $1$ übertragen soll, eilt der \gls{CA} Träger dem \gls{PY} \SI{90}{\degree} vor. Bei einer $0$ eilt das CA Signal \SI{90}{\degree} nach. +Die von der darüber liegenden Schicht erhaltenen Daten werden auf den Träger mittels \gls{BPSK} moduliert. \gls{BPSK} bietet, verglichen mit 2ASK und 2FSK, bei gleichem \gls{SNR} die geringste Bit-Error-Rate \cite{dixon1998radio}. Die Zuordnung der $1$en und $0$en zu den Phasenlagen bezieht sich auf das gleichzeitig übertragene \gls{PY} Signal\footnote{Das \gls{PY} Signal ist das militärisch genutzte GPS Signal auf der L1 Frequenz. Wie jedoch später beschrieben wird, ist es zur Dekodierung des \gls{CA} Signals nicht notwendig das \gls{PY} Signal dekodieren zu können}: Die Phasenlage, die der \gls{PY} Träger annimmt, wenn eine $0$ übertragen wird, ist als \SI{0}{\degree} definiert. Wenn das \gls{CA} Signal den Wert $1$ übertragen soll, eilt der \gls{CA} Träger dem \gls{PY} \SI{90}{\degree} vor. Bei einer $0$ eilt das CA Signal \SI{90}{\degree} nach. Das ausgesendete Signal ergibt sich durch Addition des \gls{CA} Signals mit dem um \SI{3}{\dB} gedämpften \gls{PY} Signal. \FR{GPSConstellation} stellt die Symbolkonstellation grafisch dar. Wie man sieht, gibt es je zwei Symbole die eine $1$ bzw. eine $0$ des \gls{CA} Signals signalisieren. Ein Empfänger wendet auf das empfangene Signal einen Tiefpassfilter an. Da das \gls{PY} Signal durch ein Informationssignal mit deutlich höherer Bandbreite moduliert ist und durch den Chipping Code ein pseudo-Zu\-falls\-ver\-hal\-ten aufweist, ergeben sich nach der Tiefpassfilterung wieder die Konstellationspunkte $C_{1,2}$. @@ -78,15 +78,15 @@ \subsection{GPS Nutzdaten} Der Zeitpunkt der Aussendung der Nachricht ist über das sogenannte \gls{HOW} angegeben. Das \gls{HOW} ist eine verkürzte Version von \gls{TOW}, mit der die Anzahl der Sekunden seit dem letzten Sonntag angegeben wird. Der \gls{HOW} Zähler erhöht sich um 1 in \SI{6}{\second} Schritten (also mit jedem Subframe). Der HOW Wert gibt den TOW Wert zu Beginn des \underline{nächsten} Subframes an. \paragraph{Datenstruktur} -Die \emph{NAV Daten} sind in \emph{Frames}, \emph{Subframes} und \emph{Words} unterteilt. Ein \emph{Frame} ist \SI{1500}{\bit} lang, bestehend aus 5 \emph{Subframes}, von je \SI{300}{\bit} Länge. Die \emph{Subframes} sind weiter unterteilt in \emph{Words} von je \SI{30}{\bit} Länge. Zur Erkennung von Übertragungsfehlern ist jedes Word mit 6 Paritätsbits abgesichert. +Die \emph{NAV Daten} sind in \emph{Frames}, \emph{Subframes} und \emph{Words} unterteilt. Ein \emph{Frame} ist \SI{1500}{\bit} lang, bestehend aus 5 \emph{Subframes}, von je \SI{300}{\bit} Länge. Die \emph{Subframes} sind weiter unterteilt in \emph{Words} von je \SI{30}{\bit} Länge. Zur Erkennung von Übertragungsfehlern ist jedes \emph{Word} mit 6 Paritätsbits abgesichert. -\FGimg[GPS NAV Datenstruktur]{GPSData.png}{Übersicht über die Datenstruktur mit der die NAV Nachrichten übertragen werden. Subframes 4 und 5 unterscheiden sich in jeder \emph{Page}. Jeder Subframe beginnt mit einer Präambel im ersten Wort.}{0.9\imgmaxwidth} +\FGimg[GPS NAV Datenstruktur]{GPSData.png}{Übersicht über die Datenstruktur mit der die NAV Nachrichten übertragen werden. \emph{Subframes} 4 und 5 unterscheiden sich in jeder \emph{Page}. Jeder \emph{Subframe} beginnt mit einer Präambel im ersten \emph{Word}.}{0.9\imgmaxwidth} -Zur Synchronisation des Empfängers beginnt das erste Wort jedes Subframes mit einer Preamble. Diese hat zwei Funktionen: Der Demodulator hat zwei stabile Zustände, die zu einer Negierung der Informationsbits führen können. Die Preamble wird genutzt, um dies zu erkennen bzw. zu korrigieren. Außerdem wird die Preamble genutzt um den Beginn eines Subframes zu finden. +Zur Synchronisation des Empfängers beginnt das erste \emph{Word} jedes Subframes mit einer Preamble. Diese hat zwei Funktionen: Der Demodulator hat zwei stabile Zustände, die zu einer Negierung der Informationsbits führen können. Die Preamble wird genutzt, um dies zu erkennen bzw. zu korrigieren. Außerdem wird die Preamble genutzt um den Beginn eines Subframes zu finden. Alle Subframes übertragen in den ersten zwei Words die aktuelle Zeit zum Zeitpunkt der Aussendung. Die Ephemeriden mit den Orbitdaten und weiteren Informationen über das aussendende \gls{SV} werden in den Subframes 1, 2 und 3 übertragen. Diese drei Subframes werden in jedem Frame wiederholt. Die Almanach Daten sind deutlich länger, und werden deshalb segmentiert und über 25 Frames in den Subframes 4 und 5 übertragen. Die Übertragung eines vollständigen Datensatzes dauert damit \SI{12.5}{\minute}. -\FGimg[(De)Modulation, (De)Spreading]{MoDem.png}{Prinzip der GPS Signalerzeugung und Informationsrückgewinnung: Das Datensignal wird mit dem \gls{CA} Code Modulo-2 addiert (\emph{gespreizt}), und anschließend auf den Träger moduliert}{0.7\imgmaxwidth} +\FGimg[(De)Modulation, (De)Spreading]{MoDem.png}{Prinzip der GPS Signalerzeugung und Informationsrückgewinnung: Das Datensignal wird mit dem \gls{CA} Code Modulo-2 addiert (\emph{gespreizt}), und anschließend auf den Träger moduliert.}{0.7\imgmaxwidth} \paragraph{Positionsbestimmung} \label{positionsbestimmung} diff --git a/2_Grundlagen/20_GPS_Demodulation.tex b/2_Grundlagen/20_GPS_Demodulation.tex index a65a89f..b04003e 100644 --- a/2_Grundlagen/20_GPS_Demodulation.tex +++ b/2_Grundlagen/20_GPS_Demodulation.tex @@ -1,5 +1,5 @@ \section{GPS Empfänger} -In diesem Abschnitt wird die prinzipielle Funktion eines Empfängers für das GPS Signal erklärt. Es wird hier davon ausgegangen, dass das von der Antenne kommende Signal bereits auf eine Zwischenfrequenz $f_{ZF}$ herunter gemischt wurde und digitalisiert wurde. Damit gestaltet sich die Demodulation eigentlich einfach: Es werden einfach die Schritte der Modulation erneut durchgeführt: Multiplikation mit dem (ZF-)Träger und Multiplikation mit dem CA Code (siehe \FR{MoDem.png}). Am Ausgang des Demodulators liegt dann das ursprüngliche Informationssignal an. Im Detail ist der Prozess jedoch komplexer und kann in drei Schritte aufgeteilt werden, die im Folgenden beschrieben werden. +In diesem Abschnitt wird die prinzipielle Funktion eines Empfängers für das GPS Signal erklärt. Es wird hier davon ausgegangen, dass das von der Antenne kommende Signal bereits auf eine Zwischenfrequenz $f_{ZF}$ herunter gemischt wurde und digitalisiert wurde. Damit gestaltet sich die Demodulation eigentlich einfach: Es werden die Schritte der Modulation erneut durchgeführt: Multiplikation mit dem (ZF-)Träger und Multiplikation mit dem CA Code (siehe \FR{MoDem.png}). Am Ausgang des Demodulators liegt dann das ursprüngliche Informationssignal an. Im Detail ist der Prozess jedoch komplexer und kann in drei Schritte aufgeteilt werden, die im Folgenden beschrieben werden. \subsection{Acquisition} \label{Grundlagen_Acquisition} @@ -15,7 +15,7 @@ \subsection{Acquisition} \subsubsection{Suchalgorithmus} Es gibt verschiedene Möglichkeiten zur Suche. Die einfachste, aber auch langsamste Methode ist die serielle Suche. Dabei wird das Eingangssignal $\gpsin$ punktweise mit einer Kopie des Codes $\gpsca$ und des Trägers $\gpslo$ multipliziert und dann die Energie des Signals bestimmt, wobei nacheinander verschiedene Kombinationen von \gls{PRN}, Dopplerverschiebung und Codephase ausprobiert werden. Aufgrund der großen Anzahl möglicher Kombinationen und Rechenoperationen ist dies jedoch äußerst zeitaufwändig. -Effizienter sind Methoden die sich die Fourier Transformation zunutze machen, um die aufwändige Berechnung der Kreuzkorrelation zu vereinfachen. Diese Suche muss zwar immer noch für jede PRN ausgeführt werden. Aber der Rechenaufwand bei den weiteren Schritten ist deutlich geringer. +Effizienter sind Methoden die sich die Fourier Transformation zunutze machen, um die aufwändige Berechnung der Kreuzkorrelation zu vereinfachen. Diese Suche muss zwar immer noch für jede PRN ausgeführt werden, aber der Rechenaufwand bei den weiteren Schritten ist deutlich geringer. In dieser Arbeit wird eine zweischrittige Methode aus paralleler Codephasen Suche und paralleler Frequenzsuche verwendet. Im ersten Schritt wird der Dopplershift lediglich grob bestimmt (\SI{\pm500}{\Hz}), dafür die Codephase aber mit hoher Genauigkeit bestimmt. Im zweiten Schritt ist dann die Codephase bekannt, und es kann eine parallele Suche im Frequenzbereich durchgeführt werden um den Dopplershift genauer zu bestimmen. \FGimg[Acquisition Aktivitätsdiagram]{acquisition_activity.png}{Die Acquisition wird nacheinander für alle PRN durchgeführt. Um dem Problem eines möglichen Bitwechsels vorzugreifen wird die Acquisition für zwei aufeinanderfolgende Segemente durchgeführt, von denen für die weitere Verarbeitung nur das mit der höheren Korrelation ausgewählt wird.}{0.8\imgmaxwidth} @@ -78,4 +78,4 @@ \subsubsection{Suchalgorithmus} \end{align} mit dem Zeitpunkt $t_1$ des Bitwechsels, $T$ der Segmentlänge und $\gpsin_{\pm}$ dem Eingangssignal vor bzw. nach dem Bitwechsel. Ein Bitwechsel kann aber nie ausgeschlossen werden. Wie in \cite{borre2007software} beschrieben behilft man sich deshalb damit, die maximale Segmentlänge auf $1/2 \gpsTbit$ zu begrenzen, aber die Acquisiton für zwei aufeinander folgende Segmente durchzuführen. Dann kann ein Bitwechsel höchstens in einem der beiden Segmente vorkommen, und für die weitere Verarbeitung wird dann das Segment mit dem besseren Ergebnis ausgewählt. -Bei dem oben beschriebenen zweischrittigen Algorithmus (1. parallele Codephasensuche, 2. parallele Frequenzbereichsuche) kann es sich außerdem lohnen, in den beiden Schritten mit unterschiedlichen Segementlängen zu arbeiten: Der erste Schritt ist rechenaufwändiger, weil die Berechnung für alle Dopplerverschiebungen wiederholt werden muss. Aber gleichzeitig bringen auch kurze Segemente, in der Größenordnung $\gpsTcode$ zuverlässig hohe Korrelationswerte. Es können also kurze Segemente analysiert werden um die Geschwindigkeit zu erhöhen. In der zweiten Phase muss nicht mehr über alle möglichen Codephase iteriert werden. Hier kann dann ein längeres Segment genutzt werden, um Bestimmung der Dopplerverschiebung zu verbessern\footnote{Unschärferelation der Kurzzeit Fouriertransformation}. \ No newline at end of file +Bei dem oben beschriebenen zweischrittigen Algorithmus (1. parallele Codephasensuche, 2. parallele Frequenzbereichsuche) kann es sich außerdem lohnen, in den beiden Schritten mit unterschiedlichen Segementlängen zu arbeiten: Der erste Schritt ist rechenaufwändiger, weil die Berechnung für alle Dopplerverschiebungen wiederholt werden muss. Aber gleichzeitig bringen bereits kurze Segmente, in der Größenordnung $\gpsTcode$, zuverlässig hohe Korrelationswerte. Es können also kurze Segmente analysiert werden um die Geschwindigkeit zu erhöhen. In der zweiten Phase muss nicht mehr über alle möglichen Codephase iteriert werden. Hier kann dann ein längeres Segment genutzt werden, um die Bestimmung der Dopplerverschiebung zu verbessern\footnote{Unschärferelation der Kurzzeit Fouriertransformation}. \ No newline at end of file diff --git a/2_Grundlagen/25_tracking.tex b/2_Grundlagen/25_tracking.tex index 80591a1..c70ea1d 100644 --- a/2_Grundlagen/25_tracking.tex +++ b/2_Grundlagen/25_tracking.tex @@ -1,20 +1,20 @@ \subsection{Tracking} \label{GrundlagenTracking} -Die Acquisition ist wie beschrieben ein relativ aufwändiger Prozess, und wird lediglich durchgeführt, wenn neue GPS Satelliten gesucht werden, beispielsweise nach dem Systemstart, oder wenn das Signal verloren wird. Sobald die Parameter (PRN, Codephase, Dopplershift) durch die Acquisition bestimmt wurden, werden diese an den eigentlichen Demodulator, den Trackingloop, weitergegeben. Der Begriff Trackingloop kommt daher, dass die bei der Acquisition bestimmte Codephase bzw. Dopplershift jeweils nur Momentaufnahmen sind. Dopplershift und Codephase ändern sich ständig und auch Ungenauigkeiten der Takterzeugung beim Empfänger müssen ausgeglichen werden. Der Trackingloop hat die Aufgabe die in der Acquisitonphase bestimmten Werte mittels eines Regelkreises (\emph{control loop}) nachzuführen (\emph{to track}). +Die Acquisition ist wie beschrieben ein relativ aufwändiger Prozess, und wird lediglich durchgeführt, wenn neue GPS Satelliten gesucht werden, beispielsweise nach dem Systemstart, oder wenn das Signal verloren wird. Sobald die Parameter (PRN, Codephase, Dopplershift) durch die Acquisition bestimmt wurden, werden diese an den eigentlichen Demodulator, den Tracking Loop, weitergegeben. Der Begriff \emph{Tracking Loop} kommt daher, dass die bei der Acquisition bestimmte Codephase bzw. Dopplershift jeweils nur Momentaufnahmen sind. Dopplershift und Codephase ändern sich ständig und auch Ungenauigkeiten der Takterzeugung beim Empfänger müssen ausgeglichen werden. Der Tracking Loop hat die Aufgabe die in der Acquisitonphase bestimmten Werte mittels eines Regelkreises (\emph{control loop}) nachzuführen (\emph{to track}). -\FGimg[Blockschaltbild GPS Trackingloop]{Trackingloop.png}{Blockschaltbild des GPS Trackingloops. Der Trackingloop besteht aus zwei Regelkreisen, die die LO-Frequenz bzw. die Codefrequenz nachführen. Grün markierte Blöcke haben weniger kritische Echtzeitanforderungen (\ref{echtzeitanforderungen}).}{0.9\imgmaxwidth} +\FGimg[Blockschaltbild GPS Tracking Loop]{Trackingloop.png}{Blockschaltbild des GPS Tracking Loop. Der Tracking Loop besteht aus zwei Regelkreisen, die die LO-Frequenz bzw. die Codefrequenz nachführen. Grün markierte Blöcke haben weniger kritische Echtzeitanforderungen (\ref{echtzeitanforderungen}).}{0.9\imgmaxwidth} -\FR{Trackingloop.png} zeigt ein Blockschaltbild des Trackingloops. Im Folgenden werden kurz die Funktionen der einzelnen Blöcke erklärt. Anschließend wird ein Überblick über die Funktion des gesamten Trackingloops gegeben. Eine detaillierte Beschreibung des ist in \cite{borre2007software} zu finden. +\FR{Trackingloop.png} zeigt ein Blockschaltbild des Tracking Loop. Im Folgenden werden kurz die Funktionen der einzelnen Blöcke erklärt. Anschließend wird ein Überblick über die Funktion des gesamten Tracking Loop gegeben. Eine detaillierte Beschreibung des Tracking Loop ist in \cite{borre2007software} zu finden. \paragraph{Carrier NCO} Der Carrier \gls{NCO} generiert eine lokale Kopie des (ZF-)Trägers (unter Berücksichtigung der Dopplerverschiebung). Die Frequenz des NCOs ist digital einstellbar. \paragraph{Carrier Mischer} Die zwei Carrier Mischer mischen das Eingangssignal $\gpsin$ mit dem von dem NCO erzeugten \gls{LO} Signal $\gpslo_I$ bzw. $\gpslo_Q$. Bei korrekter Einstellung des NCO wird das Eingangssignal von $f_{ZF}+f_{Doppler}$ herunter auf \SI{0}{\Hz} gemischt. -\paragraph{Carrier Loop Diskriminator} Der Carrier Loop Diskriminator analysiert das heruntergemischte Signal, und generiert ein Signal, dass den Phasenfehler angibt. +\paragraph{Carrier Loop Diskriminator} Der Carrier Loop Diskriminator analysiert das heruntergemischte Signal, und generiert ein Signal, dass die Phasendifferenz zwischen Eingangssignal und LO Signal angibt. -\paragraph{Carrier Loop Filter} Der Carrier Loop Filter wirkt als \emph{PI-Regler} (\emph{Proportional, Integral}) in dem Regelkreis. Wenn der Wert an seinem Eingang $\neq 0$ ist, integriert er diesen so lange, bis die Frequenz auf einen Wert angestiegen bzw. abgesunken ist, dass der Fehler null wird. +\paragraph{Carrier Loop Filter} Der Carrier Loop Filter wirkt als \emph{PI-Regler} (\emph{Proportional, Integral}) in dem Regelkreis. Wenn der Wert an seinem Eingang $\neq 0$ ist, integriert er diesen so lange, bis die Frequenz auf einen Wert angestiegen bzw. abgesunken ist, bei dem der Fehler null wird. -\paragraph{C/A Code Generator} Der \gls{CA} Code Generator erzeugt eine drei Kopien des Codes. Dabei ist die Codefrequenz, also die Geschwindigkeit mit der die Codesequenz \enquote{abgespielt} wird, digital einstellbar. Vereinfacht gesagt funktioniert der C/A Code Generator intern als \gls{NCO} der ein Taktsignal für die erzeugenden \gls{LFSR} generiert. Die drei Kopien unterscheiden sich leicht in der Codephase, üblicherweise um die Dauer eines $\frac{1}{2}$ Chips. Deshalb werden die Kopien mit \emph{Early}, \emph{Prompt} und \emph{Late} bezeichnet. Der Zweck dieser drei Pfade wird in Abschnitt \ref{EarlyLateGate} erläutert. +\paragraph{C/A Code Generator} Der \gls{CA} Code Generator erzeugt drei Kopien des Codes. Dabei ist die Codefrequenz, also die Geschwindigkeit mit der die Codesequenz \enquote{abgespielt} wird, digital einstellbar. Vereinfacht gesagt funktioniert der C/A Code Generator intern als \gls{NCO} der ein Taktsignal für die erzeugenden \gls{LFSR} generiert. Die drei Kopien unterscheiden sich leicht in der Codephase, üblicherweise um die Dauer eines $\frac{1}{2}$ Chips. Deshalb werden die Kopien mit \emph{Early}, \emph{Prompt} und \emph{Late} bezeichnet. Der Zweck dieser drei Pfade wird in Abschnitt \ref{EarlyLateGate} erläutert. \paragraph{Code Mischer} Nach der Mischung mit dem LO Signal wird das Signal $\gpsmx_I$ bzw. $\gpsmx_Q$ mit den Kopien des Codes gemischt. Nach der Mischung mit dem Code entspricht das Signal $\gpsxc_{I,P}$ theoretisch bereits wieder dem Datensignal $\gpsdat$. Zusammen mit den \emph{Integrate \& Dump} Blöcken (s.u.) bilden sie die Korrelatoren, die die Kreuzkorrelation zwischen Eingangssignal und lokaler Codekopie berechnen. @@ -35,7 +35,7 @@ \subsubsection{Carrier Tracking} \FGimg[Blockschaltbild Costas Loop]{Costasloop.png}{Der Costas Loop ist eine PLL Variante, die \gls{BPSK} modulierte Signale demodulieren kann.}{0.8\imgmaxwidth} -Dazu erzeugt der LO zwei Kopien des Trägers, die zueinander \SI{90}{\degree} verschoben sind: $\gpslo_I=\cos(\omega_{f} t)$ und $\gpslo_Q=\sin(\omega_{f} t)$. Das Eingangssignal $\gpsin=\gpsdat \cdot \cos(\omega_{ZF} \cdot t)$ wird im jeweiligen Arm mit dem $I$ bzw $Q$ Träger gemischt und tiefpassgefiltert: +Dazu erzeugt der LO zwei Kopien des Trägers, die zueinander \SI{90}{\degree} verschoben sind: $\gpslo_I=\cos(\omega_{f} t)$ und $\gpslo_Q=\sin(\omega_{f} t)$. Das Eingangssignal $\gpsin=\gpsdat \cdot \cos(\omega_{ZF} \cdot t)$ wird im jeweiligen Arm mit dem $I$ bzw. $Q$ Träger gemischt und tiefpassgefiltert: \begin{eqnarray} \gpsmx_I &=& \gpsin \cdot \cos(\omega_{f} t)\\ &=& \gpsdat \cdot \cos(\omega_{ZF} \cdot t) \cdot \cos(\omega_{f} t)\\ @@ -63,7 +63,7 @@ \subsubsection{Code Tracking} \paragraph{Early Late Gate} \label{EarlyLateGate} In \FR{EarlyLateBlockdiagram.png} ist ein vereinfachtes Blockschaltbild des Early Late Gate Synchronisierers dargestellt. Für das Early Late Gate werden zwei Kopien des \emph{pünktlichen} Codes $\gpsca_P$ erzeugt, \emph{Early} ($\gpsca_E$) und \emph{Late} $\gpsca_L$, die $\gpsca_P$ jeweils um $\Delta t$ voreilen ($\gpsca_E$), bzw. nacheilen ($\gpsca_L$). $\Delta t$ wird dabei üblicherweise als $\frac{1}{2} \gpsTchip$ gewählt.\footnote{Damit Verschiebungen $0r_A$. -Tabelle \ref{TabDoppler} gibt die Zahlenwerte für ein Beispiel mit einer Orbithöhe eines Cubesat von \SI{400}{km} an. +Tabelle \ref{TabDoppler} gibt die Zahlenwerte für ein Beispiel mit einer Orbithöhe eines Cubesat von \SI{400}{km} über Grund an. \begin{table}[htbp] \ttabbox diff --git a/2_Grundlagen/40_ComboardHardware.tex b/2_Grundlagen/40_ComboardHardware.tex index e10e1be..847ad9e 100644 --- a/2_Grundlagen/40_ComboardHardware.tex +++ b/2_Grundlagen/40_ComboardHardware.tex @@ -28,7 +28,7 @@ \subsection{GPS Frontend MAX2769} \FGimg[Blockdiagram MAX2769]{MAX2769.pdf}{Blockdiagramm des MAX2769 GPS Frontend ICs (entnommen aus \cite{max2769})}{0.8\imgmaxwidth} \subsection{Digitaler Signalprozessor} -Auf dem \gls{DSP} des \comboard läuft ein embedded Linux System und der Zugriff auf den FPGA und die SPI Schnittstelle erfolgt über Treiber die als ladbare Kernelmodule ausgeführt sind \FR{LinuxSystem.png}. Anwendungsprogramme (wie der GPS Prozess) können dann über die Linux Devices auf die Hardware zugreifen. Dadurch ist die Low-Level Programmierung klar von der Anwendungsprogrammierung getrennt. Weitere Vorteile des Linux Systems sind das einfache Multitasking und der Möglichkeit der Verwendung von Standardbibliotheken. Einige Nachteile gegenüber einer \emph{Bare Metal} Implementierung sind allerdings die fehlende Echtzeitfähigkeit, weshalb in dieser Arbeit der DSP nur für nicht-zeitkritische Berechnungen, verwendet wird. +Auf dem \gls{DSP} des \comboard läuft ein embedded Linux System und der Zugriff auf den FPGA und die SPI Schnittstelle erfolgt über Treiber die als ladbare Kernelmodule ausgeführt sind (\FR{LinuxSystem.png}). Anwendungsprogramme (wie der GPS Prozess) können dann über die Linux Devices auf die Hardware zugreifen. Dadurch ist die Low-Level Programmierung klar von der Anwendungsprogrammierung getrennt. Weitere Vorteile des Linux Systems sind das einfache Multitasking und der Möglichkeit der Verwendung von Standardbibliotheken. Einige Nachteile gegenüber einer \emph{Bare Metal} Implementierung sind allerdings die fehlende Echtzeitfähigkeit, weshalb in dieser Arbeit der DSP nur für nicht-zeitkritische Berechnungen verwendet wird. \FGimg[Systemarchitektur Linux]{LinuxSystem.png}{Prinzipielle Systemarchitektur eines Linux Systems. Die Hardware wird durch den Kernel und die Kerneltreiber abstrahiert}{0.7\imgmaxwidth} @@ -39,9 +39,9 @@ \subsection{Digitaler Signalprozessor} \FGimg[EBIU Memory Map]{EBIU_memmap.png}{Memory Map des ADSP-BF518 mit den für die EBIU reservierten Bereiche.}{0.65\imgmaxwidth} -Die EBIU Schnittstelle ist an den \gls{DMA} Controller den BF518 angeschlossen. Damit können sehr schnell große Datenmengen von Peripherie in den RAM des DSP übertragen werden. +Die EBIU Schnittstelle ist an den \gls{DMA} Controller den BF518 angeschlossen. Damit können sehr schnell große Datenmengen von der Peripherie in den RAM des DSP übertragen werden. -Auf dem \comboard sind nicht alle Steuersignale der EBIU Schnittstelle an den FPGA herangeführt. Daher kann für Zugriffe auf den FPGA lediglich der \gls{AMC} genutzt werden. Im Unterschied zum synchronen Speicherinterface wird hier kein Takt verwendet, und Schreib-/Lesevorgänge werden ausschließlich über die Steuerleitungen signalisiert. Um sicherzugehen, dass die Gegenseite die Kommandos erkannt hat werden Wartezustände eingebaut. Dadurch ist die Anbindung über das asynchrone Speicherinterface langsamer als das synchrone Speicherinterface. Auf Clientseite muss dazu eine State Machine implementiert werden, die protokolliert in welcher Phase (siehe \FR{EBIU_readwrite.pdf}) der Datenübertragung sich die Schnittstelle gerade befindet. +Auf dem \comboard sind nicht alle Steuersignale der EBIU Schnittstelle an den FPGA herangeführt. Daher kann für Zugriffe auf den FPGA lediglich der \gls{AMC} genutzt werden. Im Unterschied zum synchronen Speicherinterface wird hier kein Takt verwendet, und Schreib-/Lesevorgänge werden ausschließlich über die Steuerleitungen signalisiert. Um sicherzugehen, dass die Gegenseite die Kommandos erkannt hat, werden Wartezustände eingebaut. Dadurch ist die Anbindung über das asynchrone Speicherinterface langsamer als das synchrone Speicherinterface. Auf Clientseite muss dazu eine State Machine implementiert werden, die protokolliert in welcher Phase (siehe \FR{EBIU_readwrite.pdf}) der Datenübertragung sich die Schnittstelle gerade befindet. %Addressbus %Datenbus %Write Enable @@ -50,10 +50,10 @@ \subsection{Digitaler Signalprozessor} \FGimg[Timingdiagramm EBIU Asynchronous Read Write]{EBIU_readwrite.pdf}{Timing der Signale der EBIU Schnittstelle für einen asynchronen Schreib- bzw. Lesevorgang. Der Takt ist auf Clientseite nicht unbedingt benötigt. Nicht alle Steuersignale sind auf dem \comboard an den FPGA geführt. (entnommen aus \cite{BlackfinHWReference}}{0.98\imgmaxwidth} \subsection{FPGA} -Ein FPGA ist eine Integrierter Schaltkreis in dem sich digitale Schaltkreise realisieren lassen. Der FPGA besteht einfach gesagt aus einer großen Anzahl von Gattern und Flip-Flops. Die Programmierung von FPGAs erfolgt üblicherweise über eine Hardwarebeschreibungssprache (kurz HDL) wie z.B. \emph{VHDL} oder \emph{Verilog}. Mit der HDL wird beschrieben \emph{was} die Schaltung machen soll. \emph{Wie} dies umgesetzt wird wird nicht beschrieben. Daher ist HDL Code auch ersteinmal unabhängig von der Realisierung (sofern keine herstellerspezifischen Komponenten verwendet werden). Der HDL Code könnte genau so für die Herstellung eines ASIC genutzt werden. +Ein FPGA ist ein Integrierter Schaltkreis in dem sich digitale Logikschaltungen realisieren lassen. Der FPGA besteht einfach gesagt aus einer großen Anzahl von Gattern und Flip-Flops. Die Programmierung von FPGAs erfolgt üblicherweise über eine Hardwarebeschreibungssprache (kurz HDL) wie z.B. \emph{VHDL} oder \emph{Verilog}. Mit der HDL wird beschrieben \emph{was} die Schaltung machen soll. \emph{Wie} dies umgesetzt wird wird nicht beschrieben. Daher ist HDL Code auch ersteinmal unabhängig von der Realisierung (sofern keine herstellerspezifischen Komponenten verwendet werden). Der HDL Code könnte genau so für die Herstellung eines ASIC genutzt werden. Die Realisierung wird stattdessen durch ein Synthesewerkzeug entschieden, dass den Quellcode analysiert und in eine Netzliste übersetzt. Die Netzliste beschreibt die Schaltung auf Gatterebene. Mit der Netzliste wird dann durch weitere Tools ein \emph{Place \& Route} durchgeführt, das die Elemente der Netzliste den physischen Ressourcen des FPGAs zuordnet. Zum Schluss wird daraus ein sogenannter \emph{Bitstream} erstellt, der in den FPGA geladen wird. -Neben reiner programmierbare kombinatorischer und sequentieller Logik, bieten heutige FPGAs außerdem dedizierte Hardware, die sich zwar in Logik realisieren lassen würde, aber unnötige Ressourcen verbrauchen würde. So beinhaltet der verwendete \comfpga mehrere \SI{18}{\bit} Hardware Multiplizierer, insgesamt \SI{576}{\kilo\bit} Block RAM, verschiedene PLL und Digital Clock Management Module und unterstützt mehrere IO Level Standards verschiedenen IO Bänken. +Neben reiner programmierbarer kombinatorischer und sequentieller Logik, bieten heutige FPGAs außerdem dedizierte Hardware für besonders häufig verwendete Funktionen an, die sich zwar in programmierbarer Logik realisieren lassen würden, aber unnötige viele Ressourcen verbrauchen würden. So beinhaltet der verwendete \comfpga mehrere \SI{18}{\bit} Hardware Multiplizierer, insgesamt \SI{576}{\kilo\bit} Block RAM, verschiedene PLL und Digital Clock Management Module und unterstützt mehrere IO Level Standards verschiedenen IO Bänken. -Die Programmierung des FPGA ist flüchtig, wodurch der FPGA auf dem \comboard sehr flexibel einsetzbar ist. Für dieses Projekt hat der FPGA einerseits die Aufgabe eines Bindeglieds zwischen GPS Frontend und DSP, andererseits bietet die programmierbare Logik hervorragende Voraussetzungen um parallelisierbare Prozesse mit Echtzeitanforderungen zu implementieren. \ No newline at end of file +Die Programmierung des FPGA ist flüchtig und kann vom DSP aus programmiert werden, wodurch der FPGA auf dem \comboard sehr flexibel einsetzbar ist (z.B. Update-in-Flight oder Wechsel zwischen GPS und Kamera Funktion). Für dieses Projekt hat der FPGA einerseits die Aufgabe eines Bindeglieds zwischen GPS Frontend und DSP, andererseits bietet die programmierbare Logik hervorragende Voraussetzungen um parallelisierbare Prozesse mit Echtzeitanforderungen zu implementieren. \ No newline at end of file diff --git a/3_Entwurf/0_Entwurf_main.tex b/3_Entwurf/0_Entwurf_main.tex index debb9e7..2ea2aef 100644 --- a/3_Entwurf/0_Entwurf_main.tex +++ b/3_Entwurf/0_Entwurf_main.tex @@ -4,10 +4,10 @@ \chapter{Entwurf} \section{Anforderungen} Das Ziel ist, dass der \dscubesat in der Lage sein soll, seine eigene Position mittels GPS zu bestimmen. Einige Anforderungen ergeben sich außerdem aus der Konfiguration des Frontends, weshalb auch diese hier besprochen wird. -\subsection{Anzahl der Kanäle} Wie in Abschnitt \ref{positionsbestimmung} erläutert werden zur Positionsbestimmung die Daten von mindesten 4 GPS Satelliten benötigt. Daraus ergibt sich die Anforderung, dass der Empfänger mindestens 4 Kanäle zum Tracking der Signale haben muss. Weiterhin soll bei einem Verbindungsabbruch zu einem der Satelliten die Positionsbestimmung nicht abbrechen, weshalb $>4$ Kanäle erforderlich sind. Außerdem steigt die Genauigkeit der Positionsbestimmung mit mehr Satelliten. Deshalb soll der hier entwickelte GPS Empfänger mindestens 6 Kanäle umfassen. +\subsection{Anzahl der Kanäle} Wie in Abschnitt \ref{positionsbestimmung} erläutert, werden zur Positionsbestimmung die Daten von mindesten 4 GPS Satelliten benötigt. Daraus ergibt sich die Anforderung, dass der Empfänger mindestens 4 Kanäle zum Tracking der Signale haben muss. Weiterhin soll bei einem Verbindungsabbruch zu einem der Satelliten die Positionsbestimmung nicht abbrechen, weshalb $>4$ Kanäle erforderlich sind. Außerdem steigt die Genauigkeit der Positionsbestimmung mit mehr Satelliten. Deshalb soll der hier entwickelte GPS Empfänger mindestens 6 Kanäle umfassen. \subsection{Rohdatenpuffer}\label{DesignBuffersize} -Voraussetzung für das Tracking ist die erfolgreiche Acquisition, wofür eine gewisse Menge Rohdaten benötigt werden. Aufgrund der Bitwechsel Problemetik (\ref{DatenmengeAcq}) beträgt die maximal sinnvolle Pufferlänge $2\times\SI{10}{\ms}$. Für den Entwurf wurde sich an der Implementierung in der Simulation in \cite{borre2007software} orientiert, wo ein \SI{10}{\ms} Segment in der zweiten Phase der Acquisition verwendet wird. +Voraussetzung für das Tracking ist die erfolgreiche Acquisition, wofür eine gewisse Menge Rohdaten benötigt werden. Aufgrund der Bitwechsel Problematik (\ref{DatenmengeAcq}) beträgt die maximal sinnvolle Pufferlänge $2\times\SI{10}{\ms}$. Für den Entwurf wurde sich an der Implementierung in der Simulation in \cite{borre2007software} orientiert, wo ein \SI{10}{\ms} Segment in der zweiten Phase der Acquisition verwendet wird. \subsection{Komponenten und Schnittstellen des GPS Empfängers} In \FR{GPS_UML_component1.pdf} ist ein Entwurf der Komponenten des GPS Empfängers dargestellt, und die von ihnen bereitgestellten bzw. benötigten Daten. Das Diagramm macht noch keine Aussage darüber wo (ob auf DSP oder FPGA) oder wie (Hardware oder Software) die Komponenten realisiert werden. @@ -23,7 +23,7 @@ \subsection{Komponenten und Schnittstellen des GPS Empfängers} \subsection{Echtzeitanforderungen} \label{echtzeitanforderungen} -Die beiden Phasen Acquistion und Tracking haben unterschiedliche Echtzeitanforderungen: Das Tracking hat harte Echtzeitanforderungen: Erstens müssen laufend Träger- und Codekopie erzeugt und mit dem Eingangssignal multipliziert werden. Dies sind die höchsten Echtzeitanforderungen im \si{\nano\second} Bereich, da dies je Sample, also alle $1/f_S$ geschehen muss. Die Neuberechnung der Loop Parameter hat harte Echtzeitanforderungen im \si{\milli\second}, da dies lediglich nach jeder Integrationsdauer ($\gpsTcode=\SI{1}{\ms}$) passieren muss. Die Blöcke die lediglich Echtzeitanforderungen im \si{\milli\second} Bereich haben sind in \FR{Trackingloop.png} grün markiert. +Die beiden Phasen Acquistion und Tracking haben unterschiedliche Echtzeitanforderungen: Das Tracking hat harte Echtzeitanforderungen: Erstens müssen laufend Träger- und Codekopie erzeugt und mit dem Eingangssignal multipliziert werden. Dies sind die höchsten Echtzeitanforderungen im \si{\nano\second} Bereich, da dies je Sample, also alle $1/f_S$ geschehen muss. Die Neuberechnung der Loop Parameter hat harte Echtzeitanforderungen im \si{\milli\second} Bereich, da dies lediglich nach jeder Integrationsdauer ($\gpsTcode=\SI{1}{\ms}$) passieren muss. Die Blöcke die lediglich Echtzeitanforderungen im \si{\milli\second} Bereich haben sind in \FR{Trackingloop.png} grün markiert. Die Acquisition hat lediglich weiche Echtzeitanforderung im Sekundenbereich, da sich die Dopplerverschiebung nur relativ langsam verändert (schlimmstenfalls \SI{61}{\Hz/\second}, siehe \ref{maxdopplershift}). Falls die Acquisition länger als geplant dauert, kann der Trackingloop trotzdem noch einrasten wenn sich die Dopplerverschiebung nicht zu stark geändert hat. @@ -33,11 +33,11 @@ \subsection{Arbeitsteilung FPGA/DSP}\label{ArbeitsteilungFPGADSP} % Idee Vorberechnung im FPGA verworfen, Implementierungsaufwand Protokoll etc % Tracking im FPGA. Tracking erfordert hohe Parallelität bei moderatem Rechenaufwand und hat harte Echtzeitanforderungen. % Softcore Prozessor. Auswahl. Aufgabe -Das \comboard bietet mit dem DSP und dem FPGA zwei Rechenknoten an, die in verschiedenen Bereichen Vorteile und Nachteile haben: FPGAs eignen sich vor allem für gut parallelisierbare Aufgaben. Für sequentielle Aufgaben ist dagegen der Implementierungsaufwand hoch, da dies immer einen Zustandsautomaten erfordert. Im Falle des \comboard hat außerdem der DSP deutlich mehr Speicher zur Verfügung. Wie früher im Text schon besprochen haben die Acquisition und Tracking sehr unterschiedliche Anforderungen: Die Acquisition benötigt vor allem Speicher und der Ablauf (FFT, Maximumsuche, etc) ist vergleichsweise komplex. Die Echtzeitanforderungen sind bei der Acquisition nicht sehr hoch. Das Tracking dagegen hat harte Echtzeitanforderungen, aber der Rechenaufwand ist moderat, und der Ablauf ist recht einfach. Daher ist es sinnvoll die Aufgaben auf die beiden Komponenten aufzuteilen. +Das \comboard bietet mit dem DSP und dem FPGA zwei Rechenknoten an, die in verschiedenen Bereichen Vorteile und Nachteile haben: FPGAs eignen sich vor allem für gut parallelisierbare Aufgaben. Für sequentielle Aufgaben ist dagegen der Implementierungsaufwand hoch, da dies immer einen Zustandsautomaten erfordert. Im Falle des \comboard hat außerdem der DSP deutlich mehr Speicher zur Verfügung. Wie bereits früher im Text besprochen, haben Acquisition und Tracking sehr unterschiedliche Anforderungen: Die Acquisition benötigt vor allem Speicher und der Ablauf (FFT, Maximumsuche, etc) ist vergleichsweise komplex. Die Echtzeitanforderungen sind bei der Acquisition nicht sehr hoch. Das Tracking dagegen hat harte Echtzeitanforderungen, aber der Rechenaufwand ist moderat, und der Ablauf ist recht einfach. Daher ist es sinnvoll die Aufgaben auf die beiden Komponenten aufzuteilen. Der DSP kann seine Vorzüge bei der Acquisition ausspielen: Er hat einen großen Arbeitsspeicher, ist auf Signalverarbeitung ausgelegt und Programme können in einer Hochsprache wie C geschrieben werden, was nebenbei das Debugging vereinfacht. -Für das Tracking ist der FPGA ideal geeignet, da die $\geq 6$ Trackingkanäle in programmierbarer Hardware implementiert werden können und damit vollständig parallel ablaufen. Auch das Tracking erfordert allerdings einige Berechnungen, die sich einfacher in C als in VHDL beschreiben lassen. Um die Echtzeitanforderung einzuhalten werden diese Berechnungen aber nicht an den DSP übergeben. Stattdessen soll dies von einem Softcore Prozessor innerhalb FPGA der dort in programmierbarer Logik implement wird. +Für das Tracking ist der FPGA ideal geeignet, da die $\geq 6$ Trackingkanäle in programmierbarer Hardware implementiert werden können und damit vollständig parallel ablaufen. Auch das Tracking erfordert allerdings einige Berechnungen, die sich einfacher in C als in VHDL beschreiben lassen. Um die Echtzeitanforderung einzuhalten werden diese Berechnungen aber nicht an den DSP übergeben. Stattdessen soll dies von einem Softcore Prozessor innerhalb des FPGAs berechnet werden, der dort in programmierbarer Logik implementiert wird. In \FR{GPS_UML_deployment1.png} ist die Verteilung der Komponenten auf die verschiedenen Rechenknoten dargestellt. Die Komponente \emph{Tracking} aus \FR{GPS_UML_component1.pdf} ist hier auf die zwei Knoten \emph{Softcore CPU} und \emph{Tracking} aufgeteilt worden: Für jeden Kanal existiert ein \emph{TrackingHW} Knoten, der die in \FR{Trackingloop.png} weiß eingefärbten Blöcke implementiert. Für alle Kanäle gemeinsam implementiert das auf dem Softcore Prozessor laufende Programm \emph{TrackingSW} die in \FR{Trackingloop.png} grün eingefärbten Blöcke. Zur Erinnerung: Die grün eingefärbten Blöcke waren zwar algorithmisch aufwändiger, mussten dafür aber mit einer geringeren Frequenz ausgeführt werden. Durch diese Arbeitsteilung werden die Ressourcen optimal ausgenutzt. @@ -49,11 +49,11 @@ \subsection{Auswahl des Softcore Prozessors} \label{SoftcoreAuswahl} Im vorherigen Abschnitt wurde bereits die Verwendung einer Softcore CPU für einige Berechnungen im FPGA erwähnt. In einem FPGA lassen sich (in gewissen Grenzen) beliebige digitale Schaltungen synthetisieren. Funktionsblöcke, werden dabei als IP-Cores oder Softcores bezeichnet, und werden zum Beispiel als VHDL Quellcode oder als Netzlisten angeboten. Eine Softcore CPU ist also ein Prozessorkern, der über den Quellcode beschrieben wird und damit in das restliche System eingebunden werden kann. Es gibt zahlreiche kostenlose und freie Softcore CPUs auf dem Markt\footnote{Ein Überblick gibt \cite{SoftcoreOverview}}. In diesem Abschnitt soll kurz die Auswahl der Softcore CPU für den GPS Empfänger erklärt und begründet werden. -Üblicherweise bieten FPGA Hersteller bereits eigene Softcore CPUs an und als Teil der Entwicklungsumgebung Werkzeuge an um diese zu instantiieren. Für Xilinx ist dies z.B. der MicroBlaze Prozessor. Aus eigener Erfahrung verstecken jedoch die Entwurfswerkzeuge viel von der darunterliegenden Technik, wodurch das Design komplexer und weniger durchschaubar wird. Für den hier vorliegenden Fall sind die durch die CPU zu erledigenden Aufgaben relativ einfach, deshalb wurde nach einem Prozessor gesucht, der wenig Ressourcen verbraucht. Weiterhin sollte die für die Entwicklung verwendete Toolchain auf \emph{gcc} basieren, aus dem einfachen Grund, dass \emph{gcc} eine der bekanntesten Compiler Toolchains ist, in der Praxis bewährt ist und somit Einarbeitungszeit spart. +Üblicherweise stellen FPGA Hersteller eigene Softcore CPUs bereit und grafische Werkzeuge, um diese zu konfigurieren. Für Xilinx ist dies z.B. der MicroBlaze Prozessor. Aus eigener Erfahrung verstecken jedoch die Entwurfswerkzeuge viel von der darunterliegenden Technik, wodurch das Design komplexer und weniger durchschaubar wird. Für den hier vorliegenden Fall sind die durch die CPU zu erledigenden Aufgaben relativ einfach, deshalb wurde nach einem Prozessor gesucht, der wenig Ressourcen verbraucht. Weiterhin sollte die für die Entwicklung verwendete Toolchain auf \emph{gcc} basieren, aus dem einfachen Grund, dass \emph{gcc} eine der bekanntesten Compiler Toolchains ist, in der Praxis bewährt ist und somit Einarbeitungszeit spart. Die Wahl viel zunächst auf den Zylin ZPU Softcore, laut eigener Aussage die kleinste 32-bit CPU mit gcc Toolchain \cite{ZPUgithub}. Die ZPU ist ein Stack Prozessor, arbeitet also ohne Register. Das Prinzip ist ähnlich zu Taschenrechnern die mit Umgekehrt Polnischer Notation arbeiten. Zylin legt mit der ZPU Spezifikation zunächst einmal nur den Befehlscode fest. Es gibt zahlreiche Implementierungen mit verschiedenen Schwerpunkten. Leider ist durch diese Fragmentierung die Dokumentation sehr lückenhaft, und die Codequalität ist teilweise sehr schlecht. Nach mehreren Versuchen den ZPU Kern, in Form der ZPUFlex Implementierung, in das System zu integrieren wurde das Vorhaben aufgegeben. -Stattdessen wurde als Softcore der MBlite Core von Tamar Kranenburg ausgewählt. Der Entwickler hat den Prozessor in seiner Masterarbeit \cite{MBliteThesis} sehr gut dokumentiert und die Codequalität ist gut. Der MBlite Core ist eine Variante des Xilinx Microblaze und vollständig kompatibel dazu, womit die gcc Toolchain des Microblaze verwendet werden kann. Als Microblaze Variante ist er auch ein 32-bit Prozessor in Harvard Architektur. Die Vorteile des MBLite Prozessors gegenüber der Xilinx Version liegen in der Transparenz der Implementierung womit die vollständige Kontrolle beim Entwickler liegt und nicht hinter grafischen Oberflächen versteckt wird. +Stattdessen wurde als Softcore der MBlite Core von Tamar Kranenburg ausgewählt. Der Entwickler hat den Prozessor in seiner Masterarbeit \cite{MBliteThesis} sehr gut dokumentiert und die Codequalität ist gut. Der MBlite Core ist eine Variante des Xilinx Microblaze und vollständig kompatibel dazu, womit die gcc Toolchain des Microblaze verwendet werden kann. Als Microblaze Variante ist er ein 32-bit Prozessor in Harvard Architektur. Die Vorteile des MBLite Prozessors gegenüber der Xilinx Version liegen in der Transparenz der Implementierung womit die vollständige Kontrolle beim Entwickler liegt und nicht hinter grafischen Konfigurationstools versteckt wird. Die Implementierung kann je nach Anforderung an Ressourcenverbrauch oder Leistungsfähigkeit angepasst werden. Für die Anwendung im GPS Empfänger ist zum Beispiel der Hardware Multiplizierer und Barrel Shifter vorteilhaft. Die Anbindung von Peripherie kann über Memory Mapped I/O geschehen, oder über den Wishbone Bus (ein Bus Standard zur Anbindung verschiedener Cores innerhalb von integrierten Schaltkreisen). Für die Anbindung der \emph{TrackingHW} Instanzen wurde die Anbindung mit Memory Mapped I/O gewählt. Weitere Informationen zum MBlite Prozessor sind in \cite{MBliteThesis} nachzulesen. @@ -87,10 +87,10 @@ \subsection{Frontend Parameter}\label{EntwurfFrontendParameter} \paragraph{ZF und PLL Parameter} Bei der Erzeugung des LO Signals stehen im Frontend eine Integer PLL oder eine Fractional PLL zur Auswahl. Experimentell wurde bestimmt, dass die Integer PLL weniger Interferenzen verursacht, und die besten Ergebnisse bei einer ZF von etwa \SI{2}{\MHz} erreicht werden können. Bei der Auswahl der PLL Teilerfaktoren muss darauf geachtet werden, dass die geteilten Frequenzen in den im Datenblatt \cite{max2769} angegebenen Grenzen bleiben und $f_{comp}=f_{ref}/R$ muss zu dem Loop Filter der Frontend PLL passen. Das \comboard verwendet für den Loop Filter die Werte aus dem Datenblatt, wonach $f_{comp}=\SI{1.023}{\MHz}$ sein soll. Falls der komplexe Bandpass verwendet wird, muss außerdem die LO Frequenz unterhalb der Eingangsfrequenz liegen, da der komplexe Bandpass das untere Seitenband herausfiltert. -Mit dem \SI{16.368}{MHz} \gls{TCXO} auf dem \comboard ergibt sich damit $R=16$. $f_ZF$ soll im Bereich \SI{2}{\MHz} liegen, womit $N=1538$ zu wählen ist. Damit ergibt sich $f_{ZF}=f_{L1}-f_{TCXO}\cdot \frac{N}{R}=\SI{2.046}{MHz}$. +Mit dem \SI{16.368}{MHz} \gls{TCXO} auf dem \comboard ergibt sich damit $R=16$. $f_{ZF}$ soll im Bereich \SI{2}{\mega\hertz} liegen, womit $N=1538$ zu wählen ist. Damit ergibt sich $f_{ZF}=f_{L1}-f_{TCXO}\cdot \frac{N}{R}=\SI{2.046}{MHz}$. \paragraph{ZF Filter} -Als Konfiguration für das ZF Filter im Frontend wurde das komplexe Bandpassfilter gewählt. Das komplexe Bandpassfilter ist bei Anwendungen mit einer ZF $\neq 0$ zu bevorzugen, da damit die Spiegelfrequenzen unterdrückt werden\footnote{Falls die ZF zu \SI{0}{\Hz} gewählt wird sollte als ZF Filter das reelle Tiefpassfilter gewählt werden, um Satellitensignale mit negativer Doppleverschiebung nicht zu unterdrücken.}. Die untere Schranke für die Bandbreite ergibt sich aus dem Shannon-Nyquist Theorem zu $B\geq 2/\gpsTchip=\SI{1.023}{\MHz}$. Jegliche Filterung verschlechtert zwar das $E_b/N_0$, ist allerdings erforderlich um Aliasing bei der AD Wandlung zu verhindern. Wie in \cite{hegarty2011analytical} und \cite{itc1982chang} untersucht wurde, bringen allerdings Bandbreiten $B>2/\gpsTchip$ nur marginal geringere Verschlechterungen. \cite{hegarty2011analytical} nennt zum Beispiel eine Verbesserung von lediglich \SI{0.41}{\dB} wenn statt $B=2/\gpsTchip$ eine Bandbreite von $B=10/\gpsTchip$ gewählt wird. Deshalb wurde als Bandbreite $B=\SI{2.5}{\MHz}$ gewählt. +Als Konfiguration für das ZF Filter im Frontend wurde das komplexe Bandpassfilter gewählt. Das komplexe Bandpassfilter ist bei Anwendungen mit einer ZF $\neq 0$ zu bevorzugen, da damit die Spiegelfrequenzen unterdrückt werden\footnote{Falls die ZF zu \SI{0}{\Hz} gewählt wird sollte als ZF Filter das reelle Tiefpassfilter gewählt werden, um Satellitensignale mit negativer Doppleverschiebung nicht zu unterdrücken.}. Die untere Schranke für die Bandbreite ergibt sich aus dem Shannon-Nyquist Theorem zu $B\geq 2/\gpsTchip=\SI{1.023}{\MHz}$. Jegliche Filterung verschlechtert zwar das $E_b/N_0$, ist allerdings erforderlich um Aliasing bei der AD Wandlung zu verhindern. Wie in \cite{hegarty2011analytical} und \cite{itc1982chang} untersucht wurde, bringen allerdings Bandbreiten $B>2/\gpsTchip$ nur marginal geringere Verschlechterung. \cite{hegarty2011analytical} nennt zum Beispiel eine Verbesserung von lediglich \SI{0.41}{\dB} wenn statt $B=2/\gpsTchip$ eine Bandbreite von $B=10/\gpsTchip$ gewählt wird. Deshalb wurde als Bandbreite $B=\SI{2.5}{\MHz}$ gewählt. Die Mittenfrequenz $f_{cen}$ des ZF Filters lässt sich auf die gewählte ZF über ein \SI{6}{\bit} Konfigurationswort ($\textrm{FCEN}$) anpassen. Die Berechnung des Konfigurationsworts ist leider nicht im MAX2769 Datenblatt dokumentiert, es konnte aber herausgefunden werden, dass das korrekte Konfigurationswort mit folgender Gleichung ermittelt werden kann: \begin{equation} @@ -126,24 +126,24 @@ \subsection{Frontend Parameter}\label{EntwurfFrontendParameter} } \end{table} -Die Samplingrate kann über Teiler und Vervielfacher die Werte $\gpsftcxo$, $\gpsftcxo/2$, $\gpsftcxo/4$, oder $2\times \gpsftcxo$ annehmen\footnote{Es gibt außerdem noch ein Fractional Clock Divider, über den noch andere Teilraten eingestellt werden können.}. Bei der Auswahl muss ein Kompromiss gemacht werden zwischen Genauigkeit der Pseudorange Schätzung (\ref{positionsbestimmung}) und dem Speicherverbrauch für den Rohdatenpuffer. Unter Berücksichtigung der oben festgelegten Größe des Rohdatenpuffers \SI{10}{\ms} wird die Samplingrate auf $f_S=\gpsftcxo=\SI{16.368}{\MHz}$ festgelegt. Damit werden mit dem 1-bit Quantisierer mindestens \SI{163.68}{\kilo\bit} Speicher benötigt\footnote{Weil der Puffer als FIFO implementiert wird sind Speichergrößen von Zweierpotenzen vorteilhaft. Daher umfasst der Puffer \SI{262144}{\bit}, und damit etwa \SI{16}{\ms}\label{FootnoteActualBufferSize}}. +Die Samplingrate kann über Teiler und Vervielfacher die Werte $\gpsftcxo$, $\gpsftcxo/2$, $\gpsftcxo/4$, oder $2\times \gpsftcxo$ annehmen\footnote{Es gibt außerdem noch ein Fractional Clock Divider, über den noch andere Teilraten eingestellt werden können.}. Bei der Auswahl muss ein Kompromiss gemacht werden zwischen Genauigkeit der Pseudorange Schätzung (\ref{positionsbestimmung}) und dem Speicherverbrauch für den Rohdatenpuffer. Unter Berücksichtigung der oben festgelegten Größe des Rohdatenpuffers \SI{10}{\ms} wird die Samplingrate auf $f_S=\gpsftcxo=\SI{16.368}{\MHz}$ festgelegt. Damit werden mit dem 1-bit Quantisierer mindestens \SI{163.68}{\kilo\bit} Speicher benötigt\footnote{Weil der Puffer als FIFO implementiert wird, sind Speichergrößen von Zweierpotenzen vorteilhaft. Daher umfasst der Puffer \SI{262144}{\bit}, und damit etwa \SI{16}{\ms}\label{FootnoteActualBufferSize}}. -\paragraph{Andere Einstellungen} Neben den oben genannten Parametern bietet das MAX2769 Frontend noch viele weitere Einstellungen. Die meisten wurden dabei auf den Voreinstellungen belassen. Abweichend davon wurde beim Flugmodell die Phantomspeisung abgeschaltet und LNA1 ausgewählt, da dieser für passive Antennen ausgelegt ist wie sie im \dscubesat verwendet werden\footnote{Bei dem COM1 Board wurde währende der Entwicklung eine aktive Antenne und der dafür optimierte LNA2 verwendet.}. Die \gls{AGC} ist zwar aktiviert, dürfte aber bei 1-Bit Sampling keinen Einfluss haben. Der \emph{GAINREF} Parameter wurde auf 255 gesetzt. Weiterhin wurde durch ausprobieren herausgefunden, dass sich die Erfolgsrate der Acquisition leicht verbessert wenn der Hochpassfilter vor dem \gls{PGA} abgeschaltet wird (\emph{FHIPEN}$=0$). +\paragraph{Andere Einstellungen} Neben den oben genannten Parametern bietet das MAX2769 Frontend noch viele weitere Einstellungen. Die meisten wurden dabei auf den Voreinstellungen belassen. Abweichend davon wurde beim Flugmodell die Phantomspeisung abgeschaltet und LNA1 ausgewählt, da dieser für passive Antennen ausgelegt ist wie sie im \dscubesat verwendet werden\footnote{Bei dem COM1 Board wurde währende der Entwicklung eine aktive Antenne und der dafür optimierte LNA2 verwendet.}. Die \gls{AGC} ist zwar aktiviert, dürfte aber bei 1-Bit Sampling keinen Einfluss haben. Der \emph{GAINREF} Parameter wurde auf 255 gesetzt. Weiterhin wurde durch ausprobieren herausgefunden, dass sich die Erfolgsrate der Acquisition leicht verbessert, wenn der Hochpassfilter vor dem \gls{PGA} abgeschaltet wird (\emph{FHIPEN}$=0$). \section{Planung} -Nachdem im vorherigen Abschnitt die Rahmenbedingungen entworfenen wurden können nun die Arbeitspakete für die Implementierung etwas genauer festgelegt werden. +Nachdem im vorherigen Abschnitt die Rahmenbedingungen entworfenen wurden, können nun die Arbeitspakete für die Implementierung etwas genauer festgelegt werden. -Als erster Meilenstein wurde festgelegt Rohdaten vom MAX2769 Frontend sammeln zu können. Dazu muss die Schnittstelle zwischen FPGA und DSP implementiert werden, wofür auf FPGA Seite ein Gegenstück zu der EBIU Schnittstelle (\ref{ebiuinterface}) des DSP implementiert werden muss. Auf DSP Seite muss ein Kerneltreiber geschrieben werden um die Schnittstelle für Programme im User-Space zu abstrahieren. Da über die EBIU Schnittstelle lediglich \enquote{speicherartige} Peripherie angesprochen werden kann muss im FPGA Logik implementiert werden, die die AD Wandler Schnittstelle zu einem Speicher ähnlichen abstrahiert. +Als erster Meilenstein wurde festgelegt Rohdaten vom MAX2769 Frontend sammeln zu können. Dazu muss die Schnittstelle zwischen FPGA und DSP implementiert werden, wofür auf FPGA Seite ein Gegenstück zu der EBIU Schnittstelle (\ref{ebiuinterface}) des DSP implementiert werden muss. Auf DSP Seite muss ein Kerneltreiber geschrieben werden um die Schnittstelle für Programme im User-Space zu abstrahieren. Da über die EBIU Schnittstelle lediglich \enquote{speicherartige} Peripherie angesprochen werden kann muss im FPGA Logik implementiert werden, die die AD Wandler Schnittstelle zu einem Speicher ähnlichen Konstrukt abstrahiert. Als zweiter Meilenstein soll mit den nun verfügbaren Rohdaten in Matlab Acquisition und Tracking simuliert werden. Das Buch \cite{borre2007software} stellt mit dem SoftGNSS Empfänger eine Simulationsumgebung Bereit. Mit der Simulation und der funktionierenden Schnittstelle zu den Rohdaten können dann die Frontend Parameter optimiert werden. -Die Simulation im SoftGNSS Matlab Code ist nicht auf Echtzeitverarbeitung ausgelegt und unterscheidet sich deshalb stark von der endgültigen Implementierung im FPGA. Deshalb ist der dritte Meilenstein die Simulation des Tracking an eine Implementierung FPGA anzupassen. Dazu wird ein Simulink Modell erstellt welches sukzessive von einer High-Level Simulation an die FPGA Implementierung angepasst wird. +Die Simulation im SoftGNSS Matlab Code ist nicht auf Echtzeitverarbeitung ausgelegt und unterscheidet sich deshalb stark von der endgültigen Implementierung im FPGA. Deshalb ist der dritte Meilenstein die Simulation des Tracking an eine Implementierung im FPGA anzupassen. Dazu wird ein Simulink Modell erstellt welches sukzessive von einer High-Level Simulation an die FPGA Implementierung angepasst wird. -Der nächste Meilenstein ist die Implementierung des Tracking im FPGA. Ausgehend von den Erkenntnissen der Low-Level Simulation in Simulink sollen die einzelnen Module in VHDL geschrieben und getestet werden. Insbesondere das Testen ist hier wichtig, da Debugging im FPGA zeitaufwändig ist. -Teil des Trackingloop ist wie schon erwähnt auch ein Softcore Prozessor. Hier wird auf einen vorgefertigten Softcore zurückgegriffen, dieser muss jedoch noch in das System integriert werden. Parallel dazu muss der Software Teil des Trackingloop geschrieben werden. Dazu müssen einige Mathematikfunktionen für Festkommaarithmetik implementiert werden. +Der nächste Meilenstein ist die Implementierung des Tracking im FPGA. Ausgehend von den Erkenntnissen der Low-Level Simulation in Simulink, sollen die einzelnen Module in VHDL geschrieben und getestet werden. Insbesondere das Testen ist hier wichtig, da Debugging im FPGA zeitaufwändig ist. +Teil des Trackingloop ist wie schon erwähnt auch ein Softcore Prozessor. Hier wird auf einen vorgefertigten Softcore zurückgegriffen. Dieser muss jedoch noch in das System integriert werden. Parallel dazu muss der Software Teil des Trackingloop geschrieben werden. Dazu müssen einige Mathematikfunktionen für Festkommaarithmetik implementiert werden. -Als nächster Meilenstein ist die Acquisition im DSP zu integrieren. Dazu muss zum Einen der Acquisition Algorithmus programmiert werden. Zum anderen muss die Kommunikation mit dem FPGA Teil implementiert werden, um Rohdaten anfordern zu können und die Ergebnisse an die Tracking Kanäle weitergegeben werden. Zusätzlich muss die Steuerung implementiert werden, die zum Beispiel überwacht ob ein Kanal die Verbindung verliert, beispielsweise weil ein Satellit außer Sicht geht. +Als nächster Meilenstein ist die Acquisition im DSP zu integrieren. Dazu muss Tracking Loop der Acquisition Algorithmus programmiert werden. Zum anderen muss die Kommunikation mit dem FPGA Teil implementiert werden, um Rohdaten anzufordern und die Ergebnisse an die Tracking Kanäle weiterzugeben. Zusätzlich muss die Steuerung implementiert werden, die zum Beispiel überwacht, ob ein Kanal die Verbindung verliert, beispielsweise weil ein Satellit hinter dem Horizont verschwindet. Als fünfter Meilenstein ist die Extraktion der NAV Daten zu implementieren. Auch hier muss wieder die Kommunikation mit dem FPGA implementiert werden um die demodulierten Signale einzulesen. Da mit Verbindungsabbrüchen oder Übertragungsfehlern zu rechnen ist, muss diese Komponente auch solche Ausnahmen behandeln. @@ -211,7 +211,7 @@ \subsection{Schnittstelle zum Übertragen der Rohdaten} %Einige Erklärungen dazu folgen im zweiten Unterabschnitt. \subsubsection{Linux File I/O Schnittstelle} -Unter Linux werden Hardware/Software Schnittstellen typischerweise über \emph{device files} (auch \emph{special files} genannt) realisiert. Dabei abstrahiert ein Treiber die darunterliegende Hardware so, dass die Anwendung Daten durch einfach Lese-/ Schreib Operationen lesen und schreiben kann, genau wie bei einer \enquote{normalen} Datei. Es gibt einige verschiedene Typen von device files, von denen die wichtigsten \emph{Character Devices} und \emph{Block Devices} sind. +Unter Linux werden Hardware/Software Schnittstellen typischerweise über \emph{device files} (auch \emph{special files} genannt) realisiert. Dabei abstrahiert ein Treiber die darunterliegende Hardware zu einer Datei, sodass die Anwendung Daten durch ausführen einfacher Datei-Operationen lesen und schreiben kann, genau wie bei einer \enquote{normalen} Datei. Es gibt einige verschiedene Typen von device files, von denen die wichtigsten \emph{Character Devices} und \emph{Block Devices} sind. \emph{Block Devices} liefern die Daten, wie der Name schon sagt, blockweise\footnote{Die Blockgröße kann dabei natürlich auch einfach nur ein Zeichen sein. Damit ist der wahlfreie Zugriff das Hauptunterscheidungsmerkmal.} aus und verfügen über wahlfreien Zugriff. Typische Beispiele sind Festplatten. @@ -220,19 +220,19 @@ \subsubsection{Linux File I/O Schnittstelle} \FGimg[Linux File I/O Sequenzdiagramm]{GPS_UML_seq_FileIO.pdf}{Ablauf eines Lesezugriffs auf das Character Device File}{0.9\imgmaxwidth} \subsubsection{Treiberebene} -Der Aufruf einer der oben genannten Funktionen (\lstinline$fopen$ und \lstinline$fread$ usw.) ruft einen System Call auf, beispielsweise \lstinline$open$ oder \lstinline$read$. +Der Aufruf einer der oben genannten Funktionen (\lstinline$fopen$ und \lstinline[language=C]$fread$ usw.) ruft einen System Call auf, beispielsweise \lstinline[language=C]$open$ oder \lstinline[language=C]$read$. Der Treiber muss für ein Characterdevice einige Funktionen implementieren, die in der Linux Header Datei \lstinline$fs.h$ mit der Struktur \lstinline$fops$ angegeben sind. Die Struktur \lstinline$fops$ enthält Zeiger auf die Gegenstücke zu den System Calls, z.B. \lstinline$fops.read = gps_read$. -Nachdem der Linux Kernel festgestellt hat, welches Kernelmodul für die Datei zuständig ist, leitet er die System Calls an die Gegenstücke im Treiber weiter. Innerhalb des Gegenstück, bsp. \lstinline$gps_read$ passiert dann alles was notwendig ist um die angeforderten Daten zu liefern. Für den Fall \lstinline$gps_read$ bedeutet das: Die EBIU Schnittstelle muss für den Asynchronen Zugriff konfiguriert werden. Dann muss überprüft werden wie viele Daten zum Lesen verfügbar sind. Dann muss der DMA Controller initialisiert werden mit der Quell- und Zieladresse und der Anzahl zu lesenden Bytes. Zum Schluss muss die DMA Übertragung freigegeben werden und nach Beendigung der Kernel über die Anzahl gelesenen Bytes informiert werden. +Nachdem der Linux Kernel festgestellt hat, welches Kernelmodul für die Datei zuständig ist, leitet er die System Calls an die Gegenstücke im Treiber weiter. Innerhalb des Gegenstück, bsp. \lstinline$gps_read$ passiert dann alles was notwendig ist um die angeforderten Daten zu liefern. Für den Fall \lstinline$gps_read$ bedeutet das: Die EBIU Schnittstelle muss für den Asynchronen Zugriff konfiguriert werden. Dann muss überprüft werden wie viele Daten zum Lesen verfügbar sind. Dann muss der DMA Controller initialisiert werden mit der Quell- und Zieladresse und der Anzahl zu lesenden Bytes. Zum Schluss muss die DMA Übertragung freigegeben werden und nach Beendigung der Kernel über die Anzahl der gelesenen Bytes informiert werden. \subsubsection{Hardware Ebene} \label{RohdatenFIFOSchnittstelle} -Auf der FPGA Seite müssen die Daten gepuffert werden, da der DSP nicht immer sofort bereit ist die Daten zu empfangen. Dazu gibt es verschiedene Möglichkeiten: Die Daten können beispielsweise einfach in einen Speicher geschrieben werden, der durch einen im FPGA implementierten Adressdekoder auf einen Speicherbereich des DSP abgebildet wird (\FR{FIFO_vs_plain_memory.png} Variante B). Der entscheidende Nachteil hierbei ist jedoch, dass die Schreib- und Lesezeiger über die Schnittstellengrenze hinweg synchronisiert werden müssen, weil sonst keine Erkennung möglich ist ob der Puffer voll oder leer ist. Insbesondere, weil eine Synchronisation über Taktgrenzen hinweg immer problematisch ist, ist diese Variante sehr ungünstig. +Auf der FPGA Seite müssen die Daten gepuffert werden, da der DSP nicht immer sofort bereit ist die Daten zu empfangen. Dazu gibt es verschiedene Möglichkeiten: Die Daten können beispielsweise einfach in einen Speicher geschrieben werden, der durch einen im FPGA implementierten Adressdekoder auf einen Speicherbereich des DSP abgebildet wird (\FR{FIFO_vs_plain_memory.png} Variante B). Der entscheidende Nachteil hierbei ist jedoch, dass die Schreib- und Lesezeiger über die Schnittstellengrenze hinweg synchronisiert werden müssen, weil sonst keine Erkennung möglich ist, ob der Puffer voll oder leer ist. Insbesondere, weil eine Synchronisation über Taktgrenzen hinweg immer problematisch ist, ist diese Variante sehr ungünstig. Eine bessere Variante ist die Daten in eine \gls{FIFO} Warteschlange zu schreiben (\FR{FIFO_vs_plain_memory.png} Variante A). Hierbei bildet der Adressdekoder lediglich den FIFO Ausgang auf eine einzige Speicherzelle ab. Außerdem wird die Anzahl der im FIFO bereitstehenden Worte auf eine zweite Speicherzelle abgebildet. Zum Lesen von mehreren Datenwörtern wird immer wieder von der selben Speicherzelle gelesen und der FIFO im FPGA sorgt automatisch dafür, dass das nächste Wort bereit steht. -\FR{GPS_UML_Rohdatenpuffer.pdf} zeigt noch ein bisschen mehr den internen Aufbau auf FPGA Seite. Der \emph{Slave EBIU Controller} ist hier das Gegenstück im FPGA zu dem EBIU Controller im DSP ( \FR{EBIU_blockdiagram.pdf}). Er sorgt dafür die externe Asynchrone Schnittstelle auf den internen synchronen Daten- und Adressbus umzusetzen. Der Adressdekoder wertet den Adressbus aus und selektiert die entsprechenden Komponente, die ihre Daten auf den Bus legen soll. +\FR{GPS_UML_Rohdatenpuffer.pdf} zeigt noch etwas genauer den internen Aufbau auf FPGA Seite. Der \emph{Slave EBIU Controller} ist hier das Gegenstück im FPGA zu dem EBIU Controller im DSP ( \FR{EBIU_blockdiagram.pdf}). Er sorgt dafür die externe Asynchrone Schnittstelle auf den internen synchronen Daten- und Adressbus umzusetzen. Der Adressdekoder wertet den Adressbus aus und selektiert die entsprechenden Komponente, die ihre Daten auf den Bus legen soll. \FGimg[Vergleich FIFO und RAM Block Puffer]{FIFO_vs_plain_memory.png}{Vergleich des FIFO Datenpuffers (\emph{A}) mit dem Speicherblock Puffer (\emph{B}). Der entscheidende Nachteil von \emph{B} ist, dass die Schreib- und Lesezeiger über die Schnittstellengrenze hinweg synchronisiert werden müssen.}{0.95\imgmaxwidth} @@ -378,7 +378,7 @@ \subsubsection{Festkommaentwurf der Loop Filter} \begin{equation} f_{Chip,max} = \gpsfchip + 4 \cdot \frac{f_{d,max}}{1540}\approx \SI{1.024}{\MHz} \end{equation} -Der Proportionalitätsfaktor für das NCO Steuerwort ist beim Code Loop Filter $\frac{2^{N_{code}}}{f_S}$ mit $2^{N_{code}}=29$. Damit ist +Der Proportionalitätsfaktor für das NCO Steuerwort ist beim Code Loop Filter $\frac{2^{N_{code}}}{f_S}$ mit $N_{code}=29$. Damit ist \begin{equation} \textrm{FCW}_{code,max} = f_{Chip,max} \cdot \frac{2^{N_{code}}}{f_S} \approx \num{33.56e6} \end{equation} @@ -395,7 +395,7 @@ \subsubsection{Festkommaentwurf der Loop Filter} \begin{table}[htbp] \ttabbox { - \caption[Filter Koeffizienten]{Festkommaformate der Signale und Koeffizienten im Loop Filter} + \caption[Festkommaformate im Loop Filter]{Festkommaformate der Signale und Koeffizienten im Loop Filter} \label{TabKoeffFixpointFormat} } { @@ -447,10 +447,10 @@ \subsection{Matlab Simulation} %Trackingloop in Simulink In diesem Abschnitt soll kurz die Simulation in Matlab besprochen werden. Für die Simulation wurde zum einen Gebrauch gemacht von dem zu dem Buch \cite{borre2007software} gehörenden SoftGNSS Empfängers. Zum anderen wurde ein eigene Simulink Simulation des Trackings entwickelt. -\paragraph{SoftGNSS} Die verwendete Simulationssoftware SoftGNSS ist Teil des Buchs \cite{borre2007software} und beinhaltet einen vollständigen Software Defined GNSS Empfänger. Die Software ist durch das Buch und den Code selbst dokumentiert weshalb in diesem Abschnitt weniger die Funktion des Empfängers selbst beschrieben werden soll, sondern stattdessen die Anwendung in diesem Projekt. Von der Simulation wurde während der Entwicklung viel Gebrauch gemacht, um die Funktion des entwickelten Rohdateninterface zu verifizieren. Der SoftGNSS Empfänger implementiert alle Schritte, von Acquisition über Tracking und NAV Daten Extraktion bis zur Positionsbestimmung. Um das Rohdateninterface zu testen wurde ein Matlab Skript geschrieben, um die von dem Rohdateninterface kommenden Daten auf ein für den SoftGNSS Empfänger geeignetes Format umzuwandeln. Mit den umgewandelten Daten können dann die Schritte durchgeführt werden und +\paragraph{SoftGNSS} Die verwendete Simulationssoftware SoftGNSS ist Teil des Buchs \cite{borre2007software} und beinhaltet einen vollständigen Software Defined GNSS Empfänger. Die Software ist durch das Buch und den Code selbst dokumentiert weshalb in diesem Abschnitt weniger die Funktion des Empfängers selbst beschrieben werden soll, sondern stattdessen die Anwendung in diesem Projekt. Von der Simulation wurde während der Entwicklung viel Gebrauch gemacht, um die Funktion des entwickelten Rohdateninterface zu verifizieren. Der SoftGNSS Empfänger implementiert alle Schritte, von Acquisition über Tracking und NAV Daten Extraktion bis zur Positionsbestimmung. Das Rohdateninterface liefert die Daten in einem anderen Format, als der SoftGNSS erwartet. Deshalb wurde wurde ein Matlab Skript geschrieben, um die von dem Rohdateninterface kommenden Daten auf ein für den SoftGNSS Empfänger geeignetes Format umzuwandeln. \paragraph{Simulink Simulation} -Der oben beschriebene SoftGNSS Empfänger implementiert die Schritte anders als sie in der Hardware im FPGA implementiert werden: Beispielsweise werden die \gls{CA} Codes vorab mit einer Look-Up-Table generiert, statt in Echtzeit durch ein LFSR. Es wird außerdem mit Fließkommawerten gerechnet, wohingegen die FPGA Implementierung nur einzelne Bits, bzw. Festkommawerte verwendet. Bevor mit der FPGA Implementierung begonnen wurde, wurde deshalb eine eigene Simulink Simulation des Trackingloops entwickelt, mit der der Hardware Trackingloop im FPGA so gut wie möglich nachgebildet wird. Anhand dessen konnten dann z.B. die Auswirkungen der Quantisierung der Filterkoeffizienten oder Verzögerungen bei der Berechnung der Loop Parameter getestet werden. +Der oben erwähnte SoftGNSS Empfänger implementiert die Schritte anders als sie in der Hardware im FPGA implementiert werden: Beispielsweise werden die \gls{CA} Codes vorab mit einer Look-Up-Table generiert, statt in Echtzeit durch ein LFSR. Es wird außerdem mit Fließkommawerten gerechnet, wohingegen die FPGA Implementierung nur einzelne Bits, bzw. Festkommawerte verwendet. Bevor mit der FPGA Implementierung begonnen wurde, wurde deshalb eine eigene Simulink Simulation des Trackingloops entwickelt, mit der der Hardware Trackingloop im FPGA so gut wie möglich nachgebildet wird. Anhand dessen konnten dann z.B. die Auswirkungen der Quantisierung der Filterkoeffizienten oder Verzögerungen bei der Berechnung der Loop Parameter getestet werden. \FGimg[Tracking Loop Simulink Simulation]{Simulink_Trackingloop.png}{Simulink Blockdiagramm der Tracking Loop Simulation. Grün markiert sind die Teile des Tracking Loop, die in Realität mit \SI{1}{\milli\second} Abtastrate ausgeführt werden und Rot markiert die Teile die mit etwa \SI{61}{\nano\second} Abtastrate ausgeführt werden.}{1.1\imgmaxwidth} diff --git a/4_Implementierung/30_DSP_Software.tex b/4_Implementierung/30_DSP_Software.tex index 85270f6..1903fd0 100644 --- a/4_Implementierung/30_DSP_Software.tex +++ b/4_Implementierung/30_DSP_Software.tex @@ -1,5 +1,5 @@ \section{DSP Software} -Die DSP Software teilt sich auf in Kerneltreiber und User Space Software. Der Hauptteil der Arbeit hat sich mit der Entwicklung des Tracking Loop im FPGA beschäftigt, weshalb als DSP Software nur die in Abschnitt \ref{EntwurfRohdatenschnittstelle} beschriebene Rohdatenschnittstelle entwickelt wurde. Zum Ende dieses Abschnitts wird ein Beispiel gezeigt, wie sich mit dem Kerneltreiber und der dazugehörigen FPGA Firmware Rohdaten mit dem \comboard aufgezeichnet werden können. +Die DSP Software teilt sich auf in Kerneltreiber und User Space Software. Der Hauptteil der Arbeit hat sich mit der Entwicklung des Tracking Loop im FPGA beschäftigt, weshalb als DSP Software nur die in Abschnitt \ref{EntwurfRohdatenschnittstelle} beschriebene Rohdatenschnittstelle entwickelt wurde. Zum Ende dieses Abschnitts wird ein Beispiel gezeigt, wie mit dem \comboard, dem Kerneltreiber und der dazugehörigen FPGA Firmware Rohdaten aufgezeichnet werden. \subsection{Linux Kerneltreiber}\label{Kerneltreiber} Der Kerneltreiber hat folgende Aufgaben zu erfüllen: @@ -17,26 +17,26 @@ \subsection{Linux Kerneltreiber}\label{Kerneltreiber} \paragraph{Gerät im Linux Kernel registrieren und Gerätedatei erzeugen:} Diese Aufgabe wird durch die Funktion \lstinline[language=C]$compass_gps_demo_init()$ implementiert. Mit dem Makro \lstinline[language=C]$module_init()$ wird dem Kernel gesagt, dass diese Funktion beim Laden des Kernelmoduls ausgeführt werden soll. -Innerhalb der Funktion werden zuerst eine Gerätenummer und Speicher für ein Character Device alloziert. Anschließend wird eine Geräteklasse erzeugt, mit der dem Kernel mitgeteilt wird welches Kernelmodul Anfragen an Geräte dieser Klasse bearbeitet (in diesem Fall das selbe Kernelmodul, was durch das Makro \lstinline[language=C]$THIS_MODULE$ identifiziert wird.) +Innerhalb der Funktion werden zuerst eine Gerätenummer und Speicher für ein Character Device alloziert. Anschließend wird eine Geräteklasse erzeugt, mit der dem Kernel mitgeteilt wird, welches Kernelmodul Anfragen an Geräte dieser Klasse bearbeitet (in diesem Fall das selbe Kernelmodul, was durch das Makro \lstinline[language=C]$THIS_MODULE$ identifiziert wird.) Anschließend wird mit \lstinline$device_create()$ ein Datei im \lstinline$sysfs$ in einem Unterverzeichnis von \lstinline$/sys/$ erzeugt. Dies ist nicht zu verwechseln mit der Gerätedatei über die User Space Programme auf das Gerät zugreifen. Eine Gerätedatei kann zum Beispiel manuell mit dem Kommando \lstinline$mknod$ auf der Linux Kommandozeile unter Angabe der Gerätenummer erzeugt werden. Allerdings stehen mit \emph{udev} oder \emph{mdev} auch bequemere Möglichkeiten zur Verfügung die Gerätedateien automatisch zu erzeugen. Bei dem auf dem \comboard installierten Buildroot Linux ist \emph{mdev} zur dynamischen Geräteverwaltung konfiguriert. Sobald \emph{mdev} die Datei im \lstinline$sysfs$ entdeckt erstellt es automatisch eine Gerätedatei \lstinline$/dev/compass_gps_dma$. -Beim Entladen des Kernelmoduls müssen der Speicher und die Gerätenummern wieder freigegeben werden. Dies wird durch die Funktion \lstinline$compass_gps_demo_exit()$ übernommen die mit \lstinline$module_exit()$ als Clean-Up Handler registiert wird. +Beim Entladen des Kernelmoduls müssen der Speicher und die Gerätenummern wieder freigegeben werden. Dies wird durch die Funktion \lstinline$compass_gps_demo_exit()$ übernommen, die mit \lstinline$module_exit()$ als Clean-Up Handler registiert wird. \paragraph{Konfigurieren des GPS Frontends:} In Abschnitt \ref{EntwurfFrontendParameter} wurden die optimalen Parameter für das MAX2769 GPS Frontend bestimmt. Diese Parameter werden über eine SPI Schnittstelle an das Frontend gesendet. Die SPI Schnittstelle ist mit dem DSP verbunden, weshalb die Konfiguration als Teil des Kernelmoduls erfolgt. -Es gibt verschiedene Stellen an denen dies geschehen kann: Sinnvolle Möglichkeiten sind z.B. beim Laden des Moduls (\lstinline[language=C]$compass_gps_demo_init()$) oder beim öffnen der Gerätedatei durch ein User Space Programm (\lstinline[language=C]$driver_open()$) oder auch nebenläufig zur Laufzeit, indem Konfigurationsdaten in eine spezielle Datei in \lstinline$sysfs$ geschrieben werden. Letztere Möglichkeit hätte den Vorteil, dass die Frontend Konfiguration geändert werden kann ohne das Kernel Modul neu zu kompilieren. +Es gibt verschiedene Stellen an denen dies geschehen kann: Sinnvolle Möglichkeiten sind z.B. beim Laden des Moduls (\lstinline[language=C]$compass_gps_demo_init()$) oder beim Öffnen der Gerätedatei durch ein User Space Programm (\lstinline[language=C]$driver_open()$) oder auch nebenläufig zur Laufzeit, indem Konfigurationsdaten in eine spezielle Datei in \lstinline$sysfs$ geschrieben werden. Letztere Möglichkeit hätte den Vorteil, dass die Frontend Konfiguration geändert werden kann, ohne das Kernel Modul neu zu kompilieren. -Zur Zeit wird jedoch die zweite Variante verwendet, bei der mit jedem Öffnen der Gerätedatei die Konfiguration an das GPS Frontend gesendet wird. Die Variante wurde aus dem Grund der für den Anfang einfacheren Implementierung gewählt. Zukünftig sollte jedoch darüber nachgedacht werden die Konfiguration über \lstinline$sysfs$ vorzunehmen. +Zur Zeit wird jedoch die zweite Variante verwendet, bei der mit jedem Öffnen der Gerätedatei die Konfiguration an das GPS Frontend gesendet wird. Die Variante wurde aus dem Grund anfangs einfacheren Implementierung gewählt. Zukünftig sollte jedoch darüber nachgedacht werden die Konfiguration über \lstinline$sysfs$ vorzunehmen. Die Konfiguration des GPS Frontends wird über sieben \SI{32}{\bit} breite Register vorgenommen. Zuerst muss in der \lstinline[language=C]$driver_open()$ Funktion das SPI Interface konfiguriert werden. Anschließend werden die Konfigurationsworte an das GPS Frontend gesendet. Dazu wurde die Hilfsfunktion \lstinline$writeRegister()$ aus einer früheren Version des Kerneltreibers übernommen. \paragraph{Konfigurieren der EBIU Schnittstelle:} -Das asynchrone Memory Interface der EBIU Schnittstelle bietet einige Konfigurationsmöglichkeiten, z.B. wie viele Taktzyklen Lese- und Schreibzugriffe dauern sollen. Eine Beispiel für eine Konfiguration ist in \FR{EBIU_readwrite.pdf} zu sehen. Weil die EBIU Schnittstelle theoretisch auch von anderen Kernelmodulen benutzt werden kann, die eventuell eine andere Konfiguration verwenden, müssen die EBIU Schnittstellen Parameter bei jedem Lesevorgang neu konfiguriert werden\footnote{Der Schreibzugriff ist derzeit nicht implementiert. Für die zukünftige Implementierung von Schreibzugriffen muss die Schnittstelle auch bei jedem Schreibzugriff konfiguriert werden.}. +Das asynchrone Memory Interface der EBIU Schnittstelle bietet einige Konfigurationsmöglichkeiten, z.B. wie viele Taktzyklen Lese- und Schreibzugriffe dauern sollen. Eine Beispiel für eine Konfiguration ist in \FR{EBIU_readwrite.pdf} zu sehen. Weil die EBIU Schnittstelle theoretisch auch von anderen Kernelmodulen benutzt werden kann, die eventuell eine andere Konfiguration verwenden, müssen die EBIU Schnittstellen Parameter bei jedem Lesevorgang neu konfiguriert werden\footnote{Zur Zeit ist nur der Lesezugriff implementiert. Für die zukünftige Implementierung von Schreibzugriffen muss die Schnittstelle auch bei jedem Schreibzugriff konfiguriert werden.}. -Die Konfiguration erfolgt über zwei \SI{16}{\bit} Register, \lstinline$AMBCTL0$ und \lstinline$AMGCTL$. Die Werte des \lstinline$AMBCTL0$ Registers wurde aus dem Kerneltreiber für das Kamerainterface von Andrej Konforta übernommen der in \cite{DragsailAndrejMA} genaue Untersuchung zu der Performanz und Bitfehlerrate bei verschiedenen Konfigurationswerten unternommen hat. Die Konfiguration des \lstinline$AMGCTL$ wurde ebenfalls weitestgehend übernommen, lediglich der Taktausgang wurde abgeschaltet, da der EBIU Takt auf FPGA Seite nicht verwendet wird. +Die Konfiguration erfolgt über zwei \SI{16}{\bit} Register, \lstinline$AMBCTL0$ und \lstinline$AMGCTL$. Die Werte des \lstinline$AMBCTL0$ Registers wurde aus dem Kerneltreiber für das Kamerainterface von Andrej Konforta übernommen, der in \cite{DragsailAndrejMA} genaue Untersuchung zu der Performanz und Bitfehlerrate bei verschiedenen Konfigurationswerten unternommen hat. Die Konfiguration des \lstinline$AMGCTL$ wurde ebenfalls weitestgehend übernommen, lediglich der Taktausgang wurde abgeschaltet, da der EBIU Takt auf FPGA Seite nicht verwendet wird. @@ -68,14 +68,14 @@ \subsection{Linux Kerneltreiber}\label{Kerneltreiber} \paragraph{Abfragen des Füllstands des Rohdaten FIFO:} \label{FuellstandFIFO} -Ein Lesezugriff auf die Gerätedatei ruft die Funktion \lstinline[language=C]$driver_read()$ auf. Eine typischer Lesezugriff auf die Gerätedatei fragt eine bestimmt Menge an Daten an, beispielsweise \SI{4}{\kilo\byte}. Bevor der Treiber versucht die verlangte Menge aus dem FIFO auszulesen muss zuerst überprüft werden wie viele Daten überhaupt zur Verfügung stehen. +Ein Lesezugriff auf die Gerätedatei ruft die Funktion \lstinline[language=C]$driver_read()$ auf. Eine typischer Lesezugriff auf die Gerätedatei fragt eine bestimmt Menge an Daten an, beispielsweise \SI{4}{\kilo\byte}. Bevor der Treiber versucht die verlangte Menge aus dem FIFO auszulesen, muss zuerst überprüft werden, wie viele Daten überhaupt zur Verfügung stehen. -In Abschnitt \ref{RohdatenFIFOSchnittstelle} wurde bereits erklärt, dass der Füllstand des FIFOs aus einer zweiten Speicherzelle, dem FIFO Status Register, abgefragt werden kann. Das FIFO Status Register liegt an der Adresse \lstinline$GPS_FIFO_STATUS_ADDR$\footnote{Die Adresse von Statusregister und FIFO Ausgangsregister wird durch die \lstinline$PSFSM2$ Komponente im FPGA fesgelegt (siehe auch \TR{Tab_RohdatenMemMap}).}. Der Füllstand ist in Bit 2-15 des Status Registers enthalten. Die untersten beiden Bits enthalten die \emph{Full} (Bit $1$) bzw. \emph{Empty} (Bit $0$) Flags des FIFOs. +In Abschnitt \ref{RohdatenFIFOSchnittstelle} wurde bereits erklärt, dass der Füllstand des FIFOs aus einer zweiten Speicherzelle, dem FIFO Status Register, abgefragt werden kann. Das FIFO Status Register liegt an der Adresse \lstinline$GPS_FIFO_STATUS_ADDR$\footnote{Die Adresse von Statusregister und FIFO Ausgangsregister wird durch die \lstinline$PSFSM2$ Komponente im FPGA festgelegt (siehe auch \TR{Tab_RohdatenMemMap}).}. Der Füllstand ist in Bit 2-15 des Status Registers enthalten. Die Bits 1 und 2 enthalten die \emph{Full} (Bit $1$) bzw. \emph{Empty} (Bit $0$) Flags des FIFOs. Das Auslesen des Statusregisters ist in die Funktion \lstinline$get_fifo_status()$ verpackt, die nach dem Konfigurieren der EBIU Schnittstelee innerhalb der Funktion \lstinline[language=C]$driver_read()$ aufgerufen wird. Zum Lesen des Status Registers wird in der Funktion ein einfacher Zugriff ohne DMA verwendet, da der Performanzvorteil von DMA erst bei größeren Datenmengen zum tragen kommt. Die Funktion gibt eine \lstinline$fifo_status$ Datenstruktur zurück, die den Füllstand und Full/Empty Status des FIFOs enthält. \paragraph{Auslesen der Rohdaten mit DMA:} -Aus Performanzgründen muss das Auslesen der eigentlich Rohdaten mit DMA erfolgen: Der Linux Kernel unterbricht die Ausführung anderer Programme (und Kerneltreiber) mindestens alle \SI{4}{\milli\second} aufgrund des Kernel Timer Interrupts. Weitere Unterbrechungen können durch andere laufende Programme verursacht werden. Der Datenpuffer wird aber auf FPGA Seite ständig nachgefüllt und puffert maximal \SI{16}{\milli\second}\footnote{Siehe \ref{FootnoteActualBufferSize} und \ref{DesignBuffersize}}. Um ein Überlaufen des FIFO zu verhindern ist es deshalb wichtig, dass keine Unterbrechung auftritt, die länger als \SI{16}{\milli\second} ist. Dies kann lediglich durch eine DMA Übertragung garantiert werden, die nebenläufig zu dem auf dem DSP laufenden Programm Speicherbereiche kopieren kann. +Aus Performanzgründen muss das Auslesen der eigentlich Rohdaten mit DMA erfolgen: Der Linux Kernel unterbricht die Ausführung anderer Programme (und Kerneltreiber) mindestens alle \SI{4}{\milli\second} aufgrund des Kernel Timer Interrupts. Weitere Unterbrechungen können durch andere laufende Programme verursacht werden. Der Datenpuffer wird aber auf FPGA Seite ständig nachgefüllt und puffert maximal \SI{16}{\milli\second}\footnote{Siehe Fußnote\footref{FootnoteActualBufferSize} auf Seite \pageref{FootnoteActualBufferSize} und \ref{DesignBuffersize}}. Um ein Überlaufen des FIFO zu verhindern ist es deshalb wichtig, dass keine Unterbrechung auftritt, die länger als \SI{16}{\milli\second} ist. Dies kann lediglich durch eine DMA Übertragung garantiert werden, die nebenläufig zu dem auf dem DSP laufenden Programm Speicherbereiche kopieren kann. Nachdem die maximale Anzahl möglicher Datenworte bestimmt wurde wird die Funktion \lstinline$FIFO_Read_DMA16()$ aufgerufen. Diese Funktion wurde geschrieben um einen DMA Lesevorgang zu vereinfachen und erwartet als Parameter die Adresse des zu lesenden FIFO, die Zieladresse des Buffer Arrays und die Anzahl der zu lesenden Datenworte. Die Funktion führt folgende Schritte aus: @@ -87,14 +87,14 @@ \subsection{Linux Kerneltreiber}\label{Kerneltreiber} \item Markieren der Cache Region der Ziel-Speicherregion als ungültig. \end{enumerate} -Punkt 1, 3 und 4 sind vermutlich selbst erklärend. Interessanter ist Punkt 2, die Einstellung der DMA Parameter: Der DMA Controller erwartet folgende Parameter: +Punkt 1, 3 und 4 sind vermutlich selbsterklärend. Interessanter ist Punkt 2, die Einstellung der DMA Parameter: Der DMA Controller erwartet folgende Parameter: \begin{itemize} \item Die erste Quell- und Zieladresse. \item Quell- und Ziel Anzahl zu kopierender Wörter \item Quell- und Ziel Adress-Inkrement \end{itemize} -\emph{Quell- und Zieladresse} wurden der \lstinline$FIFO_Read_DMA16()$ Funktion als Parameter übergeben. Die \emph{Anzahl} der zu kopierenden Wörter auf Quell- und Zielseite ist gleich und wurde ebenfalls als Parameter übergeben. Das \emph{Adress-Inkrement} ist auf Quellseite gleich null, weil immer aus der selben Speicherzelle (dem FIFO Ausgangsregister) gelesen wird. Auf Zielseite muss das Inkrement der Größe eines Datenwortes in Bytes entsprechen, was in diesem Fall \SI{16}{\bit} also \SI{2}{\byte} groß ist. +\emph{Quell- und Zieladresse} wurden der \lstinline$FIFO_Read_DMA16()$ Funktion als Parameter übergeben. Die \emph{Anzahl} der zu kopierenden Wörter ist auf Quell- und Zielseite gleich und wurde ebenfalls als Parameter übergeben. Das \emph{Adress-Inkrement} ist auf Quellseite gleich null, weil immer aus der selben Speicherzelle (dem FIFO Ausgangsregister) gelesen wird. Auf Zielseite muss das Inkrement der Größe eines Datenwortes in Bytes entsprechen, was in diesem Fall \SI{16}{\bit} also \SI{2}{\byte} groß ist. Nachdem die DMA Übertragung gestartet wurde, transferiert der DMA Controller selbstständig die Daten. Währenddessen kann der Prozessor andere Arbeiten ausführen und der wartende Prozess kann über einen Interrupt benachrichtigt werden. Derzeit wird davon nicht Gebrauch gemacht, und es wird einfach nur eine Warteschleife ausgeführt in der das DMA Interrupt Bit manuell abgefragt wird. @@ -103,7 +103,9 @@ \subsection{Linux Kerneltreiber}\label{Kerneltreiber} Als letzter Schritt wird deshalb der Cache für die Ziel-Speicherregion als ungültig erklärt. Damit wird erzwungen bei einem Zugriff auf diese Speicherregion direkt aus dem SDRAM zu lesen. -\subsection{Beispielprogramm}\label{BeispielRohdatenAufzeichnen} +\subsection{Anwendungsbeispiel}\label{BeispielRohdatenAufzeichnen} +Hier wird ein kurzes Beispiel gegeben wie die Rohdaten aufgezeichnet werden. Alle Befehle werden auf der Kommandozeile des \comboard ausgeführt. + Das Kernelmodul wird wie andere Kernelmodule mit dem Befehl \lstinline$insmod$ geladen woraufhin die Gerätedatei \lstinline$/dev/compass_gps_dma$ erstellt wird. Zusätzlich muss auch die FPGA Firmware an den FPGA gesendet werden: \begin{lstlisting}[language=bash, deletekeywords={if}] root:/> insmod minidma.ko # Kernelmodul laden @@ -112,7 +114,7 @@ \subsection{Beispielprogramm}\label{BeispielRohdatenAufzeichnen} \end{lstlisting} \paragraph{Beispiel: Rohdaten speichern mit Standardtools} -Da das Gerät ein einfaches Character Device ist, lassen sich die Rohdaten mit einfachen Standardtools wie \lstinline$dd$ lesen. Im folgenden ist ein Beispiel gegeben bei dem die Rohdaten in eine Datei \lstinline$./dump$ gespeichert werden: +Da das Gerät ein einfaches Character Device ist, lassen sich die Rohdaten mit einfachen Standardtools wie \lstinline$dd$ lesen. Im Folgenden ist ein Beispiel gegeben bei dem die Rohdaten in eine Datei \lstinline$./dump$ gespeichert werden: \begin{lstlisting}[language=bash, deletekeywords={if}] root:/> dd if=/dev/compass_gps_dma of=./dump bs=32768 count=1000 @@ -121,7 +123,7 @@ \subsection{Beispielprogramm}\label{BeispielRohdatenAufzeichnen} root:/> \end{lstlisting} -Die Blocksize (Parameter \lstinline$bs$) gibt an wie viele Daten \emph{maximal} in einem Block versucht werden zu lesen werden. Die Blocksize wird in Bytes angegeben. Die Blocksize sollte ein Vielfaches von 2 sein, weil der FIFO ein \SI{16}{\bit} Register ist und der Wert sollte die FIFO Größe von \SI{32768}{\byte} nicht überschreiten. Der Parameter \lstinline$count$ gibt die Anzahl der Blöcke an die gelesen werden sollen. Der Parameter \lstinline$skip=10$ verwirft die ersten 10 Blöcke. +Die Blocksize (Parameter \lstinline$bs$) gibt an wie viele Daten in einem Block \emph{maximal} versucht werden zu lesen. Wenn weniger Daten zur Verfügung stehen werden entsprechend weniger Daten gelesen. Die Blocksize wird in Bytes angegeben. Die Blocksize sollte ein Vielfaches von 2 sein, weil der FIFO ein \SI{16}{\bit} Register ist und der Wert sollte die FIFO Größe von \SI{32768}{\byte} nicht überschreiten. Der Parameter \lstinline$count$ gibt die Anzahl der Blöcke an, die gelesen werden sollen. Es ist wichtig zu beachten, dass die Blocksize nur einen Maximalwert angibt. Wie oben in Abschnitt \ref{FuellstandFIFO} beschrieben werden nur die maximal so viele Datenworte gelesen wie im FIFO zur Verfügung stehen. Die Ausgabe des \lstinline$dd$ Befehls gibt Auskunft darüber wie wie viele vollständige und wie viele unvollständige Blöcke gelesen wurden. Im obigem Beispiel bedeutet die Ausgabe \lstinline$1+999 records in$, dass $1$ vollständiger \SI{32768}{\byte} Block gelesen wurde, und $999$ Blöcke mit \SI{<32768}{\byte} gelesen wurden. diff --git a/4_Implementierung/50_FPGA_Firmware.tex b/4_Implementierung/50_FPGA_Firmware.tex index 4641c8b..3036460 100644 --- a/4_Implementierung/50_FPGA_Firmware.tex +++ b/4_Implementierung/50_FPGA_Firmware.tex @@ -3,7 +3,7 @@ \section{FPGA Firmware} Da die Dokumentation in dieser Arbeit nur den derzeitigen Entwicklungsstand widerspiegelt sei für zukünftige Weiterentwicklungen auch auf die Doxygen Dokumentation\footnote{Die Doxygen Dokumentation ist im git Repository unter \lstinline$gps_fpga/doc$ zu finden.} verwiesen, die unter Umständen aktuellere Informationen enthält. -Im Folgenden wird von UML Klassendiagrammen Gebrauch gemacht um Beziehungen zwischen den Komponenten darzustellen. Deshalb soll kurz erklärt wie diese im Zusammenhang mit der Programmiersprache VHDL zu interpretieren sind: Die Hardwarebeschreibung in VHDL gliedert sich in \emph{Components}. Ein \emph{Component} ist die Instanz einer Einheit aus \emph{Entity} und \emph{Architecture}. Eine \emph{Entity} beschreibt die Schnittstelle eines \emph{Component}, und die \emph{Architecture} den inneren Aufbau und Funktion des \emph{Component}. Die \emph{Architecture} Aufbau besteht dabei aus kombinatorischer oder sequentieller Logik, kann aber auch wiederum andere \emph{Components} enthalten. +Im Folgenden wird von UML Klassendiagrammen Gebrauch gemacht um Beziehungen zwischen den Komponenten darzustellen. Deshalb soll kurz erklärt werden, wie diese im Zusammenhang mit der Programmiersprache VHDL zu interpretieren sind: Die Hardwarebeschreibung in VHDL gliedert sich in \emph{Components}. Ein \emph{Component} ist die Instanz einer Einheit aus \emph{Entity} und \emph{Architecture}. Eine \emph{Entity} beschreibt die Schnittstelle eines \emph{Component}, und die \emph{Architecture} den inneren Aufbau und Funktion des \emph{Component}. Die \emph{Architecture} Aufbau besteht dabei aus kombinatorischer oder sequentieller Logik, kann aber auch wiederum andere \emph{Components} enthalten. Typdefinitionen und Componentdeklarationen usw. können zur einfacheren Verwendung in \emph{Packages} zusammengefasst werden. Außerdem können \emph{Entities}, \emph{Architectures} und \emph{Packages} in \emph{Libraries} zusammengefasst werden\footnote{Wenn ein Element nicht aktiv einer Bibliothek hinzugefügt wird, so wird es implizit der \lstinline$work$ Bibliothek hinzugefügt.}. So wurden zum Beispiel die Komponenten des Trackingloop in der \lstinline$gps$ Bibliothek zusammengefasst. Die meisten Teile des MBlite Softcores sind Teil der \lstinline$mblite$ Bibliothek. diff --git a/4_Implementierung/52_gps_top.tex b/4_Implementierung/52_gps_top.tex index 1ebe677..26adb70 100644 --- a/4_Implementierung/52_gps_top.tex +++ b/4_Implementierung/52_gps_top.tex @@ -1,7 +1,7 @@ \subsection{Top Level Entity}\label{Section_gps_top_entity} -Die Top Level Entity ist, wie der Name sagt, die übergeordnete Komponente die zum Einen Schnittstellen zu DSP, MAX2769, und Clock bereitstellt und zum Anderen in der dazugehörigen Architecture die anderen Komponenten enthält und verbindet. +Die Top Level Entity ist, wie der Name sagt, die übergeordnete Komponente die zum einen Schnittstellen zu DSP, MAX2769, und Clock bereitstellt und zum anderen in der dazugehörigen Architecture die anderen Komponenten enthält und verbindet. -In \FR{UML_comp_structure_gps_top.pdf} ist der Aufbau der \lstinline$gps_top$ Komponente etwas vereinfacht dargestellt. Nicht dargestellt ist die in Abschnitt \ref{RohdatenFIFOSchnittstelle} beschriebene Rohdaten Schnittstelle zum DSP, die zu Anfang der Entwicklungsphase genutzt wurde um Rohdaten auf den DSP zu übertragen. Diese wird in einem eigenen Abschnitt beschrieben, da sie zu diesem Zeitpunkt aus den in Abschnitt \ref{UserIOSchnittstelle} genannten Gründen noch nicht mit dem derzeitigen Entwicklungsstand zusammengeführt wurde. Aus Gründen der Übersicht ist in \FR{UML_comp_structure_gps_top.pdf} der Clock Synthesizer nicht abgebildet. Der Clock Synthesizer frischt das vom GPS Frontend kommende Taktsignal auf und versorgt mit dem aufgefrischten Signal die anderen Komponenten. +In \FR{UML_comp_structure_gps_top.pdf} ist der Aufbau der \lstinline$gps_top$ Komponente etwas vereinfacht dargestellt. Nicht dargestellt ist die in Abschnitt \ref{RohdatenFIFOSchnittstelle} beschriebene Rohdaten Schnittstelle zum DSP, die zu Anfang der Entwicklungsphase genutzt wurde um Rohdaten auf den DSP zu übertragen. Diese wird in einem eigenen Abschnitt (\ref{implEBIUFPGA}) beschrieben, da sie zu diesem Zeitpunkt aus den in Abschnitt \ref{UserIOSchnittstelle} genannten Gründen noch nicht mit dem derzeitigen Entwicklungsstand zusammengeführt wurde. Aus Gründen der Übersicht ist in \FR{UML_comp_structure_gps_top.pdf} der Clock Synthesizer nicht abgebildet. Der Clock Synthesizer frischt das vom GPS Frontend kommende Taktsignal auf und versorgt mit dem aufgefrischten Signal die anderen Komponenten. \FGimg[Übersicht FPGA Firmware]{UML_comp_structure_gps_top.pdf}{Vereinfachte Struktur der Top Level Komponente \lstinline$gps_top$ und einige der verwendeten Typen.}{0.95\imgmaxwidth} diff --git a/4_Implementierung/55_trackingloop_vhdl.tex b/4_Implementierung/55_trackingloop_vhdl.tex index 587b2ee..2d49f63 100644 --- a/4_Implementierung/55_trackingloop_vhdl.tex +++ b/4_Implementierung/55_trackingloop_vhdl.tex @@ -1,5 +1,5 @@ \subsection{Tracking Loop} -Der Trackingloop ist teils in Hardware und Teils in Software im MBlite Softcore Prozessor implementiert. In den vorherigen Abschnitten wurde bereits der Software Teil beschrieben. In dem folgenden Abschnitt wird der Hardware Teil beschrieben. Die Beziehungen der einzelnen Klassen des Tracking Loop sind in \FR{Impl_UML_TL_classdiagram.pdf} dargestellt. Alle dort abgebildeten Komponenten sind in der Bibliothek \lstinline$gps$ zusammengefasst. In \FR{UML_class_tracking_loop_pkg.pdf} sind die im \emph{Package} \lstinline$tracking_loop_pkg$, definierten Typen dargestellt. Außerdem sind dort einige Konstanten und die Component Deklarationen zusammenfasst (nicht dargestellt in \FR{UML_class_tracking_loop_pkg.pdf}). +Der Trackingloop ist teils in Hardware und Teils in Software im MBlite Softcore Prozessor implementiert. In den vorherigen Abschnitten wurde bereits der Software Teil beschrieben. In den folgenden Abschnitten werden die Komponenten des Hardwareteils beschrieben. Die Beziehungen der einzelnen Klassen des Tracking Loop sind in \FR{Impl_UML_TL_classdiagram.pdf} dargestellt. Alle dort abgebildeten Komponenten sind in der Bibliothek \lstinline$gps$ zusammengefasst. In \FR{UML_class_tracking_loop_pkg.pdf} sind die im \emph{Package} \lstinline$tracking_loop_pkg$, definierten Typen dargestellt. Außerdem sind dort einige Konstanten und die Component Deklarationen zusammenfasst (nicht dargestellt in \FR{UML_class_tracking_loop_pkg.pdf}). \FGimg[Klassendiagramm des Tracking Loop]{Impl_UML_TL_classdiagram.pdf}{Klassendiagramm des Trackingloop. Die VHDL \emph{Entities} sind als UML \emph{Interfaces} modelliert, und die dazugehörigen VHDL \emph{Architectures} als UML \emph{Klassen}.}{0.95\imgmaxwidth} diff --git a/4_Implementierung/60_MBlite.tex b/4_Implementierung/60_MBlite.tex index da68480..eec13a3 100644 --- a/4_Implementierung/60_MBlite.tex +++ b/4_Implementierung/60_MBlite.tex @@ -16,7 +16,7 @@ \subsection{MBlite Firmware} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Tracking Kanal in MBlite Firmware ]{Der \lstinline$t_channel$ Typ fasst alle Attribute eines Trackingloop Kanals zusammen. Der Typ ist in \lstinline$trackingloop.h$ definiert.} + \caption[Typdefinition \lstinline$t_channel$]{Der \lstinline$t_channel$ Typ fasst alle Attribute eines Trackingloop Kanals zusammen. Der Typ ist in \lstinline$trackingloop.h$ definiert.} \label{Tab_t_channel} } { @@ -39,7 +39,7 @@ \subsection{MBlite Firmware} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Hardwareregister in MBlite Firmware ]{Der \lstinline$t_hw_regs$ Typ spiegelt das Memory Layout der Register der \emph{TrackingHW} Komponente wieder (siehe auch \FR{TLMemoryLayout.pdf} und \TR{Tab_tracking_loop_memory_map}). Der Typ ist in \lstinline$trackingloop.h$ definiert.} + \caption[Typdefinition \lstinline$t_hw_regs$]{Der \lstinline$t_hw_regs$ Typ spiegelt das Memory Layout der Register der \emph{TrackingHW} Komponente wieder (siehe auch \FR{TLMemoryLayout.pdf} und \TR{Tab_tracking_loop_memory_map}). Der Typ ist in \lstinline$trackingloop.h$ definiert.} \label{Tab_t_hw_regs} } { @@ -64,7 +64,7 @@ \subsection{MBlite Firmware} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition IQ Korrelatoren in MBlite Firmware ]{Der \lstinline$t_iq$ Typ fasst I und Q Integrate \& Dump Register des Early, Prompt oder Late Zweigs zusammen (siehe auch \FR{TLMemoryLayout.pdf} und \TR{Tab_tracking_loop_memory_map}). Der Typ ist in \lstinline$trackingloop.h$ definiert.} + \caption[Typdefinition \lstinline$t_iq$]{Der \lstinline$t_iq$ Typ fasst I und Q Integrate \& Dump Register des Early, Prompt oder Late Zweigs zusammen (siehe auch \FR{TLMemoryLayout.pdf} und \TR{Tab_tracking_loop_memory_map}). Der Typ ist in \lstinline$trackingloop.h$ definiert.} \label{Tab_t_iq} } { @@ -86,7 +86,7 @@ \subsection{MBlite Firmware} Anschaulich betrachtet funktioniert der \emph{CORDIC} Algorithmus indem die komplexe Zahl als Zeiger betrachtet wird, den es gilt so zu drehen, dass er auf der $x$-Achse liegt. Dies geschieht mit inkrementellen Schritten, wobei die Drehung durch Skalieren der $x$ und $y$ Komponenten des Zeigers realisiert wird. Die Drehwinkel sind dabei so gewählt, dass der Skalierungsfaktor eine Potenz von 2 ist\footnote{Zum besseren Verständnis sei auch auf den Quellcode verwiesen. Außerdem wurde in \lstinline$doc/CORDIC.ggb$ ein interaktives \emph{GeoGebra} Applet erstellt, mit dem die Funktion des \emph{CORDIC} Algorithmus graphisch dargestellt ist.}. Damit kann das Skalieren durch einfache Schiebe- und Additionsoperationen und völlig ohne Multiplikationen oder Divisionen realisiert werden. Dadurch kann der \emph{CORDIC} Algorithmus sehr schnell und mit einer vorab bekannten Anzahl an Schritten, Betrag und Phase berechnen. \lstinline[language=C]$int16_t dll_discriminator(t_channel* ch_x)$ -Berechnet den Code Diskriminator Wert für Kanal \lstinline[language=C]$ch_x$. Der Rückgabewert ist eine Festkommazahl im Format $Q1.14$. Die Berechnung erfolgt nach der Formel \ref{EqnCodeDiscr}. Zur Berechnung der Beträge ($\sqrt{\tilde{y}_{I}^2+\tilde{y}_{Q}^2}$) wird der \emph{CORDIC} Algorithmus verwendet der in \lstinline[language=C]$cart2polar()$ implementiert ist. Wie bei der Beschreibung der \lstinline$cart2polar()$ Funktion erwähnt, gibt die Funktion den mit dem Faktor $k \approx 1.644$ skalierten Betrag ($k\cdot \sqrt{\tilde{y}_{I}^2+\tilde{y}_{Q}^2}$) zurück. Dies hat jedoch auf das Ergebnis keinen Einfluss, da wenn man Formel \ref{EqnCodeDiscr} betrachtet der Faktor $k$ in Zähler und Nenner vorkommt und sich somit heraus kürzt. +Berechnet den Code Diskriminator Wert für Kanal \lstinline[language=C]$ch_x$. Der Rückgabewert ist eine Festkommazahl im Format $Q1.14$. Die Berechnung erfolgt nach Formel \ref{EqnCodeDiscr}. Zur Berechnung der Beträge ($\sqrt{\tilde{y}_{I}^2+\tilde{y}_{Q}^2}$) wird der \emph{CORDIC} Algorithmus verwendet der in \lstinline[language=C]$cart2polar()$ implementiert ist. Wie bei der Beschreibung der \lstinline$cart2polar()$ Funktion erwähnt, gibt die Funktion den mit dem Faktor $k \approx 1.644$ skalierten Betrag ($k\cdot \sqrt{\tilde{y}_{I}^2+\tilde{y}_{Q}^2}$) zurück. Dies hat jedoch auf das Ergebnis keinen Einfluss, da wenn man Formel \ref{EqnCodeDiscr} betrachtet, der Faktor $k$ in Zähler und Nenner vorkommt und sich somit herauskürzt. \lstinline[language=C]$void pll(t_channel* ch_x)$ @@ -120,7 +120,7 @@ \subsection{MBlite Firmware} In der \lstinline[language=C]$main()$ Funktion werden die Tracking Loop Kanäle konfiguriert. Dazu muss die in Abschnitt \ref{TLStartProzedur} beschriebene Startprozedur eingehalten werden. Außerdem ist vorgesehen, aber bisher noch nicht implementiert, dass in der \lstinline[language=C]$main()$ Funktion die Kommunikation mit dem DSP abläuft. -\subsubsection{Kompilieren der Firmware und erzeugen der Speicherabbilder} +\subsubsection{Kompilieren der Firmware und Generieren der Speicherabbilder} % Adressoffset? Makefile? Im Unterschied zu einem Anwendungsprogramm für einen \enquote{normalen} Mikrocontroller oder einem Programm für einen PC sind beim Kompilieren und Erzeugen des ausführbaren Programms für den MBlite Softcore einige Besonderheiten zu beachten. @@ -141,7 +141,7 @@ \subsubsection{Kompilieren der Firmware und erzeugen der Speicherabbilder} Weil der MBlite Prozessor über optionale Funktionen (z.B. Hardware Multiplizierer oder Barrel Shifter) verfügt, muss dem Compiler für Schritt 1 mitgeteilt werden welche Instruktionen in Hardware realisiert werden können und welche mit anderen Instruktionen emuliert werden müssen. Die entsprechenden Optionen sind in dem \lstinline$Makefile$ in der Variable \lstinline$XILFLAGS$ zusammengefasst. \paragraph{Schritt 2: Linken der Object Files} -In Schritt 2 wird das Memory Layout des Programms festgelegt, wie z.B. bei welcher Adresse die Datensektionen beginnen oder wie groß Stack und Heap sind. Die erste Sektion des Data Memories ist die \lstinline$.ctors$ Sektion. Die Startadresse dieser Sektion wurde auf $0x10000000$ (Variable \lstinline$DMEM_OFFSET$) festgelegt. Dies bedeutet nicht das das Binary \SI{>268}{\mega\byte} groß ist: Die Adressen sind \emph{virtuelle Adressen}. Der Adressdekoder sorgt dafür, dass Zugriffe auf diese virtuellen Adressen dem richtigen Speicher bzw. Peripheriegerät zugeordnet werden\footnote{Die Memory Map ist in der Datei \lstinline$gps_fpga/rtl/vhdl/config_Pkg.vhd$ festgelegt.}. +In Schritt 2 wird das Memory Layout des Programms festgelegt, wie z.B. bei welcher Adresse die Datensektionen beginnen oder wie groß Stack und Heap sind. Die erste Sektion des Data Memories ist die \lstinline$.ctors$ Sektion. Die Startadresse dieser Sektion wurde auf $0x10000000$ (Variable \lstinline$DMEM_OFFSET$) festgelegt. Dies bedeutet nicht, dass das Binary \SI{>268}{\mega\byte} groß ist: Die Adressen sind \emph{virtuelle Adressen}. Der Adressdekoder sorgt dafür, dass Zugriffe auf diese virtuellen Adressen dem richtigen Speicher bzw. Peripheriegerät zugeordnet werden\footnote{Die Memory Map ist in der Datei \lstinline$gps_fpga/rtl/vhdl/config_Pkg.vhd$ festgelegt.}. In dem Programm wird lediglich wenig Stack- bzw. Heap Speicher benötigt. Deshalb wird über Linker Optionen die Heap- und Stack Größe gegenüber dem Standardwert auf je \SI{4}{\kilo\byte} verkleinert. @@ -154,7 +154,7 @@ \subsubsection{Kompilieren der Firmware und erzeugen der Speicherabbilder} \paragraph{Schritt 5:} Die Programme\footnote{Die Programme kommen als Teil des MBlite Quellcodes und sind unter \lstinline$gps_fpga/firmware/util$ zu finden.} \lstinline$bin2vhd_4x8$ bzw. \lstinline$bin2vhd_32b$ konvertieren die \lstinline$.bin$ Memory Dumps in VHDL Komponenten die den Speicherinhalt als VHDL Array enthalten. -Der Grund weshalb zwei verschiedene Programme verwendet werden liegt in den unterschiedlichen Anforderungen für Instruction und Data Memory: Während für den Instruction Memory immer nur auf ganze \SI{32}{\bit} Worte zugegriffen werden muss, soll bei dem Data Memory auch auf \SI{16}{\bit}, \SI{8}{\bit} Worte zugegriffen werden können. +Der Grund weshalb zwei verschiedene Programme verwendet werden liegt in den unterschiedlichen Anforderungen für Instruction und Data Memory: Während für den Instruction Memory immer nur auf ganze \SI{32}{\bit} Worte zugegriffen werden muss, soll bei dem Data Memory auch auf \SI{16}{\bit} und \SI{8}{\bit} Worte zugegriffen werden können. Als zweiten Parameter erwarten die beiden Programme die Größe des Speichers. Die minimal notwendige Größe lässt sich mit dem Kommando\footref{MBBinutils} \lstinline$size$ bestimmen. Der Instruction Memory muss mindestest so groß sein wie die Sektion \lstinline$.text$. Der Data Memory muss mindestens so groß sein wie die Sektionen \lstinline$.data$ und \lstinline$.bss$ zusammen. Zu beachten ist herbei, dass \lstinline$size$ die Größe in \emph{Bytes} ausgibt, \lstinline$bin2vhd_*$ aber die Anzahl der 32 Bit Speicherworte als Potenz von 2 erwartet. Wenn also als Parameter eine \lstinline$10$ angegeben wird, so wird ein Speicher erzeugt, der $2^{10}\times \SI{4}{\byte}=\SI{4}{\kilo\byte}$ umfasst. diff --git a/4_Implementierung/impl_CPU_interrupt_ctrl.tex b/4_Implementierung/impl_CPU_interrupt_ctrl.tex index 0b1c49f..5756ad5 100644 --- a/4_Implementierung/impl_CPU_interrupt_ctrl.tex +++ b/4_Implementierung/impl_CPU_interrupt_ctrl.tex @@ -11,7 +11,7 @@ \subsection{Interrupt Controller} Der Signal \lstinline$o_intr$ wird mit dem Interrupt Eingang des MBlite Prozessors verbunden. -Ein Interrupt muss von den Quellen durch einen \lstinline$'1'$ Impuls signalisiert werden, das heißt, dass die Leitung nur für eine Taktperiode auf \lstinline$'1'$ gehalten werden soll und danach wieder auf \lstinline$'0'$ gesetzt wird. Der Interrupt Controller wird daraufhin die Nummer des Interrupts in der FIFO Warteschlange speichern. Je Taktperiode kann ein Ereignis in die Warteschlange eingefügt werden. Bei mehreren gleichzeitig auftretenden Interrupt Ereignissen gehen die weiteren Ereignisse jedoch \emph{nicht} verloren, sondern werden während der darauf folgenden Taktperioden eingefügt. So lange sich Interrupts in der Warteschlange befinden, ist \lstinline$o_intr='1'$. +Ein Interrupt muss von den Quellen durch einen \lstinline$'1'$ Impuls signalisiert werden, das heißt, dass die Leitung nur für eine Taktperiode auf \lstinline$'1'$ gehalten werden soll und danach wieder auf \lstinline$'0'$ gesetzt wird. Der Interrupt Controller wird daraufhin die Nummer des Interrupts in der FIFO Warteschlange speichern. Je Taktperiode kann ein Ereignis in die Warteschlange eingefügt werden. Bei mehreren gleichzeitig auftretenden Interrupt Ereignissen gehen die weiteren Ereignisse jedoch \emph{nicht} verloren, sondern werden während der darauf folgenden Taktperioden eingefügt. Solange sich Interrupts in der Warteschlange befinden, ist \lstinline$o_intr='1'$. In der \gls{ISR} muss die CPU dann zuerst die Quelle des Interrupts abfragen. Dazu ist der Ausgang des FIFO über den Address Decoder an den Datenbus der CPU angeschlossen. Die Adresse unter der der Interrupt Controller zu finden ist wird über die Memory Map in \lstinline$config_Pkg.vhd$ festgelegt. Lesen von dieser Adresse liefert die Nummer der Interrupt Quelle. Anschließend muss die CPU den Interrupt bestätigen um ihn aus der Warteschlange zu löschen. Dazu wird auf die selbe Adresse ein Schreibvorgang ausgeführt. Dabei ist es unwichtig welcher Wert geschrieben wird, intern wertet die Interrupt Controller Komponente nur das \emph{Write Enable} Signal aus (\lstinline$i_dmem.we_o$). @@ -22,7 +22,7 @@ \subsection{Interrupt Controller} \item Bevor ein erneuter Interrupt von der selben Quelle verarbeitet werden kann, muss der frühere Interrupt in die Warteschlange eingefügt worden sein. \end{enumerate} -In der Praxis sind diese Einschränkungen jedoch kein Problem, da sie lediglich zum tragen kommen wenn die Ereignisse in sehr kurzer Zeitabfolge (wenige Taktperioden) aufeinander folgen. Eine Änderung der Bearbeitungsreihenfolge ist in diesen Fällen nicht gravierend. +In der Praxis sind diese Einschränkungen jedoch kein Problem, da sie lediglich zum tragen kommen, wenn die Ereignisse in sehr kurzer Zeitabfolge (wenige Taktperioden) aufeinander folgen. Eine Änderung der Bearbeitungsreihenfolge ist in diesen Fällen nicht gravierend. \begin{table}[htbp] \ttabbox diff --git a/4_Implementierung/impl_Clock_Synthesizer.tex b/4_Implementierung/impl_Clock_Synthesizer.tex index 6392f6b..da6740b 100644 --- a/4_Implementierung/impl_Clock_Synthesizer.tex +++ b/4_Implementierung/impl_Clock_Synthesizer.tex @@ -7,9 +7,9 @@ \subsection{Clock Synthesizer} \FGimg[Fehlende Taktflanken]{ODDR_Buffer_Runt_Pulse_and_ADC_clock.png}{Taktsignal des GPS Fronted (unten) und das durch einen \lstinline$ibufg$ Buffer aufgefrischte Signal (oben). Wie man sieht reicht die Energie des Taktsignals nicht immer aus den Clock Buffer zu treiben. Für die Messung wurde das aufgefrischte Taktsignal über ein \lstinline$ODDR2$ \gls{Primitive} nach außen geführt.}{0.8\imgmaxwidth} -Die \lstinline$phaseshift180$ Entity (\FR{UML_class_phaseshift180.pdf}) ist die Schnittstelle zu dem dem \lstinline$DCM_CLKGEN$ Clock Synthesizer \gls{Primitive}. Die Entity wurde mit dem Xilinx Core Generator erzeugt und die einzelnen Signale der Schnittstelle sind in \TR{TabPhaseshift180_Entity} beschrieben. +Die \lstinline$phaseshift180$ Entity (\FR{UML_class_phaseshift180.pdf}) ist die Schnittstelle zu dem \lstinline$DCM_CLKGEN$ Clock Synthesizer \gls{Primitive}. Die Entity wurde mit dem Xilinx Core Generator erzeugt und die einzelnen Signale der Schnittstelle sind in \TR{TabPhaseshift180_Entity} beschrieben. -In \FR{Eye_Diagram_MAX2769_output_color2.png} ist zu sehen, dass das GPS Frontend die Daten auf der steigenden Taktflanke ändert. Damit die Daten von den weiteren Stufen im FPGA sicher eingelesen werden, werden die weiteren Stufen mit dem \SI{180}{\degree} verschobenen Taktsignal an \lstinline$o_clk_180$ getaktet. So ist sichergestellt, dass die Setup und Hold Zeiten der Flip Flops eingehalten werden. +In \FR{Eye_Diagram_MAX2769_output_color2.png} ist zu sehen, dass das GPS Frontend die Daten auf der steigenden Taktflanke ändert. Damit die Daten von den weiteren Stufen im FPGA sicher eingelesen werden, werden die weiteren Stufen mit dem \SI{180}{\degree} verschobenen Taktsignal \lstinline$o_clk_180$ getaktet. So ist sichergestellt, dass die Setup und Hold Zeiten der Flipflops eingehalten werden. \FGimg[Clock Synthesizer Schnittstelle]{UML_class_phaseshift180.pdf}{Die \lstinline$phaseshift180$ Entity ist die Schnittstelle zum \lstinline$DCM_CLKGEN$ Clock Synthesizer \gls{Primitive}.}{4cm} @@ -21,7 +21,7 @@ \subsection{Clock Synthesizer} } { \rowcolors{2}{light-gray}{White} - \begin{tabular}{c c l p{5.5cm}} + \begin{tabular}{c c l p{5.8cm}} \toprule Name & I/O & Typ & Beschreibung \\ \midrule diff --git a/4_Implementierung/impl_PSFSM2.tex b/4_Implementierung/impl_PSFSM2.tex index 22bdcb4..3ef14fd 100644 --- a/4_Implementierung/impl_PSFSM2.tex +++ b/4_Implementierung/impl_PSFSM2.tex @@ -1,10 +1,10 @@ \subsubsection{EBIU Schnittstelle auf FPGA Seite} - +\label{implEBIUFPGA} \FGimg[Entity/Architecture der EBIU Schnittstelle auf FPGA Seite]{UML_class_PSFSM2.pdf}{Entity und Architecture der \lstinline$PSFSM2$ Komponente, die das Bindeglied zwischen dem asynchronen Memory Interface des DSP und dem Rohdaten FIFO ist. Die in den \lstinline$t_EBIU_*$ Typen efinierten Signalen entsprechen der in \cite{BlackfinHWReference} definierten EBIU Schnittstelle.}{0.9\imgmaxwidth} Auf der FPGA Seite muss ein Gegenstück zu dem Asynchronen Memory Interface des DSP implementiert werden. Diese Komponente ist in \lstinline$PSFSM2.vhd$ implementiert. Sie dient als Bindeglied zwischen dem EBIU Interface und dem Rohdaten FIFO. -Die Herausforderung bei dem Asynchronen Memory Interface ist, wie der Name schon sagt, die Asynchronität der Signale zu dem Systemtakt des FPGA: Wenn die Setup \& Hold Zeiten der Flipflops nicht eingehalten werden, kann das FF in einen Metastabilen Zustand gelangen, der erst nach längerer, nicht vorhersagbarer Zeit verlassen wird\footnote{Einige weiterführende Informationen zu dem Thema sind in \cite{FPGAFAQMetastability} und \cite{ginosar2011metastability} zu finden. Eine umfangreiche Artikelsammlung zu dem Thema bietet \cite{MetastabilityBibliography}}. +Die Herausforderung bei dem Asynchronen Memory Interface ist, wie der Name schon sagt, die Asynchronität der Signale zu dem Systemtakt des FPGA: Wenn die Setup \& Hold Zeiten der Flipflops nicht eingehalten werden, kann das FF in einen metastabilen Zustand gelangen, der erst nach längerer, nicht vorhersagbarer Zeit verlassen wird\footnote{Einige weiterführende Informationen zu dem Thema sind in \cite{FPGAFAQMetastability} und \cite{ginosar2011metastability} zu finden. Eine umfangreiche Artikelsammlung zu dem Thema bietet \cite{MetastabilityBibliography}}. Eine perfekte Lösung Metastabilität im ersten Flipflop, auf das das Eingangssignal trifft, zu verhindern existiert nicht. Es gibt lediglich die Möglichkeit durch das Einbauen von Wartezyklen die Wahrscheinlichkeit, dass der metastabile Zustand auch an nachfolgende Flipflop Stufen propagiert wird, zu verringern. Damit lässt sich die \gls{MTBF} auf ein akzeptables Maß vergrößern. Genau dies wird auch bei dem Asynchronen Memory Interface der EBIU gemacht. Die Einstellung der Wartezeiten wurde in \TR{TabEBIUTimingConfig} gegeben. Außerdem wird durch die PSFSM2 die Memory Map festgelegt, also unter welcher Adresse der DSP den FIFO bzw. dessen Statusregister auslesen kann (\TR{Tab_RohdatenMemMap}). @@ -20,7 +20,7 @@ \subsubsection{EBIU Schnittstelle auf FPGA Seite} } { \rowcolors{2}{light-gray}{White} - \begin{tabular}{c c p{2.5cm} p{5.5cm}} + \begin{tabular}{c c p{2cm} p{5.5cm}} \toprule Name & I/O & Typ & Beschreibung \\ \midrule @@ -28,8 +28,8 @@ \subsubsection{EBIU Schnittstelle auf FPGA Seite} \lstinline$reset$ & I & \lstinline$std_logic$ & Asynchrones Reset Signal (aktiv wenn \lstinline$reset='1'$) \\ \lstinline$i_EBIU$ & I & \lstinline$t_EBIU_out$ & EBIU Signale vom DSP zum FPGA\\ \lstinline$o_EBIU$ & O & \lstinline$t_EBIU_in$ & EBIU Signale vom FPGA zum DSP\\ - \lstinline$i_FIFO$ & I & \lstinline$t_fifo_ps_Read_out$ & Signale von PSFSM2 Komponente zum Rohdaten FIFO \\ - \lstinline$o_FIFO$ & O & \lstinline$t_fifo_ps_Read_out$ & Signale vom Rohdaten FIFO zur PSFSM2 Komponente \\ + \lstinline$i_FIFO$ & I & \lstinline$t_fifo_ps _Read_out$ & Signale von PSFSM2 Komponente zum Rohdaten FIFO \\ + \lstinline$o_FIFO$ & O & \lstinline$t_fifo_ps _Read_out$ & Signale vom Rohdaten FIFO zur PSFSM2 Komponente \\ \bottomrule \end{tabular} } @@ -71,7 +71,7 @@ \subsubsection{EBIU Schnittstelle auf FPGA Seite} \midrule \lstinline$state$ & \lstinline$state_type$ & \gls{FSM} Zustand.\\ \lstinline$psfsm_to_EBIU$ & \lstinline$t_EBIU_in$ & Ausgangsregister.\\ - \lstinline$psfsm_to_fifo$ & \lstinline$t_fifo_ps_Read_in$ & Register für Steuersignale zum FIFO.\\ + \lstinline$psfsm_to_fifo$ & \lstinline$t_fifo_ps _Read_in$ & Register für Steuersignale zum FIFO.\\ \lstinline$fifo_status$ & \lstinline$SLV(15 downto 0)$ & FIFO Füllstand und Full/Empty Flags\\ \lstinline$readcount$ & \lstinline$SLV(15 downto 0)$ & Register für Testzwecke (siehe Architecture Beschreibung.)\\ \bottomrule diff --git a/4_Implementierung/impl_TL_IandD.tex b/4_Implementierung/impl_TL_IandD.tex index f73cc93..2ed3872 100644 --- a/4_Implementierung/impl_TL_IandD.tex +++ b/4_Implementierung/impl_TL_IandD.tex @@ -10,7 +10,7 @@ \subsubsection{Korrelatoren und Integrate \& Dump} \begin{table}[htbp] \ttabbox { - \caption[Carrier NCO Schnittstelle]{Schnittstellenbeschreibung (Entity) der \lstinline$carrier_nco$ Komponente.} + \caption[Integrate \& Dump Block Schnittstelle]{Schnittstellenbeschreibung (Entity) der \lstinline$integrate_and_dump$ Komponente.} \label{TabIandD_Entity} } { @@ -35,7 +35,7 @@ \subsubsection{Korrelatoren und Integrate \& Dump} \begin{table}[htbp] \ttabbox { - \caption[Carrier NCO interne Signale]{Interne Signale der \lstinline$integrate_and_dump$ Komponente.} + \caption[Integrate \& Dump interne Signale]{Interne Signale der \lstinline$integrate_and_dump$ Komponente.} \label{TabIandD_ArchSignals} } { @@ -54,7 +54,7 @@ \subsubsection{Korrelatoren und Integrate \& Dump} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Code NCO Zustandsregister]{Beschreibung der Struktur des Integrate \& Dump Zustandsregisters (\lstinline$t_iandd_reg$ Typ).} + \caption[Typdefinition \lstinline$t_iandd_reg$]{Beschreibung der Struktur des Integrate \& Dump Zustandsregisters (\lstinline$t_iandd_reg$ Typ).} \label{Tab_t_iandd_reg_Type} } { diff --git a/4_Implementierung/impl_TL_ca_lfsr.tex b/4_Implementierung/impl_TL_ca_lfsr.tex index 24eb502..b1f52f7 100644 --- a/4_Implementierung/impl_TL_ca_lfsr.tex +++ b/4_Implementierung/impl_TL_ca_lfsr.tex @@ -1,5 +1,5 @@ \subsubsection{Gold Code LFSR} -Diese Komponente ist in \lstinline$ca_lfsr_pkg.vhd$ implementiert und generiert die \gls{CA} Code Sequenz zu einer PRN. Bei \lstinline$i_ClkEna='1'$ und einer steigenden Taktflanke an \lstinline$i_clk$ wird an \lstinline$o_chip$ ein neuer Chip ausgegeben. Bei \lstinline$i_reset='1'$ wird das interne Schieberegister auf \lstinline$"1111111111"$ zurückgesetzt. In allen anderen Fällen wird der vorherige Zustand gehalten. +Diese Komponente ist in \lstinline$ca_lfsr_pkg.vhd$ implementiert und generiert die \gls{CA} Code Sequenz für eine gegebenen PRN. Bei \lstinline$i_ClkEna='1'$ und einer steigenden Taktflanke an \lstinline$i_clk$ wird an \lstinline$o_chip$ ein neuer Chip ausgegeben. Bei \lstinline$i_reset='1'$ wird das interne Schieberegister auf \lstinline$"1111111111"$ zurückgesetzt. In allen anderen Fällen wird der vorherige Zustand gehalten. \FGimg[Entity/Architecture des Gold Code LFSR]{UML_class_LFSR.pdf}{Entity und Architecture des \gls{LFSR}, das die Gold Code Sequenz erzeugt.}{8cm} diff --git a/4_Implementierung/impl_TL_carrier_nco.tex b/4_Implementierung/impl_TL_carrier_nco.tex index 67fbafa..370efc7 100644 --- a/4_Implementierung/impl_TL_carrier_nco.tex +++ b/4_Implementierung/impl_TL_carrier_nco.tex @@ -36,7 +36,7 @@ \subsubsection{Carrier NCO} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Code NCO Ausgangssignal]{Beschreibung der Struktur des \lstinline$t_carrier_nco_out$ Typs. Der Typ ist in \lstinline$tracking_loop_pkg.vhd$ definiert.} + \caption[Typdefinition \lstinline$t_carrier_nco_out$]{Beschreibung der Struktur des \lstinline$t_carrier_nco_out$ Typs. Der Typ ist in \lstinline$tracking_loop_pkg.vhd$ definiert.} \label{Tab_t_carrier_nco_out} } { @@ -81,7 +81,7 @@ \subsubsection{Carrier NCO} constant LUcos : std_logic_vector(3 DOWNTO 0):= "1001"; --! The `cos(x)` Look-up-table \end{lstlisting} -Der Phasenakkumulator ist in dieser Implementierung $N_carrier_nco=\SI{28}{\bit}$ weit, und ist als sequentieller Prozess realisiert. Mit jeder steigenden Taktflanke wird zu dem Phasenakkumulator der Wert an \lstinline$i_deltaf$ addiert. Die beiden MSB des Akkumulators werden dann zur Addressierung der \gls{LUT} verwendet, um die Amplitudenwerte zu erhalten. Damit wird auch klar woher das oben genannte NCO Gain $K_{0,carrier}=\frac{2^{N_{carrierNCO}}}{f_{clk}}$ kommt: Die Zeit zwischen zwei Akkumulator Überläufen ist die Periodendauer mit der die \gls{LUT} genau einmal durchlaufen wird. Die Zeit zwischen zwei Überläufen beträgt +Der Phasenakkumulator ist in dieser Implementierung $N_{carrierNCO}=\SI{28}{\bit}$ weit, und ist als sequentieller Prozess realisiert. Mit jeder steigenden Taktflanke wird zu dem Phasenakkumulator der Wert an \lstinline$i_deltaf$ addiert. Die beiden MSB des Akkumulators werden dann zur Addressierung der \gls{LUT} verwendet, um die Amplitudenwerte zu erhalten. Damit wird auch klar woher das oben genannte NCO Gain $K_{0,carrier}=\frac{2^{N_{carrierNCO}}}{f_{clk}}$ kommt: Die Zeit zwischen zwei Akkumulator Überläufen ist die Periodendauer mit der die \gls{LUT} genau einmal durchlaufen wird. Die Zeit zwischen zwei Überläufen beträgt \begin{equation} T=\frac{2^{N_{carrierNCO}}}{f_{clk}\cdot FCW}=\frac{1}{f_{out}} \end{equation} diff --git a/4_Implementierung/impl_TL_code_nco.tex b/4_Implementierung/impl_TL_code_nco.tex index eb5fedc..e99c2be 100644 --- a/4_Implementierung/impl_TL_code_nco.tex +++ b/4_Implementierung/impl_TL_code_nco.tex @@ -3,7 +3,7 @@ \subsubsection{Code NCO} Das keine \emph{Taktsignale}, sondern nur \emph{Steuersignale} generiert werden ist ein wichtiges Detail: Dadurch werden nachfolgende Komponenten weiterhin mit dem Systemtakt getrieben und bleiben somit synchron zu den anderen Komponenten des Trackingloop und dem MBlite Prozessor. Andernfalls könnte dies Timingprobleme und somit Metastabilität verursachen. -Die drei Ausgangssignale \lstinline$Ena_clk$, \lstinline$Ena_clk_x2$ und \lstinline$Ena_clk_div1023$ sind in dem \lstinline$record$ \lstinline$o_nco$ zusammengefasst \TR{TabCodeNCO_Type}. Die Ausgangssignale sind Impulse, d.h. sie sind nur genau für die Dauer $1/\gpsfsamp$ \lstinline$'1'$ und sonst \lstinline$'0'$. Die Frequenz, mit der sich die Impulse wiederholen, ist abhängig von dem Wert an \lstinline$i_fcw$. Genau wie bei dem Carrier NCO ist die Frequenz proportional aber nicht gleich zu dem \gls{FCW}: +Die drei Ausgangssignale \lstinline$Ena_clk$, \lstinline$Ena_clk_x2$ und \lstinline$Ena_clk_div1023$ sind in dem \lstinline$record$ \lstinline$o_nco$ zusammengefasst (\TR{TabCodeNCO_Type}). Die Ausgangssignale sind Impulse, d.h. sie sind nur genau für die Dauer $1/\gpsfsamp$ gleich \lstinline$'1'$ und sonst \lstinline$'0'$. Die Frequenz, mit der sich die Impulse wiederholen, ist abhängig von dem Wert an \lstinline$i_fcw$. Genau wie bei dem Carrier NCO ist die Frequenz \emph{proportional} aber \emph{nicht gleich} zu dem \gls{FCW}: \begin{equation} FCW=f_{out}\cdot K_{0,code} =f_{out}\cdot \frac{2^{N_{codeNCO}}}{f_{clk}} @@ -39,7 +39,7 @@ \subsubsection{Code NCO} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Code NCO Ausgangssignal]{Beschreibung der Struktur des \lstinline$t_code_nco_out$ Typs. Der Typ ist in \lstinline$tracking_loop_pkg.vhd$ definiert.} + \caption[Typdefinition \lstinline$t_code_nco_out$]{Beschreibung der Struktur des \lstinline$t_code_nco_out$ Typs. Der Typ ist in \lstinline$tracking_loop_pkg.vhd$ definiert.} \label{TabCodeNCO_Type} } { @@ -81,7 +81,7 @@ \subsubsection{Code NCO} \begin{table}[htbp] \ttabbox { - \caption[Typdefinition Code NCO Zustandsregister]{Beschreibung der Struktur des Code NCO Zustandsregisters (\lstinline$t_code_nco_out$ Typ).} + \caption[Typdefinition \lstinline$t_code_nco_out$]{Beschreibung der Struktur des Code NCO Zustandsregisters (\lstinline$t_code_nco_out$ Typ).} \label{Tab_t_code_nco_reg_Type} } { @@ -99,7 +99,7 @@ \subsubsection{Code NCO} } \end{table} -Wie die Architecture des Carrier NCO enthält auch die Code NCO Archtiecture einen Phasenakkumulator. Im Gegensatz zu dem Carrier NCO wird zur Erzeugung des Ausgangssignals aber keine \gls{LUT} verwendet. Stattdessen wird eine Logik eingesetzt, die das MSB des Akkumulators überwacht und \lstinline$Ena_clk$ für genau eine Taktperiode auf \lstinline$'1'$ setzt. Dazu wird ein zweites Register \lstinline$prev_count$ benutzt, dass den vorherigen Zustand des MSB speichert und \lstinline$Ena_clk$ nur auf \lstinline$'1'$ setzt, wenn das MSB den Zustand \emph{gewechselt} hat. Alternativ hätte auch der Akkumulatorwert mit $2^N_{codeNCO}-1$ verglichen werden können. In diesem Fall müssten aber $N_{codeNCO}$ Bits verglichen werden, wofür mehr Logikressourcen benötigt werden. Daher wurde die zuvor erklärte Logik verwendet, die lediglich ein Flip Flop und einen \SI{1}{\bit} Vergleicher benötigt. +Wie die Architecture des Carrier NCO enthält auch die Code NCO Archtiecture einen Phasenakkumulator. Im Gegensatz zu dem Carrier NCO wird zur Erzeugung des Ausgangssignals aber keine \gls{LUT} verwendet. Stattdessen wird eine Logik eingesetzt, die das MSB des Akkumulators überwacht und \lstinline$Ena_clk$ für genau eine Taktperiode auf \lstinline$'1'$ setzt. Dazu wird ein zweites Register \lstinline$prev_count$ benutzt, dass den vorherigen Zustand des MSB speichert und \lstinline$Ena_clk$ nur auf \lstinline$'1'$ setzt, wenn das MSB den Zustand \emph{gewechselt} hat. Alternativ hätte auch der Akkumulatorwert mit $2^N_{codeNCO}-1$ verglichen werden können. In diesem Fall müssten aber $N_{codeNCO}$ Bits verglichen werden, wofür mehr Logikressourcen benötigt werden. Daher wurde die zuvor erklärte Logik verwendet, die lediglich ein Flipflop und einen \SI{1}{\bit} Vergleicher benötigt. Ähnliche Logik wird für die Generierung des Signals \lstinline$Ena_clk_x2$ eingesetzt, hier wird aber stattdessen das zweihöchste Bit überwacht. diff --git a/4_Implementierung/impl_TL_tracking_loop.tex b/4_Implementierung/impl_TL_tracking_loop.tex index 2e0690c..021c3d4 100644 --- a/4_Implementierung/impl_TL_tracking_loop.tex +++ b/4_Implementierung/impl_TL_tracking_loop.tex @@ -1,7 +1,7 @@ \subsubsection{Tracking Loop Komponente} Diese Komponente ist in \lstinline$tracking_loop.vhd$ beschrieben, und eine Übersicht ist in \FR{UML_class_tracking_loop.pdf} abgebildet. Sie entspricht der in \FR{GPS_UML_deployment1.png} dargestellten \emph{TrackingHW} Komponente. Für jeden Kanal wird eine Instanz dieser Komponente benötigt. Zusammen mit dem Software Teil der im MBlite Prozessor läuft, übernimmt diese Komponente nach der Acquistion das Nachführen des Lokaloszillators und des Code Generators, so wie es in Abschnitt \ref{GrundlagenTracking} beschrieben wurde. -Die Funktion dieser Komponente ist eng verknüpft mit der \emph{TrackingSW} Komponente die im MBlite Prozessor läuft: Sie muss die \emph{TrackingHW} Komponente mit den Werten für Carrier FCW, Code FCW und initialer Codephase konfigurieren. Danach muss die TrackingSW Komponente das Startsignal geben. Während des Betriebs muss sie die Korrelator Ausgabewerte lesen, damit die neuen Werte für Carrier FCW und Code FCW berechnen und die neuen Werte an die TrackingHW Komponente übermitteln. +Die Funktion dieser Komponente ist eng verknüpft mit der \emph{TrackingSW} Komponente die im MBlite Prozessor läuft: Sie muss die \emph{TrackingHW} Komponente mit den Werten für Carrier FCW, Code FCW und initialer Codephase konfigurieren. Danach muss die \emph{TrackingSW} Komponente das Startsignal geben. Während des Betriebs muss die \emph{TrackingSW} Komponente die Korrelator Ausgabewerte lesen, damit die neuen Werte für Carrier FCW und Code FCW berechnen und die neuen Werte an die \emph{TrackingHW} Komponente übermitteln. \FGimg[Entity/Architecture Tracking Loop]{UML_class_tracking_loop.pdf}{Die übergeordnete Entity/Architecture des Tracking Loop}{10cm} @@ -102,10 +102,10 @@ \subsubsection{Tracking Loop Komponente} Wie bereits früher erwähnt, werden lediglich \SI{1}{\bit} Samples verwendet, wobei eine \lstinline$'0'$ als $+1$ interpretiert wird und eine \lstinline$'1'$ als $-1$\footnote{Dies ist genau umgekehrt zu der Interpretation in der Integrate \& Dump Komponente. Da allerdings ohnehin mit einer \SI{\pm180}{\degree} Unsicherheit gerechnet werden muss, ist dies nicht schlimm. Die nachfolgende Signalverarbeitung zur NAV Daten Extraktion invertiert das Signal, falls notwendig.}. Damit können die Mischer einfach als XOR Glieder realisiert werden: -\begin{table}[htbp] +\begin{table}[H] \ttabbox { - \caption[Exklusiv-Oder Glied]{Vergleich Multiplikation und Exklusiv-Oder (XOR) Glied.} + \caption[Exklusiv-Oder Glied vs. Multiplikation]{Vergleich Multiplikation und Exklusiv-Oder (XOR) Glied.} \label{TabXOR} } { @@ -123,7 +123,7 @@ \subsubsection{Tracking Loop Komponente} } \end{table} -Die innere Struktur der Architecture orientiert sich grob an dem Blockschaltbild in \FR{Trackingloop.png} wobei die grünen Blöcke, wie bereits erwähnt, in Software in MBlite Prozessor realisiert sind. +Die innere Struktur der Architecture orientiert sich grob an dem Blockschaltbild aus \FR{Trackingloop.png}, wobei die grünen Blöcke, wie bereits erwähnt, in Software in MBlite Prozessor realisiert sind. \subparagraph{Start Prozedur} In der Beschreibung der Schnittstelle wurden bereits die notwendigen Schritte zum Starten eines Tracking Loop Kanals beschrieben. Durch das Zurücksetzen des Trackingloop (Schritt 1), befinden sich die LFSR, die den \gls{CA} Code erzeugen, im Zustand \lstinline$"1111111111"$, was der Codephase $0$ entspricht. Auch nach Setzen der \lstinline$enable$ Flag in Schritt 2 bleiben die LFSR in diesem Zustand. diff --git a/5_Appendix/1_Festkomma.tex b/5_Appendix/1_Festkomma.tex index de61d20..7688fdb 100644 --- a/5_Appendix/1_Festkomma.tex +++ b/5_Appendix/1_Festkomma.tex @@ -1,6 +1,6 @@ \chapter{Festkomma Arithmetik} \label{AppendixFestkomma} -In dieser Arbeit wird an mehreren Stellen von Berechnungen mit Festkommazahlen Gebrauch gemacht. Dieser Abschnitt erläutert einige Grundlagen zur Darstellung von Festkommazahlen und Berechnungen damit. Der Entwurf von Algorithmen mit Festkommazahlen ist zwar deutlich aufwändiger, weil der darstellbare Dynamikbereich begrenzt ist. Aber die Berechnung mit Festkommazahlen bringt deutliche Leistungsvorteile die den höheren Entwurfsaufwand rechtfertigen. Dies gilt insbesondere auf Rechnern ohne Fließkommaeinheit die Fließkommaberechnungen in Software emulieren müssen. +In dieser Arbeit wird an mehreren Stellen von Berechnungen mit Festkommazahlen Gebrauch gemacht. Dieser Abschnitt erläutert einige Grundlagen zur Darstellung von Festkommazahlen und Berechnungen damit. Der Entwurf von Algorithmen mit Festkommazahlen ist zwar aufwändiger, weil der darstellbare Dynamikbereich begrenzt ist. Aber die Berechnung mit Festkommazahlen bringt deutliche Leistungsvorteile die den höheren Entwurfsaufwand rechtfertigen. Dies gilt insbesondere auf Rechnern ohne Fließkommaeinheit, die Fließkommaberechnungen in Software emulieren müssen. \section{Nomenklatur} diff --git a/5_Ergebnisse/0_Ergebnisse_main.tex b/5_Ergebnisse/0_Ergebnisse_main.tex index ab2ae12..131949b 100644 --- a/5_Ergebnisse/0_Ergebnisse_main.tex +++ b/5_Ergebnisse/0_Ergebnisse_main.tex @@ -4,7 +4,7 @@ \chapter{Ergebnisse} Deshalb teilt sich die Präsentation der Ergebnisse in zwei Abschnitte: -\paragraph{Acquisition} Für den Meilensteine 1 wird demonstriert wie Rohdaten mit einer an das \comboard angeschlossenen Antenne aufgezeichnet werden. Mit diesen Rohdaten wird für den Meilenstein 2 anschließend die Acquisiton und das Tracking in Matlab mit dem SoftGNSS Receiver durchgeführt. +\paragraph{Acquisition} Für die Meilensteine 1 und 2 wird demonstriert wie Rohdaten mit einer an das \comboard angeschlossenen Antenne aufgezeichnet werden. Mit diesen Rohdaten wird anschließend die Acquisiton und das Tracking in Matlab mit dem SoftGNSS Receiver durchgeführt. \paragraph{Tracking} Für den Meilenstein 3 wird ein künstlich erzeugtes Signal mit bekanntem SNR, Dopplerverschiebung und Codephase mit dem in VHDL geschriebenen Code getracked und demoduliert. diff --git a/5_Ergebnisse/30_Acquisition_Ergebnis.tex b/5_Ergebnisse/30_Acquisition_Ergebnis.tex index b71e55e..dd67ca3 100644 --- a/5_Ergebnisse/30_Acquisition_Ergebnis.tex +++ b/5_Ergebnisse/30_Acquisition_Ergebnis.tex @@ -1,5 +1,5 @@ \section{Rohdatenschnittstelle und Acquisition} -In Abschnitt \ref{BeispielRohdatenAufzeichnen} wurde bereits gezeigt, wie sich mit dem Kerneltreiber und Linux Standard Tools Rohdaten aufzeichnen lassen. Für die im folgenden präsentierten Ergebnisse wurde dies mit dem Flugmodell des \dscubesat durchgeführt. +In Abschnitt \ref{BeispielRohdatenAufzeichnen} wurde bereits gezeigt, wie sich mit dem Kerneltreiber und Linux Standard Tools Rohdaten aufzeichnen lassen. Für die im Folgenden präsentierten Ergebnisse wurde dies mit dem Flugmodell des \dscubesat durchgeführt. \subsection{Versuchsaufbau} Der Versuch wurde im Labor des Compass Projekt am Fachbereich Luft- und Raumfahrt der FH Aachen durchgeführt. Dazu wurde das Flugmodell des \dscubesat in Fensternähe aufgestellt. Das Blickrichtung des Fensters ist etwa \SI{110}{\degree}. Das Compass Labor liegt im 2. OG und oberhalb des angrenzenden Gebäudes. Die Lage des Versuchsortes ist in \FR{Versuch_Flugmodell_Karte.png} illustriert. @@ -27,23 +27,23 @@ \subsection{Versuchsdurchführung} } { \rowcolors{2}{light-gray}{White} - \begin{tabular}{c p{3cm}} + \begin{tabular}{c p{3.5cm}} \toprule Parameter & Wert \\ \midrule - \lstinline$msToProcess$ & \lstinline{600} \\ - \lstinline$skipNumberOfBytes$ & \lstinline{0} \\ + \lstinline$msToProcess$ & \num{600} \\ + \lstinline$skipNumberOfBytes$ & \num{0} \\ \lstinline$filename$ & Dateiname der umgewandelten Datei. \\ \lstinline$dataType$ & \lstinline$'int8'$ \\ - \lstinline$IF$ & \lstinline$2.046e6$ \\ - \lstinline$samplingFreq$ & \lstinline$16.368e6$ \\ - \lstinline$acqThreshold$ & \lstinline$1.8$ \\ + \lstinline[language={}]$IF$ & \num{2.046E6} \\ + \lstinline$samplingFreq$ & \num{16.368E6} \\ + \lstinline$acqThreshold$ & \num{1.8} \\ \bottomrule \end{tabular} } \end{table} -Eine genaue Beschreibung der Parameter ist dem kommentierten Quellcode der SoftGNSS Konfiguration zu entnehmen. Der Parameter \lstinline$acqThreshold$ legt die Schwelle fest ab der ein Satelliten Signal als \emph{vorhanden} gezählt wird. Diese wurde in der Entwurfsphase ursprünglich auf \num{2.5} festgelegt. Für den Versuch mit dem Flugmodell musste diese Schwelle jedoch etwas gesenkt werden, vermutlich aufgrund der passiven Antennen die ein schwächeres Signal liefern als die aktive Antenne, die in den Vorversuchen verwendet wurde. +Eine genaue Beschreibung der Parameter ist dem kommentierten Quellcode der SoftGNSS Konfiguration zu entnehmen. Der Parameter \lstinline$acqThreshold$ legt die Schwelle fest ab der ein Satelliten Signal als \enquote{vorhanden} gezählt wird. Diese wurde in der Entwurfsphase ursprünglich auf \num{2.5} festgelegt. Für den Versuch mit dem Flugmodell musste diese Schwelle jedoch etwas gesenkt werden, vermutlich aufgrund der passiven Antennen die ein schwächeres Signal liefern als die aktive Antenne, die in den Vorversuchen verwendet wurde. \subsection{Versuchsergebnisse} Mit dem aufgezeichneten Signal hat der SoftGNSS Empfänger einen Satelliten mit der PRN 30 gefunden. Die durch die Acquisition bestimmten Parameter sind in \TR{FlugmodellAcquisitionErgebnisse} aufgelistet @@ -69,6 +69,6 @@ \subsection{Versuchsergebnisse} } \end{table} -\FR{Versuch_Flugmodell_SoftGNSS_Tracking.pdf} zeigt das Ergebnis des Tracking. Im Konstellationsdiagramm (oben links) lassen sich sehr gut die Konstellationspunkte der BPSK Modulation erkennen. Im oberen rechten Diagramm ist das Ausgangssignal des \emph{I Prompt} Korrelators dargestellt ($\gpspllout_{E,I}$ in \FR{Trackingloop.png}), der das demodulierte Signal ausgibt. Es sind sehr gut die Bits der NAV Daten erkennbar. Man sieht, dass am Anfang die Signalstärke etwas schwächer ist. Dies ist darauf zurückzuführen, dass zu beginn der Regelkreis noch nicht perfekt auf die korrekten Parameter eingeschwungen ist. +\FR{Versuch_Flugmodell_SoftGNSS_Tracking.pdf} zeigt das Ergebnis des Tracking. Im Konstellationsdiagramm (oben links) lassen sich sehr gut die Konstellationspunkte der BPSK Modulation erkennen. Im oberen rechten Diagramm ist das Ausgangssignal des \emph{I Prompt} Korrelators dargestellt ($\gpspllout_{E,I}$ in \FR{Trackingloop.png}), der das demodulierte Signal ausgibt. Es sind sehr gut die Bits der NAV Daten erkennbar. Man sieht, dass am Anfang das \gls{SNR} etwas schlechter ist. Dies ist darauf zurückzuführen, dass zu Beginn der Regelkreis noch nicht perfekt auf die korrekten Parameter eingeschwungen ist. \FGimg[Versuchsergebnis Flugmodell]{Versuch_Flugmodell_SoftGNSS_Tracking.pdf}{Demoduliertes Signal aus dem Versuch mit dem Flugmodell.}{10cm} \ No newline at end of file diff --git a/5_Ergebnisse/60_Tracking_Ergebnis.tex b/5_Ergebnisse/60_Tracking_Ergebnis.tex index 0b17d4b..fa76447 100644 --- a/5_Ergebnisse/60_Tracking_Ergebnis.tex +++ b/5_Ergebnisse/60_Tracking_Ergebnis.tex @@ -14,9 +14,9 @@ \subsection{Versuchsvorbereitung} Dem resultierenden \lstinline$gps_top_tb$ Programm können auf der Kommandozeile einige Optionen übergeben werden, wie z.B. die Stop Zeit der Simulation. Eine detaillierte Beschreibung der Optionen ist der \emph{ghdl} Dokumentation zu entnehmen. -Der Dateiname aus dem das Programm versucht die Rohdaten zu lesen ist in \lstinline$gps_top_tb.vhd$ über ein Generic auf \lstinline$./infile$ festgelegt. Dieser kann auf den korrekten Dateinamen angepasst werden. Für die folgende Simulation wurde aber einfach ein symbolischer Link auf die Datei mit den Rohdaten erstellt. +Der Dateiname aus dem das Programm versucht die Rohdaten zu lesen ist in \lstinline$gps_top_tb.vhd$ über ein Generic auf \lstinline$./infile$ festgelegt. Dieser kann auf den korrekten Dateinamen angepasst werden. Für die folgende Simulation wurde aber einfach ein symbolischer Link von \lstinline$./infile$ auf die Datei mit den Rohdaten erstellt. -Um zu prüfen ob die durch den Tracking Loop demodulierten Daten auch den gesendeten NAV Daten entsprechen, wurden für diesen Versuch künstlich erzeugte Rohdaten mit bekannter PRN, SNR, Codephase und Dopplerverschiebung erzeugt. Das erzeugte Signal trägt als \enquote{Nutzdaten} einfach eine zufällige Sequenz von Einsen und Nullen. Die Nutzdatenrate beträgt wie beim echten GPS Signal auf \SI{50}{\bit\per\second} festgelegt. Die Dopplerverschiebung des Signals ändert sich mit \SI{10}{\hertz\per\second} um einen langsamen Drift zu simulieren, dem der Tracking Loop folgen muss. Die weiteren Parameter sind in \TR{TrackingVersuchTestsignalParameter} zusammengefasst. Der Dateiname der Testdaten ist \lstinline$testdata_noisy_-30dBSNR_IF1M949875_PRN28_int8$. +Um zu prüfen ob die durch den Tracking Loop demodulierten Daten auch den gesendeten NAV Daten entsprechen, wurden für diesen Versuch künstlich erzeugte Rohdaten mit bekannter PRN, SNR, Codephase und Dopplerverschiebung erzeugt. Das erzeugte Signal trägt als \enquote{Nutzdaten} einfach eine zufällige Sequenz von Einsen und Nullen. Die Nutzdatenrate beträgt wie beim echten GPS Signal \SI{50}{\bit\per\second}. Die Dopplerverschiebung des Signals ändert sich mit \SI{10}{\hertz\per\second} um einen langsamen Drift zu simulieren, dem der Tracking Loop folgen muss. Die weiteren Parameter sind in \TR{TrackingVersuchTestsignalParameter} zusammengefasst. Der Dateiname der Testdaten ist \lstinline[language={}]$testdata_noisy_-30dBSNR_IF1M949875_PRN28_int8$. Die Tracking Loop Parameter werden zu Beginn der \lstinline$main()$ Funktion vom MBlite Softcore Prozessor an den Tracking Loop Kanal gesendet. Bis die Konfiguration des Tracking Loop Kanals abgeschlossen ist vergehen etwa 214 Taktzyklen, während denen das (Dummy-) GPS Frontend schon Rohdaten sendet. Deshalb muss die Codephase um diese 214 Taktzyklen angepasst werden. @@ -47,7 +47,7 @@ \subsection{Versuchsergebnisse} In \FR{Versuch_Tracking_Plot_Results.png} sind einige Signale des Tracking Loop Kanals graphisch dargestellt. Auch hier sind im oberen Teil wieder sehr gut die demodulierten Datenbits erkennbar. Im unteren Bereich ist die LO Frequenz dargestellt (Diese wurde aus dem protokollierten Carrier FCW berechnet). Man kann sehr gut erkennen, wie der Regelkreis dem künstlich eingestellten Frequenzdrift von \SI{10}{\hertz\per\second} folgt. -\FR{Versuch_Tracking_IQ_Plot.png} zeigt die Ausgangssignale des I und Q Prompt Korrelators zusammen in einem Konstellationsdiagramm. Auch hier sind deutlich die Gruppierung um die beiden BPSK Symbole zu erkennen. +\FR{Versuch_Tracking_IQ_Plot.png} zeigt die Ausgangssignale des I und Q Prompt Korrelators zusammen in einem Konstellationsdiagramm. Auch hier ist deutlich die Gruppierung um die beiden BPSK Symbole zu erkennen. \FGimg[Tracking Loop Simulationsergebnisse]{Versuch_Tracking_Plot_Results.png}{Im oberen Teil ist das demodulierte Signal zu sehen, welches am Ausgang des I Prompt Korrelators anliegt. Unten ist die vom Trackingloop geregelte LO Frequenz zu sehen. Es ist gut erkennbar, dass der Regelkreis den langsamen Drift von \SI{10}{\hertz\per\second} nachregelt.}{11cm} diff --git a/5_Ergebnisse/90_Fazit_Ausblick.tex b/5_Ergebnisse/90_Fazit_Ausblick.tex index e5f746f..26f6fc0 100644 --- a/5_Ergebnisse/90_Fazit_Ausblick.tex +++ b/5_Ergebnisse/90_Fazit_Ausblick.tex @@ -1,5 +1,5 @@ \section{Fazit} -In dieser Arbeit wurde der Grundstein für einen funktionsfähigen Software Defined GPS Receiver auf dem \dscubesat gelegt. Obwohl noch nicht alle Meilensteine erreicht wurden, konnte gezeigt werden, dass das in der Entwurfsphase festgelegte Konzept geeignet ist um GPS Daten zu empfangen. +In dieser Arbeit wurde der Grundstein für einen funktionsfähigen Software Defined GPS Receiver auf dem \dscubesat gelegt. Obwohl noch nicht alle Meilensteine erreicht wurden, konnte gezeigt werden, dass das in der Entwurfsphase festgelegte Konzept geeignet ist um GPS Daten zu demodulieren. In den Grundlagen wurden Näherungen für die erwartete Dopplerverschiebung des GPS Signals für einen Satelliten in einer Umlaufbahn ermittelt. In der Matlab Simulation wurde verifiziert, dass der Tracking Loop auch mit diesen, im Vergleich zu einem Empfänger auf der Erde, erhöhten Anforderungen das GPS Signal erfolgreich tracken kann. diff --git a/FrontBackMatter/abstract.tex b/FrontBackMatter/abstract.tex index fd38427..8dbd8c0 100644 --- a/FrontBackMatter/abstract.tex +++ b/FrontBackMatter/abstract.tex @@ -1,12 +1,22 @@ %******************************************************* % Abstract %******************************************************* -\chapter*{Abstract} +\chapter*{Abstract (de)} +Diese Arbeit dokumentiert den Entwurf und die Implementierung eines Software-Defined GPS Empfängers, der auf dem \dscubesat integriert wird. Die Implementierung nutzt sowohl den FPGA als auch den DSP des COM Subsystems des Satelliten. Auch wenn noch nicht alle Teilaufgaben erreicht wurden, konnten mehrere wichtige Meilensteine erreicht werden. Durch mehrere Experimente wurde die Umsetzbarkeit des Entwurfs und der Implementierung gezeigt. -This thesis documents the design and the implementation of a software-defined GPS receiver meant to be integrated on the \dscubesat. The implementation makes use of the FPGA and DSP onboard the satellite's COM subsystem. Although not every task could be completed, several important milestones were reached and the feasability of the concept and implementation is proven with several experiments. +Es wurde eine Näherungsformel für die maximal auftretende Dopplerverschiebung des GPS Signals für Low-Earth-Orbit Satelliten hergeleitet. Die Funktion des entworfenen Empfängers unter diesen Bedingungen wurde mit einer Matlab Simulink Simulation verifiziert. -An approximate value for the maximum dopplershift of the GPS signal for Low-Earth-Orbit Satellites is derived. The function of the receiver under these conditions is verified with a Matlab Simulink simulation. +Ein Linux Kernel Treiber wurde für die Schnittstelle zum GPS Frontend entwickelt. Die GPS Tracking Loops wurden in programmierbarer Hardware im FPGA und in Software in einem Softcore Prozessor realisiert. Die Funktion der Schnittstelle wurde mit einem Experiment mit dem Flugmodell des \dscubesat demonstriert. Im Zuge dieses Experiments wurde auch zum ersten Mal der vollständige Signalpfad von Antenne bis zum DSP verifiziert. -A Linux Kernel driver is developed to interface with the GPS Frontend chip. The function of the interface is then demonstrated with an experiment with the flight model of the \dscubesat. At the same time it was shown for the first time, that the passive antennas together with the GPS frontend deliver a signal that is suitable for position calculation. +Eine \gls{RTL} Simulation wurde durchgeführt um die Funktion, der im FPGA implementierten Tracking Loop Kanäle zu verifizieren. Weiterhin wurde damit die Performance der implementierten Festkommaalgorithmen gemessen. Mit der derzeitigen Implementierung unterstützt der GPS Empfänger bis zu 10 Kanäle (mindestens 4 Kanäle sind für eine Positionsbestimmung nötig). Mit kleinen Änderungen ließen sich auch mehr Kanäle realisieren, da die maximale Anzahl vor allem durch die Rechenleistung des Softcore Prozessors begrenzt ist. -A \gls{RTL} simulation is used to verify the function of the tracking loop channels that were implemented in the FPGA. Additionally, the performance of the designed fixed point algorithms was measured. With the current implementation the GPS receiver supports up to 10 channels. The maximum number of channels is mostly dependent on the computational power of the softcore processor. Hence, with few changes, more channels can easily be realized. + +\chapter*{Abstract (en)} + +This thesis documents the design and the implementation of a software-defined GPS receiver meant to be integrated on the \dscubesat. The implementation makes use of both FPGA and DSP onboard the satellite's COM subsystem. Although not every task could be completed during the course of this thesis, several important milestones were reached and by means of several experiments, the feasibility of the concept and implementation has been proven. + +An approximate value for the maximum Doppler shift of the GPS signal for Low-Earth-Orbit Satellites has been derived. The function of the receiver under these conditions were verified with a Matlab Simulink simulation. + +A Linux Kernel driver was developed to interface with the GPS Frontend chip and tracking loops were realized in programmable hardware and in software in a Softcore CPU. The function of the interface has been demonstrated using the flight model of the \dscubesat. As part of the experiments the function of the entire signal path from antenna to the DSP was verified for the first time. + +A \gls{RTL} simulation was used to verify the function of the tracking loop channels that were implemented in the FPGA. Additionally, the performance of the designed fixed point algorithms has been measured. The current implementation the GPS receiver supports up to 10 channels, which would be sufficient to acquire a position fix. With few changes however, more channels can easily be realized since the maximum number of channels is mostly dependent on the computational power of the softcore processor. diff --git a/main.tex b/main.tex index 502bad5..33412ea 100644 --- a/main.tex +++ b/main.tex @@ -2,13 +2,14 @@ \documentclass[ % Replace twoside with oneside if you are printing your thesis on a single side % of the paper, or for viewing on screen. - oneside, - %twoside, TODO anpassen + %oneside, + twoside, %TODO anpassen 11pt, a4paper, footinclude=true, headinclude=true, cleardoublepage=empty, - parskip=half%, + parskip=half, + BCOR=15mm %DIV=40 ]{scrbook} @@ -32,8 +33,9 @@ \usepackage[T1]{fontenc} \usepackage{csquotes} % has to come after inputenc \usepackage{textcomp} % fixes warning when using \micro in a siunitx unit -\usepackage[binary-units=true]{siunitx} % Einheiten in Formeln +\usepackage[binary-units=true, decimalsymbol=comma]{siunitx} % Einheiten in Formeln \usepackage{enumitem} % allows some customization of lists, e.g. vertical spacing +\usepackage{xspace} % fixes spacing after "newcommand" textmacros. \usepackage[nolist,style=clong]{glossaries} \usepackage{graphicx} % To insert figures - for PDF-LaTeX: .pdf and .png (.jpg possible, but should be avoided) diff --git a/thesis.bib b/thesis.bib index 0729fe6..786fc1b 100644 --- a/thesis.bib +++ b/thesis.bib @@ -352,6 +352,8 @@ @misc{SwiftNavPiksi } @misc{gnss-sdr, + author={Carles Fernandez-Prades and GNSS-SDR Contributors}, + publisher={Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)}, title={GNSS-SDR - Open Source GPS Receiver Framework}, url={http://gnss-sdr.org} }