Onderwerp: Sailing Performance Dashboard

Elk N2K device heeft een SourceID. Als er 2 devices zijn die hetzelfde PGN nummer sturen, zijn deze te onderscheiden hierdoor. In je N2K klokken geef je in de bronselectie aan welke je wilt gebruiken.

Een 0183>2000 vertaler zou unieke talkerID’s aan unieke SourceID’s kunnen (moeten...) mappen...

Hier een voorbeeld: dezelfde PGN uit verschillende devices:

De miniplex3 presenteert slechts de nmea0183 ingangen op het n2k netwerk als source, niet de id's van de sensors/apparaten op die ingangen zitten aangesloten. Helaas


Gepost met de officiële Zeilersforum-app

Beter zou zijn om talkerID’s te onderscheiden, maar dat is toch allemaal niet relevant voor dit draadje?

Wel iets relevants:

in de Log van de frou frou (met NKE apparaten) zitten heel wat meer VHW-records (met STW) dan RMC-records (met SOG).
Bovendien zit in die VHWtjes de watersnelheid met 2 decimalen, dus honderdste kts.
De COG in de RMC is 1 decimaal.

Als ik in een replay van die log omschakel van SOG naar STW voor de berekening van True Wind zie je dus de variaties in True Wind (Angle en Speed) toenemen. Gemiddeld zal het wel hetzelfde zijn, maar de grotere hoeveelheid VHWtjes én die extra decimaal geven een zeer rommelige TWA en TWS.

Ik ga eerst die STW uit de VHW maar eens afronden op 1 decimaal, kijken wat dat doet. 1 honderdste knoop lijkt me een beetje onzin

En weer een extra reden om SOG (in Heading minus Current) te nemen voor TWA.

Formeel dien je een pre-sampling filter toe te passen op de analoge meetdata. Die analoge data is echter niet beschikbaar; je kunt dat echter ook in het digitale domein doen door

-met zo hoog mogelijke frequentie te samplen (10 Hz bij PolarPlot)
-deze data door een eerste orde presaming filter te halen
-met veel lagere frequentie (1 Hz bij PolarPlot) samples hieruit te halen

Heb PolarPlot daarom in parallelle threads opgebouwd:
-zodra er nieuwe data beschikbaar is komt deze in een buffer. Event-driven dus
-deze buffer wordt hoogfrequent gesampled (vaste Fs) en gefilterd (Tf afhankelijk van hieronder)
-berekeningen worden met lagere, vaste Fs uitgevoerd op de met Tf gefilterde data

Als je zoekt in de audioweteld naar “pre-sampling filter”, “A/D conversie”, “D/A conversie” en “oversampling” vind je goede voorbeelden van deze technologie.

666 schreef : Weet je het zeker? Ik kan er nu even niet bij, maar volgens mij is er zelfs een speciaal veld SA (source adres).

Even iets over correcties op gemeten Apparent Wind (AWA en AWS):

Sommige instrumenten corrigeren misschien ook al iets, en dubbelop corrigeren is ongewenst.

Masthoogte compensatie is natuurlijk nuttig voor performance en polar; de polar geldt voor 10m hoge wind. Ook de windvoorspellingen zijn voor 10 meter (Harmonie e.a.), dus die 10 meter is wel nodig. Wind bij de masttop is niet van belang. SailingPD corrigeert dus AWS naar 10 meter hoog.

AWS compenseren voor helling is maar weinig. Mijn windset zit op 18 meter, dus naar 10 meter is een flink stuk eraf. Je ziet het als je stilligt: de AWS daarboven is dan meer dan de TWS 10m.

Het beetje dat er bij 20 graden helling nog af gaat is flink minder dan die 8 meter. Wordt wel gecorrigeerd a.d.h.v. gemeten of polar-heel.

Wel staan de schoepjes bij helling schuin tov de wind! Formule daarvoor heb ik uit een artikel over windmolens die in de bergen op hellingen staan; die hebben er echt last van: wind volgt de bodem/helling en stroomt schuin op de schoepjes.

