photron

Did the PTC problem occur once or is it reproducible? What kind of power supply do you use to feed the black power input on the HAT Brick? Could the system be underpowered?

Do you run Raspberry Pi OS or Ubuntu at the moment? The -246.88 is the value you get if the sensor input on the PTC Bricklet 2.0 is shorted.

I tested Raspberry Pi 4 with Raspberry Pi OS with brickd 2.4.2 and "stress -c 4". I can see that the SPI clock is 2x faster than expected and there are errors in the brickd.log, but the error rate is still low enough that the error recovery mechanisms in brickd can deal with it. But this is not a recommended setup, it's barely working and on the edge to failing.

Yes, with brickd 2.4.2 the SPI frequency setting is broken in brickd and it might work for you under certain conditions, but might just fail under other conditions. Please test the attached snapshot versions of brickd in the post above. These have the SPI frequency setting logic fixed. In my tests here this works without problems with Ubuntu on Raspberry Pi 4. The original 2.4.2 version doesn't work there because the SPI frequency is way too high there because of a bug in brickd.

I've found the difference between Raspberry Pi OS and Ubuntu. Raspberry Pi OS scales down the core frequency to 200 if there is not much load on the CPU. Ubuntu keeps the core frequency at 500 all the time, resulting the SPI clock being to fast all the time.

Please test the attached brickd version with Ubuntu. The arm64 variant is for Ubuntu, the armhf variant is for Raspberry Pi OS. This version fixes the Problem for me with Raspberry Pi 4 and Ubuntu. There is no need to modify core_freq or anything else. This should work with an unmodified OS image. With this version you should not see these kinds of messages in the log file anymore: 2020-11-19 18:07:15.845333 <E> <bricklet_stack.c:396> Frame error (port: I, count: 33) 2020-11-19 18:07:15.853887 <E> <bricklet_stack.c:478> Message checksum error (port: I, count: 12) brickd_2.4.2+snapshot~7af86f9_armhf.deb brickd_2.4.2+snapshot~7af86f9_arm64.deb

Okay, the whole core_freq situation is way more complex. That it works for you with Raspberry Pi Os is just luck I think. Sorry, for the mess, I working on improving this situation. On RPi 4 core_freq can be 500, 550 or 360 depending on the TV-Out and HDMI config. The core_freq_min can be 250 or 275. The kernel will dynamically change the actual core frequency depending on the load. On RPi 1 and 2 core_freq and core_freq_min are fixed 250, no problem there. On RPi 0/W and 3A/B+ core_freq is 400 and core_freq_min is 250. In brickd 2.4.2 we switched to a new backend for SPI communication with the HAT (Zero) Brick. It seems that the old backend dealt correctly with this dynamic and higher core frequency, but the new one just assumes it to be fixed at 250 and fails in cases where core_freq is higher than 250.

Brick Daemon expects the Raspberry Pi core_freq to be 250, but with the Raspberry Pi 4 core_freq is 500 by default. The SPI clock is based on the core_freq. With a core_freq twice as fast as expected the SPI clock is also twice as fast. This is too fast for the Bricklets. This is a somewhat known problem. But our documentation doesn't cover this well. You can try forcing the core_freq to 250 in Ubuntu by editing /boot/firmware/config.txt and adding, but the Raspberry Pi documentation warns about doing this on a Raspberry Pi 4, as it might result in boot problems: core_freq=250 But this might affect other things that expect the core_freq to be 500. I'll fix this in brickd, to not assume the core_freq to be 250 when calculating the SPI clock, but read the actual core_freq value.

About the extra 5 seconds of data: From the output file it seems that there are full zero output line every full second when the fusion mode is changed. The extra 5 seconds of data don't have that. Also the recorded data has the expected sample timing of 10 milliseconds. To get this extra 5 seconds would require that the ipcon.disconnect() call is delayed by 5 seconds. But I don't see how that should happen. Could you record the value of the callbackTimer directly before and after the ipcon.disconnect() call to see when it's called and how long it takes in relation to the extra 5 seconds of data? Is this fixed 5 seconds of extra data, or is this times 2 of extra data? Could you replace the pause(1) calls with pause(2) calls to see if this gives you 15 or 20 seconds of recorded data in total?

Das Problem ist mit der aktuellen Brick Daemon Version 2.4.2 behoben und es sollten keine Workaround mehr notwendig sein. Die beste Lösung ist natürlich weiterhin die Firmware des HAT Bricks auf 2.0.2 oder neuer zu aktualisieren. Aber bei der Kombination Kernel 5.4, HAT Brick Firmware < 2.0.2 und Brick Daemon 2.4.2 tritt das Problem nicht mehr auf.

