photron

Okay, dass sieht erstmal gut aus. Der RED Brick hat also ordentlich Netzwerkverbindung. Was du da jetzt nicht getestet hast, ist, ob du vom Laptop den RED Brick pingen kannst. Da es aber in die andere Richtung geht, sollte das auch funktionieren. Da du den RED Brick per USB erreichen kannst muss der Brick Daemon grundsätzlich laufen. Aber über Netzwerk ist Brick Daemon nicht erreichbar. Netzwerk funktioniert aber. Daher bleibt nur das Brick Daemon nicht richtig aufs Netzwerk lauscht. Verbinde dich bitte mal per USB mit dem RED Brick und überprüfe die Brick Daemon Config auf dem RED Brick -> Settings -> Brick Daemon Tab. Dort muss die Listen Address auf 0.0.0.0 und der Port auf 4223 stehen. Wenn das nicht der Fall ist dann stellt das bitte mal so um und bestätige das mit dem Save Knopf unten rechts. Falls das nicht das Problem löst, dann zeig mal bitte das brickd.log vor. Das kannst du über den RED Brick -> Import/Export -> System Logs herunterladen.

Brick Viewer 2.4.5 Improve GUI and error handling of RS485 Bricklet plugin Improve WIFI Extension 2.0 configuration validation Handle spectrum stream-out-of-sync error for Sound Pressure Level Bricklet Handle station/sensor loss for Outdoor Weather Bricklet Don't trigger overview updates while RED Brick plugin is not visible Fix duplicated async-reads in RED Brick plugin script manager Enable Retina mode on macOS Fix upload of empty files to RED Brick Fix timezone setting for RED Brick Make WIFI Extension 2.0 flashing more robust by increasing the number of bootloader connection attempts Downloads: Windows, Linux, macOS

Brick Viewer 2.4.5 GUI und Fehlerbehandlung des RS485 Bricklet Plugin überarbeitet WIFI Extension 2.0 Konfigurationsprüfung verbessert Spektrum Stream-Out-Of-Sync Fehler wird im Sound Pressure Level Bricklet Plugin korrekt behandelt Stations/Sensor-Verlust wird im Outdoor Weather Bricklet Plugin korrekt behandelt Overview-Updates werden nicht durchgeführt, wenn das RED Brick Plugin nicht sichtbar ist Es werden keine doppelten Async-Reads im RED Brick Plugin Script Manager ausgelöst Retina-Modus auf macOS aktiviert Hochladen leerer Dateien auf den RED Brick korrigiert Zeitzoneneinstellung auf dem RED Brick korrigiert WIFI Extension 2.0 Flashing ist robuster, durch erhöhte Anzahl an Bootloader-Verbindungsversuchen Downloads: Windows, Linux, macOS

Du kannst weiterhin ganz normal Bricks per USB am Raspberry Pi anschließen, auch gleichzeitig zum HAT.

Okay, der Brick Viewer Screenshot sieht gut aus. Wechsel in Brick Viewer mal auf den Console Tab des RED Brick und verbinde dich mit der seriellen Schnittstelle des RED Brick. Teste dort mal die WLAN Verbindung des RED Bricks in dem du vom RED Brick aus versuchst mal denen Laptop zu pingen. Und auch mal versuchst irgendwas im Internet wie google.de oder heise.de zu pingen.

Das die Host-Auswahl im Brick Viewer "red-brick" nicht anzeigt ist normal. In der Host-Auswahl listet der Brick Viewer die letzen 10 Hosts auf zu denen erfolgreich eine Verbindung aufgebaut werden konnte. Dass es selbst mit der IP-Adresse nicht geht ist komisch. Kannst du die IP-Adresse des RED Bricks vom Laptop aus pingen, oder geht selbst dass nicht? Hast du auf dem RED Brick DHCP gewählt oder die IP-Adresse statisch eingestellt? Wenn du sie statisch eingestellt hast, hast du dann in der Konfiguration vielleicht einen Fehler? Kannst du hier mal einen Screenshot von Brick Viewer mit den Netzwerkeinstellungen des RED Bricks zeigen?

Hast du mal die IP Adresse des RED Bricks anstelle des Hostnamens versucht? Was passiert, wenn du den RED Brick per USB an deinem Laptop angeschlossen lässt und dich dann versuchst mit Brick Viewer zu red-brick statt localhost zu verbinden?

