photron

Brick Viewer 2.4.10 Thermal Imaging Bricklet Bildansicht ist abtrennbar Firmware-Auto-Update für Co-MCU Bricklets repariert Mögliche Config-Datei-Schreibkollision zwischen zwei Brick Viewer Instanzen auf Linux und macOS verhindert Brick Viewer App ist notariziert, um bereit für macOS 10.15 zu sein Möglichen Crash in der WIFI Extension 2.0 Firmware Update-Erkennung behoben Exception Hook für Python 3.8 repariert Bevorzugt hPa über mbar und Tesla über Gauss Data Logger Support für Lesen der Daten des RS232 Bricklet 2.0 hinzugefügt Server Monitoring Support für Humidity Bricklet 2.0 Temperature Wert hinzugefügt Downloads: Windows, Linux, macOS

Brick Logger 2.1.2 Add support for RS232 Bricklet 2.0 data reading Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.2 Support für Lesen der Daten des RS232 Bricklet 2.0 hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Bist du mit deinem PC denn im gleichen Netz wie der RED Brick? Teste auch mal bitte mit der IP Adresse des RED Bricks (laut Screenshot: 192.168.1.163) in Brick Viewer, anstatt mit dem Hostnamen red-brick. Vielleicht verbindet dein Router die Informationen aus DNS und DHCP nicht miteinander, so dass der Hostname nicht aufgelöst werden kann.

Die aktuelle brickd Version ist auf GitHub verfügbar: https://github.com/Tinkerforge/brickd https://github.com/Tinkerforge/daemonlib

Und was genau hat jetzt geholfen?

Well, Microsoft kills that hope too. I've looked into this shortly after you suggested this. It's basically working but auto-detection is the problem again. I've now commit the experimental HAT (Zero) Brick support, that I had sitting on my PC since summer, collecting dust. You can test it using the latest brickd source code from GitHub. See the Windows 10 IoT Core readme section for some hints about how to enable it. It's disabled by default, because Windows 10 IoT Core doesn't provide any kind of HAT detection. As far as I can tell, there is no proper way for Brick Daemon to detect if a HAT is connected or not or what kind of HAT it is. The UWP Devices API doesn't even allow access to the GPIO pins that Raspbian uses for HAT detection on Linux.

Seit der Beta ist da nicht viel passiert. Es gab ein paar kleine Bugfixes zu diesem Thema in Brick Daemon, das grundsätzliche Problem ist aber immer noch vorhanden. Bricks tauchen unter Windows 10 IoT Core nicht so als USB Geräte auf, dass brickd direkt mit ihnen arbeiten könnte. Erst nach der beschriebenen manuellen Registryänderung kann brickd auf per USB angeschlossene Bricks zugreifen. Nach meinem Verständnis ist das bei Bug im USB Stack von Windows 10 IoT Core, da es mit Windows 10 IoT Desktop ohne Probleme funktioniert. Ich habe versucht das Problem an Microsoft zu melden, aber ohne Erfolg. Daher gibt da keine Pläne, denn ich wüsste nicht was ich tun sollte, außer darauf zu warten, das Microsoft das Problem irgendwann behebt. Der aktuelle Stand ist folgender: Der Windows 10 IoT Core Support für über USB an einem Raspberry Pi angeschlossene Bricks ist Teil der normalen Brick Daemon Codebase. Es gibt aktuell aber keinen vorkompilierten direkt installierbaren Brick Daemon für die Universal Windows Platform (UWP) und damit Windows 10 IoT Core. Du kannst aber mit der kostenlosen Visual Studio 2019 Version den aktuellen Brick Daemon Sourcecode für UWP kompilieren und auf einem Raspberry Pi installieren. Abgesehen von der händischen Registryänderung funktioniert das problemlos. Die Readme hat mehr Details dazu, siehe den Windows 10 IoT Core Abschnitt.

RED Brick Image 1.15 Add support for RTL8821CU USB WiFi + Bluetooth dongle Workaround Ethernet Extension W5500 buffer config reset bug Update Brick Viewer to version 2.4.9 Update all API bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Java 2.1.25, JavaScript 2.1.25, Octave 2.0.25, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Shell 2.1.24, Visual Basic .NET 2.1.24 Download: RED Brick Image

RED Brick Image 1.15 Support für RTL8821CU USB WLAN + Bluetooth Stick hinzugefügt Workaround für Ethernet Extension W5500 Buffer Config Reset Bug hinzugefügt Brick Viewer auf Version 2.4.9 aktualisiert Alle API Bindings aktualisiert: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Java 2.1.25, JavaScript 2.1.25, Octave 2.0.25, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Shell 2.1.24, Visual Basic .NET 2.1.24 Download: RED Brick Image

