Onderwerp: SignalK invoer OpenCPN

Realtime moest alleen van 3Noreen, die al geschreven heeft dat hij het wel zou willen, maar fantasie is.
De timestamp interesseert me ook wel, ik was het nog niet tegengekomen.
Maar dat zal dan door de server gedaan moeten worden. Binnenkomende data heeft geen eigen timestamp natuurlijk.
Maar je kan er verder ook niet zoveel mee, in onze toepassing.

@ZP Laten we het even ontopic houden aub.

Nachtvlinder schreef : Ik nam daarvoor de GPS tijd en vergeleek die met de door in OpenCPN toegevoegde ontvangst tijd.
Ik had ook 2 GPSen aangesloten en zo ingesteld (alle data zinnen van U-blox) dat ze op 4Hz het maximale aan data uitzonden (op 4Hz met 3 satellietsystemen stuurden die toen meer data dan met 2 satellietsystemen op 10Hz)

de timestamnp ging niet over jou ZP, is ook helemaal niet van belang in deze discussie.
Het ging over de eerder genoemde timestamp van Ashwin.
Lees nu even het draadje, en ga on topic. Dank.

roozeboos schreef :
3Noreen heeft vooral interesse in toepassingen die voor hem bruikbaar zijn. Voor o.a. mijn stuurautomaat is latency het verschil tussen een bruikbare of niet bruikbare stuurautomaat. Een radar, liever een puur radarbeeld dan een projectie over een kaart waar geen touw aan vast te knopen is. Ik gebruik mijn radar NOOIT in de haven. Omdat ik het nut daarvan niet snap. Daar ben ik te dom voor. Ik zie namelijk liever eentjes gewoon zwemmen als ik kijk.

roozeboos schreef :
De zelf benoemde moderator aan het woord. Die toevallig ook wat hardware verkoopt....

Zeilprutser schreef :
Probeer eens voor de grap twee gps ontvangers te gebruiken, één op de boeg de ander op je hek, bij mij 12 meter uit elkaar. En dan de gevaren koers uit te rekenen. Daar wordt je wijzer van.

3Noreen schreef :
Af en toe ben je zo zuur Gary, ik begrijp daar echt niks van. Dacht ik net dat het zo goed gaat.
Voor de record, ik doe echt mijn best. Maar dit soort offtopic geneuzel kan ik echt niet positief over doen.

3Noreen schreef : Als je nu het draadje even leest, dan weet je waarom ZP deze opmerking maakte.
Had niks te maken met nuttig of niet. Ging om snelheid van datastroom.
Aan de hand van de timestamp opmerking , die ZP verkeerd begreep omdat het over de timestamp van Ashwin ging.
Die beweert dat elk signalK bericht een timestamp krijgt.

En mijn vraag is nog steeds waarom signalK een snel protocol heeft zoals dezelfde Ashwin beweert.
Maar die is natuurlijk allang afgehaakt door al het gekwetter van diverse posters hier.

Het is zo jammer dat je een willlekeurig postje leest 3Noreen en dan een zure opmerking maakt. Ten eerste is het off topic, ten tweede trek je het helemaal uit z'n verband. Ten derde snapt nu niemand er nog wat van. En ten vierde kom je zo nogal dom over. Maar goed misschien is het gewoon de bedoeling om te zieken. Ook goed hoor.

Maar inderdaad een goede reden om de mods maar weer te vragen om op te schonen.

Mods:
Het gaat dus over SignalK. En of het nuttig is om dit in te bouwen in een apparaat.

roozeboos schreef :
Probeer het bovenstaande experiment met twee stuks gps uit te voeren op een varend jachtje. Daarna kom je terug met je bevindingen en hebben we het nog eens over de relevantie in dit topic.

En wat heeft dat dan te maken met SignalK?

Dat heeft dan alleen te maken met jou drang naar 0.00000001 seconde latency in de berichten.
Waarbij we samen al eens waren ,in dit draadje, over het feit dat je wat veel fantasie hebt.
En dat jou gedachtenkronkels uitzonderlijk zijn. Niks mis mee natuurlijk, maar voor 99 % van de toepassingen niet relevant.

