Onderwerp: Rpi, OpenCPN (5.6.0),

Op mijn 2 jaar geleden 2de hands gekochte boot zitten een Raymarine ST2000+ op, een Raymarine S100 draadloze controller met een Seatalk basisstation, en een Garmin GPSmap 521 plotter.

Zonet heb ik ontdekt dat als ik op die plotter een waypoint aangeef om naartoe te zeilen dat de autopilot (als de S100 op "track" staat) vanzelf de boot op die koers wil zetten.

Op zich al een hele belevenis om dat pas nu na meer dan 2 jaar te ontdekken.
Ik heb ook een Rpi met OpenCPN 5.6.0 in werking.

Mijn vragen:
1. kan OpenCPN ook worden ingesteld om een koers naar een bepaalde waypoint te berekenen (GPS an AIS aangesloten en werkend), en hoe te doen (eventueel een hint naar een procedure of werkwijze)?
2. welke instelling op OpenCPN "Opties/Verbindingen/.." is dan nodig om de output naar de Raymarine Seatalk basisstation te verzorgen?
3. welke bedrading (evt via USB->RS232 omzetter) naar welke aansluiting op het Seatalk basisstation is dan nodig? Ik vermoed dat de RS232 TX pin moet verbonden worden met de NMEA0183 RX input op het basisstation?

Aub geen verwijzingen naar Signal-K of NMEA2000 ? Ik gebruik die niet en ben dat ook niet van plan . Alvast heel veel dank voor enige feedback!

Oei, de titel is onvolledig, moest zijn "Rpi, OpenCPN (5.6.0), Raymarine autopilot en Seatalk"

Ja dat kan door OCPN haar NMEA0183 output aan de ST2000 te koppelen. Als je je GPS (zoals nu) óók aan je ST2000 gekoppeld wilt houden, zul je een (om)schakelaartje moeten bouwen of een multiplexer moeten kopen. OCPN kan ook multiplexen, maar moet dan altijd aan staan. Of je dat wilt weet ik niet.

Als je je RPi met OCPN als multiplexer in wilt zetten:
GPS > RS232<>USB > OCPN
OCPN > RS232<>USB > ST2000

Je moet dan wel opletten dat niet EN je GPS EN OCPN tegelijk een route aktief hebben. Mss kunnje dat filteren; weet ik niet zeker…

Mijn iets oudere RM C120 wordt er erg nukkig van als er van een andere bron route opdrachten komen.
Je zult net als ik waarschijnlijk moeten voorkomen dat die opdrachten bij de automaat aankomen maar niet bij de plotter.
Er is ook nog iets met waypoint arrival. De kans is groot dat je niet vanzelf naar de volgende waypoint gaat sturen.

Kan allemaal. RPI4 met multiplexer functie. Dat in en data uit. Maar goed dat had ik al eerder aangegeven.

3Noreen schreef : Ja inderdaad, daar kan ik zeker inkomen. Mijn bedoeling is dan om die Garmin plotter los te koppelen en de Rpi op de Seatalk aan te sluiten, en die dan permanent actief open te houden.

Nachtvlinder schreef : De Garmin mag wat mij betreft worden losgekoppeld.

OpenCPN spreekt NMEA183. Geen SeaTalk.

Die vertaalslag moet ergens gemaakt worden. De meeste RM displays hebben een NMEA in-/uitgang. Die kun je daavoor gebruiken.

Dus leg die puzzel rustig.

Als je in OpenCPN een route aktiveert, of een "navigate here" instelt, worden de relevante zinnen aangemaakt.

De instinker is wel dit: gebruik niet zomaar een RS232-USB omzetter. De massa daarvan is doorverbonden. Dan maak je een massa lus, waar ongelimiteerd stromen kunnen gaan lopen. Een RS422-USB omzetter werkt wel. Of een MUX. De Boatcontrol MUX is de facto een (digitaal) transparante RS422 omzetter.

ST2000 heeft NMEA0183 ingang; z'n huidige GPS gebruikt die ook...

Eens met je opmerking over galvanische scheiding. Als de enioge aardlus deze zou zijn, zou je evt ook de RPi voeding (ipv de NMEA0183) kunnen isoleren. Dit is alleen nodig als dew ingang van de ST2000 niet gescheiden is.

Nachtvlinder schreef :
De vorige eigenaar had de seriële uitgang van de AIS-engine (een passieve AIS) bedraad naar de Garmin NMEA0183 ingang zonder de "GND" of "grond" of "0V" pin mee te verbinden: de "grond" was reeds via de AIS-engine voeding verbonden met de Garmin. En AIS signalen werden correct op de Garmin weergegeven.

Dit is dus het omgekeerde van wat je (correct) voorstelt: bij mij zijn zowel AIS-engine, als ST2000+, als Rpi als VHF door dezelfde voeding bedraad waardoor alle "GND" aansluitingen reeds op hetzelfde potentiaal zitten.
Bijvoorbeeld van de AIS-engine seriële uitgang is enkel de TX pin verbonden met de RX pin van een RS232-USB omzetter module naar de Rpi en dat werkt goed.

Als ik het goed begrijp mag ik dan uit bovenstaande discussie afleiden dat ik hetzelfde principe zou mogen toepassen voor het ST2000+ basisstation?
Namelijk een uitgang van de Rpi configureren om "een signaal" naar de NMEA0183 ingang van het Raymarine basisstation te zenden. Hierbij moet dan de juiste poort (waarop een USB-RS232 omzetter is aangesloten die wordt gebruikt om "dat signaal" naar het Raymarine basisstation te zenden) worden aangegeven in de sectie Opties/Verbindingen/ , samen met de correcte baudrate -hoeveel dat is moet ik nog uitzoeken-.

