severinkaderli/bachelor-thesis
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Correct thesis report

Browse source 
Signed-off-by: Severin Kaderli <severin@kaderli.dev>
This commit is contained in:
Severin Kaderli 2023-01-17 16:15:14 +01:00
parent 2f8b0b524a
commit 1862068f09
Signed by: severinkaderli
GPG key ID: F419F8835B72F0C4
10 changed files with 70 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

24
documentation/thesis/content/02_preliminaries.tex
View file

@ -49,8 +49,8 @@ transmission, the checksum that was transmitted with the message, and the
checksum that is calculated from the received message are compared, if they
don't match, the message contains an error.
For calculating a \gls{crc} value message, which is treated as a binary
polynomial is divided by another value, to so-called generator polynomial. The
For calculating a \gls{crc} value, the message, which is treated as a binary
number, is divided by another value, the so-called generator polynomial. The
remainder of this division is the checksum value. The order of the generator
polynomial defines the bit-length of the resulting checksum \cite{crcGuide}.
@ -72,7 +72,7 @@ Because of these small variations, there are many implementations of
The specific algorithm used in this thesis is the CRC-8-AUTOSAR algorithm with
the polynomial $x^{8} + x^{5} + x^{3} + + x^{2} + x + 1$ and an initial value
of $\mathtt{0xFF}$. This algorithm is created by AUTOSAR \cite{AutosarCrc} and
of $\mathtt{0xFF}$. This algorithm was created by AUTOSAR \cite{AutosarCrc} and
according to the CRC Polynomial Zoo, it can detect up to 4 single bit errors in
a message length of 119 bits \cite{CrcPolynomialZoo}. As our maximum payload
size is 128-bit, this is a fitting CRC algorithm to use.
@ -85,7 +85,7 @@ to implement. \cite{Crc}
Manchester is a simple encoding code for the transmission of binary data. The
data is encoded in the transitions of the signal instead of simple high or low
values. A transition from low to high indicates a 0 and a transition from high
to low indicates a 1 in the original definition by G. E. Thomas, in the
to low indicates a 1 in the original definition by G. E. Thomas. In the
definition from IEEE the values of the transitions are swapped
(see \autoref{figure:manchester_code}).
@ -95,13 +95,13 @@ definition from IEEE the values of the transitions are swapped
\label{figure:manchester_code}
\end{figure}
The advantages of manchester encoding are that there are no prolonged high or
low signals and the original clock signal can be extracted from the signal and
doesn't need to be synchronized between the sender and receiver, on the other
side the bandwidth requirements are doubled as two bits in the signal are
The advantages of manchester encoding are, that there are no prolonged high or
low signals. Furthermore, the original clock signal can be extracted from the signal and
doesn't need to be synchronized between the sender and receiver. On the other
side the bandwidth requirements are doubled as two code bits in the signal are
needed to encode one bit of the original data \cite{manchesterCode}.
For the work in this thesis, we use the definition of Manchester Code by G.E
For the work in this thesis, I use the definition of Manchester Code by G.E
Thomas.
\section{Web Worker}
@ -111,7 +111,5 @@ threads in the browser. This way you can run CPU intensive processes without
stalling the main thread and locking up the UI.
There are a few limitations with Web Workers. A Web Worker doesn't have access
to the \gls{dom}, to the window object and to some web APIs.
The main thread and Web Workers can communicate together using messages.
\cite{WebWorkers}
to the \gls{dom}, to the window object, and to some web APIs. The communication
between the main thread, and the web workers occurs via messages \cite{WebWorkers}.

7
documentation/thesis/content/03_personas.tex
View file

@ -7,3 +7,10 @@ Alice wants to be able to receive a small piece of data over a website, similar
to a QR code, with her smartphone but without other people being able to see the
code over her shoulders. She also would like to be able to receive data to her smartphone while it has connection available, for example when it's in airplane mode.
\textbf{Charlie} \\
Charlie would like to enable \gls{2fa} on a website. To do so, he normally
needs to scan a \gls{qr} code to register the website to his authentication
app, but the camera on his smartphone is broken. Thus, he wants to be able to
receive the \gls{2fa} registration token wirelessly to his smartphone without
the use of his camera.

