\section{Experiments}

\subsection{Setup and Environment}

%\begin{itemize}
%	\item Pixel 2XL Android P liefert RSSI und FTM
%	\item 4 Intel NUCS mit selbstgebauten Antennen (Auf Ibrahim verweisen aber auch genau erläutern, eventl mit Bild)
%	\item Gebäude erläutern. Bürogebäude in Industriegebiet. Holzhaus. Gebäude war Leer um eine optimale menschenleere Umgebung zu schaffen. Größe XxX. -> Bild mit AP Positionen (gerne von unten linken wo ergebnisse drauf sind, spart platz)
%	\item FH Gebäude erläutern. -> Bild mit AP Positionen (gerne von unten linken wo ergebnisse drauf sind, spart platz)
%	\item Zweites Gebäude weil: Verhält es sich in einem anderen Gebäude genauso? Also AP's ähnlich positionieren, aber andere umgebung (wände, räume usw.). 
%	\item Position wurde auf einem Stockwerk geschätzt, also nur 2D. 
%	\item Nuc steht auf einem Tisch
%	\item die messungen kommen immer gleichzeitig von ftm und rssi. dadurch ist die sampelrate die gleiche und wir können besser vergleichen
%\end{itemize}
%
%
%Mapping zwischen AP-MAC und Position ist gegeben.
%In Android Q könnte man LCI am Ap hinterlegen um die AP-Pos dynamisch zu erfragen.
%Praktische Einschräkungen: Da Wifi Scans nur selten möglich sind, können neue FTM APs nicht leicht erkannt werden.
%AUßerdem muss per Reflection ScanResults für bereits bekannte APs MAC erzeugt werden.
%Für eine parktische Anwendung wäre es nochtwenig, dass neue APs automatisch on the fly erkannt werden können.

In all our experiments we used a Google Pixel 2 XL and Google Pixel 3a smartphone, both running Android~9.
Google introduced official ranging APIs based on FTM for supported devices with Android~9.
Also starting with Android~9, Google limited the number of network scans to four every two minutes.
This limitation renders the commonly used network scanning API practical useless for measuring RSSI values for localization purposes.
However, the new FTM ranging API has no rate limit.
Additionally, the new FTM API also provides RSSI values, thus with each measurement the signal strength and distance to one AP can be simultaneously obtained.

In our experiments every \SI{200}{ms} a FTM measurement to every known access point is queried.
The list of access points is statically stored in the application and known beforehand.
With Android~10 it is possible to transfer the AP position dynamically using the location configuration information protocol.
In some cases we noticed that Android did not provide FTM measurements for intervals about three up to five seconds long for unknown reasons, although multiple APs were clearly in reach.
Due to the rarity of this problem we decided to repeat these faulty experiment runs.

% TODO welche Daten liefert Android. Wie die konkret gemessene Distanz entshtet ist nicht bekannt. Android teilt mit wieviele FTM Messungen erfolgreich waren z.b. 7/8. etc.

% TODO Linux kernel version; intel firmware version
The access points are Intel NUCs running a patched Linux to enable FTM support.
In total we're using eight APs based on Intel WiFi cards.
Four of them are based on Intel Dualband-Wireless-AC 8260 cards and configured as described by \etal{Ibrahim} \cite{ibrahim2018verification}.
The remaining four are based on Intel Wireless-AC 9462 modules and run a recent Linux kernel where the iwlwifi driver and hostapd are already prepared to support FTM.
However, the driver still requires small manual changes, as a global boolean flag needs to be set to activate the FTM related code.
In addition, the firmware of the card returns that the chip is not calibrated for FTM.
As a consequence the driver disables FTM responder functionality.
Overriding this check however, allows to use the chip as responder and FTM measurements can be performed reliable.
At this point it is not clear to us what the exact purpose of the flag is.
Due to regulatory limitations both wireless cards can only be configured as access points in the \SI{2.4}{GHz} frequency band.

