Steuerung von Audio-Messungen - ein Experiment

Autor

Beitrag

HinzKunz
Inventar

#1 erstellt: 22. Mai 2009, 00:30

Dieses Thema wurde aufgetrennt, der Ursprung befeindet sich:Hier!

Es waren die falschen Einstellungen, ich hatte "directsereal" anstatt "directserial" eingetippt... peinlich

Jetzt heißt es nur noch die Befehle alle "sniffen".
Zumindest die für Gerätetyp, Softwareversion, Spannung, Frequenz und ob gerade ein Bedienelement benutzt wird hab ich schon:

Den Rest muss ich nun auch noch aus den Tonnen an mitgeschnittenem Material heraus angeln.
Dann wird das Ganze in Matlab angelegt, sodass man die Befehle direkt in Scripten und später mit einem schönen GUI-Programm nutzen kann.
Vorteil ist, man hat viel größere Freiheiten auch in der Auswertung. So könnte man nicht nur THD+N VS. Leistung plotten, sondern zusätzlich noch Leistung VS. THD VS Frequenz als 3D-Plot.
Wobei das im Grenzlastbereich vermutlich nicht wirklich gut ausgehen wird für den Verstärker, immerhin braucht der THD-Sweep schon seine Zeit

Leider kann man das scope-Bild scheinbar nicht übertragen, das würde noch viele weitere Möglichkeiten bieten, FFT z.B.
Naja, man kann nicht alles haben...

[Beitrag von HinzKunz am 06. Jun 2009, 12:01 bearbeitet]

HinzKunz
Inventar

#2 erstellt: 22. Mai 2009, 22:34

Guten Abend,

ich hab den heutigen Ausfall einer abendlichen Verabredung genutzt, um das Ganze mal ein Stück voran zu treiben.
Meine Befehlsliste hat Mittlerweile etwas über 20 Befehle. Damit kann ich den A1 schon zu weiten Teilen fernsteuern.

Nun ist der "hardwarenahe" Teil quasi erledigt und es geht daran, das ganze softwaremäßig auf einigermaßen stabile Füße zu bekommen.
Der derzeitige Stand ist schon so weit, dass ich Steuerungsbefehle aus einem kleinen Matlabscript (nur ein paar Zeilen, ganz primitiv) heraus an den A1 schicken kann und Matlab die entsprechende Antwort erfasst und Abspeichert.

Das sind beispielsweise Spannungen im Halbsekundentakt aufgenommen mit offenem Eingang. Eiert bei knapp 10µV rum.

Eine Sache, die nun aussteht ist der "Vorverarbeitung" der Daten. Der Neutrik schickt seine Messwerte in einer Vielzahl von Variationen, teilweise mit Zehnerpotenz (1,2345E-6 V), teilweise aber auch mit den entsprechenden Einheiten (12,345 mV). Genauso wird auch die Frequenz in Hz und kHz geschickt. Bei der THD-Messung wird an den Daten die Unterscheidung zwischen dB und % auch durch die Enstsprechende Einheit gekennzeichnet.
Das muss alles erstmal vorweg "verarbeitet" werden, um das Chaos etwas zu lichten und danach nur noch Matritzen mit double-Werten vorliegen zu haben. Das erleichtert die Auswertung immens. Zumal sich die Einheiten Während einer längeren Messung auch ändern können, sei es durch stark schwankende Werte oder durch manuelle Eingriffe am Gerät (Unit-Taste). Darauf muss die Software reagieren können. Es muss also jeder Messwert einzeln ausgewertet und dementsprechend in einen Double umgewandelt werden.

Eine Sache ist mir aufgefallen, von der ich nicht weiß, ob es an meiner DOSBox oder an der Neutrik-Software liegt:
Ich kann die Frequenz und die Amplitude in der GUI nur kleiner stellen, egal auf welche der Schaltflächen ich klicke.
Können andere dieses Problem bestätigen?

So, Schluss für heute

HinzKunz
Inventar

#3 erstellt: 05. Jun 2009, 22:03

Hallo,

nun ist das erste echte "Messcript" fertig.
Ein THD+N-Sweep von 100-20000Hz. Dass der Schrieb etwas "scheiße" aussieht liegt an dem DUT, welches nix taugt... aber es ging da ja auch nur um "irgendeinen" Versuchsgegenstand.
Ich hätte den auch bis 40kHz laufen lassen können, aber dann wäre der THD bis auf 3%(!!) angestiegen und man hätte goanix mehr gesehen.

Das ist ein ziemlich billiger japanischer Verstärker aus den 70ern. Die Spannung, die Über der Last abfiel betrug etwa 2V, also 0,5Watt an 8Ohm ohmscher Last.

