home     Inhaltsverzeichnis
erste Version am 16.07.2017
letzte Änderung am 25.07.2017

Raspberry Pi als GPS-Tracker
Seite 5


Berechnung des AccessPoint-Standortes

Nun will ich mich mal darum kümmern, den Standort eines AccessPoints (AP) aus seinen Sichtungs-Koordinaten allgemeiner herzuleiten.
Bisher wurden dazu alle Sichtungs-Koordinaten eines APs herangezogen, die Wertigkeit einer Koordinate anhand ihres jeweiligen Dämpfungs-Wertes angepasst, alles addiert und final durch die Anzahl geteilt.
Das klappt zwar meistens ganz passabel, berücksichtigt jedoch noch nicht die Problemfälle:
  1. ) ein AP kann in einem Fahrzeug installiert sein.
  2. ) ein AP kann sich [zeitweilig] an einem anderen Ort befinden,
    1. ) weil der Besitzer umgezogen ist.
    2. ) weil der AP verkauft/verschenkt wurde.
    3. ) weil er temporär an einem anderen Ort genutzt wurde (z.B. LAN-Party).
  3. ) ein AP kann von einem mehrere Kilometer entfernt gelegenen Ort gesehen werden,
    1. ) weil er sehr hoch angebracht ist (z.B. Windrad).
    2. ) weil er nah an einer Bucht, einem größeren See oder mitten auf einem sehr großen flachen Acker aufgestellt ist.
  4. ) auf mehreren APs kann die selbe SSID eingestellt sein (vom Nutzer absichtlich so konfiguriert).
All diese Fälle habe ich bereits in der Datenbank - sehr wahrscheinlich zumindest. Allerdings beruht das auf manueller Interpretation der gesammelten Daten. Und es hat bei einzelnen AP-Sichtungen z.T. mehrere Minuten gedauert, bis sämtliche Daten so zueinander in Beziehung gebracht waren, dass sich ein plausibles Gesamtbild daraus ableiten ließ. Idealerweise soll das zukünftig insofern vollautomatisch gehen, dass am Ende höchstens eine handvoll APs übrig bleiben, die sich dann im Status "suspekt" befinden.


Der Problemfall 1. ließe sich ziemlich sicher dadurch identifizieren, dass ein AP bei einer Tour an sehr unterschiedlichen Orten gesehen wurde (und nicht 3. gilt). Allerdings wird dieser Fall wohl sehr selten eintreten. Wird er bei unterschiedlichen Touren immer an sehr unterschiedlichen Orten gesehen (und nie am selben Ort), ist dies ebenfalls ein Indikator für den 1. Fall. Umgedreht lässt sich der 1. Fall nicht sicher dadurch ausschließen, dass er auf mehreren Touren am selben Ort gesehen wurde - es könnte sich dabei schließlich um den heimischen Parkplatz handeln.

Fall 2.1 und 2.2 sind quasi identisch, bei 2.2 wurde der AP vielleicht zusätzlich umbenannt (andere ESSID). In beiden Fällen wird der AP auf mindestens zwei Touren an einem Ort gesehen, ab einer bestimmten Tour dann mindestens auf zwei Touren an einem anderen Ort. Jedoch wird diese Sequenz eher selten, bzw. nur bei häufig gesehenen APs erkannt werden können.
Es könnte aber reichen, nur die jüngsten Touren zu betrachten: wenn der AP auf den jungen Touren mehrfach und ausschließlich an einem Ort gesehen wurde, befindet er sich jetzt an diesem Ort. Dabei muss jedoch die Dämpfung berücksichtigt werden. Ansonsten könnte ein in letzter Zeit häufig passierter Ort als neuer Standort angesehen werden, obwohl alle neuen Sichtungen eine sehr viel höhere Dämpfung aufweisen, als am ursprünglichen Ort - und nur Fern-Sichtungen des ursprünglichen Standorts sind.

Wenn ein AP auf mindestens zwei Touren an mehreren deutlich unterschiedlichen Orten erneut gesehen wurde, wird es ziemlich sicher Fall 4. sein. Ansonsten hätte er ja während beider Touren von seinem Besitzer (zeitgleich zu meinen Touren) jeweils von dem einen Ort an den anderen gebracht werden müssen.

Der Fall 2.3 sollte dadurch identifizierbar sein, dass ein AP auf mehreren Touren an deutlich unterschiedlichen Orten pro Tour jeweils einmalig gesehen wurde und das Sichtungs-Areal pro Tour klein ist. Wobei ich auch einen AP in der Datenbank habe, der bei fünf Touren gesehen wurde und bei der ältesten Tour in Glücksburg in einer Arztpraxis (gemäß ESSID) stand. Bei der zweitältesten stand er in Flensburg Jürgensby (gut 8 km Luftlinie entfernt, bei einer anderen Arztpraxis) und hatte eine geänderte, nichtssagende ESSID. Bei den restlichen Touren wurde er wieder in Glücksburg gesichtet und hatte seine alte "Praxis FooBar"-ESSID.


