PWM auf der DDS

Fragen zur Software des digitalen Funktionsgenerators und des True-RMS-Messaufsatzes bitte hier stellen.
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

Wegen der Marker im Linear-Sweep-Modus: Ich hab da grade mal etwas gespielt, also prinzipiell geht das. Ich muß aber erst meinen Code von vor zwei Jahren wieder verstehen.

Einen Bug hab' ich noch entdeckt: Wenn man die (normale) Frequenzeinstellung auf Terz-Modus umstellt, dann ist der auch bei den Start- und Stopfrequenzen für den Sweep aktiv. Aber irgendwie greift die Routine immer zuächst auf den alten Wert zu, also wenn man grade den Startwert z.B. auf 100Hz gestellt hat und der Endwert steht bei 8000Hz und man ändert diesen, dann springt der erst mal auf die 100Hz. Hmmm.

Gute Nacht
Paul

[EDIT]
So, heute nochmal drüber nachgegrübelt und die Änderungen eingebaut. Jetzt gibt es auch im Linear-Sweep-Modus Marker (der Code ist aber noch nicht eingecheckt). Dabei sind aber zwei Fragen aufgetaucht:

a) Beim absoluten Octave-Marker-Modus bezieht sich der Code auf eine "Frequenz" 6.875Hz. Ich hab keine Ahnung mehr, wie ich darauf komme. Könnte aber auch ein Fehler sein, denn der Kommentar sagt, daß sich die Marker auf 2^x Hz befinden (was sie aber nicht tun). Ich kann das jetzt ändern, aber bei der Gelegenheit die Frage an die "Musiker" unter uns: wäre es nicht sinnvoller, die absoluten Octave-Marker auf 2^x*(eine Grundfrequenz) zu legen? Wenn ja, welche?

b) Im relativen Marker-Modus beziehen sich die Marker auf die Centerfrequenz. Das ist für den Log-Modus perfekt, aber im Linearmodus Quatsch. Soll ich mich für die Marker im Linear-Sweep nicht besser auf die Startfrequenz beziehen?

Der zusätzliche Code frißt derzeit etwas mehr als 600 Byte, das ist aber noch vertretbar. Was meint Ihr?

Viele Grüße
Paul

[EDIT2]
Die Ursache für das Problem mit dem Terzmodus habe ich auch lokalisiert. Leider hatte ich damals mit der Implementierung (schnell-schnell 8) ) nicht bedacht, daß es nicht nur die normale Frequenzeinstellung gibt, sondern eben auch 3 für den Sweep-Modus (Start, Stop, Center). Es gibt aber nur eine (1) Variable (uint8_t gc_TerzNum) für den Terz-Index. Eine einfache Lösung wäre, entsprechend die Indizes für die restlichen drei Frequenzen nachzurüsten (ist jeweils nur ein Byte), und eine entsprechende Fallunterscheidung zu machen. Noch Ideen?
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

thoralt hat geschrieben: Das mit dem 5. Kapitel ist eine gute Idee. Ich werde da mal einen Platzhalter einfügen. Und nein, eilig ist es nicht, aber wenn PWM dann zufriedenstellend funktioniert, dann schreibt sich der Text fast von alleine :)
+ Kapitel 5 angelegt
+ Kleine Korrekturen
+ Review-Kommentare im tex-File als Kommentar (diffen oder nach DKS suchen)

Grüße Karsten
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 263
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Re: PWM auf der DDS

Beitrag von thoralt »

psclab38 hat geschrieben: So, heute nochmal drüber nachgegrübelt und die Änderungen eingebaut. Jetzt gibt es auch im Linear-Sweep-Modus Marker (der Code ist aber noch nicht eingecheckt).
Coole Sache!
Dabei sind aber zwei Fragen aufgetaucht:

a) Beim absoluten Octave-Marker-Modus bezieht sich der Code auf eine "Frequenz" 6.875Hz. Ich hab keine Ahnung mehr, wie ich darauf komme.
Aber ich: Kammerton A = 440 Hz / 64, also 6 Oktaven unterhalb von A. Somit beziehst Du Dich auf A, was gar nicht so verkehrt ist. Hat zwar keinen echt technischen Hintergrund, ist aber nachvollziehbar.
Könnte aber auch ein Fehler sein, denn der Kommentar sagt, daß sich die Marker auf 2^x Hz befinden (was sie aber nicht tun). Ich kann das jetzt ändern, aber bei der Gelegenheit die Frage an die "Musiker" unter uns: wäre es nicht sinnvoller, die absoluten Octave-Marker auf 2^x*(eine Grundfrequenz) zu legen? Wenn ja, welche?
Nun, wenn Du _wirklich_ einen Parameter (z. B. "SWP MARKER BASE") im Menü dafür verwenden willst, dann wäre es sinnvoll, dass der die Bezugsfrequenz für oktavischen und dekadischen Sweep gleichzeitig vorgibt - ohne Unterschied. Aber ich könnte auch mit festen Werten (440 Hz, 1000 Hz bzw. Vielfache/Teile davon) leben.
b) Im relativen Marker-Modus beziehen sich die Marker auf die Centerfrequenz. Das ist für den Log-Modus perfekt, aber im Linearmodus Quatsch. Soll ich mich für die Marker im Linear-Sweep nicht besser auf die Startfrequenz beziehen?
Äh - ja. Ich freue mich schon auf die Formulierung des Kapitels im Handbuch :) (Das habe ich bis jetzt bewusst ausgelassen).
Der zusätzliche Code frißt derzeit etwas mehr als 600 Byte, das ist aber noch vertretbar. Was meint Ihr?
Das ist OK, ich habe derzeit noch 992 Bytes frei, und die Implementierung des PWMLo/Hi braucht nicht mehr viel. Wenn es dennoch nicht reichen sollte, müssen wir eben hier und da noch ein bisschen "Luft rauslassen". Als letzte Waffe können wir noch den Kommandozeilenaufruf von gcc ziehen (steht in der main.c ganz oben als Kommentar), um alles mit einem Mal zu compilieren (2786 Bytes frei).
Die Ursache für das Problem mit dem Terzmodus habe ich auch lokalisiert. Leider hatte ich damals mit der Implementierung (schnell-schnell 8) ) nicht bedacht, daß es nicht nur die normale Frequenzeinstellung gibt, sondern eben auch 3 für den Sweep-Modus (Start, Stop, Center). Es gibt aber nur eine (1) Variable (uint8_t gc_TerzNum) für den Terz-Index. Eine einfache Lösung wäre, entsprechend die Indizes für die restlichen drei Frequenzen nachzurüsten (ist jeweils nur ein Byte), und eine entsprechende Fallunterscheidung zu machen. Noch Ideen?
Das halte ich für eine sinnvolle, weil einfach umzusetzende Lösung. Wie Captain Picard sagen würde: Machen Sie's so!
dg1vs hat geschrieben:+ Kapitel 5 angelegt
+ Kleine Korrekturen
+ Review-Kommentare im tex-File als Kommentar (diffen oder nach DKS suchen)
Danke! Ich habe die Änderungen gemerged und wieder eingecheckt (die Änderungen sind aber nur minimal). Hast Du eigentlich eine Umgebung, um TeX compilieren zu können? Für Eclipse gibt es das Texlipse-Plugin. Allerdings brauchst Du dafür noch den ganzen großen TeX-Haufen, welcher die wirkliche Arbeit macht (für Windows z. B. MiKTeX). Ich habe mir für MacOS mal ein komplettes Paket mit allem Drum und Dran installiert, das waren respektable 3 GB (es geht aber auch kleiner).

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

thoralt hat geschrieben: Danke! Ich habe die Änderungen gemerged und wieder eingecheckt (die Änderungen sind aber nur minimal). Hast Du eigentlich eine Umgebung, um TeX compilieren zu können? Für Eclipse gibt es das Texlipse-Plugin. Allerdings brauchst Du dafür noch den ganzen großen TeX-Haufen, welcher die wirkliche Arbeit macht (für Windows z. B. MiKTeX). Ich habe mir für MacOS mal ein komplettes Paket mit allem Drum und Dran installiert, das waren respektable 3 GB (es geht aber auch kleiner).
Bei den Musik-Sachen hängt ihr mich ab, aber ich frag mal meinen Sohn.....

Ja ich nutzte MikTex, lief gestern auch durch, aber ich wollte nur das source-file einchecken, wegen den Kommentaren.

Grüße Karsten
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

Hallo *

ich habe in meinen alten tex-Projekten gestöbert und die Docu etwas erweitert. Nicht viel, aber immerhin. Kommentare sind gerne gesehen.

