Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

Dominique Görsch schrieb:
> Super, dass du es gleich implementieren willst. Reichen dir die Infos
> aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?

Es wäre natürlich nett, wenn Du auch ein paar Scans machen könntest. 
Graue Theorie ist die eine Geschichte, Praxis oft eine andere :-)

Gruß,

Frank

Kein Problem, werde ich machen. Muss deinen Code dafür nur etwas 
umstricken weil ich in meiner Firmware sowieso UART mit 250kBaud (USB) 
drin hab. Wird heute aber wohl eher nixmehr...

Dominique Görsch schrieb:
> Sowohl als auch wäre genial. Ich plane zum einen eigene Receiver die
> dann mit der LEGO Fernbedienung steuerbar sind, zum anderen aber auch
> das automatische Steuern zB von Zügen.

Im SVN ist nun ein IRMP/IRSND mit dem LEGO-Protokoll zu finden. 
Maßgeblich sind in irmp_data.command die unteren 12 Bits, die je nach 
Inhalt von der Anwendung zu prüfen sind - anlehnend an die 
LEGO-Dokumentation. irmp_data.address ist immer 0.

IRMP liest die 16 Bits des LEGO-Telegramm ein und checkt das letzte 
Nibble im XOR-Verfahren gegen die anderen 3 Nibbles. Kommt der richtige 
Wert raus, gibt IRMP die 12 Bit an Nutzdaten zurück.

Umgekehrt kann man die 12 Bits an IRSND in irmp_data.command übergeben. 
IRSND "konstruiert" daraus das fehlende letzte Nibble und schickt 
anschließend den kompletten Frame mit 16 Bit raus.

Als letzte Info: Man braucht eine Interrupt-Frequenz von 20kHz, da die 
Pulse ziemlich kurz sind. Wenn Du noch Scans machen möchtest, dann bitte 
mit 20kHz.

Ich hoffe, ich habe keinen Fehler gemacht, bitte testen.

Gruß,

Frank

Hy Frank,

wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur 
"Merlin" ?
Hast Du da schon was erreichen können ?

Gruß
Torsten

Torsten K. schrieb:
> wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur
> "Merlin" ?
> Hast Du da schon was erreichen können ?

Nein, noch nicht. Da werde ich wohl vor dem nächsten Wochenende nicht zu 
kommen. Wenn Du mir helfen willst, kannst Du gern vorabe schon mal ein 
paar Scans mit IRMP machen. Das würde mir eine Menge Arbeit abnehmen.

Gruß,

Frank

Hi,

ja, werde mal sehen, wie ich die Tage dazu komme, sollte aber möglich 
sein.

Bis dann
Torsten

Sorry, ich komme im Moment leider nicht zum Testen, trotzdem schonmal 
ein Danke für die schnelle Implementation.

Hi Joachim,

Joachim B. schrieb:
> an Frank (ukw)
>
> habe eine FB die IRMP nicht erkennt

Doch, wird erkannt. Das ist das NEC16-Protokoll (eine verkürzte Variante 
des 32-Bit-NEC-Protokolls, dafür aber mit Sync-Bit nach den 8 
Adressbits).

Protokoll: 27
Adresse: 0x0015

Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des 
SVN.

Gruß,

Frank

Joachim B. schrieb:

> hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme
> ?

Habs mir gerade angeschaut, das hat was mit einer kürzlich von mir 
geänderten Behandlung der 2-fachen Längen von Pulsen/Pausen im 
Manchester-Decoder zu tun. Ich wollte da Code einsparen, hab aber nicht 
bedacht, dass da Variablen "platzen" könnten. Ich repariere das am 
Wochenende. Entweder Du gehst auf 15kHz runter oder Du verzichtest 
erstmal auf RC5 und Co.

Gruß,

Frank

Joachim B. schrieb:
> hast du schon die 8-bit Timer0 Variante eingebaut ?

Nein, habe ich noch nicht. Bei der 16-Bit-Timer-Variante werden die 
Werte für die Timer-Register über eine Formel, die lediglich von F_CPU 
und F_INTERRUPTS abhängig sind, automatisch initialisiert. Da muss man 
nichts anpassen.

Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann 
die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht 
so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und 
her, wie ich das am besten allgemeingültig in den Code einbaue.

Hallo Frank,

erst mal ein großes Lob, Dein IRMP ist große Klasse!

Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu 
basteln, die mit einem 5" Touch etwa so viel kann wie die Philips 
Pronto.
Leider hat Philips die Herstellung dieser genialen Fernbedienungen 
eingestellt und es gibt keinen Hersteller, der etwas vergleichbares 
anbieten kann, zumindest nicht unter 1400€.

Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und 
IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen 
gebracht.

Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP 
nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen 
älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die 
Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der 
Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur 
Modulationsfrequenz, sollte aber trotzdem noch gehen.

Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Gruß
Cajus

Hoppla, irgendwie ist mein Dateianhang doppelt vorhanden!?
Weis jemand wie man Dateianhänge wieder löschen kann?

Cajus H. schrieb:

> erst mal ein großes Lob, Dein IRMP ist große Klasse!

Danke :-)

> Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu
> basteln, die mit einem 5" Touch etwa so viel kann wie die Philips
> Pronto.

Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine 
programmierbare FB handelt, bei dem das Tastenlayout auf dem Display 
frei wählbar ist?

Vielleicht schaust Du Dir dazu mal

  http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

an. Diese kann die Codes lernen und im EEPROM abespeichern. Ich weiß, 
hier gibt es zwar nur 5 Tasten, aber vielleicht kannst Du da was von 
übernehmen oder zumindest die eine oder andere Anregung erhalten :-)

> Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und
> IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen
> gebracht.

Super!

> Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP
> nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen
> älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die
> Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der
> Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur
> Modulationsfrequenz, sollte aber trotzdem noch gehen.
>
> Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
> Es wäre schön, wenn man das Protokoll noch implementieren könnte.

Habs mir gerade mal kurz mit "irmp-15kHz -a" unter Linux angeschaut. Das 
Protokoll ist sehr einfach gehalten:

- Jeder Frame wird 2 mal wiederholt (also insgesamt 3 Frames)
- Kein Startbit
- Framelänge 12 Bit
- Pulslänge: 550 µs
- Pausen: 1990 µs oder 4523µs

Ich schaue mal, ob ich das morgen früh mal einbaue, sollte nicht 
schwierig sein. Dank der Fülle Deiner Scans sollte ich auch noch 
herausbekommen, wieviele Bits zur Adresse und wieviele zum Kommando 
gehören.

