Sida 4 av 6
Re: Lågpassfilter i mjukvara!
Postat: 13 april 2011, 22:34:43
av Borgen
Varför måste likspänningsförstärkningen vara ett? Varför inte t.ex. 0,5? Ni som hävdar att Gdc måste vara ett får gärna komma med argument.
Det intressanta med ett LP-filter är att högre frekvenser ska dämpas mer än låga frekvenser, filtrets brytfrekvens samt ordning (antal brytpunkter). Ibland är det även intressant vilken typ av filter man väljer Tjebysjov- (olika stavningar förekommer), Buttervorthfilter eller annan typ då deras kurvformer skiljer sig åt.
Inte ovanligt att man vill ha både ett LP-filter och en förstärkning och det förekommer att man kan kombinera de båda till ett LP-filter vars likspänningsförstärkning är skilt från ett.
Om filtrets överföringsfunktion inte konvergerar kan man flytta ut förstärkningen eller lägga in en förstärkning till filtret så man får ett stabilt filter.
Re: Lågpassfilter i mjukvara!
Postat: 13 april 2011, 22:46:12
av Borgen
ahlsten skrev:Som en parentes följer en enkel räkneövning...
Vid konstant insignal efter oändlig tid så gäller: y[n] = y[n-1]
Den statiska förstärkningen, ofta benämnd G_0, fås då av:
y[n] = 0.99*y[n] + 0.009*x[n] =>
(1-0.99)*y[n] = 0.009*x[n] =>
y[n] = 0.009/(1-0.99)*x[n] = 0.9*x[n] =>
G_0 = 0.9
(Hoppas nu bara att ingen missförstår termen 0.009/(1-0.99)*x[n] ...)
Ja, den är enkel och fungerar bara på filter som konvergerar. (Om jag minns rätt.) Annars måste man nyttja andra beräkningsmetoder. Högre ordningens filter kan vara svåra att avgöra med din analys, de brukar kräva att man tittar på Z-transformens poler eller i det kontinuerliga fallet Laplacetransformens dito. Vill minnas att det finns generella test man kan nyttja i stället, de kan man finna i bra reglersystemböcker.
Konvergerar - går mot ett fixt ändligt värde. Motsatsen är att filtret divigerar.
Re: Lågpassfilter i mjukvara!
Postat: 13 april 2011, 23:33:25
av Andax
Ett annat problem med rekursiva filter är att fasen ofta är ganska olinjär, som funktion av frekvensen.
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 08:44:55
av Nerre
Borgen skrev:Varför måste likspänningsförstärkningen vara ett? Varför inte t.ex. 0,5? Ni som hävdar att Gdc måste vara ett får gärna komma med argument.
Enkelt: Lågpass = släpper igenom låga frekvenser. DC är den lägsta frekvensen, den skall alltså komma igenom opåverkad.
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 09:44:37
av snigelen
Så de flesta OP-baserade lågpassfilter (som inte har förstärkningen ett) är inte lågpassfilter?
Är detta LP?
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 13:59:47
av Nerre
Nej, tar du bort R2 blir det ett lågpassfilter. Annars är det en frekvensberoende spänningsdelare:)
Jag menar, tänk dig att du köper ett lågpassfilter till din subwoofer. Så kopplar du in det och krämar på och det hörs nästan ingen bas alls från subwoofern... Då visar det sig att filtret har en DC-förstärkning på 0,01...
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 14:03:09
av ahlsten
Ett lågpassfilter och en attenuator? Lågpassfilter syftar till en funktion, ett idealiskt lågpassfilter, inte en samling komponenter som "sänker högre frekvenser mer än låga"... när sedan implementationen inte kan ge samma beteende som ett idealiskt tänkt filter så får man beskriva hur det skiljer sig, att nämna att det är av första ordningen antyder exempelvis att dämpningen ökar med 6dB för varje fördubbling av frekvensen över brytfrekvensen.
Borgen: Ja, det var bara för att visa varför förstärkningen blev 0,9 för det aktuella lågpassfiltret...
Ett lågpassfilter som inte konvergerar för DC är väl inget lågpassfilter? Det är en integrator...
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 15:24:37
av snigelen
Så
detta är inte heller ett lågpassfilter? De säger "Another type of electrical circuit is an active low-pass filter." och en stund senare "the gain in the passband is −R2/R1, and the stopband drops off at −6 dB per octave as it is a first-order filter.". Blir det bara lågpassfilter då R1 är lika med minus R2?
Motsvarande för "mitt" filter så kan man väl säga:
Förstärkningen i passbandet är R2/(R1+R2) och i stoppbandet avtar den med 6 dB per oktav.
Men, men. Jag är väl ute och cyklar som vanligt (men det lär ju vara bra motion i alla fall

)
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 15:48:38
av ahlsten
Låter väl alldeles utmärkt?

