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

Finalize thesis report and fix grammar mistakes
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Details

Browse source 
Signed-off-by: Severin Kaderli <severin@kaderli.dev>
This commit is contained in:
Severin Kaderli 2023-01-15 21:51:11 +01:00
parent 77fbdd194f
commit 10bf9ebf44
Signed by: severinkaderli
GPG key ID: F419F8835B72F0C4
21 changed files with 2716 additions and 211 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
documentation/thesis/assets/app_home.jpg Executable file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 190 KiB

BIN
documentation/thesis/assets/app_receive.jpg Executable file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 155 KiB

BIN
documentation/thesis/assets/magnetic_induction_cpu.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
documentation/thesis/assets/signature.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 70 KiB

26
documentation/thesis/content/01_introduction.tex
View file

@ -1,11 +1,25 @@
\chapter{Introduction}
In our lifes we use many communication technologies that work over a short range: for connecting our mice and keyboards to our computers, listening to music wirelessly and to pay contactlessly. Those technologies include but are not limited to: Bluetooth, \gls{rfid}, \gls{nfc} and many others.
In our lives we use many communication technologies that work over a short
range: for connecting our mice and keyboards to our computers, listening to
music wirelessly and to pay contactlessly. Those technologies include, but are
not limited to: Bluetooth, \gls{rfid}, \gls{nfc} and many others.
What many of those technologies have in common is that they work on top of radio waves that utilize electromagnetic induction. Some problems of radio waves are the difficulty of passing through conductive materials such as water or metals \cite{RadioWaves} and they are susceptible to interference \cite{RadioInterference} and jamming \cite{RadioJamming}.
What many of those technologies have in common is that they work on top of
radio waves that utilize electromagnetic induction. Some problems of radio
waves are the difficulty of passing through conductive materials such as water
or metals \cite{RadioWaves} and they are susceptible to interference
\cite{RadioInterference} and jamming \cite{RadioJamming}. An alternative to
those technologies would be communication over magnetic induction.
Other reseach projects in this area exists and some have covered the use of the magnetic fields emitted from CPUs as a communication channel \cite{MagneComm} and other cover the general use of magnetic induction communication in body area networks \cite{magneticInductionBAN}.
Other research projects in this area already exist and some have covered the
use of the magnetic fields emitted from CPUs as a communication channel
\cite{MagneComm} and other cover the general use of magnetic induction
communication in body area networks \cite{magneticInductionBAN}.
This thesis will research the concept of communication using magnetic induction and will create a prototype implementation of a protocol that works through attempted manipulation of magnetic fields using a CPU in a Laptop. A simple user interface in the form of a website is created that allows an user to send text over the protocol and an Android application is used for receiving the text over the protocol.
// TODO: Reword the introduction
This thesis researched the concept of communication using magnetic induction
and created a prototype implementation of a protocol that works through
attempted manipulation of magnetic fields using a CPU in a laptop called
MagSend. A simple user interface in the form of a website is created that
allows a user to send messages over the protocol and an Android application
is used to receive messages using the protocol.

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

@ -1,31 +1,93 @@
\chapter{Preliminaries}
\section{Web Worker}
\label{section:webworkers}
Web Workers are a web API that allows running JavaScript code in background threads in the browser. This way you can run CPU intensive processes without stalling the main thread and locking up the UI.
\section{Magnetic Induction}
\gls{mi}, also known as magnetic flux density or simply the magnetic field, is a
physical quantity measured in Tesla \si{\tesla}. The movement of electric
charges in a conductor produces a magnetic field around the conductor. This
phenomena also happens when in a CPU \cite{magneticFluxDensity}.
There's 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.
In \autoref{figure:magnetic_induction_cpu} the difference of the magnetic field
of a CPU in idle (first 10 seconds) and under 100\% load can be seen.
The main thread and Web Workers can communicate together using messages. \cite{WebWorkers}
\begin{figure}[H]
\includegraphics[width=\textwidth]{magnetic_induction_cpu.png}
\caption{Magnetic Field of a CPU}
\label{figure:magnetic_induction_cpu}
\end{figure}
\section{Hall Effect Sensor}
\label{section:hallEffectSensor}
A Hall Effect Sensor is a type of sensor to measure the strength of magnetic
fields. This type of magnetometer is found in many smartphones today
\cite{hallEffectSensor} and is generally used for compass capabilities and for
positioning \cite{smartphoneSensors}.
It utilizes the so-called hall effect to do so. The hall effect is the voltage
between two sides of a current-carrying conductor inside a magnetic field
\cite{hallEffect,hallEffect2}.
\section{Thermal Throttling}
\label{section:thermal_throttling}
CPUs utilize a lot of power when under load, and thus they get hotter. When they
get too hot, they throttle by reducing clock speeds. This process is designed to
protect the CPU from overheating \cite{thermalThrottling}.
When stress is put on the CPU, the CPU begins to throttle and the resulting CPU
loads gets dampened after a while (see \autoref{figure:throttle}).
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{benchmarking/1bps_25.png}}
\caption{CPU Utilization with Thermal Throttling}
\label{figure:throttle}
\end{figure}
\section{CRC}
\label{section:crc}
\gls{crc} is a family of error detection codes designed to check if a message has been corrupted during transmission. To check if any errors ocurred during 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.
\gls{crc} is a family of error detection codes designed to check if a message
has been corrupted during transmission. To check if any errors ocurred during
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 remainder of this division is the checksum value. The order of the generator polynomial defines the bit-length of the resulting checksum \cite{crcGuide}.
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
remainder of this division is the checksum value. The order of the generator
polynomial defines the bit-length of the resulting checksum \cite{crcGuide}.
Depending on the chosen generator polynomial different groups of errors can be detected \cite{crcErrors}:
Depending on the chosen generator polynomial, different groups of errors can be
detected \cite{crcErrors}:
\begin{itemize}
\item{A single, and double bit errors can always be detected}
\item{Depending on the polynomial more bit errors can be detected inside specific message lengths}
\item{Using a n-bit generator polynomial can detect burst errors of up to n-bits in length}
\item{A generator polynomial with an even amount of terms can detect errors with an odd amount of bits}
\item{Depending on the polynomial, more bit errors can be detected inside
specific message lengths}
\item{Using an n-bit generator polynomial can detect burst errors of up to
n-bits in length}
\item{A generator polynomial with an even number of terms can detect errors
with an odd number of bits}
\end{itemize}
Because of these small variations there many different implementations of \gls{crc} algorithms in use and defined by different parties \cite{crcCatalogue}.
Because of these small variations, there are many implementations of
\gls{crc} algorithms in use and defined by different parties
\cite{crcCatalogue}.
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
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.
CRC is widely used in networks for detecting transmission errors and is simple
to implement. \cite{Crc}
\section{Manchester Code}
Manchester is a simple encoding code for the transmission of binary data. The data is encoded in the transistions 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 definition from IEEE the values of the transitions are swapped (see \autoref{figure:manchester_code}).
\label{section:manchester}
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
definition from IEEE the values of the transitions are swapped
(see \autoref{figure:manchester_code}).
\begin{figure}[H]
\includegraphics[width=\textwidth]{manchester_code.png}
@ -33,10 +95,23 @@ Manchester is a simple encoding code for the transmission of binary data. The da
\label{figure:manchester_code}
\end{figure}
The advantages of manchester encoding is that there are no prolonged high or low signals and the original clock signal can be extracted from the signal, on the other side the bandwidth requirements are doubled as two bits in the signal are needed to encode one bit of the original data \cite{manchesterCode}.
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
needed to encode one bit of the original data \cite{manchesterCode}.
\section{Hall Effect Sensor}
\label{section:hallEffectSensor}
A Hall Effect Sensor is a type of sensor to measure the strength of magnetic fields. This type of magnetometer is found in many smartphones today \cite{hallEffectSensor} and is generally used for compass capabilities and for positioning \cite{smartphoneSensors}.
For the work in this thesis, we use the definition of Manchester Code by G.E
Thomas.
It utilizes the so-called hall effect to do so. The hall effect is the voltage between two sides of a current-carrying conductor inside a magnetic field \cite{hallEffect} \cite{hallEffect2}.
\section{Web Worker}
\label{section:webworkers}
Web Workers are a web API that allows running JavaScript code in background
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}

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

