Onderwerp: aansturen stuurautomaat vanuit pc

Probeer dit eens! Kun je ongeveer alles met alles verbinden, multiplexen, meerdere COM poorten mappen etc.

Is wel mogelijk in OpenCPN

zit alleen buitenbeeld.

Ga naar verbindingen, maak er 1 aan en voeg toe.

Dan trek de schuifbalk aan de rechterkant naar beneden,vink output aan en klik op het kies vak aan de rechterkant, selecteer de sentences die je wil uit sturen.

mogelijk heb je hier wat aan;

Output van mijn route software;
$ECAPB,A,A,0.000,R,N,V,V,201.9,T,Waypoint 1036,201.9,T,,,A*0D
$ECBWC,143427.17,5012.239,N,00502.299,W,201.9,T,204.9,M,0.39,N,Waypoint 1036,A*71
$ECBWR,143427.17,5012.239,N,00502.299,W,201.9,T,204.9,M,0.39,N,Waypoint 1036,A*60
$ECRMB,A,0.000,R,,Waypoint 1036,5012.239,N,00502.299,W,0.39,201.9,,V,A*64

okee, opencpn laat nu de inkomende nmea data zien van mijn multiplexer.
als ik uitgaande data aan zet stopt de nmea debug window.
hoe kan ik nu opencpn vertellen het zenden van de route te starten?

Ah, Activeer!
hij verstuurt nu, nu kijken of het binnenkomt op de multiplexer.

Opnieuw OpenCPN opstarten?

heb je ozi explorer al geprobeerd?

Je kunt ook seaclaer gebruiken, maar dan moet je het signaal eruit sturen via navmonpc.

Maar: Vind je een windows product betrouwbaar genoeg om daadwerkelijk het roer van je boot in handen te geven?

Ik niet.

haha joop

Joop66 schreef : Ging alleen om testen, toch?

Windows of niet, route maken in Opencpn en deze activeren. Werkt als een trein.

Als je inderdaad met windows begint kom je nooit uit de test fase. Wat dat betreft 'dot net niet'.

Een beetje onzin natuurlijk
Een goed geinstalleerde pc kan wel degelijk zonder problemen draaien
Dit kun je ook testen en loggen (maar daar gaat het niet over, toch ?)

Roozenboos zal een systeem willen bieden waar het iig mogelijk is, of de eindgebruiker dan windowbased wil werken is zijn/haar keuze

Je kunt het ook nog anders zien, een laptop/pc is tegenwoordig vaak in huis, dan is het toch mooi dat je een 2e systeem hebt naast je plotter (mocht die er mee stoppen, want ook die kan stuk)

Tox, mag ik je verzoeken om bij ons te komen solliciteren. Blijkbaar heb jij bijzondere gaven wanneer het aankomt op systeem stabiliteit. Ik heb het dan niet over stand alone pc's maar over complexe bancaire systemen.

mgbgt1975 schreef :
de rabo toch? dat noemde ik ooit in een presentatie (voor abnamro) als 'het enige software museum ter wereld'

9 uit 10 keer is instabiliteit van een site te wijten aan marketing wensen. Voor de core bis heb je bijna nooit java-flash-data mining nodig. Of is reclame toch de core bis bij een bank.

Och mgbgt1975 je hebt het nu over complexe systemen
maar een simpel en degelijk geïnstalleerd kan wel degelijk goed draaien

Zolang je er maar niet van alles op zet dat niet nodig is

Baasklusje schreef :
Nee, geen Rabo. Wij stonden tot voor kort bekend als it bedrijf met een bank licentie.

toch een probleempje:
Ik kan met opencpn wel de binnenkomende berichen vanit de multiplexer inlezen.
voor de andere kant op:
Selecteer ik output mode activeer een route. nmea debug schermpje laat de berichten mooi zien.
Maar ze komen niet aan bij de multiplexer!
Ik zie ook dat de tcp verbinding niet wordt geopend. daarom komt het niet binnen natuurlijk.

als ik output mode dan weer uitzet wordt het wel weer geopend en komen de berichten weer binnen in opencpn.

Iemand enig idee?

hij zal toch wel dezelfe poort gebruiken voor beide richtingen? kan er ook maar 1 instellen


oja de uitgaangde berichten zijn wel rood. dat zou een transmit error zijn?

Werkt de tcp port van opencpn als server (De client (wifi-module) moet actief zelf de data ophalen van opencpn)
of als een client (opencpn dropt de data op de poort van de wifi-module?

ja ik weet t niet.
Maar,
UDP werkt wel vindik net uit! ook goed wat mij betreft.

OpenCPN werkt als server:
RTFM:
With "Output on this port" checked, OpenCPN will act as a TCP server accepting a connection from a remote TCP client. It will only output data to this client. NMEA data the client transmits will be ignored. OpenCPN will listen on all its host computer's network interfaces for TCP connections to the port specified in the "DataPort" field regardless of the contents of the "Address" field. By convention, users should set the "Address" field to 0.0.0.0. There should normally be no reason to select a "DataPort" value other than the standard 10110 unless multiple servers are required: In the current implementation a single data connection can accept only one client. If multiple clients wish to connect to OpenCPN, a dedicated data connection must be provided for each and each data connection must have a different DataPort.

Oftewel, je wifi-module moet actief gaan ophalen bij de openCPN-computer.
Oh en dat by convention op 0.0.0.0 dat lijkt wel verplicht, want anders doet ie het hier niet.

sja ophalen doe ik niet hoor.

ik heb nu een tcp/ip naar opencpn en een udp verbinding terug.
En dat werkt goed.
zelfs twee verschillende gps'en worden geaccepteerd, opencpn staat dan welk te klapperen maar dat is logisch natuurlijk.

Ik ben helemaal blij hoor. Daar zitten al met al weer een heel aantal uren in. dat geef niet, maar dan moet het uiteindelijk wel werken.

Nu moet ik dan nog het omzetten van de nmea naar de seatalk doen. was ik al mee begonnen toen dit er tussendoor kwam.

Jammer dat er niemeand is hier waar ik een dansje mee kan doen.

Tja, je zou Meindert ten dans kunnen vragen, maar ik vraag me af of die wil...

als udp maar goed gaat, stukje tekst van een ander:

Het UDP-protocol geeft geen garanties. Het is niet zeker dat u een waarschuwing krijgt wanneer een bericht niet aankomt. Het garandeert ook niet dat de berichten op volgorde aankomen.
Als we UDP vergelijken met TCP zien we dat TCP vooral toegepast wordt waar het belangrijk is dat alle data correct aankomt. UDP wordt gebruikt waar efficiëntie of snelheid belangrijk zijn. Bijvoorbeeld voor video-streams of waar andere methoden voor foutcorrectie gebruikt worden.