Onderwerp: SignalK invoer OpenCPN

SignalK is een open communicatie protocol gebaseerd op het HTML. HTML is in iedere browser toe te passen en hierdoor systeem onafhankelijk.

Je kunt hiervoor allerlei digitale meters ontwikkelen.

Weg met de gaten in je boot, waar je later spijt van krijgt als het betreffende apparaat het niet meer doet en niet kan worden vervangen.

De gegevens kunnen eenvoudig over internet of netwerk verplaatst worden.

Combineert de invoer van NMEA183 en SignalK en kan ook het gesloten NMEA2000 via signalK/canboat omzetten naar SignalK. NMEA2000 wordt hiermee opengebroken.

SignalK is niet gebonden aan een aantal beperkt vastgelegde regels zoals NMEA183 en NMEA2K. Er kunnen eenvoudige nieuwe toepassingen aan worden toegevoegd.

Denk aan motorfuncties, temperatuur metingen, barometer etc. etc.

Het past helemaal in de Open Source traditie. Vandaar dat de eerste opzet hiervan is gebaseerd op Linux systemen. Met OpenPlotter als voortrekker van deze ontwikkeling.

De toekomst is voor open systemen gebaseerd op computer toepassingen en niet op gesloten systemen met specifieke kaarten van een leverancier.

Alles modulair uitgevoerd, zodat storingen eenvoudig kunnen worden opgelost door vervanging van een van de modules.

Dit is zeker een noodzaak als het kaarten materialen steeds meer in digitale vorm worden gebruikt en actueel kunnen worden gehouden met updates.

Ook dat is de toekomst, waarbij digitale (tijdelijke ?) Aton betonning steeds meer toegepast zal gaan worden.

Dat klopt wel ongeveer.

3Noreen schreef : Signal-K is een protocol, ongeveer net als nmea ( 0183 of 2000). Waarbij een duidelijk verschil is dat bij nmea niet alleen het protocol, maar ook de manier van transport is vast gelegd (de hardware). En nmea is natuurlijk een afgeschermd geheel door patenten en auteurs rechten zodat je hier geen vrij gebruik van mag maken.

Signal-K is een poging om hieraan een einde te maken, door een open protocol wat iedereen vrij mag gebruiken, en geschikt voor moderne manieren van transport.

Op dit moment is het grootste voordeel dat je data(incl kaarten) kan laten zien in een browser waardoor dit dus op bijna alle apparaten kan. Van e-reader, telefoon tot computer, ongeacht merk, besturingssysteem en zonder de noodzaak van het instaleren van een of andere 'app'.

Momenteel is er voor direkt gebruik aan boord nog weinig voordeel te halen. Waaraan het ontbreekt is een 'kritische' massa van gebruikers. De ondersteuning die momenteel in OpenCPN wordt ingebouwd is vooral bedoeld om deze massa te vergroten.

Bij een wijdere acceptatie worden de mogelijkheden ineens legio. Je zou bv mee kunnen kijken op het echolood van je voorganger, of de havenmeester kan je een box aanwijzen door een pijltje op jou eigen plotter. of .....

Precies.

Voorlopig praten onze sensoren nog wel N2K of NMEA0183 (als ze al “smart” zijn) en lijkt SK een overbodige tussenlaag. Nu OpenCPN native SK ondersteunt, geeft dut hopelijkveen drive voor fabrikanten om hun sensoren ook SK te laten praten.

Gebeurt dat niet, dan blijft het wat mij betreft “yet another layer”. Metertjes in een webbrowser vind ik persoonlijk meer een demonstratie dan dat dit iets toevoegt.

Dit lijkt mij een belangrijke applicatie voor SK om wellicht kritische massa te gaan geven.

Het is ook dat Brambo doorzet, en het blijft promoten, wat natuurlijk prima is.
Maar anders was het ook hier nooit in beeld gekomen, of hooguit in een enkel verloren draadje.
Dat zegt in feite al genoeg.

Html over ethernet is toch een asynchroon data protocol ? Van instrumenten verwacht ik toch zo veel mogelijk real time data. Op zijn minst zou dan de SignalK data moeten worden reclocked. Of zie ik hier iets verkeerd. Het aspect van timing van canbus,is in mijn idee, juist een heel sterk voordeel.

Nachtvlinder schreef :
Beste NV,

de diverse apparaten doen eenvoudig hun invoer in de SignalK server en komen er gecombineerd uit als SignalK formaat.

Er hoeven geen SignalK apparaten apart voor ontwikkeld te worden. En de vertraging (van yet another layer) zijn minimaal. Nu kun je de NMEA2000 invoer via SignalK direct gebruiken in OpenCPN.

Tegelijk staat er nog een venstertje open met de stand van je brandstoftank of nog erger de vulling van je vuilwatertank !

Groet,

Bram

roozeboos schreef : Dat jouw mux geen nmea2000 'spreekt' heeft, zegt wat mij betreft al genoeg over het voordeel van een open protocol. Om als fabrikant nmea te mogen toepassen moet je lid worden van de nmea club en dat is niet echt goedkoop . En uiteindelijk betalen wij als gebruikers dat natuurlijk door dat de apparatuur onnodig prijzig wordt. Volgens mij is het dus in ons aller belang dat dit slaagt.

3Noreen volgens mij moet je SignalK als 'eindstation' van je data zien en niet meer trachten om die weer 'door te schakelen' naar een volgende. In die opvatting is SignalK een aanvulling op OpenCPN, bvb als gever voor een repeater in de kuip, aan de mast of op je foon.