@ -1,9 +1,9 @@
\chapter{Personas}
This chapter describes the personas with their motivations, goals and problems that they want
This chapter describes the personas with their motivations, goals, and problems that they want
to have solved. These motivations are then later used to create and describe the requirements in \autoref{chapter:requirements}.
\textbf{Alice} \\
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 wants to be able to receive data to her smartphone while it has connection available e.g. when it's in airplane mode.
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.

18
documentation/thesis/content/04_requirements.tex
View file

@ -7,7 +7,7 @@
ID & F01 \\
Title & Calibration on Website \\
Application & Website \\
Description & The user visits the website and starts the calibration mode on the website. While in calibration mode the website continuously puts load on the CPU.
Description & The user visits the website and starts the calibration mode on the website. While in calibration mode, the website continuously puts load on the CPU.
\end{reqTblr}
\caption{Functional Requirement 01}
\end{table}
@ -17,7 +17,7 @@
ID & F02 \\
Title & Calibration on App \\
Application & Smartphone App \\
Description & In the app the user can start the calibration process. By putting their smartphone on different location on their laptop the app will tell them the current strength of the magnetic field. The point with the strongest magnetic field is the optimal place for data transmission.
Description & In the app, the user can start the calibration process. By putting their smartphone on different locations on their laptop, the app will tell them the current strength of the magnetic field. The point with the strongest magnetic field is the optimal place for data transmission.
\end{reqTblr}
\caption{Functional Requirement 02}
\end{table}
@ -27,7 +27,7 @@
ID & F03 \\
Title & Text Entry \\
Application & Website \\
Description & The website contains a text input field. THe user can enter any ASCII string in this text input.
Description & The website contains a text input field. The user can enter any ASCII string in this text input.
\end{reqTblr}
\caption{Functional Requirement 03}
\end{table}
@ -37,7 +37,7 @@
ID & F04 \\
Title & Sending Data \\
Application & Website \\
Description & The user visits the website, enter a text and then clicks on the send button. The website will attempt to send the string in the input field using MI. The data will be sent continously until the user stops the sending by clicking on the stop button.
Description & The user visits the website, enter a text and then clicks on the send button. The website will attempt to send the string in the input field using \gls{mi}. The data will be sent continuously until the user stops the sending by clicking on the stop button.
\end{reqTblr}
\caption{Functional Requirement 04}
\end{table}
@ -47,21 +47,21 @@
ID & F05 \\
Title & Receiving Data \\
Application & Smartphone App \\
Description & The user can start the receiving mode in the app. By putting their smartphone on the laptop they can receive the data that is sent by the website. The app displays the received text on the screen.
Description & The user can start the receiving mode in the app. By putting their smartphone on the laptop, they can receive the data that is sent by the website. The app displays the received text on the screen.
\end{reqTblr}
\caption{Functional Requirement 05}
\end{table}
\newpage
\section{Non Functional Requirements}
\section{Non-Functional Requirements}
\begin{table}[H]
\begin{reqTblr}{l p{11.8cm}}
ID & N01 \\
Title & Working in Airplane Mode \\
Description & The user can receive data using the app on their smartphone even if they have put their phone in airplane mode and normal connectivity is not working.
Description & The user can receive data using the app on their smartphone, even if they have put their phone in airplane mode and normal connectivity is not working.
\end{reqTblr}
\caption{Non Functional Requirement 01}
\caption{Non-Functional Requirement 01}
\end{table}
\begin{table}[H]
@ -70,5 +70,5 @@
Title & Transfer Rate \\
Description & The transfer speed between the laptop and smartphone should at least be \SI{1}{\bit\per\second}. That means an ASCII character should take 8 seconds to transmit.
\end{reqTblr}
\caption{Non Functional Requirement 02}
\caption{Non-Functional Requirement 02}
\end{table}

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

