Onderwerp: nmea wifi repeater

nou ik weet t nu ook niet meer hoor..

Baasklusje schreef :
Interessant! Zijn dit soort analyses ook geschikt voor dynamische waarden of dien je dan trukjes uit te halen door een of meer reeksen te verschuiven in de tijd?

Had in m'n vorige baan (advanced process control engineer) erg mooie tools daarvoor die juist geschikt zijn voor multivariabele dynamica, maar die statistische tools zoals jij voorstelt weer missen. Een combinatie zou ideaal zijn!

Matlab heeft vast ook goede toolboxen daarvoor, maar dat is geen goedkoop pakket...

Ach, in Excel en wat logisch nadenken kom je wellicht ook ver!

Dus.....en nu, wat moet er dus nu aan de mux aangepast of geprogrammeerd worden??

Oeps, heel wat stof tot denken opgewaaid vandaag.........

Helaas kan ik geen zinniger bijdrage leveren dan het wensen lijstje en natuurlijk een praktijktest.

@BK: ik denk niet dat het trager reageren/verversen van de st60 multi gaat helpen. Dan pakt hij random het laatste gegeven dat dan nog steeds ongefilterd/ongeremd door de mux wordt gepresenteerd.

Volgens mij is er niets anders mogelijk dan Chris al voorstelt: berekende performance filteren voordat ie uitgespuugd wordt. Interpretatie is dan alleen geldig zoals BK al jaren doet: analyses alleen indien waardes voldoende stabiel zijn.

Of en hoe de ingangen gesynchroniseerd zijn, ruis of incorrecte dynamische informatie bevatten heeft dan geen invloed.

Waar ik nog wel aan zat te denken: dat iOS appje wat Sunday laatst linkte lijkt zelf te detecteren of een waarde (daar een toegevoegd punt aan een groeiende polar) geldig is of niet - in rood of groen weergegeven. Wellicht kan het nuttig zijn de mux zelf te laten bepalen of een berekende performance stabiel genoeg is om geldig te zijn of zich nog aan het instellen is? Dit dan met een extra, ook te loggen, statusbit of gewoon geen ongeldige waarden uitspugen. Geeft wel weer extra mogelijkheden tot bugjes natuurlijk en maakt troubleshooting lastiger "gaat er iets niet goed of zijn de omstandigheden niet stabiel genoeg?"

Heb nog ergens een proefschrift met een statistische methode om te bepalen of een signaal "stationair" genoemd mag worden, maar een criterium zoals BK gebruikt lijkt mij een doeltreffende vereenvoudiging.

Ik ben zwaar onder de indruk van alle berekeningen hierboven... pff daar komt heel wat bij kijken!


Na de laatste update valt mijn MUX niet meer uit! Maar de al gemelde waarneming dat de IP op 0.0.0.0 werd gezet deed zich ook bij mij voor. Na handmatige aanpassing doetíe het weer prima.

Wie heeft er ook een ST60+ diepte aan de mux hangen? Ik krijg geen diepte signaal. Dit weekend wel een repeater in het seatalk-netwerk gehangen, daarop komt de diepte prima tevoorschijn. Maar in zowel de log van de mux als de wifi log zie ik niets wat lijkt op diepte.

Daarnaast wordt al mijn ST60+ winddata geïnterpreteerd als wind van stuurboord. Ook als die dus van bakboord staat. Heeft iemand dat ook al een keer gezien?

tnx

Mij viel afgelopen weekend na uitgebreid testen een aantal gekke dingen op;
- De ware wind berekening in opencpn gaf een (overigens aannemelijke hoek en snelheid) wind van stuurboord aan, terwijl de schijnbare van bakboord kwam. Hierbij heb ik het over de app en true wind ANGLE, de true wind DIRECTION blijft altijd op noord bij 0 knopen staan vreemd genoeg...
- De gps locatie op het scherm wisselt tussen de echte locatie en een of andere locatie rond utrecht. Dit fenomeen verdwijnt bij het uitschakelen van de output van de RMB of RMC sentence in de plotter.. Deze zijn echter wel beide nodig voor de autopilot, dus ik zit even vast!
- Er komt geen kompaskoers (van de raymarine autopilot) binnen op de pc, terwijl andere data van de seatalk (bv diepte) wel netjes doorkomen.
- Zonder van de IP-adres bug te weten was de mux na de update ook niet meer te vinden op 192.168.1.1, heb deze als test naar .255 gezet en sindsdien weer prima functie.
Genoeg te puzzelen dus! Enige echt vreemde vind ik die ware wind.... Daar kan ik niets op verzinnen.