Es gibt ein paar kleine API Unterschiede: read/write/CALLBACK_READ: Bei 1.0 wird immer eine Liste der Länge 60 Byte übergeben, zusammen mit einem zusätzlichen Längenwert der ausdrückt wie viele Bytes in der Liste gültig sind. Bei 2.0 gibt es den zusätzlichen Längenwert nicht mehr und die Länge der Liste ändert sich entsprechend der Länge der gültigen Daten. set_configuration: Die beiden Flowcontrol Parameter wurden bei 2.0 zusammengefasst

Der HAT Brick ist der erste Brick, der nicht mehr die alten 10 Pol Bricklets unterstützt, sondern nur noch die neuen 7 Pol Bricklets. Siehe Hinweis in der Dokumentation: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#beschreibung Alle andere Bricks unterstützen die alten 10 Pol und die neuen 7 Pol Bricklets. Da das RS232 Bricklet (1.0) aber ein 10 Pol Bricklets ist funktioniert es an einem HAT Brick leider nicht, auch wenn du es durch falsche Verwendung eines 10 Pol auf 7 Pol Brickletkabels an einem HAT Brick rein mechanisch anschließen kannst. Es gibt keine Möglichkeit ein 10 Pol Bricklet an einem HAT Brick zu betreiben.

In den Daten sehen ich Folgendes: Es kommen sehr häufig mehrere Pakete in einem Socket Read an (data_history, 3. Spalte ist die Paketlänge), bis dann dauerhaft 8192 Byte pro Socket Read ankommen mit längeren Pausen dazwischen. Die Kommunikation ist also sehr Burst-artig. Das ist unerwartet. Die Exception kommt dann, weil da zwischen zwei Paketen 3 Byte extra stehen, die da nicht hingehören. Zur Veranschaulichung: Es kommen abwechselnd zwei Callbacks an, A und B. In der ersten Zeile die normale Abfolge ABAB, alles vollständig, alles okay. In der zweiten Zeile der kaputte Fall. Erst kommt ein normales A an, gefolgt von den ersten 3 Byte eines B, das sind die 3 Byte die da nicht hingehören. Dann ein normales B, gefolgt von einem A bei dem die ersten 3 Byte fehlen, dann wieder ein normales B. [ A ][ B ][ A ][ B ] [ A ][ B.. ][ B ][ ..A ][ B ] Die Frage ist jetzt wo diese Veränderung der Daten wegkommt. Ist es möglich den Master Brick über USB statt Ethernet anzuschließen, um zu testen ob das Problem durch die Ethernet Verbindung bzw die Ethernet Extension entsteht? Läuft auf allen Brick und Bricklets die aktuelle Firmware (Brick Viewer kann dir das sagen)?

Ich muss mir die Ausgabe noch genauer ansehen, was aber schon auf den ersten Blick auffällt ist, dass die pending_data 6645 Byte lang sind. Es scheint doch zu passieren, was ich für unwahrscheinlich hielt. The Receive Thread ließt eingehende Daten vom Socket und sammelt die in pending_data auf. Nach jedem Empfangen wird dann geprüft , ob genug Daten da sind um daraus ein Paket zu dekodieren. Die absolute maximale Paketlänge ist 80 Byte. Damit sich 6645 Byte in pending_data aufstauen können, müssen die mehr oder weniger in einem Receive Aufruf ankommen. Das sollte erstmal kein Problem sein, die IP Connection kommt damit zurecht. Das Problem hier ist, dass die IP Connection hier versucht ein Paket der Länge 0 zu dekodieren. Die minimale Länge ist aber 8 Byte. Das hat jetzt zwei mögliche Ursachen. Entweder schickt eines der Bricklets ein Paket mit falschen Wert im Längenfeld, das führt zu einem Offset in der Dekodieren der IP Connection die dann ultimativ die Daten falsch versteht. Oder beim Ethernet Transport gehen Daten verloren oder werden verfälscht, was zum gleichen Ergebnis führt. Hilfreich wäre es einen vollständigen Dump zu haben.

