borg

Firmware: LCD 128x64 Bricklet 2.0.6, Air Quality Bricklet 2.0.1 Fix off-by-one in Button und Slider Größchencheck (LCD 128x64 Bricklet) Fix Error in Paketlänge für get_iaq_index-Funktion (Air Quality Bricklet) Download: LCD 128x64 Bricklet 2.0.6, Air Quality Bricklet 2.0.1

Firmware: LCD 128x64 Bricklet 2.0.6, Air Quality Bricklet 2.0.1 Fix off-by-one in button and slider bounding box check (LCD 128x64 Bricklet) Fix error in packet length for get_iaq_index function (Air Quality Bricklet) Download: LCD 128x64 Bricklet 2.0.6, Air Quality Bricklet 2.0.1

Ich hab Firmware Version 2.0.0 und 2.0.1 getestet mit diesem Code: #include <stdio.h> #include "ip_connection.h" #include "bricklet_industrial_digital_in_4_v2.h" #define HOST "localhost" #define PORT 4223 #define UID "FrC" // Change XYZ to the UID of your Industrial Digital In 4 Bricklet 2.0 // Callback function for value callback void cb_value(uint8_t channel, bool changed, bool value, void *user_data) { (void)user_data; // avoid unused parameter warning printf("Channel: %u\n", channel); printf("Changed: %s\n", changed ? "true" : "false"); printf("Value: %s\n", value ? "true" : "false"); printf("\n"); } int main(void) { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object IndustrialDigitalIn4V2 idi4; industrial_digital_in_4_v2_create(&idi4, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); return 1; } // Don't use device before ipcon is connected // Register value callback to function cb_value industrial_digital_in_4_v2_register_callback(&idi4, INDUSTRIAL_DIGITAL_IN_4_V2_CALLBACK_VALUE, (void *)cb_value, NULL); // Set period for value (channel 1) callback to 0.1s (100ms) industrial_digital_in_4_v2_set_value_callback_configuration(&idi4, 1, 100, true); printf("Press key to exit\n"); getchar(); industrial_digital_in_4_v2_destroy(&idi4); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally return 0; } Ausgabe: olaf@pc2:~/build20/c$ g++ -pthread example_callback.c bricklet_industrial_digital_in_4_v2.c ip_connection.c -o test In file included from /usr/include/errno.h:25:0, from ip_connection.c:19: /usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^~~~~~~ olaf@pc2:~/build20/c$ ./test Press key to exit Channel: 1 Changed: true Value: true Channel: 1 Changed: true Value: false Channel: 1 Changed: true Value: true Channel: 1 Changed: true Value: false Mal abgesehen davon das wir in den Bindings irgendwo ein veraltetes define verwenden funktioniert das bei mir ohne Probleme. Im Brick Viewer wird es auch korrekt angezeigt. Was genau konfigurierst du?

Kann ich irgendwie nicht reproduzieren. Hab mit folgendem getestet: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "GK7" # Change XYZ to the UID of your LCD 128x64 Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_lcd_128x64 import BrickletLCD128x64 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection lcd = BrickletLCD128x64(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Clear display lcd.clear_display() lcd.remove_all_gui() lcd.set_gui_graph_configuration(0, lcd.GRAPH_TYPE_DOT, 62, 0, 60, 52, "X", "Y") lcd.set_gui_graph_data(0, list(range(59)) + [200]) raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() Sprich der Graph hat Länge 60, und die Dots gehen von 0-58 und dann der letzte bei 200.

In der Tat! Danke für den Hinweis, fixe ich gleich.

Ja, auch die ganz alten Master Brick 1.0 sind (mit dem neuen 7p-10p Kabel) noch zu den neuesten Bricklets kompatibel.

Mhh, hab gerade schnell in den Code geschaut: Der enable()-Aufruf führt in der Tat ein Reset auf dem IC aus den wir nutzen, daher macht es Sinn das der Schrittmotor aufhört zu laufen. Ich kann mir allerdings nicht erklären warum danach setSteps() nicht mehr funktioniert. Ich denke die bessere Vorgehensweise wäre allerdings sowieso wenn der enable()-Aufruf gar nichts macht wenn der Stepper Brick bereits enabled ist. Ich schreib mir das auf die TODO-Liste, wird mit der nächsten Version gefixt.

Generally, the calls to the API have a timeout of 2.5 seconds. So calls like setSteps will never block, since they may take a long time. But you can make your own blockingSetSteps function that sets a bool value to true, calls setSteps, sets in the callback the bool value back to false and the blockingSetSteps function only returns when the bool value was set back to false.

Sehr komisch! Du könntest einmal testen auch das NFC Bricklet neu zu flashen, ich wüsste allerdings auch nicht was das ändern sollte. Wenn das alles nichts bringt musst du die NFC Bricklets einschicken befürchte ich, wir würden uns das gerne ansehen. Vor allem wenn es ein Hardware-Defekt ist der erst nach einer Weile aufgetreten ist wäre das natürlich für uns interessant. Melde dich diesbezüglich dann bitte bei info@tinkerforge.com, wir können die auch vorher bereits erst zwei neue NFC Bricklets schicken.

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.