borg

Hallo, Der eigentliche Algorithmus ist leider proprietär, wir können also nicht genau sagen wie der IAQ Index berechnet wird. Bosch schreibt dazu: Sprich das funktioniert darüber das der Chip davon ausgeht das er in einem gegebenem Zeitraum sowohl gute als auch schlechte Werte sieht. Wenn ein die Luftqualität über einen langen Zeitraum gleich bleibt, wird die Genauigkeit über die Zeit wieder schlechter (so ist meine Vorstellung davon). In unseren Tests funktioniert das als Indikator zum lüften allerdings sehr gut. Wenn der Laser-Cutter bei uns längere Zeit an ist schießt der Wert nach oben (trotz professioneller Lüftung im Laser-Cutter). Wenn wir dann lüften geht der Wert wieder nach unten. Alternativ wenn der Laser-Cutter nicht an ist und wir sitzen hier mit 4 Leuten in einem Raum geht der Wert innerhalb eines Tages auch Stück für Stück nach oben bis man wieder lüftet etc. In der Tat, das ist so gebaut. Es werden die ersten 50 Werte genommen. Ein Bar-Graph wo die "Bars" in jedem Pixel gezeichnet werden ist das gleiche wie der Line-Graph, nur ausgefüllt unten. Daher hatten wir die Idee da jeweils eine Lücke zu lassen um eichte "Bars" darzustellen.

Muss ich mir angucken, klingt aber in der Tat nach einem off-by-one irgendwo. Komme ich womöglich erst morgen zu.

Der Temperaturoffset den du setzt wird in die Luftfeuchte und IAQ Index berechnet genutzt.

Mmmh, wir haben da versucht die Oberfläche oben komplett glatt zu halten. Was ich mir vorstellen könnte, jetzt wo ich drüber Nachdenke: Man könnte 3 runde Platten Lasern. Dabei ist die obere ohne Loch, die mittlere mit großen Loch und die untere mit kleinem Loch. Sodass man die unterste festschrauben kann und dann alle drei aufeinander kleben. Dann hat man natürlich einen ziemlich dicken Teller .

Der Sensor auf dem Air Quality Bricklet (und auch der auf dem Humidity Bricklet 2.0) haben leider was die Hersteller "self-heating" nennen. D.h. die eigentliche Abfrage der Werte führt zu Erhitzung des Sensors. Mit der maximalen Abtastrate von 1Hz hatten wir eine Selbsterhitzung von ~3°C festgetellt und mit einer Rate von 0,33Hz von 0,5°C. Wir hatten uns dann dazu entschieden die Rate von 0,33Hz zu nehmen und 0,5°C fest in die Firmware einzubauen. Bei deinen Tests scheint der Wert allerdings um erheblich mehr als die 0,5°C zu steigen! Ich werde nächstes Jahr nochmal ein paar Air Quality Bricklets auspacken und die zueinander vergleichen um zu sehen wie unterschiedlich die Selbsterhitzung zwischen den Sensoren ist. Eventuell sollten wir die Abtastrate ähnliche wie jetzt bei dem Humidity Brickelt 2.0 auch einstellbar machen, da hat man dann die meiste Kontrolle darüber.

Anbei eine Testfirmware mit gefixter Kalibrierung. Ist ungetestet, hab gerade kein Air Quality Bricklet in der nähe. Das Release mache ich dann wenn ich das nächste mal wieder in der Firma bin . air-quality-bricklet-firmware.zbin

In der Tat, da hast du einen Bug gefunden .

Der FLIR-Sensor sitzt ja in einem Sockel, hast du schon überprüft ob er eventuell aus dem Sockel gerüttelt ist?

Die WIFI Extension ist als Access Point konfiguriert und dein PC verbindet sich auf diese Access Point und im Brick Viewer nutzt du die IP der WIFI Extension richtig? Das sollte gehen. Oder hast du ein bestehendes Netzwerk in dem sich dein PC befindet? In dem Fall musst du die WIFI Extension als client konfigurieren und sie kann sich mit deinem bestehenden Netzwerk verbinden. Du kannst dich dann mit dem Brick Viewer auf die IP die an die WIFI Extension vergeben wurde verbinden.

Die Daten sehen gut aus. Du kannst das ausgegebene Array in distance_lookup.c als letztes Element des Arrays dort hinzufügen und in distance.h DISTANCE_SENSOR_NUM auf 4 setzen. Vorher einmal nochmal pullen, hab in der communication.c eine kleine Änderung gemacht damit du deinen neuen Sensor-Typ auch per set_sensor_type(3) auswählen kannst. Als Anhang einmal die kompilierte Firmware mit deinen Änderungen. distance-ir-v2-bricklet-firmware.zbin

Deine Analogwerte haben 21 Bit, das Script geht unkonfiguriert von 12 Bit aus. Bitte einmal die neueste Version pullen, ich hab das jetzt klarer gemacht was zu konfigurieren ist. Für deine Datei: # Filename filename = 'DEIN_DATEINAME.txt' # '2Y0A41.txt' / '2Y0A21.txt' / '2Y0A02.txt' # Number of bits of input values ANALOG_BITS = 21

Hier gibt es ein Beispiel dafür: https://www.tinkerforge.com/de/doc/Software/IPConnection_Java.html#enumerate

Das Distance IR Bricklet 2.0 hat genug Flash um die Kalibrierung für alle Sensoren die wir anbieten zu speichern, daher sollte es nicht mehr notwendig sein die Kalibrierung zu ändern. Wenn du eine eigene Kalibrierung benötigst müsstest du die in deinem Programm durchführen.

You can find an example for that here: https://www.tinkerforge.com/de/doc/Software/IPConnection_Delphi.html#enumerate

