Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

Matthias Frank schrieb:
> Ja stimmt, mit dem NUBERT-Protokoll hat es gleich funktioniert.
> Allerdings nicht ganz so wie es soll. Die Taste OFF wird seltsamerweiße
> von IRMP nicht erkannt, daher bin ich auch nicht darauf gekommen, dass
> es sich um dieses Protokoll handelt, da ich nur diese eine Taste
> getestet habe.
>
> Außerdem wird jede Taste beim senden irgendwie 2 mal vom Ventilator
> erkannt, obwohl irmp_data.flags auf 0 ist.
> Sind da im Protokoll vlt noch kleine Schönheitsfehler? :P

Da dies 2 gravierende Unterschiede zum NUBERT-Protokoll sind, habe ich 
nun kurzentschlossen ein neues Protokoll "FAN" eingebaut. Das 
berücksichtigt nun die Unterschiede zum Nubert-Protokoll.

Im SVN findet man nun die Version 2.9.0 mit folgenden Neuigkeiten:

  - Neues Protokoll FAN
  - Neues Protokoll MERLIN

Zip-Dateien zum Download kommen später. Erstmal reicht die SVN-Version.

Viel Spaß,

Frank

Ich habe nun folgende 2 Unterprogramme entsprechend ergänzt.

irmp_uart_init

1

#elif defined (__AVR_XMEGA__)

2

3

  PMIC.CTRL |= PMIC_HILVLEN_bm;

4

5

  USARTC1.BAUDCTRLB = 0;

6

  USARTC1.BAUDCTRLA = F_CPU /153600-1;

7

  USARTC1.CTRLA = USART_RXCINTLVL_HI_gc; // High Level (Empfangen)

8

  USARTC1.CTRLB = USART_TXEN_bm | USART_RXEN_bm; //Aktiviert Senden und Empfangen

9

  USARTC1.CTRLC = USART_CHSIZE_8BIT_gc; //Größe der Zeichen: 8 Bit

10

  PORTC.DIR |= (1<<7);  //TXD als Ausgang setzen

11

  PORTC.DIR &= ~(1<<6);

12

13

#else

irmp_uart_putc

1

#if (IRMP_EXT_LOGGING == 0)

2

3

  #  if defined (__AVR_XMEGA__)

4

  while (!(USARTC1.STATUS & USART_DREIF_bm));

5

  USARTC1.DATA = ch;

Reicht es dir, wenn ich hier die Register direkt beschreibe? Weil du die 
initialisierungen immer mithilfe von Defines gelöst hast?

Frank M. schrieb:
> Auch Dir ist das bei 2 Tasten passiert ;-)
Ja ich hatte schon versucht die Tasten nur kurz zu drücken aber 
irgendwie hab ich es bei 2 nicht ganz hinbekommen xD

> Du kannst jetzt erstmal in irmpprotocols.h ändern:
> Dann sollte es bei Dir erstmal laufen - bis auf den Off-Befehl.

ja richtig, wenn ich NUBER_FRAMES ändere geht alles bis auf den Off 
Befehl :P

> Am besten führe ich eine neue Protokoll-Nummer für Dein
> Ventilator-Protokoll ein, um das allgemein zu lösen. Dann kann ich beide
> Abweichungen (nur 1 Frame statt 2 und ein Datenbit mehr, aber kein
> Stop-Bit) berücksichtigen.

Hier scheinen noch Fehler zu sein:

implicit declaration of function 'ANALYZE_PRINTF'
und
undefined reference to ANALYZE_PRINTF'
Da ich nicht wusste, was das bewirkt hatte ich es einfach mal 
auskommentiert.
Gehört das überhaupt da hin?

Die einzelnen Tasten werden jetzt alle erfolgreich erkannt.
Aber wenn ich sie versuche zu senden reagiert der Ventilator jetzt 
überhaupt nicht mehr :-/

Matthias Frank schrieb:
> Ich habe nun folgende 2 Unterprogramme entsprechend ergänzt.

Vielen Dank, habe ich so übernommen. Ist in Version 2.9.1 (SVN).

> Reicht es dir, wenn ich hier die Register direkt beschreibe? Weil du die
> initialisierungen immer mithilfe von Defines gelöst hast?

Die Defines für ATmegas sind nur dafür da, um die unterschiedlichen 
Bezeichnungen der einzelnen UART-Register auszugleichen. Da herrscht in 
der ATmega-Welt ziemliches Chaos. Ich hoffe, dass Atmel hier bei den 
XMegas etwas klüger war...

Matthias Frank schrieb:
> ja richtig, wenn ich NUBER_FRAMES ändere geht alles bis auf den Off
> Befehl :P

Prima, dann sind wir ja auf dem richtigen Weg.

> Hier scheinen noch Fehler zu sein:
>
> implicit declaration of function 'ANALYZE_PRINTF'
> und
> undefined reference to ANALYZE_PRINTF'
> Da ich nicht wusste, was das bewirkt hatte ich es einfach mal
> auskommentiert.
> Gehört das überhaupt da hin?

Ja, das gehört da hin, aber bedingt. Nämlich nur für Linux und Windows. 
Hier werden zusätzliche Analyse-Meldungen ausgegeben, die fürs Debugging 
und Verständnis ziemlich hilfreich sind. Ich habe das in 2.9.1 
korrigiert.

> Die einzelnen Tasten werden jetzt alle erfolgreich erkannt.

Gut.

> Aber wenn ich sie versuche zu senden reagiert der Ventilator jetzt
> überhaupt nicht mehr :-/

Ich habe nun in 2.9.1 folgende Änderungen vorgenommen:

  - Deine Scans neu ausgemessen und die Timings für FAN angepasst
  - Die Pausen zwischen den Frames von 35ms auf 6,6ms gekürzt.

Teste bitte die neue Version nochmal. Sollte es damit immer noch nicht 
gehen, will Dein Ventilator offenbar zumindest bei einigen Kommandos 
doch eine Frame-Wiederholung. Lasse dann bitte IRSND noch einen 
Wiederholungsframe senden, indem Du flags auf 1 setzt. Sollte es erst 
dann funktionieren, haben wir dann evtl. das Dilemma, dass der 
Ventilator einige Befehle ohne Wiederholung versteht, bei anderen 
Befehlen wohl aber doch zwingend eine Wiederholung haben möchte. Denn Du 
sagtest ja, dass der Ventilator manche Befehle 2-fach ausführt beim 
NUBERT-Protokoll.

Auf das Ergebnis bin ich gespannt.

Frank M. schrieb:
> Auf das Ergebnis bin ich gespannt.

Supi vielen dank. Jetzt geht alles so wie es soll :P

Einen kleinen Schönheitsfehler gibt es noch. Wenn NUBERT und FAN 
gleichzeitig aktiviert ist wird jeder Tastendruck als NUBERT erkannt und 
die Off Taste wird nicht erkannt.

Vielleicht sollte man es so machen, dass man nur eines von beiden 
aktivieren kann.

In der Version hast 2.9.1 hast du außerdem standartmäßig das Protokoll 
Fan schon aktiviert. Das kannst du ja theoretisch bei den nächsten 
Versionen wieder abschalten.

>Die Defines für ATmegas sind nur dafür da, um die unterschiedlichen
>Bezeichnungen der einzelnen UART-Register auszugleichen. Da herrscht in
>der ATmega-Welt ziemliches Chaos. Ich hoffe, dass Atmel hier bei den
>XMegas etwas klüger war...

Ich habe gerade noch mal bei einem anderem Controller der Xmega Serie 
geschaut. Da schienen die Register alle gleich zu sein. Was halt denke 
ich vielleicht sein kann ist dass es den Port C nicht gibt (an diesem 
ich den Uart verwende). Dann würde man aber an entsprechender Stelle 
eine Fehlermeldung bekommen.

Da die Register alle gleich zu seinen scheinen kann man auch folgendes 
ändern um auch andere Controller lauffähig zu bekommen:

irsnd.c Zeile 148
statt

1

#elif defined (__AVR_ATxmega128A1U__)

das hier

1

#elif defined (__AVR_XMEGA__)                               // ATxmega

Matthias Frank schrieb:

> Supi vielen dank. Jetzt geht alles so wie es soll :P

Freut mich :-)

> Einen kleinen Schönheitsfehler gibt es noch. Wenn NUBERT und FAN
> gleichzeitig aktiviert ist wird jeder Tastendruck als NUBERT erkannt und
> die Off Taste wird nicht erkannt.

Ja, ich werde FAN automatisch deaktivieren, wenn NUBERT aktiviert ist.

> In der Version hast 2.9.1 hast du außerdem standartmäßig das Protokoll
> Fan schon aktiviert. Das kannst du ja theoretisch bei den nächsten
> Versionen wieder abschalten.

Ja, ich hatte vergessen, es nach dem Testen wieder abzuschalten. Nicht 
sooo schlimm. In 2.9.2 ist es wieder weg.

> Da die Register alle gleich zu seinen scheinen kann man auch folgendes
> ändern um auch andere Controller lauffähig zu bekommen:
>
> irsnd.c Zeile 148
> statt
>

1

> #elif defined (__AVR_ATxmega128A1U__)

2

>

> das hier
>

1

> #elif defined (__AVR_XMEGA__)                               // ATxmega

2

>

Okay, dann mache ich das so.

Gruß und Dank,

Frank

Neue Version 2.9.2 ist online, sowohl zum Download als auch im SVN.

Änderungen:

  - Neues Protokoll S100
  - Kleinere Korrekturen (s. letztes Posting)

