Onderwerp: Raspberry Pi performance box

MOTION CORRECTION...

...was nog een optie die verder uitgewerkt diende te worden. Deze feature zou sterk afhankelijk zijn van de snelheid van de metingen, de nauwkeurigheid daarvan en de dynamica in de sensoren zélf. Met dynamica bedoel ik in dit geval de looptijd en group delays veroorzaakt door filtering in de sensoren zelf (die verder niet te beïnvloeden zijn).

Hoewel het me tegen stond de Actisense N2K<>USB dongle te kopen om met de Airmar "proprietary software" alleen hún sensoren te kunnen configureren heb ik dit toch maar gedaan. Nu draait zowel de AWA, AWS en attitude (motion) sensor in de ultrasone windset op 10 Hz (het log trouwens ook maar dat is niet zo zinvol). Tot 20 Hz zou kunnen maar was volgens mij niet nodig en zou een nóg hogere data rate in de RPi geven; processor belasting is nu al bijna 50% en op een gegeven moment gaan de latencies (ik krijg de N2K data binnen via een interne TCP server uit het CANboat project) een overheersende rol spelen.

Onderstaande analyse komt uit een directe dump van de CAN bus (ook via die TCP server). 10 Samples per seconde dus; stukje data is plm 2 minuten.

Vannacht lag ik voor anker in mooi stil water met een zwakke wind van 3-5 knopen; op de kop uiteraard. Door de boot zo veel als ik kon aan het slingeren te brengen kon ik redelijk wat (ik noem dit) "induced wind" opwekken in de masttop, waarbij zowel de gemeten AWA en AWS flink verstoord raakten. Te zien was al dat de Windex ver door slingerde (bijna rondjes draaide), terwijl het leek dat de massaloze AWA en AWS metingen mooi de pas hielden met de slingeringen.

Onderstaande plot laat de ruwe data van het slingeren en de daardoor veroorzaakte (en gemeten!) verstoringen in de AWA en AWS zien.

De AWS staat hierbij op de rechter as; Heel en AWA op de linker as.

Te zien is dat:

• er voldoende snel gesampled is om de variaties in zowel de beweging van de boot als de wind te beschrijven;
• er een correlatie is tussen de bewegingen van de boot en de gemeten wind;
• ook ná het slingeren de variaties in de gemeten wind lijken te correleren met de -dan afnemende- bewegingen van de boot;
• de boot tijdens deze periode iets achter het anker heeft liggen draaien (of dat er een "echte" windshift is geweest).

Volgende stap is om deze correlatie aan te tonen en eventuele dynamica in de sensoren (die de tijd-relaties tussen de metingen zouden kunnen verstoren) te identificeren. Omdat de AWA een directe relatie met de afgeleidde van Heel moet hebben (dHeel/dT - als de boot naar SB beweegt draait de gemeten AWA ook naar SB), is de kruiscorrelatie daartussen bepaald. Deze correlatie is maximaal wanneer Heel 2 samples (=200 ms) vertraagd wordt tov de wind. Correlatie is dan 0.92 - behoorlijk duidelijk dus. Zonder deze delay van de gemeten Heel is deze correlatie 0.90 - echt nodig is deze verschuiving dus niet. AWA en AWS zijn al maximaal gecorreleerd zonder verschuiving (komen natuurlijk ook uit dezelfde processor in de masttop unit).

Om de motion correctie te doen wordt in PolarPlot (en hier in Excel tbv de analyse) de wind (AWA en AWS) ontleed in de snelheidscomponenten in X-en Y-richting. In deze plot is ook de (200 ms vertraagde) induced wind weergegeven. Deze heeft nu alleen een X-component, omdat de boot slingerde niet stampte. Dat ziet er als volgt uit:

Hierbij staat de gemeten wind in voorlijke richting op de rechter as.

Te zien is dat:

• de gemiddelde wind van voren (plm 3.5 kn) groter is dan van opzij (1 knoop van BB). Dat is logisch want de boot lag voor anker;
• de gemiddelde wind van opzij een grote correlatie heeft met de induced wind, terwijl de wind van voren er meer als ruis uit ziet. Ook weer logisch want de boot slingerde wel maar stampte niet;
• ook ná het geforceerd slingeren (laatste 1/5 deel plot) correleert de X-component goed met de induced wind door het weinig bewegen van de boot op de golfslag die er was. Gemeten windvariaties zijn in dit geval dus bijna volledig veroorzaakt door het bewegen van de boot en niet door variaties in de wind zélf!

