Onderwerp: Seatalk1/N0183/N2000 integratie zonder multiplexer

Ik ben onlangs "slachtoffer" geworden van een behoorlijk uitgebreid en goed werkend Raymarine systeem. Te mooi om te vervangen en nog volledig functioneel - wie weet wordt ik straks ook nog van RonV (niet die van ZF, dat is een goeie Ron!) afhankelijk - dat zien we dan wel.

De grijze apparaten heb ik nog liggen vanuit een eerdere boot en CVO keuring waarbij deze niet nodig bleken. Die wil ik zo goed en mooi mogelijk gaan integreren, samen met de mini-PC die in bestelling is.

Hoe het nu aangesloten is (de niet-grijze apparaten...) weet ik niet precies, maar de functionaliteit die ik zou willen bereiken is:

• Het plottertje dat slechts een N2000 aansluiting heeft dient AIS targets door te krijgen. Dat komt goed volgens mij via de Vesper. Het zou ook mooi (maar niet nodig) zijn om wind, bootsnelheid, diepte en heading daarin beschikbaar te hebben: dan werkt het "SailSteer" display
• De VHF heeft een interne dus nu onderdekse GPS en kan stand-alone functioneren. Indien mogelijk zou ik daar ook een extern GPS signaal aan willen aanbieden
• De Windows mini-PC moet zowel snelheid, wind, diepte, heading, GPS en AIS targets binnen krijgen
• Op die mini-PC wil ik SPD gaan draaien - als dat mag van Baasklusje . De actuele performance ofwel zichtbaar op de Multi's binnen en buiten, ofwel (op een andere manier) op de plotter
• Het zou leuk zijn (maar geen eis) als ik vanuit OpenCPN de stuurautomaat van een aktief waypoint kan voorzien

Ik heb wat ideeën hoe dit netjes op de boot te bouwen zou zijn, maar ik wil voor nu beperken naar of dit technisch überhaubt kan of dat ik aan een dure multiplexer vast zou komen te zitten...

Dit is een idee:


De VHF heb ik nu als standalone getekend; ik denk dat die nu gevoed wordt door een oude MLR GPS, die ik niet meer wil gebruiken.

De ST1/N2000 gateway werkt beide kanten op en ondersteunt dit:

Volgens mij moet dat goed gaan: op de N2000 bus komt de positie- en AISdata "van boven" en de rest van beneden. Voor het ST1 netwerk is alleen relevant dat de positiedata binnenkomt. Dat zou de bridge moeten gaan doen; ik verwacht dat dat nu gebeurt door de N0183 output van de oude MLR GPS naar de ST4000 door te lussen. Die laatste verbinding zou dan vervallen.

Mijn grootste zorgen zijn of de Vesper naast haar eigen gemaakt AIS en positiedata óók de boot, wind en kompasdata mee zendt naar WiFi en haar N0183 output. Ik vind deze info niet helemaal sluitend:

Ik hoop dat zowel de "PGNs Sent" als de "PGNs Received" naar de WiFi en N0183 gestuurd worden.

Heeft iemand daar ervaring mee?

Dan het voor mij meest onduidelijke...
De ST4000 zet deze N0183 inputs om naar ST1 (en doet daar zelf ook iets mee neem ik aan):

ik neem aan dat dit voldoende is om op te kunnen sturen (ik ga er even vanuit dat OpenCPN deze ook kan uitsturen).

Voor de SPD outputs:
-In dit schema is het onmogelijk om de performance output op het N2000 netwerk te krijgen?
-De Multi's kan je ook N0183 voeden en accepten waypoint en positiedata; op de miniPC COM2 poort zou ik een omschakelaar kunnen zetten die bij dat gebruik niet naar de AP stuurt maar naar de Multi's. Maar omdat deze óók naar ST1 vertalen: stuurt dat de boel niet in de war??



En het was zo lekker "heel eenvoudig" allemaal vroeger, met een N2000 systeem

Oja: de woorden "Linux" en "RPi" zijn taboe in dit project