Den Artikel zu IRMP habe ich aktualisiert.

Viel Spaß,

Frank

Hallo Zusammen,

hat jemand ne Idee was das für ein Protokoll sein könnte (siehe 
Excel-Sheet). Es handelt sich hierbei um ein 33 kHz Signal welches 
vermutlich über die Pulseweite arbeitet und immer die gleiche 
Pausenlänge hat.

Pause: ca. 300us
Puls lang: ca. 1300us
Puls kurz: ca. 900us

Matthias Laubnitz schrieb:
> hat jemand ne Idee was das für ein Protokoll sein könnte (siehe
> Excel-Sheet). Es handelt sich hierbei um ein 33 kHz Signal welches
> vermutlich über die Pulseweite arbeitet und immer die gleiche
> Pausenlänge hat.
>
> Pause: ca. 300us
> Puls lang: ca. 1300us
> Puls kurz: ca. 900us

Das einzige Pulse Width Protokoll, welches ich in IRMP implementiert 
habe, ist SIRCS von Sony. In Deiner Aufzeichnung fehlt aber ein 
ausgezeichnetes Start-Bit mit einer abweichenden Länge. Ich gehe also 
davon aus, dass Dein Protokoll gar kein besonderes Start-Bit hat. Von 
daher kann das schon kein SIRCs sein.

Wenn Du möchtest, kann ich das Protokoll in IRMP einbauen. Dazu müsstest 
Du mit IRMP Scans erstellen und mir dann schicken. Wie das geht, findest 
Du im IRMP-Artikel:

  https://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_IR-Protokollen

gnuopfer schrieb:
> Hallo,
>
> Ich hab seit Neuestem einen Badezimmerheizkörper bei dem der Thermostat
> über IR angebunden ist. Typ ist "Milux IR Chrono-Thermostat"; (in etwa:
> http://ecommerce.nes-france.com/telecommande/13-stone-digit-anthracite.html)
> Hat jemand dieses Gerät schon mal mit IRMP zum laufen gebracht ? Im Netz
> ist nichts zum verwendeten Protokoll zu finden.

Schicke mir am besten IR-Scans - aufgenommen mit IRMP und IRMP_LOGGING = 
1, siehe Artikel.

Dann kann ich Dir sagen, ob IRMP das Protokoll versteht. Wenn nicht, 
kann ich es einbauen.

Gruß,

Frank

Frank M. schrieb:
> Matthias Laubnitz schrieb:
>> hat jemand ne Idee was das für ein Protokoll sein könnte (siehe
>> Excel-Sheet). Es handelt sich hierbei um ein 33 kHz Signal welches
>> vermutlich über die Pulseweite arbeitet und immer die gleiche
>> Pausenlänge hat.
>>
>> Pause: ca. 300us
>> Puls lang: ca. 1300us
>> Puls kurz: ca. 900us
>
> Das einzige Pulse Width Protokoll, welches ich in IRMP implementiert
> habe, ist SIRCS von Sony. In Deiner Aufzeichnung fehlt aber ein
> ausgezeichnetes Start-Bit mit einer abweichenden Länge. Ich gehe also
> davon aus, dass Dein Protokoll gar kein besonderes Start-Bit hat. Von
> daher kann das schon kein SIRCs sein.
>
> Wenn Du möchtest, kann ich das Protokoll in IRMP einbauen. Dazu müsstest
> Du mit IRMP Scans erstellen und mir dann schicken. Wie das geht, findest
> Du im IRMP-Artikel:
>
> 
https://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_IR-Protokollen

Hallo Frank,

ich habe den IRMP am laufen und meine Fernbedienung für das Klimagerät 
gescannt.
Ich hoffe du erkennst darin mehr als ich.
Bei Fragen meld dich einfach!

Vielen Dank schonmal!

Matthias Laubnitz schrieb:
> Frank M. schrieb:
>> Matthias Laubnitz schrieb:
>>> Pause: ca. 300us
>>> Puls lang: ca. 1300us
>>> Puls kurz: ca. 900us

Hab mal kurz drübergeschaut. Du scheinst Puls und Pause verwechselt zu 
haben. Die TSOPs arbeiten active low.

irmp -a zeigt mir:

Start-Puls: 390µs
Start-Pause: 950µs

Daten-Puls:    390µs
Daten-Pause 0: 950µs
Daten-Pause 1: 1300µs

Scheint tatsächlich was neues zu sein, auf jeden Fall ist die Zuordnung 
nicht eindeutig. Das Protokoll kann ich gerne einbauen. Was ist das für 
ein Klimagerät? Hast Du da eine Bezeichnung? Ich brauche einen Namen für 
das Kind ;-)

Zusatz:

Der Decoder für die Klima-Anlage läuft schon mal. Jetzt habe ich "nur" 
noch das Problem, dass ich die 70 Datenbits in 16 verfügbare Adress- und 
16 verfügbare Kommando-Bits quetschen muss. Da muss ich noch nach 
Redundanzen suchen. Auf den ersten Blick sind jedenfalls jede Menge 
nicht genutzter 0-Bits drin. Außerdem scheint es mindestens zwei 
Toggle-Bits zu geben. Außerdem 4 CRC-Bits.

Wird noch etwas dauern, bis ich die Systematik komplett durchschaut 
habe.

Hey das klingt ja super!
Vielen Dank schonmal!

Also ich kann dir auch noch mehr Funktionen scannen.
Es ist ein Klimagerät mit der Bezeichnung ACP-24 von der Firma Stiebel 
Eltron.

Matthias Laubnitz schrieb:
> ich habe den IRMP am laufen und meine Fernbedienung für das Klimagerät
> gescannt.
> Ich hoffe du erkennst darin mehr als ich.
> Bei Fragen meld dich einfach!

Für die Temperatur-Änderungen ergeben sich folgende Werte:

1

# Temperatur plus 1 Grad:

2

0011001 000010000000010001 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

3

-------------------------------------------------------------------

4

# Temperatur plus 1 Grad:

5

0011001 000010000000010001 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

6

-------------------------------------------------------------------

7

# Temperatur plus 1 Grad:

8

0011001 000010000000010010 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

9

-------------------------------------------------------------------

10

# Temperatur minus 1 Grad:

11

0011001 000010000000010011 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

12

-------------------------------------------------------------------

13

# Temperatur minus 1 Grad:

14

0011001 000010000000010011 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

15

-------------------------------------------------------------------

16

# Temperatur minus 1 Grad:

17

0011001 000010000000010011 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

(die vielen 0en habe ich mal auf "..." gekürzt).

Wenn man sich die letzten 4 Bits anschaut (die hinter dem "..."), wird 
diese Zahl bei "Temperatur plus 1 Grad" hochgezählt, bei "Temperatur 
minus 1 Grad" heruntergezählt. Das sieht für mich so aus, als ob die 
Temperatur mit absoluten Werten übertragen wird.

Jetzt meine Fragen:

  - Hat die Fernbedienung vielleicht ein Display, auf welchem die
    eingestellte Temperatur angezeigt wird? Anders kann ich mir die
    Übertragung absoluter statt relativer Werte nicht erklären.

  - Was möchtest Du erreichen? Eine Fernsteuerung der Klima-Anlage
    per IRSND? Dann ist es zwingend erforderlich, die Bits zu
    entschlüsseln. Ich bräuchte dann parallel zu den Temperatur-Scans
    auch noch die Angabe, was das Display als Temperatur anzeigt.
    Die meisten Klimaanlagen fangen bei 15°C = 0000 an und zählen
    dann in 0,5°C- oder 1°C-Schritten hoch bis 1111.

Frank M. schrieb:
> - Hat die Fernbedienung vielleicht ein Display, auf welchem die
>     eingestellte Temperatur angezeigt wird? Anders kann ich mir die
>     Übertragung absoluter statt relativer Werte nicht erklären.

Ja genau die Fernbedienung hat ein Display auf welchem sämtliche 
Einstellungen angezeigt werden, unter anderem auch die Temperatur.

Siehe auch das zweite Foto hier: 
https://www.stiebel-eltron.de/de/home/produkte-loesungen/klima/klimageraete/lokale_raumklimageraete/lokales_kompakt-raumklimageraetacp24mitzweischlauch-technik-funk/acp_24_2.html#product-detail-layer

Frank M. schrieb:
> - Was möchtest Du erreichen? Eine Fernsteuerung der Klima-Anlage
>     per IRSND? Dann ist es zwingend erforderlich, die Bits zu
>     entschlüsseln. Ich bräuchte dann parallel zu den Temperatur-Scans
>     auch noch die Angabe, was das Display als Temperatur anzeigt.
>     Die meisten Klimaanlagen fangen bei 15°C = 0000 an und zählen
>     dann in 0,5°C- oder 1°C-Schritten hoch bis 1111.

Ich möchte das Klimagerät Internetfähig machen. Also mit einem ESP8266 
eine IR-LED ansteuern. Dazu muss ich die Schnittstelle kennen. Leider 
bin ich mir nicht mehr ganz sicher bei welcher Temperatur ich gescannt 
habe. Meine aber das es über 18°C war und unter 25°C. Ich kann heute 
Abend allerdings noch die genauen Werte posten.

Noch ne Frage:
Wo findest du denn die Kombination 1010 oder 1001?

Matthias Laubnitz schrieb:
> Ja genau die Fernbedienung hat ein Display auf welchem sämtliche
> Einstellungen angezeigt werden, unter anderem auch die Temperatur.

Okay, das erklärt einiges.