23
documentation/thesis/content/05_solution.tex
View file

@ -1,9 +1,9 @@
\chapter{Solution}
The solution consists of two separate applications: a website used for transmitting data and a smartphone application used for receiving data. Transmission between the two application happens using a simple protocol on top of signals made using magnetic induction. I call the system MagSend.
The solution consists of two separate applications: a website used for transmitting data, and a smartphone application used for receiving data. Transmission between the two application happens by a simple protocol on top of signals that use magnetic induction. I call the system MagSend.
\section{Protocol}
\label{section:protocol}
The following section describes how the MagSend protocol works. I explain the entire protocol first by explaining how the data gets encoded on the sender site, then the transmission and finally how the data is received.
The following section describes how the MagSend protocol works. First I explain how the data gets encoded on the sender site, then the transmission, and finally how the data is received.
\subsection{Sending}
This section explains how a user-provided message gets encoded and finally transmitted using \gls{mi}.
@ -11,7 +11,7 @@ This section explains how a user-provided message gets encoded and finally trans
Data over MagSend gets sent in a packet. For the structure of the packet I tried to follow other packet formats that already exist. Most of the structure is similiar to the structure of a LoRa packet. \cite{LoRaPacketFormat} I choose LoRa as example as I am familiar to it was a part of my studies and as LoRa is also a protocol designed with a low data-rate in mind. The packet contains three parts.
\subsubsection*{Header}
The first part of the packet is the header. The header is \SI{4}{\bit} long and contains the length of the payload in bytes. The length is mainly used, to be able to detect the end of the payload.
The first part of the packet is the header. The header is \SI{4}{\bit} long and contains the length of the payload in bytes. The length is mainly used to detect the end of the payload.
\subsubsection*{Payload}
Next is the actual payload. As the length of the payload is specified in the header, the payload is limited to a size of $2^4$ bytes. While the contents of the payload can be any bit stream, the sender and receiver should assume that the bit stream is interpreted as ASCII text.
@ -27,7 +27,7 @@ The transmission works over magnetic induction. By putting a load on a CPU the r
To indicate the start of a message in the signal, a preamble is used. The preamble used in this protocol is 3 high signals, followed by 3 low signals, followed by 3 high signals. The duration of one signal in the preamble is 1 second. That means the entire preamble takes 9 seconds.
After the preamble that contents of the manchester encoded packet is sent.
After the preambl, the contents of the manchester encoded packet is sent.
\begin{figure}[H]
\begin{bytefield}[bitwidth=.05\linewidth, bitheight=11mm]{4}
@ -78,9 +78,9 @@ process.
\caption{Website - Home}
\end{figure}
When the calibration process is started, a message is displayed so it's clear
that we are in the calibration process. What happens technically is the website
will just put a full load on the CPU for the duration of the calibration. The
When the calibration process is started, a message is displayed, so it's clear
that we are in the calibration process. What happens during calibration is, that the website
puts a full load on the CPU for the duration of the calibration. The
actual calibration process happens in the smartphone application.
\begin{figure}[H]
@ -90,10 +90,9 @@ actual calibration process happens in the smartphone application.
\end{figure}
\newpage
When the user presses the sending button, the text will be sent by website
When the user presses the sending button, the text will be sent by the website
using the protocol described in \autoref{section:protocol}, by putting stress
on the CPU to generate a signal. While sending there is a message which
indicates that there is currently a send in process.
on the CPU to generate a signal. A message is displayed that indicates that a sending process is ongoing.
\begin{figure}[H]
\centering
@ -114,7 +113,7 @@ On the homescreen you have two buttons. One button is for receiving messages and
\end{figure}
\newpage
The calibration mode is used to find the most optimal location where the user should put the smartphone on the sending device. The website will continously put a load on the CPU. The app will then show the current strength of the magnetic field. The location where the strength is the highest is the one, where you will get the best transmission results.
The calibration mode is used to find the most optimal location where the user should put the smartphone on the sending device. The website will continously put a load on the CPU. The app will then show the current strength of the magnetic field. The location where the strength is the highest is the one where you will get the best transmission results.
\begin{figure}[H]
\centering
@ -123,7 +122,7 @@ The calibration mode is used to find the most optimal location where the user sh
\end{figure}
\newpage
When receiving a message, the currently received text is displayed on the screen while a loading indicator indicates that the receiving is still in process. When the receiving is finished the complete text is displayed. While receiving the user has the possibility to restart the receiving process to receive a new message.
During the reception process, the currently received text is displayed on the screen while a loading indicator indicates that the process is still ongoing. When the process is finished, the complete text is displayed. At any time, the user has the possibility to restart the reception process for a new message.
\begin{figure}[H]
\begin{minipage}{.5\textwidth}

