GPS-Dekodierung gelandeter Vaisala SGP-Sonden mit dem Zilog-Decoder

Problem und erste Erfahrungen
Gelandete SGP-Sonden gelten allgemein als nicht auffindbar nach ihrem GPS-Signal. Das hat vor allem damit zu tun, dass die GPS-Helix-Antenne der Sonde nach der Landung nicht mehr korrekt nach oben ausgerichtet ist und lokale Hindernisse den Himmel teilweise abschatten, was den GPS-Empfang verschlechert. Darauf scheint das in Sondenjägerkreisen sehr populäre Programm Sondemonitor besonders allergisch zu reagieren. Ich habe in der letzten Zeit mit die Signale gelandeter Sonden mit dem Zilog-Decoder decodiert und sehr positive Erfahrungen gemacht:

Fazit: Die Lokalisation von gelandeten SGPs ist mit dem Zilog-Decoder meistens problemlos möglich. Wir haben es mehr mit einem Sondemonitor-Problem zu tun haben und weniger mit einem SGP-Problem. Sondemonitor ist ein sehr schönes, vor allem komfortables Programm, und man braucht es auch, aber zum Auffinden der SGP-Sonden am Boden ist es nicht geeignet:

Ich habe ein paar Experimente gemacht und in letzter Zeit eine Reihe von SGPs am Boden nur nach ihren GPS-Koordinaten gefunden. Auch habe ich Sondemonitor-RAW-Dateien einiger früher durch Peilen gefundener Sonden nachträglich dekodiert und deren Positionen überprüft. In einige Fällen, wo ich die Sonde nicht gefunden hatte, wusste ich danach, warum ich erfolglos blieb. Bei anderen konnte ich genauer ergründen, wie man die Qualität des GPS-Signals genauer analysieren kann, was sich als wichtig herausstellte.

Lösung

Der Zilog-80-Decoder liegt als als Sourcecode auf Github vor. Man muss den Quellcode komplilieren und kann dann aufgezeichneten Mitschnitte des Sondensignals decodieren. Als Eingabefile kann man hier entweder eine mitgeschnittene WAV-Datei aus SDRsharp verwenden, oder man nutzt eine Rawdatei aus Sondemonitor. Meist versuch ich beides. Die Ergebnisse werden in einer Textdatei abgelegt. Das Programm wird auf der Kommandozeile bedient - was nicht allzu komfortabel ist. Um das zu erleichtern, habe ich die Quellen in Windows kompiliert und füge dem Paket auch die von mir verwendeten Batch-Dateien bei, die die Bedienung etwas erleichtern.

Wenn ich die Landephase aus z.B. 20km Distanz mitschneide, kann ich typischerweise die Sonde bis in Baumwipfelhöhe erfassen, was oft bereits das Auffinden der Sonde im Gelände ermöglicht. Da sind die 80-100m mehr an Genauigkeit als bei Sondemonitor schon ein Segen. Daher jage ich solche Daten inzwischen sofort nach der Landung durch den Zilog-Decoder.

 
Landeanflug nach Empfang aus ca. 18km Entfernung. Letzte GPS-Höhe 100.5 m, entspricht ca. 60m über Grund, bei annähernder Windstille am Boden. d= ca. 2.5, DOP= ca. 1.7. Der Marker zeigt die Auffindeposition der Sonde, die Spuren von Sondemonitor und Zilog sind dargestellt.  Man beachte die Pendelbewegungen der Sonde in der Zilog-Lösung. Kartendaten: © OpenStreetMap-Mitwirkende, SRTM | Kartendarstellung: © OpenTopoMap (CC-BY-SA)

Bei den meisten gelandeten SGPs liefert Zilog verwertbare GPS-Koordinaten. Ein Vorteil ist auch, dass man die Qualität der Daten recht gut abschätzen kann und gute und schlechte Ergebnisse relativ einfach unterscheiden kann.

Erfahrungen
Von meinen letzten 12 SGP-Sonden, die ich am Boden sendend angetroffen habe, hörten 2 auf zu senden, unmittelbar nachdem ich sie das erste Mal erfasst habe. In einem Fall konnte ich vorher noch die grobe Richtung peilen und die Sonden damit finden. Die zweite erforderte ein großräumiges Absuchen der Landeregion. Eine Sonde konnte ich im Nahfeld empfangen, sie lieferte aber kein verwertbares GPS-Signal. Bei einer Sonde war das Ergebnis ungenau, und ich betrachte den erfolgreichen Fund nach GPS-Daten als etwas glücklich. Die 8 verbleibenden Sonden lagen sehr nahe der mit dem Zilog-Decoder ermittelten GPS-Position. Inzwischen ist es bei einer Suche nach einer sendenden, gelandeten SGP mein Plan A, das Sonden-GPS zu decodieren. Erst wenn das nicht funktioniert, wird intensiver gepeilt. Hingewiesen sei auch darauf, dass Peilen und Mitschneiden des Signals sich ja nicht ausschließen, zumindest, wenn man mit einem Rechner + RTL-SDR unterwegs ist.