Die ersten 10 Byte sind kein vollständiges Paket, das ist erwartet, da ich einfach die letzten 1000 Bytes ausgeben, ohne auf Paketgrenzen zu achten. Wenn ich die ersten 10 Byte weglasse, dann dekodieren die restlichen Daten sauber zu 44 Callbacks, jeweils abwechselnd der Accelerometer Bricklet 2.0 Acceleration Callback und der Air Quality Bricklet All Values Callback. Die ersten weggelassenen 10 Byte sehen aus wie die letzten 10 Bytes eines der All Values Callbacks. Sprich, ich sehen aus den Daten nicht warum der Fehler auftritt. Wenn ich die ersten 11 Byte weglasse, dann tritt der Fehler im dritten Paket auf. Das ergibt aber wenig Sinn, denn damit das wirklich so aufgetreten sein könnte, müssen die restlichen Daten, die 42 Pakete ergeben, bei der IP Connection in einem Socket Receive Aufruf angekommen sein. Das ist nicht unmöglich, aber doch sehr unwahrscheinlich. Ich kann aus den Daten leider so nicht sehen was da wirklich los ist, sorry. Hier eine IP Connection die beim Auftreten des Problems alles ausgibt was an Daten da ist. Damit bitte nochmal das Problem erzeugen. Die Ausgabe ist deutlich umfangreicher und sieht in etwa so aus: --------- BEGIN --------- timestamp: 106665.961430398 exception: Traceback (most recent call last): File "/home/matthias/tf/dev/brickv/src/brickv/bindings/ip_connection.py", line 992, in receive_loop raise Exception('a') Exception: a data_counter: 19 data_history: [ (0, 106663.574052653, 68, b' %\xf6\xc8"\xfd\x08\x0068WcDS\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\x04\r\x00\x00\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00'), (1, 106663.574205742, 68, b'\xd6z\x00\x00"\xfd\x08\x00amb\x00\x00\x00\x00\x0068WcDS\x00\x00b\x01\x01\x00\x02\x00\x03\x15\x00\x00\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00'), (2, 106663.574246151, 34, b'i\xe1&""\xfd\x08\x00SCD32\x00\x00\x0068WcDS\x00\x00d\x01\x02\x00\x02\x00\x06\xd4\x00\x00'), (3, 106663.579172704, 9, b' %\xf6\xc8\t\x058\x00\x00'), (4, 106663.580263621, 9, b' %\xf6\xc8\t\x12H\x00\x00'), (5, 106663.580755935, 9, b' %\xf6\xc8\t\x1aX\x00\x00'), (6, 106663.581016582, 9, b' %\xf6\xc8\tAh\x00\x00'), (7, 106663.581347659, 9, b' %\xf6\xc8\tNx\x00\x00'), (8, 106663.581620615, 9, b' %\xf6\xc8\tM\x88\x00\x01'), (9, 106663.604665966, 16, b'i\xe1&"\x10\x0c\x98\x00\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa'), (10, 106665.059943865, 10, b'\x90>J\xbd\n\x01\xa8\x00e\x01'), (11, 106665.160133984, 10, b'\x90>J\xbd\n\x01\xb8\x00d\x01'), (12, 106665.260356932, 10, b'\x90>J\xbd\n\x01\xc8\x00d\x01'), (13, 106665.360479232, 10, b'\x90>J\xbd\n\x01\xd8\x00e\x01'), (14, 106665.460632221, 10, b'\x90>J\xbd\n\x01\xe8\x00e\x01'), (15, 106665.56087381, 10, b'\x90>J\xbd\n\x01\xf8\x00e\x01'), (16, 106665.661021859, 10, b'\x90>J\xbd\n\x01\x18\x00d\x01'), (17, 106665.76111894, 10, b'\x90>J\xbd\n\x01(\x00e\x01'), (18, 106665.861319748, 10, b'\x90>J\xbd\n\x018\x00e\x01'), (19, 106665.961430398, 10, b'\x90>J\xbd\n\x01H\x00e\x01'), ] packet_history: [ (0, 0, 106663.574052653, 34, 34, b' %\xf6\xc8"\xfd\x08\x0068WcDS\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\x04\r\x00\x00', b'\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00'), (0, 1, 106663.574052653, 34, 34, b'\x90>J\xbd"\xfd\x08\x005QCAEd\x00\x0068WcDS\x00\x00a\x01\x01\x00\x02\x00\x02\x1b\x00\x00', b''), (1, 2, 106663.574205742, 34, 34, b'\xd6z\x00\x00"\xfd\x08\x00amb\x00\x00\x00\x00\x0068WcDS\x00\x00b\x01\x01\x00\x02\x00\x03\x15\x00\x00', b'\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00'), (1, 3, 106663.574205742, 34, 34, b'\xe2\x90\x01\x00"\xfd\x08\x00wvq\x00\x00\x00\x00\x0068WcDS\x00\x00c\x01\x00\x00\x02\x00\x02\xdd\x00\x00', b''), (2, 4, 106663.574246151, 34, 34, b'i\xe1&""\xfd\x08\x00SCD32\x00\x00\x0068WcDS\x00\x00d\x01\x02\x00\x02\x00\x06\xd4\x00\x00', b''), (3, 5, 106663.579172704, 9, 9, b' %\xf6\xc8\t\x058\x00\x00', b''), (4, 6, 106663.580263621, 9, 9, b' %\xf6\xc8\t\x12H\x00\x00', b''), (5, 7, 106663.580755935, 9, 9, b' %\xf6\xc8\t\x1aX\x00\x00', b''), (6, 8, 106663.581016582, 9, 9, b' %\xf6\xc8\tAh\x00\x00', b''), (7, 9, 106663.581347659, 9, 9, b' %\xf6\xc8\tNx\x00\x00', b''), (8, 10, 106663.581620615, 9, 9, b' %\xf6\xc8\tM\x88\x00\x01', b''), (9, 11, 106663.604665966, 16, 16, b'i\xe1&"\x10\x0c\x98\x00\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa', b''), (10, 12, 106665.059943865, 10, 10, b'\x90>J\xbd\n\x01\xa8\x00e\x01', b''), (11, 13, 106665.160133984, 10, 10, b'\x90>J\xbd\n\x01\xb8\x00d\x01', b''), (12, 14, 106665.260356932, 10, 10, b'\x90>J\xbd\n\x01\xc8\x00d\x01', b''), (13, 15, 106665.360479232, 10, 10, b'\x90>J\xbd\n\x01\xd8\x00e\x01', b''), (14, 16, 106665.460632221, 10, 10, b'\x90>J\xbd\n\x01\xe8\x00e\x01', b''), (15, 17, 106665.56087381, 10, 10, b'\x90>J\xbd\n\x01\xf8\x00e\x01', b''), (16, 18, 106665.661021859, 10, 10, b'\x90>J\xbd\n\x01\x18\x00d\x01', b''), (17, 19, 106665.76111894, 10, 10, b'\x90>J\xbd\n\x01(\x00e\x01', b''), (18, 20, 106665.861319748, 10, 10, b'\x90>J\xbd\n\x018\x00e\x01', b''), ] packet_counter: 21 packet: 10 10 b'\x90>J\xbd\n\x01H\x00e\x01' pending_data: 0 b'' ---------- END ---------- ip_connection.py

