Onderwerp: SignalK invoer OpenCPN

De conclusie van Rooz is wel juist. Ik ben een uitzondering waarvoor er groot verschil zit tussen data en (bruikbare) informatie. Ik kan dus Signalk wel links laten.

brambo schreef :
Dat klopt niet helemaal, Signal K is JSON (JavaScript Object Notation), wat een standaard is die in veel webapplicaties wordt gebruikt, en ook steeds meer voor communicatie tussen software.

Om Signal K een beetje te begrijpen is het belangrijk om te weten dat die naam voor meerdere onderdelen gebruikt wordt:

• Het protocol/data formaat (JSON)
• De server software, die fysieke sensoren of data uit andere bronnen (bijv. NMEA0183 of NMEA2000) omzet in Signal K en deze data beschikbaar maakt voor clients. Er zijn servers geschreven in de programmeertalen Node.js en Java; NMEA-multiplexers zouden dit deel ook kunnen inbouwen.
• Webapplicaties (HTML en JavaScript) die in de browser draaien en een client zijn van de server. Deze zorgen voor het weergeven van de data. De applicaties kunnen te downloaden/openen zijn via een webpagina die door de Signal K-server aangeboden wordt, of kunnen onafhankelijk daarvan op internet staan.
• Navigatiesprogramma’s als OpenCPN kunnen ondersteuning voor Signal K inbouwen als client, zodat ze de data kunnen weergeven. Ze kunnen ook een server kunnen inbouwen, om data die via andere bronnen binnenkomt in die applicatie (bijv. bestaande NMEA0183-bronnen) of gegevens uit het programma (waypoints, route) aan te bieden aan andere applicaties,

Op de Signal K website omschrijven ze het als volgt:

3Noreen schreef :
Daar komt nog veel meer bij kijken dan alleen timing, om dit te bepalen heb je een goede GPS nodig waar de hoogte uitkomt, een motion sensor, maar dan ben je er nog lang niet en is het middel erger dan de kwaal.
Wat je vooral nodig hebt is dat alle afstanden tussen alle sensoren in een rekenmodel komen anders klopt er geen moer van, al heb je nog zulke prachtige sensoren.

We proberen al jaren echoloden te compenseren voor golfhoogte en pitch en roll en daar komt de laatste jaren net een redelijk resultaat uit, maar makkelijk ging het niet.

Het was ook maar een fantasie. voor een ander draadje misschien.

@Menno, ik heb dat ook al eerder proberen uit te leggen, maar tevergeefs.

henkvd schreef :
Mooi. Het is bijna altijd zo dat techniek die in eerste instantie heel veel kost en behoorlijk ingewikkeld is op den duur beschikbaar komt voor een heel betaalbare prijs.
Ik weet nog dat de eerste betaalbare sony gps op de markt kwam. Koste nog altijd 1k gulden. Nu heb je al een veel betere voor twee tientjes.

Menno schreef :
Een open protocol en een krachtige server geeft natuurlijk wél mogelijkheden voor innovatieve ontwikkelingen. De server kan de timing controleren en zo afgeleide informatie genereren.
Opeens zie ik het nut en een zee van mogelijkheden. Het radarbeeld kan gecorrigeerd doorgegeven worden. Golfhoogte en periode geen probleem. Wind data opgeschoond enz.
Vooral het open protocol geeft die mogelijkheid het een en ander betaalbaar en cross platform te brengen.
Mijn oorspronkelijke vraag is zo wel voldoende beantwoord. Het begint bij een dode doorgeef luik maar de kracht komt van afgeleide data.

roozeboos schreef :
Timing heeft meerdere aspecten. Het is belangrijk om precies te weten hoe oud je data is. SignalK voorziet hierin door aan elk datapunt een timestamp te hangen. De NMEA protocollen kennen geen timestamp.
Het is ook belangrijk dat je data niet te oud is. Hierbij helpt een geschikt protocol, TCP is dat eigenlijk niet, en een hoge bandbreedte, dat hebben de NMEA protocollen niet.
Kijkend naar moderne multiplayer games over internet dan denk ik dat je met TCP een heel eind richting real time data kunt komen.

Voor jullie erg technisch geinteresseerden is dit misschien interessant:

github.com/canne/dashboard_tac...b74f12d450#r36535333

Canne is een software ontwikkelaar.

Met alle respect Ashwin, maar dat ben ik niet met je eens. Zolang je geen 3Noreen dingen wil gaan doen tenminste.

Het grootste deel van de boorddata wordt al elke seconde herhaald. Die boorddata gaat door boten die 5 a 6 of misschien soms 15 knoop varen. Ik bedoel maar, het is geen JSF. Daar maakt een seconde geen data vast wel veel uit.
Dus, ja timing maakt uit, maar het hangt erg af van de toepassing.

Hoe oud de data is, ja als bij ons het 5 seconden oud is wordt het wel vervelend. Precies weten? 4.55678 of 5 secondes, maakt dat uit?
Het gros van de data die wij verwerken is echt niet kritisch qua timing, vind ik.

