Durch eine Recherche bei go...le stieß ich heute auf diese Art der Sinuserzeugung. Stichwort ist "Sunderland Zerlegung", offenbar publiziert um 1984 herum. Leider ergibt die Suche fast keine Ergebnisse außer immer wieder denselben Bezug zu der genannten Publikation und der Grafik oben. Folgende Fragen: 1) Angeblich wird der Vektor (hier 12 Bit) in 3 Fragemente geteilt, welche der Vorschrift a<2(-1) , b<2(-4) und c<(-8) gehorchen. Das schon erkenne ich in der Grafik nicht wirklich wieder. So wie es scheint, werden die Vektoren einfach 4-Bit-weise geteilt. Dabei wären "A" die oberen 4, "B" die mittleren 4 und "C" die unteren 4. D'accord? 2) In den beiden Boxen finden sich dann zwei unterschiedliche Vorschriften zur Erzeugung der Werte. Dabeit ist mir widerum nicht klar, wie die Vektoren zugeführt werden müssen: Sind das nun beide Werte zwischen 0 und 15 parallel oder muss der jeweils obere 4 Bits nach oben geschiftet werden, sodass das Argument 8 Bit hat? 3) Was die Rechenvorschrift angeht: Komisch finde ich, dass der Sinus aus (a+b) gebildet wird, wo ich eigentlich Werte von 0 ... 1 erwartet hätte. Ich nehme an, man muss sie noch durch 16 teilen, um sie zu skalieren? Dann läuft (a+b) aber von 0 ... 2. Wobei die PI/2 dazu passen könnten. D'accord? Oder sind es Werte von 0 ... 255 wegen 8 Bit CONCAT? und dann durch 256? 4) Was ist mit "nicht b" gemeint? Der Balken über dem b ist eine Inversion der Bits, was streng genommen dazu führt, dass man die gesamte Formel als boolsche Formel lesen müsste und das "+" als Oder lesen sollte. Ich nehme aber an, dass das b einfach auf ein (1-b) hinausläuft? Also 15-x oder sind es 16-x? 5) Wie ist der Ausgang zu interpretieren? Müssen die Sinuswerte noch auf 9 und 4 Bit skaliert werden? Wie werden sie verrechnet? Im Text steht etwas von EXOR, aber das Symbol ist eher ein Connector. Werden nur die unteren 4 Bits verrechnet oder kommt die Tabelle von oben mit 9 Bits und hinten kommen 13 raus? ------------------- Ich habe verschiedene Versionen probiert, komme aber zu keinem Sinus. Nicht annähernd. Irgendwie muss sich das aber lösen lassen denke ich. Hat jemand einen Tipp? Die nächste Frage wäre dann: 6) Kann man die Vorschrift skalieren? Also z.B. doppelte Bits rein, doppelte Bits raus?
Angehängte Dateien:
-
sunderland_rom_sinus.gif
35 KB
Eine weitere Unklarheit: Im "FINE ROM" werden alle 3 Variablen benutzt, um den Tabellenwert zu definieren: "a", "nicht b" und "c". Daher braucht es dort 12 Bit = 4096 Einträge. D'accord? Angesteuert wird die Tabelle aber nur mit A und B, also 256 Möglichkeiten. Printed man die Tabelle, ist die aber nicht von b unabhängig. Christoph db1uq K. schrieb: > da heisst es "Sunderland algorithm" Das bringt leider neue Konfusion, denn da kommen hinten nicht 9,4 Bits sondern 11, 4 heraus. Ferner ist die sich ergebende letzlich als optimal hingestellte Struktur nach der dortigen Publikation wieder eine etwas andere.
M. W. schrieb: > Hat jemand einen Tipp? Guck dir einfach mal die Theorie an, die bei dem Algorithmus im Hintergrund steht: https://de.wikipedia.org/wiki/Formelsammlung_Trigonometrie#Additionstheoreme Der Sunderland Algorithmus stellt eine Verbesserung des Hutchison Algorithmus dar.
Angehängte Dateien:
-
sunderland_rom_sinus.gif
58 KB
Wolfgang schrieb: > Der Sunderland Algorithmus stellt eine Verbesserung des Hutchison > Algorithmus dar. Das habe ich auch schon gelesen. Die Theorie ist eigentlich auch klar. In einer anderen Seite findet sich diese Tabelle. Das sieht schon logischer aus, ist aber am Ende nichts anderes als ein Sinus über die höchsten 8 der 12 Bits. Es entsteht ein Viertelbogen mit jeweils 16 identischen Werten, wegen der unteren 4 Bits. Allerdings kriege ich die Vorschrift für das fine RAM nicht hin. So wie es dort steht, geht es nicht. Die Zwischenbögen interpolieren nicht sauber.
Angehängte Dateien:
Hier ist die Summation beider Werte: Es muss für die Werte im ROM 2, dem fine rom, ein Bogen herauskommen, der fast eine Gerade ist und weiter oben in der STeigung abflacht. Das Abflachen leistet der COS(c), der gegen PI gegen 0 geht. Das passt! Die Gerade liefert der Sinus mit den unteren 4 Bits. Die Krümmung passt aber nicht. Ist zu stark gekrümmt. Aber nur bei diesem Ausschnitt X/16 * PI liefert er die richtige Amplitude. Kann es sein, dass die weggelassenen Restterme / Bits die Ursache sind?
Angehängte Dateien:
-
AD9835_450kHz.jpg
89 KB -
absunderlich.png
73 KB
Wenn ich das Ausgangssignal meines DDS hier vergrößert anschaue, hat der auch ähnliche Stufen. Die kochen alle nur mit Wasser.
Ui, genau so sieht das aus! Da frage ich mich aber, was das dann soll. Ist das linear nicht besser?
> Da frage ich mich aber, was das dann soll. Hardware sparen und gleichzeitig schnell sein. > Ist das linear nicht besser? Mach mal in HW. Und im Prinzip ist das Fine-ROM doch nichts anderes - 16 unterschiedliche Interpolationssegmente, die oberen Bits wählen das Segment aus, die unteren die Punkte des Segments.
> Eine lineare Interpolation in HW ist trivial.
Auch, wenn du direkt auf bestimmte Punkte innerhalb des
Interpolationsintervalls zugreifen willst? Also nicht inkrementell
einen Punkt nach dem anderen?
Warum nicht? Entweder, ich lese zwei Punkte aus der Tabelle und bilde die Steigung, oder ich lege sie gleich so ab. Beim Sinus hast du dann gleich den Cosinus. Der Rest ist Y = a * x + b.
Ob die Stufen so deutlich sichtbar sind, hängt vom Verhältnis Taktfrequenz zu Ausgangsfrequenz ab, hier war es gerade so, dass die still stehen. Normalerweise werden sie aber schnell wandern, dann sind sie am Oszilloskop nicht mehr zu erkennen. Spektral ist das ja eine ziemlich hohe Harmonische. Außerdem habe ich ja einen kleinen Ausschnitt der Sinuskurve vergrößert. Und der AD9835 hat nur 14 Bit und ist relativ alt.
:
Bearbeitet durch User
Ich bezog mich auf die Bögen, die gerade im unteren Bereich auszumachen sind.
Angehängte Dateien:
-
ISBN_9780070702561.png
72 KB
ja die meine ich auch. Wenn ich die Frequenz verstelle, sind die Bögen nicht mehr zu sehen. Einige DSP-Literatur vor allem ältere, kennt den Namen Sunderland. Hier in ISBN 9780070702561 wird von drei Tabellen gesprochen, im Gegensatz zu Hutchison, der nur zwei hat. books.google.com findet noch mehr zum Thema.
:
Bearbeitet durch User
Markus W. schrieb: > Entweder, ich lese zwei Punkte aus der Tabelle und bilde > die Steigung, Bei nicht näher definierten Verläufen ja, aber bei einem Sinus findet man den Cosinus auch 90° später in der Tabelle. Geht bei einem FPGA mit Lesen auf zwei Seiten im Block-RAM in voller Geschwindigkeit. M. W. schrieb: > Ist das linear nicht besser? Es kommt nur auf die Relation an! Mit der Sunderland-Methode kriegt man pro ROM-Platz den besseren Sinus heraus. Er ist auch etwas besser, als das Zusatz-RAM wegzulassen und linear zu interpolieren. Die Bögen, die durch diese Interpolation (nicht) entstehen, entsprechen den Resten, die der Sinus produziert, wenn man eine Gerade abzieht. Ich hatte vor einiger Zeit hier eine Grafik gepostet, in der die Fehler der Interpolation bei einfachen Tabellen aufgezeigt wird: Beitrag "Präzise Sinus-DDS mit kleiner Tabelle" Diese kleinen Teilbögen im Bild links oben bekommt man mit Sunderland reduziert (wenn auch nicht weg). Und obwohl das etwas buckelig aussehen mag, ist es mitunter besser, weil die entstehenden Oberwellen geringer sind. Die Bögen sind runder. Die Frage insgesamt aber ist aus meiner Sicht, ob man das überhaupt mit einer Tabelle machen muss, weil man (wie im Artikel angedeutet) mit 1GHz im ASIC Sinüsse generieren will, oder ob man das nicht auch komplett per Rechnung erledigen kann. Nach meinen bescheidenen Versuchen ist es meistens zweckmäßiger, das mit einer Ersatzrechnung zu tun, wenn man etwas Rechenzeit hat. Ich hatte hier einen Sinus gepostet, der mit einem 8Bit-Rechner erzeugt werden kann. Der Fehler ist kleiner, als bei Sunderland gleicher Phasen- und Amplitudenauflösung! Man braucht also weniger Speicherfläche, sondern nur mehr Rechnerei, also etwas mehr Kombinatorik oder in einem AVR mehr Zeit. https://www.mikrocontroller.net/articles/Datei:Opimierte_naeherung_sinusfunktion2_js.png Wenn man es in einer Tabelle machen möchte, wofür es bei anderen Pulsformen mehr Berechtigung gibt, als beim Sinus, dann kann man eine Grobtabelle aus den Werten vorgeben und hinterlegen und eine Feintabelle mit Korrektur werten von der VHDL-Synthese berechnen lassen, indem man die Grobwerte von den Zielwerten abzieht und sie mit dem feiner aufgelösten Vektor ins Verhältnis setzt. Je nach Geschmack schiebt man das ins BRAM oder in eine WHEN -Tabelle, die die Synthese dann berechnet und ins LUTs abbildet. Ich verfahre z.B. so bei einigen WAVE-TABLE-SYNTHESIS-Modulen, die eine Grundfrequenz haben: Diese wird in der Soll-Tabelle abgezogen und nur die Differenz gespeichert. Damit fallen 3-4 Bits der Amplitude weg, die weniger gespeichert werden müssen. Mit einem BLock-RAM, das nur 18 Bit breit ist, bekommt man so locker einen 20Bit genauen Wert. Hintendrein muss natürlich einmal addiert werden, aber Adder ist beim Mixer mit drin und die Wellenformen laufen eh alle parallel zu jederzeit mit, weil im FPGA alles zur gleichen Zeit existiert. Mit etwas Geschick bekommt man damit kostenlos eine gewaltige zusättzliche Zahl von Wellenform-Kombinationen, die praktisch kaum mehr Speicher oder Rechenaufwand machen. Was reine Sinuserzeugung angeht, habe ich eine Version, die aus nur 9 18-Bit-Multiplizieren besteht und einen Sinus auf > 16 Bit genau produziert. Hinzu kommt die Filterung und Interpolation.
Christoph db1uq K. schrieb: > ja die meine ich auch. Wenn ich die Frequenz verstelle, sind die Bögen > nicht mehr zu sehen. Ist auch kaum anzunehmen, dass ein DDS-Chip die gleichen Fehler produziert. Das kommt eher von den Stufen bei geringen Frequenzen und dem Filter und seiner darauf nicht angepassten Grenzfrequenz. Das ergibt Kondensatorladekurven. M. W. schrieb: > Eine lineare Interpolation in HW ist trivial. Auch eine quadratische Interpolation ist in HW nicht sonderlich aufwändig. Man braucht dann aber 2+1 Punkte. Ich frage mich aber gerade etwas anders: Wenn ich die beiden Bilder vergleiche, welche die Sunderland'schen Tabellenwerte beschreiben, dann ist oben einmal eine Geradengleichung (a+b) mit enthalten und unten nicht. Kann es sein, dass da etwas fehlt? Die Gleichung oben sieht nämlich irgendwie so aus, wie ich es in der gelinkten Grafik gezeigt habe: Eine Gerade welche die Punkte linear verbindet und den entstehenden Rest als lauter Sinusbögen, die Sunderland versucht, mit dem Zusatz-ROM wegzunehmen. Vielleicht muss diese Gerade in das Korrektur-ROM mit hinein? Christoph db1uq K. schrieb: > Hier in ISBN 9780070702561 wird von drei Tabellen gesprochen, Was nur logisch wäre, weil es drei Phasenvektoren sind. Allerdings lässt man ja die mittleren Bits weg, wegen der Identität. Dem dürfte die dritte Tabelle zum Opfer gefallen sind.
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.