Poängen jag personligen hade var att ett idealiskt filter har passbandsförstärkning 1 och oändlig attenuation för spärrband. Skiljer det sig på grund av implementation så anger man det och om det beror på ett medvetet val och inte en implementationsbegränsning så kan man gott ange varför.
Jag skrev:när sedan implementationen inte kan ge samma beteende som ett idealiskt tänkt filter så får man beskriva hur det skiljer sig
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 18:21:35
av mounte
ahlsten skrev:Som en parentes följer en enkel räkneövning...
Vid konstant insignal efter oändlig tid så gäller: y[n] = y[n-1]
Den statiska förstärkningen, ofta benämnd G_0, fås då av:
y[n] = 0.99*y[n] + 0.009*x[n] =>
(1-0.99)*y[n] = 0.009*x[n] =>
y[n] = 0.009/(1-0.99)*x[n] = 0.9*x[n] =>
G_0 = 0.9
(Hoppas nu bara att ingen missförstår termen 0.009/(1-0.99)*x[n] ...)
Kanske dags att slänga in laplace-transformen...
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 19:57:22
av ahlsten
For teh lulz?
y(n) = a*y(n-1) + b*x
y(n) - a*y(n-1) = b*x
(1-a)*y(n) + a*(y(n) - y(n-1)) = b*x => {dy/dt = y(n) - y(n-1)} =>
(1-a)*y + a*y' = b*x
Y(s) * (1 - a + a*s) = b*X(s)
Y(s)/X(s) = b/(1 - a + a*s) = G(s)
G(0) = b/(1-a) = 0.009/(1-0.99) = 0.9
Fast det hela implementeras visserligen i diskreta tidssteg, så ...
y(n) = a*y(n-1) + b*x
y(n) - a*y(n-1) = b*x
Y(z)*(1 - a*z^(-1)) = b*X(z)
Y(z)/X(z) = b/(1-a*z^(-1)) = G(z)
G(1) = b/(1-a) = 0.009/(1-0.99) = 0.9
Hur man än räknar så verkar det bli samma?

Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 20:28:19
av Borgen
mounte skrev:Kanske dags att slänga in laplace-transformen...
Laplacetransformen är för tidskontinuerliga filter
Z-transformen är för tidsdiskreta filter
Då det rör sig om ett filter i mjukvara för en kontroller och vi arbetar med samplade värden använder vi Z-transformen. Har tyvärr inte tid att skriva lösningen med Z-transformen inatt. Kanske kommer senare
Edit
Missade att ahlsten hade räknat ut det. Vi kan även se att filtret 0.009z/(z-0.99) har polen inom enhetscirkeln och är därmed även stabilt.
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 20:31:24
av snigelen
Snyggt! Jag tänke just att z-transform vore lämpligare i diskret tid. Men att det blir same shit visade du ju kort och elegant.
Edit: det var ahlstens inlägg jag svarade på.
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 20:46:25
av Borgen
Ideala filter.... *suck* I sak är det rätt att ett idealt filter ska ha bandpassförstärkningen ett och förstärkningen vid gränsfrekvenserna ska ha oändlig derivata vilket praktiskt är omöjligt att konstruera. Försök bara få till oändlig derivata på utsignalen från en opamp med ett unitstep som insignal.... Det går inte ens att få till ett unitstep som matematiskt är korrekt.
Det är inte många praktiska filter som har bandpassförstärkningen ett. Tillverkningsprocesserna för de ingående komponenterna ger sådan onogrannhet och variation att det inte är praktiskt möjligt att konstruera ett filter med banpassförstärkningen ett. Men man kan komma mycket nära.
Om man har ett LP-filter med DC-förstärkningen 0.63 anger man det som "ett LP-filter med förstärkningen 0.63". Att sedan påstå att det inte är ett LP-filter får i alla fall mig att fundera på vem jag pratar med. Säger man att det är ett LP-filter så utgår man från att de högre frekvenserna dämpas mer än de lägre. Vilken dämpning/förstärkning som filtret har får man ta reda på genom att läsa i pappret, räkna på, simulera, mäta, fråga om.....
Re: Lågpassfilter i mjukvara!
Postat: 14 april 2011, 20:49:25
av ahlsten
snigelen: Mmm, det jag utgår ifrån tar visserligen inte hänsyn till tiden mellan y(n) och y(n-1)... den kan vara oändligt kort eller sampletid T. Tidskonstanten (och pol) blir beroende av detta... men efter oändlig tid ser jag inte nån skillnad.