@ -1,99 +1,104 @@
\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.
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.
\section{Protocol}
\label{section:protocol}
\subsection{Signal}
The main communication protocol works over magnetic induction. By putting a load on a CPU the resulting magnetic field can be changed. Using a magnetometer in a smartphone these changes can be measured and interpreted.
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.
For simplification purposes the protocol in this project is used to transmit ASCII text but in reality any bitstream can be transmitted.
\subsection{Sending}
This section explains how a user-provided message gets encoded and finally transmitted using \gls{mi}.
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.
\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.
\subsubsection*{Checksum}
For verifying the integrity of the payload, a checksum of the payload is calculated and placed at the end of the packet. The algorithm used is the 8-bit CRC-8-AUTOSAR algorithm (see \autoref{section:crc}).
\subsubsection*{Encoding}
The contents of the packet is then encoded using a manchester code (see \autoref{section:manchester}) for transmission.
\subsubsection*{Transmission}
The transmission works over magnetic induction. By putting a load on a CPU the resulting magnetic field can be changed. High signals should be interpreted as a 1 and low signals should be interpreted as a 0.
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.
\subsection{Packet Format}
\subsubsection*{Encoding}
What follows the preamble is the actual contents of the message packet. The packet content is a bitstream encoded using a manchester code. Manchester Code is used, as it is self clocking and therefore we don't need to synchronize the clock between the sender and the receiver seperately. We use the definition of Manchester Code by G.E Thomas where a 0 is indicated by a 0 to 1 transition, and a 1 is indicated by a 1 to 0 transition.
\subsubsection*{Inspiration}
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.
\subsubsection*{Header}
The first part of the message is the header. The header is \SI{4}{\bit} long and contains the length of the payload in bytes. The length is useful 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. The contents of the payload can be any bitstream. For this implementation of the protocol we transmit ASCII encoded text where the characters are padded to a byte.
\subsubsection*{Checksum}
For verifying the integrity of the payload, a checksum of the payload is calculated and placed at the end of the packet. The algorithm used is a 8-bit CRC (see \autoref{section:crc}). The specific algorithm 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 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 fitting CRC algorithm to use.
A possibility for even better error detection would be to use a 16-bit CRC algorithm but we are already working under low data-rate constraints and a bigger CRC would increase the packet size by another byte.
There also also other possible error-detecting codes that could be used but I choose CRC as it is widely used in networks for detecting transmission errors and they are simple to implement. \cite{Crc}
After the preamble that contents of the manchester encoded packet is sent.
\begin{figure}[H]
\begin{bytefield}[bitwidth=.05\linewidth, bitheight=11mm]{4}
\bitbox[]{4}[]{9 Symbols} & \bitbox[]{2}[]{4 Bit} & \bitbox[]{10}[]{n Bytes} & \bitbox[]{4}[]{1 Byte} \\
\bitbox{4}[bgcolor=gray!30]{Preamble} & \bitbox{2}[bgcolor=red!30]{Payload Length} & \bitbox{10}[bgcolor=blue!30]{Payload} & \bitbox{4}[bgcolor=green!30]{CRC-8-AUTOSAR}
\end{bytefield}
\caption{Packet Structure}
\caption{Packet Structure, with Preamble at the Start}
\end{figure}
\subsection{Sending}
The following describes the steps needed to send a message using our protocol:
\begin{enumerate}
\item{Convert the text to an ASCII encoded bitstream which will be the payload}
\item{Calculate the length of the payload in bytes}
\item{Calculate the CRC-8-AUTOSAR checksum of the payload}
\item{Combine the payload length, payload, and checksum into a packet}
\item{Encode packet using manchester encoding}
\item{Start the transmission by sending the preamble}
\item{Transmit the manchester encoded bitstream of the packet}
\end{enumerate}
The following pseudocode in \autoref{listing:sending_pseudo} explains step by
step how a message should get encoded and transmitted using MagSend.
// TODO: Detailed description of sending process with pseudocode
\lstinputlisting[
style=bfh-c,
language=C,
caption={Pseudocode for Sending},
label={listing:sending_pseudo}
]{thesis/listings/sending_pseudo.py}
\subsection{Receiving}
The following describes the steps needed to receive a message using our protocol:
The receiver utilizes a magnetometer to measure the magnetic field and
interprets the received sensor values as a signal.
\begin{enumerate}
\item{Detect the preamble in the signal}
\item{Decode the received manchester encoded bitstream}
\item{Read the first four bits of the bitstream to get the payload length}
\item{Read the next n Bytes of the bitstream, according to the payload length, to get the payload}
\item{Read the next byte to get the CRC-8-AUTOSAR checksum of the payload}
\item{Verify the integrity of the payload using the checksum}
\item{Convert the payload ASCII bitstream to text}
\end{enumerate}
// TODO: Detailed description of decoding process with pseudocode
The following pseudocode in \autoref{listing:receiving_pseudo} explains step by
step how the signal should get interpreted and decoded using MagSend.
\lstinputlisting[
style=bfh-c,
language=C,
caption={Pseudocode for Receiving},
label={listing:receiving_pseudo}
]{thesis/listings/receiving_pseudo.py}
\newpage
\section{Website}
The website provides the user with an interface to transmit text over our protocol.
The website provides the user with an interface to transmit text over the
MagSend protocol.
When the user opens the website they are greeted by a simple interface. It contains an input field for entering text and two buttons. The first button will send the entered text, and the second one will start the calibration process.
When the user opens the website they are greeted by a simple interface. It
contains an input field for entering text and two buttons. The first button
will send the entered text, and the second one will start the calibration
process.
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{mockups/website/home_v1.png}}
\caption{Website - Home - Mockup}
\centering
\fbox{\includegraphics[width=.65\textwidth]{test_cases/t1.png}}
\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
actual calibration process happens in the smartphone application.
\begin{figure}[H]
\centering
\fbox{\includegraphics[width=.65\textwidth]{test_cases/t2.png}}
\caption{Website - Calibration}
\end{figure}
\newpage
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 actual calibration process happens in the smartphone application.
When the user presses the sending button, the text will be sent by 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.
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{mockups/website/calibration_v1.png}}
\caption{Website - Calibration - Mockup}
\end{figure}
\newpage
When the user presses the sending button, the text will be sent by 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.
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{mockups/website/sending_v1.png}}
\caption{Website - Sending - Mockup}
\centering
\fbox{\includegraphics[width=.65\textwidth]{test_cases/t9.png}}
\caption{Website - Sending}
\end{figure}
\newpage
@ -103,16 +108,18 @@ The app allows the user to receive messages over the protocol.
On the homescreen you have two buttons. One button is for receiving messages and one is to start the calibration process. By clicking one of the buttons the user will be switched to the corresponding screen.
\begin{figure}[H]
\fbox{\includegraphics[width=0.4\textwidth]{mockups/app/home_v1.png}}
\caption{App - Home - Mockup}
\centering
\fbox{\includegraphics[width=0.4\textwidth]{app_home.jpg}}
\caption{App - Home}
\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.
\begin{figure}[H]
\fbox{\includegraphics[width=0.4\textwidth]{mockups/app/calibration_v1.png}}
\caption{App - Calibration - Mockup}
\centering
\fbox{\includegraphics[width=0.4\textwidth]{test_cases/t5.jpg}}
\caption{App - Calibration}
\end{figure}
\newpage
@ -120,13 +127,13 @@ When receiving a message, the currently received text is displayed on the screen
\begin{figure}[H]
\begin{minipage}{.5\textwidth}
\fbox{\includegraphics[width=0.8\textwidth]{mockups/app/receive_progress_v1.png}}
\caption{App - Receiving in Progress - Mockup}
\centering
\fbox{\includegraphics[width=0.8\textwidth]{app_receive.jpg}}
\caption{App - Receiving in Progress}
\end{minipage}
\begin{minipage}{.5\textwidth}
\fbox{\includegraphics[width=0.8\textwidth]{mockups/app/receive_complete_v1.png}}
\caption{App - Receving Completed - Mockup}
\centering
\fbox{\includegraphics[width=0.8\textwidth]{test_cases/t11.jpg}}
\caption{App - Receving Completed}
\end{minipage}
\end{figure}
// TODO: Replace mockups here with the final interface

