diff options
| -rw-r--r-- | doc/thesis/chapters/implementation.tex | 16 | ||||
| -rw-r--r-- | doc/thesis/chapters/theory.tex | 52 | ||||
| -rw-r--r-- | doc/thesis/tex/docstyle.sty | 20 | ||||
| -rw-r--r-- | src/gr-fadingui/python/netsink.py | 2 |
4 files changed, 46 insertions, 44 deletions
diff --git a/doc/thesis/chapters/implementation.tex b/doc/thesis/chapters/implementation.tex index 9a20d24..191feba 100644 --- a/doc/thesis/chapters/implementation.tex +++ b/doc/thesis/chapters/implementation.tex @@ -4,15 +4,23 @@ \section{Overview} -First of all the tools which were used in this theses are interdused; software and hardware. Then the sender and receiver chain are explained in detail and how they are implemented. This both chains are the same for the simulation itself and the hardware implementation. Also the channel in details are explained which is inportent for the simulation to illustrate the multipath fading effect. After some measurements are tried, with the help of the bit error rate, to compare it with the simulation. +First of all the tools that were used in this project are introduced. Then it is explained how the sender and receiver chains are implemented. Except for the channel, there are no differences in the signal processing chains between the simulated and real flowgraphs (with hardware). Following are some channel simulations and measurements of the bit error rate (BER). Finally, the issues and the degree of completeness of our current implementation is discussed. \section{Software Stack} \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 software defined radios (SDR). GR is composed of two parts: a C\texttt{++} library with Python bindings to write signal processing code, and GNU Radio Companion (GRC), a graphical user interface to more easily construct signal processing chains by representing 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}. 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}. +\begin{figure} + \caption{ + A GNU Radio flow graph. + \label{fig:flowgraph} + } +\end{figure} + {\newcommand{\placeholder}[1]{\textit{\(\langle\)\,\textrm{#1}\,\(\rangle\)}} \begin{lstlisting}[ language = python, escapechar = {`}, float, @@ -43,7 +51,7 @@ To construct a graphical interface for a demonstration platform the Dear IMGUI ( The DPG GUI communicates with the GR flow graphs using the IP/UDP protocol. This decision to separate the project into two parts that communicate over the IP network was made because it is not very easy to extend the graphical interface of GRC without interfering with the sophisticated multi-threaded architecture of GR. Furthermore, this allows to have multiple correctly configure flow graph on disk and to choose which one to run and display on the graphical interface, instead of having a single flow graph whose parameters need to be changed each time. -Also as a side effect, in theory this setup allows to have one computer running the graphical interface, and another remote machine running just the flow graph. +As a side effect, in theory this setup allows to have one computer running the graphical interface, and another remote machine running just the flow graph. \section{Hardware} @@ -66,6 +74,7 @@ Also as a side effect, in theory this setup allows to have one computer running As receivers and transmitter devices for the SDR setup two USRP B210 devices from Ettus Research were used. Some technical specifications are shown in \tabref{tab:usrp-specs}. GR provides off the shelf blocks that interface with the official API provided from Ettus Research. \section{Sender chain} + \subsection{Data frame} \begin{figure} @@ -133,7 +142,7 @@ The relevant observation to make in \eqref{eqn:xc-oop-copy} that since \(R_{aa}\ \subsection{Implementing fine phase and frequency correction} -To implement in GR what was discussed in \S\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 \S\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: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. 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). @@ -386,7 +395,6 @@ For generating the Byte error rate it is focus on byte-blocks of a specific leng self.send(self.encode([trueber, ber_max, ber_avg])) #Send the valuse to the GUI return len(inp) - \end{lstlisting} diff --git a/doc/thesis/chapters/theory.tex b/doc/thesis/chapters/theory.tex index 3262751..a9bea7d 100644 --- a/doc/thesis/chapters/theory.tex +++ b/doc/thesis/chapters/theory.tex @@ -282,7 +282,6 @@ is different from \eqref{eqn:multipath-impulse-response} consider again the plot From a signal processing perspective \eqref{eqn:discrete-multipath-impulse-response} can be interpreted as a simple tapped delay line, schematically drawn in \figref{fig:tapped-delay-line}, which confirms that the presented mathematical model is indeed a FIR filter. Simple multipath channels can be simulated with just a few lines of code, for example the data for the static fading channel in \figref{fig:multipath-frequency-response-plots} is generated in just four lines of Python. The difficulty of fading channels in practice lies in the estimation of the constantly changing parameters \(c_k(t)\) and \(\tau_k(t)\). - \subsection{Simulating multipath CIR with FIR filters} \label{sec:fractional-delay} % TODO quelle: http://users.spa.aalto.fi/vpv/publications/vesan_vaitos/ch3_pt1_fir.pdf @@ -324,17 +323,10 @@ where the odd order of the filter \(N\) should satisfy the condition for a minimal error in the approximation. It is worth mentioning that it is also possible to build FIR filters of even length with a different condition, or that do not satisfy \eqref{eqn:fractional-fir-length}, in which cases more consideration is required. An example of a fractional delay FIR filter is shown in \figref{fig:fractional-delay-sinc-plot}. \subsection{Statistical model} \label{sec:statistical-model} -%TODO: Quelle? -Because as mentioned earlier it is difficult to estimate the time-dependent parameters of \(h_l(m)\) in many cases it is easier to model the components of the CIR as stochastic processes, thus greatly reducing the number of parameters. This is especially effective for channels that are constantly changing, because by the central limit theorem the cumulative effect of many small changes tends to a normal distribution. - -Recall that \(h_l(m)\) is a function of time because \(c_k\) and \(\tau_k\) change over time. The idea of the statistical model is to replace the cumulative change caused by \(c_k\) and \(\tau_k\) (which are difficult to estimate) by picking the next CIR sample \(h_l(m +1)\) from a \emph{circularly symmetric complex Gaussian distribution}, or concisely written as -\begin{equation} - h_l \sim \mathcal{CN}(0, \sigma^2) -\end{equation} -for some parameter \(\sigma\). Loosely speaking, the distribution needs to be ``circular'' because \(h_l\) is a complex number, which is a ``two dimensional number'', it can however be understood as \(\Re{h_l} \sim \mathcal{N}(0, \sigma^2)\) and \(\Im{h_l} \sim \mathcal{N}(\mu, \sigma^2)\), i.e. having each component being normally distributed. +Because as mentioned earlier it is difficult to estimate the time-dependent parameters of \(h_l(m)\) in many cases it is easier to model the components of the CIR as stochastic processes, thus greatly reducing the number of parameters \cite{Messier,Mathis}. This is especially effective for channels that are constantly changing, because by the central limit theorem the cumulative effect of many small changes tends to a normal distribution. -%TODO : Picture of gaussian distribution +\skelpar[3]{Assumptions of the model} \begin{subequations} \begin{align} R_{l} (k) &= \E{h_l(m) h_l^*(m+k)}, \\ @@ -342,6 +334,27 @@ for some parameter \(\sigma\). Loosely speaking, the distribution needs to be `` \end{align} \end{subequations} +\paragraph{NLOS case} + +Recall that \(h(\tau, t)\) is a function of time because \(c_k\) and \(\tau_k\) change over time. The idea of the statistical model is to replace the cumulative change caused by \(c_k\) and \(\tau_k\) (which are difficult to estimate) with a single random variable \(f\). This is done as follows. + +Multipath fading is a form of multiplicative noise, as mathematically confirmed by the fact that convolving a complex baseband signal \(e^{j\omega_c t}\) with the fading CIR \(h(\tau, t)\) gives +\begin{equation} + e^{j\omega_c \tau} * h(t, \tau) = \sum_k c_k(t) e^{j\omega_c(\tau - \tau_k(t))} + = e^{j\omega_c \tau} \sum_k c_k(t) e^{-j\omega_c \tau_k(t)} + = e^{j\omega_c \tau} \cdot f(t). +\end{equation} +If there is no line of sight (NLOS), it is reasonable to assume that all path have more or less the same attenuation, i.e. all \(c_k\) are the same. Another reasonable assumption in this case is that all paths are equally likely to be taken, or in other words the delays \(-\omega_c \tau_k\) can be replaced with random variables \(\vartheta_k\) that are uniformly distributed on \([0,2\pi)\) \cite{Hoher2013,Mathis}. Finally, assuming that there are infinitely many paths the random variable for the multiplicative fading noise becomes +\begin{equation} + f = \lim_{N\rightarrow\infty} \frac{1}{\sqrt{N}} + \sum_{k=1}^{N} e^{j \vartheta_k }, +\end{equation} +where the \(c_k\) where omitted, since they are assumed to be all equal. The factor \(1/\sqrt{N}\) is introduced such that \(\expectation \{|f|^2\} = 1\). It then can be shown that the probability density function of \(|f|\) is +\begin{equation} + p(a)= 2a e^{-a^2}, \text{ or } |f| \sim \mathcal{R}, +\end{equation} +i.e. the amplitude of \(f\) is \emph{Raileigh} distributed. + \begin{figure} \centering \begin{subfigure}{.45\linewidth} @@ -360,25 +373,6 @@ for some parameter \(\sigma\). Loosely speaking, the distribution needs to be `` \end{figure} \skelpar[4]{Explain This formulars} -%TODO :Maby some correction on the descreption, because mentionet earlyer Is f(t) =(c k (t) parameters)? -\paragraph{NLOS case} - - In the case of the Rayleight distribution the signal has no line of sight. It can be looked at the Fading process \cite{Hoher2013} with the help of the amplitude \(a(t)\) in time and the associated phase \(\Theta(t) \in[\,0,2\pi)\,\). To find the probability function of the amplitutes it can be looked at the fading possess as a superimposition of those infinity distribute signals: -\begin{equation} \label{eqn:rayleight fading} - f(t) = \lim_{N\rightarrow\infty} \frac{1}{\sqrt{N}}\sum_{n=1}^{N} e^{j(\Theta +2\pi jf t)}. - \end{equation} -whish are nominate with the factor \(\frac{1}{\sqrt{N}}\) so that the power probability is \(\E{|f(t)|²}=1\) as mentioned earlier. From the fact that we are looking at the complex basiband and this processes is an independent one with a gaussian distributions it can be said that \(\E{f(t)}=0\) and so the propabiliti of the amplitude is: - -\begin{equation} \label{eqn:rayleight_fading_probabilety_dencety} - p(a)= 2a\exp{{-a}^2} -\end{equation} - -It can also explaint with I- and Q-contribution : -\begin{equation} - \Re{h_l(n)}, \Im{h_l(n)} - \sim \mathcal{N} \left(0, \frac{1}{2} \E{|h_l(n)|^2} \right) -\end{equation} -\skelpar[4] \paragraph{LOS case} diff --git a/doc/thesis/tex/docstyle.sty b/doc/thesis/tex/docstyle.sty index 5222748..3a009ce 100644 --- a/doc/thesis/tex/docstyle.sty +++ b/doc/thesis/tex/docstyle.sty @@ -8,16 +8,16 @@ \ProcessOptions\relax %% Page Margins (done with KOMA) -% \PassOptionsToPackage{geometry}{ -% a4paper, showframe -% } -% \RequirePackage{geometry} -% \AfterCalculatingTypearea{% -% \geometry{% -% inner = 1cm, outer = 1cm, includeheadfoot -% top = 3cm, bottom = 3cm -% } -% } +\PassOptionsToPackage{geometry}{ + a4paper, +} +\RequirePackage{geometry} +\AfterCalculatingTypearea{% + \geometry{% + inner = 3cm, outer = 2.5cm, includeheadfoot, + top = 2cm, bottom = 2cm + } +} %% Need colors \RequirePackage{xcolor} diff --git a/src/gr-fadingui/python/netsink.py b/src/gr-fadingui/python/netsink.py index 8851fe9..932eb0b 100644 --- a/src/gr-fadingui/python/netsink.py +++ b/src/gr-fadingui/python/netsink.py @@ -71,7 +71,7 @@ class netsink(gr.sync_block): try: return self.socket.sendto(data, self.srv) except socket.error as err: - log.warn(f"No data was sent: {err}") + log.debug(f"No data was sent: {err}") return 0 def encode(self, data): |