Onderwerp: Sailing Performance Dashboard

Nachtvlinder schreef :
- 0,996 is 0,4% performance. 6 minuten op de 24uursrace. Twee plaatsen verschil in de uitslag

zeker zinvoller om voor helling de wind te corrigeren. En dat zit er dan ook in, zelfs op 3 manieren:
- AWA wordt gecorrigeerd voor helling met de formules van Arvel Gentry 1981
- TWS wordt gecorrigeerd voor wijzigende masthoogte (door de helling)
- EN TWS wordt gecorrigeerd voor scheef aangestroomde windcupjes. Formule uit de windturbine-industrie:



Nog meer wensen ?

Geen wensen meer, begrijp ik uit de stilte

In het andere draadje over SailingPD (weergeven) staat inmiddels eea over de plannen om ook op een N2K-instrument performance te gaan weergeven.
Dat vereist dan een speciaal NMEA183-bericht dat door de mux (een Miniplex 3) wordt omgezet in een keurig bericht dat op N2K displays en MFDs kan worden weergegeven.
Zoals het nu lijkt wordt het toerental van een van de motoren (standaard PGN in N2K) straks gebruikt voor Performance.

Ander leuks:
de EV stuurcomputer van Raymarine stuurt volgens de documentatie slechts 2 soorten berichten naar buiten: een PGN met Vessel Heading en eentje met Rudder Angle (van de roerstandsensor).
Echter, er blijkt heel wat meer uit te komen!
Na een vertaling naar NMEA183 komen er dan in SailingPD binnen:
- Heave: de vertikale beweging van de boot (dompen in het Nederlands)
- Yaw: de draai om de verticale as van de boot (gieren) als afwijking van de recente koers.
- Pitch: stampen
- Roll: hellen om de lengteas.
- RoT: Rate of Turn, het draaien van echte bochten (niet de kleine korte oscillaties van Yaw)

Pitch, Roll en RoT zitten nu al in SailingPD.
Geven vast interessante mogelijkheden, zoals de invloed van Pitch op performance. Allemaal uit te rekenen met de PDLog.
Wat we met Heave (dompen) moeten weet ik zo even niet. Golflengtes meten?

Yaw geeft natuurlijk meteen een effect op hoe goed je on de groove stuurt. Het kan zijn dat je Yaw moet 'maken' om in de groove te blijven, maar het omgekeerde kan ook: Yaw (van golven) die je uit de groove gooit....

En dan komt er vermoedelijk ook nog een goed gevulde VBW-NMEA183.
Daarin zitten watersnelheden in 2 richtingen: de lengte en haaks op de boot.
Als dat er echt netjes uitziet hebben we daarmee een prima meting van drift (incl eventuele stroom).
Ik ben benieuwd hoe zo'n EV van RM die 2 snelheden meet..... versnellingen (recht en hoek) is een ding, maar continue snelheden? Iemand een idee?
De veranderingen in die twee snelheden leveren dan ook gegevens over schrikken en verzetten, en dan hebben we alles!

SailingPD schreef :
De hamvraag is met welke frequentie komen die berichten. Plus krijg je het gemiddelde sinds het voorlaatste bericht of een momentane meting.

Leuk allemaal, straks alles aan alles correleren via multivariate statistische analyse

Roll (de daaruit afgeleidde heel) kun je gebruiken om de drift op stromend water (waar COG -/- HDG niet geldig is) te schatten...

Als je je software breed toepasbaar wilt maken, dien je veel aandacht aan “crippled modes” te besteden: verschillende combinaties van niet beschikbare data. In z’n simpelste vorm door de gebruiker aan te geven of automatisch laten herkennen...

Nachtvlinder schreef :
Heerlijk ja, ik zie de logistische regressies al voor me, en dan daarna weer wat Smart Warnings inbouwen op basis van de ontdekte samenhangen! Eindelijk een beetje AI in het zeilen

Van die Roll en drift moet je even uitleggen, of bedoel je de invloed van helling op de K-formule voor drift?