AWA wordt niet voor masthoogte gecompenseerd door SailingPD, wel voor helling. Formule van Arvel Gentry 1981. Als je plat ligt en wel snelheid hebt komt de wind altijd recht van voren, dat idee
Ik wil best (in de boatspecfics) iets maken dat dubbele compensaties voorkomt; als NKE het al doet (andere spullen niet, voor zover ik weet) dan kunnen we de SPD-compensaties eventueel uitzetten.
Gaat dan om deze vier dingen:
AWS voor Masthoogte (sensor)
AWS voor helling, geeft andere hoogte
AWS voor helling, correctie voor schuine schoepjes in de wind
AWA voor helling, hoe schuiner hoe meer van voren.

Iemand een idee of instrumenten al een en ander corrigeren?

@koko
Ja dat weet ik eigenlijk wel zeker. Neemt niet weg dat je op bijv je nmea2000 display natuurlijk wel kan kiezen dat je je diepte via nmea0183 ingang 3 wilt zien, omdat die PGN daar aanwezig is. Maar als er op die nmea0183 ingang twéé dieptemeters aanwezig zouden zijn, kan je niet kiezen tussen wélke.

666 schreef : Ah, ik snap nu beter wat je bedoelt. Dat zal wel kloppen inderdaad. Maar op een ingang past in principe maar 1 talker. Dus het probleem dat jij schetst doet zich alleen voor als je 2 multiplexers koppelt.
Maar nu zijn we wel of topic
Over het inregelen van multiplexer en andere routering middelen wil ik binnenkort een nieuw topic starten. Wie weet kunnen we het daar uitdiepen.

Bij mijn Raymarine ST60 vroeger en de nieuwe, zelfde windmeter, maar dan omgezet door een converter (ITC5) naar STng ben ik die optie niet tegengekomen. Ik kan er nog even naar zoeken, maar het zou me verbazen.

Maar stel dat een merkt dat doet, compenseren voor sensorhoogte, da kan je SPD toch op 10mtr sensorhoogte zetten?

SPD is effectief ook een multiplexer...

Gepost met de officiële Zeilersforum-app

666 schreef : Klopt helemaal. En als je ook een navigatieprogramma wil laten draaien heb je nog een compoort splitter nodig. Niet helemaal een mux, maar wel routering software.

666 schreef :
Nou.....

SPD heeft net 455.000 records van 3Noreen in 20 seconden omgezet in 25.000 slimme logrecords.
Dat zou ik geen multiplexen noemen.
Het is meer het omzetten van ruwe en versplinterde datazooi in hoogwaardige informatie

koko schreef :
Precies. Simpele oplossing.

Ik heb net de Manual van de NKE Racing Processor (snel) doogelezen.
Er is daar correctie op AWS voor helling als je een NKE hellingsensor hebt.
Verdere correcties ben ik niet tegen gekomen (de 10 meter, de schuinstaande windschoepjes,d e AWA met helling). Ik wacht nog op andere NKE-gebruikers voor meer info.
Vooralsnog ga ik niets programmeren om correcties weg te laten als de instrumenten al corrigeren.

666 schreef :
SPD heeft maar een input, dus daar valt niet zo veel aan te multiplexen.
Hooguit de ene input met de gegenereerde records.

Nou, oké. Multiplexen niet, maar zet natuurlijk wel een heleboel ruwe data om in nieuwe, slimme als je wil data en zet dat weer op de bus.

Zodra je de data uit SPD zichtbaar wil maken op een display in de kuip is routering en multiplexen wel iets waar je bij stil moet staan. Maar dat is meer iets voor het project van Holtere.

De meeste correcties heb je er nu wel inzitten, maar je mist nog wat slimmigheidjes die nodig zijn om straks een consistente en ruisarme TWD - The Holy Grail - te kunnen realiseren zonder systematische fouten (9 en 10).

Blokje (12) heeft Sailmon uitgevonden en geeft een zeer stabiele maar wel dynamische TWA. Jij hebt iets vergelijkbaars gedaan bij het schatten van STW op basis van ruisige STW en lokale stroming. Je zou het een rudimentaire toestandsschatter kunnen noemen.

