Die Predict-API

aktualsiert am 12.1.2023

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.

Man beginnt eventuelle Peil- oder Dekodierbemühungen im Nahbereich und spart Nerven und Zeit. Oder kann die Antenne gleich im Rucksack lassen
Ich fahre mit "Öffis" und Rad zu den Sonden; eine bessere Kenntnis der Landestelle hilft mir, die Anreise zu planen.
Ist die Batterie der Sonde schon leer (z.B. weil man als Berufstätiger erst Tage nach der Landung Zeit für eine Suchexpedition hat), kann man die "kalte" Sonde mit etwas Glück trotzdem noch finden.
Timerkill, wie er in letzter Zeit von einigen Stationen auf z.B. 3h20min eingestellt wird, lässt sich durch eine Verfolgung der Sonde bis kurz vor der Landung und eine gute Vorhersage oft überwinden.
Wurde auf der Bremer Seite zeitnah keine Vorhersage ausgelöst, kann man das auch viele Stunden nach dem Flug selber machen.

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

https://api.v2.sondehub.org/tawhiri?profile=standard_profile&launch_datetime=2023-01-12T01:50:00Z&launch_latitude=53.5499&launch_longitude=10.5194&launch_altitude=132.1&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.

NEU: Wenn man an den Call noch &format=kml oder &format=csv anhängt, bekommt man eine kml-Datei für Google-Earth oder csv-Datei heruntergeladen, z.B.

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_longitude: Letzte 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

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

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

stage "descent" //Abstiegsbahn

trajectory

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 Sondehub eine Benutzerobefläche für die API. 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 Prediction bei wettersonde.net
wettersonde.net bietet während des Abstiegs eine sehr gut funktionierende Live-Prediction an. Auf wettersonde.net gibt es auch eine Benutzeroberfläche des Predictors, der sehr gut funktioniert. Es werden jeweils Parameter benutzt, wie sie auf dieser Seite vorgeschlagen werden.

On the fly Predictions bei Sondehub

Sondehub 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. 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