> Siehe auch das zweite Foto hier:
> 
https://www.stiebel-eltron.de/de/home/produkte-loesungen/klima/klimageraete/lokale_raumklimageraete/lokales_kompakt-raumklimageraetacp24mitzweischlauch-technik-funk/acp_24_2.html#product-detail-layer

Danke, jetzt kann ich mir das besser vorstellen. Ich nenne das Protokoll 
dann ACP24.

> Ich möchte das Klimagerät Internetfähig machen. Also mit einem ESP8266
> eine IR-LED ansteuern.

Spannend! Okay, das ist sehr sinnvoll. Sobald wir die Bedeutung der Bits 
geknackt haben, baue ich das Protokoll auch noch in IRSND ein.

> Leider
> bin ich mir nicht mehr ganz sicher bei welcher Temperatur ich gescannt
> habe. Meine aber das es über 18°C war und unter 25°C. Ich kann heute
> Abend allerdings noch die genauen Werte posten.

Das wäre auf jeden sinnvoll. Ich brauche nur 2 Temperatur-Werte und die 
dazugehörenden Scans, damit wir den Offset haben. Deine FB macht 
1°C-Schritte, dann könnte das zum Beispiel so aussehen:

0000 15°C
0001 16°C
0010 17°C
0011 18°C
....
1111 30°C

Welche ist bei Dir die niedrigste und die höchste Temperatur, die Du 
einstellen kannst? Die Antwort könnte den Scan schon erübrigen, wenn die 
Differenz zwischen Maximal- und Minimalwert genau 15 ergibt ;-)

Matthias Laubnitz schrieb:
> Noch ne Frage:
> Wo findest du denn die Kombination 1010 oder 1001?

Die finde nicht ich, sondern IRMP (unter Linux) aus den Scans, nachdem 
ich das Protokoll in IRMP eingebaut habe. IRMP erzeugt dann aus den 
Puls-/Pause-Paaren:

   390µS Puls /  950µs Pause eine 0
   390µS Puls / 1350µs Pause eine 1

Daraus ergibt sich dann ein Bitmuster, das ein Mensch aus den Scans 
nicht unbeding sofort erkennen kann.

1

# Einschalten

2

# ADR  P      ?          ?????     TTTT

3

001100 1 0000 1 00000000 00100 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8400, f=0x00

4

001100 1 0000 1 00000000 00111 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8400, f=0x00

5

001100 1 0000 1 00000000 10000 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

6

001100 1 0000 1 00000000 10110 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

7

-------------------------------------------------------------------

8

# Ausschalten

9

# ADR  P      ?          ?????     TTTT

10

001100 0 0000 1 00000000 00101 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0400, f=0x00

11

001100 0 0000 1 00000000 01001 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0401, f=0x00

12

001100 0 0000 1 00000000 10000 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0402, f=0x00

13

001100 0 0000 1 00000000 10110 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0402, f=0x00

14

-------------------------------------------------------------------

15

# Temperatur plus 1 Grad:

16

# ADR  P      ?          ?????     TTTT

17

001100 1 0000 1 00000000 10001 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

18

001100 1 0000 1 00000000 10001 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

19

001100 1 0000 1 00000000 10010 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

20

001100 1 0000 1 00000000 11001 ... 1011 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

21

001100 1 0000 1 00000000 11001 ... 1100 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

22

001100 1 0000 1 00000000 11001 ... 1101 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

23

-------------------------------------------------------------------

24

# Temperatur minus 1 Grad:

25

# ADR  P      ?          ?????     TTTT

26

001100 1 0000 1 00000000 11000 ... 1100 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

27

001100 1 0000 1 00000000 11000 ... 1011 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

28

001100 1 0000 1 00000000 11000 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00

29

001100 1 0000 1 00000000 10011 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

30

001100 1 0000 1 00000000 10011 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

31

001100 1 0000 1 00000000 10011 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00

Die FB sendet nicht wie andere FBs nur einfach ein Kommando, sondern 
sendet bei jedem Tastendruck (egal welchem) ALLE Daten mit ihren 
Absolutwerten komplett.

Folgende Bits habe ich bereits identifiziert:

ADR  = Geräteadresse
P    = Power, 1=ein, 0=aus
TTTT = Temperatur in 1°C-Schritten, vermutlich 0000=15°, 1111=30°

Wenn Du zum Beispiel "Temp-Plus" drückst, wird auch der Power-Zustand 
übertragen. Oder wenn Du ein- bzw. ausschaltest, wird auch die 
Temperatur (hier 0111) übertragen.

Was jedoch noch komplett unklar ist, ist der ?????-Block. Hier werden 
scheinbar willkürliche 5 Bits übertragen, die sich dauernd ändern. 
Vielleicht sind die egal und IRSND kann sie mit irgendwelchen 
Phantasiewerten füllen. Aber besser wäre es, die Bedeutung 
herauszufinden, bevor wir noch zufälligerweise den 
Selbstzerstörungsmechanismus der Anlage auslösen ;-)

Da noch andere Tasten auf der FB sind, wäre es praktisch, wenn Du diese 
auch mal scannen würdest - auch wenn Du sie später nicht brauchst. 
Vielleicht finden wir dann mehr heraus und das Puzzle fügt sich dann 
zusammen.

Ok hier auf die schnelle den Rest! Morgen wieder mehr Kommentar :-)

Matthias Laubnitz schrieb:
> Ja genau die Fernbedienung hat ein Display auf welchem sämtliche
> Einstellungen angezeigt werden, unter anderem auch die Temperatur.

wenn du aber nur + und - 1°C senden kannst kennst du nicht die absolute 
Temperatur.

Im Heizkörperthermostaten Thread wurde das so gelöst das erst mal x 
Schritte rückwärts gegangen wurde, mehr Schritte als nötig und dann die 
entsprechenden Schritte vorwärts das ein Sender auch die absolute 
anzeigen kann da er ja keine Rückmeldung bekommt.

Joachim B. schrieb:
> Matthias Laubnitz schrieb:
>> Ja genau die Fernbedienung hat ein Display auf welchem sämtliche
>> Einstellungen angezeigt werden, unter anderem auch die Temperatur.
>
> wenn du aber nur + und - 1°C senden kannst kennst du nicht die absolute
> Temperatur.

Die FB sendet aber kein + und -, sondern die absolute Temperatur. Diese 
ist offenbar in der FB gespeichert. Bei + wird sie intern inkrementiert 
und dann der absolute Wert geschickt.

Was aber auf jeden Fall Verwirrung geben kann: Wenn IRSND eine 
abweichtende Temperatur sendet, dann zeigt die IR-Fernbedienunng immer 
noch die alte Temperatur an. Drückt man dann Plus, wird die interne 
FB-Temperatur hochgezählt und nicht die in der Klimaanlage zuletzt 
empfangene.

Ich habe die neuen Scans mittlerweile ausgewertet:

1

# Einschalten

2

N VVMMM    ? ???    t vmA x                 y                     TTTT

3

0011001000010000000000100000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

4

0011001000010000000000111000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

5

0011001000010000000010000000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

6

0011001000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

7

0011001000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

8

----------------------------------------------------------------------

9

# Ausschalten

10

N VVMMM    ? ???    t vmA x                 y                     TTTT

11

0011000000010000000000101000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22

12

0011000000010000000001001000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22

13

0011000000010000000010000000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22

14

0011000000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22

15

0011000000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22

16

----------------------------------------------------------------------

17

# Temperatur plus 1 Grad:

18

N VVMMM    ? ???    t vmA x                 y                     TTTT

19

0011001000010000000010001000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23

20

0011001000010000000010001000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24

21

0011001000010000000010010000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25

22

0011001000010000000011001000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26

23

----------------------------------------------------------------------

24

# Temperatur minus 1 Grad:

25

N VVMMM    ? ???    t vmA x                 y                     TTTT

26

0011001000010000000010011000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24

27

0011001000010000000010011000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23

28

0011001000010000000010011000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

29

0011001000010000000011000000000000000000000000000000000000000000001100 p=46 (ACP24), a=0x0000, c=0x800c, f=0x00, power on, temp=27

30

0011001000010000000011000000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26

31

0011001000010000000011000000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25

32

----------------------------------------------------------------------

33

# Einschalten mit 18 Grad

34

N VVMMM    ? ???    t vmA x                 y                     TTTT

35

0011001000000111000000000000000000000000000000000000000000000000000011 p=46 (ACP24), a=0x0000, c=0x8003, f=0x00, power on, temp=18

36

----------------------------------------------------------------------

37

# Erhoehen auf 19 Grad

38

N VVMMM    ? ???    t vmA x                 y                     TTTT

39

0011001000000111000000000000000000000000000000000000000000000000000100 p=46 (ACP24), a=0x0000, c=0x8004, f=0x00, power on, temp=19

40

----------------------------------------------------------------------

41

# Erhoehen auf 20 Grad

42

N VVMMM    ? ???    t vmA x                 y                     TTTT

43

0011001000000111000000000000000000000000000000000000000000000000000101 p=46 (ACP24), a=0x0000, c=0x8005, f=0x00, power on, temp=20

44

----------------------------------------------------------------------

45

# Weiter bis...

46

0011001000000111000000011000000000000000000000000000000000000000000110 p=46 (ACP24), a=0x0000, c=0x8006, f=0x00, power on, temp=21

47

0011001000000111000000011000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22

48

0011001000000111000000011000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23

49

0011001000000111000000011000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24

50

0011001000000111000000011000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25

51

0011001000000111000000011000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26