Nun zum eigentlichen, der Code des Scriptes sieht wie folgt aus:

------------------------------------------------------------
clear all;
s = serial('COM1', 'BaudRate', 9600, 'DataBits', 7, 'Parity', 'even', 'StopBits', 1);

fopen(s);
pause(1);

%fprintf(s, 'F?');
%Startf = sscanf(fgets(s), '%f');

fprintf(s, 'THD');
fgets(s);
pause(2);

for ii = 1:1:30
    A = 'OSC FREQ ';
    if ii <= 10
        B=int2str(ii*100);
        Out(ii,2) = ii*100;
    else 
        B = int2str((ii-10)*1000);
        Out(ii,2) = (ii-10)*1000;
    end
    
    A = [A B];
    
    fprintf(s, A);
    fgets(s);
    pause(4);
    fprintf(s, 'M?');
    Out(ii,1) = sscanf(fgets(s), '%f');
end

    A = 'OSC FREQ 1000';
    fprintf(s, A);

fclose(s);

plot(Out(:,2),Out(:,1))
------------------------------------------------------------

Prinzipiell nicht wirklich schön programmiert, zugegeben (Variablennamen A, B...

und auch sonst recht wischiwaschi)
Auch ist der Durchlauf noch sehr primitiv mit 10 Stufen bis 1kHz und 20 über 1kHz: 100Hz, 200Hz, ... 1kHz, 2kHz, ...20kHz.
Dafür würde ich mir eine eigenes Sweep-Modul schreiben, dem man nur noch Start- und Stoppfrequenz übergibt und das dann "durchläuft". Dann kann man auch etwas ausgeklügeltere Sweeps machen.
Was noch aussteht ist die Unterscheidung anhand der Einheiten.
Momentan werden alle nicht-float-werte in dem Ausgabestring des A1 schlichtweg verworfen.
Die Einheiten aus dem String heraus zu ziehen ginge mit dem Befehl char(sscanf(A, '%*f %s'));, wenn jemand eine elegantere Lösung kennt: Immer her damit.

Und überhaupt wär ich für Feedback jeder Art dankbar, ich bin noch nicht sonderlich Erfahren mit der Matlab-Scriptsprache. Wenn jemand da etwas sieht, bin ich für Verbesserungsvorschläge immer dankbar.

_ES_
Administrator

#4 erstellt: 05. Jun 2009, 22:08

Erstmal bin ich beeindruckt

Kritik kommt dann, wenn ich mir den Kram reingezogen habe

Irgendwann...

Ansonsten: Saubere Sache

HinzKunz
Inventar

#5 erstellt: 06. Jun 2009, 00:04

Hallo,

nun noch eine Messung, die so in der Form wohl eher unüblich ist.
THD+N VS. Freq VS. Power

Ist nun sehr gering auflösend, da die Messung extrem lange dauert. Eine THD+N-Messung dauert etwa 4 Sekunden.
In dem Diagramm befinden sich 100 Messpunkte, ergo dauerte sie ca. 6 1/2 Minuten.
Würde ich die Messung bis 20kHz laufen lassen, wäre ich bei 20 Minuten, würde man nun im untereren Bereich die Auflösung noch erhöhen, würde das locker die halbe Stunde sprengen

Wenn ich die linearen gegen logarithmische Sweeps ausgetauscht habe, dürfte das die Messzeit erheblich Senken.
Eine Viertelstunde bis 20 Minuten dürfte es aber dennoch bleiben.

Klar ist auch, dass das eine "brandgefährliche" Messung ist. Gibt man hier falsche Parameter an, oder passt nicht auf, steht das DUT blitzschnell in Flammen.

Interessant finde ich diese Messart aber schon, denn man kann auf den ersten Blick erkennen, dass im Bassbereich der Klirr mit steigender Spannung steigt, im Mitteltonbereich (1kHz) hingegen sinkt.
Bei 1V Eingangspannung liegen am Ausgang 5,3V an, bei 100mV daher logischer Weise 530mV.
Das heißt, die Messung fand zwischen 3,5W und 0,35W statt.

[Beitrag von HinzKunz am 06. Jun 2009, 01:13 bearbeitet]

HinzKunz
Inventar

#6 erstellt: 06. Jun 2009, 11:48

Hallo,

der letzte Beitrag ist ein schönes Beispiel, warum man sowas nicht um 2 Uhr machen sollte

Ich hab den Plot falsch gemacht und es nichtmal bemerkt

Hier nun eine neue Messung, ein logarithmischer Sweep, von 30Hz-2kHz.