39
documentation/thesis/content/06_testing.tex
View file

@ -1,9 +1,9 @@
\chapter{Testing}
\section{Devices}
The following devices were used for the development and testing of MagSend. While theoretically MagSend should work on other laptops and smartphones, I have only tested in on specified devices. For each device, the most important specifications are listed.
The following devices were used for the development and testing of MagSend. While theoretically MagSend should work on other laptops and smartphones, I have only tested it on the specified devices. For each device, the most important specifications are listed.
\subsection{Laptop}
The laptop was used as the sending device for MagSend. The Website was run using the Firefox browser and the laptop was always plugged in to the power grid to ensure that CPU, doesn't throttle.
The laptop was used as the sending device for MagSend. The Website was run on the Firefox browser. The laptop was always plugged in to the power grid to ensure that the CPU throttles less often.
\begin{table}[H]
\begin{reqTblr}{l p{11.0cm}}
@ -39,7 +39,7 @@ The following test cases are all structured in the same way. The table lists the
\begin{reqTblr}{l p{10.5cm}}
ID & T01 \\
Related Requirement & F01 \\
Description & The user is provided with the option to the start calibration on the website. \\
Description & The user is provided with the option to start the calibration on the website. \\
Expected Result &
\begin{enumerate}
\item{The user opens the website in a web browser}
@ -110,7 +110,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The calibration is stopped, and the CPU should not be utilized anymore}
\end{enumerate} \\
Actual Result &
When the user clicks on the "Stop Calibration" button, the message about the calibration disappears and the button switches back to "Start Calibration" and the website should look like if it has just opened.
When the user clicks on the "Stop Calibration" button, the message about the calibration disappears and the button switches back to "Start Calibration". In the end, the website should look like if it has just opened.
After stopping the calibration, the CPU utilization also goes back down to normal levels (see \autoref{figure:t03_2}).
\\
@ -137,12 +137,20 @@ The following test cases are all structured in the same way. The table lists the
\item{The user is provided with a button to start the calibration}
\end{enumerate} \\
Actual Result &
Upon opening the app, the user is greeted with an option to start the calibration (see autoref{figure:t04}).
Upon opening the app, the user is greeted with an option to start the calibration (see \autoref{figure:t04}).
\\
\end{reqTblr}
\caption{Test Case 04}
\end{table}
\begin{figure}[H]
\centering
\fbox{\includegraphics[width=0.4\linewidth]{test_cases/t4.jpg}}
\caption{Test Case 04 - Home Screen in the App}
\label{figure:t04}
\end{figure}
\begin{table}[H]
\begin{reqTblr}{l p{10.5cm}}
ID & T05 \\
@ -152,10 +160,10 @@ The following test cases are all structured in the same way. The table lists the
\begin{enumerate}
\item{The user opens the app}
\item{The user clicks on the "Calibrate" button}
\item{The user is shown the current measured magnetic field strength as well as a chart of the historical values}
\item{The user is shown the current measured magnetic flux density as well as a chart of the historical values}
\end{enumerate} \\
Actual Result &
After starting the calibration in the app, the user can see the magnetic field strength and historical data in a chart. (see autoref{figure:t05}).
After starting the calibration in the app, the user can see the magnetic flux density and historical data in a chart. (see \autoref{figure:t05}).
\\
\end{reqTblr}
\caption{Test Case 05}
@ -196,10 +204,10 @@ The following test cases are all structured in the same way. The table lists the
\begin{enumerate}
\item{The user opens the website in a web browser}
\item{The user clicks into the text input}
\item{The user can enter any text between 0 and 16 characters}
\item{The user can enter any text between 0 and 16 characters in length}
\end{enumerate} \\
Actual Result &
The user can enter any character in the input they want, but they unable to enter more than 16 characters (see \autoref{figure:t07}).
The user can enter any character in the input they want, but they are unable to enter more than 16 characters (see \autoref{figure:t07}).
\\
\end{reqTblr}
\caption{Test Case 07}
@ -228,7 +236,7 @@ The following test cases are all structured in the same way. The table lists the
Actual Result &
When the user attempts to start sending when they haven't entered any text, a message is displayed (see \autoref{figure:t08}).
When the user attempts to start sending when they have entered any non-ASCII characters, a message is diplayed. (see \autoref{figure:t08_2}).
A message also appears, when the user attempts to start sending when they have entered any non-ASCII characters (see \autoref{figure:t08_2}).
In both cases, the sending process is not started.
\\
@ -298,7 +306,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The sending is stopped, and the CPU should not be utilized anymore}
\end{enumerate} \\
Actual Result &
When the user clicks on the "Stop Sending" button, the message about the sending disappears and the button switches back to "Start Sending" and the website should look like if it has just been opened.
When the user clicks on the "Stop Sending" button, the message about the sending disappears and the button switches back to "Start Sending". In the end, the website should look like if it has just opened.
After stopping the sending, the CPU utilization also goes back down to normal levels (see \autoref{figure:t10}).
\\
@ -327,7 +335,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The app will start the reception process and will indicate if the preamble was detected, the length of the received payload, and if the checksum is valid. The received text is also displayed.}
\end{enumerate} \\
Actual Result &
When the users starts the reception process they are informed about the current process of the receive status. They are informed whether the preamble was detected, the length of the payload and if the checksum is valid. They can also see the currently received text at all times (see \autoref{figure:t11}).
When the users starts the reception process they are informed about the current process of the receive status. They are informed whether the preamble was detected, about the length of the payload, and if the checksum is valid. They can also see the currently received text at all times (see \autoref{figure:t11}).
When the checksum is invalid the user is informed about it (see \autoref{figure:t11_2}).
\\
@ -339,13 +347,13 @@ The following test cases are all structured in the same way. The table lists the
\begin{minipage}{.5\textwidth}
\centering
\fbox{\includegraphics[width=0.8\linewidth]{test_cases/t11.jpg}}
\caption{Test Case 11 - Reception Process without any Errors}
\caption{Test Case 11 - Reception Process\\ without any Errors}
\label{figure:t11}
\end{minipage}
\begin{minipage}{.5\textwidth}
\centering
\fbox{\includegraphics[width=0.8\linewidth]{test_cases/t11_2.jpg}}
\caption{Test Case 11 - Reception Process with Invalid Checksum}
\caption{Test Case 11 - Reception Process\\ with Invalid Checksum}
\label{figure:t11_2}
\end{minipage}
\end{figure}
@ -434,8 +442,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The transfer speed between laptop and smartphone should at least be \SI{1}{\bit\per\second}}
\end{enumerate} \\
Actual Result &
The clock speed of the transmitted signal is 500ms. As the MagSend payload is encoded using a manchester code, which doubles the data size, this means every second 1 bit gets transmitted. For more information about data rate benchmarks, please refer to \autoref{chapter:benchmarking}.
\\
The clock speed of the transmitted signal is 500ms. The MagSend payload is encoded using a manchester code, which doubles the data size. This means every second 1 bit gets transmitted. For more information about data rate benchmarks, please refer to \autoref{chapter:benchmarking}.
\end{reqTblr}
\caption{Test Case 15}
\end{table}

