Onderwerp: Low-pass filter voor gps data

Mijn oude vertrouwde RM 125 GPS heb ik deze winter vervangen door een Garmin 19x. Alles leuk en wel maar, deze nieuwe is veel sneller en de berichten die hij uitzend zijn van een veel kortere sample. Ergo COG en SOG gaan met de golf periode waar Noreen overheen vaart op en neer. Het wordt dus wat software schrijven voor de Raspberry die voor een low-pass filtering zorgt. Nu is het meest voor de hand liggend wel een vorm van exponentieel filter. Maar zou het niet zo zijn dat er een verband met de golf periode en de ideale moving average is ?

Ideen ? Algoritme ? Andere opmerkingen.

Is er een slimme manier om software te schrijven die de golf periode determineert ?

Gewoon een eerste orde laagdoorlaatfilter doen. Golfperiode is veel te lang om mee te filteren, dan wordt het veel te traag.

Ieder sample:
Vgemiddeld = Vgemiddeld * (n-1)/n + Vnew * 1/n;
(Bij n = 2,4,8,16 etc wordt het dan een bitshift en is ie nog retesnel ook!)

Interessante vraag!

Een moving average filter heeft, net zoals een exponentieel filter, een low-pass karakteristiek. MA is echter een niet-linear filter met een kleinere afval dan een linear 1ste of 2de orde filter.

Concreet betekent dit, dat als je voldoende demping wilt om de ruis in je (nu te) snelle updates weg te filteren, je filter zó lang en traag wordt, dat wél significante variaties een grote delay kunnen krijgen. Theoretisch dus misschien niet belangrijk in de praktijk

Tweede uitgaging is de implementatie. Exponentieel benodigt maar weinig processortijd (recursief -IIR), terwijl een moving average filter een FIR struktuur heeft. Je dient dus veel meer te rekenen, schuiven etc bij FIR. Dat zal in de praktijk met een RPi overigens geen enkel probleem zijn, maar dat moet je wel netjes zien te coderen. Ik denk dat daar wel voorbeelden van zijn te vinden (ik heb ze zo niet).

Origineel idee om de variaties als gevolg van cyclische bewegingen nog nét weg te filteren, en alle frequenties daaronder door te laten. Lijkt mij een heel leuk experiment om te kijken hoe dat zich gedraagt!
Hoe dát te implementeren weet ik niet: in principe zou je eerst de kantelfrequentie willen bepalen die bij die periode hoort. Heeft jouw platform daar slimme FFT algorithmen voor? Daarna zou je, op basis van die (doorlopend aangepaste) schatting van die frequentie je échte filter willen aanpassen.

Dat laatste heb ik laatst wél wat mee gestoeid bij wat experimenten om "PolarPlot" event-driven te maken. Dan komen de samples niet netjes gespaced binnen, terwijl ik (na filtering) wel een in de tijd consistente dataset wil houden. Het gedrag van het filter moest dus gelijk blijven, te berieken door het filter min of meer adaptief te maken. Ik heb het toen opgegeven, omdat de implementatie wel ingewikkeld werd. Lukte wél om de filterconstante real-time te berekenen op basis van de (vrariabele) tijd tussen de twee laatste samples, maar om tegelijkertijd het filter te her-initialiseren was erg lastig.

Probeer anders eerst eens (om het principe te testen) tegelijkertijd zo'n EMA én FIR filter te laten draaien, waarbij je de lengte van het FIR filter live aanpast op basis van je eigen schatting van de golf-periode. Thuis kun je de ruwe data dan vergelijken met de twee filter-topologiën.

Leuk onderwerp en toepassing! (maar bij mij aardig weggezakt)

Fourieranalyse was ook mijn eerste gedachte. Alleen beheers ik die materie niet genoeg om dat in werkende C++ code om te zetten.
Denk wel dat dit de kern is waar ook de meeste goede stuur automaten gebruik van maken.
Zal eens wat zoeken of er wat code op het net voor te vinden is.
Een MA met een aanpasbare n lengte is niet zo ingewikkeld. Het deel van de software die de data ontvangt zet die in een stack met een schuivende pointer volgens het FiFo principe. Bijvoorbeeld 300 samples (30 seconden). Na behoefte kun je dan een reeks met een variabele lengte de jongste data uit trekken. Het is een beetje van dik hout maar de Pi is snel genoeg om dit met gemak met meerdere data sets te kunnen.

PS: wil je me wat data sturen waar dit effect in zit?