Hier wird auch sofort deutlich, wo der Fehler in dem Obrigen Bild lag:
Frequenz und Eingangs-Spannung waren vertauscht im Plot.

[Beitrag von HinzKunz am 06. Jun 2009, 11:50 bearbeitet]

HinzKunz
Inventar

#7 erstellt: 07. Jun 2009, 20:31

Guten Abend,

hier noch der Quellcode der 3D-Messung, nichts wildes, nur eine weitere For-Schleife:

---------------------------------------------
clear all;
s = serial('COM1', 'BaudRate', 9600, 'DataBits', 7, 'Parity', 'even', 'StopBits', 1);

fopen(s);
pause(1);

%fprintf(s, 'F?');
%Startf = sscanf(fgets(s), '%f');

fprintf(s, 'THD');
fgets(s);
pause(2);

for jj = 1:1:10
    C = 'OSC LEVEL ';
    D = 'V';
    Uin = num2str(jj*0.1);
    Out1(jj,1) = jj/10;
    
    C = [C Uin D];
    fprintf(s, C);
    fgets(s);
    pause(1);
    for ii = 1:1:20
        A = 'OSC FREQ ';
        B = num2str(100*(1/log(21/ii)));
        Out2(ii,1) = 100*(1/log(21/ii));
    
       A = [A B];
    
       fprintf(s, A);
       fgets(s);
       pause(4);
       fprintf(s, 'M?');
       Out(ii,jj) = sscanf(fgets(s), '%f')
    end
end

    A = 'OSC FREQ 1000';
    fprintf(s, A);

fclose(s);
---------------------------------------------

Nun Aufbauend darauf habe ich bereits eine neue "Funktion" fertig, den ganz normalen Frequenzgang:

Der Quellcode dazu:

---------------------------------------------
clear all;
s = serial('COM1', 'BaudRate', 9600, 'DataBits', 7, 'Parity', 'even', 'StopBits', 1);

fopen(s);
pause(1);

fprintf(s, 'LEVEL');
fgets(s)
pause(2);
for ii = 1:1:20
    A = 'OSC FREQ ';
    B = num2str(100*(1/log(21/ii)));
    Out2(ii) = 100*(1/log(21/ii));
    A = [A B];
  
    fprintf(s, A);
    fgets(s);
    pause(2);
    fprintf(s, 'M?');
    Out(ii) = sscanf(fgets(s), '%f');
end
fclose(s);

plot(Out2, Out)
---------------------------------------------

Mittlerweile sind die Frequenzsweeps logarithmisch, wenn auch nach einem eher ungünstigen System. Aber, wie bereits geschrieben, werde ich die Sweeps versuchen in eine eigene Methode zu stecken, sodass man in den wirklichen Programmen übersichtlicher Arbeiten kann.

Und der wichtige Hinweis:
Der hier vorgestellte Quellcode zur Steuerung des A1 ist momentan komplett experimenteller Natur.
Wer bei dem Code momentan eine Falscheingabe macht, zerstört damit u.U. seinen kompletten Testaufbau, also Augen auf

PS: Ich finds übrigens sehr schade, dass ich hier quasi einen Monolog halte... ist das Thema derartig uninteressant?!

castorpollux
Inventar

#8 erstellt: 08. Jun 2009, 11:50

PS: Ich finds übrigens sehr schade, dass ich hier quasi einen Monolog halte... ist das Thema derartig uninteressant?!

Im Gegenteil, ich wüsste nur nichts beizutragen

Grüße und: Weitermachen!

Alex

Boettgenstone
Hat sich gelöscht

#9 erstellt: 09. Jun 2009, 20:35

Hi,
hab grad keinen A1 zur Hand.

Prinzipiell nicht wirklich schön programmiert, zugegeben (Variablennamen A, B... und auch sonst recht wischiwaschi)

Hab schon schlimmeres beim Professor abgeliefert.

Passt außerdem alles noch auf eine Bildschirmseite.

HinzKunz
Inventar

#10 erstellt: 09. Jun 2009, 21:16

Hallo ihr beiden,

danke für den Kommentar

(und natürlich auch Danke an @R-Type, nachträglich

)

castorpollux schrieb:

Im Gegenteil, ich wüsste nur nichts beizutragen

Muss auch keiner, es reicht mir schon zu wissen, dass ich das hier nicht mit einer leeren Menge rede

Ich werde das Ganze hier nach und nach weiterführen und Dokumentieren. Bis zum Fertigen "Programm", was hoffentlich Ende diesen Sommers so sein wird.
Das dürfte dann auch vom Code her deutlich länger größer sein. Bis dahin müssen aber noch einige Hürden genommen werden.

Hab schon schlimmeres beim Professor abgeliefert.

