borg

Hard to say why you don't have the deive-tree, the easiest solution is probably to just configure it by hand, see here: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Zero_Brick.html#compatibility-to-other-boards-and-images Add the lines from the documentation to your /etc/brickd.conf and turn spi interface on with raspi-config. Then the brickd doesn't have to configure anything by reading out the device-tree first and it should just work.

Grundsätzlich sind auf Grund des internen Aufbaus der Software der Bricks nur maximal 1000 Nachrichten pro Sekunde möglich (egal welche Schnittstelle). Zu den Fragen: 1) Der Master Brick muss bei dem Chip auf der Ethernet Extension nach neuen Daten pollen, daher geht da immer Zeit verloren, auch wenn keine Daten über Ethernet übertragen werden. Man müsste das exakte Szenario profilen um zu sehen warum genau 1/4 Datendurchsatz verloren geht in dem Fall. 2 und 3) Wenn die Ethernet Extension auf einem RED Brick sitzt wird diese immer vom Linux Kernel genutzt und nie direkt vom Brick Daemon. Der Durchsatz dabei hängt von vielen Faktoren ab, inkl. der CPU Last und wieviel anderes IO auf dem RED Brick gemacht wird usw. 4) Die meisten Nachrichten bekommst du über einen einzelnen Master Brick der an einen USB 3.0 Port angeschlossen ist.

Wenn du am Ende 12800 Datenpunkte nach einer Sekunde hast sind diese auch Äquidistant gemessen worden. Der KX122 misst nicht mehr als die eingestellte Frequenz und das Bricklet liest nichts doppelt. Wenn da zwischendurch Daten fehlen da diese nicht rechtzeitig verschickt werden konnten gibt es allerdings keine Aussage dazu an welcher Stelle diese genau Fehlen im Datenstrom.

Firmwares: RS232 2.0 Bricklet 2.0.4 Make sure there are no glitches on TX line during configuration change Download: RS232 2.0 Bricklet

Firmwares: RS232 2.0 Bricklet 2.0.4 Stelle sicher dass es keine Glitches auf TX gibt wenn die Konfiguration geändert wird Download: RS232 2.0 Bricklet

Bei mir läuft das Touchscreen immernoch... Vielleicht komme ich hier bei mir auf dem Schreibtisch zu oft dran und "resette" dadurch irgendeinen Zustand im Code oder im Touchscreen-Controller? Wie oft macht du denn etwas mit dem Display? Regelmäßig oder drückst du da nur alle paar Monate einmal drauf und dann hast du den Bug?

Firmware: Thermal Imaging 2.0.5 Fix vertikale Orientierung von Wärmebildern für Getter Fix Problem mit Tearing von Wärmebildern bei Verwendung von Gettern Set/GetLinearFluxParameters API hinzugefügt Download: Thermal Imaging

Firmware: Thermal Imaging 2.0.5 Fix vertical orientation of images transfered by getter Fix tearing issue when images transfered by getter Add Set/GetLinearFluxParameters API Download: Thermal Imaging

Firmware: Industrial Counter Bricklet 2.0.4 Fix Bug in 0 nach -1 Übergang und konfiguriere dazugehörigen Overflow korrekt Download: Industrial Counter

Firmware: Industrial Counter Bricklet 2.0.4 Fix 0 to -1 transation handling and configure corresponding overflow correctly Download: Industrial Counter

OK, also handelt es sich definitiv wirklich um ein grundsätzliches Problem und es war nicht ein Problem mit deinem spezifischen LCD. Ich baue mir hier auf dem Schreibtisch nochmal ein LCD mit Debug auf und versuche da jeden Tag ein paar mal drauf rumzutouchen um das Problem hier zu reproduzieren. Es ist leider immer schwierig dieses Bugs zu debuggen die nur alle paar Wochen einmal auftrete 😐 .

Das GPS Bricklet 2.0 funktioniert leider nicht stabil mit dem HAT Brick. Dies ist ein bekannter Bug, siehe hier: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/GPS_V2.html#beschreibung

Testest du das In einem Gebäude? Falls ja, könntest du das einmal draußen über freiem Himmel testen? Nur um sicher zu gehen das es kein Empfangsproblem sein kann.

Du brauchst Raspberry Pi, HAT Brick oder HAT Zero Brick, Outdoor Weather Bricklet, Bricklet-Kabel 7p-7p und Außenwetterstation. Das HAT wird auf den RPi gesteckt und das Outdoor Weather Bricklet per Bricklet-Kabel an das HAT.