Eine Frage hätte ich noch: Hast Du die Tasten kurz gedrückt oder länger? 
Die 2 Wiederholungen eines jeden Frames sind etwas untypisch. Eventuell 
müsstest Du das nochmal testen, sobald IRMP das Thomson-Protokoll 
"versteht". Nicht dass zumindest der 3. Frame eine Wiederholung ist, die 
durch langes Drücken einer Taste zustandekam...

Gruß,

Frank

Mich hat es doch in den Fingern gejuckt und ich habe gerade mal das 
Thomson-Protokoll in den IRMP eingebaut. Da es so einfach ist, hat es 
gerade mal 20 Minuten gebraucht :-)

Neue Erkenntnisse:

- Der Frame setzt sich aus einer 4-Bit-Adresse und 8-Bit Daten zusammen
- MSB oder LSB first ist noch unbekannt, lässt sich leider nicht aus den
  Tasten 0 bis 9 erkennen
- Frame-Wiederholungen werden im Moment noch als Tasten-Wiederholungen
  (flag = 0x01) erkannt. Das muss noch angepasst werden, sobald klar
  ist, wieviele Frames bei kurzem! Tastendruck erzeugt werden

@Cajus H. (cajush):

Teste das bitte mal. Gemeinsam sollten wir das dann hinbekommen.

Im Anhang findest Du die gegenüber dem SVN geänderten Sources.

Achja: Da kommt im Moment noch eine Compiler-Warnung, die Du ignorieren 
kannst... ist halt noch ein Prototyp.

Gruß,

Frank

Hallo Frank,

>> Philips Pronto...
> Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine
> programmierbare FB handelt, bei dem das Tastenlayout auf dem Display
> frei wählbar ist?

Ja genau und zwar WIRKLICH frei wählbar mit Tastenform, Tastengröße, 
Anordnung der Tasten, beliebige Macros und vielem mehr. Es gab eine 
Variante mit Graustufen-Touch und eine Variante mit Farb-Touch, ich habe 
eine ältere Graustufen-Variante mit relativ kleinem Touch. Im Anhang 
sind ein paar Seiten meiner Pronto.
Als Basis für eine Touch-FB habe ich dieses Modul im Auge 
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=459 
, erweitert um einen ATmega mit IRSND.

> Thomson Protokoll...
Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und 
lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR 
kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog 
zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob 
kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen 
Tasten.

Ich habe Dir außerdem mal meine Source-Dateien angehängt.
Darin sind ein paar kleine Änderungen:
- Versionsnummer aktualisiert (sollte man eigentlich besser in einer 
Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul 
;-)
- printf-Unterstützung auch für gcc (war nur für CODEVISION drin)
- Namen der Protokolle erweitert

Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
Ich habe mal angefangen die Codes meiner FBs in eine Tabelle zu packen, 
aber vielleicht gibt es schon eine vergleichbare Sammlung. Ich habe den 
aktuellen Stand der Liste auch mal angehängt, es fehlen noch einige FBs. 
Eigentlich eine Anwendung für eine Datenbank...

Gruß
Cajus

Hallo Frank,

hier noch einmal meine modifizierten IRMP Sourcen, bei den obigen hatte 
sich ein Fehler eingeschlichen, der das Übersetzen mit IRMP_LOGGING = 0 
verhinderte. Das resultierte daher, weil ich Deine Uart-Initialisierung 
nach main() kopiert hatte, die Definition der Register aber nur bei 
IRMP_LOGGING = 1 gemacht wird. Daher habe ich diese Definitionen nach 
irmp.h verlegt.

Ich habe die Version nach irmp.h verschoben und gebe bei printf nur noch 
%s aus.


In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch 
schon in der letzten Version meiner Sourcen behoben hatte: irmp.c

vor
static PROGMEM IRMP_PARAMETER thomson_param =
steht
#if IRMP_SUPPORT_DENON_PROTOCOL == 1
das sollte vermutlich
#if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
heissen, oder?

Gruß
Cajus

Hallo Frank,

hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger 
gedauert.
Gemacht mit  F_INTERRUPTS 20000.
Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Gruß
Torsten

Cajus H. schrieb:
>> Thomson Protokoll...
> Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und
> lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR
> kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
> Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog
> zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob
> kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen
> Tasten.

Sehr gut. Bei kurzen Tastendrücken gibt es nur einen einzigen Frame. Das 
macht die Sache leichter. Danke für den Tipp mit dem Toggle-Bit. IRMP 
blendet das nun aus. Damit konnte ich dann sehen, dass die 
Bit-Reihenfolge MSB-First ist, denn die untereinander liegenden Tasten 
0,4,7 / 2,5,8 / 3,6,9 haben damit eine aufsteigende Reihenfolge. Das 
ergibt folgende Codeänderungen:

1

#define THOMSON_COMMAND_OFFSET                  5                               // skip 4 address bits + 1 toggle bit

2

#define THOMSON_COMMAND_LEN                     7                               // read 7 command bits

3

#define THOMSON_LSB                             0                               // MSB...LSB

> Ich habe Dir außerdem mal meine Source-Dateien angehängt.
> Darin sind ein paar kleine Änderungen:
> - Versionsnummer aktualisiert (sollte man eigentlich besser in einer
> Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul
> ;-)

Die Versionsnummer, die im Codevision-Teil steht, habe ich nie gepflegt. 
Ich überlege mittlerweile auch, die Codevision-Unterstützung komplett 
rauszuwerfen, da ich diese mangels Codevision-Compiler sowieso nicht 
unterstützen kann. Das würde den Code etwas übersichtlicher machen - 
zumindest in main.c.

> - printf-Unterstützung auch für gcc (war nur für CODEVISION drin)

Schaue ich mir mal an. Eigentlich hat das aber nichts im IRMP zu suchen. 
Die main.c ist eigentlich nur ein Beispiel-Code und nicht wirklich 
Bestandteil des IRMP.

> - Namen der Protokolle erweitert

Ja, eben, das wurde nicht gepflegt. Eigentlich will ich das auch gar 
nicht ;-)

> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?

Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu 
machen, weiß ich nicht.

Cajus H. schrieb:

> In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch
> schon in der letzten Version meiner Sourcen behoben hatte: irmp.c
>
> vor
> static PROGMEM IRMP_PARAMETER thomson_param =
> steht
> #if IRMP_SUPPORT_DENON_PROTOCOL == 1
> das sollte vermutlich
> #if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
> heissen, oder?

