Für die Dezimation eines AD-Wandlers (8Bit) wird ein CIC2 vorgeschlagen. Ich möchte den selber schreiben, statt was zurecht zu frickeln und weis auch noch wie das ungefähr ging. Allerdings habe ich eine kleine Erinnerungslücke: Muss man bei den Integratoren auch mit einem Dezimationsfaktor abtasten, oder kann ich die Durchlaufen lassen? Ich rechne momentan mit jedem neuen Wert (Valid = 1) Folgendes: Wert1 := Wert1 + Input; Wert2 := Wert2 + Wert1; Dann gibt es zwei Counter, die jeweils bis 31 zählen und die aktuellen Werte merken, die Differenzen bilden und weiterpuschen. Es wird also mit 32x32 dezimiert. Macht es einen Unterschied, ob man das eingangsseitig noch abtastet? Wie verhält sich das dann mit den Überläufen? Der anschlossene Wandler kommt mit 8 Bit. Wie müsste man das gestalten, damit es mit den automatischen Überläufen klappt?
Franki schrieb: > Für die Dezimation eines AD-Wandlers (8Bit) Und warum soll der bestraft werden? https://de.wikipedia.org/wiki/Dezimation
Harald W. schrieb: > Franki schrieb: > >> Für die Dezimation eines AD-Wandlers (8Bit) > > Und warum soll der bestraft werden? > https://de.wikipedia.org/wiki/Dezimation "Dreistöckiger Hausbesitzer". Dezimiert wird hoffentlich nicht der AD-Wandler, sondern der Datenstrom, den liefert. Und strenggenommen wird er auch nicht dezimiert, sondern reduziert...
Moin, Franki schrieb: > Ich möchte den selber schreiben, statt was zurecht zu frickeln Was ist da der Unterschied? > Muss man bei den Integratoren auch mit einem Dezimationsfaktor abtasten, > oder kann ich die Durchlaufen lassen? Die Dezimation oder auch die Interpolation erfolgt immer zwischen dem Haufen Integratoren und dem Haufen Differenzierer. Also laeuft der eine Haufen mit dem Eingangstakt, der andere Haufen mit dem Ausgangstakt. Dazwischen passiert "die Magie" der Samplerateveraenderung. Gruss WK
Harald W. schrieb: > Franki schrieb: >> Für die Dezimation eines AD-Wandlers (8Bit) > Und warum soll der bestraft werden? > https://de.wikipedia.org/wiki/Dezimation Sehr lustig Grummler schrieb: > Dezimiert wird hoffentlich nicht der AD-Wandler, sondern > der Datenstrom, den liefert. Doch, ich möchte den Datenstrom unbehandelt lassen und nur dem Wandler eins aufs Dach geben. Mann, sind das hier dämliche Antworten
Dergute W. schrieb: > Die Dezimation oder auch die Interpolation erfolgt immer zwischen dem > Haufen Integratoren und dem Haufen Differenzierer. > Also laeuft der eine Haufen mit dem Eingangstakt, der andere Haufen mit > dem Ausgangstakt Das mit den Takten ist in Software ja virtuell: In den beiden angedachten Versionen (getaktetes und ungetaktetes Integrieren) wäre so oder immer ein update der Struktur mit dem Eingangssignal präsent. Dergute W. schrieb: > Dazwischen passiert "die Magie" der > Samplerateveraenderung. Das muss ich ja schon irgendwie machen und tut nicht von alleine. Dass ich am Ausgang, also des zweiten Differenzieres mit der dann geringeren Rate auslese, ist schon klar. Nur damit das Differenzieren richtig funktioniert, muss ja immer auch mit einem Bruchteil des Taktes - JE STUFE - abgetastet werden. Es sind ja 2 Stufen und die zweite läuft mit 1/N langsamer, also mit 1/(N*N). Ich entnehme aber deiner Antwort, dass die Integratoren vorne nicht getaktet werden sondern mit jedem neuen Wert aufintegrieren (?)
Moin, Wie ich schon schrub: Beim normalen CIC gibts genau 1, i.w. eine Stelle, an der sich der Takt aendert, eben zwischen dem Haufen mit den Integrierern und dem Haufen mit den Differenzierern. Nicht zwischen Differenzierern und nicht zwischen Integrierern. Gruss WK
chris_ schrieb: > Beitrag "CIC-Filter für Halbierung der Abtastrate" das war der erste thread, den ich beim suchen gefunden hatte, aber dort steht auch nichts konkretes zur implementierung.
Dergute W. schrieb: > Wie ich schon schrub: Beim normalen CIC gibts genau 1, i.w. eine Stelle, > an der sich der Takt aendert Wenn aber doch die Differenzierer mit sagen wir dem halben Takt betrieben werden, dann taktet die erste Stufe mit 1/2 und die zweite effektiv mit 1/4, oder?
Moin, Ist jetzt nicht gross getestet, aber so ungefaehr koennte ein CIC 2. Kajuete mit 32facher dezimation ausschauen:
1 | #include <stdio.h> |
2 | |
3 | #define N (32)
|
4 | void output(int o) { |
5 | printf("%d\n",o); |
6 | }
|
7 | |
8 | void cic(int input) { |
9 | static int deccount; |
10 | static int integral1, integral2; |
11 | static int diff1, old1; |
12 | static int diff2, old2; |
13 | integral1 += input; |
14 | integral2 += integral1; |
15 | if (++deccount >= N) { |
16 | deccount = 0; |
17 | diff1 = integral2 - old2; |
18 | diff2 = diff1 - old1; |
19 | old2 = integral2; |
20 | old1 = diff1; |
21 | output(diff2); |
22 | }
|
23 | }
|
24 | |
25 | int main() { |
26 | int i; |
27 | int input; |
28 | for (i=0;i<1000;i++) { |
29 | input = 0; |
30 | if ((i>=0) && (i<256)) input = 1; |
31 | cic(input); |
32 | }
|
33 | }
|
Die Integrierer laufen mit jedem Aufruf der cic() funktion, die Differenzierer und die Ausgangssampleweiterverarbeitung eben nur bei jedem Nten. Gruss WK
Ja, so dachte ich das auch, nur hatte ich irgendwie ein Problem mit vorzustellen, wie sich die Differenzen verhalten. Ich dachte eigentlich immer, dass sich der Dezimationsfaktor in jeder Stufe abbildet.
Wäre es für einen Unwissenden aber Interessieren möglich dass ihr erklärt worum es hier geht? Ich kenne Filter grob nur als Signalfilter mit dem Verständnis dass je nach Auslegung unterschiedliche Frequenzen unterschiedlich gedämpft werden können. Wo erkenne ich hier das Filter? Was soll warum Dezimiert werden?
Moin, Nein - doch - ohhhh: https://de.wikipedia.org/wiki/Cascaded-Integrator-Comb-Filter https://www.dsprelated.com/showarticle/1337.php Gruss WK
N00b schrieb: > Wo erkenne ich hier das Filter? Das Filter besteht in der Aufaddition von Werten mit einer langsameren Abtastung. Einstufig betrachtet wäre das z.B. eine Summe über 10 Werte mit Abtastung 1/10. > Was soll warum Dezimiert werden? Um aus einem Wandler mehr rauszuholen. Der liefert sehr schnell wenige Bits und der Filter liefert dann langsamer mehr Bits. Hier eine Temperatur.
@Franki Heiß dies dann also beispielsweise konkret: * Der ADC liefert einen mit x1 Bit aufgelösten Wert alle y1 Sekunden * mit Filter erhält man einen mit x2 aufgelösten Wert alle y2 Sekunden * dabei dann x2 > x1 auf Kosten von y2 > y1 * also Genauigkeit auf Kosten von Zeit ?
N00b schrieb: > * also Genauigkeit auf Kosten von Zeit ... wenn man das so darstellen möchte, ja. Ich brauche ja keine Temperaturwerte mit 10kHz. Ein Bruchteil reicht. Ich hab das Filter jetzt nebenbei erwähnt, am Laufen. Was ich noch nicht durch habe, ist das richtige Dimensionieren der Integer-Rundung und des Überlaufs. Bei manchen Konstelleationen gibt es komische Werte und die (automatische ?) Berichtigung der Werte durch die Differenzierer scheint nicht richtig zu arbeiten.
N00b schrieb: > Wäre es für einen Unwissenden aber Interessieren möglich dass ihr > erklärt worum es hier geht? Im Prinzip geht es um einen gleitenden Mittelwert. Der gleicht das Wackeln der einzelnen Input-Werte aus und liefert dadurch (in geringem Maße) etwas mehr an Auflösung, allerdings zu Lasten der Bandbreite. Eine Stufe (z.B. von 0 auf 100), die im Eingangssignal von einer Wandlung auf die nächste kommt, verteilt sich dabei auf mehrere (bis viele) Ausgangswerte. Aber diese künstlich erzeugte Rampe braucht eigentlich keiner, weswegen man sie auch weglassen kann und nur jeden x-ten Wert wieder herausgeben kann. Das ist eine Reduzierung der Samplerate. Rein theoretisch würde man einen gleitenden Mittelwert etwa so machen, daß man die Input-Samples in einen Speicher stopft, wobei das neueste Sample an den Anfang kommt, alle Samples deshalb eins nach hinten rücken und das älteste Sample ins Nirwana fällt. Und dann die Summe bilden und durch die Anzahl Samples teilen. Ist umständlich. Hogenauers Idee war, die Input-Samples einfach aufzuaddieren, wodurch der o.g. Speicher überflüssig wird. Dann wird von Zeit zu Zeit der Stand der Summe hergenommen, der vorherige Stand (den man sich gemerkt hat) abgezogen und der Rest muß dann bloß noch durch die enthaltene Anzahl von Samples geteilt werden. Diese Anzahl Samples seit dem letzten 'Angucken' entspricht dann der Reduzierung der Samplerate. Natürlich läuft ein Summierer irgendwann über. Also muß man das berücksichtigen beim 'Angucken' und die Variable, die die Summe aufnimmt, muß ausreichend viele Bit breit sein, um das sicher erkennen zu können. Nochwas: Hier wird oft und gern von Integratoren geredet. Nun, Integrieren ist etwas dezent anderes. Hier haben wir es mit Summierung zu tun. Ein Gleiches gibt es zu den 'Differenzierern' zu sagen. Es ist hier nur die Differenz zur vorherigigen Summe gemeint und nicht die Steilheit des Anstieges im Signal. Aber Integratoren klingen 'mathematischer' als bloße Summierer. Das hebt. W.S.
W.S. schrieb: > Rein theoretisch würde man einen gleitenden Mittelwert etwa so machen, > daß man die Input-Samples in einen Speicher stopft, wobei das neueste > Sample an den Anfang kommt, alle Samples deshalb eins nach hinten rücken > und das älteste Sample ins Nirwana fällt. Und dann die Summe bilden und > durch die Anzahl Samples teilen. Ist umständlich. Nicht wirklich umständlich. Man muss nicht "nach hinten rücken", das geht weitaus intelligenter zu lösen. Einzig die Tatsache, dass man Speicher benötigt entsprechend der Anzahl der Samples, über die der Mittelwert gebildet werden soll, ist unschön. > Nochwas: Hier wird oft und gern von Integratoren geredet. Nun, > Integrieren ist etwas dezent anderes. Hier haben wir es mit Summierung > zu tun. Integration ist bei der Verarbeitung diskreter Werte nunmal nix anderes als als Summenbildung. > Ein Gleiches gibt es zu den 'Differenzierern' zu sagen. Hier gilt das analoge. Bei der Verarbeitung diskreter Werte ist Differenzieren tatsächlich nur: Bildung von Differenzen.
c-hater schrieb: > Nicht wirklich umständlich. Man muss nicht "nach hinten rücken", das > geht weitaus intelligenter zu lösen. Jeder normale Elektroniker weiß das und kann das. Und hier ging es nur darum, das Prinzip zu erläutern. Aber das geschilderte Verfahren ist tatsächlich umständlich. W.S.
c-hater schrieb: > Integration ist bei der Verarbeitung diskreter Werte nunmal nix anderes > als als Summenbildung. weswegen der Herr Hogenauer und der Rest der Welt sie auch so nennt. :-) W.S. schrieb: > Hogenauers Idee war, die Input-Samples einfach aufzuaddieren, wodurch > der o.g. Speicher überflüssig wird. Dann wird von Zeit zu Zeit der Stand > der Summe hergenommen, der vorherige Stand (den man sich gemerkt hat) > abgezogen und der Rest muß dann bloß noch durch die enthaltene Anzahl > von Samples geteilt werden. Die Idee war glaube ich schon Jahrzehnte älter. Hogenauers Idee war eigentlich das normale Filterverhalten nämlich Integration und Differenziation zu trennen und alle INTs und alles DIFs zusammenzufassen. Und der weitere Punkt ist das mit den Überläufen, die sich angeblich automatisch lösen. Das habe ich leider auch nicht mehr im Kopf, worauf man da aufpassen muss. Was ich nebenbei gesagt sehe ist, dass die Integratoren alle mehr und mehr weglaufen, also der eine immer überwiegend positiv ist, wodurch die Folgestufe immer steiler wird und früher überläuft und es (scheinbar) trotzdem funktioniert. Das Komische ist, dass meine Eingangswerte voll +/- sind also symmetrisch.
c-hater >> Nochwas: Hier wird oft und gern von Integratoren geredet. Nun, >> Integrieren ist etwas dezent anderes. Hier haben wir es mit Summierung >> zu tun. >Integration ist bei der Verarbeitung diskreter Werte nunmal nix anderes >als als Summenbildung. In deiner Welt als Anfänger der Signalverarbeitung wahrscheinlich schon. Wenn du dich weiterbilden willst, liest mal ein paar Artikel zu digitalen Integrationsverfahren.
Gerold schrieb: > Artikel zu digitalen Integrationsverfahren. Denen ist aber durchaus allen gemein, dass es irgendwo eine Summenbildung gibt. Sei es explizit durch Akkumulation oder implizit durch Nutzung einer Gleichung, die Ergebnis einer mathematischen Integration ist. Im vorliegenden Fall werden durch die Summation alle eingehenden Daten mit 1.0 gewichtet, daher sieht das so "einfach" aus - es ist aber in der Tat eine vollständige diskrete Integration. c-hater schrieb: > Bei der Verarbeitung diskreter Werte ist > Differenzieren tatsächlich nur: Bildung von Differenzen. ... man muss sich hier und auch bei der Integration halt nur immer bewusst machen, dass es der Differenzenquotient ist, der gebildet- und gfs. aufintegriert wird und nicht der "richtige" Differentialquotient. Mithin vergessen Viele bei der diskreten Integration das Restglied, das man nicht immer vernachlässigen kann und im Einzelfall auch nicht sollte.
>Gerold schrieb: >> Artikel zu digitalen Integrationsverfahren. >Denen ist aber durchaus allen gemein, dass es irgendwo eine >Summenbildung gibt. Sei es explizit durch Akkumulation oder implizit >durch Nutzung einer Gleichung, die Ergebnis einer mathematischen >Integration ist. Ich denke, dass die Verwendung eines Näherungspolynoms oder die Verwendung eines schrittweisen Näherungsverfahrens zu Integration nicht einfach als "Summierung" bezeichnet werden kann.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.