Vill hälla sirap bland hysteriska siffror, ”skapa medelvärde

[Fagge]

Jag sitter å leker med en barometrisk höjdmätare modul ifrån http://www.hexpertsystems.com/zlog/ (Z6M)
Målet är att bygga en variometer, som har tilluppgift att mäta vertikal stig & sjunk hastighet inom flyget.

Ur den här Z6M modulen, får jag ut höjd siffrorna i Feet, 8ggr / sek. Dessa Omvandlar jag senare till Meter för höjden & m/s för variometern.

Nedan:
Ett slumpmässigt urval av hur värdena kan se ut när modulen ligger stilla på bordet.
Anledningen till att talen nedan är negativa är tack vare rådande högtryck. Men se talet som positivt, minustecknet är bara en symbol i detta sammanhanget.
-271
-272
-271
-265
-267
-267
-267
-264

-266
-269
-270
-269
-267
-268
-270
-270
.
Som synes så spretar siffrorna iväg lite gran, fram & tillbaka hela tiden.
Variationen är så pass liten att det duger gått & väl för att visa en stabil höjd i meter utandecimaler.
Men när man ska få fram variometer datat då blir det genast mycket hysteriskare, Då även Decimalen är viktig.
T.e.x 1,5m/s

Variometer= Föregående höjd mätning – Senaste höjd mätning.
Då får man fram skillnaden. Ex. Det blir ett ständigt pendlande flera Feet upp & ner hela tiden med ovanstående siffror, vilket det förstås inte är eftersom modulen ligger stilla.

Önskemålet är att uppdatera displayen 1ggr/sek, & då försöka skapa ett så stabilt medelvärde som möjligt utav dessa 8 samples som jag får varje sek.
Men det är ok att uppdatera vart annan sek också, som så skulle behövas... Vilket man då får 16 samples att leka med.

Filtrerings metoden jag har testat med är:
.Att lägga alla 8 mätningarna i varsin hög.
Sedan plocka bort det högsta & det lägsta talet, så att 6st återstår.
Därefter adderat ihop alla 6 mätningar, för att sedan dividerat resultatet med 6, för att skapa ett medelvärde.

Men nej det det blir fortfarande ett irriterat upp & ner pendlande på displayen, dock mycket bättre än att köra med ren rå data.
Så kom igen nu forumets mattesnillen, har ni någon smidig sirap lösning för ovanstående problem.?
/Fagge

[Icecap]

Jag har använd det digitala lågpassfilter som någon skrev om tidigare, det fungerar perfekt för mitt ändamål och jag ser inte varför det inte skulle fungera till detta heller. http://elektronikforumet.com/forum/view ... =7&t=50406

En annan lösning är att ha ett konstant flytande medelvärde, t.ex. spara de senaste 8 värden och räkna genomsnitt på dom. Varje gång det kommer en ny mätning kastas den äldsta och ett nytt medelvärde räknas ut. Sköts enkelt med en cirkulär buffer och en in-pekare.

[zealotry]

Prova ett enkelt digitalt lågpassfilter, finns pseudokod här: http://en.wikipedia.org/wiki/Low-pass_f ... ss_filters

[psynoise]

Det är någon typ av uppskattning du vill göra av det egentliga värdet. Vi kan anta att fördelningen på mätvärdena uppkommer från mätfel. Vad som är bäst kan man säkert läsa sig till och sedan beräkna. Se t.ex Maximum likelihood och massa annat om du är intresserad av statistik.

Eftersom jag inte tror att du vill djupdyka i statistikstudier hade jag satsat på Icecaps föreslag om flytande medelvärde (medelvärde genom ett tidsfönster hade jag sagt). Ska man hitta på andra konstigheter som att ta bort lägsta eller högsta medelvärde borde man nog läsa på mer hur man brukar göra uppskattningar.

[Andax]

Skattningsonoggrannheten är proportionell mot 1/sqrt(N) där N är antal sample som du medelvärdesbildar. Om man räknar standardavvikelsen på något så är noggrannheten i den skattningen beroende på 1) hur mycket varierar det man faktiskt vill mäta (t.ex. lufttrycket) från sample till sample, 2) Beroende på hur många sample man medelvärdesbildar.

Så varje varje fördubbling av antal sample minskar osäkerheten i skattningen med en faktor 1/sqrt(2), dvs 0.7.

När du räknar ut ett glidande medelvärde så är den absolut smidigaste metoden, precis som Icecap mflr skrivit att ha en ringbuffer. Men se till att ha en variabel som innehåller summan av de värden som ligger i ringbuffern. Varje gång man tar bort ett element så minskar man denna variabel med det värdet och när man lägger till ett element så ökar man variabeln med detta värdet. Då är meddelvärdet alltid variabeln/N där N är antal värden i ringbuffern. Väljs N som en 2-potens blir det mycket enkel att dividera fram medelvärdet (bara ett skift).
Fördelen med denna metod är att det tar lika lång tid att beräkna ett glidande medelvärde för ett 1024 sample långt medelvärde som för ett 8 sample långt.

[Icecap]

Kan hålla med Andax men man måste även tänka på hur lång "tid" som ligger i buffern, blir den för stor kommer den utläsning man faktisk vill ha att släpa efter alldeles för mycket. Men i stor får man testa sig fram.

[jesse]

Det var jag som skrev om mjukvarufiltret här.

Kod: Markera allt

//  Update filter with current sample.  
filter_reg =  filter_reg  -   ( filter_reg >> FILTER_SHIFT)  +  filter_input ;

//  Scale output   for  unity  gain.  
output  =  filter_reg >> FILTER_SHIFT

Det går även enkelt att göra i t.ex. Open Office Calc:

cellerna A1 - An = inkommande värden
cellerna B1 - Bn = (B(n-1)*7+An)/8
cell B0 = startvärde.

[Nerre]

Ja det är ju knappast svårt att skriva ihop ett litet program som räknar medelvärde över olika stort antal värden.

Jag skulle nog börja på tre värden och sen gå uppåt.

Men sen är frågan om man verkligen ska räkna ut hastigheten baserat på bara två "filtrerade" värden... De handlar ju om att räkna ut en derivata i princip.

[jesse]

...

[Glattnos]

Det Andax skrev ska jag ta med mig i min framtida nutid Jag fick lite funderingar också, lite som föregående skribenter redan skrivit men jag skriver ändå.

Om man tex. har 32 st 8-bitarstal i buffern så blir det ju 4 sekunder(8 st/sek) i buffern. Variabeln blir 13-bitar och delar man det med 32(5 st shift) så har man medelvärdet(8 bitar) de senaste 4 sekunderna och den går att få 8 gånger i sekunden. Då är det bara att testa hur ofta man ska uppdatera för att det ska passa. Sen kan ju i och för sig värdet variera för mycket ändå men det varierar ju mindre desto längre tid man har i buffern.
Beroende på vilken upplösning man vill ha så kan man ju välja att bara ta hänsyn till vertikal förflyttning på tex över 0,3 m/sek, så struntar man i förändringar som är mindre än 0,3 m/sek. Blir den vertikala rörelsen över 0,3 m/sek så kan man ju använda en upplösning på tex 0,1 m/sek(eller full upplösning). Då håller variometern sig lugn vid planflykt men ger ett exaktare värde vid stigning eller inflygning(plan'e eller vad det heter ). Vid planflykt är det ju höjdmätaren man går efter för att hålla konstant höjd och inte variometern.

Hoppas att jag tänkte rätt nu

[bearing]

Jag tycker att jesses filter är fantastiskt elegant, eftersom att det inte kräver någon buffert, men ändå ger så pass bra resultat.

Hur var det nu, tidskonstanten blir större än filterkonstanten?
Så var det, enligt tabell 1.
http://ece124web.groups.et.byu.net/refe ... Filter.pdf

I det här fallet (division 16 / skift 4 steg) är tidskonstanten 34. Med skift 3 steg blir tidskonstanten 16. Shift 3 steg kanske är lämplig i detta fallet, eftersom att önskemålet var max 2 sekunders responstid. Å andra sidan går skift 4 steg snabbt att göra i en PIC med SWAP och AND.

Fast, nu ser jag att stigtiden i tabell 1 var beräknat på amplitudändringen 10% - 90%. Med en traditionell definition av stigtiden (0-63%) blir den väl just 16 om skift 4 används?

Hur var det med förstärkningen? minns att det var diskussioner huruvida förstärkningen var 1 eller inte.

[Andax]

Ett ringbuffer filter faller under kategorin FIR (Finite Impulse Response) medan Jesses är ett sk IIR (Infinite Impulse Response). Fördelen med ett IIR-filter är att man kan göra det mycket kort och effektivt. Nackdelen är att man får en olinjär fas på resultatet samt att effekten av en outlier (felaktigt värde) lever kvar länge, och att filtret kan börja självsvänga av numeriska problem. FIR filter kan gå att göras med linjär fas, är per definition stabila och en outlier påverkar bara under så många sample som filtrets längd. Med en generell filterkärna är FIR oftast mer beräkningstungt om man inte kan utnyttja t.ex. att man kan skriva om det och utnyttja ringbuffrar etc på ett smart sätt som ovan.

[jesse]

Om du kan öka sampelhastigheten till det dubbla så halverar du tidskonstanten med bevarad filtereffekt.

[Nerre]

Som jag tolkar honom kan han inte styra hur ofta modulen skickar data, det kommer 8 gånger per sekund. Det går alltså inte att öka samlingsfrekvensen.

[Glattnos]

Eftersom det är en variometer som han vill göra tycker jag hittills bäst om mitt förslag Vilket inte innebär att jag inte är fascinerad av de övriga förslagen i tråden. Massor av smarta lösningar på just medelvärdes-bildningen! Men Fagge ville ju(bland annat) få bort "hoppandet" uppåt och neråt när ingen vertikal förflyttning skedde.

Fagge: Är det inte lämpligt att hoppa över variationer som är mindre än en viss stig-/sjunk-hastighet?
Jag vet inte hur din variometer ska användas men jag har i alla fall "viss" erfarenhet av flyg och om jag inte är helt ute och cyklar så är variometern inte så intressant förutom just när man stiger eller sjunker, och då har man kanske lite mer än tex 0,3 m/sek(eller vad man nu väljer som gräns) vertikal förflyttning, 1-4 m/sek är väll inte ovanlig stighastighet för många flygfarkoster. Liknande sjunk, iofs kanske sjunk ner till 0,5 m/sek är av intresse ibland. Men men, just vid planflykt(konstant höjd) så låter man väll inte variometern vara referens för höjden, utan höjdmätaren?

Ditt medelvärde som du får fram(genom något av föregående förslag) är ju höjden, så höjdmätare får du ju ändå samtidigt.