En dan ervoor zorgen dat de Garmin niet hetzelfde doet, dus diens huidige NMEA0183 uitgang loskoppelen van het Raymarine basisstation.

Je werkt dan single ended, net zoals RM doet met die ene gele Seatalk draad. Ik verwacht wel dat dat goed gaat, ook omdat het voorheen blijkbaar ook al goed werkte via dit principe.

Als je AP stroom gaat trekken en haar voedingsdraad zou te dun zijn of slecht contact maken, dat kun je wel nare potentialen op de interface krijgen waar deze wellicht niet tegen kan.

Ook moeten al de in- en uitgangen in dit netwerkje dan ongeïsoleerd zijn, anders kan er geen stroompje gestuurd worden via één draad.

Nachtvlinder schreef :
Bedankt, goed advies.

Inderdaad is in mijn NMEA0183 netwerk niets geïsoleerd; en zijn de GND en voedingsdraden minimaal 1mm² en overal ferm aangesloten.

brice3010 schreef :
Totdat je een apparaat treft wat wél aan de NMEA specificatie voldoet en een geïsoleerde input heeft. Dat zullen er echt twee draadje moeten zijn om data over te brengen.

Ja inderdaad. Maar ik denk dat het er bij mij wel op zit: ik had nog maar pas na 2 jaar ontdekt dat die ST2000+ bij mij niet alleen met een remote controller (S100) kan gestuurd worden maar ook nog eens door de aanwezige Garmin plotter. Nu is het welletjes op m'n boot, en tijd voor het échte zeilen

De NMEA0183 input van de ST2000+ is (vanzelfsprekend) galvanisch ontkoppeld. Je kunt dus eventueel de +3V3 van je raspberry aan de NMEAin+ hangen en de TxD van je raspberry aan de NMEAin-. Voor thuis en voor zolang je nog geen adaptertje hebt. E.e.a. kun je zien in de eerste minuut van dit filmpje, ook voor welke Raspberry/OpenCPN settings je nodig hebt.

Ietsjes slimmer is een USB-naar-RS232 interface te kopen - zo'n kabeltje dus. Daarvan de GND naar de NMEAin- en de TxD naar de NMEAin+. Je krijgt op je raspberry dan een /dev/ttyUSB interface en die moet je ook op 4800 baud zetten.

forum.openmarine.net/showthrea...1&pid=17231#pid17231

ironman schreef :
Top!! Dank je wel!!

Je moet dus wel die garmin hiervoor loskoppelen van de nmea aansluitingen, maar dat had je al begrepen natuurlijk . Dergelijke stunts worden overigens op dit forum wel verfoeid door de professionalistas dus verwacht enige controverse.

ironman schreef :
Krijgt brice3010 een nieuwe Raspberry als het toch blijkt dat je de Raspberry met jou advies stuk maakt ?

Oh en die garmin heeft geen geisoleerde nmea ingangen dus daarmee werkt het niet...

3Noreen schreef :
Geen zorgen, ik hoef niks hier behalve advies en dan nog op eigen risico

ironman schreef :

Leuk draadje, dat ik ook ga volgen. Ik ben zelf ook bezig om OpenCPN aan mijn ST2000+ te koppelen. Na een tweetal proefvaarten is het resultaat vooralsnog teleurstellend. De verbinding tussen De Pi en de ST2000+ is stabiel, maar de gevaren koers allerminst. Het werd een whisky koers, flinke slingers.
Graag had ik de Autopilot_route_pi plugin geprobeerd, maar daar is helaas geen panklare build voor de Pi van beschikbaar: github.com/seandepagnier/autopilot_route_pi/releases .

Ik blijf nog experimenteren en meld me als ik een doorbraak heb.

Tiens heb ik nog gehoord van een vriend: zou het kunnen dat OpenCPN onvoldoende de korstondige fluctuaties afkomstig van de GPS -die aan OpenCPN is verbonden- uitvlakt?

Elke GPS geeft wat meetfouten tussen elke sateliet-polling, als OpenCPN daar geen lopend gemiddeld van berekent dan zit je met nogal grillige positioneringsfouten, zelfs al zijn die maar enkele meters verschillend onderling.
En als OpenCPN vervolgens telkens de koers corrigeert op basis van elk nieuw metingetje zonder uitvlakken (of zonder een lopend gemiddelde te berekenen) dan zou het m.i. kunnen het gevolg zijn dat commando's naar Raymarine ST2000+ grillig van richting veranderen?

OliSailor schreef :
Sinds een paar weken is er (eindelijk) een versie van de autopilot_route plugin in de beta catalogus van de opencpn plugin manager, voor als je daar mee aan de slag wilt. Zie dit draadje op openmarine. Deze is nog nauwelijks getest. Ikzelf vaar er wel al sinds eind vorig jaar mee, maar dat was gecompileerd van source en met een pypilot. Ik weet niet helemaal zeker of de raymarine wel de door deze plugin gegenereerde uitgeklede nmea zinnen aankan. Voor zover ik kan nagaan is dat nog nooit geprobeerd. Maar voor pypilot-bezitters (dus ook: pcnautic) is dit erg relevant.

Ook relevant om als zeiler te weten. Een rechte weg van A naar B is bijna nooit de snelste weg om zeilend af te leggen.