photron

Es gab am Freitag ein Problem mit dem Bauen des Brick Viewers auf macOS. Dadurch hat sich die Veröffentlichung von Brick Viewer 2.4.7 auf heute verzögert, sorry.

Brick Viewer 2.4.7 Add support for Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0, Rotary Poti 2.0 and XMC1400 Breakout Bricklet Add Data Logger support for Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0 and Rotary Poti 2.0 Bricklet Fix latest firmware version discovery if no Internet connection is available Add interpolation and scale factor options to Thermal Imaging Bricklet plugin Download firmware files using HTTPS Updates/Flashing dialog can download Brick Viewer updates Fix WIFI Extension 2.0 flashing to fix web interface Don't try to use invalid IMU Brick calibration Don't crash if OpenGL is not available Correctly handle Modbus response with unknown request in RS485 Bricklet plugin Downloads: Windows, Linux, macOS

Brick Viewer 2.4.7 Support für Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0, Rotary Poti 2.0 und XMC1400 Breakout Bricklet hinzugefügt Data Logger Support für Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0 und Rotary Poti 2.0 Bricklet hinzugefügt Neuste-Firmware-Erkennung repariert wenn keine Internet-Verbindung besteht Interpolations- und Skalierungsoptionen zum Thermal Imaging Bricklet Plugin hinzugefügt Firmware-Dateien werden über HTTPS heruntergeladen Updates/Flashing-Dialog kann Brick Viewer Updates herunterladen Flashen der WIFI Extension 2.0 Firmware repariert um das Web-Interface zu reparieren Absturz durch ungültige IMU Brick Kalibrierung repariert Absturz durch fehlende OpenGL-Unterstützung repariert Modbus-Antworten ohne entsprechende Anfragen werden im RS485 Bricklet Plugin richtig behandelt Downloads: Windows, Linux, macOS

Bindings: C/C++ 2.1.26, C# 2.1.24, Delphi/Lazarus 2.1.25, Go 2.0.4, Java 2.1.24, JavaScript 2.1.24, LabVIEW 2.1.23, Mathematica 2.1.23, MATLAB/Octave 2.0.24, MQTT 2.0.7, Perl 2.1.24, PHP 2.1.23, Python 2.1.23, Ruby 2.1.23, Rust 2.0.12, Shell 2.1.23, Visual Basic .NET 2.1.23 Add support for Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0, Rotary Poti 2.0 and XMC1400 Breakout Bricklet [All] Add Get/SetFilterConfiguration functions to Accelerometer Bricklet 2.0 API [All] Add ConversionTime constants to Voltage/Current Bricklet 2.0 API [All] Fix misaligned array access in callback wrapper function [C/C++] Don't leak the get_random_uint32 symbol [C/C++] Break API to stop mixing object and function pointers for callback functions [C/C++] Allow to pass non-constant values to parameters with constants [Go] Break API to remove enumerate response structure: enumerate callback uses parameters directly, which is more in line with all other callbacks [Go] Increase minimum JDK version from 1.6 to 8 [Java] More robust connection handling [MQTT] Fix init file loading [MQTT] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Bindings: C/C++ 2.1.26, C# 2.1.24, Delphi/Lazarus 2.1.25, Go 2.0.4, Java 2.1.24, JavaScript 2.1.24, LabVIEW 2.1.23, Mathematica 2.1.23, MATLAB/Octave 2.0.24, MQTT 2.0.7, Perl 2.1.24, PHP 2.1.23, Python 2.1.23, Ruby 2.1.23, Rust 2.0.12, Shell 2.1.23, Visual Basic .NET 2.1.23 Support für Color 2.0, Compass, Distance US 2.0, Energy Monitor, Multi Touch 2.0, Rotary Poti 2.0 und XMC1400 Breakout Bricklet hinzugefügt [Alle] Get/SetFilterConfiguration Funktionen zur Accelerometer Bricklet 2.0 API hinzugefügt [Alle] ConversionTime-Konstanten zur Voltage/Current Bricklet 2.0 API hinzugefügt [Alle] Misalignte Array-Zugriffe in Callback-Wrapper-Funktionen korrigiert [C/C++] get_random_uint32 Symbol leakt nicht mehr [C/C++] API-Bruch um Objekt- und Funktions-Pointer für Callback-Funktionen nicht mehr zu vermischen [C/C++] Verwendung von nicht-Konstantenwerten für Parameter mit Konstanten erlaubt [Go] API-Bruch um die Enumerate-Antwort-Struktur zu entfernen: Enumerate-Callback verwendet direkt Parameter wie alle anderen Callbacks auch [Go] Minimum JDK Version von 1.6 auf 8 erhöht [Java] Robustere Verbindungslogik [MQTT] Laden der init Datei repariert [MQTT] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Die Fehler haben so erstmal nichts mit USB zu tun. Die USB Ready Pipe, um die es hier geht, ist ein interner Mechanismus in brickd um dem Event Loop mitzuteilen, dass es libusb Events gibt. Die Pipe besteht aus zwei miteinander verbundenen Sockets. Die Fehler die du da siehst, sind Connection Aborted und Connection Reset Fehler zwischen den beiden Sockets. Diese beiden Sockets sind aber nur intern in brickd verbunden und zu nichts externem. Mir ist unklar wie du diese Art von Fehlern bei diesen beiden Sockets haben kannst. Wenn ich raten müsste würde ich sagen, das brickd startet und dann Windows das Netzwerk Subsystem neustartet und das dann die interne Verbindung der beiden Sockets killt. Alternative hast du komische Virenscanner oder Firewalls installiert die dazwischenfunken. Tritt das Problem jedes mal auf? Bezüglich Log Rotation: Ich nehme das mal auf die TODO Liste auf.