Bovendien zit je jezelf tegen te spreken in je laatste zin , zoals ik het lees tenminste.

Een gemiddeld jachtje beweegt inderdaad op zee heel langzaam. Vandaar dat veel mensen uit verveling zeeziek worden.
Als je die beweging maar vaak genoeg relativeert gaan mensen het wel geloven en zullen aanzienlijk minder last van zeeziekte hebben. Placebo effect.

roozeboos schreef : Ja dat klopt.

Het punt wat ik wilde maken is dat SignalK meer geschikt is voor tijd kritische toepassingen doordat ze timestamps gebruikt en gebruik maakt van een veel sneller transport protocol (ook al is dat protocol op zich niet bedoeld voor real time toepassingen).

Dat snap ik niet, wat is er sneller aan signal K?
Uiteindelijk verstuur je dat ook gewoon over tcp lijkt me.
Zou je echt snel willen dan moet je signalK over UDP versturen.
En de timestamp is wel leuk, maar ook weer overhead. Hier neem je wat, daar geef je wat..

Dus, wat is het "sneller transport protocol" wat jij bedoelt?

Met TCP krijg je een veel hogere prioriteit, uit onze testen blijkt dat icm de Raspberry je over TCP veel hogere snelheden haalt en ook het bereik is groter, bij UDP begin je dan al veel data te missen terwijl je bij TCP niet eens lag ziet, ook het vastlopen van TCP gebeurt niet meer. De verbinding wordt gewoon verbroken en in range weer automatisch hersteld, op TCP filteren we niet eens data omdat het niet nodig is.
Een tiental TCP verbindingen met een hele berg vertaalde NMEA2000 data (busload van 50%) is geen enkel probleem.
Hoeveel verbindingen kunnen met radar overlay weet ik niet.

PS als je goede client server afspraken hebt met SignalK schijn je de data naar 3% load te kunnen comprimeren. De server stuurt dan alleen de relevante data door, je weet bijvoorbeeld van welk schip of sensor de data komt dat hoef je dan niet te elke keer opnieuw te vertellen, 1x per seconde de time stamp bijvoorbeeld is ook voldoende, etc, etc,

NMEA 0183 heeft een standaard band arte v a n 4800 byte/s. NMEA200 heeft 250 kbits/s. Zo'n 6500 keer sneller dan NMEA 0183. SignalK loopt via TCP over ethernet. GIGABIT ethernet heeft een snelheid van 1000 Mbits/s. Dat is 4000 keer sneller dan NMEA2000. Dan kan er wel een timestamp bij denk ik.
Ik denk niet dat UDP veel sneller is, ook dat loopt over ethernet.

Het punt is echter dat je ook signalK kan versturen over nmea0183. Vandaar mijn vraag aan jou over wat dan een sneller protocol is aan signalK.

Nmea0183 heeft nog een paar bytes en commans om het berichttype enzo te identificeren.
Ik denk dat SignalK toch ook heel wat eromheen heeft zitten, naast de json regeltjes met {} [] , en dus meer data moet versturen dan nmea0183.
Dat maakt over ethernet niet zoveel uit, maar wel bij 38400 bps over Rs422.

Ik kan me daarom ook voorstellen dat een signalK server gewoon een aantal nmea0183 ingangen heeft. En die dan door kan multiplexen naar wat webbrowsers over wifi of ethernet.

Overigens is udp in de basis altijd sneller dan tcp. Tcp is nu eenmaal een meer robuust protocol met ACK en retransmissions.

Udp spuugt het gewoon uit. Leuk voor muziek en nmea strings, die toch steeds worden herhaald. Een paar bytes verliezen is niet erg.

Zolang je je boorddata niet op hetzelfde wifi of ethernet laat draaien waar je ook op netflixt zal de udp foutloos doorkomen, en is TCP overkill.

Diezelfde bus met tcp is dan ook een stuk trager omdat er meer retransmissions plaatsvinden.
Omdat de data nu eenmaal door MOET komen. Dan kan je beter een berichtje verliezen.

Over LAN ethernet heb je tegenwoordig helemaal geen bandbreedte problemen meer, we hebben het in dit geval over WLAN / Wifi dan haal je zulke snelheden niet.
De vraag is natuurlijk wel of je zoveel data wilt toelaten op je netwerk, we zijn nu net blij dat we met een simpele pi4 eigenlijk alles kunnen, maar dan moet je de boel natuurlijk niet vol gaan gooien met onnodige data. Mijn droom is dus juist de boel klein en licht houden en toch alles kunnen doen.

Ja, met een rpi zou ik het ook klein willen houden, dat snap ik wel.
Keep on dreaming...

Je zou het zelf kunnen testen met 1 van je pi's Chris!
Ik dacht ook dat UDP sneller zou zijn, in de praktijk is dit echter niet zo, ik noem het prioriteit waardoor TCP sneller is, dit is wat Kees er in 2016 over zij:Take it or leave it.

