aktualsiert am 29.12.2018

Verwendung der Tawhiri-API zur Vorhersage der Landestellen von Wetterballons

 

H. Lüthen

Wenn man durch eigenen Empfang Positionsdaten einer Radiosonde bis in eine geringe Höhe über dem Boden erhalten hat, möchte man eventuell die genaue Landestelle kennen. Die Tawhiri-API kann die Bahn des Ballons von der letzten bekannten Position bis zur Landestelle relativ genau vorhersage. Das ist für den Sondenjäger nützlich.

Ich habe in den letzten Monaten diese Technik ein wenig optimiert und konnte dadurch etliche Sonden im Gelände auffinden, zum Teil in unmittelbarer Nähe zur vorhergesagten Position. Da mich verschiedene Sondenfreunde darum gebeten haben, hier mal eine grobe Doku.

 

Die Predict-API

Die Tawhiri API ist eigentlich dazu da, die Flugbahn eines Ballons von Start bis Landung vorherzusagen. Eingegeben werden Positionen (Länge, Breite, Höhe) des Startorts, Aufstiegsgeschwindigkeit, Höhe des Platzens und Abstiegsgeschwindigkeit. Die API liefert dann eine Vorhersage der Flugbahn des Ballons mit Zwischenpositionen bei Auf- und Abstieg. Hierzu werden die Winddaten aus dem aktuellen RUN des GFS-Wettermodells verwendet. Bei der Vorhersage der Landestelle  wird ein Erdoberflächenprofil (Terrain) automatisch berücksichtigt, das eine Auflösung von 15" (ca. 30m) hat.

Der Service kann auch dazu zweckentfremdet werden, die Landestelle einer Sonde aus den letzten empfangenen Positionen zu berechnen. Dies erlaubt das Auffinden „kalter Sonden“ am Wochenende und ist ein sinnvolles Mittel gegen Timerkill-Sonden.

Aufruf und Syntax

 

http://predict.cusf.co.uk/api/v1/?launch_latitude=54.872897&launch_longitude=9.038564&launch_altitude=132.1&launch_datetime=2018-04-12T15:58:25Z&ascent_rate=15&burst_altitude=139.1&descent_rate=8

 

Man passt diese Zeile der jeweiligen Sonde an, kopiert sie per Zwischenablage in das Browserfenster und ruft sie wie eine Webseite auf.  Die Antwort wird dann im Browser angezeigt.

 

Tipp: Ich habe mehrere Zeilen dieses Aufrufs in einer Textdatei, editiere im Editor, und kopiere die Zeile in das Adressfenster des Browsers. Wenn ich eine Zeile kaputteditiere, habe ich noch weitere. In dieser Datei befindet sich auch entsprechender Aufruf für Google-Maps. Vielleicht schreibt ja mal jemand eine kleine Benutzeroberfläche dafür. Mit etwas Übung ist es aber möglich, auch "zu Fuß" sehr schnell einen Aufruf zu starten und abzuschicken .

 

Dabei sind die Parameter sind für den eigentlichen Einsatzzweck der API - die Planung eines Ballonflugs von Start bis Landung - so definiert:

launch_latitude:              Geografische Breite des Startplatzes in ° (Dezimalformat)
launch_longitude:          Geografische Länge des Startplatzes in ° (Dezimalformat)
launch_altitude:              Höhe des Startplatzes in Metern über Geoid (N.N.)

launch_datetime:           Zeitpunkt des Starts in UT
ascent_rate:                     Aufstiegsrate in m/s
descent_rate:                   Abstiegsrate bei Landung (auf Höhe N.N.)

burst_altitude:                 Höhe des Platzens in Metern über Geoid (N.N.)

 

Wie wählt man die Parameter für eine Landevorhersage zum Aufsuchen einer kalten Sonde?

Angenommen wird ein Ballon, der an der letzten empfangenen Position  (Länge, Breite, Höhe)  gestartet wurde und der dort sofort platzt.  Vorhergesagt wird dann nur der Abstieg der Sonde am Fallschirm.

launch_latitude, launch_longitude sind also die letzten Positionen der Sonde

