photron

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?

https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#red-brick-web-interface

Brick Viewer 2.4.6 Fix message box explosion for color gradient with one LED in LED Strip Bricklet 2.0 plugin Only check WIFI Extension 2.0 AP password length if password is changed Downloads: Windows, Linux, macOS

Brick Viewer 2.4.6 Dialogbox-Explosion für Color-Gradient mit einer LED im LED Strip Bricklet 2.0 Plugin entfernt WIFI Extension 2.0 AP Password-Längenprüfung wird nur durchgeführt, wenn das Password geändert wird Downloads: Windows, Linux, macOS

Alle Programme die du über den Brick Viewer auf den RED Brick lädst werden mit dem Nutzer tf ausgeführt. Eine Möglichkeit ist es sudo das Password per Kommandozeile zu übergeben: echo tf | sudo -S -p "" rm /var/log/brickd.log Dazu das Password tf per echo ausgeben und sudo mit der -S Option das Password von stdin lesen lassen. Die -p "" Option unterdrückt das Password Prompt von sudo.

Okay, that means that the RED Brick did not fully boot up. This can be an issue with the SD card itself or the file system on the SD card. If you don't have any important data stored on the SD card then you could try flashing a fresh RED Brick image to the SD card: https://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#copy-image-to-sd-card Alternatively, if you have another SD card similar to the RED Brick one then you could try flashing a fresh RED Brick image to that SD card instead.

Please check if the three LEDs on the RED Brick light up in the documented sequence: https://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#leds If they don't, what's the sequence you're seeing when you power up the RED Brick?

Das Log ist voller Debug Nachrichten. Das ist nicht die Standardeinstellung. Normalerweise werden nur Info, Warn und Error Nachrichten geloggt. Schau mal im Brick Viewer RED Brick Tab unter Settings -> Brick Daemon nach. Da sollte Log Level auf Info stehen. Ich erwarte, dass dort bei dir Debug steht. Wenn du das auf Info zurückstellst, dann hört auch das brickd.log auf so schnell zu wachsen.

Hast du den Brick Daemon auf deinem Windows PC oder dem RED Brick aktualisiert?

Das Logfile sollte nicht so explodieren. Kannst du mal so ein Logfile zeigen, damit ich verstehen kann was da passiert?

Wenn dir die 8 bzw. 4 Brickletanschlüsse des HAT (Zero) Bricks auf Dauer nicht reichen, dann kannst du natürlich zusätzlich immer noch weitere Master Bricks über USB zusätzlich zum HAT (Zero) Brick anschließen.

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.