Als ich für sowas Noten bekam, hab ich da auch manches mal nur "Rudimentärarbeit" (

) geleistet

Momentan bekomme ich von Studis ausm 2. Semester so einen Kram vorgesetzt und ärgere mich darüber (die Tab-Taste scheint mittlerweile auch ganz aus der Mode gekommen zu sein).

Und da ich nun richtig merke, wie Chaotisch es ist, wenn Leute ihre Variablen a,b, c, hund, katze, maus oder auch richard nennen, bin ich eigentlich dazu übergegangen es nicht mehr zu tun

Zumal in Programmen, die nicht nur für Spiel, Spaß und Spannung gut sind, sondern wirklich auch eingesetzt werden sollen, ist ein guter Stil von Anfang an (eigentlich) wichtig.
Naja, vielleicht bin ich da auch etwas arg pingelig...

-DE-
Ist häufiger hier

#11 erstellt: 10. Jun 2009, 16:54

Keine Sorge, du bist nicht alleine...

HinzKunz
Inventar

#12 erstellt: 20. Jun 2009, 22:14

So, und nun gehts weiter.
Nichts beeindruckend Neues diesmal, aber dennoch erwähnenswert (finde ich).

Die Messung des Frequenzgangs mit einem relativen Pegel bezogen auf 1kHz.

Wie man sieht, bei 1kHz wirklich exakt auch bei 0,00dBr gemessen, klappt also

Quellcode:
---------------------------------------------------


clear all;
s = serial('COM1', 'BaudRate', 9600, 'DataBits', 7, 'Parity', 'even', 'StopBits', 1);

fopen(s);
pause(1);

fprintf(s, 'L.REL'); %Rel.Pegel-Modus
fgets(s);
pause(2);

fprintf(s, 'OSC FREQ 1000');
fgets(s);
pause(2);
fprintf(s, 'SETREF'); % Referenz setzen
fgets(s);
pause(1);
fprintf(s, 'REF?');
disp(fgets(s))

for ii = 1:1:20
    A = 'OSC FREQ ';
    B = num2str(100*(1/log(21/ii)));
    Out2(ii) = 100*(1/log(21/ii));
    A = [A B];
  
    fprintf(s, A);
    fgets(s);
    pause(2);
    fprintf(s, 'M?');
    Out(ii) = sscanf(fgets(s), '%f');
end
fclose(s);


semilogx(Out2, Out)

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

Noch enthält der Code einige unnütze dinge und einige nicht zwingend notwendige Pausen, aber das darf ja dann nach belieben weggelassen werden in echten "Arbeitssituationen"

Damit sind jetzt 2 der Wichtigsten Funktionen abgedeckt, nun kann man sich schon mal überlegen das ganze in eine etwas 'hübschere' Form zu bringen und die anderen Funktionen dann nach und nach noch hinzuzufügen.
In der nächsten Zeit bin ich leider zeitlich sehr Knapp, da wird das wohl etwas dauern

HinzKunz
Inventar

#13 erstellt: 30. Aug 2009, 23:45

Hallo,

während mein A1 nachwievor halb zerlegt auf dem Tisch liegt und ich daher erstmal keine weiteren Versuche machen kann, möchte ich die bisher gefundenen Befehle, sowie deren Bedeutung vorstellen.

Wichtig!
Diese Befehle habe ich durch Auslesen des Datenverkehrs zwischen A1 und Software ermittelt, ich kann daher nicht Garantieren, dass sie sich in jeder Situation so verhalten, wie beschrieben!
Wenn jemand Ergänzungen oder auch Erklärungen hat, immer her damit!


VERSION? - Versionsabfrage (Rückgabe: Version 2.33)
MODEL? - Modellabfrage (Rückgabe: Model A1 Series)
PHANT? - Phantomspannung(Rückgabe: PHANTOM OFF/ON)
LOCAL - ??? (Rückgabe:  E0)
GRAP - ??? (Rückgabe E0)
FUNCT? - ??? (Rückgabe: FUNCTION LEVEL)
S? - Kompletter Statusbericht
M? - Spannung (Rückgabe: 1.002571 V)
F? - Frequenz (Rückgabe: 1.003kHz)
C? - Bedienelement aktiv (Rückgabe: YES/NO)
FILT? - Abfrage ob Filter aktiv (Rückgabe: FILTERS OFF/ON)
OSC SINE - Oszillator auf Sinus stellen (Rückgabe: E0)
OSC SQUARE - Oszillator auf Rechteck stellen (Rückgabe: E0)
OSC FREQ XX Hz/kHz - Frequenzset in Hz (Rückgabe: E0)
F - Frequenz auf min (20Hz) setzen (Rückgabe: E6)
OSC LEVEL XX V/mV/uV - Ausgangspegel (Rückgabe: E0)
OSC LEV? - Sollpegel des Ausgangs (Rückgabe: OSCILLATOR LEVEL XX V/mV/uV)
LEVEL - Pegelmessung(Rückgabe: E0)
L.REL - Ralative Pegelmessung (Rückgabe: E0)
REF? - Referenzspannung ausgeben (Rückgabe: REFERENCE X.XX V/mV/uV)
SETREF - Neue Referenzspannung setzen (Rückgabe: E0)