Zo hadden wij het ook op ons vorige bootje met een veelvoud aan verschillende grijze dozen en protocollen
Werkte prima met de xb-8000

Alle seatalk 2 (st instrumenten en stuurautomaat) via de converter naar STng / n2k backbone waarop ook de xb-8000 en plotter schermen aangesloten waren

Alles werkte en communiceerde met elkaar

Er zitten twee zaken niet zo lekker in je schema, de koppeling AIS-PC en de koppeling PC-AP. Hierdoor ontstaan dubbele datawegen, zowel via Seatalk als via NMEA0183.

Een veel elegantere oplossing is om de PC via een NMEA0183 - N2k converter bi-directioneel aan te sluiten op de N2k backbone. Daarmee is er altijd maar één datapad. Ik gebruik zelf de Yacht-Devices YDNG03 gateway. Die heb je in een N2k versie maar ook in een SeatalkNG versie. Je kunt zelf kiezen welke data die wel of niet door moet laten. Op je PC beschik je dan over alle data die op het netwerk aanwezig is, tenzij je iets uitfiltert (via blacklist of whitelist)

Dankje.

Ik heb evt. een Actisense NGT-1 (N2000<>USB) beschikbaar, maar weet niet hoe die zich aan de PC presenteert; volgens mij vertaalt die niet naar N0183. Zal dat gaan uitzoeken.

Edit: hmmm, dan zou er SignalK nodig zijn. Dat is niet "heel eenvoudig"

Denk dat de Actisense zich als COM poort meldt op je pc.

Je kunt de NGT-1 niet flashen zodat ie zich als NGW-1 (N0183<<>USB) voordoet. Deze blijft altijd de ASCII representatie van de N2000 PGN's uitsturen - daar kan OpenCPN niets mee.

OpenCPN zegt dat je SignalK nodig hebt die de ruwe N2000 data heen en terug vertaalt naar een N0183 stream. Liever niet maar zojuist de installer van SignalK uitgevoerd:

github.com/SignalK/signalk-ser...alk-server-setup.exe

...het lijkt te werken "Heel eenvoudig" als het gewoon doet wat je verwacht!


Ik heb nog geen driver van de NGT-1 geinstalleerd maar dat is (wel of ook?) een market-ready produkt dus zal wel goed gaan.

Het volgende ligt nu voor de hand lijkt mij:


De N0183 uitgang van de Vesper kan dan op 4800 baud ingesteld worden om de VHF te voeden

OpenCPN leest zonder afhankelijk te zijn van de Vesper direct vanuit de bus. Schijven van waypoints zou ook moeten kunnen via SignalK.

Blijft over hoe de performance vanuit SPD zichtbaar te maken buiten. Dat zou dan op de Vulcan kunnen door
-een virtuele COM poort aan te maken
-daar SPD een N0183 (RPM ?) naar te laten schrijven
-SignalK die poort uit te laten lezen en naar de NGT-1 en daarmee N2000 te laten schrijven

Goed idee IlCigno en veel "schonere oplossing"

Wel spannend of SignalK goed werkt straks en of het die RPM kan vertalen naar N2000

In je schema klopt de aansluiting van de NGT-1 niet goed.

De NGT-1 moet je aansluiten op de SignalK server. Dan komt de NMEA2000 data in de SignalK server. Is tegelijk een multiplexer. De invoer naar je PCeetje met OpenCPN doe je direct in het SignalK formaat.

netwerk > signalk > localhost > poort 3000

De waypoint en routes vanuit OpenCPN doe je vanuit OpenCPN met UDP localhost poort 2000. Let op uitgaand ! Met de twee puntje aan de onderkant van het configuratie blad kun je instellen wat je vanuit OpenCPN wilt verzenden. Ik gebruik alleen RMC, RMB en XTE.

Nu moet je in de SignalK server nog een inkomende aansluiting maken:

NMEA183 localhost UDP en poort 2000. Nu komen de route en waypoint gegevens gegevens uit OpenCPN in de SignalK server.

