FB mit LIRC auf RasPi OK, auf PC nicht

  • Das am seriellen Port ankommende Signal ist noch OK, wie das beiliegende Bild vom Oszilloskop zeigt. Auch wenn ich die Taste nur kurz drücke und damit der "repeat" Code (rechts im Bild) nicht kommt, besteht das Signal aus dem Header, 32 Datenbits und dem abschließenden "trailing pulse". Der "trailing pulse" geht anscheinend irgendwo auf dem Weg vom seriellen Port zu LIRC verloren, bzw. wird erst weitergeleitet, wenn weitere Impulse kommen.


    Klaus

  • Linux vdr4 4.12.14-lp150.12.45-default

    Wenn ich micht recht entsinne, dann war das serial_ir modul im 4.12er noch etwas buggy.

  • Der letzte "-" müsste der trailing pulse sein oder ein Teil davon sein.

    Was fehlt ist dann eigentlich nur die Lücke. Merkwürdig, dass es nicht geht.


    Ein Vergleich mit dem RaspberryPi wäre aufschlussreich, wie es da auch aussieht.
    Bei unterschieden auch mal die nicht graphische mode2-Ausgabe mit den Signalzeiten vergleichen, dann weiss man genau, was da am Ende fehlt.

    "ptrail" könnte man testweise mal auskommentieren. Keine Ahnung das was da bringt, aber vielleicht gibt es zumindest eine andere Fehlermeldung.



    VDR berücksichtigt den Wiederholcounter durchaus. [...]

    Mir ist es jedenfalls nicht gelungen, es so einzustellen, dass x einzelne Tastendrücke die Funktion auch immer x mal ausführen und es trotzdem bei längerem Druck nicht zum nachlaufen kommt.

    Gegen doppelte Eingaben bei einem kurzen Tastendruck haben die beiden Einstellungen auch nicht geholfen, es sei denn ich hab sie so hoch gedreht, dass die FB unerträglich langsam wurde. "suppress_repeat" in der lircd.conf hat es dann gebracht.

    Gruss
    SHF


  • Wenn ich micht recht entsinne, dann war das serial_ir modul im 4.12er noch etwas buggy.

    Es ist doch immer wieder schön, wenn etwas, das lange Zeit gut funktioniert hat, durch etwas neues ersetzt wird, das erstmal nicht mehr funktioniert... :-(.


    Ich habe jetzt mal versucht, den neuesten Kernel zu installieren...

    Code
    1. /etc/zypp/zypp.conf:
    2. - multiversion.kernels = latest,latest-1,running
    3. + multiversion.kernels = latest,latest-1,running,oldest
    4. zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
    5. zypper dist-upgrade -r kernel-repo

    ...aber danach wird immer noch der alte Kernel gebootet.

    Und in /boot ist auch nur sehr wenig von einem Kernel 5.0.0 zu sehen:

    Mache ich etwas falsch?

    Oder gibt es eine Möglichkeit, lediglich das serial_ir Modul upzudaten?


    Klaus

  • Also, bei mir enden die Signale auch immer mit einem pulse.

    Das sollte also nicht das Problem sein.

    Ein kurzer Tastendruck, Code plus eine Wiederholung.

    ( -s kennt meine Version von mode2 nicht)


    Es ist doch immer wieder schön, wenn etwas, das lange Zeit gut funktioniert hat, durch etwas neues ersetzt wird, das erstmal nicht mehr funktioniert... :-(.

    Und wenn das dann endlich funktioniert, soll lirc durch rccore abgelöst werden.


    Zu SuSE und den Kerneln kann ich nichts sagen, da bin ich zu lange raus.

    4.12 ist aber schon länger EOL, merkwürdig, dass der noch läuft. Ich hätte da einen LTS-Kernel (4.9 oder 4.14) mit aktiven Support erwartet. Eventuell klappt da generell was mit den Updates nicht.

    http://download.opensuse.org/r…HEAD/standard/kernel-repo

    Der link geht im Browser zumindest mal nicht.

    Oder gibt es eine Möglichkeit, lediglich das serial_ir Modul upzudaten?

    Früher konnte und musste man die lirc-Module per out of tree bauen.

    Ob das noch immer geht, konnte ich nicht in Erfahrung bringen.

    Den Kernel upzudaten wird inzwischen aber die einfachere Option sein, schätze ich.

    Gruss
    SHF


    The post was edited 1 time, last by SHF ().

  • Sieht bei mir eigentlich auch so aus:

    Möglicherweise ist das, was da am Ende des von 'mode2 -s 500' dargestellten Diagramms zunächst fehlt und erst beim nächsten Tastendruck erscheint, ja dieser lange "space" zwischen den Tastendrücken. Das würde dann aber heißen, dass der Fehler im lircd passiert, was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...


    Klaus

  • Möglicherweise ist das, was da am Ende des von 'mode2 -s 500' dargestellten Diagramms zunächst fehlt und erst beim nächsten Tastendruck erscheint, ja dieser lange "space" zwischen den Tastendrücken.

    Ja, das ist der "space".

    Ich war nur nicht mehr sicher, ob der "space" erst mit dem nächsten Code kommt, oder ob er schon vorher, durch einen Timeout, kommen sollte.

    Aber das Verhalten ist so korrekt.


    Das würde dann aber heißen, dass der Fehler im lircd passiert,

    Das ist der logische Schluss.

    was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...

    Eventuell betrifft es nur spezielle Fernbedienungen (mit "trailing pulse"?).

    Die Erkennung geht ja bis zum "trailing pulse" korrekt.


    Hast du mal versucht "ptrail" auf genau 563 zu setzen?
    Wobei die geringe Abweichung eigentlich aufgefangen werden müsste.


    Was ich aber auch noch immer nicht verstehe ist, dass es bei längerem Tastendruck geht.

    Die FB sendet den Code ja nur einmal und dann den "repeat code". D.h. die Erkennung des Codes am Anfang muss funktioniert haben.

    Gruss
    SHF


  • Ich habe jetzt lircd mal mit -Dtrace2 gestartet. Die Ausgaben bei einem kurzen Tastendruck, bei dem irw keinen Code ausgibt, und einem längeren, bei dem ein Code ausgegeben wird, sind in den ersten 256 Zeilen, bis auf geringe Abweichungen in den pulse/space-Längen, gleich.

    Am Ende unterscheidet es sich aber:

    Er wartet anscheinend auf den "trailing pulse", aber dann kommt ihm ein Timeout dazwischen.

    Im "gut"-Fall bewirkt vielleicht die erste Flanke des auf den ersten Code folgenden Wiederholungscodes, dass der "trailing pulse" erkannt wird.


    Klaus

  • Das würde dann aber heißen, dass der Fehler im lircd passiert, was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...

    Ich nutze das Original LIRC von Leap 15.0 zusammen mit einem selbstkompilierten yausbIR Modul für LIRC. Das ist zwar noch nicht im produktiven Einsatz, funktioniert aber einwandfrei. Das Problem müsste sich dann auf das serial_ir-Modul beschränken.

    Hast Du mal den Quellcode des Moduls zwischen Raspi und Leap verglichen?


    Oder ein anderes LIRC RPM probieren? https://software.opensuse.org/package/lirc

  • Mich wundert das weniger, ich würde mir nie ein Board ohne kaufen.

    Diese "alten" Schnittstellen sind noch immer die einzige Möglichkeit, wenn es um Hardware nahe, direkte Ein- und Ausgabe geht. (Zumindest, wenn es sich preislich im Rahmen bleiben soll.)

    Die Schnittstellen selber sind dazu in allen Multi-IO-Bausteinen drin, Mehrkosten sind also nur die Stiftleisen.


    Heutzutage ist der gängigere Weg einen Mikrocontroller zwischen I/O und den USB Port zu bauen. Billig und im Zeitalter von Arduino auch nicht schwer zu erlernen.

  • Beim nächsten mal werde ich mir ein FLIRC-Modul kaufen, dass einfach eine Tastatur emuliert.

    Dann hast du aber manchmal Nachlauf.

  • Er wartet anscheinend auf den "trailing pulse", aber dann kommt ihm ein Timeout dazwischen.

    Timeout ist das Stichwort:

    https://github.com/torvalds/li…vers/media/rc/serial_ir.c

    (3. Commit von unten)

    Es ist also ein Kernel-Update angesagt.


    Das erklärt dann aber auch, warum nicht alle die Probleme haben. Das wird nur bei einigen "langsamen" FBs mit langen Codes Probleme machen.

    RC-5 ist beispielsweise so schnell, dass es praktisch unmöglich ist den Tasten-Code nur einmal zu senden.


    Wobei laut dem Link das "serial_ir"-Modul lediglich das umbenannte "lirc_serial" ist.

    Was dann bedeuten müsste, dass es auch da einige Versionen betreffen müsste, oder der Fehler erst ab der Änderung auftritt.

    Leider konnte ich auf die Schnelle keine Historie zu "lirc_serial" finden, das hätte mich schon interessiert.


    Heutzutage ist der gängigere Weg einen Mikrocontroller zwischen I/O und den USB Port zu bauen. Billig und im Zeitalter von Arduino auch nicht schwer zu erlernen.

    Das ist bei vielen Problemen auch eine gute Lösung.

    Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.

    Gruss
    SHF


    The post was edited 1 time, last by SHF ().

  • Leider konnte ich auf die Schnelle keine Historie zu "lirc_serial" finden, das hätte mich schon interessiert.


    Use the source, Luke:


    https://github.com/torvalds/li…/media/lirc/lirc_serial.c

    Quote

    Das ist bei vielen Problemen auch eine gute Lösung.

    Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.


    Zeitkritisch und PC?


    Wenn man einen Echtzeit-Linuxkernel mit in die Gleichung nimmt, dann könnte man vielleicht noch ein paar Spezialanwendungen finden, aber ein Standard-Linux inklusive all der Programme die um Rechenzeit auf der CPU konkurrieren ist von "Echtzeit" meilenweit entfernt.


    Bei allem was zeitkritisch ist, hat man eigentlich auch schon vor USB einen µC eingesetzt. Nur eben mit MAX232 für die RS232-Schnittstelle adaptiert. Ähnlich wie man es heute mit einem FT232RL macht um auf USB zu gehen.

  • Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.

    Sind dir Bruchteile von Millisekunden zu viel?


    Ich habe damals beim Entwickeln sogar mal gebenchmarkt, wieviel Zeit zwischen dem Senden von IR und dem Empfang liegt. Die genauen Zahlen weiß ich nicht mehr, aber es war so wenig, dass ich mich dann nicht mehr drum gekümmert habe.


    Im Verhältnis zur Länge eines Frames ist das vernachlässigbar.

  • Ja, bei IR ist das eher vernachlässigbar - wenn schon die Übertragung eines IR-Frames für einen Tastendruck im zweistelligen Millisekundenbereich liegt, kommt es auf die kleine Verzögerung von unter einer Millisekunde durch die USB-Übertragung kaum mehr an.


    USB-Eingaberäte mit Tasten bekommen einen guten Teil ihres Input-Lags (und den damit verbundenen schlechten Ruf) durch die fürs Debouncing benötigte Zeit (die Hersteller stecken da vergleichsweise wenig Aufwand rein) - wenn man es darauf anlegt, geht das deutlich flotter: https://michael.stapelberg.de/…kinx-keyboard-controller/).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Eine RC5 FB mit serial_ir funktioniert auf meinem x86_64 System erst, wenn ich "uinput" blackliste.

  • Eine RC5 FB mit serial_ir funktioniert auf meinem x86_64 System erst, wenn ich "uinput" blackliste.

    Lieber lircd-uinput.service deaktivieren, das Lirc-Paket für Debian ist da ziemlich übereifrig, was das aktivieren von Diensten angeht.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • So, jetzt habe ich eine (zumindest für mich brauchbare) Lösung gefunden.

    Nachdem 'mode2' wie hier gezeigt den "trailing pulse" tatsächlich - verzögerungsfrei - liefert, und dazu gar nicht durch den lircd geht, musste das Problem irgendwo im lircd liegen.

    Lasse ich lircd mit -Dtrace2 laufen, dann erhalte ich bei einem kurzen Tastendruck

    Die Zeile "Trace2: c564" stammt aus der Funktion rec_buffer_clear() in lib/receive.c. Unmittelbar davor wird readdata(0) aufgerufen, und dieser Aufruf liefert offensichtlich den erwarteten "trailing pulse", der dann auch als "<p564" erkannt wird, allerdings zu spät.


    Wenn ich nun dafür sorge, dass das readdata() in get_next_rec_buffer_internal() mit '0' aufgerufen wird, wenn der "trailing pulse" erwartet wird, dann läuft alles reibungslos ab.

    Dieser Patch erreicht das:

    Das ist zugegebenermaßen höchstwahrscheinlich nur ein schmutziger Workaround, der das eigentliche Problem vielleicht nicht löst. Aber um da tiefer einzusteigen fehlt mir das Verständnis dieser Strukturen, und auch die Zeit.

    Auf jeden Fall reagiert 'irw' damit auf kurze und lange Tastendrücke wie erwartet:

    Das Einzige, was etwas unschön ist: der letzte Repeat-Code (hier mit Counter 06) kommt mit etwas Verzögerung (gefühlt in der Größenordnung 100-200ms).


    Vielleicht hilft das ja jemandem, das tatsächliche Problem zu erkennen. Ich kann zumindest mal weitermachen.


    Klaus

  • Vielleicht hilft das ja jemandem, das tatsächliche Problem zu erkennen.

    Auch wenn ich es nicht ganz nachvollziehen kann, vermute ich, das das mit dem von mir o.ä. commit zusammenhängt.
    Da muss wohl ein Fehler bei Timeout drin gewesen sein, so dass readdata() zu lange auf wartet.



    Genau die Seite suchte ich verzweifelt! :respekt

    Jetzt musst du mit nur verraten, wie man da hin kommt.


    Die haben das gesamte Timing in dem Modul umgestellt, da wird sich wohl der Fehler mit eingeschlichen haben.




    Zu den Schnittstellen nur noch so viel:

    Primär verwende ich die noch für diese Bitbang-Programmierkabel und ähnliche Geschichten. Mit denen kann man viel machen für kleines Geld.

    Wenn es über USB gehen soll wird es deutlich teurer und/oder aufwändiger.

    Gruss
    SHF