Hallo zusammen, ich steh gerade echt auf dem Schlauch bei dem Versuch die CIC Filter richtig zu verstehen. Hab dazu "Von Hand" ein Dezimationsfilter in Matlab geschrieben. Das funktioniert auch prinzipiell solange, bis es zu einem Überlauf kommt. Die 3. Integrator Stufe springt von +(großer Wert) zu -(2^Bitbreite+Überlaufdifferenz), genau so wie er es soll. Nur bei den Comb Filter kommt es dann zum Problem, was meines erachtens auch logisch ist. Bei den Comb Stufen wird ja der aktuelle Wert mit dem letzten Wert subtrahiert und dabei kommt zum Zeitpunkt des Überlaufes eine Zahl heraus, die kleiner als meine Bitbreite ist. Ich hab das Gefühl da stimmt was nicht :) Anbei noch die Matlab Plots der jeweiligen Stufen. Ab Sample ~700 kommt es in der 3. Integrationsstufe zum ersten Überlauf. Da das Ganze mit R=8 läuft, tritt der Fehler bei Sample ~80 in der 1. Comb Stufe auf.
Soweit ich mich erinnere, müssen die Integrationsstufen so weit gefasst sein, dass sie nicht überlaufen. Es gibt aber einen Trick, bei dem das Differenzbilden unter bestimmten Randbedingungen auch dann funktioniert, weil der Unterlauf in binären Zahlen auf dieselbe Differenz hinaus läuft. Mach mal den Integrator 3 groß genug und schaue, ob die Rechnung als solche stimmt und was bei der ersten Differenzbildung heraus kommt und bei der, wei welcher der Überlauf in der limitierten Version erfolgt. Eventuell sieht man da wie man es machen muss. Ich glaube, es kommt auf den größer-kleiner-Vergleich an, bei dem noch 2n-1 addiert werden müssen.
Der Tipp war genau richtig, vielen Dank! Meine Behandlung bei einem wrap around von -2^n ins positive ist falsch. Ich war zu geizig für den Fixed Point Designer und hab das Ganze in int32 implementiert… Beispiel mit n = 5 -> Wertebereich geht also von -16 bis +15: Vom Wert 12 wird +6 addiert, das gibt -14. -14 - 12 = -26, das Ganze muss jetzt mit 2^n addiert werden: -26 + 32 = 6. Passt, so müsste es gehen. Melde mich nochmal wenn es läuft. So wie ich es übrigens verstanden habe ist EIN Überlauf bei den Integrationsstufen innerhalb von 2 downsampling Abtastungen erlaubt. Es geht ja darum, dass die Differenzinformation nicht verloren geht. Bei 2 oder mehr Überläufen während 2 Abtastungen geht die Info flöten, also müssen die Integrationsstufen so breit sein, dass das nicht passiert.
:
Bearbeitet durch User
Uwe schrieb: > Bei 2 > oder mehr Überläufen während 2 Abtastungen geht die Info flöten, also > müssen die Integrationsstufen so breit sein, dass das nicht passiert. Das klingt mir aber unsicher. Würde bedeuten, dass die Funktionssicherheit von dem Verhältnis der Abtastfrequenzen links und rechts vom Kammfilter abhinge. Sollte sich das (nicht) ausrechnen lassen? 1) 3-fach-Dezimierung um Faktor 64 -> 4*4*4 -> 2 Bit mehr beim Akumulieren -> 1 Bit mehr benötigt. 2) 2-fach-Dezimierung um Faktor 256 -> 16*16 -> 4 Bit mehr beim Akumulieren -> 3 Bit mehr benötigt. Stimmt das? Oder doch besser sicherheitshalber groß und breit genug bauen?
Andreas F. schrieb: > Würde bedeuten, dass die > Funktionssicherheit von dem Verhältnis der Abtastfrequenzen links und > rechts vom Kammfilter abhinge. Jein, die Registerbitbreite ist abhängig von der Eingangsbitbreite + Stages * log2(R). Das heißt umso größer R ist, desto länger wird zwischen 2 Abtastungen aufintegriert, und umso breiter müssen die Register sein. Was ich jetzt aber zusätzlich nicht verstehe ist, dass die Bitbreite von einer Integrationsstufe zur nächsten eigentlich immer mehr anwachsen müsste. In der Literatur und in irgendwelchen Tutorials findet man immer nur folgendes Bildchen: https://s3.amazonaws.com/embeddedrelated/user/14446/CIC_digital_filters_fig12.png Hier sind alle Integrationsstufen 21 Bit breit. Wenn ich jetzt aber in der 2. Stufe schon an der oberen Grenze bin, dann kommt es bei der 3. Stufe logischerweise nach jedem Sample zum Überlauf...? Das Überlauf bzw. Unterlauf Problem in den Comb Stufen hab ich jetzt tatsächlich hinbekommen. Der oben beschriebene Ansatz war korrekt.
Uwe schrieb: > dass die Bitbreite von einer Integrationsstufe zur nächsten > eigentlich immer mehr anwachsen müsste. Ja sicher, dem ist so. Mehr noch, es kommt irgendwann automatisch zu einem Überlauf. Der ist nur so spät, dass er bei der Differenzbildung nicht mehr relevant ist, weil pro Dezimationsstufe immer nur ein Underrun / Overrun auftreten kann, der kompensiert wird. Nimm ein Beispiel: Ein Sinus ab 0 Grad liefert erst nur Positive, dann gleich viele negative Anteile. Das Integral daüber ist immer Positiv, bildet einen Hügel und kommt wieder auf 0. Das 2. Integral wächst stufenförmig an. Das dritte wächst linear beschleunigt über alle Grenzen.
Uwe schrieb: > Hier sind alle Integrationsstufen 21 Bit breit. Wenn ich jetzt aber in > der 2. Stufe schon an der oberen Grenze bin, dann kommt es bei der 3. > Stufe logischerweise nach jedem Sample zum Überlauf...? Das darf nicht passieren. Nur der letzte darf überlaufen, oder man behandelt den Überlauf. Das gilt auch für die anderen genannten Fälle des Unterlaufs, oder dann wenn man nicht einen binären Faktor nutzt. Dann aber steigt sofort der Aufwand.
Uwe schrieb: > Hier sind alle Integrationsstufen 21 Bit breit. Wenn ich jetzt aber in > der 2. Stufe schon an der oberen Grenze bin, dann kommt es bei der 3. > Stufe logischerweise nach jedem Sample zum Überlauf...? Nach meiner Erinnerung war es so, dass die immer überlaufen, das aber keine Relevanz besitzt, weil es digitale Zahlen sind , bei denen der Unterlauf während der Rechnung zum gleichen Ergebnis führt.
Wenn der Überlauf vor der Integration in der Folgestufe erfolgt, gibt das sehr wohl ein Problem. Und die Nutzung der Ambivalenz der Werte im Binärsystem hinsichtlich des Unterlaufs funktoniert nur bei CIC-Filtern, die auch mit Binärzahlen arbeiten. Mit einem Dezimator von z.B. 128 auf 125 geht das nicht, weil die Stufen nur bis Vielfach von 5 zählen, also z.B. 25 statt 32 und es kein automatisches Modulo gibt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.