Etwas komplizierter ist die Behandlung der Höhen:
Generell nutzt die API Höhen über dem Geoid (also praktisch über N.N.). Das Sonden-GPS (und jedes andere normale GPS) liefert aber  Höhen über dem Ellipsoid. Diese Höhen sind im norddeutschen Raum ca. 40 Meter größer als die Höhe über dem Geoid. In Deutschland sind es generell 40-50 Meter.

Man muss also von jeder Sonden-GPS- Höhe ca. 40 Meter abziehen. Genaue Werte bekommt man z.B. hier:

earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html

 

Würde man launch_altitude und burst_altitude gleichsetzen, gibt es eine Fehlermeldung der API. Also muss man die launch_altitude minimal niedriger ansetzen als die letzte verfügbare Höhe; die burst_altitude kann man der letzten beobachteten Höhe gleichsetzen.

 

Ich habe ein wenig herumprobiert und ziehe seither 7 Meter von der letzten beobachteten Höhe ab. Als Aufstiegsgeschwindigkeit wähle ich dann 15m/s, damit der Ballon schnell auf die gewünschte Höhe klettert, ohne im Modell nennenswert zu verdriften.

Hier noch einmal eine

Übersicht über alle Parameter für eine Vorhersage der Landeposition einer Radiosonde

launch_latitude, launch_longitudeLetzte Positionen der Sonde

launch_altitude: Letzte GPS Höhe (m) – 40m – 7m

launch_datetime: Uhrzeit der letzten Beobachtung in UT . Kann schadlos etliche Stunden in der Vergangenheit liegen. Liegt sie so weit zurück, dass im aktuellen GFS-Modell keine Wetterdaten mehr vorhanden sind, gibt es eine Fehlermeldung: Prediction did not complete: 'Value out of range. Dieses Problem sollte aber nicht vor 7-10 Stunden nach der Sondenlandung auftreten.

Ascent_rate: 15m/s
descent_rate: Letzte Abstiegsrate
(m/s)
Strenggenommen handelt es sich hier um die Abstiegsrate auf 0m N.N.. In Höhen unter 1000-2000m kann man sie aber mit der letzten beobachteten Abstiegsrate in erster Näherung gleichsetzen.

Burst_altitude:  Letzte GPS Höhe (m) – 40m

 

