Kategorie-Archiv: Segeln

OpenCPN und S63 Karten

Das Hauptproblem vor dem viele OpenCPN (eine Open Source Plotter-Software für Seekarten) Nutzer stehen, ist die Beschaffung von vernünftigem Kartenmaterial.

Während die National Oceanic and Atmospheric Administration NOAA Karten für die USA direkt im mit OpenCPN kompatiblen S57 Format anbietet, kucken viele europäische Segler in die Röhre. Die häufig verwendeten S63 Karten werden standardmäßig nicht von OpenCPN unterstützt.

Es gibt jedoch eine (fast) kostenlose PlugIn Lösung.

http://o-charts.org bietet ein kostenloses Plugin für OpenCPN auf Linux, MacOs und Windows Plattformen an, dass die Nutzung von S63 Kartenmaterial ermöglicht. In dieser Schritt-für-Schritt Anleitung soll der interessierte Nutzer bei der Installation des PlugIns, dessen Setup und der erstmaligen Verwendung einer S63 Seekarte begleitet werden.

OpenCPN und S63 Karten

Das S63 PlugIn kann für die jeweilige OpenCPN Version bei o-charts.org heruntergeladen und mittels selbsterklärender Installationsroutine installiert werden. Anschliessend findet man es unter OpenCPN>Preferences>Plugins

OpenCPN_Preferences_PlugIns

Ausser OpenCPN und dem oben angesprochenen Plugin benötigt man eine sogenannte UserPermit für die einmalig Kosten in Höhe von ca 15,- EUR anfallen und eine sogenannte InstallPermit, die man bei vorhandener UserPermit für ein bestimmtes Computer- oder Plotter-System kostenlos generieren kann.

Der UserPermit ist ein 28-stelliger Zahlencode den man nach Bezahlung der Gebühr über o-charts.org per eMail erhält und in OpenCPN unter Preferences>Charts>S63 Charts hineinkopiert:

OpenCPN_Preferences_Charts_S63_Charts

Anschliessend lässt sich innerhalb von OpenCPN ein Fingerprint-File (System Identifier file) generieren und auf der Festplatte speichern. Diese FPR-Datei gilt spezifisch für das verwendete System (Computer). Hat man dieses Fingerprint-File auf der Festplatte gespeichert kann man (erneut bei o-charts.org) durch Upload dieser Datei eine InstallPermit damit erzeugen (ein acht stelliger alphanummerischer Code).

Installpermit_erzeugen

Installpermit_erhalten

Dieser muss dann wiederum bei OpenCPN eingetippt werden:

alle_vorraussetzungen

Bei einem Computerwechsel kann man mit dem schon vorhandenen (kostenpflichtigen) UserPermit (der bei o-charts.org im Benutzerbereich gespeichert bleibt) jederzeit für einen neuen Rechner/Plotter kostenlos eine neue InstallPermit generieren.

Nach diesem etwas holprigen Prozedere erfüllt unser System prinzipiell alle Voraussetzungen um S63 Kartenmaterial anzuzeigen. Zum Beispiel bei Chartworld lassen sich nun Lizenzen zur zeitlich begrenzten Nutzung von S63 Karten beziehen.

Für die Nutzung dieses Kartenmaterial fallen leider nicht unerhebliche Lizenzgebühren an. Hier gilt leider: Je mehr Informationen auf den Karten dargestellt werden (je grösser der Zoomfaktor) desto teurer die Karte.

Für Urlaubs- oder Gelegenheitsnutzer lässt sich bei vielen Karten glücklicherweise ein Updatezeitraum von nur 3 Monaten wählen. Während dieses Zeitraums erhält man per eMail Hinweise zu Änderungen der Seekarte und kann sich ggf. Aktualisierungen herunterladen.

Navionics® Seekarten mit OpenCPN

Bei Chartworld lassen sich auch einige der beliebten Navionics Karten für OpenCPN im S63 Format herunterladen (leider nur mit einem Standard-Update-Zeitraum von 12 Monaten, was die OpenCPN Navionics Karten dann recht teuer macht).

Zu Demonstrationszwecken habe ich zwei Karten von Mallorca (eine Übersichtkarte und eine Detailkarte für die Bucht von Palma) gewählt, die für 3 Monate ca. 10,- EUR kosten.

Nach Bezahlung und Download der beiden Dateien muss zunächst die so genannte Cell Permit (ein txt File) in OpenCPN importiert werden. Anschliessend lässt sich die S63 Karte unter Preferences>Charts>S63 Charts importieren:

import_cellpermit

import_karten_abgeschlossen

Und so sieht das ganze in den unterschiedlichen Zoomstufen dann aus:

Mallorca übersichtskarte

Seekarte_Mallorca

OpenCPN S63 Karte Bucht von Palma

Bei Fragen, Unklarheiten oder Ergänzungen freue ich mich auf einen Kommentar zu diesem Beitrag.

Wie gelangen GPS Positionsdaten vom Boot ins Netz?

Guido Dwersteg tut es, Johannes Erdmann tut es und auch Harald Sedlacek tat es bei seinen beiden Atlantiküberquerungen mit der nur 4,90 m langen Fipofix. Das Who ist who der neuen deutschs-prachigen Blauwasser-Generation blogt. Auf keinem dieser Blogs und Internetseiten darf heute eine Karte fehlen, auf der die aktuelle Bootsposition eingeblendet wird. Den Daheimgebliebenen wird so ermöglicht, remote aber „live“ dabei zu sein und den Reiseverlauf im Internet zu verfolgen.

Wie aber ist das technisch möglich? Wie kommen die aktuellen GPS Koordinaten von Bord einer Segelyacht in regelmäßigen Abständen auf die eigene Homepage oder auf Social Media Plattformen wie Facebook, Twitter & Co?

Dieser Übersichtsartikel soll die technischen Voraussetzungen dafür beleuchten und die diversen Möglichkeiten ein solches Live-Tracking System aufzubauen skizzieren.

sample_yblog
Vielen Dank an YB Tracking für die Genehmigung obiges Bild das eine Beispielkarte eines Blogs zeigt hier einzubinden.

Grundvoraussetungen zum Aufbau eines Online-Trackers ist die Bestimmung der eigenen GPS Koordinaten und anschliessend deren Übermittlung an den eigenen Internetauftritt bzw. den zugehörigen (auf dem Festland lokalisierten) Server.

Der erste Teil dieser Voraussetzungen ist relativ leicht zu erfüllen, denn nicht nur Smartphones, sondern auch beinahe jede Yacht ist heute mit einem GPS-Modul ausgerüstet, das (z.B. über den Kartenplotter) jederzeit die aktuelle Position mit Leichtigkeit bestimmt. Doch der zweite Teil ist kniffliger. Wie gelangen diese Daten nun zum Server aufs Festland? Die Möglichkeiten einen Datentransfer von einem beliebigen Punkt auf den Weltmeeren zum Festland zu verwirklichen, gleichen denen, die man vom Bezug des aktueller Wetterberichts an Bord kennt: Im wesentlichen sind dies die Kommunikationswege per Kurzwelle oder Satellit (meist Iridium).

