Onderwerp: Sailing Performance Dashboard

Nachtvlinder schreef :
Het ontvangen van ruwe NMEA over UDP werkt inmiddels.
Het ontvangen over TCP werkt alleen binnen 1 PC (de zender en de ontvanger); daar zit nog een netwerkprobleempje tussen bij zenden op 1 PC en ontvangen op een andere. Wordt aan gewerkt.

Wat betreft het uitzenden van eigen SPD-NMEA-records:

- dat gaat prima over serieel-COM-TTY (naar de ene COM of naar een aparte 2e OUT-only)

- voor UDP moet dat ook eenvoudig kunnen; kwestie van verzenden. Dat ga ik proberen in te bouwen.

- voor TCP is dat een stuk lastiger: dan moet er 2 kanten op (SPD moet ontvangen en versturen over TCP en dat vereist nogal wat) NMEA verzonden worden. Echte naar SPD en nep naar een mux of zo.
Het lijkt er ernstig op dat ik dat niet ga maken

Het resultaat zal dan zijn dat als je TCP wil gebruiken om ook nep-NMEA uit SPD te ontvangen je pech hebt. Ontvangen over UDP kan dan wel, dus ook als SPD ontvangt via TCP.

Is dat ok?
Of heeft er niemand behoefte aan SPD-NMEA over een netwerk via TCP (naar displays, uiteindelijk).
Er is natuurlijk ook de webserver en node red naar Signal K....

Ja hoor

Dit draadje heeft mij veel bezig gehouden

Als ik heel eerlijk ben, heb ik dit met mijn vriendin en zeilgenote vaak een beetje geridiculiseerd. Dat komt ook omdat wij ernstig onderbeinstrumenteerd op alleen een iPhone (en later ook een waterkaart en peilkompas) op het Wad voeren. En ons eigenlijk kapot ergerden aan de iPhone die afleidt van wind, golven, landschap en elkaar.

Ik had het altijd over "Pleasure Points" met haar, in mijn optiek de ultieme KPI voor de pleziervaart. Wat maakt een vaart plezierig? Het weer, niet te veel en niet te weinig wind, een leuke tocht met veel te zien, lekker eten en drinken aan boord, goed gezelschap, bijzondere gebeurtenissen als zeehond en dolfijn...

En ik dacht: ik wil Pleasure Points meten! En toen maakte ik grappen over een rode en een groene smiley, en vaak zeiden we tegen elkaar, bij een ongelukje in de sluis of stress om op tijd te zijn: rood knopje (en lachen dan naar elkaar). En ook heel vaak: "10000 keer op het groene knopje drukken!" als we weer eens bevangen werden door de extase van een mooie zonsopkomst op zee ofzo.

In mijn vak is "data labelling" hot. Hoe mooi zou het zijn, als je al die data van al die sensoren aan boord kan labelen met "pleasure points", en op die manier met predictive analytics de verwachtingen rondom een zeiltocht kan managen? En de omstandigheden kan optimaliseren?

Of zijn er toch teveel onbekenden in "plezier" omdat voorspelbaar te maken? (koppeling aan voorraadbeheer, de ambitie van het zeilplan, samenstelling bemanning, ...?)

Of gaat het alleen maar om optimale snelheid?

Groeten,


Thijs

Thijs1971 schreef :
Koppelen aan een "Pleasure Points" app die elk bemanningslid de mogelijkheid geeft om in te checken, tijdens de toch smileys te geven en na de tocht een klein evaluatieformuliertje in te vullen (ratings) over de kwaliteit van de schipper, samenwerking, catering, zeilbeleving, tochtervaring en de hoeveelheid humor aan boord?

Dat kan al.
Knopje Write in Log.

Kun je al je plezier mee opschrijven.
Wil je een eigen knopje? ' alweer plezier' knop?

Maar Thijs, waar maak je nou toch uit op dat de zeilers die enthousiast zijn over performance varen niet zouden genieten, gelukzalige momenten afwisselen met minder mooie momenten en die kunnen koesteren?