Beispiel für eine Ausgabe (//mit Kommentaren)

 Die Antwort sieht dann etwa so aus:

 

metadata          

complete_datetime       "2018-05-03T01:42:31.824435Z"

start_datetime  "2018-05-03T01:42:31.82144Z" //Uhrzeit des Aufrufs

prediction         

0            

stage     "ascent"             //Aufstiegsbahn. Ist hier sehr kurz (7 Meter)

trajectory          

0                                           //Ausgangsposition

altitude               495.88  //Ausgangshöhe war 502.88 Meter, 7 Meter abgezogen

datetime             "2018-05-03T01:35:39Z" //beachte: 7 Minuten in der Vergangenheit

latitude               53.79129

longitude            10.65927

1            

altitude               502.91125          // Ende der Aufstiegsbahn, burst altitude überschritten

datetime             "2018-05-03T01:35:39.46875Z"

latitude               53.791301606958726 // Länge und Breite haben sich kaum verändert

longitude            10.659310847255291

1            

stage     "descent"           //Abstiegsbahn

trajectory          

0            

altitude               502.91125          // Beginn der Abstiegsbahn. Ausgangspunkt entspricht dem Endpunkt des Aufstiegs

datetime             "2018-05-03T01:35:39.46875Z"

latitude               53.791301606958726

longitude            10.659310847255291

1                                                                        //Erste Position der Abstiegsbahn. Es kann mehr solche Zwischenpositionen geben. Bei sehr niedriger Ausgangshöhe kann  hier auch sofort die Landeposition kommen

altitude               240.96940219843123

datetime             "2018-05-03T01:36:39.46875Z"

latitude               53.793953755255885

longitude            10.663460009090608

2                                                                        //Zweite und letzte Position der Abstiegsbahn (Landeposition)

altitude               24.732170638875736     //Geländehöhe der Landestelle

datetime             "2018-05-03T01:37:29.625Z" //Uhrzeit der Landung, ist immerhin noch 2 min geflogen

latitude               53.79582562802369

longitude            10.664212300052373

 

 

request                                    //Eingabedaten werden am Ende noch mal aufgelistet

ascent_rate        15

burst_altitude   502.88

dataset "2018-05-02T18:00:00Z" // 18Z GFS Modell wurde verwendet für eine Landung am Folgetag um 1:35

descent_rate     4.3

launch_altitude               495.88

launch_datetime            "2018-05-03T01:35:39Z"

launch_latitude               53.79129

launch_longitude           10.65927

profile   "standard_profile"

version 1

 

 

Neue Tawhiri-Prediction auf der Bremer Seite

Seit Dezember 2018 bietet wetterson.de  eine sehr schöne und komplett neue Implementierung des Tawhiri-Predict-Aufrufs.  Die übergebenen Parameter sind genau die gleichen, wie sie oben beschrieben werden. Daher sind die Ergebnisse auch komplett identisch.

Auf der Sondenkarte kann man die Sonde anklicken. Dann erscheint oben rechts folgendes Fenster:

   Einfach auf PREDICT klicken. Am Rande der Karte erscheint das folgende Menü, in das bereits die letzten Höhen aus der Bremer Seite korrekt umgerechnet und eingetragen sind.

 

 

Will man einfach auf Basis der Seite wetterson.de eine Prediction rechnen, einfach auf SUBMIT klicken.

Hat man bessere Daten aus eigenem Empfang oder anderen Quellen, kann man sie hereineditieren bzw. in die betreffenden Felder pasten.

Hierbei sind Latitude und Longitude die letzte Position. Bei den Höhen gilt wieder, wie oben erläutert, Start Altitude = letzte GPS-Höhe-47m und Burst-Altitude=letzte GPS-Höhe-40m

Old Descent Model: Für die Kaltsondenjagd belanglos. Will man die Landung einer noch fliegenden Sonde verfolgen, der sich noch in großer Höhe befindet, anklicken. Die Abstiegsgeschwindigkeit  einer am Fallschirm hängenden Sonde vermindert sich durch den Einfluss der dichter werdenden Atmosphäre. Wird das Feld aktiviert, wird versucht, diesen Effekt zu berücksichtigen. Unter 1000m Höhe erfolgt keine Korrektur.

 

Date braucht man nicht groß zu editieren. Wenn bitte bedenken: UT-Zeiten verwenden.

Hat man auf SUBMIT geklickt, erscheint eine Karte auf OSM-Basis mit der vorhergesagten Flugbahn und der Landestelle

 

Wenn man das Kreuz an der Landestelle anklickt, erscheint mehr Info:

Altitude bezeichnet die Höhe des Terrains an der Einschlagstelle in Metern über N.N. Land ist die vorhergesagte Landezeit in UT. Dataset ist die Startzeit des verwendeten GFS-Runs. Der Klick auf Google-Maps erlaubt eine Darstellung in Google-Maps (Satellitenansicht). Diese Funktion ist auch nützlich, um an die Koordinaten der Landestelle zu kommen, z.B. um sie in ein GPS-Handgerät oder in eine Handy-App einzugeben.

 

Wie üblich kann man bis ca. 10 Stunden nach dem Flug noch Predictions mit der korekten Zeit auslösen.  Danach kommen Fehlermeldungen.

 

Vergleich mit radiosondy.info

Auf der polnischen Seite radiosondy.info wird auch eine Prediction dargestellt, deren Generierung und zugrunde gelegten Parameter aber unklar sind. Die ermittelten Landepunkte sind ähnlich wie die mit der hier dargestellten Methode ermittelten, die Sonde fliegt aber eher zu weit. Daher ist es vorzuziehen, wenn radiosondy die Sonde tiefer hat als der eigene Empfang oder die Bremer Seite, eine Tawhiri-Prediction auf Basis der letzten Position händisch oder durch Editieren der Eingabewerte der Bremer Seite aufzurufen. Seit es in meiner Gegend zwei neue Empfangsstationen für radiosondy.info gibt, die die Sonden bis in 100-200m Höhe erfassen, habe ich darüber mehrere Sonden z.T. metergenau vorfinden können.

 

Vergleich mit predict.habhub.org

Diese Seite ist eigentlich eine Benutzeroberfläche der API (möglicherweise auch einer Vorgängerversion), weist in ihrem Verhalten dennoch drastische Unterschiede auf. Insbesondere wird das 3-D-Terrain der Erdoberfläche nicht berücksichtigt, wie ich durch vergleichende Testläufe in Gebirgsregionen herausfinden musste. Habhub weigert sich zudem, Daten für Zeitpunkte der Vergangenheit auszugeben. Dafür kann man Platzhöhe und Starthöhe gleichsetzen.

Näherungsweise Predictions sind möglich, indem man von den Höhen Geoidhöhe (also 40m) und Terrainhöhe (z.B. aus Google Earth) abzieht. Allerdings macht man dabei den Fehler, dass die angenommene Sonde aus einer objektiv geringeren Höhe startet. Diesen Fehler kann man in Gebirgsgegenden nicht vernachlässigen. Auch muss man Habhub-Predictions direkt nach der Landung auslösen, was ähnlich wie bei der Bremer Seite einen Aufruf der Prediction zeitnah nach der Landung erzwingt. Da ist die Original-API eben sinnvoller, die die Berechnung auch Stunden nach dem Sondenflug erlaubt.

 

Genauigkeit der Prediction

Erfahrungsgemäß stimmen im GFS-Modell die Windrichtungen und Windstärken in Bodennähe (und die braucht man für unseren Zweck) an den meisten Tagen recht gut. Das hängt auch damit zusammen, dass ja nur eine kurze Zeit überbrückt wird. Eine typische Mittagssonde wird z.B. gegen 13 Uhr UT landen; das dann aktuelle GFS-Modell wäre das mit der Ausgangszeit von 6 Uhr UT, das gegen 11 Uhr UT publliziert wird. Das Modell muss also nur 7 Stunden überbrücken. Wenn man zur Vorhersage derselben Landestelle später am Abend die API-aufruft (z.B. um 17:00), ist sogar das 12:00 GFS-Modell schon heraus; dann wäre es nur eine Stunde. In beiden Fällen sollte in einem für 10 Tage ausgelegten Modell noch keine großen Fehler aufgelaufen sein.

Die durchschnittliche Genauigkeit liegt nach meiner Erfahrung bei ca. 10-15% der Strecke (3-D) zwischen letzter Position und Aufschlagstelle. Ist die Sonde z.B. durch eigenen Empfang bis in 150 Meter verfolgt worden, kann diese Strecke also z.B. 300m betragen. Dann könnte man die Sonde mit einiger Sicherheit in 30-50 Meter Entfernung von der Prediction auffinden. Ist die Landestelle einigermaßen übersichtlich, ist das völlig ausreichend. Bei 1500m letzter Höhe wäre der zehnfache Fehler zu erwarten, was dann die Chance für eine Auffindung sehr stark vermindert. Ich habe aber solche Sonden durchaus gefunden, wenn sie sehr auffällig im Gelände erkennbar waren.

Grundsätzlich gilt auch hier „garbage in, garbage out“. Bei RS92-Sonden ist z.B. Sondemonitor nicht zu empfehlen, weil die Positions- und Höhenangaben ungenau sind. Dort macht der Zilog-Decoder mehr Sinn. RS41 und DFM09-Sonden funktionieren auch mit Sondemonitor. M.E. liefert auch hier die Demod-Version von Zilog Daten aus den niedrigsten Höhen. RS41-Tracker erfordert ziemlich gute Signalqualität und geht sehr früh "in die Knie". Die neuen Positionsangaben vom DWD weisen leider auch noch z.T. beachtliche Fehler auf, was sie wenig geeignet zur Sondensuche macht.

 

Impressum

Datenschutzerklärung