To improve the signal quality and strength we connected two external consumer grade omni directional antennas to the wireless cards and attached them to the case of the Intel NUC.
The antennas have an antenna gain of \SI{2}{dBi} as specified by the manufacturer.
We used a \SI{10}{cm} coaxial cable to connect the antennas to the cards, which is practically the shortest cable possible.

All experiments were done in our university building.
The before mentioned Intel NUCs were deployed, because the existing WiFi infrastructure does not support the FTM protocol.
While the positions of the access points where chosen with localization in mind, the actual positions mimic the placement of access points for network infrastructure.
In contrast to regular stationary access points which are usually mounted on walls or ceilings, our Intel NUCs were placed on tables for practical reasons.



\subsection{Ftm range meas performance}
%\begin{itemize}
%    \item AP position strategy 
%    \item DoP plot 
%    \item wieviel APs sichtbar sind, wie kommen die Ranges, welche Parameter machen was und bedeuten was
%    \item Einfluss der Wände; warum starke Abschwächungen
%    \item Welche Platzierung wäre besser; Warum nicht möglich?
%    \item Daher Proabilistic Ansatz weil viele Messungen fehlen oder stark schwanken
%    \item Mehr APs bringen was?
%    \item Bildergrid und Video
%\end{itemize}

The first experiment evaluates the precision of FTM distance measurements given different hardware configurations.
While \etal{Ibrahim} already verified the precision of the Intel AC 8260 card in great detail, our setup differs from theirs and requires anew evaluation.
In contrast to \etal{Ibrahim} we use smartphones as receivers and two different cards with different firmware versions as senders.
Additionally, it is unclear how the external antennas affect the measurements.
For these reasons we did a static distance measurement experimental setup to confirm that the combination of Pixel devices and Intel cards provide reliable values. 


Our test setup consist of 10 measurement points evenly spaced on a straight line with a distance of \SI{2}{m}.
The closest point to the AP is \SI{2}{m} away and the furthest \SI{20}{m}.
At every point each phone is placed on a stand and around 140 FTM measurements are recorded, which corresponds to a measure period of \SI{30}{s} per point.
The APs and the phones are placed on an empty cardboard box on a metal stand to allow some distance between the metal and the phone.
Both the APs and the phones are located at \SI{1.05}{m} above the floor.
While recording measurements for \SI{30}{s} at a single point is not realistic in a dynamic positioning system, it allows to evaluate the statistical properties of the method.

Each distance measurement is done with every hardware combination.
On the receiving side we used the Google Pixel 2 XL and Pixel 3a.
On the sending side we used the Intel AC 8260 and 9462 with internal or external \SI{2}{dBi} antennas.
The geometry and properties of the internal antenna are unknown.

% TODO Table mit mean dist err, median dist err und mean RSSI

% Erkenntnis 1: 9462 bessere schätzung, weniger Messungen die zu kurz sind; 8260 viele Messungen bei <16m sind zu kurz; Zusammenhang mit 15m wegen Sampling Rate?
% Erkenntnis 2: Unterschied der Antennen bei RSSI minimal langweilig; 
% Erkenntnis 3: Antenne vs FTM: Keine Aussage möglich
% Erkenntnis 4: Unterschied zwischen Pixel 2 und 3 ist nicht erkennbar


\begin{figure}[ht]

\begin{minipage}[t]{0.5\textwidth}
  \centering
  \includegraphics[width=1\textwidth]{DistMeasMean.png}
  \caption{Mean distance}   
\end{minipage}
\begin{minipage}[t]{0.5\textwidth}
  \centering
  \includegraphics[width=1\textwidth]{DistMeasCDF.png}
  \caption{Dist. Meas CDF}   
\end{minipage}

\end{figure}


\subsection{Localization performance}
\begin{itemize}
    \item Location error per method (multilateration, prob, particle filter)
    \item Wie gut geht der PF? Parameter und Szenarien
    \item RSSI vs FTM; wo ist FTM besser wo schlechter?; Verhält es sich ähnlich?
\end{itemize}

\subsection{Results for Multilateration}
zunächst wird das einfachste und nahliegendste verfahren untersucht um die performance von ftm und rssi gegenüberzustellen.