Dan het resultaat van de motion-correctie, die als doel heeft de "echte" AW zo nauwkeurig mogelijk te laten zijn, voordat die omgerekend wordt naar de true wind die PolarPlot gebruikt om de performance te berekenen.

Hieronder de plot die de gecorrigeerde X- en Y-component laat zien met daarbij de mate van correctie van de X-component.


Te zien is dat:

• de mate van correctie gróter is dan de waarden zélf (dit is een vrij extreme situatie maar ideaal voor analyse);
• de gecorrigeerde waarden geen duidelijke correlatie meer hebben met het slingeren van de boot - en dus de "echte" windcomponenten weergeven

Tot slot het resultaat. In deze plot de gemeten én gecorrigeerde AWA en AWS.


Windsnelheden staan op de rechter as.

Duidelijk is dat:

• de verstoring van de meting door het slingeren bijna geheel is verdwenen;
• de gecorrigeerde meting tijdens en na het slingeren veel beter de "echte" variaties in de wind volgen.

Resultaat is beter dan wat ik gehoopt had! Nu nog corrigeren voor het stampen, maar dat gaat precies hetzelfde, alleen in de Y-riching

Het is fraai!
Maar waarom slingerde je de boot harder naar de min (BB?) dan naar de plus?
Je stond zeker binnen en kon meer naar SB dan naar BB... wat je al niet kan zien aan een goede reeks metingen

Stand van de giek in de kuip beperkte mijn mogelijkheden!

Nachtvlinder schreef :
je ziet, niets blijft verborgen

Fraai...maar houdt het ook stand?

Je hebt nu een minofmeer sinus beweging gemaakt in een nagenoeg zuivere bb/sb beweging.

Frequentieafhankelijke verschuiving (mogelijk geen ding bij een motionless, maar nu nog niet uit te sluiten) zal nog om de hoek komen kijken bij echte golfbewegingen, ook in relatie tot de v00-achter beweging.

Verder zal de compensatie misschien wel op twee of meer assen gecalibreerd moeten worden; windsnelheid en seastate zijn niet afhankelijk van elkaar.

Maar wel een hoopvol begin!

Denk dat de verschuiving (2 samples - 200 ms) er niet zoveel toe doet. Optisch zie je dat niet eens. Verder gaan we het zien inderdaad; zou met 2 zware kerels de stamprichting nog eens uit kunnen zoeken, kijken of dat consistent is.

De bewegingen van een boot onder zeil zullen niet dit soort sinussen zijn, maar blokgolven of zaagtanden ook weer niet. Boot heeft zelf nogal wat traagheid natuurlijk.

Maar dit eerste resultaat valt me allezins mee: heb niet hoeven tweaken door aan een of meer signalen best-geuss dynamica toe te voegen bv.

boarderbas schreef :
Bas, hier raak je me kwijt. Ik ken de rol- en stamp-as maar kan me iets voorstellen bij een vertikale as. Is dat waar je op doelt?

Zou je ook je laatste opmerking (wind onafhankelijk van seastate) willen toelichten?

Die hoogfrequente ruis die je in het laatste plaatje ziet in de tijd waartussen de boot aan het slingeren is (vergelijk hoe ruisig de gecorrigeerde AWA is tijdens en na het slingeren!) is afkomstig door het differentieren van de Heel. Zie hieronder een snapshot van hoe die afgeleidde eruit ziet tijdend de nuldoorgangen van de Heel. Het punt waarop de blauwe lijn over gaat van stijgend naar dalend... Dat klopt niet indien de slingeringen een zuivere sinus zouden zijn:


Die rare ruis komt denk ik doordat de Heel slechts met 1 decimaal wordt gemeten (rond de nuldoorgang kent de afgeleidde haar maximum/minimum). Ook denk ik een latency te zien: soms lijkt het alsof 2 opeenvolgende samples verwisseld zijn in de tijd.

Klopt dit? Wat zou ik hier aan kunnen doen? Heel heeft een delay van 2 samples nu: dit geeft mogelijkheid een klein laagdoorlaatfilter te bouwen met een group delay wat hier binnen valt.