Nachtvlinder schreef :
een factoranalyse doe je op een N-dimensionale correlatiematrix, correlaties tussen allerlei (op hetzelfde tijdstip gemeten, in dit geval) gegevens.
Stel je die correlaties voor als een N-dimensionale puntenwolk (of 2 of 3 dimensies, als N wat lastig te zien is ); wat factoranalyse doet is door die puntenwolk een aantal assen ('factoren') zoeken die de variantie het beste (meeste) verklaren.
Lastig is vervolgens de interpretatie van wat die assen nu precies betekenen, hoewel dat in het geval van een boot wel mee zal gaan vallen.
Dus: meet en correleer SOG, AWA, AWS, TWA, TWS, STW, Pitch, Roll, Yaw, DBT en wat je nog meer maar hebt gemeten, en gooi de correlatiematrix in een factoranalyseprogramma.

idonap schreef :
Hmmm, interesant.......is me nog nooit opgevallen allemaal. Dat is waarschijnlijk ook wel logisch in miijn geval want al mijn instrumenten zijn seatalkers. (Behalve de gps). Dus windrichting en snelheid, log en diepte, compas, stuurautomaat. De Multi en de Graphic geven alles weer, maar halen die data ook niet uit de mux, maar van de Seatalk lijn ( noem ik het maar).
Ik zal weer eens een logje maken binnenkort en eens kijken. Of de Ipad eens linken via wifi. 'S kijken wat die dan nog laat zien.

@BK: doet me denken aan Principale Componenten Analyse. Ooit eens gebruikt om een vrij complex cement produktie proces (roterende 160m lange oven zoals ENCI Maastricht) te begrijpen. De meer dan 30 variabelen bleken tot slechts 3 onafhankelijke "bewegingsrichtingen" gecombineerd te kunnen worden. De inputs in deze 3 principale component bleken te staan voor massa balans, energie balans en voeding samenstelling. Gaf veel inzicht destijds en hielp verbanden zichtbaar te maken.

Ben benieuwd wat er hier uitkomt!

Nachtvlinder schreef : idd, dat is één van de soorten factoranalyse.

en wie gaat er nu meten en rekenen ?

Baasklusje schreef :
Met dat verschil dat een PCA Ortogonale componenten oplevert en een FA niet natuurlijk ;->

Maar belangrijker: Wat hopen we hier uit te leren dan? Ik durf wel te gokken dat een PCA 3 orthogonale factoren oplevert: TWA, TWS en heading.... De rest heeft allemaal correlaties met deze 3.
Een vierde onafhankelijke factor is 'trim' maar die meet je niet.

Orthogonaal is wel beter te snappen.... die willen we!

Zou er niet een factor 'golven' tevoorschijn kunnen komen? Deels met wind gecorreleerd, maar dat hoeft niet natuurlijk.
En helling, is niet per se windgerelateerd, hangt sterk van de koers af...?

en als we alles gemeten hebben en ge-PCA-d dan zeilen we geen meter harder...
Maar voor een stuurautomaat (voorspellen!) kan het wel nuttige info opleveren.

Beste idonap

Diepte signaal lukt me ook niet uit seatalk, noch uit ST50+ nog uit ST4000 als repeater. Krijg je wel speed door het schoepenwieltje STW door?

Baasklusje schreef :
Dus niet orthogonaal Sterke correlatie met koers en wind.

Om het lekker simpel te houden zou ik Chris aanraden een vorm van demping op de wind data in de nmea wifi repeater in te bouwen. Zowel raymarine als nasa lijken deze gegevens ongedempt door te geven.

Chris, ik weet niet hoe het met jou gaat, maar ik zit met grote ogen naar alle tekst hierboven te kijken en zit me af te vragen of we nu wel, of juist niet in de zeik worden genomen. Waarlijk geen idee

Aannemende dat alles hierboven serieus is lijkt het mij dat daar een performance meter wordt ontwikkeld waar Bouwe en Dirk nog plezier van zouden hebben. Of dat nou perse uit de mux moet komen??