Ließe sich für eine Koordinate ihre Höhe über NN zuverlässig ermitteln, könnte damit die Plausibilität von Fern-Sichtungen besser beurteilt werden. Die Höhe eines Installationsortes wird sich darüber zwar eher nicht herleiten lassen (z.B. auf Hochhaus oder Windrad). Aber Wasserflächen wie etwa die Flensburger Förde könnten ggf. erkannt und entsprechend berücksichtigt werden.
Die Daten gibt es z.B. hier. Oder hier per API und hier Doku dazu. Allerdings kommt da recht bald ein:
You have exceeded your daily request quota for this API. We recommend registering for....
Und dann gehts da mit Account und Billing weiter. Allein deswegen müsste das -wenn überhaupt- mit OSM gehen.

Aber so werde ich nicht weiter kommen....ich muss das irgendwie systematischer angehen.
Vielleicht sollte ich erst mal die erkennbaren Umstände sammeln:
- die Anzahl der Touren, bei denen ein AP gesehen wurde,
- die Orte mit der geringsten Dämpfung (pro Tour) von einem AP,
- die zeitliche Reihenfolge der Sichtungen eines APs,
- die Größe des Sichtungs-Areals pro Tour,
- die Größe des Sichtungs-Areals über alle Touren, bei denen der AP gesehen wurde und
- die Entfernung der pro Tour gebildeten Sichtungs-Mittelpunkte zueinander.
Und noch etwas trickiger:
- die Verteilung der Sichtungspunkte im Sichtungs-Areal pro Tour, um darüber
- die Anzahl der Sub-Areale (getrennte Sichtungs-Häufungen) pro Sichtungs-Areal pro Tour herzuleiten.

Anhand der Anzahl und Größe der Sichtungs-Areale mehrerer einzelner nah beieinander liegender BSSIDs pro Tour ließe sich vielleicht auf die Funkwellen-Ausbreitungs-Güte eines Ortes schließen. Also zur Unterscheidung, ob ein Ort eher "eng besiedelt" oder "flacher Acker" ist. Insofern könnte es sogar nützlich sein, zur Bestimmung eines AP-Standortes die Daten anderer APs aus der näheren Umgebung heranzuziehen.

Im Endeffekt läuft alles darauf hinaus, für einen konkreten Ort beurteilen zu können, ob eine Sichtung an einem soundso weit entfernten Ort plausibel sein kann, oder nicht. Wenn sie nicht plausibel ist, muss nur noch zwischen "moved", "moving" und "cloned" unterschieden werden.
Und dann stellt sich noch die Frage nach der Darstellung auf der Map. Zumindest solange der Standort-Bestimmungs-Algorithmus nicht final und endgültig zuverlässig arbeitet (also quasi ewig), sollten verworfene Sichtungspunkte auf der Map erkennbar sein. Die angezeigte AP-Position sollte sich stark an der jüngsten Sichtung orientieren.

Bei der Daten-Analyse ist mir gerade aufgefallen, dass sich die Berechnung des AP-Standortes noch deutlich verbessern ließe, wenn statt der einfachen Mittelwert-Bildung mit dbm-Wert-Berücksichtigung ein Algorithmus verwendet würde, der die Sichtungspunkte mit ihren dbm-Werten so zueinander in Beziehung setzt, dass dabei ein AP-Standort herauskommen kann, der komplett außerhalb des von Sichtungspunkten umschlossenen Gebietes liegt.
Das Szenario dazu sieht z.B. so aus, dass die Sichtungspunkte von einem AP auf zwei Straßen liegen, die zueinander einen stumpfen Winkel bilden.
Auf der einen Straße ergeben die dbm-Werte der Sichtungspunkte eine Glockenkurve. Auf der andere Straße steigen sie halbwegs linear in Richtung der Kreuzung. In diesem Fall wird der AP-Standort wahrscheinlich nicht im stumpfen Winkel zwischen den zwei Straßen liegen, sondern eher in der Verlängerung der Straße mit den linear steigenden dbm-Werten.
Bei der Implementierung könnten Paare aus zeitlich aufeinander folgenden Sichtungspunkten gebildet und mit ihrem dbm-Wert als Richtungsvektor betrachtet werden. Der jeweils größere dbm-Wert zeigt in Richtung AP-Standort.
Andererseits wird das nur funktionieren, wenn für alle Sichtungspunkte gleiche Voraussetzungen gälten. Praktisch werden jedoch bei einigen Sichtungspunkten Gebäude, hohe Fahrzeuge oder Bäume den dbm-Wert verschlechtern und bei anderen nicht.
Folglich kann der dbm-Wert nicht zuverlässig als Maß der Entfernung zum AP-Standort verwendet werden.


