Onderwerp: Sailing Performance Dashboard

Hier de analyse. Dit alles nog zónder helling...

zeilersforum.nl/index.php/foru...box?start=125#817401

koko schreef :
-files de naam default geven kun je zelf doen
- NMEAtemplates moét zo heten. Meerdere kan niet. Je kan wel onderweg editen en opnieuw inlezen, en/of een rename van een andere file doen en die dan inlezen.
- de YY (voorUDPover wifi en voor Webserver) kunnen allebei of apart N zijn.

Een openstaand punt was nog of SPD ook last heeft van het draaien van de ware wind (geo-windrichting) bij een tack of gijp.
Dat gebeurt natuurlijk niet echt maar is het gevolg van het missen van wat meetcorrecties.

Gisteren (trimclinic) wat tacks gemaakt en net even gekeken wat de geowind dan doet.
Niets! En dat hoort zo

Blauw de geowind, oranje de heading.

Versie 1.9.6 komt eraan.

- Postprocessors now ignore log-records with sogperf higher than 110; these records often are 222-records which raise average performance.

- Deviation changed to x.x instead of whole number. This gives a better deviation table. Post-processor also changed to support this.

Gisteren bij de trimclinic viel op dat er nogal veel header- en lifter-waarschuwingen langskomen.
Zowel echte (winddraai) als velocity (TWS-verandering).

De drempelwaarde voor een echte shift stel je in met een knopje. Default staat dat op 5 graden of meer binnen een halve minuut. Lijkt me redelijk. Maar kan je dus zelf instellen.
De drempel voor de TWS-verandering bij velocity header/lifter is 20% TWS-verandering. Hard geprogrammeerd.
Dus van 15 naar 12 kts, bijvoorbeeld. Ook dat lijkt me redelijk.
Maar ook van 4 naar 5 kts.

Iemand ervaring en/of een mening erover?
Beter teveel dan te weinig waarschuwingen, zou ik zeggen

Baasklusje schreef :
Helder, dank je!

Vanmiddag de post-processor van de log voor het maken van Deviatie en STWcorrectie aangepast om ook helling mee te nemen voor STW. Of dat voor deviatie ook nodig is bekijk ik nog even.
Het inlezen van een STW-correctie met helling erin was al mogelijk in SPD (keuze in de boatspecifics).
Nu kun je hem dus ook maken uit een PDlog. (nou ja, binnenkort, 1.9.7)

Je hebt wel gauw ontbrekende waarden in die tabel met helling, want lang niet elke snelheid van 0 tot 13 kts in stapjes van 0,5 kts komt voor bij elke helling.
Hoge snelheden zijn by definition vooral te vinden bij meer helling....

Dit komt er uit een 9-uurs log van de trimclinic:

koko schreef :
Update op deze vraag: mijn Multiview gaf in de haven af en toe gaan data te ontvangen. Vandaar de vraag. Vandaag onder zeil nog een keer getest. Bleef gewoon draaien nu. Alleen cog en sog bleef op nul. Toen het RMC bericht direct uit de gps doorgezet naar de Multiview en toen bleef het scherm perfect weergeven en niet meer te bevriezen. Perfect nu dus.
Ook de Multiview is dus een prima scherm voor SPD

@koko, mooi zo!

Ik heb de post-processor die STW-correctie en Deviatietabel maakt nu ook aangepast om Deviatie per hellingshoek te berekenen uit een PDlog.
Er komt een keurige CSV uit, maar SPD kan die niet inlezen (alleen Deviatie per boeg, niet per boeg en helling). (STW kan wel per boeg en helling, dat kon meteen al).

Het probleem met deze data is dat er zoveel lege cellen zijn. Dan staat er 0 als deviatie.
Grote helling komt alleen voor bij grote snelheid, en omgekeerd (geen snelheid geen helling) is ook het geval. Dqt geeft een vreemd gevulde STW-correctietabel.

De CSV's die uit de postprocessor komen geven ook het aantal meetpunten (observaties) per cel weer. Dan kan je zien of een gekke waarde (grote deviatie, grote STWcorrectie) misschien door 1 of 2 metingen (seconden) komt.

Ik zou deze 2D-versie van de postprocessor alleen gebruiken voor analyses en dan handmatig je STW-correctietabel (met of zonder helling) en deviatietabel (alleen zonder helling) verbeteren aan de hand van de data in deze 2D-tabellen.

Voorbeeld van de deviatie-tabel na 9 uur trimclinic:

Bij een replay van de NMEA van de trimclinic viel op dat de GEOwind gek deed.
De gefilterde Geowind. Die is een gemiddelde van een reeks van een aantal (2 tot 512, knopje voor instellen) metingen.

De wind rommelde een beetje rond de 0 graden. En als het dan van 10 naar 350 gaat wordt het gemiddelde 180 graden, zuid ipv noord.
Omgekeerd (van 350 naar 10 graden wind) hetzelfde.
Na zo'n shift komt de Geowind dan langzaam weer op de juiste waarde (tot de reeks in het moving average geheel ververst is). Maar dan komt de volgende shift door de nul alweer

Opgelost in 1.9.7, door in zo'n geval even opnieuw te beginnen met moving average-reeks.

Ik geloof dat ik dat opgelost heb door transformatie naar cartetische coördinaten. Mathematisch zuiver ipv die work-around

Hoe heb je de filtering in de live omgeving opgelost?

Versie 1.9.7 in de download.

- New postprocessor for the PDlog: PDtablesbuilder2D. This routine builds a Deviation table with heel (4 rows per bow) and now also creates an STW-correction table with heel taken into account. This table with 8 rows of deviation can be read by SPD (that was already a possibility).
The 2D-deviation is for information only; SPD does not read it. New routine PDtablesbuilder2D.py