roozeboos schreef : Nou mijn droom van 6 jaar geleden is vooralsnog met de pi4 wel uitgekomen!!!!
Weet nog heel goed dat ik tegen Remco (mijn embedded engineer) toentertijd zij het zou mooi zijn als we de pi ook als plotter zouden kunnen gebruiken. Zijn antwoord...."Dat gaat nooit gebeuren!" en kijk waar we nu zijn!

Nog niet getest maar ook een wensen van mij:
@signalk/vedirect-serial-usb
Signal K Node.js server plugin to read Victron VE.Direct data via serial USB

signalk-airmar-plugin
Configure an Airmar DST800 depth sensor by Scott Bender
(weet niet of dit voor de NMEA0183 of NMEA2000 is)

signalk-calypso-ultrasonic
Signal K plugin for connecting to and receiving wind data from a Calypso Ultrasonic wireless wind instrument by Fabian Tollenaar

signalk-overboard-notifications
Signal K server plugin that creates notifications when devices stop sending location updates by Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.

Zeilprutser schreef : Dit is niet mijn ervaring.
Net ff een iperf3 test gedaan tussen een synology server en een raspberry pi over WiFi.


TCP test:

pi@pi:~ $ sudo iperf3 -c diskstation -p 5201 -b 0 -Z -t 5
Connecting to host diskstation, port 5201
[ 4] local 192.168.1.8 port 39406 connected to 192.168.1.3 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 9.74 MBytes 81.6 Mbits/sec 0 351 KBytes
[ 4] 1.00-2.00 sec 11.4 MBytes 95.4 Mbits/sec 0 414 KBytes
[ 4] 2.00-3.00 sec 12.0 MBytes 101 Mbits/sec 0 460 KBytes
[ 4] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec 0 485 KBytes
[ 4] 4.00-5.00 sec 11.5 MBytes 96.4 Mbits/sec 0 510 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-5.00 sec 56.7 MBytes 95.1 Mbits/sec 0 sender
[ 4] 0.00-5.00 sec 55.3 MBytes 92.7 Mbits/sec receiver

iperf Done.


UDP test:

pi@pi:~ $ sudo iperf3 -c diskstation -p 5201 -u -b 0 -Z -t 5
Connecting to host diskstation, port 5201
[ 4] local 192.168.1.8 port 45166 connected to 192.168.1.3 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 12.5 MBytes 104 Mbits/sec 1600
[ 4] 1.00-2.01 sec 12.6 MBytes 105 Mbits/sec 1610
[ 4] 2.01-3.00 sec 13.1 MBytes 110 Mbits/sec 1680
[ 4] 3.00-4.00 sec 13.2 MBytes 111 Mbits/sec 1690
[ 4] 4.00-5.01 sec 13.4 MBytes 112 Mbits/sec 1710
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-5.01 sec 64.8 MBytes 108 Mbits/sec 1.380 ms 0/8289 (0%)
[ 4] Sent 8289 datagrams

iperf Done.


De UDP bandbreedte is 16% hoger dan TCP.

roozeboos schreef :
@noreen:
Heb het op open water nog niet echt goed kunnen testen. De radarbeelden komen over ethernet zonder vertraging binnen. Maar toen Roozeboos aan boord was kreeg ik nog geen goede snelle heading in open_cpn omdat die van de GPS was en niet van het stuurcompu compas. Zou ondertussen wel moeten kunnen met de geinstalleerde actisense. Maar eerst verloor ik beide schroeven en toen moest ik een huis timmeren. Dus nog niet kunnen stoeien. Deze zomer hoop ik weer wat meer te spelen met de grote cat dan zal ik de draad weer oppakken.

@MVDP Dat TCP langzamer is dan UDP is algemeen bekend, dat is waarom ik het eerst niet en Chris nog niet verwacht dat het in onze toepassing sneller zal zijn.
Met de door jou langzaamste geconstateerde TCP snelheid zouden we nog een paar 100 volle NMEA2000 bussen kunnen streamen!
De praktijk in onze toepassing is echter anders, ik heb getest met een Raspberry pi3B+ op 2.4GHZ en 2 Android smartphones en een Tablet, dan naar het grensgebied lopen van je bereik, ik meen me te herinneren dat je dan een "g" verbinding had, in OpenCPN krijg je netjes een timestamp in de NMEA data dus in de log kun je goed zien of er bij TCP lag optreed (dat gebeurt niet) maar je ziet dat bij UDP steeds meer data wegvalt, met TCP kon je de afstand ongeveer 10 tot 30% vergroten (wifi bereik schommelt enorm)

Anyway uit jouw test mag je concluderen dat de bandbreedte icm de raspberry geen issue is, met de door jou genoemde snelheden kun je rustig 3 stuks 4K Video streams opzetten Dat kan mijn Telfort router niet eens!

NMEA berichten (2000 noch 0183) kennen toch geen timestamp? Of kent OpenCPN die toe na ontvangst? Dat is dus dan toegekend na evt latency!?

Anyway geen van de systemen zijn real-time zoals safwguarding systemen dat zijn. Dmv snelle verbindingen kun je wel de latency beperken, zodat er geen significante vertraging optreedt.