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):
begin remote
name FS10synth
bits 44
flags SPACE_ENC
eps 30
aeps 100
one 500 700
zero 500 300
ptrail 500
gap 216249
toggle_bit_mask 0x0
begin codes
4left 0x0002948E2F2
4right 0x0003B48E2F1
end codes
end remote
Alles anzeigen
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).
![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
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.