Er zijn in principe natuurlijk 2 benaderingen:
- dure sensors die met 25 Hz gesampled worden, en daar dan wat filtering-demping op loslaten (geen mens kan data 25 keer per seconde tot zich nemen ). NKE doet dat zo, en van Sailmon weet ik het niet. Maken die jongens (uit Medemblik!) eigen instrumenten? Ik zal het Jan eens vragen
- leven met wat er is: langzame NMEA183 (0,5 a 1 Hz) en een beetje N2K. Dan is snel samplen totaal onmogelijk en is de enige oplossing achteraf de ruis er een beetje uit werken. Omdat het allemaal niet real time hoeft (we gaan niet de AP aansturen) en de boot en de mens erop toch traag is, is het niet om met wat moving averages over pakweg 5 seconden te werken. Niemand die het merkt; de massa van de boot is toch de traagste factor in het geheel.

Bovendien zijn veel data al gedempt en gefilterd voor we ze zien.
Wie weet wat een AWA/AWS sensor en display allemaal doen voor wij een windrecord zien? Het zijn getelde pulsjes, dus een digitaal signaal van een bepaalde frequentie. Logwieltje idem. Ultrasoon log? Digitaal. GPS? Daar zit een hoeveelheid processing in voor wij een COG of SOG te zien krijgen...

Wat betreft de Holy Grail:
als het goed gaat heb ik binnenkort 3 manieren om Leeway te bepalen:
- de aloude formule van Arvel Gentry, met de K (ook in gebruik bij NKE Racing en in Sailmpn)
- uit wat driehoeksprocessing waaruit leeway+stroom komen. Dan stroom opzij eraf, en leeway blijft over.
- uit een VBW (uit PGNs gemaakt door Miniplex3). In die VBW zitten 4 snelheden: voorwaarts en zijwaarts, beide tov water en tov ground. Komt uit N2K uit moderne snelle sensoren als EV. Als die versnellingsopnemers zijdelingse bewegingen integreren (beetje links, beetje rechts) is het eindresultaat een snelheid (opzij en naar voren).
Deze dingen vereisen een beetje filtering om de ruis te verwijderen, maar dan heb je een prima leeway.
In SailingPD is actuele leeway nu al te zien (uit die driehoekjes dank zij een oude Griek). Die is best stabiel. Het VBW record zal dat nog verbeteren.
Dan hebben we die 3 leeway-inschattingen. Twee meer dan NKE, OCPN en Sailmon.
Daarmee is een betere TWD en TWA te maken, zeker met een beetje gedempte AWA. Idem TWS.
Alles ook nog gecorrigeerd voor masthoogte en helling.

Dan wordt het een keuze van hoeveel wil je achterlopen op de werkelijkheid.
Gezien de traagheid van de massa (boot) en bemanning (ogen en hersens ) lijkt het me niet erg als de getoonde data een paar seconden achterlopen bij de actuele werkelijkheid van wind en snelheid....

Het is dat, of vele 10k eur uitgeven aan top-apparatuur.

SailingPD schreef :

roozeboos schreef :
Een andere filter-optie is natuurlijk bij een beetje flink aanbod van NMEArecords gewoon de helft weg te kieperen en het Overflow-knippertje aan te zetten.

Betreft datahandling:
Het gaat er alleen om, om op elk moment een consistente set getallen te laten zien, meer niet... Dat lukt dus niet als de actueel weergegeven performance berekend wordt op een windmeting die 10 s oud is, terwijl de STW net vers is binnengekomen.

Je dient je mix van data uit verschillende bronnen, met verschillende latency en Fs dus zo consistent mogelijk te maken. Meer kun je niet doen en minder doen is zonde en geeft meer ruis dan nodig. Dit heeft niet met de prijs van je instrumenten te maken.

Grofweg zijn er 2 methoden:

-Event driven: telkens als er 1 nieuw datapunt (1 meting...) binnen is bereken je alles opnieuw, op basis van de net geupdate dataset

-Vaste executie intervallen: elke (bv) sec bereken je alles opnieuw, op basis van de op dat moment laatst beschikbare data