Ich denke das hat nichts mit Brick Daemon oder Raspbian zu tun. Der Brick tauch als USB Device nicht auf, daher listet lsusb ihn nicht auf. Dadurch kann Brick Daemon ihn dann auch gar nicht finden. Daher auch keine Meldungen im brickd.log. Wenn beim Anstecken des Bricks an USB das Raspberry Pi neustartet, dann würde ich auf eine zu schwache Stromversorgung des Raspberry Pis tippen. Die zusätzliche Stromaufnahmen des Bricks lässt die Spannungsversorgung einbrechen. Alternative hat das Mini-USB-zu-Micro-USB-Kabel zwischen Brick und Raspberry Pi Zero eine Macke. Oder wie verbindest du die beiden? Ich bekomme hier gerade mein Raspberry Pi Zero nicht ins WLAN, daher kann ich das gerade nicht testen.

Führ den gleichen Test mit "dmesg | tail -n 30" bitte noch mal durch, ohne das dabei der Stick angeschlossen ist.

Leuchten die LEDs des Bricks, wenn du den Brick an das Raspberry Pi abschließt? Findet brickd den Brick am Raspberry Pi laut /var/log/brickd.log? Ändert sich die Ausgabe von "lsusb" auf dem Raspberry Pi zwischen der Brick ist an USB angeschlossen und der Brick ist nicht an USB angeschlossen? Was sagt "dmesg -w" auf dem Raspberry Pi wenn du den Brick an USB an- und absteckst? Da sollen beim An- und Abstecken Meldungen über das An- und Abstecken einen USB Devices kommen. Alternativ kommen da Fehlermeldungen zu USB.

Firmware: OLED 128x64 Bricklet 2.0 2.0.5 Make the clear-display function obey the automatic-draw config Download: LCD 128x64 Bricklet 2.0 2.0.5

Firmware: OLED 128x64 Bricklet 2.0 2.0.5 Die Clear-Display Funktion hält sich jetzt auch an die Automatic-Draw Einstellung Download: OLED 128x64 Bricklet 2.0 2.0.5

Kann ich hier nicht nachstellen. Mein IMU Brick 2.0 hier auf dem Tisch, zeigt einen absolute stabilen Gravitiy Vector. Hast du die aktuelle Firmware 2.0.14 auf dem Brick? Hast du Brick Viewer und den C Programm gleichzeigt laufen und sieht da die Unterscheide in den Werten, oder lässt du die nacheinander laufen?