Ik zou het volgende gaan proberen als ik jou was (ga zelf mss ook doen). Een vast EMA filter maken kan natuurlijk altijd nog
Onderstaand is nogal houtje-touwtje, maar kan misschien werken om op een quick-and-dirty manier de golfperiode te schatten?

1. Houd een array1 van vaste lengte bij van ruwe data met lengte die in ieder geval 2-3 golfperioden beslaat
2. Zoek de min en max waarde uit array1 (Max, Min)
3. Range = Max-Min
4. Zoek de index uit array1 op wanneer voor het eerst ruwedata>Min+0.9*Range (Tmax)
5. Zoek de index uit array1 op wanneer voor het eerst ruwedata>Min+0.1*Range (Tmin)
6. Periode=2*(Tmax-Tmin)*sampleinterval
7. Haal Periode door een eerste orde laagdoorlaatfilter; mag best traag zijn (Periode_filt)

Zie je voor je wat ik bedoel? Periode bepaling op deze manier zal best af en toe haperen en af en toe meet je de dubbele periode, maar omdat je deze Periode flink filtert, zou er iets uit kunnen rollen wat gemiddeld langzaam meeloopt met de échte golfperiode in de omstandigheden waarin je vaart. Dat die gefilterde Periode langzaam geupdate wordt hoeft uiteraard niet te betekenen dat deze periode ook groot zal zijn. Nog wel nagaan wat er gebeurt als er helemaal geen golven zijn...

Die Periode_filt kun je dan gebruiken om de tijdsconstante van een eenvoudig EMA filter continue aan te passen.

Ik wil wel in Excel gaan spelen hiermee...

Wat écht leuk zou zijn, is om alles rond die golfperiode of sneller juist niet weg te filteren, maar het golfeffect te schatten en een stukje vooruit te voorspellen. Die voorspelling dan gebruiken om de ruwe data real-time te corrigeren. Je moet dan in de richting van FFT en Kalman filtering denken, denk ik. Dat kan erg gecompliceerd worden.
Ik zou simpel beginnen, zodat eenvoudig te zien is wat er precies gebeurt. Geen black-boxes in dit stadium zou mijn voorkeur zijn.

Ik meen me te herinneren dat de COG en SOG in een NMEA bericht sowieso al 'berekende' waardes zijn die door de gps module gemaakt worden. Ik heb een Adafruit GPS Ultimate aan een RPi hangen. Daar kan ik setup commando's naar sturen om te zeggen over hoeveel tijd de COG en SOG wil hebben in een message. Ik ben er nog niet achter of dat ook iets doet met de middeling van de meetwaarden.

Weet niet hoe snel je Garmin je van positiefixes voorziet, maar wellicht kun je die ook als bron gebruiken om zelf je SOG en COG te berekenen? Hoewel ik denk dat de doppler shift methode in je module in principe nauwkeuriger moet zijn.

Just my thoughts...

Of investeren in een gyro zodat je voortdurend je yaw, pitch and roll weet - daar kun je die info van je golfperiode dan weer van afleiden

Ben wel benieuwd naar nachtvlinder zijn voorgestelde aanpak.

Helaas geen 10Hz (de snelheid van de garmin en kompas) logbestanden. De Rpi maakt dan kaartjes stuk Waarschijnlijk omdat het schrijven te traag gaat en er een buffer over-run komt. Of dat de lees routine om nieuwe data in te lezen zich eerder aandient. Tegenwoordig log ik met een interval van 30 sec met rekenkundig gemiddelden. Die er overigens erg gedempt uitzien. Lig nu voor anker slecht weer af te wachten en kan leuk zien dat de gps een koers haaks op de kompas heading geeft afwisselend naar beide kanten. Wat me wel op het idee brengt om te zoeken naar max en min verschil kk en COG. De gps registreert het wegglijden van de golfen het kompas niet ?

Twist schreef :
Ik heb ook zo'n Adafruit aan boord naast de garmin. Als je hem langzamer zet gaat hij net als de garmin samples weg gooien of, slimmer, niet maken. Hij middelt in ieder geval niet. De garmin heb ik eigenlijk alleen maar gekocht omdat die een magnetische variatie ophoest.

Twist schreef :
de fix is op 3 meter nauwkeurig. In het ergste geval heb je dan tussen twee posities 6 meter verschil. Je vaart gemiddeld 4 m/s. Om een redelijke koers te bepalen heb je dan toch wel 20 - 30 seconden nodig. Met een filter van 30 seconden is de gps COG zo strak als een huis.

3Noreen schreef :
Je kan wellicht een ramdisk maken om een 10Hz log bestandje naar weg te schrijven. Daarna op het gemakje van de RPi kopieren naar iets minder volatiels.

