Wetterrouting an Bord

Wetterrouting für die Langfahrt ohne Budget

Wetterrouting für die Langfahrt ohne Budget

Wetter und taktische Navigation an Bord

Zuerst möchte ich am Anfang dieses Beitrages etwas erwähnen: Ich habe keine Ahnung, ich weiß nur, dass es funktioniert 🙂

Aber vielleicht geht es dir in Bezug auf Wetterdaten für die taktische Navigation genauso. In küstennahen Gebieten nutzt du für deine Planung wahrscheinlich außer DWD Windfinder oder Windy, und Abends bist du eh wieder Zuhause.

Irgendwann reicht das aber nicht mehr. Um Gefahrensituationen zu vermeiden ist es gerade bei längeren Strecken und Nachtfahrten gut zu wissen, was auf einen zukommt. Wer ein eigenes Schiff besitzt, hat aber meistens auch ein beschränktes Budget und nicht unbedingt ein teures Satellitenkommunikationssystem. 

Bevor man sich mit der Hardware auseinandersetzt, empfehle ich für das grundsätzliche Verständnis von Wettersystemen und Daten die Wetterseminare von Wetterwelt. Was nutzt einem das ganze Equipment, wenn man die Ergebnisse nicht interpretieren kann?

Wie geht Routing oder Wetterrouting?

Ich hatte einen Wetterrouting-Bedarf und nur eine vage Vorstellung davon, wie das gehen könnte: Irgendwoher wollte ich Grib-Daten auf ein Wetterrouting Programm laden und am besten auch noch auf die digitale Seekarte. Und zwar nicht nur auf einer App im Smartphone, sondern auf dem Bordrechner

Die Roaring Forty hatte folgendes Equipment zu bieten: 

  • B&G-Marine-Elektronik, 
  • Iridium Satelliten-Telefon (spielt hier keine Rolle), 
  • Bordrechner (Lenovo Thinkpad) mit OpenCPN als Kartensystem und dem Plug-In oeSENC für oeSENC-Seekarten* von o-Charts, 
  • 1 Multiplexer für die GPS- und AIS-Datenübertragung an den Bordrechner (NMEA-Daten),
  • Verschiedene Antennen für B&G, GPS und AIS-Empfang.

* oeSENC: OpenCPN Encrypted System Electronical Nautical Charts Karten sind offizielle Seekarten mit weltweiter Abdeckung im Vektorformat. Es sind die preiswertesten Qualitätsvektorkarten, die angeboten werden.

Budget danach: No Budget.

Was brauchte ich also, um unter diesen Umständen Gribdaten laden und für die taktische Navigation verwenden zu können? Um dir die Suche in verschiedenen Foren zu ersparen, schildere ich in diesem Beitrag kurz mein Set up und Erfahrungen damit.

Gribdaten:

Es gibt verschiedene Vorhersage-Modelle, wie du vielleicht auf Windfinder und Windy schon festgestellt hast: das europäische ECMWF und das amerikanische GFS. Die Unterschiede liegen u.a. in der Maschenweite und der Rechenkapazität. Das EW hat engere Maschen und höhere Rechenkapazitäten. Es lässt sich selbstverständlich keine generelle Aussage ableiten, welches Modell nun “besser” ist. Unsere Erfahrung auf der Roaring Forty (immerhin über 15.000 nm seit 2016 zwischen 54 N und 10 S Breitengrad) zeigt aber, dass das im Norden die ECMWF Vorhersage ganz akkurat stimmt, aber je mehr wir in Richtung Süden gesegelt sind, fanden wir mehr Übereinstimmungen mit den GFS-Vorhersagen. Aber wahrscheinlich führt diese Behauptung von mir zu einem Glaubenskrieg, denn exakte Vergleiche und Analysen sind kaum zu bewerkstelligen. In der Praxis sehe ich mir (schon einige Tage vorher) vor der Segelreise die Wetterentwicklung in beiden Modellen an, aber ich lade anschließend über ein Anfrage an saildocs die GFS-Daten herunter (gut erklärt auf http://weather.mailasail.com/Franks-Weather/Saildocs-Free-Grib-Files). Saildocs ist ein E-Mail-basiertes Dokumentenabrufsystem für die Bereitstellung von textbasierten Internetdokumenten, eben auch custom grib weather-data files, entweder auf Anfrage oder im Abonnement. Natürlich kann man sich die Gribdaten gegen eine geringe Gebühr auch von Wetterwelt zur Verfügung stellen lassen, aber der Titel des Beitrags heißt ja „ohne Budget“ :-).

Wetterrouting:

Mein Lieblingsprogramm trägt den sperrigen Namen qtVlm. Ich habe keinen Schimmer, was diese Abkürzung heißen soll. Die Website URL ist wesentlich einfacher zu merken: www.meltemus.com. Predict Wind Offshore bietet die gleiche Leistung, habe ich aber nur rudimentär ausprobiert. Bluewater Racing ebenso. Jetzt ist natürlich jedes Boot unterschiedlich schnell. In qtVlm kann ich die Eckdaten (oder Polardaten) meines Bootes für die Berechnung des Wetterroutings eingeben. Einige Boote werden bereits vorgeschlagen, zum Beispiel die Class 40.

Wetterempfang:

Ich hatte kurzfristig ein Navtex-Gerät, leider eins der billigsten Sorte und völlig unnütz. Es kamen keine brauchbaren Daten raus, egal wo ich die Antenne montiert habe und ich habe es wieder von Bord genommen. Über das Multiplex-Gerät und einer Verbindung zum Audio-Eingang am Computer ziehen wir nun Wetterdaten aus Mscan Meteo. Das Programm kombiniert die Fähigkeiten FAX, NAVTEX und RTTY Signale zu dekodieren. Dadurch habe ich immer die neuesten Wetterberichte. Hier muss ich auf Marc Jähnke von B.I.S. Electronics verweisen, denn ich habe, wie gesagt, keine Ahnung, wie es funktioniert. Mscan Meteo liefert aber noch keine Gribdaten für mein Routing, denn ich habe keinen SSB Receiver, sondern es ist in dieser Konstellation ein Ersatz für das Navtex-Gerät.

Wie passt das alles zusammen?

Das sind die einzelnen Komponenten, die bei uns an Bord eine wichtige Rolle spielen. Aber wie werden sie zusammengeführt? Durch das Dokumentenabrufsystem von Saildocs (s. o.) lasse ich mir über eine Mailanfrage Gribdaten schicken. Das Gribfile, was per Mail zurückkommt, lade ich am Bordrechner im OpenCPN Programm mithilfe eines internen Plug ins hoch. Damit habe ich beim Navigieren und Tracking immer meine Windpfeile und kann diese bei Bedarf auf einem Zeitbalken durchlaufen lassen. Das selbe File lade ich auch im Wetterrouting Programm qtVlm hoch. Auf der Karte von qtVlm kann ich auf der Karte zwei Wegpunkte anlegen, z. B. Start und Zielhafen, und das Routing von dem einen zum anderen vorschlagen lassen. Dabei kommt dann eine meistens ungerade Linie mit verschiedenen „Beulen“ oder „Bananen“ heraus, die daraus resultieren, dass die vorgeschlagene Route jeden Winddreher mit der geschätzten Bootsgeschwindigkeit aus den Polardaten berücksichtigt. Und was soll ich sagen? Wir sind vielleicht nicht immer die exakte Kurve nachgesegelt, aber das ETA, bzw. die geschätzte Ankunftszeit war immer eine Punktlandung! Das Anlegebier kann man sich also schon mal kalt stellen lassen!

Verschiedene Darstellungsmöglichkeiten der Route in qtVlm

P.S. qtVlm kann sich übrigens auch mit den vielen verschiedenen NMEA-Quellen verbinden (serielle Schnittstelle, internes GPS, GPSD, TCP und UDP) und kann mehrere Quellen gleichzeitig verwenden. Ich verwende aber schon die NMEA-Daten für OpenCPN, und anscheinend kann ich die gleichen Daten nicht in zwei Programmen verwenden. Da dieses Verständnis meine Computerkenntnisse übersteigt, kann ich hier auch nicht weiter helfen 🙂