Brick Daemon 2.4.2 Properly shutdown subsystems on Ctrl+C instead of abruptly exiting on Windows Rotate persistent log file on Windows and limit its total size to 25 MB Add commandline options to override log and config file location on Windows Colorize Log Viewer live log messages on Windows Reword Log Viewer messages to be less ambiguous on Windows Add build option to work without a device file manager such as udevd on Linux Allow to handle more then 6 USB devices on Windows Use BCM2835 library for SPI connected Bricklets on Raspberry Pi to improve performance and work around SPI chip select conflict between Linux kernel 5.4 and HAT Brick firmware < 2.0.2 Improve log messages related to HAT (Zero) Brick on Linux Fix SPI hardware chip select usage on Linux Allow to fully static link brickd for Docker container usage on Linux Switch Debian package build to debhelper and drop SysV init support Improve USB transfer error logging and stall error recovery Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.2 Subsysteme werden ordentlich anstatt abrupt beendet bei Ctrl+C auf Windows Logdatei wird rotiert und auf 25 MB Gesamtgröße beschränkt auf Windows Kommandozeilenoptionen für Log und Config-Datei hinzugefügt auf Windows Log Viewer Live log Nachrichten werden farblich hervorgehoben auf Windows Log Viewer Nachrichten besser verständlich neuformuliert auf Windows Compile-Option hinzugefügt um ohne Device Manager wie udevd auszukommen auf Linux Unterstützung für mehr als 6 USB Geräte auf Windows Verwendet BCM2835 Bibliothek für SPI verbundene Bricklets auf Raspberry Pi um die Performance zu verbesser und einen SPI Chip Select Konflikt zwischen Linux Kernel 5.4 und HAT Brick Firmware < 2.0.2 zu umgehen Logmeldungen bezüglich HAT (Zero) Brick verbessert auf Linux SPI Hardware Chip Select Verwendung repariert unter Linux brickd kann für Docker Container Verwendung vollständig statisch gelinkt werden auf Linux Debian Packages werden mit debhelper ohne SysV Init Support gebaut USB Transfer Fehlermeldungen und Stall Fehlerbehandlung verbessert Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Es passiert da denke ich folgendes: Dein Programm wird gestartet, aber brickd hat noch nicht alle Bricklet gefunden. Dadurch sendet dein Programm jetzt die rotary_encoder_v2_set_count_callback_configuration Anfrage, diese wird aber in brickd verworfen, weil die UID noch nicht bekannt ist. Deswegen hilft es auch wenn du in deinem Programm am Anfang kurz wartest, weil du dann erst rotary_encoder_v2_set_count_callback_configuration aufrufst, wenn brickd alle Bricklets gefunden hat. Im Fehlerfall sollte rotary_encoder_v2_set_count_callback_configuration aber nicht 0 sondern -1 (Timeout) ausgeben, das verwundert mich etwas. Das eigentliche Problem ist, dass dein Programm gestartet wird bevor brickd bereit ist. Das Problem kannst du durch kurzes Warten in deinem Programm umgehen, ich nehme das aber auch mal auf die TODO Liste, das zu verbessern, so dass Programm nicht mehr zu früh gestartet werden.

Das bedeutet aber nicht, dass alleine dadurch die Antwort verloren gehen kann, sondern nur, dass, falls die Antwort ankommt, sie jetzt per Broadcast an alle geschickt würde, statt gezielt an den Anfragenden.

Du könntest über die API des RED Bricks das tun was Brick Viewer im Wizard intern tut. Wenn du dich aber vor Linux nicht scheust, dann ist es einfacher über einen systemd Service zu gehen, genau wie du das schon getan hast.

Brick Viewer 2.4.16 Reduce Qt requirement to 5.11 to fix crash on macOS Downloads: Windows, Linux, macOS

Brick Viewer 2.4.16 Qt Abhängigkeit auf 5.11 reduziert um Crash auf macOS zu beheben Downloads: Windows, Linux, macOS

Brick Viewer 2.4.15 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt Fehlerbehandlung und Fehlermeldung verbessert Support für Integrated GPU auf macOS hinzugefügt Downloads: Windows, Linux, macOS

Brick Viewer 2.4.15 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet Improve error handling and reporting Support running on integrated GPU on macOS Downloads: Windows, Linux, macOS

Brick Logger 2.1.4 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.4 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt Downloads: Windows, Linux, macOS, RED Brick

Bindings: C/C++ 2.1.30, C# 2.1.28, Delphi/Lazarus 2.1.29, Go 2.0.9, Java 2.1.29, JavaScript 2.1.31, LabVIEW 2.1.27, Mathematica 2.1.27, MATLAB/Octave 2.0.29, MQTT 2.0.12, Perl 2.1.28, PHP 2.1.27, Python 2.1.27, Ruby 2.1.27, Rust 2.0.16, Saleae 2.0.4, Shell 2.1.28, Visual Basic .NET 2.1.27 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet [All] Fix inline documentation syntax errors [Perl] Log API bindings version on start-up [MQTT] Fix timeout error handling [MQTT] Improve Python 2 compatibility [MQTT] Fix array handling in RS232 2.0 and RS485 Bricklet write functions [Octave] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET

Bindings: C/C++ 2.1.30, C# 2.1.28, Delphi/Lazarus 2.1.29, Go 2.0.9, Java 2.1.29, JavaScript 2.1.31, LabVIEW 2.1.27, Mathematica 2.1.27, MATLAB/Octave 2.0.29, MQTT 2.0.12, Perl 2.1.28, PHP 2.1.27, Python 2.1.27, Ruby 2.1.27, Rust 2.0.16, Saleae 2.0.4, Shell 2.1.28, Visual Basic .NET 2.1.27 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt [Alle] Syntaxfehler in der Inline Dokumentation behoben [Perl] API Bindings Version wird beim Start ausgegeben [MQTT] Timeout-Fehlerbehandlung repariert [MQTT] Python 2 Kompatibilität verbessert [MQTT] Array-Behandlung in RS232 2.0 aud RS485 Bricklet write Funktionen repariert [Octave] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET

Entweder du hast nicht ein ganzes Programm gezeigt, oder du rufst einfach deine channel_number() Funktion nicht auf.

Ja.