diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/thesis/chapters/conclusions.tex | 19 | ||||
| -rw-r--r-- | doc/thesis/chapters/implementation.tex | 37 |
2 files changed, 23 insertions, 33 deletions
diff --git a/doc/thesis/chapters/conclusions.tex b/doc/thesis/chapters/conclusions.tex index 8153616..f9a66a2 100644 --- a/doc/thesis/chapters/conclusions.tex +++ b/doc/thesis/chapters/conclusions.tex @@ -4,14 +4,9 @@ \section{Results} -The goal to build a functional demonstrator had been achieved, unfortunately not all of the originally planned features were implemented. A stable wireless link using QPSK modulation that computes the BER was developed. +The goal to build a functional demonstrator has been only partially achieved, unfortunately not all of the originally planned features could be implemented. A stable wireless link using QPSK modulation that computes the BER was developed. Because of the issue discussed in section \ref{sec:access-code-issue}, the QAM variant cannot compute the empirical BER. -Some different typ of multiple fading model were tested and illustrated. -Two different Models for the simulation options are built. One discrete time model whish is basically a FIR filter in the channel, the other with a statistical model which is based on a GR block. - -One other file to implement the hardware with. Unfortunately it was not possible to measure those in a meaningful way. For that a least square approximation could be used as described in the further steps. An other difficulty is to reproduce the same effect in a simulation compare with the hardware, because of al the side effect of the environment, which cant be predicted in a simulation. - -% TODO Mention QAM16 +For both modulation schemes samples from multiple different conditions were collected and analyzed, albeit some assessments could only be conducted when QPSK was used. \section{Future Work} @@ -21,15 +16,13 @@ One other file to implement the hardware with. Unfortunately it was not possible A missing feature in this work is an automated collection of the BER data, which would allow to more easily to observe and measure the influence of each parameters in the fading channel model. -\subsection{Improvements of GUI frontend} - -The current GUI prototype built with DearPyGUI has some issues, the most critical begin a single-threaded application. The interprocess communication (with GR's flow graphs) should be on a separate thread from the graphics. The problem is not noticeable as long as the flow graphs in the background keep sending data, but as soon as the UDP/IP data stream stops the timeout of the socket interface causes the interface to run at less that 20 frames per second. +\subsection{Improvements in the GUI front-end} -In addition to fixing the aforementioned issue, a very important feature that is currently missing is the ability to change the fading parameters in real time from within the GUI. Dear PyGUI offers many graphical elements that could be used to control the parameters, however a new GR block would need to be created to propagate the updated values into the flow graph. +In addition to fixing the issue discussed in section \ref{sec:gui-issue-single-threaded}, a very important feature that is currently missing is the ability to change the fading parameters in real time from within the GUI. Dear PyGUI offers many graphical elements that could be used to control the parameters, however a new GR block would need to be created to propagate the updated values into the flow graph. -\subsection{Channel parameters estimation with Pilot Symbols} +\subsection{Channel parameters estimation with PSAM} -An interesting continuation of this work could be to regularly interpolate some so called pilot symbols in the modulated data stream. Briefly, the pilot symbol assisted modulation (PSAM) technique consists of periodically inserting informationless (known) symbols in the data stream, which are then used to estimate the fading parameters of the communication channel. More details are presented in \cite{Xiaoyi1999} (and its references) from which the illustrations in \figref{fig:psam} were taken. +An interesting continuation of this work could be to regularly interpolate some so called pilot symbols in the modulated data stream. In short, the pilot symbol assisted modulation (PSAM) technique consists of periodically inserting informationless (known) symbols in the data stream, which can then be used to estimate the fading parameters of the communication channel. More details are presented in \cite{Xiaoyi1999} (and its references) from which the illustrations in \figref{fig:psam} were taken. \begin{figure} \centering diff --git a/doc/thesis/chapters/implementation.tex b/doc/thesis/chapters/implementation.tex index 0f92f29..b418927 100644 --- a/doc/thesis/chapters/implementation.tex +++ b/doc/thesis/chapters/implementation.tex @@ -12,7 +12,7 @@ The rest of the chapter is structured as follows. First the tools used in this p \subsection{GNU Radio} -For both the signal processing and the simulations the GNU Radio (GR) toolkit was chosen, as it already had drivers for the USRP hardware. GR is an open-source free software framework that can be used to build signal processing chains and SDRs. GR is composed of two parts: a C\texttt{++} library with Python bindings to write signal processing code, and GNU Radio Companion (GRC). GRC is a graphical user interface made to more easily construct signal processing chains. Signal processing algorithms as ``blocks'' that are chained together with arrows, essentially drawing a diagram called ``flow graph''. An example of a flow graph is shown in \figref{fig:flowgraph}. +For both the signal processing and the simulations the GNU Radio (GR) toolkit was chosen, as it already had drivers for the USRP hardware. GR is an open-source free software framework that can be used to build signal processing chains and SDRs. GR is composed of two parts: a C\texttt{++} library with Python bindings to write signal processing code, and GNU Radio Companion (GRC). GRC is a graphical user interface made to more easily construct signal processing chains. Signal processing algorithms as ``blocks'' that are chained together with arrows, essentially drawing a diagram called ``flow graph''. An example of a flow graph can be seen in \figref{fig:sync-lock-flowgraph}. Internally GR works by keeping multiple memory buffers of samples, that are passed as pointers to the signal processing algorithms' ``work functions''. When the signal processing is complete, the output buffer of one block is given to the next block as input according to how they were connected in the flow graph. The structure of a block is shown in the Python listing \ref{lst:gr-block-py}. To improve performance GR creates a thread for each work function to parallelize the workload of the concurrently running signal processing blocks. For more details see the GNU Radio Wiki and User Manual in \cite{GRWiki}. @@ -97,9 +97,11 @@ GR provides a constellation modulator block, that already implements several sta \section{Receiver chain} \begin{figure} + \centering + \includegraphics[width = .95\linewidth]{figures/screenshots/sync_lock} \caption{ - Cutout GNU Radio flow graph used to synchronize, equalize and lock the envelope. - \label{fig:flowgraph} + Part of the GNU Radio flow graph for the QPSK modulated link (with hardware). The shown blocks are used to synchronize, equalize and lock the envelope. + \label{fig:sync-lock-flowgraph} } \end{figure} @@ -149,7 +151,7 @@ The relevant observation to make in \eqref{eqn:xc-oop-copy} that since \(R_{aa}\ \subsubsection{Implementing fine phase and frequency correction} \label{sec:implement-phasecorr} %TODO: Figure -To implement in GR what was discussed in section \ref{sec:phasecorr} two blocks shown in \figref{fig:phasecorr-blocks} were used: a correlator estimator block, and a custom block. The former essentially implements the first 3 of the steps discussed at the end of section \ref{sec:phasecorr}. The correlator estimator block is given a sequence of samples, and when the cross correlation between them and the input stream is higher than a certain threshold (90\% of the amplitude of a perfect autocorrelation), it produces a ``tag'' in the output stream, that contains the phase estimate. +To implement in GR what was discussed in section \ref{sec:phasecorr} two blocks shown in \figref{fig:sync-lock-flowgraph} were used: a correlator estimator block, and a custom block. The former essentially implements the first 3 of the steps discussed at the end of section \ref{sec:phasecorr}. The correlator estimator block is given a sequence of samples, and when the cross correlation between them and the input stream is higher than a certain threshold (90\% of the amplitude of a perfect autocorrelation), it produces a ``tag'' in the output stream, that contains the phase estimate. Tags are GR's way of working with metadata that is attached to a sample. Internally tags are just polymorphic data structures containing a number indicating the absolute offset (in samples), and a pair of arbitrary values called ``key'' and ``value''. Tags are passed on from one block to the next like sample streams (unless the block specifies to do otherwise). @@ -414,21 +416,23 @@ For generating the bit error rate a bit stream with a specific length is compare \section{Issues in the current implementation} -\subsection{Non modulated access codes} +\subsection{Non modulated access codes} \label{sec:access-code-issue} Currently, as described in section \ref{sec:data-frame}, the access codes are put as bytes in front of the frame in the \(k\)-byte preamble. For this to work, the access code bytes must still have a good autocorrelation function after being modulated into symbols using the chosen modulation scheme. This works well with QPSK, because the constellation is quite simple and the length of the sequence is only halved after the modulation (since QPKS has 2 bits per symbol). Thus, in the QPSK flow graph the longest known Barker sequence \texttt{0x1f35} (13 bits, left padded with zeros) is sufficient (\(\approx 7\) symbols). -With QAM however, the complexity of the constellation and the higher number of bits per symbol makes it increasingly difficult to find binary sequences retain a good autocorrelation function after being modulated. A better solution would be to use for example a \emph{constant amplitude zero autocorrelation waveform} (CAZAC) of length \(N\), which is computed with +With QAM however, the complexity of the constellation and the higher number of bits per symbol makes it increasingly difficult to find binary sequences that retain a good autocorrelation after being modulated. A better solution for example would be to use a \emph{constant amplitude zero autocorrelation waveform} (CAZAC) of length \(N\), which is computed with \begin{equation} u_k = \exp\left(j\frac{M\pi K}{N}\right) \text{ where } K = \begin{cases} k^2 & \text{when } N \text{ is even} \\ - k(k+1) & \text{when } N \text{ is odd} - \end{cases}, + k(k+1) & \text{when } N \text{ is odd}, + \end{cases} \end{equation} -and \(M\) is relatively prime to \(N\) \cite{Chu1972}. CAZAC waveforms are ideal because they have a Dirac delta as autocorrelation \cite{Chu1972}, i.e. \(R_{uu}(\tau) = \delta(\tau)\). Though unfortunately, since these complex values are not on any constellation point they break some assumptions of the polyphase clock sync and the LMD DD equalizer (but not CMA). Thus, to use CAZAC waveforms, the transmitter needs to put them in front of the modulated symbols (for example using a correctly parametrized stream mux block in GR), and the receiver would need to synchronize with the sequence before the clock recovery or equalization. The latter is especially problematic because then it is no longer possible to identify the peak by comparing the autocorrelation value to a fixed threshold as done in section \ref{sec:implement-phasecorr}. +and \(M\) is relatively prime to \(N\) \cite{Chu1972}. CAZAC waveforms are ideal because they have a Dirac delta as autocorrelation \cite{Chu1972}, i.e. \(R_{uu}(\tau) = \delta(\tau)\). Unfortunately, since these complex values are not on any constellation point they break some assumptions of the polyphase clock sync and the LMD DD equalizer (but not CMA, which unfortunately cannot be used for QAM). Thus, to use CAZAC waveforms, the transmitter needs to put them in front of the modulated symbols (for example using a correctly parametrized Stream MUX block in GR), and the receiver would need to synchronize with the sequence before the clock recovery or equalization. The latter is especially problematic because then it is no longer possible to identify the peak by comparing the autocorrelation value to a fixed threshold as done in section \ref{sec:implement-phasecorr}. Because of the aforementioned reasons, in its current state the QAM flow graph is unable to lock and decode any signals. + +\subsection{Single threaded GUI application} \label{sec:gui-issue-single-threaded} -\subsection{Single threaded GUI application} +The current GUI prototype built with DearPyGUI has some issues, the most critical begin that it is a single-threaded program. The interprocess communications (with GR's flow graphs) should be on a separate thread from the graphics, what is currently not the case. The problem is not noticeable as long as the flow graphs in the background keep sending data, but as soon as the UDP/IP data stream stops, the timeout of the socket interface causes the interface to run at less than 20 frames per second. \subsection{Incomplete parts} @@ -438,13 +442,6 @@ Unfortunately the two SDR need an external clock generator. For that a Rubidium %TODO: Right squenz? Without those only the amplitudes could be seen in the plots. -\subsection{GUI Parameter change} -%TODO: conclusion - -As in \ref{sec:GUI} described the GUI was implemented, but unfortunately the parts where the parameter could be changed, will showing the current simulation isn't possibl like the noise voltage of the channel or the bandwidth from the Polyphase Clock , the Gain of the Equalizer aren't implemented yet. Actually everything which needs a responds from the interfaces to the GR. - -The second part which is missing is to be able to change the timing plot for the different scattering plots. - % TODO : Picture of the setup % TODO: Plots from the Hardware @@ -469,7 +466,7 @@ The second part which is missing is to be able to change the timing plot for the \centering \input{figures/tikz/qpsk-simulations-dynamic} \caption{ - Simulations with a dynamic fading channel model using PDP values of the Extended Typical Urban model (ETU) of the ETSI standard normative Annex B.2 in \cite{ETSI}. The color gradient represents progression in time. + Simulations with QPSK modulation and a dynamic fading channel model that uses PDP values of the Extended Typical Urban model (ETU) from the ETSI standard normative Annex B.2 in \cite{ETSI}. The PDP values from the standard are reported in \tabref{tab:etsi-tap-values}. The color gradient represents progression in time: yellow samples are more recent than the blue samples. \label{fig:qpsk-simulations-dynamic} } \end{figure} @@ -478,14 +475,14 @@ The second part which is missing is to be able to change the timing plot for the \centering \input{figures/tikz/qam-simulations-dynamic} \caption{ - TODO QAM simulation + Simulation using the same channel parameters as in \figref{fig:qpsk-simulations-dynamic}, but with a 16-ary QAM modulation scheme. Unfortunately, because of the issue discussed in section \ref{sec:access-code-issue} the receiver cannot lock and decode the envelope. } \end{figure} \begin{figure} \centering \input{figures/tikz/hardware} \caption{ - TODO QPSK hardware + HARDWARE } \end{figure} \newpage |