Ja, danke, das war ein Copy&Paste-Fehler.

Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN 
einchecken.

Gruß,

Frank

Torsten K. schrieb:
> hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger
> gedauert.

Vielen Dank. Auf den ersten Blick ist das ein Bitserielles Protokoll - 
analog zur Netbox. Also weder Manchester noch Pulse-Distance, wie es bei 
Fernbedienungen üblich ist. Ich schaue mal, dass ich da einen ersten 
Prototyp im Laufe der kommenden Woche baue.

> Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.

Danke, ich melde mich dann :-)

Gruß,

Frank

Joachim B. schrieb:

> gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?

Ich sehe dafür eigentlich keine Notwendigkeit. IRMP ignoriert das 
Toggle-Bit, weil es meines Erachtens überflüssig ist. Zum "Entprellen" 
der Tastatur stellt IRMP andere (kompatible) Methoden zur Verfügung, 
s.u.

> ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt,
> Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu
> einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste

Das ist einfach: IRMP setzt in flags das BIT IRMP_FLAG_REPETITION, wenn 
eine Wiederholung durch langen Tastendruck entsteht, siehe auch 
IRMP-Artikel.

Einfache Abfrage:

1

    if (irmp_data.flags & IRMP_FLAG_REPETITION)

2

    {

3

      // Benutzer hält die Taste länger runter

4

      // entweder:

5

      //   ich ignoriere die (Wiederholungs-)Taste

6

      // oder:

7

      //   ich benutze diese Info, um einen Repeat-Effekt zu nutzen

8

    }

9

    else

10

    {

11

      // Es handelt sich um eine neue Taste

12

    }

So ist das für alle von IRMP unterstützten Protokolle kompatibel gelöst 
- egal, ob das Protokoll ein Toggle-Bit bereitstellt oder nicht.

> irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie
> ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich
> bekomme 2 steps zum einstellen, mit toogle bit wärs leichter

Ignoriere einfach alle Frames, wo das Bit IRMP_FLAG_REPETITION gesetzt 
ist.

Also in Deinem Fall:

1

    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))

2

    {

3

      // Es handelt sich um eine neue Taste

4

      // ACTION!

5

    }

Und schon hast Du Deine FB-Tasten "entprellt" ;-)

Gruß,

Frank

Joachim B. schrieb:

> funzt, nur natürlich kein repeat mehr.....

Wie hast Du denn mit dem Toggle-Bit das Repeat gemacht? Wenn das 
Toggle-Bit sich nicht(!) ändert, dann Repeat wegen langem Tastendruck? 
Das entspricht doch dem Fall, dass das IRMP-Flag gesetzt ist.

Brauchst Du für jede Taste ein Repeat? Oder nur für bestimmte?

> ich weiss die Lösung hast du schon beschrieben, nur muss ich das in
> meinen Code pressen, oder meinen code neu schreiben, mal sehen

Vielleicht zeigst Du mal einen Auszug aus Deinem Code?

Gruß,

Frank

Hallo Frank,

>> Thomson Protokoll...
> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
> einchecken.
Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Nachdem ich die Fernbedienungen aller z.Zt. in Gebrauch befindlichen 
Geräte mit IRMP einlesen konnte stehe ich nun vor der Aufgabe IRSND in 
Betrieb zu nehmen. Der aktuelle Code aus dem SVN funktionierte auf 
Anhieb, zumindest kam ein IR-Signal im 1 sec. Rythmus. Wie ich oben 
schon erwähnt habe, möchte ich eine Programmierbare FB mit Touch-Screen 
bauen. Die Touch-Software erkennt einen Tastendruck und sendet einen 
"Taste Gedrückt" Event an IRSND, zusammen mit dem Wert für Protokoll, 
Adresse und Komando. Wird der Finger vom Touch genommen kommt der "Taste 
Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende 
Kommando senden.

Frage: Wie lässt sich das mit IRSND realisieren?

Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event 
dürfte nicht funktionieren. Ich habe Funktionen, die unterschiedlich auf 
lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen: 
Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer 
Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h. 
neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der 
gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer 
als neuen Tastendruck. Würde ich also den Befehl "Licht ein/heller" so 
lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde 
jede Wiederholung mit invertiertem Toggle Bit ausgesendet. Dies würde 
vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem 
Tastendruck nicht die Funktion Dimmen, sondern nur 
ein-aus-ein-aus-ein-aus erkannt wird.

Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das 
unterstützen?

Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl 
der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment, 
in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten 
bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND 
einbauen?

Gruß
Cajus

Hallo Cajus,

Cajus H. schrieb:

>> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
>> einchecken.
> Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)

Upps, habe ich das tatäschlich vergessen? Naja, bis auf die 3 defines 
habe ich da nichts großartiges geändert. Okay, werde ich nachholen.

> [...] Wird der Finger vom Touch genommen kommt der "Taste
> Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende
> Kommando senden.
>
> Frage: Wie lässt sich das mit IRSND realisieren?

Gute Frage. Ich würde auf den ersten Blick sagen, dass Du, bis das 
Loslassen-Event kommt, immer wieder irsnd_send_data() aufrufst.

> Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event
> dürfte nicht funktionieren.

Warum nicht? Wenn das Problem lediglich das Toggle-Bit ist, werden wir 
das auch lösen können. Ich habe da auch schon eine Idee, siehe weiter 
unten.

> Ich habe Funktionen, die unterschiedlich auf
> lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen:
> Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer
> Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h.
> neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der
> gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer
> als neuen Tastendruck.

Wenn ich es recht in Erinnerung habe, toggelt IRSND das Toggle-Bit nicht 
in Wiederholungen, die durch den flags-Wert angegeben ist, sondern nur 
bei erneutem Aufruf von irsnd_send_data(). So sollte es jedenfalls 
sein... und so brauchst Du das ja prinzipiell auch.

> Würde ich also den Befehl "Licht ein/heller" so
> lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde
> jede Wiederholung mit invertiertem Toggle Bit ausgesendet.

Korrekt.

> Dies würde
> vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem
> Tastendruck nicht die Funktion Dimmen, sondern nur
> ein-aus-ein-aus-ein-aus erkannt wird.

Okay, habe ich verstanden. Ist das Dein eigens entwickelter Dimmer? 
Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible 
Geschichte, wenn man an andere IR-Protokolle denkt ;-)

> Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das
> unterstützen?

Ja, sollte IRSND berücksichtigen. Bei jedem erneuten Aufruf von 
irsnd_send_data() wird getogglet, innerhalb der flags-Wiederholungen 
nicht.

> Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl
> der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment,
> in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten
> bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".

Ja, genau DAS ist das Problem, was ich bei meiner lernfähigen FB, die 
mein Sohn und ich im gesonderten Artikel vorgestellt hatten, auch hatte.

Deshalb rufe ich irsnd_send_data() in einer Schleife mit flags = 0 auf, 
wenn ich Wiederholungen senden möchte (Code dazu s. ganz unten). Da wird 
aber das Toggle-Bit immer wieder geändert... nicht schön.

Ich hätte folgenden Vorschlag zur Änderung der Software:

1. Die Anzahl der Wiederholungen werden im unteren Nibble von
   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
   siehe Punkt 2.

   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
   unterbindet. Damit kann man dann das endlose Senden dann wieder
   stoppen.

Fürs API würde ich folgende 4 Konstanten vorsehen:

#define IRSND_NO_REPETITIONS       0    // no repetitions
#define IRSND_MAX_REPETITIONS     14    // max # of repetitions
#define IRSND_ENDLESS_REPETITION  15    // endless repetions
#define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Du könntest dann beim "Taste Gedrückt" Event die Funktion 
irsnd_send_data() mit flags = IRSND_ENDLESS_REPETITION aufrufen. Sobald 
Deine Software das "Taste Losgelassen" Event schickt, rufst Du 
irsnd_stop() auf.

Wäre Dir damit geholfen?

> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
> einbauen?

Ja, kann ich machen. Ich komme zu all diesen Änderungen aber frühestens 
am Sontagabend (spät!).

Gruß,

Frank

P.S.
IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch 
noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die 
Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man 
irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird 
das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man 
direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Ich habe das in der DIY-FB erstmal als Hack folgendermaßen gelöst:

1

        while (cnt > 0)                                             // send cnt frames

2

        {

3

            irsnd_send_data (&(irmp_data[k]), TRUE);                // send IR code now

4

5

            while (irsnd_is_busy ())                                // HACK: wait until IRSND is ready

6

            {

7

                ;

8

            }

9

10

            _delay_ms (50);                                         // wait 50 msec to force a pause between frames

11

            cnt--;

12

        };

Ich weiß, das ist unschön. Deshalb werde ich den Bug in IRSND 
schnellstmöglich fixen.

Hallo Frank,

> Ist das Dein eigens entwickelter Dimmer?
Ja
> Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible
> Geschichte, wenn man an andere IR-Protokolle denkt ;-)
Dem will ich nicht widersprechen, aber die Abhängigkeit vom Toggle-Bit 
ist nicht auf meinem Mist gewachsen. Ich habe bei diversen alten Philips 
TV Geräten und anderen mit RC5 arbeitenden FBs eine ähnliches Verhalten 
festgestellt: Lautstärke + gedrückt halten hat nur funktioniert, wenn 
sich das Toggle Bit NICHT geändert hat.

> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>   flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>   Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>   siehe Punkt 2.
>
>   Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

OK. Ich hoffe es schreit dann keiner "Ich brauche aber 20 
Wiederholungen!"

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>   wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>   natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Gut. Vielleicht sollte man eine "Notabschaltung" nach einigen Sekunden 
vorsehen (per #define sollte reichen), sonst ist bei batteriebetriebenen 
Geräten und einem verloren gegangenen Loslass-Event jedes mal die 
Batterie alle ;-). So etwas kann man auch in main() realisieren, dann 
bläht das nicht die Interrupt Routine auf.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>   von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>   unterbindet. Damit kann man dann das endlose Senden dann wieder
>   stoppen.

Perfekt!

> Wäre Dir damit geholfen?

Sehr!

>> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
>> einbauen?
> Ja, kann ich machen.

Danke!
Bitte im Thomson Protokoll auch das Toggle-Bit berücksichtigen!

> IRSND hat im Moment auch noch einen unschönen Bug...
> Nach Aussenden des gewünschten Frames wird die Pause-Zeit zum
> nächsten Frame nicht eingehalten...

Danke für den Hinweis. Ich sehe das aber nicht als so schlimm an, das 
kann ruhig in main() erledigt werden. Schreib doch einfach den Hinweis 
und den Code in irsndmain.c. Ich halte das für völlig ausreichend.

Gruß
Cajus

Frank M. schrieb:

> Ich hätte folgenden Vorschlag zur Änderung der Software:
>
> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von
>    flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
>    Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
>    siehe Punkt 2.
>
>    Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.

Die Änderung ist nun im SVN.

> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
>    wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
>    natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.

Bei flags == IRSND_ENDLESS_REPETITION wird der erzeugte Frame endlos 
geschickt. Nein, stimmt nicht ganz: Nach max. 256 Frames wird aufgehört, 
um die Batterie nicht komplett leerzulutschen :-)

Auch diese Änderung ist im SVN.

> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
>    von Wiederholungen nach Abschluss des aktuell gesendeten Frames
>    unterbindet. Damit kann man dann das endlose Senden dann wieder
>    stoppen.

Ist nun auch im SVN.

> Fürs API würde ich folgende 4 Konstanten vorsehen:
>
> #define IRSND_NO_REPETITIONS       0    // no repetitions
> #define IRSND_MAX_REPETITIONS     14    // max # of repetitions
> #define IRSND_ENDLESS_REPETITION  15    // endless repetions
> #define IRSND_REPETITION_MASK     0x0F  // lower nibble of flags

Ist ebenso umgesetzt.

> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.

Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber 
ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann 
eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt 
wird.

Desweiteren habe ich das THOMSON-Protokoll in den IRSND eingebaut.

Cajus H. (cajush):

Kannst Du das bitte testen und berichten?

Gruß,

Frank

Hy Frank,

gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier 
überlesen ??

Gruß
Torsten

Hallo Frank,

Frank M. schrieb:
> Cajus H. (cajush):
>
> Kannst Du das bitte testen und berichten?

Da ist ein Copy&Paste Fehler in irmp.c
nach
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1

static PROGMEM IRMP_PARAMETER netbox_param =
sollte vermutlich
static PROGMEM IRMP_PARAMETER merlin_param =
heissen...

