Frage an die Spektroskopiker:
Hat jemand außer Hugojun, Holger Adelmann und mir ein ASEQ-Spektrometer in Betrieb und eigene Software dazu erstellt?
Viele Grüße aus Bonn
Horst
Hallo Horst,
ja, in der Tat, auch ich benutze ein LR1 bzw. LR1-T (etwas älteren Datums, jene mit 2^14 Bit Auflösung) mit selbstgeschriebenem Programm. Anbei eine Abbildung des Anwendungs-Fensters. Es werden alle Hardware-Funktionen unterstützt, nebst den "üblichen" Sachen zur Spektroskopie (glätten ...). Damit mir nicht dauernd Licht auf den Detektor fällt, wird ein FTDI-Wandler (TTL-USB) angesteuert, um die Blende der Lichtquelle (via TTL) schalten zu können. Gelegentlich kommen auch USB-Relais zu Einsatz. Fragen sind immer wiillkommen ...
Viele Grüße aus Berlin,
Michael
PS: Ich benutze mal die forenübliche und lockere Anrede, müsste sonst den Cursor wieder ganz an den Anfang des Textes bewegen :-)
Hallo Michael,
das sieht schon sehr gut aus.
Ich habe Probleme mit den dürftigen Unterlagen zum ASEQ, vielleicht kannst Du mir auf die Sprünge helfen.
Weil das nur eine mikroskopisch kleine Minderheit im Forum interessieren dürfte, alles weitere per PN.
Viele Grüße
Horst
Zitat von: Horst Wörmann in Mai 19, 2021, 11:55:23 VORMITTAG
Weil das nur eine mikroskopisch kleine Minderheit im Forum interessieren dürfte, alles weitere per PN...
Hallo Horst,
schade, die
kleine Minderheit hat sicher auch Interesse!
Gruß,
Rolf
Hallo Horst,
so klein ist die Minderheit nicht!! Bitte gerne hier diskutieren!
Danke
Herzliche Grüße
Peter
Liebe Kollegen,
da habe ich mich ja doch über das Interesse getäuscht... fühle mich immer von Schnibblern und Tümplern umzingelt.
Aber laßt mich erst mal das Problem in Ruhe lösen, dann werde ich berichten. Versprochen.
Viele Grüße
Horst
Hallo Michael,
wenn es sich bei der Software nicht um LabVIEW handelt, würde es mich auch interessieren.
Ich betreibe ein LR1 der ersten Stunde und es reagiert auf die Hersteller Software CheckTr_2.
Welche Optionen und / oder Vorteile bietet ein ,,DIY"-Software?
LG
Jürgen
Hallo Jürgen,
der Vorteil selbstgestrickter Software liegt für mich auf der Hand: kostet nix außer Zeit.
Ganz im Gegenteil zu LabView, aber auch da muß man sich was zusammenbasteln. Vorteil LabView ist die Verfügbarkeit mathematischer Funktionen, sagt Holger.
Die beim ASEQ mitgelieferte Software ist sehr minimalistisch und für mich unbrauchbar. Spectragryph kann mit dem ASEQ kommunizieren, ist aber mit Funktionen überladen, wird auf meinem Bildschirm nicht richtig angezeigt, und ich verheddere mich immer wieder in dem Programm.
Beim Selbstgebastelten kann man dagegen alles so auf dem Bildschirm anordnen, wie es am besten in den eigenen Arbeitsablauf paßt. Optionen: alles, was sich programmieren läßt. Zum Beispiel einen Shutter steuern oder ein Filterrrad.
Deshalb versuche ich ja, das ASEQ mit meiner vorhandenen Software (für Zeiss/tec5 MCS) zu nutzen, da braucht man sich nicht umzugewöhnen (was für einen alten Knacker ein Vorteil ist...).
Viele Grüße
Horst
Hallo Horst & Jürgen,
sorry für meine Zurückhaltung, ich war / bin ziemlich beschäftigt mit diversen Publikationen (Geol. Jahrbuch Hessen, Internat. Workshop Montanarchäologie, Aufschluss ...), daher konnte ich nicht viel mit dem ASEQ Spektrometer arbeiten.
Man hat in LabView nicht nur einzelne Funktionsgruppen sondern bereits eine einfache Anwendung, die man dann nach Belieben erweitern kann, ich hänge mal einen Screenshot an.
Es gibt auch C++ Bibliotheken die Du verwenden kannst, Horst.
Mit einer Anwendung in LabView kann man natürlich dann auch alle mathematischen / statistischen Nachanalysen machen mit den mächtigen Möglichkeiten von LabView, und natürlich aus der Spektrometer-Applikation heraus direkt Hardware steuern. Es gibt ja wie ich schon mal gezeigt habe schöne LabView Bibliotheken für den Arduino ...
Man kann sich übrigens eine kostenlose LabView Community Edition herunterladen, die für den strikt persönlichen Gebrauch frei ist und keine signifikanten Einschränkungen gegenüber der Vollversion hat.
Viele Grüße,
Holger
Hallo Holger,
das ist ja alles sehr schön mit LabView, aber auch damit muß man sich was zusammenbasteln - für mich hieße das Beginn von ganz vorne.
Mein Ziel ist die Einbindung des ASEQ in die schon vorhandene Software; die Grundfunktionen sind schließlich bei allen Spektrometer gleich (also Integrationszeit einstellen, Mittelwertbildung, Startsiganl etc).
Dazu brauche ich aber Informationen zur Datenübertragung, konkret: getFrame -> Intensitätsdaten für jedes Pixel vom ASEQ in das Array. Die ASEQ-Informationen sind minimalistisch, das Muster-Basic-Programm läuft, gibt aber nur scheinbar Werte aus.
Ich nehme an, für LabView gibt es eine eigene DLL, die mit Basic nicht harmoniert? Trotzdem müßte man doch auch mit LabView herausfinden können, welche Daten man an das ASEQ schicken muß und in welchem Format sie wieder herauskommen.
Viele Grüße
Horst
Hallo Horst, Jürgen und Rolf,
uii, damit hätte ich auch nicht gerechnet, dass es doch einige Interessenten mehr gibt. Also noch mal meine Antwort an Horst für die "Mikro-Gemeinde" sowie einige zusätzliche Anmerkungen.
Wie sich herausstellte, besitzt Horst ein "HR1"-Spektrometer und andere (wie z.B. ich) ein LR1- bzw. ein LR2-Spektrometer. Nun ist es so, dass das HR1 ein 16Bit-AD-Wandler besitzt und die LR-Typen einen 14Bit-Wandler. Das führt dazu, dass die Basis-DLL's nicht identisch sind. Der Vollständigkeit halber die Namen der Bibo's: "spectrlib-shared.dll" sowie "adcDll1.dll". Das macht die Sache (für mich) etwas komplizierter um Horst wirklich helfen zu können.
----- Zitat aus der Email an Horst:
"Darüber hinaus verwende ich (überwiegend) eine MS-ferne Programmiersprache was die Vergleichbarkeit auch nicht einfacher macht. Ich habe allerdings mal die Inhalte der Bibo's verglichen und festgestellt dass die Übergabeparameter identisch sind. Ich kann an deinem Aufruf kein Problem entdecken. So weit so gut, nutzt uns aber letztendlich auch nichts, da ich keinen echten Test durchführen kann.
Allerdings kann ich mich erinnern, ein sehr ähnliches Problem gehabt zu haben, letztendlich hat sich herausgestellt, dass das Setzen der, nicht unbedingt voneinander unabhängigen, Parameter stimmig sein muss. Also der Fehler nicht bei dem eigentlichen Abholen der Spektren bestand.
Und generell funktioniert doch die Werteübergabe, du erhältst Werte, wenn auch nicht jene die du erwartest. Auch das spricht m.E. eher dafür, das ,,Getframe" genau jenes macht, was es soll. In dem von dir verlinkten Beispiel gibt es doch eine bereits kompilierte Fassung des VB-Net-Beispiels, funktioniert diese Applikation (auch) nicht ? Ich kann zumindest im Original-Sourcecode nichts Problematisches entdecken. Das Projekt wird klaglos in Visual Studio 12 geladen und ausgeführt. Ob sich ein Fehler in deinen ,,Nachbau" eingeschlichen hat, kann ich ohne Kenntnis deines Programms nicht sagen."
Zitatende-----------
Sicherlich wird es immer die Diskussion geben, welche Programmierumgebung denn nun am geeignetsten wäre ... , was aber abschließend kaum zu klären sein dürfte :-)
Jürgen wollte wissen, ob meine Software mit LAbVIEW erstellt worden ist. Nein, ist sie nicht! Ich benutze "GFA-Basic 32", eine C-nahe Basic-Variante mit Assembler. Früher mal eine kommerzielle Software, inzwischen frei verwendbar, wird aber trotzdem noch durch Sjouke Hamstra ( http://gfabasic32.blogspot.com/ ) gepflegt.
Software, u.a. für Geräte, erstelle ich deshalb selber, weil die beigelegte oder zu erwerbende Software, nie wirklich das macht, was und wie man sich es wünscht. Was natürlich auch nicht zu erwarten ist (siehe Windows :-) ). Sicherlich kann man so etwas in Auftrag geben, leider ist aber mein Programmier-Geldbäumchen seit vielen Jahren außer Betrieb (Reparatur¬anleit¬ungen sind natürlich willkommen .-) ), so dass sich dieser Weg nicht ergibt. Außerdem ist es gar nicht so einfach, seine Wünsche in einem Auftrag zu formulieren, na gut, ich schweife ab.
Einige wesentliche Punkte zu meinem Programm für das LR1 bzw. LR2 (Übrigens: ja Jürgen, die checktr (2).exe kommt mir sehr bekannt vor ... )
1) alle Funktionen auf einem Fenster platziert, ohne jede Menge von (Unter)-Menüs ...
2) Cursor für Auslesen (einstellbare WL, Auswahl des Spektrums) während einer Messaktion ... (in der oberen Abbildung nicht sichtbar)
3) zeitgesteuerte Aufnahme (via Tabelle) möglich (Funktion in der oberen Abbildung nicht sichtbar)
4) automatisches Abspeichern mit Datei-Inkrement (Einzelspektrum) bzw. das manuelle Abspeichern aller "gehaltenen" Spektren in einer Datei bzw. Einzeldateien
5) Glätten u. a. gängige math. Operationen möglich (siehe Abbildung)
6) Einbindung von weiterer Hardware (siehe vorherige Antwort an Horst), sowie auch eine Motorsteuerung für polarisierte Messungen (Drehversteller) bzw. die Ansteuerung eines Mikroskoptisches (MCL von Lang) (Option in der oberen Abbildung nicht sichtbar)
Viele Grüße aus Berlin
Michael
PS: Sollte ich jemande(n) in der Anrede vergessen haben, bitte ich im Voraus um Entschuldigung ...
Hallo Michael,
das mitgelieferte VB-Net-Beispiel funktioniert nur scheinbar: ausgegeben werden die ersten 10 Daten, und die sehen tatsächlich wie Daten aus. Wenn man das Programm aber auf die Ausgabe von z.B. 500 Daten erweitert, kommt nur Mist raus. Das hat mich doch sehr verwirrt.
Die Lösung war, nach Deinem Vorschlag einfach mal die Parameter anders als im Beispiel zu setzen, die sind wohl falsch. Und siehe da, es funktioniert - Screenshot anbei.
Das ist das Leuchtstofflampenspektrum, wie es aussehen soll. Jetzt geht es an die Feinheiten.
Danke Dir für den Hinweis,
viele Grüße aus Bonn
Horst
Hallo Horst,
es freut mich, dass das Problem gelöst ist und du weiterarbeiten kannst. Deine Anfrage hat mich übrigens dazu verführt, mich etwas eingehender mit der Spezifikation des HR1 zu beschäftigen.
In dem Datenblatt werden verschiedene Gitter beschrieben. Das Beugungsgitter mit 300 Linien/mm deckt, lt. der Tabelle, einen Wellenlängenbereich von 600nm ab. Und stellt damit auch den größten Bereich dar. Nun ist mir aber unklar wie der Gesamtbereich von 200nm-1100nm ausgenutzt werden kann. Entweder müsste es dann ein Gitter mit weniger Linien als 300/mm geben oder aber das Gitter müsste hinsichtlich seiner Ausrichtung im Strahlengang änderbar sein. Was hast du in deinem Spektrometer, resp. welchen Wellenlängenbereich deckt dein Gerät ab ?
Viele Grüße aus Berlin
Michael
Hallo Michael,
so richtig arbeiten kann ich immer noch nicht damit, die Angaben zur DLL bringen mich zur Verzweiflung. NumOfScans (also Zahl der gespeicherten Spektren) soll lt. DLL bis zu 137 sein, in der Spezifikation sind aber nur max. 64 genannt, nur mal so als Beispiel. Bisher funktioniert nur Scanmode 0 (cont. scan), sonst noch nichts. Aber immerhin kommt damit ein Spektrum raus, s.o.!
Zum Gitter gibt es keine Angaben, da werde ich beim Stas nachfragen. Bestellt war der Bereich 520 bis 650 nm, geliefert wurde 536 bis 676 nm bei einer Auflösung von 0,12 nm (mit verstellbarem Spalt, habe ich noch nicht nachgeprüft). Also auch da muß ich noch etwas nachjustieren. Das Gitter ist zwar nachstellbar, aber wie Jürgen schreibt, ist das eine große Fummelei.
Wenn ich da an die Unterlagen zu den Software Development Kits von tec5 oder Faulhaber denke - die sind perfekt, da funktioniert alles. Und wenn mal nicht: super Service von denen!
Viele Grüße
Horst
Hallo Horst,
hinsichtlich des Scan-Modus trat bei mir sofort der Trigger-"Gedanke" auf den Plan. Und nach Studium der HTML-Hilfe komme ich zu der Erkenntnis, dass du in der Tat wesentlich mehr Möglichkeiten hast (im Vergleich zu LRx-Benutzern), mit deinem Gerät etwas nicht so zu machen, wie es durch den Hersteller ersonnen wurde :-).
Schau dir mal "setMultipleParameters()" bzw. ,,setExternalTrigger()" an, da steht, dass im Fall des Scanmode = 1 oder 2 auf den Trigger gewartet wird (bzw. in "enablemode" abgeschaltet werden kann).
Funktioniert eigentlich der Transfer von mehreren (zwischengespeicherten) Spektren vom Spektrometer zum PC ?
Ja, Tec5 und Faulhaber sind mir auch keine Unbekannten, in der Tat sind die Beschreibungen wesentlich besser, bzw. die Testapplikationen. Wenn ich mich recht entsinne, kostete es aber auch ,,etwas" mehr .-)
Viele Grüße
Michael
Hallo Michael,
den ExternalTrigger habe ich ausprobiert, das hat keinen Einfluß. Ich denke, das bezieht sich auf den BNC-Triggereingang, nicht auf die Triggerung durch die Software ("triggerAcquisition").
Der Transfer von mehreren Spektren funktioniert, ebenso der "frameAveragingMode" = Scanmode 3.
Mit Modus 1 oder 2 komme ich noch nicht klar, ich weiß auch nicht, was man damit anstellen soll. Man könnte doch im Prinzip auf 3 stehen lassen und nur die numOfScans verändern - also 1 Scan als schnellste Messung, numOfScans >1 gibt dann Mittelwertbildung über die eingestellte Anzahl?
"ClearMemory" löscht auch nicht wie angenommen den Speicher, sondern setzt nur den Spektren-Zähler wieder auf Null.
Tec5: für das "etwas mehr" kann man ein ganzes ASEQ kaufen... aber damit wäre ich längst fertig.
Viele Grüße
Horst
Hallo Horst,
hinsichtlich "setExternalTrigger" hast du wohl recht, wie es ja auch dein Test gezeigt hat. Ich habe mir mal die Beispiele in "C++" angesehen, in denen wird übrigens immer mit "TriggerAcquisition" gearbeitet. Leider alle Beispiele nur mit scanmode=3! Ich nehme mal an, dass die Kombination von "TriggerAcquisition" mit scanmode=1 oder 2 auch nichts bewirkt, oder ?
Deine Lösung, Scanmode= 3 generell zu benutzen, ist sicherlich ein brauchbarer Weg. Aber auch mit dem kleinen Nachteil verbunden, keine "blankScans" durchführen zu können. Deine Frage der Mittelwertbildung ist mehr als berechtigt, lässt sich für mich aber leider nicht eindeutig beantworten, da es diese Optionen in unserer DLL-Version nicht gibt.
Sollte sich aber anhand des Beispiels "usedll1" (mit spectrlib_shared.dll) beantworten lassen:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
unsigned short framePixelsBuffer[4096]; unsigned short numOfFrame=0xFFFF;
numOfStartElement=0; numOfEndElement=3647; reductionMode=0; numOfScans=4; numOfBlankScans=0; scanMode=3; exposureTime=200;
Flag1=setAcquisitionParameters(numOfScans, numOfBlankScans, scanMode, exposureTime);
Flag1=getAcquisitionParameters(numOfScansB, numOfBlankScansB, scanModeB, timeOfExposureB);
Flag1=setFrameFormat(numOfStartElement, numOfEndElement, reductionMode, numOfPixelsInFrame);
Flag1=getFrameFormat(numOfStartElementB, numOfEndElementB, reductionModeB, numOfPixelsInFrame);
Flag1=getStatus(statusFlags,framesInMemory);
Flag1=0;
while(*framesInMemory==0) //1- one spectra in memory; spectra is ready and at least one spectra is lost because it's not been read
{
Sleep(25);
getStatus(statusFlags,framesInMemory);
Flag1++;
}
Flag1=getFrame(framePixelsBuffer, numOfFrame);
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Leider ist die Bemerkung des Programmierers nicht so einfach zu interpretieren ... Dem Fluß des Programmes folgend, sollte eigentlich nur ein Spektrum vorhanden sein, denn es wird ja genau einmal ,,getframe" aufgerufen (und framePixelsBuffer kann auch ja auch nur ein Spektrum aufnehmen). Dafür verstehe ich die Bemerkung des Programmierers ,,... at least one spectrum is lost ..." nicht, sollte im obigen Fall "getFrame" öfter aufgerufen werden ?
Würde ich das obige Beispiel mit der 14 Bit-Bibliothek (also LR1-Gerät, Version<<2) ausführen, müsste ich viermal das (adäqate) "getframe" aufrufen, um alle 4 Spektren zu erhalten.
Zumindest war das Anlass mir mal den Sourcecode der DLL anzusehen. Wie feststellen musste, hilft die Analyse der DLL auch nicht weiter, da diese keine Hardwarezugriffe offenlegt, sondern letztendlich ,,nur" die Windows-API-Funktionen ,,WriteFile" und ,,Readfile" aufruft. Damit bleibt die Lösung des Rätsels um den ScanMode =1 bzw. 2 verborgen. Wie sich aber herausstellte, sind sich die Bibliotheken sehr ähnlich, die ,,spectrlib_shared.dll" enthält den "Report-Aufbau" welcher bei der 14Bit-Version sich noch im Hauptprogramm befindet. Die Anzahl der Parameter sowie die Parameter selber sind teilweise unterschiedlich.
Übrigens gebe Dir völlig recht, mit einem Modell von tec5 wäre man schon längst fertig. Vielleicht kommt dir die SDACQ32MP.DLL "Operating Electronics for Carl Zeiss MMS/MCS Spectral Sensors and Hamamatsu MOS Linear Image Sensors", bekannt vor...
Viele Grüße
Michael
Hallo Michael,
herzlichen Dank für Deinen Kommentar, das hilft mir schon etwas weiter!
Was ist der Zweck von Blank Scans, und wieso hältst Du es für einen Nachteil, wenn man die nicht machen kann? Ein Scan wird durchgeführt, aber nicht gespeichert, da sind halt nur Pausen einstellbarer Länge zwischen den Messungen.
Nach eingehender Exegese der DLL-Beschreibung in func_descr.txt folgende Anmerkungen:
"reduction Mode" halte ich für eine Mittelwertbildung über 2/4/8 benachbarte Pixel, also eine Art Binning, unter Verlust von Auflösung.
"frame averaging" ist dagegen die Mittelung über n Spektren ohne Auflösungsverlust, für jedes Pixel einzeln, aber mit entsprechendem Zeitbedarf. Das hat nichts zu tun mit "Fast" in der Toolbar des mitgelieferten Programms; dabei wird zwecks schnellerer Datenübertragung nur jeder zweite Datenpunkt übertrage, mit dem schönen Nebeneffekt, daß die Wellenlängenskala nicht mehr stimmt.
Dein Beispiel aus useddll_1 will ich mal ausprobieren. Bericht folgt. Entscheidend ist numOfFrame = 0xFFFF, das lädt das fertige gemittelte Spektrum. Im Beispiel wird framesInMemory in einer Schleife so lange abgefragt, bis der Wert 1 oder 2 ist. Danach wird in der letzten Zeile das gemittelte Spektrum mit getFrame geladen (wegen NumOfFrame = 0xFFFF) - also nicht viermal getFrame aufrufen! Irgendwann muß das Spektrometer ja melden, wenn es fertig ist, wichtig bei langen Integrationszeiten; deshalb die Abfrage von framesInMemory.
Ansonsten gibt es neue Klöpse: schmale Peaks haben immer einen kleinen Begleiter, wahrscheinlich durch schlechte Justierung eines Spiegels (siehe Bild). Und die mitgelieferte Wellenlängen-Kalibriertabelle sollte eigentlich die Wellenlänge jedes einzelnen Pixels liefern. Das ASEQ-Programm gibt korrekte Werte, aber wenn ich über die Funktion "save calibration to file" die geräteeigene Kalibrierung lade und im eigenen Programm verwende, gibt es einen shift von immerhin ca. 1 nm. Seltsam.
Ach, wie schön ist das Arbeiten mit SDACQ32MP.DLL! Und dieser phänomenale Telefonservice von denen!
Viele Grüße
Horst
Hallo Horst,
danke für das aufmerksame Studium meiner Zeilen, da wäre ja sonst ein Fehler durchgerutscht! Aber der Reihe nach:
Was ist der Zweck von Blank Scans, und wieso hältst Du es für einen Nachteil, wenn man die nicht machen kann? Ein Scan wird durchgeführt, aber nicht gespeichert, da sind halt nur Pausen einstellbarer Länge zwischen den Messungen.
Du hast die Frage eigentlich schon selber beantwortet: ,,.. sind halt nur Pausen einstellbarer Länge...".
Wahrscheinlich ist das Ansichtssache. Ich sehe es so: Man könnte, ohne Zeitsteuerung durch den Computer, die Gesamtmesszeit durch die (leider nur äquidistanten) Zeitabstände der Blank Scans verlängern. Sicher hat man nicht mehr Spektren, kann sie aber über einen längeren Mess-Zeitraum besser verteilen ...
Es könnte da auch noch einen zweiten Aspekt geben, allerdings habe ich das noch nicht wirklich getestet. Außerdem befürchte ich, dass ich mich dabei auf sehr dünnem Eis bewege.
Gelegentlich kommt es vor, dass der Zeilendetektor durch zuviel Licht regelrecht geflutet wird. Dass einmalige Auslesen ist dann nicht ausreichend um die ,,Elektronik wieder in den Ausgangszustand zu versetzen". Im Fall des LR1 (14Bit) ist es daran zu erkennen, das die Counts negativ werden (das habe ich so auch noch nicht an anderen Arrays beobachtet). Die Blank Scans könn(t)en dann dafür sorgen, dass die elektr. Ladung wieder vollständig ,,entladen" wird. Na,ja wohl sehr theoretisch. In so einem Fall behelfe ich mich mit dem Neustart des Programms.
Und natürlich ist es schön, mal eine andere Meinung zu den Blank Scans zu hören...
Nach eingehender Exegese der DLL-Beschreibung in func_descr.txt folgende Anmerkungen:
"reduction Mode" halte ich für eine Mittelwertbildung über 2/4/8 benachbarte Pixel, also eine Art Binning, unter Verlust von Auflösung.
Da ist mir wahrlich ein Schnitzer unterlaufen, da hast du vollkommen recht, das ist ,,Binning" und kein ,,Averaging", so wie es in der Beschreibung (unkorrekt) genannt wird. An den Parametern hätte es mir spätestens auffallen müssen, denn was sollte die Beschränkung auf 2^n, und das auch nur bis n= 3, für die Mittelwertbildung von Spektren. Dann ist das Beispiel doch sehr viel klarer. Allerdings verstehe ich die Bemerkung des ASEQ-Programmierers immer noch nicht, was aber letztendlich egal ist, da der Praxistest ja zeigen wird was Sache ist. In diesem Sinne habe ich meinen Beitrag auch korrigiert, nicht dass ein anderer Leser noch darüber stolpert und falsche Schlüsse zieht.
Das LR1 (14Bit) bringt diese Optionen nicht mit, ich löse diese Aufgaben innerhalb des Programms.
Ansonsten gibt es neue Klöpse: schmale Peaks haben immer einen kleinen Begleiter, wahrscheinlich durch schlechte Justierung eines Spiegels (siehe Bild). Und die mitgelieferte Wellenlängen-Kalibriertabelle sollte eigentlich die Wellenlänge jedes einzelnen Pixels liefern. Das ASEQ-Programm gibt korrekte Werte, aber wenn ich über die Funktion "save calibration to file" die geräteeigene Kalibrierung lade und im eigenen Programm verwende, gibt es einen shift von immerhin ca. 1 nm. Seltsam.
Ich entsinne mich, das davon die Rede war, das man die Optik (Spiegel ?) korrigieren kann. Wird das von außen über Stellschrauben realisiert und darf (muß) man das Gerät dafür öffnen ?
Eine Differenz von einem Nanometer, hört sich für ein hochauflösendes Gerät schon ganz schön viel an. Hast du technische Mittel um die Wellenlängenrichtigkeit zu überprüfen ? Aktuell beschäftige ich mich ebenfalls mit diesem ,,Bereich" des Spektrometers. Die von Dir erwähnten -korrekten Werte- beziehen sich doch auf die CheckTr-Applikation (entsprechend deiner Abbildung), oder ?
Ich kann mich nicht entsinnen, eine Datei mitgeliefert bekommen zu haben. Du hast deine Datei über ,,load calibration from file" geladen ? Hast du anschließend die Option ,,save current calibration to flash memory" benutzt ?
Ich habe mir mal die Werte angesehen, welche im Programm via ,,save calibration to file" ausgegeben werden. Ich erhalte folgendes:
1) Name und Versionsnummer des Spektrometers
2) die drei Parameter für das Polynom zur Berechnung der Wellenlänge als f( Diodennummer)
3) 3553 Werte mit dem Wert = 1 oder nahe diesem Wert (siehe Abbildung, min:0.766, max:1.16)
4) Einmal ,,0"
5) leer
6) 3553 mal den Wert= 51.199
7) am Ende, einmal ,,1"
Was mich wundern würde wenn unter Punkt 3 eine Wellenlängenkorrektur abgelegt wäre. Entweder wird der Zusammenhang zwischen Diodennummer und Wellenlänge wird mit einer Polynomfunktion korrekt erfasst, oder es kann nicht exakt genug berechnet werden, so dass generell eine Wertetabelle benutzt werden muss. Das Polynom wäre m.E. dann höchst überflüssig...Die Werte mit exakt ,,1", hätte man prima in den Parametern des Polynoms unterbringen können. Da ich diese Werte in meinem Messprogramm nicht benutze (ich kann mich allerdings schwach erinnern, mich damit schon mal beschäftigt zu haben, aber an eine tabellarische Wellenlängenkorrektur kann ich mich in diesem Zusammenhang nicht erinnern), ist es wohl notwendig, noch mal ein genaues Studium (vielleicht wird es auch eine Exegese ;)) der LR1-Unterlagen durchzuführen.
Viele Grüße aus Berlin
Michael
Hallo Michael,
zu den Blank Scans: das mit der Übersteuerung der Pixel könnte gut sein, muß mal unseren Physiker dazu befragen.
Den Optik-Spiegel kann man nur in engen Grenzen von außen justieren, eine Beschreibung war beigelegt, die aber nicht mit der Realität übereinstimmte. Ich habe dann noch mal beim Stas nachgefragt und den üblichen Einwortsatz zurückerhalten. Die Korrektur soll sich nur auf die Intensität auswirken ("to achieve maximum detectable signal"), die Wellenlängenkorrektur sei wesentlich aufwendiger (hat Jürgen ja schon beschrieben). Ich habe aber noch nichts verstellt, die Programmierung hat Vorrang. Die Wellenlängenrichtigkeit prüfe ich mit einer Neon-Glimmlampe, dazu gibt es veröffentliche Daten. Die mit dem ASEQ-Programm und mit Spectragryph ermittelten Wellenlängen sind bis aufs Hundertsel korrekt.
Das Calibration File sieht bei mir völlig anders aus, nämlich
Line 1 Spectrometer Model, Y/N für Irradiation Calibration, Seriennummer
Line 2 Coeff for absolute irradiation
Line 3-12 leer
Line 13 bis 1665: Wellenlänge für 1. bis 3653. CCD-Element
Die restlichen Zeilen bis 10975 sind für "intensity normalization for each CCD-element" - das entspricht Deiner Tabelle, enthält bei mir ebenfalls 1,000 für jeden Wert. Das dient also der Intensitätskalibrierung (was ich noch nicht kann wg. Problemen mit der Kalibrierlampe).
So habe ich es sowohl von ASEQ als separate Datei mit meiner Seriennummer erhalten, und genauso kann ich es über load calibration file auslesen.
Inzwischen habe ich aber ein funktionierendes Unterprogramm zum Auslesen anhand Deines Beispiels von gestern erstellt, wobei ich die Zeilen mit get... wegelassen habe, keine Ahnung wozu erst reinschreiben und dann wieder auslesen ohne Prüfung des Statusflags auf Fehler. Ist in VB2010, aber selbsterklärend:
'ASEQ ######### Unterprogramm Messung ########################################
Public Sub Messung(ByRef Meßreihe As Integer)
Dim result As Integer
Dim numScans As UShort = txtBoxMittelwert.Text 'maximal 64 bis 70 frames
Dim numBlankScans As UShort = 0 'nach Angabe in func_descr
Dim scanMode As Byte = 3 'frame averaging mode
Dim exposure As UInteger = 100 * txtBoxIntegrationszeit.Text 'da Takt = 10 µs und Integrationszeit in ms
Dim startElement As UShort = 0 '0: zulässiges Minimum
Dim endElement As UShort = 3647 '3647: zulässiges Maximum
Dim reductionMode As Byte = 0
Dim pixelsInFrame As UShort = 3647 'vielleicht zur Korrektur beim Binning?
Dim framesInMemory As UShort
Dim numOfFrame As UShort
Dim statusFlags As UInteger
numOfFrame = Convert.ToInt32("FFFF", 16)
result = spectInterface.setAcquisitionParameters(numScans, numBlankScans, scanMode, exposure)
result = spectInterface.setFrameFormat(startElement, endElement, reductionMode, pixelsInFrame)
result = 0
Do While (framesinMemory <> 2)
System.Threading.Thread.Sleep(25)
result = spectInterface.getStatus(statusflags, framesInMemory)
result = result + 1 'aus dem Beispiel - wozu?
Loop
result = spectInterface.getFrame(Rohdaten, numOfFrame) 'Rohdaten: Array für die Meßwerte
spectInterface.clearMemory() 'habe ich sicherheitshalber mal eingefügt
End Sub
Mit numOfFrame 0xFFFF wird das gemittelte Spektrum abgeholt. Mit framesInMemory = 2 ging es gut, heißt ja "spectra is ready and at least one spectra is lost because it's not been read" - weiß der Teufel, was damit gemeint ist. Keine Triggerung!
Geht das in Deiner Version auch so mit der Abfrage oder hast Du eine andere Lösung dafür?
Viele Grüße
Horst
Hallo Horst ,
zu den Punkten Antwort #18:
3 – 6 die Werte ,
wenn eine Kalibrierung durchgeführt wurde .
(https://www.mikroskopie-forum.de/pictures010/303623_47096010.jpg) (https://www.pic-upload.de)
LG
Jürgen
Hallo Jürgen,
das mußt Du mir mal erklären. Wie bist Du vorgegangen?
Die Kalibrierdaten (d.h. die Wellenlängen für jedes Pixel) habe ich aus dem Gerät über "load Calibration file" aus dem Gerät geholt; da mit dem ASEQ-Programm die richtigen Werte rauskommen, sollte das Spektrometer schon werksseitig kalibriert sein.
Heißt das: bei einer erneuten Kalibrierung stehen in 3-6 die Koeffizienten?
Die gezeigte Kurve ist mir auch unklar: Abszisse = Pixelzahl, Ordinate = ? Und wieso eine Gerade?
Viele Grüße
Horst
Hallo Horst ,
dies hat nichts mit der Pixel / Lambda kalibrierung zu tun , die stehen unter Punkt 2 deiner Tabelle (Parameter A,B,C des Polynoms)
Das Diagramm zeigt die orange gerade Linie , alle Werte auf 51 gesetzt vor der Plank Kalibrierung.
Nach der Kalibrierung ( Aufnahme der Kurve einer Bekannte Quelle und Eingabe der Farbtemperatur der Quelle).
errechnet das Programm oder das Gerät ( kann nicht sagen was) die korrektur zur Plank- Kalibrierung ( graue Kurve und die durch
die dünnen Schichten am Chip entstandenen Interferenzen Punkt 3.( Etaloning ) werden berechnet und kompensiert
(blaue Linie , min:0.766, max:1.16rechte Ordinate aber nicht korrekt dargestellt).
LG
Jürgen
Hallo Horst,
ich verfolge diesen Dialog nun schon eine Weile mit Interesse.
Wolltest Du mit dem Gerät auch messen?? ;D ;D ;D
Viele Grüße,
Holger
Moin Holger,
ja, messen war eigentlich meine Absicht. Aber ASEQ ist dagegen.
Bei der Gelegenheit: es scheint bei Dir offensichtlich mit LabView zu funktionieren. Also ein paar Fragen:
Woher kommen die Faktoren A, B, C?
Geht die Datenübertragung so wie in den Beiträgen von Michael und mir oben vermutet?
Was bedeutet "Test"? Das ist ein Häkchen, das in der ASEQ-Software gesetzt werden kann und auch in LabView auftaucht. Die Funktion ist nirgendwo beschrieben.
Was wird eigentlich im Flash-Speicher abgelegt? Es gibt zwar Funktionen zum Beschreiben und Lesen, aber wozu?
Hast Du die Wellenlängenkalibrierung mal geprüft und die Sensor-Empfindlichkeit mit der Kalibrierlampe?
Im Laufe des Tages fallen mir sicher noch mehr Dinge ein, die ASEQ verschweigt.
Viele Grüße
Horst
Hallo Jürgen,
das Problem ist: wir haben verschiedene Versionen.
Ich habe nicht CheckTR, sondern ASEQ Spectra, = ASEQ_16bits V1_13.exe, dazu eine andere Kalibriertabelle namens N2315.clbr.
Da steht was anderes drin als bei Dir.
"dies hat nichts mit der Pixel / Lambda kalibrierung zu tun , die stehen unter Punkt 2 deiner Tabelle (Parameter A,B,C des Polynoms)"
Genau darum geht es mir ja gerade. In Punkt 2 (= Zeile 2) meiner Tabelle steht nichts, also keine Faktoren A,B,C.
Von Planck-Kalibrierung bin ich noch weit entfernt...
Viele Grüße
Horst
Hallo Horst,
ich hab erst ab dem 7. Juni wieder Zugriff auf das System und schau mir das in LabView an.
Das Messen mittels der mitgelieferten Applikation läuft aber - oder?
(Ich weiß, dass es Dir um eine Systemintegration geht, wollte aber nur sicherstellen, dass das Gerät messen kann ...)
Viele Grüße,
Holger
Hallo Holger,
ASEQ Spectra und Spectragryph laufen, das Gerät ist in Ordnung (bis auf den abweichenden Meßbereich und die Peak-Satelliten).
Mich wundert übrigens auch, daß ein so abseitiges Thema schon über 900 Zugriffe hat...
Viele Grüße
Horst
Hallo Horst,
inzwischen habe ich jetzt wieder einen klaren Durchblick, da ich endlich meine Reservekopie des Sourcecodes gefunden habe, so muss ich nicht mehr nur aus dem Gedächtnis (13 Jahre her) die Sachlage rekonstruieren.
ich gehe mal davon aus, dass deine Frage auf die Abfrage der Status-Bereitschaft abzielt. Zum Vergleich findest Du die (a) Routine der Funktion ,,GetStatus" aus der 16Bit-DLL (gekürzt und etwas gestrafft), sowie den (b) Programmcode aus dem 14Bit-Anwendungsprogramm aufgelistet.
Auszug aus der DLL – 16 Bit
----------------------------------------------------------------------------------
int getStatus(uint8_t *statusFlags, uint16_t *framesInMemory,...)
report[0] = ZERO_REPORT_ID; -> 0
report[1] = STATUS_REQUEST; -> 1
result = _writeReadFunction(report,.., ....,...);
if (statusFlags) {*statusFlags = report[1]; }
if (framesInMemory) { *framesInMemory = (report[3] << "8") | (report[2]); }
| Auszug aus dem Hauptprogramm – 14 Bit
----------------------------------------------------------------------------------------------------
//*********** get status ***************
OutputReport(0) = 0 -> ZERO_REPORT_ID
OutputReport(1) = 2 -> STATUS_REQUEST
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
While InputReport(3) != 0
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
Wend
|
Der Programm-Aufbau und die ,,Verarbeitung" (auf der PC-Ebene) sind sehr ähnlich. Die wesentlichen Unterschiede sind:
1) Das 16Bit- ,,GetStatus" ist weiter abstrahiert und taucht eben nur noch als ,,Getstatus" im Anwendungsprogramm auf. Anhand des Programm-Codes in der DLL, siehst du aber, dass das, was bei mir im Hauptprogramm steht (z.B. das ,,Reportfeld"), in die 16 Bit –DLL ausgelagert worden ist
2) Die Parameter-Werte sind teilweise anders (rot markiert)
Damit ist die Benutzung der DLL's an die jeweiligen Gerätetypen gebunden und nicht austauschbar. Sicherlich wird ohnehin kein ,,16Bit-User" die alte Bibliothek nutzen wollen, die ,,14Bit-User" können aber auch nicht die neuere DLL benutzen. (Man könnte natürlich die 14 Bit-Bibliothek umschreiben, um so eine Angleichung zu erreichen...)
Die eigentlichen Befehle sind letztendlich die Windows-API-Funktionen ,,WriteFile" und ,,Readfile", welche mit dem Betriebsprogramm des Spektrometers kommunizieren. Diesen API-Funktionen werden die Parameter in einem Feld/Speicher (,,....Report" bzw. OutputReport und InputReport) übergeben bzw. zurückgegeben. Die Funktion ,,writeReadFunction" (16 Bit) bzw. ,,ReadWritetoDevice" (14 Bit) sind nur Zwischenstationen zu den API-Funktionen.
Der Vollständigkeit halber, und zum Vergleich mit deinem Beispiel, die Routine im Haupt¬programm zum Spektrentransfer (welche sich an den oben gezeigten Sourcecode anschließen würde..):
For i = 1 To NScans
s = GetSpectra( _
V:SpecInt(0, i - 1), /* "Spectra" = 3653 elements (unsigned __int16) array */ _
1, /* "SpecNmb" = 1 */ _
0, /* "endPix" = 3652 */ _
3652, /* "StartPix" = 0 */ _
Fast, /* "Fast" = 0 or 1 */ _
0, /* "test1" = 0 */ _
33, /* "tot_startPix " = 33 */ _
3685) /* "tot_endPix" = 3685 */
OutputReport(1) = 9 //move address ?? (whatever that means ...)
OutputReport(2) = &H01
OutputReport(3) = &H80
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
Next i
Die Nutzer-Oberfläche der ,,ASEQ_16bits V1_13.exe" (Abbildg., Beitrag #17) sieht zumindest so aus, wie die der ,,CheckTr.exe". In der Menuleiste steht ,,ASEQ Software" über ,,Help" erhält man die Versionsnummer, bei mir Version 9.4.
Ja, in der Tat sind deine (im Flash-Speicher abgelegten) Werte etwas anders ... So vorhanden, geh doch bitte mal in das Haupt-Menu ,,Calibration", sowie zum Untermenü ,,Calibration". Dort werden die drei Parameter A, B und C angezeigt, so vorhanden. Aber letztendlich bist du ja nicht auf den Parametersatz zur Berechnung der Wellenlänge = f(Pixel) angewiesen, da du ja eine WL-Wertetabelle hast. Mir ist jetzt nicht klar, ob du nach den Parametern A,B und C suchst, um deinen Wissensdurst zu stillen, oder ob dir der analytische Ansatz, via Polynom, symphatischer ist.
Aus dem Flash-Speicher werden die Werte der Aufzählung (1-3) (Antwort #18) ausgelesen. Das bekomme ich auch mit meinem Programm hin. Woher allerdings die Werte aus der Aufzählung (6) (Antwort #18) kommen (3553 mal den Wert= 51.199), ist mir aber noch unklar. Es ist nicht unbedingt zwingend, den Flash-Speicher im Anwendungsprogramm auszulesen. Letztendlich reicht auch eine ,,Verdrahtung" der Daten in der (eigenen) Applikation bzw. das Einlesen der Daten vom Speichermedium, wenn man z.B. eine ganze Batterie von ASEQ-Spektrometern hat ;) .
Die unter der Aufzählg. (3) (Antwort #18) erwähnten, und in der Abbildung ,,Graph1c.jpg" dargestellten Werte zur Intensitätskorrektur, nutze ich auch. Wer es ausprobieren möchte: In der ,,ASEQ software" über die IconBar, das Icon ,,Schraubenschlüssel" auswählen. Im ,,Settings"-Menu -> ,,Apply norm" wählen (Standardeinstellung). Die angefügte Abbildung zeigt die Unterschiede welche mit einem LR1-14Bit zu beobachten sind.
Die Option ,,Test" in der Funktion ,,GetSpectra" (das 14Bit-Pendant für ,,GetFrame") wurde anhand der 14Bit-DLL untersucht. Die Funktion besteht aus mehreren Seiten Programmier¬code, eine schnelle Analyse ist da nicht möglich. Ein Vergleich der beiden Sequenzen zeigt aber, dass der Testbereich wesentlich weniger umfangreich, und im Wesentlichen identisch, mit dem Anfang der normalen Routine, ist. Standardeinstellung für den Parameter ,,Test" ist ja ,,0", jeder andere Wert führt die Test-Routine aus. Es ist anzunehmen, dass die 16Bit-DLL kaum Überraschungen dahingehend bereithält. Im CheckTr-Programm (,,Settings") ist diese Option übrigens auch verfügbar.
Noch mal zum Binning-Parameter der setFrameFormat()-Funktion (16 Bit). Du hattest es ja als ,,... eine Art von Binning" bezeichnet. Ich hatte noch mal überlegt ob es jetzt ein Software-Binning ist oder doch ein Hardware-Binning sein könnte. In der Beschreibung des Parameters "reductionMode" steht: "reductionMode defines the mode of pixels averaging 0 - no average 1 - average of 2 2 - average of 4 3 - average of 8". Was ja leider eher nach Software-Binning (reine Mittelwertbildung) aussieht. Ganz ausgeschlossen scheint mir das echte Binning (Hardware-) aber nicht zu sein. Sicherlich ist diese generelle Frage bei ASEQ besser aufgehoben, aber falls jemand
praktische Erfahrungen/Kenntnisse haben sollte, im Fall es ist Hardware-Binning, würde mich natürlich über eine Nachricht freuen.
Viele Grüße aus Berlin
Michael
Hallo Michael ,
,,Noch mal zum Binning-Parameter 4 3 - average of 8". Was ja leider eher nach Software-Binning
(reine. Ganz ausgeschlossen scheint mir das echte Binning (Hardware-) aber nicht zu sein. Sicherlich ist diese generelle Frage
bei ASEQ besser aufgehoben, aber falls jemand praktische Erfahrungen/Kenntnisse haben sollte, im Fall es ist Hardware-Binning,
würde mich natürlich über eine Nachricht freuen."
ich habe mal zwei Spektren aufgenommen ,bei den ersten habe ich ,,Scans ,,konstant gehalten und ,,box ,, von 5 , 10 , 20 , 30 variiert.
Im Zweiten habe ich ,,box ,,Konstant gehalten und ,,Scans" variiert. Man sieht deutlich , wie bei Veränderung der ,,box", der Ausschlag wandert ,Pixel und Intensität.
Somit vermute ich ein Hardware ,,binning" .
(https://www.mikroskopie-forum.de/pictures010/303746_63208015.jpg) (https://www.pic-upload.de)
(https://www.mikroskopie-forum.de/pictures010/303746_32001227.jpg) (https://www.pic-upload.de)
LG
Jürgen
....
Ich habe noch eine Simulation von drei Spektren die nur Software mäßig ,,gebinnt" wurden.
Mittelwerte aus 10 Messungen ,,vorwärts, rückwärts und symmetrisch" . Hier tritt auch eine Verschiebung auf, aber nur entlang der x-Achse, nicht an der Intensität Y.
(https://www.mikroskopie-forum.de/pictures010/303765_36849274.jpg) (https://www.pic-upload.de)
LG
Jürgen
Hallo Jürgen,
Vorsicht, mit dem Kästchen "Box" wird nicht das hier diskutierte "Binning" gemacht. Das ist vielmehr eine Boxcar-Glättung, also ein gleitender Mittelwert. Dabei verschieben sich die Maxima! "Binning" kann man im ASEQSpectra nicht einstellen, das geht nur über die direkte Programmierung mit der DLL. Was dann passiert, muß ich noch ausprobieren.
Die Glättung von Spektren geht besser mit Savitzki-Golay, da bleiben die Maxima erhalten. Ist aber bei ASEQ nicht drin.
Der verbaute Chip Toshiba 1304DG macht laut Datenblatt kein Pixel-Binning, da müßte der AD-Wandler herhalten, und ich glaube nicht, daß die so viel Aufwand getrieben haben. Aber glauben heißt nicht wissen.
Viele Grüße
Horst
Hallo Michael,
vielen Dank für Deine umfangreichen Software-Untersuchungen!
Es sieht ganz so aus, als sei das Datenübertragungsproblem gelöst. Ich habe einfach mal verschiedene Einstellungen durchprobiert, und es funktioniert nur mit der in #19 gezeigten Abfrage auf ,,framesInMemory = 2". Ich erhalte dann die erwarteten Spektren - aber nur fast; denn die Wellenlängen stimmen nicht, und es fehlt ein Stückchen im Langwelligen.
Die Wellenlänge konnte ich folgendermaßen korrigieren:
Da die Parameter A,B,C nicht vorhanden sind, habe ich die aus der Kalibriertabelle berechnet. Damit kann ich nun durch einen Versatz der Form Lambda = A*(Pixelnummer+Versatz)² + B*(Pixelnummer+Versatz) +C die Kalibrierung gewissermaßen parallelverschieben. Dann paßt alles ganz genau. So macht es auch das ASEQ_Spectra (aktuell V. 1.15) mit der Funktion ,,Calibration-> Calibration shift".
Was aber noch aus Deinem Programmteil Spektrentransfer auffällt: ,,endpix" sollte doch 3647 sein (also 0 bis 3647 für 3648 Pixel des Sensors) und nicht 3652? Und was bedeutet tot_startPix=33 und tot_endPix=3685? Bei mir kann ich nur numOfstartElement =0 und und numOfEndElement = 3647 eingeben. Ich suche nämlich immer noch nach dem verlorengegangen Stückchen im Langwelligen, s.o.
Die Option ,,Test" kann man also getrost ignorieren, ebenso wie den Flash-Speicher.
Die Intensitätskorrektur ,,Aufzählg. (3) (Antwort #18)" ist wohl nur für die XYZ-Option gedacht, ich brauche aber eine Korrektur der wellenlängenabhängigen Detektorempfindlichkeit (was wie eingangs erwähnt nicht einfach ist und eine Kalibrierlampe braucht). Kommt später noch rein.
Zum letzten Abschnitt ,,Binning" Deines Beitrags: das ist überhaupt kein Binning oder Mittelung oder sonst was, ,,averaging" ist schlicht falsch. Das ist nur die Funktion ,,fast" im ASEQ_Spectra (bzw. CheckTr), bei der jedes 2./4./8. Pixel übertragen wird, um die Datenübertragung zu beschleunigen. Hat den Charme, daß dann die Wellenlängen nicht mehr stimmen (auch so im ASEQ_Spectra!).
Viele Grüße nach Berlin
Horst
Hallo Horst,
gerne geschehen, so lerne ich ja auch dazu bzw. werde auf neue Fragestellungen aufmerksam (gemacht).
Das ist schon sehr merkwürdig, mit dem fehlenden Teil des Spektrums. Lässt sich irgendetwas ableiten aus der "Länge" (wieviel Pixel) des fehlenden Spetrumbereiches ? Ich nehme mal an, dass am Spektrum in der ASEQ-16Bit-Software aber nichts fehlt, oder doch ? Das Wellenlängenproblem ist also generell gelöst ? Was ich nicht verstehe, ist deine Bemerkung, dass bei "framesInMemory = 2" die Wellenlängen nicht stimmen ..., ist das ein Problem, oder kannst du es durch den "Versatz" korrigieren ?
Deine Anmerkung zu den Pixeln ("GetSpectra") ist interessant, ich habe die Werte für diese Parameter von ASEQ. Eine (genaue) Information zu den Parametern habe ich eigentlich nicht. Meine Interpretation ging dahin, dass es sich bei dem "totalen Startpixel" bzw. "totalem Endpixel" um die wirklich vorhandenen Pixel handelt (so kenne ich es zumindest von anderen Spektrometern). Bis jetzt hatte ich mich allerdings auch noch nie mit dem Datenblatt beschäftigt, in welchem ja von (,,nur") 3648 Pixeln die Rede ist. Hmm, da ist in der Tat ein neues Rätsel aufgetaucht. Ich habe mal die Werte für die ,,tot_-Werte" verändert und siehe da, das Signal (Spektrum) ändert sich. Da gibt es plötzlich zusätzliche Peaks bzw. im langwelligen Bereich fehlt etwas ! Wird beispielsweise jeweils 33 subtrahiert, ,,fehlen ca. 12 nm Spektrum" im langwelligen Bereich. Unter ,,Settings" in der CheckTr.exe tauchen diese auch auf (T start bzw. T end pixel), ohne die Möglichkeit diese verändern zu können. Hast du in deiner ASEQ-Software vielleicht ähnliche Einträge ?
Vielen Dank, dass du dir ,,reductionmode" mal praktisch angeschaut hast, wie es aussieht, gibt es (leider) keine positive Überraschung ...
Hallo Jürgen, auch dir meinen Dank. Insbesondere, da ich über eine Implementierung des BoxCar-Verfahrens zur Glättung nachgedacht habe. Insbesondere das Beispiel ,,...habe ich ,,box ,,Konstant gehalten und ,,Scans" variiert. Man sieht deutlich , wie bei Veränderung der ,,box", der Ausschlag wandert ,Pixel und Intensität.", lässt mich eher von meinem Vorhaben Abstand nehmen. Zumal ich aktuell das gleitende Mittelwertverfahren (Sawitzky-Golay) benutze, bei dem ich eine (derartige) Verschiebung der Maxima noch nicht beobachtet habe. Ohne Frage spielen generell der Glättungsparameter und die Y-Wert-Verteilung eine große Rolle.
Worin bestehen denn die Verbesserungen (Änderungen) zwischen den LR1-Generationen nun eigentlich:
- aus dem Einsatz eines 16-Bit-AD-Wandlers und
- der Umgestaltung und Erweiterung der Anwender-DLL ...
Ich werde aber mal bei ASEQ nachfragen, und mal sehen, ob es die Möglichkeit gibt, das LR1-14Bit auf 16Bit umzurüsten. Zumindest steht ja im ASEQ-Datenblatt: "We can replace CCD sensors on our previously made spectrometers", da besteht doch (bei mir zumindest) eine gewisse Hoffnung auch hinsichtlich des AD-Wandlers.
Hinsichtlich der Kalibrierung (wellenlängenabhängige Detektorempfindlichkeit) hatte ich schon mal mit Jürgen konferiert. Mein Vorhaben ging von meiner Hardwarebasis aus. Ich möchte gern unter Verwendung eines Leistungsdichte-Messgerätes https://de.coherent.com/measurement-control/measurement/labmax-to mit entsprechendem Sensor und unter Einsatz einer polychromatischen Lichtquelle (Hg-Brenner) in Kombination mit Metall-Interferenzfiltern mich einem Kalibrierungsversuch nähern. Eine durchstimmbare monochromatischen Lichtquelle (Laser) wäre mir zwar lieber, aber erst einmal haben ... Wie sieht denn dein Plan zur Kalibrierung genau aus ?
Viele Grüße nach Bonn
Michael
Hallo Michael,
nach dieser Anleitung z.B. könnte man vorgehen. Die Vorgehensweise ist relativ einfach, so man eine bekannte Eich-Lichtquelle hat, die zudem nicht schon durch Alterung an Leistung verloren hat.
https://www.horiba.com/fileadmin/uploads/Scientific/Documents/OSD/203_Instrument_Response_Corrections.pdf
Mein LR1 z.B hatte diese Kalibrierung bei seiner Auslieferung, aber durch meine Basteleien, war sie am Ende nichts mehr Wert. Wie in unserem Emails -Austausch schon angesprochen, ist die Farbtemperatur -Korrektur, bei der man zu Ende der Plank-Kalibrierung noch die Farbtemperatur der Lichtquelle eingeben muss, nur die halbe Miete.
Unter dem Menüpunkt ,,Settings" muss nach vollständigem Aufbau der Messeinrichtung noch der ,,irradiation correction Coefficient" eingeben, um die Abweichung von der ,,Basis-Kalibrierung" zum eigentlichen Aufbau zu korrigieren. Das kann man durch eine Vorher-nachher-Messung herausfinden. Dennoch gestalte sich das aber schwierig , wenn man z.B die Strahlungsleistung die am Objekt einwirkt ( unter dem Mikroskop), kennen möchte, denn von Lichtquelle bis Objekt und dann weiter vom Objekt bis zum Spektrometer verändern sich die Verhältnisse wieder. Man müsste also an der Lichtquelle , direkt am Objekt und nach dem Beobachtungs-Strahlengang messen.
Zum Mittelwert-Verfahren (z.B.: Sawitzky-Golay ) möchte ich anmerken , das es doch wohl keinen Sinn macht, wie im Programm des Herstellers, z.B. die vorangehenden 7 Messpunkte zur Mittelwertbestimmung zu nutzen , anstatt drei oder vier vorangehende und drei oder vier nachgestellte Werte zu berechnen? War das nur Dummheit oder steck da doch etwas Anderes dahinter?
LG
Jürgen
Hallo Michael und Jürgen:
@Michael:
Zum Datentransfer-Problem in den ersten beiden Absätzen werde ich mich später äußern, das ist noch nicht ganz geklärt. Muß noch ein paar Versuche dazu machen und den Stas befragen. Nur so viel: das mit den fehlenden 12 nm ist auch bei mir so.
"reduction mode", "averaging" und "binning": dazu schreibt Stas:
Dear Horst,
Your spectrometer has 1200gr/mm diffraction grating.
Yes, you can see reduction mode. It will transfer every 2nd, 4th and so on pixel just to increase data transfer speed.
Regards,
Stas
Jetzt haben wir es amtlich, kein "binning", nur schnellerer Datentransfer.
Nach dem Sinn des Blank Scans habe ich auch gefragt, das hat er aber nicht beantwortet. Mein Fehler, niemals mehr als zwei Fragen in einer Mail >:(
@ Jürgen:
Glättungsverfahren: die haben alle ihren Sinn. Die Savitzky-Golay-Glättung hat - wie schon erwähnt - den Vorteil, daß sie die Peakmaxima nicht verschiebt. Das ist nicht zufällig so, sondern beabsichtigt. Deshalb hat Michael das auch noch nicht beobachtet. Dafür gibt es auf einmal bei meinen scharfen Peaks Überschwinger, die bei der Niedrigauflösung so nicht vorkommen.
Wenn Du die Zahl n der Scans erhöhst, werden die Spektren gemittelt und das Rauschen um Wurzel (n) reduziert. Das Peakmaximum verschiebt sich nicht, ist ja immer dasselbe Spektrum.
Savitzky-Golay ist nicht im ASEQ enthalten!
Wellenlängenabhängige Detektor-Empfindlichkeit:
Die von Jürgen zitierte Horiba-Methode mit Wolframlampe ist eigentlich Standard. Hg-Brenner geht gar nicht, viel zu instabil und nicht langzeitkonstant. Wir haben das mit einer Halogenlampe versucht, die mit 1-A-Konstantstrom betrieben wird, und die mit einem kalibrierten Spektrometer gemessen für die Kalibrierkurve. Hat bisher nicht funktioniert, weil Mondphase und mein Chakra nicht harmonierten ...
Das mit Lasern usw. ist zu kompliziert, ein Coherent-Lasermeßgerät ähnlich wie in Deinem Link habe ich hier zum Spielen (Coherent FieldMaxII), halte Gerät und Methode mit vielen, vielen Spektralfiltern (weil man viele Meßpunkte braucht) aber für ungeignet: es müßte kalibriert sein, Filter sind teuer, durchstimmbare Laser nur unwesentlich teurer....
Aktueller Plan: ich habe eine Ocean Optics DH-mini hier, das ist aber nicht als Kalibrierlampe gebaut und muß noch auf irgendwas Kalibriertes zurückgeführt werden. Das kriegen wir aber mithilfe des Physikalischen Instituts hin. Man erhält ein klassisches Planckh-ähnliches Wolframlampen-Spektrum und hat zu jeder beliebigen Wellenlänge die Energie. Rückführbar auf nationale Standards und damit akkreditierbar nach DIN EN ISO 17025: wohl kaum, macht aber nichts ;)
Austausch des CCD-Sensors: das wird wohl nur bei ASEQ möglich sein, also nach Kanada schicken und zurück?
Viele Grüße aus Bonn
Horst
Also bei mir besteht ein Datensatz (1 Spektrum) schon aus 3653 Wertepaaren, 5 mehr als der Chip Pixel hat(3648).
Damit können Start und Endpunkt nicht einer realen Messung entsprechen. Eher glaube ich, dass hier der Bereich für
das Polynom der Wellenlängen-Umrechnung vorgegeben wird.
3685-33=3652 (pixel0= 1 Wertepaar))=Anzahl der Wertepaare( und entspricht dem Graphikaufbau der x-Achse).
LG
Jürgen
Liebe Kollegen,
neues von ASEQ: Frage nach dem Sinn der blank scans.
Q:>> -What is the purpose of the blank scans?
A:
Dear Horst,
Blank scans are for triggering mode to insert blank scans between real
scans after the triggering event.
Kind regards,
Stas.
Dazu kann ich nur sagen: aha. Achwas!?
LG
Horst
Zitat von: hugojun in Juni 15, 2021, 10:37:35 VORMITTAG
Also bei mir besteht ein Datensatz (1 Spektrum) schon aus 3653 Wertepaaren, 5 mehr als der Chip Pixel hat(3648).
Damit können Start und Endpunkt nicht einer realen Messung entsprechen. Eher glaube ich, dass hier der Bereich für
das Polynom der Wellenlängen-Umrechnung vorgegeben wird.
3685-33=3652 (pixel0= 1 Wertepaar))=Anzahl der Wertepaare( und entspricht dem Graphikaufbau der x-Achse).
LG
Jürgen
Im Datenblatt des TCD1304 wird eine Leseperiode mit 3694 Elementen angegeben , ab Element 32(+0=33)
bis 3648 handelt es sich um ein Signal , 0- 32 und 3648 bis 3694 sind Dummy Signale , Vielleicht hilft das ja weiter.
LG
Jürgen
Hallo Jürgen,
vielen Dank für die Datei, werde ich mir genauestens anschauen. Ich habe den Inhalt schon mal überflogen und bin bei Seite 2, ,,1. Instrument Setup", hängen geblieben. Da wird der Einsatz einer Platte welche das Licht streut, um eine homogene Beleuchtung (Belichtung) zu erreichen, beschrieben. Wird das bei euch auch berücksichtigt ? Eventuell mit dem Kosinus-Korrektor welcher dem Spektrometer beiliegt ? Wobei dieses Bauteil ja wohl eher für die Empfängerseite gedacht ist ...
Was mich interessiert, ist genau jener Fakt, den du beschreibst: ,,Dennoch gestalte sich das aber schwierig, wenn man z.B die Strahlungsleistung die am Objekt einwirkt (unter dem Mikroskop), kennen möchte, ..".
Da bleibt wohl noch einiges zu tun. Hinsichtlich des Mikroskops muß ich allerdings ,,gestehen", dass dies aktuell nur Gedankenspiele sind, da für ein Mikroskopspektrometer mindestens noch das gesamte Blendenmaterial (Meßfleckeinstellung und Beobachtung desselben) und die Ein- und Auskopplung fehlt. Wie ich kürzlich gesehen habe, hat sich z.B. Horst schon vor längerer Zeit mit einem Mikroskop-Spektrometer https://www.mikroskopie-forum.de/index.php?topic=15053.msg116026#msg116026 beschäftigt. Allerdings liest es sich für mich so, dass auch du an einem Mikroskop-Spektrometer werkelst ...?
,,Im Datenblatt des TCD1304 wird eine Leseperiode mit 3694 Elementen angegeben , ab Element 32(+0=33) bis 3648 handelt es sich um ein Signal , 0- 32 und 3648 bis 3694 sind Dummy Signale , Vielleicht hilft das ja weiter."
Vielen Dank Jürgen, dass wir jetzt eine Erklärung für den ,,leeren" 12nm-Bereich zu haben, ich finde es immer gut, über etwas Hintergrundwissen zu verfügen. Müsste Horst nur noch die Parameter finden, welche die ,,tot-Werte" übernehmen.
Savitzky-Golay-Glättung
Zu diesem Punkt hatte sich Horst schon geäußert, in der Tat verwende ich obige Glättung nur für Spektrenbanden die sehr, sehr gauß-förmig daherkommen. Für meine Präparate aus dem organischen Bereich genau das Richtige. Die ,,Horst'schen –Peaks", aus anorganischer Quelle, finden die SG-Variante nicht so angenehm, und gehen bei Anwendung ja auch prompt ein ;).
Viele Grüße aus Berlin
Michael
Hallo Horst,
danke für die Hinweise zur Stabilität der Lichtquellen, da hast du wohl absolut recht.
,,... ein Coherent-Lasermeßgerät ähnlich wie in Deinem Link habe ich hier zum Spielen (Coherent FieldMaxII), halte Gerät und Methode mit vielen, vielen Spektralfiltern (weil man viele Meßpunkte braucht) aber für ungeignet: es müßte kalibriert sein, Filter sind teuer, ...,,
Die Kalibrierung des/der Sensors/en sollte eigentlich gegeben sein, denn sonst wäre das Gerät wenig sinnvoll. Allerdings hast du recht, es müsste natürlich ein Prüfprotokoll vorliegen, um sicher zu sein. Da ich die Möglichkeit habe, zwei Geräte (besser gesagt, zwei Sensoren), zweier Hersteller (Coherent und Thorlabs) gegeneinander antreten zu lassen, wurde dies mal an einem Laser (633nm, ca. 40 mW) durchgeführt. Leider hatte ich dabei schon eine Abweichung von ca. 16 Prozent. Somit widerspreche ich eigentlich meinen eigenen Eingangsworten zur Kalibrierung. Hinsichtlich der Anzahl der Messpunkte (die Sache mit den Filtern) hatte ich im Detail noch nicht überdacht. Ich habe auch nicht so viele Filter um mehr als 8 Punkte hinzubekommen. Gut, man könnte, so Metallinterferenzfilter vorausgesetzt, durch Kippen der Filter die ,,Anzahl der Wellenlängen" etwas erweitern. Was wäre denn von einem Gitter zu halten ? Die Monochromasie wäre per Spektrometer kontrollierbar und über einen Spalt einstellbar und die Leistung/nm bzw. Leistungsdichte /nm (im uW-Bereich) dann mit dem Leistungsmessgerät zu ermitteln.
Was mich fasziniert, ist dein aktueller Plan: ,,ich habe eine Ocean Optics DH-mini hier, ..." An den Details deines Planes wäre ich interessiert, da ich ein Ocean Optics - DH-2000-S-DUV-TTL habe.
Hinsichtlich des Austauschs am LR1 habe ich eher an den AD-Wandler gedacht, von 14 auf 16Bit, die CCD's (TCD1304DG) sind in allen Geräten doch gleich, oder ? Parallel denke ich über die Nachrüstung mit dem Peltier-Element nach. Das scheint ja, lt. Darstellung auf der ASEQ-Homepage, auf alle Fälle nachrüstbar zu sein.
Viele Grüße aus Berlin
Michael
Hallo Michael,
"Die Kalibrierung des/der Sensors/en sollte eigentlich gegeben sein, denn sonst wäre das Gerät wenig sinnvoll."
Einspruch, solange man Absorption mißt, braucht man nur die Wellenlängenkalibrierung. Für den hier im Forum oft gemachten Vergleich verschiedener LEDs dagegen dürfte die radiometrische Kalibrierung aber erforderlich sein.
Die Hersteller machen das nicht, weil ja die vorgeschalteten Einheiten wie Glasfaser, Cosinus-Korrektor etc. ja auch ihre spektralen Absorptionen haben, die dann aber vom Kunden zu korrigieren wären. Deshalb bieten die ihre teuren Referenzlampen an.
Seit einigen Tagen habe ich das Problem hier aber gelöst. Ich habe von unserer Physik die Korrekturdaten erhalten, entstanden durch Messung der erwähnten Ocean Optics-Lampe mit einem kalibrierten Spektrometer von Thorlabs. Die Messungen der Physik an verschiedenen anderen unkalibrierten Spektrometern zeigen erstaunliche Unterschiede, bedingt durch unterschiedliche Sensoren. Das zeigt Dein Vergleich zwischen Coherent und Thorlabs bei 633 nm ja auch sehr schön.
Leider nützt es nichts, die Korrekturdaten weiterzugeben, weil die wie oben erwähnt sehr individuell sind, bei mir z.B. nur für den Spektrometereingang gelten.
Nach Einprogrammierung der Korrektur sehen auch die Glühlampenspektren viel besser aus, jetzt mit Intensität in nW/nm.
Ich bin dabei, das mal zusammenzufassen und mit mit einigen Meßbeispielen auf unserer Webseite zu bringen, ist für das Forum etwas zu umfänglich.
Leider zeigen die Daten auch, daß eine Kalibrierung bei einer Wellenlänge (also Dein 633-nm-Laser) nichts nützt; Du brauchst eine Reihe von Stützpunkten im Langwelligen, die geringe Änderung durch Filterkippen bringt nichts, die Punkte liegen zu nahe beieinander. Selbst die Ocean-Optics DH 2000 ist nicht brauchbar, solange nicht die spektralen Daten dafür bekannt sind. Ein weiterer Haken ist die Alterung der Lampe, deshalb hat unser Physiker die Kalibrierung über das Spektrometer gemacht. Abweichungen von 10 % von der Theorie kann man wohl getrost erwarten.
Nachrüstung LR1: A/D-Wandler: geht nur mit neuer Platine von ASEQ. Peltier-Element: auch das geht nicht ohne größeren Umbau, der Sensor ist ja fest mit dem Peltier verbaut, wegen der Kondensationsgefahr. Neukalibrierung der Wellenlänge usw. ist ja klar, da hat Jürgen Erfahrung. Du wolltest doch mal bei ASEQ nachfragen?
Der Link zu meinem Forumsbeitrag ist veraltet. Der neueste Stand ist auf unserer Webseite: http://www.mikroskopie-bonn.de/bibliothek/mikroskopische_technik/192.html.
Zu guter Letzt: "Die ,,Horst'schen –Peaks", aus anorganischer Quelle, finden die SG-Variante nicht so angenehm, und gehen bei Anwendung ja auch prompt ein ;)."
"Prompt eingehen" heißt? Habe nur Überschwinger.
Viele Grüße
Horst
Hallo Horst , Hallo Michael,
als Horst seinen Beitrag verfasst hat, bin ich noch in den Nordseewellen der Normandie geschwommen. Bei auflaufender Flut nimmt das Wasser die Wärme des Strandes auf und so hat es herrliche 19°C.
@ Michel.
,,Hinsichtlich der Anzahl der Messpunkte (die Sache mit den Filtern) hatte ich im Detail noch nicht überdacht..."
Recht einfach und ohne viel Aufwand habe ich mit den 8 folgenden Stützpunkten ganz gute Erfahrung gemacht:
Die ersten 5 stammen von einer Entladungs- Sparlampe 365nm, 402nm, 435nm, 542nm, 611nm und sind sehr markant.
Für den roten Bereich nutze ich dann noch Kaminzündhölzer ,,K" Linie 766nm, 769nm und
eine KFZ-Xenon Lampe z.B.: Xe D2 BMW für 823nm.
Aber Achtung: Die Zündhölzer und die Xenon Lampe müssen im Moment der Zündung bzw.
des Einschaltens aufgenommen werden, da die Linien danach gänzlich verschwinden.
Allerdings liest es sich für mich so, dass auch du an einem Mikroskop-Spektrometer werkelst ...?
Jain: Eigentlich ging es mir immer um die Analyse des Lichts unter Nutzung von Polfilter in Kombination mit Kipp-Kompensatoren , da man so schön die Wirkung der kompensierten Wellenlänge auf das Farbresultat quantitativ auswerten kann. Feste Kompensatoren wie RotI oder λ/4 haben nicht immer genau die gleichen Wellenlängen. Das ist aber bei Anwendungen in der Reflexion-Messung an anisotropen, stark absorbierenden Kristallen wichtig zu wissen.
Gelegentlich habe ich auch mal direkt an einem Dünnschliff ein opaques Mineral gemessen. Die Anforderungen an die Präparierung einer Messoberfläche sind aber anspruchsvoll.
Meine Objekte enthalten meistens gediegenes Eisen. Mit eine S/W Kamera kann ich dann die Grauwerte der angrenzenden Minerale gegen die des Eisens ,,kalibrieren".
Leider kann ich von hier aus dem Urlaub nicht mit Beispielen dienen.
LG aus der Normandie
Jürgen
Hallo Jürgen,
das ist ein Mißverständnis:
was Du meinst, ist die Wellenlängenkalibrierung. Im Beitrag vorher ging es aber um die radiometrische Kalibrierung, also um die Korrektur der wellenlängenabhängigen Empfindlichkeit des Sensors.
Viele Grüße
Horst
Up's
Da hab ich wohl noch Salz in den Augen gehabt und das beim überfliegen auf dem Handy übersehen.
LG
Jürgen
Hallo Horst,
Asche auf mein Haupt, da hat es doch etwas länger gedauert eine Antwort zu formulieren. ;D
Danke, für den Link zur Beschreibung deines Mikroskop-Spektrometers. Die Sache mit dem Messpunkt-Laser ist mir verständlich, allerdings nicht die technische Realisierung.
Hinsichtlich der Aufrüstung des LR1-14 Bit habe ich folgende Antwort erhalten:
"Dear Michael, We can replace electronics (225usd). TEC has to be replaced as well (375usd). Total 600usd+shipping. Kind Regards, Stas"
Da kommt noch einmal zusätzlich "Shipping" hinzu, und der Zoll möchte u.U. auch noch ein kleines Salär. Obwohl Firmen (auch Privatleute ?) wohl die Möglichkeit haben, auf Antrag, bei Reparatur oder/und Aufrüstung, Geld beim Zoll sparen zu können.
Inzwischen ist mir aber bei Ebay ein Zeiss-MCS über den Weg gelaufen, da bin ich schwach geworden ...
Viele Grüße aus Berlin,
Michael