\begin{itemize}
	\item Parameter einführen und erklären
	\item Unterschied FTM und RSSI bei diesem Verfahren
	\item Positioning Error
	\item Wie sieht der geschätzte Pfad aus
	\item FTM ist nicht wie erwartet mega viel besser als RSSI. die simple literation glättet einfach gar nichts, weswegen... (hier begründung einfügen)
\end{itemize}

wir bekommen hier also das gefühl, das ftm irgendwie besser sein muss, aber können es noch nicht wirklich nutzen. weshalb nun der probabilistische approach angesehen wird.

\subsection{Results for Probabilistic Approach}

multilateration verfügt über keinerlei glättung, das einfach probablistische verfahren bietet das. verlgeicht man fig. x und fig. y kann man das schön sehen.

\begin{itemize}
	\item Parameter einführen und erklären
	\item Unterschied FTM und RSSI bei diesem Verfahren
	\item Positioning Error
	\item Wie sieht der geschätzte Pfad aus
	\item FTM setzt sich langsam ab und wird ein gutes stück besser als Rssi
\end{itemize}


\subsection{Results for Particle Filtering}
der einsatz der probablistischen methode sieht weitaus besser azs als multilateration weil wir eine glättung der daten ermöglichen. es fehlt aber informationen über die vergangenheit. der particle filter bietet das.

\begin{itemize}
	\item Parameter einführen und erklären
	\subitem filter updated pro neuer messung. kann man natürlich auch anders machen. nachdem wir aber eine so simple transition haben, ist es egal.
	\item Unterschied FTM und RSSI bei diesem Verfahren
	\item Positioning Error
	\item Wie sieht der geschätzte Pfad aus
	\item Hier werden die Ergebnisse langsam richtig gut. Also FTM ist weitaus besser als RSSI. Warum ist das so? (Filter hat die Vergangenheit mit drin, FTM ist somit auf Dauer stabiler und streut deswegen nicht so stark wie RSSI).
\end{itemize}


\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM.png}
\caption{Path 2 FTM, Pixel 2 mean 4.94778 stdDev 2.49081 median 4.88544 count 249}
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM_Error.png}
\caption{Path 2 Error FTM, Pixel 2 }
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_RSSI.png}
\caption{Path 2 RSSI, Pixel 2 mean 5.33965 stdDev 2.68662 median 5.22802 count 249}
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_RSSI_Error.png}
\caption{Path 2 Error RSSI, Pixel 2}
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM_RSSI_Error.png}
\caption{Path 2 Error FTM / RSSI, Pixel 2}
\end{figure}

Unterscuhen ob die Abweichung nach untne daher kommt weil die Brandschutztür stört


\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{VersuchsaufbauBST1.png}
\caption{}
\end{figure}

\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{VersuchsaufbauBST2.png}
\caption{}
\end{figure}

\subsection{Comparison and Discussion}
Hier vergleichen wie sich die einzelen Verfahren untereinander unterscheiden und welche Vor / Nachteile sie haben. Jeweils für RSSI und FTM. (Vorher haben wir RSSI und FTM gegenübergestellt innerhalb der Verfahren und jetzt stellen wir die einzelnen Verfahren gegenüber und diskutieren deren Unterschied in Bezug auf die WI-Fi methoden)


\begin{itemize}
	\item multilateration ist an sich schon ein schlechtes verfahren, man kann aber sehen das ftm schon etwas besser wird. verfolgt man den gedanken über die weiteren verfahren, sieht man schnell wie sich FTM von der Leistung her absetzt und durch die besseren verfahren auch eine besser lokalisiierungsleistung bringt.
	\item Tabelle, wo alle Ergebnisse nochmal zusammen sind.
	\item Wichtige Erkenntnisse: 
	\subitem wenn man sehr nah dran ist, ist die messung nicht wirklich gut bei FTM.
	\subitem FTM ist vom setup weitaus einfacher als rssi, weil es die dämpfung etc. pp nicht so wichtig nimmt.
\end{itemize}


