IRMP auf STM32 - ein USB IR Empfänger/Sender/Einschalter mit Wakeup-Timer

  • Ok, Frage war nur für den Fall der Fälle.


    Gruß


  • Nochmal drüber nachgedacht, ich würde es bei den Sticks doch lieber lassen.

    Vermutlich nimmt das Mainboard die 5V USB entweder vom Standby des Netzteils oder vom 5V des Netzteils. Im ersten Fall hat man die Versorgung schon, im zweiten Fall gibt es einen Querstrom vom 5V Standby des Netzteils durch das Mainboard zum 5V des Netzteils.

    Das kann gut gehen oder auch nicht.

  • Eventuell ist das auch der Grund, warum Atric das über einen Jumper gelöst hat. Wäre halt für Boards interessant, die eigentlich noch funktionieren und man den Stick mit Wakeup benutzen möchte.


  • Darüber war mal was in der c't. Ich habe gerade mal im Archiv gestöbert:


    Strom von hinten


    Zitat: "Um die Rückspeisung zu verhindern, genügt im Prinzip eine wenige Cent teure (Schottky-)Diode. " Also müsste es doch funktionieren.....


  • Hier werden auch noch Varianten beschrieben:


    USB Host zu Device - Spannungsversorgung?


  • Nochmal drüber nachgedacht, ich würde es bei den Sticks doch lieber lassen.

    Vermutlich nimmt das Mainboard die 5V USB entweder vom Standby des Netzteils oder vom 5V des Netzteils. Im ersten Fall hat man die Versorgung schon, im zweiten Fall gibt es einen Querstrom vom 5V Standby des Netzteils durch das Mainboard zum 5V des Netzteils.

    Das kann gut gehen oder auch nicht.

    Ich habe noch einige Threads bei mikrocontroller.net zum Thema Schottky Diode gelesen. Wenn ich unser Thema mal pragmatisch betrachte, geht das bestimmt einfacher.

    Der ST-Link wird doch in der Regel intern über ein Mainboard-USB-Pfostenstecker-Adapter (USB Pinheader Buchse) angeschlossen. Wenn man nun an dem Pfostenstecker den +5V Pin herausnimmt (was ja möglich ist) und diesen über eine selbstrückstellende Sicherung an den +5V Standby vom ATX Netzteil anschließt, wäre man doch gekämmt und gebügelt. Oder sehe ich da was falsch?


  • In dem speziellen Fall wäre das sogar sauber, sofern man der auf den Sticks vorhandenen selbstrückstellenden Sicherung vertraut.

    Deshalb würde ich sicherheitshalber eine entsprechende PTC Sicherung dazwischen löten und Schrumpfschlauch drüber.


  • Sodele, auch wenn ich aktuell keinen Bedarf für die Lösung hatte, ich habe es an meinem Test VDR mal testweise umgesetzt. Funktioniert tadellos.


  • Hallo Jörg,

    ich hatte das in easyVDR eingebaut aber es hat nicht funktioniert. gitano hatte dazu einen Thread im easyVDR Forum aufgemacht, wo ich mich mal dran gehängt habe. Ich bekam eine Fehlermeldung beim Absetzten des Befehls.


    Code
    1. bash: Syntaxfehler beim unerwarteten Wort »(«


    Aaron ist aufgefallen, dass nur eine einfache Klammer genutzt wird und bei Berechnungen mit Variablen ist eine Doppelklammer notwendig. An dieser Stelle nochmal Danke an Aaron :). D.h. komplett sieht der Befehl für easyVDR so aus:


    Code
    1. /usr/share/vdr/shutdown-hooks/10_shutdown.custom:
    2. SHUTDOWNCMD=sudo /usr/bin/stm32IRalarm -d /dev/input/ir-auto_dtc -s $(($2 - 300)) && sleep 1; exit


    Gruß

    Obelix


  • Nabend. Ich habe hier ein sehr, sehr seltsames Phänomen unter easyVDR. Ich habe es bereits im easyVDR Forum gepostet aber man ist ebenfalls etwas ratlos.


    Vorab: Alternative Tests mit yaVDR waren erfolgreich. Alle getesteten Fernbedienungen funktionieren tadellos. Die Bedienung des VDRs zügig und geschmeidig.


    Mit easyVDR ist es genau das Gegenteil. Lediglich die Harmony 300 mit dem KLS 1.6 Profil funktioniert "fast". Sie ist stellenweise übersensibel. Fernbedienungen mit dem NEC Protokoll wollen so gut wie gar nicht. Bei Fernbedienungen mit dem NEC Protokoll funktionieren die Pfeiltasten vom Steuerkreuz, Kanal +/-, Lautstärke +/-. Mit funktionieren meine ich die Weitergabe an den VDR. irw zeigt bei allen Tasten und Fernbedienungen etwas an.


    Tests mit Kodi unter easyVDR waren erfolgreicher. Alle Fernbedienungen funktionieren. Ab und an prellen Tasten.


    Ich habe bereits die neuste Version von irmplircd aus dem Git erfolglos getestet. Irgendwie wird aus dem Ganzen kein Schuh draus.... =O;(


    Gruß

    Obelix


  • Wie ist denn im Vergleich dazu der Weg bei easyVDR?

    Hingen bei deinen Tests VDR bzw. Kodi am selben Sockel?

    Mit was für Parametern läuft irmplircd?

    Wie ist im VDR Repeat und Delay eingestellt?

    Zeige mal eine irw Ausgabe des Problems, dabei dieses irw benutzen mit diesem Fix.

  • Zitat

    Wie ist denn im Vergleich dazu der Weg bei easyVDR?

    eventlircd und lircd2uinput gibt es bei easyVDR nicht.


    Zitat

    Hingen bei deinen Tests VDR bzw. Kodi am selben Sockel?

    Kann nicht folgen...


    Zitat

    Mit was für Parametern läuft irmplircd?

    Standardmäßig läuft irmplircd:

    Code
    1. /usr/bin/irmplircd -r 150 -f -t /var/lib/vdr/irmp_keymap /dev/input/ir-auto_dtc

    allerdings gibt es keinen Unterschied, wenn man -r 150 weg lässt.

    Zitat

    Wie ist im VDR Repeat und Delay eingestellt?

    Dies kenne ich nur in der lircd.conf oder was meinst du?


    Zitat

    Zeige mal eine irw Ausgabe des Problems, dabei dieses irw benutzen mit diesem Fix.

    Bitte:



  • Kann nicht folgen...

    Beide an /var/run/lirc/lircd?!


    Den Fix hast du nicht angewendet, aber trotzdem ist zu sehen, dass der zweite Tastendruck 144ms nach dem Ersten kommt, und dann alle 108ms.


    allerdings gibt es keinen Unterschied, wenn man -r 150 weg lässt.

    Merkwürdig, das widerspricht den 144ms.


    oder was meinst du?

    Die setup.conf vom VDR.

  • Beide an /var/run/lirc/lircd?!

    Ja.


    Den Fix hast du nicht angewendet, aber trotzdem ist zu sehen, dass der zweite Tastendruck 144ms nach dem Ersten kommt, und dann alle 108ms.

    Ja, da muss beim Speichern etwas schief gegangen sein.



    Merkwürdig, das widerspricht den 144ms.

    Die Ausgabe war mit -r 150. Ohne war nur eine Anmerkung von mir. Ich erstelle zwei Neue mit dem Patch.


    Die setup.conf vom VDR.

    Da nutzt man schon so lange den VDR und kennt nicht alle Parameter :whistling:

    Code
    1. RcRepeatDelay = 300
    2. RcRepeatDelta = 100


    Hier die neue irw mit -r 150:



    Habe die -r 150 Option in der entsprechenden Konfigdatei entfern aber in ps- aux sehe ich sie noch. Eine Variante ohne müsste ich bei Bedarf heute Abend liefern.


    Gruß


  • Nun ist zu sehen, dass der zweite Tastendruck 252ms nach dem Ersten kommt, und dann alle 216ms. Das passt zu -r 150 beim alten irmplircd.

    Denn aus 144, 108, 108 108, ...

    wird

    144 +108 = 256

    108 +108 = 216

    108 +108 = 216

    ...


    Über das legt dann der VDR seinen Filter (300, 100) darüber.

    Daraus müsste dann folgendes werden:

    256 + 216 = 472

    216

    216

    ...


    Meine Empfehlung: Nimm das neue irmplircd, benutze -r und -s, und nimm 0, 0 statt 300,100 im VDR.

    Dann kannst du als Delay 144 oder 252 oder 360 oder 468 oder ... bekommen

    und als Period 108 oder 216 oder 324 oder ... .

    Also zum Beispiel -r 0 gibt 144, -r 150 gibt 252, -r 300 gibt 360.

    Und zum Beispiel -s 0 gibt 108, -s 150 gibt 216, -s 300 gibt 324.


    Auf einem System mit lircd2uinput und eventlircd wird's dann noch etwas komplizierter, da es da noch mehr Filter gibt.

    Daher ist es am Besten alles über irmplircd's -r und -s zu machen, und Alles, was danach kommt, so einzustellen, dass es nichts weiter darüber legt.


    Edit: Was ist das eigentlich für eine Fernbedienung? 108 = 3 * 36, 144 = 4 * 36, kannst du da auch was einstellen? Falls ja, kannst du die Wiederholung feiner auflösen.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • Wow, Respekt... Ich sehe da keinen Unterschied zwischen den beiden irw Ausgaben. Seawhawk1986 hatte mir in einem anderen Thread bezüglich Atric USB einiges mit mode2 erklärt.... Ist schon echt interessant...


    Ich teste das nachher....


    Die Fernbedienung ist eine Terratec Cinergy. Seahawk1986 hatte im Thread Atric IR-Wakeup USB ECO v1.2 Fernbedienung anlernen. Keine Wiederholrate. herausgefunden, dass es sich dabei um eine mit NEC Protokoll handelt.