8
documentation/thesis/content/07_benchmarking.tex
View file

@ -2,7 +2,7 @@
\label{chapter:benchmarking}
This chapter will research the real world capabilities of MagSend. I attempt to transmit a message using different speeds of MagSend under different system CPU loads to see how it performs and which transfer speed is the most reliable to use.
The following benchmark test are structured in the same way. I run each test 5 times to get a more accurate view of the test. For each test I note if MagSend can detect the preamble, the received payload length, whether the \gls{crc} is valid and the received message.
The following benchmark tests are all structured in the same way. I run each test 5 times to get a more accurate view of the test. For each test, I wrote down if MagSend can detect the preamble, the received payload length, the received message, and whether the \gls{crc} is valid.
The message used in the test transmissions is "\textbf{Test}".
@ -68,9 +68,9 @@ The following benchmarks were run with 25\% CPU utilization. The tool \texttt{st
\subsection{Results}
As one can see in the benchmarks, the most successful configuration was running MagSend with \SI{1}{\bit\per\second} at with an idle CPU followed by \SI{0.5}{\bit\per\second} at an idle CPU.
The benchmarks with 25\% CPU load were mostly failing, with some few ones being able to detect the preamble and one even being able to receive the payload length from the message. There might be a few reasons why the results are like this. The first one is thermal throttling (see \autoref{section:thermal_throttling}).
The benchmarks with 25\% CPU load were mostly failing, with a few being able to detect the preamble, and one even being able to receive the payload length from the message. There might be a few reasons why the results are like this. The first one is thermal throttling (see \autoref{section:thermal_throttling}).
The laptop that was used for running the benchmarks, already reaches CPU temperatures of over \SI{90}{\celsius} when only running at around 25\% CPU load (see \autoref{figure:cpu_temperatures}).
The laptop that was used for running the benchmarks already reaches CPU temperatures of over \SI{90}{\celsius} when only running at around 25\% CPU load (see \autoref{figure:cpu_temperatures}).
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{benchmarking/cpu_temperatures.png}}
@ -78,4 +78,4 @@ The laptop that was used for running the benchmarks, already reaches CPU tempera
\label{figure:cpu_temperatures}
\end{figure}
The other problem with the failing benchmarks is on the receiving side. The interval at which the sensor provides data to the application is not guaranteed and thus introduces some jitter \cite{androidSensorMonitor}.
The other problem with the failing benchmarks is on the receiving side. The interval at which the sensor provides data to the application is not guaranteed and thus introduces some jitter \cite{androidSensorMonitor}, which is not yet handled perfectly in the app.

