LIRC-Codes "berechnen" (insbesondere ELV) ?

  • Zur Hausautomation muß ich FS10-Codes abstrahlen (via IR-zu-RF-Brücke à la PowerMid), vgl. zum ELV-Protokoll LIRC & Lichtsteuerung Erfahrungsbericht und http://web.archive.org/web/200…chl.fundf.net/wsprotocol/


    Leider kann dieses per 433MHz-AM-Infrarot-Konverter von LIRC nur als Raw Codes gesampled werden, was dann auch bei jedem Gerätewechsel sehr zeitaufwendig wiederholt werden muß (ebenso v.a. für die chinesischen LED-Stripes) und nicht mit jedem Transceiver gelingt (einige wie mceusb hängen sich bei manchem raw-Senden sogar auf).

    Gibt es mit den o.g. Informationen zu Bitmustern, Timing und Modulation eine Möglichkeit, die raw-Samples zu visualisieren und bereinigt oder berechnet (wie wohl in EZcontrol möglich) ins transceiverunabhänigere Format kürzerer Hexadezimalcodes zu bringen?
    Über http://winlirc.sourceforge.net/technicaldetails.html hinaus konnte ich leider noch nicht viel zu den Details des LIRC-Dateiaufbaus finden.

  • Ich weiss zwar nicht, was du genau machen willst. Aber "Visualisierung" von LIRC mache ich immer mit dem Speicheroszi. Ich lasse mir die lirc.conf erst nach Moeglichkeit generieren und verwende sie anschliessend zum Senden.


    Da sieht man naemlich erst was von LIRC oft fuer ein Schrott-lirc.conf generiert wird. Solche Fehler wuerde man anders kaum finden. Siehe auch 334


    Von Hand kann man die lirc.conf dann aber solange bequem tunen bis Original und Kopie auf dem Display exakt zur Deckung kommt.

  • Ich weiss zwar nicht, was du genau machen willst. Aber "Visualisierung" von LIRC mache ich immer mit dem Speicheroszi. Ich lasse mir die lirc.conf erst nach Moeglichkeit generieren und verwende sie anschliessend zum Senden.


    Da sieht man naemlich erst was von LIRC oft fuer ein Schrott-lirc.conf generiert wird. Solche Fehler wuerde man anders kaum finden. Siehe auch 334


    Von Hand kann man die lirc.conf dann aber solange bequem tunen bis Original und Kopie auf dem Display exakt zur Deckung kommt.


    Ich habe es ohne Oszi z.B. mit der in http://web.archive.org/web/200…chl.fundf.net/wsprotocol/ unter Datenübertragung & Telegrammaufbau dokumentierten Codierung zu tun (Sensoren und Fernbedienungen haben bei FS10 ein gemeinsames Protokoll, vgl. http://www.elv.de/controller.aspx?cid=726&detail=33279).
    Beschrieben sind 10 Nullbits Header; 4N1; 1187,5 Mikrosekunden/Bit, 1 kurz, 0 lang (>50% Taktzeit).


    Die RF demoduliere ich mit einem IR-Umsetzer ähnlich http://web.archive.org/web/201…e.com.tw/ir-extender.html (und umgekehrt).


    LIRC liefert das im Eingangspost genannte sehr schiefe Ergebnis (ähnlich oft auch bei reinen IR-Fernbedierungen).
    Gerne würde ich anhand des theoretisch bekannten Signaltimings (statt unscharfer Samples) die lircd.conf erstellen, finde aber weder Erfahrungsberichte, wonach andere das ebenso schon durchgeführt hätten, noch das Dateiformat hinreichend für LIRC selbst dokumentiert.


    Nach den Angaben zum Derivat http://winlirc.sourceforge.net/technicaldetails.html und o.g. Protokollbeschreibung hätte ich mit einer SHIFT_ENC (heute RC5) gerechnet.
    Das Format des Dateikopfes ist zu WinLIRC einigermaßen beschrieben, aber was sollen <phead> <shead>, <leading pulse> und pre* enthalten, und v.a. wie genau verhalten sich die raw_codes zur Ausgabe?
    Als Paare aus Takt- und Totzeiten in Mikrosekunden schienen sie kaum zum erwarteten Signal zu passen - aber auch ohne Oszilloskop erscheinen mir Anstiegs- und Abklingzeiten von um die 100us bei IR-Halbleiterschaltungen nicht unwahrscheinlich.


    Es muß doch über http://www.righto.com/2010/03/…ir-remote-codes-lirc.html hinaus Dokumentation dazu geben, wie "saubere" Samples nach raw umgesetzt, und letztere umgekehrt ins Standardformat "verfeinert" werden sollen?
    Finden konnte ich hierzu jedoch nichts.
    Tatsächlich konnte ich aber mit einem anhand der raw_codes (vgl. mode2) ersonnenen und bisher wohl noch nirgends sonst beschriebenen Verfahren eine synthetische lircd.conf erstellen, die eine SPACE_ENC mit 500us Puls gefolgt von 250-300us Pause für 0 und 700us Pause für 1 enthält.


    Die Schwierigkeit dabei war, daß FS10 zumindest wie es sich aus den LIRC-Samples darstellt offenbar mit dem 5. stets gesetzten "Stop"-Bit beginnt, gefolgt von einem odd-parity-Bit (also gesetzt wenn die Summe der drei folgenden Bits gerade ist - damit rechnete ich nur, wenn auch nicht an dieser Position, auch nur weil das serielle Protokoll des ELV-Sensorempfängers schon eine vergleichbare Auffälligkeit aufweist).


    Diese manuell ausgetüftelte lircd.conf wiederum vermag dann irrecord -a anders als seine eigenen Samples in ein "nicht mehr rohes" Hex-Format zu überführen (evtl. mit einer führenden 0 zuviel):

    Für jedes Bit der binären Darstellung dieser Hex-Codes wird dann (mit dem MSB beginnend bis zum LSB, d.h. "von links nach rechts") das jeweilige o.g. Muster für zero oder one übertragen und man sieht, wie nur die letzten 3 von je 5 Bits (neben Stop und Parity) tatsächlich "Nutzlast" enthalten.
    Gegenwärtig scheint das Timing noch nicht perfekt, da ein so vom seriellen Dongle erzeugtes IR-(zu-RF-)Signal erkannt wird, nicht aber das gleiche vom mceusb gesendet (was ja die eigentliche Motivation war, von den raw_codes wegzukommen - nun aber zumindest testweise Timingänderungen erheblich erleichtert).

  • Gegenwärtig scheint das Timing noch nicht perfekt, da ein so vom seriellen Dongle erzeugtes IR-(zu-RF-)Signal erkannt wird, nicht aber das gleiche vom mceusb gesendet (was ja die eigentliche Motivation war, von den raw_codes wegzukommen - nun aber zumindest testweise Timingänderungen erheblich erleichtert).

    Evtl. ist das mit dem mceusb auch nicht hinzubekommen, da hartkodierte Auflösungsbegrenzung in http://lxr.free-electrons.com/…rivers/media/rc/mceusb.c:
    #define MCE_TIME_UNIT 50 /* Approx 50us resolution */
    (vgl. http://sourceforge.net/p/lirc/mailman/message/24253837/)


    Welcher Transceiver wird denn vom Standardkernel gut unterstützt und gibt Samples möglichst hochauflösend&originalgetreu (wie die alten seriellen Homebrew-Dongles) weiter&wieder?

  • Hi,
    Gab es da nicht verschieden schnelle Protokolle? Die Activy verwendete doch ein schnelleres... Gibt doch versch. Tsops. Da sollte ein passender zu finden sein. Und dann daraus einen klassischen seriellen Empfänger mit Elko und Widerstand, wenn ich es korrekt erinnere machen und da einen FTDI232 da dran und gut. Nimm aber einen echten! Gibt viele Fakes...
    Hoffe das hilft etwas...
    MfG Stefan


    Gesendet von meinem HTC One mit Tapatalk 2

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Gab es da nicht verschieden schnelle Protokolle?

    Klar gibt's die, ein FS10-Protokoll z.B. bekomme ich v.a. über die gemischte IR-/Funkstrecke bei 50us max. Auflösung selten erkennbar übertragen, selbst bei synthetischer statt gesampleter lircd.conf (100us-Timings, die das mceusb aber wohl dennoch nicht genau genug abstrahlt; klassisch seriell funktionierts, aber ab Riesenkiste mit 15-fachem Stromverbrauch).


    Zitat

    Die Activy verwendete doch ein schnelleres... Gibt doch versch. Tsops. Da sollte ein passender zu finden sein. Und dann daraus einen klassischen seriellen Empfänger mit Elko und Widerstand, wenn ich es korrekt erinnere machen und da einen FTDI232 da dran und gut.

    Meinst Du http://www.huitsing.nl/irftdi/ ? Der hatte im Prototyp auch einigen Jitter, sollte aber verkraftbar sein.
    Die mceusb-Limitierung scheint aber nicht am TSOP zu liegen, sondern eine eingebaute Bremse im Treiber (wahrscheinlich wegen weniger performanter, nicht allzu akkurater Dongle-Hardware) zu sein - oder kennt jemand einen Weg, sie für genaueres Timing zu lösen?

    Zitat

    Nimm aber einen echten! Gibt viele Fakes...

    Wäre einem Fertiggerät mit qualitätsgesicherten Komponenten nicht abgeneigt (schon um mehr Zeit fürs allein ausreichend kopfschmerzträchtige Reversen&alternative Implementieren diverser Gebäudeautomatisierungsprotokolle zu haben), Hauptsache es wird vom Standardkernel unterstützt: Für http://dangerousprototypes.com/docs/Vanesse:_USB_IR_Toy_v3 &
    http://dangerousprototypes.com…pdated-irwidget-firmware/ scheint das ja noch nicht soweit zu sein (IRMAN-Modus kann wohl nur empfangen).


    Immerhin scheint mein langjähriger Vorschlag eines "eierlegenden Wollmilchtransceivers" (RF/IR-Integration, mehrere Übertragungswege an GPIO, zur Laufzeit abschaltbarer Softcarrier) durch den Raspberry Pi nun endlich Umsetzung zu erfahren: http://www.harctoolbox.org/lirc_rpi.html :]
    Das (evtl. inkl. Möglichkeiten neben festen Tasten auch Meßwerte diverser auf gleicher Hardware empfangbarer Funksensoren auszugeben) muß allerdings auch erst alles den Rückweg in LIRCs Standard(kernel)module finden.

  • 8 verschiedene Hauscodes kennt der vom Markt verschwindende http://www.elv.de/topic/fs10-handsender-fs10-s8.html und erfordert bei jedem Batteriewechsel die oben oder unter der URL genannte Prozedur.
    Mit Konvertierung aus dem überlaufenen 433MHz-ISM-Band wird das LIRC-Sampling zunehmend unmöglich.
    Hat jemand eine Idee, wie sich lircd.conf-Codes stattdessen "synthetisch" erstellen lassen?

    Greif doch den Code direkt im Sender ab, bevor er auf HF aufmoduliert wird.
    Empfängerseitig ist das schwierig, da Du ohne aufsynchronisieren das Nutzsignal nicht vom rauschen unterscheiden kannst.



    Garry

    VDR-Tower(yaVDR0.5): ASROCK N68c-S UCC + MSI N210 MDIG/D3NVIDIA630 + Doppeltunerkarte TBS 6981 + 2*DVBS USB PCTV461e
    Pundit Ah2 2xSkystar2.6c + HP NovaTD über DVI HDMI (yavdr0.3) stillgelegt
    Asus M3N78-EMH HDMI + GT630 single Slot mit YAVDR0.5 2xTT cinergy DVB-C +DVBS USB PCTV461e+ Hauppauge USB TD (DUAL DVB-T) 2 x MediaMVP+RaspberryVomp + Raspbmc

  • Greif doch den Code direkt im Sender ab, bevor er auf HF aufmoduliert wird.
    Empfängerseitig ist das schwierig, da Du ohne aufsynchronisieren das Nutzsignal nicht vom rauschen unterscheiden kannst.

    Die letzten Fernbedienungen ihrer Art :rolleyes: wollte ich nur ungern zerlegen (und habe immer noch kein Oszi), doch zum Glück konnte ich herausbekommen, daß 10 Nullen Vorspann gesendet werden - war dann nicht so schlimm, daß nicht alle davon beim einschwingenden Empfänger ankommen.
    Nach ein paar Runden mode2 ließ sich das Protokoll dann austüfteln und anstelle unsauberer Samples eine lircd.conf "synthetisieren".
    Fehlt mir nur ein Transceiver mit feinerem Timing als 50µs und idealerweise hoher IR-Reichweite.
    Evtl. nimmt sich hier ja einer der LIRC- oder Einschalter-µC-Entwickler http://www.harctoolbox.org/lirc_rpi.html an und verallgemeinert das zu einem Modul mit gepflegtem Kerneltreiber?

  • Die zehn Nullen am Anfang solltest Du dem Empfänger gönnen damit er sich auch einschwingen kann.
    Eine eins dazwischen bringt Deinen Decoder unter Umständen aus dem Konzept wenn er versucht darauf aufzusyncronisieren.
    Kann zwar trotzdem noch funktionieren, aber die Störempfindlichkeit wird größer und damit die Reichweite geringer.


    Gerald

    VDR-Tower(yaVDR0.5): ASROCK N68c-S UCC + MSI N210 MDIG/D3NVIDIA630 + Doppeltunerkarte TBS 6981 + 2*DVBS USB PCTV461e
    Pundit Ah2 2xSkystar2.6c + HP NovaTD über DVI HDMI (yavdr0.3) stillgelegt
    Asus M3N78-EMH HDMI + GT630 single Slot mit YAVDR0.5 2xTT cinergy DVB-C +DVBS USB PCTV461e+ Hauppauge USB TD (DUAL DVB-T) 2 x MediaMVP+RaspberryVomp + Raspbmc

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!