eine Messreihe

Eben habe ich eine sehr kurze Messreihe erstellt. Sehr kurz deswegen, weil es zu nieseln anfing und mein Test-AccessPoint nicht wetterfest ausgelegt war.
Erste Vorab-Erkenntnis: der Alfa funktioniert zwar wunderbar als WLAN-Scan-Device, als AccessPoint will er jedoch nicht.
Und wenn man ihn befragt, dann sagt einem der Alfa auch:
dede@rp1:~$ iw list
[...]
Supported interface modes:
     * IBSS
     * managed
     * monitor
[...]
Tja...unerwartet...aber egal. Den zweiten Alfa hatte ich eh primär als Ersatz für den Fall des Ausfalls vom ersten beschafft.
Daher wurde es für diesen Zweck ein anderer WLAN-Stick .... aus meinem mittlerweile üppigen Fundus von WLAN-Sticks.
Der Stick von Adattatore lässt sich problemlos als AccessPoint konfigurieren. Hier liefert der iw list auch den AP-Modus:
dede@rp1:~ $ iw list
[...]
Supported interface modes:
     * IBSS
     * managed
     * AP
     * AP/VLAN
     * WDS
     * monitor
     * mesh point
[...]
Somit bestand mein Test-AccessPoint aus einem Raspberry Pi (Model B Version 1), dem USB-WLAN-Stick von Adattatore und einer USB-Powerbank.
Das habe ich auf eine (gerade frisch zu OSM zugefügte) Sitzbank am Wegesrand gelegt und bin erstmal 150m gen Osten geradelt, habe gedreht und dann 250m zurück gen Westen. Leider kamen da die ersten Tropfen vom Himmel. Also wieder 100m zurück, AccessPoint eingesammelt und ab nach Hause.
So sieht die Tour in wxOSM aus (Bild anklicken für volle Größe):
Screenshot
Die blauen Punkte kennzeichnen die Sichtungsorte, der daraus berechnete AP-Standort ist der grüne Punkt unter dem Mauscursor und die Linie folgt den vom Kismet-Server erzeugten Trackpunkten.

Ergebnis: bei der Tour wurde genau ein AccessPoint mit 116 Sichtungspunkten gesehen. Parallel wurden 283 Trackpunkte erzeugt.
Na gut, genauer gesagt sind 116 Sichtungspunkt-Sätze in der Datenbank gelandet. Die DB sorgt dafür, dass bei identischen Geo-Koordinaten pro Tour nur ein Satz mit entsprechenden Werten für dbm_best und dbm_worst angelegt wird. Daher die deutliche Abweichung zur Trackpunkt-Anzahl. Im gpsxml-File befinden sich 595 Sichtungs-Zeilen für "00:19:86:81:17:AF".
Die dbm-Range über alle Sätze beträgt -4 bis -76.
Unerfreulicherweise sind genau das auch die Werte von dbm_best und dbm_worst bei den ersten und den letzten Sätzen - bei denen sich mein Rad bzw. Warbiking-Equipment direkt neben dem AccessPoint befand.
Also sowas hier findet sich im gpsxml-File:
<gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909449" time-usec="65167" lat="54.807991" lon="9.542542" spd="0.010000" heading="98.410004" fix="3" alt="49.000000" signal_dbm="-76" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909449" time-usec="167547" lat="54.807991" lon="9.542542" spd="0.010000" heading="98.410004" fix="3" alt="49.000000" signal_dbm="-56" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909449" time-usec="577183" lat="54.807991" lon="9.542542" spd="0.010000" heading="98.410004" fix="3" alt="49.000000" signal_dbm="-11" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909450" time-usec="908414" lat="54.807991" lon="9.542542" spd="0.041000" heading="98.410004" fix="3" alt="49.099998" signal_dbm="-53" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909451" time-usec="10797" lat="54.807991" lon="9.542542" spd="0.041000" heading="98.410004" fix="3" alt="49.099998" signal_dbm="-71" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909451" time-usec="113190" lat="54.807991" lon="9.542542" spd="0.000000" heading="98.410004" fix="3" alt="49.099998" signal_dbm="-53" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909451" time-usec="215615" lat="54.807991" lon="9.542542" spd="0.000000" heading="98.410004" fix="3" alt="49.099998" signal_dbm="-4" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909451" time-usec="932432" lat="54.807991" lon="9.542542" spd="0.000000" heading="98.410004" fix="3" alt="49.099998" signal_dbm="-65" noise_dbm="0"/>
Die Werte für lat und lon sind identisch, aber signal_dbm dreht frei....(nach rechts scrollen).
Gut. Praktisch nutze ich den dbm_worst bisher nicht. Das wäre also kein Problem.
Allerdings gibt es auch Sichtungspunkte, die nur einen Meter weiter entfernt liegen und bei denen dbm_best mit -62 gespeichert wurde.
Konsequenterweise sind auch die weiter entfernt gemessenen dbm-Werte nicht vollständig linear zur Entfernung steigend.

