Entwicklung eines freien LS-Messprogramms

Jawollja, die Skripterei funktioniert so wie ich es mir gedacht habe. Schnell, einfach, zuverlässig.

Eine Messung bei drei verschiedenen Lautstärken (75, 85, 95) hat bei mir gerade einmal 17 Sekunden gedauert.

Es geht doch nichts über Geschwindigkeit.

Wegen der anderen Möglichkeit: ich kann nichts rausschmeißen, was nicht drin ist. Zumindest habe ich die nötigen Schnittstellen, um das zu aktivieren, ich müsste mich nur hinsetzen und das ordentlich fertig machen.

Gruß
Cpt.

Unix, besonders die mitgelieferten Tools, ist etwas wunderbares.

Bei diesem Skript zur Verzerrungsmessung hat mich bisher nur eines gestört: die Ausgabe ist in Dezibel. Prozentwerte wären ganz nett.

Nungut, wie macht man das am besten? Eine von esweep erzeugte Textdatei mit einem Spektrum in polaren Koordinaten hat folgende Form:

- am Dateikopf Kommentarzeilen, die mit '#' anfangen
- danach die Daten in 3 Spalten:
Frequenz Amplitude Phase

In diesem Fall liegt die Amplitude in Dezibel vor, also muss man die irgendwie nach Prozent umrechnen. Und im Ergebnis sieht das dann so aus:

sed '/#/D' "$j/temp.txt" | awk -v "ref=$j" '{print $1" "100*(10^(($2-ref)/20))}' > "$j/k$i.txt";

Kryptisch. Aber ein Einzeiler.

Dröseln wir das mal auf.

'sed' ist der Stream Editor. Der wendet ein paar Kommandos auf die angegebene Datei an. In diesem Fall macht der '/#/D' auf die Datei "$j/temp.txt". In der stehen die Werte in Dezibel, "$j" ist eine Variable und enthält den aktuellen Nutzpegel (z. B. 95dB), für jeden legt das Skript ein eigenes Verzeichnis an.

Das Kommando '/#/D' macht folgendes: '/#/' ist ein sogenanntes Pattern, und bedeutet, dass der nachfolgende Befehl - hier das 'D' - nur auf _Zeilen_ der Datei angewandt wird, in denen das Zeichen '#' vorkommt. 'D' bedeutet dabei ganz einfach: Zeile löschen. Also entsorgt dieser Befehl alle Zeilen der Eingabedatei, in denen ein '#' vorkommt, damit wären die Kommentarzeilen Geschichte.

'sed' schreibt das Ergebnis auf stdout, d. h. er würde uns die Kommandozeile mit pro Datei 2049 Zeilen vollmüllen. Das wollen wir aber nicht, wir wollen die weiterverarbeiten. Dafür gibt es dann den senkrechten Strich '|'. Der erzeugt eine "pipe" zu dem dann zwingend notwendigen zweiten Befehl. Die "pipe" sorgt für nichts anderes, als das der folgende Befehl statt einer normal angegeben Eingabedatei stdout nimmt (oder anders gesprochen: die "pipe" leitet stdout nach stdin um und der Befehl list von stdin).

Der nächste Befehl ist 'awk'. 'awk' ist eine Programmiersprache (bzw. deren Interpreter), die noch kryptischer als 'sed' daherkommt (kommen kann). Der häufigste Anwendungsfall ist das selektive Schreiben (auf stdout) von Spalten einer Eingabedatei, eine Zeile anch der anderen. Aber 'awk' kann noch mehr, es kann nämlich auch rechen, und vor allem, im Gegensatz zur Shell selber, auch mit Gleitkommezahlen, und das sogar noch viel besser als C. Also rechnen wir einfach, bzw. zuerst schreiben ("print") wir die erste Spalte "$1". Weil 'awk's' "print" zwischen den einzelnen Bestandteilen kein Leerzeichen lässt, müssen wir dort eines einfügen, das geht mit dem " ". Im nächsten Teil wird dann gerechnet: der Wert in der zweiten Spalte ("$2") minus den Referenzwert ("ref"), den wir mit der Option "-v ref=$j" definiert haben. Nochmal zur Erinnerung, "$j" ist der aktuelle Nennschalldruck. Das ganze dann geteilt durch 20, als Potenz von 10 ("10^(..)") und multipliziert mit 100, schon haben wir die Werte in Prozent. Wers nicht glaubt, soll das mit nem Taschenrechner nachmachen.

Natürlich brauchen wir diese Ergebnisse in einer Datei. 'awk' schreibt wie 'sed' nach stdout, um es von da in einer Datei zu bringen braucht es den Umleitungsoperator ">". Der legt die Zieldatei - hier "$j/k$i.txt", wobei "$i" die aktuelle Ordnung des Klirrs ist - neu an (oder überschreibt sie) und befördert alles was auf stdout kommt in diese Datei. Im übrigen, falls man stdout an eine Datei anhängen möchte, dann benutzt man den doppelten Umleitungsoperator, ">>".

Das wars. Noch Fragen?

Ich wollt Euch eigentlich nur ein bisschen quälen. Übrigens lässt sich der 'awk'-Befehl auch anders schreiben, ohne "-v ...". Aber das ist nicht wichtig. Doch wie mir scheint, als ich die Anleitung zu 'awk' durchgelesen habe, lässt sich evtl. der 'sed' weglassen. Schaun mer mal.

Gruß
Cpt.

P.S.: wenn ich nett bin bringe ich morgen das Skript online, genauso wie das zur schnellsten Directivity-Messung aller Zeiten .

So sieht das Ergebnis einer Directivity-Messung aus:



Aus irgendeinem Grund sind die Farben in der Colorbox beim Exportieren etwas verrutscht, macht aber nichts, den Tannenbaum kann man auch so gut erkennen.

Das sind 37 Messungen (-180°-0°, 5° Auflösung), der Spaß war nach 6 Minuten durch. Eigentlich noch viel zu lange, aber das per Hand ausrichten ist so aufwändig. Und dann immer zum Computer hinspringen und ein Knöppsche drüggen.

Die Messung ist auf 0° normiert, das kostet eine Minute, ohne Normierung wärs also nochmal schneller. Die Normierung erfolgt über ein PERL-Skript.

Wie lange braucht man eigentlich bei ARTA oder anderen Programmen für eine vergleichbare Messung?

Gruß
Cpt.

Hallo,

Arta: Dodekaeder im RAR aller 15° 0 bis 180° in ca. 10 min (geschätzt). Inklusive Sonogramm und einfachem Polarplot.
Nicht gerechnet sind allerdings Transport, Aufbau und Verkabelung, aber bei Dir sicher auch nicht.

In dieser Hinsicht ist Arta vielleicht gerade ausreichend bestückt. Etwas umständlich aber immer noch, weil Dateien per Hand umzubenennen sind, könnte man ggf. auch automatisieren.

Danke Cpt.!

tiki schrieb:

Arta: Dodekaeder im RAR aller 15° 0 bis 180° in ca. 10 min (geschätzt).

Ahja. Dreifache Auflösung => dreifache Zeit. Also 30 Minuten. Welches Messsignal hast Du benutzt?

Inklusive Sonogramm und einfachem Polarplot.

Nun gut, da muss man ein wenig Konzession betreiben. Um das abgebildete Spektrogramm hinzubiegen habe ich ne knappe halbe Stunde gebraucht. Die aber nie wieder, weil ich mir dazu eine Vorlage geschaffen habe. Deswegen schlappe 6 Minuten.

Wegen dem Polarplot muss ich mich noch mit gnuplot beschäftigen, am Energiefrequenzgang arbeite ich noch (ist ein PERL-Skript, Lösung habe ich heute gefunden, ist aber noch nicht perfekt). Kostet ungefähr ne zusätzliche Minute.

Nicht gerechnet sind allerdings Transport, Aufbau und Verkabelung, aber bei Dir sicher auch nicht.

Natürlich nicht.

Etwas umständlich aber immer noch, weil Dateien per Hand umzubenennen sind, könnte man ggf. auch automatisieren.

Je nachdem, wie sie vorher abgespeichert wurden.

Danke Cpt.!

Bitte!

Gruß
Cpt.

Uff! Meßsignal? Ich glaube, es war MLS (white/periodic noise?), der Einfachheit wegen. Hat dort im RAR auch niemanden/nichts gestört und wurde auch nicht gestört.
Die Bilder hat der Verrückte und ich zu Hause, vergess ich ständig.

In der alten Version (0.2) konnte man sich auch den klassischen Wasserfall mit auf Perioden basierter Darstellung erzeugen. Das ist zugunsten des faltungsbasierten CSDs aber rausgefallen. Was nicht heißt, dass das überhaupt nicht mehr ginge. Man muss nur den kleinen Freund awk (und ein wenig sed) benutzen.

Dazu lässt man esweep in gewohnter Weise den klassischen Wasserfall berechnen und erzeugt eine Textdatei. Die hat die Form:

<Dateikopf>
<Frequenz> <Zeit> <Amplitude>

Man muss nur die Zeit in Perioden umrechnen, und schon hat man es. Damit man das mit awk machen kann, muss als erstes der Dateikopf entsorgt werden (mit sed), das Resultat wird dan an awk gepiped und dessen Ausgabe in eine Datei geschrieben.

Das sieht dann so aus:

sed '/#/D' in.txt | awk '{print $1,$1*$2,$3}' > out.txt

Schreiend einfach. sed löscht alle Zeilen, in denen ein '#' vorkommt (also den Dateikopf) aus der Datei in.txt, awk schreibt Spalte 1, dann Spalte 1 mulipliziert mit Spalte 2 und zum Schluss Spalte 3 auf stdout und das wird in die Datei out.txt umgeleitet.

$1*$2? Klar doch: die Frequenz ist der Kehrwert der Periodendauer T, also f=1/T, multipliziert mit der in Spalte 2 stehenden Zeit ergibt einen Bruchteil einer Periode.

Alles janz einfach.

Gruß
Cpt.

Saacht mal, würde Euch eine menübasierte Steuerung zusagen? Erster Entwurf sieht ungefähr so aus:


Bitte wählen:

1) Neue Messung
2) Vorhandene Messung auswerten
x) Ende


Durch Auswahl von "Neue Messung" kommt man dann ins nächste Menü:


Bitte wählen:

1) Impulsantwort
2) Multisinus
3) Directivity
x) Zurück


So hangelt man sich dann durch.

Ich habe nämlich festgestellt, dass sich so ein Menü furchtbar einfach in einer Shell skripten lässt. Anzeige der Messdaten würde weiterhin über ein externes Programm laufen, allerdings nur statisch, d. h. keine Spielchen ala Anzeigebereich wechseln. Sowas kommt in eine Konfigurationsdatei.

Gruß
Cpt.

Na, das wäre zumindest ein sehr guter Ansatz, um die Bedienbarkeit auch für Laien angenehmer zu machen.

Moin,

ich weiß, Gnöbbsche drügge ist manchem intuitiver. Ich muss auch zugeben, dass dieses Menu sehr hilft. Es ist im übrigen schon ziemlich weit fortgeschritten, mit Speichern und Laden, ich hätte gern noch sowas wie ein Overlay drin, aber da hab ich noch ein wenig dran zu knacken.

Gruß
Cpt.

Nicht nur manchen, den meisten.

Ich finde es auch immer wieder beeindruckend, wenn Linux-User mit einer Zeile in der Console eine CD rippen, die MP3s sortieren, Laufwerk hda1 defragmentieren und noch einen Kaffee kochen. Ich drück aber trotzdem lieber Gnöppsche, dauert zwar ein bisschen länger, aber dafür muss ich nicht vorher 3 Handbücher gefressen haben...

Moin,

weils mir grad aufgefallen ist: im Chassistest der aktuellen HH kann man an einem Chassis sehr schön den Nachteil des klassischen CSD bewundern. Der Thiel 12.1 scheint ja insgesamt relativ langsam auszuschwingen, aber das stimmt nicht. Schaut Euch mal die einzelnen Slices an und vergleicht die mit dem hier in Bild 4 dargestellten Spektrum eines plötzlich abgeschalteten Sinussignal.

Wie man an der Bildunterschrift in der HH erkennen kann führt das durchaus mal zu falschen Schlüssen.

Gruß
Cpt.

Moin,

die Tage las ich im Visaton-Forum etwas über das adaptive Fenster eines einschlägigen Messprogramms (MLSSA). Und dachte ich mir: moment, das kannste auch.

Erstmal worum es geht: der normale Hobbybastler hat meistens keinen RAR zur Verfügung in dem er bis 70Hz hinunter reflexionsfrei messen kann. Die einzige Lösung für ihn heißt, eine Messung über die Impulsantwort zu machen (ansonsten ginge das nämlich auch mit nem RTA ganz fein) und die Raumreflexionen auszublenden. Denn ansonsten bekommt er einen welligen Frequenzgang, der zwar die tatsächliche Situation des Lautsprechers im Messraum zeigt, aber nicht zu einer Frequenzweichenentwicklung taugt.

Das adaptive Fenster macht nun nichts anderes, als für verschiedene Frequenzbereiche unterschiedlich lange Impulsantwort auszuwerten. Eigentlich wird das von MLSSA dazu benutzt, um einen Lautsprecher passend auf einen Raum entzerren zu können, denn dazu braucht nicht jeder Frequenzganghubbel - der auch noch positionsabhängig ist - entzerrt zu werden, sondern das ganz soll gerade im Mittel- und Hochton sehr breitbandig geschehen.

Aber auch in der Boxenentwicklung kann das vorteilhaft sein, und zwar wenn man die Box entweder zusammen mit dem Raum entwickeln will, oder sie ihrer natürlichen Umgebung anpassen möchte - bei Standboxen z. B. im stehen und nicht frei in der Luft schwebend (was für ein Unsinn, nicht wahr?).

Gerade im letztgenannten Fall ist so ein adaptives Fenster von Vorteil, ermöglicht es doch die Entwicklung einer allgemeinverträglichen Box, die im Bass den Raum miteinbezieht, im Mittel- und Hochtonbereich aber schnurgerade ist (sein kann).

Und nun kommen wir also zum adaptiven Fenster in esweep. Zuerst messen wir eine Impulsantwort, wie das geht ist hinreichend beschrieben. Aus der schneiden wir uns erstmal eine lange heraus, auch der Vorgang sollte bekannt sein. Wir nehmen 100ms, das ist lang genug um auch wirklich alles wichtige mit aufzunehmen. Der Frequenzgang sieht dann natürlich katastrophal aus:



Das ist eine ganze Box, aber jeder wird mir zustimmen, dass eine saubere Frequenzweichenentwicklung damit nicht möglich ist. Und dabei ist dieser Frequenzgang schon mit 1/12-Oktave geglättet.

In meinem Messaufbau trifft die erste Reflexion nach 5ms ein. Für einen reflexionsfreien Frequenzgang im Mittel- und Hochton dürfte ich also ein Fenster mit maximal 5ms Breite wählen. Das gibt eine Frequenzauflösung von 200Hz, im MHT völlig ausreichend, im Bass viel zu wenig. Ich habe in dem Beispiel hier 4ms gewählt, macht eine Auflösung von 250Hz.

Nun habe ich beide Impulsantworten ausgeschnitten und muss sie noch fouriertransformieren. Wichtig ist dabei, dass sie beide mit gleichen FFT-Länge transformiert werden. Die lange Impulsantwort (100ms) besteht bei einer Abtastrate von 44,1kHz aus 4410 Abtastwerten, die nächsthöhere Zweier-Potenz ist 8192. esweep wählt automatisch immer die nächsthöhere Zweier-Potenz, außer man wünscht explizit eine andere. Das muss hier gemacht werden, weil die kurze Impulsantwort nur aus 176 Samples besteht. Mit dem Parameter und der Option "-l 8192" kann man dem esweep-Modul die gewünschte Länge mitteilen.

Und nun kommt der eigentlich Trick: diese beiden Spektren müssen aneinandergefügt werden. Dazu gibt es das Modul concat. Das Spektrum der langen Impulsantwort liegt in "long.fft", das der kurzen in "short.fft", das Ergebnis kommt nach "concat.fft". Der Zusammenschluss soll bei 500Hz erfolgen. Dann lautet der Befehl:

esweep concat -o concat.fft -f 500 long.fft short.fft

Wichtig ist die Reihenfolge, in der die Quelldateien am Ende stehen: die erste bestimmt nachher den unteren, die zweite den oberen Teil des Spektrums. Und im Ergebnis schaut das dann so aus:



Hier sind alle 3 Kurven übereinandergelegt.

Und was nutzt einem das jetzt? Nun, ich könnte diesen Frequenzgang jetzt in ein Simulationsprogramm laden und eine Weiche basteln, die den Raum berücksichtigt. Dann würde ich z. B. dafür sorgen, dass der Mittelton um grob 2dB angehoben wird (wenn das denn geht, muss der MT ja mitmachen, nech?), um das Room-Gain im oberen Bass mitzunehmen. Denn eigentlich ist dieser Lautsprecher völlig falsch abgestimmt: der Entwickler (zum Glück war das nicht ich) gleicht den baffle step aus und vergisst dabei, dass so eine kleine Kompaktbox gerne mal in der Nähe einer Wand (so wie in dieser Messung) oder noch schlimmer im Regal betrieben wird. Und im Endeffekt bläst dieser Lautsprecher viel zu viel Energie bis in den Grundton hinein in den Raum, so dass die Wiedergabe dick und mulmig wird (manche würden "angenehm" sagen).

Also, ein ganz nettes Spielzeug. Schöner wäre natürlich ein RAR, aber wie ich schon ausführte: den hat nicht jeder.

Edit: um das ganze noch etwas schöner zu machen könnte man auch bei der FFT der langen IR eine Oktavglättung benutzen, bei der kurzen IR gar keine (braucht man da auch nicht). Dann wären die bösen Zacken untenrum weg, aber die Tendenz würde erhalten bleiben.

Gruß
Cpt.

Moin,

heute ist mir was janz feines gelungen, hauptsächlich zwar gut für die Mausathleten, aber ich find es auch nicht schlecht.

Bisher habe ich mit gnuplot immer ein Bild (z. B. PNG) rendern müssen, weil ich gnuplot nicht von einem externen Programm steuern konnte bzw. es sich immer sofort selbst beendete. Das ist kein Bug von gnuplot, das ist ein Feature. Wirklich. Normalerweise ist das sehr nett von ihm. Nur nicht hier.

Die Frage war nun, wie ich es hinbekomme, dass das gnuplot-Fenster offen bleibt und man on-the-fly die Beschriftung und Achsen ändern kann.

Die Lösung ist ein klitzekleines PERL-Skript, an dem ich aber richtig lange geackert habe, teils weil ich zu blöd bin, teils weil PERL es ist.

Dieses PERL-Skript läuft im Hintergrund und erhält als Argument eine Datei. Das PERL-Skript öffnet zusätzlich eine Pipe zu gnuplot und hält sie *offen* - das ist etwas, was mit der Shell nicht geht (oder ich weiß noch nicht wie mans macht). Das Shell-Skript schreibt die gnuplot-Befehle in die Datei und sendet an das PERL-Skript ein Signal, woraufhin dieses an gnuplot den Befehl sendet, genau diese Datei als Kommandodatei zu laden. Packt man da die richtigen Kommandos in der richtigen Reihenfolge hinein kann man die Anzeige ohne große Probleme erneuern.

Dieser kleine Teilerfolg bedeutet einen großen Schritt zur Fertigstellung der ultimativen Menusteuerung für esweep. Irgendwann ist sie fertig, vielleicht noch diesen Monat

Gruß
Cpt.

So, Freunde der Nacht. Die Shell-Menüsteuerung ist vorerst gekippt (was nicht heißt, dass die sich niemand selber basteln könnte), weil...

Ankündigung:

Es wird ein GUI geben

OK, nachdem jetzt die Sektkorken geknallt haben, die Einschränkungen:

1.) es wird vorerst sehr einfach
2.) es wird nie die volle Komplexität von esweep ausschöpfen
3.) die Darstellung der Daten wird weiter über gnuplot erfolgen (siehe vorherigen Post)
4.) das GUI wird nie zum Kernprojekt gehören, sondern als Skript-Applikation laufen

zu 2.) ich plane, eine Schnittstelle zu Skripten aus anderen Sprachen (Shell, Perl, Python, Tcl) zu implementieren, die man dann aufrufen und das Ergebnis betrachten kann; das ist aber noch ferne Zukunft

zu 3.) ich muss mal schauen, wie schnell mein GUI ähnlich große Datenmengen darstellen kann. Gnuplot ist da manchmal recht langsam, vor allem weil es die Daten jedesmal neu einliest (total hohl, was die Autoren sich dabei wohl gedacht haben?). Wenn das GUI schneller ist, wird die Darstellung darin erfolgen.

Nochmal: dieses GUI ist nicht offizieller Bestandteil des Projekts sondern lediglich eine Hilfe für diejenigen, denen das Programmieren von Skripten schwer fällt.

Und nun zum Grund meines Sinneswandels:

ich habe heute, nachdem ich die Möglichkeit der Steuerung von gnuplot über PERL erkannt habe, erst versucht die textbasierte Steuerung in PERL zu übersetzen, weil ich mir dann einige Klimmzüge erspare (nicht nur wegen gnuplot, bei komplizierten Sachen wird die Shell langsam zur Hölle).

Und dann habe ich mir gedacht, wenn ich schon mit PERL arbeite, dann kann ich mal einen Blick auf Perl/Tk werfen. Tk ist ein grafisches Toolkit, mit dem im Handumdrehen Applikationen entstehen können - vor allem solche, wo es um Gnöbbsche drügge mit anschließender Reaktion seitens des Programms geht.

Und tatsächlich, ich habe - nach Einarbeitungsphase - in erstaunlicher Geschwindigkeit eine kleine Applikation aus dem Hut gezaubert.

Also, ich werde da ab jetzt kontinuierlich dran arbeiten, und es ist fertig wenn es fertig ist.

Ach, btw, ich suche immer noch jemanden mit zu viel Freizeit der sich ein wenig um meine Webseite kümmert. Aufhübschen, ein paar Texte schreiben, etc. Geld gibts keines, nur Hirnnahrung.

Gruß
Cpt.

Cpt._Baseballbatboy schrieb:

So, Freunde der Nacht. Die Shell-Menüsteuerung ist vorerst gekippt (was nicht heißt, dass die sich niemand selber basteln könnte), weil... Ankündigung: Es wird ein GUI geben

Ausgezeichnet!

Cpt._Baseballbatboy schrieb:

zu 2.) ich plane, eine Schnittstelle zu Skripten aus anderen Sprachen (Shell, Perl, Python, Tcl) zu implementieren, die man dann aufrufen und das Ergebnis betrachten kann; das ist aber noch ferne Zukunft

Ich hab 'mal sowas aehnliches aus Python/TclTk zusammengestrickt. Etwas gewoehnungsbeduerftig, aber ansonsten einfach zu machen. Das Python-script hat Shell-scripts, awk-files, etc. geschrieben und dann entsprechend aufgerufen. Es ist hilfreich wenn Anwender diese Scripts (oder direkt ausgefuehrte Befehle) zu sehen bekommen. Das erleichert das Erlernen der Low-Level Befehle, von denen man durch die GUI sonst vollkommen isoliert wird.

Die Python/TclTk-Kombination kann ich empfehlen solange das Projekt nicht zu gross und umfangreich wird - sonst wird's einfach zu unuebersichtlich. Mit Perl komme ich persoenlich nicht so gut klar. Fuer groessere Projekte wuerde ich Qt empfehlen, evtl ueber Python/Qt. Gratis fuer Linux et al, aber nur mit Lizenz fuer Windows. Qt ist eine Library fuer C++ und damit recht schnell.

Cheers,
c2007.

PS: Bin immernoch nicht dazugekommen mich mit dem Portaudio-Problem unter Gentoo-Linux zu beschaeftigen

Moin,

c2007 schrieb:

Cpt._Baseballbatboy schrieb: zu 2.) ich plane, eine Schnittstelle zu Skripten aus anderen Sprachen (Shell, Perl, Python, Tcl) zu implementieren, die man dann aufrufen und das Ergebnis betrachten kann; das ist aber noch ferne Zukunft Ich hab 'mal sowas aehnliches aus Python/TclTk zusammengestrickt. Etwas gewoehnungsbeduerftig, aber ansonsten einfach zu machen. Das Python-script hat Shell-scripts, awk-files, etc. geschrieben und dann entsprechend aufgerufen. Es ist hilfreich wenn Anwender diese Scripts (oder direkt ausgefuehrte Befehle) zu sehen bekommen. Das erleichert das Erlernen der Low-Level Befehle, von denen man durch die GUI sonst vollkommen isoliert wird.

ich habe so was ähnliches auch im Hinterkopf, nicht für dieses GUI-Projekt, vielleicht irgendwann mal. Vielleicht kennst Du VEE oder LabView, dort kann man einzelne Funktionsblöcke zu einem Programm zusammenfügen. Sowas ginge, auf esweep umgemünzt, auch. Die GUI-Anwendung würde dann ein Skript in einer beliebigen Sprache schreiben, was dann ausgeführt werden kann.

Für dieses aktuelle GUI habe ich mir schon ein paar Gedanken über die Schnittstelle zu Skripten gemacht, mal sehen wann ich das einbaue. Erstmal muss der Rest stehen.

Mit Perl komme ich persoenlich nicht so gut klar.

Es ist... ehm... manchmal seltsam. Nicht umsonst gibt es eigenartige Wettbewerbe wie den Obfuscated Perl Contest

Fuer groessere Projekte wuerde ich Qt empfehlen, evtl ueber Python/Qt. Gratis fuer Linux et al, aber nur mit Lizenz fuer Windows. Qt ist eine Library fuer C++ und damit recht schnell.

Qt in der Version 4 ist auch für Windows unter der GPL zu haben. Ich finde es eine sehr feine Schnittstelle, ziemlich ausgereift. Gibt auch ein Binding für Perl. An Python habe ich mich mal rangetraut, in Ermangelung eines realen Ziels (sprich: fertige Applikation) fehlte mir aber die Motivation. Perl war bei mir die logische Konsequenz aus der Beschäftigung mit der Shell-Programmierung, die sind sich doch sehr ähnlich. Unter anderen Umständen wäre ich u. U. an Python oder Ruby hängengeblieben.

Die meisten Tk-Module sind im übrigen auch in C geschrieben und werden dann mehr oder weniger nativ ausgeführt. Perl selber übersetzt den Quellcode bei jeder Ausführung in einen Bytecode, der recht flott ausgeführt wird. An die native Geschwindigkeit eines reinen C/C++-Kompilats kommt das nicht heran, aber der Unterschied ist nicht mehr besonders groß.

Gruß
Cpt.

Moin moin Cpt.,

Cpt._Baseballbatboy schrieb:

Moin, (Perl) ...ist... ehm... manchmal seltsam. Nicht umsonst gibt es eigenartige Wettbewerbe wie den Obfuscated Perl Contest

Den gibt es auch fuer C, was ansonsten ja so klar, knapp und buendig ist wie kaum eine andere Sprache. Aber mit #define und pointern laesst sich schon einiges machen
Obfuscated C contest

Cpt._Baseballbatboy schrieb:

An Python habe ich mich mal rangetraut, in Ermangelung eines realen Ziels (sprich: fertige Applikation) fehlte mir aber die Motivation.

Fuer alle C-Programmierer die ich so kenne war Python sehr leicht zu lernen. Die Sources werden auch erst zu Bytecode kompiliert, und das ganze laeuft dann im Prinzip recht fix. Nur bei groessere Mengen von graphischen Daten macht sich der Unterschied zu "richtingen" Compilersprachen dann doch bemerkbar. Eignet sich hervorragend fuer Scripts, weniger gut fuer die Commandline.

Cheers,
c2007

ich bin beeindruckt was da so alles auf die beine gestelt wird.

logischer weise frag ich mcih natürulcih warum man die entwickler power nicht in schon grosse programme investiert und verfeinert anstatt imme rwieder neu zu beginnen.

SAT LIVE www.tomy-pa.de wäre so ein projekt

ARTA etc pp und viele ander kleine Messprogramme die sei so gibt selbst auf sorceforge findet man ein paar wenige.

Hallo Cpt.,
lang nicht reingeschaut, böse von mir, ich weiß.
Die GUI-Ankündigung ist sehr freundlich, ist es möglich, daß Du zunächst bzw. auch an die Tastaturfetischisten denkst, die in der verbotenen Zone zwischen Kommandozeile und Maus herumhantieren? Mit anderen Worten an mich?
Abends fällt mir immer fast der Arm ab, weil die blöden nicht winkonformen Programme nicht durchgängig Tastaturbedienung erlauben. Vielleicht kannst Du das vorteilhaft mit den sowieso vorhandenen Befehlen (Anfangsbuchstaben etc.) verbinden.

Mein Sohnemann hatte heute seine letzte Prüfung. Wenn er aus dem Koma wieder aufwacht (diese Jugend heutzutage!), kann ich ihn mal mit Deinen Aufgaben konfrontieren. Kann gut sein, daß er nicht abgeneigt ist. Ein wenig Erfahrung mit Webseitenbastelei hat er schon, nur kaum Muße in der letzten Zeit.