Canbus is toch min of meer een open standaard. Het zou mooier zijn dat de ontwikkelaars van een nieuw instrument "taal" nmea2000 links hadden laten liggen door zelf een open software layer over canbus te formuleren.

hetzeilen schreef :
Even voor mijn begrip. Voorbeeld van wind data. Wind instrument stuurt nmea naar een SignalK server. Die stuurt dat dan door naar OpenCpn. Wordt er in de SignalK server ge-reclocked ? Of speelt OpenCPN als server ?

signalK werkt alleen met een server, zeg maar multiplexer. Dus het wordt wel degelijk door geschakeld.

Voor de rest ben ik het helemaal eens dat nmea2k technisch niks toevoegd.
Het voordeel voor de minder technische watersporter is het makkelijker aansluiten. Maar dat is ook onzin natuurlijk.
En die backbones en t stukjes zijn reteduur.

Misschien zou het een idee zijn om de multiview signal K te laten inlezen. En meteen server.

roozeboos schreef :
Dus de timing aspecten van canbus is een fabeltje ?

Ik zat al te wachten op je reactie. En ja hoor.
De timing is voor 99,99999% van de gebruikers volledig niet relevant.
Het zal een gemiddelde watersporter roesten of de data over 4800 bps of 250kbps wordt verzonden.

roozeboos schreef :
Misschien heb ik gewoon teveel fantasie. Ik stel me bijvoorbeeld voor dat je met een motion sensor en een dieptemeter die gekoppeld worden via een behoorlijk snelle databus vrij makkelijk een golfhoogte op je display kunt krijgen.
Nu kun je afvragen wat daarvan het nut is. Ik stel me voor dat je een riviertje aan de oostkust van Engeland op wilt. Inmiddels kun je actuele getij gegevens op een paar cm nauwkeurig binnenhalen. Het wordt dan ook leuk om iets nauwkeuriger de golfhoogte ter plekke te kunnen aflezen van je boord instrumenten.
Zomaar een nut van toekomstige mogelijkheden.

Als ik het zo lees zou signalK ook buiten het maritieme wereldje gebruikt kunnen worden, misschien gebeurd dit al maar daar heb ik nog niets van gemerkt.
Bvb in het digitale huis van de toekomst waar CV, Airco, licht, toegang, bewaking, alarmering, positonering van de zonnepanelen/zonneboiler, gordijnen door verschillende producenten dikwijls via aparte berichten en soms zelfs aparte bekabeling worden aangestuurd, dan via 1 netwerkprotocol en 1 bekabeling hun data kunnen bekomen.

Er is ook MQTT, dat is meer geschikt voor IOT.( MQTT is een protocol om over TCP data te versturen.)
Daar heb ik een aantal projecten mee uitgevoerd. Dat wordt vooral gebruikt om sensor data te versturen over internet.

@3noreen, er is niks mis met teveel fantasie. Daar lijd ik ook aan.

Je voorbeeld geeft al aan dat jij dus bij die 0.00001% hoort.
Maar dan zou ik evengoed niet canbus/'nmea2000 nemen, maar ethernet. En dan nog is de timing vooral afhankelijk van je sensoren. Geen kattepis om een zeer nauwkeurige motion en dieptesensor te ontwikkelen hoor ( voor een rollende zeilboot). Daar ligt dan het probleem, niet bij de dataoverdracht zelf.
Maar goed, je gaf het zelf al aan, het is misschien teveel fantasie, niet voor dit draadje dus.

roozeboos schreef :
Een ander fantasie. Een radar beeld over een elektronische kaart projecteren. Ook iets waarbij de timing van kompas data maakt dat je een bruikbaar of leuke gimmick hebt. Afgezien van de vervorming van het radar beeld die in het tijdsdomein plaatsvind.
Voor mij is het gewoon leuk om te bedenken wat voor toepassingen er in de toekomst mogelijk kunnen zijn. Niet stil blijven staan met wat nu kan.

SignalK zou het protocol van de toekomst moeten zijn toch ?

Radar overlay in Opencpn via wifi werkt al jaren, één van de ontwikkelaars van de plug in (heb het net opgezocht) had dat in 2016 al draaien op een BoatController 3B (zonder+) in combinatie met Signalk trouwens.

@3noreen:
Een mede zf'er heeft dat al. Alleen gaat dan de overdracht via ethernet en naar opencpn.

Ik bedenk me overigens ook altijd suf over innoverende projecten.
Voor een volgend wbso project. Dus als je ideëen hebt graag!

Of SignalK de toekomst is, is speculeren. Het zou kunnen, het is immers simpel genoeg.

Zeilprutser schreef :
bruikbaar of leuke gimmick ? Tot nu toe heb ik nooit een radar overlay gezien die bruikbaar was in een redelijk zeegang aan boord van een jachtje.

Vraag alweereengijp even. Die heeft het draaiend op een gewone pc.

Overigens heb ik het gezien, je kon de eendjes zien zwemmen. Serieus.
Maar dat was in de box, ik weet niet hoe het gaat op zee.

Heb het resultaat nooit gezien, maar hij heeft het zover mij bekend op 3 stuks >40voet jachten geplaatst die de wereld rondgaan, hijzelf zit nu in Suriname dus het zal wel goed werken denk ik.

Het mooie van radaroverlay icm AIS en goede kaarten is juist dat je zelf heel goed "kunt" leren wat je ziet door de feedback.