THD - In THD-Messung wechseln(Rückgabe: E0)
M? - THD+N in dB oder % (Rückgabe: X dB bzw. X %)
UNIT DB - Ausgabe in dB umschalten (Rückgabe: E0)
UNIT % - Ausgabe in % umschalten (Rückgabe: E0)

SWEEPMODE FREQ - in Sweepmodus versetzen (Rückgabe: E0) (???)

Diese Liste ist noch sehr Unvollständig, es gibt mit Sicherheit noch Massenhaft weitere Kommandos, die ich aber bis jetzt noch nicht ausgelesen habe.
Sollte jemand über eine erweiterte Liste verfügen, wäre ich sehr Dankbar wenn derjenige Ergänzungen Posten würde.

Von meinem Verständnis bisher für die Rückgaben: E0 ist quasi ACK, E6 wohl ungültiger Wert o.ä. und E5 ungültiger Befehl.
Bei einigen Befehlen weiß ich nachwievor nicht sicher, was sie tun, so z.B. der Sweepmodus. Vorstellen könnte ich mir, dass er dann zwischen Frequenzwerten "durchläuft" und nicht springt. Das kann ich aber momentan nicht testen.

Die hier angegebenen Rückgaben sind logischer Weise für mein Gerät spezifisch und auch nur exemplarisch zu sehen. Das A1 hat eine erschreckende Kreativität bei der Rückgabe von Daten. So werden Spannungen jeweils mit V, mV oder uV gekennzeichnet und manchmal auch noch mit Zehnerpotenz.
Daher sind die Rückgaben immer mit hoher Vorsicht zu genießen, einfach die Zahlen weiterverarbeiten geht todsicher schief.

-DE-
Ist häufiger hier

#14 erstellt: 31. Aug 2009, 20:55

Das A1 hat eine erschreckende Kreativität bei der Rückgabe von Daten.

kreative Messgeräte sind mir nicht geheuer...

Aber auch dahinter muss sich ja ein System verstecken. Man muss es nur finden. Also: Weitermachen !

nailhead
Stammgast

#15 erstellt: 01. Sep 2009, 08:32

Hallo @all,

für die 'schöne Verpackung' gibt's den Matlab 'guide', also einfach 'guide' in der Matlab-Befehlszeile eingeben. Hoffentlich ist dieser auch in der Studentenversion enthalten. Es ist ein Editor für graphische Bedienoberflächen (GUI), mit recht einfacher Bedienung.

Grundlagen (wirklich nur Grundlagen

) für die GUI-Programmierung unter anderem hier:

http://www.walderich.de/seb/matlab/anleitung.htm

Hier schon etwas ausführlicher (und besser

)

http://www.mepnet.de...view&id=24&Itemid=35

Denke auch nicht, dass das Messgerät 'kreativ' ist, man muss nur hinter das System kommen

Übrigens wäre LabVIEW hier eine alternative zu Matlab gewesen, ist für den normalen User einfacher zu bedienen (wenn man sich an die Eigenarten mal gewöhnt hat)

lg Andy

HinzKunz
Inventar

#16 erstellt: 01. Sep 2009, 10:26

Hallo,

danke für die Links, GUIDE existiert zumindest in meiner "Dienst"-2008a-Vollversion.
Das erleichtert mir viel, da ich bisher noch nie eine GUI unter Matlab programmiert habe

Da ich mir jetzt einen USB zu RS232 Adapter gekauft habe, werde ich den alten Laptop mit meiner Studilizenz (der noch eine Serielle Schnittstelle eingebaut hatte) in Ruhestand schicken.

Denke auch nicht, dass das Messgerät 'kreativ' ist, man muss nur hinter das System kommen

Klaro... es war nur eine Redewendung, da das System (mE) unnötig kompliziert zu verarbeiten ist.
Schlussendlich muss ich über sscanf die Einheit auch auslesen und die Entsprechende Zehnerpotenz dranmultiplizieren.
Die vom A1 manchmal mitgeschickten Zehnerpotenzen verarbeitet er zum Glück automatisch. Das geschieht mW aber nur bei einstelligen µV-Werten, dann wird "XXE-6 V" zurück gegeben.