Maw: als er een wat rustigere output uit de mux komt, die liefst een aantal gegevens middelt of filtert waarmee er een bruikbare performance uitrolt heeft de mux al veel meer functionaliteit dan andere muxxen. Het hoeft geen VOR meter te worden.

Als ik een bijdrage kan leveren hoor ik je graag!

ditto hier,

Het is een beetje als de performance zelf. het schiet een beetje door, met heel veel reacties en suggesties.
Ik zit een beetje te wachten tot de rust er weer terug in keert en dan maar kijken wat we gaan doen.

ik snap er de ballen van..

koko schreef :
Het is allemaal serieus hoor, van die analyses.
Dat zijn statistische technieken om uit een hele berg data (meetdata van een schip ook dus) allerlei gevolgtrekkingen te kunnen maken over verbanden tussen de gemeten gegevens.
Maar het gaat wat ver voor onze huis-tuin-keuken performancemeter.....

Gewoon een aantal seconden de berekende performance middelen, en het gemiddelde displayen.
Misschien nog met een door de gebruiker instelbaar aantal seconden, voor de rust op de display.

Baasklusje schreef :
Helder...zo zie je maar wat er voor kennis komt kijken bij het wetenschappelijk benaderen van onze sport.
3Noreen (onder anderen) stelt voor om de gegevens van de windmeter te dempen. Dat komt op mij wel logisch over. Die varieert het snelst en het meest. Windsnelheid en windhoek varieren immers per golf, stuurbeweging, vlaag, flatgebouw of windmolen enz enz. Het mooist zou zijn om die gegevens per tijdseenheid (zeg de ververssnelheid van de output) te middelen?
Dat zou je ook kunnen doen met bootsnelheid, maar je kan bootsnelheid misschien ook 1x per update pakken? Minder nauwkeurig natuurlijk, maar de mux moet het ook allemaal maar berekenen.
Wat blijft er dan nog over/ missen we nog aan beschikbare data voor de performanceberekening?
Update snelheid instelbaar van 1 tot 30 sec? Is zat, toch?

Nabrander: het middelen van de performance zelf is denk ik (nog) niet de weg. Hoewel geen log gemaakt, viel mij tijdens het kijken naar de meter op hoevaak er gekke waardes voorbij kwamen. De mux heeft verschillende codes. Je krijgt 3 cijfers (het percentage) en een letter. De P is performance, de F is van meetfout en de V van wind buiten het bereik van de tabel (zachter dan 6 kts of hogere hoek dan 44gr ware wind of lager dan 120 gr ww). Daarnaast vlogen de percentages flink op en neer met verschillen van meer dan 50% in luttele seconden. Dat gaat nog steeds een mal beeld opleveren, ook al is dat dan een gemiddeld mal beeld.

Volgens mij is de formule die Hans Fix voorstelt al voldoende. (Voor de wind data.)

Als Roozeboos slim is, is de performance bij de volgende update niet meer aanwezig, komt hij ook nog eens op het water.

ik zou niet zo snel de data de schuld geven.....

Op de Capolavoro komt de SOG zo ongeveer per 2 seconden uit de GPS, de AWA en AWS ook zoiets, misschien nog wel minder vaak dan dat.
Filtering in Tactictool gebruik ik vrijwel niet (zie eerdere post).

En Tactictool logt elke seconde, in 3 decimalen, de performance. (99,999%)
Drie willekeurige minuten uit de laatste trimclinic zien er dan zo uit, met 1 waarde per seconde:





Netjes toch, met die ruwe input? het gaat van 80 tot 95.

Dat had ik niet verwacht.....dat wind en sog ongeveer per 2 sec wordt ververst. Ik gebruik bootsnelheid, maar kan dat omzetten naar sog. Verder hebben wij dezelfde windset, dus daar kan het niet in zitten.

Dan is het eerste onderzoek dus toch de instelling van de multi. Ik weet niet op welke instelling die van mij staat, maar ik zal hem aanpassen. Dat lukt niet eerder dan zaterdag of zondag. Ik laat het weten en draai gelijk een log uit de mux.

henkvd schreef :
Slecht voorstel, heel slecht voorstel :angry