Onderwerp: Leg hier je Signal-K toepassing uit

In een eerder draadje is de installatie, het idee van... en de meest eenvoudige Signal-K installatie uitgelegd.

Ook Seanymph heeft een goede stap-voor-stap handleiding gemaakt:
drive.google.com/file/d/1gPJfs...L_HdVNeGBXuA0ou/view

Het lijkt het mij nu tijd om een aantal praktsiche voorbeelden langs te laten komen, waarbij gebruikers kunnen uitleggen hoe (en waarom) ze Signal-K gebruiken. Ik geef mijzelf de aftrap

Als het navolging krijgt is dit de eerste post in een langer draadje; anders is het slechts een beschrijving hoe en waarom ik het op mijn boot gebruik.

Disclaimer: Ik ben géén IT’er laat staan netwerk-specialist, dus de gebruikte symbolen zullen vast verkeerd zijn. Maar in onderstaande tekening heb ik zo duidelijk mogelijk mijn netwerk opgetekend. Software en hardware loopt wat door elkaar heen.



De basis werkt ook zonder de mini-PC en Signal-K. Die basis is de N2K apparatuur die de Verper AIS transponder vertaalt naar NMEA0183 en beschikbaar maakt in haar TCP/IP server. Dit apparaat is óók een Wifi access point waar tablet, telefoon etc mee kunnen verbinden. TZ iBoat, iSailor werken dan al.

Ook de PC-Nautic stuurautomaat functioneert zonder de mini-PC.

Op de mini-PC draait OpenCPN. De mini-PC verbindt draadloos met het Access Point en OpenCPN leest direct vanuit de NMEA0183 server op de Vesper. Als ik een route aanmaak, stuurt OpenCPN de RMC etc data naar de Vesper. De Vesper neemt deze dan op in haar 0183 server, maar vertaalt deze óók naar NMEA2000 en zet deze nieuwe data op de N2K bus. De "Triton" klokjes tonen die route informatie dan:



Tot zover nog steeds geen Signal-K nodig dus (kán wel maar simpel vind ik fijner en SK vind ik geen doel opzich)

Wat doe ik wél met Signal-K?

Magnetische en ware heading op de NMEA2000 bus beschikbaar maken
De PC-Nautic autopilot heeft een electronisch kompas. Hoewel deze leest vanaf de Vesper NMEA0183 server, schrijft hij daar niet naartoe (kan ie niet). Wel heeft het apparaat zélf een NMEA0183 server, waarin ROT, TRIM, HEEL en HDM beschikbaar zijn. TRIM en HEEL héb ik al op het NMEA2000 netwerk vanaf de Airmar transducer. Heading echter niet. Signal-K verbindt met de NMEA0183 server van de PC-Nautic en vertaalt de magnetische heading daaruit naar een interne Signal-K variabele. Signal-K schrijft die heading op haar beurt naar de N2K bus (via de "SK to NMEA2000" plugin). Da's mooi, maar nog steeds een magnetische heading. Om de wind in de kaart te plotten, wil de tablet en OpenCPN een TRUE heading.
Die wordt in de SK plugin "derived data" berekend: uit de actuele variate (die komt van de GPS) berekent deze plugin de TRUE heading. Ook die wordt naar de bus geschreven:



Het mooie is dat de Vesper die weer vertaalt naar NMEA0183 en op háár server beschikbaar maakt, zodat deze HDT uiteindelijk in OpenCPN belandt.

SPD voeden met data
SPD heeft wat NMEA0183 zinnen nodig om te kunnen werken. In pricipe zou het eenvoudigst zijn om SPD via TCP/IP te laten verbinden met de Vesper, net zoals OpenCPN dat doet. Thomas en ik hebben eerder flink zitten stoeien, maar deze verbinding heeft nooit stabiel en voldoende snel gerealiseerd kunnen worden.
Als workaround leest SPD nu uit de door Signal-K aangemaakte NMEA0183 server op de miniPC; voor SPD is dat “localhost" en dan werkt deze verbinding om onduidelijke redenen wél snel en zonder hickups.

