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:
- ) ein AP kann in einem Fahrzeug installiert sein.
- ) ein AP kann sich [zeitweilig] an einem anderen Ort befinden,
- ) weil der Besitzer umgezogen ist.
- ) weil der AP verkauft/verschenkt wurde.
- ) weil er temporär an einem anderen Ort genutzt wurde (z.B.
LAN-Party).
- ) ein AP kann von einem mehrere Kilometer entfernt gelegenen
Ort gesehen werden,
- ) weil er sehr hoch angebracht ist (z.B. Windrad).
- ) weil er nah an einer Bucht, einem größeren See oder mitten
auf einem sehr großen flachen Acker aufgestellt ist.
- ) 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):
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):
Nur die dbm_best-Kurve. Auch nicht gerade schön - aber
besser:
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:
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.