Ich hatte Bedarf an einem Messprogramm, mit dem sich schnell mal eine Terzmessung machen lässt. Das Programm erzeugt über die Soundkarte (Vollduplex, 48 kHz) ein periodisches pseudo-zufälliges rosa Rauschsignal (Pseudo Random Periodical Pink Noise) und wertet die Leistung online in Terzschritten aus. Da es sich um ein pseudo-zufälliges Signal handelt, hat man bereits nach sehr wenigen Mittelungen ein stabiles Ergebnis. Mit dem kleinen Programm kann man gut die Aufstellung und den Abgleich von Subwoofern überprüfen, Equalizer einstellen oder auch die Funktion von Frequenzweichen überprüfen, ohne gleich eine "ausgewachsene" Messsoftware starten zu müssen. Es ist bewusst spartanisch ausgestattet, um so einfach wie möglich zu bedienen zu sein. Das macht es auch für Anfänger interessant.

Hier geht's zum Download und zu weiteren Erläuterungen: http://www.michaelgaedtke.de/SubMen...Terz_Manual.htm

Viel Erfolg beim Messen!

Moin,

Link ist kaputt, das hier ist der richtige: http://www.michaelgaedtke.de/SubMenu_Messen/Terz_Manual.htm

Gruß
Cpt.

Moin,

das mit dem GUI kann noch ein wenig dauern. Ich habe festgestellt, dass gnuplot zwar ganz toll beim Skripten ist, aber im interaktiven Gebrauch leicht Schwachstellen aufweist. Deswegen bastel ich gerade an einem eigenen Darstellungsprogramm, dass ein wenig auf die Bedürfnisse des LS-Entwicklers abgestimmt ist. Das wird dann in das GUI eingebunden.

Stattdessen habe ich gestern die Zweikanalmessung eingebaut, zumindest unter OpenBSD. In meiner ToDo-Liste war dafür 1 Woche angesetzt, gebraucht habe ich dafür 1h. War viel einfacher als ich gedacht hatte, weil eigentlich alles wichtige schon vorbereitet war. Da muss ich mir wohl schon früher mal nen Kopf drum gemacht haben.

Gruß
Cpt.

sobald ne gui vorhanden ist, werde ich das proggie auf meine "to-test"-Liste setzen*g*

bin halt ausser Gnöppsche-drück-fraktion, aber dennoch hochinteressiert!

Hi Cpt.,
der brave Programmierer nutzt Python.
Tu es!

Moin,

nur weil Dein Diplomand Python nutzt heißt das ja noch nicht, dass ich das auch muss, oder?

Wo ich gerade Deinen Namen lese, da fällt mir doch was ein was ich mir notiert hatte, war irgendwas mit nem Vortrag oder so Hmmm, nächste Woche mache ich da was fertig.

So, wie geht es mit esweep weiter. Mit meiner GUI-Ankündigung habe ich mich ganz schön reingerissen. Weil ich die Skriptfähigkeit nicht aufgeben möchte muss ich mit der aktuellen Version ganz schön tricksen. Es geht, aber ist nicht gerade etwas was man "komfortabel" nennen könnte.

Also habe ich mir in den letzten Wochen ein paar Gedanken gemacht. Und herausgekommen ist die Idee, den in C programmierten Part als Bibliothek zu gestalten und drumherum eine Schnittstelle zu verschiedenen Skriptsprachen zu basteln. Zu diesem Zweck gibt es SWIG, ein freies Tool, das alle möglichen Sprachen unterstützt, Tcl, Perl, Python etc.

Im Moment konzentriere ich mich da auf Tcl, weil das grafische Toolkit Tk genau dafür entworfen wurde (auch wenn es das inzwischen auch für Perl und Python gibt, was aber kein Nachteil ist). Außerdem ist Tcl eine sehr schöne Sprache und für den Laien einfach zu benutzen (ganz im Gegensatz zum unglaublich mächtigen Perl, und das OOP von Python ist auch nicht jedermans Sache).

Das Interface wird möglichst einfach gestaltet. esweep kennt 4 Datentypen, Wave (Folge reeller Zahlen), Complex (Folge komplexer Zahlen), Polar (Folge komplexer Zahlen in eulerscher Darstellung), Surface (dreidimensionale Fläche). Teiweise lassen die sich ineinander umwandlen, das wichtigste ist aber, dass der Nutzer sich nur selten damit herumzuplagen braucht (auch wenn das Wissen darüber nicht von Nachteil ist). Sämtliche Funktionen sind so gestaltet, dass sie erstmal jeden Datentyp akzeptieren, aber nicht jeden bearbeiten können.

Das ganze ist ne Gratwanderung zur hohen Flexibilität, die mit der kommenden Version auf die Spitze getrieben wird. Die aktuelle war im Vergleich dazu ein Witz. Es gibt z. B. die Cepstrum-Analyse: das ist die IFFT des logarithmierten Betragsspektrums. Dadurch lassen sich Reflexionen an Gehäusekanten ziemlich genau entdecken (ansonsten gehen die nämlich im allgemeinen Gewaber unter). Mit dem aktuellen esweep undenkbar (hat keine IFFT, peinlich, peinlich). ARTA kann das auch nicht, die anderen Programme? Ich glaube DAAS war das erste, ansonsten Fehlanzeige (vielleicht noch MLSSA, das ist viel mächtiger als man denkt - und vor allem wird es weit unter seinen Fähigkeiten verwendet). Also, Cepstrum-Analyse:

- Impulsantwort berechnen
- FFT
- polares Spektrum logarithmieren (Dezibel)
- IFFT

Mit der neuen Version kein Problem, denn genau diese Operationen sind (teilweise noch feiner) disktretisiert.

Nur: wie macht man das dem gemeinen Nutzer zugänglich?

Prinzipiell bleibt die Skriptfähigkeit, d. h. man kann sich solche Vorgänge automatisieren, ohne GUI. Mit GUI ist die ganze Sache schon komplizierter. Und da habe ich mir folgende Sachen überlegt:

- alle möglichen Operationen sind über die Menüleiste zugänglich

- ein Makro-Rekorder ermöglicht, die verwendeten Operationen erneut zu verwenden

- zusätzliche Skripte lassen sich ebenfalls ausführen

Der Unterschied zwischen Makros und Skripten wird einfach darin liegen, dass die Makros lediglich aufgenommen Befehle wieder abspielen (latürnich auf die aktuelle vorhandenen Daten), die Skripte aber auch grafische Oberflächen beinhalten können.

Alles was ich gerade beschrieben habe gehört in die Kategorie "geplant". Die Bibliothek macht sehr gute Fortschritte, mit ein bisschen Glück bin ich nächste Woche damit fertig. Das GUI wird mehr oder weniger parallel entwickelt, allerdings fehlt da noch ein Anzeige-Teil. Das hatte ich eigentlich (zumindest für zweidimensionale Daten) fertig, dann aber festgestellt, dass die Lizenz nichts taucht*.

Gruß
Cpt.

* das ist ein sehr hübsche und für mein Empfinden sogar sauber programmierte C++-Klasse in Qt. Will die jemand haben?

Kann zweidimensionale Darstellungen, zwei Y-Achsen, Y als auch X logarithmisch darstellbar, 2 X-Marker, 2 Y-Marker, angezeigt wird aktuelle Position und Differenz. Ziemlich frei konfigurierbar, es lässt sich quasi alles auch zur Laufzeit verändern. Und es ist einigermaßen schnell. Stelle ich unter der GPL zur Verfügung, also wer es haben will bei mir inkl. Mailadresse vorstellig werden.

Hallo Cpt.

unglaublich, was Du da so zurechtzauberst, mit einer beneidenswerten Ausdauer.
Ja nee, Python muß natürlich nicht, es ging nur um die Umgebung, mit der sich die Einzelmodule, wie Bibliotheken ornlich verbinden lassen. Völlig klar, daß Du einen größeren Überblick über das Brauchbare hast. Leider ist es auch nicht "mein" Diplomand, sondern er wandert dieses Wochenende zum DLR nach Göttingen ab, um dort den verdünnten Gasströmungen zu frönen.
Auf jeden Fall bin ich saumäßig gespannt auf Deine Präsentation. Nicht nachlassen!

Moin,

ich hab Euch mal nen Screenshot vom noch lange nicht fertigen GUI gemacht.



Ich will nämlich ein wenig den dahinter liegenden Gedanken erklären.

Zuerst: was sieht man? Oben die Menüleiste, links eine Liste der Daten und das große weiße wird später mal der Darstellungsbereich. Im Moment ist das nur ein Platzhalter.

Wenn man das Programm startet ist erstmal nichts zu sehen - keine Grafik, keine Daten. Die muss man sich erstmal erzeugen. Das geht über den Menüpunkt "Generate" (je nach Fleiß wird das Programm noch lokalisiert), da kann man sich Sinusse, Sweeps oder anderes Gedöns zusammenstellen und auch bearbeiten (schneiden, zusammenfügen, AM/FM/PM, etc.). Das ist nicht überaus komfortabel, aber es ist auch nicht vorgesehen, dass man das besonders oft macht.

Sobald man sich ein Signal (Datentyp "Wave", es gibt noch "Complex", "Polar" und "Surface" (<- sehr kompliziert)) erstellt hat erscheint in der Leiste links das Objekt "current" - hinter dem doppelten Doppelpunkt ist dann noch der Datentyp vermerkt - und wird angezeigt (im Bild natürlich noch nicht zu sehen, weil der entsprechende Programmteil fehlt).

Dieses Signal kann man dann auf verschiedenste Arten missbrauchen - mit einem anderen Falten/Entfalten, FFT, IFFT, skalieren, multiplizieren, potenzieren, logarithmieren, was eben die Mathematik so hergibt. Das ist alles hinter den Menüpunkten versteckt, und jede Operation wird immer auf den Datensatz mit der Bezeichnung "current" angewendet bzw. auf "current" und einen vorher gespeicherten Datensatz. Speichern - geht ganz einfach, irgendwo habe ich da einen Menüpunkt versteckt der den Datensatz "current" kopiert und unter anderem Namen in die Liste einfügt (hier: "sine", weils ein Sinus ist).

Es gibt nirgends irgendwelche Menüpunkte wie "Impulsantwort messen" oder "IMD messen". Der Zugriff auf solche "höheren" Funktionen erfolgt über Makros oder Skripte. Eigentlich sind Skripte auch nur bessere Makros, aber das sind unwichtige Interna.

