aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorsara <sara.halter@gmx.ch>2021-12-21 20:47:50 +0100
committersara <sara.halter@gmx.ch>2021-12-21 20:47:50 +0100
commit99e769ebc5ffd23f521a0b2dfcc0fe55029475f2 (patch)
tree9bd4ef6f268e62b14f449a654475bbc86add1127
parentDoku changes (diff)
downloadFading-99e769ebc5ffd23f521a0b2dfcc0fe55029475f2.tar.gz
Fading-99e769ebc5ffd23f521a0b2dfcc0fe55029475f2.zip
some littel changes
-rw-r--r--doc/thesis/chapters/conclusions.tex10
-rw-r--r--doc/thesis/chapters/implementation.tex25
2 files changed, 19 insertions, 16 deletions
diff --git a/doc/thesis/chapters/conclusions.tex b/doc/thesis/chapters/conclusions.tex
index 8cb3a5d..1343d3b 100644
--- a/doc/thesis/chapters/conclusions.tex
+++ b/doc/thesis/chapters/conclusions.tex
@@ -7,7 +7,7 @@
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.
Some different typ of multiple fading model were tested and illustrated.
-Two different Models for the simulation options are build. One discrete time model whish is basicly a FIR filter in the channel, the other with a statistical model which is based on a GR block.
+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.
@@ -23,7 +23,7 @@ An interesting continuation of the current work could be to automate the collect
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.
-In addition to fixing the aforementioned issue, a very important missing 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 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.
\subsection{Channel parameters estimation with Pilot Symbols}
@@ -31,11 +31,11 @@ In addition to fixing the aforementioned issue, a very important missing feature
\section{Closing words}
-\section{Acknowledgements}
+\section{Acknowledgments}
-We would like to thank everyone who took the time to help us. Specially Michel Nyffenegger, Nicola Ramagnano for his explanations, with the GNU Radio tool,
-Marcel Kluser, who has provided the equipment, Prof. Dr. Heinz Mathis for the opportunity and to our fiends whose supported us in different ways.
+We would like to thank everyone who took the time to help us. Specially Michel Nyffenegger, Nicola Ramagnano for their explanations, with the GNU Radio tool,
+Marcel Kluser, who has provided the equipment, Prof. Dr. Heinz Mathis for the opportunity and to our friends whose supported us in different ways.
diff --git a/doc/thesis/chapters/implementation.tex b/doc/thesis/chapters/implementation.tex
index 1ecfd9d..b73b10a 100644
--- a/doc/thesis/chapters/implementation.tex
+++ b/doc/thesis/chapters/implementation.tex
@@ -313,13 +313,13 @@ When nothing else is mentioned, the number of FIR-filter taps used is eight.
\subsubsection{Issues}
-A difficulty was to check the correctness of the statistical models, if there is noise in the channel from the fading effect. Especially when the Doppler frequency is included. This was difficult to recreate, when the amplitude and phase parameter in which the amplitude and the phase shift can be seen exactly.
-To have some indication to verified the plot, mainly whether the movement could be correct a little Matlab model was used with the same values for the different distributions.
+A difficulty was to check the correctness of the statistical models, if there is noise in the channel from the fading effect. Especially when the Doppler frequency is included. This was difficult to recreate, when the amplitude and phase parameter are not in a special state in which the amplitude and the phase shift can be seen exactly.
+To have some indication to verify the plot, mainly whether the movement could be correct, a little Matlab model was used with the same values for the different distributions. With this, the model could be verified.
%TODO: Other Plots?
\subsubsection{Real value example}
-In order to obtain a realistic simulation the values for multipath fading propagation condition for a Extended Typical Urban (ETU) model, from the ETSI (European Telecommunication Standards Institute), where used\cite{ETSI}, with the values shown in \tabref{tab:etsi-tap-values}. For those the maximum Doppler frequency possibilities are predefined. In the following examples \figref{fig:dynamic-exp-real} either \(\SI{5}{\hertz}\) or \(\SI{70}{\hertz}\) were used, as in \eqref{eq:doppler} \(\SI{16}{\hertz}\) calculated for a walking speed of \(\SI{2}{\meter\per\second}\). Those predefined values had a speed of
+In order to obtain a realistic simulation the values for multipath fading propagation condition for a Extended Typical Urban (ETU) model, from the ETSI (European Telecommunication Standards Institute) were used\cite{ETSI}, with the values shown in \tabref{tab:etsi-tap-values}. For those the maximum Doppler frequency possibilities are predefined. In the following examples \figref{fig:dynamic-exp-real} either \(\SI{5}{\hertz}\) or \(\SI{70}{\hertz}\) were used, opposed to the in \eqref{eq:doppler} calculated value for a walking speed of \(\SI{2}{\meter\per\second}\), where the Doppler frequency is \(\SI{16}{\hertz}\). Those predefined values correspond to a speed of
\begin{equation}
v = \frac{\Delta f}{f_c}\cdot c_0 = \frac{\SI{5}{\hertz}}{\SI{2.4}{\giga\hertz}}\cdot \SI{3e8}{\meter\per\second}= \SI{0.625}{\meter\per\second}
\end{equation}
@@ -328,7 +328,7 @@ and
v = \frac{\Delta f}{f_c}\cdot c_0 = \frac{\SI{70}{\hertz}}{\SI{2.4}{\giga\hertz}}\cdot \SI{3e8}{\meter\per\second}= \SI{8.75}{\meter\per\second}
\end{equation}.
-The numbers of tags used in this case are similar to the number of given values.
+The numbers of tags used in this case are the number of given values.
\skelpar[5]{
More simulation plots. Beschreiben.
}
@@ -372,10 +372,12 @@ The BER in an indore enviroment, for example the lab is about
\subsection{Empirical BER} \label{sec:ber}
To find out how accurate the simulations are comparer with a simulation of the fadinng effect and tested measurements, the byte error rate of the system is calculated. This is done with the help of a user specified \(k\)-byte test frame in the beginning of each vector. Implemented according to the code in \ref{lst:ber-work}. Every bit is compared with the test vector at the beginning before the modulation and demodulation part.
-Because of the fact that the test vector has some random bit at the end the bit error rate has always a value on average 32, even when its perfect match. So to avoid high numbers this value is subtracted and only on focused on the positive values.
+Because of the fact that the test vector has some random bit at the end, the bit error rate has always an average value of 32, even if its perfect match. To only focus on the BER of the signal, this value is subtracted.
-The vector which is used as test vector is: \texttt{[0x1f, 0x35, 0x12, 0x48]}, because this numbers are well suited to compare.
-For generating the byte error rate it is focus on byte-blocks of a specific length. So for each of this blocks compared with test vector there is a BER. To make it simpler or better said to avoid mistakes, the last 200 of this individual BER are taken to find an average and the highest value.
+The vector which is used as test vector is: \texttt{[0x1f, 0x35, 0x12, 0x48]}. Because this numbers are well suited to compare.%TODO: verweissen auf erklährung
+
+
+For generating the bit error rate a bit stream with a specific length is comped with the test vector. To make it simpler and to avoid mistakes, the last 200 bits of this individual BER are taken to find an average and the highest value.
\skelpar[5]{
Maybe more
@@ -411,7 +413,7 @@ For generating the byte error rate it is focus on byte-blocks of a specific leng
\subsection{Non modulated access codes}
-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).
+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
\begin{equation}
@@ -421,7 +423,7 @@ With QAM however, the complexity of the constellation and the higher number of b
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)\). 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}.
\subsection{Single threaded GUI application}
@@ -429,11 +431,12 @@ and \(M\) is relatively prime to \(N\) \cite{Chu1972}. CAZAC waveforms are ideal
\subsection{Clock synchronization issues}
-Unfortunately the SDR needs an external clock generator. For that a Rubidium Frequency STd. Model FS725 is used. Better said two of them, to make them more movable and independent, with the clock frequency \SI{10}{\mega\hertz}. Those Rubidiums where used, because the synchronization, dosn`t work as planed in \ref{sec:preforming-implementation}.
+Unfortunately the two SDR need an external clock generator. For that a Rubidium Frequency standard device (Model FS725) is used with the clock frequency of \SI{10}{\mega\hertz}. Two of them are used to make them more movable and independent. Those Rubidiums where needed, because the synchronization does not work as planed in \ref{sec:preforming-implementation}.
%TODO: Right squenz?
-Without those only the amplitudes could be seen in the Plots, with all the noise from the inter-symbol differences.
+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.