aktualsiert am 11.3.2021

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:

https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=53.5+10&option=Submit

 

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

 

Tawhiri-Benutzeroberfläche bei Sondehub (Habub)

Es gibt bei Habhub eine Benutzerobefläche für die API - aber nur auf der Sondhub-Version. Die Habhub-Version zeigt nicht nur die Google-Karten statt der Open Streetmap, sondern verwendet auch eine nicht sinnvolle Uraltversion des Predictors. Seit wetterson.de offline ist, ist das eine gute Alternative. Man muss allerdings die Daten per Copy/Paste von einer anderen Quelle einfügen.

Hier kann man die Daten entsprechend der oben genannten Erläuterungen eingeben.

Sondehub-Predictor

 

On the fly Predictions bei Sondehub/Habhub

Habhub bietet auch eine On-the-Fly Prediction, die während des Abstiegs der Sonde alle 30 Sekunden aufgefrischt wird. Hier mal ein Link, der NUR klassische Radiosonden der letzten Stunde zeigt und auf den norddeutschen Raum zentriert ist. Man kann durch Änderung der Koordinaten in der URL den Mittelpunkt der Karte ändern. Auch hier ist die Sondehub-Version der klassischen Habhub-Ansicht überlegen. Die On-The-Fly-Prediction funkioniert meistens - nicht immer. Auch ist das Empfangsnetz nicht so dicht, so dass hier letzte Positionen aus ganz niedriger Höhe nicht zu haben sind. Um aber die Anreise zur Landestelle zu planen, ist das (wenn es funktioniert) ganz ok. Entspricht in etwa dem old descent model der verstorbenen Webseite wetterson.de 
 

onthefly

 

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.

Man kann sich hier auch eine Satellitenansicht der Landestelle angucken.

 

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