"crippled' modes" wordt al flink wat tegen gedaan.
Zo wordt elke cycle (een SOG en een Wind record gevonden) ook onthouden wat er de vorige cycle gevonden is aan allerlei waarden. Als er iets mist (want geen NMEA binnengekomen) dan is er altijd nog de waarde van de vorige cycle. En als dat mis gaat zijn er defaults (vaak nul).
En Python heeft een prima foutafvang:
de functie Try: (en dan een stukje code)
gevolgd door de functie Except: als er een fout in de Try optreedt (delen door nul, bijvoorbeeld) dan vangt de Except-code dat op.

Ook wordt elke numerieke waarde uit een NMEA-record getest of er wel een getal van te maken is.
Na het oppakken van het veld uit het record is het tekst, en die moet dan een integer of een float worden. Dat stelt eisen aan dat veld: het moet wel een getal kunnen worden.
Als er een $ in zit, of twee punten, of een letter, dan wil dat niet zo.
En je weet nooit waar die records eerder geweest zijn
Ze worden dus allemaal getest; er mag alleen 0123456789. in zitten. Anders gaan ze in de bittenbak.

Voor alle testers:
een nieuwe versie SailingPD 1.5.1 op het bekende adres op de Onedrive.

Diverse kleine verbeteringen:
- geen fout meer bij wifisend = N in de sendoverwifi.txt (systemfiles) (Dank AdB voor het ontdekken)
- stopt nu correct als er geen RMC of windrecords in de live input zitten (bleef eerst braaf wachten)
- wifi broadcast gaat nu naar alle UDP-luisteraars binnen wifi-bereik (op poort 5000), niet slechts naar een enkel IP adres.

Toegevoegd:
- NMEA 183 RPM bericht, motortoerental. Dat zou door vele omzetters naar N2K moeten worden vertaald
- NMEA 183 XDR bericht, maar daar heeft nog niemand wat aan Er zijn geen displayers voor.

Te downloaden:
- SD Program files/dist met alle programma's
- aangepaste manual
- nieuwe sendoverwifi.txt in de systemfiles
- nieuwe NMEATemplates.txt ook in de systemfiles.

Die laatste is ook echt nodig want daar staan de 2 nieuwe records (RPM en XDR) in.
Wel even onthouden welke variabelen je nu gebruikt in je Templates; in de nieuwe file staan vast andere waarden.
Je zou ook alleen die twee nieuwe regels in de Templates erbij kunnen zetten voor de dapperen onder ons.
Deze twee:

$PDRPM,E,1,$sogperf,$sogperf,A
$UPXDR,G,$sogperf,P,SailPerf

en waag het niet er spaties achter te zetten
De E,1 in de PDRPM is Engine 1. En dan staat zowel bij Toerental als bij Trimpercentage de sogperformance op je N2K display.

Thomas,
De “E,1” is die nog aan te passen naar “E,2” voor de mensen met een module die echte motordata verstuurt?
Of zijn er dan andere addertjes onder het nmea-gras?

In systemfiles/NMEAtemplates.txt kan je het template aanpassen, en elk nummer kiezen dat je wilt.

De letters PD in de prefix $PDRPM geven ook aan dat de verzender van dit bericht SailingPD is, zou kunnen dat dat ook nog herkenbaar is na het omzetten naar NMEA2000. En in sommige displays kan je selecteren welke bron je wilt gebruiken.

koko schreef :
ALLEEN 1 of 2.
GEEN 3 of iets anders.

Bij het inlezen van de NMEATemplatesfile wordt gecontroleerd of er geen niet-ondersteunde waarden in staan (zoals $xyz voor een niet-bestaande variabele,, of $twss , een typfout).
1 en 2 staan in die lijst, E ook. Andere dingen dus niet....

Dit alles ter voorkoming van serieuze problemen door gebruikers zelf veroorzaakt

Leg je met dat soort controles niet te veel beperkingen op? Waarom zou de software zich moeten bemoeien met wat de gebruikers aan geldige of ongeldige NMEA-sentences prutsen in die templates?

