ich habe hier eine IR-Fernbedienung, die ich unbedingt am Arduino betreiben möchte. Der Code wird allerdings von der RC-Library nicht korrekt erkannt und das, was die Library als berechneten Code ausgibt, passt auch nicht, weil die Timings nicht passen.
Ich habe hier mal einige Tasten vergleichsweise dargestellt.
Was auffällt:
der erste Bereich bis zu Linie ist immer gleich - Korrektur: stimmte nicht, unterscheidet sich zwischen Zahlen- und Buchstabentastatur
die LOW Werte scheinen in etwa gleich lang zu sein zw 430 und 480ms
die HIGH Werte sind unterschiedlich (160, 860, 1500, 1190, 1520)
Vielleicht hat einer von euch eine Ahnung, was das für ein Code sein könnte.
Wer ist der Hersteller der FB?
Wenn du nach Hersteller und IR-Code googelst, solltest du fündig werden.
Es gib da eine Aufstellung der verschiedenen Hersteller, die habe ich hier leider nicht zur Hand.
Und es kann auch ein Hersteller sein, der mit einer anderen Frequenz atbeitet.
Frequenz und Empfänger passen zusammen, beides 56kHz.
Die FB ist schon einige Jahre alt und wurde damals für ein Linux Mediacenter verwendet. Der Hersteller ist iTV Media.
Das besondere an dieser FB ist, dass sie ein volle Tastatur bietet.
Ich habe auch einen lirc.conf File für die FB, da stehen aber auch nur die Zeiten drin. Häng ich mal an. Der Hersteller ist nicht mehr online, aber hier gibt es einen Bericht über das Mediacenter und ein Abbild der FB.
In einen alten Forum habe ich gefunden dass ein Sejin-Code sein soll. Hab ich noch nie gehört.
Naja, die RAW Codes sind die Zeiten, aber daraus muss ich ja eine Zahl generieren, die ich als Vergleichskriterium nutzen kann um daraus auf die Bedeutung zu schließen.
Die IRremote Bibliothek kann etliche Protokolle dekodieren, einfach mal ausprobieren
ABER: die Version von Robot_Remote ist uralt, besser die neueste Version von shirriff besorgen.
Im Zweifelsfall könnte der Hash-Decoder einheitliche Werte für jede Taste liefern, das wäre dann schon mal ein guter Ausgangspunkt.
In den Diagrammen sehe ich etliche ganz kurze Pulse, da würde ich fast auf ein Hardware-Problem tippen (falsche Trägerfrequenz?). Möglicherweise paßt Dein Empfänger nicht zum Sender? Die Abtastung erfolgt in der IRremote Bibliothek mit 50µs, da könnten solche Spikes Ärger machen.
Die neueste IRRemote Lib hatte ich natürlich als erstes ausprobiert. Das Protokoll ist aber darin auch nicht bekannt.
Was ist der Hash-Decoder ?
Die kurzen Pulsen gehören schon mit dazu und sind ca.200us lang. In der lirc.conf sind auch Pulse (hier) von 220us enthalten. Für ein HW Problem sind die auch zu regelmäßig. So sind die ersten Pulse ja auch immer gleich.
Trägerfrequenz ist korrekt, ich hatte mir extra noch die 56kHz Empfänger besorgt.
Durch die Abtastung mit 50us werden die Pulse sehr unsicher erkannt.
Mehr Infos gibt es mit #define DEBUG 1 in IRremote.h.
Meine Fernbedienung von Grundig wird erkannt, aber auch das Timing mit ausgegeben. Wenn die Erkennung nicht funktioniert, das Timing aber stabil angezeigt würde, wäre das möglicherweise ein Ansatzpunkt.
Die Ausgabe erfolgt anscheinend in ms µs. Da kannst Du selbst feststellen, daß die Zeiten alle Vielfache von 50µs sind, weil das die Interruptrate des Timers ist, mit der das Signal abgetastet wird. Die tatsächlich gemessenen Ticks bekommst Du nur beim direkten Zugriff auf results.rawbuf.
Zudem wird bei der Decodierung noch eine Verzögerungszeit von 100µs berücksichtigt, um die sich die Dauer von Mark und Space unterscheiden (kommt vom Sensor). Da müßte man nachschauen, ob die in den Ausgaben berücksichtig sind.
Wie das beim Sender gehandhabt wird, habe ich noch nicht nachgeschaut, vielleicht tritt bei dessen Ansteuerung keine derartige Verschiebung auf.
Mein Fork von IRremote (...DrDiettrich/IRremote) hat inzwischen Beachtung gefunden, mal sehen wieviel davon in die offizielle IRremote Bibliothek übernommen wird. Die Änderungen betreffen aber nur das API der Bibliothek, die Messung erfolgt unverändert wie in der z30 (shirriff) Version.
DrDiettrich:
Die Ausgabe erfolgt anscheinend in ms.
Ich tippe auf µs
Die Ausgabe erfolgt nach Multiplikation mit USECPERTICK (50 µs Abtastrate). Bei -- Code -- habe ich diese Multiplikation mal weggelassen: -- Info --
Encoding : RC5
Code : C61 (12 bits)
-- Raw mit USECPERTICK multipliziert --
Timing[23]:
900, - 850 + 900, - 800 + 900, - 850 +1750, - 850
900, - 800 + 900, -1700 + 900, - 850 +1750, - 850
900, - 800 + 900, - 850 + 900, -1700 + 850
-- Code --
unsigned int rawData[23] = {18,17, 18,16, 18,17, 35,17, 18,16, 18,34, 18,17, 35,17, 18,16, 18,17, 18,34, 17}; // RC5 C61
unsigned int data = 0xC61;Bin gespannt, was die Fernbedienung des TO ausgibt.
Mich machen nach wie vor die Ausreißer (50-150) stutzig, die mir nach einem Hardware-Problem aussehen. Die 50 entsprechen ja gerade mal 1 Interrupt, da sind ja schon die 100µs MARK_EXCESS länger. Wie sehen die Zeiten denn aus, wenn Du MARK_EXCESS noch berücksichtigst?
Du mußt Dir wohl einen eigenen Decoder für diesen Code schreiben.