Python API bindings version 2.1.24 is now available.

Bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Go 2.0.5, Java 2.1.25, JavaScript 2.1.25, LabVIEW 2.1.24, Mathematica 2.1.24, MATLAB/Octave 2.0.25, MQTT 2.0.8, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Rust 2.0.13, Shell 2.1.24, Visual Basic .NET 2.1.24 Add set/get-voltages-callback_configuration functions and voltages callback to HAT Brick API [all] Add set/get-usb-voltage-callback-configuration functions and usb-voltage callback to HAT Zero Brick API [all] Add set/get-statistics-callback-configuration functions and statistics callback to Isolator Bricklet API [all] Report error if authentication secret contains non-ASCII chars [all] Don't silently ignore stream-out-of-sync errors in callbacks [Go] Replace BrickletError with DeviceError [Go] Don't use deprecated Buffer constructor if possible [JavaScript] Log Brick Daemon (dis)connects under --debug [MQTT] Use stable order for init-file lines [MQTT] Fix symbol translation of IP Connection callbacks [MQTT] Report all errors when reading init-file [MQTT] Add pre/post_connect init-file format [MQTT] Add get_connection_state to IP Connection [MQTT] Add last will (sent if the API bindings crash) and shutdown messages [MQTT] Correctly reset registered callbacks [MQTT] Handle SIGTERM/SIGQUIT [MQTT] Fix handling of character arrays [MQTT] Fix names of high-level-callback members [MQTT] Fix some error format strings in IPConnection class [Python] Fix Python 3 compatibility [Shell] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Sobald du einmal über Brick Viewer die WLAN Verbindung konfiguriert hast sollte sich RED Brick danach von selbst wieder mit dem WLAN verbinden, ohne das du etwas dafür tun musst. Aus deiner Beschreibung geht nicht hervor, ob das der Fall ist. Musst du nach jedem Boot des RED Bricks wieder über den Network Tab im Brick Viewer die Verbindung händisch herstellen, oder funktioniert das doch automatisch?