Menno schreef :
De template wordt gevuld met een Python Substitute.
Als er namen van variabelen in de template staan die niet voorkomen in de substitute gaat dat fout.
Ook als er recordtypes worden gebruikt die niet in de lijst staan geeft dat narigheid.
De software kan er prima tegen, maar de gebruiker krijgt niet de records die hij verwacht.
Zou ik gewoon kunnen laten gebeuren natuurlijk, maar dan zijn de gebruikers boos dat het niet werkt
Nu wijs ik ze op hun foutjes... het typfoutje $sogperff bijvoorbeeld geeft dit:



Is dat vriendelijk of niet!

Inmiddels van een paar gebruikers wat feedback gekregen.

- iemand stelt voor de afmeting van het PD displayscherm voor de gebruiker te definieren te maken. Dat zou dan in een opstartfile kunnen (processlist). Nu is het scherm een vaste maat waar alles precies in past. Het is ook te vergroten (vol scherm) of te verkleinen. Slepen aan de randen. Gewoon een normaal window dus. De opstartmaten (pixels hor en vert) in een opstartfile stoppen is simpel maar kan ook tot nare fouten leiden.

- een ander verzoek is om de twee files voor copy-NMEA-IN en copy-NMEA-OUT automatisch een naam te geven. Je hoeft die files niet te maken (twee maal N in de boatspecifics en klaar is kees), maar als je ze wel wil moet je ze een naam geven. De PDLog krijgt wel automatisch een naam (bootnaam+jaar+datum+tijd)
Dat kan natuurlijk ook voor beide NMEAcopyfiles, die PDLogs zien er zo uit:



Wat vindt men ervan?

Die automatische naamgeving lijkt me prima. Naderhand kun je desgewenst eenvoudig selecteren en herbenoemen. Dat is dus enkel maar gemakkelijk!

Eens met Holtere. Dat is altijd goed te herleiden naar iets wat je zoekt. Woensdag avond competie van twee weken geleden? Datum en tijd is alles wat je nodig hebt.

Mogelijk fouten introduceren met ernstige consequenties......... niet doen. Tenzij je in de handleiding een lijstje maakt met fouten, resultaat en oplossing.

Ja, via de afschatting Leeway = K_fudge * Heel / BSP^2

Het liefst gebruik je (alleen toepasbaar zonder stroming) Leeway = COG -/- HDG, maar op stromend water moet je op die afschatting terugvallen. In PolarPlot heb ik daar een toggle voor gebouwd (Tidal_mode). Tevens wordt dan geen (10 Hz en erg nauwkeurige) SOG maar BSP gebruikt voor bootsnelheid.

Uit data analyse van verzamelde data in non-Tidal mode kun je K_fudge bepalen.

toch nog een kleine aanvulling op automatisch naam geven: wellicht ook SPD in de naam opnemen, zodat je data kunt herkennen als uit Sailing Performance Dashboard.

nobody schreef :
In een kort logje door de multiplexer zaten 2006 regels met data, zonder AIS.480 + 480 + 91 regels daarvan kwamen uit de EV1 sensor. Hieronder het overzicht.

aantal type
229 $WIMWV
45 $WIMTW
45 $WIMDA
45 $VWVLW
39 $VWVHW
98 $VDVBW
91 $TIROT
45 $SDDBT
146 $PSMDOV
460 $PFEC
460 $HCHDG
45 $GPZDA
45 $GPVTG
45 $GPRMC
45 $GPGLL
45 $GPGGA
22 !AIVDO
56 !AIVDM
2006

Kompas dus met 10 Hz,Wind met 5 Hz en $PFEC ook met 10 Hz. Geen idee wat deze data inhoud.

Als je bedenkt dat de overwegende golf periode op de Zee tussen de 5 en 25 seconde is kun je goed uit een 10 Hz signaal de overwegende golf periode bepalen. Gewoon door de tijd te meten tussen de nul doorgangen. Door vervolgens alle andere gegevens te dempen met die tijd krijg je een behoorlijk stabiel en rustige output zonder dat je een overdreven lange demping hoeft te gebruiken.

Noreen, ik heb geen illusie dat je dynamisch iets kunt met deze data. Gewoon door eerste orde filter halen. Bestaat al volgens mij, instelbaar ook.

Dan kom je ook onder de noodzaak uit anti-aliasing filters te gebruiken; te verwerken data dienen dan de gefilterde waarden geen spotmetingen te zijn.

