borg

Firmware: CO2 V2 Bricklet 2.0.2 Behandlung von I2C-Fehlern verbessert Download: CO2 2.0

Firmware: CO2 V2 Bricklet 2.0.2 Improve I2C error handling Download: CO2 2.0

Die neueste Firmware (2.0.5) sollte die Ausreißer jetzt endgültig beheben . Sag bitte Bescheid falls du mit 2.0.5 immer noch Ausreißer hast!

Firmware: Air Quality Bricklet 2.0.5 Bosch BSEC auf v1.4.7.4 aktualisiert Behandlung von Ausreißerwerten verbessert Download: Air Quality

Firmware: Air Quality Bricklet 2.0.5 Update Bosch BSEC to v1.4.7.4 Improve outlier value handling Download: Air Quality

I think you will be able to read out most professional pyranometer with the existing Bricklets. For example, with a quick search i found this: https://www.rg-messtechnik.de/pyranometer-cmp11.php They use Pt elements that you would be able to read with a PTC Bricklet 2.0

Bitte einmal auf die neueste Piezo Speaker Firmware Version aktualisieren, dann geht es wieder. Da gab es eine Inkompatibilität mit neueren Master Brick Firmware Versionen die noch gar nicht aufgefallen war. Danke für den Hinweis!

Firmware: Piezo Speaker Bricklet 2.0.3 Don't disable IRQs during calibration, since newer Brick versions use interrupts during I2C communication Download: Piezo Speaker

Firmware: Piezo Speaker Bricklet 2.0.3 Don't disable IRQs during calibration, since newer Brick versions use interrupts during I2C communication Download: Piezo Speaker

Ich hatte hier jetzt eine Zeit lang einen Testaufbau am laufen der immer nur get_touch_position aufgerufen hat mit der Hoffnung dass ich irgendwann einen "falschen Touch" sehe. Ich konnte das leider bisher nicht reproduzieren. Ein Pressure-Wert von 1 ist bereits der niedrigste Wert, meine Behauptung von vorher dass ich dort einen Threshold niedriger setzen kann macht also keinen Sinn. Meine neueste Vermutung ist, dass du für eine ganz kurze Zeit fälschlicherweise irgendwo eine Berührung siehst (beim Aufruf von get_touch_position nach dem Callback ist der Pressure-Wert dann schon wieder auf 1) und der Fix wäre eher ein Minmum-Klickzeit für den Button-Klick einzuführen. Ich hab da jetzt nochmal mehr logging eingebaut und es sind jetzt auch Buttons mit konfigurierten Callbacks mit eingebaut. Das lasse ich jetzt nochmal ein paar Tage laufen. Melde mich dann wieder.

Firmware: Thermal Imaging Bricklet 2.0.4 Nutze Double Buffering für Lepton-Statistiken um Tearing in den Statistiken zu verhindern Download: Thermal Imaging

Firmware: Thermal Imaging Bricklet 2.0.4 Double buffer lepton statistics to prevent statistics tearing Download: Thermal Imaging

Einen Widerstand kannst du mit den Bricklets am einfachsten über einen Spannungsteiler und einem (Industrial) Analog In Bricklet messen. https://www.elektronik-kompendium.de/sites/slt/0201111.htm In dem Beispiel wäre R1 der veränderliche Widerstand und R2 ein fester Widerstand. Die Spannung zwischen den beiden Widerständen verändert sich dann wenn sich R1 ändert.

Ich bin jetzt dazu gekommen mir das einmal mit dem Profiler anzuschauen. Einen kleinen Flaschenhals hab ich bei den SPI Chip Selects gefunden, die konnten ohne großen Aufwand effizienter gemacht werden. Das hat sowas wie ~15% eingespart. Zusätzlich hab ich eine "sleep_between_read"-Option pro Bricklet in die /etc/brickd.conf hinzugefügt. Damit kann jetzt eingestellt werden wie lange der Brick Daemon mindestens warten soll zwischen zwei "Reads" von einem Bricklet. Der Wert ist in us und war damals per Default 200us. Die Default-Konfiguration sieht mit der neuen brickd Version jetzt so aus: bricklet.portA.sleep_between_reads = 200 bricklet.portB.sleep_between_reads = 200 bricklet.portC.sleep_between_reads = 200 bricklet.portD.sleep_between_reads = 200 bricklet.portHAT.sleep_between_reads = 2000 Die Default-Einstellung vom HAT selbst hab ich von 200us auf 2ms erhöht, da das HAT selbst sowieso nie große Datenmengen übertragen muss. Wenn am Bricklet nichts angeschlossen ist was große Datenmengen überträgt kann aber auch z.B. alles auf 5ms gesetzt werden und es funktioniert immernoch gut: bricklet.portA.sleep_between_reads = 5000 bricklet.portB.sleep_between_reads = 5000 bricklet.portC.sleep_between_reads = 5000 bricklet.portD.sleep_between_reads = 5000 bricklet.portHAT.sleep_between_reads = 5000 Meine Ergebnisse nach den Änderungen: HAT mit Defaultkonfiguration, keine Bricklets angeschlossen: HAT mit Defaultkonfiguration, Thermal Imaging Bricklet an port B streamt mit vollem Durchsatz Bild über WIFI: HAT mit 5ms-Konfiguration, Rotary Encoder an Port B: Anbei die Beta-Version des neuen Brickd mit den Änderungen. brickd-2.4.1-beta1_armhf.deb