Bindings: C/C++ 2.1.27, C# 2.1.25, Delphi/Lazarus 2.1.26, Go 2.0.5, Java 2.1.25, JavaScript 2.1.25, LabVIEW 2.1.24, Mathematica 2.1.24, MATLAB/Octave 2.0.25, MQTT 2.0.8, Perl 2.1.25, PHP 2.1.24, Python 2.1.24, Ruby 2.1.24, Rust 2.0.13, Shell 2.1.24, Visual Basic .NET 2.1.24 set/get-voltages-callback_configuration Funktions und voltages Callback zu HAT Brick API hinzugefügt [alle] set/get-usb-voltage-callback-configuration Funktions und usb-voltage Callback zu HAT Zero Brick API hinzugefügt [alle] set/get-statistics-callback-configuration Funktions und statistics Callback zu Isolator Bricklet API hinzugefügt [alle] Authentication Secret darf nur ASCII Zeichen enthalten [alle] Stream-Out-Of-Sync Fehler werden in Callbacks nicht mehr still ignoriert [Go] BrickletError durch DeviceError ersetzt [Go] Wenn möglich wird kein veralteter Buffer Konstruktor verwendet [JavaScript] Brick Daemon Verbindungen werden ins Log geschrieben, wenn --debug aktiviert ist [MQTT] Init-File Zeilen werden in stabiler Reihenfolge eingelesen [MQTT] Symbol-Abbildung für IP Connection Callbacks korrigiert [MQTT] Alle Fehler beim Lesen des Init-Files werden auch gemeldet [MQTT] pre/post_connect Einträge zum Init-File-Format hinzugefügt [MQTT] get_connection_state zur IP Connection hinzugefügt [MQTT] Last-Will (wird gesendet falls die API Bindings abstürzen) und Shutdown Nachrichten hinzugefügt [MQTT] Registrierte Callbacks werden korrekt zurückgesetzt [MQTT] SIGTERM/SIGQUIT Signals werden behandelt [MQTT] Behandlung von Character Arrays korrigiert [MQTT] Namen von High-Level-Callback Feldern korrigiert [MQTT] Einige Error-Format-Strings in der IPConnection Klasse korrigiert [Python] Python 3 Kompatibilität repariert [Shell] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Did you start you test with the IMU Brick in green calibration state, see: https://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_V2_Brick.html#calibration Do you have anything near to the IMU Brick that produces a (changing) magnetic field? For example, try to stay away from monitors even modern TFT ones. Try moving the IMU Brick near to a running monitor without rotating it and see that the orientation will rotate due to the magnetic fields of the monitor.

Hast du am Monitor beide HDMI Eingänge getestet? Hast du versucht die Bildquelle am Monitor händisch auszuwählen? Hast du irgend einen anderen Monitor mit dem du testen könntest?

Sorry, I didn't manage to finish the release today. It'll be released on Monday.

Der Fehler kommt von einem kaputten Paket. Die IP Connection versucht da ein Paket zu dekodieren, das einen falschen Wert im Längenfeld stehen hat. Das sollte eigentlich nicht passieren können. Ich habe dir eine modifizierte IP Connection angehängt. Diese speichert die letzten 1000 byte empfangene Daten zwischen und gibt diese auf die Standardausgabe aus, wenn der Fehler auftritt. Nutze bitte diese IP Connection in deinem Programm, erzeuge das Problem nochmal und poste die Ausgabe hier. Das wird dann etwa so aussehen, nur länger: EXCEPTION 1574431120.7630146 b'1p\xb6\xc0"\xfd\x08\x005VGUhR\x00\x000\x00\x00\x00\x00\x00\x00\x000\x02\x01\x00\x02\x04\n\r\x00\x00' Daraus sollte ich dann genauer ableiten könne was das Problem erzeugt. ip_connection.py

Was ist das denn für ein Monitor (Marke und Modell)? Stell bitte sicher das der Monitor eingeschaltet ist bevor du dem RED Brick Strom gibst. Einen Monitor an einen laufenden RED Brick anzuschließen kappt nicht immer. Verwendest du unser HMDI Kabel für den RED Brick? Leuchten die LEDs am RED Brick? Nach dem du Strom angeschlossen hast sollte sollte die blaue dauerhaft leuchten. Die rote sollte kurz aufleuchten und dann wieder ausgehen. Die grüne sollte kurz darauf angehen und etwas später anfangen zu blinken. Wenn dies nicht der Fall ist, dann bootet der RED Brick nicht richtig.

Was für Bricks und Bricklets verwendest du?