Statt selbst zum Tüftler, Elektrotechniker und Programmierer werden zu müssen, um den Bordmitteln beizubringen die ermittelte Position „nach Hause“ zu übermitteln, kann man inzwischen auf eine wachsende Anzahl preisgünstiger, portabler Gadgets zurückgreifen, die die Position nach einer mehr oder weniger komfortablen Konfiguration (mit mehr oder weniger Programmieraufwand) via Satellit zum eigenen Server weiterleiten1.

(Fast) Alle der oben genannten (und sicherlich viele weitere) Segler wählen der Einfachheit halber diesen Weg ein Tracking System auf ihrem Internetauftritt zu verwirklichen. Die nachfolgende Tabelle listet günstige GPS Tracker auf und vergleicht Anschaffungs- und Betriebskosten.

  Spot-Trace GPS Tracker  YB Tracking YB3 Basic  DeLorme inReach SE
Anschaffungskosten ca. 100,- € (zzgl. MWSt.). ca. 400,- £ (zzgl. MWSt.). ca. 300,- $.
Laufende Kosten Servicevertrag (ab ca. 97,- €/Jahr oder ab ca. 10,- €/Monat zzgl. Steuern) benötigt Ab ca. 8,- £ pro Nutzungsmonat sowie zusätzlich 0.04-0.12 £ pro Positionsmeldung Ab ca. 12,- $ pro Nutzungsmonat sowie zusätzlich 0.10 $ pro Positionsmeldung
Gewicht 87.9 g 305 g 190 g
Stromversorgung 4 AAA Batterien 5V USB Kabelverbindung (dann nicht wasserdicht) Festverbauter Akku Festverbauter Akku
Beispiel Harals Sedlaceks Spot GPS Tracker: http://www.open16.com/index.php/en/proof-of-principle/live-tracking Guido Dwerstegs YB Tracker: http://www.törn.de/blog/?page_id=1673  
Kommentar Nach Auskunft von Norbert Sedlacek war ein SPOT GPS-Tracker an Bord von Fipofix. Nach Konfigurationsproblemen und „da er sich als „Batterienfresser“ entpuppt hat“ wurden die Positionen schliesslich manuell mittels Satelliten-Telefon übermittelt und in die Karte eingepflegt. Guido Dwersteg hat sich nach eignen Angaben aufgrund der „idiotensicheren“ Konfiguration und der Tatsache, dass sich diese Systeme seit Jahrzehnten im Regatta-Bereich bewährt haben für YB Tracking entschieden.  

Die Akkulaufzeit hängt sehr vom Trackingintervall sowie der Güte der Satellitenverbindung ab. Bei Bewölkung etwa halten die Batterien z.T. deutlich kürzer.

Manuelles Positionsupdate per eMail

Zu guter letzt bleibt der manuelle Weg, für den sich Johannes Erdmann nach eigenen Angaben aus Kostengründen entschieden hat. Hier übermittelt der Skipper die aktuellen Koordinaten per eMail via Satellitentelefon oder Kurzwelle an einen Service wie spotwalla.com um sie so auf der eigenen Homepage darzustellen. Auch wenn diese Option sicherlich die meisten Freiheiten lässt (man kann/könnte sogar ganze Blogbeiträge von unterwegs übermitteln…) dürfte Sie für Gelegenheitsnutzer aufgrund der benötigten technischen Ausrüstung (Kurzwellenfunkgerät bzw. Satellitentelefon) oft keine wirkliche Alternative zu den oben vorgestellten Gadgets sein.

Weiterführende Links zum Artikel:

http://www.findmespot.eu
http://www.ybtracking.com
http://www.delorme.com
http://www.spotwalla.com
http://www.expeditionstechnik.de/

Vielen Dank!

Vielen Dank an Johannes Erdmann, Guido Dwersteg und Norbert Sedlacek, die mir bereitwillig Auskunft über das von Ihnen verwendete System und dessen Vor- und Nachteile gegeben haben.

1Die diversen auf dem Markt befindlichen Tracking Apps für Smartphones, wurden in diesem Artikel ausgeschlossen, da diese aufgrund des vorausgesetzten Mobilfunknetzes allenfalls in Sichtweite zur Küste funktionieren.

Breitband auf See – Schnelles Internet auf Segelyachten und Motoryachten

Im Zeitalter von Social Media und Videostreamingportalen, ist eine schnelle Internet Anbindung für viele auch auf See unabdingbar (oder zumindest wünschenswert). GRIB Wetterdaten per eMail über das Kurzwellenfunkgerät zu empfangen ist bereits seit Jahrzehnten möglich. Die maximale Datenübertragungsrate per Kurzwelle liegt hierbei mit aktuellen PACTOR IV Modems jedoch bei nur rund 10 kBit/s. Eine 50 kByte grosse GRIB Datei liesse sich damit im Idealfall(!) innerhalb von 40 sec herunterladen. Tatsächlich sind die Datenübertragungsraten jedoch je nach äusseren Gegebenheiten (z.B. Wetter) deutlich langsamer und die Übertragung von GRIB Daten kann mitunter viele Minuten dauern. Wenn die zu übertragende Datenmenge einige Kilobyte übersteigt, wird es entsprechend noch mühsamer.

Zum Vergleich: Die ersten Modem Modelle Anfang der 90er Jahre ermöglichten bereits eine Internetanbindung mit (theoretisch) bis zu 14.4 kBit/s. Aktuelle DSL Anschlüsse bieten gar Geschwindigkeiten jenseits der 100 Mbit/s also 100.000 kBit/s Grenze. Damit lassen sich auf dem Festland in 40 sec (erneut im Idealfall) bereits 500 Megabyte an Daten herunterladen.

Doch wie sieht es fernab des heimischen Wohnzimmers an Bord einer Yacht aus? Welche Datenübertragungsrate lässt sich hier heutzutage bestenfalls realisieren? Gibt es Mbit Verbindungen auch auf hoher See? Was kostet das ganze? Wie wird es technische realisiert? Dieser Artikel soll den derzeitigen „state-of-the-art“ beleuchten.

Die zweite Technik die neben dem Kurzwellenfunk für einen weltweit verfügbaren Internetanschluss an Bord eines Schiffes in Frage kommt, ist die Datenübertragung per Satellitenverbindung. Grundsätzlich gibt es zwei Satelittennetze die eine (fast) weltweite Abdeckung bieten: Inmarsat und Iridium.

Während Inmarsat auf ein Netzwerk aus geostationäre Satelliten in Höhe von 36000 km setzt, kommt bei Iridium ein Netz aus Satelliten zum Einsatz, die in einer Höhe von 780 km ständig um die Erde kreisen. Dies führt zu einigen Besonderheiten und Einschränkungen der jeweiligen Netze:

Inmarsat kann aufgrund der Position der Satelliten über dem Äquator die Polbereiche nicht abdecken (auch wenn die polnische Segelyacht Selma kürzlich auf 78° Süd vorgedrungen ist, dürfte dies für die meisten Segler zu verschmerzen sein). Ausserdem muss man die Antenne des Empfangsgerätes in Richtung des scheinbar still stehenden Satelliten ausrichten um eine optimale Verbindungssqualität zu erreichen.

Iridium baut auf einem Netzwerk aus Satelliten auf, deren Umlaufgeschwindigkeit um die Erde bei ca 100 min liegt. Dadurch sind sämtliche Bereiche der Erde abgedeckt und eine Ausrichtung der Antenne in Richtung eines Satelitten ist nicht notwendig. Allerdings muss bei längerer Downloads/Telefongesprächen der Satellit über den kommuniziert wird, gewechselt werden. Dies geschieht zwar voll automatisch, kann im schlimmsten Fall jedoch zu Verbindungsabbrüchen führen.

Übersicht über festinstallierte Breitband Satellitenkommunikationslösungen im Marine Bereich

Inmarsat FleetBroadband Sailor 500 Inmarsat Fleet One Iridium Pilot
Grösse Antenne: 605 x Ø 630 mm
Empfangsgerät: 42,5 x 264,5 x 273 mm
Antenne: 291,9 x Ø 275,6 mm
Empfangsgerät: 278 x 264 x 41 mm
Antenne: 230 x Ø 570 mm
Empfangsgerät: 250 x 200 x 55 mm
Gewicht Antenne: 16 kg
Empfangsgerät: 2,5 kg
Antenne: 3,9 kg
Empfangsgerät: 2,0 kg
Antenne: 11 kg
Empfangsgerät: 1,35 kg
Satellitennetz Inmarsat Inmarsat Iridium
Max. Geschwindigkeit 432 kBit/s 100 kBit/s 134 kBit/s
Hardware Kosten ca. 16.000,- EUR ca. 4.000,- EUR ca. 5.500,- EUR
Laufende Kosten(zzgl. MWSt.)* Aktivierung: 63,03 USD
ab 88,94 USD/Monat (inkl. 5 MByte), anschliessend 17,79 USD pro MByte (Abrechnungstakt 50 kByte)
Aktivierung: 67,23 USD
ab 63,53 USD/Monat (inkl. 10 MByte), anschliessend 6,36 USD (Home Region) bzw. 36,30 USD (Outside Home Region) pro MByte (Abrechnungstakt 20 kByte)
Aktivierung für 0MB Plan: 300,- USD
ab 0,- USD/Monat, dann 16,10 USD pro MByte (Abrechnungstakt 1 Byte).
Mindestvertragslaufzeit: 12 Monate

Bezüglich der maximal erreichbaren Geschwindigkeit liegt das Inmarsat Satellitennetz derzeit also vorn. Hier sind Übertragungsraten von bis zu 492 Kbit/s (also knapp 0.5 Mbit/s) möglich. Einen echten Mbit Internetzugang auf See sucht man derzeit noch vergeblich.

Lösungen die über das an jedem Ort verfügbare Iridium Netz kommunizieren sind derzeit noch deutlich langsamer. Allerdings steht mit Iridium NEXT bereits ein neues Netzwerk mit zusätzlichen Satelliten in den Startlöchern mit dem ab 2017 bis zu 512 kBit/s möglich sein sollen.

Die oben aufgeführten Kosten (an dieser Stelle vielen Dank an m-cramer Satellitenservices für die freundliche Auskunft) machen deutlich, dass die verfügbaren marinen Breitbandlösungen allesamt sehr hochpreisig sind. So kostet doch ein einziger heruntergeladener Film (z.B. 1 GByte = 1000 MByte) bereits viele tausend Euro.

Günstigere Lösungen mit Abstrichen

Für Freizeit-Kapitäne, die in Sachen Wasserfestheit und Toleranz von Schiffsbewegungen kompromissbereit sind und per Satellit lediglich in der Marina im Internet surfen möchten, gibt es sowohl im Iridium als auch Inmarsat Netz „low cost“ Lösungen:

Zum einen ist hier das Iridium Go für rund 900,- EUR zu nennen. Hier muss der Anwender neben einer maximalen Geschwindigkeit von 2.5 kBit/s auch die Tatsache, dass eine Kommunikation nur über ganz bestimmte Apps möglich ist in Kauf nehmen. Das Iridium Go ist lediglich dazu gedacht, Smartphones und Tablets auch Abseits von Mobilfunknetzen mit eigens dafür angebotenen Apps mit Daten zu versorgen bzw. Statusmeldungen auf Twitter oder Facebook absetzen zu können. Den gewohnten eMail Client zu nutzen oder gar mit seinen Laptop zu surfen ist mit diese Lösung nicht möglich.

Iridium Go

Inmarsat schickt mit dem iSavi Inmarsat IsatHub für einen etwas höheren Preis von rund 1350,- EUR ebenfalls einen Vertreter in dieser erschwinglicheren Klasse ins Rennen. Mit diesem Gadget ist der Aufbau eines „normalen“ WLAN Netzes möglich, mit dem sich sämtliche WLAN fähigen Geräte verbinden lassen um mit den gewohnten Programmen im Internet zu surfen oder eMails zu empfangen. Die maximale Geschwindigkeit von bis zu 384 kBit/s lässt den etwas höheren Preis im Vergleich zum Iridium Go sicher verschmerzen:

iSavi Inmarsat IsatHub

Wer eine bezahlbare Lösung für den Internetzugang fernab der Heimat sucht und sich auf den Liegeplatz im Hafen beschränken kann, sollte das iSavi von Inmarsat in Betracht ziehen…

Zu guter Letzt sei erwähnt, dass es durchaus auch Modems als Zubehör für Satellitentelefone gibt. Diese kosten um 200,- EUR und ermöglichen zusammen mit einem bereits vorhandenen Satellitentelefon den Aufbau eines WLAN bzw. LAN Netzes an Bord. Damit sind jedoch ebenso wie mit dem Iridium Go nur Übertragungsraten von wenigen kBit/s möglich, die sich auch über die Eingangs erwähnte Kurzwellenverbindung realisieren lassen.

Übersicht: http://www.groundcontrol.com
deutschsprachige Übersicht: http://www.m-cramer-shop.de bzw. http://www.expeditionstechnik.de

OpenCPN und der AIS Empfänger für den heimischen Küchentisch

Auch der heutige Beitrag wurde durch meine Leidenschaft fürs Segeln getriggert und ist gleichzeitig der erste Artikel der neuen Kategorie „Tech-Gadgets“. Konkret geht es in diesem Artikel um PIA, einen kombinierten USB AIS– und GPS Empfänger von aisspotter.com, doch der Reihe nach:

AIS oder das Automatic Identification System ist ein System, bei dem per Funk Navigations- und anderen Daten zwischen Schiffen ausgetauscht werden, um die Sicherheit im Schiffsverkehr zu verbessern. Während ein AIS Transceiver (kombinierter Sender und Empfänger) in der Berufsschifffahrt Pflicht ist, verwenden zahlreiche Freizeitkapitäne freiwillig einen AIS Empfänger, um größere Schiffe in der Umgebung des eigenen Bootes auch bei schlechter Sicht (Nachts, Nebel, etc) ohne Radar zu erkennen und den eigenen Kurs frühzeitig anpassen zu können um eine Kollision zu vermeiden.

Neben der aktuellen Position der Schiffe werden per AIS mit Kurs, Geschwindigkeit, Zielort usw. auch eine ganze Reihe weiterer interessanter Details geliefert.

Da AIS Informationen im UKW-Seefunkbereich (161,975 MHz (Kanal 87B) bzw. 162,025 MHz (Kanal 88B)) gesendet werden, wird ein AIS Empfänger klassischerweise an das an Bord befindliche UKW-Funkgerät gekoppelt. Der Clu bei PIA ist nun, dass man gar kein Funkgerät benötigt, um diese AIS Signale empfangen zu können. In Kombination mit einem Laptop erledigt dies ein USB-Stick, an den eine externe Funkantenne angeschlossen wird.

Das PIA Set enthält ausserdem einen GPS-Empfänger mit dem die eigene Position ermittelt werden kann um z.B. einen automatischen Kollisionswarner zu verwirklichen.

Navigations Software

Das in Kombination mit PIA von mir eingesetzte OpenCPN ist eine kostenlose Chart Plotter und Navigationssoftware.

OpenCPN

AIS Empfänger PIA:

PIA_AIS-GPS-Empfänger

Lieferumfang: UKW-Antenne mit Magnetfuß, festverbundenes Antennenkabel (ca. 2.5 m, MMCX Stecker) zum Anschluss am USB-Stick (in den der GPS Empfänger integriert ist), Antennenadapter von MMCX auf BNC Buchse (z.B. zur Verwendung mit einer bereits vorhandenen UKW Antenne)

Kosten: 159,- €
z.B. hier: http://busse-yachtshop.de/s/AIS-Empfaenger-GPS-Empfaenger-im-USB-Stick-Gehaeuse-PIA-mit-AIS-Tischantenne

Installation & Konfiguration:

Damit das AIS/GPS Gadget betrieben werden kann, sind entsprechende Treiber notwendig. Diese werden auf aisspotter.com kostenlos zum Download angeboten bzw. dort verlinkt.

Windows Laptop: (fast) Plug&Play: Einstöpseln und Treiber auf aisspotter.com herunterladen, fertig.

MacBook Pro (MacOs X): Download des Virtual Com Port Drivers von FTDIchip, anschließend wird das Gadget ebenso problemlos erkannt wie beim Windows System.

Wichtig: In OpenCPN muss anschliessend unter Options>Connections zwingend die richtige Baudrate von PIA (38400) eingestellt werden.

Bildschirmfoto 2015-02-15 um 16.34.27

Ob OpenCPN anschliessend Signale empfängt, lässt sich auch ohne aktive AIS Ziele in der Umgebung über das NMEA Debug Window feststellen.

Bildschirmfoto 2015-02-15 um 16.36.02

Dieses sollte sich (korrekte Konfiguration vorausgesetzt) im Abstand von 1 Sekunde selbstständig aktualisieren und etwa so aussehen:

Bildschirmfoto 2015-02-15 um 16.36.31

Ergebnis:

Je nach Empfangsqualität werden nun nach einiger Zeit die AIS Ziele der Umgebung angezeigt.

OpenCPN auf MacBook Pro (MacOs X) mit ENC Binnenkarte "Hochrhein"

AIS Signal in OpenCPN auf MacOs mit ENC Binnenkarte „Hochrhein“

OpenCPN MacOs mit OpenSeaMap

OpenCPN MacBook Pro (MacOs X) mit entsprechendem OpenSeaMap Ausschnitt

Fazit & Kritikpunkt:

Auf dem heimischen Balkon funktioniert das ganze prima. Die eigene GPS Position wird ermittelt und in OpenCPN angezeigt. Anschliessend erscheinen nach einigen Sekunden auch nach und nach die AIS Ziele der näheren Umgebung.

Führt man jedoch lediglich die AIS/UKW Antenne inkl. Kabel durch ein Fenster nach draussen, um gemütlich auf dem Sofa sitzend den Schiffsverkehr zu beobachten, bereitet der GPS Empfang Probleme (der Empfänger ist im USB Stick verbaut). Häufig wird kein GPS Signal empfangen, was die Nützlichkeit des Gadgets erheblich einschränkt, denn nur bei (ständig aktualisiertem) eigenem GPS Signal lässt sich mit OpenCPN ein automatischer Kollisionswarmer realisieren. Zugegeben: Im Wohnzimmer dürfte das Kollisionsrisiko überschaubar sein, aber:

Da bei Beitrieb auf einer Segelyacht das Laptop eher unter als an Deck platziert wird, wäre es sinnvoll gewesen, den GPS Empfänger in den Fuss der UKW-Antenne, statt in den USB Stick zu integrieren.

Dann müsste man lediglich ein (dann kombiniertes USB/Antennenkabel) durch eine Luke an Deck führen um unter Deck arbeiten zu können. Ob das vorliegende Gadget in der Lage ist unter (GFK-) Deck überhaupt ein GPS Signal zu empfangen, wird sich beim geplanten Feldversuch im Ionischen Meer Ende Mai zeigen. Falls dem nicht so ist, wäre ein möglicher Work-Around  ein USB-Verlängerungskabel und ein wasserdichtes Gehäuse für den USB Stick, doch dazu evtl. nach dem Test unter Outdoor-Bedingungen mehr.

PHP Gezeiten berechnen | Gezeiten PHP Skript | Ebbe und Flut berechnen | Teil 5

Qualitätskontrolle und weitere Verbesserungen

Im fünften und letzten Teil unseres kleinen Tutorials „PHP Gezeiten berechnen“ geht es um den Vergleich der von unserem Ebbe und Flut PHP Script gelieferten Daten mit der Realität.

Dieser fällt zunächst ernüchternd aus:

Ebbe_und_Flut_PHP_Gezeiten_qc1

Problem 1: Unser Skript kann Ebbe und Flut berechnen (Zeitpunkte und Wasserstände). Aber: während zumindest die Zeitpunkte für die Hochwasserevents relativ gut mit der Realität übereinstimmen, trifft unsere Annahme, die Niedrigwasserzeitpunkte würden exakt in der Mitte zwischen zwei Hochwassern liegen offensichtlich nicht zu. Lösung: Statt vom Benutzer lediglich einen Hochwasserevent abzufragen und davon ausgehend künftige Hoch- und Niedrigwasser-Zeiten zu berechnen, fügen wir mit $LW_event_user_timestamp eine weitere Benutzereingabe ein, nämlich ein reales, beobachtetes Niedrigwasser, das uns als Berechnungsgrundlage für künftige Niedrigwasserzeitpunkte dient. Auch hier sollte ein Zeitabstand von 44700 s gelten.