Danach arbeitet IRMP gut und liefert sinnvolle Werte für das Thomson 
Protokoll.

IRSND - mein main() sieht so aus:

int main (void)
{
  IRMP_DATA irmp_data;

  irsnd_init(); // initialize irsnd
  timer_init(); // initialize timer
  sei();        // enable interrupts

  for (;;)
  {
    irmp_data.protocol = IRMP_THOMSON_PROTOCOL;
    irmp_data.address  = 0x03;
    irmp_data.command  = 0x1d;
    irmp_data.flags    = 15;

    irsnd_send_data (&irmp_data, TRUE);
    _delay_ms (10000);
    irsnd_stop ();
    _delay_ms (3000);

  }
}
Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde 
Pause und wieder von vorne. Es passiert aber folgendes:
- 10 Sekunden Senden
- 3 Sekunden Pause
- Senden bis die Batterie alle ist.
Scheinbar funktioniert das irsnd_stop(); nur einmal ?!
Wenn ich
irmp_data.flags = 14;
setze, dann funktioniert es. (auch mit dem irsnd_stop(), vermutlich weil 
das Senden von 14 Wiederholungen keine 10 Sekunden dauert...)
Das Beenden des Sendens nach 256 Wiederholungen funktioniert, außer im 
Fall oben, da hört IRSND mit dem Senden nicht mehr auf,

Gruß
Cajus

Hallo Cajus,

Cajus H. schrieb:

> Da ist ein Copy&Paste Fehler in irmp.c

Danke, ist korrigiert.

> Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde
> Pause und wieder von vorne. Es passiert aber folgendes:
> - 10 Sekunden Senden
> - 3 Sekunden Pause
> - Senden bis die Batterie alle ist.

Danke für den Test, ich habe den Fehler gefunden und korrigiert. 
irsnd_stop() sollte nun tun, was es soll.

Klappt das denn nun auch mit dem Toggle-Bit, so wie Du es mir 
beschrieben hat? Kann Dein Dimmer nun lange Tastendrücke von mehrfachen 
Tastendrücken per Toggle-Bit unterscheiden?

> Scheinbar funktioniert das irsnd_stop(); nur einmal ?!

Nein, es funktionierte keinmal. irsnd_stop() hatte die falsche Variable 
zurückgesetzt. Das hatte schlicht und ergreifend "Null Effekt".

Korrektur ist im SVN eingecheckt.

Gruß,

Frank

Hallo Torsten,

Torsten K. schrieb:

> gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier
> überlesen ??

Sorry, habs noch nicht geschafft, die Merlin-Tastatur komplett auf alle 
Tastendrücke durchzuchecken. Ich hoffe, ich schaffe es im Laufe der 
Woche.

Gruß,

Frank

Joachim B. schrieb:

> NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO
> kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste
> lasse)

Was meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal 
MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle 
eingeschaltet?

> KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS

Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?

> irgendwas ist instabil

Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist 
angeschlossen und aktiv?

Gruß,

Frank

Joachim B. schrieb:
> keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)

Ich habe Dir bisher nicht antworten können, weil ich noch ein 
Privatleben ohne µC und Elektronik habe ;-)

> ich versuchs mal anders zu erklären
> [...]

Da ich an den Timingparametern nichts geändert habe, kann ich mir im 
Moment gar nicht vorstellen, wo Deine Probleme herrühren. Im Moment kann 
ich mir da nur den fehlenden Quarz vorstellen. Sonst helfen mir da nur 
intensive Tests weiter.

Am Donnerstagabend habe ich vielleicht Zeit, Dein Szenario 
durchzuspielen. Dann kann ich Dir auch antworten. Vorher schaffe ich es 
leider nicht, sorry.

> nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen
> sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann
> ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem
> Vorcode ist, trotzem ist er neu und es sollte toggeln....

Wenn der nächste IR-Frame innerhalb IRMP_KEY_REPETITION_LEN (150 msec) 
reinkommt, dann geht IRMP davon aus, dass die FB automatisch repetiert. 
Dann wird das Repetition-Flag gesetzt. Das funktioniert sehr gut. Wenn 
Du selber mit dem Finger repetierst, wirst Du das nicht so schnell 
schaffen und IRMP setzt dann auch nicht(!) das Repetition-Flag. Also 
vergiss das mit dem Toggle, das geht nur bei RC5, RC6 und Thomson. Bei 
den 27 anderen FB-Protokollen, die IRMP unterstützt, gibt es gar kein 
Toggle-Bit. Daher kann ich das auch gar nicht auswerten.

EDIT: Wenn Du das Toggle-Bit simulieren musst, weil Du anderen Code 
verwendest, der nicht auf das RC5-Toggle-Bit verzichten kann, dann mach 
einfach folgendes:

 - Repetition-Flag gesetzt: dann nicht togglen
 - Repetition-Flag nicht gesetzt: dann togglen

Dann sollte auch RC5-Legacy-Code zusammen mit IRMP funktionieren ;-)

Gruß,

Frank

Joachim B. schrieb:

> bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche
> den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir
> wieder einen KEY wenn vorhanden

Wenn was zu tun ist: Wie lange brauchst Du, um den Key abzuarbeiten?

Bitte möglichst in msec angeben :-)

Sobald IRMP einen Frame eingelesen hat, sperrt er den Empfang weiterer 
IR-Signale solange, bis Du den Code auch abholst.

Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.

1. Du hältst den Finger auf eine FB-Taste
2. IRMP empfängt 1. Frame
3. Du holtst ihn ab und verarbeitest den Key...
4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
6. Es kommt der 3. Frame, aber IRMP empfängt nicht
7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
   fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
   ohne ausgezeichnetes Start-Bit.

Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht 
sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame 
davor nicht abgeholt hast.

Gruß,

Frank

Joachim B. schrieb:
> warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code
> vorhanden ?

Weil Du dann für ein- und dieselbe Taste zwei unterschiedliche Codes 
bekommen würdest.

> dann könnte man sich diese Quälerei sparen, im RC5 wird es ja
> mitgeliefert und ich brauche nicht zu tricksen

Die "Quälerei" hast Du nur deshalb, weil Du Code benutzt, der Original 
RC5 sehen will. IRMP wandelt die Daten aber in ein portables Format, was 
für alle Protokolle einheitlich ist.

> wenn der Umbau aber klappt mit toggle selber erzeugen -
>
> (nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
> toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
> wurde also die FB Taste mal nicht gedrückt war )