52

0011001000000111000000011000000000000000000000000000000000000000001100 p=46 (ACP24), a=0x0000, c=0x800c, f=0x00, power on, temp=27

53

0011001000000111000000011000000000000000000000000000000000000000001101 p=46 (ACP24), a=0x0000, c=0x800d, f=0x00, power on, temp=28

54

0011001000000111000000011000000000000000000000000000000000000000001110 p=46 (ACP24), a=0x0000, c=0x800e, f=0x00, power on, temp=29

55

----------------------------------------------------------------------

56

# 30 Grad

57

N VVMMM    ? ???    t vmA x                 y                     TTTT

58

0011001000000111000000011000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

59

----------------------------------------------------------------------

60

# 30 Grad

61

N VVMMM    ? ???    t vmA x                 y                     TTTT

62

0011001000000111000000011000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

63

----------------------------------------------------------------------

64

# Luefter auf Stufe 1

65

N VVMMM    ? ???    t vmA x                 y                     TTTT

66

0000001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

67

----------------------------------------------------------------------

68

# Luefter auf Stufe 2

69

N VVMMM    ? ???    t vmA x                 y                     TTTT

70

0001001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

71

----------------------------------------------------------------------

72

# Luefter auf Stufe 3

73

N VVMMM    ? ???    t vmA x                 y                     TTTT

74

0010001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

75

----------------------------------------------------------------------

76

# Luefter auf Automatik

77

N VVMMM    ? ???    t vmA x                 y                     TTTT

78

0011001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

79

----------------------------------------------------------------------

80

# Modus Lueften

81

N VVMMM    ? ???    t vmA x                 y                     TTTT

82

0011010000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x000f, f=0x00, power off, temp=30

83

----------------------------------------------------------------------

84

# Modus Entfeuchten

85

N VVMMM    ? ???    t vmA x                 y                     TTTT

86

0011011000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

87

----------------------------------------------------------------------

88

# Modus ???

89

N VVMMM    ? ???    t vmA x                 y                     TTTT

90

0000100000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x000f, f=0x00, power off, temp=30

91

----------------------------------------------------------------------

92

# Modus kuehlen

93

N VVMMM    ? ???    t vmA x                 y                     TTTT

94

0011001000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

95

----------------------------------------------------------------------

96

# Nacht-Mode

97

N VVMMM    ? ???    t vmA x                 y                     TTTT

98

1011001000000111000001000000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

99

----------------------------------------------------------------------

100

# Automatik-Programm aktivieren

101

N VVMMM    ? ???    t vmA x                 y                     TTTT

102

0011101000000111000001001000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

103

----------------------------------------------------------------------

104

# Timer 1

105

N VVMMM    ? ???    t vmA x                 y                     TTTT

106

0011001000000111000010000010000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

107

----------------------------------------------------------------------

108

# Timer 2

109

N VVMMM    ? ???    t vmA x                 y                     TTTT

110

0011001000000111000010001000000000000000000010000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

111

----------------------------------------------------------------------

112

# Timer 1 und 2

113

N VVMMM    ? ???    t vmA x                 y                     TTTT

114

0011001000000111000010001010000000000000000010000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

Dabei ist:

1

TTTT = Temperatur + 15 Grad

2

        TTTT

3

        ----------

4

        0000        ???

5

        0001        ???

6

        0010        ???

7

        0011        18 Grad

8

        0100        19 Grad

9

        0101        20 Grad

10

        0110        21 Grad

11

        ...

12

        1111        30 Grad

13

14

N    = Nacht-Modus

15

        N

16

        ----------

17

        0           aus

18

        1           ein

19

20

VV   = Luefter-Stufe, v muss 1 sein!

21

        VV   v

22

        ----------

23

        00   1      Stufe 1

24

        01   1      Stufe 2

25

        10   1      Stufe 3

26

        11   1      Automatik

27

28

MMM  = Modus

29

        MMM  m

30

        ----------

31

        000  0      Ausschalten

32

        001  0      Einschalten

33

        001  1      Kuehlen

34

        010  1      Lueften

35

        011  1      Entfeuchten

36

        100  1      ???

37

        101  1      ---

38

        110  1      ---

39

        111  1      ---

40

41

A    = Automatik-Programm

42

        A

43

        ----------

44

        0           aus

45

        1           ein

46

47

t   = Timer

48

        t   x y

49

        ----------

50

        1   1 0     Timer 1

51

        1   0 1     Timer 2

Die Kunst besteht nun darin, die 70 Bits aus dem Frame in 16 
IRMP-command-Bits zu quetschen. Das habe ich nun folgendermaßen gemacht:

1

ACP24-Frame:

2

3

N VVMMM    ? ???    t vmA x                 y                     TTTT

4

0011001000010000000000100000000000000000000000000000000000000000000111 

5

6

IRMP-command - Bits 15 bis 00:

7

8

        1111110000000000

9

        5432109876543210

10

        ----------------

11

        NAVVvMMMmtxyTTTT

Dann kann man mit folgenden C-Funktionen die einzelnen Features der 
ACP24-Klimaanlage steuern:

1

#include "irmp.h"

2

#include "irsnd.h"

3

4

#define IRMP_ACP24_TEMPERATURE_MASK         0x000F                                          // TTTT

5

6

#define IRMP_ACP24_SET_TIMER_MASK           (1<<6)                                          // t

7

#define IRMP_ACP24_TIMER1_MASK              (1<<5)                                          // x

8

#define IRMP_ACP24_TIMER2_MASK              (1<<4)                                          // y

9

10

#define IRMP_ACP24_SET_MODE_MASK            (1<<7)                                          // m

11

#define IRMP_ACP24_MODE_POWER_ON_MASK       (1<<8)                                          // MMMm = 0010 Einschalten

12

#define IRMP_ACP24_MODE_COOLING_MASK        (IRMP_ACP24_SET_MODE_MASK | (1<<8))             // MMMm = 0011 Kuehlen

13

#define IRMP_ACP24_MODE_VENTING_MASK        (IRMP_ACP24_SET_MODE_MASK | (1<<9))             // MMMm = 0101 Lueften

14

#define IRMP_ACP24_MODE_DEMISTING_MASK      (IRMP_ACP24_SET_MODE_MASK | (1<<10) | (1<<8))   // MMMm = 1001 Entfeuchten

15

16

#define IRMP_ACP24_SET_FAN_STEP_MASK        (1<<11)                                         // v

17

#define IRMP_ACP24_FAN_STEP_MASK            0x3000                                          // VV

18

#define IRMP24_ACP_FAN_STEP_BIT             12                                              // VV

19

#define IRMP_ACP24_AUTOMATIC_MASK           (1<<14)                                         // A

20

#define IRMP_ACP24_NIGHT_MASK               (1<<15)                                         // N

21

22

23

// possible values for acp24_set_mode();

24

#define ACP24_MODE_COOLING                  1

25

#define ACP24_MODE_VENTING                  2

26

#define ACP24_MODE_DEMISTING                3

27

28

static uint8_t temperature = 18;                                                    // 18 degrees

29

30

static void

31

acp24_send (uint16_t cmd)

32

{

33

    IRMP_DATA irmp_data;

34

35

    cmd |=  (temperature - 15) & IRMP_ACP24_TEMPERATURE_MASK;

36

37

    irmp_data.protocol = IRMP_ACP24_PROTOCOL;

38

    irmp_data.address  = 0x0000;

39

    irmp_data.command  = cmd;

40

    irmp_data.flags    = 0;

41

42

    irsnd_send_data (&irmp_data, 1);

43

}

44

45

void

46

acp24_set_temperature (uint8_t temp)

47

{

48

    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

49

50

    temperature = temp;

51

    acp24_send (cmd);

52

}

53

54

void

55

acp24_off (void)

56

{

57

    uint16_t    cmd = 0;

58

    acp24_send (cmd);

59

}

60

61

#define ACP_FAN_STEP1       0

62

#define ACP_FAN_STEP2       1

63

#define ACP_FAN_STEP3       2

64

#define ACP_FAN_AUTOMATIC   3

65

66

void

67

acp24_fan (uint8_t fan_step)

68

{

69

    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

70

71

    cmd |= IRMP_ACP24_SET_FAN_STEP_MASK | ((fan_step << IRMP24_ACP_FAN_STEP_BIT) & IRMP_ACP24_FAN_STEP_MASK);

72

73

    acp24_send (cmd);

74

}

75

76

void

77

acp24_set_mode (uint8_t mode)

78

{

79

    uint16_t    cmd = 0;

80

81

    switch (mode)

82

    {

83

        case ACP24_MODE_COOLING:    cmd = IRMP_ACP24_MODE_COOLING_MASK;     break;

84

        case ACP24_MODE_VENTING:    cmd = IRMP_ACP24_MODE_VENTING_MASK;     break;

85

        case ACP24_MODE_DEMISTING:  cmd = IRMP_ACP24_MODE_DEMISTING_MASK;   break;

86

        default: return;

87

    }

88

    acp24_send (cmd);

89

}

90

91

void

92

acp24_program_automatic (void)

93

{

94

    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_AUTOMATIC_MASK;

95

    acp24_send (cmd);

96

}

97

98

void

99

acp24_program_night (void)

100

{

101

    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_NIGHT_MASK;

102

    acp24_send (cmd);

103

}

Ich nehme mal an, dass ich spätestens morgen die ACP24-Unterstützung 
komplett habe. Dann kann das direkt am lebenden Objekt so getestet 
werden.

