Hauptmenü

ASEQ-Spektrometer

Begonnen von Horst Wörmann, Mai 18, 2021, 17:55:49 NACHMITTAGS

Vorheriges Thema - Nächstes Thema

Horst Wörmann

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

MiR

#16
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 

Horst Wörmann

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

MiR

#18
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

 

Horst Wörmann

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


hugojun

#20
Hallo Horst ,
zu den Punkten  Antwort #18:
3 – 6 die Werte ,
wenn eine Kalibrierung durchgeführt wurde .



LG
Jürgen

Horst Wörmann

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

hugojun

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

Holger Adelmann

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

Horst Wörmann

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

Horst Wörmann

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

Holger Adelmann

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

Horst Wörmann

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

MiR

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



 


hugojun

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" .




LG
Jürgen