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

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