Übrigens wäre LabVIEW hier eine alternative zu Matlab gewesen, ist für den normalen User einfacher zu bedienen (wenn man sich an die Eigenarten mal gewöhnt hat)

Da hast du natürlich Recht. Ich könnte in LabVIEW eine VI für das A1 erstellen (was nicht so schwer wäre) und damit dann sehr einfach Programme zurecht stricken.
Mein Problem ist, ich mag LabVIEW nicht.

Außerdem ist meine Lizenz (6.irgendwas) etwas veraltet.

Evtl. nehme ich das in Angriff, wenn es unter Matlab läuft.

HinzKunz
Inventar

#17 erstellt: 05. Sep 2009, 15:24

Hallo!

Noch vielleicht als kleiner Ausblick meine Gedanken, wie es weitergehen wird.
Bisher habe ich ja lediglich einige "Originalmessungen" auf die neue Plattform Übertragen. Sprich die alte Software ersetzt.

Nun bietet einem das ganze aber noch weitere Möglichkeiten.
So liefert das A1 einen "Monitorausgang" mit Konstant etwa 1V Amplitude.
Hier könnte man, da man ja eh den PC benutzt eine Soundkarte vergleichsweise ungefährlich anschließen (das Maximum was da raus kommt sind etwa 3V).
Dadurch könnte man Matlab mit weiteren Daten füttern und auch spektrale Analysen z.B. von Verzerrungsmessungen durchführen.
Das A1 filtert ja die Grundwelle heraus und liefert einem dann die Verzerrungskomponenten schön verstärkt an diesem Ausgang.
Durch die schon im Gerät stattfindende Verstärkung wäre man recht flexibel in der Wahl des Wandlers am PC, man müsste also mit einer "realtiv Preiswerten" Studiokarte schon ganz gut zurecht kommen.

Nimmt man eine Bessere, kann man das A1 auch als "Analog-Frontend" missbrauchen und die komplette Signalanalyse rechnergestützt durchführen.

Genauso könnte man den umgekehrten Weg gehen und eine Soundkarte als Signalquelle nehmen, das würde Messungen an D/A-Wandlern vereinfachen da man nun eine schöne, digitale Quelle hat (SPDIF-Ausgang der Soundkarte).

So könnte man den Funktionsumfang des A1 um einiges Erweitern, und damit Bereiche abdecken, die sonst nur wesentlich teureren Messgeräten vorbehalten bleiben.

Inwieweit das ganze (praktikabel) Funktioniert und ob die Messergebnisse dann auch wirklich etwas taugen bleibt zu erproben.

Als erstes will ich mich aber nun an einer grafischen Oberfläche für Amplitudengang und THD+N versuchen.

Ämblifeier
Stammgast

#18 erstellt: 03. Okt 2009, 20:55

Super Sache

, bitte um Fortsetzung.

HinzKunz
Inventar

#19 erstellt: 04. Okt 2009, 23:56

Hallo,

seit einigen Tagen habe ich wieder etwas mehr "Luft" und daher geht es nun auch hier weiter.

Ich habe mich heute ein wenig GUIDE beschäftigt und meine erste (lauffähige) grafische Oberfläche mit der entsprechenden Funktion geschrieben.

Die Funktion selbst ist ein logarithmischer Sweep von 20Hz-40kHz (20 Messungen) mit automatischer Referenz bei 1kHz. Das Ergebnis wird also in dBr angeben, Achsenbeschriftungen fehlen noch.

Mit den beiden Textboxen soll man in der nächsten Version Start- und Stopfrequenz angeben können.
Die Anzahl der Schritte wird dann automatisch berechnet oder kann angegeben werden...

Aber wir wollen ja mal klein Anfangen

Die Bedienung ist momentan denkbar einfach, auf den "Push Button" drücken und abwarten

Die Ausgangsspannung wird automatisch auf ein Volt gesetzt.

Das ganze mag jetzt wenig aufregend erscheinen, aber es ist für mich ein wichtiger Schritt, denn der komplette "Komplex" GUI ist alles andere als mein übliches Arbeitsfeld.
Daher bitte ich auch fehlende "Finesse" der Oberfläche zu entschuldigen

Der Code wird langsam länglicher, was aber auch an der "Kommentarmasse" liegen mag


function varargout = testgui_2(varargin)