Ein Makro kann man sich aufzeichnen: im Menü "Macros" gibt es die Funktion "Start Recording", und ab da werden alle Schritte aufgezeichnet, bis man "Stop Recording" drückt. Das Makro wird dann abgespeichert, kann noch mit einer Funktionstaste verbunden werden und kann danach immer wieder erneut schnell und einfach abgespielt werden.

Beispiel: messen der Impulsantwort

1.) "Start Recording"
2.) logarithmischen Sweep erstellen; dabei erscheint ein Dialog der die möglichen Optionen bereithält, das Makro wird diesen Dialog umgehen
3.) den Sweep speichern
4.) den Sweep abspielen und die Systemantwort aufnehmen
5.) Entfaltung der Systemantwort (ist in "current") mit dem Sweep
6.) Sweep löschen
7.) "Stop Recording"

Dieses Makro verbindet man dann mit z. B. "F1" und hat dann innerhalb weniger Sekunden die Impulsantwort auf dem Tisch.

Klar wie es läuft?

Gruß
Cpt.

Moin,

weil ich es kurzfristig brauchte habe ich mir aus den Bruchstücken der kommenden Version einen kleinen Sinusgenerator gebastelt. So sieht er aus:



So einfach wie möglich. Die Bedienung ist grausam weil stockend, das lässt sich aber wohl nicht viel anders machen. esweep ist nicht auf Echtzeitanwendungen ausgelegt (also so Scherze wie ein RTA, wobei das durchaus im Bereich des Möglichen sein wird, ich werde es zumindest mal ausprobieren), deswegen musste ich ein wenig tricksen.

Der Quellcode dieses Sinusgenerators schaut so aus:


load ./esweep.so esweep

proc create_wave {freq} {
global samplerate length au_out

set wave [esweep_create wave $samplerate]
esweep_genSine $wave [expr ceil($freq*$length / $samplerate)*$samplerate/$length] \
[expr 1000*(0.0 + $length) / $samplerate]  0 $samplerate

esweep_confAudioData $au_out $wave $wave
esweep_free $wave
}

proc play_tone {} {
global play samplerate au_out au_handle
if {$play} {
esweep_play $au_out $au_handle
after 250 [info level 0]
}
}

set samplerate 44100
set length 32768
set au_out [esweep_create wave $samplerate]
set freq 440

scale .freq -label Frequency -variable freq \
-from 10 -to 20000 \
-bigincrement 100 \
-command {after 50 create_wave}

pack .freq
set au_handle -1
button .play -text Play -command {set play 1; set au_handle [esweep_open "/dev/sound" $samplerate]; play_tone}
button .pause -text Pause -command {set play 0; if {$au_handle >=0} {esweep_close $au_handle}; set au_handle -1}

pack .play -side left
pack .pause
.freq configure -state active

create_wave $freq
set play 0


Ganze 42 Zeilen. Lächerlich einfach.

Gruß
Cpt.

Moin,

der Cpt. hat sich mal wieder was feines aus seinen rumverseuchten Hirnwindungen gezogen. Wie immer gilt: vielleicht nicht neu, mir aber vorher nicht bekannt.

Folgende Schwierigkeit tut sich bei Messungen eines mehrwegigen akustischen Wiedergabegerätes immer wieder auf: die Phase.

Wie wir alle wissen macht die Laufzeit, verursacht durch Wegstrecke und Latenz des Messgerätes, aus der Phase alles mögliche, nur nichts verwertbares. Da werden dann so unnütze Dinge wie die "Minimalphase" ins Spiel gebracht, obwohl so ein Lautsprecher (als auch ein einzelnes Chassis) alles andere als minimalphasig ist.

Ich habe mir zu diesem komplexen Thema also ein paar Gedanken gemacht und bin auf eine recht einfache Lösung gekommen. Es ist ein simpler mathematischer Trick (eher eine Weglassung). Es geht über den Umweg der Gruppenlaufzeit, auch ein beliebtes Instrument zur Beurteilung von Lautsprechern, und wegen der mitgemessenen Laufzeit auch nicht das wahre.

Die Gruppenlaufzeit ist definiert als negierte Ableitung des Phasengangs p(w) über der Kreisfrequenz w:


     -dp(w)
t  = -----
 g    dw


Der Phasengang lässt sich als Linearkombination aus "Lautsprecher"-Phase (p_L) und "Laufzeit"-Phase (wT_L) schreiben:


p(w) = p (w) - w T
        L         L


Die Ableitung nach w ergibt:


p'(w) = p'(w) - T
         L       L


Der Strich am p sollte jedem aus der Schulmathematik geläufig sein.

Da haben wir also die Gruppenlaufzeit (abgesehen vom Vorzeichen) und sehen, dass die Laufzeit dort kräftig mitmischt. Eigentlich nur ein konstanter Faktor, aber wie eliminieren? Minimum der Gruppenlaufzeit? Mittelwert? Bestenfalls eine Annäherung.

Machen wir doch einfach Nägel mit Köpfen und das ganze exakt. Eine erneute Ableitung nach w macht folgendes:


p''(w) = p''(w)
          L


Schwupps, weg ist das T.

Aber der eigentliche Trick kommt jetzt erst, und ganz streng genommen ist der mathematisch nicht korrekt. Im Moment haben wir die Ableitung der Gruppenlaufzeit. Absolut nicht aussagekräftig. Um zurück zur GLZ zu kommen müssten wir integrieren. Integration in der allgemeinen Form lautet:


  /
 |
 | f'(x) dx = F(x) + C
 |
/


Denn das unbestimmte Integral von f'(x) hat unendlich viele Lösungen durch die Konstante C. Das wäre in unserer obigen Rechnung das T, und weil wir das einfach weglassen, bleibt die reine "Chassis"-GLZ übrig. Und das ganze nochmal integriert bringt uns die laufzeitbereinigte Phase. Brilliant.

Ist irgendein am Markt befindliches Messprogramm in der Lage, diese Berechnungen durchzuführen? Nicht das ich wüsste. Möglicherweise benutzen das einige, um die Laufzeit zu bestimmen, aber das glaube ich nicht. esweep kann es auch noch nicht, wird es aber in der nächsten Version können. Weil die dazu nötigen Funktionen vorhanden sind und weil sie allgemein genug gehalten wurden.

Natürlich kann der Cpt. viel erzählen wenn der Tag lang ist, ein paar Bilder dürfen nicht fehlen.

Ich habe mir eine um 100ms verzögerte ideale Impulsantwort geschaffen, nach einer FFT die obigen Berechnungen durchgeführt und das Ergebnis zurücktransformiert, wodurch eine weitere ideale Impulsantwort entstanden ist - völlig ohne Laufzeit.



Natürlich kann man auch die Laufzeit bestimmen, indem man die laufzeitbereinigte GLZ von der laufzeitbehafteten GLZ subtrahiert. Der Fehler betrug genau 1 Sample (hier 1/44100 Sekunde), was zu gut passt um Zufall zu sein (wenn ich dafür jetzt noch ne Erklärung hätte wärs perfekt).

Wie immer ist esweep allen anderen Programmen gnadenlos überlegen, in Funktionsumfang, Geschwindigkeit, und komplizierter Bedienung

Gruß
Cpt.

Moin moin Cpt,

erst mal ein kleines Kompliment: Deine Hirnwindungen sind wirklich verwunden. So verwunden, dass mir
da irgendetwas da noch nicht ganz klar ist.

Eine verzoegerte (um T_L) ideale Impulsantwort sieht etwa so aus
(LaTeX-speak, sorry, aber die ASCII-Formeln sind ziemlich unleserlich)

g(t) = \delta(t + T_L)

Die Fourier-transformierte ist dann

G(t) = \frac{1}{\sqrt{2\pi}} e^{i\omega T_L}

Ableiten nach der Zeit multipliziert die FT mit i\omega. Da das Signal keine konstanten Terme enthaelt, faellt auch nix weg. Und wieder aufintegriert kommt man wieder zum gleichen Ergebnis (ist ja auch ein bestimmtes Integral, von 0 bis t}.

Irgendwo ist Dein Trick da durch die Ritzen gefallen.

Wenn Du natuerlich nur den Modulus der FT nimmst, dann geht der komplexe Faktor natuerlich weg. Bei einem realistischen Signal geht das allerdings tief in die Hose. Versuch es z.B. mal mit zwei idealen Impulsantworten (deltas) im zeitlichen Abstand t...

Dann bleibt noch die Frage: Wozu die absolute Phase bestimmen? Relevant ist sicherlich nur die relative Phase der verschiedenen Frequenzen zueinander. Und anders als z.B. Neutronen breiten sich bein Schall alle Wellenlaengen mit der gleichen Geschwindigkeit aus. Zumindest in Luft, in irgendwelchen Absorbermaterialien koennte es da Unterschiede geben. D.h. alle phasenunterschiede kommen zwangslaeufig von der Quelle.

Cheers,
c2007.

Moin,

c2007 schrieb:

(LaTeX-speak, sorry, aber die ASCII-Formeln sind ziemlich unleserlich)

so schiet aber auch, die sind verrutscht. Früher hat das doch immer geklappt wenn ich die in CODE eingebettet habe.

Ableiten nach der Zeit multipliziert die FT mit i\omega.

Hier laufen Deine mit meinen Windungen asynchron. Die GLZ wird durch Ableitung des Phasengangs (e^jp(w)) nach w berechnet.

Dann bleibt noch die Frage: Wozu die absolute Phase bestimmen? Relevant ist sicherlich nur die relative Phase der verschiedenen Frequenzen zueinander.

Relevant ist bei der Lautsprecherentwicklung vor allem die absolute Phase inkl. Laufzeit jedes einzelnen Chassis relativ zur Messposition. Was ich hier mache ist hauptsächlich gut für die Darstellung, weil ein Phasengang, der sich wegen der Laufzeit alle 100Hz um 180° dreht einfach scheiße ausschaut. Und für die GLZ, weil die dann richtig angezeigt wird, ohne schädliche Laufzeiteinflüsse, die gelegentlich zu Fehlinterpretationen führen.

Gruß
Cpt.