13
documentation/thesis/content/10_project_management.tex
View file

@ -2,8 +2,8 @@
\section{Project Plan}
At the beginning of the project, a project plan was created to plan all of the
work. That original plan can be found in \autoref{section:plan}. During the
project the actual plan was recorded and can be found in
\autoref{section:actual_plan}.
lifetime of the project, the plan was updated to reflect the actual state of
the project. That adjusted plan can be found in \autoref{section:actual_plan}.
For the first few weeks, I managed to match my initial plan pretty well. I
spent a bit more time than I'd like on the concrete selection of my subject.
@ -34,6 +34,7 @@ generous planning in the beginning it all worked out.
\begin{ganttchart}[
vgrid,
hgrid,
bar/.append style={fill=green!90},
x unit=0.8cm,
y unit chart=0.5cm,
y unit title=0.5cm, % height of title line and gap
@ -84,6 +85,7 @@ generous planning in the beginning it all worked out.
\begin{ganttchart}[
vgrid,
hgrid,
bar/.append style={fill=green!90},
x unit=0.8cm,
y unit chart=0.5cm,
y unit title=0.5cm, % height of title line and gap
@ -149,11 +151,12 @@ During the planning of the solution, I created multiple mockups of the planned
website and app screens. To create the mockups, I used the open-source design
tool Penpot \cite{penpot}.
\newpage
\section{Conclusion}
The project, albeit with some issues, was finished in time. The initial plan
was only met for the beginning as the sickness delayed the rest of the tasks,
this caused the last of weeks of the projects to be more stressful than I'd
have liked, but thanks to generous planning it worked out.
was only met for the beginning as the sickness delayed the rest of the tasks.
This delay caused the last few of weeks of the project to be more stressful
as I'd have liked, but thanks to generous planning it worked out.
One of the biggest things in terms of project management I can improve for the
next project is to plan everything a bit more. While I had some rough planning

2
documentation/thesis/content/_glossary.tex
View file

@ -3,3 +3,5 @@
\newacronym{rfid}{RFID}{Radio-frequency identification}
\newacronym{nfc}{NFC}{Near-field communication}
\newacronym{mi}{MI}{Magnetic Induction}
\newacronym{2fa}{2FA}{two-factor authentication}
\newacronym{qr}{QR}{Quick Response}