Routenkontrolle bei Raymarine Evolution AP

Moin,

kurze Frage bevor ich mein Problem hier ausbreite: hast es jemand geschafft die Routenkontrolle bei einem Raymarine Evolution AP zu aktivieren und die dazu notwendigen Daten von einem Nicht -Raymarine GPS, welches Daten im NMEA0183-Format sendet, via Konverter in den SeaTalkNG-Bus geleitet?

Moin,
da wie ich bereits befürchtet habe, die Resonanz nicht gerade überwältigend war, schildere ich mal das Problem im Detail, in der Hoffnung, daß der Beitrag vielleicht so eher gefunden wird.
Zunächst die Konfiguration:

• Raymarine EV100 System, bestehend aus Kurscomputer EV1, Controlleinheit ACU100, Bedieneinheit p70S und Schubstange Q047 (für Pinne); kein Ruderlagengeber, da Welle nicht zugänglich. Kommunikation über SeaTalkNG-Bus.
• Garmin GPS76 mit der Möglichkeit einer Zielfahrt oder dem Abfahren einer Route ("Navigationsmodus"), Datenschnittstelle NMEA0183;
  Gesendete Datensätze:
  
  
  • $GPRMC
  • $GPGGA
  • $GPVTG
  • $GPGLL
    Zusätzlich beim Navigationsmodus (Anm.: die Sätze sind auch sonst vorhanden, aber leer):
  • $GPBOD
  • $GPBWC
  • $GPRMB
  • $GPXTE
• Yacht Devices YDNG03R bidirektionaler Konverter NMEA0183 <--> STNG

Eigentlich ziemlich simpel - dachte ich: das GPS schickt seine Daten zum Konverter, dieser übersetzt das Ganze nach STNG (was ja N2K bloß mit anderen Steckern ist), das p70S zeigt die Werte an (super zusätzlich eine Tochteranzeige!) und der AP fährt den nächsten WP an.

Im Positionsmodus des GPS werden COG und SOG auf dem p70S einwandfrei angezeigt. Schaltet man am GPS auf auf Navigationsmodus um, dann werden auch BTW, DTW und XTE angezeigt. So weit so gut, aber: als ich dann an der p70S die Routenkontrolle aktivierte bekam ich lapidar die Meldung "Route complete" (ich hab' Englisch als Sprache belassen) und die Anlage ging wieder auf Kompasskurs.
Was ich daraufhin überprüft bzw. verändert habe:

• Der Konverter bietet die Möglichkeit u.a. via Mikro-SD-Karte den ein- und ausgehenden Datenstrom zu protokollieren. Das habe ich gemacht und festgestellt, daß das GPS alle Datensätze korrekt liefert. Die in STNG (also N2K) übersetzten Datensätze kann ich aufgrund der binären Kodierung nicht lesen und daher nicht kontrollieren, ob die Übersetzung korrekt ist.
• Yacht Devices kontaktiert; die haben das Protokoll überprüft und einen Fehler in der Software des Konverters festgestellt. Die Aktualisierung erfolgt gleichfalls (sehr praktisch!) mit der Mikro-SD-Karte; hat bloß nichts gebracht. Des Weiteren haben sie festgestellt, daß ich dem Konverter das Lesen der STNG-Datensätze untersagt hatte - ich war der Meinung, daß dies nicht notwendig sei, da das GPS ja schließlich keine Daten von AP bekommt). Die Neukonfigurierung (man ahnt es schon: mittels Mikro-SD-Karte) hat dann tatsächlich was verändert: nach dem Umschalten am GPS auf Navigationsmodus zeigte das p70S die Kursänderung zum nächsten WP an. Hurra? Leider nein: nach dem Bestätigen kam entweder sofort oder nach kurzer Zeit wieder die Meldung "Route complete".
• Lt. Bedienungsanleitung von Raymarine erfolgt diese Meldung nur, wenn ein MFD angeschlossen ist und dies ist definitiv nicht der Fall.
• Raymarine ist leider nicht sehr kooperativ; die sehen insbesondere Geräte von Yacht Devices nicht gerne in ihrem System.
• Yacht Devices kann man ein Bemühen nicht absprechen.

Ich vermute, daß sich in einem vom Konverter übersetzten STNG-Datensatz etwas befindet, was den AP dazu veranlaßt, die Routenkontrolle abzubrechen. Leider ist wie erwähnt mir der Einblick in die STNG-Datensätze nicht möglich.

Seaskip: könntest Du die Konfiguration in Erfahrung bringen? Vielleicht hilft das ja weiter.

Moin,

ein Bild sagt ja bekanntlich mehr als 1000 Worte.

Einige Bilder aus einem Video über das merkwürdige Verhalten des AP, allerdings noch vor der letzten Änderung der Konfiguration. Damals hat die automatische Umschaltung auf Routenkontrolle am AP noch nicht funktioniert, wenn man am GPS auf Navigationsmodus umgeschaltet hat. Mußte man noch dort erledigen.

Auto-Modus des AP, aber bereits mit kompletter Datenanzeige:
Auto-Modus des AP.png