Das ist gar nicht so schwierig. Du holst dir zuerst per "search_bus" die IDs der ganzen Sensoren: ids = ow.search_bus().identifier Dann kannst du auf die einzelnen Sensoren zugreifen in dem du bei jedem "write_command" die id anstatt 0 überträgst, z.B.: ow.write_command(ids[0], 78)

Wenn ich den RED Brick per USB anschließe und das über den PC laufen lasse komme ich auf ~900 Nachrichten, das könnte man eventuell noch etwas tweaken um auf die vollen 1000 zu kommen. Wenn ich das ganze über einen WLAN-Stick über WLAN mache komm ich auf 600. Wenn ich die record.py auf dem RED Brick ausführe (GPU, webserver, etc bereits alles ausgestellt) komme ich auf ~550 Nachrichten pro Sekunde. Leider vergleichsweise weit weg von den vollen 1000. Sieht also so aus als wäre der Flaschenhals auf dem RED Brick entweder das eigentliche schreiben auf die SD Karte oder die zusätzliche CPU-Last die dadurch erzeugt wird.

Bei mir auf dem PC läuft dein Programm gut: RED Brick probiere ich gleich aus.

Echt komisch. Als Workaround könntest die aktuelle Version der Python-Bindings die du benötigst mit deinem Programm mit hochladen. Also ein tinkerforge/ Ordner erstellen in dem eine __init__.py, die ip_connection.py sowie die brick*_*.py die du benötigst liegen. Python sollte diese dann den installierten vorziehen.

Mit dem neuesten Brick Viewer sollte es eigentlich keine Probleme mit dem 1.13er Image geben. Ich probiere das mal gerade aus. Edit: Hab gerade per Brick Viewer ein frisch geflashtes 1.13er Image aktualisiert, lieft problemlos durch. Ich bin ein bisschen ratlos woran das liegen kann. Hattest du schon probiert den RED Brick und Brick Viewer einmal neuzustarten?

Hab gerade testweise bei einem 1.12 Image die Bindings über den Brick Viewer aktualisiert und das lief problemlos durch. Eventuell war einfach wirklich unser Server kurzzeitig nicht erreichbar? Ich würde es einfach nochmal probieren.

Wie schaut denn das Programm aus welches auf die Ethernet Extension zugreift? Öffnet und schließt das oft die Verbindung? Kann es passieren das die Verbindung eventuell nicht geschlossen wird und im Hintergrund offen bleibt? Die Ethernet Extension kann nur maximal 7 Sockets gleichzeitig bedienen. Danach wäre sie dann nicht mehr erreichbar, was deiner Fehlerbeschreibung entspricht.

Grob kannst du bei jedem Getter mit 2ms und bei jedem Setter mit 1ms Laufzeit rechnen. Du hast in deiner Schleife 4 getter und 8 Setter. Das entspricht also 16ms pro Schleifendurchgang, ich würde in dem Programm also in etwa mit einem Durchsatz von maximal 1000/16 = 62 Beschleunigungsdaten pro Sekunde rechnen. Ich würde versuchen das so umzustellen das du deine Aufzeichnung der Daten per Callback machst (z.B. für 500ms), diese speicherst und danach darstellst. Nach dem darstellen wieder die nächste Aufzeichnung starten etc.

Es gibt hier denke ich kein Hardwareseitiges Problem. Als ersten Schritt sollten wir erstmal in deinem Programm die vollen 1000Hz erreichen. Wenn du nur Master Brick + Accelerometer Bricklet anschließt und in deinem Programm einfach nur die Daten loggst (oder sogar nur zählst erstmal), dann solltest du auf jeden Fall auf 1000Hz kommen. Wenn das funktioniert müssen wir von da aus schauen wie wir den Rest der Hardware einbinden. Dabei ist wichtig: 1000 Nachrichten pro Sekunde sind die maximale Anzahl an Nachrichten die über einen USB-Anschluss laufen können bei uns im System. Wenn du z.B. einen Getter verwendest wird eine Anfrage zum Bricklet geschickt und eine Antwort wieder zurück. Das sind dann bereits zwei Nachrichten. D.h. Callbacks sind in deiner Anwendung definitiv notwendig (die erzeugen nur eine Nachricht, da es die Anfrage nicht gibt). Wenn du mehrere Bricklets verwendest teilen sich diese die Anzahl der Nachrichten. Wenn du also die 1000 Nachrichten/Sekunde von dem Accelerometer Bricklet benötigst, wirst du einen Stapel benötigen der nur aus Master + Accelerometer besteht und einen weiteren für die restlichen Module. Alternativ wenn die Aufzeichnung "schubweise" stattfinden soll kann man es auch so bauen das die anderen Bricklets nicht angesprochen werden während die Aufzeichnung läuft. Wie soll dein Aufbau später aussehen? Standalone irgendwo in einer kleinen Box oder ist er immer am PC angeschlossen?

Hattest du denn vor ein eigenes Programm zu schreiben oder nur den Logger zu nutzen? Mein Beispiel oben wäre ja bereits ein guter Einstieg. Es erhebt die Daten bereits mit den vollen 1000Hz, es fehlt nur das schreiben in eine Datei.

Die RS485 Extension ist zum verbinden von mehreren Stapeln, die benötigst du hier nicht. Du kannst deinen Stapel bauen aus (von unten nach oben): Step-Down Power Supply + Master Brick 2.1 + WIFI Extensin 2.0. Das Thermal Imaging Bricklet wird am Master Brick angeschlossen. Für die initiale Konfiguration des WLANs kannst du den Stapel per USB mit dem PC verbinden. Danach kannst du die Stromversorgung über die Step-Down Power Supply machen und über das WLAN auf den Stapel zugreifen. Der Master Brick bleibt dabei die ganze Zeit im Stapel.