SPD outputs op klokken buiten weergeven
ZF'fer hanst heeft een aantal SK plugins geschreven op basis van zijn uitpluiswerk van welke data (PGN's) B&G gebruikt om haar Hydra/Hercules racecomputers in een (hún...) N2K netwerk op te nemen. Een van die plugins is de "B&G Performance" plugin. Deze vertaalt performance data beschikbaar in de SK database naar de juiste B&G PGN's en kan deze naar het N2K netwerk schrijven.

Daarvóór moet deze data wel beschikbaar zijn in Signal-K. In overleg met -ook ZF'fer- michaelh is de SPD websocket-server aangepast, zodat met een NODERED flow - een scriptje/functie (dat is grafisch programmeren, beetje Matlab Simulink achtig, maar dan event-based. Home Assistant gebruikt het ook...) de SPD output via een websocket verbinding gelezen kan worden.

Ik gebruik SPD dan headless; de outputs komen vanzelf in de SK server. De "B&G performance" plugin schrijft die data (ik gebruik maar 4 variabelen daarvan, maar er is meer mogelijk) naar de NMEA2000 bus:




VHF informatie op smartphone
Nog steeds in ontwikkeling maar voldoende "af" om te gebruiken is hanst' VHFinfo! plugin. Deze gebruikt GPS positie om te weten waar je bent en de heading en een zoekhoek/afstand om te bepalen in welk VTS of blokgebied, haven of kunstwerk je (bijna) in de buurt bent. Op je smartphone zie je dan dat VHF kanaal, de URL van dat object, meldpost etc, telefoonnummer en naam en aard van het object.



Accu monitoring
Totaal onnodig maar "omdat het kán" is de VE.Direct plugin. Deze leest data van de accumonitor (state of charge, stroom, spanning etc) van de Victron accumonitor en zet deze data in de SK database.
In de "SK to NMEA2000" plugin staat deze data aangevinkt om op de bus beschikbaar te maken. Ik zou op de klokken alarmen kunnen instellen, maar het is veel makkelijker dat gewoon binnen, op de accumonitor zélf te doen natuurlijk.



Configuratie
Hier nog wat voorbeelden uit de configuratieomgeving (webbrowser naar poort 3000 in mijn geval).

Hier zie je het Dashboard overview met bovenaan een overzicht van het dataverkeer door de plugins en verbindingen naar buiten; daaronder de status van de plugins:


Hier een stuk uit het configuratieschem van de "B&G Performance" plugin. Je ziet daar de mapping van de SK variabelen (de "paths") naar de PGN's die naar de NMEA2000 bus gaan:


Hier een stukje van het configuratiescherm van de "derived data" plugin die de TRUE heading berekent (de plugin kan veel meer maar gebruik ik niet):


Hier een overzicht van de dataverbindingen "naar buiten"



Hoe nerdy en stabiel is het
Ik heb best wel moeten stoeien alles goed werkend te krijgen. De meeste tijd kostte het werkend krijgen van de Actisense: in de standaard Windows installatie deed deze het niet; ik herinner mij dat ik bepaalde node.js uit het canboat project handmatig heb moeten toevoegen, maar reproduceren...? Ik moet nog steeds een backup maken!

Vanmorgen ook zoiets: ik update de NODERED plugin, is de "FLOW" van michaelh die daarvóór prima werkte zomaar verdwenen. “Geen probleem” dacht ik. “Pak ik de flow die meegeleverd is met de laatste SPD installatie”; blijkt deze niet meer te matchen met de versie van SPD die ik draai.

Idem voor de B&G performance plugin van hanst: versie 1.0.17 werkt bij bij níet, de oudere 1.0.10 wél. Geen idee waarom! Na veel gedoe (onervarenheid) heb ik de broncode van 1.0.10 terug kunnen vinden en gepaste in de desbetreffende files.

