Onderwerp: Clipper GPS repeater koppelen aan Openplotter

Toeter schreef :
Heb je gekeken naar de onderste regel wat je wilt verzenden. De twee stippen aanklikken. Alles wissen en alleen aangeven wat je wilt verzenden.

Toeter schreef :
Inderdaad veelal wordt COG berekend uit het verschil tussen twee posities. Mijn GPS geeft wel een COG als de boot "stilligt" maar dat is een-onzin waarde die alles tussen de 0 en 359 kan zijn. Er is altijd wel verschilletje tussen twee opeenvolgende posities.
Als je GPS een kompas heeft dan zouden HDM/HDT/HDG beschikbaar moeten/kunnen zijn.

brambo schreef :
Uiteraard, ik laat OpenCPN GSA, RMB en RMC verzenden.

Ik vind SignalK niet erg prettig werken, maar goed, ik denk dat ik weet wat het probleem is. Ik laat OpenCPN de drie NMEA sentences naar poort 10111 sturen. In SignalK heb ik een verbinding OpenCPNOut ingesteld, en ik heb ingesteld dat de data van OpenCPNOut naar de Clipper verstuurd moet worden.

Het probleem: De data van OpenCPNOut komt ook weer in OpenCPN terecht.

Hoe voorkom ik nu dat de gegevens van OpenCPNOut op de grote NMEA-hoop in SignalK terecht komen (die vervolgens door OpenCPN wordt gelezen) en hoe zorg ik dat de gegevens alleen bij de Clipper terechtkomen?

Dat doe je door in OpenCPN bij je in/out verbinding dezelfde sentences op input te negeren, als die je op output uitstuurt:


[Edit:] Dit werkt natuurlijk alleen voor data die OpenCPN zelf produceert, niet voor RMC die het op dezelfde verbinding binnen krijgt. Zie het antwoord van Brambo hieronder voor een betere manier om dat op te lossen.

Toeter schreef :
Dat gaat niet goed.

Je stuurt de gekozen uitvoer naar SignalK. Je doet dat als volgt:

UDP localhost poort 2000 (in OpenCPN)

In SignalK maakt je een nieuw item aan:

Zoiets als OpenCPN-in NMEA183 udp localhost en poort 2000. Herstarten.

In Opencpn zet je inkomend of signalk localhost poort 3000 bij de laatste beta versie.

Of tcp localhost poort 10110. Je krijgt dan de SignalK stroom gecombineerd uit SignalK.

SignalK maakt er een stroom van met diverse invoeren.

Je moet aan SignalK even wennen, maar het is werkelijk het "draaipunt" van alle communicatie stromen.

Zo zingt er niets rond. Wel opletten dat je bij de uitgaande stroom alleen uitgaand aanvinkt.

Je voert uiteraard de Gps, ais etc in via serial in OpenPlotter naar SignalK. En vergeet niet iedere verbinding een alias te geven.

Bram

brambo schreef :
Dit is exact wat ik eerst had, maar dan met udp poort 10111 in plaats van 2000. Ik neem aan dat ik in SignalK ook nog moet instellen dat de gegevens van OpenCPNIn naar de rs232-uitvoer voor de Clipper worden gestuurd?
Het levert in elk geval dus ook hetzelfde geknipper van de Clipper op, en als ik in OpenCPN kijk zie ik dat er wel degelijk informatie rondzingt.

Wat wel blijkt te werken: als ik OpenCPN de data (GSA, RMB, RMC) direct naar de USB-poort van de Clipper laat sturen (dus Serieel, niet Netwerk) werkt alles goed: Clipper toont goede data in alle gegevensvelden en knippert niet, en OpenCPN krijgt zo te zien alleen de goede gegevens binnen.

Ik weet het niet, maar als je 2 x poort 10110 gebruikt lijkt mij dat niet goed werken.

Volg gewoon even de aangegeven instructie en kijk dan met de signalk filter applicatie wat er werkt in Signalk.

Daarna maak je een connectie via serieel en SignalK nmea183 uitvoer naar de Nasa.

Dan heb je beslist geen rondzingen. In OpenCPN heb je alleen de uitvoer van de route etc. en de invoer vanuit de SignalK server. Is mooier met de laatste OpenCPN beta, waarbij je eenvoudig direct SignalK invoert in OpenCPN.

We horen het nog wel.

Bram

brambo schreef : Mij ook niet, daarom deed ik dat ook niet en gebruikte ik dus poort 10111 om te verzenden vanuit Open CPN en niet 10110.
Overigens: als je de instructies op Openmarine.net volgt moet je juist wel twee keer 10110 gebruiken.

de uitvoer naar de Clipper heb ik nu ingesteld door in SignalK bij de verbinding met de Clipper bij Output Events gpsmuis en OpenCPNOut in te stellen, conform instructies op openmarine.net. Bedoel jij iets anders met "SignalK nmea183 uitvoer"?

Toeter schreef :
In SignalK heb je nu de gpsmuis invoer ingesteld en de OpenCPN uitvoer > invoer, zoals aangegeven.

Wat dan nog ontbreekt is de uitvoer van nmea183 naar je Nasa ding.

In serial de gewenste poort aanmaken, alias geven, dan bij verbindingen die doorschakelen naar SignalK, de baudrate invullen. De SignalK server herstart.

Met nmea183 - nmea183 plugin kun je ook nog de gewenste nmea183 zinnen voor de poort instellen.

Het is niets zo moeilijk maar je moet het even begrijpen.

We horen wel als het werkt.

Bram

brambo schreef :
Haha, je hoort het vooralsnog vooral als het niet werkt
Het is wel een beetje frustrerend want volgens mij heb ik alles precies zo gedaan als je beschrijft, maar toch klopt het resultaat niet.
We blijven proberen.

Zie je nu in SignalK filter alles draaien ? Je GPS muis en je data invoer vanuit OpenCPN ? Als je een route of route naar een waypoint hebt ingesteld.

In OpenCPN moet je uiteraard dan ook de GPS positie zien.

Dan werkt dat in ieder geval.

Ja, dat werkt allemaal prima.

Ik heb nog even zitten denken en misschien een oorzaak van het probleem gevonden.

Als ik OpenCPN alle drie sentences laat genereren dan snapt de Clipper het goed. Alleen geeft dit een probleem omdat OpenCPN RMC binnen krijgt en verzendt, dus er ontstaat rondzingen.

Als ik OpenCPN alleen RMB laat genereren dan snapt de Clipper niet wat mijn COG en SOG is. SignalK Diagnostic vertelt me dat de gpsmuis in RMC alleen de True COG stopt. De Magnetic COG wordt wel verstuurd maar in een andere sentence (VTG) die de Clipper niet kan lezen. En volgens verschillende mensen op dit forum en daarbuiten moet de CLipper magnetische COG hebben.

1. Is er een manier om softwarematig de magnetische COG uit de VTG sentence in een RMC bericht richting de CLipper te sturen?

2. Of is er een manier om OpenCPN alle data voor de Clipper te laten genereren zonder dat dit bij SignalK binnen komt en gaat rondzingen?

Toeter schreef :
Je moet eens kijken naar de nmea - nmea plugin waarmee je kunt aangeven welke data je wilt versturen. Alleen de benodigde data voor de Nasa.

Verder kun je aan de lijst van door te sturen gegevens door OpenCPN ook nog andere zinnen handmatig toevoegen. Er is hiervoor ruimte gemaakt.

Kan het hier zelf niet proberen.

Het rondzingen komt niet van signalK maar van je instellingen.


Bram

Ik geef het op met SignalK. Alle mogelijke suggesties zijn geprobeerd en nog een hoop andere, maar geen sjoege bij de Clipper.
Wat het beste lijkt te werken: Alle data voor de Clipper direct door OpenPlotter naar de seriële
poort laten sturen ipv via SignalK. Op die manier kan ik OpenPlotter laten luisteren naar de data van de gpsmuis (die wel via SignalK binnenkomt) en vervolgens OpenPlotter RMB, RMC en GSA laten genereren voor de Clipper. Omdat die RMA/RMC/GSA-sentences direct naar de seriële poort gaan ipv via SignalK worden ze niet opnieuw door OpenPlotter beluisterd, waarmee rondzingen is voorkomen.

Beste Toeter,

dat rondzingen is gewoon je eigen fout.

SignalK ontvangt de data vanuit OpenCPN via UDP poort 2000 (met beperkingen)

OpenCPN ontvangt uit SignalK de data of direct via Signalk locaLhost poort 3000 of via tcp localhost 10110.

Dat werkt gewoon.

Nu nog de gewenste data naar de aangemaakte serieele poort in NMEA183 formaat naar je Clipper.

Je kunt ook nog de NMEA zinnen aangeven die je wilt uitzenden naar je Clipper.

Bij het laatste gaat er iets niet goed. De baudrate goed ingesteld ?

Heb je naar de plugin nmea - nemea gekeken ? Met heading true en heading magnetic.

Kan hier verder ook niets testen.

Bram

Het rondzingen op zich is het probleem niet, ik begrijp waar het door veroorzaakt wordt. (AL zouik het handig vinden als er een mogelijkheid bestond om OpenCPN RMC te laten lezen én uitzenden naar SIgnalK).

Ook het versturen van de goede sentences naar de Clipper is het probleem niet, ik snap hoe dat moet en dat lukt ook.

Het probleem is dat proefondervindelijk blijkt dat de Clipper wel goed reageert op de NMEA sentence RMC als ik die door OpenCPN naar de seriele poort laat sturen, en niet goed reageert als ik hem door SignalK naar diezelfde poort laat sturen.
Kennelijk verpakt OpenCPN dezelfde informatie in dezelfde sentence (RMC) net anders waardoor de Clipper het ineens begrijpt.

Toeter schreef :
Als je echt wil weten hoe dat zit, dan zou je dat moeten vragen aan de makers van OpenCPN, of iemand anders die thuis is in de sourcecode daarvan. Maar weet je zeker dat er niet nog andere verschillen zijn tussen beide setups? Geen andere sentences die wel worden verstuurd in de ene situatie en niet in de andere?

Kan je de rmc filtering in OpenCPN uitbreiden met product-id?
Dus ipv rmc iirmc of gprmsc?
Voor de door OpenCPN gegenereerde kan je denk ik zelf kiezen.

De Nasa Clipper helpt ook niet mee, irritant toestel die alleen vreet wat hij lust, op de juiste wijze bereid en geheel naar z'n smaak.

OpenCPN stuurt de gewenste data naar de SignalK server in NMEA183 formaat. Dezelfde NMEA183 data kun je ook direct gebruiken richting de Nasa.

Je hoeft niet eens SignalK om te zetten in NMEA183. Je kunt daarna wel de SignalK applicaties, zoals het handige MXTommy Kip gebruiken.

Daarnaast is er ook nog de Kplex multiplexer speciaal voor nmea183.

Zie niet in waarom het uit OpenCPN wel zou werken en via een andere weg niet.

Maar goed ik kan het hier niet proberen.

Bram