Höchst unschön....so sieht es aus, wenn man dbm_best und dbm_worst in LibreOffice lädt und als Kurve darstellen lässt (die dbm-Werte wurden *-1 genommen):
dbm_best und dbm_worst als Kurve dargestellt

Nur die dbm_best-Kurve. Auch nicht gerade schön - aber besser:
nur dbm_best als Kurve dargestellt

Immerhin ist hier halbwegs erkennbar, dass sich mein Rad bei den Punkten 1-3, 71 und 112-116 an der selben lon-Koordinate befand, wie der RaspTestAP.
Am Punkt 35 habe ich den ersten 180°-Schwenk gemacht, am Punkt 87 den zweiten.

Sehr interessant finde ich, dass an den Kurven nicht deutlicher erkennbar ist, ob ich mich vom AP weg oder darauf zu bewege. Schließlich stört mein Körper die direkte Sichtverbindung zwischen Antenne und AP, wenn ich den AP hinter mir habe bzw. mich davon weg bewege. Na gut...die Kurve steigt etwas steiler, als sie sinkt.

Ebenfalls fehlt mir eine deutliche Verschlechterung der Werte beim zweiten Wendepunkt. Da gibts nämlich einen kleinen Hügel und am westlichen Wendepunkt konnte ich die Bank mit dem AP nicht mehr sehen. Aber: meine Augen befinden sich ca. einen halben Meter oberhalb von der Antenne - die neben der Lenker-Stange angebracht ist und ein paar Zentimeter darüber hinaus ragt.
Der westliche Wendepunkt ist leicht am heading-Wert zu erkennen, der von 290° über 8° nach 100° wechselt (nach rechts scrollen):
<gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909342" time-usec="55207" lat="54.808086" lon="9.540790" spd="1.049000" heading="290.049988" fix="3" alt="40.200001" signal_dbm="-64" noise_dbm="0"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909343" time-usec="111209" lat="54.808086" lon="9.540790" spd="1.049000" heading="290.049988" fix="3" alt="40.200001"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909344" time-usec="216851" lat="54.808098" lon="9.540783" spd="1.466000" heading="7.830000" fix="3" alt="39.099998"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909345" time-usec="315928" lat="54.808102" lon="9.540832" spd="2.536000" heading="83.790001" fix="3" alt="38.799999"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909345" time-usec="24855" lat="54.808102" lon="9.540832" spd="2.536000" heading="83.790001" fix="3" alt="38.799999" signal_dbm="-63" noise_dbm="0"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909345" time-usec="127263" lat="54.808102" lon="9.540832" spd="2.536000" heading="83.790001" fix="3" alt="38.799999" signal_dbm="-63" noise_dbm="0"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909346" time-usec="376940" lat="54.808109" lon="9.540874" spd="2.922000" heading="91.739998" fix="3" alt="38.700001"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909347" time-usec="444739" lat="54.808105" lon="9.540920" spd="3.303000" heading="97.550003" fix="3" alt="39.099998"/> <gps-point bssid="GP:SD:TR:AC:KL:OG" time-sec="1500909348" time-usec="531630" lat="54.808105" lon="9.540967" spd="3.575000" heading="99.870003" fix="3" alt="39.099998"/> <gps-point bssid="00:19:86:81:17:AF" source="00:19:86:81:17:AF" time-sec="1500909348" time-usec="270482" lat="54.808105" lon="9.540967" spd="3.575000" heading="99.870003" fix="3" alt="39.099998" signal_dbm="-68" noise_dbm="0"/>
Der altitude-Wert liegt an diesem Punkt (49-39=) 10 Meter unterhalb von dem, der am AP-Standort registriert wurde.
Etwa so:
Schema-Bild
Das würde ja heißen, dass die Funkwellen quasi unbeeindruckt durch ein paar Meter Erde und Teer-Straßenbelag gehen.
Oder dass sie von den dichten Gebüschen, die an beiden Seiten der Straße wachsen, so reflektiert werden, dass sie einen Bogen bilden.
Beides finde ich ziemlich abwegig.....sonderbar...sonderbar.

Weiter zu Seite 6.