Ich habe doch schon geschrieben: Wenn Repetition-Flag nicht gesetzt, 
dann togglen, wenn Flag gesetzt, dann nicht togglen. Hast Du das 
überlesen?

> - für alle Codes waere das auch fein

Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen 
Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das 
Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so 
ein Toggle-Bit.

Gruß,

Frank

Joachim B. schrieb:
> ich hatte mir was überlegt, aber das scheint auch nicht zu klappen

1

> void fb(void)

2

> {

3

>   if (irmp_get_data(&irmp_data) && !strcmp((char

4

> *)Proto[irmp_data.protocol-1], "RC5(x)") )

5

>   {

6

>     L_Com&=0x8000; // loesche L_Com aber behalte das alte toggleBIT

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?

1

>       L_Com  ^= (1<<15);

Auch hier:

Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?

Schau Dir bitte http://www.sbprojects.com/knowledge/ir/rc5.htm an.

merke_rc5 wird bei Dir gesetzt aber nie benutzt?

Machs doch einfach so:

1

void fb(void)

2

{

3

    static uint16_t toggle_bit;

4

    ...

5

6

    toggle_bit ^= (1<<11);    // Togglen

7

    L_Com|= toggle_bit;

8

    ...

9

}

Und noch etwas:

Dein

   if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))

ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:

   if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)

Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein 
Zeichenkettenvergleich. Warum machst Du so etwas?

Gruß,

Frank

Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende 
gehört da auch nicht hin.

Ich schreibe das mal neu:

1

void fb(void)

2

{  

3

  static uint16_t toggle_bit;

4

5

  if (irmp_get_data(&irmp_data) && irmp_data.protocol == IRMP_RC5_PROTOCOL)

6

  {  

7

    L_Com = (((irmp_data.address*100) + irmp_data.command) & 0x7fff); // L_Com aus Adresse und Kommando zusammenbauen

8

9

    if (! (irmp_data.flags & IRMP_FLAG_REPETITION))

10

    {

11

      toggle_bit ^= (1<<11);    // Togglen

12

      L_Com |= toggle_bit;

13

    }

14

15

16

    // ....

17

    // ab hier mache ich weiter wie frueher

18

    // ....

19

20

  }

21

22

  // KEIN ELSE!!!!

23

}

So einfach ist das. :-)

Zusatz:

Was soll der Ausdruck ((irmp_data.address*100) + irmp_data.command) & 
0x7fff)

Adresse mal hundert + Kommando? Verstehe ich nicht. Damit baust Du 
jedenfalls nicht den Original-Frame zusammen, sondern irgendeine 
Zufallszahl.

Joachim B. schrieb:
> also im RC5 Code wäre es nicht künstlich eingebaut, da wird das
> mitgeliefert und damit lief mein altes Programm genau wie geplant, ich
> verstehe halt nicht warum IRMP das nicht durchreichen kann ?

Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe 
Taste 2 verschiedene Codes bekommen.

> weil das für mich der schnellste Weg war ohne IRMP vollständig zu
> erkunden ?

Die Konstante steht in irmp.h und im IRMP-Artikel steht ein 
Anwendungsbeispiel:

   http://www.mikrocontroller.net/articles/IRMP#Anwendung_von_IRMP

Zitat:

1

      if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll

2

          irmp_data.address == 0x1234)                   // Adresse 0x1234

> ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das
> mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja
> korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns
> erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum
> nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun

Jetzt verstehe ich auch, warum Du wolltest, dass ich die Texte in main.c 
vervollständige... :-)

> ich probiere es ;-)))

Viel Glück! :-)