Das sieht ja super aus. Ich bin gespannt. Hast du noch nen Tipp für 
IR-Led?

Version 2.9.4 ist online.

Änderungen für IRMP und IRSND:

  - Neues Protokoll ACP24 für Stiebel-Eltron-Klimaalagen.

Das ACP24-Protokoll ist im Artikel detailliert beschrieben - 
insbesondere die Entschlüsselung der Bits. Auch die oben aufgeführten 
C-Beispielfunktionen findet man dort auch nochmal.

Matthias Laubnitz schrieb:
> Das sieht ja super aus. Ich bin gespannt. Hast du noch nen Tipp für
> IR-Led?

Ich nehme mal an, dass Du keine großen Reichweiten benötigst. Daher 
kannst Du so ziemlich jede IR-LED benutzen, z.B. SFH-409. Gibt es bei 
Reichelt für 30ct. Die Schaltung zum Anschließen der LED findest Du im 
Artikel:

  https://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

Soll es eine stärkere IR-LED sein, dann: SFH4550. Die kannst Du mit 1A 
pulsen. Beachte aber, dass der Austrittswinkel nur 3° beträgt, d.h. Du 
musst schon ziemlich genau zielen.

Viel Spaß,

Frank

Hat schon mal jemand IRMP auf STM32Cube ausprobiert?

Jörg R. schrieb:
> Hat schon mal jemand IRMP auf STM32Cube ausprobiert?

Mir ist jedenfalls nichts bekannt.

Gruß,

Frank

Cyclotron schrieb:0
> Nubert sollte umbennannt werden in Toshiba, denn er basiert auf den
> Toshiba TC9148P welcher auch noch von Princeton als PT2248 produziert
> wird.

Vielen Dank für den Hinweis. Ich habe mir das Protokoll vom TC9148P mal 
angeschaut. Das scheint tatsächlich zu passen. Vermutlich kann ich das 
FAN-Protokoll (für Ventilatoren), welches sich bis auf die Anzahl der 
Frame-Wiederholungen nur unwesentlich von Nubert unterscheidet, mit 
diesen konkreten Angaben aus dem Datenblatt auf ein IRMP-Protokoll 
reduzieren.

Wie bist Du darauf gekommen? Fernbedienung aufgeschraubt?

Cyclotron schrieb:
> Jepp. Mich hatte mal interressiert wer was sendet.

Was mich mal interessiert: Welches Gerät steuert Deine Fernbedienung 
konkret? Offenbar werden diese Toshiba-ICs universell eingesetzt, 
nämlich nicht nur bei Lautsprechersystemen, sondern auch bei 
Ventilatoren.

Neue Version 2.9.5 von IRMP und IRSND ist online.

Änderung:

  * Neues Protokoll TECHNICS

Viel Spaß,

Frank

Hallo zusammen,

hier mal eine grundsätzliche Idee, um das "Interruptflimmern" zu 
reduzieren:

 *Request for Comments*:

Was denkt ihr über die Möglichkeit, IRMP in einem Modus betreiben zu 
können, wo alles über einen Pin-Change-Interrupt läuft?

Die State-Machine müsste dabei nur marginal umgeschrieben werden. 
Anstatt die Aufrufe zu zählen und aus der bekannten Frequenz die 
Pulsdauern zu berechnen könnte bei jedem Wechsel des Pin-Status die Zeit 
auf einem frei-laufenden Timer abgefragt werden, und dann aus der Zeit 
seit dem letzten Statuswechsel alle Dauern berechnet werden.
Ein (langsam laufender) Timerinterrrupt kann dann eventuell fertige 
Kommandos freigeben und die "Ready-Flag" setzen.

Hierdurch könnte man IRMP viel einfacher zusammen mit wirklich 
timingkritischen Abläufen wie USB-CDC (bei der Initialisierung) 
einsetzen. Außerdem reduziert sich auch die CPU-Last, weil (fast) 
ausschließlich nur dann für IRMP das Programm unterbrochen wird, wenn 
auch etwas zu tun ist.

Di P. schrieb:
> Was denkt ihr über die Möglichkeit, IRMP in einem Modus betreiben zu
> können, wo alles über einen Pin-Change-Interrupt läuft?

Da denke ich schon seit einiger Zeit drüber nach, da mich die 15.000 
Interrupts pro Sekunde auch ziemlich stören.

Ich bin mir aber noch nicht so sicher, ob das Umschreiben tatsächlich 
nur "marginal" ist. Die Auswertung der Bits muss dann im 
Pin-Change-Interrupt geschehen, eine etwaige Timeout- und 
Fehler-Behandlung aber weiterhin in einem Timer-Interrupt.

Denn es gibt einige Protokolle (NEC, NEC16, NEC48, MATSUSHITA, TECHNICS 
uws.), wo sich erst anhand eines Timeouts klären lässt, um welches 
Protokoll es sich tatsächlich handelt. Beispiel MATSUSHITA und TECHNICS: 
Beide Protokolle benutzen dasselbe Timing, aber unterschiedlich viele 
Bits. Ein TECHNICS-Frame ist kürzer. Ausserdem müssen Fehler bei der 
Übertragung (Empfang eines unvollständigen Frames) die Statemachine 
zurücksetzen. Da reicht ein Pin-Change-Interrupt nicht aus: der wartet 
u.U. ewig.

Hinzu kommt noch das "Problem", dass IRMP mittlerweile nicht nur auf 
AVRs, sondern auch auf diversen STM32, Xmegas und Pics läuft. Auch hier 
muss dann ein neuer Port erstellt werden, wobei ich von Xmegas und Pics 
wenig bis keine Ahnung habe.

Außerdem muss dann noch die "Zusammenarbeit" mit IRSND geklärt und 
programmiert werden. Da nützt ein Pin-Change-Interrupts gar nichts. Aber 
man könnte natürlich einen Timer flexibler "einstellen", um nur noch 
Timer-Interrupts dann zu generieren, wenn der Pegel tatsächlich 
gewechselt werden muss.

Aber meinetwegen: Irgendwann muss der Sprung ins kalte Wasser gewagt 
werden. Ich werde die Aufgabenstellung mal in den nächsten Tagen 
angehen.

EDIT:
Es gibt noch eine andere Möglichkeit, den Hauptprozessor zu entlasten: 
Man nimmt einen ATTiny25/45/85 (je nach Anzahl der benötigten 
Protokolle), flasht dort IRMP und IRSND drauf und macht die 
Kommunikation mit dem Hauptprozessor über Soft-Uart. Dann brauchen pro 
Frame von/zum Hauptprozessor lediglich eine Handvoll Bytes übertragen zu 
werden. Das minimiert dann den Aufwand auf dem Hauptprozessor extrem.

Frank M. schrieb:
> Da denke ich schon seit einiger Zeit drüber nach, da mich die 15.000
> Interrupts pro Sekunde auch ziemlich stören.

Danke für die ausführliche Antwort :)

Mit den einzelnen Protokollen kenne ich mich nicht aus. Das von dir 
beschriebene Problem könnte ggf. durch einen "timestamp" des letzten 
und des ersten Pin-Change gelöst werden. Im Time-Out könnte dann die 
Dauer des letzten Befehls bestimmt werden.

Deinen Vorschlag für IRSND finde ich plausibel. Das könnte gut klappen - 
ich kanns aber überhaupt nicht genau einschätzen, da ich den Teil noch 
nicht verwendet habe.

An die Variante mit einem dedizierten Mini-µC hab ich auch schon 
gedacht. Die Variante ist aber für mich aus Platz- und Aufwandsgründen 
nicht gut machbar.

Frank M. schrieb:
> Aber meinetwegen: Irgendwann muss der Sprung ins kalte Wasser gewagt
> werden. Ich werde die Aufgabenstellung mal in den nächsten Tagen
> angehen.

Cool! cheers

eku schrieb:
> Ich mach das mit der Dekodierung von 433MHz RF Signalen so, dass die
> Zeiten zwischen den Pegelwechseln von der ISR in einen Ringpuffer
> geschrieben werden. Die Auswerung erfolgt dann außerhalb der ISR.

Ich habe auch schon überlegt, die Dekodierung komplett aus der ISR 
rauszuziehen. Das braucht dann aber ein wenig mehr RAM. Beim 
Kasikyo-Protokoll mit 48 Bits wären das dann mindestens 96 Bytes.

Jetzt ist das anders: Durch die instantane Dekodierung wird aus 2 Zeiten 
(Puls + Pause) direkt ein einzelnes Bit.

eku schrieb:
> Die Konvertierung kann doch bereits starten, bevor das Telegramm
> vollständig empfangen wurde. Das macht die ISR von IRMP doch auch schon
> so.

Ja, natürlich. Ich bezog mich nur auf Deinen Satz:

      "Die Auswerung erfolgt dann außerhalb der ISR."

> Mein Dekoder für Wetterstationstelegramme mit 48Bit Information kommt
> mit einem Ringpuffer von 16 Shorts, je 8 für Low und High-Zeiten, aus.
> Es muss sichergestellt sein, dass die Dekodierroutine genügend
> Rechenzeit bekommt, so dass der Ringpuffer nicht überläuft.

Achso, Du meinst Speichern der Zeiten im Ringbuffer, aber 
On-the-Fly-Auswertung in der Hauptroutine. Das ist aber schon eine sehr 
spezielle Situation, welche die Allgemeinheit der User wohl so nicht 
unbedingt bereitstellen kann. Wer weiß, wo die Hauptroutine gerade so 
hängt... Im Extremfall wird der Ringbuffer randvoll.