Overigens heb ik al eens gekeken naar jou voorstel van twee gps'en aan boord, voorop en achterop en dan de heading te berekenen. Erg duur vooral. Gps is moeilijk nauwkeurig genoeg te krijgen, ook vanwege reflectie op het water. als ik het zo even terughaal. Dus geen oplossing opnieuw voor de gemiddelde watersporter.
True heading heeft volgens mij een oplossing. Maar reteduur. Jugo zal er wel op terugkomen, als hij dit nog leest.

Timestamp zit inderdaad in het bericht. Die timestamp wordt gegenereerd op het moment dat het signaal verwerkt wordt door de server. Deze timestamp lijkt niet specifieker dan per seconde te gaan. Voor hypersensitive metingen mogelijk al te grof. De keuzes die met SignalK gemaakt zijn lijken mij zeer logisch. Het gebruik van TCP prima te billijken en op toekomst gericht.

signalk.org/specification/1.3.0/doc/data_model.html

Tegelijkertijd zie je dat door de opkomst van IOT veel nieuwe mogelijkheden opduiken. Vraag is hoe makkelijk dit te realiseren en integreren is in een maritieme omgeving. Zoveel keuzes en mogelijkheden!

Dankjewel, voor je inhoudelijke reactie.
Je ziet nu toch wel dat er nog heel wat data omheen zit, maar dat moet ook wel natuurlijk, om het zo flexibel te houden.
nmea0183 is dan toch wel compacter.

roozeboos schreef :
Het topic is gestart over Signal K invoer in OpenCPN.

Het topic gaat nu o.a. over:

• Wat is Signal K?
• Wat zijn de voordelen van Signal K t.o.v. NMEA0183/2000?
• Is het nuttig Signal K in te bouwen in de Roosmux?
• Is Signal K realtime genoeg?

Als je het specifiek over het nut van Signal K in de Roosmux wilt hebben moet je daar misschien een projectdraadje voor starten

ik zal me er verder niet mee bemoeien.

Het wordt bijna hilarisch, straks krijgen we te horen dat een Bochtaanwijzer een onnodig instrument is.

roozeboos schreef :
Nmea0183 is aardig voor wat gepruts thuis en daarvoor nog ok. Maar het is op alle vlakken te beperkt.

Ik ben nog niet afgehaakt hoor. Maar aan sommige discussies heb ik niets bij te dragen, dan ben ik liever stil.

Nog even over de timestamp in SignalK. Die is tot op 1/1000 seconde. De timestamp wordt toegevoegd zodra iets een SignalK bericht wordt. Dus in geval dat een of andere multiplexer een NMEA bericht omzet naar SignalK wordt de timestamp door de multiplexer toegevoegd. Wanneer er sensoren komen die SignalK uitspugen zullen deze sensoren de timestamp aanmaken en benadert de timestamp beter het moment van meten.

Ter informatie mijn Canable canbus boardje (NMEA2K invoer) werkt op een bitrate van 250000. NMEA2K wordt via SignalK/canboat vertaald naar SignalK.

Boardje gebruikt slechts twee data aders van de NMEA2K kabel.

Kan het verder nog niet proberen. Boot staat in de winterstalling en een NMEA2K GPS voor test doeleinden heb ik nog niet ontvangen.

In OpenPlotter 2.0 beta zit er een instelling menu voor een dergelijk canbus boardje of de NGT-1 van Actisense er al in.

Bram

Inmiddels is er nu ook een Linux Bionic 64 bits beta versie verschenen op het eerder genoemde adres. OpenCPN met directe invoer van SignalK.

Voor installatie van een SignalK server kun je de Openplotter instelling gebruiken.

Kan geinstalleerd worden met ppa vanaf de server. ppa:openplotter/openplotter

Bram

Inmiddels deze nieuwe OpenCPN beta versie met directe SignalK ook kunnen proberen op mijn Linux AMD 64 Bionic versie.