Nach dem Umschalten auf Routenkontrolle am p70S:
Nach Umschalten auf Routenkontrolle .png
Tatsächlich Start der Routenkontrolle mit einer Drehung nach Steuerbord zum WP:
Routenkontrolle - Kursänderung 1.png Routenkontrolle - Kursänderung 2.png

Abbruch nach einigen Sekunden:

Abbruch.png
Eines ist allerdings merkwündig: den WP hatte ich nicht mit "1" bezeichnet. Evtl. ein Ansatzpunkt?

Moin Andreas,

vielen Dank für Deinen Beitrag.

Interessante Beobachtung, die Du gemacht hast. Normalerweise habe ich die Kompaßseite mit 2 großen Zusatzwerten aktiviert und starte von dort aus in den Navigationsmodus. Ich werde das auf jeden Fall mal ausprobieren, wenn das Schiff denn wieder 'draußen ist. Momentan habe ich in der Halle keine Chance. Allerdings glaube ich nicht so recht daran, da ich über die beschriebene Protokollierung des Konverters Einblick in die NMEA0183 Datensätze habe.

Den Simulatormodus benutze ich überhaupt nicht; wäre fatal, wenn man einen AP damit "steuern" könnte.

Aber mal 'ne andere Frage an die Allgemeinheit: hat jemand ein Programm, mit dem man die N2K-Datensätze "lesbar" machen kann? Ein Beispielprotokoll kann ich gerne mal als Rohdaten (txt), Komma getrennt (txt) oder importiert in Excel hier einstellen.

Ergänzung: hattest Du diesen OpenCPN Mit OpenCPN und Raymarine Wegpunkt abfahren Beitrag gemeint? Die Konfiguration ist bis auf den Transport der NMEA0183-Daten zum Konverter (WLAN statt Kabel) verdammt ähnlich.

Moin Andreas,

sorry, daß ich mich noch nicht wieder gemeldet hatte, hab' meine ganze freie Zeit mit der Vendeé Globe und dem gestrigen Drama verbracht.

Vielen Dank für den Link zu den PGN's. Kannte ich zwar auch bereits, allerdings nur in der Version von 2010.

Ich vermute auch das Problem in den vor Dir genannten PGN's, allerdings nicht bei den Name der Wegpunkte. Diese sind im Datensatz RMB enthalten (Beispiel stammt vom GPS 76):"$GPRMB,A,0.97,L,JACHT-HFN,36,5350.9700,N,00846.2455,E,4.810,112.3,,V,D*4F"

Die Route führt von "Jacht-HFN" zur Tonne "36". Es fehlen aber etliche andere Dinge wie z.B. ETA's; dies dürfte aber für die Steuerung unerheblich sein.
Klar wäre es interessant, mal zu sehen, was ein MFD so von sich gibt. Nur nützt einem das gar nichts, weil die Daten ohne eine entsprechende Decodierung nicht lesbar sind (Beispiel stammt vom Protokoll des Konverters): 00:30:40.422 T 19F90556 20 35 00 00 02 00 00 00
00:30:40.425 T 19F90556 21 00 00 E7 09 01 28 52
00:30:40.552 T 19F90556 22 6F 75 74 65 29 FF 00
00:30:40.554 T 19F90556 23 00 08 01 4F 52 49 47
00:30:40.557 T 19F90556 24 49 4E 1E 17 1A 20 A2
00:30:40.683 T 19F90556 25 F9 37 05 01 00 06 01
00:30:40.685 T 19F90556 26 41 55 54 4F FF FF FF
00:30:40.687 T 19F90556 27 7F FF FF FF 7F

Kurze Erläuterung:
- 1. Feld ist die Zeit seit Einschgalten des Konverters- 2. Feld ist eine Kennzeichnung, ob Empfangen oder wie hier gesendet wird
- 3. Feld ist irdgendwie die PGN : ignoriert man das zweite (9) sowie die beiden letzten Zeichen (56) erhält man "1F905". Umsetzung Hex --> DEz ergibt: 129285!
- 4 - 11. Feld: sind die Daten
Man erkennt, daß die Daten in 8 Zeilen übertragen werden, wobei diese in der Regel nicht direkt hintereinander erfolgen. Im Beispiel habe ich die dazwischenliegenden anderen Datensätze entfernt.

Wenn man den konvertierten Datenstrom dekodieren könnte wäre es relativ einfach, nach signifikaten Unterschieden zu suchen, wenn der AP mit "Route complete" den Trackmodus beendet.Hinweis für jemanden, der es dekodieren kann: zum Zeitpunkt des Beispiels war das GPS noch nicht in den Navigationsmodus geschaltet. Folglich dürften dort keine brauchbaren Informationen enthalten sein.

Moin Andreas,

PGN 129284 baut der Konverter lt. Manual aus RMB und APB zusammen.

Wobei 129284 2mal gesendet wird: 1mal mit rechtweisenden Kursen/Peilungen und 1mal mit mißweisenden. Entsprechend ist der Parameter 3 (Course/Bearing Reference) dann besetzt.