Damit stimmen nun beide Zeitpunkte gut überein:

Ebbe_und_Flut_PHP_Gezeiten_qc2

Problem 2: Unsere zwischen 1.44 und 0.56 schwankende Extremfaktorfunktion fällt im Vergleich zur Realität viel zu schnell ab. Lösung: Das Hochwasser schwankt in Dover zwischen 7.27 m (100%, entspricht 1.44) und 5.54 m (76.2%). Unser Skript geht derzeit jedoch von einer Schwankung zwischen 100% und 56% aus, was zum beobachteten zu schnellen Abfall führt. Verwenden wir für die Schwankungen von Hochwasser und Niedrigwasser nicht unsere Extremfaktorfunktion sondern Funktion Nr. 2 aus Teil 2 sollte dieses Problem behoben sein.

Problem 3: Dem aufmerksamen Beobachter fällt noch eine weitere Ungenauigkeit auf: In der Realität (zumindest an unserem Beispielort Dover) beobachtet man den höchsten Wasserstand (7.27 m) eben nicht wie erwartet bei Voll- oder Neumond sondern erst 2.558 Tage später. Das niedrigste Niedrigwasser fällt jedoch ziemlich exakt mit den Mondextremereignissen zusammen. Lösung: Ich habe für Ebbe und Flut eine „offset“ Variable eingefügt, die dies berücksichtigt.

Schlussendlich sieht unser fertiges PHP Ebbe und Flut Skript also so aus:

//Benutzerangaben z. B. via Formular
$MaxHW=7.27;
$MinHW=5.54;
$MaxLW=1.96;
$MinLW=0.2;
$HW_offset=2.558;
$LW_offset=0;
//$HW_event_user=01.01.2014 10:42
$HW_event_user_timestamp=gmmktime(23,07,00,01,01,14);
//$LW_event_user=02.01.2014 06:31
$LW_event_user_timestamp=gmmktime(06,31,00,01,02,14);
//andere Konstanten
$pi=3.1415927;
$two_pi=2*$pi;
//Aus der Monddatenbank entsprechend des eingegebenen Hochwasserdatums die Periodizität berechnen im Bsp 14.73472 Tage = 1273080 s
$extreme_period_sec=1273080;
$extreme_period_days=$extreme_period_sec/(60*60*24);
//letztes Extremereignis aus der Datenbank auslesen
$last_extreme_event_timestamp=gmmktime(11,14,00,01,01,14);
$delta_seconds=$HW_event_user_timestamp-$last_extreme_event_timestamp;
$delta_days=$delta_seconds/(60*60*24);
$HW_event[]=$HW_event_user_timestamp;
$LW_event[]=$LW_event_user_timestamp;
$HW_delta_days[]=0;
 
$i=0;
//HW_events und Wasserhöhen berechnen
while($i<7)
{
$HW_event[]=$HW_event[$i]+44700;
$HW_delta_days[]=$HW_delta_value=($HW_event[$i]-$last_extreme_event_timestamp-$HW_offset)/(60*60*24);
$HW_value[]=($MaxHW-$MinHW)/2*COS($two_pi/$extreme_period_days*$HW_delta_days[$i])+($MinHW)+($MaxHW-$MinHW)/2;
$i++;
}
 
//LW_events und Wasserhöhen berechnen
$i=0;
while($i<7)
{
$LW_event[]=$LW_event[$i]+44700;
$LW_delta_days[]=$LW_delta_value=($LW_event[$i]-$last_extreme_event_timestamp-$LW_offset)/(60*60*24);
$LW_value[]=($MaxLW-$MinLW)/2*COS($two_pi/$extreme_period_days*$LW_delta_days[$i]+$extreme_period_days)+($MinLW)+($MaxLW-$MinLW)/2;
$i++;
}
 
echo "
<table border='1'>
<tbody>
<tr>
<td>HW</td>
<td>Wasserstand</td>
<td>NW</td>
<td>Wasserstand</td>
</tr>"; $i=0; while($i<7) { echo "
<tr>
<td>".$HW_event_formated = gmdate("d.m.Y H:i",$HW_event[$i])."</td>
<td>".number_format($HW_value[$i], 2)."</td>
<td>".$LW_event_formated = gmdate("d.m.Y H:i",$LW_event[$i])."</td>
<td>".number_format($LW_value[$i], 2)."</td>
</tr>
"; $i++; } echo "</tbody>
</table>";
HW Wasserstand NW Wasserstand
01.01.2014 23:07 7.27 02.01.2014 06:31 0.37
02.01.2014 11:32 7.25 02.01.2014 18:56 0.27
02.01.2014 23:57 7.19 03.01.2014 07:21 0.22
03.01.2014 12:22 7.09 03.01.2014 19:46 0.20
04.01.2014 00:47 6.96 04.01.2014 08:11 0.23
04.01.2014 13:12 6.80 04.01.2014 20:36 0.30
05.01.2014 01:37 6.62 05.01.2014 09:01 0.40

Und liefert mit weniger als 50 Zeilen Code folgende Daten, die im grafischen Vergleich doch relativ gut mit der Realität übereinstimmen:

Ebbe_und_Flut_PHP_Gezeiten_qc3

Das in diesem Tutorial entwickelte Script oder Teile davon können gerne unter Angabe der Quelle verwendet werden. Bitte jedoch immer mit dem Hinweis, dass die berechneten Daten keinesfalls zur Navigation verwendete werden sollten.

Viel Spaß und hoffentlich: Immer eine handbreit Wasser unterm Kiel…

PHP Gezeiten berechnen | PHP Ebbe und Flut berechnen | Teil 4

Weiter geht´s mit der Herausforderung mit „PHP Ebbe und Flut berechnen

Angenommen an unserem Beispielort Dover liegt das höchste mögliche Hochwasser (extreme Wetterverhältnisse, Tornados, Sturmfluten, Tsunamis etc. lassen sich nicht vorhersagen und bleiben ausgeklammert) bei 7.27 m und das niedrigste möglich Niedrigwasser bei 0.20 m. Der maximale Tidenhub (der ja bei Springzeit auftreten sollte) liegt dann bei 7.07 m.

Wir erinnern uns an unsere Extremfaktor-Funktion aus Teil 2:

y=0.44*cos(2pi/14.8961805555x)+1 

X war hierbei der Abstand in Tagen vom beobachteten Extremereignis.

Einige Zeilen PHP Code später, liefert uns unser Gezeiten-Skript eine Tabelle der nächsten 7 Ebbe und Flut (oder Hoch- und Niedrigwasser-) Ereignisse und der zugehörenden Wasserstände:

//Benutzerangaben z. B. via Formular
$max_HW=7.27;
$min_LW=0.2;
//$HW_event_user=01.01.2014 10:42
$HW_event_user_timestamp=gmmktime(23,07,00,01,01,14);
//Aus der Monddatenbank entsprechend des eingegebenen Hochwasserdatums die Periodizität berechnen im Bsp 14.73472 Tage = 1273080 s
$extreme_period_sec=1273080;
$extreme_period_days=$extreme_period_sec/(60*60*24);
//letztes Extremereignis aus der Datenbank auslesen
$last_extreme_event_timestamp=gmmktime(11,14,00,01,01,14);
$pi=3.1415927;
$two_pi=2*$pi;
$delta_seconds=$HW_event_user_timestamp-$last_extreme_event_timestamp;
$delta_days=$delta_seconds/(60*60*24);
$HW_event[]=$HW_event_user_timestamp;
$LW_event[]=$HW_event_user_timestamp+22350;
$HW_delta_days[]=0;
$i=0;
//HW_events, Extremheitsfaktor und Wasserhöhen berechnen
while($i<7)
{
$HW_event[]=$HW_event[$i]+44700;
$HW_delta_days[]=$HW_delta_value=($HW_event[$i]-$last_extreme_event_timestamp)/(60*60*24);
$Extreme_factor_HW[]=$Extreme_value_HW=0.44*COS($two_pi/$extreme_period_days*$HW_delta_value)+1;
$HW_value[]=$max_HW*$Extreme_value_HW/1.44;
$i++;
}
 
$i=0;
while($i<7)
{
$LW_event[]=$LW_event[$i]+44700;
$LW_delta_days[]=$LW_delta_value=($LW_event[$i]-$last_extreme_event_timestamp)/(60*60*24);
$Extreme_factor_LW[]=$Extreme_value_LW=0.44*COS($two_pi/$extreme_period_days*$LW_delta_value)+1;
$LW_value[]=$min_LW*1.44/$Extreme_value_LW;
$i++;
}
 
$i=0; while($i<7) { echo "
"; $i++; } echo "
<table border='1'>
<tbody>
<tr>
<td>HW</td>
<td>Wasserstand</td>
<td>NW</td>
<td>Wasserstand</td>
</tr>
<tr>
<td>".$HW_event_formated = gmdate("d.m.Y H:i",$HW_event[$i])."</td>
<td>".number_format($HW_value[$i], 2)."</td>
<td>".$LW_event_formated = gmdate("d.m.Y H:i",$LW_event[$i])."</td>
<td>".number_format($LW_value[$i], 2)."</td>
</tr>
</tbody>
</table>
HW Wasserstand NW Wasserstand
01.01.2014 23:07 7.22 02.01.2014 05:19 0.20
02.01.2014 11:32 7.07 02.01.2014 17:44 0.21
02.01.2014 23:57 6.81 03.01.2014 06:09 0.22
03.01.2014 12:22 6.48 03.01.2014 18:34 0.23
04.01.2014 00:47 6.07 04.01.2014 06:59 0.25
04.01.2014 13:12 5.61 04.01.2014 19:24 0.27
05.01.2014 01:37 5.13 05.01.2014 07:49 0.30

So weit so gut, wir haben ein PHP-Script geschrieben, dass uns Ebbe und Flut Zeiten und zugehörige Wasserstände vorhersagt. Im nächsten Schritt testen wir durch Vergleich mit „echten“ Daten, was das Skript bereits taugt und wie wir es weiter verbessern können…

PHP Gezeiten berechnen | Ebbe und Flut per PHP Script | Teil 3

Nachdem wir uns bisher notwendigerweise mit Mondphasen und trigonometrischen Funktionen als Grundlagen beschäftigt haben, heute die Zeiten von Hoch- und Niedrigwasser: Wann kommt die Flut?

Geplant ist z.B. per Formular folgende Parameter an das PHP Skript zu übergeben:

  • Extrem HW
  • Extrem NW
  • Datum (unsere Datenbank ist auf 2014 beschränkt!) und Uhrzeit des letzten beobachteten Hochwassers

Das Skript soll anhand des Datums berechnen, welches Mondextremereignis am nächsten vor diesem Datum liegt (Vollmond oder Neumond) und wie lange der aktuelle Mond-Monat (von diesem Extremereignis zum nächsten) dauert. Von dieser Springzeit aus, berechnen wir einen Vorfaktor der angibt wie gross der Einfluss der Sonne auf die Gezeiten aktuell ist.

Bsp.: Aufgrund der Tatsache, dass es an unserem bisher verwendeten Beispielort (Hamburg) einen Wechsel zwischen Sommer und Winterzeit gibt und Hamburg sich nicht in der GMT Zeitzone befindet, habe ich für die folgenden Berechnungen Dover als Beispielort gewählt, da die dann verfügbaren Vergleichsdaten direkt in GMT vorliegen und keine Umrechnung vorgenommen werden muss.

Die Uhrzeit der vorhergesagten Hochwassers/Niedrigwasser Ereignisse berechnen wir näherungsweise mit unserer Funktion Nr 3:

Angenommen des vom Benutzer eingegebene Hochwasser war 01.01.2014 10:42:00. In Form eines Unix-GMT timestamps also

$timestamp=gmmktime(10, 42, 00, 1, 1, 2014)

Von einem Hochwasser zum nächsten dauert es 0.51736 Tage oder 0.51735d*24h*60min*60s= 44699,904 Sekunden (wir rechnen mit 44700).

Das vom Benutzerzeitpunkt aus gesehene Hochwasser findet also zu folgender Zeit statt:

echo $timestamp=gmmktime(10, 42, 00, 1, 1, 2014)." + 44700 statt:";
$next_HW=$timestamp+44700;
echo $next_HW."
 Also am: ";
echo gmdate("d. M. Y - H:i:s", $next_HW);

1388572920 + 44700 statt:1388617620
Also am: 01. Jan. 2014 – 23:07:00

Wollen wir nun die nächsten 7 Hochwasserereignisse ausgeben geht das mit folgender Schleife:

$timestamp=gmmktime(10, 42, 00, 1, 1, 2014);
$i=1;
$next_HW=$timestamp;
while($i&lt;=7) 
{
$next_HW=$next_HW+44700;
echo $i." | ".$next_HW." | ";
echo gmdate("d. M. Y - H:i:s", $next_HW);
echo "
";
$i++;
}

Was uns die folgende Liste liefert:

1 | 1388617620 | 01. Jan. 2014 – 23:07:00
2 | 1388662320 | 02. Jan. 2014 – 11:32:00
3 | 1388707020 | 02. Jan. 2014 – 23:57:00
4 | 1388751720 | 03. Jan. 2014 – 12:22:00
5 | 1388796420 | 04. Jan. 2014 – 00:47:00
6 | 1388841120 | 04. Jan. 2014 – 13:12:00
7 | 1388885820 | 05. Jan. 2014 – 01:37:00

Die Uhrzeiten der Hochwasserereignisse hätten wir, es folgt analog dazu die Zeit des Niedrigwassers. Näherungsweise gehen wir davon aus, dass zwischen HW und NW immer 44700/2 also 22350 Sekunden liegen.

$timestamp=gmmktime(04, 56, 00, 1, 16, 2014);
$i=1;
$next_LW=$timestamp;
while($i&lt;=7) 
{
$next_LW=$next_LW+22350;
echo $i." | ".$next_LW." | ";
echo gmdate("d. M. Y - H:i:s", $next_LW);
echo "
";
$i++;
}

1 | 1388595270 | 01. Jan. 2014 – 16:54:30
2 | 1388617620 | 01. Jan. 2014 – 23:07:00
3 | 1388639970 | 02. Jan. 2014 – 05:19:30
4 | 1388662320 | 02. Jan. 2014 – 11:32:00
5 | 1388684670 | 02. Jan. 2014 – 17:44:30
6 | 1388707020 | 02. Jan. 2014 – 23:57:00
7 | 1388729370 | 03. Jan. 2014 – 06:09:30

Die Zeitpunkte hätten wir damit. Es fehlt die Berechnung des erwarteten Wasserstands aus den Extremwerten mittels Vorfaktor-Funktion.

Im nächsten Teil kommt es hoffentlich endlich zum „PHP Ebbe und Flut berechnen“.

PHP Gezeiten berechnen | Ebbe und Flut | Teil 2

In Teil 1 haben wir mittels gmmktime() timestamps sämtlicher Mondphasen für 2014 erzeugt und in einer Datenbank abgelegt. Wir nähern uns langsam dem PHP Gezeiten Rechner, auch wenn man dieses Kapitel alternativ mit „Wiederholung trigonometrischer Funktionen“ hätte überschreiben können…

Wie man aus unserer Monddatenbank leicht errechnen kann, lagen zwischen dem 1. und 2. Vollmond 2014 genau (!) 2574060 Sekunden (oder 29.7923611111 Tage) also rund 6.28 Stunden mehr als der Mittelwert unserer ersten Näherung.

Dies kann man als trigonometrische Funktion darstellen. Ich habe mich für den Cosinus entschieden.

Man erinnert sich an die Schulzeit y=cos(x). Mit einigen Modifikationen was Amplitude und Frequenz angeht landen wir bei:

1) y=0.5*cos(2pi/29.7923611111x)+0.5