Lekker genieten van de dingen waar jij van droomt. Anderen de maat nemen kost zoveel energie, zonde van je tijd.

Hier een ouwetje, maar geeft leuk weer wat een lol we hebben:
zeilersforum.nl/index.php/foru...len/578940-oewh-yeah

Speciale versie van SPD voor Thijs1971!

koko schreef :
Ik ben het met je eens hoor, en ben eigenlijk gewoon ook maar een jaloerse gadget freak En missch is de iPhone juist wel zo irritant, want onnodig tijdrovend, want geen ergonomisch verzamelde info in 1 oogopslag beschikbaar en te veel tijd kwijt aan zinloze speculaties over ongemeten hydro- en aëorodynamisch/mechanische krachten en hun koppels.

Het werkt, de TCP verbinding.
Nog een paar laatste tests, en dan de manual bijwerken. Dan v2.6.0.

Hier plaatje van WinGPS en SPD die beide over TCP data krijgen van NavMonPC op een andere PC!
SPD doet nu dus serieel (echt of USB, in en out), UDP (in en out) en TCP (alleen IN).

Versie 2.6.0 staat klaar. Met UDP en TCP support voor NMEA-bron.

Met 100 records / seconde (da's normaal met AIS erbij) lijkt TCP het niet makkelijk te hebben....
Ben benieuwd naar ervaringen.

uit de changelog:
Meer regels ook in de boatspecifics.ini. Die ook even aanpassen! Voorbeeld in de download.

Mooi, fijn en bedankt! Ik voel mij wel verplicht het te gaan gebruiken nu

Zelfs een goed gevulde 38k4 is helemaal niets om via TCP/IP over te dragen. Je kunt dit vast berekenen, maar (alweer...) koko’s 38k4 NMEA0183 stream 10x realtime afgespeeld met NavmonPC TCP server gaf geen enkel probleem.

Maar dat is ook wel uitzonderlijke kwaliteit natuurlijk

Wat een hoop plezier van onze stream toch. Mooi!

Nachtvlinder schreef :
Mooi! De ini files zijn ook wel prettig (tot je er eenin de war maakt )

Ik had hier 1 PC NavMonPC afspelend, de andere over TCP ontvangend, en SPD liet zeer hikkend niet elke seconde maar om de 5 a 10 seconden (RMC-tijd) een update zien. Vreemd.
Kan het nu niet reproduceren.

Je bent niets verplicht, maar ik kan het gebruik ernstig aanraden. Net een vaccin, eigenlijk

Een booster dan toch zeker

Zijn er al ervaringen en/of opmerkingen over de SPD-versie met ini en TCP-UDP verbindingen?

Het is lockdown tenslotte, dus iedereen heeft tijd genoeg om ermee te spelen
Of wachten jullie tot de schoonouders op bezoek zijn?

Ja, de Scarabee moet wel een beetje blijven varen natuurlijk.

Versie 2.6.1 staat klaar... vast de laatste van 2021....

Een paar kleine en grote optimalisaties:

- Routine Splitxdr (part of splitnmea routine) improved; it now can deal with erroneous XDR records better.


- Readline for TCP improved; EOF and a failed decode of the bytes to ASCII give separate errors now

- Separate routines for reading TCP and UDP now combined in simpler ones that can handle both TCP and UDP by looking at the socket type. No impact for users. Just some cleaner code and easier maintenance for the poor programmer....

Tot zover merk je er niets van.
De volgende is wel voor de gebruikers!
De instelling voor de filter voor schijnbare wind (AWA en AWS) is makkelijker geworden.
Deze filter zorgt voor een rustigere AWS en AWA , met name van belang in 'choppy' omstandigheden, stampend in de golven.
Nu realtime (tijdens werkend SPD!) te wijzigen.

- The Apparent Wind filter, a value in processlist.ini, can now also be used in boatspecifics.ini. Section [Inputcontrol] now can have an extra key

[Inputcontrol]
AWfilter = 3

This value will overwrite a value for AWfilter from the processlist file. If not specified in your boatspecifics, a default value will kick in and overwrite the processlist value for AWfilter. This default is hard coded at 3. The AWfilter in proceslist.ini thus is never used any more.
This change makes it easier for users to experiment with a different filter value. Change it in boatspecifics and re-read that with the button ‘I/O & Files’ in a running SPD.

Mooie ontwikkelingen. De afgelopen tijd meer bezig geweest met andere apps, netwerk van thuis naar de boot, nmea naar verschillende apps. Komende week hopelijk weer meer tijd om spd met udp in de pi aan signalk te koppelen.

Fijne feestdagen.

Nog eentje dan... versie 2.6.2
Staat klaar voor WIndows en Linux, maar de PI-versies zijn nog 2.6.1 (gekke time-out bij de compilatie op Github)

Twee knoppen toegevoegd: Apparent Wind averaging, kan nu met knopjes van 1 tot 64!
Ook de knoppen een beetje beter geordend.

v2.6.2 voor Pi inmiddels ook klaar.

Weer even verder met de integratie van SPD. In mijn test streamt signalk de teststream van Koko via UDP. Die stream zie ik ook binnen komen in de omgeving (docker) waar SPD draait.

Bij het starten geeft SPD de melding "UDP listening to port: 2000"
en na een aantal seconden krijg ik de melding "No NMEA records found on UDP, timeout after 50 seconds"

Kan ik ergens in de log zien wat SPD binnen krijgt? Kan het zijn dat hier weer een CR/LF verschil tussen windows en de pi optreedt waardoor SPD de NMEA data niet herkent?

michaelh schreef :
Vreemd....
Die CR/LF die we eerder hadden was achter een poortnaam (bij TTY).
UDP werkt hier prima, zender op de ene PC, ontvanger SPD op een andere.

SPD probeert 5 keer om150 records te ontvangen en te kijken welke soorten er zijn.
(als de 1e keer goed gaat dan slaat ie de andere 4 keer over).
Als er helemaal niets binnenkomt krijg je die foutmelding.

Kun je met een gewone UDP-viewer even loggen wat er daarop binnenkomt als Signal K de stream verstuurt??
Dan kan ik wat meer zien.....

Even een mogelijkheid tot records loggen (printen) ingebouwd.

Even V2.6.3 ophalen en dan:

als je in processlist.ini de onderste extra regel opneemt:

[Starting specials]
Dummywind = N
Noquestionsasked = N
Printnetworkrecords = Y

dan zal SPD de ontvangen records printen naar zijn standaard output (scherm of logfile).
Het zit er alleen ingebouwd voor netwerk-nmea (dus niet serial, com, usb, tty)
Zowel voor TCP als voor UDP werkt het.

5 keer 150 records maximaal, maar bijna altijd max 150.

In V 2.6.3 ook nog het volgende:

Version 2.6.3 of 2 January 2022
- Buttons improved (on-off state shown now on many buttons)
- "App Wind-filter" key added to webserver output, showing number of wind records averaged (AWS and AWA)
- New parameter for debugging purposes in processlist.ini:
[Starting specials]
Printnetworkrecords = Y
When Y is specified, the first (max 750) records received on a network connection (TCP or UDP) will be printed. This way, users can test their NMEA source better.

Tip tussendoor: voor het sturen van of luisteren naar tcp/udp ascii streams is dit een heel handig tooltje : en.wikipedia.org/wiki/Netcat

Het command nc lijkt me de juiste output te geven (zie bijlage):
nc -ul -s 172.17.255.255 -p 2000

SPD geeft echter geen output, terwijl Printnetworkrecords = Y in de processlist.ini staat en ik daar ook een melding van krijg. Met een python script van een paar regels krijg ik ook de udp data binnen.