Posts by obelix

    Danke für den Patch :respekt Ich habe gerade unter Manjaro den Patch ins PKGBUILD eingebaut und es funktioniert. :tup


    Das Fußballspiel Deutschland - Frankreich kann beginnen.


    :vdr1


    Gruß

    Obelix

    Das noch: Bei easyvdr3 musste noch Policykit leicht modifiziert werden, damit es mit den User vdr und easyvdr und unmounten in Kodi klappt:


    /usr/share/polkit-1/actions/org.freedesktop.udisks.policy:

    Standard ist allow any auf no.


    Gruß

    Obelix

    Ich habe aktuell kein easyvdr5 im Zugriff aber mit easyvdr3 und einem Desktop (bei mir LXDE) ist da schnell umgesetzt gewesen:


    /etc/usbmount/usbmount.conf


    Code
    1. # Change to zero to disable usbmount
    2. ENABLED=0


    Über das Toolmenu "easyvdr-lxde" installiert, reboot. Fertig. Ich hatte das auch mit XFCE getestet und da hat es auch funktioniert.


    Gruß

    Obelix

    So, der STM32 China Böller (RedLinkCrap mit CKS32) ist gegen einen RobotDyn (BluePill) ausgetauscht. Das so am Rande.


    Zurück zum eigentlichen Thema. Mir ist aufgefallen, dass der Pi die Option


    Code
    1. dtoverlay=gpio-shutdown,gpio_pin=3, active_low=1,gpio_pull=up

    in der config.txt nicht mehr benötigt. WakeUp funktioniert OOTB. D.h. ich habe ein sauberes Libreelec 9.6.0 Image installiert. Den WakeUp Anschluss SCK vom RobotDyn mit 220 Ohm Widerstand an den GPIO 3 (Pin 5) vom Raspberry Pi 4 verbunden und fertig. WakeUp funktioniert mit der angelernten Taste.


    Ich bin kürzlich über das Projekt uhubctl gestolpert und habe es gerade ausprobiert:


    Quote

    uhubctl is utility to control USB power per-port on smart USB hubs. Smart hub is defined as one that implements per-port power switching.

    Mit dem Befehl lässt sich die Stromversorgung eines USB Ports / USB Hubs schalten. Ich habe den Befehl in die shutdown.sh gepackt


    und der Arduino wird ausgeschaltet.


    Was die Schaltung von Argus angeht, habe ich mir ein Breadboard geordert und werde die Schaltung damit aufbauen und dann den Fehler in meiner gelöteten Variante suchen....

    So, ich habe mir für meine Raspberry Spielwiese einen RobotDyn (BlueDev) gelötet. Der RobotDyn in meinem M3d1@Pi hat die Firmware Version 2019-07-04_01-31_blueDev_BL_SC_KBD_jrie.bin und da ist die Steuerleitung vom IR Empfänger an B9. Mit 2020er Versionen hast du was geändert? Es funktioniert nämlich an B9 nicht mehr und wenn ich in der config.h nachschaue, steht da A13 für IR_IN. A13 gibt es beim RobotDyn nicht.

    An welcher Stelle misst du die 0,5V bzw. 1,2 bis 1,5V? Was misst du dort ohne Tastendruck?

    Welche Firmware hast du in #158 benutzt? Ist der andere Stick auch ein CKS32?

    Was ist zwischen dem Stick und dem Pi?

    Falls es beides CKS32 sind, passiert das auch auf einem STM32?

    Sind beides CK32. An die Bezeichnung gewöhne ich mich einfach nicht. Ich messe die Spannung am Pin 6 (SWCLK) nach dem Widerstand gegen GND. Ohne Tastendruck sind es 0V. Nein die Firmware aus #158 habe ich nicht getestet, da ein Stick mit IRMP Firmware das gleiche Verhalten zeigt.


    Ein Test mit einem STM32 mache ich....

    Hi. Ich habe gerade festgestellt, dass ich hier ja auch noch eine Baustelle offen habe :saint:. Den von dir angesprochenen gründlichen Test mache ich noch. Ich bin über ein seltsames Phänomen mit dem RedCrap Stick und mit der Firmware #148 gestolpert. Der erzeugt auch Wakeup Signale beim drücken von normalem Tasten. Aufgefallen ist es mir, als ich die OK Taste drückte und mein Bastel Pi ist aufgeweckt....


    Ich habe ein Multimeter dazwischen geklemmt und festgestellt, dass ein normaler Tastendruck 0,5V erzeugt und das reicht, damit der Pi aufweckt. Die definierte Wakeup Taste erzeugt zwischen 1,2 und 1,5V.


    Sollte das ein Firmware Thema sein, oder eher der Stick ?

    Ok, das werde ich machen. Allerdings bin ich gerade bei dem 4er Pi mit der neusten Firmware darüber gestolpert, dass egal ob die Option


    Code
    1. dtoverlay=gpio-shutdown,gpio_pin=3, active_low=1,gpio_pull=up

    gesetzt ist oder nicht, der Pi sich einschalten lässt. Des Weiteren habe ich ein seltsames Phänomen mit einem STM32 China Stick... Zu viele Baustellen....


    Melde mich.

    hallo,

    beim Ein/Aus Schalter ging es doch um den RPI4? Wenn ich mich recht erinnere, gabs da doch was mit dem neuen Powermanagement des RPI4 und dem abschalten der internen Baugruppen. Haben alle Ausgangs GPIOs weiterhin Potential nach dem Abschalten? Und ändert sich was, wenn Du im abgeschalteten Zustand testweise die o. erwähnten 10KOhm jeweils vom Ausgangspin nach Masse klemmst?


    Gruß Frank

    Hi,

    der Pi lässt sich über den STM32 per Lirc, entsprechendem config.txt Eintrag und Firmware Update einschalten. Das ist kein Thema.


    Das Problem war und ist, dass wenn diese Option gesetzt ist, der Arduino über den USB Port weiterhin mit Strom versorgt wird. Ich Schalte über meine kleine Schaltung (Low-Side Switch) den Lüfter ein und aus und da meine kleine Schaltung das leistungstechnisch nicht packt, hattest du mir die High-Side Schaltung erstellt, um über den GPIO14 vom Pi die 5V für den Arduino und den Lüfter zu schalten.

    Ich habe die Schaltung fertig und gerade getestet. Ich habe allerdings einen Fehler eingebaut, da ich sobald ich GPIO abschalte, weiterhin 4,66 V am Ausgang habe.... :huh:

    Danke euch für die Infos. Die Schutzschaltung habe ich mir mal gespeichert. GND und 5V+ hatte ich nicht vertauscht. Auch keine Überspannung. Am Nano und am Pixel waren die Kontakte richtig. Ich hatte die Wahrnehmung, dass es gerochen hat....


    Nach der Korrektur der Durchflussrichtung funktioniert alles tadellos. Ärgerlich ist ja, dass die Durchflussrichtung auf den NeoPixel markiert ist und ich sie entsprechen zurechtgelegt hatte ....


    https://elektro.turanis.de/html/prj240/index.html



    Hi,

    ich bin dabei, die Schaltung von Argus zu integrieren. Dafür möchte ich das unter Laborbedingungen testen und nicht gleich fest verbauen. Ich habe mir dafür einen weiteren Arduino Nano mit NeoPixel LEDs zusammengebaut. Die NeoPixel wollten einfach nicht funktionieren, bis ich dann irgendwann bemerkt habe, dass ich nicht auf die Durchflussrichtung geachtet habe :wand Kurzum: Kann beim verwechseln der Durchflussrichtung was kaputt gehen?


    Gruß

    Obelix

    probiere mal alle Stromsparmaßnahmen abzuschalten. Ansonsten Buffer und Latenzen im Treiber erhöhen.

    Die beiden Parameter


    Code
    1. echo 2048 > /sys/class/rtc/rtc0/max_user_freq
    2. echo 2048 > /proc/sys/dev/hpet/max-user-freq

    haben zumindest mit Kodi bei meinem Notebook zum Erfolg geführt. Die Tonausgabe zum Beispiel mit dem Chromium Browser knistert weiterhin.