RED Brick Image 1.14 Add Python 3 dependencies for Brick Viewer version >= 2.4.0 Update Brick Daemon to version 2.4.0 Update Brick Viewer to version 2.4.6 Add PIL for Python 2 and 3 Update all API bindings: C/C++ 2.1.25, C# 2.1.23, Delphi/Lazarus 2.1.24, Java 2.1.23, JavaScript 2.1.23, Octave 2.0.23, Perl 2.1.22, PHP 2.1.22, Python 2.1.22, Ruby 2.1.22, Shell 2.1.22, Visual Basic .NET 2.1.22 Download: RED Brick Image

RED Brick Image 1.14 Python 3 Abhängigkeiten für Brick Viewer version >= 2.4.0 hinzugefügt Brick Daemon auf Version 2.4.0 aktualisiert Brick Viewer auf Version 2.4.6 aktualisiert PIL für Python 2 und 3 hinzugfügt Alle API Bindings aktualisiert: C/C++ 2.1.25, C# 2.1.23, Delphi/Lazarus 2.1.24, Java 2.1.23, JavaScript 2.1.23, Octave 2.0.23, Perl 2.1.22, PHP 2.1.22, Python 2.1.22, Ruby 2.1.22, Shell 2.1.22, Visual Basic .NET 2.1.22 Download: RED Brick Image

Das Sound Intensity Bricklet und das Sound Pressure Level Bricklet sind da nicht so einfach zu vergleichen. Das alte Bricklet hat die Bestimmung der Intensity analog in Hardware gemacht. Das neue Bricklet macht die SPL Bestimmung digital in Software. Mit den verschiedenen Weighting wird versucht das menschliche Hörvermögen nachzubilden. Außer db(Z), dabei wird keine Gewichtung vorgenommen und die Daten vom Mikrofon unverändert verwendet. Ich habe gerade kein Sound Pressure Level Bricklet zur Hand, da die gerade ausverkauft sind. Daher mal ins Blaue: db(A) mit 256er FFT und dann über die Spektrumwerte einen Mittelwert bilden, dabei den ersten Wert im Spektrum ignorieren, da dies das DC Offset ist. Alternativ, schau dir das Spektrum in Brick Viewer an und nimmt dann den Teil des Spektrums der sich am meisten bewegt. Den fasst du dann über Maximum oder Mittelwert zusammen. Ich denke du musst da einfach mal verschiedenes ausprobieren.

In brickd 2.4.1 wird "After=network.target" enthalten sein. Version 2.4.1 ist aber noch nicht veröffentlicht und aktuell kann ich dir auch noch keinen Termin dafür nennen. Sprich, bei 2.4.0 musst du die Zeile händisch hinzufügen. Ab 2.4.1 dann nicht mehr.

Die *_register_callback Funktionen erwarten C Funktions-Pointer. Du versucht da aber einen Pointer auf eine C++ Methode zu übergeben. Der Unterschied zwischen einer C Funktion und einer C++ Methode ist der this Pointer. Der übliche Weg das zu regeln ist über den Umweg einer statischen C++ Methode, die wie eine C Funktion auftreten kann, da sie keinen this Pointer hat. Im angehängten Beispiel wird die statische C++ Methode cb_enumerate_static bei der IP Connection registriert und als user_data wird der this Pointer mitgegeben. Die cb_enumerate_static Methode nimmt dann den per user_data übergebenen this Pointer und ruft damit die C++ Methode cb_enumerate auf. example_enumerate.cpp

Zwischen diesen beiden Zeilen git clone https://github.com/Tinkerforge/daemonlib git reset --hard brickd-2.4.0 fehlt ein cd daemonlib und dann passt auch das cd .. wieder. Ist aber nicht so kritisch. Der Unterschied zwischen HEAD und brickd-2.4.0 im der daemonlib ist aktuell für deinen Fall nicht relevant.