Ik weet nu nóg zekerder : NOOIT UPDATEN ZONDER REDEN (hoeveel "sneller, nóg beter!" sommigen ook roepen)

Verder ervaar ik Signal-K als stabiel, tot zover (begin afgelopen seizoen gaan gebruiken) geen gekke dingen meegemaakt. Maar "heel eenvoudig" is dit niet in mijn ervaring.

Heel informatief Nachtvlinder. Ik doe graag met je mee en heb daarom ook mijn eigen configuratie eens in een schema gezet. Is wel heel minimalistisch hoor, ik heb niet zoveel apparaten aan boord. Maar misschien wel leuk voor wie met alleen een Raspberry Pi en een Smartphone iets wil bouwen.

Overigens snap ik nog lang niet alles. Maar ach, het werkt nu (bijna) probleemloos...

Hier mijn schema en in bijgevoegde PDF een nadere uitleg en wat fotootjes.






Vrgr, Roel

oeps, schema zelf was niet bijgevoegd. Hier een tweede poging...

Nachtvlinder schreef :
Dat is niet goed. Wat werkte er precies niet? Zou je een 'issue' willen aanmaken op github om het daar te troubleshooten?

Hier een bescheiden exposé van mijn ratjetoe. Hoge nerd-factor, maar misschien zitten er wat bruikbare ideetjes tussen:

Ik gebruik het voor veel verschillende dingen. Onder andere NavTex uitlezen via usb/serial (NX300) om zo op telefoon/tablet/MFD te kunnen lezen:

En om Digital Switching mee te kunnen doen vanaf B&G MFD:

En Simarine Pico gegevens (accu/tank/temp) mee uit te lezen en op de N2k bus te zetten.
Handig om in de kuip de tank gegevens te kunnen aflezen tijdens het vullen van een tank.

En ook die van LifePO4 BMS (JBD over bluetooth)

Nachtvlinder schreef :
Het is eigenlijk meer een vraag en misschien is dit draadje niet de juiste plek. Maar ik probeer het toch maar.

Bearing FROM Waypoint in SignalK/KIP

In SignalK heb ik een path ‘navigation.courseRhumbline.nextPoint.bearingTrue’. Dat geeft een peiling NAAR dat punt. En dat pad gebruik ik in MxTommy/KIP. Maar wat ik óók zou willen zien, is de peiling VANAF dat punt.

Voorbeeld: ik zet in OpenCPN een waypoint en klik ‘Navigate to Here’. Dan krijg ik in KIP een afstand (RNG) en peiling (BRG) naar dat waypoint. Bijvoorbeeld BRG 318 en RNG 3.50. Dat waypoint zit dus vanaf mijn positie gerekend op 318 graden en 3,5 mijl. Maar als dat waypoint een (stationair) schip is of een verkeerspost, dan zou ik het wel zo makkelijk vinden als ik ook kan zien wat de peiling is VANAF dat schip of die verkeerspost.
Dat is in dit geval dan … eh… even rekenen, 318-180= ...eh… 318-200=118 en dan +20 = eh..138.
138 dus. Maar dan moet ik zelf gaan rekenen en dat verhoogt de kans op fouten. Bij mij wel tenminste.

Als ik in SignalK en/of KIP die berekening al automatisch kan laten maken en dan aan mij wordt gevraagd waar ik mij bevind, kan ik meteen zeggen ‘ik zit op een afstand van 3,5 mijl, peiling 138 graden vanaf u gerekend.’ Lijkt me wel handig.

Ik weet dat je zowel een ‘To’ als een ‘From’ kunt krijgen met de EBL-functie van de Draw-plugin in OpenCPN, maar dat vind ik op een smartphone te priegelig. Ik zou het graag als SignalK-pad willen hebben om op te nemen in KIP.

Weet iemand of dit mogelijk is?