Die Krux dabei könnte sein, daß im Manual der NMEA0183 Datensatz APB zum Bau von 129284 zusätzlich erwähnt wird. Allerdings wären das nur der 4. Parameter (Perpendicular crossed? - d.h. WP querab?) und der 9. Parameter (Peilung Start-WP). Beides m.E. für den AP nicht notwendig. Das Manual enwähnt im Übrigen auch lediglich RMB als zwingend für die Steuerung eines AP.

Den von Dir genannten 5. Parameter ("Arrival Circle entered") hatte ich auch im Verdacht. Allerdings ist - wie von Dir richtig erkannt - der entsprechende Wert in RMB enthalten (13. Wert, Arrival Status). Kann mir nicht vorstellen, das es hier ein Problem gibt. Zudem besagt der Parameter ja lediglich, daß der WP erreicht wurde (korrekt: der Abstand ist geringer als ein dafür im GPS eingestellter Wert). Einen Parameter, daß das Ende der Route erreicht wurde, hab ich in den maßgeblichen PGN's nicht gefunden oder bin ich blind?

Ray erwähnt die Meldung ("Route complete") im Manual, verbunden mit dem Hinweis, daß sie nur erscheint, wenn ein MFD installiert ist. Ich vermute mal, daß der AP aus einer speziellen Kombination mehrerer Parameter auf das Ende der Route schließt. Nur eine solche Info rückt Ray nicht 'raus . Daher ja auch die Idee, die PGN's direkt vor und nach dem Abbruch zu untersuchen.

Der Konverter kann den Datenstrom N2K-seitig auch binär protokollieren (CAN-Format). Würde das weiter helfen?

Moin Andreas (2mal),

wie bereits erwähnt, ist der Konverter in der Lage, den ein- und ausgehenden Datenstrom sowohl auf NMEA0183 als auch auf STNG-Steite zu protokollieren: entweder im Text-Format (Beispiele s.o.) oder im CAN-Format (nur auf Seite STNG). Falls es von Interesse ist: hier ein Protokoll: YDNGLOG.TXT

Die Text-Datei läßt sich relativ einfach in Excel importieren und dann kann man über Filtereinstellungen in der entsprechenden Spalte sich nur Zeilen mit einem bestimmten Datensatz anzeigen lassen (z.B RMB). So läßt sich dann sehr schön der Unterschied zwischen Positionsmodus (leere Datenfelder) und Navigationsmodus erkennen. Dort habe ich keinen signifikaten Unterschied kurz vor und nach dem Abbruch festgestellt. Somit habe ich das GPS nicht im Verdacht.

Leider ist es mir - wie mehrfach erwähnt nicht möglich - gleiches mit den STNG Daten zu praktizieren. Somit kann ich nicht kontrollieren, was der Konverter übersetzt.
Es gibt natürlich auch die Möglichkeit, daß der EV 1 'ne Macke hat.
Im Navigationsmodus verhält sich der AP gleich seltsam, egal ob man eine Route abfahren oder nur einen WP ("Goto") ansteuern möchte.
Die Konfiguration des Konverters hab ich mit Yacht Devices schon durchgekaut, daran soll's nicht liegen. Weitere Datenquellen - vom AP selbst mal abgesehen - gibt's nicht. Insofern sind auch keine Gerätegruppen definiert.

Mit dem Actisense NMEA-Reader komme ich leider nicht weiter: Erstens braucht man dafür den NGT1-Konverter und zweitens ein Notebook mit COM-Schnittstelle an Bord. Letzteres könnte ich wohl organisieren, aber einen Konverter zu erwerben, um den Datenstrom eines anderen aufzuzeichnen, wäre schon etwas gaga.

Aber: mit dem EBL-Reader kann man aufgezeichnete Logs lesen. Ich hab' den mal mit obigem Log gefüttert und er hat die NMEA0183-Zeilen zwar etwas merkwürdig dargestellt (Zeit war immer 0, als Typ wurde N183 ausgegeben, in Data dann der Datensatz), aber die Interpretation unten ist einwandfrei! Für die STNG-Daten geht das anscheinend nicht so einfach. Schade!

Andreas: vielen Dank für den Hinweis, aber ich merke gerade, daß sich dies so allmählich verselbständigt. Ihr macht unwahrscheinlich spannende und interessante Projekte - meine Hochachtung dafür. Aber ich habe ehrlich gesagt keine Lust, einen hohen Aufwand dafür zu treiben, daß ein gekauftes Produkt funktioniert.

Wie bereits erwähnt, ist Yacht Devices durchaus bemüht und ich hab' mit denen bis zum Herbst als das Schiff in die Halle kam auch viel korrespondiert. Das ist jetzt abgerissen, aber ich kann den Kanal ja wieder aktivieren. Ich hatte gehofft, daß es hier jemanden gibt, der eine ähnliche Gerätekombi hat und von seinen Erfahrungen berichtet.

PS: Sonntag, der 31. Januar ist übermorgen ...