- Small error in application of deviation to HDG corrected. Even less false current detection now.

- Moving average of geowind when wind oscillates around 360 was an issue. The average of 350 and 10 is 180…. Should be 0 or 360. Solved with a blunt solution in calcmovatrend routine.

- PDwindsetcheck error in case no warning needed now corrected. Thx Jumping Jack for finding it! His windset nears perfection....

Baasklusje schreef : Kijk da's leuk.
In t kader van meer is beter: Had een aantal PD log files aan elkaar geplakt om verschillende koersen / omstandigheden samen te voegen (dat zou voor stw en deviatie correcties prima moeten zijn dacht ok zo) en zo minder nullen als resultaat, zo even snel 600k regels.

Maar.... alleen de eerste 99k records worden opgepakt. Valt dat nog op te rekken, of gaat die dan over z'n giechel?

Zal ik morgen even naar kijken.
Uit mijn hoofd zeg ik dat er geen beperking is.
Heb je de kopregels van de aangeplakte files wel verwijderd?

ja, in notepad knippen en plakken en dan de header regels er tussenuit halen (even zoeken op 'boat').

En qua nullen in de 2d STW file... als ik 40 graden heel heb bij 1 knoop dan heb ik andere problemen
Dus een trap in die tabel lijkt me heel normaal.
Maar je hebt toch nog een heel aantal verschillende waarnemingen nodig om tot een goede tabel te komen. Omstandigheden die meestal niet op 1 dag voorkomen.

Jumpinjack schreef :
Zeker, een tabel met een trap erin is voor STWcorrectie prima.
Voor deviatie niet.... die moet vol zijn.

In de meeste PD-routines stond 100.000 als max te lezen records.
Dat is bijna 28 uur PDlog, bij 1 Hz metingen. Leek me redelijk

Heb het in 1.9.7.1 op 1.000.000 gezet, 280 uur... genoeg?

@Jumpinjack: kun je een plaatje laten zien van het STW-resultaat?

Lijkt me plenty!
En ik zal eens kijken of ik niet op 10 Hz zit.

Jumpinjack schreef :
Het gaat om de RMC en MWV en/of VWR. De frekwentie van de andere records doet er niet toe.

Ik kan er ook 100.000.000.000 van maken; als de file gelezen is stopt het toch... maar dat kan lang duren...

Zal eea eens naar 1Hz brengen. Dan lijkt me 1Mio records wel plenty om een betrouwbare output te krijgen.

Jumpinjack heeft zo'n 600.000 logrecords door de PDpostprocessor voor STW-correctie met helling gehaald.

Mooi plaatje. Snelheid op de X-as, in halve kts, dus 0 tot 8,5 kts.
De STW-fout bij meer helling is alleen te meten bij hogere snelheden en omgekeerd. Logisch.
Wel een heel groot verschil SB-BB, eigenlijk bij elke snelheid....

Waar zit de sensor, Bas? Of zit hij niet helemaal in lijn met de bootlengte?

Wat betreft de hellingshoeken: die 4 (0,10,25,40) komen uit de manier waarop NKE dit doet. Info van ZZZ.
0 helling is 0 tm 5 graden
10 is 6 tm 19
25 is 20 tm 34
40 is 35 en meer.

Jumpinjack schreef :
Dat hangt er helemaal van af wat de statistische verdelingen is.

Baasklusje schreef :
De sensor zit aan stuurboord, een cm of 30 uit t lood, net achter t begin van de kiel.
Laten we zeggen, een prima plek om te voorkomen dat bij te hijsen de singel er op zit, maar qua meten: prut locatie.
Compensatie is dus onder helling hard nodig.

Qua helling, moet ik mn sensor updaten zodat hij de correctie (1 graad ongeveer) al mee neemt in de messages, dus eea is nu 1 graad off.

3Noreen schreef :
Zeker. 2.5 keer de hoogste frequentie samplen is voldoende. Met 1 Hz data krijg je dus verschijnselen netjes in beeld die 1 keer per 2,5 seconde plaatsvinden.
Lijkt me prima voor STW-afwijking en Deviatie.

En er is ruis en er is bias.
De bias krijg je goed in beeld met veel data. Ruis is random, als het goed is
(anders is het bias.....)

De deviatie van Jumpinjack na 600.000 logrecords.
X-as is stapjes van 15 graden van 0-360
Alle afwijkingen bij helling over Port zijn negatief, Starboard positief.
Minder afwijkingen bij X=12, zuid.

Baasklusje schreef :
Ik heb absoluut geen idee waar je het over hebt. Varieert de uitlezing van je kompas met een frequentie van 0,4Hz ?

Verder ben ik wel benieuwd of andere elektronische kompassen ook iets dergelijks hebben als mijn Airmar kompas.

Heading integrated with the three-axis rate gyro and three-axis accelerometer data allows the H2183 to maintain 2° of accuracy even if the vessel is pitching and rolling up to 30°.

Dus als je kortstondig een helling maakt dan compenseert het ding dat zelf. Maar wat gebeurt er als je langdurig die helling maakt ?

3Noreen schreef :
In SPD wordt HDG niet gebruikt om een AP aan te sturen.
Wel om stroom uit te rekenen: vector COG/SOG minus vector HDG/STW.
Dat gaat prima met lage frequentie data, sterker nog, HDG en STW worden een beetje gefilterd met moving avg.

De EV1 van RM stuurt 10 Hz data uit: Heading, Roll, Pitch, roerhoek. Leuk voor de AP, verder niet nuttig voor SPD.

Heb je de deviatie van de Airmar ook in beeld bij verschillende boegen en hellingshoeken? (hoewel een tri niet serieus helt natuurlijk).