We hebben 3 draaiende bewegingen: stampen, slingeren en gieren
En 3 bewegingen heen en weer in 1 richting: dompen, verzetten en schrikken.

Zou je eigenlijk allemaal moeten meenemen, behalve dompen misschien. Hoewel, dompen met veel helling doet wel wat met de windmeting...



Verder kun je grote golven hebben zonder wind (swell ergens anders vandaan) en ook heel veel wind en plat water (bij de hogerwal). Dus de afhankelijkheid (wind ==> golven) is niet eenduidig...

Ah, ok.

Wat zou gieren dan voor invloed kunnen hebben op de meting?

Qua ontbreken relatie wind en seastate klopt het natuurlijk wat Bas en jij zeggen. Maar de manier waarop ik nu corrigeer is volgens mij helemaal niet afhankelijk van het wel of niet bestaan van zo'n relatie! Ik schat real-time (2 samples te vroeg) welke wind de mast bovenin zelf opwekt en trek die af van de gemeten wind. Waarom zou dit niet/anders werken bij:
-weinig wind en veel golfslag vs.
-veel wind en weinig golfslag?

Baasklusje schreef :
Ik lees het topic bewonderend mee en probeer een en ander te snappen....., helaas erg technisch voor mij om het allemaal te bevatten

Maar even off-topic: over deze materie, de termen en bijbehorend plaatje zou ik me wat verder willen inlezen.
Uit welk boek komt een en ander?
Alvast bedankt.

Groeten,
Hans

Leuk stoeien met data stromen.

Wat ik me zelf afvraag hoeveel beter deze methode is dan gewoon een filter op tijdbasis van de slingerbeweging.
Interessant zou zijn om een gefilterd signaal te laten zien met een instelbare demping waardoor je mogelijke vervorming door fase verschuiving zou kunnen zien. Kortom hoeveel slechter is zo'n signaal.

Dat zou een leuke oefening zijn inderdaad.

