Suchen
Benutzer-Anmeldung
Newsfeeds
Wer ist online
Autopilot ansteuern mit NMEA-Datensätzen
erstmal ein dickes Lob an die Entwickler und Danke für dieses Superprogramm!
Für die Ansteuerung eines Autopiloten wurde extra ein Portausgang geschaffen. Das ist auch gut so!
Jedoch wird bei Ansteuerung einer Route nur der NMEA-Datensatz "RMB" ausgegeben- nur dann, und sonst nichts. Diese Info gibt aber nur Ansteuerungsdaten aus (also relative Angaben). Die genaue Position usw ist dem Autopilot bis dahin aber nicht bekannt!
RMC und RMB gemeinsam gelten als minimalste Info`s .
Richtig wäre es m.E. (sogar zwingend notwendig), wenn RMB und RMC abwechselnd ausgegeben werden.
RMC müsste dauernd ausgegeben werden, RMB natürlich nur, wenn die Ansteuerung eines Wege-Punktes oder einer Route
ansteht.
Ob es dann aber auch Sinn macht, weitere NMEA Datensätze durschzuschleifen, etwa Tiefen- oder Wind-Infos könnte man
diskutieren.
Es wäre gut, wenn diese Info an die Entwickler weitergereicht würde.
Viele Grüße
Alexandro
PS Info über die Bedeutung der NMEA - Datensätze kann man leicht bei Google finden!
(Anmerkung vom Admin) Oder u.a. direkt hier: http://www.nmea.de/nmea0183datensaetze.html
Hallo Alexandro!
Vielen Dank für deinen Beitrag. Das ist genau die Art von Feedback, die hilfreich ist, um OpenCPN stetig weiter zu verbessern.
Da ich mich selbst noch nicht mit dieser speziellen Materie beschäftigt habe, habe ich da noch ein paar Rückfragen.
Diese Info gibt aber nur Ansteuerungsdaten aus (also relative Angaben). Die genaue Position usw ist dem Autopilot bis dahin aber nicht bekannt!
Alle mir bekannten Autopiloten bieten grundsätzlich (maximal) 2 Möglichkeiten:
- Sie steuern einen bestimmten Kurs (oder Winkel zum Wind)
- Sie steuern zu einem bestimmten (Weg)Punkt
Welche Informationen für einen der beiden Fälle sollte einem Autopilot denn jetzt fehlen, die nicht im RMB Satz enthalten ist (aber dafür im RTC)?
Und wozu, oder weshalb sollte ein Autopilot die Positionsangabe benötigen?
Abgesehen davon, dass er diese (intern) im Fall 2 auch ganz einfach aus dem RMB Satz berechnen kann.
Es wäre gut, wenn diese Info an die Entwickler weitergereicht würde.
Das kann ich gerne machen (bzw. tue das auch immer). Es steht aber auch jedem frei, dies selber zu tun - siehe Tracker.
Gruß
Gunther
Hallo Alexandro!
Also wenn ich dich richtig verstehe geht es dir darum über den Autopilot Ausgang von OpenCPN auch andere NMEA Sätze zu senden als nur den RMB?
Wozu? Ein Autopilot braucht doch nur diesen Satz.
Und wenn du andere "Listener" mit anderen Sätzen versorgen willst, musst du das halt anders machen, als über OpenCPN.
Aber was ich auch immer noch nicht verstehe ist deine Konstellation?
Hast du keinen "richtigen" (separaten) GPS Empfänger, sondern holst dir deine Position über deinen Autopilot?
Was hast du denn in OpenCPN unter 'Einstellungen' -> 'GPS' -> 'NMEA-Datenquelle' eingestellt und wie sind deine (NMEA) Geräte verbunden, bzw. an deinen Computer mit OpenCPN angeschlossen?
Gruß
Gunther
Hallo Netsurfer,
ich will mal versuchen, die Sachlage weiter zu beschreiben.
Meine Anlage und ich denke die meisten größeren Anlagen sind vernetzt. Das heißt, im günstigsten Fall korrespondieren die einzelnen Geräte über NMEA Daten. Es gibt auch Anlagen, die eigene Protokolle verwenden-
aber meistens ist eine Schnittstelle zu NMEA möglich. Das bedeutet, daß alle Navigationdaten im Netz verteilt werden. (reden wir mal nicht über alleinstehende Pinnensteuerung o.ä.).
Irgend ein GPS-Gerät im Netz liefert Positionsdaten. Nun könnte man aus der Anlage heraus diesen Datenstrom nach Opencpn über den GPS-Port einspeisen. Das funktionier ja auch grundsätzlich. Somit stehen auch andere Daten (Wind, Tiefe usw.) in Opencpn zur Verfügung. Weitere Opencpn - Apps können ja was anfangen mit diesen Daten! Nur leider ist es noch nicht möglich auch Daten von Opencpn an das Netzwerk zurückzugeben (außer RMB).
Vielleicht werden auch zukünftige Apps irgendwas mit solchen Daten anfangen wollen.
Ich glaube, daß sich die grundsätzliche Frage stellt, ob man die Daten mischen oder multiplexen kann.
Wenn das in Zukunft möglich wäre, wären dann Fragen über RMC oder RMB geklärt.
Ich habe lange Jahre Netzwerk-Programme geschrieben- bin inzwischen altersbedingt nicht mehr im Dienst.
Da denkt man halt ein Bisschen andersrum.
Ich freue mich auf weitere Diskussionen!
Grüße
Alexandro
nun bin ich aber auch neugirig geworden. OpenCPN kann ja wunderbar ein AP steuern. Dies tut er, wie ich von dir gelernt habe, mir dem RMB Datensatz. Nun liegt mein unverständnis darin begündet, das ich nicht weis wofür du noch den RMC Datensatz brauchs bzw. haben möchtes. Kann dein AP auch die Posidaten, UTC, Date und SOG anzeigen?
Oder möchtes du generell die über NMEA gesammelten Daten auch noch irgendwo anderes außer in openCPN angezeigt bekommen. Etwa wie eine SeaTalk Multifunktionsanzeige?
Gruß
(-: waarschipper
es geht hier um Netzwerkfragen. Wenn ein System (der Autopilot ist nur ein Teil eines Systems) einen Wegepunkt, muss (das System) doch wenigstens wissen, wo die augenblickliche Position ist.
Selbstverständlich haben doch die meisten Netzwerke noch einige andere Info´s zu bieten (Tiefe, Wind, Kompass usw)
Opencpn kann diese Daten nur von außen bekommen, kann ggf damit was anfangen und sollte m.E. das auch wieder ausgeben können ( incl. seiner eigenen Daten -Route usw).
Das ist jetzt ein Bisschen allgemein formuliert und sollte zu nachdenken anregen.
Gruß
Alexandro
Moin Alexandro,
wenn ich dich nun richtig verstanden habe geht es nicht um eine konkrete Anwendung, wie beispielsweise ein AP oder der gleiche, sondern um das Generelle? Dein AP kann doch an den Ausgang openCPN bleiben, die hier ausgegebenen Daten sind ja vollständig. Und wenn du, wofür auch immer noch die RMC Daten möchtest, so kann du die doch am Ausgang deines Multiplexers parallel abfragen.
Und, verstehe dies bitte nicht falsch, kannst du mir das übersetzen 
:
es geht hier um Netzwerkfragen. Wenn ein System (der Autopilot ist nur ein Teil eines Systems) einen Wegepunkt, muss (das System) doch wenigstens wissen, wo die augenblickliche Position ist.
Hier fehlt mir der Zugang zum Kern der Aussage. Wahrscheinlich Mangels einer Ergänzung nach 'Wegepunkt'.
Der AP bekommt doch die Routeninfo von openCPN und dies ist nur möglich, da die Posidaten dort bekannt sind.
(-: waarschipper
Hallo Waarshipper,
ja natürlich da fehlt ein Wort. Wenn ein System einen "Wegepunkt ansteuern soll".....
Also nun meine Überlegung...
Opencpn auf einem Notebook (z.B.) , ersetzt einen Plotter (oder kann ersetzen) . Plotter haben ein integriertes GPS.
(oder auch nicht).
Somit müsste doch ein Notebook auch die Positionsdaten ausgeben können!
Es wird bereits auf opencpn.de ein link angeboten von einem Programm, das die Info´s eines input-Ports auf mehrere virtuelle Ports verteilen kann. Das ist eine gute Sache! Es gibt auch Hardware , die 2 Portausgänge zusammenmischen kann. (Multiplexer - teuer!) Das zusammenführen von Daten könnte man doch recht einfach im Programm Opencpn "erledigen". Oder?
Natürlich kann man auf 2 Ports die Daten ausgeben (Einer RMC vom GPS , auf dem Zweiten RMB).
Dann hat man 2 Leitungen. Dann muß aber auch eine vorhandene Anlage 2 Inputs haben usw.
Dieser Gedanke widerspricht eigentlich unserer modernen Idee, alles über sowenig Kabel wie möglich zu verteilen. (zB USB, eSata, usw)
Viele Grüße
Alexandro
ich werde immer noch nicht ganz schlau was du vor hast. Kannst du uns bitte einmal mitteilen ob du eine spezielle Anwendung verfolgst oder ob es um Generelles geht. Der Titel handelt ja vom ansteuern eines APs.
Der Vergleich NMEA0183 und eSATA ist nicht ganz fair gegenüber dem NMEA. Dieser Standard kommt ja noch aus dem letztem Jahrtausend. Er kann anders als der CAN Bus nur in eine Richtung Daten übermitteln. Entweder zum lesen oder hören. Deshalb braucht es 2 Kabel, wenn man überall alles haben will.
Nur mir ist keine Anwendung oder vielmehr kein Gerät bekannt, welches diese Daten gebraucht. Außer dem AP. Und der wird ja völlig korrekt mit Daten von openCPN versorgt.
Sollte man die gesammelten Daten doch noch woanders brauchen, so muss man entweder auf SeaTalk oder NMEA2000 Geräten ausweichen. Die können auf dem Bus in beide Richtungen Daten austauschen.
Aber dies braucht man meines Wissens nur, wenn man eine Multifunktionsanzeige hat oder aber eine Windanzeige, die auch versegelte Winddaten anzeigen kann. Dann braucht diese natürlich den COG und SOG.
Bleibt man bei seinen bisherigen NMEA0183 Geräten, so bedarf es einer kleinen Trickserei, um trotzdem alle Daten überall zu habe. Dafür müsste man die NMEA Eingangsdaten parallel abgreifen und leitet sie, wohin auch immer.
(-: waarschipper
schaut doch mal einen einfachen Plotter an, was da so alles mit Schnittstellen geboten wird!!
Die Homepage von Standard Horizon- und da wiederum das Handbuch als PDF geben ganz gut Auskunft.
Da sieht man besser den Stand der Technik von heute.
Und noch immer keine Kritik an Opencpn- das ist ein Superprogramm! Nochmals Danke den Entwicklern!
Dann unterhalten wir uns nochmals....
Mit freundlichen Grüßen
Alexandro
nach einigem Mitlesen denke ich, es könne ja sein,
daß so etwas wie ein "Anreichern der NMEA-Daten" durch Open-CPN gemeint sein könnte.
Alles was auf dem Weg NMEA an Daten kommt vorne hinein
und alles wieder hinten heraus, plus einiges vom Open CPN.
Und wenn alle Sticke reißen, gleich noch auf x-beliebig vielen USB<--->NMEA Schnittstellen-Convertern.
Das klingt mir alles aber sehr nach Sea Clear II,
der kann als Eingang drei Schnittstellen und als Ausgang zwei bedienen,
wobei eine dann konfigurierbar ist. APA, APB, RMB, BOD, BWC, WPL + RTE ..... was will man mehr ?
Hallo Netsurfer,
nun bin ich ja auch nicht jedenTag mit diesem Thema befaßt....
Jedenfalls habe ich bei meiner Anlage (Simrad) mal den Plotter datentechnisch auseinander genommen.
Der Plotter beinhaltet auch das GPS. Die Ausgangsdaten (NMEA) kann man einstellen. Da wird ohne Wahlmöglichkeit immer RMB und RMC gemeinsam angegeben.
RMC gilt auch als Minimum zum Betreiben einer wie auch immer gearteten Positionsarstellung. (also auf einer Land- oder Seekarte).
Das ist der NMEA RMC Datensatz:
Field Number:
1) UTC Time
2) Status, V = Navigation receiver warning
3) Latitude
4) N or S
5) Longitude
6) E or W
7) Speed over ground, knots
8) Track made good, degrees true
9) Date, ddmmyy
10) Magnetic Variation, degrees
11) E or W
12) Checksum
Das ist der NMEA RMB Datensatz:
Field Number:
1) Status, V = Navigation receiver warning
2) Cross Track error - nautical miles
3) Direction to Steer, Left or Right
4) TO Waypoint ID
5) FROM Waypoint ID
6) Destination Waypoint Latitude
7) N or S
8) Destination Waypoint Longitude
9) E or W
10) Range to destination in nautical miles
11) Bearing to destination in degrees True
12) Destination closing velocity in knots
13) Arrival Status, A = Arrival Circle Entered
14) Checksum
RMB enthält also keine Angaben über die momentane Position- es sei denn man errechnet aus den Wegepunktdaten und dem Kurswinkel die aktuelle Position. (durchs Knie in die Brust!)
Außerdem stehen im Falle, daß keine Route angesteuert wird , überhaupt keine Info´s bereit!
Man sollte die Sache nochmals überdenken. Wenn Opencpn aber sogar soundsoviel Datensätze versteht,
also programmintern sowieso die Daten vorliegen, sollte es ein Leichtes sein den RMC mit auszugeben.
Alternativ müßte man GPS-Daten (RMC) und Autopilot-Steuerdaten (RMB) über einen Multiplexer zusammenführen, um sie auf einer Leitung zur Verfügung zu stellen.( das mach ganz sicher überhaupt keinen Sinn).
Der einzige Ausgabeport wäre da natürlich anders zu benamen. Also nicht "Autopilotdaten", sondern "Position und Steuerdaten" oder ähnlich! Vielleicht kann man dann ja sogar weitere Datensätze (auswählbar) mit ausgeben.
Ich freue mich auf weitere Komentare und verbleibe mit
freundlichen Grüßen
Alexandro