Problem mit RGB Moodlight und IRMP

[Jan S. (janser123)]

Hallo ich habe folgende Schaltung nachgebaut 
Beitrag "noch ein AVR Moodlight" und jetzt folgendes Problem 
und zwar Läuft das Moodlight an sich also fadet die Farben durch aber es 
reagiert nicht auf die Fernbedienung. Nur wenn ich bei IRMP das Logging 
einschalte macht die Schaltung was wenn ich eine Taste auf der 
Fernbedienung drücke aber sie macht nicht das was sie soll sondern 
blinkt wie blöde oder geht aus.
Achso ich habe die Schaltung ein wenig verändert und zwar hab ich den 
ir-empfänger an C0 und die Leds an C1,C2 und C3 gepackt

[Jan S. (janser123)]

Ist Pushen erlaubt ???

[Axel R. (Gast)]

Schade, ich kann Dir hier leider nicht helfen.

[Marc N. (Gast)]

Axel R. schrieb:
> Schade, ich kann Dir hier leider nicht helfen.

Tja dann solltest du dir funktionierendes Equipment kaufen. Bei mir 
funktioniert hier alles wunderbar ...

[Axel R. (Gast)]

Ok könnte ich machen. In der Zeit... woran liegt es denn nun, das es 
beim Jan nicht funktioniert?

[Axel S. (a-za-z0-9)]

Moin,

ich habe mit Jan schon Email ausgetauscht und ich bin mir sehr sicher, 
daß sein Problem darin besteht daß er falsche Tasten-/System-Codes 
benutzt (konfiguriert mit einem Haufen #defines am Anfang von 
moodlight.c)

Jan hat mir (aber nicht im angehängten moodlight.zip) auch die Winlirc 
Konfigurationsdatei für seine Fernbedienung gezeigt. Ich hänge das mal 
an. Für mich sieht das nach astreinem NEC Protokoll aus mit Systemcode 
0x00FF und Keycode von bspw. 0x40 für die On/Off/Standby Taste.

Warum das für ihn nicht funktioniert, für mich aber doch, kann ich nicht 
beantworten. Meine Empfehlung wäre

a) einen IRMP-basierten Fernbedienungs-Decoder a'la 
http://www.klaus-leidinger.de/mp/Mikrocontroller/IR-LCD/IR-LCD.html zu 
bauen und daraus die definitiven System- und Tastencodes zu entnehmen.

Oder alternativ

b) das Logging in IRMP zu aktivieren und die von IRMP empfangenen 
Signale auf dem PC mitzuschneiden und auszuwerten.

Für jeden, der den Code ansehen will:

- die (simple) Event-Loop ist am Ende von main.c
- die Auswertung der Fernbedien-Kommandos (im Prinzip ein großes 
switch() Statement) ist in moodlight_remote() in moodlight.c

alles eigentlich straight-forward und ohne große Fehlermöglichkeiten. 
Außer natürlich, daß man auf das korrekte Protokoll und System-/Keycodes 
testen muß.


XL

[Axel S. (a-za-z0-9)]

Für alle, die es interessiert, hier noch ein copy&paste Snippet aus 
einer Mail an Jan, die erklärt wie man die Informationen aus einer 
(Win)lirc Konfigurationsdatei für IRMP aufarbeitet.

<---schnipp-->

Zuerst mal mußt du wissen, daß die lirc-Codes die physikalischen 
Eigenschaften des Signals codieren, während IRMP auf die logischen 
Eigenschaften ausgerichtet ist.

Schauen wir mal rein:

> begin remote
>
>   name  ..\config1.cf
>   bits           16
>   flags SPACE_ENC|CONST_LENGTH
>   eps            30
>   aeps          100
>
>   header       9040  4401
>   one           643  1596
>   zero          643   476
>   ptrail        637
>   repeat       9038  2164

OK, das ist ganz eindeutig das NEC Protokoll. Die korrekten Zeiten wären 
so:

  header       9000  4500
  one           560  1690
  zero          560   565
  ptrail        560
  repeat       9000  2250

>   pre_data_bits   16
>   pre_data       0xFF

Das ist die Systemadresse. ABER: 16 Bit und nicht nur 8. Es ist also 
gemeint:

   pre_data       0x00FF

Und jetzt kommt die erste Gemeinheit: NEC sendet System- und Tastencode 
immer zweimal hintereinander, das zweite Mal invertiert. Ein Code 0xRSTU 
(mit RSTU als Platzhalter) muß also gelesen werden als 0xRS - der 
eigentliche Code - gefolgt von 0xTU - dem invertierten Code. 
Insbesondere müssen sich 0xRS und 0xTU zu 0xFF aufsummieren.

Bei pre_data klappt das offensichtlich: 0x00 + 0xFF = 0xFF

>       begin codes
>           Heller                  0x3AC5

Hier auch: 0x3A + 0xC5 = 0xFF

etc. pp

>           off                     0x02FD

Hier schauen wir jetzt nochmal genauer. Das scheint deine Ein/Aus Taste 
zu sein. Du hast dafür in moodlight.c geändert:

#define KEY_OPERATE 0x02 //Standby