Naar mijn mening echter is het bewegen van een boot niet altijd een mooie periodieke beweging; slingeren wellicht wel maar bij ruime wind surfen of aan-de-wind een paaltje pikken lijkt het me lastig hier een adaptief filter op in te stellen. Bovendien haalt zo'n (elk!) filter data weg, onafhankelijk van de herkomst. Ook "echte" variaties in windsnelheid/-richting rond die frequentie zullen dan gedemp worden.
De motion-correction is fysisch bepaalt en corrigeert real-time voor de verstoring op dat moment: het is niet adaptief op een recent stukje geschiedenis (en loopt dus ook nooit achter in geval van veranderende omstandigheden (als je hoger gaat sturen bijvoorbeeld waardoor de golven anders binnen komen)

Wellicht kan beide tegelijk ook:
-een conservatieve (bv 70%) motion correctie en
-op de resterende harmonischen een (licht) adaptief filter

Wellicht heeft dit een goede combibatie van robuust en toch een levendig, natuurgetrouw resulterend signaal?

Ps: 3Noreen, weet jij nog waar je laatst opgeschreven hebt hoe je jouw filtering precies doet? Vergeten te bookmarken en kan het niet meer vinden...

Nachtvlinder schreef :
Ik neem aan dat de verticaal van je assenstelsel gekoppeld is aan de buitenwereld (zodat je niet elke keer de wind hoeft te projecteren op een schommelend vlak, maar dat het gewoon evenwijdig aan het xy vlak waait).
Dan volgt daaruit dat gieren onder helling ook een snelheidscomponent in de masttop tot gevolg heeft.

Verder zal je ergens een gelijktijdige rotatie (slingeren) en translatie (verzetten) moeten koppelen, want die hebben samen tot gevolg dat het polair punt van de rotatie van je schip+mast ergens anders dan in het zwaartepunt van je schip komt te liggen.

Wel een leuke uitdaging.

Even snel voordat ik er verder mee ga stoeien: hieronder het FFT spectrum van de Heel en AWA in een vast window van de eerste 512 samples. Frequentie-as is in Hz en stopt bij 5 Hz - de halve sampling frequentie.



Duidelijk is dat de dominante periodieke frequentiecomponent voor Heel en de daardoor verstoorde AWA gelijk liggen, althans het maximum ligt in dezelfde "bin", namelijk 0.234 Hz (=periodetijd 4.3 s). Dit hadden we al gezien en klopt met de slingertijd.

Ben benieuwd wat 3Noreen hier nu precies heeft gedaan.

In het tijdsdomein:
-de absolute amplitude van deze verstoringscomponent schatten;
-dit signaal genereren, synchroniseren met en aftrekken van de meting.

Of in het frequentiedomein:
-een notch (band stop) filter definiëren;
-de meting door dit filter halen.

Vooral het benodigde synchroniseren in de eerste optie lijkt me lastig. Als hier te grote fouten in zitten dan zou deze "noise cancelling" weleens meer kunnen beschadigen dan het goed kan doen kan ik me voorstellen!

PS JotM: ik kom op je opmerkingen terug - stof tot nadenken

Nachtvlinder. Hoe heb je de correctie uitgevoerd?

Mijn data zien er bepaald anders uit. Een trimaran gaat ook niet zo slingeren als en mono. Hierdoor is het signaal hoofdzakelijk verstoord door beweging veroorzaakt door de sea state. Tijdens het zeilen komt een signaal wat zo'n grote hoekverdraaiing heeft niet voor.

Mijn data processing is voorlopig gericht geweest om een beter resultaat van de stuurautomaat te halen. Vooral ruimwinds. Dan stuur ik op ware windhoek. Dit is dus een samengesteld signaal wat veel meer fouten bevat. Zeker het log signaal is matig van kwaliteit.
In het tijdsdomein kun je nooit meer correctie doorvoeren dan de inschatting van jitter tussen de verschillende signalen. Mijn streven is niet een tien te halen maar van een zesje naar een 7+ te komen.

Dat begrijp ik, en het hier gebruikte signaal is meer een academisch voorbeeld dan hoe het Heel signaal en de (in dit geval) hierdoor verstoorde wind metingen er in de praktijk uit zullen zien. Echter, als het hier al niet werkt, zal het in de praktijk zeker niet werken.

Ik ben dus benieuwd wat je met jouw FFT resultaat doet in de praktijk. Je hebt je SOG signaal en doet een FFT analyse hierop. Hoe corrigeer je dit SOG signaal dan vervolgens?

Aswin schreef :
Die FFT heb ik nog niets mee gedaan, was een oefening om te zien hoe deze geforceerde slingering in een FFT analyse naar boven zou komen. Je zou, op basis van die analyse, ofwel in het tijdsdomein, ofwel in het frequentiedomein kunnen corrigeren. Benieuwd dus naar wat 3Noreen nu uiteindelijk gedaan heeft; weet alleen dat hij ook ergens een FFT analyse doet op zijn SOG data.

Hij schrijft hier over:
De correcties die je in de eerste post boven in deze pagina ziet heb ik gedaan door de wind (richting en snelheid) in de top van de mast te ontleden in een voorwaardse richting op het meetvlak van de sensor (lengterichting boot) en zijwaarse richting (breedterichting van de boot), ook parallel aan het meetvlak. De mast snijdt dit meetvlak loodrecht.
Door ook de hoeksnelheid (in knopen) in de masttop te bepalen in deze richtingen heb ik de parallel aan het meetvlak gemeten windsnelheden gecorrigeerd. Daarna deze gecorrigeerde snelheden weer teruggerekend van cartetisch naar polair: van (Vx,Vy) naar (AWA,AWS).

Hoeksnelheid is in principe dHeel/dT * 2*Pi*Masthoogte/360 (en dan nog omrekenen van m/s naar kn)

Opvallend is dat wanneer ik de echte masthoogte gebruik, er veel te sterk gecorrigeerd wordt. Met een toegevoegde fudgefactor van plm 0.3 werkt het zoals in de plaatjes. Geen idee hoe dat komt - misschien doet de windset zelf al een gedeelte van de correctie of wordt er daar al gefilterd. Echt zuiver "first principles" is het dus niet, eigenlijk...

Hi,

Is het niet mogelijk om de hoeksnelheid direct van je sensor te betrekken ipv deze uit de attitude (heel) af te leiden? Indien er een gyro in je sensor unit zit dan wordt deze namelijk ook direct gemeten.
Niet alleen is dit een meer directe route met minder kans op verwerkingsfouten (bv door onnauwkeurigheid in de dt) maar attitude kan ook beïnvloed worden door de versnelling van het schip zelf. Attitude is direct of indirect afkomstig van een versnellingsmeter en gebaseerd op de richting van de zwaartekracht. Echter een versnellingsmeter meet niet alleen de zwaartekracht maar de som van de zwaartekracht en de versnelling van de sensor zelf. Bij een slingerende masttop en/of varende boot is er ook sprake van versnelling van de sensor. Dit kan je correctie verstoren. Bovendien geeft een versnellingsmeter veel meer ruis dan een gyro sensor. Mogelijk heb je hier geen last van omdat je sensor een (mbv de gyro) gefilterd signaal afgeeft maar dat kan ik niet beoordelen.

Zou je je ruwe data beschikbaar willen stellen? Ik vind het leuk om daar eens naar mee te spelen. Ik heb vaker met dergelijke data en filters gespeeld. Ik zeg niet dat ik er alles van af weet maar weet wel waar je in praktijk zoal tegen aan loopt.

Welke sensor gebruik je?

Als je je email per PB geeft stuur ik je graag de data.

Roll en pitch is inderdaad beter dan de orientatie Heel en Trim, maar die heb ik niet beschikbaar. Daarom als alternatief snel sampelen en zelf de eerste afgeleidde bepalen.

Ik gebruik een Airmar WX150 sensor

Nachtvlinder schreef :
De eerlijkheid is dat het nog een proces in ontwikkeling is. Door stukjes FFT code die ik van het net af vis in te bouwen in mijn programmaatje kijk ik simpel weg wat er met het signaal gebeurt en of de uitkomst van de FFT functie iets zinvols over t+1 kan produceren. Door log files af te spelen kan ik op die manier experimenteel knoeien.
Op deze manier maak ik me schuldig aan wat ik regelmatig jonge gasten verwijt dat ze met hun rekenmachine wel de antwoorden kunnen achterhalen maar niet weten hoe het uitgerekend moet worden.
Kortom subjectief constateer ik dat het werkt. Ook als ik dan het meest veel belovende programmaatje in de praktijk aan mijn stuurautomaat koppel. Alleen je kun betwijfelen of de resultaten algemener dan alleen mijn boot toepasbaar zijn.
Als ik publiceer zal er, zelfs hier, opgemerkt worden dat het slechts experimenteel geknoei is. Wat ik ook niet kan ontkennen.

Ook dat geeft niets natuurlijk!

Maar voor dat vooruitkijken dien je de voorspelde verstoringsinput toch te synchroniseren op de real-time data?

Even text-book maar weer. Stel:

• jouw FFT analyse geeft aan dat de gemeten SOG een frequentie van 1 Hz bevat met een amplitude van 1 kn
• je neemt even aan dat dit door seastate komt en dus gecorrigeerd mag worden
• ik neem aan dat je van plan bent het nieuw binnenkomende sample te corrigeren voor de meest aannemelijke nieuwe waarde van die verstoring
• daartoe dien je te weten waar in de amplitude van de sinusvormige verstoring dat nieuwe sample zit

Ofwel je dient de fase tussen de verstoringsinput met het gemeten signaal te synchroniseren zodat je de juiste waarde op het juiste moment aftrekt van de meting...

Hier wat plaatjes van wat ik bedoel met een willeleurig verzonnen SOG signaal:

In groen de gemeten SOG en in paars de door FFT verkregen (niet gemeten) verstoring daarop.

De echte verstoring valt hier, zowel in amplitude als fase, samen met de door de FFT gereconstureerde verstoring. Door deze verstoring af te trekken van de gemeten SOG kan het "echte" SOG signaal gereconstrueerd worden (blauwe lijn).



Nu hetzelfde plotje en methode, echter de gereconstrueerde verstoring (paars) is in amplitude juist, maar is in fase een beetje verschoven tov de echte (niet gemeten) verstoring.
Het resultaat (gecorrigeerde SOG - lichtblauw) lijkt nog redelijk op de echte SOG (donkerblauw) en is in elk geval beter dan dan de gemeten SOG (groen)



Weer hetzelfde plotje en methode, maar nu met een grote fase-fout. Te zien is dat de gereconstueerde SOG (lichtblauw) slechter is geworden dan wanneer er niet gecorrigeerd zou worden. In een extreem geval (faseverschuiving 180 gr) zou het compensatie signaal er zelfs bij opgeteld worden ipv afgetrokken (teken is verkeerd).

Ik heb een garmin gps. Uit de gebruiksaanwijzing.

4.4.1 One-Pulse-Per-Second (PPS) Output
The highly accurate one-pulse-per-second (PPS) output is provided for applications requiring precise timing measurements. After the initial position fix has been calculated, the PPS signal is generated and continues until the unit is powered down. The rising edge of the signal is aligned to the start of each GPS second within 1 µs for all conditions in which the receiver has reported a valid and accurate position for at least the previous 4 seconds.
The NMEA 0183 sentences that follow each rising edge of the PPS signal tell when you were and where you were at that previous rising edge of the PPS signal, beginning with the RMC sentence as the lead sentence in any particular NMEA 0183 record. If RMC sentence is not enabled then another sentence will be the lead sentence.

Ik zie nu dat je na mijn reactie je voorgaande bericht hebt veranderd met een uitleg waarom het belangrijk is geen fase fouten te introduceren nadat ik mijn laatste bericht geplaatst heb. Dat maakt de discussie wat verwarrend en minder prettig voor mij om informatie te delen.

Een tijd terug heb ik geschreven.

Kennelijk is daar tot nu toe is daar overheen gelezen.
Het mooie van je bijdrage is dat je voor de mede lezer het principe inzichtelijk hebt gemaakt.
Het is ook de reden waarom ik voorliefde heb met het gps signaal SOG én COG te werken. Deze hebben zoals uit het voorgaande bericht blijkt een bijbehorende tijd signaal op 1 µsec nauwkeurig.

Overigens een soortgelijk fase probleem doet zich ook voor bij een, over een korte reeks werkend, exponentieel delay filter. Iets wat ik in het draadje Accurater wind berekenen RoosRepeater/Mux heb trachten te benadrukken.

Verder is van belang om te weten dat de uitkomst van de FFT in de ordes van 0,2 - 0,05 Hz liggen. Dat geeft een indicatie van de jitter tolerantie.

Wat je schrijft over het voorkomen van fasefouten heb ik meermaals gelezen, maar het is mij tot je laatste bericht onduidelijk gebleven wat je daar precies mee bedoelde:

• het aanwezig zijn van jitter in de klok, of
• het niet synchroon inlezen de verschillende berichten (door verschil in lengte van de NMEA zinnen/een multiplexer die de vaste volgorde waarmee de verschillende zinnen worden uitgespuugt om zeep helpt, of
• de onnauwkeurigheid (in het tijdsdomein) waarmee je het eerst volgende nieuwe sample corrigeert door de geschatte fase van het te corrigeren signaal

Gezien je laatste post doel je op de eerste 2 punten?

Anyway misschien is er ook wel wat verwarring ontstaan omdat we (beide denk ik) niet dagelijks in dit vakgebied werkzaam zijn en onze eigen beeldvorming bij de gebruikte termen hebben. Geeft niets denk ik...

Ben de afgelopen tijd aan het lezen, nadenken en pielen geweest over die filtering. Wanneer wil je dat wel/niet doen en welke mogelijkheden zijn er. Filteren heeft tot doel de hoeveelheid ongewenste informatie in het signaal te onderdrukken omdat dit zowel de weergave als de performance berekeningen onrustiger maken. Je wilt ook weer niet te zwaar filteren, omdat dit ook informatie onderdrukt die wél nuttig kan zijn. Slim, opmaat filteren dus...

Ik heb onderstaande ideeën bekeken en op testdata uitgewerkt. Handmatig in Excel voorlopig nog...

1. Correctie op basis van een verstoringsmodel;
2. Correctie in het tijdsdomein op basis van een on-line statistische signaal analyse;
3. Adaptief filteren in het frequentiedomein op basis van eenzelfde analyse;
4. Niet-adaptief filteren met een vast ingesteld filter

1. Correctie op basis van een verstoringsmodel


Hierbij wordt het verstoringsmodel gebruikt worden om de invloed van een gemeten verstoring te gebruikern om de verstoorde meting te corrigeren. Het verstoringsmodel moet geldig zijn onder alle omstandigheden en dient geïdentificeerd te kunnen worden. Deze methode kan alleen real-time gebruik worden indien het verstoringsmodel "kleiner" is (snellere dynamica bevat) als het systeem (boot+mast).

Het eerdere experiment van de "mast motion correctie" is een voorbeeld hiervan: een simpel fysisch model (zonder dynamica in dit geval) blijkt in staat (in ieder geval tijdens dít experiment) de verstoringsinvloed te beschrijven.

Als dit "perfect" zou lukken zijn geen andere vormen van filtering nodig. Dat is in de praktijk nooit zo...

2. Correctie in het tijdsdomein


Deze methode gaat er vanuit dat de (in dit geval niet gemeten) verstoringen een bepaald patroon hebben waarmee ze doorwerken in de te corrigeren meting. In het geval van mijn slinger-experiment en 3Noreen's golven is dat het geval. Hierbij wordt continue (of zover er processorkracht is) een FFT analyse uitgevoerd in een window van de laatste n samples. Hieruit volgt de meest recente schatting van de frequentie van de typische verstoring. Omdat de FFT geen idee heeft of een repeterende signaal component een verstoring is of niet, zal de FFT handmatig een aantal randvoorwaarden moeten worden meegegeven. Als je bijvoorbeeld weet dat een typische golfpatroon een periode tussen 4 en 8 seconden heeft, zou je de FFT kunnen beperken.

In de volgende stap wordt het correctie-signaal aangemaakt. Dit signaal dient gesynchroniseerd te worden met het te corrigeren signaal om een nieuw binnenkomend sample met de juiste waarde te kunnen corrigeren. Fase tussen beide signalen dient gelijk te zijn.

Dat laatste is lastig te bereiken: de FFT kent maar een discreet aantal frequenties en kost veel rekenkracht (teveel om met 10Hz mee te laten lopen in een fatsoenlijk window). In de (mijn) praktijk verschuift de frequentie van het te corrigeren signaal relatief snel zodat de FFT altijd achter loopt en de faseverschillen meer kapot dan goed maken. Ook gezien het feit dat de FFT slechts bepaalde frequenties kan identificeren zal de fase steeds verder uit elkaar gaan lopen.

Echter met een breed window, hoge en stabiele sampling frequentie en stationair signaal (tsja...) zou het goed kunnen werken.

3. Adaptief filteren in het frequentiedomein


Ook deze methode neemt een periodiek verstorings signaal aan, maar werkt in het frequentiedomein. Groot verschil met de voorgaande methode is dat zo'n discreet notch filter relatief zwak filtert aan beide kanten van de centerfrequentie. Daar waar de hiervoor beschreven methode probeert exact één signaal te verwijderen uit de meting, is deze methode minder selectief en verwijderd ook frequentiecomponenten rondom het priodieke signaal. Dat is zowel een voordeel (licht verlopende frequenties worden beter meegenomen), maar ook een nadeel (er wordt altijd teveel informatie weggehaald). Van de synchronisatie fouten en rekenkracht-limitering is echter geen sprake. De FFT kan bijvoorbeeld elke minuut herhaald worden, waarna de filter parameters aangepast worden.

4. Niet-adaptief filteren met een vast ingesteld filter


Dit is wat onze apparatuur standaard doet, meestal met een laagdoorlaat filter. Je filtert (dempen meestal), ongeacht hoe de (al of niet gemeten) verstoringen eruit zien. Dit is geschikt om ruis met hoge frequenties te dempen, maar zal nooit als filter voor specifieke frequenties uitgevoerd kunnen worden.

Op basis van de recente experimenten (voorlopig in Excel), neig ik naar een echte test in PolarPlot met methode (3).

Zal binnenkort wat vergelijkende plaatjes laten zien van deze 4 methoden.

Heb goede resultaten met een biquad Notch filter. Dit is een tweede orde discreet filter, wat behoorlijk robuust blijkt. Werk echter liever met een vierde orde filter, maar met 10 Hz en een centerfrequentie van 0.05 Hz is dit lastig stabiel te krijgen.

Heeft iemand ervaring daarmee?

Nog andere suggesties? Zal veel praktijkdata moeten gaan verzamelen om echt goed te testen...