Joachim B. schrieb:
> funktioniert nicht :-(

Du hattest auch meine Frage bzgl. der Position des Toggle-Bits nicht 
beantwortet. Wo muss das stecken? An der 16. Stelle? Oder wie im 
Original an der 12. Stelle?

Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das 
Toggle-Bit stecken muss.

Frank M. schrieb:
> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
> Toggle-Bit stecken muss.

Habs gerade selber gefunden in

   Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Da steht:

1

aus dani code

2

void fb(void)

3

{  if( i_ )

4

  {  //_toggelbit = ( i_ >> 11 & 1);

5

    L_Com  =  (i_ >> 6 & 0x1F)*100;

6

      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

Ein RC5x-Frame sieht folgendermaßen aus:

C6 T A4 A3 A2 A1 A0 C5 C4 C3 C2 C1 C0

Die Zeile

1

    L_Com  =  (i_ >> 6 & 0x1F)*100;

Speichert in L_Com das Hundertfache von der Adresse: A4 A3 A2 A1 A0.
Dabei werden die Kommando-Bits und auch das Toggle-Bit weggeschnitten.

Die Zeile

1

      L_Com  +=  (i_ & 0x3F) | (~i_ >> 7 & 0x40);

sollte wohl C6 C5 C4 C3 C2 C1 C0 speichern, wobei C6 invertiert ist nach 
dem RC5x-Protokoll.

Aber das scheint ein Programmierfehler zu sein: Wenn ich richtig zähle, 
stimmt aber die Bitposition für das C6 nicht.

@Joachim B.

Das Toggle-Bit an 12. Stelle wird hier jedenfalls komplett ignoriert. 
Ich brauche den alten RC5-Code, sonst kann ich Dir nicht helfen.

Joachim B. schrieb:
> ja und ? das war schon immer so, der einzige Unterschied wäre das
> originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das
> jemanden stört !

Sorry, Du hast den Sinn und Zweck von IRMP nicht verstanden. IRMP 
speichert den Frame in einem kompatiblen Format ab und nicht im 
RC5-Format. Ein IRMP-Anwender braucht gar nicht zu wissen, was RC5 ist 
und dass da ein Toggle-Bit ist, was ausmaskiert werden muss!

Der Vorteil von IRMP ist doch gerade die Protokoll-Unabhängigkeit. Soll 
der jetzt da reinschreiben: "Wenn protokoll gleich RC5, schmeiß dass 
Toggle-Bit weg"?

Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den 
Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht 
akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source 
von Dir, sonst wird das nix.

Joachim B. schrieb:
> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte

Jetzt zeige bitte den neuen Source, welcher IRMP nutzt, damit ich das 
vergleichen kann.

Gruß,

Frank

Joachim B. schrieb:

> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
> der State hat ja nie gewechselt, ergo dürfte
>
>

1

>   if( !(irmp_data.flags & IRMP_FLAG_REPETITION) )

2

>       {

3

>      toggle_bit ^= (1<<15);    // Togglen

4

>            L_Com |= toggle_bit;

5

>       }

6

>

>
> nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das
> togglebit unverändert und __p == HAUPTMENU

Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem 
Tastendruck?

Joachim B. schrieb:
> vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP
> nutzen)

Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen 
anzuschauen.

Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann 
musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den 
letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder 
nicht. Das ist alles viel zu umständlich. Dein Source würde sich 
vereinfachen, wenn Du einfach das Flag konsequent abfragst. Es bringt 
nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die 
Anpassung Deines Sources an IRMP.

Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5 
Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit 
gefragt, um da durchzusteigen. Ich machs irgendwann in den nächsten 
Tagen, bin aber viel unterwegs. Kann also etwas dauern.

Gruß,

Frank

Joachim B. schrieb:

> das hatten wir doch versucht ? ohne Erfolg :-(

Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und 
mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so 
gut kennst :-)

Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:

 - Das toggle-Bit muss komplett raus.
 - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
 - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
   (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
    Hose)

> klar ich bin sehr dafür !

Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann 
mit Leben füllst (reinschreiben konkreter numerischer Werte + Test). 
Dann sollte das machbar sein.

> genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top
> down Entwicklung (erwähnte ich das ich kein Softi bin :D)
> PS. brauchst du noch den umfangreichen Rest ?

Dieses "pö a pö" ist der falsche Weg, das macht alles nur 
unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu 
schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste 
machen soll, z.B.

TAB kurz:    nächster Menüpunkt Funktion: menu_down()
TAB lang:    Untermenüaufruf, Funktion: sub_menu()

So in der Richtung...

Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da 
erst übernächste Woche zu.

Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838)
> kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.

hmm, bedingt, was meinst du damit ? als Sender oder Empfänger ?

im Prinzip einfach, an einer TastenMatrix für IRSND den pin-change 
wakeup und senden, als Empfänger dito pinchange belauscht den TSOP

ich habe es in meinem Timer1 gemacht, luca in einem Cam Trigger, da 
werden sogar die Puls/Pausenzeiten per sleep realisiert, also jedes 
delay schickt die CPU schlafen bis die Zeit um ist

Michael K. schrieb:
> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
> gesammelt, zwecks Realisierbarkeit?

Das ist eigentlich nicht Sache des IRMP - als Bibliothek betrachtet.

> Die neueren TSOPs (z.B. TSOP34838) kommen ja mit weniger als 1mA
> aus - da würde sich das IMO schon lohnen.

Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des 
TSOPs über einen ATMega-Pin steuert. Ich habe das so in der Lernfähigen 
Fernbedienung so umgesetzt, die auch IRMP nutzt:

http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP

Dafür muss dann aber das Programm "wissen", wann es den TSOP einschalten 
muss, damit etwas empfangen werden kann. Der Stromverbrauch bei diesem 
Mini-Projekt liegt bei weit unter 1µA.

Gruß,

Frank

Hallo zusammen,

ich verwende IRMP zusammen mit dem IR-Receiver in Hugo Portisch. Da der 
IR-Receiver einen älteren Stand aus dem letzen Jahr enthält, habe ich 
ein Upgrade auf IRMP-SVN-Head gemacht. Das funktioniert soweit auch gut, 
bis auf folgendes:

1. ich kann keine Frequenzen > 10000 benutzen, dann wird nichts mehr 
erkannt. Das könnte auch ein IR-Receiver spezifisches Problem sein. Im 
Thread dort habe ich schon nachgefragt aber keine Antwort bekommen. BTW 
der ältere Stand aus dem letzen Jahr hat das gleiche Problem.

2. Die Ruwido Merlin funktioniert bei mir nicht, es wird nur Müll 
erkannt. Wie ist denn der genaue Status der Merlin Implementierung? 
Sollte das funktionieren?

Folgende Protokolle funktionieren bei mir: RC6A, Samsung32, FDC 
Keyboard.

Michael K. schrieb:
> Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung,
> daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit
> dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware
> sollte nach der Neukompilierung laufen (ich habe es nicht getestet).

Ich habe natürlich F_INTERRUPTS in der IRMP Source geändert und nicht 
über die Windows-DLL. Es funktionert (bei mir) nicht.

KLez schrieb:
> IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das
> Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert
> das ohne extra Hardware allgemein nicht?

Ja, das sollte möglich sein.

Gruß,

Frank

@Frank M.

Darf ich deine Aufmerksamkeit auf diesen Beitrag 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

lenken. Vorallem Punkt 2 würde mich interessieren.
Danke.

KLez schrieb:
> Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es
> so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit
> 10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig
> um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen
> Denkfehler?

Eine 38kHz Trägerfrequenz hat eine Periodenlänge von ca. 26 µsec. Du 
musst die Pulse von ca. 13 µsec softwaremäßig auf mehr als 26 µsec 
verlängern, damit IRMP ein durchgängiges Signal "sieht".

> Wie würdest Du das ganze implementieren?

Ich würde mir einen PCINT-Interrupt auf das Eingangssignal setzen. Dort 
setze ich ein globales Flag namens ir_signal, z.B. so:

1

#define IR_OFF    1             // no IR signal

2

#define IR_ACTIVE 0             // IR signal active

3

4

volatile uint8_t ir_signal = IR_OFF;

5

6

ISR(PCINT1_vect)

7

{

8

    ir_signal = IR_ACTIVE;      // IR is active

9

}

In der normalen Timer_ISR, die Du ja sowieso für den Aufruf der IRMP-ISR 
brauchst, würde ich nach(!) dem Aufruf von irmp_ISR() dieses Flag wieder 
zurücksetzen, also:

1

ISR(TIMER1_COMPA_vect)

2

{

3

  (void) irmp_ISR();

4

  ir_signal = IR_OFF;

5

}

In irmpconfig.h setzt Du:

1

#define input(x)        ir_signal

Der Trick ist, dass Du damit jeden Puls des Trägersignals solange 
softwaremäßig verlängerst, dass die IRMP-ISR ihn mindestens einmal 
"sieht". Da der PCINT bei aktivem IR-Signal viel öfter kommt als die 
IRMP-ISR ausgelöst wird, sollte das so klappen.

Gruß,

Frank

Dirk W. schrieb:
> Darf ich deine Aufmerksamkeit auf diesen Beitrag
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> lenken. Vorallem Punkt 2 würde mich interessieren.

Sorry, zum Punkt 1 kann ich nichts beitragen, ich habe mich bisher nicht 
so tief in Hugos V-USB Port reingehängt.

Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe 
zwischwendurch viele andere interessante Sachen gemacht. ;-)