Version 2.9.6 von IRMP ist online.

Einzige Änderung:

  - Portierung auf STM8

Der Artikel wurde an den entsprechenden Stellen aktualisiert.

Mein Dank geht an Axel Schwenke für den sauberen Port auf STM8.

Eine Neuigkeit über IRSND:

Ich habe die IRSND-Bibliothek nach Android (Java) portiert und in die 
Android-App "RemoteButler" aus dem Projekt Remote IRMP eingebaut.

Damit ist es möglich, nicht nur übers WLAN IRMP-codierte Frames an 
IRMP-Satelliten im Netz zu schicken, sondern auch den IR-Transmitter im 
Handy direkt zu verwenden. Das Handy lässt sich dann als 
Universal-Fernbedienung benutzen.

Es sind bisher ca. 50% aller von IRSND unterstützten Protokolle 
umgesetzt. Weitere werden folgen.

Im Anhang findet Ihr App RemoteButler.apk, die man am besten direkt am 
Handy über Download installiert. Dafür muss man jedoch in den 
Einstellungen die Installation von Apps aus "anderen Quellen" erlauben.

Das Senden von IR-Frames über Android wird von immer mehr Handys 
unterstützt, u.a. vom Galaxy S4 und diversen HTC-Smartphones. Genau an 
diese Anwender ist die Beta-Version gerichtet, nämlich um diese 
Geschichte zu testen.

Mit RemoteButler lassen sich auf insgesamt 24 Bildschirmseiten über die 
Oberfläche Fernbedienungen "zusammenklicken". Wie das geht, ist im 
Artikel Remote IRMP näher erklärt. Die dort zum Download angebotene 
Version von RemoteButler ist jedoch älter und unterstützt das Senden 
über den internen IR-Transmitter natürlich noch nicht.

Auf jeder Bildschirmseite (durch Wischen nach rechts/links auswählbar) 
lassen sich neben einem Titel in 20 Zeilen und 4 Spalten insgesamt bis 
zu 80 Fernbedienungstasten definieren. Diesen kann man zuweisen:

    - IRMP-Satellit: Hier immer "IR Transmitter" auswählen!
    - Text für Beschriftung
    - Protokollnummer (dez.)
    - Adresse (dez.)
    - Kommando (dez.)
    - Farbe der Taste

Die Taste "Anlernen" ist hier mangels IR-Empfänger ohne Funktion. Diese 
ist nur gedacht für die Zusammenarbeit mit den IRMP-Satelliten aus 
Remote IRMP.

In den Konfigurationsmodus gelangt man über den Menü-Eintrag 
"Bearbeiten". Mit Druck auf den Speichern-Button wird der 
Konfigurationsmodus wieder beendet. Eine neue Taste kann man definieren, 
indem man einfach auf eine leere Fläche tippt. Dann erscheint die neue 
Taste. Durch erneutes Tippen kann man diese dann konfigurieren. Löschen 
kann man eine Taste durch längeres Antippen.

Ein paar Tipps dazu:

Ihr könnt beim Konfigurieren mehrere Zeilen (für spätere Tasten oder zur 
optischen Abtrennung) freilassen. Sobald der Konfigurationsmodus 
verlassen wird, werden die Leerzeilen "zusammengequetscht", so dass die 
FB dann kompakter aussieht. Werden in einer Zeile nur 3 statt 4 Tasten 
definiert, werden diese 3 Tasten anschließend zentriert, so dass sie 
dann mittig ausgerichtet werden.

Im Anhang seht Ihr dazu ein paar ScreenShots. Ich habe mir damit schon 
eine FB für den Fernseher, DVD-Player und eine Nikon-Kamera 
zusammengebaut. Mit letzterem kann ich den Fernauslöser an der Kamera 
per Handy auslösen - sehr praktisch!

Hauptgrund dieser Beta-Version ist es, das ganze Programm mal 
durchzuchecken. Viele der Protokolle sind nicht nur ungetestet, auch am 
Komfort kann man noch einiges verbessern, wie Copy&Paste und das 
Verschieben von Tasten oder ganzen Bildschirmseiten oder auch Einfügen 
von Leerzeilen. Später soll man seine eigenen FB-Konfigurationen 
seitenweise auf einen Server schicken können, um sie da in einem Fundus 
einzupflegen, aus dem sich dann alle RemoteButler-Nutzer bedienen, d.h. 
die fertigen Konfigurationen wieder herunterladen können.

Aber zunächst sollten erstmal die Protokolle laufen. Da bin ich auf Eure 
Unterstützung angewiesen.

Folgende Protokolle habe ich bereits umgesetzt:

SIRCS
NEC
SAMSUNG
MATSUSHITA
KASEIKYO
RECS80
RC5
DENON
RC6
SAMSUNGG32
APPLE
RECS80EX
JVC
RC6A
NIKON
NEC16
NEC42
LEGO
THOMSON
LGAIR
SAMSG48
MERLIN
PENTAX

Aber längst alle sind noch nicht getestet. Ich habe mir dafür eine 
Test-Seite in RemoteButler zusammengeklickt, siehe 5-Test.png. Die 
Protokolle, welche die Manchester-Codierung verwenden (also z.B. RC5, 
RC6 und RC6A) bringen das Programm zum Crash... das habe ich schon 
rausgefunden. Offenbar hab ich das noch einen Bug beim Encodieren von 
Manchester-Codes. Bei den anderen Protokollen wird durchaus etwas 
ausgesandt. Diese kann man dann mit einem real existierenden Gerät oder 
mit einem IRMP-Empfänger selbst austesten. NEC und NIKON laufen 
jedenfalls mit real existierenden Geräten einwandfrei.

Über Feedback würde ich mich sehr freuen. Bitte dann bei der Gelegenheit 
Name und Version des Smartphones angeben. Sollten mehr Infos nötig sein, 
bitte melden.

Als letztes: Das Programm erwartet eine Mindest-Android-Version von 
4.4.2. Solltet Ihr ein Smartphone mit einer älteren Android-Version 
haben, in welchem ein IR-Transmitter verbaut ist, bitte melden. Ich 
versuche dann, das Programm auch für eine ältere Version 
zusammenzubauen.

Viel Spaß,

Frank

Update:

Den Bug im Manchester-Encoder von RemoteButler konnte ich beseitigen. 
RC5, RC6 und Co. sollten daher nun auch laufen.

Außerdem sind folgende Protokolle hinzugekommen:

GRUNDIG
NOKIA
SIEMENS
FDC
RCCAR
RUWIDO
IR60
BOSE
TELEFUNKEN
ROOMBA
LGAIR
TECHNICS

Damit verbleiben nun nur noch 13 exotische Protokolle - von insgesamt 
47.

Das Update findet Ihr im Anhang.

Viel Spaß,

Frank

Ein weiteres Update von RemoteButler findet Ihr im Anhang.

Man kann nun im Beabeitungsmodus die Tasten per Copy, Cut & Paste 
kopieren oder aussschneiden und anschließend wieder einfügen. Ausserdem 
ist es möglich, Leerzeilen einzufügen oder ganze Zeilen auch wieder zu 
löschen.

Mit diesem Patch kann man irmp/irsend auch mit Teensy 3.x verwenden. 
Dies ist ein Arduino Clone mit 32Bit Prozessor.

@ Frank M, wenn du willst kanst du diesen Patch auf den svn trunk 
anwenden

ciao Achill

Achill H. schrieb:
> Mit diesem Patch kann man irmp/irsend auch mit Teensy 3.x verwenden.

Sehr schön! Danke!

Ich habe nahezu alle Deine Änderungen übernommen, bis auf diese:

1

+#  ifndef memcpy_P

2

 #  define memcpy_P                      memcpy

3

+#  endif

Ich habe das eher "klassisch" aufgelöst:

1

#elif defined(TEENSY_ARM_CORTEX_M4)

2

#  define PROGMEM

3

#  define memcpy_P                      memcpy

4

5

#else

6

#  define PROGMEM

7

#  define memcpy_P                      memcpy

... auch wenns hier redundant ist.

Noch eine Frage. Das hier:

1

/* helper function: attachInterrupt wants void(), but irmp_ISR is uint8_t() */

2

void timerinterrupt()

3

{

4

  // only when tsop dont see the ir_led flashing

5

  irsnd_ISR();              // call irsnd ISR

6

  irmp_ISR();               // call irmp ISR

7

8

/*

9

  // do not recive when sending (tsop see the ir_led)

10

  if (! irsnd_ISR())          // call irsnd ISR

11

  {                           // if not busy...

12

    irmp_ISR();               // call irmp ISR

13

  }

14

*/

15

}

habe ich nicht recht verstanden. Warum kannst Du den Return-Wert von 
irsnd_ISR() denn nicht prüfen? Das wäre eigentlich wichtig, um keine 
Geister-Echos durch das eigene Senden reinzubekommen.

> Dies ist ein Arduino Clone mit 32Bit Prozessor.

Muss ich mir mal anschauen, danke.

> @ Frank M, wenn du willst kanst du diesen Patch auf den svn trunk
> anwenden

Ich habs eingepflegt - allerdings mit der Hand. Einige diffs - 
entstanden durch abweichende Einrückungen in nicht-relevanten 
Abschnitten - waren mir nicht ganz geheuer. Ich mache so etwas gerne 
händisch, wenn der Aufwand gering ist. Bei dieser Gelegenheit kann ich 
nämlich direkt den Code verstehen, Typos beseitigen, zusätzliche 
Kommentare einpflegen und fehlerhafte Einrückungen korrigieren.