Overigens heb ik nog geen problemen gehad met 10Hz logging.

Twist schreef :
Geen idee waarom dat bij mij verkeerd gaat.
Mogelijk door brakke manier van programmeren ik lees in C de seriële poort uit met een select() system call misschien doe ik daar iets fout.
Of zit het in dat hier dat ding 3 maanden non stop staat te loggen en wordt het kaartje daar ziek van. Wie zal het zeggen ?
Verder vind ik het leuk om stil liggend wat met het ding te pielen. Maar tijdens het zeilen ben ik toch primair met andere zaken bezig. Het vraagt ook het nodige om op zee achter het schermpje te zitten programmeren terwijl je flink op en neer geschut wordt.

O, ik dacht dat je data sneller binnenkwam dan 1 Hz. Met 1Hz gaat het niet goed lukken die golfperiode te bemonsteren dus ook niet de periode af te leiden uit de data.

Gek, bij mij gaat het wegschrijven goed tot 20 Hz, maar dan loop ik tegen de latency van de system-clock call aan (of hoe dat ook heet).

Ik verwacht dat het in C++ beter zou moeten gaan dan met compiled Free Pascal, maar ben niet thuis in dat soort dingen. Ik hobby/probeer ook maar wat...

Nachtvlinder schreef :
Jou data zijn dan toch bruikbaar om te laten zien hou je daar een basis frequentie uit kunt analyseren? Dat zou me wel in de goede richting kunnen zetten.

De golffrequentie bepalen kan als volgt.
1 neem de ruwe input en low pass deze met een ruime demping. Dit geeft een "gemiddelde" snelheid.
2 trek de gemiddelde snelheid van de actuele snelheid af. Je weet nu hoeveel sneller of langzamer dan gemiddeld je gaat.
3 als de afwijking van teken verandert (bv van sneller naar langzamer) start je een timer.
4 de waarde van de oude timer geeft op dat moment de tijd voor helft van de golflengte.
5 deze tijd vermenigvuldig je met 2.
6 low pass de berekende golflengte om de variatie te verminderen.

Als je het op deze manier aanpakt is er geen noodzaak om oude metingen in een array op te slaan. Je kan toe met 6 variabelen. Ik heb deze manier ooit met speelgoed robotjes gebruikt om de frequentie van een knipperlicht te bepalen. Dat ging zonder moeite, de huidige hobby boardjes zijn vele maken krachtiger dan die speelgoed robot. Zie nxttime.wordpress.com/?s=Beacon&submit=Search

Eigenlijk toont dit het gebrek aan van een smartsensor, een dood gewone GPS heeft smoothing mogelijkheden om dit euvel op te lossen.

Positie smoothing een normale waarde 2 sec
snelheid smoothing een normale waarde voor de scheepslengte 3 sec
en als er nog wat luxe ingebouwd zit een gemiddelde snelheid om mee te rekenen van een 10 sec.

Dat oude GPS had dat kennelijk keurig in zich.

Smoothing is meestal niets anders dan een eerste-orde filtering en werkt in de praktijk. Voorwaarde is wel dat deze demping gebeurt voordat de data gesampeld wordt. Dit lijkt in 3Noreen's case niet het geval.

De vraag is dan wat je achteraf nog kunt doen. Niet zoveel in dit geval, ben ik bang. Tenzij de sampling frequentie >2x hoger is dan de hoogste frequenties in het oorspronkelijke signaal. Als je met 5 Hz ofzo sampled kun je nog alle kanten op, onafhankelijk of er netjes een pre-sampling filtering is geweest of niet.

Kun je echt niets instellen in je nieuwe GPS? Dus dat de sensor de filtering al doet of (als alternatief), een snellere output en zodat jij die filtering kunt doen?

Leuk dat er nog zoveel mensen meedenken. Dat geeft een hoop extra inzicht.
De methodiek die Aswin voorstelt lijkt me goed haalbaar.
Door opmerking van Henk ga ik me afvragen hoe lang de gemiddelde golf periode is. Mijn aanname was dat wind golven een periode van ±10sec hadden en swel ±30 sec. Met een verschil als je er tegen in vaart of mee. Maar Henk heeft het over 2 - 3 sec.

De gps is wel 10 Hz maar mijn opgeslagen log om achteraf te kunnen analyseren is dat niet. De log data zijn low-pass gefilterd en in lagere frequentie opgeslagen. Vandaar de hoop dat één van de twee posters die wel een 10Hz bestand hebben die analyseren om er achter te komen in welke orde van frequentie er gedacht moet worden.