Hallo zusammen, ich bin gerade an einem Funktionsgenerator dran. Nur zum Spielen und keine echte Anwendung. Der Frequenzbereich soll sich von 20Hz bis 20kHz erstrecken mit der Auflösung 1Hz. Das sind recht moderate Anforderungen, damit ich bei der Beschaltung und dem DAC auf günstige Audio-ICs setzen kann. Und das geht noch auf Lochraster. Die Implementierung ist so gemacht, dass mit dem Sampletakt für den DAC ein neuer Wert aus dem Speicher kommt (96kHz). Und genau beim Speicher kommen die Fragen auf. Der DAC hat eine Auflösung von 24bit. Die kann ich niemals voll ausnutzen. Aber wie würdet ihr das machen? Wie viel bit Auflösung sollten die Werte im Speicher haben und wie viele? Wenn ich hier spare, dann resultiert das in einem höheren Phasenrauschen. Oder würdet ihr für diese Anwendung (mit den Frequenzen) die Werte direkt mit einem Cordic rechnen und gar keine LUT nehmen? Für ein paar Anregungen würde ich mich freuen. Grüße, Jens
Moin, das kommt etwas auf deine genaueren Anforderungen an. Wie viel Speicher hast du zur Verfügung? Wie viele Zyklen hätte ein CORDIC zur Verfügung? Welches SNR/SFDR soll der Funktionsgenerator haben? Grundsätzlich kannst du beim DDS noch etwas bzgl. des SFDR rausholen, wenn du Dither oder eine Taylor-Korrektur verwendest, ohne dass die LUT übermäßig groß werden muss. Die Wortbreite am Ausgang des DDS bestimmt natürlich das maximale SNR.
Hallo Rezy, danke für die Hinweise. Ich habe keine Speziellen Anforderungen zu SNR/SFDR. Der DAC liegt im Bereich um -100dB. Was wäre denn die Empfehlung, wenn man da hin kommen will um die Performance des DACs voll zu nutzen. Und klar, mit Lochraster und so weiter bekommt man das niemals, aber für die theoretische Betrachtung würde ich das ins Auge fassen. Ich verwende einen Spartan 6 LX9. Der hat 32 18kb RAM Blöcke. Also insgesamt 576kBit. Gibt es einen Daumenwert wo man von Frequenz und Auflösung auf Tabellengröße kommt? Die Approxiamtion mit Taylorreihe und auch das Thema mit dem Dither hab ich gelesen, aber nichts konkretes über die Implementierung. Ich dachte, wenn man so etwas macht, könnte man die Werte auch gleich mit Cordic rechnen. Ist diese Annahme richtig von mir? Grüße
Hi, Ich habe vor ein paar Jahren mal eine Sin/cos-Tabelle auf opencores.org hochgeladen mit einem DDS als Testbett. Bisher kamen keine Beschwerden, abgesehen von Leuten, die mit ihrem Modelsim nicht klarkamen. Das ist in der Abteilung Mathe etc gelandet. Es ist reines VHDL, die Tabellen werden zur Compilezeit berechnet. Auflösung nach Amplitude und Phase und die Anzahl der Pipelinestufen sind frei wählbar. Mit einem Spartan-6 Evalboard bin ich WIMRE auf 200 MHz Takt gekommen, ohne besondere Anstrengungen. Gruß, Gerhard < https://opencores.org/projects/sincos > Oh, von wegen paar Jahre, das war 2010!
:
Bearbeitet durch User
Hallo Gerhard, das schau ich mir mal an. Vielen Dank für den Hinweis. Grüße, Jens
Jens W. schrieb: > Wie viel bit Auflösung sollten die Werte im Speicher haben und wie > viele? Wenn ich hier spare, dann resultiert das in einem höheren > Phasenrauschen. Das hängt wohl von DEINEN Ansprüchen ab, oder? Das müsstest du also klären und durchrechnen. Die Frage ist auch erst einmal, was der DDS-Generator liefern soll. Wenn es "nur" ein statischer Sinus sein soll, der sich nicht sprunghaft ändern können muss, geht das mit einem Schwingkreis 2. Ordnung erheblich einfacher, weil die DDS-Tabelle sehr lang sein müsste und zudem auch noch interpoliert werden sollte, um da ranzukommen: http://www.96khz.org/oldpages/sinesynthesisdds.htm Je nach Interpolationsfunktion braucht es gfs auch noch eine Filterung. Für den reinen Audiobereich würde eine 1-stufige DDS reichen, wenn man mit dem Jitter leben kann: http://www.96khz.org/oldpages/limitsofdds.htm (siehe Bild 3) In der Regel braucht man das in der Messtechnik aber zweistufig: Beitrag "Re: Universell programmierbarer DDS-Funktionsgenerator" Dann kann man mit der ersten DDS einen sehr sauberen Takt fein einstellen und auch eine oberwellenbehaftete Signalform korrekt abspielen.
Jens W. schrieb: > Die Implementierung ist so gemacht, dass mit dem Sampletakt für den DAC > ein neuer Wert aus dem Speicher kommt (96kHz). > Und genau beim Speicher kommen die Fragen auf. Der DAC hat eine > Auflösung von 24bit. Das sieht mir danach aus, daß du einen fertigen Audio-DAC verwenden willst. Sowas hat zumeist ein I2S-Interface, also müßtest du genau das liefern. Fertige DDS von AD haben ihren DAC selber drin und die haben eine Auflösung von 10..14 Bit je nach Schaltkreis. Und was den CORDIC betrifft: den kann man ausrollen und dann hat er auch bloß einen Takt Verzögerung pro tatsächlich berechnetem Bit. Was aber die meisten (C-)Programmierer vergessen, ist daß man nur so etwa 1/3 der benötigten Bits wirklich ausrechnen muß, wenn man den Rest mit verwendet. Man muß ihn nur wieder normieren, um die Verlängerung mit je 1/(cos(Schrittwinkel)) wieder rückgängig zu kriegen. Da wären für dein Vorhaben allenfalls 7 oder 8 CORDIC-Schritte nötig, die restlichen Bits liefert dann der Rest. Aber du brauchst da eben für jede Stufe einen separaten Satz von Operationen. Bei wieviel Bit das dann genauso viel Aufwand im FPGA ausmacht wie eine Tabelle, hängt natürlich vom konkreten FPGA ab. W.S.
Jens W. schrieb: > Hallo Rezy, > > danke für die Hinweise. > Ich habe keine Speziellen Anforderungen zu SNR/SFDR. > Der DAC liegt im Bereich um -100dB. > Was wäre denn die Empfehlung, wenn man da hin kommen will um die > Performance des DACs voll zu nutzen. > Und klar, mit Lochraster und so weiter bekommt man das niemals, aber für > die theoretische Betrachtung würde ich das ins Auge fassen. Moin, davon ausgehend, dass du etwa im Bereich von 100 dB SNR landen willst: Das SNR eines vollausgesteuerten Sinus mit Wortbreite w bits ist ungefähr SNR = 1.76 dB + w*6.02 dB (sofern w hinreichend groß ist). Du bräuchtest also mindestens 17 bits an Auflösung, um die 100 dB überhaupt zu erreichen. Das wäre die Breite jedes samples im LUT. Wenn du im Audio-Bereich arbeitest, möchtest du natürlich spektral reine Töne erzeugen, also eine große SFDR erreichen. Das Design des DDS bringt leider das Problem mit sich, dass die LUTs sehr schnell sehr groß werden. Deshalb wird das Phaseninkrement nach dem Akkumulator (die Momentanphase) abgeschnitten (requantisiert). Mit einer gewünschten Frequenzauflösung von 1 Hz bei fs=96 kHz benötigst du 17 bits für das Phaseninkrement (96e3/2^17 < 1). Die Wortbreite der Momentanphase bestimmt die nötigen Einträge deiner LUT. Wenn die Momentanphase nach Requantisierung eine Wortbreite von q bits hat, sollte das SFDR etwa 6*q dB betragen. Wenn du also bspw. auch hier etwa 100 dB erreichen willst, bräuchtest du q=17 bits (also wird nichts requantisiert). Bedeutet, dass du insgesamt 2^17*17 bits Speicher bräuchtest. Nun gibt es da einige Tricks.. Man muss lediglich eine Viertelwelle im RAM ablegen -> q=15 bits. Ist immer noch zu viel. Wenn du aber bspw. einen Dither vor der Requantisierung der Momentanphase addierst, verbesserst du das SFDR (sofern ich mich richtig erinnere) um etwa 12 dB. Das liegt daran, dass du den periodischen Requantisierungsfehler, der die Artefakte im Spektrum erzeugt, durch das Zufallssignal zerstörst. So bräuchtest du also "nur" noch q=13 bits + Dither.. Bessere Performance bietet aber noch die Taylor-Korrektur. Das ist die Interpolation von der Jürgen sprach. Diese kann man beliebig genau machen. In der Regel reicht eine Korrektur 1. Ordnung aus, mehr als 2. Ordnung benötigt man nicht. Der Trick ist, dass man den Fehler der Requantisierung kennt und mit diesem den Wert aus der LUT korrigiert. Selbst bei linearer Taylor-Korrektur sollte mit bspw. q=12 bits ein SFDR > 100 dB drin sein. Zusammenfassend bedeutet das: DDS mit Phaseninkrement 17 bits, requantisierter Momentanphase q=12 bits (für volle Periode) sowie w=17 bits Wortbreite am Ausgang sollte voraussichtlich für deine Anforderung genügen, wenn du eine lineare Taylor-Korrektur vornimmst. Da du nur 10 der 12 bits für das RAM benötigst (Viertelwelle), wären das 17408 bits im RAM. Das passt in einen 18K BRAM ;) Dabei sei aber noch erwähnt, dass höhere zu synthetisierende Töne (in Bezug auf fs) zu Artefakten führen. Zum Einen hast du hinter dem DAC natürlich den Einfluss des sinc, zum Anderen stören die Spiegelfrequenzen zunehmend -> die Anforderungen an das Rekonstruktionsfilter steigen.
Hallo zusammen, vielen Dank für die vielen Ideen und Hinweise. Das hilft mir echt weiter. Um es vorweg zu nehmen: Ich möchte keine Musik damit machen, sondern eher ein LCR-Meter. Dafür möchte ich den Audiobereich nehmen, da die ADCs und DACs günstig und einfach verfügbar sind. Wie gesagt, das ist zum Spielen und Lernen. Da will ich nicht unbedingt eine extra Leiterplatte entflechten. Das muss auf Lochraster mit Minimalaufwand gehen. Als ADC möchte ich den PCM1808 nehmen und als DAC den PCM5102. Das Interface ist schon fertig. Laut Testbench funktioniert das. Da kommen auch schon die richtigen Werte aus dem DDS raus. Die Tabelle für den Sinus habe ich im Moment mit 12bit länge und 14bit Auflösung abgelegt (den vollen Sinus). Ich dachte, dann kann ich noch einen Gain mit 10bit einsetzen und komme so auf die maximalen 24bit. So wird der erste Test aussehen. Ich lade euch Bilder hoch wenn ich soweit bin. Zu der Interpolation: Kennt ihr da Quellen wo ich das genauer nachlesen kann? Was ein Dither ist oder eine Taylorreihe weiß ich, aber wie man die Korrektur damit macht fällt mir noch schwer zu verstehen. Und noch eine Frage zur Messtechnik: Wie kann ich denn messtechnisch bestimmen, ob das nun taugt oder nicht? Mit dem Oszi wird vermutlich alles gut aussehen oder? Um da genau ein Bild zu bekommen muss ich einen Spektrum Analyser nehmen oder? (aber die -100dB wird man zu Hause nie messen können mit "normalem" Equipment) Grüße, Jens
Rezy schrieb: > q=15 bits. Ist immer noch zu viel. Wenn du aber bspw. einen Dither > vor der Requantisierung der Momentanphase addierst, verbesserst du das > SFDR > (sofern ich mich richtig erinnere) um etwa 12 dB. Das kann man so pauschal nicht sagen. Wenn das eine günstige, ganzzahlig passende Frequenz ist, gibt es keinen Phasensprung und man hat nur Quantisierungsrauschen und dessen Dämpfung durch die Interpolation. Mit einem ungünstigen Wert, sehr knapp neben einer Ganzzahl, liegt der in der Frequenz sehr tief, weil es selten Sprünge gibt und dem ist auch mit Phasen-Dither / Amplituden-Dither nicht beizukommen, bzw. man handelt sich sehr viel einzuprägendes Ditherrauschen ein, für wenig Effekt. Bei der (eigentlich anspruchsvollen) Audiosignalsynthese gibt es da aber einen erleichternden Vorteil gegenüber der Messtechnik, weil dieser niederfrequente Anteil in der Amplitude so gering ist, dass er unter die physiologische Erkennungsgrenze fällt. Je nach Autor sind das frequenzabhängig 40dB-50dB Abstand zum dominanten Ton. Ich habe das selber bei meinem Synth untersucht und nutze da aber schon größere Phasenvektoren sowohl für die Erzeugung des Sinus als auch bei der Interpolation über den Restvektor und einen zusätzlichen Interpolationsfilter. Bei messtechnischen Anwendungen (Audiosignaltestgenerator) geht es nochmal sehr viel genauer. Wohlgemerkt bereits schon beim Sinus. Und in beiden Fällen auch mit mehr als 96kHz. Jens W. schrieb: > Wie kann ich denn messtechnisch bestimmen, ob das nun taugt oder nicht? Gute Oszis können ein Spektrogramm aufnehmen und den THD direkt anzeigen. Auch freeware-Programme können das vereinzelt. Braucht dann eben einen guten AD-Wandler. Beginnen kannst du auch mit deiner PC-Soundkarte. Ansonsten hast du ja einen FPGA. Dort kann man sehr leicht einen Spektrumanalyzer einbauen: http://www.96khz.org/htm/spectrumanalyzer2.htm
Jens W. schrieb: > Die Tabelle für den Sinus habe ich im Moment mit 12bit länge und 14bit > Auflösung abgelegt (den vollen Sinus). > Ich dachte, dann kann ich noch einen Gain mit 10bit einsetzen und komme > so auf die maximalen 24bit. > So wird der erste Test aussehen. Ich lade euch Bilder hoch wenn ich > soweit bin. Damit wirst du aber keine 100 dB erreichen. Auch mit dem 10 bit gain bleibt deine echte Auflösung natürlich bei 14 bit. > Zu der Interpolation: > Kennt ihr da Quellen wo ich das genauer nachlesen kann? Was ein Dither > ist oder eine Taylorreihe weiß ich, aber wie man die Korrektur damit > macht fällt mir noch schwer zu verstehen. Kurze Recherche zu Dither (da ist auch ein noise shaping approach beschrieben): https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.736.9526&rep=rep1&type=pdf Zur Taylor-Korrektur: Die inkrementelle Taylorreihe ist (zeitkontinuierlich gesehen)
t+h wäre die Momentanphase vor Requantisierung. t ist die Momentanphase nach Requantisierung, h ist der abgeschnittene Anteil (der Fehler). Interessiert nur die lineare Korrektur und möchte man einen Sinus generieren, folgt
Der erste Teil plumpst direkt aus deinem LUT raus. Das muss korrigiert werden mit dem Fehler (h) multipliziert mit der Ableitung des Wertes. In Gerhards link ist das aufgezeigt. Alternativ kannst du auch den gleichen BRAM verwenden und nur an eine an die Adresse schauen, das BRAM beinhaltet ja ebenso den Wert für den cos, nur an anderer Adresse ;) > Und noch eine Frage zur Messtechnik: > Wie kann ich denn messtechnisch bestimmen, ob das nun taugt oder nicht? > Mit dem Oszi wird vermutlich alles gut aussehen oder? Um da genau ein > Bild zu bekommen muss ich einen Spektrum Analyser nehmen oder? > (aber die -100dB wird man zu Hause nie messen können mit "normalem" > Equipment) Ich würde die Algorithmik zunächst in Matlab/Octave simulieren, um zu überprüfen, dass das gewünschte SNR/SFDR erreicht wird. Daraufhin kannst du deine Implementierung mit einer Testbench prüfen und die generierten Werte auch nochmal in Matlab/Octave bzgl. SNR/SFDR untersuchen. Somit erschlägst du zumindest alles auf digitaler Seite und kannst dir sicher sein, dass es so funktioniert wie gewünscht. Wenn alles stimmt, das Scope oder Spectrum Analyzer anschließen. Dein Scope wird aber nicht die Auflösung haben, um das zu bestätigen, sofern du ein hohes SNR erreichst..
Jürgen S. schrieb: > Rezy schrieb: >> q=15 bits. Ist immer noch zu viel. Wenn du aber bspw. einen Dither >> vor der Requantisierung der Momentanphase addierst, verbesserst du das >> SFDR > (sofern ich mich richtig erinnere) um etwa 12 dB. > Das kann man so pauschal nicht sagen. Wenn das eine günstige, ganzzahlig > passende Frequenz ist, gibt es keinen Phasensprung und man hat nur > Quantisierungsrauschen und dessen Dämpfung durch die Interpolation. Mit > einem ungünstigen Wert, sehr knapp neben einer Ganzzahl, liegt der in > der Frequenz sehr tief, weil es selten Sprünge gibt und dem ist auch mit > Phasen-Dither / Amplituden-Dither nicht beizukommen, bzw. man handelt > sich sehr viel einzuprägendes Ditherrauschen ein, für wenig Effekt. Ja, bei speziellen Fällen fällt das SFDR ohnehin höher aus, da bringt der Dither natürlich nichts, sondern reduziert nur das SNR geringfügig. Das gilt eben immer bei speziell gewählten Frequenzen. Ohne das jemals getestet zu haben, würde ich schätzen, dass man deinem zweiten Beispiel eigentlich entgegenwirken können müsste, wenn die PN-Sequenz nur lang genug ist.
Hallo zusammen, da hab ich ja gut zu lesen! Danke dafür. Jetzt hab ich gleich mehrere Möglichkeiten parallel. das mit dem Dither gefällt mir sehr gut. Das wäre ein Ansatz. Bleibt aber noch offen, was ich anfangs mit dem Cordic gefragt habe. Den Cordic für Sinus und Cosinus gibt es ja auch als IP-Core. Wenn ich den in der vergleichbaren Vektorbreite (also 24bit) nutze, wie sieht es dann mit dem Rauschen aus. Das müsste dann doch genauso gut sein, wie ein Sinus aus Tabelle mit Dither oder Taylor-Reihe. Ich meine, ich spreche von 96kHz. Da kann man ganz locker die Werte in Echtzeit mit Cordic erzeugen. Dann brauch ich nicht viel machen. Core nutzen und drumrum nur das Datenformat anpassen. Oder spricht da was dagegen? Grüße, Jens
Jens W. schrieb: > Oder spricht da was dagegen? Eigentlich nichts. Außer daß du sowas ausprobieren mußt, denn manche IP-Cores lassen sich nur auf bestimmten FPGA machen, weil sie bestimmte auf dem Silizium installierte Funktionsblöcke benutzen. Und wenn davon nix oder zu wenig da ist, dann geht es eben nicht. Jedenfalls in der gewünschten Bitbreite. Ich habe ja nicht umsonst von der Resteverwertung beim Cordic geschrieben, eben um die Anzahl der berechneten Bits möglichst klein zu halten. W.S.
Jens W. schrieb: > Bleibt aber noch offen, was ich anfangs mit dem Cordic gefragt habe. > Den Cordic für Sinus und Cosinus gibt es ja auch als IP-Core. > Wenn ich den in der vergleichbaren Vektorbreite (also 24bit) nutze, wie > sieht es dann mit dem Rauschen aus. > Das müsste dann doch genauso gut sein, wie ein Sinus aus Tabelle mit > Dither oder Taylor-Reihe. Ja, geht auch. Je mehr bits, desto größer wird im Allgemeinen eben die Latenz - 1 cycle pro bit. Bei 96 kHz problemlos machbar. Das SNR wird bei 24 bits am Ausgang groß genug sein, sofern die interne Präzision für die Berechnungen groß genug ist. Bei Xilinx IP cores sollte das gegeben sein. Natürlich hängt das Ergebnis aber weiterhin auch von der Momentanphase ab.
Rezy schrieb: > Ohne das jemals getestet zu haben, würde ich schätzen, dass man deinem > zweiten Beispiel eigentlich entgegenwirken können müsste, wenn die > PN-Sequenz nur lang genug ist. Du meinst das Rauschen zum Dithern? Das für die Amplitude ist weis im Bereich 16kHz - 96kHz bei 768kHz Samplefrequenz und damit eng repetierend. Es ist so, dass in dem späteren Dezimationsfenster, wenn von 768kHz auf 192kHz reduziert wird, jede Summe über die Samples des Rauschens Null ergibt. Erzeugt mit dedizierten Zahlen, keine PRN. Wenn man etwas für 96k machen möchte, würde ich von 8kHz bis 48kHz gehen. Da ist aber wenig headroom. Das für die Phase ist eine Eigenentwicklung, die ich nicht publiziert habe. Generell kommt auch hier wieder zum Tragen, dass man beim Audio weniger Probleme hat, weil praktisch alle gleichförmigen Wellen entweder im statischen Amplitudenfall ein Vibrato haben und im Fall der Tansiente bei konstanter Frequenz eine ADSR-Kurve, die indirekt die Tonhöhe etwas moduliert, wodurch sehr viel kaschiert wird. Für die Messanwendungen hilft es für die Phasenthematik am Ende nur, sehr gut zu interpolieren. Für eine Anwendung, die Sinüsse im Bereich MHz zu liefern hatte (bei damals langsamen FPGAs), hat man dann einfach kaum oversampling headroom und leider ist auch der CORDIC zu langsam gewesen. Daher SIN und COS hochgenau in Tabellen, beides gegeneinander genutzt, um zu interpolieren, alle Werte für Oberwellen aus parallelen Tabellen, pipelined ADD/MUL, dann für alle Kanäle parallel in glättende IIR-Filter und ab damit in die IQ-Kanäle. Mit einem heutigen FPGA könnte man eine einzige Tabelle pro Kanal für alle Oberwellen nehmen und hätte noch mehr 1-2 mehr Wellen frei.
Hallo zusammen, es gibt ein kleines Update: Ich habe mich nun mit dem Cordic IP Core von Xilinx auseinandergesetzt. Der verwendet ein besonderes Fixed Point Datenformat. Da müsste ich viel manuell machen, damit man das zum laufen bekommt. Direkt von einem Integer Laufindex (das ist ja mein Phaseakkumulator) auf diesen Datentyp wandeln geht leider nicht. Daher habe ich das wieder verworfen. Was ich nun gemacht habe: Ich bin zu meiner ursprünglichen Lösung mit dem Speicher zurück. Habe nun die Werte in der vollen Auflösung abgelegt (24bit) und 4096 Werte in der Länge. Da habe ich auch noch genügend Ressourcen übrig für andere Dinge. Ich habe nun beim DDS die Akku-Truncation weg gelassen und verwende die volle Breite. Ich hole mir immer den nächst höheren Wert und interpoliere linear. So bekomme ich einen guten Kompromiss zu Aufwand und Speicherauslastung. Damit werde ich die ersten Versuche mal fahren mit dem DAC. Bisher habe ich ja immer nur im Simulator getestet. Die -100dB erreiche ich damit natürlich nicht, aber ich komme für die Anwendung (Sinuserzeugung für LCR-Meter) sicher weit genug runter, dass man da keinen Einfluss mehr merkt. Danke euch allen! Grüße, Jens
Jens W. schrieb: > 4096 Werte in der Länge. + > beim DDS die Akku-Truncation weg gelassen und verwende die volle Breite = 12 Bit Phase für den Viertelbogen -> 14 Bit für den Sinus. Da sollten auch 14 Bit für den Wert reichen. Da nur die positiven Zahlen hinterlegt sind, auch 13 Bit. Ich würde behaupten, dass 12 dann auch nicht mehr Fehler machen und du mit der halben Auflösung fast das Gleiche erreichst.
Jens W. schrieb: > Ich habe mich nun mit dem Cordic IP Core von Xilinx auseinandergesetzt. > Der verwendet ein besonderes Fixed Point Datenformat. Da müsste ich viel > manuell machen, damit man das zum laufen bekommt. Direkt von einem > Integer Laufindex (das ist ja mein Phaseakkumulator) auf diesen Datentyp > wandeln geht leider nicht. > Daher habe ich das wieder verworfen. Eigentlich hat man das "besondere Fixed Point Format" bei allen Dingen, die nach DSP-Funktionalität riechen. Genauer gesagt, sind da mehrere definiert. Warum bereitet dir das Probleme? Bedenke mal, daß Sinus und Cosinus im Bereich von -1 bis +1 leben und daß damit immer Zweierpotenzen kleiner als 1 Mode sind. Noch putziger wird das für unbedarfte Zuschauer, wenn dann noch der Winkel auf Werte 0 .. 3.999... normiert wird. Aber auch das macht man aus Gründen der rechentechnischen Vereinfachung, weil damit der Quadrant eben schon richtig vor dem 'Dezimal'-Punkt steht. Die menschliche Sichtweise im Dezimalsystem und Pi=3.1415usw. ist rechentechnisch eher ungünstig. Bei der Gelegenheit frage ich mal, wie du dir die Darstellung deiner Stützstellen und deren interpolierten Ausgabe denn so vorstellst? W.S.
W.S. schrieb: > Noch putziger wird das für unbedarfte Zuschauer, wenn > dann noch der Winkel auf Werte 0 .. 3.999... normiert wird. Arbeiten neue FPGAs jetzt mit float? Der Definitionsbereich des Sinus ist nach wie vor -pi bis pi, egal wie das umgerechnet wird. 0...3.999 machen für mich keinen Sinn.
Angehängte Dateien:
@W.S.: Bei dem Core von Xilinx für den Cordic ist der Eingang für die Phase im 2QN Format. Also drei Stellen vor dem Punkt und dann je nach Auflösung N stellen nach dem Punkt. Für die Positiven Werte ist das kein Problem. Da muss man nur den Wertebereich begrenzen und gut ist es. Aber im negativen Bereich weichen die (so wie es mir scheint) von der Zweierkomplement Darstellung ab. So steht es im Datenblatt: "01100100100" => 011.00100100 => +3.14 "10011011100" => 100.11011100 => - 3.14 Für den positiven Bereich passt das. Man kann die Vorkommastelle und die Nachkommastelle separat betrachten und sich das aus dem Laufindex (DDS Akku) berechnen. Aber für negative Zahlen geht das nicht -3 sind nicht "100", sondern "101". Für nach dem Punkt stimmt es wieder. Bei 8 Bit kann ich 256 Werte darstellen. 256*0.14 sind gerundet 36. Und -36 sind "11011100". Aber wie sie auf die "100" für die -3 ist komisch. Da bin ich noch nicht dahinter gestiegen. Grüße, Jens
Dann dachte ich, ich rechne alles in Float und nehme vom Float-Core die Typumwandlung. Aber das geht nicht, da der Core nicht in dieses Format vom Cordic direkt wandeln kann.
Georg B. schrieb: > Arbeiten neue FPGAs jetzt mit float? Der Definitionsbereich des Sinus > ist nach wie vor -pi bis pi, egal wie das umgerechnet wird. 0...3.999 > machen für mich keinen Sinn. Ach nö. 3.999.. sind zwei Bit vor dem (gedachten) 'Dezimal'-Punkt und die übrigen danach. W.S.
Jens W. schrieb: > "01100100100" => 011.00100100 => +3.14 > "10011011100" => 100.11011100 => - 3.14 Eigentlich nicht, das ist schon komplementär - konkret bis zur letzten sichtbaren Stelle völlig bit-invers. Das "Komplement" entsteht an der letzten, nicht sichtbaren Stelle, wenn es zu 2 addiert. Das Problem dieser Darstellung ist, dass es nicht eindeutig ist, wie der binäre Wert auf den tatsächlichen übersetzt, wenn die Stellen nicht 1:1 ausgeführt sind. Viele Cores rechnen z.B. bei Sinus16 (0000) = sin (0) und bei Sinus32 (00000) auch mit sin (0). Das ist streng genommen aber falsch und führt zum "Zaunpfahlproblem" wie ich es gerne erkläre: Es gibt n nulldimenionale Punkt, die Pfähle und n-1 eindimensionale Zwischenräume. Nach meiner Auffassung sollte die Repräsentation von Wertebereichen immer durch den Mittelpunkt erfolgen und nicht durch den Anfangspunkt, es sei denn man nimmt zwei Punkt und die Reste des nicht verwendeten Vektors zur Interpolation. Siehe dazu auch meine Ausführungen im Artikel zur digitalen Sinusfunktion und der Bildung eines voll symmetrischen Wertebereiches. Die Schwierigkeit ist nämlich die, zwei unterschiedliche Cores oder zwei abweichende Darstellungen (und da eben auch unterschiedlicher Skalierung desselben Cores) mit einander zu verrechnen: Beim 16 Stellen-Sinus entsteht beim Übergang zum 32-Stellen-Sinus ein offset, den es bei mir z.B. nicht gibt. Das führt dann regelmäßig zu Problemen bei updates und Umskalierungen von Schaltungen. Das Problem hat man oft auch im Übergang durch die Nullstelle / den Spiegelpunkt: Die binäre Darstellung hat im Negativen immer 1 mehr und ist damit automatisch unsymmetrisch. Das lässt sich 1:1 nicht auf eine solche Funktion abbilden, wenn man die Zaunpfähle adressiert, statt die Mitten. Leider hat sich das so etabliert und es entsteht damit Freiraum für Interpretation. Insbesondere im Inneren der Cores, weis so niemand, welche Stelle dann tatsächlich adressiert wird - außer dem Xilinx-Programmierer. Um das Problem zu verdeutlichen empfehle ich, das, was die Firma Xilinx mit ihrem Cordic / der DDS beim Durchgang von z.B. 10 Bit Phasen ausgibt und was mein DDS-Core ausgibt mit dem zu vergleichen, was beide bei 12 Bit ausgeben und wie das zusammenpasst. Von daher bevorzuge ich die natürliche Darstellung der Vektoren in Punkten und mache die Rundung und Interpretation des Phasenvektors selber.
Audiomann schrieb: >> beim DDS die Akku-Truncation weg gelassen und verwende die volle Breite > = 12 Bit Phase für den Viertelbogen -> 14 Bit für den Sinus. > Da sollten auch 14 Bit für den Wert reichen. Die Sache ist noch mehr tricky: Der Phasenfehler in Bit in Relation zu dem der Amplitude macht aus 2 Gründen mehr Probleme: a) Man benötigt 2xPI=6 mal mehr Auflösung für die Phase, um in Kästchen gedacht, den maximalen Fehler (Steigung Sinus = 1) in der gleichen Größenordnung zu haben. Das wären also 2.5 Bit. Im Durchschnitt der statistischen Steigungen reichen wohl 1.5 Bit. Diese Überlegung stellen die meisten an, "addieren" die Viertelbogentheorie und kommen auf dieselben Werte. Aber: b) Der Quantisierungfehler liefert bei jedem Bit (wenn man die Phasen statistisch anlegt und irgendwelche Wellen produziert) einen neuen Fehler, der sich in einem stark statistischen Rauschen abbildet, welches einen großen hochfrequenten Anteil besitzt, der sich gut filtern lässt - insbesondere bei hohen Samplefrequenzen. Der Phasenfehler erstreckt sich hingegen beim gleichmäßigen Phasendurchgang der DDS über jeweils längere Zeitabschnitte und produziert einen großen tieffrequenten spektralen Anteil, der sich nur schlecht filtern lässt. Mein Tipp bleibt daher der, wie ich es schon öfters gepostet habe, die Phase in Relation wegen a) um 1-2 Bit und wegen b) um weitere 1-2 Bit genauer zu machen, als die Amplitude. Für weiße Spektren ohne Betonung auf irgendeiner Frequenz, sind als also z.B. 3 Bit. Für Audio und der dort speziellen Randbedingungen ("rosa Profil") wäre noch mehr Fokus auf b) zu legen und damit eher 4 Bit. Davon ausgehend bringt man nun die Speicherung von 90 Grad ins Spiel und spart bei der Amplitude 1 Bit und der Phase 2 Bit, damit sind es wieder 3. Bei einem FPGA mit 9 Bit-RAMs wäre also eine Phase von 12 Bit je Quadrant angemessen. Wenn man nun geschickt dithert, profitiert die Phasengenauigkeit mehr, als die Amplitude. Dann sind auch wieder mehr Bits an Auflösung sinnvoll.
Jens W. schrieb: > Ich habe nun beim DDS die Akku-Truncation weg gelassen und verwende die > volle Breite. > Ich hole mir immer den nächst höheren Wert und interpoliere linear. > So bekomme ich einen guten Kompromiss zu Aufwand und Speicherauslastung. Wie genau interpolierst du denn, wenn du nichts abschneidest? Nimmst du den Mittelwert aus dem derzeitigen Wert und dem nächst höheren? > So steht es im Datenblatt: > "01100100100" => 011.00100100 => +3.14 > "10011011100" => 100.11011100 => - 3.14 > > Für den positiven Bereich passt das. Man kann die Vorkommastelle und die > Nachkommastelle separat betrachten und sich das aus dem Laufindex (DDS > Akku) berechnen. > Aber für negative Zahlen geht das nicht -3 sind nicht "100", sondern > "101". > Für nach dem Punkt stimmt es wieder. Bei 8 Bit kann ich 256 Werte > darstellen. 256*0.14 sind gerundet 36. Und -36 sind "11011100". > > Aber wie sie auf die "100" für die -3 ist komisch. Da bin ich noch nicht > dahinter gestiegen. Das ist schon die korrekte Darstellung im Zweierkomplement: 100.11011100 -> -1 * 2^2 + 0 * 2^1 + 0 * 2^0 (.) + 1 * 2^(-1) + 1 * 2^(-2) + ...
Hallo Rezy, Zur Zahlendarstellung: Danke, das kommt hin, da muss ich nochmal nachrechnen. Aber wie ich nun die Werte umrechne, das fällt mir trotzdem noch schwer. Wie gesagt, mein Phasen-Akku hat einen Integer Wert. Und das ist der Laufindex für den Speicher. Der ist unsigned. Und wie komme ich nun zum Zahenformat vom Cordic Core? Gibt es da eine einfache Abbildungvorschrift? Da stehe ich auf dem Schlauch. Zur Interpolation: Ich versuche die Interpolation nochmal genauer zu beschreiben. Die Werte, die ich im Speicher abgelegt habe sind 4096 24bit-Werte. Das was ich mit Truncation geschrieben habe ist vermutlich nicht ganz richtig. Ich greife ja nicht mit 20bit auf den Speicher zu, das ist ja die Truncation. Das DDS-Akku hat 20 bit. Ich interpretiere den Sinus nun eigentlich als 12.8 Wert. Also 12bit vor dem Punkt als echten Wert aus dem Speicher und die 8bit nach dem Punkt sind die Interpolation (der Bruchteil). für die 12bit Werte nehme ich den aktuellen, und den nächst höheren. Und die Zwischenräume interpoliere ich mit 256 linear verteilten Stützstellen. Als Beispiel mit willkürlich gewählten Zahlen: Sinus_low = Wert von Adresse 1000 Sinus_high = Wert von Adresse 1001 Sinus_quotient = (Sinus_high - Sinus_low)/(120/256) Siunus = Sinus_low + Sinus_quotient Grüße, Jens
Jürgen S. schrieb: > Man benötigt 2xPI=6 mal mehr Auflösung für die Phase, um in Kästchen > gedacht, den maximalen Fehler (Steigung Sinus = 1) in der gleichen > Größenordnung zu haben. Ähem... Es ist nach meiner Rechnung nicht 6 sondern 3. Das wegen der Tatsache, daß ein Vollkreis zwar 2PI umfaßt, der Sinus hingegen dabei von -1 bis +1 reicht. Das macht, daß sich die 2 heraushebt. Jens W. schrieb: > Bei dem Core von Xilinx für den Cordic ist der Eingang für die Phase im > 2QN Format. Also drei Stellen vor dem Punkt und dann je nach Auflösung N > stellen nach dem Punkt. > Für die Positiven Werte ist das kein Problem. Also so langsam verwirrst du mich. Normalerweise kann man mit gemischtgebrochenen Zahlen fast genauso rechnen wie mit ganzen Zahlen, wenn man bedenkt, daß bei der Multiplikation Integerzahlen nach links wachsen, während gebrochene Zahlen nach rechts wachsen. Ich sehe dieses 2QN Format etwa so: VGG.bbbbbbbbbbbbbbbbb wobei V=Vorzeichen, G=Ganzteil, b=gebrochener Teil Und soweit ich das sehe, brauchst du als Argumente für den Cordic keine negativen Zahlen. Denn dein Winkel läuft ja von 0 an ins Positive, um dann bei Überstreichen des Vollkreises wieder auf Werte ab 0 zu gehen. Das ist eben der Überlauf. Das Einzige, was ich da an Nachzulesendem fände, wäre die Skalierung des Vollkreises, also ob der 0..2PI oder 0..360 oder 0..1 oder (wie ich vermute) 0..4 geht. Präziser gesagt 0..(4 - 1LSB) also salopp 0..3.99999 oder so. W.S.
Hallo, ich glaube auch, dass wir aneinander vorbei reden. So steht es im Datenblatt zum Cordic-Core: The phase signals are always represented using a fixed-point 2’s complement number with an integer width of 3 bits. W.S. schrieb: > Ich sehe dieses 2QN Format etwa so: > VGG.bbbbbbbbbbbbbbbbb > wobei V=Vorzeichen, G=Ganzteil, b=gebrochener Teil Das von dir geschriebenen passt nur zu den für den positiven Wertebereich. Der Core akzeptiert das aber nicht. Der braucht als Eingang für die Phase: -PI <Phase < Pi Und wenn ich Werte in den negativen Wert konvertiere im Zweierkomplement, dann werden die Bits invertiert und 1 addiert. Das passt aber nicht zu dem Beispiel aus dem Datenblatt: 100.11011100 => - 3.14 Grüße, Jens
Jens W. schrieb: > Und wenn ich Werte in den negativen Wert konvertiere im > Zweierkomplement, dann werden die Bits invertiert und 1 addiert. > Das passt aber nicht zu dem Beispiel aus dem Datenblatt: > 100.11011100 => - 3.14 Moin, doch, das passt. 3.14 -> 011.00100100 Bits invertieren: 100.11011011 +1 LSB: 100.11011100 Du kannst auch scaled radians auswählen. Dann muss der Eingang zwischen [-1,1] liegen. Der input ist immer noch 2QN. Also max. 001.0000.. und min. 111.0000.. Dabei entspricht 001.0000.. pi rad und 111.0000.. -pi rad. Deine Momentanphase ist ein unsigned integer. Bsp. 10 bit: zwischen 0000.. und 0111.. deckst du [0,pi) ab, zwischen 1000.. und 1111.. deckst du [pi,2*pi) ab. Wenn du also einfach eine sign extension um 2 bits vornimmst, deckst du den Bereich korrekt ab, sofern du scaled radians verwendest. Oder übersehe ich hier gerade etwas? 0000.. wird zu (00)0000.. -> Interpretiert als 000.0000... -> 0 rad 0111.. wird zu (00)0111.. -> Interpretiert als 000.1111... -> pi rad - 1LSB 1000.. wird zu (11)1000.. -> Interpretiert als 111.0000... -> -pi rad (=pi rad) 1111.. wird zu (11)1111.. -> Interpretiert als 111.1111... -> 2*pi rad - 1LSB (=0 rad - 1LSB)
Hallo Rezy, bin ich blind! Ok, jetzt hab ich das gerafft! Recht herzlichen Dank! Jetzt macht es Sinn was da steht! Grüße, Jens
W.S. schrieb: > Es ist nach meiner Rechnung nicht 6 sondern 3. Das wegen der > Tatsache, daß ein Vollkreis zwar 2PI umfaßt, der Sinus hingegen dabei > von -1 bis +1 reicht. Das macht, daß sich die 2 heraushebt. Kommt drauf an, wie man rechnet: 0 bis 2 PI sind 6 Einheiten gegen 1, der Faktor 2 der Amplitude steckt bei mir weiter unten in der Betrachtung des letzten Satzes. Ist aber etwas undurchsichtig formuliert. In jedem Fall kam es mir darauf an, die Wichtigkeit der Phase einzubringen. Wie gesagt, kommt man in der Größenordnung um einige Bits mehr raus, braucht umgekehrt gedacht, für die Amplitude weniger Bits, als für die Phase. Das gilt soweit für einen Sinus. Wenn man andere Wellenformen speichert, die einen höherfrequenten Anteil haben, kommt noch mehr a) ins Spiel. Dann ist die Steigung sehr oft deutlich größer, als 1 und man benötigt weitere 2-3 Bits um (auch mit Bogeninterpolation) die Welle noch abspielen zu können. Bei nicht symmetrischen Wellenformen fällt die 90-Grad Betrachtung weg und es sind wieder bis zu 2 Bit mehr. Für ein Pseudorechteck als nichtsymmetrischer PWM-Impuls mit Oberwellen bis zur 7. Hamonischen kann man dann für die Phase gerne weiter 3-4 Bits mehr veranschlagen. Was jetzt wieder hinzu kommt, ist die die Phaseninterpolation und Dithern:
Angehängte Dateien:
-
sinus_dds_error.gif
68 KB
Ein Beispiel: Eine Phase von 10 Bit mit Viertelbogen zu 8 Bit und nur 32 Punkten nach meiner Sinusfunktion in Artikel erzeugt bei linearer Interpolation für eine ganzzahlig passende Frequenz Fehler im Bereich von "nur" 200ppm (rote Funktion um Faktor 1000 verstärkt) und rechtfertigt eine Auflösung von etwa 8192! Die Oberwellen liegen um Faktor 32 höher, als die Nutzfrequenz - bei 1kHz z.B. praktisch irrelevant. So bekommt man mit praktisch null Tabellenaufwand (geht als LUTs) einen super Sinus. Aber wehe man nimmt eine Frequenz, die um z.B. um 0,5% verstimmt ist, dann gibt es eine fette Fehlerfunktion, weil irgendwann der Phasensprung eingeholt wird. Man bekommt also nicht diese Frequenz, sondern zusammengebastelte Fragmente der Ganzzahlfrequenz, also eine Art verkappte Granularsynthese. Der Fehler springt dann mit sehr viel tieferer Frequenz, als die Nutzfrequenz und das lässt sich nicht mehr Filtern. Da bleiben nach dem AA-Filter (gelbe Kurve) immer Reste und es hilft auch erstmal keine erhöhte Abtastrate. Die Genauigkeit liegt hier im Beispiel bei gerade noch 8 Bit. Mit Dither (Bild 2) von einer halben Phasenpunktbreite geht es schon mal ordentlich runter, es entstehen aber schon bis zu 2 Digit an Rauschen. Man kann das noch ein wenig günstiger gestalten, wenn man noch mehr dithert und dabei höher abtastet und auch noch etwas mehr Rauschen im Nutzband akzeptiert. Eine richtige Abhilfe ist aber nur: Mehr Phasenpunkte und irgendwann auch eine bessere Interpolation.
:
Bearbeitet durch User
Jens W. schrieb: > Hallo Rezy, > > bin ich blind! > Ok, jetzt hab ich das gerafft! Recht herzlichen Dank! > Jetzt macht es Sinn was da steht! > > Grüße, Jens Gerne! Jürgen S. schrieb: > b) Der Quantisierungfehler liefert bei jedem Bit (wenn man die Phasen > statistisch anlegt und irgendwelche Wellen produziert) einen neuen > Fehler, der sich in einem stark statistischen Rauschen abbildet, welches > einen großen hochfrequenten Anteil besitzt, der sich gut filtern lässt - > insbesondere bei hohen Samplefrequenzen. Der Phasenfehler erstreckt sich > hingegen beim gleichmäßigen Phasendurchgang der DDS über jeweils längere > Zeitabschnitte und produziert einen großen tieffrequenten spektralen > Anteil, der sich nur schlecht filtern lässt. Ich finde diese Formulierung ohne Detailwissen irgendwie sehr schwierig nachzuvollziehen, stimme dem aber zu. Ich versuche das mal etwas klarer mit meinen Worten darzustellen, falls andere deine Erklärung auch nicht so richtig nachvollziehen können: Der Quantisierungsfehler (Amplitudenquantisierung) ist näherungsweise spektral weiß, sofern die Wortbreite des Sinus hinreichend groß ist. Durch ein weiteres Überabtasten erzielt man einen zusätzlichen SNR-Gewinn, bezogen auf die eigentlich gewünschte Bandbreite, weil sich die gleiche Quantisierungsrauschleistung auf ein größeres Band verteilt. Der durch die Abschneidung entstehende Phasenfehler (Phasen-Requantisierung) ist beim DDS zwangsweise periodisch und gleicht letztendlich einer abgetasteten Sägezahnfunktion. (Bei speziellen Frequenzen entsteht natürlich kein Phasenfehler). Die Grundfrequenz des Sägezahns hängt von der gewählten Frequenz und fs ab. Dieser Fehler limitiert das SFDR und liegt im worst case eben etwa 6*q dB unter dem generierten Sinus (q ist Wortbreite der abgeschnittenen Phase). Das Spektrum des Phasenfehlers hat also unendlich viele Harmonische der Grundfrequenz. Diese spiegeln sich aufgrund der zeitlichen Diskretisierung stets ins Band bis fs/2 zurück. All diese Spiegelungen tauchen als "spurs" im generierten Ton auf und sind natürlich auch nicht wegzufiltern, da sie quasi "wirr" im gesamten Band auftreten und überall liegen können - das hängt eben vom Verhältnis der Frequenz zu fs ab. Als Denkanstoß: Man kann den Phasenfehler durch Abschneidung übrigens auch komplett annihilieren: Beispiel: 18 bit Phase, die zu 12 bit abgeschnitten wird für einen 12 bit LUT. Es gilt nämlich:
Ist x die abgeschnittene Phase und y der Fehler, kann man einfach einen zweiten LUT mit 18-12 = 6 bit -> 64 Einträgen zusätzlich aufwenden. x wird für den 2^12 LUT verwendet, y für den 2^6 LUT. Anstelle des 2^18 LUTs benötigt man also nur Speicher für 2^12+2^6 Einträge. Anstelle der linearen Taylor-Korrektur benötigt man also nur eine Multiplikation und einen (kleinen) LUT mehr und ist den Phasenfehler durch die Abschneidung komplett los ;)
Rezy schrieb: > und ist den Phasenfehler durch die Abschneidung komplett los ;) Nee, du bist ihn nicht "komplett" los, sondern erleichterst dir die Rechnung mit einem 18 Bit Phasenvektor durch Aufteilung der Tabellen mit trigonometrischer "Restezerlegung". Es bleibt bei deinen 18 Bit. Das kann man auch symmetrisch auftrennen und eine 18 Bit-Phase mit 9Bit Halbbögen erziehlen, also zwei halb große oder gar dieselbe Tabelle nehmen. Spart noch mehr Platz. Solche Verfahren gibt es einige, aber sie fangen eben immer mehr an zu rechnen, statt "direkte digitale Synthese zu betrieben". Gleichwohl wurde es aber in "den Anfangsjahren der DDS" genau so gemacht und es gibt auch ein dediziertes Verfahren dafür, nur fällt mir der Name des Entwicklers gerade nicht ein. Das gleiche Ergebnis kann man in einem FPGA übrigens erreichen, wenn man dasselbe RAM von zwei Seiten ausliest. Auch da klappt es mit und ohne partielle Zerlegung des Phasenvektors. Man liest einfach 90 Grad später die Steigung aus. Wie auch immer: Die Auflösung bleibt trotzdem endlich! Und: Es gilt nur für den Sinus und für den habe ich eine andere generische Vorschrift entwickelt, die gar keine Tabelle braucht und mit jeder Auflösung zurecht kommt. Sie ist im Aufwand skalierbar groß und deckt beliebig hohe Oberwellengenauigkeiten ab und produziert dem Wesen nach keine Frequenzen unterhalb der Nutzfrequenz. Und (Zufall oder nicht) sie lief in meinem ersten Synth tatsächlich mit 18 Bit. :-)
Jürgen S. schrieb: > Rezy schrieb: >> und ist den Phasenfehler durch die Abschneidung komplett los ;) > Nee, du bist ihn nicht "komplett" los, sondern erleichterst dir die > Rechnung mit einem 18 Bit Phasenvektor durch Aufteilung der Tabellen mit > trigonometrischer "Restezerlegung". Es bleibt bei deinen 18 Bit. Deshalb sprach ich vom Phasenfehler durch Abschneidung. Vielleicht war das nicht ganz deutlich. Ich meinte natürlich nur den, den man durch die Abschneidung der Phase hinter dem Akkumulator erzeugt. Dass eine allgemeine Quantisierung der Phase grundsätzlich einen Fehler erzeugt, sollte - hoffe ich - klar sein. > Das kann man auch symmetrisch auftrennen und eine 18 Bit-Phase mit 9Bit > Halbbögen erziehlen, also zwei halb große oder gar dieselbe Tabelle > nehmen. Spart noch mehr Platz. Guter Punkt. Ich glaube, nun haben wir das Thema auch wirklich durch :D
Angehängte Dateien:
-
LCR-Meter-Theory.JPG
180 KB
Hallo, ich hätte noch eine Frage, wenn ich dann die Berechnungen für ein LCR-Meter ausführen will. Die Theorie habe ich in dem Bild angehängt. Das ist aus der Elektor Zeitung von 2013, wo das LCR-Meter von denen vorgestellt wurde. Im Prinzip ist mir das klar, wie das geht. Aber wie muss man die Formeln für Up und Uq anpassen, wenn man über mehrere Perioden sampelt? Der Termin in der Klammer für den Sinus bildet ja eine Periode ab. Wenn ich mit 96kHz abtaste und zum Beispiel 1000 Wert für die Berechnung heran ziehen will, dann messe ich über mehrere Perioden, wenn der Sinus zum Beispiel 10kHz hat. Wie bringe ich in den Term von Up und Uq die Abtastfrequenz und die Anzahl der Messwerte mit rein? Da stehe ich gerade wieder auf dem Schlauch. Grüße, Jens
Jens W. schrieb: > ich hätte noch eine Frage, wenn ich dann die Berechnungen für ein > LCR-Meter ausführen will. Naja, das ist aber ein bissel was anderes, als man es im Eröffnungspost lesen kann. Ob das direkte Aufsplitten nach Re und Im eine wirklich gute Lösung ist, oder man eher den Weg |U| und |I| und Winkel dazwischen gehen sollte, wäre zu diskutieren. Immerhin hat man bei nur 96 kHz Abtastrate und 20 kHz Meßfrequenz nur so etwa 5 Stützstellen pro Periode. Da ist die im Bild gezeigte "Theorie" nicht wirklich ausreichend. Mir schwebt dabei eine andere Herangehensweise vor: 1. Winkel bestimmen: nach einem Nulldurchgang der jeweiligen Kurve zwischen der letzten und der aktuellen Stützstelle per linearer Regression (der Einfachheit wegen) den tatsächlichen Nulldurchgang berechnen und aus relativ vielen so berechneten Nulldurchgängen den Winkel zwischen den U und I berechnen. Da braucht man dann auch kein extra Bezugssystem und etwaige Phasendrehungen in einem dem DDS nachgeschalteten Filter spielen keine Rolle mehr. 2. Beträge bilden: Ebenfalls aus möglichst vielen "gleichgerichteten" Stützstellen den Mittelwert bilden. Bei (mal angenommenen) 10000 Stützstellen sollte der Fehler durch das quasi winkelignorierende Hineintrampeln in die Perioden der Meßfrequenz bereits recht klein geworden sein. Man müßte das mal etwas genauer durchrechnen. W.S.
Du hast Recht! Das passt hier nicht mehr dazu. Ich habe einen neuen Thread dazu aufgemacht. Beitrag "LCR-Meter mit Audio ADC/DAC" Da ist auch ein interessanter Link von einem LCR-Meter drin, das tatsächlich mit Audio ADCs misst! Sehr interessant. Grüße, Jens
:
Bearbeitet durch User
Beitrag #7151662 wurde vom Autor gelöscht.
Jens W. schrieb: > Wenn ich hier spare, dann resultiert das in einem höheren > Phasenrauschen. Phasenrauschen kommt primär von der fraktionalen Länge des DDS-Akkumulators. Je mehr bits, desto weniger Phasenrauschen.
Hallo Mampf, ich denke so pauschal kann man das nicht behaupten. Zumindest in meinem Fall hier. Wenn man die Länge des DDS-Akkus verlängert, dann muss man bei gleicher Ausgangsfrequenz auch die Samplerate vergrößern. Wenn man das nicht macht, dann wird die Auflösung nicht besser. Egal wie viele Bits man verwendet. Das geht bei mir aber nicht. Diese Frequenz ist vom verwendeten Audio-DACs vorgegeben und beträgt fest 96kHz. Grüße, Jens
Jens W. schrieb: > Wenn man die Länge des DDS-Akkus verlängert, dann muss man bei gleicher > Ausgangsfrequenz auch die Samplerate vergrößern. Man muss auch die Tabelle vergrößern.
Hallo Hans, das stimmt. Und dann ist man wieder am Anfangsproblem. Entweder man nimmt eine große Tabelle, oder man rechnet die Werte in Echtzeit. Grüße, Jens
Hans schrieb: > Man muss auch die Tabelle vergrößern. Nö, muß man nicht. Alle DDS von AD machen es dir vor: Man benutzt zum D/A-Wandeln nur soviele Bits (vom MSB runter bis man genug hat), wie man haben will - die Phasen-Akkumulation hingegen erfolgt mit der kompletten Bitbreite. W.S.
W.S. schrieb: > Hans schrieb: >> Man muss auch die Tabelle vergrößern. > > Nö, muß man nicht. Alle DDS von AD machen es dir vor: Man benutzt zum > D/A-Wandeln nur soviele Bits (vom MSB runter bis man genug hat), wie man > haben will Darum ging es nicht. Es ging um eine vergrößerte Auflösung der Phase. Du beschreibst sogar genau das, was ich sage: Die Tabelle MUSS zur Wortbreite passen. Ferner MUSS die Tabelle wachsen, wenn die Genauigkeit steigen soll. Sonst bleibt es bei den gleichen Phasensprüngen. Dass der Wandler eine endliche Wortbreite hat und man folglich nicht mehr MSB zuführen kann, hat damit nichts zu tun.
Hans schrieb: > Es ging um eine vergrößerte Auflösung der Phase. Das macht man mit einer größeren Rechenbreite beim Phasen-Akku. Damit kann man dann feiner die Periodenlänge auflösen. Das hat nichts mit dem DAC und dessen Auflösung zu tun. Und deshalb ist die Tabelle nicht wirklich abhängig von der Phasenauflösung. So herum. Schließlich kann man konstruktiv nicht voraussehen, für welche Ausgangsfrequenz das Phaseninkrement vom Anwender gewählt wird. Da ändert sich bei niedrigen Frequenzen der ausgegebene Amplitudenwert über mehrere Inkremente eben nicht. Den umgekehrten Fall hat man bei hoher Ausgangsfrequenz: da ändert sich der Amplitudenwert bei jedem Inkrement um mehr als nur ein Bit - bis hin zu nur 3 Stützstellen pro Periode. Und kurz vor nur 2 Stützstellen pro Periode ist endgültig Schluß damit. W.S.
W.S. schrieb: > Das macht man mit einer größeren Rechenbreite beim Phasen-Akku. und einer größeren Tabelle, wie ich schon erklärte. Der größere Phasenakku bringt keine Verbesserung. Wohin mit den zusätzlichen Bits? > Damit kann man dann feiner die Periodenlänge auflösen. Was keinen Vorteil bringt. > Das hat nichts mit dem > DAC und dessen Auflösung zu tun. Meine Rede. Ich war nicht derjenige, der die DAC-Auflöung ins Spiel brachte. Ich zitiere mal: W.S. schrieb: > Man benutzt zum > D/A-Wandeln nur soviele Bits (vom MSB runter bis man genug hat), Eben deshalb bringen weitere zusätzliche Bits nichts. W.S. schrieb: > bei hoher Ausgangsfrequenz: > da ändert sich der Amplitudenwert bei jedem Inkrement > um mehr als nur ein Bit - bis hin zu nur 3 Stützstellen pro Periode. > Und kurz vor nur 2 Stützstellen da ist schon sehr viel früher Schluss mit Sinus. Zu mehr als einem 10-tel der Abtastfrequenz sind DDS-Generatoren nicht zu gebrauchen.
Rezy schrieb: > Ich glaube, nun haben wir das Thema auch wirklich durch Offenbar nicht, wenn ich die letzten Beiträge lese :-) Ich versuche mal, es zu ordnen: Grundsätzlich geht eine höhere Genauigkeit in der Phase nur, wenn man genauere Werte hat. Klar. Solange die Amplitudenauflösung der Tabelle groß genug ist, fordert das entweder mehr Werte pro Zeit (s.u.) oder genauere Werte zu einem exakteren virtuellen Zeitpunkt. Diese kann man bekommen, durch: a) eine perfekte(re) Interpolation bei Kenntnis der Funktion und des Steigungsverlaufs unter Nutzung der Restbits, also praktisch des gesamten Phasenvektors, zur Abbildung des genauen Zeitpunktes b) durch mehr Tabelleneinträge unter Verschiebung der Grenze von MSBs und LSBs des Phasenvektors, zur besseren direkten Ablese. Eine Vergrößerung allein des Phasenvektors bringt also theoeretisch durchaus eine bessere Auflösung, praktisch aber nur dann, wenn ich entweder a) oder b) oder beides zusätzlich anwende. Da die Interpolationsqualität endlich ist, braucht es irgendwann automatisch mehr Punkte. Soweit sollte das klar sein. Fakt ist: Bei gegebener Tabelle bleiben die Phasensprünge durch die Größe immer gleich und lassen sich auch mit noch so großem Phasenakku nicht beseitigen. Wenn man davon ausgeht, dass die DDS richtig dimensioniert ist, also mit und ohne Interpolation mit der jeweils angemessenen Auflösung, läuft die weitere Erhöhung der Zahl der LSBs ins Leere. Jens W. schrieb: > Diese Frequenz ist vom verwendeten > Audio-DACs vorgegeben und beträgt fest 96kHz. Das ist insoweit richtig, als dass für die effektive Auflösung der Phase nicht mehr Werte / Zeit übertragen werden können. Eine wachsende Tabellengröße zieht aber linear wachsende Inkrementalwerte für die Tonfrequenzen nach sich. (Es würde z.B. alles um Faktor 2 größer und an der Abtastgenauigkeit ändert sich nichts). Damit lassen sich die Tonfrequenzen selber aber genauer darstellen, d.h. der Phasenakku repräsentiert die Zielfrequenz genauer. In der Praxis ist das wichtig, wenn der Ton moduliert werden soll. Da greift wieder das Thema Phasenjitter. Selbigen kann man ja nutzen, um die Tonfrequenz mit einem Vibrator zu belegen, aber eben auch, um selbige exakt zu treffen! Die LSBs des Phasenakkuss verhalten sich dann wie bei einer PDM. Mehr Bits im Gesamtvektor und damit auch Restvektor sind also durchaus hilfreich. Natürlich gibt es zwei Grenzen: Eine technische, nämlich die Amplituden-MSB des Wandlers und eine funktionelle, nämlich die Wahrnehmbarkeit der Frequenzauflösung. Zu dieser ist zu sagen, dass es irgendwann nichts mehr bringt, den Phasenakku zu überdimensionieren - siehe Punkt "Jitter". Zur Amplitudenauflösung ist zu sagen, dass man die des Wandlers auch überkommen kann, wenn man dithert: Genau wie bei der Phase kann man durch Modulation aus einem genauen 32 Bit-Signal ein 24-Bit-Signal für einen Wandler machen (und das wird auch so gemacht) und man kann selbiges 32-Bit-Signal durch Interpolation aus einer 16-Bit-Tabelle gewinnen (und auch das wird gemacht, siehe weiter oben das Thema 18 bit aus 2x9). Heißt auf Deutsch: Amplitudenauflösung des Wandlers und Amplituden-Auflösung der Tabelle einerseits- sowie MSBs des Phasenakkus und Länge der Tabelle andererseits hängen funktionell schon irgendwie sinnvoll zusammen, haben aber in beiden Fällen nicht notwendigerweise exakt die gleiche Größe. W.S. schrieb: > Alle DDS von AD machen es dir vor: Man benutzt zum > D/A-Wandeln nur soviele Bits Dass AD-Chips das so machen, hängt daran, dass sie eben eine klassische "direkte" digitale Synthese betreiben. Das macht sie schnell und preiswert. Sie tun es mit Rücksicht auf Genauigkeiten allerdings mit sehr hohen Wandlerauflösungen und Tabellengrößen. Je nach Anforderung sind die Chips ab 10MHz, spätestens 100MHz einfach besser, als FPGAs. Darunter baue ich im FPGA bessere DDSs und diese auch billiger - vor allem mehrkanalig.
W.S. schrieb: > Da ändert sich bei niedrigen Frequenzen der ausgegebene Amplitudenwert über > mehrere Inkremente eben nicht. Dafür haben wir ja die Interpolation: Die Phasenauflösung muss natürlich mindestens mal so groß sein, dass die tiefste gewünschte Frequenz auch abbildbar ist, sich also in einem genügend gut aufgelösten Fortschritt in den LSBs wiederfindet. Das ist eines der Hauptdesignkriterien. Wenn man es jetzt konkretisieren will, braucht man die maximal zulässige THD für diese niedrige Frequenz und setzt sie ins Verhältnis zum Spektralfehler der Interpolation, woraus sich indirekt die minimale Tabellengröße, also das Verhältnis von MSB und LSB ergibt. Hans schrieb: > nur 3 Stützstellen pro Periode. >> Und kurz vor nur 2 Stützstellen > da ist schon sehr viel früher Schluss mit Sinus. Wenn man keine Interpolation benutzt und es direkt ausgibt, also nur die Werte der MSBs hat, dann ist mitunter sogar schon sehr viel früher Ende der Fahnenstange. Als Richtwert für einen statischen Sinus ohne große Phasenverschiebung und Schwebungen, braucht es 7 Punkte, wenn es die Richtigen sind. Wenn es ein vibratofähiger Sinus in derselben Größenordnung sein soll, der keine Schwebungen generiert, dann in etwa das Quadrat = 50 Punkte. Das gilt für eine sehr gute analoge AA-Filterung. Für das, was man so typischerweise an AA-Elektronik baut, sollte man eher das Doppelte vorsehen. Für Musik bedeutet das, dass z.B. bei 768kHz alle Frequenzen bis 8kHz perfekt abgebildet werden. "Perfekt" orientiert sich an der Wahrnehmbarkeitsschwelle von Intermodulationen und Störungen durch Oberwellen, der in dem Bereich mit 40dB-50dB veranschlagt wird. In der nächsten Oktave kommen größere Fehler, die aber absolut unhörbar geringe Schwebungen nach sich ziehen. Noch weiter darüber interessiert es nicht mehr, wegen Audioende = 20kHz. Dort, wo es wegen "wenigen Punkten" richtig schweben würde, nämlich bei 20%fs, wird nichts ausgegeben und selbst wenn man es täte, lägen die Schwebungen auch schon überwiegend im Ultraschallbereich. Jens W. schrieb: > oder man rechnet die Werte in Echtzeit. Für einen Sinus allemal. Genau genommen gibt es bei FPGAs gar keinen Grund mehr, dafür eine DDS zu nehmen, weil sich oberwellenarme Sinüsse auch anders herstellen lassen und Multiplier meistens genug vorhanden sind. Bei Waveformgeneratoren sieht es anders aus. Spezielle bandlimitierte Signale (auch Rechtecke!) kann man aber in Tabellen gut parken. Und vor allem für die Fensterung muss man entscheiden, ob Tabellen oder generische Rechnungen effektiver sind. Kaiser braucht in aller Regel eine Tabelle, aber schon Blackman-Harris macht mn eher mit einem Gen-Sinus - auch weil die Anwendungen meistens längere TAPs haben. Nochmal was dazu: Rezy schrieb: > DDS mit Phaseninkrement 17 bits, Wie schon diskutiert, braucht es auch Tabellenwerte, die auch in der Amplitude in der Größenordung aufgelöst sind und bei interpolierenden DDS sehe ich einige Bit mehr. Wie weit das sinnvoll zu treiben ist, hängt von der Technologie ab: Bei FPGAs ist es ja so, dass man dedizierte Multiplier und -breiten hat. Die geben quasi vor, wie man mit den Vektoren umgehen sollte. Wenn man bei XI et al mit 18 Bit auskommt, ist das fein - die nächste Stufe sind 25 (beim Artix) oder 27 (Ultrascale) und danach kommen z.B. 36. Ab da wird es richtig teuer, weil binomisch stark erweitert werden muss und somit das Tempo runter geht. Es kann also sein, dass man bei einem schnellen Generator keinen 10MHz-Sinus hinbekommt, der zugleich eine hohe Auflösung hat und man dann doch wieder eine Tabelle braucht - sogar für den Sinus. Fairerweise muss man sagen, dass das ein klarer Nachteil von FPGAs gegenüber modernen CPUs und DSPs ist. Andererseits kommt die große Masse der Anwendungen mit einem solchen FPGA-Mul aus. Ich habe es in meiner ganzen Zeit einmal gehabt, dass ein FPGA bei einer Wellenformgeneration von einem DSP ersetzt wurde.
Hallo Jürgen, sehr aufschlußreich! Danke für die Erläuterung! Was verwendest du denn für AD- und DA-Wandler die eine Sampelrate von 768kHz haben? Gibt es die für "Normalsterbliche" zu erwerben? Und werden die auch noch über I2S betrieben? Oder haben die schon irgendwas mit LVDS oder ähnlichem? Grüße, Jens
Hans schrieb: > W.S. schrieb: >> Das macht man mit einer größeren Rechenbreite beim Phasen-Akku. > und einer größeren Tabelle, wie ich schon erklärte. Der größere > Phasenakku bringt keine Verbesserung. Wohin mit den zusätzlichen Bits? Die bleiben im Akku, damit die Phasenakkumulation und damit die Frequenzauflösung ordentlich geht. >> Damit kann man dann feiner die Periodenlänge auflösen. > Was keinen Vorteil bringt. Meinst du? Also, hier mal ein Wort aus der Praxis: Ich habe in meinem Wobbler einen AD9951 drin, der mit 400 MHz getaktet wird und eine Amplitudenauflösung von 14 Bit hat. Und ich benutze den sowohl für den (fast noch) NF-Bereich so ab etwa 10 kHz bis herauf zu 160 MHz. Und zwar zum Abgleich von Filtern und dergleichen. Im einen Grenzbereich ist der erzeugte Sinus so langsam, daß selbst bei 14 Bit sich die DAC-Ausgabe über mehrere Takte nicht ändert und im anderen Grenzbereich hat man nur so etwa 2.5 Stützstellen pro Periode. Versuche bitte nicht, mir erzählen zu wollen, daß ein größerer Phasenakku nix bringt oder eine feinere Frequenzauflösung keinen Vorteil bringt. Die Inkarnationen des Gegenbeweises stehen auf tausenden von Bastel/Arbeits-Tischen. W.S.
Jens W. schrieb: > Gibt es die für "Normalsterbliche" zu erwerben? Rein theoretisch: JA Aber praktisch sind schnelle DAC ziemlich teuer bis unbezahlbar. Ein Beispiel: AD3551R (33 MHz, 16 Bit) für so etwa $160, AD9081 (12 GHz, 16 Bit) für zierliche $1900 bei Abnahme ab 100 Stück, na und so weiter. Das einzige, was preislich nicht im Jenseits ist, sind Audio-Codecs, die es auch für 192 kHz Taktfrequenz gibt. W.S.
Jens W. schrieb: > Was verwendest du denn für AD- und DA-Wandler die eine Sampelrate von > 768kHz haben? Zum Testen der Signale verwende ich u.a. eine high-speed Karte mit meinem Cyclone 2, der noch deutlich höher kann, allerdings keine 24 Bit bringt. W.S. schrieb: > die es auch für 192 kHz Taktfrequenz gibt. Die gibt es auch für 384. Real arbeite ich aber auch meistens mit Wandlern die auf 96kHz und 192kHz arbeiten. Die 768 dienen der internen Präzision und der richtigen Darstellung von Oberwellenspektren und ihren Effekten: Beitrag "Re: VA-Ozillatoren mit bandlimitierenden Methoden (BLIT) ?" Wenn die Signale aus der Syntheseeinheit kommen und ins Mischpult gehen, werden sie mit einem Tiefpass auf c.B. 30kHz limitiert und in 192kHz überführt. Durch die Überabtastung werden dann indirekt auch diverse Artefakte von DDS-Wellen reduziert - vor allem die aus dem User-RAM.
W.S. schrieb: > Im einen Grenzbereich ist der erzeugte Sinus so langsam, daß selbst bei > 14 Bit sich die DAC-Ausgabe über mehrere Takte nicht ändert und im > anderen Grenzbereich hat man nur so etwa 2.5 Stützstellen pro Periode. Was würdest du dir von einem größeren Phasenakkumulator versprechen? Wenn die Tabelle nicht größer wird, was sie bei demselben Chip ja nicht wird, bleibt es bei denselben Bits für die Phase. Eine größere Frequenzauflösung, die du beim Durchfahren dann hättest, würde zwar zu einem "feiner" jitternden Signal führen, allerdings bist du da an dem Punkt schon längst in einem Betriebsbereich, wo die DDS nicht mehr sinnvoll nutzbar ist. Wenn nicht durch Phasenjitter also Adressmanipulation an der Tabelle dafür gesorgt wird, dass das Zittern des Y-Wertes auch bei niedrigen Frequenzen zu einem Rauschen in einem so hohen Spektralbereich führt, dass er gegenüber der Nutzfrequenz noch gut filterbar ist, bringt das nichts. Daher baue ich DDS lieber im FPGA, der das dynamisch anpasst und interpoliert, also die LSB auch zur Erzeugung des Wertes nutzt und der zudem noch die Möglichkeit hat, für niedrige Frequenzen die Tabelle mehrfach abzutasten, um zu besseren Zwischenwerten zu gelangen. Man kann ja gerne auch 3 oder mehr Werte lesen und die interpolieren. Bei festen DDS-Chips geht es nicht, es sei denn, die machen das intern selber. Bei AD kenne ich da nichts, habe aber schon länger nichts mehr mit denen gemacht. Möglich, dass es das inzwischen gibt. Ich habe in einem Fall für einen ASIC eine DDS konzipiert, die das kann und zudem Werte "geschickt" aus der Tabelle bezieht, um sehr gut zu interpolieren. Dazu müssen 3 weitere Informationen aus der Tabelle entnommen und errechnet werden und neben einem alten auch ein neu zu berechnender Zeitpunkt des Zugriffs in der Zukunft bekannt sein, was bei veränderlichen Frequenzen nicht trivial ist. Die MIMIK steckt in meinem Synth und ansatzweise in einer RADAR-Anwendung meines Kunden und war zu meiner Überraschung damals so nicht bekannt. Selbst mein Professor Otmar Loffeld kannte das nicht. Ich habe auch bisher kein Patent entdecken können, wo das so gemacht wird. Korrekterweise muss man sagen, dass der Aufwand auch beträchtlich ist und nur lohnt, wenn man das Maximale aus der aktuellen Technologie rausholen will. Soweit möglich, ist es billiger, eine entsprechend höhere Frequenz und Tabellenlänge zu nehmen. Wenn es extrem schnell sein muss, braucht es dann mehrere Tabellen vorberechneten Hilfswerten wie z.B. die Differentiale 1. und 2. Ordnung etc. Für einen Signalgenerator, wie man ihn im Labor braucht, ist es allemal einfacher, eine 2-stufige DDS zu nehmen, also die zu spielende Wellenform exakt 1:1 abzutasten und die Frequenz dafür mit einer vorgelagerten DDS zu erzeugen und zu filtern. Wenn man das stark genug dithert und filtert, bekommt man über z.B. einen Bereich von 5% bis 20% eine sehr präzise einstellbare Taktfrequenz, die über den gesamten Bereich von 2 Oktaven für alle Werte die gleiche Qualität hat. Dann braucht es nur eine umschaltbare PLL mit Oktavteilern und kriegt über ein weites Spektrum alles exakt. Man könnte jetzt hergehen und zwei davon in einem FPGA aufbauen, um wie bei einer Doppelkupplung durch geschicktes Wechseln die Frequenz kontinuierlich von 0.X bis z.B. 300 MHz stufenlos durchfahren zu können. Dann wäre es eine Frage der Tabellenlänge, was an maximaler Frequenz herauskommt. Einen perfekten Sinus bekommt man schon mit 30-40 Punkten, wenn der Filter gut ist.
Hallo zusammen, also es gibt ein kleines Update. Leider nicht mit dem Ergebnis, wie ich es gerne hätte. Auf meinem Board gab es eine kleine Kernschmelze. Ich habe ein Display mit angeschlossen gehabt, damit ich da meine Debug Ausgabe machen kann. Muss ja nicht immer USB sein. Dabei hab ich das an 5V angeschlossen. Es hätten besser 3,3V sein sollen. Fazit: Display ist Schrott und hat den Rest am 3,3V Netz mitgenommen. 3,3V LDO, µC, FPGA, PCM5102. Jetzt bin ich erstmal am Reparieren. µC ist getauscht, ebenso FPGA. Aber ich muss nun vom PCM5102 auf den PCM1754 umsteigen. Was anderes habe ich nicht mehr da. Mein Glück ist, dass ich die restlichenTeile alle da habe, sonst wäre jetzt etwa ein Jahr Pause angesagt wegen Shortage! Ich meld mich, wenn ich wieder am Testen mit dem DDS bin. Grüße, Jens
Jens W. schrieb: > Display ist Schrott und hat den Rest am 3,3V Netz mitgenommen. 3,3V LDO, > µC, FPGA, PCM5102. Auch wenn das mit dem Thema DDS jetzt weniger was zu tun hat, sondern in Richtung Schaltungsumsetzung geht: 1) Netzteile bei Laboraufbauten immer mit Strombegrenzung fahren. Das hilft, einen größeren Totalschaden zu vermeiden. 2) Schutzbeschaltung vorsehen 3) Aufkleber draufpappen, die einen erinnern
Hallo zusammen, ich bin einen Schritt weiter. Ich hab alles repariert. Gott sei Dank hatte ich noch alle Teile im Regal. Da hatte ich mich schon vorher eingedeckt. Nicht zu glauben was die Teile jetzt kosten!!! Es funktioniert nun alles wieder soweit. Und der DAC gibt brav den Sinus aus. Ich musste aber noch die Datentypen umstellen. Ich muss für die Signale signed und unsigned nehmen. Ich hatte vorher alles als integer, aber da hat es Probleme gegeben. Da hat der Wertebereich nicht richtig gepasst, obwohl ich die range explizit angegeben hatte. Mit signed und unsigned hat es auf Anhieb funktioniert. Beim Sinus sieht man das Phasenrauschen sehr deutlich bei 20kHz Ausgangsfrequenz. Da ist die Interpolation zwischen den Werten aber noch nicht drin. Die habe ich zur Fehlersuche wegen den Datentypen raus genommen. Die Interpolation nehme ich morgen in Betrieb, da bin ich dann gespannt wie viel das bringen wird. Grüße, Jens
Lohnt sich das denn echt, so eine Schaltung noch selbst zu konstruieren? Solche Generatoren kommen aus Fernost feritg aufgebaut für einen Appel und ein Ei. Jens W. schrieb: > Aber ich muss nun vom PCM5102 auf den PCM1754 umsteigen. Was anderes > habe ich nicht mehr da. Auch die gibt es doch als fertige Module.
Hallo Audiomann, nein, lohnen tut sich das natürlich nicht (zumindest finanziell). Aber es ist das Hobby und ich lerne damit. Also von der Seite her geht es. Grüße, Jens
Das sieht - mit Verlaub - schlimm aus. Kann es sein, dass der Tiefpass nicht korrekt dimensioniert ist?
Audiomann schrieb: > Kann es sein, dass der Tiefpass > nicht korrekt dimensioniert ist? Bei 96 kHz zu 20 kHz gibt es nur 5 Stützstellen pro Periode. Dafür sieht das Ergebnis doch gut aus. Duke
Hallo, oh Mann, mein Beitrag ist ja komplett verschwunden! Sorry! Ich hatte das Bild vergessen und hab dabei wohl den Beitrag gelöscht. Der Tiefpass am Ausgang fehlt komplett! Das ist das Signal der Rohdaten. Worauf es ankommt ist, dass die Signale synchron bearbeitet werden. Der DAC sampelt beide Kanäle gleichzeitig. Ich gebe den Sinus und den Cosinus aus und die Phasenverschiebung der Signale passt sehr gut! Die Interpolation der Werte, die ich einbauen wollte ist gar nicht notwendig, bzw. macht es nicht besser (Im Bild oben fehlt das auch). Ich lese mit 96kS/s die Werte aus dem Speicher. Das Framesignal LRCK sieht man oben als Rechteck. Wenn man nun genau auf die Cursor achtet sieht man, dass der DAC selbst die Werte interpoliert mit drei oder vier Stützstellen. Besser wird das mit der eigenen Interpolation auch niemals, da ich die Werte gar nicht ausgeben kann. Die Interpolation vom DAC wirkt ja so, als sei die Samplerate drei- bis viermal höher. Wenn da noch der Tiefpass am Ausgang hin kommt wird das Signal zwar etwas verzögert, aber ich denke das wird glatt genug sein. Da bekomme ich die 20kHz mit 96kS/s. Grüße, Jens
Jens W. schrieb: > Besser wird das mit der eigenen Interpolation auch niemals, da ich die > Werte gar nicht ausgeben kann. Die DACs arbeiten mit garantiert mehr, als nur mit 4-fach oversampling, das wirst du allerdings so nicht sehen. Wenn, ist das eher ein bandlimit deiner Messung. So oder so muss da ein Tiefpass rein, der steilflankig bei 20kHz abschneidet, dann wird das auch rund.
Jens W. schrieb: > Hallo, > > oh Mann, mein Beitrag ist ja komplett verschwunden! > Sorry! > Ich hatte das Bild vergessen und hab dabei wohl den Beitrag gelöscht. > > Der Tiefpass am Ausgang fehlt komplett! Das ist das Signal der Rohdaten. > Worauf es ankommt ist, dass die Signale synchron bearbeitet werden. Der > DAC sampelt beide Kanäle gleichzeitig. > Ich gebe den Sinus und den Cosinus aus und die Phasenverschiebung der > Signale passt sehr gut! Der PCM1754 ist ein Delta-Sigma-Wandler und hat einen Tiefpass-Filter integriert. Allerdings einen sehr dürftigen. Durch die Delta-Sigma-Wandlung entstehen sehr viele hochfrequente Anteile, die da nur schwach gefiltert werden. Deshalb sieht es zwar "etwas" geglättet aus, ist aber natürlich weit entfernt von einem spektral reinen Ton. Ein zusätzliches Tiefpass-Filter ist auf jeden Fall notwendig! So ist der Ton noch stark verzerrt. > Die Interpolation der Werte, die ich einbauen wollte ist gar nicht > notwendig, bzw. macht es nicht besser (Im Bild oben fehlt das auch). > Ich lese mit 96kS/s die Werte aus dem Speicher. Das Framesignal LRCK > sieht man oben als Rechteck. > Wenn man nun genau auf die Cursor achtet sieht man, dass der DAC selbst > die Werte interpoliert mit drei oder vier Stützstellen. Naja, er arbeitet wie gesagt als Delta-Sigma-Wandler mit Tiefpass. Deshalb bekommst du da schon etwas sinusoides raus, nur nicht gut. Die Interpolation, über die wir hier diskutiert haben, hat ein anderes Ziel. Solange dein Sinus aber analog nicht sauber gefiltert ist, hast du natürlich keinen Mehrwert, digital zu korrigieren. Sobald das Signal sauber analog gefiltert wird, kannst du mit der Interpolation noch etwas an spektraler Reinheit rausholen. > Besser wird das mit der eigenen Interpolation auch niemals, da ich die > Werte gar nicht ausgeben kann. Die Interpolation vom DAC wirkt ja so, > als sei die Samplerate drei- bis viermal höher. Doch, es wird besser. Die diskutierte Interpolation ist eine Korrektur der Fehler, die durch das Prinzip eingeführt werden, was den Ton spektral reiner macht. Du interpolierst keine zusätzlichen Werte rein, die du als Abtastwerte ausgibst. Vielmehr korrigierst du deine Abtastwerte. > Wenn da noch der Tiefpass am Ausgang hin kommt wird das Signal zwar > etwas verzögert, aber ich denke das wird glatt genug sein. Da bekomme > ich die 20kHz mit 96kS/s. Die Verzögerung ist vernachlässigbar. Du verzögerst ja schon allein durch das I2S interface. Aber schön, dass es voran geht!
Hallo Rezy, danke für die Erklärung! Dann ergänze ich mal den analogen Filter und schau mir das Signal nochmal an. Wenn das Filter dann alles glatt gebügelt hat, wird es aber mit der Messtechnik schwer das zu sehen oder? Mit dem Oszi wird man das nicht mehr sehen, wie viel das besser wird, oder auch nicht. Da werde ich einen Spektrumanalyzer brauchen oder? Oder reicht die FFT Funktion von meinem Oszi aus? Ich bin gespannt und berichte weiter. Grüße, Jens
Rezy schrieb: > Der PCM1754 ist ein Delta-Sigma-Wandler und hat einen Tiefpass-Filter > integriert. Allerdings einen sehr dürftigen. Ich denke, der ist schon richtig gebaut. Der wird genau das filtern, was der DAC am Bereichsende nicht mehr darstellen kann. Bei 96kHz werden das wohl 30 - 40 kHz sein. Dass die Anwendung das aufgrund anderer Limits nicht kann und mehr Filterung braucht, ist davon unabhängig. > Durch die Delta-Sigma-Wandlung entstehen sehr viele hochfrequente > Anteile, die da nur schwach gefiltert werden ??? Das ist doch ein DAC! Da kommt nichts hochfrequentes und alles, was der DAC selber durch seine Wandlung generiert, filtert der weg!
Angehängte Dateien:
-
pcm1754.PNG
71 KB
Audiomann schrieb: > Rezy schrieb: >> Der PCM1754 ist ein Delta-Sigma-Wandler und hat einen Tiefpass-Filter >> integriert. Allerdings einen sehr dürftigen. > Ich denke, der ist schon richtig gebaut. Der wird genau das filtern, was > der DAC am Bereichsende nicht mehr darstellen kann. Bei 96kHz werden das > wohl 30 - 40 kHz sein. Dass die Anwendung das aufgrund anderer Limits > nicht kann und mehr Filterung braucht, ist davon unabhängig. Siehe Anhang. Natürlich ist der korrekt. Aber ausreichend ist er nicht. Insbesondere weil dieser DAC intern noise shaping betreibt und hochfrequentes Rauschen generiert. Das entsteht durch die Requantisierung auf eine kleinere Wortbreite. >> Durch die Delta-Sigma-Wandlung entstehen sehr viele hochfrequente >> Anteile, die da nur schwach gefiltert werden > > ??? > Das ist doch ein DAC! Da kommt nichts hochfrequentes und alles, was der > DAC selber durch seine Wandlung generiert, filtert der weg! Ein Delta-Sigma-Wandler arbeitet doch gänzlich anders als ein R-2R DAC. Das Signal wird interpoliert, die Abtastrate deutlich erhöht. Dann kommt der Delta-Sigma-Modulator, der u.a. die Wortbreite (in der einfachsten Variante) auf 1 bit reduziert. Das wird gewandelt. Der Ausgang ist also eher ein "höherfrequenter" Bitstream, der D/A-gewandelt wird. Das Tiefpass-Filter glättet das. Durch den Bitstream entstehen höherfrequente Anteile.
Jens W. schrieb: > Mit dem Oszi wird man das nicht mehr sehen, wie viel das besser wird, > oder auch nicht. Im Zeitbereich sieht man sowas eher nicht. > Da werde ich einen Spektrumanalyzer brauchen oder? Oder reicht die FFT > Funktion von meinem Oszi aus? Die FFT vom Oszi kann helfen, ist aber nach meiner Erfahrung erst bei höherpreisigen Geräten brauchbar. Übliche Spektrumanalyzer starten erst bei 9 kHz oder 100 kHz mit der unteren Frequenz, da muß man aufpasssen. Günstiger dürfte man mit einer Soundkarte davonkommen, die die entsprechenden Parameter hat (24-bit/192 kHz). Die Frage ist auch, was Du letztendlich für Anforderungen hast. Ein AFG3011C von Tek ist je nach Frequenzbereich mit -60 bis -50 dBc spuriuos emissions spezifiziert. Duke
Hallo Duke, das mit dem Oszi hatte ich mir schon gedacht. Ich habe da bisher auch keine guten Erfahrungen mit der eingebauten FFT gemacht. Ich habe hier noch einen Signal Analyzer stehen. Einen HP 3561A. Der geht bei 125mHz los bis 100kHz. Den habe ich bisher noch nie gebraucht, habe den aber genau wegen dem Frequenzbereich noch nicht entsorgt (die Kiste ist riesig und sauschwer). Da habe ich wohl endlich eine Anwendung für den gefunden. Nur die Bedienung ist nicht so intuitiv. Damit muss ich mich wohl richtig auseinandersetzen. Ich betreibe auf meinem Board ja einen DAC und einen ADC. Ich will ja in Richtung LCR-Meter damit. Das Signal vom ADC bis zum DAC durchschleifen funktioniert super. Man sieht, dass die Signal absolut synchron bleiben vom Eingang bis zum Ausgang. Der ADC sampelt also auch beide Kanäle synchron. Beste Voraussetzung ;-) Der Phasenbeszug vom analogen Eingangssignal zum Ausgang vom DAC passt zwar nicht (kann ja auch nicht, da die Daten intern verarbeitet werden), aber das macht nichts, da sich so ein Delay bei der Berechnung von Z heraus rechnet, solange die Signale synchron bleiben. Grüße, Jens
Jens W. schrieb: > Ich habe hier noch einen Signal Analyzer stehen. Einen HP 3561A. Der > geht bei 125mHz los bis 100kHz. Mit seinem Eingangswiderstand von 1 MOhm kann der sogar direkt am DAC-Ausgang messen: https://accusrc.com/uploads/datasheets/5350_3561a.pdf Von der Samplerate siehst Du zwar nur die Grundwelle, aber besser als nix. Wenn Du damit ein LCR-Meter baust, kannst Du den Phasen- und Amplitudengang auch rauskalibrieren. Außerdem kannst Du durch Mehrfachmessung und Mittelwertbildung den Dynamikbereich erhöhen. Also AD5933 gibt es sowas auch fertig integriert: https://www.analog.com/en/products/ad5933.html Vielleicht findest Du dort in der zugehörigen Literatur noch ein paar Anregungen. Duke
Rezy schrieb: > Der Ausgang ist also > eher ein "höherfrequenter" Bitstream, der D/A-gewandelt wird. Das > Tiefpass-Filter glättet das. Durch den Bitstream entstehen > höherfrequente Anteile. Ja,ja - und diese interne Filter ist genau auf die Modulationsfrequenz = Taktfrequenz x X abgestimmt. Das von dir gepostete Diagram zeigt es auch: Das Limit setzt oberhalb des Audiospektrums bei etwa 50kHz sichtbar ein, begrenzt dieses also nicht. Daher braucht es einen externen Filter und zwar einen den man auf "Seine" Anwendung einstellt. Es kann ja sein, dass man so einen DAC für irgendwas bis 3kHz verwenden will. Es kommt jetzt also auf die Qualität der DDS an wo deren nutzbare Grenzfrequenz liegt.
Duke Scarring schrieb: > Also AD5933 gibt es sowas auch fertig integriert: > https://www.analog.com/en/products/ad5933.html Das habe ich mir schon angeschaut. Leider messen die nicht in niedrige Impedanzen. Daher versuche ich es selbst. Ich habe sehr spezielle Anforderungen. Daher mach ich das zu Fuß. Da gibt es nichts fertiges was ich nehmen kann. Ich brauche zum Messen einen Strom mit einigen Ampere. Da gibt es kein fertiges Gerät zu kaufen. Weder verfügbar, noch zu einem bezahlbaren Preis. Grüße, Jens
jensw schrieb: > Ich brauche zum Messen einen Strom mit einigen Ampere. Da gibt es kein > fertiges Gerät zu kaufen. Was hat denn die Messung eines Stromes mit der Erzeugung einer Sinuswelle zu tun? Was ist das für eine Anforderung? Für die Messung von Gleich- und Wechselstrom ("Strom" nicht Spannung!) gibt es Stromsensoren mit einer ausreichend geringen Belastung und GEnauigkeit für wenige Euro!
Hallo Ottakar, da musst du schon alles lesen! Es geht um eine LCR-Messbrücke. Dein Beitrag hat leider gar nichts mit dem hier diskutierten zu tun. Grüße, Jens
Angehängte Dateien:
-
TEK00000.BMP
38 KB
Hallo zusammen, so, das analoge Filter ist fertig und das funktioniert echt gut. Das wird für meine Anwendung vollkommen ausreichen. Die Ergebnisse im Anhang. Kanal 1 ist der Ausgang vom DAC. Die lineare Interpolation für die Werte ist mit integriert. Kanal 2 ist der Ausgang vom Filter. Das ist ein Tiefpass 3. Ordnung. Grüße, Jens
Duke Scarring schrieb: > Bei 96 kHz zu 20 kHz gibt es nur 5 Stützstellen pro Periode. > Dafür sieht das Ergebnis doch gut aus Alles ganz easy - einfach nochmal durch einen FIR-Filter jagen, dann wirds schon hübscher^^ Dann kann der externe Filter auch einfacher ausfallen. Und mit sowas wie "nur 5 Stützstellen pro Periode" denkt man womöglich falsch - laut Nyquist benötigt man min. die doppelte Frequenz für eine exakte Rekostruktion eines gesampelten Signals. Bei DDS wird, um das Phasenrausch klein zu halten, min. die 4fache empfohlen.
:
Bearbeitet durch User
Mampf F. schrieb: > Bei DDS wird, um das > Phasenrausch klein zu halten, min. die 4fache empfohlen. Was hat denn das Phasenrausch(en) mit der Zahl der Stützstellen zu tun, sodass 4 besser ist als 3? Wenn man das dadurch überwinden will, muss man mal 1000 oder 10000 Stützstellen nehmen, damit sich die Sprünge verteilen. Wichtiger ist, dass der Y-Wert genau stimmt: Der Zeitpunkt muss bekannt sein und der dazu passende Y-Wert genau berechnet werden, dann geht es auch bis an Nyquist heran und zwar auch nichtganzzahlig ganz ohne jegliches Phasenrauschen.
Duke Scarring schrieb: > Bei 96 kHz zu 20 kHz gibt es nur 5 Stützstellen pro Periode. > Dafür sieht das Ergebnis doch gut aus. Im 8-Bit Oszilloskop sieht jedes Audiosignal gut aus :-) Was sagt der Spektrumanalysator?
W.S. schrieb: > Im einen Grenzbereich ist der erzeugte Sinus so langsam, daß selbst bei > 14 Bit sich die DAC-Ausgabe über mehrere Takte nicht ändert und im > anderen Grenzbereich hat man nur so etwa 2.5 Stützstellen pro Periode. > Versuche bitte nicht, mir erzählen zu wollen, daß ein größerer > Phasenakku nix bringt Ich glaube, hier liegt ein Misverständnis vor. Der größere Phasenakku erhöht nur die Genauigkeit der im Mittel erzeugten Frequenz und löst nicht das Problem langsam kletternder Y-Werte. Mampf F. schrieb: > Jens W. schrieb: >> Wenn ich hier spare, dann resultiert das in einem höheren >> Phasenrauschen. > Phasenrauschen kommt primär von der fraktionalen Länge des > DDS-Akkumulators. +1 Je größer der Phasenvektor (und die Tabellenadresse), desto genauer ist der Wert. Auch bei interpolierten Phasen! Bei der Interpolation spielt die Akkubreite freilich eine Rolle. Mampf F. schrieb: > Alles ganz easy - einfach nochmal durch einen FIR-Filter jagen, dann > wirds schon hübscher^^ Die Kernfrage ist, welches Spektrum die DDS erzeugen muss. Wenn es um einen sehr engen Spektralbereich oder gar nur um eine Frequenz geht, lässt sich ein Filter (auch ein analoges) leicht so auslegen, dass das niedrig frequente Mischprodukt herausgeblockt werden kann.
W.S. schrieb: > Da wären für dein > Vorhaben allenfalls 7 oder 8 CORDIC-Schritte nötig, die restlichen Bits > liefert dann der Rest. Bei der geringen Abtastrate ist Cordic einfacher und genauer, als eine gewaltige Tabelle. Wir berechnen für unsere Encoder-Lösungen Sin-Cos-Signale mit einer Genauigkeit von 32 Bit mit einem kleinen STM32.
Thread beobachten
Seitenaufteilung abschalten
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.