% TESTGUI_2 M-file for testgui_2.fig
%      TESTGUI_2, by itself, creates a new TESTGUI_2 or raises the existing
%      singleton*.
%
%      H = TESTGUI_2 returns the handle to a new TESTGUI_2 or the handle to
%      the existing singleton*.
%
%      TESTGUI_2('CALLBACK',hObject,eventData,handles,...) calls the local
%      function named CALLBACK in TESTGUI_2.M with the given input arguments.
%
%      TESTGUI_2('Property','Value',...) creates a new TESTGUI_2 or raises the
%      existing singleton*.  Starting from the left, property value pairs are
%      applied to the GUI before testgui_2_OpeningFcn gets called.  An
%      unrecognized property name or invalid value makes property application
%      stop.  All inputs are passed to testgui_2_OpeningFcn via varargin.
%
%      *See GUI Options on GUIDE's Tools menu.  Choose "GUI allows only one
%      instance to run (singleton)".
%
% See also: GUIDE, GUIDATA, GUIHANDLES

% Edit the above text to modify the response to help testgui_2

% Last Modified by GUIDE v2.5 05-Oct-2009 00:17:39

% Begin initialization code - DO NOT EDIT
gui_Singleton = 1;
gui_State = struct('gui_Name',       mfilename, ...
                   'gui_Singleton',  gui_Singleton, ...
                   'gui_OpeningFcn', @testgui_2_OpeningFcn, ...
                   'gui_OutputFcn',  @testgui_2_OutputFcn, ...
                   'gui_LayoutFcn',  [] , ...
                   'gui_Callback',   []);
if nargin && ischar(varargin{1})
    gui_State.gui_Callback = str2func(varargin{1});
end

if nargout
    [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:});
else
    gui_mainfcn(gui_State, varargin{:});
end
% End initialization code - DO NOT EDIT


% --- Executes just before testgui_2 is made visible.
function testgui_2_OpeningFcn(hObject, eventdata, handles, varargin)
% This function has no output args, see OutputFcn.
% hObject    handle to figure
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)
% varargin   command line arguments to testgui_2 (see VARARGIN)
% Choose default command line output for testgui_2
handles.output = hObject;

% Update handles structure
guidata(hObject, handles);

% UIWAIT makes testgui_2 wait for user response (see UIRESUME)
% uiwait(handles.figure1);


% --- Outputs from this function are returned to the command line.
function varargout = testgui_2_OutputFcn(hObject, eventdata, handles) 
% varargout  cell array for returning output args (see VARARGOUT);
% hObject    handle to figure
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)
% Get default command line output from handles structure
varargout{1} = handles.output;


% --- Executes on button press in pushbutton1.
function pushbutton1_Callback(hObject, eventdata, handles)
% hObject    handle to pushbutton1 (see GCBO)
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)
clear all;
s = serial('COM10', 'BaudRate', 9600, 'DataBits', 7, 'Parity', 'even', 'StopBits', 1);

fopen(s);
pause(1);

fprintf(s, 'L.REL');
fgets(s);
pause(2);

fprintf(s, 'OSC FREQ 1000');
fgets(s);
pause(1);

fprintf(s, 'SETREF');
fgets(s);
pause(2);

for ii = 1:1:20
    A = 'OSC FREQ ';
    B=int2str(20 + 40000.*((2.^ii-1)./1048575));
    Out(ii,2) = 20 + 40000.*((2.^ii-1)./1048575);
    
    A = [A B];
    
    fprintf(s, A);
    fgets(s);
    pause(1);
    fprintf(s, 'M?');
    Out(ii,1) = sscanf(fgets(s), '%f');
end

    A = 'OSC FREQ 1000';
    fprintf(s, A);

fclose(s);

semilogx(Out(:,2),Out(:,1))



function edit1_Callback(hObject, eventdata, handles)
% hObject    handle to edit1 (see GCBO)
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of edit1 as text
%        str2double(get(hObject,'String')) returns contents of edit1 as a double


% --- Executes during object creation, after setting all properties.
function edit1_CreateFcn(hObject, eventdata, handles)
% hObject    handle to edit1 (see GCBO)
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows.
%       See ISPC and COMPUTER.
if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor'))
    set(hObject,'BackgroundColor','white');
end



function edit2_Callback(hObject, eventdata, handles)
% hObject    handle to edit2 (see GCBO)
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of edit2 as text
%        str2double(get(hObject,'String')) returns contents of edit2 as a double


% --- Executes during object creation, after setting all properties.
function edit2_CreateFcn(hObject, eventdata, handles)
% hObject    handle to edit2 (see GCBO)
% eventdata  reserved - to be defined in a future version of MATLAB
% handles    empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows.
%       See ISPC and COMPUTER.
if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor'))
    set(hObject,'BackgroundColor','white');
end

