Bestimmung von Komplexzusammensetzung und Komplexkonstante unter Nutzung der Dual-Wavelength Photometrie

[mgritsch]

Output is automatic when the key is pressed and auto-print (in Preferences) is on. If auto-print is off, results can be printed on demand using the . key".
Zumindest könnte man dann diese Daten am PC abgreifen. Inwieweit sich das lohnt -

Wow, danke für den Hinweis
Probieren kann man alles mal, wenngleich ich mir da wenig Hoffnung mache. Output to Printer erzeugt AFAIK die gleiche pixelige Grafik wie am Display, bloß auf Papier. Die kann ich nicht wirklich verwerten.

Spannend wären die Tabellen mit Wellenlänge / Absorption die man den Screenshots nach in der Software bekommen kann. Dann kann man auch in Ruhe später Auswerten, mehrere Spektren übereinander plotten, isosbestische Punkte ermitteln, usw usf. Aber ist klar dass das eine komplexere Datenstruktur ist die wohl nicht so leicht herauszukitzeln ist wenn man nicht die genauen steuerbefehle kennt.

[MiR1]

Output is automatic when the key is pressed and auto-print (in Preferences) is on. If auto-print is off, results can be printed on demand using the . key".
Zumindest könnte man dann diese Daten am PC abgreifen. Inwieweit sich das lohnt -

Wow, danke für den Hinweis
Probieren kann man alles mal, wenngleich ich mir da wenig Hoffnung mache. Output to Printer erzeugt AFAIK die gleiche pixelige Grafik wie am Display, bloß auf Papier. Die kann ich nicht wirklich verwerten.

Spannend wären die Tabellen mit Wellenlänge / Absorption die man den Screenshots nach in der Software bekommen kann. Dann kann man auch in Ruhe später Auswerten, mehrere Spektren übereinander plotten, isosbestische Punkte ermitteln, usw usf. Aber ist klar dass das eine komplexere Datenstruktur ist die wohl nicht so leicht herauszukitzeln ist wenn man nicht die genauen steuerbefehle kennt.

Wie gut (mit wieviel DPI) man die Grafik in den PC umleiten kann, hängt ja von der Software im Messgerät ab. Wenn es (virtuell) so ähnlich ausieht wie in den Abbildungen, dann bringt es sicherlich nix. Da ist abfotografieren und digitalisieren der Fotos sicherlich der einfachere Weg. Ohne Frage kann dies nur eine Hilfslösung sein, die Auflösung der echten Daten wird man, selbst im besten Fall, nie erreichen.

Allerdings frage ich mich was folgende Aussage bedeutet (ebenfalls S. 15 im Kapitel "Output to Printer"):
"Text printer (no graphics) (3)
Use for any class of parallel printer; no graphics or accents on text are printed."

So richtig verstehe ich den Satz nicht, aber man könnte es dahingehend interpretieren, dass dann nur die Daten (anstatt einer Pixelgrafik) gedruckt (bzw. umgeleitet) werden kann. Das wäre dann schon eher brauchbar.

[mgritsch]