Grüße Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

Hi Thoralt,
thoralt hat geschrieben:
psclab38 hat geschrieben:a) Beim absoluten Octave-Marker-Modus bezieht sich der Code auf eine "Frequenz" 6.875Hz. Ich hab keine Ahnung mehr, wie ich darauf komme.
Aber ich: Kammerton A = 440 Hz / 64, also 6 Oktaven unterhalb von A. Somit beziehst Du Dich auf A, was gar nicht so verkehrt ist. Hat zwar keinen echt technischen Hintergrund, ist aber nachvollziehbar.
Oh je, lalalaaaaaaaa ... ! Ich hatte den Kammerton schon in Verdacht, hab ihn aber irgendwie vor lauter Frequenzen nicht mehr gehört. :roll:
thoralt hat geschrieben:
psclab38 hat geschrieben:Könnte aber auch ein Fehler sein, denn der Kommentar sagt, daß sich die Marker auf 2^x Hz befinden (was sie aber nicht tun). Ich kann das jetzt ändern, aber bei der Gelegenheit die Frage an die "Musiker" unter uns: wäre es nicht sinnvoller, die absoluten Octave-Marker auf 2^x*(eine Grundfrequenz) zu legen? Wenn ja, welche?
Nun, wenn Du _wirklich_ einen Parameter (z. B. "SWP MARKER BASE") im Menü dafür verwenden willst, dann wäre es sinnvoll, dass der die Bezugsfrequenz für oktavischen und dekadischen Sweep gleichzeitig vorgibt - ohne Unterschied. Aber ich könnte auch mit festen Werten (440 Hz, 1000 Hz bzw. Vielfache/Teile davon) leben.
Nein, einen neuen Parameter will ich nicht einführen, das lassen wir dann so, wie es ist.
thoralt hat geschrieben:
psclab38 hat geschrieben:b) Im relativen Marker-Modus beziehen sich die Marker auf die Centerfrequenz. Das ist für den Log-Modus perfekt, aber im Linearmodus Quatsch. Soll ich mich für die Marker im Linear-Sweep nicht besser auf die Startfrequenz beziehen?
Äh - ja. Ich freue mich schon auf die Formulierung des Kapitels im Handbuch :) (Das habe ich bis jetzt bewusst ausgelassen).
Im Quellcode steht jetzt:

Code: Alles auswählen

	// absolute Marker Mode - Markers are set to  10^x Hz for Decade and 2^x * 440Hz for Octave
	// relative Marker Mode - Markers are set to  2^x or 10^x *fCenter for Log and 2^x or 10^x *fStart for Linear
Ist eigentlich ganz einfach. :D
thoralt hat geschrieben:
psclab38 hat geschrieben:Der zusätzliche Code frißt derzeit etwas mehr als 600 Byte, das ist aber noch vertretbar. Was meint Ihr?
Das ist OK, ich habe derzeit noch 992 Bytes frei, und die Implementierung des PWMLo/Hi braucht nicht mehr viel. Wenn es dennoch nicht reichen sollte, müssen wir eben hier und da noch ein bisschen "Luft rauslassen". Als letzte Waffe können wir noch den Kommandozeilenaufruf von gcc ziehen (steht in der main.c ganz oben als Kommentar), um alles mit einem Mal zu compilieren (2786 Bytes frei).
Ich konnte noch etwas sparen, es sind "nur" 582 Bytes verbraucht worden. Manche "Sparmaßnahmen" mußte ich aber wieder zurückbauen, die haben deutlich mehr verbraucht. Die Änderungen sind recht überschaubar, und den Code konnte ich auch ein klein wenig klarer gestalten. Ich nehme mal an, ich kann das mal nach Sourceforge hochladen, ohne Deinen Änderungen in die Quere zu kommen?
thoralt hat geschrieben:
psclab38 hat geschrieben:Die Ursache für das Problem mit dem Terzmodus habe ich auch lokalisiert. Leider hatte ich damals mit der Implementierung (schnell-schnell 8) ) nicht bedacht, daß es nicht nur die normale Frequenzeinstellung gibt, sondern eben auch 3 für den Sweep-Modus (Start, Stop, Center). Es gibt aber nur eine (1) Variable (uint8_t gc_TerzNum) für den Terz-Index. Eine einfache Lösung wäre, entsprechend die Indizes für die restlichen drei Frequenzen nachzurüsten (ist jeweils nur ein Byte), und eine entsprechende Fallunterscheidung zu machen. Noch Ideen?
Das halte ich für eine sinnvolle, weil einfach umzusetzende Lösung. Wie Captain Picard sagen würde: Machen Sie's so!
Ay, Captain!
[EDIT]
Ich sehe aber grade, ganz so einfach ist es doch nicht. Speziell, weil die drei Sweep-Frequenzen von einander abhängen, und diese Berechnung geht nunmal nicht nur im Terz-Raster. Oh je...

