borg

Do you have the IMU Brick V2 directly connected to a PC via USB or is it in a stack? Do you have any additional Bricklets connected? If the fusion algorithm is enabled you should be able to reach a 100Hz update rate. Here is screenshot from the BNO055 datasheet: If you turn the fusion algorithm off (see set_sensor_fusion_mode) the frequency goes up, you can then configure it with the set_sensor_configuration function.

Firmware: Thermal Imaging 2.0.1 Bricklet now uses "low gain" in "high range" mode. Otherwise the full 400°C range can't be reached. Download: Thermal Imaging

Firmware: Thermal Imaging 2.0.1 Bricklet nutzt jetzt automatisch "low gain" im "high range"-Modus. Ansonsten kann der volle 400°C Bereich nicht erreicht werden. Download: Thermal Imaging

Wenn du das Programm auf dem PC ausführst kannst du es mit Spyder debuggen. Es läuft dann auf dem PC wie jedes andere Programm auch.

Zum debuggen würde ich den RED Brick am PC anschließen und das Programm auf dem PC ausführen.

Die "write_lines" werden ja direkt in den Callbacks aufgerufen? Ich würde erstmal damit anfangen prints in die Callbacks zu machen um schauen ob Sie aufgerufen werden. Wenn sie aufgerufen werden musst du gucken welche der Bedingungen nicht eintreffen (self.Tick1 = X etc). So auf Anhieb nur durchs draufschauen kann ich keinen Bug finden.

Das Protokoll ist hier beschrieben: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c (oben in den Kommentaren). Auf dem 7-Pol Stecker wird nur noch SPI mit dem "SPITF"-Protokoll gesprochen (und 3.3V, 5, GND).

Firmware: PTC Bricklet 2.0.2 SensorConnectedCallback API hinzugefügt Download: PTC

Firmware: PTC Bricklet 2.0.2 Add implementation for SensorConnectedCallback API Download: PTC

I suspect that the Brick Viewer sensd a bit too much data to be transferred over WIFI. Have you tried it with your own program? At what rate does it work and and what rate doesn't it work?

Die neuen Bricklets haben andere Funktionen zur Callback-Konfiguration (wir haben für die neuen Bricklets den kompletten Mechanismus überarbeitet und vereinfacht). Du verwendest z.B. "set_humidity_callback_period", das gibt es aber gar nicht mehr. Siehe set_humidity_callback_configuration: https://www.tinkerforge.com/de/doc/Software/Bricklets/HumidityV2_Bricklet_Python.html

Wir haben das Temperature IR 2.0 hier ausgiebig unter den unterschiedlichsten Bedingungen getestet. Ich konnte nie so einen Fehler erzeugen . Gibt es irgendetwas womit du den Fehler reproduzieren kannst? Oder tritt es immer einfach so nach einiger Zeit auf?

Statt if (identifier = 119) { musst du if (identifier == 119) { verwenden.

Ja, ich wüsste nicht warum das nicht funktionieren sollte.

Das ist leider nicht möglich. Wir lauschen immer mit einer festen Bitrate, diese ist aber von Typ zu Typ unterschiedlich.

How do you detect the button press? Do you use the internal pull-ups from the IO-4 and the button shorts to ground? If that is the case, you might want to add an additional pull-up (perhaps 1k or similar). The internal processor pull-up is specified to be somewhere between 100k and 400k, which might be to little resistance for the interference from the pump?

Du musst beide Ifs in einen Callback packen. Dein zweiter ".on"-Aufruf überschreibt den ersten.

Support im Master Brick gibt es seit 2.4.4, im Brick Viewer seit 2.3.13. Ich würde aber auf jeden Fall empfehlen auf die neusten Versionen zu aktualisieren!

Schick einfach eine Email an die info@tinkerforge.com mit deiner Bestellnummer, wir tauschen den Sensor dann aus.

Alles auf dem neusten Stand? Brick Viewer, Master Brick Firmware?

The "Internet of Thinkgs enclosure" is now compatible to the Outdoor Weather Bricklet . We put in some more mounting holes in the bottom, the holes in the front fit without changes. https://www.tinkerforge.com/en/shop/cases/internet-of-things-case.html I still have to make some updated photos.

Da können wir nichts dran ändern, Typ A ist sozusagen rückwärtskompatibel zu Typ C, aber je nachdem was geschickt wird nicht umgekehrt. Also rein analog die gesendeten Daten sind kompatibel, die Interpretation ist anders.

So, es gibt jetzt Firmware Version 2.0.1. Ich mache jetzt in der Tat eine Überabtastung der Daten und erlaube bis zu ~25% Unterschiede in Bitrate. In meinen Tests funktioniert das jetzt erheblich besser. Ich kann jetzt auch mit dem alten Remote Switch Bricklet das neue Remote Switch Bricklet 2.0 schalten. Bei Typ B wenn man alles auf 0 stellt (address, unit) kommt es schonmal öfter zu falschen Messungen. Rein technisch führt das dazu das im ganzen Bitstream das gleiche Pattern versendet wird und die Sync-Bits sehen dem Pattern sehr ähnlich. Dadurch bekommt das Bricklet manchmal einen Versatz rein. Selbst als Mensch ist das aber schwierig zu interpretieren. Die "address" wird ja von der Fernbedienung zufällig vergeben, daher sollte das mit einer echten Fernbedienung eigentlich nie auftreten. @insidERR: Wir schicken dir deinen Aufbau heute zurück (mit neuesten Firmwares drauf geflasht und getestet). Vielen Dank für das zusenden!

Firmware: NFC Bricklet 2.0.1 Add function for global maximum timeout to API Use RequestTagIDError state if no tag has been found after timeout Download: NFC Firmware: Remote Switch Bricklet 2.0 2.0.1 Digitize 2x oversampled input data in a fuzzy-manner to allow for bit-rate differences between remotes Use passive level 0 as expected by RFM69 IC Download: Remote Switch 2.0

Firmware: NFC Bricklet 2.0.1 Funktion zur Einstellung eines globalen Timeouts zur API hinzugefügt Nutze RequestTagIDError falls es einen Timeout beim suchen eines Tags gibt Download: NFC Firmware: Remote Switch Bricklet 2.0 2.0.1 Nutze Oversampling und "Fuzzy-Matching" zum digitalisieren der Daten. Dadurch können wir Bitratenunterschiede zwischen Fernbedienungen besser behandeln. Nutze Passiv-Level 0 für SPI, wie vom RFM69 IC erwartet Download: Remote Switch 2.0