Thermal Imaging... Ein paar Fragen:

[Quantasy]

Ich wollte da was implementieren und bin über ein paar Unklarheiten gestolpert:

1. Doku zu den Auflösungen: 

    -10°C to 140°C mit einer Auflösung von 0.01°C

    -10°C to 450°C mit einer Auflösung von 0.1°C

  API zu den Auflösungen:

    von 0 bis 6553 Kelvin (-273,15°C bis +6279,85°C) mit 0,1°C Auflösung

    von 0 bis 655 Kelvin (-273,15°C bis +381,85°C) mit 0,01°C Auflösung

 

Was würde denn da nun stimmen? (Ich tippe auf das API ;-)  )

 

2. Da gibt es zwei Listener:

  BrickletThermalImaging.TemperatureImageLowLevelListener

  BrickletThermalImaging.HighContrastImageLowLevelListener

 

Gehe ich recht in der Annahme, dass wir 'Normalos' diese nicht nutzen sollen, da sie die gleiche Dokumentation aufweisen wie die 'non-LowLevel' Pendants? Oder würden die uns mit diesen 'Chunks' was spezielles bieten?

 

 

[borg]

Ich wollte da was implementieren und bin über ein paar Unklarheiten gestolpert:

1. Doku zu den Auflösungen: 

    -10°C to 140°C mit einer Auflösung von 0.01°C

    -10°C to 450°C mit einer Auflösung von 0.1°C

  API zu den Auflösungen:

    von 0 bis 6553 Kelvin (-273,15°C bis +6279,85°C) mit 0,1°C Auflösung

    von 0 bis 655 Kelvin (-273,15°C bis +381,85°C) mit 0,01°C Auflösung

 

Was würde denn da nun stimmen? (Ich tippe auf das API ;-)  )

Das hatte uns erst selbst ein wenig durcheinander gebracht. Die Spezifikation von Flir gilt für den kleinen Bereich (-10°C bis 140°C/450°C). Die API läuft über den kompletten uint16 Bereich mit der 0,1°/0,01°C Auflösung. D.h. bei Temperaturen über 140°C solltest du bereits in den 0,1°C-Auflösung Modus wechseln.

 

Im Brick Viewer verwenden wir aktuell den größeren Bereich, was sicherlich verwirrend ist. Ich hatte das im git schon geändert.

 

2. Da gibt es zwei Listener:

  BrickletThermalImaging.TemperatureImageLowLevelListener

  BrickletThermalImaging.HighContrastImageLowLevelListener

 

Gehe ich recht in der Annahme, dass wir 'Normalos' diese nicht nutzen sollen, da sie die gleiche Dokumentation aufweisen wie die 'non-LowLevel' Pendants? Oder würden die uns mit diesen 'Chunks' was spezielles bieten?

 

Die werden intern für die "Streaming-Listener" verwendet. Also wenn du den HighContrastImageListener verwendest werden intern die Daten eines ganzen Bildes in mehreren Chunks mit je 64 Bytes abgefragt und am Ende zusammengestellt. Diese Chunks kannst du auch selbst abfragen und zusammenstellen, einen Mehrwert sehe ich da allerdings nicht.

[Quantasy]

Danke für die Antworten!

Das mit den Chunk-Listenern habe ich verstanden, ist abgehakt.

 

 

Das mit den Temperaturen... alleine ein Blick in den Hauseigenen Tiefkühler verrät, dass die Temperatur tiefer als -10°C gemessen werden kann.(ca. -23°C)

Aus Deinem Post entnehme ich aber, dass der 'kleine' Bereich nur runter auf -10°C (263.15K) gehen soll?!

Die Spezifikation von Flir gilt für den kleinen Bereich (-10°C bis 140°C/450°C).

Ich werde nächste Woche mal mit flüssigem Stickstoff messen und mitteilen, ob die FLIR bis 'runter' 'sieht'...

 

Nun habe ich aber noch eine neue Frage:

Wie kann das Bricklet wieder 'abgeschaltet' werden, wenn es im Callback-Modus war (IMAGE_TRANSFER_CALLBACK_HIGH_CONTRAST_IMAGE)?

Ich dachte, ein Wechsel auf MANUAL (IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE) würde das Bricklet wieder 'zum Schweigen' bringen... aber das blinkert lustig weiter und auch die Callbacks kommen weiterhin!?

 

Ich möchte ja nur programmatisch das Bricklet stoppen (nicht resetten), damit die Kamera geschont und die Bandbreite wieder 'frei' wird. Hab ich was übersehen?

[borg]

Wie kann das Bricklet wieder 'abgeschaltet' werden, wenn es im Callback-Modus war (IMAGE_TRANSFER_CALLBACK_HIGH_CONTRAST_IMAGE)?

Ich dachte, ein Wechsel auf MANUAL (IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE) würde das Bricklet wieder 'zum Schweigen' bringen... aber das blinkert lustig weiter und auch die Callbacks kommen weiterhin!?

Huch? Das muss ich testen, du solltest keine Callbacks mehr bekommen wenn du auf "manual" umstellst. Komme ich aber frühestens Montag zu.

[borg]

Konnte das gerade doch kurz testen und bei mir funktioniert alles so wie es soll.

 

Habe den Brick Viewer gestartet und dann folgendes ausgeführt:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

HOST = "localhost"
PORT = 4223
UID = "D1H" # Change XYZ to the UID of your Thermal Imaging Bricklet

from tinkerforge.ip_connection import IPConnection
from tinkerforge.bricklet_thermal_imaging import BrickletThermalImaging

# Callback function for high contrast image callback
def cb_high_contrast_image(image):
    print("cb")