Wie geht es?

Was brauche ich?

1) Folgende Version des Decoders (schon fertig für Windows kompiliert). Inhalt einfach in ein Verzeichnis entpacken. Es enthält 2 EXE-Dateien und einige Batch-Dateien. Für andere Betriebssysteme und für aktuellere Versionen sei dringend auf die offiziellen Sourcen des Programmautors verwiesen, die man mit z.B. GCC komplilieren kann.

2) Eine neue (max 2h alte) RINEX-Datei. Die Dateien werden ständig aktualisiert, behalten aber den ganzen Tag über den selben Dateinamen.
Einfach die letzte Datei auf der Liste downloaden und entpacken (z.B. mit 7zip). Diese Datei kommt auch in das Verzeichnis, in dem sich das Zilog-Programm befindet. Die Verwendung von Almanach-Dateien ist aus Genauigkeitsgründen nicht empfehlenswert.

3) Als Eingabedatei eine RAWdatei aus Sondemonitor UND/ODER eine Mitschnitt des Sondensignals als WAV-Datei (z.B. aus SDR#). Die Eingabedatei(en) gehören ebenfalls in das Zilog-Verzeichnis.


Anwendung:
In meiner Windoof-Version befinden sich Batch-Dateien (*.bat) für verschiedene Einsätze:
decode_RAW.bat
decode_WAV.bat
für RAW - bzw. WAV-Dateien. Beide Dateien eignen sich für eine 3D-Decodierung von fliegenden oder gelandeten Sonden

Für hartnäckige Fälle (wenn die gelandete Sonde nur noch 3 Satelliten sieht), gibt es 2 weitere Versionen, die weiter unten erläutert werden:
decode_2D_RAW_boden.bat
decode_2D_WAV_boden.bat
.

Die Batch-Dateien kann man wie ein Programm ausführen. Man muss aber vorher mit einem Editor die letzte Zeile ändern:
Bei der WAV-Version lautet die Zeile z.B. so:

rs92gps --crc -g2 -v -e  brdc0650.17n input_landung.wav > output_wav_Landung.txt

Man muss folgendes ändern:
- den Filenamen der gewünschten WAV-Datei (oder RAW-Datei) anpassen (in dem Beispiel "input_landung.wav" durch den Filenamen der eigenen Datei ersetzen).
- den Filenamen der RINEX-Datei anpassen (in dem Beispiel "brdc0650.17n" durch den Filenamen der aktuellen Rinexdatei ersetzen).
- den Filenamen der gewünschten Output-Datei anpassen (in dem Beispiel "output_wav_Landung.txt" durch den gewünschten Namen des Ausgabefiles ersetzen).
Nicht vergessen, die Batchdatei aus dem Editor zu speichern.

Die ganzen Zeilen vor der entscheidenden Zeile, die mit REM beginnen, sind Kommentare. Die letzte REM-Kommentarzeile ist eine funktionierende Version des Befehls. Wenn man also etwas kaputteditiert, gibt es hier Ersatz.
 
Dann die Batchdatei wie ein Programm ausführen. Das Ergebnis ist eine Textdatei (im Beispiel "output_wav_Landung.txt"), die man mit dem Lister oder Editor angucken kann.

Diese Liste enthält natürlich die gewünschten Koordinaten. Die kann man auf verschiedene Weise weiterverarbeiten:



Hinweise für die Versionen für die Dekodierung im Flug und am Boden

Die Ausgabedaten
Die Versionen für die Dekodierung im Flug geben einem eine Liste der Positionen, die zusätzlich eine Einschätzung der GPS-Genauigkeit erlaubt. Eine Zeile sieht so aus:

[23841] (M2243313) (2017-03-17) Fr 05:07:19.480  lat: 53.76645  lon: 10.00144  alt: 77.6  (d:1.2) DOP[9,6,3,23,17,31,19] 3.1

[Framenr][Sondenkennung] Datum (YYYY-MM-DD) <Wochentag Uhrzeit> lat:<Breite in Grad> lon: <Länge in Grad> alt: <GPS-Höhe in Metern> <d-Wert> DOP[Satellitennummern] <DOP-Wert>


Frames sendet die Sonde alle Sekunde, Framenr ist also die Zeit in Sekunden nach Einschalten der Sonde. Datum, Uhrzeit (UT), lat, lon sind selbsterklärend
Zur GPS-Höhe (alt) ist zu sagen, dass es sich hierbei um eine Höhe über dem WGS84 Ellipsoid handelt und NICHT über Höhen über Meereshöhe. Um letztere zu erhalten, muss man im Hamburger Raum 40m Geoidhöhe abziehen.

Hier und hier gibt Online-Rechner, die einem die Geodhöhe für den eigenen Standort liefern.

Abschätzung der Genauigkeit der Ergebnisse
Für das Aufsuchen am Boden muss man bedenken, dass die Zahl der erfassten Satelliten durch die ungünstige Ausrichtung der Helixantenne und Abdeckung des Himmels durch Hindernisse (z.B. dem Baum, in dem die Sonde hängt; die Sonde hat eine nach heutigen Maßstäben schlechte Empfangsleistung) begrenzt ist. Der Zilog-Decoder kommt damit aber oft erstaunlich gut klar. Wichtig ist, dass man das Sondensignal ein paar Minuten lang aufzeichnet, denn mit der Zeit ändert sich die Satellitengeometrie, die die Sonde nutzt. Nicht nur de Satellitengeometrie, sondern auch die generelle Genauigkeit der GPS-Dekodierung schwankt mit der Zeit. Es wechseln Phasen, bei denen eine gute GPS-Lösung herauskommmt und solche, in denen es nicht so gut oder gar nicht funktioniert. Daher ist es sehr wichtig, dass man die Qualität der Daten sorgfältig analysiert, um die guten Lösungen als solche zu erkennen. Dazu bietet der Zilog-Decoder folgende Daten:

Der d-Wert ist ein generelles Maß, wie gut die Lösung generell konvergiert - unabhängig von der Satellitengeometrie.Guten Lösung haben nach meiner  Erfahrung d-Werte << 10, meist auch  < 5 und oft sogar unter 1. Bei einem Wert zwischen 10 und 30 muss man schon mit einem ziemlichen Fehler der Position rechnen. Fazit: Gute Lösungen haben einen kleinen d-Wert.

Bei DOP findet man zwei weitere Angaben, die die Einschätzung der erzielten Genauigkeit ermöglichen - sehr wichtig bei gelandeten Sonden.
- Die zur Lösung herangezogenen Satelliten werden in eckigen Klammern aufgelistet. Hier sind bei fliegenden Sonden 10-12 typisch, bei gelandeten deutlich weniger. 4 sind das absolute Minimum. Fazit: Je mehr Satelliten, umso besser ist die Lösung.
- der DOP-Wert selbst, der ein Maß für die Qualität der Satellitengeometrie ist. Faustregel: Je niedriger der Wert, um so besser. Fliegende Sonden haben hier oft einen Wert von 1 bis 2, gelandete sehr viel schlechter.

Es gilt:
< 1: Ideal (nie erlebt)
1-2: Sehr gut. Typisch für fliegende Sonden. Bei gelandeten Sonden fast ein sicheres Zeichen für eine Baumlandung....
2-5: Immer noch richtig gut. Sonde wird man in der Regel unmittelbar am angegebenen Ort vorfinden. Vielleicht ist Dein Handy-GPS ungenauer.
5-10: Mittelgut. Meist ist die Sonde erstaunlich nahe an der Position, aber kann z.B. auch 20m daneben liegen
10-20: nicht sehr verlässlich: Sonde auf freiem Feld vielleicht noch findbar.
>20: Schlecht. Vielleicht hingehen und dann peilen?

Bei schlechtem DOP-Wert lohnt es sich oft, die Aufzeichnung zu verlängern, denn oft ändern sich die Satellitengeometrien im Laufe der Zeit. Habe ich eine DOP=8-Lösung, geh ich da hin, und wenn es nicht reicht, wird die Aufzeichnung verlängert. In den meisten Fällen findet man die Sonde aber im unmittelbaren Umfeld der ermittelten Position.

Man hat aus einer 5-Minuten-Aufzeichnung viele solcher Werten, und man kann sich die mit den meisten Satelliten, dem kleinsten d-Wert und dem geringsten DOP aussuchen. Manchmal ist das DOP durchgehend ähnlich, oder es wechseln Phasen ohne Lösung mit solchen mit gutem GPS-Lösungen ab.  Nach meiner Erfahrung ist auch das Produkt von d-Wert und DOP-Wert ein gutes Maß für die zu erwartende Genauigkeit. Im folgenden Beispiel wurde eine am Boden liegende Sonde für mehr als eine Stunde mit einem RTL-SDR empfangen und durch Peilen gefunden. Ich hatte aber einen großen Sondemonitor Rawfile, und dieser wurde mit Zilog decodiert. Die Helixantenne der SGPL horizontal lag auf einer Rasenfläche, und es gab Himmelsabdeckung durch Büsche, Bäume, Gartenmöbel und ein Haus. Im Datensatz fanden sich Werte mit DOP=52 und solche mit DOP=2.5, und etliche bei DOP=3.4 bis 3.7. Die Werte wurden nach dem Produkt von d*DOP sortiert, und einige Subsets dieser Daten werden hier dargestellt:




GPS-Positionen einer gelandeten Radiosonde. Dekodiert mit Zilog aus einem Sondemonitor Rawfile. Nur Werte, bei denen das Produkt d-Wert*DOP < 8 war, wurden dargestellt, als Beispiel für eine sehr gute Qualität der ausgewählten Daten. Die Sonde befand sich beim Marker (unterer Eckpunkt des Vierecks). Sondemonitor zeigte eine um 800m falsche Position. Kartengrundlage © OpenStreetMap contributors.



Wie oben, aber es werden nur Positionen dargestellt, bei denen das Produkt (d-Wert* dop) zwische 20 und 100 lag, als Beispiel für eine mittelmäßige Qualität der Daten. Kartengrundlage © OpenStreetMap contributors.


Wie oben, aber es werden nur Positionen dargestellt, bei denen das Produkt (d-Wert* dop) über 100 lag - dies sind die schlechtesten Positionen der Serie. Kartengrundlage © OpenStreetMap contributors

Bei einer echten Sondenjagd hat man natürlich nicht die Zeit zu einer elaborierten statistischen Analyse. Aber das Beispiel illustriert, worauf es ankommt: Man kann einen Datensatz sehr schnell durchgucken und sehr leicht erkennen, welche Werte die besten im Set sind: Es sind die, bei dem ein geringer DOP Wert, ein geringer d-Wert und eine hohe Zahl von Satelliten zusammenfallen. Derartige ausgewählte gute Koordinaten kann man nun in ein GPS-Handgerät oder in sein Handy eingeben. Sehr praktisch ist eine App, die z.B. die Open-Streetmap offline darstellt, dann ist man auch im Funkloch handlungsfähig, wie z.B. Locus.

2D-NAV: Wenn nix mehr hilft
Für harte Fälle gibt es noch die 2D-Nav-Version des Decoders. Die hilft in Fällen, wo die Sonde nur 3 Satelliten erfasst (die anderen Tools brauchen 4 Satelliten). Es muss klar sein, dass die Genauigkeit hier kritisch ist. Bei Tests am Boden konnte ich diesen Fall kreiieren, bei allen meinen Sondenjagden unter realen Bedingungen hatte ich bisher, wenn überhaupt, immer gleich eine 3D-NAV-Lösung. Der 2D-Decoder liefert aber auch automatisch eine 3D-Lösung, wenn diese möglich ist.

Hat man beim 2D-Decoder nur eine 2D-Lösung,  erhält man eine manchmal eine deutlich bessere oder sogar richtig gute Genauigkeit, wenn man die reale GPS-Höhe der Sonde kennt und dem Decoder vorgibt. Hier kann man auch den Drucksensor der Sonde nutzen (z.B. im Vergleich eines Drucks auf Meereshöhe aus dem Netz oder im Vergleich zum Handy-Druckmesser; Geoidhöhe draufaddieren nicht vergessen). Schätzt an die GPS-Höhe der Sonde auf 83m, würde man die Option "--2dalt 83" zusätzlich in die Zeile einsetzen.

 
Erfahrungen
Ich schätze, dass man ca. 75% der gelandeten SGP-Sonden mit dem Verfahren auffinden kann.

Bei einigen Sonden, die ich durch früher durch Peilen lokalisiert hatte, konnte ich die Position nach den Sondemonitor-Rawfiles bestätigen.

Zilog-Decoding ist vor allem für Leute, die mit RTL-SDR und Laptop durch die Gegend laufen, sehr angenehm: Mit etwas Übung hat man einen Fix innerhalb von Minuten. Nach erfolgter Lokalisation mit offensichtlich guter Genauigkeit verschwinden Rechner und Antenne im Rucksack, und das GPS-Handgerät oder das Handy führt einen zur Sonde!

H. Lüthen (astrohardy.de) Juni 2017