That's very strange. For exactly this reason Brick Daemon links to @executable_path/libusb-1.0.dylib. There should be no confusion for the loader which libusb to load. Brick Daemon comes with its own libusb version that includes some brickd specific changes. So there is no point in trying to make this look like a vanilla libusb version anyway. I've changed libusb-1.0.dylib to libusb-1.0-brickd.dylib now. This should fix the problem. Please test the attached brickd version. brickd_macos_2_4_0_libusb_name.dmg

Das Problem ist jetzt in brickd 2.4.0 behoben.

Das Problem ist jetzt in brickd 2.4.0 behoben.

Ich kann an deinem Code so erstmal kein Problem finden. Ich bin dem "Status line contains non-ASCII character" Fehler noch mal nachgegangen. Der Aufbau einer WebSocket-Verbindung beginnt mit einem HTTP GET Request. Darin fragt Safari bei der WIFI Extension den Aufbau einer WebSocket Verbindung an. Darauf antwortet die WIFI Extension mit einem HTTP Response. Der "Status line contains non-ASCII character" Fehler besagt jetzt, dass in der Statuszeile des HTTP Response der WIFI Extension ein ungültiges Zeichen wäre. In der Statuszeile des HTTP Response steht immer dieser Text: HTTP/1.1 101 Switching Protocols Ich habe mir den WIFI Extension Firmware Code angesehen und kann da kein offensichtliches Problem finden, dass erklären würde, warum da nicht immer "HTTP/1.1 101 Switching Protocols" übertragen werden sollte. Ich habe das hier gerade nochmal getestet und mir auf Linux und macOS mit Wireshark die Kommunikation zwischen Browser und WIFI Extension angesehen. Das sieht aber alles exakt so aus wie es soll und funktioniert auch ohne Probleme. Das hilfreichste wäre, wenn du die Kommunikation mit Wireshark aufzeichnen könntest während das Problem auftritt, damit wir sehen können welche kaputte Antwort da wirklich kommt, wenn das Problem auftritt.

Ich hab mir die Library noch mal angesehen und der Deadlock mit der disconnect Methode ist noch da. Wenn ich den beheben, dann bleibt noch das Problem, dass das AllStatusLed_Loop_Example Beispiel sich auch nach dem Ende der main Methode nicht direkt beendet, sondern noch ein Stück weiter läuft. Das liegt daran, wie du den ExecutorService verwendest. Der hält das Programm noch eine Weile offen. Mir sind auch noch ein paar andere Kleinigkeiten aufgefallen. Ich habe die dazu auch GitHub mal einen Pull Request erstellt.

Brick Daemon 2.4.0 Add support for HAT (Zero) Brick (SPI connected Bricklets) Install Log Viewer start menu link for all users on Windows Add commandline options to override config, log and PID file location on Linux and macOS Remove accidental dependency to libusb 1.0.20 on Linux Replace Event Log usage with persistent log file on Windows Extend Log Viewer to start/stop brickd, view log file and edit config file on Windows Fix rare crash in WIFI Extension 2.0 mesh packet handling Add support for receiving multiple response packets per USB read transfer Update bundled libusb to 1.0.23-rc1 on Windows and macOS, this fixes problems with ROOT/SYSTEM/0001 USB hubs on Windows Bind to all IP addresses resolved from the listen.address config option, instead of just the first one Downloads: Windows, Linux (amd64, i386, armhf), macOS

Brick Daemon 2.4.0 Support für HAT (Zero) Brick (SPI-verbundene Bricklets) hinzugefügt Log Viewer Startmenu-Link wird für alle Benutzer auf Windows installiert Kommandozeilenoptionen zum überschreiben der Config-, Log- und PID-Dateipfade auf Linux und macOS hinzugefügt Unabsichtliche Abhängigkeit zu libusb 1.0.20 auf Linux entfernt Windows Event Log Nutzung durch dauerhafte Log Datei auf Windows ersetzt Log Viewer erweitert um Starten/Stoppen von brickd, Log-Datei-Anzeige und Config-Datei-Bearbeitung auf Windows Seltenen Absturz in der WIFI Extension 2.0 Mesh-Packet-Behandlung korrigiert Support für das Empfangen mehrerer Antwortpakete pro USB-Read-Transfer hinzugefügt Mitgelieferte libusb auf Version 1.0.23-rc1 auf Windows und macOS aktualisiert, dies behebt Probleme mit ROOT/SYSTEM/0001 USB Hubs auf Windows Bindet alle IP-Adressen zu denen die listen.address Config-Option aufgelöst wird, statt nur der ersten Downloads: Windows, Linux (amd64, i386, armhf), macOS