Vandaar uit kun je er weer alle kanten mee uit. Aansturing van je NMEA183 autopilot of naar de NMEA2K bus.

Ik heb dat al eens eerder aangegeven maar herhaal dit nog maar eens.

Interessant is ook de MXTommy/kip aplicatie voor een instrumentenpaneel. Hiermee kun je alles in dashboard vorm instellen. Staat in de SignalK applicaties.

Een aparte data server voor al je nautische en andere bronnen is de manier om toe te passen.

Het is HTML en kan in iedere browser getoond worden. SignalK in de browser is is localhost:3000 of bij een remote systeem het ipadres:3000

Allemaal leermomenten !!

Er is ook nog opto koppeling die het Seatalk 1 netwerk omzet in SignalK. Weet alleen niet hoe dat gaat met Windows. Dingen kosten een paar dollar.

De applicatie hiervoor staat ook in de SignalK apps.

Groet,


Bram

Dankje Bram.

Weet jij of er een lijst beschikbaar is van PGN's die SignalK kan schrijven en/of lezen zoals ik in de OP gepost heb van een aantal andere apparaten?

Concreet wil ik weten of de N0183 "RPM" scentence vertaald wordt naar N2000.

Als ik het zo lees vind ik het maar een complexe oplossing. Let wel, dat is slechts mijn mening, voor een ander is het juist een uitdaging!

Met NMEA0183 en de eerder genoemde YDNG03 gateway kan je de PC waarschijnlijk out of the box koppelen met het N2k netwerk. De XB8000 AIS kan je waarschijnlijk instellen dat hij geen GPS PGN's naar de N2k backbone stuurt, dus daarmee voorkom je dubbele positiedata op het netwerk.

Geen gedoe met adressen, Signal-K of USB opto-couplers (de YDNG03 heeft een galvanische scheiding). Waarmee is uiteraard niet wil zeggen dat de oplossing van Brambo niet zou kunnen werken, in tegendeel.

NB Nóg schoner is natuurlijk om al dat Seatalk 1 spul gewoon te vervangen door moderne N2k / Seatalk NG apparaten. Inclusief een mooie EVO AP

Bram legt alweer veel te veel uit, namelijk "wat er óók allemaal kan"

Ik wil het in elk geval proberen - die NGT-1 heb ik al en is geïsoleerd. De miniPC trouwens ook (via de voeding), maar zodra ik de eerste COM poort aansluit neemt ie het potentiaal van die aansluiting aan.

Het hangt ook een beetje van de stabiliteit van de software af: in pricipe is dat eenmalig instellen. Als ik eerst 5 programma's moet starten wordt dat een nogo...

En passant heb ik het draadje van Baasklus zijn SP software van Meindert een opmerking gelezen dat de AIS vertaling van n2k naar 0183 niet zo vanzelfsprekend is.

Weet niet wat NO183 RPM is.

Allerlei data kan in de SignalK server gezet worden. Is niet gebonden aan NMEA zinnen.

Weet niet of dit nog zo is, maar een paar PNG's voor een NMEA2000 autopilot waren destijds nog niet beschikbaar.

Bij de webapps even opletten. In bovenste regel staat laatste nieuwe, je moet daar echter all aanzetten om ze allemaal te zien.

Na aanpassing instelling altijd een herstart van de server doen.

Bram

Nachtvlinder schreef :
SPD kan een aparte 2e COM gebruiken voor zijn output.
Dan krijgt het zijn data via de NGT1 (GPS-data uit N2K, wind etc uit ST via de converter) over de ene COM en schrijft het zijn NMEA183-records naar de 2e COM.
(want terug over de route NGT1 etc is geen goed plan: allerlei dubbele records: echte en neppers uit SPD)

Aan die 2e COM (een USB) een USB to Serial converter en die dan naar de NMEA-IN van een Multi.
Dan ook nog de ST-data naar die Multi (gele draad) kunnen onderbreken met een schakelaar. Klaar is kees.