cos_mondphasen

x ist hierbei die Anzahl der Tage seit dem letzen Vollmond, wenn x=14 ist, ist gerade Neumond, bei x=7 befinden wir uns im „letzten Viertel“ etc.

Wir brauchen noch weitere periodische Funktionen, mit deren Hilfe unser PHP-Script dann später die Berechnung von Ebbe und Flut vornehmen kann. Beim BSH erfährt man, dass zwischen 2 Hochwassern im Durchschnitt (Achtung Näherung!) 12h und 25 min liegen. Das entspricht 0.51736 Tagen. Wir brauchen also eine Funktion die mit einer Periodizität von eben diesen 0.51736 Tagen oszilliert (von einem (Funktions-)Wellenberg zum nächsten soll es also nicht 2pi sondern 0.51736 dauern).

y=cos(2pi/0.51736x)

Diese Funktion hat die gewünschte Periodizität, die Amplitude beträgt jedoch 1. Angenommen das letzte Hochwasser lag bei 5 Metern und das letzte Niedrigwasser bei 1 Meter, dann bräuchten wir eine Funktion, die um den Mittelwert 3 Meter oszilliert und im oberen Extremfall den Wert 5, im unteren Extremfall den Wert 1 zurück liefert:

y=2*cos(2pi/0.51736x)+1+2

Diese Funktion schwankt mit der gewünschten Periodizität und Amplitude:

cos_tidenhub

Verallgemeinert kann man schreiben:

2) y=(HW-NW)/2*cos(2pi/0.51736x)+1+(HW-NW)/2

Hier ist x Anzahl Tage seit dem letzten Hochwasser, wenn seither 0.51736 Tage vergangen sind, gibt es wieder einen neuen Wellenberg (nächstes Hochwasser). Wenn seither nur 0.25868 Tage vergangen sind haben wir gerade Niedrigwasser…

Die letzte periodische Funktion die wir brauchen, berücksichtigt den Einfluss der Sonne. Stehen Sonne, Erde und Mond in einer Linie (also immer bei Vollmond und Neumond) sind die Gezeiten besonders stark ausgeprägt (der Seemann spricht von Springzeit). Stehen Sonne und Mond von der Erde aus betrachtet im rechten Winkel zueinander, sind die Gezeiten relativ schwach (der Wassersportler spricht von Nippzeit), da der Einfluss der Sonne dem (stärkeren) Einfluss des Mondes entgegen wirkt.

Angenommen wir werten den Einfluss des Mondes auf die Gezeiten mit 100 Punkten. Der Einfluss der Sonne beträgt (Achtung Näherung!) 44% des Einflusses des Mondes, wird also mit 44 Punkten bewertet. Ziehen Sonne und Mond nun also am gleichen Strang (verstärken sich also) erhalten wir einen Gesamteffekt von 144 Punkten. Stehen Sonne und Mond im rechten Winkel zueinander muss die Wirkung der Sonne von der Wirkung des Mondes abgezogen werden. Der Gesamteffekt beträgt dann 100-44=56 Punkte. Wir brauchen also eine Funktion. die zwischen 1.44 und 0.56 oszilliert:

y=(1.44-0.56)/2*cos(2pi/x)+0.56+(1.44-0.56)/2

Wir brauchen eine Periodizität von 29.7923611111/2 also 14.8961805555 Tagen

y=(1.44-0.56)/2*cos(2pi/14.8961805555x)+0.56+(1.44-0.56)/2

Da sich die Werte 1.44 und 0.56 als genäherte Naturkonstanten nicht ändern, können wir vereinfachen:

3) y=0.44*cos(2pi/14.8961805555x)+1 

cos_zusammenspiel_sonne_und_mond

Hier ist x der Tag nach dem letzten extremen Mondereignis, also 3 wenn gerade 3 Tage nach Neumond ist oder 6 wenn 6 Tage nach Vollmond ist.

Wir haben also nun 3 trigonometrische Funktionen die die Gezeitenphänomene näherungsweise beschreiben.

Im nächsten Kapitel basteln wir aus diesen Funktionen ein PHP Skript, dass uns die Rechenarbeit abnimmt. Mein Plan ist dem Skript als Benutzereingabe folgende Daten zu liefern (z.B. über ein Formular):

  • Datum, Uhrzeit des letzten Hoch- und Niedrigwassers
  • Extrem Hoch und Niedrigwasserdaten

Anhand dieser Angaben soll das Skript zunächst (durch Vergleich mit unserer „Vollmond-Datenbank“) ermitteln, in welcher Mondphase diese Daten zustande kamen und anschliessend Wasserstände und Uhrzeiten der nächsten Ebbe und Flut berechnen.

PHP Gezeiten berechnen | Ebbe und Flut | Teil 1