[man könnte es dahingehend interpretieren, dass dann nur die Daten (anstatt einer Pixelgrafik) gedruckt (bzw. umgeleitet) werden kann. Das wäre dann schon eher brauchbar.

Das allerdings, wenn dann einfach ASCII Code ausgespuckt würde, das wäre entzifferbar!

[MiR1]

[man könnte es dahingehend interpretieren, dass dann nur die Daten (anstatt einer Pixelgrafik) gedruckt (bzw. umgeleitet) werden kann. Das wäre dann schon eher brauchbar.

Das allerdings, wenn dann einfach ASCII Code ausgespuckt würde, das wäre entzifferbar!

Wenn sich da nichts geändert hat, was ich mir logisch auch nicht erklären könnte, war/ist das der kleinste gemeinsame Nenner von Druckern. Zumindest bei HP- und Epson-Druckern kenne ich das aus persönlicher Erfahrung. Die Grafikbefehle beider Druckerfamilien unterscheiden sich da dagegen schon ganz erheblich.
Wie es scheint, kann man wohl zwischen Grafikausgabe und Textausgabe auswählen, wenn man dem (französischsprachigen) Beitrag auf Youtube zu dem Spektrometer verfolgt. Allerdings musste ich hier mehr raten, da ich die Sprache nicht beherrsche. Da sich ja ein solches Gerät in deinem Dunstkreis befindet, wirst du es ja sicherlich wissen ... .-)

[mgritsch]

Da ich die Frage hier aufgeworfen habe auch mal hier die Lösung:
Das Ultrospec 2100 pro kann mit einem Nullmodemkabel (gekreuzt!) problemlos ausgelesen werden.
Zuerst am Gerät: System → Preferences → Printer → „Text printer (no graphics)” und Autoprint aktivieren. Das sorgt dafür, dass alle Werte direkt auf die Serielle Schnittstelle geschrieben werden. Einzelne Absorbance-Werte könne auch ohne Autoprint durch Drücken der "." Taste ausgegeben werden.

Parameter für die Kommunikation:
Port /dev/ttyUSB0
Baudrate 19200 bps
Datenbits 8
Parität None
Stopbits 1
Flow Control keine Hardware-Handshake-Leitungen → rtscts=False, xonxoff=False
Ende-Zeichen beim Senden CR (\\r)
Antwortende CR LF (\\r\\n)

Damit kann man sich "live" die Daten liefern lassen, zB bei einer Aufnahme des Spektrums:

2025-10-27 16_56_36-Raspi (WayVNC) - RealVNC Viewer.png (62.34 KiB) 515 mal betrachtet

Eine Python-Applikation zum speichern/visualisieren folgt ASAP
Das Ansteuern des Geräts über Befehle scheint nicht möglich zu sein, eine Vielzahl "Üblicher Verdächtiger" hat das Gerät nicht verstanden. Aber das macht nichts, die Bedienung über das Display ist in Ordnung.

Aber jedenfalls die Zeiten abfotografierter LCD Screens sind vorbei!

[mgritsch]

E voila, hier die erste Version der Software:

Zu sehen sind die Spektren einer Glasküvette (schwarz) und einer PS-Küvette (blau) gegen eine Quarzglas-Küvette

[MarbsLab]

Das Ansteuern des Geräts über Befehle scheint nicht möglich zu sein, eine Vielzahl "Üblicher Verdächtiger" hat das Gerät nicht verstanden.

Um da weiterzukommen, bräuchte man zunächst den Schaltplan des Geräts. Dann könnte man sich anschauen, welche Art von Kommunikation zwischen der Eingabe und dem Microcontroller des Geräts stattfindet. Wenn es nicht über Serial läuft, wird's schwierig. Dann müsstest du voraussichtlich die Hardware modifizieren (Datenleitungen und GND einlöten und nach außen führen) und dir mittels eines Logic Analyzers anschauen, was da vor sich geht. Wenn das verstanden ist, könnte man ein entsprechendes Programm für den Raspberry Pi schreiben (oder schreiben lassen ).

[mgritsch]

Um da weiterzukommen, bräuchte man zunächst den Schaltplan des Geräts. Dann könnte man sich anschauen, welche Art von Kommunikation zwischen der Eingabe und dem Microcontroller des Geräts stattfindet. Wenn es nicht über Serial läuft, wird's schwierig. Dann müsstest du voraussichtlich die Hardware modifizieren (Datenleitungen und GND einlöten und nach außen führen) und dir mittels eines Logic Analyzers anschauen, was da vor sich geht.

oh my god, overkill

Der Kollege meinte die proprietäre Software kann das Gerät (über serial) ansteuern aber benutzt vermutlich proprietäre (binäre?) Steuerbefehle, kein ASCII. Auf jedes plausible ASCII Input kam nur ein "Kommando nicht verstanden" zurück. ASCII ist nur der Output auf den "Printer". Die einzige Chance das nachzustellen wäre wenn man die Software hat und mitschnüffelt was da geschickt wird. Hardware-Modifikationen sind da mal ganz weit weg, ich werde nicht ein top funktionierendes Gerät riskieren nur um zu erreichen dass ich mit der Maus am Bildschirm klicke statt am Touchpad auf "Run" zu drücken (oder aus dem Menü eine Applikation und Parameter zu wählen.) Das hat keinen Mehrwert

[MarbsLab]

(binäre?) Steuerbefehle, kein ASCII.

Alle gängigen Kommunikationen sind binär . ASCII ist auch binär. Jedes ASCII-Zeichen kann ich dezimal, hexadezimal oder binär darstellen. Wenn die Kommunikation zwischen HMI und Microcontroller auch über Serial läuft, müsste man nur an den Rx-Pin herankommen und könnte über den Serial monitor sehen, was da gesendet wird, wenn man verschiedene Tasten drückt. Da es dir aber sowieso mehr auf eine erweiterte Auswertung ankommt, was auch das Wichtigste ist, ist es vermutlich die Mühe nicht wert.

[mgritsch]

Alle gängigen Kommunikationen sind binär . ASCII ist auch binär.

Spitzfindigkeit ASCII ist binär, aber nicht jedes Binär ist ACSII auch wenn man jeden Datenstrom natürlich willkürlich in 8-bit Stücke hacken und zum ASCII erklären könnte.
Mit den 255 ASCII Zeichen gibt es vermutlich mehr Steuerbefehle als das Ding braucht, vielleicht haben sie ja eine 7 oder 6 bit Logik? Und wenn ein Befehl lauten sollte: "AZcXT3/Sd35Adpu&" dann mag das zwar auch ASCII sein aber ist halt nicht sowas wie "WAVELENGTH". Diese letztere Art von ASCII-Befehlen war gemeint und da hat das Gerät nur einen einzigen verstanden und beantwortet, das war "ID?" darauf antwortet er brav mit der Versionsnummer der Firmware (was zumindest mal grundsätzlich bestätigt dass es keine one-way-Schnittstelle ist). An die 100 andere "Verdächtige" wurden nur mit "E91 Not recognised" beantwortet (sowie mit dem Zusatz "HEX:453931204e6f74207265636f676e697365640d0a" was das gleiche in HEX bedeutet, somit wissen wir zumindest dass er auch HEX spricht).

[MarbsLab]

vielleicht haben sie ja eine 7 oder 6 bit Logik?

Der Schaltplan wäre wirklich interessant. Anhand dessen könnte man evtl. mehr über das Kommunikationsprotokoll zwischen dem Interface und dem Controller erfahren (z. B. bei der Verwendung von 8-Bit-Parallel-Load- oder Serial-In-Schieberegister). Ein 7-Bit-System kann \(2^7=128\) verschiedene Kombinationen darstellen, bei 8-Bit wären wir bei einem Byte, also 256 (und nicht 255 Kombinationen. In der Programmierwelt ist alles null-terminiert.) mögliche Kombinationen usw. Wenn man die Kombinationsmöglichkeiten des Interfaces hätte, könnte man daraus auch Rückschlüsse ziehen. ASCII ist eigentlich ein 7-Bit-Zeichencode (Bit mit der niedrigsten Wertigkeit ist immer Null, kann man weglassen). Nur der erweiterte ASCII-Codes (128-255) ist 8-Bit, glaube aber nicht, dass diese Sonderzeichen Verwendung finden. Die ersten 32 Zeichen der ASCII-Tabelle sind nicht druckbar. Sie werden verwendet, um Peripheriegeräte wie Drucker zu steuern. Diese können wir auch erstmal außenvorlassen.

PS:

und da hat das Gerät nur einen einzigen verstanden und beantwortet, das war "ID?"

Ich wäre sehr vorsichtig mit dem Senden von Befehlen (sind doch Spitzfindigkeiten, ich probier' mal "Erase" .) Mit etwas Pech erwischt du einen, der das Spektrometer in einen Mode versetzt, in den du es nicht haben willst, und aus dem es auch nicht mehr herauskommt, ohne den entsprechenden Befehl zu kennen (z. B. Service-Mode, Software-Update-Mode, etc.).

[mgritsch]

Mit etwas Pech erwischt du einen, der das Spektrometer in einen Mode versetzt, in den du es nicht haben willst, und aus dem es auch nicht mehr herauskommt, ohne den entsprechenden Befehl zu kennen (z. B. Service-Mode, Software-Update-Mode, etc.).

Sehr berechtigte Bedenken.

Die Tests erfolgten mit typischen SCPI Befehlen oder bekannten an SCPI angelehnten Varianten. „ID?“ war fast ein Zufallstreffer da andere Geräte angeblich dafür „IDN?“ nutzen.

Wenn ich mir die Tastatur-Bedienung ansehe - hier gibt es nur einen Zahlenblock 0-9 mit . und Backspace sowie die Run und Stop Tasten, insgesamt also 14. Alle Elemente werden durch Auswahl der Menü-Nummer aufgerufen, Texteingabe ähnlich wie bei den alten Nokias durch Mehrfach-Drücken einer Zahlentaste.

Ich habe daher einen Verdacht, dass man keine Befehlssprache implementiert hat sondern nur mit 4 Bit/einfachen Hex-Codes 0-F die den Tastaturbelegungen entsprechen alles steuern kann. Um Menü 1, Unterpunkt 1 aufzurufen muss ich nur 1,1 (HEX) schicken. Das ist aber nicht das was ankommt wenn ich als ASCII „1,1“ sende. „ID?“ dürfte der einzige ASCII Befehl sein den er versteht. Ich hoffe das macht klar was mit „binär“ gemeint war Und nein, auf der Ebene möchte ich aus den von dir genannten Gründen lieber nicht im Blindflug experimentieren…

[MarbsLab]

Um Menü 1, Unterpunkt 1 aufzurufen

Könnte durchaus sein (und halte ich für am wahrscheinlichsten), dass die Tasten direkt vom Controller ausgelesen werden (über einen digitalen Eingang wird im Zeitmultiplexverfahren bzw. durch eine Tastenmatrix nur geprüft, ob eine bestimmte Taste auf high oder low liegt) und es zwar eine serielle Eingabe gibt (über den Rx-Pin des Controllers, der Tx-Pin dient der Ausgabe), die aber nur dem Service-Techniker vorbehalten ist und lediglich ein paar Befehle umfasst. Ohne Schaltplan fischen wir da leider im Trüben.