Wat doe je nu in SPD? Beide methoden hebben voor en nadelen, en je moet sowiezo even nadenken wat deze methoden vergen qua filtering - wat er effectief gebeurt. Dat hoeft echt niet ingewikkeld te zijn om weg van te lopen, maar hoort bij je software ontwerp.

Betreft de correcties:
Op de correcties die je mogelijk onbewust laat liggen doel ik op blokje (9) en (10) in de hierboven gepostte rekenstructuur. Hieronder en in de links staan deze beschreven. Denk je zonder deze te kunnen / op basis waarvan schat je in dat deze te weinig toevoegen?

Ik daag je uit om vooraf een uitspraak te doen wanneer je tevreden bent met de resultaten van een typische consumer set aan instrumentarium:
-Hoeveel graden mag de TWD berekening slingeren bij overstagjes of testrondjes op de motor?
-Hoeveel kn mag de TWS berekening varieren bij deze manouvres?

Het is een groot compromis tussen kosten van hardware (doen we niet, "standaard instrumenten!") nauwkeurigheid, complexiteit en bruikbaarheid.
Nachtvlinder schreef :

Nachtvlinder schreef :
Zoveel mogelijk met zeer verse data rekenen. Elke AWA AWS SOG COG STW etc gaat meteen mee en het resultaat wordt direct getoond. Er wordt nergens een berekening gemaakt met gefilterde data.
Alleen voor het displayen worden sommige data gefilterd. En dat is the zien aan de Italics Display

Sommige data hebben wat filtering nodig om de ruis uit de metingen te halen.
Gelukkig zijn dat vaak data die niet elke seconde veranderen. Stroming, leeway, diepte, gemiddelde windrichting en -snelheid.

Dus het gebruik van een 5 seconden gemiddelde van berekende leeway en stroming in berekeningen van TWA en TWS lijkt me prima te verantwoorden. (bovendien hoef ik niets te verantwoorden Het is gratis ).
Dat zit er nu nog niet in. Komt vast wel.

Het alternatief is die zaken als leeway en stroming helemaal niet mee te nemen, en daar wordt het resultaat niet beter van.
Ze ongefilterd meenemen is ook geen verbetering.
De gulden gratis middenweg dus.

Je bent je al behoorlijk aan het verantwoorden hoor! En alle opties die ik noem zijn gratis

Event-driven dus met hoofdzakelijk output filtering begrijp ik. Goed dat je daar over nadenkt.

Betreft de correctietabellen:
"TWS correctie voor downwind condities" en "TWD is tacking with me"

Wat verwacht je van het eindresultaat, wanneer ben je tevreden, hoeveel nauwkeuriger denk je te worden dan bv Tactictool of de Multiview (afgezien van de extra info die je presenteert!)

-Hoeveel graden mag de TWD berekening slingeren bij overstagjes of testrondjes op de motor?
-Hoeveel kn mag de TWS berekening varieren bij deze manouvres?

Durf je daar nu al een uitspraak over te doen, of wordt het dit gewoon en wordt de toepasbaarheid een resultante geen specificatie?

Nachtvlinder schreef :
Correcties die je telkens weer in moet voeren ga ik bewust (!) niet aan beginnen.
PC aanzetten, een paar klikken en het moet werken.
Windshear verandert van uur tot uur (of sneller) met temperatuur lucht/water, met drukverandering etc. De enige constante is de irrelevante coriolis . Windshearmeter kost 3 euro.
Upwash verandert met zeilvoering (rif, hoger of lager voorzeil). Niet te meten bovendien.
Acceleratie (veel pitch zwiepende masttop en sensor) geeft rare metingen EN uit de groove-zeilen.
Calibratie-koersen varen.... Als je daar net mee klaar bent is het allemaal alweer anders. Dan is je windsetje lekker op temperatuur en verloopt de aanwijzing...

Ik maak niet iets voor de America's Cup of zo; het is een gratis, makkelijk ding dat voor de meeste gewone zeilers iets van bewustwording en inzicht geeft.