diff --git a/code/Settings.h b/code/Settings.h index 22bed9e..1b61ed6 100644 --- a/code/Settings.h +++ b/code/Settings.h @@ -12,7 +12,7 @@ namespace Settings { const std::string plotDataDir = "../plots/data/"; const std::string outputDir = "../output/"; - const bool PlotCircles = false; + const bool PlotCircles = true; const bool PlotToPng = false; const bool UseKalman = false; diff --git a/tex/chapters/3_ftm.tex b/tex/chapters/3_ftm.tex index 9fbaed6..850291f 100644 --- a/tex/chapters/3_ftm.tex +++ b/tex/chapters/3_ftm.tex @@ -157,6 +157,7 @@ Assuming that the signal propagates constantly at the speed of light the distanc %TODO ToF -> distance ToF/2 * c %TODO IEEE 802.11-2016 6.3.58.1 + The accuracy of distance estimate depends on the ability of the hardware to detect the line-of-sight signal, or direct path. In an indoor environment it is very common that a signal will reach the receiver from different paths with different lengths. The prime example is a signal which reaches the receiver via a direct line-of-sight propagation plus two reflected paths of the same length. @@ -170,7 +171,7 @@ Hence, the time resolution is proportional to the inverse of the bandwidth. In \ieeWifiN the channel bandwidth is \SI{20}{Mhz} in the \SI{2.4}{GHz} range which results in a sampling rate of one sample every \SI{50}{ns}, or one sample every \SI{12.5}{ns} for \SI{80}{Mhz} channels in the \ieeWifiAC \SI{5}{GHz} range. Assuming that the receiver recognizes the signal at the first sample of the preamble the smallest possible resolution of the range estimate is \SI{15}{m} for \SI{20}{Mhz} bandwidth, and \SI{3.74}{m} for \SI{80}{Mhz}. To allow much finer resolution the receiver uses super resolution methods to allow sub-sample resolution \cite{TODO}. - +%TODO genaue implementierung unbekannt und daher black box %Therefore, time-based distance estimates can greatly differ from the ideal euclidean distance. In addition to distance measurements the \ieeWifiFTM standard defines a format to transfer location information about the responder. diff --git a/tex/chapters/8_experiments.tex b/tex/chapters/8_experiments.tex index 2da25bb..d74b896 100644 --- a/tex/chapters/8_experiments.tex +++ b/tex/chapters/8_experiments.tex @@ -2,35 +2,116 @@ \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} +%\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. -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. \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} +%\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} diff --git a/tex/gfx/placeholder/DistMeasCDF.png b/tex/gfx/placeholder/DistMeasCDF.png new file mode 100644 index 0000000..fe6b134 Binary files /dev/null and b/tex/gfx/placeholder/DistMeasCDF.png differ diff --git a/tex/gfx/placeholder/DistMeasMean.png b/tex/gfx/placeholder/DistMeasMean.png new file mode 100644 index 0000000..8ed5546 Binary files /dev/null and b/tex/gfx/placeholder/DistMeasMean.png differ