Die Gezeiten hängen vom Stand des Mondes und der Sonne ab.

Da Ebbe und Flut darüber hinaus auch von örtlichen/geographischen Gegebenheiten abhängen, ist mein Ansatz wie folgt: Wie bereits beim Mond erhält man recht verlässliche Angaben (die die örtlichen Gegebenheiten bereits berücksichtigen), wenn man seine Berechnungen auf empirisch beobachtete Ereignisse „aufpfropft“. Will heissen: Wenn man aus Gezeitentabellen weiss, dass z.B. am 01. September 2014 an einem bestimmten Ort um 19:43 Hochwasser ist/war, müsste es möglich sein, den Zeitpunkt des nächsten Hochwassers mittels PHP-Skript zu berechnen (Wir basteln also einen PHP Gezeiten Rechner).

Da es gar nicht so trivial ist, den nächsten Vollmond zu berechnen (bzw. da triviale Lösungen dieses Problems eine Ungenauigkeit von mehreren Stunden aufweisen, was bei Gezeitentabellen natürlich inakzeptabel wäre) bin ich froh, die Berechnung der Mondphasen Profis überlassen zu können. Die NASA veröffentlicht dankenswerterweise Mondphasen Daten für das komplette 21. Jahrhundert (wer am verwendeten Algorithmus interessiert ist wird im Buch Astronomical Algorithms auf knapp 60 (!) Seiten fündig). Auch wenn ein Streben nach Autarkie und die Demonstration des technisch Machbaren sicher erstrebenswert wäre. Ein solches PHP Script würde den Rahmen eines „kostenlosen“ Codeschnipsels sprengen (falls es einen Sponsor gibt der an einer Umsetzung Interesse hat freue ich mich über eine eMail ;-))

Wir werden für die Gezeitenberechnung, die auch so noch ausreichend komplex wird, auf die Daten der NASA zurückgreifen. Und zwar auf den Abschnitt für 2014:

 Year      New Moon       First Quarter       Full Moon       Last Quarter     

 2014   Jan  1  11:14     Jan  8  03:39     Jan 16  04:52     Jan 24  05:19            
        Jan 30  21:39     Feb  6  19:22     Feb 14  23:53     Feb 22  17:15    
        Mar  1  08:00     Mar  8  13:27     Mar 16  17:09     Mar 24  01:46    
        Mar 30  18:45     Apr  7  08:31     Apr 15  07:42 t   Apr 22  07:52    
        Apr 29  06:14 A   May  7  03:15     May 14  19:16     May 21  12:59    
        May 28  18:40     Jun  5  20:39     Jun 13  04:11     Jun 19  18:39    
        Jun 27  08:09     Jul  5  11:59     Jul 12  11:25     Jul 19  02:08    
        Jul 26  22:42     Aug  4  00:50     Aug 10  18:09     Aug 17  12:26    
        Aug 25  14:13     Sep  2  11:11     Sep  9  01:38     Sep 16  02:05    
        Sep 24  06:14     Oct  1  19:33     Oct  8  10:51 t   Oct 15  19:12    
        Oct 23  21:57 P   Oct 31  02:48     Nov  6  22:23     Nov 14  15:16    
        Nov 22  12:32     Nov 29  10:06     Dec  6  12:27     Dec 14  12:51    
        Dec 22  01:36     Dec 28  18:31

Mit Hilfe dieser Tabelle können wir also die Zeitspanne zwischen zwei Vollmonden durch Differenzbildung exakter bestimmen.

Zunächst werden wir diese Zeitangaben in einen UNIX timestamp transformieren und in einer MySQL Datenbank ablegen.

Um Problemen mit Zeitzonen ebenso aus dem Weg zu gehen, wie der Frage ob gerade Sommerzeit oder Winterzeit ist, erfolgen alle Berechnungen in UT (auch GMT). Die Daten in obiger Tabelle beziehen sich ebenfalls auf UT.

Auch PHP weiss um die Zeitzonen Problematik und enthält mit gmmktime() dankenswerterweise eine eigene Funktion um Zeitangaben die in Universal Time gemacht wurden in entsprechende UT-Timestamps umzuwandeln:

echo $timestamp=gmmktime(11, 14, 00, 1, 1, 2014)."
";
//Zur Kontrolle, dass kein Fehler passiert ist lassen wir den timestamp wieder "zurückkonvertieren" und Datum/Uhrzeit ausgeben.
echo gmdate("d.M.Y - H:i:s", $timestamp);

Dieses Script liefert folgende Ausgabe:

1388574840
01.Jan.2014 – 11:14:00

Die MySQL Datenbank, die unsere Monddaten enthält sieht dann etwa so aus:

-- 
-- Tabellenstruktur für Tabelle `moondata`
-- 
 
CREATE TABLE `moondata` (
  `ID` tinyint(4) NOT NULL AUTO_INCREMENT,
  `TYPE` varchar(15) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `TIME` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=MyISAM AUTO_INCREMENT=51 DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci AUTO_INCREMENT=51 ;
 
-- 
-- Daten für Tabelle `moondata`
-- 
 
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (1, 'new', '1389698040');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (2, 'new', '1391117940');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (3, 'new', '1393632000');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (4, 'new', '1396205100');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (5, 'new', '1398752040');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (6, 'new', '1401302400');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (7, 'new', '1403827200');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (8, 'new', '1406414520');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (9, 'new', '1408975980');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (10, 'new', '1411539240');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (11, 'new', '1414101420');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (12, 'new', '1416660720');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (13, 'new', '1419212160');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (14, 'first', '1389152340');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (15, 'first', '1391714520');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (16, 'first', '1394285220');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (17, 'first', '1396859460');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (18, 'first', '1399432500');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (19, 'first', '1402000740');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (20, 'first', '1404561540');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (21, 'first', '1407113400');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (22, 'first', '1409656260');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (23, 'first', '1412191980');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (24, 'first', '1414723680');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (25, 'first', '1417255560');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (26, 'first', '1419791460');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (27, 'full', '1389847920');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (28, 'full', '1392421980');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (29, 'full', '1394989200');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (30, 'full', '1397547720');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (31, 'full', '1400181360');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (32, 'full', '1402632660');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (33, 'full', '1405164300');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (34, 'full', '1407693600');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (35, 'full', '1385775480');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (36, 'full', '1412074260');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (37, 'full', '1415312580');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (38, 'full', '1417868820');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (39, 'last', '1390540740');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (40, 'last', '1393089300');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (41, 'last', '1395625560');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (42, 'last', '1398153120');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (43, 'last', '1400677140');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (44, 'last', '1403203140');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (45, 'last', '1405735200');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (46, 'last', '1408278360');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (47, 'last', '1410833100');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (48, 'last', '1413400920');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (49, 'last', '1415978160');
INSERT INTO `moondata` (`ID`, `TYPE`, `TIME`) VALUES (50, 'last', '1418561460');

Genug für heute, im zweiten Teil folgt die Berechnung der Gezeiten…