Und jetzt kommt die zweite Gemeinheit: NEC sendet das niederwertigste 
Bit zuerst, lirc hingegen schiebt die empfangenen Bits von links in den 
Code (das zuerst empfangene Bit steht also ganz links). lirc hat für die 
"off" Taste gelesen: 0x02FD = (0000 0010 1111 1101)b

Die ersten 8 Bits sind der Tastencode, die zweiten 8 das Komplement. 
Allerdings ist die Reihenfolge der Bits im Tastencode verkehrt herum. 
Aus logischer Sicht ist der Tastencode (0100 0000)b = 0x40

Beim Systemcode hast du das gleiche Bit-Reversal, allerdings spielt das 
bei 0x00 bzw. 0xff keine Rolle.

<---schnapp-->


XL

[Frank M. (ukw) (Moderator)]

Axel Schwenke schrieb:

> b) das Logging in IRMP zu aktivieren und die von IRMP empfangenen
> Signale auf dem PC mitzuschneiden und auszuwerten.

Dass Logging benutzt ja bekanntermaßen den UART. Also wenn ein UART 
benutzt werden muss, kann man sowieso Protokoll, Adresse und Kommando 
direkt auf diesem ausgeben. Damit erübrigt sich das Logging ;-)

Aber Du wirst mit dem Bitreversal recht haben. Lirc kümmert sich nicht 
um die Bitreihenfolge MSB und LSB, sondern fasst alles als MSB auf. Das 
NEC-Protokoll ist aber ein LSB-Protokoll. IRMP berücksichtigt dieses 
sehr wohl. Daher muss man, wenn man auf LIRC-Daten zurückgreift, die 
Bits tatsächlich spiegeln.

Aber das einfachste ist wirklich, die IRMP-Daten auf dem UART 
auszugeben. Damit ist man auf der sicheren Seite.

Gruß,

Frank

[Axel S. (a-za-z0-9)]

Moin,

ich glaube ich habe den Fehler gefunden.

Axel Schwenke schrieb:
> Beim Systemcode hast du das gleiche Bit-Reversal, allerdings spielt das
> bei 0x00 bzw. 0xff keine Rolle.

Es ist zwar richtig, daß das Bit-Reversal die Werte von 0x0 bzw. 0xF 
nicht ändert, aber man muß natürlich auch die Reihenfolge der Nibble 
umdrehen.

Mal zum Vergleich meine Goldstar Fernbedienung:

lirc: pre_data 0x7689
IRMP: #define MY_REMOTE_ID 0x916e

  0x7689 = 0111 0110 1000 1001
reversed   1110 0110 0001 1001 = 0xE619

um auf den IRMP-kompatiblen Systemcode zu kommen, muß man jetzt noch die 
Nibble reversen (die Hex-Ziffern von hinten nach vorn lesen).

Für Jan also:

lirc: pre_data 0xFF
  0x00FF = 0000 0000 1111 1111
reversed   0000 0000 1111 1111

und dann von hinten nach vorn gelesen: 0xFF00. Das ist also der 
Systemcode mit dem IRMP diese Fernbedienung erkennt.


XL

[Frank M. (ukw) (Moderator)]

Axel Schwenke schrieb:

> um auf den IRMP-kompatiblen Systemcode zu kommen, muß man jetzt noch die
> Nibble reversen (die Hex-Ziffern von hinten nach vorn lesen).

Das ist zwar prinzipiell richtig, aber ein wenig kompliziert ausgedrückt 
;-)

Du musst die Bits allesamt einfach von rechts nach links lesen, dann 
passt das schon.

[Jan S. (janser123)]

Läuft!!! Es lag an dem Systemcode
Danke an alle die mir geholfen haben.
Ihr seid Super

[Axel S. (a-za-z0-9)]

Um Probleme wie das eben für die Zukunft zu vermeiden, habe ich mal ein 
kleines Perl-Skript gebastelt, das ein (Win)lirc Konfigfile einliest und 
in IRMP-taugliche #defines umwandelt.

Beispiel:

$lirc2irmp.pl goldstar.lirc 

/* codes for remote control 'GS' */
#define MY_REMOTE_ID    0x916e
#define KEY_+   0x18
#define KEY_-   0x19
#define KEY_0   0x04
#define KEY_1   0x05
#define KEY_2   0x06
#define KEY_3   0x07
#define KEY_4   0x0c
#define KEY_5   0x0d
#define KEY_6   0x0e
#define KEY_7   0x0f
#define KEY_8   0x1c
#define KEY_9   0x1d
#define KEY_FFWD        0x03
#define KEY_OPERATE     0x14
#define KEY_PAUSE       0x0b
#define KEY_PLAY        0x08
#define KEY_REC 0x09
#define KEY_REW 0x02
#define KEY_STOP        0x01

Das frißt auch Jans winlirc.txt ohne Probleme.


XL

[Jan S. (janser123)]

Es wäre Super wenn man das Script auf der Irmp Seite Verlinken würde

[Axel S. (a-za-z0-9)]

Jan S. schrieb:
> Es wäre Super wenn man das Script auf der Irmp Seite Verlinken würde

Frank: sieh es als eine Spende meinerseits an :)


XL