Forum: FPGA, VHDL & Co. DDS mit FPGA - Speicher vs. Rechnen in Echtzeit


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens W. (jensw)


Lesenswert?

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

von Rezy (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Gerhard H. (ghf)


Lesenswert?

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
von Jens W. (jensw)


Lesenswert?

Hallo Gerhard,

das schau ich mir mal an.
Vielen Dank für den Hinweis.

Grüße, Jens

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Rezy (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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

von Rezy (Gast)


Lesenswert?

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..

von Rezy (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Rezy (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Audiomann (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Georg B. (georg2011) Benutzerseite


Lesenswert?

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.

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

@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

von Jens W. (jensw)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Rezy (Gast)


Lesenswert?

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) + ...

von Jens W. (jensw)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Rezy (Gast)


Lesenswert?

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)

von Jens W. (jensw)


Lesenswert?

Hallo Rezy,

bin ich blind!
Ok, jetzt hab ich das gerafft! Recht herzlichen Dank!
Jetzt macht es Sinn was da steht!

Grüße, Jens

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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:

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Rezy (Gast)


Lesenswert?

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 ;)

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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. :-)

von Rezy (Gast)


Lesenswert?

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

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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.
von Mampf F. (mampf) Benutzerseite


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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

von Jens W. (jensw)


Lesenswert?

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

von Audiomann (Gast)


Lesenswert?

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.

von Jens W. (jensw)


Lesenswert?

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

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

Und natürlich das Bild vergessen...

: Bearbeitet durch User
von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

und natürlich das Bild vergessen...
Sorry

von Audiomann (Gast)


Lesenswert?

Das sieht - mit Verlaub - schlimm aus. Kann es sein, dass der Tiefpass 
nicht korrekt dimensioniert ist?

von Duke Scarring (Gast)


Lesenswert?

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

von Jens W. (jensw)


Lesenswert?

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

von Audiomann (Gast)


Lesenswert?

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.

von Rezy (Gast)


Lesenswert?

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!

von Jens W. (jensw)


Lesenswert?

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

von Audiomann (Gast)


Lesenswert?

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!

von Rezy (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Jens W. (jensw)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von Audiomann (Gast)


Lesenswert?

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.

von jensw (Gast)


Lesenswert?

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

von Ottakar (Gast)


Lesenswert?

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!

von Jens W. (jensw)


Lesenswert?

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

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

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

von Mampf F. (mampf) Benutzerseite


Lesenswert?

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
von Dogbert (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.