Hier wurde sehr viel von GUIDE erzeugt, die genaue Codebeschaffenheit kenne (und verstehe) ich noch nicht, damit werde ich mich in der nächsten Zeit genauer beschäftigen...
Bücher wälzen, HowTos lesen, Beispielcodes durchackern... das übliche Programm eben.

Das wird wohl etwas länger dauern, denn ich habe (vor Jahren) grafische Programmierung anhand von Delphi gelernt, aber schnell gemerkt, dass davon a) nichts mehr hängen geblieben ist und b) bei Matlab eh alles komplett anders funktioniert

Also nicht wundern, wenn im Quelltext totaler Blödsinn drin steht...
Hier übernehme ich daher noch viel weniger gar keine Garantie auf funktionierende Programme und Unbeschädigte Hardware als sonst.

HinzKunz
Inventar

#20 erstellt: 26. Sep 2010, 17:21

Hallo,

nun ist (fast) ein Jahr vergangen und ich buddel das Thema Mal wieder aus.

Es hat sich ein wenig was getan. Als erstes habe ich ein neues Messgerät dazu bekommen, einen HP 3561A Signalanalysator. Das ist quasi ein FFT-Analyzer von 125µHz bis 100kHz. Außerdem ein USB-GPIB Adapter (von NI).

Auch für das Ding habe ich erste Matlab-Befehle geschrieben... fertig ist eine Funktion, die mir die Daten der aktuell aktiven Spur ausgibt, in der Standardeinstellung also Frequenz- bzw. Zeitverlauf.

Aber der HP soll hier (erstmal) nicht das Thema sein.
Zuallererst möchte ich eine komplette Matlab-Routine für das Neutrik A1 schreiben, mit der Man quasi alles, was die Kiste kann steuern können soll.

Konzeptionell stelle ich mir das so vor:

Es gibt eine Matlab-function, nennen wir sie "neutrik".
Diese Funktion nimmt diverse Parameter an.
Dazu gibt es noch ein Geräteobjekt, nennen wir es "Dev".

Im Gerät, "Dev", sind alle wichtigen Betriebsdaten für das aktuelle Gerät gespeichert. Also (Com-)Port, aktuelle Frequenz, aktueller Pegel, aktueller Betriebsmodus etc. pp

Die Funktion Neutrik erwartet als Parameter ein Geräteobjekt und was zu tun ist.
Also Beispielsweise: neutrik(dev1, 'write', 'freq', 1000)
Das würde nun an dev1 den Befehl schicken, die Frequenz auf 1kHz zu setzen.

Als Hauptbefehle plane ich momentan:

write: Wert setzen
read: Wert(e) auslesen
mode: Darstellung umschalten
function: Messmodus umschalten (Level, THD, rel. Level etc.)

Write erwartet zwei Parameter, einmal was gesetzt werden soll, also Frequenz oder Pegel und der Wert.
Die einzige Ausnahme ist 'write', 'ref', also das Setzen des Referenzwertes.

Desweiteren gibt jede Schreiboperation den neuen Wert, oder einen Fehler als Rückmeldung.

Noch nicht sicher ist ein weiterer Hauptbefehl, nämlich do.
Hier könnte ich bereits in die "Neutrik"-Funktion gewisse Messungen einbauen, z.B. neutrik(dev1, 'do', 'levelsweep', 'log', 20, 20000).
Das wäre dann ein Pegelschrieb, logarithmisch von 20Hz bis 20kHz.
Wenn, würde ich dort wohl einen linearen und logarithmischen Sweep für Frequenzgang und THD vs. Frequency einbauen. Alles weitere erscheint mir da zu Übertrieben.
Alternativ ist eine eigene function, also levelsweep(dev1, 'log', 20, 20000), welcher sich die Neutrik-Funktion zunutze macht.
Diese Variante erscheint mir eleganter, da dann eine einzelne Funktion nicht zu überladen ist.

Für das ganze gibts dann ein grafisches Frontend, was das Ganze dann gut Bedienbar macht.
Das ist dann natürlich deutlich schlanker, da hier lediglich die Funktionsaufrufe drin stehen.

Erweitert wird das Ganze über kurz oder lang durch weitere Messmittel, die via GPIB angesteuert werden, so z.B. der o.g. HP.
Mein DSO (Philips PM3320A) hat auch eine GPIB-Schnittstelle, leider fehlt mir nachwievor das dazugehörige Programmierhandbuch.

Aber allein die Kombination des A1 mit dem FFT des HP erweitert die Messmöglickeiten deutlich.

Soviel erstmal zum aktuellen Planungsstand...

[Beitrag von HinzKunz am 26. Sep 2010, 17:28 bearbeitet]

Suche: