Onderwerp: USB NMEA adapter ontvangt alleen en zend niet?

Loop toch nog weer tegen wat nieuws aan met mijn OpenCPN installatie op een Raspberry met RaspOs in 64 bit uitvoering.

Groot deel lijkt te werken, ik krijg netjes NMEA info (AIS en positie en zo) binnen maar hij lijkt geen data te willen versturen. Ik wil graag XTE en zo sturen, maar ik ontvang niets op mijn multifunctioneel display. Ik heb voor de NMEA0183 aansluiting op de Pi een NMEA0183 naar USB adapter die zowel een RX als een TX heeft, met voor beide een statusled.

Ontvangen gaat prima zoals boven te lezen, alleen verzenden lijkt niet te lukken. Ik gebruik daar de in/output van OpenCPN voor, zonder signaalK. Maar als ik verzenden inschakel (met het vinkje) komt er geen data uit, terwijl ik wel een aantal zinnen in het zendvakje heb gezet.
Omdat de status led ook niet gaan knipperen vermoed ik dat er ook echt niet gezonden wordt. Heeft iemand een idee waar het aan kan liggen? Zit er nog ergens een instelling verstopt?

Ik heb geëxperimenteerd met een optisch geïsoleerde usb adapter met RS422 ondersteuning. Deze werkte echter direct icm met OpenCPN en een RPi.

Hoe ik toen heb getest is het debugscherm open zetten. Zit ergens in een menu verstopt. Maar daar kun je zien welke sentences daadwerkelijk over de lijn binnen komen en daadwerkelijk getracht verzonden te worden.

Als je de verbinding ook aanmerkt als autopiloot, dan kun je er routeinformatie heen laten sturen en inhet debugscherm de activiteit zien. Zie je geen uitgaande activiteit in jet debugscherm, dan probeert OpenCPN niets te sturen.

Probeer eerst eens naar een TCP server te zenden (server aanmaken met NavMonPC of VSPE bv, OpenCPN is client…). Is het zichtbaar in het debugscherm (verzonden is blauw volgens mij…), dan weet je dat dat deel werkt en je niet per ongeluk filtert. Die filter velden zijn bij mij leeg namelijk.

HotSnail schreef :
Wat zegt het NMEA messages schermpje in OpenCPN?

Dat t verzonden is?

Nog een voor de hand liggend dingetje om te controleren: Heeft het account waar openCPN onder draait schrijfrechten op de seriële poort?

Al eens gekeken naar het gebruik van de SignalK server.

De route en waypoint data kun je vanuit OpenCPN terugvoeren naar de SignalK server en vandaar uit kun je er alle kanten mee uit.

In de eerste plaats voer je SignalK data direct in OpenCPN met alle data die binnenkomt in de SK server. Kan nmea183, NMEA2000, Seatalk1 zijn en sensors.

Is in OpenCPN > signalK, localhost en poort 3000 (automatisch zoeken uitzetten).

Dan terugvoer route/waypoint vanuit OpenCPN naar de SignalK server:

Kies in OpenCPN voor uitvoer (niet in- en uitvoer)

UDP localhost poort 2000

Belangrijk ! Kies bij de twee puntjes onderste regel welke data je wilt uitvoeren. Alles wissen en aanzetten wat je wilt verzenden XTE en RMD etc. bijvoorbeeld.

Dit om te voorkomen dat data gaat rondzingen.

In SignalK maak je het ontvangen van deze data in:

NMEA183 naam voor de invoer (opencin ?) UDP en poort 2000.

Vervolgens maak je de gewenste uitvoerpoort aan met nmea >nmea plugin kun je aangeven ook welke data je wilt uitvoeren.

Laat nog maar een zien met een oud plaatje dat het werkt.

Bram

De volgende vraag is mogelijk hoe krijg ik SignalK op mijn Linux systeem ?

Hier de route:

sudo install NPM

sudo npm install -g --unsafe-perm signalk-server

Om de Signalk server automatisch te laten starten:

sudo signalk-server-setup (alles nee behalve de scheepsnaam)

In de browser localhost:3000 en dan heb je het menu scherm. het is eenvoudig HTML.

Waarom SignalK als extra laag inzetten voor wat TS wil?

HotSnail schreef :

Je probeert zo te zien RX op 38400 baud en TX op 4800 baud dat gaat niet werken, je hebt dan een converter extra nodig.

henkvd schreef :
Voor het kunnen zien of OpenCPN probeert uit te zenden in het 'debugscherm' zou de baudrate echter niets uitmaken. Er hoeft niet eens iets aangesloten te zijn op de RX en TX poorten om activiteit te zien. Serieel is zeer 'dom'. Ik zou dan nog steeds oplichtende ledjes verwachten aan TX zijde, tenminste dat doet die van mij wel.

Maar verschil in baudrate kan zeker het volgende probleem erna zijn. Echter als RX en TX aan hetzelfde apparaat is gekoppeld dan van beide de baudrate hetzelfde zijn. Je kunt TX en RX baudrate niet afzonderlijk instellen op die converters, dus een 2e nodig. Maar XTE stuur je naar je autopiloot en die zal hoogstwaarschijnlijk op een andere baudrate draaien dan de AIS zoals henkvd aangeeft. Ipv een 2e converter kun je ook kijken naar een NMEA multiplexer met USB/wifi aansluiting en daar de AIS, instrumenten en autopiloot op aansluiten. Die regelt de baudrate verschillen en stuurt het gewenste verkeer naar de gewenste poort (AIS info naar PC en niet autopiloot bijv).

OpenCPN zendt alleen uit wat er wordt ontvangen. Als hij niks ontvangt, verzendt hij niks. Van AIS berichten weet ik even niet of die doorgestuurd worden.

Tenzij je een route activeert. Dan genereert OpenCPN RMB, APB en XTE berichten. Maar ook alleen alleen maar als er RMC of GLL berichten binnenkomen.

Het helpt als je een screendump stuurt van je connection settings. En, ja, output van je NMEA debug window.

Nachtvlinder schreef :
Je zet geen extra laag aan. Je maakt alleen een scheiding tussen de kaartplotter software en de data verwerking.

OpenCPN ontvangt alleen wat er allemaal binnenkomt op de data server.

Je hebt dus data (plus de multiplexer functie) en de kaartplotter software gescheiden.

ironman schreef :
NMEA debug window werkt niet in OpenCPN in combinatie met de SignalK server.

OpenCPN heeft maar een kanaal en dat is de gemultiplexte data uit de SignalK server.

Wat wel mooi werkt is de de SignalK diagnose applicatie van OpenPlotter. Dan zie je in details wat er rondwaard in de SignalK server. De data en ook de bijbehorende PNG's.

De in- en uitvoer snelheden maken in SignalK ook niets uit.

Jammer dat men de logica van een aparte data server annex multiplexer moeilijk lijkt te begrijpen.

Maar we hebben het niet over een signalk server Bram.

Beste IM,

het gaat hier om oplossing voor een probleem.

Hier nog een schermafdruk van het SiognalK diagnose applicatie. Jammer dat er hier geen NMEA2000 is aangesloten op SignalK.

brambo schreef :
De logica van een aparte multiplexer begrijp ik maar al te goed. Onder meer daarom heb ik een Miniplex3... en geen Signal K.

Het kan eenvoudig allemaal in de software van SignalK en nog veel meer dan met de Miniplex mogelijk is.

Motordata, sensors, tankinhoud indicators etc.

Echter Voor het omzetten en uitzenden van OpenCPN route data naar NMEA2000 data krijg je soms te maken met aparte instellingen van een autopilot door de fabrikant die niet standaard zijn.

Dank voor de antwoorden allemaal!

Zenden en ontvangen probeer ik beide op hoge snelheid te doen en dat zo de USB adapter ook moeten kunnen, snelheid zou het probleem dus niet direct moeten zijn. Ik ga eens in het NMEA scherm kijken wat daar aan berichten langs komt, daar had ik niet aan gedacht.

Het gaat me om de RMB en XTE berichten, die heb ik op zenden staan en om rondzingen door mijn setup te voorkomen filter ik ze aan de ingang weer weg. Dat zou in beginsel goed moeten gaan toch?

SignalK kan ik de logica van inzien, maar als de functionaliteit al aan boord is vind ik extra software ook weer extra risico op problemen (sorry Brambo) en het is niet heel veel wat er aan filtering hoeft te gebeuren. Is allemaal NMEA0183, ik gebruik verder geen draadloze schermen voor klokken en dergelijke en het gaat me qua zenden dus enkel om de RMB en XTE berichten. Ik zou het het lieft zonder nog weer extra software doen om die reden.

Ik ga vrijdag weer naar de boot en ga dan het een en ander verder testen en dan maak ik ook wat scheershots en logfiles

Je piloot begrijpt 38400 baud niet

Heb je wel een waypoint actief, zodat RMB ook daadwerkelijk aangemaakt wordt?

HotSnail schreef :
Ik geef alleen maar betrouwbare oplossingen. Maar goed, als je verder wilt prutsen met verschillende snelheden en het niet voor elkaar krijgt, dan moet je het zelf maar uitzoeken.

De logica is echt eenvoudig. Data in een dataserver en kaartplotter software zonder extra handelingen in OpenCPN.

Groet,

Bram

Je gaat TS wél verder helpen wanneer het met met SignalK ook niet lukt? Hoe zou een evt. baudrate probleem daar met deze zelfde hardware wel op te lossen zijn?

Of wordt de voorwaarde dan uitgebreid met “je moet die en die 64 bits flatpak versie” installeren; werk bij mij thuis op zolder sneller en stabieler dan ooit

Werkt dat uberhaupt?
De mux aansluiten via USB/RS232?

Als ik het goed lees heb je de keus uit bluetooth gebruiken, meer niet.







Het kan ook zijn dat de RS232-poort mee zit te lurken aan de AIS aansluiting. Dan krijg je daar nooit data naar binnen voor een plotter koers. Dan zou je een 2e connectie kunnen maken, heb je daar een aansluiting voor vrij?
En check even de isolatie, want de B41 is veel eenvoudiger als de miniplex2 en miniplex3, dus misschien ontbreekt de isolatie voor de ontvangende NMEA-poorten.

Nachtvlinder schreef :
SignalK is een data server en kan overweg met allerlei inkomende en uitgaande baudrates en formaten. Conversie is eenvoudig en kan ook nog naar keuze worden ingesteld.

Geen "houtje-touwtje" oplossingen.

Het heeft niets met Flatpak te maken, dat is gewoon een standaard versie van OpenCPN maar dan in een eigen omgeving onafhankelijk van welke release het wordt toegepast.

De flatpak omgeving is in vrijwel iedere Linux versie te installeren. Dat is dus de "zandbak-sandbox" waar de standaard Flatpak OpenCPN zich vertoont.

Vandaar dat de complete reeks plugins er al standaard bij zit. Want die hoeven maar eenmalig te worden samengesteld en niet meer per release.

Bram

@ Reuver

je laat een hele oude Miniplex zien, data in/out USB/ RS232 / lan ( afhankelijk van het type ) bij de 2 en 3 versie gaat wel, die optie noemen ze host en kan je netjes instellen op de outputs.