if __name__ == "__main__":
    ipcon = IPConnection() # Create IP connection
    ti = BrickletThermalImaging(UID, ipcon) # Create device object

    ipcon.connect(HOST, PORT) # Connect to brickd
    # Don't use device before ipcon is connected

    # Register high contrast image callback to function cb_high_contrast_image
    ti.register_callback(ti.CALLBACK_HIGH_CONTRAST_IMAGE, cb_high_contrast_image)

    # Enable high contrast image transfer for callback
    ti.set_image_transfer_config(ti.IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE)

    raw_input("Press key to exit\n") # Use input() in Python 3
    ipcon.disconnect()

 

Der Brick Viewer nutzt das High Contrast Image im Callback-Modus. Wenn ich die "set_image_transfer_config"-Funktion auskomentiere und das Skript ausführe läuft im Brick Viewer alles weiter und ich bekomme "cb" Prints über den Callback (welcher vom Brick Viewer gestartet wurde). Wenn ich die Funktion drin lasse und dadurch die Config auf "manual" umstelle bleibt das Bild im Brick Viewer stehen und ich bekomme auch keine Prints. Die LED hört auch auf zu blinken.

[Quantasy]

Wuups!

Sorry, ja, das funktioniert genau so wie borg es sagt und getestet hat!

Ich nehme alles zurück bezgl. 'kann nicht stoppen' und unterstütze das Gegenteil: Es stoppt.

Tschuldigung 

[Quantasy]

Wir konnten Messungen mit flüssigem Stickstoff machen und die Werte mit einer FLIR-für Smartphones und zwei Thermal-Imaging Bricklets vergleichen.

 

Unsere ersten (nicht ganz wissenschaftlichen) Tests ergaben, dass sich die Sensoren in diesen tiefen Temperaturen nicht so ganz einig sind und statt der 77.355K ​(−195.795°C) Werte bis zu 0K (-273.15°C) anzeigten.

Also eine Abweichung von bis zu 80K aufweisen, wobei die Streuung der einzelnen Messwerte pro Sensor (positiv) überraschend gering war.

 

Je näher wir bei der Erwärmung der 300K Marke kamen desto genauer wurden die Sensoren, mit einer Abweichung untereinander von nur noch ca. 1-2K.

Höhere Temperaturen haben wir bisher nicht so getestet, werden wir aber noch machen.

 

Frage: Gäbe es eine Möglichkeit, eine 'lineare Eichung' oder gar eine Eichtabelle ins Bricklet zu schreiben (so ähnlich wie bei der LoadCell)?

 

Disclaimer: Diese Erkenntnisse sind nicht wissenschaftlich fundiert und die Abweichungen können auch durch einen falschen Testaufbau entstanden sein.

[borg]

Ich befürchte das ist nicht möglich. Der Prozessor den wir verwenden läuft mit 32MHz, wir sprechen mit dem Lepton mit 8MHz.

 

D.h wir haben 4 Prozessortakte pro Bit an Daten zur Verfügung. Damit müssen wir das Protokoll mit dem Lepton sprechen, die Daten Zwischenspeichern, API-Aufrufe abarbeiten, das Protokoll mit dem Brick sprechen und I2C mit dem Lepton zur Konfiguration, etc.

[Quantasy]

Ok, ich seh's, da wird dann die Luft bzw. die verfügbaren Takte knapp...

 

Dann wird die Eichung und die daraus erstellte Tabelle wohl in die "Business-Logik" einfliessen müssen.

 

Danke für die Erklärungen!

[developer]

Ich greife es hier nochmal auf:  wären also Temperaturmessungen mit dem Thermal Imaging Bricklet ausserhalb des angegebenen Temperaturbereiches (-10 bis 450 Grad) trotzdem mit einer Kalibrierung und Korrektur durchführbar oder ist es dann völlig ungenau ?

Anwendungsfall: Laser-Schweissen mit dem Thermal Bricklet beobachten und einigermassen verlässlich die Schweisspunkttemperatur messen ?

 

Mich würde auch sehr interessieren was "Quantasy" hier herausgefunden hat. 

[Quantasy]

Wie bereits beschrieben, haben wir nur einen ersten Test im tieftemperatur Bereich gemacht und festgestellt, dass der Sensor (für sich) scheinbar* nicht Akkurat ist.

*(Scheinbar deshalb, weil wir das bloss mit zwei Sensoren gemacht haben und der Versuchsaufbau nicht reproduzierbar (mal schnell auf dem Labortisch) war.)

 

Was wir noch nicht wissen ist, wie präzise der Sensor in den extremen Bereichen ist.

<Traum>

Falls er präzise genug ist, können wir mit Hilfe einer Korrekturtabelle (wahrscheinlich pro Sensor und Sensortemperatur) die 'Accurarcy' so weit erhöhen, dass die Messungen über einen grösseren Bereich nutzbar werden.

</Traum>

 

<Realität>

'Leider' haben die Vorlesungen wieder begonnen und wir können erst wieder in der vorlesungsfreien Zeit (ab Mitte Juni) mit praktischen und !nachvollziehbaren! Experimenten an das Thema herangehen.

</Realität>

<Klinkenputz>

Natürlich wären wir jederzeit für ein finanziertes Forschungsprojekt zu haben, denn so können wir uns von den Vorlesungen 'freikaufen'.

</Klinkenputz>

 

@Developer:

Wir wollen also genau Deine Fragestellung auch geklärt wissen...

Geduld oder Geld... wir arbeiten dran und teilen die Erkenntnisse auf jeden Fall mit. :-)