De vraag is nog even hoeveel NMEA-listeners (de Multi's) je kan voeren met de stroompjes uit een Serial to USB. Die wordt gevoed door de USB-poort, en ik heb geen idee hoeveel displays die kan aansturen.
Holtere is met deze opstelling bezig: 2 Multi's aan een USB-to Serial die aan de 2e COM van SailingPD hangt.
In het ergste geval (te klein stroompje) zou je een oude serial mux ertussen kunnen doen als versterker: de Serial-to-USB aan een ingang, en wel 16 Multi's aan de 4 uitgangen

(en dit allemaal zonder Signal K)

brambo schreef :
Met N0183 bedoel ik NMEA0183...

En RPM betekent Revolutions Per Minute; een standaard N0183 scentence die SPD uit kan sturen.
De concrete vraag: een paar jaar terug was er al allerlei mogelijk. Ik heb tot op heden geen parameter lijst gezien zoals de tabellen in de OP wat SignalK nu wel en niet snapt. Dat "je er een heleboel" in kunt stoppen is een mooie promo, maar dit is een eenvoudige en praktische vraag volgens mij.

Zou jij eens willen informeren anders in de kanalen die je hebt of er zo'n lijst bestaat? Ook in het SignalK specificatiedocument een boel mooie praat en ideeën, maar nergens een overzicht van wat de concrete status nu is...

Hier een voorbeeldje; ik verwacht (hoop...) dus dat een mapping is tussen:
-N0183 scentence en
-SignalK variabele en
-N2000 PGN

Ik verwacht iets in een tabelvorm met 3 kolommen naast elkaar en een kruisje als Signalk dit snapt om te lezen en een ander kruisje als SignalK dit ook kan schrijven...

Dus bijvoorbeeld die RPM, die bestaat onder N0183 als xxRPM; onder SignalK als (weet ik niet?) en onder N2000 zit ie in de PGN "dynamic engine data" (nummer weet ik niet uit mijn hoofd)...

Eens met IlCigno en BK: zo eenvoudig en robuust mogelijk met zo min mogelijk software heb ik uiteindelijk ook de beste ervaringen mee. Heb ook expliciet voor de W10 miniPC gekozen om niet te hoeven hobbyen/dingen te doen waar ik niet goed in thuis ben. Ik wil het AAn kunnen zetten en het moet werken, ook als ik een maand niet aan boord ben geweest/vergeetachtig ben.

Combinatie van wat IlCigno en BK voorstellen ziet er zo uit:


De dubbele omschakelaar schakelt de Multi buiten ofwel in haar normale stand ofwel in de SPD stand.

nog maar één probleem: miniPC heeft 2 stuks 9-pins COM poorten; wat ik mij herinner van vroeger is dat één applicatie slechts één poort kan lezen of schrijven. Dan kan 1 COM poort voor OpenCPN gebruikt worden en de andere voor SPD. Probleem zit nog aan de rechterkant: de Multi wil 4800 baud zien en beide poorten dienen op dezelfde (vanwege AIS hoge) baudrate ingesteld te staan...

Nog over nadenken... Met virtual COM poorten zou dit wellicht opgelost kunnen worden, maar dat maakt de softwarekant weer ingewikkelder.

Die NMEA0183 verbinding tussen de AIS en de VHF zou ik weglaten. De VHF met een aparte GPS antenne is veel handiger. Je kunt dan alles gewoon uitzetten (of alleen de AIS) en de marifoon aan laten staan zonder dat er gezeurd wordt om ontbrekende positiedata.

De enige echt goede reden om een dataverbinding naar je marifoon te hebben is m.i. als je marifoon AIS targets herkent en er direct een DSC boodschap naar kan versturen. Helaas zijn er maar weinig marifoons die de NMEA0183 "$--DSC" message begrijpen. Zelfs binnen één merk verschilt het soms per model of de AIS-to-DSC functie werkt of niet.

Ik gebruik zelf de RPM van mijn motor niet.

Een van de SignalK ontwikkelaars, Scott Bender, ontwikkeld instrumenten applicatie voor SignalK die op Apple spullen draaien. Hier een voorbeeld met daarin ook de toeren aanduiding. Helaas geen webpage om te tonen.

Dan maar een schermafdruk. Is helaas wat onduidelijk.

Nachtvlinder, ik ben even vergeten welke N2K-0183 vertalingen de Vesper doet, maar indien voldoende zou ik deze rechtstreeks op de mini PC com-port aansluiten. VHF op NMEA OUT van ST60 multi. OpenCPN kan prima als multiplexer fungeren, met filtering. Alternatief en/of als backup: ST60 multi NMEA output naar mini PC. Een 4G routertje erbij. Output van OpenCPN via wifi of Ethernet kabeltje naar router. Devices zoals iPad e.d. kunnen via de router de volledige datastroom oppikken en hebben via dezelfde netwerkverbinding internet access. ST60 NMEA out ook naar VHF.

Ik zal nog maar een keer herhalen. Je hebt kaartplotter software. Soms ook nog op een ander systeem of op een netwerk. En je hebt allerlei datastromen, die je ook wilt converteren in andere formaten.

Wat is er dan logischer dat de data stromen in een apart draaiende server software worden verwerkt.

Met slechts een inkomende datalijn naar de kaartplotter software met de gemultiplexte nmea183 data.

De uitvoer van route en waypoint gegevens gaan met een uitgaande lijn ook weer terug naar de data server voor verder gebruik voor allerlei toepassingen en in allerlei formaten.

Dat lijkt mij een prima idee; heb nog even gekeken en het blijkt dat de Vesper veel meer verwerkt dan ik in de OP uit de handleiding had gehaald. Ook route-informatie wordt verwerkt tussen N0183 en N2000:


En óók van N0183 naar N2000; de output van OpenCPN kan de Vesper dan vertalen naar N2000. De Multi's geven trouwens géén WPT/route informatie in hun N0183 output, dus de VHF die moet dan maar stand-alone.

Dan wordt het nu echt "heel eenvoudig"!

Nog 1 open eindje:
waar laat je SailingPD zijn NMEA183 input vandaan halen?
Dat kan denk ik via OpenCPN (dat aan de COM hangt en alles doorstuurt).
Alternatief is GPSGate ertussen en OpenCPN en SailingPD elk aan een eigen virtuele poort hangen.
Kan ook met NavmonPC.

Wat je wel wilt is dat een RMB uit je navigatieprogramma ook in SailingPD binnenkomt.
Dan krijg je VMG to WP, Layline-info (tijd en afstand) etc in beeld.

Direct uit OpenCPN zal dat wel kunnen, die RMB naar SailingPD.
GPSGate kan het niet, NavmonPC wel.

Ik ben wel benieuwd hoe Signal K het nóg eenvoudiger zou kunnen maken
(alle vertalingen worden al gedaan, alle multiplexing ook, alle logging ook...)

SignalK is niet meer voor mij. 300 MB en 20k+ files lichter. Geen nette uninstaller natuurlijk en een aantal files kon ik niet verwijderen. Registry cleaner heeft de rest gedaan. Een niet-market-ready nerdprodukt vind ik het. Wel 100 type boten die je kunt definieren en een zeer uitgebreid "debug" menu. Heel nuttig. Maar geen naslaglijst welke PGN's en scentences nu wel en niet ondersteund worden.

NavMonPC heb ik nog; als het nét niet lukt op "hardware niveau" dan geeft dit denk ik wel die benodigde flexibiliteit.

Ik zou trouwens ook via WiFi de miniPC in kunnen, maar doe dit liever met draadjes. Ook weet ik niet of die WiFi beide kanten op werkt.

Het is een oplossing op zoek naar een probleem

RMB van openCPN naar sailingpd via virtual comport good old VSPE misschien. Slanke oplossing.

WaltB schreef :
Kende ik nog niet!
VSPE kan inkomend op de ene virtual port doorsturen naar een andere, begrijp ik?
Zit er ook nog iets van filtering in?

NavMonPC kan uitgebreid filteren en forwarden, maar het is wel langzaam en resource-onvriendelijk....