Hi, soweit ich verstehe in Decimation wird lediglich ein Abtastwert aus einigen Abtastwerten genommen. Die anderen werden einfach weggeschmiessen. Aber bei der CIC Decimation scheint es anders au sein, nämlich alle Werte werden berücksichtigt und irgendwie integriert. Stimmt es? Owen
Moin, Du darfst erst dann dezimieren (d.h. nur noch jedes n-ten Sample weiterverarbeiten), wenn sichergestellt ist, dass dein Signal vor der Dezimation das Abtasttheorem nach der Dezimation nicht verletzt. Das macht man oft durch einen Tiefpass vor der Dezimation. Bei der CIC-Dezimation ist der Tiefpass halt "eingebaut", ansonsten musst du dich halt selbst drum kuemmern und/oder mit dem verletzten Abtasttheorem leben. Kleines Beispiel: Du hast diese Samples: 4 4 7 4 4 7 4 4 7 4 4 7 ... Das ist ein Signal, was - ich sag' mal - mit 1kHz abgetastet wurde. Darin enthalten ist also ein Gleichanteil und ein Signal bei 333Hz. Wenn du das einfach um den Faktor 2 dezimierst, dann kommt zB. das raus: 4 7 4 4 7 4 Da die 333Hz aber bei 500Hz Abtastfrequenz das Abtasttheorem verletzt haben, hast du ploetzlich eine neue Frequenz in deinem Signal (167Hz), die da nicht reingehoert. Mit einem vernuenftigen Tiefpass vor der Dezimation sollte dann das rauskommen: 5 5 5 5 5 5 Gruss WK
Also, nach meinem Verständnis besteht der CIC-Algorithmus schlichtweg aus einer Verkettung von mehreren gleitenden Mittelwerten aus je 2 Samples. Damit dabei der Informationsgehalt nicht verlustig geht, steigt dabei die Bitbreite bei jeder Stufe um eins an. Normalerweise hat man ja keine Integers, sondern gebrochene Zahlen, weswegen die zusätzlichen Bits "rechts" drankommen. Mal salopp skizziert: gegeben seien hereinkommende Samples "A", also A(n),A(n-1)... usw. Die 1. CIC-Stufe macht daraus B = (A(n-1) + A(n))/2. B braucht dabei 1 Bit Breite mehr als A und B wird bei jedem 2. Takt als neuer, dezimierter Strom von Samples "B" (also B(m),B(m-1).. usw) an die nächste Stufe weitergegeben. Die nächste CIC-Stufe macht daraus C = (B(m-1) + B(m))/2. Und so weiter, je nachdem, wieviele Stufen man haben will. Bei jeder Stufe wird die Samplerate halbiert und dafür die Bitbreite erhöht. Obiges Beispiel: derguteweka schrieb: > Du hast diese Samples: > 4 4 7 4 4 7 4 4 7 4 4 7 ... > > 4 7 4 4 7 4 ähem.. anders: 4 - 4 (4+4)/2 = 4 7 - 4 (7+4)/2 = 5.5 4 - 7 (4+7)/2 = 5.5 4 - 4 (4+4)/2 = 4 7 - 4 (7+4)/2 = 5.5 4 - 7 (4+7)/2 = 5.5 ... die nächste Stufe sollte dann das abkriegen: 4 - 5.5 (4+5.5)/2 = 4.75 5.5 - 4 (5.5+4)/2 = 4.75 5.5 - 5.5 (5.5+5.5)/2 = 5.5 ... W.S.
Angehängte Dateien:
-
cic.png
13 KB
Moin, @W.S: Das was du skizziert hast, ist kein richtiges CIC; das ist ein FIR Tiefpass mit 2 Koeffizienten [0.5 0.5]. Damit wird's auf jeden Fall auch besser als ganz ohne Tiefpass. Die Integratoren beim CIC speichern ja die gesamte Vorgeschichte, nicht nur 1 Sample. Aber es ist eigentlich voellig wurst, wie dieser Tiefpass vor der Dezimation aufgebaut ist - wichtig ist nur, dass er da ist (wenn das Signal bandbegrenzt werden muss) und fuer die Anwendung gut genug ist... Hoffentlich hab' ich mich nicht verrechnet; hier mal das Beispiel mit einem CIC Dezimator mit je 2 Integratoren und 2 "Kaemmen"(Differenzierern). Das ist schon besser als ohne - der SpitzeSpitzewert des Stoersignals ist immerhin von 3 auf 0.75 reduziert - aber halt noch nicht ganz weg... Von oben nach unten: Eingangssignal Nach dem 1. Integrator Nach dem 2. Integrator Nach der Dezimation Nach dem 1. Kamm Nach dem 2. Kamm Durch 4 geteilt: Gruss WK
Hmm.. also was du da skizziert hast, sieht mir nach Additor mit nem Überlauf und anschließendem Crash aus. Im Prinzip MUSS jede Stufe dafür sorgen, daß sie nicht gegen die Wand integriert, sonst passiert nach ein paar Zyklen das Ungeheure. Ich hab das Gefühl, daß du dich da vergaloppiert hast. Aber im Grunde sehe ich das recht hemdsärmelig: Ein laufender Mittelwert ist ne hardwaremäßig relativ leicht zu realisierende Sache, braucht also wenig Ressourcen und er ist im Gegensatz zu allen anderen Tiefpassfiltern kurvenformgetreu. Also ist er auch das geeignete Mittel, um Signale zu dezimieren. Ach ja, guck dir doch mal den IP für nen CIC-Dezimator von Xilinx an. Mit jeder Steigerung der Ordnung steigt auch die Bitbreite und die Burschen bieten auch an, mit einer Instanz zwei voneinander unabhängige Signale A und B zu dezimieren, solange selbige nur geordnet (AABBAABBAABB..) in den Dezimator geschickt werden. Das sieht mit verdammt nach dem von mir geposteten Prinzip aus. Naja.. ich habe bislang noch keine wirklich befriedigende Darstellung des CIC gesehen. Eigentlich ALLE Autoren verlieren sich in mathematisches Geschwafel. Da fällt mir ein Spruch meines damaligen Mathe-Prof's zu Lösungsansätzen für Differentialgleichungssysteme ein: "Och, da ist einfach Intuition gefragt, einfach ein bissel herum probieren ob eine Funktionsklasse besser geht als die andere..." (T.Riedrich, ca. 1975) W.S.
Nachtrag: Guck dir mal sowas an: "http://de.wikipedia.org/wiki/Cascaded-Integrator-Comb-Filter"; glaubst du, daß SO ETWAS geeignet ist, einen geneigten Leser zum tatsächlichen Verständnis zu führen, wie so ein CIC-Dezimator tatsächlich funktioniert? W.S.
Hallo, also CIC geht wunderbar, aber je nach sind es mehr als 1 Bit pro Stufe. Der DC-Offset ist natürlich der größte feind des Filters. Der DC-Offset kann aber leicht eliminiert werden, durch eine einfache Rückkopplung. Im Web gibt es da genügend Literatur darüber. Ich selber habe einen Upsampler gebaut der von 16KHz auf 512Khz mit 24 Bit Audio hoch geht. Ich meine es waren nur 5 oder 6 Stufen notwendig. Es wird vermutlich nichts vergelichbares geben, als CIC mit so wenig rechenleistung. Ein FIR-Filter oder IIR-Filter verschlingt um potenzen mehr. Übrigens ist der Überlauf kein Problem. Und mit CIC kann man rauf wie runter mit der Samplingfrequenz. Ich meine hier im Forum gab es schonmal einen sehr guten Thread darüber. Gruß Sascha
Sascha schrieb: > also CIC geht wunderbar, aber.. Das ist ja schön für dich, aber weiß du auch WIE CIC geht, so daß du es hier beschreiben oder gar posten kannst? Mir ist schon klar, daß man in Mathworks&Co fertige eingebaute Routinen hat, die einem die eigentliche Arbeit machen. Aber hier geht es vorrangig um das echte Verstehen und weniger um die blinde Benutzung. W.S.
Hallo, selbstverständlich habe ich es verstanden, sonst hätte ich in Assembler nicht die CIC-Routinen programmieren können. Erklären kann ich es nicht im Forum, weil ich sonst vermutlich etwas falsch rüber bringe. Damit ist dir dann etwas weniger geholfen. Ich kann dir aber Code-Fragmente posten, wenn das dich weiterbringt. Du must im Web nach dem Erfinder der CIC-Routinen suchen. Die CIC-Routinen sind in den 70er Jahren entstanden, weil dort die Rechner noch keine Rechenleistung hatten, aber man mit Signalverarbeitung bereits begonnen hatte. Die CIC-Routinen sind auch bei der Musik-CD anfänglich als Halfbandfilter eingesetzt worden. Ich muss meine Unterlagen durchsuchen dann finde ich sicherlich noch eine gute Erklärung. Gruß Sascha
Sascha schrieb: > Der DC-Offset ist natürlich der größte feind des Filters. Das kommt mir doch sehr seltsam vor. Immerhin brauchen wir zum Dezimieren einen Tiefpaß - und dieser MUSS mit einem Gleichanteil zurechtkommen, sonst taugt er nichts. Ich weiß, daß fast alle Autoren so ein nettes Bild in ihre Artikel einbauen, wo zunächst die Samples in eine Reihe von Integratoren (sprich Akkus) kommen und dann erst kommt sowas wie Differentiatoren. Haben wohl alle voneinander abgeschrieben und das Ding selber nicht wirklich verstanden. Also ganz klar: Ein IIR-Tiefpaß aus zumindest 2 Summanden ist ein Integrator oder auch Akku und macht (pascalartig geschrieben) sowas: akku:= akku + sample; So etwas läuft garantiert alle nase lang über. Man muß deshalb schon im Akku was dagegen tun, einfachstenfalls so: akku:= (akku + sample)/2; Sascha schrieb: > selbstverständlich habe ich es verstanden, sonst hätte ich in Assembler > nicht die CIC-Routinen programmieren können. Erklären kann ich es nicht.. Hmm.. da kommt mir der Witz vom Urvogel in den Sinn: Der sagte mal zu seinen Dino-Zeitgenossen: "Ich weiß ganz genau, wie ich heiße, aber ich kann's nicht aussprechen." (Archaeopterix) nix für ungut.. Es wäre aber dennoch hier ne gute Gelegenheit, die Funktionalität des CIC-Algos mal vernünftig und verstehbar darzustellen. W.S.
Moin, Uiuiui, lauter CIC Eggsberddn. Ich bin zutiefst impraegniert. Die Frau Werwolf meint uebrigens: Das mit den ueberlaufenden Integratoren, "des g'hoert so". Solange die hoechstens einmal waehrend der Dezimation ueberlaufen und alles schoen in 2er-komplement rechnet, isses wurscht. Das ist ja grad' der Witz dran. Mit welchen Bitbreiten das dann jeweils sichergestellt ist, kann man nachlesen. Das I in CIC steht wirklich fuer _I_ntegrator und nicht fuer _i_rgendein komisches Tiefpassfilter. zu: [quote]Guck dir mal sowas an: ... glaubst du, daß SO ETWAS geeignet ist,...[/quote] kann ich nur sagen: Ja, das erscheint mir durchaus geeignet. Am Ende des Wikipediaartikels gibts noch einen Link zu einem cic.pdf, wo nochmal alles erklaert wird. Gruss WK
Samuel schrieb: > Der Überlauf beim Integrator wurde hier schon diskutiert: > > Beitrag "Probleme mit CIC Filter" Sapperlott, da steht ja alles. Und ich schreib' mir hier nen Wolf :D Gruss WK
So, ich hab mal was zum Diskutieren oder so angehängt, einfach damit man mal was Halbkonkretes hier sehen kann. In der CIC2.pdf steht übrigens ein netter Satz: "This summation is the same as the system function for a FIR filter. Therefore a N section CIC filter is functionally equivalent to a cascade of N FIR filters! A way to do this is use a N cascade of RM storage registers ( FF’s) and one accumulator per section." Da fühle ich mich dann doch nicht so einsam mit meiner obigen Brachialversion. W.S.
derguteweka schrieb: > Ja, das erscheint mir durchaus geeignet. Ähem.. naja. Dann erkläre mal den Kippschalter mitten in der Grafik, also den, der den Eingang des 1. Differentiators vom Ausgang des letzten Integrators trennt und nach üblicher Logik damit ein "unbestimmt" an den Eingang legt. Jaja, wer sich an dieses Bild gewöhnt hat (alle Artikel zum Thema CIC repetieren dieses Bild uneditiert), dem fällt das nicht mehr auf, aber eigentlich müßte das ein Umschalter sein, der den Eingang entweder auf Null legt oder auf den letzten Integratorausgang. Oder? W.S.
Hallo, das mit dem Schalter kommt darauf an, ab du rauf oder runter die Samplingrate ändern willst. Man vertauscht nur Integrator mit Differentiator. Wenn man die Samplingrate dezimiert z.B. /2 so nimmt man ja nur jedes zweite Sample, also ist es in der Zeit dazwischen eqal was anliegt, weil keine Bearbeitung stattfindet. Viel schwieriger wirds beim vervielfachen der Samplingrate, dort geht die Bearbeitung des Ausgangskreises in dem fall als Integrator (Tiefpassfilter) schneller und man sollte das letzte Sample nehmen. Gruß Sascha
Hallo, fast vergessen, die CIC geschichte ist eigentlich nur eine Notlösung. Mit Heutiger DSP Performance kann man viel besseres anstellen. Schaut euch mal im Frequenzspektrum das Ergebniss an. Da würde ich jeden anderen Filter wie SinC,SinX und FIR bevorzugen wenns mit der Rechenleistung des DSPs geht. Gruß Sascha
Naja, eigentlich geht es nicht gar so sehr um DSP, sondern um die Vorbearbeitung in einem FPGA. Deswegen ist dieser Thread hier etwas deplaziert, aber macht nix, es ist ja in jedem Fall digitale Signalbearbeitung. Ein typisches Szenario ist ein digital arbeitender Empfänger für KW. Da wird erstmal mit 100 MHz digitalisiert und dann muß im Digitalen heruntergemischt werden. Ja, CORDIC für den LO, I/Q-Mischer dran und dann hat man je 2 Samples im 100 MHz Takt, wo man erstmal die Summenfrequenz unterdrücken muß (so gut es geht) und die Differenzfrequenz so weit tiefpaßfiltern und dezimieren muß, daß nur der Bereich übrig bleibt, der einer üblichen ZF (im Analogen) so lala entsprechen würde - und die wird dann mit einem wirkungsvolleren Filter gemacht. Mit je 2 Samples im 100 MHz Takt ist wohl jeder DSP erschlagen, da muß man all die grandios mathematisch formulierten Algorithmen so weit herunterbrechen, daß ein Sack logische Gatter und Flipflops übrig bleibt, die man in ein FPGA stopfen kann. An dieser Stelle hat dann sowas wie CIC so seine Berechtigung. Allerdings denke ich mir, daß man mit einer Kaskade von 2..3 hintereinander geschalteten gleitenden Mittelwerten mindestens genau so gut fährt, zumal dabei keine solche Aufblähung der Datenbreite nötig ist und ein gleitender Mittelwert aus 2 Samples ja auch nur 1 Register und 1 Adder braucht - und obendrein keine Polstelle bei 0 hat. W.S.
Hallo, @W.S. das habe ich auch noch vor aber ich nehme einen GC4016 von Ti. Das mit den FPGAs ist schon eine Wissenschaft für sich. Ich habe meinen Sender schon fast fertig und nehme den AD9957 leuft übrigens super, und genau dazu brauchte ich die CIC-Routinen, weil auf einem Cortex-M4 von ST mit 180MHz irgendwann auch schluss ist. Ich wandle dabei von 16KHz Audio (Hilberttransformation) auf 512KHz und füttere den AD9957 damit. Aber Xilinx hat doch dafür eine AppNode und sogar Code oder ? Intressant ist es beim Empfänger, über die Dezimierung einen höheren Dynamikbereich zu bekommen, dazu müssen die Filter allerdings stimmen. Gruß Sascha
Sascha schrieb: > Aber Xilinx hat doch dafür eine AppNode und sogar Code oder ? > Intressant ist es beim Empfänger, über die Dezimierung einen h Kannst du vergessen. Natürlich haben die eigentlich alles.. aber eben nicht offen, so daß man lesen kann, was da abgeht, sondern nur encrypted. W.S.
Moin, W.S. schrieb: > > Da fühle ich mich dann doch nicht so einsam mit meiner obigen > Brachialversion. > > W.S. Ja, da gibts diverse Moeglichkeiten, was zu bauen, was noch weniger Flipflops und Addierer frisst, als ein normales CIC Filter, sich aber genauso verhaelt - bloss ist das, wenn man das normale CIC Prinzip noch nicht durchdrungen hat, eher noch verwirrender. In "Streamlining Digital Signal Processing" von Richard G. Lyons gibts dazu das Kapitel 6. Der "Kippschalter" in den Grafiken, statt einem Umschalter - naja, das ist halt die uebliche Nomenklatur. Klar, wenn du ein Seminar/Vorlesung ueber DSP machst vor lauter Energieelektrikern, dann kannst du's schoen ueber die 5 Sicherheitsregeln erklaeren - so mit "Freischalten" und "Erden und Kurzschliessen". Auch das Pluszeichen im Kreis ist sowas - Bei FPGAs sind Addierer eher sowas wie die Umrisse einer Hose mit einem Pluszeichen drinnen. Bei irgendwelchen CRC Berechnungen sind so gekringelte Pluszeichen eher Anzeichen fuer XOR-Gatter... Genauso die imaginaere Einheit i,die bei den Elektrolurchen halt j heisst, weil i schon fuer den Strom steht. So gibts halt ueberall Eigenheiten bei Bezeichnungen und Bildern... Aber: Der eigentliche Knackpunkt ist der, dass man nicht von Anfang an sagen sollte: "Ich mach' jetzt CIC-Dezimation auf Teufelkommraus", sondern sich erstmal ueberlegen, was an Signalen reinkommt, und was rauskommen soll. Wie diese Signale ggf. im Spektrum aussehen. Welche signaltheroretischen Schritte fuer die Verarbeitung notwendig sind. Und dann erst, mit welchen Konzepten und mit welcher Hardware man das hinkriegen kann/muss. Dann kann man evtl. zum Schluss kommen, dass ein CIC vielleicht guenstig sein kann - inclusive einem vielleicht noch zusaetzlich notwenigen Vor- oder Nachfilter, was den Durchlassbereich wieder geradebiegt...Oder CIC nur als ein Teil der Dezimation. Ist mir Phase und Gruppenlaufzeit voellig wumpe, dann wird evtl. ein lustiges IIR-Cauerfilter vor dem dezimierenden "Kippschalter" eine viel bessere Aliasunterdrueckung machen, bei auch ertraeglichem Aufwand, seien es Flipflops/Gatter oder Assemblerbefehle. Gruss WK
Hallo, @derguteweka, danke, du sprichst die Probleme richtig an. Ich sehe das genauso und habe übrigens diese Erkenntnis in der Praxis schon einholen können. Phasendrehung, Frequenzgang und Oberwellen durch den Filter sind bei DSP das gleiche Problem wie auch in der Analogtechnik. Man muss schon sehr gute DSP-Filter bauen, damit sich der Aufwand lohnt. Wenn man dann professionelle Lösungen anschaut sieht man erst den Aufwand. For allen spielt man unter Umständen Monate lang an den Filter Parameter rum, bis es einiger maßen passt. Aleine meine Hilberttransformation von 300Hz bis 5KHz linear zu bekommen, mit einem max. Winkelfehler von +/-0.01% war eine sehr strenge Arbeit. Ein SDR-Empfänger zu bauen macht aber nur sinn, wenn ich durch den gewonnenen dynamik Bereich einen Vorteil habe. Aber ich kann nur allen Mut zusprechen, es ist noch kein Meister vom Himmel gefallen. Und wer nichts macht, kann bekantlich auch nichts falsch machen. Gruß Sascha
Sascha schrieb: > Ein SDR-Empfänger zu bauen macht aber nur sinn, wenn ich durch den > gewonnenen dynamik Bereich einen Vorteil habe. Naja, mach mal halblang. Der eigentliche Grund, sich auf Biegen und Brechen mit digitaler Signalverarbeitung herumzuschlagen ist, daß es heutzutage kaum noch eine Hardwarebasis für rein analoge Technik gibt. Vergleiche doch mal das Angebot auf der letzten Hamrad mit dem von vor einigen Jahren. Es geht kommerziell schon seit langem nur noch digital - und unsereiner steht da erstmal wie die sprichwörtliche Kuh vor'm neuen Tor. Die Alternative heißt also SDR oder bleibenlassen. Ärgerlich ist das Thema dennoch, denn sowohl auf der DSP-Seite als auch auf der FPGA-Seite sind die Befindlichkeiten der Leute, die sowas beruflich schon seit langem tun, ziemlich hochnäsig gesetzt. Das schlägt zum einen auf die erreichbare Literatur durch, wo mir noch wirklich KEIN echt praxisnahes Buch untergekommen ist und zum anderen auf die entsprechenden Forensparten hier durch, wo z.B. die FPGA-Leute sich partout nicht vorstellen können, daß es Leute geben könnte, die nicht ihren eigenen Stallgeruch an sich haben und die all die Dinge deshalb völlig anders sehen als sie selbst. Was bleibt, ist das eigene Pröbeln, also durch "probieren_und_auf_die_Nase_fallen" zu versuchen, sich die Kenntnisse anzueignen, die eigentlich schon längst bekannt sind, aber mangels geeigneter Lehrtätigkeit eben nicht die Verbreitung gefunden haben, die sie eigentlich haben sollten. Im Grunde finde ich das unbefriedigend. Leute, die ihre Brötchen damit verdienen müssen, müssen da halt durch, aber als Amateur fragt man sich, ob einem sowas letztendlich noch den nötigen Spaß bereitet, um ohne wirkliche Hilfe sich in die SDR-Gefilde einzuarbeiten. W.S.
Hallo, @W.S. also ich mache die Funkgeschichte auch nur in meinem Hobby. Beruflich bin ich zwar etwas vorbelastet, muss mir die DSP-Geschichte auch aneignen. Was mir hin und wieder fehlt sind etwas bessere mathematische Kenntnisse. Aber man braucht viel Zeit um sich durch die unterschiedliche Literatur zu arbeiten. Ich mache das Digitale nicht um im Moment Hip zu sein, sondern es bietet einige Vorteile, die das Analoge nicht bieten kann. Damit meine ich zum Beispiel Filter, die nicht durch Bauteiletoleranz driften. Sonst muss ich dir Recht geben, es scheint gerade Hip zu sein was SDR heißt. Und dann sind die SDR Dinger meist recht schlampig gebaut. Es gibt aber immer noch sehr gute analoge HF-IC, wenn man bei verschiedenen Herstellen schaut. (Sind meist nur recht unbekannt.) PS. ich will im kommenden Jahr eine Web-Seite zu diesem Thema AFU und Digitales starten. Ziel ist es auch Leute zu finden die sich für qualitatives und nicht für qantitatives begeistern können. Gruß Sascha
Moin, Jetzt sind wir hier aber schon arg vom Originaltopic abgedriftet, aber nachdem Owen ja schon alles klar ist - warum auch nicht :D Wenn ich hier so ein bisschen querles', dann faellt oft der Ausdruck SDR. Ich nehm mal an, damit ist nicht der Sueddeutsche Rundfunk gemeint, sondern "Software defined Radio". Das halt' ich aber fuer ein aehnliches Blaehwort wie Industrie 4.0. Denn das kann doch alles moegliche sein. Was sind denn fuer ein konkretes Projekt die Anforderungen; welche Eingangssignale sollen mit welchen Bandbreiten, C/N Verhaeltnissen, Nachbarkanaldaempfungen, etc. bla. empfangen/demoduliert(?) werden. Und ganz grob umrissen - welche Hardware ist da im Bereich des Moeglichen? Filter im Allgemeinen sind schon ein anspruchsvolles Thema, insbesondere dann bei der digitalen Signalverarbeitung - auch noch gepaart mit dem ganzen Spass, den man sich bei der Abtastung einfaengt. Ich glaub' nicht, dass das so ganz ohne Mathe geht. Gruss WK
derguteweka schrieb: > Jetzt sind wir hier aber schon arg vom Originaltopic abgedriftet Naja, so eigentlich eher nicht, denn gerade digitales Mischen, Filtern, Dezimieren und Demodulieren sind ja nun mal die Kernthemen beim Empfängerbau. Und SDR ist mittlerweile ein gängiger Ausdruck, ursprünglich nur für das Verwenden eines PC zum Empfangen eingeführt und jetzt ein Sammelwort für alles, was eben numerisch und nicht mehr analog geht. Das sollte uns nicht stören. Die großartigen Argumente der SDR-Verfechter lauten ja zumeist, daß man nur die rudimentärsten Funktionen analog bauen sollte und möglichst ganz viel dann digital (eigentlich besser "in Software" genannt), weil man da ja ganz leicht updaten kann, wenn es was neues gibt. Ich halte das für Mumpitz, weil bisher noch keiner wirklich in die Zukunft hat schauen können. In den letzten 20 Jahren haben wir schon so oft Worte wie ULTRAFAST, ULTRAHIGH und andere Ultras gehört - und schon wenige Jahre danach war das damit Beworbene nur noch Schnee von gestern. Also: Wenn schon Radiobau mit DSP, FPGA und Konsorten, dann NUR so, wie wir es jetzt und heute für unsere jetzigen und allernächsten Bedürfnisse haben wollen. Teuer genug wird es ohnehin. Tja.. zum mathematischen Unterbau: Es ist völlig schnurz, ob man gar kein oder nur ein 40 Jahre zurückliegendes Mathe-Studium im Kreuz hat. Fourier- und Laplace-Transformatin konnte unsereiner damals auswendig vor und zurück, aber eben nur auf der theoretischen Ebene, nicht im Mindesten in den Niederungen der praktischen Anwendung - aber davon ist nur noch die grobe Erinnerung geblieben. Eines bleibt aber - selbst für den reinen Praktiker - immer übrig: Das Herangehen an's Problem, also WIE man den Signalfluß von der Antenne bis zur NF-Buchse denn so gestalten will. Echte Mehrfach-Super sind nach meinem Empfinden mittlerweile obsolet geworden, wenn es an irgend einer Stelle im Signalfluß digital werden soll oder muß. Das läuft dann immer auf I/Q-Direktmischer hinaus und auf das Verarbeiten von ganz kleinen Pegeln im NF-Bereich. Ist anders als bisher, aber nicht wirklich leichter oder besser. W.S.
Hallo, um es mal einfach auf den Punkt zu bringen, eine ZF am Eingang muss sein und dann kommt der superschnelle AD-Wandler mit 16 Bit, und ganau da liegt zur Zeit auch noch das Problem. Ein 16 Bit Wandler hat effektiv ca. 12-14 Bit Auflösung bei 100MHz, der Rest ist verauscht. Das stört aber nicht weiter wenn genug stark dezimiert wird. Das trennen in I und Q wird nach dem AD-Wandler im FPGA oder ASIC gemacht. Nun kommen die CIC und FIR Filter zum Einsatz. @WS der einzigste Vorteil was das Digitale bietet ist nacher der Preis in der Serie. Analoger Abgleich und Quartzfilter sind viel teurer. Gruß Sascha
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.