Als je maar lang genoeg middelt komt de wind altijd uit het zuiden.

De PFEC,GPAtt en de HCHDG komen allemaal (na conversie in een mux) uit de RM EV.
In de PFEC,GPAtt zitten roll en pitch.
Er is ook nog Rate of Turn in de TIROT, ook via mux uit de EV.

Die EV stuurt dus heel wat meer dan de Rudder Angle en Heading die in de manual staan.
Dat doet 'ie vast (en met 10 Hz) om de eraan gekoppelde RM AP (ACU en drive) van veel snelle info te voorzien.

Voor SailingPD is het niet interessant, die 10 Hz.
De aanpak is dat er een RMC en een Wind record (VWR of MWV) binnen moeten komen, en dan kan er true wind, performance etc worden berekend. Dat is dus pakweg 1 keer per seconde, afhankelijk van het binnenkomen van de RMC en MWV en/of VWR uit de instrumenten.
Alles wat in de tussentijd binnenkomt (10 keer de HDG, de Pitch etc) is niet zo relevant. Daarvan wordt de toevallige laatste (van de 10?) meegepakt, degene die vlak voor de RMC of windrecord zat, vlak voor de rekenfase. (if windfound and rmcfound, staat er in de code)
Dat is dus een (niet geheel random) selectie uit die snelle records.
Voor Roll (heel), RoT en HDG doet dat er niet zoveel toe die zijn redelijk stabiel van zichzelf; voor Pitch met golfperiodes van 5 tot 25 seconden (of langer, deining) is 1 Hz ook nog steeds genoeg; 2.5 keer de hoogste frekwentie in het signaal sampelen was vroeger altijd genoeg .
Binnenkort komen er ook Heave (dompen) en voorwaartse en zijdelingse snelheden (tov water en tov ground) beschikbaar in een NMEA183 (uit N2K EV bericht). Daar kijk ik naar uit!

De 10Hz is overigens in de mux eenvoudig te reduceren tot iets langzamers. 1 Hz lijkt me voldoende.
We gaan tenslotte geen AP aansturen, we gaan nette gedempte data aan de bemanning laten zien waardoor ze sneller gaan varen, met de hand sturend! En er is ook nog altijd de demping door de massa van de boot: het duurt even voor je effect ziet van je handelen.
Uit de groove raken is een kwestie van 3 seconden pinchen, en de performance zakt naar 75%
Terug in de groove komen (op 100%) gaat een heel stuk langer duren....

Precies, komt allemaal niet zo precies, qua timing Een filter met tijdscontante van zo’n 5 sec is prima.

Hie headers signaleren is wel typisch een dynamisch iets bedenk ik me. Via welke tijdsconstantes ga je filteren om (niet te laat...) één significante draaiing te detecteren?

Nachtvlinder schreef :
Er is een tijdreeks van geowind, lengte instelbaar met het knopje more/less filter.
Uit mijn hoofd minimum 2 (bijna geen filter) maximum 512 seconden. (ca 9 minuten)
Een shift is dan als er meer dan shiftdev verandering is tussen het gemiddelde van de eerste en de tweede helft van de reeks.
De shiftdev stel je in (grensloos) met more/less shift knopjes.
In het gevoeligste geval (shiftdev 0, filter 2) is er dus altijd wel een shift, het ongevoeligste geval is nooit shifts (hoge grenswaarde, en lange reeks)
Moet natuurlijk in de praktijk ondervonden worden of dat goed werkt.

Zo zou ik het ook doen. Je zou “shiftdev” nog automatisch kunnen bepalen uit de mate van stationairiteit van de geowind, maar dat wordt erg complex.

Gebruik je echt geowind (grondwind wanneer geankerd) of TWD (wanneer op stroom dobberend)? Wanneer je plotseling een gebiedje met meer stroom invaart bij het passeren van een stroomrafel; moet je daar dan iets mee?

Nachtvlinder schreef :
Dan verandert het verschil tussen COG en HDG en tussen SOG en STW.
En daardoor ook de Apparent Wind. En de True Wind aan boord. En niet de Geowind

Uiteraard, maar krijg je daar een waarschuwing over, dat je kunt loeven bv?