In diesem Fall muss das Flashen irgendwie fehlgeschlagen sein und das HAT Brick befindet sich im Bootloader-Modus. Du müsstest einmal eine Konfiguration in der /etc/brickd.conf durchführen wie hier beschrieben:https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#kompatibilitat-zu-anderen-boards-und-images und danach dann noch einmal per "sudo raspi-config" das SPI-Interface aktivieren. Nach einem neustart tauch der HAT dann im Bootloader-Modus wieder im Brick Viewer auf. Dort kannst du dann die Firmware wieder drauf flashen.

Echt komisch. Die große Frage ist jetzt ob es da einen Bug in der Ausleselogik des Touch-Controllers gibt oder ob dein Touchscreen einen defekt hat. Wir hatten das LCD noch nicht ausgetauscht, oder? Könntest du einmal an die info@tinkerforge.com eine Email schreiben mit der Bestellnummer und einen Hinweis auf diesen Thread. Dann würde ich vorschlagen dass wir dir erstmal ein neues LCD 128x64 schicken um sicher zu stellen das es sich nicht um einen Hardware-Defekt handelt.

Wir hoffen aktuell dass wir diese Woche (KW 2) wieder welche rein bekommen, falls nicht aber auf jeden Fall nächste Woche (KW 3)! Das gleiche gilt auch für alle anderen Bricklets die aktuell ausverkauft sind, bis auf PTC Bricklet 2.0. Das dauert noch etwas länger.

Das sieht so aus als würde das Bricklet den Shutter bewegen zur Kalibrierung, der Shutter bewegt sich aber physikalisch nicht. Du könntest einmal probieren das Lepton-Modul runterzudrücken, eventuell ist es ein Stück aus dem Sockel gerutscht? Ansonsten, kann man am Shutter irgendein Defekt erkennen? Hängt der Shutter eventuell irgendwie fest (Staubkorn oder so)?

So, sollte jetzt in der frisch veröffentlichten Firmware 2.0.3 gefixt sein:https://github.com/Tinkerforge/industrial-counter-bricklet/commit/ef2a1251b43653d8aebaba87803ac32e004bd72f Vielen Dank für denk Hinweis!

Firmware: Industrial Counter Bricklet 2.0.3 Fix erroneous value_has_to_chnage-logic for callbacks Download: Industrial Cunter

Firmware: Industrial Counter Bricklet 2.0.3 Falsche value_has_to_change-Logik im Callback-Handler gefixt Download: Industrial Cunter

In der Tat. Ich schaue mir gerade den Code an: if((!counter.cb_counter_value_has_to_change) || (last_counter[0] != new_counter[0]) || (last_counter[1] != new_counter[1]) || (last_counter[2] != new_counter[2]) || (last_counter[3] != new_counter[3])) { last_time = system_timer_get_ms(); tfp_make_default_header(&cb.header, bootloader_get_uid(), sizeof(AllCounter_Callback), FID_CALLBACK_ALL_COUNTER); for(uint8_t channel = 0; channel < COUNTER_NUM; channel++) { cb.counter[channel] = new_counter[channel]; } } Der Check ist zwar richtig, aber last_counter wird nie gesetzt... Ich fixe das kurzfristig.

Die Diode wird irgendwann sicherlich ausfallen. Aber auch die Werte werden (auch auf Grund von kleinen Staubpartikeln die sich über die Zeit im Inneren auf Spiegel und Diode festsetzen) anfangen zu driften. Wenn dir die Genauigkeit der Werte sehr wichtig ist musst du wahrscheinlich nach 8000h wechseln. Mehr als die Herstellerangaben können wir da ja auch nicht weitergeben. Ansonsten würde ich sagen reicht aber auch eine Plausibilitätsprüfung der Daten. Du hast ja historische Daten mit denen du vergleichen kannst nehme ich an.

Eigentlich sollte das per set_all_counter_callback_configuration(100, True) funktionieren. Damit bekommst du den Callback alle 100ms, aber nur dann wenn sich der Wert auch geändert hat.

Die Kanäle nach außen sind bei allen Bricklets von links nach rechts durchnummeriert (also links 0, rechts 1 in diesem Fall). Der ADC ist einfach so angeschlossen wie es sich am besten routen lässt. Die interne Kanalnummer des ADCs ist ja nicht relevant für den Nutzer des Bricklets.