Hast Du nen Vorschlag um das zu fixen?
Da passt der Funktionsname nicht (ist mir nicht aufgefallen, weil der Decoder mit der Harmony nie in diesen Abschnitt der Bedingung kommt) - ich hoffe das passt so: https://github.com/seahawk1986…9d03b23e73def9caedde38b59
Edit: ich sehe gerade da fehlt noch eine weitere Funktion - kannst du mir mal das genaue Modell deiner RC-6 Fernbedienung sagen, dann schau ich mal mit meiner Harmony, ob der Decoder dafür passt
So, die noch fehlende Funktion ist jetzt auch drin: https://github.com/seahawk1986…49f82e862611e788c55655386
Ich verwende diese Fernbedienung: http://www.amazon.de/gp/product/B009SNPYEM/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
Deine Anpassung werde ich nachher ausprobieren.
Claus
Ich hab's nun getestet.
Das Tool lässt sich nun starten und übersteht auch Tastendrücke. Nur leider passiert bei der RC-6 Fernbedienung ansonsten nichts weiter. irw bringt keine Ausgabe. Meine RC-5 Fernbedienung funktioniert hingegen tadellos.
Da ist also noch irgendwo im RC-6 Teil der Wurm drin.
Claus
Da ist also noch irgendwo im RC-6 Teil der Wurm drin.
Naja, das ist halt kein RC-6_6A_32 Protokoll, was die Fernbedienung liefert, sondern nur ein "normales" Philips RC-6 (http://www.pcbheaven.com/userpages/The_Philips_RC6_Protocol/). Probier mal die aktuellste Version aus dem Git, bei mir klappt es damit.
Meine RC-5 Fernbedienung funktioniert hingegen tadellos.
Das ist doch schon mal positiv 
Man lernt nicht aus... Und ich dachte bisher RC-6 ist RC-6.
Jetzt funktioniert auch RC-6 mit meiner Fernbedienung
Als nächstes werde ich mir jetzt ne Konfigurationsdatei erstellen und testen wie gut das mit lircd2uinput und eventlircd zusammen arbeitet.
Ach eines noch. Du hast da wohl was zum debuggen aktiviert. Ich bekomme nun so was angezeigt:
('ToggleBit:', False)
('got Phillips Code', bitarray('1100000000000001011000'))
('ToggleBit:', False)
('got Phillips Code', bitarray('1100010000000001011000'))
('ToggleBit:', True)
('got Phillips Code', bitarray('1100010000000001011000'))
('ToggleBit:', True)Ich berichte dann später ob's alles zufriedenstellen funktioniert.
Claus
Wenn es funktioniert, kann ich die Debug-Meldungen ja wieder rausnehmen
Edit: done
Hi,
ich hab nun nen neues Problem. Nachdem ich den yaUsbIR direkt auf's Mainbord gesteckt, und den IR Empfänger über ein 5m Kabel angeschlosen habe, funktioniert nur noch die RC-5 Fernbedienung problemlos. Die RC-6 Signale kommen nur noch sporadisch an. Ich bin nicht 100% sicher, aber ich meine, dass die RC-6 Fernbedienung mit dem 5m Kabel am Raspberry PI betrieben (mit dem lircd daemon) keine Probleme gemacht hatte.
Hat jemand ne Idee dazu? Ist der RC-5 Codec störungs unempfindlicher als RC-6? Liegt das an der Softwareseitigen Auswertung der Signale? Wird das Protokoll bereits im YaUsbIR Empfänger entschlüsselt, oder passiert das wie bei nem alten Seriellen Empfänger komplett auf dem PC?
Claus
Hat jemand ne Idee dazu? Ist der RC-5 Codec störungs unempfindlicher als RC-6? Liegt das an der Softwareseitigen Auswertung der Signale? Wird das Protokoll bereits im YaUsbIR Empfänger entschlüsselt, oder passiert das wie bei nem alten Seriellen Empfänger komplett auf dem PC?
Ganz wie bei den Empfänger, die lirc_serial nutzen ist es nicht - die haben ja nur am DCD-Pin der seriellen Schnittstelle gewackelt. Der Treiber macht einen USB-Interrupt-Transfer und liest jeweils bis zu 64 Bytes vom yaUsbIR, die ersten Beiden Bytes enthalten eine Start-Sequenz und der Rest besteht aus Gruppen von je 2 Bytes, die die Länge und die Art (Puls/Pause) des Signals enthalten. Die eigentliche Dekodierung der Sequenzen muss dann der Treiber übernehmen.
Wenn der IR-Empfänger am langen Kabel Probleme macht, versuch doch mal da noch einen Entstör-Kondensator anzulöten (siehe yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter )
Danke für den Tipp! Ich werde nachher mal testen ob's hilft.
Claus
ich weiß ja nicht, in wie weit Du hier mitgelesen hast, aber wäre es für Dich mit vertretbarem Aufwand möglich zu schauen was das pyYaUsbIR.py Programm anders macht als der lircd Treiber, im Bezug auf die RC-6 Codes? Mit dem pyYaUsbIR.py Programm funktioniert das RC-6 bei meiner Philips Fernbedienung ja ohne zu stottern, im Gegensatz zum lircd Treiber.
Claus
Falls der Kondensator alleine nicht reicht, kannst du auch die Standardschaltung aus dem Datenblatt nehmen und noch einen Widerstand in die Plus Leitung löten. 4,7uF und 100 Ohm haben sich bewährt. Möglichst nahe am TSOP. Oder geschirmtes Kabel.
https://cdn-reichelt.de/docume…OP312SERIES_DATASHEET.pdf
...Oder geschirmtes Kabel.
Meinst du das so? 
[Blockierte Grafik: http://1.bp.blogspot.com/_fZrb-0CKutc/TT5hVs7_THI/AAAAAAAABAY/2yjgJoJlNKU/s1600/Schirm2.jpg]
Gruß
MegaX
Ja, so ungefähr hab ich das verstanden
Ich hab grad noch mal nen Test mit "lircd -H ya_usbir" gemacht. Und was soll ich sagen, dass funktioniert noch immer genau wie mit dem kurzem Kabel (es funktioniert, stottert nur ein wenig). Lediglich das "yaUsbir.py" reagiert allergisch auf das lange Kabel. Bei dem kommen kaum noch Signale durch. Und wie gesagt, das betrifft auch nur das RC-6 Protokoll. Wie kann das sein?
seahawk1986,
hast Du ne Idee wie das zustande kommen kann? Lässt sich da eventuell doch Software seitig was dran drehen, bzw. ist da eventuell noch nen Bug drin?
Claus
seahawk1986,
hast Du ne Idee wie das zustande kommen kann?
Wenn du das Kommentar-Zeichen vor dieser Zeile entfernst, bekommst du von yaUsbir.py eine Ausgabe ähnlich wie von mode2: https://github.com/seahawk1986…b/receiver/yaUsbir.py#L36
Wenn du dann mal die Ausgaben von meinem Programm für ein paar Tastendrücke mit dem langen Empfänger-Kabel postest, kann ich dir hoffentlich sagen, warum mein Decoder da weniger erkennt als lircd.
Ich hab das Log angehängt. Ich habe drei Tasten jeweils ca. zwei Sekunden gedrückt. Ganz zum Schluss wurde ein Tastendruck erkannt.
Danke schon mal.
Claus
Die Pausen bei deiner FB sind z.T. ganz schön kurz - theoretisch sollten das ca. 444 µs sein, die FB liefert aber welche mit minimal 325 µs.
Mach mal in der rc6decoder.py aus dem unteren Wert von 350 eine 300: https://github.com/seahawk1986…/master/rc6decoder.py#L12
Wie sieht deine lircd.conf aus? Was für Werte sind da gesetzt?
Ein verringern des Wertes ändert leider nichts am Verhalten (hab's runter bis 250 ausprobiert). Mit erhöhen des Wertes geht gar nichts mehr. Was mir dabei aber gerade aufgefallen ist, das es hilft wenn ich weiter weg gehe. Bei einem Abstand von ca. 2m kommen nahezu keine Signale durch. Bei 4m klappt's sporadisch und ab 5m ist's fast schon OK. Macht das irgendwie Sinn?
Mein Log von gestern war aus 4m Abstand.
Und noch eine Info, die Eventuell doch wichtig sein könnte. An dem langen Kabel habe ich einen anderen TOS als an dem kurzen. Aber das sollte doch egal sein, schließlich geht's ja mit dem lircd daemon.
Claus
Zeig doch mal was mit dem kurzen Kabel und dem anderen TSOP so an Ausgaben kommen. Meine Decoder sind recht eigensinnig, wenn da nicht genau die erwartete Puls-/Pausensequenz kommt, erkennen die halt nichts.
OK, hier nun noch das Log mit Original TSOP. Ich habe die selben drei Tasten gedrückt, eventuell aber in ner anderen Reihenfolge.
Claus
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