De SignalK server staat inmiddels ook op dit systeem.

Hier zijn de Linux en Windows versie van OpenCPN met SignalK invoer te downloaden:

De invoer van een serial NMEA183 en/of NMEA2K worden vertaald naar SignalK en de uitkomsten zijn toe te passen in OpenCPN.

www.cruisersforum.com/forums/f...-preview-227965.html

SignalK server is eenvoudig te installeren met de OpenPlotter opties for Linux.

Hier nog even een handleiding:

sudo add-apt-repository ppa:openplotter/openplotter

Nu kan het zijn dat dit commando niet bekend is:

Dan even installeren:

sudo apt install software-properties-common

dan het eerste commando herhalen.

Dan kan er nog een drempel verschijnen, dat de key niet herkend wordt.

Dit kun je als volgt oplossen door de betreffende ontbrekende key to kopieren en deze zelf aan te melden:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys (dan hier de uitkomst van key)

Dan uiteraard update.

Het is uiteraard allemaal nog beta, waardoor de wat uitgebreide procedure om het te laten werken.

OpenCPN met SignalK invoer is er nu voor Linux Xenial, Trusty en Bionic.

Bram
Nog even een aanvulling:

Na deze installatie heb je de settings van OpenPlotter en kun je hiermee de SignalK server installeren.

Serieele invoer doe in principe in SignalK. Maar handiog is ook de serieele instellingen van de OpenPlotter modules te gebruiken. Je geeft hiermee het betreffende apparaat een alias, zodat apparaat eenvoudig herkend wordt de usb aansluitingen.

Een en andere ook nog geprobeerd op een Linux 32 bits systeem. Dit werkte echter niet door de versie van de nodejs versie. Moet dit nog verder uitzoeken.

Let op het is allemaal nog in een pril stadium. In de OpenPlotter versie 2.0 beta is dit allemaal standaard aangebracht. Hiervoor is echter nog geen OpenCPN versie met directe SignalK invoer. Komt er zeker binnenkort aan.

Bram

Hier nog een beeld van de instellingen in SignalK voor een gps muis invoer. Gpsmuis is de alias voor een gps muis die ik hier gebruik. Deze instellen met de serieele pagina van OpenPlotter (ook in Linux systeem)

Zodoende is deze voor het systeem terug te vinden ongeacht de usb poort.

Voor SignalK moet je inloggen. Bij instellingen server of plugins de instellingen doen en de soort invoer. NMEA2K, NMEA183, SignalK etc.

En na aanpassen van de instellingen. Restart doen. Als het werkt dan zie je de cijfers in het dashboard veranderen.

Aswin schreef :
Misschien een domme vraag, maar welke tijd gebruik je dan als referentie?
De klok van de computer? Of de klok van de GPS?

Als ik naar de Raspberry Pi kijk of een RK3399 of een andere ARM-kloon dan heb ik het gevoel dat je voor een goede timestamp eigen NTP-server moet opzetten waarbij de klok synchroniseerd wordt met het PPS-signaal van een GPS (PPS = pulse per second).

Voor degene die niet weet wat hiermee bedoeld wordt:
- Aangepaste GPS-muis met extra aangesoldeerde kabel voor PPS-signaal

- Extra kabel voor PPS aangesloten op GPIO

- Voor de software aanpassingen: zie Google

Alternatief is natuurlijk een GPS direct via de GPIO, wat ook neerkomt op de nodige huisvlijt.

Of je dat nu tot standaard wilt verheffen?

(Ik post het even als referentie, niet dat ik dit zelf werkend heb.)

Ik zie het probleem niet helemaal.

De tijd komt toch van de aangesloten GPS.

Mogelijk moet je de tijd nog aanzetten in SignalK.

Groet,

Bram

SignalK gebruikt SI-eenheden, dus voor de tijd neem je UTC, die kan je afleiden van je GPS-signaal. De computer moet daar natuurlijk ook aan gesynchroniseerd zijn.
Mogelijk kan je ook de secondepuls van de GPS gebruiken om alles exact tot op de milliseconde te syncen.