Hallo zusammen, ich bin mir fast sicher, dass ich nicht im richtigen Forum bin, allerdings seid ihr so fit, dass ihr mir bestimmt weiter helfen könnt. Mein Prof hat mir die Aufgabe gestellt einen DDC im FPGA zu programmieren. Im Anhang ist der Aufbau (Wiki Bild). Die Daten vom ADC (14 Bit) bekomme ich sauber in den FPGA und mit einem DDS habe ich einen Sinus und Kosinus erzeugt (jeweils 14 Bit). Somit ist mein nächster Schritt jetzt die Signale miteinander zu multiplizieren. Dafür will ich XtremeDSP Slices benutzen. Wenn ich allerdings beide Signale miteinander multipliziere bekomme ich ein 28 Bit Signal. Ich frage mich ob das so sein muss! Sprich muss ich nach dem Multiplizieren mit 28 Bit weiterrechnen (erstes ? im Bild) oder kann ich bereits hier eine Bitbreitenreduktion durchführen? Wenn ich mit 28 Bit weiterrechnen muss müssen diese komplett in den Tiefpass. Danach habe ich dann ja noch immer 28 Bit (bitte verbessert mich wenn ich mich irre). Anschließend kommt der Dezimator, nachdem noch immer 28 Bit vorliegen. Oder? Der Dezimator verringert (bzw passt an) doch lediglich die nötige Abtastfrequenz (im Bezug auf die neue Mittenfrequenz)? Zusammengefasst weiß ich nicht mit welchen Bitbreiten ich an den mit den Fragezeichen gekennzeichnet Stellen rechnen muss. Könnt ihr mir helfen? Ich hoffe ich habe mich deutlich ausgedrückt.
Angehängte Dateien:
-
DDC.png
18 KB
In der Mittelstufe hatten wir füher die sogenannte "Fehlerechnung". Damit konnte man unter Berücksichtigung der Aussteuerung der Werte den jeweils maximalen Fehler durch die Rundung berechnen. Da dieses Verfahren 2000 abgeschafft wurde, darfs Du es nicht mehr benutzen und musst ausprobieren.
Bei einer Multiplikation kann das Ergebnis nicht genauer sein, als der ungenauste Faktor.
Jan Peters schrieb: > Wenn ich mit 28 Bit weiterrechnen muss müssen diese komplett in den > Tiefpass. Danach habe ich dann ja noch immer 28 Bit (bitte verbessert > mich wenn ich mich irre). Nein, danach hast du sogar noch mehr Bits. Hab das schonmal realisiert und dabei im Filter noch mit der vollen Bitbreite gerechnet. Kam dann bei glaube ich 36 Bit raus(Eingangsignal 16 Bit) von denen ich nur 16 verwenden durfte. Hab dann einen Mux dahinter gehangen, den man konfigurieren kann sich ein Fenster von 16 Bit aus den 36 heraus zu ziehen (z.b. 35 bis 20 oder auch 25 bis 10, etc). Das hat den Vorteil, das man bei schwachem Signal mehr Genauigkeit nach unten hat. Kommt aber auf die Anwendung an ob das für dich auch machbar ist oder nicht(dynamische Umschaltung dieses Fensters). Im Zweifelsfall nur die höchstwertigsten Bits nehmen, dann aber drauf achten das sowohl DDS als auch Filter richtig skalieren, wobei du bei beiden etwas Amplitude verlieren wirst.
Abc schrieb: > Hab dann einen Mux dahinter gehangen, den man konfigurieren kann sich > ein Fenster von 16 Bit aus den 36 heraus zu ziehen (z.b. 35 bis 20 oder > auch 25 bis 10, etc). Das hat den Vorteil, das man bei schwachem Signal > mehr Genauigkeit nach unten hat. Da kann man sich auch einfach mal die Dokumentation der "alten" Analog-Devices Festkomma-DSPs ADSP-218x ansehen. Die Jungs dort hatten immer das Problem, nur mit 16 Bit rechnen zu können, und deshalb gibt es schön dokumentierte Vorgehensweisen. Im Überblick zu finden hier http://www.analog.com/en/processors-dsp/ADSP-21xx/processors/manuals/resources/index.html unter Using the ADSP-2100 Family Volume 1 (Rev 1.0, 1990) und Using the ADSP-2100 Family Volume 2 (Rev 1.0) Der eigentltiche Trick ist die mentale Umskalierung des Signals von -32768...32767 nach -1...+1. Denn dann kann nach einer Multiplikation (vereinfacht) auch nur etwas zwischen -1 und +1 herauskommen... ;-)
Hallo Lothar Miller hallo Abc, Das sind super Tips Danke. Werde gleich mal gucken und mich schlau machen
E. M. schrieb: > sehr vereinfacht, ja Nicht allzusehr, es passen bei 16 Bit die Zahlen 0x8000 ... 0x0000 ... 0x7FFF das ergibt -32768/32768 ... 0 ... +32767/32768 und damit -1 ... 0 ... +0,99996948 Das Hauptproblem besteht darin, auch die Multiplikation von -1*-1 halbwegs plausibel abzubilden, weil da ein Üblerlauf stattfinden wird: -1*-1=1, und das ist größer als 0,999969. Und es ist klar, dass ein Überlauf bei der Addition durch passende Skalierung behandelt werden muss 0,7+0,7 (=22937+22937) passt nun mal nicht in den Bereich bis 0,9999 (=32767)...
Hallo, zunächst einmal danke für das rege Interesse! Den Ansatz von Lothar Miller mit dem Überlauf habe ich verstanden. Allerdings bin ich mir noch nicht 100% im Klaren wie die Normierung auf 1 mir bei der Reduzierung der Bitbreite helfen soll. Aber das wird hoffentlich noch wenn ich mir alle Unterlagen die Lothar mir empfohlen hat durchgearbeitet habe.
Wenn man auf 1 normieren könnte, dann würde es funktionieren. Klappt leider bei der Multiplikation ohne Überlauf mit einem Sinus nicht. Da verliere ich dann 1/Sqrt(2) (stimmt das? irgentwas in der Richtung auf jeden Fall) der Amplitude. Wenn ich zudem noch von Unsigned auf Signed gehe wirds noch schlimmer. Filteroperationen auf 1 zu skalieren ohne Überlauf ist auch nicht in jedem Fall möglich. Grundsätzlich in jedem Fall der richtige Weg. Kommt aber auch aufs Anwendungsgebiet an. Will man auch die untersten Bits des Eingangssignals noch behalten muss man wohl den Bereich erhöhen oder wenn das nicht geht eben dynamisch skalieren. (Gain multiplier, mux, etc)
Für eine Demodulation ist interessant: Wie ist das Signal moduliert? Wo steckt die Information im Signal? Hat das Signal einen Träger? Es gibt auch andere Demodulatoren als der oben aufgezeigte Hilbertransformator. Digital PLL z.B. Die Reduktion von Bits erhöht den Quantisierungsfehler. Die Bitbreite hängt von der Signalstärke ab, die du noch detektieren willst. Du könntest genauso die Bitbreite des ADC reduzieren.
Ok jetzt wird es langsam alles klar! Das mit der Normierung und der dynamische Skalierung finde ich ganz interessant! Vielleicht kann ich aber auch einfach die LSBs vernachlässigen. Dafür muss ich aber erst klären wie stark das Signal ist. Danke an alle. Zu Renés es ist in diesem Fall keine Modulation. Es geht darum eine Reflektion einer modulierten Sinuswelle ins Basisband zu mischen. Darum hätte ich auch keine Quantisierungsfehler. Es werden keine Daten übermittelt sondern lediglich die Verzögerungen mehrere Kanäle zueinander ausgewertet. Noch mal danke an alle! Ihr habt mir Super geholfen.
Hallo, der schon erwähnte Ansatz, die Signale im Wertebereich [-1,1-LSB] zu interpretieren ist genau richtig. Ein 14*14 bit Multilizierer liefert dann am Ausgang ein 28-bit-Signal mit einem Wertebreich [-2, 2-2^-26]. Wenn vermieden wird, dass der SIN/COS den Augangswert -1 erzeugt, kann das MSB am Ausgang des Multplizierers verworfen werden. Dies ist aber möglich, indem die SIN/COS-Werte sehr geringfügig kleiner skaliert werden. Ob nun am Ausgang der Mulpilizierer durch Runden (nicht Abschneiden, da sonst DC-Offset im Nutzband) die Wortbreite reduziert werden kann, hängt von einer Rauschbetrachtung ab. Ein realler 14-Bit-ADC hat meist eher ein ENOB (Effective Number Of Bits) von ca. 12 bit. Der Runder fügt ein zusätzliches Rundungsgeräusch von LSB^2/12 ein. Liegt das Rauschen des Runders 20 dB unter dem Rauschen des ADC, wird das SNR um ca. 1 dB schlechter. Ist das OK, dann folgende Abschätzung 20 dB/6 dB ~ 4 -> Bei ADC mit 12 bit ENOB benötigt man 12 + 4 = 16 bit am Ausgang des Runders. Noch 2 bit Reserve draufgeben und mit 18 bit am Ausgang des NCO fährt man gut. Durch die Skalierung der SIN/COS-Werte erspart man sich auch die Begrenzung im Runder. Hierzu die Grenzfälle durchrechnen (negativster Wert am Eingang * negativster Wert aus SIN/COS < dem Wert, der begrenzt werden muss). Ein gewisser Zündstoff ist noch die Statistik des Rauschens des ADC. Ist das Rauschen des ADC "wirkliches" Rauschen, wird auch das Quantisierungsrauschen des Runders "weiss" sein und bei der nachfolgenden Filterung ergibt sich ein Genauigkeitsgewinn (Erhöhung der Ausflösung durch Filterung). Absolut auf Nummer sicher geht man, wenn vor dem Runder ein gleichverteiltes Rauschsignal im Wertebreich [-LSB/2, LSB/2] addiert. Dann ist das Quantisierungsrauschen des Runders immer weiss. Der Preis denn man bezahlt, ist ein um 3 dB höheres Rauschen des Runders. Gruss Markus
Wenn Du mein sin/cos-Paket unter <http://opencores.org/project,sincos>; benutzt, ist das mit der Sinus-Skalierung auf +-0.999 schon gemacht. Es ist auch das Packet un_signed_sprt dabei, das Konversionen von/nach float <=> signed, unsigned macht -- unter der Annahme dass der Bitvektor -1.0 ... 0.999 oder 0.0 ... 0.999 abbildet. Macht FIR-Koeffizienten recht übersichtlich. Auch nach 983 downloads noch nicht ein Bit Feedback. Muss wohl weitgehend funktionieren. :-) Gruß, Gerhard
Opencores mag anscheinend keine deep links mehr. www.opencores.org am linken Rand Projects arithmetic core SineAndCosineTable Gerhard
Bor vielen dank Gerhard!!! Das ist ja ein Super Tip! Werde ein Feedback schreiben :-) Bin echt total begeistert von eurerganzen Hilfe.
Lothar Miller schrieb: > Das Hauptproblem besteht darin, auch die Multiplikation von -1*-1 > halbwegs plausibel abzubilden, weil da ein Üblerlauf stattfinden wird: Deshalb plädiere ich auch bei der IQ-Modulation für eine Phasenverschiebung um 0,5 * 1/n wie ich es im Artikel Sinus-Generation beschrieben habe. Der Wert "1" wird niemals erreicht, er ist aber dennoch impliziert. Die andere Möglichkeit ist, von der pathologisch anzutreffenden Vollaussteuerung Abstand zu nehmen. Wenn ich sehe, dass in der Messtechnik ständig auf 10'3 und 10'6 gemessen und angezeigt wird, wäre es aus meiner Sicht nur natürlich die entsprechenden Skalierungen scho früh und vorne in die Rechnungen einzutreiben, in dem man nicht mit 1024 erweitert oder diese nach einer Multiplikationen belässt, sondern einfach mit 1000 erweitert. Damit bekomme ich fast Vollaussteuerung in der gesamten Kette und muss nicht ständig mit Überläufen und "n-1"-Problemen hantieren. Die verbleibenden 23 Werte eigenen sich auch hervorragend für Codes/Tests und Sonderfunktionen.
Lothar Miller schrieb: > Das Hauptproblem besteht darin, auch die Multiplikation von -1*-1 > halbwegs plausibel abzubilden, weil da ein Üblerlauf stattfinden wird: > -1*-1=1, und das ist größer als 0,999969. Ist zwar bisle offtopic aber ehrlich gesagt verstehe ich diese Argumentation nicht. Benutzt man Festkommazahlen mit Vorzeichen so werden sie binär denoch im 1-Komplement gespeichert, und das so skaliert das als reine Binärzahl betrachtet in Wahrheit garkeine Nachkommastellen mehr existieren. Somit ergibt sich für gebrochene Festkommazahlen immer einen Wertebereich der von +1 bis -(1-0.x) geht. Die 1 ist also in dieser Zahlendarstellung vorhanden und eine Multiplikation von +-1 * +-1 sollte auch +-1 ergeben, ohne Über/Unterlauf. Zurück zum Thema stehe ich auf dem Standpunkt das für diese Problemstellung garkeine Fixpoint Berechnungen notwendig sind, besonders nicht auf FPGAs die das Downscaling einer Ganzzahl durch "kostenlose" Verdrahtungen möglich sind. Dh. es ist easy auf einem FPGA nach einer Multiplikation zwei Ganzzahlen diese um /2^x runter zu skalieren. Ob der OT seine 28Bit wieder runterskaliert bevor er damit weiter rechnet entscheidet sich nur an Hand der Frage nach dem tolerierbaren Fehler. Insofern wurde schon im 2. Posting Beitrag "Re: Digital Down Converter Bitbreiten" korrekt geantwortet. Pauschal würde ich sagen: Ja, skaliere die 28Bit durch "Division mit 2^14" wieder runter bevor du damit weiterarbeitest. Denn es gilt erstmal: deine Inputsignale sind 14Bit breit mehr an Information wirst du nicht drinnen haben als diese 14Bit. Selbst wenn du nach der Multiplikation mit dem 28Bit Resultat weiter rechnest so hast du denoch nur 14Bit Dynamik im Gesamten (auf dein spezifische Problem bezogen mit dem IQ Mischer) Gruß Hagen
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.