Ich melde mich dazu nochmal.

Gruß,

Frank

Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Danke fürs Feedback. Ich habe inzwischen noch eine Netbox Tastatur hier 
und die funktioniert auch nicht. Es wird nur gelegentlich RC6A erkannt. 
Evtl. hängt das mit den Merlin Problem zusammen.

Bei der FDC Tastatur ist mir aufgefallen, dass wenn ich längere Zeit 
eine Taste festhalte nicht auschliesslich Events mit Protokoll FDC 
geschickt werden, sondern auch welche mit Protokoll Merlin. Das kann 
aber auch Zufall sein, dass irgendwas überläuft und ausgerechnet Merlin 
Codes geschickt werden. Die Codes sehen auch ziemlich seltsam aus.

eku schrieb:
> um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
> Variablen als const zu markieren, was auch nur logisch ist. Könntest Du
> den SVN Quellcode diesbezüglich bitte aktualisieren.

Ist erledigt.

Gruß,

Frank

Hallo!

Nachdem ich die Frage hier

Beitrag "USB IR Remote Receiver (V-USB + IRMP)"

schonmal gestellt habe und dabei auf dieses Forum verwiesen wurde 
versuch ichs nun hier:

Ich habe diesen Empfänger:

http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:

Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.

Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?

Muß dazu sagen daß ich ein absoluter Laie bin was das Thema 
programmieren o.ä. angeht....

Daniel S. schrieb:
> Nachdem ich die Frage hier
>
> Beitrag "USB IR Remote Receiver (V-USB + IRMP)"
>
> schonmal gestellt habe [...]

... habe ich dir dort geantwortet:

  Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"

Die Antwort gilt natürlich hier auch :-)

Gruß,

Frank

Frank M. schrieb:
> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
> zwischwendurch viele andere interessante Sachen gemacht. ;-)
>
> Ich melde mich dazu nochmal.

Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu 
meiner Anfrage bzgl. Merlin Tastatur ist?

Hallo eku,

eku schrieb:

> würdest Du bitte den Mitschnitt im Anhang analysieren.

Habs mir gerade mal im Editor und mit "irmp -a" angeschaut. Das 
Protokoll ist einfach, aber ziemlich blöde für irmp.

Eigenschaften:

1. Bitserielles Protokoll mit Datenrate von 600Bd
2. 1 Startbit ohne Pause, 8 Datenbits, 1 Stopbit
3. Jeder Frame wird 2x gesendet.

Blöd für IRMP ist der Punkt 2: Ohne Pause nach dem Startbit kann das 
Protokoll nicht eindeutig erkannt werden, weil schon der erste Puls 
1-fache bis 9-fache Länge haben kann.

Ich kann das Protokoll zwar einbauen in IRMP, aber man müsste sämtliche 
anderen Protokolle deaktivieren, damit dieses eindeutig erkannt wird. 
Die Geschichte ist also für einen Multiprotoll-Decoder ziemlich 
unsinnig.

Einfacher wäre es, den TSOP direkt an den UART zu hängen und den UART 
auf 600 Bd einzustellen. Dann kann man die Bytes direkt mit jeder 
üblichen UART-Lib auslesen. Im IRMP wäre es sowieso nichts anderes als 
ein Software-Uart.

Gruß,

Frank

Dirk W. schrieb:
> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
> meiner Anfrage bzgl. Merlin Tastatur ist?

Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich 
zugeben. Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.

Gruß,

Frank

Frank M. schrieb:
> Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich
> zugeben.
Dafür habe ich vollstes Verständnis, daher frage ich auch jetzt erst 
nach, ist ja alles deine Freizeit.

> Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.
Wäre schön. Wie gesagt, mir geht es nur darum: funzt die Merlin mit dem 
Head-Stand oder nicht. Also ein reiner Funktionstest.

narkus schrieb:
> Toll das!! :))
> Großes Lob, Frank!

Danke :-)

>   if (irmp_data.address == 19)

Besser:

>   if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)

So kann Dir keine andere FB, die auch die Adresse 19 (aber ein anderes 
Protokoll) hat, dazwischenfunken.

> Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings
> habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste
> mehrmals schnell hintereinander drücken will (für track skippen oder
> Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder
> Tastendruck wird erkannt. Woran kann das liegen?

IRMP unterscheidet über die Konstante

  IRMP_KEY_REPETITION_LEN

in irmp.c, ob es sich um eine schnell gedrückte Wiederholungstaste 
handelt oder ob die FB selbst "repetiert" - durch langen Tastendruck. 
Offenbar schaffst Du es, innerhalb von 150msec die Taste mehr als einmal 
zu drücken... Du bist da ganz schön schnell :-)

Verkleinere den Wert einfach mal - z.B. von 150.0 auf 120.0 oder 100.0.

> Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem
> Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach
> losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder
> beliebiger fester Wert >0x80, mich interessiert nicht unbedingt *welche*
> Taste losgelassen wurde, sondern dass eine losgelassen wurde)?

Das würde ich ungern machen wollen. Es gibt nämlich durchaus FBs, die 
16-Bit-Kommandos rausschicken, da bräuchte ich dann ein 17. Bit.

Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im 
IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang 
gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und 
entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit 
nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag 
setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen 
Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das 
Toggle-Bit.

Ich schaue mal, dass ich das am Wochenende so einbaue. Du könntest 
parallel dazu aber mal den Wert der Konstanten IRMP_KEY_REPETITION_LEN 
testweise herabsetzen und hier berichten.

Gruß,

Frank

P.S.
Hast Du ein Schaltbild zu Deiner Lösung? Ich habe mit den 
AT90USB-Dingern noch nie was gemacht. Vielleicht wäre das ja eine 
Erwähnung im IRMP-Artikel wert....

jar schrieb:

> das sieht nach meinem "alten" Problem aus,

Nicht ganz: Du hast dir immer gewünscht, dass Dir IRMP das Toggle-Bit 
liefert, damit Du den Code nicht umschreiben musst. ;-)

Sorry, das werde ich nicht machen. Ich brauche eine Lösung für alle 
von IRMP unterstützten Protokolle. Ich kann für RC5/RC6 das Toggle-Bit 
auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.