Der Jetson Nano scheint arm64 Architektur zu sein. Dafür bieten wir aktuell kein vorgebautes Package an. Du kannst dort nicht das Package für die armhf Architektur (Raspberry Pi, RED Brick, ...) installieren. Du solltest aber selbst ein passendes Package bauen können. Führt mal diese Folge von Befehlen auf dem Jetson aus: sudo apt-get install git build-essential pkg-config libusb-1.0-0-dev git clone https://github.com/Tinkerforge/brickd cd brickd git reset --hard v2.4.0 cd src git clone https://github.com/Tinkerforge/daemonlib cd daemonlib git reset --hard brickd-2.4.0 cd .. python build_src.py sudo dpkg -i brickd-2.4.0_arm64.deb Das ist ungetestet, ich habe hier kein Jetson oder anderes arm64 Board zu Hand.

Okay, systemd startet brickd also noch bevor die /dev/ Einträge angelegt sind. Ein Service kann Abhängigkeiten auf /dev/ Einträge haben. Das würde die allgemeine brickd ARM Installation aber spezifisch für's Raspberry Pi machen. Ich habe jetzt erstmal für die nächste brickd Version das After=network.target eingefügt. Das hat eh gefehlt und abhängig von dem /dev/ Problem. Und wenn das auch das /dev/ Problem behebt, um so besser.

Teste mal bitte diese brickd.service Datei: [unit] Description=Brick Daemon After=network.target [service] Type=forking ExecStart=/usr/bin/brickd --daemon [install] WantedBy=multi-user.target Es könnte sein, dass systemd brickd startet bevor das Netzwerksubsystem läuft. Dann kann brickd keinen Socket öffnen und beendet sich wieder. Neu in dieser brickd.service Datei ist die After=network.target Zeile. Zeig auch mal bitte die /var/log/brickd.log Datei vor. Ich erwarte, dass brickd sagt, dass kein Socket gebunden werden kann und sich dann wieder beendet.

Hast du beim Sound Pressure Level Bricklet mal die verschiedenen Gewichtungen durchprobiert? Du solltest getSpectrum() Aufrufen, nicht getSpectrumLowLevel(). Das Spektrum ist zu groß um ein einem Packet übertragen zu werden. Die getSpectrumLowLevel() gibt das Spektrum in Stücken (Chunks) aus. Die getSpectrum() nutzt intern die getSpectrumLowLevel() Funktion und setzt das vollständige Spektrum aus Chunks zusammen. Wie die Dokumentation für die getSpectrum() Funktion beschreibt gibt dieses das Frequenzspektrum in form eines FFT aus. Daraus kannst du dir verschiedenste Darstellung ableiten.

The problem was that during flashing the WIFI Extension firmware, Brick Viewer did not configure the flash size for the ESP8266 module correctly (Python 2 vs Python 3 bug). This resulted in the web interface HTML/CSS/JS files being stored after the configured end of flash. This make the webserver on the WIFI Extension 2.0 unable to access those files, resulting in a 404. The bug was introduced in Brick Viewer 2.4.0 and will be fixed in Brick Viewer 2.4.7. Older or newer Brick Viewer versions are not affected. Thanks for reporting this problem.

You've found a bug. The problem seems to be that Brick Viewer since 2.4.0 doesn't flash the WIFI Extension 2.0 correctly anymore. If you use Brick Viewer 2.3.17 or older to flash the WIFI Extension 2.0 firmware then the Web Interface on port 80 works. I'll figure this out and this will be fixed in the next Brick Viewer version 2.4.7.

Ich nehme an, du hast auf dem Raspberry Pi 4 einen HAT Brick mit Bricklets angeschlossen. Das sieht bei mir in htop wie auf dem angehängten Bild aus. Das ist erwartet, da brickd durchgehend mit den angeschlossenen Bricklets kommuniziert. Auf dem Raspberry Pi 4 habe ich 2019-07-10-raspbian-buster-lite.img laufen. Wenn du keinen HAT Brick auf dem Raspberry Pi 4 hast dann sollte da auch keine signifikante CPU Last entstehen. Wie sieht denn dein Aufbau genau aus? Und wie genau sieht die CPU Last in htop aus? Hast du auf dem Raspberry Pi 4 die aktuelle Raspbian Version laufen?