Vielen Dank für Deine Arbeit! Der Port auf Teensy kommt mit dem nächsten 
Release.

Neue Version 2.9.7 von IRMP und IRSND ist online.

Änderungen IRMP:

 - 17.11.2015: Neues Protokoll: PANASONIC
 - 17.11.2015: Portierung auf ESP8266
 - 17.11.2015: Portierung auf Teensy (3.x)

Änderungen IRSND:

 - 17.11.2015: Neues Protokoll: BOSE
 - 17.11.2015: Neues Protokoll: PANASONIC
 - 17.11.2015: Portierung auf Teensy (3.x)

Vielen Dank an Wolfgang S. für die Portierung auf ESP8266, Achill Hasler 
für die Portierung auf Teensy.

Hallo Frank,
wenn der Empänger vom angeschlossen Sender nicht gesehen werden kann 
(Empfänger aussen, Sender innen bei den Geräten) dann ist es besser 
beide Funktionen in der isr aufzurufen.

1

  // only when tsop dont see the ir_led flashing

2

  irsnd_ISR();              // call irsnd ISR

3

  irmp_ISR();               // call irmp ISR

Dammit empfängt und sendet er nur mit der verzögerung der Packet-länge, 
nach kompletter Erkennung wird gleich mit dem Senden dieses Paketes 
begonnen. D.h. Auch während des Senden kann Empfangen werden. Dabei muss 
der Empfänger eine andere IRMP_DATA Struktur befüllen als die gesendete.
Im angehängten Bild sieht man wie dass zusammen geht. (blau tsop, rot 
ir-diode, 15khz)

1

APPLE P:B A:1A C:A 0

2

APPLE P:B A:1A C:A 1

3

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111111111111111111111100000000001111111111111111111111111000000000011111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111110000000000111111110000000001111111110000000001111111110000000001111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111110000000001111111111111111111111111100000000011111111100000000011111111100000000011111111100000000011111111000000000011111111000000000111111111111111111111111110000000001111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111000000000111111110000000001111111110000000001111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111100000000011111111111111111111

4

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111100000000011111111100000000011111111100000000011111111000000000011111111000000000111111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111111111111111111111000000000011111111111111111111111110000000000111111110000000001111111110000000001111111110000000001111111110000000001111111111111111111111111100000000011111111111111111111111110000000000111111111111111111111111100000000011111111111111111111111111000000000111111111000000000111111111000000000111111111000000000111111110000000000111111110000000001111111110000000001111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111100000000001111111100000000011111111100000000011111111111111111111

bei

1

  // do not recive when sending (tsop see the ir_led)

2

  if (! irsnd_ISR())          // call irsnd ISR

3

  {                           // if not busy...

4

    irmp_ISR();               // call irmp ISR

5

  }

überliest er jedes zweite gesendete Packet, da ja den Empfang während 
des Senden abgschalten ist.
ABER Dies muss man so machen, wenn der TSOP von der IR-Diode geblitzt 
wird!

oder meinst du den Kommntar? Bei Arduino werden isr mit void fn(void) 
installiert, uint8_t fn(void) können nicht installiert werden.

1

  Timer1.attachInterrupt(timerinterrupt);

Die Einrückungen sind dadurch entstanden, weil dein Editor nun spaces 
durch tabs ersetzt. Ich arbeite normalerweise mit tab 2, Du wohl mit tab 
4. Am besten stellst du deinen Editor so ein, dass er nur spaces 
einfügt, auch wenn du tab drückst.

Das Beispiel unter irmp/examples/Arduino.ino muss unter 
irmp/examples/Arduino/Arduino.ino stehen, dammit die Arduino IDE dieses 
Beispiel anzeigen und kompilieren kann. Kannst du das noch verschieben?

Ich hab den neuen code gleich ausprobiert, alles soweit ok

PS: neu sind Panasonic und Bose Protokoll. In irsend.c Zeile 2413 & 2428 
benutzt aber im folgendem mega #if (z 2471) fehlt der bose define?

Im Bild sieht man auch, dass nicht wirklich das geschickt wird, was 
Empangen wurde, apple: sendet Paket, repeat-puls (solange man auf der 
Taste ist), ende-Paket. irsend sendet Paket, Paket(..), kein ende-Paket.

Die lib selbst gefällt mir, verwendet habe ich sie auch schon mit Atmel 
Projekten. merci für deinen Einsatz

ciao Achill

Hallo Achill,

Achill H. schrieb:

> wenn der Empänger vom angeschlossen Sender nicht gesehen werden kann
> (Empfänger aussen, Sender innen bei den Geräten) dann ist es besser
> beide Funktionen in der isr aufzurufen.

Ja, natürlich, dann geht das.

> Im angehängten Bild sieht man wie dass zusammen geht.

Vielen Dank für das Bild. Darf ich das im Artikel IRMP verwenden? 
Dann könnte ich das Verhalten dort besser erklären.


> bei [...]
> überliest er jedes zweite gesendete Packet, da ja den Empfang während
> des Senden abgschalten ist.

Ja, wenn man den Finger runterhält, stimmt das. Das habe ich bisher 
nicht bedacht. Danke für den Hinweis.

> ABER Dies muss man so machen, wenn der TSOP von der IR-Diode geblitzt
> wird!

Ja.

> oder meinst du den Kommntar?

Ja, den hatte ich missverstanden. Für mich sah es so aus, als ob Du 
wegen dieses Kommentars das if() weggenommen hättest. Schließlich hast 
Du es ja auskommentiert noch stehen lassen.

Ich werde beide Möglichkeiten im Source dokumentieren, wann welcher Fall 
sinnvoller ist.

> Die Einrückungen sind dadurch entstanden, weil dein Editor nun spaces
> durch tabs ersetzt. Ich arbeite normalerweise mit tab 2, Du wohl mit tab
> 4. Am besten stellst du deinen Editor so ein, dass er nur spaces
> einfügt, auch wenn du tab drückst.

Der ist schon seit Jahren so eingestellt, dass er nur Spaces speichert. 
;-)

Egal. War nicht schlimm.

> Das Beispiel unter irmp/examples/Arduino.ino muss unter
> irmp/examples/Arduino/Arduino.ino stehen, dammit die Arduino IDE dieses
> Beispiel anzeigen und kompilieren kann. Kannst du das noch verschieben?

Upps, das wusste ich nicht. Ich fand die Idee mit dem 
examples-Verzeichnis eigentlich sehr gut und dachte daran, unter 
examples zukünftig weitere main-Beispiele (PIC, XMEGA, STM32 usw) 
abzulegen, da die jetzige main.c durch die #ifdef-Statements recht 
unübersichtlich geworden ist.

Ja, natürlich, verschiebe ich.

> Ich hab den neuen code gleich ausprobiert, alles soweit ok

Prima, danke.

> PS: neu sind Panasonic und Bose Protokoll. In irsend.c Zeile 2413 & 2428
> benutzt aber im folgendem mega #if (z 2471) fehlt der bose define?

Hm, tatsächlich? Werde ich prüfen.

> Die lib selbst gefällt mir, verwendet habe ich sie auch schon mit Atmel
> Projekten. merci für deinen Einsatz

Danke für die Portierung! :-)

Natürlich kannst du das Bild verwenden. Besser währe aber png Format. 
(kleiner) Wenn ich deine e-mail kennen würde, könnte ich dir diese 
Bilder und weiter scans direkt schicken.

> Der ist schon seit Jahren so eingestellt, dass er nur Spaces speichert.
Das währe gut, wenn du das wider so machen würdest. (In letzten svn up 
sind sehr viele tabs dazugekommen in den sourcen)

ciao Achill

Achill H. schrieb:
> Natürlich kannst du das Bild verwenden. Besser währe aber png Format.
> (kleiner) Wenn ich deine e-mail kennen würde, könnte ich dir diese
> Bilder und weiter scans direkt schicken.

Meine E-Mail-Adresse steht in jedem Source-Modul oben im Header ;-)

> Das währe gut, wenn du das wider so machen würdest. (In letzten svn up
> sind sehr viele tabs dazugekommen in den sourcen)

Echt? Mist. Bringe ich in Ordnung.

So, ich habe die oben erwähnten kleineren Mißstände nun behoben:

  - Es sind wieder Spaces in den Sources
  - examples/Arduino.ino -> examples/Arduino/Arduino.ino
  - Fehlendes IRSND_SUPPORT_BOSE_PROTOCOL ergänzt

SVN und die Downloads über den IRMP-Artikel sind aktualisiert.

OK, Pics und Scans werde ich dir direkt zustellen. (heute Abend, denn 
ich bin z.Z. am Geld verdienen)
ciao Achill

Andy P. schrieb:
> Hat noch jemand das Problem, eine der letzten beiden Remote_butler.apks
> zu installieren?

"Die letzten beiden"? Die vom 11.11. geht also, die vom 12.11. und 
14.11. (s.o) nicht?

Vielen Dank für IRMP! Nachdem ich mir mit einem Mega88 und Fleurys LCD 
Lib einen IRMP Analyzer gebastelt hatte, war das Ausklingeln der 
vorhandenen FB und die Implementierung in einem LED Controller auf 
Tiny85 nur noch ein Klacks.

Einfach super!

Andy P. schrieb:

> Auflösung: Komplett deinstallieren + Neuinstallation half.

Hm, eine Erklärung habe ich dafür nicht.

> Jetzt heißt es: alles neu anlernen.