Edit: ich habe die ASCII-Formeln repariert, Problem war ein nicht richtig geschlossenes CODE-Tag. Übrigens habe ich die mit aamath erstellt, sehr feines Programm, kann leider keine griechischen Zeichen (wie das LaTeX-\omega)

Moin auch,

ja, es war schon spaet gestern abend, und ich stand da ziemlich auf dem Schlauch.

Im Beispiel einer einfachen Delta-Distribution funktioniert das tatsaechlich ausgezeichnet.

++++ Erster Fall: Delta ohne Laufzeit:

g(t)=\delta(t)

G(\omega)= \frac{1}{\sqrt{2\pi}}

Die FT ist reel, hat damit Phase \Phi(\omega)=0 fuer alle \omega. Kann man ableiten und integrieren wie man will. Null bleibt null. Alles OK.

++++ Zweiter Fall: Delta mit Laufzeit T_L (der Peak kommt erst nach T_L):

g(t)=\delta{t-T_L)

G(\omega) = \frac{1}{\sqrt{2\pi}} e^{-i \omega T_L}

Hier ist die Phase ganz klar \Phi(\omega)=-\omega T_L

Abgeleitet nach \omega gibt -T_L = negative Gruppenlaufzeit, wie gewuenscht/definiert. Alles Prima. Zweite Ableitung ist natuerlich 0, weil kein \omega mehr da ist. Aufintegriert bleib's 0, und das Ergebnis ist das gleiche wie im ersten Fall.

Aber das hattest Du ja schon mit Deiner Graphik gezeigt.

Aber was passiert wenn die Testfunktion nicht so einfach ist?

++++ Dritter Fall: Zwei Deltas: Ein zweiter Peak im Abstand \tau, mit kleinerer Amplitude (-1 < x < 1):

g(t) = \delta(t) + x \delta(t-\tau)

G(\omega) = \frac{2}{\sqrt{2\pi}} (1 + x e^{i \omega \tau})

Man sieht schon, das ist complex und zappelt wenn man die Frequenz aendert. Die Phase ist hier