Bindings: Rust 2.0.11 Allow device construction with an IpConnectionRequestSender Download: Rust

Bindings: Rust 2.0.11 Device Constructor kann mit IpConnectionRequestSender aufgerufen werden Download: Rust

Richtig, die Winkelbestimmung mit dem Accelerometer Bricklet 2.0 geht davon aus, dass das Bricklet ruht und die Erdbeschleunigung misst. Der IMU Brick 2.0 kann das intern kompensieren. Dadurch kannst er die Lagewinkel auch in Bewegung korrekt bestimmen.

Einen Enumerate Available Callback kannst du ignorieren, wenn du das Device schon kennst. Einen Enumerate Connected Callback solltest du nicht ignorieren, da dieser dir anzeigt, dass das Device gerade gestartet ist und daher seine vorherige Konfiguration verloren hat.

Gib mal das enumeration_type Parameter des Enumerate Callbacks mit aus, um zu sehen, ob das ein Available oder Connected Enumerate Callback ist. Available bedeutet, dass das Enumerate angefordert wurde. Sprich, vielleicht hast du ein anderes Programm laufen, dass jede Minute ein Enumerate anfordert. Wenn du z.B. in Brick Viewer auf Connect klickst, dann fordert Brick Viewer in dem Zug auch ein Enumerate an. Connected bedeutet, dass das Enumerate vom Brick/Bricklet ausgelöst wurde. Sprich, es könnte sein, dass der Stapel jede Minute neustartet. Registriere auch mal den Connected und Disconnected Callback der IP Connection, um zu sehen ob dort Auto-Reconnects passieren. Das wäre ein Hinweis darauf, dass der Stapel jede Minute neustartet.

Teste mal bitte das angehängte Beispiel. Dort werden in der Callback-Funktion die Winkel ausgerechnet, genauso wie es Brick Viewer tut. matlab_example_pitch_roll_callback.m

Das ist schon das beste Vorgehen. Die einfache Variante ist, ein Enumerate per IPConnection.Enumerate() auszulösen und dann ab dann eine fixe Zeit zu warten. Die dynamische Variante ist nach jedem Enumerate Callback eine fixe Zeit darauf zu warten, dass kein weiteres Enumerate Callback mehr kommt. Das funktioniert robuster bei sehr großen Aufbauten.

Bindings: Perl 2.1.23 Fix UID decoding on RED Brick Download: Perl

Bindings: Perl 2.1.23 UID Dekodierung auf RED Brick korrigiert Download: Perl

Nutzt du dann Brick Viewer vom MacBook aus, indem du statt localhost den Hostname oder die IP Adresse des Raspberry Pis in Brick Viewer angibst? Sprich, die Timeouts treten nur dann auf, wenn der RED Brick per USB am MacBook angeschlossen ist? Es könnte also ein USB Problem zwischen MacBook und RED Brick sein. Kannst du hier bitte mal das Brick Daemon Log von deinem MacBook anhängen? Das liegt hier: /var/log/brickd.log

Alle diese Fehler haben die gleiche Ursache: Timeouts. Die Kommunikation zwischen Brick Viewer und RED Brick ist gestört, so dass nicht alle Nachrichten die sich Brick Viewer und RED Brick gegenseitig schicken auch ankommen. Aus deinem ersten Screenshot kann ich sehen, dass der RED Brick per USB an deinem MacBook angeschlossen ist. Daher wundert es mich etwas, dass du da so viele Timeouts hast. Hast du am RED Brick noch andere Bricks angeschlossen, oder ist der RED Brick alleine? Wenn der RED Brick nicht alleine ist, hilft es dann alles außer die USB Verbindung zum MacBook zu entfernen? Hast du schon irgendetwas am RED Brick verändert? Konfiguration umgestellt, Programme hochgeladen, etc.? Oder hast du den RED Brick frisch ausgepackt und angeschlossen? Verwendest du die SD Karte die wir zum RED Brick anbieten, oder verwendest du deine eigene SD Karte? Wenn du deine eigene SD Karte verwendest, dann ist diese vielleicht zu langsam.