Viele Grüße
Paul
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

psclab38 hat geschrieben:
thoralt hat geschrieben:
psclab38 hat geschrieben:Die Ursache für das Problem mit dem Terzmodus habe ich auch lokalisiert. Leider hatte ich damals mit der Implementierung (schnell-schnell 8) ) nicht bedacht, daß es nicht nur die normale Frequenzeinstellung gibt, sondern eben auch 3 für den Sweep-Modus (Start, Stop, Center). Es gibt aber nur eine (1) Variable (uint8_t gc_TerzNum) für den Terz-Index. Eine einfache Lösung wäre, entsprechend die Indizes für die restlichen drei Frequenzen nachzurüsten (ist jeweils nur ein Byte), und eine entsprechende Fallunterscheidung zu machen. Noch Ideen?
Das halte ich für eine sinnvolle, weil einfach umzusetzende Lösung. Wie Captain Picard sagen würde: Machen Sie's so!
Ay, Captain!
[EDIT]
Ich sehe aber grade, ganz so einfach ist es doch nicht. Speziell, weil die drei Sweep-Frequenzen von einander abhängen, und diese Berechnung geht nunmal nicht nur im Terz-Raster. Oh je...
Mission ausgeführt, Captain! Die Behebung hab' ich jetzt doch anders realisiert, dabei ist die Variable gc_TerzNum gleich ganz rausgeflogen. Jetzt rechnet die Routine zwar jedesmal beim Drehen am Encoder die Frequenzen um, aber das geht ja fix.

Bei der gegenseitigen Umrechnung der Sweep- End- und Centerfrequenzen ist immer der aus den beiden anderen berechnete Wert nicht im Terz-Raster. Wenn man den aber manuell verstellt, dann springt er im Raster.

Weiterer Vorteil: die PWM-Frequenzeinstellung wird auch im Terz-Modus unterstützt. Ein wenig Feintuning ist vielleicht noch nötig, weil die Frequenzen durch die Quantisierung immer ein wenig unter oder über der Nominal-Terzfrequenz liegen. Damit ist beim Umdrehen der Encoder-Drehrichtung die Frequenz nicht identisch. z.B. beim Raufdrehen: 4.001kHz und beim Runterdrehen: 3.999kHz. Bei den niedrigeren Frequenzen ist das vielleicht nicht so offensichtlich, weil dieser Effekt bei den nicht sichtbaren Kommastellen passiert.
@Thoralt: Ein Hinweis: ich hab Deinen Quantisierungscode ein paar Zeilen runtergeschoben. Bitte nicht übersehen.

Der Code ist auch online. Die Änderungen haben übrigens nicht mal Speicher verbraucht.

Viele Grüße
Paul
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

dg1vs hat geschrieben:Hallo *

ich habe in meinen alten tex-Projekten gestöbert und die Docu etwas erweitert. Nicht viel, aber immerhin. Kommentare sind gerne gesehen.

Grüße Karsten
Hi Karsten,

irgendwie sind wir das 0D0A-Problem noch nicht los. Das dds-german.pdf, das Du gestern eingecheckt hast, war ziemlich kurz. Ich habe das heute lokal neu erzeugt und versucht hochzuladen. Ist mir aber weder mit UNIX noch mit DOS Modus gelungen. Wird entweder viel zu kurz oder aus 0D werden mit Gewalt 0A. :?: :roll:
Grüße
Paul
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

psclab38 hat geschrieben:
dg1vs hat geschrieben:Hallo *

ich habe in meinen alten tex-Projekten gestöbert und die Docu etwas erweitert. Nicht viel, aber immerhin. Kommentare sind gerne gesehen.

Grüße Karsten
Hi Karsten,