\Phi(\omega) = \atan(\frac{x \sin(\omega \tau)}{1+x \cos(\omega\tau)}

das Ableiten ueberlasse ich einem anderen Freiwilligen.

Verzoegern der Gesammtfunktion gibt wieder einen zusaetzlichen Faktor e^{-i \omega T_L}. Durch einfaches Ableiten ist dieser Faktor hier aber leider nicht zu isolieren/eliminieren.

++++ Kurzum: Wenn die Testfunktion symmetrisch zu t=0 ist, dann ist die FT reel, und Dein Trick funktioniert sehr gut. Wenn die Testfunktion aber asymmetrisch ist, dann ist schon die unverzoegerte FT complex, und Dein Trick wird ziemlich schwierig zu implementieren.

Wenn es darum geht die Phase eines Chassis relativ zu einem anderen zu messen, warum schliesst Du nicht eins an den linken Stereo-Kanal des Verstaerkers, das andere an den rechten, und generierst eine Serie von Testsignalen (Sinus) mit definierter Phasenlage. Damit kannst Du leicht die Phase maximaler konstruktiver und destruktiver Interferenz bestimmen.

(wollte sowieso schon vorschlagen die Measure und Play Funktionen von Esweep um eine Kanal-option zu erweitern, z.B. -k=l(eft) r(right) b(oth) a(antiphase)
Antiphase geht natuerlich leicht, nur Vorzeichen umdrehen. Andere Phasen muessen dann schon gleich bein Generieren eingerechnet werden.)

Cheers,
c2207

(hoffentlich hab ich es diesmal richtig verstanden. sonst gebe ich auf )

Moin,

c2007 schrieb:

++++ Dritter Fall: Zwei Deltas: Ein zweiter Peak im Abstand \tau, mit kleinerer Amplitude (-1 < x < 1): g(t) = \delta(t) + x \delta(t-\tau) G(\omega) = \frac{2}{\sqrt{2\pi}} (1 + x e^{i \omega \tau}) Man sieht schon, das ist complex und zappelt wenn man die Frequenz aendert. Die Phase ist hier \Phi(\omega) = \atan(\frac{x \sin(\omega \tau)}{1+x \cos(\omega\tau)} das Ableiten ueberlasse ich einem anderen Freiwilligen.

in der Tat, dann funktioniert es nicht. Das Problem dürfte sein, dass die GLZ in dem Fall negativ wird (steigende Phase). Möglicherweise funktioniert es unter der Vorraussetzung, dass die Impulsantwort (weitestgehend) reflexionsfrei ist. Ich hatte es gestern auch mal mit ner echten IR probiert, das schien zu klappen.

Wenn es darum geht die Phase eines Chassis relativ zu einem anderen zu messen, warum schliesst Du nicht eins an den linken Stereo-Kanal des Verstaerkers, das andere an den rechten, und generierst eine Serie von Testsignalen (Sinus) mit definierter Phasenlage. Damit kannst Du leicht die Phase maximaler konstruktiver und destruktiver Interferenz bestimmen.

Ich bin zwar noch jung, aber soviel Zeit habe ich auch nicht.

(wollte sowieso schon vorschlagen die Measure und Play Funktionen von Esweep um eine Kanal-option zu erweitern, z.B. -k=l(eft) r(right) b(oth) a(antiphase)

Das ist mit der kommenden Version kein Problem mehr.

Gruß
Cpt.

Moin moin,

Cpt._Baseballbatboy schrieb:

Moin, c2007 schrieb: ++++ Dritter Fall: ... in der Tat, dann funktioniert es nicht. Das Problem dürfte sein, dass die GLZ in dem Fall negativ wird (steigende Phase). Möglicherweise funktioniert es unter der Vorraussetzung, dass die Impulsantwort (weitestgehend) reflexionsfrei ist. Ich hatte es gestern auch mal mit ner echten IR probiert, das schien zu klappen.

Die Laufzeit \omega T_L wird immer auf die Phase addiert, und verschindet deshalb auch immer nach der zweifachen Ableitung. Das hattest Du ja schon beschrieben.

Das Problem ist eher dass die Ableitungen evtl. auch wertvolle Anteile der Testfunktion 'rausschmeissen.

Wenn es darum geht die Phase eines Chassis relativ zu einem anderen zu messen, warum schliesst Du nicht eins an den linken Stereo-Kanal des Verstaerkers, das andere an den rechten, und generierst eine Serie von Testsignalen (Sinus) mit definierter Phasenlage. Damit kannst Du leicht die Phase maximaler konstruktiver und destruktiver Interferenz bestimmen. Ich bin zwar noch jung, aber soviel Zeit habe ich auch nicht.

In der Regel geht es um ein Paar Frequenzen im Bereich wo die Weiche trennt. Pro Frequenz sagen wir mal alle Phasen im Abstand von 30 Grad zu messen geht (ginge ) fix, wenn man alle Teil-Testsignale in einen Scan einbettet. Die genaue Lage des Minimums/Maximums und damit die genaue relative Phasenlage laesst sich interpolieren, da die Amplitude des Summensignals eine Sinusfunktion der Phase ist.

War nur so 'ne Idee. Ich hatte gedacht das ist eine systematische Arbeitsweise die erlaubt eine Trennfrequenz nach der anderen zu optimieren. Fuer's "Biamping" muss man natuerlich umstoepseln. Aber wenn die Frequenzweiche vor jeder Messung modifiziert wird, dann macht das ja wohl den Kohl nicht mehr fett.

(wollte sowieso schon vorschlagen die Measure und Play Funktionen von Esweep um eine Kanal-option zu erweitern, z.B. -k=l(eft) r(right) b(oth) a(antiphase) Das ist mit der kommenden Version kein Problem mehr. Gruß Cpt.

Prima!

Cheers,
c2007

Hallo

nochmal zur relativen Phasenlage zweier Chassis:

Eine geeignetes Paar von Testfunktion waere:

Chassis 1: sin(omega t)
Chassis 2: sin((omega + 2pi/T)t)

Die Amplitude der ueberlagerten Wellen ist dann mit cos(phi - 2pi/T t) moduliert, wobei phi die (gesuchte) relative Phase der zwei Chassis ist. 2pi/T sollte natuerlich sehr viel kleiner als omega sein. Bei T=1sec sollte die Schwebung mit dem blosen Ohr gut zu hoeren sein.

Cheers,
c2007

Moin,

mathematisch einwandfrei, aber ließe sich das automatisieren? Wenn ich für den Zweck eine spezielle Funktion schreibe, dann vielleicht, aber ich hasse spezielle Funktionen. Ich will alles so allgemein wie möglich halten.

Für die FW-Entwicklung gibt es sowieso nur eine ordentliche Lösung: Zweikanal-Messung. Dann sind alle nicht-konstanten Latenzen (Soundkarte) raus, nur die Laufzeit des Schalls ist noch im Spiel, die aber bei allen Chassis gleich (bzw. durch unterschiedliche ak. Zentren leicht verschieden).

----

Was den reflektierten Impuls angeht, stop mich wenn ich was falsches rechne:


       -jwT
1 + k e

    -jwT / jwT      -jwT\
    ---- | ---      ----|
      2  |  2         2 |
=> e     \e    + k e    /


    -jwT
    ----
      2  /     wT         wT         wT           wT \
=> e     | cos -- + j sin -- + k cos -- - j k sin -- |
         \      2          2          2            2 /


Für k=1 könnte man die Klammer zu 2*cos... vereinfachen, wie zu erwarten, bis hierhin also alles richtig. Die Klammer zusammengefasst:


 -jwT
 ----
   2  /             wT                 wT \
e     | (k + 1) cos -- - j (k - 1) sin -- |
      \              2                  2 /


Dadurch wird die Phase zu:


                 /              wT\
                 |  (k - 1) sin --|
       -wT       |               2|
p(w) = --- + atan|- --------------|
        2        |              wT|
                 |  (k + 1) cos --|
                 \               2/

          -wT       /  k - 1     wT\
=> p(w) = --- + atan|- ----- tan --|
           2        \  k + 1      2/


Dadurch wird die Ableitung etwas gefälliger*:


  T           1                 2/ wT \   T
- - - ---------------------  sec | -- | * -
  2       / k - 1     wT \2      \  2 /   2
      1 + | ----- tan -- |
          \ k + 1      2 /


Aber ab hier kapituliere ich auch (und hoffe, dass ich die Kettenregel richtig angewandt habe). Zumindest würde ich aber bestreiten, dass außer dem T/2 vornedran irgendetwas bei der nächsten Ableitung "verloren" geht. Eher kommt bei den darauffolgenden Integrationen etwas "dazu", irgendetwas was einem gar nicht passt.

Gruß
Cpt.

* viel schöner wäre es natürlich, wenn man den atan(b*tan(x)) einfach so auflösen könnte, aber das geht wohl nicht, jedenfalls finde ich nichts entsprechendes; atan(tan(x)) wäre zweifellos x, aber mit nem Faktor davor?

Cpt,

+++ Deine Rechnung: Korrekt, soweit ich dass auf einem Blick uebersehe.

Fuer den Fall k=1 kann man das ganze als eine zeitverschobene, symmetrische Funktion sehen.

g(t) = delta(t+T/2) + delta(t-T/2), verschoben um T/2

Genau dieses T/2 geht bei der Ableitung verloren, und somit verschiebt die Transformation den ersten Puls auf t=-T/2.

Mit so einer einfachem Modellfunktion ist das noch nachzuvollziehen. Aber wie sieht's dann z.B. bei einem Logsweep aus?

Die erste willkuerliche Integrationskonstante ist immer eine Zeitverschiebung - die Zeitverschiebung T_L willst Du ja loswerden. Die Zweite integrationskonstante ist eine konstante Phase. Wenn das Eingangssignal reel war, dann bleibt nur noch das Vorzeichen.

Wenn man das Eingangssignal kennt, dann kann man wahrscheinlich die Integrationskonstanten (konstante Phase und Zeitverschiebung) vorab bestimmen.

+++ Die Schwebungsmessung sollte sich relativ leicht automatisieren lassen. Die Grundfrequenz omega haengt natuerlich vom Testobjekt ab. Die Auswertung koennte so ablaufen: Zuerst die hochfrequenten (omega) Schwingungen ausglaetten, z.B. durch Faltung mit Gausskurve mit breite T/10 oder so. Dann einmal durch die Daten laufen um I und t von Minimum und Maximum zu finden. Das sind dann die Startparameter fuer einen least-squares fit gegen

I(t) = (A+B cos(C-2pi/T*t))

(A=Imin+Imax/2, B=Imax-Imin, C=2pi tmax/T)

Fehler durch irgendwelche Latenzen in der Soundkarte, Signallaufzeiten etc.sind immer mit T zu vergleichen. Wenn T=1sec, dann sind akustische Laufzeiten vernachlaessigbar.
Totzeit vor Beginn des Signals koennte durch ein Startsignal korrigiert werden (wie bei allen anderen Messungen/Funktionen auch). Keine Ahnung wie sich Echos, Reflektionen usw. auswirken. So lange die Amplitude deutlich kleiner ist als das direkte Signal wahrscheinlich vernachlaessigbar.

Aber um eine spezielle Funktion wird man wohl nicht herumkommen.

Cheers,
c2007

Moin,

c2007 schrieb:

Genau dieses T/2 geht bei der Ableitung verloren, und somit verschiebt die Transformation den ersten Puls auf t=-T/2.

soweit sich das aus dem obigen Formelwust herauslesen lässt. Allerdings war das Ergebnis dann doch ein anderes, hab ich natürlich nicht als Bild abgespeichert und das Skript schon umfunktioniert.

Aber wie sieht's dann z.B. bei einem Logsweep aus?

Mal geraten: weil der Phasengang eines Sweeps der was auf sich hält streng monoton ist dürfte es keine Probleme geben. Hmm, vielleicht müsste ich diese Laufzeitkorrektur nicht bei der Impulsantwort sondern beim aufgenommenen Sweep machen? Schaunmermal...

--------------

Weil ich grad dabei bin, mal ein kleines Update was die neue Version betrifft. Es fehlen noch Funktionen zum Fenstern von Signalen und der Dateibehandlung (Speichern, Laden, Ascii-Im-/Export), die sind schnell fertig. Was ein wenig länger dauern könnte ist die Implementation des C(B)SDs sowie die Modifikationen des dadurch entstehenden Datentyps (Surface, ein 3D-Objekt). Der soll auch dazu missbraucht werden Directivity-Diagramme anzufertigen. Da brauchts aber noch ein paar nette Funktionen. Zum Schluss dann noch die Portierung auf Windows und Linux (MacOS kann ich nicht machen weil ich das nicht habe, sobald aber Windows und Linux gehen müsste es da auch laufen).

Alles in allem würde ich mal mit zwei Wochen rechnen. Natürlich ohne GUI, denn wie ich schonmal sagte ist das nicht offiziell. Die Darstellung wird bis auf weiteres also noch mit gnuplot erfolgen müssen.

Edit:
die Lektüre des ARTA-Handbuches hat mich auf eine Idee gebracht, wie man die Erzeugung des CBSDs noch beschleunigen könnte. Es steht zwar nicht explizit da, doch vermute ich das Ivo das genauso macht.

Bisher habe ich den shaped tone burst (4 Perioden Cosinus mit Blackman gefenstert) im Zeitbereich erstellt, mit der Impulsantwort gefaltet, und dann die Hüllkurve berechnet. Macht zusammen 4 Fouriertransformationen, zwei bei der Faltung, zwei wegen Hilbert-Trafo auf dem Weg zur Hüllkurve; die Impulsantwort hatte ich schon vortransformiert, macht 1 Trafo extra, die anderen 4 müssen mit der Anzahl der ausgewerten Mittenfrequenzen multipliziert werden. Mal ganz davon ab das die Erzeugung des Bursts hingeschlampt war und total uneffektiv, eine arschlahme Geschichte das ganze.

Wenn ich stattdessen so einen shaped tone burst direkt im Frequenzbereich erzeuge, dann spare ich mir 3 der 4 Trafos. Denn die Faltung kann ich dann genauso wie die Hilbert-Trafo direkt im Frequenzbereich durchführen, und muss dann nur zum Schluss in den Zeitbereich transformieren und dann den Betrag des Zeitsignals nehmen (nach der HT ist das dann die Hüllkurve).

Dazu müsste ich natürlich einen shaped tone burst haben, dessen Spektrum analytisch (also mit Bleistift und Papier) zu berechnen ist und gleichzeitig noch relativ einfach. Ivo benutzt ein Morlet-Wavelet, das könnte so etwas sein, da muss ich mich mal reinlesen.

Auf jeden Fall erwarte ich einen gewaltigen Geschwindkeitszuwachs.

2. Edit:

genau so ist es. Das Morlet-Wavelet hat ein bekanntes Spektrum, das kann man direkt im Frequenzbereich erzeugen, dann komplexe Multiplikation mit der fouriertransformierten Impulsantwort (entspricht einer Faltung), Transformation in den Zeitbereich, Betragsbildung, fertig ist die Laube. Sehr nett.

Gruß
Cpt.

Moin,

zu Übungszwecken und um mich selber mit der von mir entwickelten Schnittstelle vertraut zu machen habe ich eine kleine GUI-Applikation gebastelt. Die ist heute innerhalb von Netto vielleicht 6h entstanden.

So sieht die aus:

[img]http://www.directupload.com/files/jmzimj1rfljygjjzmqmy.jpg[/img]

In der Mitte das Hauptfenster, rechts oben die Sprungantwort, links oben der Betragsfrequenzgang. Im Hintergrund ist [url=http://www.openbsd.org/lyrics.html]Puffy, the Blowfish[/quote] zu erkennen.

Funktionsweise:
Im Menü "Measure" versteckt sich der Eintrag "Impulse response". Wie der Name schon sagt, kann man damit die Impulsantwort messen. Es öffnet sich ein Dialog mit ein paar wenigen Einstellungen.

Aus dieser gemessenen Impulsantwort wird ein Ausschnitt dargestellt, über das Menü "Analyse" kommt man zu "Gated impulse response", da lassen sich die Gates festlegen, die man für "Step response" und "Frequency response" braucht. Wem es noch nicht aufgefallen ist, ein wenig richtet sich die Bedienung an ARTA.

Die Grafik wird im übrigen von gnuplot erstellt. Das hat netterweise ein Terminal (so heißen dort die Ausgabetreiber), dass eine Tk-Canvas schreibt. Die kann man dann ganz einfach in eine Anwendung einbinden. Nachteil ist immer noch die niedrige Geschwindigkeit bei großen Datenmengen (umgehe ich durch geeignete Reduzierung derselben) und umständliche Größenänderung (dazu muss gnuplot jedesmal eine Textdatei neu einlesen und die Canvas-Datei schreiben; ich habs einfach weggelassen).

Bei der Entwicklung sind mir ein paar Sachen aufgefallen:

1.) die Schnittstelle ist manchmal etwas kompliziert, aber würde ich die vereinfachen wäre die Universalität weg.

2.) die zeitliche Integration skaliert seltsam (schaut mal auf die y-Achse der Sprungantwort); möglicherweise ist da ein Fehler drin

3.) beim Smoothing hab ich Mist gebaut
Edit: das wär erledigt, der Bösewicht war ein "<" anstelle eines "<="

Nochmal: Entwicklungszeit netto 6h, Code ist exakt 387 Zeilen lang. Also wieder mal lächerlich einfach.

Edit: DirectUpload will mich grad verarschen, die mögen das Bild nicht

Gruß
Cpt.

Moin,

ich bin positiv überrascht: ich hatte die Befürchtung, dass die Darstellung über den gnuplot-Umweg ein großartiges Hindernis wäre, aber das ist wirklich akzeptabel. Gut, man kann nicht in den Grafiken großartig rumpfuschen (skalieren, zoomen, Achsen verändern, Marker setzen), aber es ist einigermaßen flott und sieht gut aus. Ich finde es auch kein großes Drama, dass man nicht wie in ARTA das Gate mit der Maus setzen kann (sondern über zwei Eingabefelder), mit ein wenig Übung geht auch das schnell von der Hand.

Durch geschicktes Recycling sind da noch ein paar Analyse-Funktionen hinzugekommen, als da wären Hüllkurve der Impulsantwort, Energie-Zeit-Kurve (nach meiner Definition: Impulsantwort quadriert und logarithmiert) und Cepstrum (nach der Definition in der englischen Wikipedia).

Und binäres Laden/Speichern von Dateien geht jetzt auch.

Edit:
ganz fix und flott ging auch die Farina-Methode in der GUI einzubinden. Bis zur 10ten (willkürlich gewählte Grenze) Harmonischen innerhalb von 1s auf dem Schirm.

Edit 2:
eigentlich war ich heute Abend mental darauf eingestellt, auf dem Fussballplatz ein paar Knochen zu brechen, und zwar die eines Landesligisten (wir spielen nur B-Liga). Heute wäre Kreispokal gewesen, aber weil Fussball nur entfernt etwas mit Wasserball zu tun hat ist das Spiel ausgefallen.

Da habe ich die Zeit genutzt, und mal eben Zweikanal-Messung und Overlays (zumindest im Frequenzgang-Modus) ins GUI eingebaut. Mir reicht das dann, noch ein paar Kleinigkeiten und fertig ist die Laube.

Nochmal zur Statistik:
die Datei ist natürlich ein wenig größer geworden, es sind jetzt 775 Zeilen; Entwicklungszeit keine 2 Tage

Gruß
Cpt.

Nicht das du denkst, du führst hier einen Monolog! Hier lesen einige mit, nur mangels Kompetenz auf diesem Gebiet kann zumindest ich nichts dazu beitragen.

Harry

Ich dagegen schon:

...eigentlich war ich heute Abend mental darauf eingestellt, auf dem Fussballplatz ein paar Knochen zu brechen, und zwar die eines Landesligisten (wir spielen nur B-Liga).

Oha! Das hatte ich damals aber ganz anders verstanden!

Moin,

tiki schrieb:

Oha! Das hatte ich damals aber ganz anders verstanden! :D

wie meinen?

Dieses GUI wird immer vollständiger. Das Overlay funktioniert jetzt für jeden Modus, es lassen sich Kurven löschen, zur Berechnungsgrundlage machen, Impulsantworten können aufaddiert werden (sehr praktisch), ASCII-Export ist möglich für Frequenzgang und gegatete Impulsantwort.

Die Sprungantwort funktioniert jetzt auch, Grund für das Fehlverhalten war ein Programmierfehler in Zusammenspiel mit einem mathematischen Grund.

In der esweep-Bibliothek ist die Funktion esweep_integrate enthalten. Die führt eine Integration im Zeitbereich durch, implementiert ist die als IIR-Filter (auch Euler-Rückwärts-Integration genannt). Als Differenzengleichung:

y(n)=T*x(n)+y(n-1)

T ist die Schrittweite, in diesem Fall der Kehrwert der Abtastfrequenz. Das ist dann auch gleichzeitig die Verstärkung des Filters.

Programmiertechnisch macht man das in C mit einer for-Schleife, die beim zweiten Wert beginnt (y(n-1) ist dann der erste). Dummerweise hatte ich vergessen, eben diesem ersten Wert auch die Verstärkung (1/fs) zu verpassen.

Das war aber nicht der Grund für die falsche Skalierung der Sprungantwort, aber der Grund warum ich nicht sofort auf den Fehler gekommen bin.

Die Sprungantwort ist definiert als die zeitliche Integration der Impulsantwort. Wenn die Impulsantwort ein Dirac-Impuls ist dann ist die Sprungantwort h(t)=1 für t>=0. Die Funktion esweep_integrate würde daraus h(t)=1/fs machen, also muss man nachträglich (oder vorher, weil es ein linearer Filter ist ist das egal) mit fs skalieren. Für andere Funktionen, also keine Impulsantwort, muss man das nicht.

Eigentlich ne logische Sache, man muss aber erstmal dran denken. Und ich wäre bestimmt eher darauf gekommen, wenn der Programmierfehler nicht gewesen wäre. Denn wenn ich dann vorher skaliert habe, kamen unsinnig hohe Werte raus (weil der erste Wert der "Waveform" zu groß ist), wenn ich es nachher gemacht habe passte es schon besser, aber auch nicht richtig.

Jetzt stimmt es, also merken: die Sprungantwort wird durch Integration der Impulsantwort bestimmt. Bei esweep muss das Ergebnis nachher noch zusätzlich mit der Abtastrate skaliert werden.

Gruß
Cpt.

Moin moin,

bin schon gespannt auf die "oeffentliche" Version des Programmes mit GUI.

Auf meinem altersschwachen Linux-Laptop hatte ich uebrigens ein kleineres Problem mit v0.3: Hin und wieder hat sich esweep mit einem Segmentation Fault wenig elegant verabschiedet. Ich habe also den Quellcode mit "printf"s gepfeffert (waere schone wenn ich mich in meinen eigenen Programmen so gut zurechtfinden wuerde. Sehr sauber geschrieben und ausfuehrlich kommentiert. Bravo, weiter so!). Je nach Last (gentoo kompiliert immer 'was ) kam der Crash frueher oder spaeter - Offensichtlich ist eine Interrupt-Routine schuldig. Das Problem wurde geloest durch 2 sec Wartezeit vor "snd_close()" in measure.c. Es sieht so aus als ob "snd_pnr()" nicht abwartet bis das Abspielen/Aufnehmen wirklich fertig ist.

Als blutiger Anfaenger in Sachen Audiotheorie und -praxis hab ich mir endlich auch 'mal Deine Theorieseiten angesehen.

Hab da eine kleine Frage zum zweiten Teil, "Eine alternative Methode zur Berechnung des kumulativen Zerfallsspektrums": In der ersten Gleichung, muss es da nicht \exp(j 2\pi f \tau) heissen anstatt \exp(j 2\pi f t)??? Sonst koenntest Du die ganze exp.Funktion vor das Integral ziehen und die FT ist futsch...

Cheers,
c2007

PS: Gut Holz beim Foosball. Mir ist es lieber wenn die Gegner durch ein Netz getrennt sind.

Moin,

c2007 schrieb:

bin schon gespannt auf die "oeffentliche" Version des Programmes mit GUI.

hat halt nur den Schönheitsfehler, dass das GUI nicht offiziell ist. Der in den letzten Beiträgen von mir beschriebene ARTA-Klon ist aber ganz nett und wird definitiv veröffentlicht.

Es sieht so aus als ob "snd_pnr()" nicht abwartet bis das Abspielen/Aufnehmen wirklich fertig ist.

Richtig. In der Linux/Windows-Version wird das an die Portaudio-Bibliothek weiterdelegiert. Kann natürlich sein dass dort der Hase im Pfeffer begraben liegt.

Das muss ich mir mal anschauen, wenn ich die Audio-Ausgabe auf Linux portiere.

Hab da eine kleine Frage zum zweiten Teil, "Eine alternative Methode zur Berechnung des kumulativen Zerfallsspektrums": In der ersten Gleichung, muss es da nicht \exp(j 2\pi f \tau) heissen anstatt \exp(j 2\pi f t)??? Sonst koenntest Du die ganze exp.Funktion vor das Integral ziehen und die FT ist futsch... :?

Auch richtig. Kleiner Dreckfehler.

Gruß
Cpt.

Moin,

schnell in ner knappen Stunde* zusammengebastelt: ein Spectrum Analyzer



Wobei sich die Analysefunktionen auf die Darstellung beschränken, außerdem braucht er eine externe Signalquelle.

Edit:
letzteres hat sich erledigt, es funktioniert auch mit eingebautem Signalgenerator hervorragend. Das hat mich dann doch ein wenig überrascht, weil ich die Audioausgabe nur etwas halbherzig auf "Echtzeit" optimiert habe.

Edit 2:
so sieht das dann aus:


Blau: Einzelsinus mit 1,6kHz
Rot: Overlay, zwei Töne 1,6kHz und 200Hz

Womit wir also auch schon beim Thema "Features" wären. Der Analyzer kann eine Kurve als Overlay speichern. Finde ich ziemlich praktisch. Das Ausgangssignal besteht aus einzelnen Sinustönen, deren Frequenz, Phase und Pegel kann angegeben werden. FFT-Länge ist einstellbar, E/A-Kanal, Mittelungen (kann nur linear), Glättung wenn gewünscht, ebenso der Bereich der Y-Achse (20-100dB, mehr ist eh nicht sinnvoll). Nettes kleines Teil, Arbeitszeit knapp 3h, 250 Zeilen Code.

Gruß
Cpt.

* natürlich mit Recycling gewisser Teile aus dem ARTA-Klon

Moin,

drei Sachen:

1.) ich habe endlich mal den Quellcode im CVS auf den neuesten Stand gebracht, natürlich fehlt da noch einiges, wer aber mal schauen mag...
So wie der da jetzt drin ist baut der aber nur unter OpenBSD.

2.) ich habe einen Weg gefunden (in einem 12 Jahre alten Newsgroup-Beitrag) wie man sehr einfach die Größe der Tk-Canvas ändern kann und die enthaltene Grafik mitskaliert. Das ging bisher nämlich nicht. Und eines muss man der Canvas lassen: sie ist verdammt flott, wenn die Grafik erstmal auf ihr drauf ist. Das ist nämlich das Problem und relativ langsam (aber nicht dramatisch)

3.) ich suche immer noch jemanden der sich freiwillig und ehrenamtlich ein wenig mit der Webseite beschäftigt will.

Gruß
Cpt.

Bei sourceforge.net findet man doch auch projekt auf linux basis die sich mit Messtechnik befassen .

elvt kann man von dort eienn sinusgenerartor oder sonstiges nützliches adaptieren.

bzw den kollegen programmierer mal fragen wie er das gelöst hat bzw ob man zusammen was machen kann.