Anbei Beta-Versionen des nächsten Bindings-Release von Rust und MATLAB: http://download.tinkerforge.com/_stuff/tinkerforge_rust_bindings_2_0_11_beta1.zip http://download.tinkerforge.com/_stuff/tinkerforge_matlab_bindings_2_0_23_beta1.zip

Firmware Version 2.0.2 ist jetzt veröffentlicht und sollte das fixen. Ich hab die Firmware in dem Zuge auf die neuen Coop Tasks umgestellt die wir in der bricklib haben (gab es zu dem Zeitpunkt als wir die Firmware geschrieben haben noch nicht) Die Baudrate hab ich auf 200kHz erhöht um das Jitter zu verringern, wobei der Durchsatz bei 100kHz prinzipiell auch bereits gereicht hatte. So sieht das jetzt aus: 976 SPS 488 SPS 244 SPS Der etwas größere Block bei CLK sind immer die Daten und die kleinen Blöcke sind die Statusabfrage. Das sieht jetzt IMO ganz gut aus und bleibt auch langfristig gleichmäßig.

Firmware: Industrial Dual Analog In V2 Bricklet 2.0.2 Fix error in sample rate configuration Use coop task instead of complicated state machine Properly reconfigure ADC in case of invalid data Download: Industrial Dual Analog In 2.0

Firmware: Industrial Dual Analog In V2 Bricklet 2.0.2 Fix error in sample rate configuration Use coop task instead of complicated state machine Properly reconfigure ADC in case of invalid data Download: Industrial Dual Analog In 2.0

So, ich hab jetzt eine entsprechende Funktion hinzugefügt: https://www.tinkerforge.com/en/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_filter_configuration Gibt es in Firmware Version 2.0.2. Die API wird dann mit dem nächsten Bindings-Release aktualisiert. Das kann leider noch ein wenig dauern. Welche Programmiersprache verwendet ihr? Dann erstelle ich für euch einmal schnell Beta-Bindings zum testen (wenn bedarf besteht).

Ich hab es mir auf die TODO-Liste geschrieben da nochmal mit einem Profiler zu schauen wo die CPU-Zeit verloren geht. Eventuell können wir da ein einstellbares Abfrageintervall o.ä. machen für Anwendungen wo kein hoher Durchsatz benötigt wird.

Steht irgendetwas in der /var/log/brickd.log? Zum Thema CPU-Auslastung: Kann es sein dass der brickd gerade so wenig CPU zieht das der RPi sich heruntertaktet und dann eine relativ hohe Auslastung anzeigt? Um das zu testen kannst du einmal probeweise den Linux Governor auf "performance" stellen: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#konfiguration-fur-verbesserten-durchsatz

Mh, ich glaube ich muss da nochmal eine Debug-Firmware fertig machen die den Rohwert des Touchscreens ausgibt um zu sehen wie nah das an einem "Pressure-Wert" von 1 dran ist. Vielleicht muss da generell der Threshold ein bisschen höher. Ich melde mich hier nochmal wenn ich da mehr Erkenntnisse hab.

Ich hab es mir nicht im Detail angeschaut, sieht aber in der Tat nach einem sehr unnötigen Bug aus! Schaue ich mir schnellstmöglich an, gibt dann eine neue Firmware. Danke für den Hinweis .

Wir haben das gerade nochmal getestet, bei uns startet der brickd automatisch wenn wir es nach Anleitung machen. Sehr komisch. Falls das irgendwie nicht funktioniert hat kannst du den Autostart auf jeden Fall mit sudo systemctl enable brickd aktivieren. Ich glaube der Service taucht da auch nicht zweimal auf, du siehst da nur zwei Threads. Ansonsten hat der RPi Zero halt nur einen Kern mit 1GHz, da kann der brickd schon schnell viel CPU ziehen. Welche Bricklets hast du denn angeschlossen und was machst du mit diesen/hast du mit diesen vor?

I tried the newest Raspbian Image with RPI 2/3/4 and the behavior is now the same with all three versions*: The SPI speed scales with the CPU frequency, which is depended on the Linux governor. I added a section to the documentation: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Brick.html#configuration-for-improved-throughput With the RPi 3 and 4 i get the full 1000 messages per second after the changes.