117
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 in on 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 using the Firefox browser and the laptop was always plugged in to the power grid to ensure that CPU, doesn't throttle.
\begin{table}[H]
\begin{reqTblr}{l p{11.0cm}}
@ -33,13 +33,13 @@ The smartphone was used as the receiving device for MagSend. The app was run nor
\section{Test Cases}
The following test cases are all structured in the same way. The table lists the related requirements from \autoref{chapter:requirements} and describes the test case briefly. Then the expected result row lists the steps and endresult that should happen for the test case to be successful. The last row describes the actual result from testing.
The following test cases are all structured in the same way. The table lists the related requirements from \autoref{chapter:requirements} and describes the test case briefly. Then the expected result row lists the steps and the result that should happen for the test case to be successful. The last row describes the actual result from testing.
\begin{table}[H]
\begin{reqTblr}{l p{10.5cm}}
ID & T01 \\
Related Requirement & F01 \\
Description & The user is provided with the option the start calibration on the website. \\
Description & The user is provided with the option to the start calibration on the website. \\
Expected Result &
\begin{enumerate}
\item{The user opens the website in a web browser}
@ -53,7 +53,8 @@ The following test cases are all structured in the same way. The table lists the
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t1.png}
\centering
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t1.png}}
\caption{Test Case 01 - Start Calibration Button on Website}
\label{figure:t01}
\end{figure}
@ -68,26 +69,28 @@ 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 on the "Start Calibration" button}
\item{The calibration process is started and the user is notified about it}
\item{During calibration the CPU is periodically stressed}
\item{The calibration process is started, and the user is notified about it}
\item{During calibration, the CPU is periodically stressed}
\end{enumerate} \\
Actual Result &
When the user starts the calibration process the "Start Calibration" button changes to "Stop Calibration" and a message appears that indicates that calibration is in process (see \autoref{figure:t02}).
When the user starts the calibration process, the "Start Calibration" button changes to "Stop Calibration" and a message appears that indicates that calibration is in process (see \autoref{figure:t02}).
While calibrating the CPU is periodically stressed as seen in the CPU utilization graph (see \autoref{figure:t02_2}).
While calibrating, the CPU is periodically stressed as seen in the CPU utilization graph (see \autoref{figure:t02_2}).
\\
\end{reqTblr}
\caption{Test Case 02}
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t2.png}
\centering
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t2.png}}
\caption{Test Case 02 - Calibration in Process on Website}
\label{figure:t02}
\end{figure}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t2_2.png}
\centering
\includegraphics[width=\linewidth]{test_cases/t2_2.png}
\caption{Test Case 02 - CPU Utilization}
\label{figure:t02_2}
\end{figure}
@ -104,10 +107,10 @@ The following test cases are all structured in the same way. The table lists the
\item{The user opens the website in a web browser}
\item{The user clicks on the "Start Calibration" button}
\item{The user then clicks on the new "Stop Calibration" button}
\item{The calibration is stopped and the CPU should not be utilized anymore}
\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 just has been opened.
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.
After stopping the calibration, the CPU utilization also goes back down to normal levels (see \autoref{figure:t03_2}).
\\
@ -116,7 +119,8 @@ The following test cases are all structured in the same way. The table lists the
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t3_2.png}
\centering
\includegraphics[width=\linewidth]{test_cases/t3_2.png}
\caption{Test Case 03 - CPU Utilization after Stopping the Calibration}
\label{figure:t03_2}
\end{figure}
@ -126,7 +130,7 @@ The following test cases are all structured in the same way. The table lists the
\begin{reqTblr}{l p{10.5cm}}
ID & T04 \\
Related Requirement & F02 \\
Description & The user is provided with the option the start calibration in the app.\\
Description & The user is provided with the option to start calibration in the app.\\
Expected Result &
\begin{enumerate}
\item{The user opens the app}
@ -151,14 +155,15 @@ The following test cases are all structured in the same way. The table lists the
\item{The user is shown the current measured magnetic field strength 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 field strength and historical data in a chart. (see autoref{figure:t05}).
\\
\end{reqTblr}
\caption{Test Case 05}
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t5.jpg}
\centering
\fbox{\includegraphics[width=0.4\linewidth]{test_cases/t5.jpg}}
\caption{Test Case 05 - Calibrate Screen in the App}
\label{figure:t05}
\end{figure}
@ -172,11 +177,11 @@ 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{While on the calibration screen the user clicks on the back arrow in the upper left corner}
\item{While on the calibration screen, the user clicks on the back arrow in the top left corner}
\item{The user should be back on the home screen of the app}
\end{enumerate} \\
Actual Result &
After clicking the back arrow inside the calibration screen the user arrives back on the home screen and can choose again between "Receive" and "Calibrate".
After clicking the back arrow inside the calibration screen, the user arrives back on the home screen and can choose again between "Receive" and "Calibrate".
\\
\end{reqTblr}
\caption{Test Case 06}
@ -194,7 +199,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The user can enter any text between 0 and 16 characters}
\end{enumerate} \\
Actual Result &
The user can enter any character in the input they want but they are not able to enter more than 16 characters (see \autoref{figure:t07}).
The user can enter any character in the input they want, but they unable to enter more than 16 characters (see \autoref{figure:t07}).
\\
\end{reqTblr}
\caption{Test Case 07}
@ -202,7 +207,7 @@ The following test cases are all structured in the same way. The table lists the
\begin{figure}[H]
\centering
\includegraphics[width=0.75\linewidth]{test_cases/t7.png}
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t7.png}}
\caption{Test Case 07 - Entering Text on the Website}
\label{figure:t07}
\end{figure}
@ -218,27 +223,29 @@ The following test cases are all structured in the same way. The table lists the
\item{The user clicks into the text input}
\item{The user enters any text between 0 and 16 characters}
\item{The user clicks on "Start Sending"}
\item{When the user hasn't entered any text or the text contains non-ASCII characters a fitting message is displayed and the sending process is not started.}
\item{When the user hasn't entered any text or the text contains non-ASCII characters, a fitting message is displayed, and the sending process is not started.}
\end{enumerate} \\
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}).
In both cases the sending process is not started.
In both cases, the sending process is not started.
\\
\end{reqTblr}
\caption{Test Case 08}
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t8.png}
\centering
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t8.png}}
\caption{Test Case 08 - Validation of Empty Input}
\label{figure:t08}
\end{figure}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t8_2.png}
\centering
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t8_2.png}}
\caption{Test Case 08 - Validation of Invalid Characters}
\label{figure:t08_2}
\end{figure}
@ -257,7 +264,7 @@ The following test cases are all structured in the same way. The table lists the
\item{The user is notified that the sending has started and the text that was entered is sent using the MagSend protocol by stressing the CPU according to the payload}
\end{enumerate} \\
Actual Result &
When the user starts the sending process the "Start Sending" button changes to "Stop Sencing" and a message appears that indicates that the sending is is in process (see \autoref{figure:t09}).
When the user starts the sending process, the "Start Sending" button changes to "Stop Sencing" and a message appears that indicates that the sending is in process (see \autoref{figure:t09}).
In the CPU utilization during the sending, the structure of the preamble and the packet itself can be seen (see \autoref{figure:t09_2}).\\
\end{reqTblr}
@ -265,13 +272,15 @@ The following test cases are all structured in the same way. The table lists the
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t9.png}
\centering
\fbox{\includegraphics[width=0.65\linewidth]{test_cases/t9.png}}
\caption{Test Case 09 - Website when Sending a Message}
\label{figure:t09}
\end{figure}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t9_2.png}
\centering
\includegraphics[width=\linewidth]{test_cases/t9_2.png}
\caption{Test Case 09 - CPU Utilization when Sending a Message}
\label{figure:t09_2}
\end{figure}
@ -286,10 +295,10 @@ The following test cases are all structured in the same way. The table lists the
\item{The user opens the website in a web browser}
\item{The user clicks on the "Start Sending" button}
\item{The user then clicks on the new "Stop Sencding" button}
\item{The sending is stopped and the CPU should not be utilized anymore}
\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 just has 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" and the website should look like if it has just been opened.
After stopping the sending, the CPU utilization also goes back down to normal levels (see \autoref{figure:t10}).
\\
@ -298,7 +307,8 @@ The following test cases are all structured in the same way. The table lists the
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t10.png}
\centering
\includegraphics[width=\linewidth]{test_cases/t10.png}
\caption{Test Case 10 - CPU Utilization after Stopping the Sending}
\label{figure:t10}
\end{figure}
@ -314,10 +324,10 @@ The following test cases are all structured in the same way. The table lists the
\item{The user puts the smartphone on the laptop}
\item{The user clicks on the "Receive" button}
\item{The user starts the sending process on the website}
\item{The app will start the receive 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.}
\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 receiving 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, 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}).
\\
@ -326,22 +336,26 @@ The following test cases are all structured in the same way. The table lists the
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t11.jpg}
\caption{Test Case 11 - Receive Process without any Errors}
\label{figure:t11}
\begin{minipage}{.5\textwidth}
\centering
\fbox{\includegraphics[width=0.8\linewidth]{test_cases/t11.jpg}}
\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}
\label{figure:t11_2}
\end{minipage}
\end{figure}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t11_2.jpg}
\caption{Test Case 11 - Receive Process with Invalid Checksum}
\label{figure:t11_2}
\end{figure}
\begin{table}[H]
\begin{reqTblr}{l p{10.5cm}}
ID & T12 \\
Related Requirement & F05 \\
Description & The user can restart the receive process.\\
Description & The user can restart the reception process.\\
Expected Result &
\begin{enumerate}
\item{The user opens the app}
@ -349,10 +363,10 @@ The following test cases are all structured in the same way. The table lists the
\item{The user clicks on the "Receive" button in the app}
\item{The user starts the sending process on the website}
\item{The user clicks on the "Restart" button in the app}
\item{The app should reset the receive progress to a clean state}
\item{The app should reset the reception progress to a clean state}
\end{enumerate} \\
Actual Result &
When the user clicks on the "Restart" button the received text gets removed and all status informations are reset to their default state.
When the user clicks on the "Restart" button, the received text gets removed and all status information is reset to their default state.
\\
\end{reqTblr}
\caption{Test Case 12}
@ -362,17 +376,17 @@ The following test cases are all structured in the same way. The table lists the
\begin{reqTblr}{l p{10.5cm}}
ID & T13 \\
Related Requirement & F05 \\
Description & The user can stop the receive process.\\
Description & The user can stop the reception process.\\
Expected Result &
\begin{enumerate}
\item{The user opens the app}
\item{The user puts the smartphone on the laptop}
\item{The user clicks on the "Receive" button in the app}
\item{While on the receive screen the user clicks on the back arrow in the upper left corner}
\item{While on the reception screen, the user clicks on the back arrow in the top left corner}
\item{The user should be back on the home screen of the app}
\end{enumerate} \\
Actual Result &
After clicking the back arrow inside the receive screen the user arrives back on the home screen and can choose again between "Receive" and "Calibrate".
After clicking the back arrow inside the reception screen, the user arrives back on the home screen and can choose again between "Receive" and "Calibrate".
\\
\end{reqTblr}
\caption{Test Case 13}
@ -393,14 +407,15 @@ The following test cases are all structured in the same way. The table lists the
\item{The app should still be able to receive messages over MagSend}
\end{enumerate} \\
Actual Result &
Even in airplane mode the app can still receive data over MagSend as this process doesn't use any connectivity but only the inbuilt sensors of the smartphone (see \autoref{figure:t14}).
Even in airplane mode, the app can still receive data over MagSend as this process doesn't use any connectivity but only the inbuilt sensors of the smartphone (see \autoref{figure:t14}).
\\
\end{reqTblr}
\caption{Test Case 14}
\end{table}
\begin{figure}[H]
\includegraphics[width=0.5\linewidth]{test_cases/t14.jpg}
\centering
\includegraphics[width=0.4\linewidth]{test_cases/t14.jpg}
\caption{Test Case 14 - Receive Process in Airplane Mode}
\label{figure:t14}
\end{figure}
@ -419,10 +434,8 @@ 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 to 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. 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}.
\\
\end{reqTblr}
\caption{Test Case 15}
\end{table}
// TODO: Fix up sizing of images

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

@ -68,7 +68,7 @@ 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. CPUs produce a lot of heat when under load and thus they get hotter. When they get to hot, they throttle by reducing clock speeds. This process is designed to protect the CPU from overheating \cite{thermalThrottling}.
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 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}).
@ -78,12 +78,4 @@ The laptop that was used for running the benchmarks, already reaches CPU tempera
\label{figure:cpu_temperatures}
\end{figure}
When MagSend then attempts to sent data by putting even more stress on the CPU, the CPU begins to throttle and the resulting CPU loads gets dampened (see \autoref{figure:throttle}). While longer spikes like the preamble at the start of the packet are still visible, the rest of the message is only noise and really be received.
\begin{figure}[H]
\fbox{\includegraphics[width=1\textwidth]{benchmarking/1bps_25.png}}
\caption{CPU temperatures under 25\% CPU load}
\label{figure:throttle}
\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}.

4
documentation/thesis/content/08_materials_methods.tex
View file

@ -5,11 +5,11 @@ needed:
A laptop, which acts as the sender. This laptop needs to be able to run a
modern web browser which supports the Web Workers API
(see \autoref{section:webworkers}). The operating system is irrelevant as
MagSend is web based.
MagSend is web-based.
An Android smartphone, which acts as the receiver. This phone needs to run at
least Android version 10 to be able to run the MagSend client application.
Furthermore it is required that the phone is equipped with a magnetometer.
Furthermore, it is required that the phone is equipped with a magnetometer.
Most modern smartphones should contain a hall effect sensor for that purpose
(see \autoref{section:hallEffectSensor}).

4
documentation/thesis/content/09_future_work.tex
View file

@ -1,6 +1,6 @@
\chapter{Future Work}
The goal of this thesis was to research and develop a communication method which uses magnetic induction, while using standard components and devices.
The result was a working prototype that allows non-technical users to transmit a message from their laptop to their smartphone wirelessly over with the help of magnetic induction, called MagSend.
The result was a working prototype that allows non-technical users to transmit a message from their laptop to their smartphone wirelessly using magnetic induction, called MagSend.
For future improvements surrounding MagSend, the most important one is to enhance the robustness of the system. While the system generally works, there any many cases where the message doesn't get received, the preamble doesn't get detected or the received message is incorrect. Furthermore when the systems gets more robust it might also be possible to increase the transfer speed of MagSend. In the end the user experience and user interface applications can also be improved by giving more feedback and guidance to the user on how to use MagSend.
For future improvements surrounding MagSend, the most important one is to enhance the robustness of the system. While the system generally works, there are any many cases where the message doesn't get received, the preamble doesn't get detected, or the received message is incorrect. Furthermore, when the system gets more robust, it might also be possible to increase the transfer speed of MagSend. In the end, the user experience and user interface applications can also be improved by giving more feedback and guidance to the user on how to use MagSend.

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

@ -1,15 +1,42 @@
\chapter{Project Management}
\section{Project Plan}
\subsection{Initial 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}.
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.
First I planned to use a speaker as the sending device in MagSend, as a
magnetic field is generated, when a sound is played through the speaker. After
multiple tests and experiments I wasn't able to get useful results from the
speakers and settled on using a CPU after some quick prototypes.
In October, after defining the requirements for the project, my plan fell
apart as I fell ill with COVID-19. I was sick for about 3 weeks and in that
time I wasn't able to work on my thesis. This whole event caused my plan to
shift behind a few weeks. I was generous in my initial planning, which helped
alleviate this issue.
In November, I picked up the pace again and started with the planning and
documentation of the solution, and then started to work on the prototypes for
the sender and receiver. I spent a bit longer on the prototype for the
receiver as in early December I was busy with some other projects and exams.
During the winter break and in early January, I in the process of finishing up
the thesis report and the additional deliverables like the poster and movie. In
the end it was a bit of a crunch to finish everything but thanks to some
generous planning in the beginning it all worked out.
\begin{sidewaysfigure}
\subsection{Initial Plan}
\label{section:plan}
\begin{ganttchart}[
vgrid,
hgrid,
x unit=0.9cm,
y unit chart=0.6cm,
y unit title=0.6cm, % height of title line and gap
x unit=0.8cm,
y unit chart=0.5cm,
y unit title=0.5cm, % height of title line and gap
title height=1 % use full height for title, leaving no gap
]{1}{18}
\gantttitle{Project Plan}{18}
@ -51,14 +78,15 @@
\caption{Project Plan}
\end{sidewaysfigure}
\subsection{Actual Plan}
\begin{sidewaysfigure}
\subsection{Actual Plan}
\label{section:actual_plan}
\begin{ganttchart}[
vgrid,
hgrid,
x unit=0.9cm,
y unit chart=0.6cm,
y unit title=0.6cm, % height of title line and gap
x unit=0.8cm,
y unit chart=0.5cm,
y unit title=0.5cm, % height of title line and gap
title height=1 % use full height for title, leaving no gap
]{1}{18}
\gantttitle{Project Plan}{18}
@ -75,36 +103,76 @@
\\
\ganttbar{Prepare Thesis Document}{1}{2} \\
\ganttbar{Create Project Plan}{1}{2} \\
\ganttbar{Research Other Solutions}{1}{2} \\
\ganttbar{Experiment with Hardware}{1}{2} \\
\ganttbar{Write Introduction}{2}{2} \\
\ganttbar{Define Use Cases \& Personas}{3}{3} \\
\ganttbar{Create Project Plan}{1}{1} \\
\ganttbar{Research Other Solutions}{2}{2} \\
\ganttbar{Experiment with Hardware}{1}{3} \\
\ganttbar{Write Introduction}{3}{3} \\
\ganttbar{Define Use Cases \& Personas}{3}{4} \\
\ganttbar{Define Requirements}{3}{4} \\
\ganttbar{Plan Solution}{5}{6} \\
\ganttbar{Document Solution}{5}{6} \\
\ganttbar{Define Test Cases}{6}{6} \\
\ganttbar{Prepare Hardware for Prototype}{7}{7} \\
\ganttbar{Create Prototype for Sender}{7}{9} \\
\ganttbar{Create Prototype for Receiver}{8}{10} \\
\ganttbar{Testing}{11}{12} \\
\ganttbar{Benchmarking}{11}{12} \\
\ganttbar{Document Materials \& Methods}{13}{13} \\
\ganttbar{Document Future Work}{13}{13} \\
\ganttbar{Create Abstract}{14}{14} \\
\ganttbar{Create Poster}{14}{15} \\
\ganttbar{Create Movie}{16}{16} \\
\ganttbar{Finish Thesis Report}{16}{17} \\
\ganttbar{Prepare Presentations}{17}{18}
\ganttbar{COVID-19}{4}{6} \\
\ganttbar{Plan Solution}{7}{8} \\
\ganttbar{Document Solution}{7}{8}
\ganttbar{}{17}{17} \\
\ganttbar{Define Test Cases}{8}{9} \\
\ganttbar{Create Prototype for Sender}{9}{10} \\
\ganttbar{Create Prototype for Receiver}{11}{13}
\ganttbar{}{15}{15} \\
\ganttbar{Testing}{14}{15} \\
\ganttbar{Benchmarking}{14}{15} \\
\ganttbar{Document Materials \& Methods}{16}{16} \\
\ganttbar{Document Future Work}{16}{16} \\
\ganttbar{Create Abstract}{16}{16} \\
\ganttbar{Finish Thesis Report}{15}{18} \\
\ganttbar{Create Poster}{16}{17} \\
\ganttbar{Create Movie}{18}{18} \\
\ganttbar{Prepare Presentations}{18}{18}
\end{ganttchart}
\caption{Project Plan}
\end{sidewaysfigure}
\newpage
\section{Organization}
All data for the project, including documentation, images, data, and source
code was kept in a single Git repository \cite{MagSendGit}. The documentation
and presentations were written using LaTeX with the official BFH templates.
// TODO: Actual plan
\subsection{Meetings}
In the first week I agreed on weekly meetings with my advisor, unless it
wasn't needed. For the big meetings I created a meeting notes document in
advance, where I wrote down my progress since the last week and questions that
I might have for my advisor. In hindsight, weekly meeting were a bit too
frequent and bi-weekly meeting would have sufficed, but it was useful to have
regular feedback from my advisor.
// TODO: First subject: Speakers
\subsection{Mockups}
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}.
// TODO: Organization / Planning / Mockups / Experiments / Meetings / Sickness
\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.
// TODO: problems / pain points / learnings
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
with my project plan, the individual points, especially the development of the
prototypes were not fully planned. By splitting those tasks up in smaller ones,
I could have planned around them better and might have found some flaws in the
plan.
The other problem was with the debugging and developing of the Android
application. Many times I was testing the receiving of data over MagSend, when
it didn't work, while it worked just in the try before. After much trial and
error I found out that one of the main issues was that the logging capabilities
of Android were quite slow and sometimes delayed the values from the magnetic
sensor and caused wrong results, that didn't appear in normal utilization of
the app. My takeaway from this is, to invest early in good logging and
debugging utilities, especially when dealing with "invisible" data, such as
magnetic fields and to use separate devices for running the applications
as those used for developing them.
In the end, I'm happy with the project and my results. I managed to develop a
custom communication protocol and finish a working prototype in the allotted
time.

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

@ -2,3 +2,4 @@
\newacronym{dom}{DOM}{Document Object Model}
\newacronym{rfid}{RFID}{Radio-frequency identification}
\newacronym{nfc}{NFC}{Near-field communication}
\newacronym{mi}{MI}{Magnetic Induction}

2227
documentation/thesis/data/magnetic_induction_cpu.csv Normal file
View file

File diff suppressed because it is too large Load diff

41
documentation/thesis/listings/receiving_pseudo.py Normal file
View file

@ -0,0 +1,41 @@
// Define constants
preamble = [1, 1, 1, 0, 0, 0, 1, 1, 1]
// Get sensor values
sensor_values = get_data_from_sensor()
value_range = range_of_data(sensor_values)
// Determine for sensor values if they are a high or low signal
signal = []
for value in sensor_values:
// Compare the value with the median of the values with some threshold
if value < median_with_threshold(value_range):
signal += low
else if value > median_with_threshold(value_range):
signal += high
else:
// Discard value
// Filter out single high or low signals
signal = clean_signal(signal)
// Only keep the first of consecutive same signals, as the transitions hold the data
signal = compress_signal(signal)
// Check for preamble in data
if contains(signal, preamble):
// Decode the received manchester encoded bitstream
packet = signal[index(preamble)]
// Read the first four bits of the bitstream to get the header
header = read_bits(packet, 0, 4)
display_header(header)
// Read the next n Bytes of the bitstream, according to the payload length, to get the payload
payload = read_bits(packet, 4, header)
display_payload(payload)
// Read the next byte to get the CRC-8-AUTOSAR checksum of the payload
checksum = read_bits(packet, 4 + header, 8)
show_checksum_result()

38
documentation/thesis/listings/sending_pseudo.py Normal file
View file

@ -0,0 +1,38 @@
// Define constants
preamble = [1, 1, 1, 0, 0, 0, 1, 1, 1]
// Set clock speed
clock_speed = 500
// Get the text from the user
text = get_input()
// Convert the ASCII text to a bit stream
payload = ascii_to_bits(text)
// Calculate the length of the payload in bytes
header = byte_length(payload)
// Calculate the CRC-8-AUTOSAR checksum of the payload
checksum = calculate_checksum(payload)
// Combine the header, payload, and checksum into a packet
packet = to_bits(header) + payload + to_bits(checksum)
// Encode packet using manchester encoding
encoded_packet = manchester_encode(packet)
// Start the transmission by sending the preamble
for symbol in preamble:
if symbol is 1:
stress_cpu(1000)
else:
idle_cpu(1000)
// Transmit the manchester encoded bit stream of the packet
while transmission_not_stopped:
for code_bit in encoded_packet:
if code_bit is 1:
stress_cpu(clock_speed)
else:
idle_cpu(clock_speed)

30
documentation/thesis/thesis.bib
View file

@ -197,8 +197,32 @@
urldate = "2022-01-11",
}
@online{androidStudio,
title = {{Android Studio}},
url = "https://developer.android.com/studio",
urldate = "2022-01-11",
title = {{Android Studio}},
url = "https://developer.android.com/studio",
urldate = "2022-01-11",
}
@online{magneticFluxDensity,
author = "Stan Zurek",
title = {{Magnetic flux density?}},
url = "https://e-magnetica.pl/magnetic_flux_density",
year = 2021,
urldate = "2022-01-15",
}
@online{penpot,
title = {{Penpot - Design Freedom for Teams}},
url = "https://penpot.app/",
year = 2022,
urldate = "2022-01-15",
}
@online{MagSendGit,
author = "Severin Kaderli",
title = {{MagSend}},
url = "https://git.kaderli.dev/severinkaderli/bachelor-thesis",
year = 2022,
urldate = "2022-01-15",
}

5
documentation/thesis/thesis.tex
View file

@ -33,6 +33,7 @@
\usepackage{pgfgantt}
\usepackage{rotating}
\LoadBFHModule{listings}
\usepackage{siunitx}
\sisetup{per-mode=symbol}
@ -62,6 +63,9 @@
\advisor{Dr. Reto König}
\expert{Thomas Jäggi}
\degreeprogram{Bachelor of Science in Computer Science}
\setupSignature{
Severin Kaderli={\includegraphics[width=\linewidth]{signature.png}}
}
%---------------- BFH tile page -----------------------------------------
@ -101,6 +105,7 @@
\listoffigures
\listoftables
\lstlistoflistings
\appendix
\chapter{Task Description}