Das ist blöd. Du kannst jedoch, wenn Du Dein Smartphone an den PC 
hängst, die Datei RemoteButler/Buttons.xml auf den PC als Backup 
kopieren. Die neue RemoteButler-App arbeitet jedoch mit 4 Spalten und 
rechnet alte 3-spaltige XML-Dateien um. Umgekehrt geht das leider nicht, 
d.h. die alte kann mit der neuen Datei nichts anfangen.

Andy P. schrieb:
> Irgendwie komm ich nicht zu Potte. Mit der neuen .apk sind die
> Protokolle jetzt nach Alphabet sortiert, nicht mehr nach
> Protokollnummer.

Ja, das stimmt. Ich hielt das so für einfacher. Ich könnte aber hinter 
jedem Protokoll auch noch die dazugehörende Nummer in Klammern 
einblenden.

> Okay, dacht ich, nutzt du halt die nette Anlernfunktion im Remotebutler.
> Die geht nicht, obwohl ein "ipclient rec" vom PC aus funktioniert.

Ja, ich hab da wohl im Protokoll noch irgendwas kaputtrepariert :-(

> Es stellt sich raus, daß man in der Server.xml zwar angeben kann
> "<protocol>TCP</protocol>", die apk laut Wireshark dann aber noch immer
> UDP sendet.

Das kann man in der App aber nicht einstellen. Ich habe in der App 
bisher nur UDP realisiert. Das manuelle Umstellen in der 
Server.xml-Datei bewirkt daher nichts.

> Das wäre nicht so schlimm, wenn der Server nicht ein merkwürdiges
> Verhalten zeigen würde.
> [...]
> Das Problem ist das Byte "answer". REC antwortet im UDP-Modus mit "S"
> statt richtigerweise mit "R".

Ja, da liegt wohl der Hund begraben. Wie ich schon sagte, habe ich 
damals (lang ists her) irgendetwas im Protokoll nach meinen Tests 
kaputtgemacht.

Ich werde mir das heute abend nochmal in Ruhe anschauen und dann 
entscheiden, was da richtig ist.

> In /Remote-irmp/AtmelStudioV6_Source_IR_Remote/ipserver/ipserver.c in
> Zeile 444 steht auch korrekterweise "ipbuf[0] = 'R';".
> Leider bin ich mit meinem Latein am Ende. Dummerweise habe ich grad
> keinen WindowsPC, um mit AtmelStudio die Datei neu zu kompilieren.

Arbeitest Du mit der Version 1.0 oder 1.1 unter

    https://www.mikrocontroller.net/articles/Remote_IRMP#Downloads

Die Version von Rahphael kenne ich nicht. Er hat diese auch ohne mein 
Wissen hochgeladen.

Wie gesagt: Ich schaue mir heute abend mal alles genau an. Dann werde 
ich den Fehler schon finden und beseitigen.

Andy P. schrieb:
> Nein andersrum wäre es sinnvoller- in ipclient einfach:
>

1

 printf (" (name = %s)\n", protoname[protocol]);

Habe es so gemacht:

1

printf ("protocol name = %s\n", protocol < IRMP_N_PROTOCOLS ? irmp_protocol_names[protocol] : "unknown");

> Im RemoteButler ist die Reihenfolge nach Alphabet schon die intuitivere
> Sortierung. Lediglich das Umrechnen von ipclient-Ausgabe nach
> RemoteButlereingabe wird so wieder ohne Quelltextstudium möglich.

Sollte mit obiger Änderung ja nun erledigt sein.

Ich habe im Remote IRMP-Artikel nun die Version 1.3 hochgeladen. 
Dort ist das mit dem 'R' vs. 'S' im UDP-Teil nun auch bei mir 
korrigiert. ipclient.c mit obiger Änderung ist dort nun auch drin. Die 
EXE-Datei ipclient.exe ist damit auch auf dem neuesten Stand.

Marius schrieb:
> Daher habe ich mir eine Krücke überlegt:
> Ich nehme 2 Mikrokontroller (in meinem Fall ATtiny4313), auf dem einen
> läuft IRMP und auf dem anderen der LED Controller.

Prinzipiell erstmal vom Ansatz her keine schlechte Idee.

> Der IRMP-Controller empfängt also über PD2 das IR Signal (NEC) und soll
> es über PD5 als RC-5 weitergeben.

Das wiederum halte ich für suboptimal, und zwar aus folgenden Gründen:

  - NEC kann man nicht in RC5 quetschen, da in NEC mehr Informationsbits
    als in RC5 stecken.

  - IRSND produziert ein moduliertes Signal mit 36kHz, Deine ASM-RC5-
    Empfangsroutine jedoch möchte ein statisches Signal - so wie
    es ein TSOP fix und fertig liefert.

  - zu aufwändig

> Um es nicht zu kompliziert zu machen, wollte ich in einem ersten Schritt
> ausprobieren, ob dieses "durchreichen" nur mit RC-5 funktioniert.

Theoretisch ginge es, wenn Du nur die für die Unterschiede relevanten 
NEC-Bits (z.B. Tasten 1-9) in einen RC5 quetschst und gleichzeitig die 
36-kHz-Modulation in IRSND abstellst - durch Anpassung der Funktionen 
irsnd_off() und irsnd_on().

Es geht aber viel einfacher: Du koppelst beide µCs über den UART und 
schreibst in main.c:

1

int

2

main (void)

3

{

4

  IRMP_DATA   irmp_data;

5

6

  irmp_init();                 // initialize irmp

7

  // irsnd_init () RAUS!

8

  timer1_init();               // initialize timer

9

  sei ();                     // enable interrupts

10

11

  for (;;)

12

  {

13

    if (irmp_get_data (&irmp_data))

14

    {

15

      uart_putc (0);                           // start byte

16

      uart_putc (irmp_data.protocol);          // protocol

17

      uart_putc (irmp_data.address & 0x00FF);  // address lower byte

18

      uart_putc (irmp_data.address >> 8);      // address upper byte

19

      uart_putc (irmp_data.command & 0x00FF);  // command lower byte

20

      uart_putc (irmp_data.command >> 8);      // command upper byte

21

    }

22

  }

23

}

IRSND kannst Du dann komplett rauswerfen.

Auf der Assembler-Seite holst Du Dir die 1 + 5 Bytes wieder über den 
UART (RX) und machst damit, was Du dann willst. Deine 
RC5-Empfängerroutine kannst Du dann komplett rauswerfen.

> F_INTERRUPTS läuft auf 15000
> in der irmpconfig.h und irsndconfig.h habe ich jeweils NEC und RC5
> aktiviert.

Ja, korrekt.

> eingefügt, wobei dann in der irsnd.c noch folgendes nötig war
>

1

> #if defined (__AVR_ATtiny2313__) || defined (__AVR_ATtiny4313__)

Danke für den Tipp, ich werde den 2313 & 4313 hinzufügen.

P.S.

In Deinem Versuch wäre dies:

1

ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec

2

{

3

    irsnd_ISR())          // call irsnd ISR

4

    irmp_ISR();           // call irmp ISR

5

}

die bessere Wahl, um keine Frames zu verschlucken, während IRSND sendet. 
Das zusätzliche if mit Totschalten von IRMP in der Dokumentation ist nur 
für den Fall drin, dass IRMP den eigenen Output, den IRSND erzeugt, als 
Echo wieder sehen könnte. Das ist aber bei Dir nicht der Fall, da Du 
per Kabel übertragen wolltest.

Wenn Du das aber sowieso mit dem UART löst, dann fliegt IRSND komplett 
raus und die ISR reduziert sich auf:

1

ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec

2

{

3

    irmp_ISR();           // call irmp ISR

4

}

Marius schrieb:
>> Es geht aber viel einfacher: Du koppelst beide µCs über den UART
>
> Das geht leider nicht, da dieser beim zweiten µC schon mit der DMX
> Empfangsroutine belegt ist. Sorry, hatte ich nicht gleich mit erwähnt.

Du könntest auch einen Software-UART auf dem zweiten µC verwenden. Ich 
denke mir, das findest Du auch als ASM-Code.

> Ich dachte an eine Umsetzung auf die Art:
> "Wenn die NEC Taste '1' gedrückt wurde, sende das RC5 Kommando '1'".
> D.h. in dem C-Programm kommt auch eine Art "Übersetzer" mit rein...
> auch wenn das vermutlich umständlich sein wird.

Ja, das ginge. Aber hier müsstest Du schon für Deinen Test:

1

    if (irmp_get_data (&irmp_data))

2

    {

3

      irmp_data.flags = 0;    // reset flags!

4

      irsnd_send_data (&irmp_data, FALSE);

vor dem Senden das Protokoll auf RC5 umstellen, damit Deine 
ASM-RC5-Empfangsroutine überhaupt etwas versteht. Oder hältst Du eine 
RC5-Fernbedienung an den TSOP?

> Dh. ich schaue mir jetzt mal an, ob es klappt, wenn ich die Modulation
> abstelle.

Die folgenden Funktionen reduzierst Du dafür auf folgende 
Minimal-Varianten:

1

void

2

irsnd_init (void)

3

{

4

    IRSND_PORT |= (1<<IRSND_BIT);         // set IRSND_BIT to high

5

    IRSND_DDR |= (1<<IRSND_BIT);          // set IRSND_BIT to output

6

}

7

8

static void

9

irsnd_off (void)

10

{

11

    if (irsnd_is_on)

12

    {

13

        IRSND_PORT |= (1<<IRSND_BIT);     // set IRSND_BIT to high