Kijk, leuk draadje.
Gaat even in de bookmarks tot ik tijd heb om te spelen

Seanymph schreef :
Dit is zeker mogelijk, maar ik kan nog geen huidige plugin vinden die dit doet.
Een generieke 'offset' van 180 graden zou genoeg moeten zijn.
Ik hou het even in m'n achterhoofd.

Nachtvlinder schreef :
Super leerzame en interessante setup. Ik kom denk ik tzt nog terug met vragen op andere onderdelen van je config, maar eerst even over de accumonitoring: begrijp ik goed dat je BMV-712 via een VE.direct USB kabel rechtstreeks aan de rpi zit waarop de SignalK server draait? Ik dacht namelijk dat er eerst verbinding moest worden gemaakt met een Cerbo of Venus server (Venus met VenusOS op een rpi). Dat is dus niet nodig begrijp ik hieruit?

Ja, het is een directe verbinding. Ik gebruik zelf de officiële Victron VE.Direct to USB interface (omdat ik -aanneem- dat deze galvanisch gescheiden is), maar een generieke uart-usb converter werkt ook; dat stekkertje achterop de BMV is een standaard verkrijgbare connector. Dan ben je voor een paar euro klaar.

Cool, ga ik mee aan de slag! Ik heb diverse berichten gelezen bij pogingen de BMV met VenusOS te verbinden dat het niet lukte vanwege een niet galvanisch gescheiden kabel, dus ik denk dat ik ook gewoon voor de Victron kabel ga.

Andere vraag, over het op de N2K bus zetten van nieuwe N2K waarden (ik zou bv denken aan de True Wind na een SPD berekening). Zijn er dan niet 2 True Wind waarden op het netwerk? Of ge/misbruiken jullie een andere PGN voor deze geupdate waarde?

Er kunnen binnen N2K zonder problemen meer dezelfde data aanwezig zijn. Elke PGN heeft een (per aangesloten fysiek of virtueel apparaat) uniek source adres. Ik je klokken of plotter geef je aan van welk apparaat je de true wind wilt gebruiken (bron selectie).

hanst schreef :
Oh, dat naviop loop spul kende ik nog niet.
Niet goedkoop, wel hele leuke gimmick.

Shutter Speed schreef :
Precies, niet goedkoop. Dus heb ik een SignalK plugin gemaakt die doet alsof het Naviop hardware is en dan kun je het paneel op de MFD krijgen en de 0/1 in een SignalK path.
Daarmee kun je dan weer bijv Sonoff switches schakelen. En die zijn een stuk beter te betalen

Wat voor relais gebruik je uiteindelijk? Zijn dat Wifi devices, Zigbee? Hoe loopt zo'n schakelsignaal vanaf je MFD verder vanaf het moment dat dit in een SignalK path komt? Verwerk je dat met NodeRED?

Nachtvlinder schreef :
Oeps, niet Sonoff, maar Shelly. Die zijn wifi based en er is een SignalK plugin voor.
Via pathmappet plugin kun je dan het Naviop path koppelen aan het Shelly path.

Maar er zijn soms ook software switches waar je een ‘fysieke’ schakelaar wilt hebben. Dat kan dan ook. Bijv Icom vhf plugin om auto-follow van VHFinfo aan/uit te zetten vanaf de MFD.

XanderB schreef :
Met die Victron kabel gaat het zeker goed. Bij de goedkope USB-serial converters moet je een beetje mazzel hebben welke chip er gebruikt is. Ik heb een Pi3 met VenusOS. Die is via USB verbonden met de BMV-712 (Victron kabel) en met het Daly/Sinowealth BMS van de accu (lange USB-kabel met Startech USB-isolator). Op mijn Pi4 met Openplotter draait de Venus-plugin die de data in SignalK zet. Zo kan ik bijvoorbeeld de spanningsverschillen zien tussen het BMS en de BMV712. Omdat het kan.