irgendwie sind wir das 0D0A-Problem noch nicht los. Das dds-german.pdf, das Du gestern eingecheckt hast, war ziemlich kurz. Ich habe das heute lokal neu erzeugt und versucht hochzuladen. Ist mir aber weder mit UNIX noch mit DOS Modus gelungen. Wird entweder viel zu kurz oder aus 0D werden mit Gewalt 0A. :?: :roll:
Grüße
Paul


Local passt alles, aber die aktuelle ist auf sourceforge auch defekt. Es kommt wieder... man müßte es als binary hochladen, ich such gerade die Option in der gui.

Beim "adden" hat man die Möglichkeit das File als binary zu kennzeichnen. Passiert bei mir wenn ich ein pdf neu einpflegen würde. Das Handbuch-pdf wird aber als ascii-geführt. "removen" und neu "adden", aber da trau ich cvs nicht über den Weg?

Grüße Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

dg1vs hat geschrieben: Beim "adden" hat man die Möglichkeit das File als binary zu kennzeichnen. Passiert bei mir wenn ich ein pdf neu einpflegen würde. Das Handbuch-pdf wird aber als ascii-geführt. "removen" und neu "adden", aber da trau ich cvs nicht über den Weg?
Na, getraut hab ich dem cvs schon, aber bei dem Versuch die Datei zu löschen hänge ich jetzt bei

cvs update: conflict: removed dds-german.pdf was modified by second party

Au weia...

Grüße
Paul
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

psclab38 hat geschrieben:
dg1vs hat geschrieben: Beim "adden" hat man die Möglichkeit das File als binary zu kennzeichnen. Passiert bei mir wenn ich ein pdf neu einpflegen würde. Das Handbuch-pdf wird aber als ascii-geführt. "removen" und neu "adden", aber da trau ich cvs nicht über den Weg?
Na, getraut hab ich dem cvs schon, aber bei dem Versuch die Datei zu löschen hänge ich jetzt bei

cvs update: conflict: removed dds-german.pdf was modified by second party

Au weia...

Grüße
Paul
Soll ich auch mal, da ich kurz vorher nochmal mit den Zeilenenden gespielt habe. Oder wir bennen das tex-file und das pdf-file um .... .

VG Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

dg1vs hat geschrieben: Soll ich auch mal, da ich kurz vorher nochmal mit den Zeilenenden gespielt habe. Oder wir bennen das tex-file und das pdf-file um .... .
VG Karsten
Klingt wie eine Erklärung, probier mal...
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

psclab38 hat geschrieben:
dg1vs hat geschrieben: Soll ich auch mal, da ich kurz vorher nochmal mit den Zeilenenden gespielt habe. Oder wir bennen das tex-file und das pdf-file um .... .
VG Karsten
Klingt wie eine Erklärung, probier mal...
Versuch mal....

Auf sourceforge passt es nun.

Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 949
Registriert: 25.01.2008, 23:34

Re: PWM auf der DDS

Beitrag von psclab38 »

dg1vs hat geschrieben:
psclab38 hat geschrieben:
dg1vs hat geschrieben: Soll ich auch mal, da ich kurz vorher nochmal mit den Zeilenenden gespielt habe. Oder wir bennen das tex-file und das pdf-file um .... .
VG Karsten
Klingt wie eine Erklärung, probier mal...
Versuch mal....

Auf sourceforge passt es nun.

Karsten
Ja, geht jetzt. Hatte schon Schweiß auf der Stirn... CVS hatte sich bei mir aber richtig verhakt und ich mußte in ein neues Verzeichnis frisch aktualisieren. Im alten ließ sich der Konflikt nicht lösen. Merke: vor dem Löschen muß man den lokalen Stand frisch vom Server aktualisiert haben.

Wieder was gelernt.

Grüße
Paul
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: PWM auf der DDS

Beitrag von dg1vs »

psclab38 hat geschrieben: Ja, geht jetzt. Hatte schon Schweiß auf der Stirn... CVS hatte sich bei mir aber richtig verhakt und ich mußte in ein neues Verzeichnis frisch aktualisieren. Im alten ließ sich der Konflikt nicht lösen. Merke: vor dem Löschen muß man den lokalen Stand frisch vom Server aktualisiert haben.
cvs ist Steinzeit, aber immer noch besser als gar kein KM-Tool! Selbst große Firmen (oder gerade große???) tun sich mit neuen KM-Konzepten schwer.

Karsten
Antworten