Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Matthias F. (frank91)


Angehängte Dateien:
  • irmp.c (321 KB, 129 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun folgende 2 Unterprogramme entsprechend ergänzt.

irmp_uart_init
#elif defined (__AVR_XMEGA__)

  PMIC.CTRL |= PMIC_HILVLEN_bm;

  USARTC1.BAUDCTRLB = 0;
  USARTC1.BAUDCTRLA = F_CPU /153600-1;
  USARTC1.CTRLA = USART_RXCINTLVL_HI_gc; // High Level (Empfangen)
  USARTC1.CTRLB = USART_TXEN_bm | USART_RXEN_bm; //Aktiviert Senden und Empfangen
  USARTC1.CTRLC = USART_CHSIZE_8BIT_gc; //Größe der Zeichen: 8 Bit
  PORTC.DIR |= (1<<7);  //TXD als Ausgang setzen
  PORTC.DIR &= ~(1<<6);
  
#else

irmp_uart_putc
#if (IRMP_EXT_LOGGING == 0)
  
  #  if defined (__AVR_XMEGA__)
  while (!(USARTC1.STATUS & USART_DREIF_bm));
  USARTC1.DATA = ch;
  

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

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
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 :-/

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias F. (frank91)


Bewertung
0 lesenswert
nicht lesenswert
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
#elif defined (__AVR_ATxmega128A1U__) 
das hier
#elif defined (__AVR_XMEGA__)                               // ATxmega

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
>
> #elif defined (__AVR_ATxmega128A1U__)
> 
> das hier
>
> #elif defined (__AVR_XMEGA__)                               // ATxmega
> 

Okay, dann mache ich das so.

Gruß und Dank,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Matthias L. (mcl024)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von gnuopfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

mfg,

  gnuopfer

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Matthias L. (mcl024)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Matthias L. (mcl024)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
# Temperatur plus 1 Grad:
0011001 000010000000010001 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Temperatur plus 1 Grad:
0011001 000010000000010001 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Temperatur plus 1 Grad:
0011001 000010000000010010 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Temperatur minus 1 Grad:
0011001 000010000000010011 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Temperatur minus 1 Grad:
0011001 000010000000010011 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Temperatur minus 1 Grad:
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.

: Bearbeitet durch Moderator
von Matthias L. (mcl024)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Matthias L. (mcl024)


Bewertung
0 lesenswert
nicht lesenswert
Noch ne Frage:
Wo findest du denn die Kombination 1010 oder 1001?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.
# Einschalten
# ADR  P      ?          ?????     TTTT
001100 1 0000 1 00000000 00100 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8400, f=0x00
001100 1 0000 1 00000000 00111 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8400, f=0x00
001100 1 0000 1 00000000 10000 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
001100 1 0000 1 00000000 10110 ... 0111 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
-------------------------------------------------------------------
# Ausschalten
# ADR  P      ?          ?????     TTTT
001100 0 0000 1 00000000 00101 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0400, f=0x00
001100 0 0000 1 00000000 01001 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0401, f=0x00
001100 0 0000 1 00000000 10000 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0402, f=0x00
001100 0 0000 1 00000000 10110 ... 0111 p=46 (KLIMA), a=0x000c, c=0x0402, f=0x00
-------------------------------------------------------------------
# Temperatur plus 1 Grad:
# ADR  P      ?          ?????     TTTT
001100 1 0000 1 00000000 10001 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
001100 1 0000 1 00000000 10001 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
001100 1 0000 1 00000000 10010 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
001100 1 0000 1 00000000 11001 ... 1011 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
001100 1 0000 1 00000000 11001 ... 1100 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
001100 1 0000 1 00000000 11001 ... 1101 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
-------------------------------------------------------------------
# Temperatur minus 1 Grad:
# ADR  P      ?          ?????     TTTT
001100 1 0000 1 00000000 11000 ... 1100 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
001100 1 0000 1 00000000 11000 ... 1011 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
001100 1 0000 1 00000000 11000 ... 1010 p=46 (KLIMA), a=0x000c, c=0x8403, f=0x00
001100 1 0000 1 00000000 10011 ... 1001 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
001100 1 0000 1 00000000 10011 ... 1000 p=46 (KLIMA), a=0x000c, c=0x8402, f=0x00
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.

: Bearbeitet durch Moderator
von Matthias L. (mcl024)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok hier auf die schnelle den Rest! Morgen wieder mehr Kommentar :-)

von gnuopfer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> 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.

Danke & gut zu wissen. Allerdins hat die Anbindung des Heizkörpers an 
die Haussteuerung (darum gehts eigentlich :-) ) derzeit noch keine 
Priorität. Wenn es soweit ist werde ich mir das Protokoll auch selbst 
mal ansehen. Der Sender und Empfänger ist ein recht billig wirkender 
Aufbau, ich glaube nicht dass da etwas hochspezielles verbaut ist.

mfg

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
# Einschalten
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000010000000000100000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000010000000000111000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000010000000010000000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
----------------------------------------------------------------------
# Ausschalten
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011000000010000000000101000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22
0011000000010000000001001000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22
0011000000010000000010000000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22
0011000000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22
0011000000010000000010110000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x0007, f=0x00, power off, temp=22
----------------------------------------------------------------------
# Temperatur plus 1 Grad:
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000010000000010001000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23
0011001000010000000010001000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24
0011001000010000000010010000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25
0011001000010000000011001000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26
----------------------------------------------------------------------
# Temperatur minus 1 Grad:
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000010000000010011000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24
0011001000010000000010011000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23
0011001000010000000010011000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000010000000011000000000000000000000000000000000000000000001100 p=46 (ACP24), a=0x0000, c=0x800c, f=0x00, power on, temp=27
0011001000010000000011000000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26
0011001000010000000011000000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25
----------------------------------------------------------------------
# Einschalten mit 18 Grad
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000000000000000000000000000000000000000000000000011 p=46 (ACP24), a=0x0000, c=0x8003, f=0x00, power on, temp=18
----------------------------------------------------------------------
# Erhoehen auf 19 Grad
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000000000000000000000000000000000000000000000000100 p=46 (ACP24), a=0x0000, c=0x8004, f=0x00, power on, temp=19
----------------------------------------------------------------------
# Erhoehen auf 20 Grad
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000000000000000000000000000000000000000000000000101 p=46 (ACP24), a=0x0000, c=0x8005, f=0x00, power on, temp=20
----------------------------------------------------------------------
# Weiter bis...
0011001000000111000000011000000000000000000000000000000000000000000110 p=46 (ACP24), a=0x0000, c=0x8006, f=0x00, power on, temp=21
0011001000000111000000011000000000000000000000000000000000000000000111 p=46 (ACP24), a=0x0000, c=0x8007, f=0x00, power on, temp=22
0011001000000111000000011000000000000000000000000000000000000000001000 p=46 (ACP24), a=0x0000, c=0x8008, f=0x00, power on, temp=23
0011001000000111000000011000000000000000000000000000000000000000001001 p=46 (ACP24), a=0x0000, c=0x8009, f=0x00, power on, temp=24
0011001000000111000000011000000000000000000000000000000000000000001010 p=46 (ACP24), a=0x0000, c=0x800a, f=0x00, power on, temp=25
0011001000000111000000011000000000000000000000000000000000000000001011 p=46 (ACP24), a=0x0000, c=0x800b, f=0x00, power on, temp=26
0011001000000111000000011000000000000000000000000000000000000000001100 p=46 (ACP24), a=0x0000, c=0x800c, f=0x00, power on, temp=27
0011001000000111000000011000000000000000000000000000000000000000001101 p=46 (ACP24), a=0x0000, c=0x800d, f=0x00, power on, temp=28
0011001000000111000000011000000000000000000000000000000000000000001110 p=46 (ACP24), a=0x0000, c=0x800e, f=0x00, power on, temp=29
----------------------------------------------------------------------
# 30 Grad
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000011000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# 30 Grad
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000011000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Luefter auf Stufe 1
N VVMMM    ? ???    t vmA x                 y                     TTTT
0000001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Luefter auf Stufe 2
N VVMMM    ? ???    t vmA x                 y                     TTTT
0001001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Luefter auf Stufe 3
N VVMMM    ? ???    t vmA x                 y                     TTTT
0010001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Luefter auf Automatik
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000101000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Modus Lueften
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011010000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x000f, f=0x00, power off, temp=30
----------------------------------------------------------------------
# Modus Entfeuchten
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011011000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Modus ???
N VVMMM    ? ???    t vmA x                 y                     TTTT
0000100000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x000f, f=0x00, power off, temp=30
----------------------------------------------------------------------
# Modus kuehlen
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000000111000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Nacht-Mode
N VVMMM    ? ???    t vmA x                 y                     TTTT
1011001000000111000001000000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Automatik-Programm aktivieren
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011101000000111000001001000000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Timer 1
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000010000010000000000000000000000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Timer 2
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000010001000000000000000000010000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30
----------------------------------------------------------------------
# Timer 1 und 2
N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000000111000010001010000000000000000010000000000000000000001111 p=46 (ACP24), a=0x0000, c=0x800f, f=0x00, power on, temp=30

Dabei ist:
TTTT = Temperatur + 15 Grad
        TTTT
        ----------
        0000        ???
        0001        ???
        0010        ???
        0011        18 Grad
        0100        19 Grad
        0101        20 Grad
        0110        21 Grad
        ...
        1111        30 Grad

N    = Nacht-Modus
        N
        ----------
        0           aus
        1           ein

VV   = Luefter-Stufe, v muss 1 sein!
        VV   v
        ----------
        00   1      Stufe 1
        01   1      Stufe 2
        10   1      Stufe 3
        11   1      Automatik

MMM  = Modus
        MMM  m
        ----------
        000  0      Ausschalten
        001  0      Einschalten
        001  1      Kuehlen
        010  1      Lueften
        011  1      Entfeuchten
        100  1      ???
        101  1      ---
        110  1      ---
        111  1      ---

A    = Automatik-Programm
        A
        ----------
        0           aus
        1           ein

t   = Timer
        t   x y
        ----------
        1   1 0     Timer 1
        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:
ACP24-Frame:

N VVMMM    ? ???    t vmA x                 y                     TTTT
0011001000010000000000100000000000000000000000000000000000000000000111 

IRMP-command - Bits 15 bis 00:

        1111110000000000
        5432109876543210
        ----------------
        NAVVvMMMmtxyTTTT

Dann kann man mit folgenden C-Funktionen die einzelnen Features der 
ACP24-Klimaanlage steuern:
#include "irmp.h"
#include "irsnd.h"

#define IRMP_ACP24_TEMPERATURE_MASK         0x000F                                          // TTTT

#define IRMP_ACP24_SET_TIMER_MASK           (1<<6)                                          // t
#define IRMP_ACP24_TIMER1_MASK              (1<<5)                                          // x
#define IRMP_ACP24_TIMER2_MASK              (1<<4)                                          // y

#define IRMP_ACP24_SET_MODE_MASK            (1<<7)                                          // m
#define IRMP_ACP24_MODE_POWER_ON_MASK       (1<<8)                                          // MMMm = 0010 Einschalten
#define IRMP_ACP24_MODE_COOLING_MASK        (IRMP_ACP24_SET_MODE_MASK | (1<<8))             // MMMm = 0011 Kuehlen
#define IRMP_ACP24_MODE_VENTING_MASK        (IRMP_ACP24_SET_MODE_MASK | (1<<9))             // MMMm = 0101 Lueften
#define IRMP_ACP24_MODE_DEMISTING_MASK      (IRMP_ACP24_SET_MODE_MASK | (1<<10) | (1<<8))   // MMMm = 1001 Entfeuchten

#define IRMP_ACP24_SET_FAN_STEP_MASK        (1<<11)                                         // v
#define IRMP_ACP24_FAN_STEP_MASK            0x3000                                          // VV
#define IRMP24_ACP_FAN_STEP_BIT             12                                              // VV
#define IRMP_ACP24_AUTOMATIC_MASK           (1<<14)                                         // A
#define IRMP_ACP24_NIGHT_MASK               (1<<15)                                         // N


// possible values for acp24_set_mode();
#define ACP24_MODE_COOLING                  1
#define ACP24_MODE_VENTING                  2
#define ACP24_MODE_DEMISTING                3

static uint8_t temperature = 18;                                                    // 18 degrees

static void
acp24_send (uint16_t cmd)
{
    IRMP_DATA irmp_data;

    cmd |=  (temperature - 15) & IRMP_ACP24_TEMPERATURE_MASK;

    irmp_data.protocol = IRMP_ACP24_PROTOCOL;
    irmp_data.address  = 0x0000;
    irmp_data.command  = cmd;
    irmp_data.flags    = 0;

    irsnd_send_data (&irmp_data, 1);
}

void
acp24_set_temperature (uint8_t temp)
{
    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

    temperature = temp;
    acp24_send (cmd);
}

void
acp24_off (void)
{
    uint16_t    cmd = 0;
    acp24_send (cmd);
}

#define ACP_FAN_STEP1       0
#define ACP_FAN_STEP2       1
#define ACP_FAN_STEP3       2
#define ACP_FAN_AUTOMATIC   3

void
acp24_fan (uint8_t fan_step)
{
    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK;

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

    acp24_send (cmd);
}

void
acp24_set_mode (uint8_t mode)
{
    uint16_t    cmd = 0;

    switch (mode)
    {
        case ACP24_MODE_COOLING:    cmd = IRMP_ACP24_MODE_COOLING_MASK;     break;
        case ACP24_MODE_VENTING:    cmd = IRMP_ACP24_MODE_VENTING_MASK;     break;
        case ACP24_MODE_DEMISTING:  cmd = IRMP_ACP24_MODE_DEMISTING_MASK;   break;
        default: return;
    }
    acp24_send (cmd);
}

void
acp24_program_automatic (void)
{
    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_AUTOMATIC_MASK;
    acp24_send (cmd);
}

void
acp24_program_night (void)
{
    uint16_t    cmd = IRMP_ACP24_MODE_POWER_ON_MASK | IRMP_ACP24_NIGHT_MASK;
    acp24_send (cmd);
}

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.

: Bearbeitet durch Moderator
von Matthias L. (mcl024)


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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Hat schon mal jemand IRMP auf STM32Cube ausprobiert?

von Frank M. (ukw) (Moderator) Benutzerseite


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

Mir ist jedenfalls nichts bekannt.

Gruß,

Frank

von Cyclotron (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nur mal so in den Raum geworfen...

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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Cyclotron (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jepp. Mich hatte mal interressiert wer was sendet.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyclotron (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die die ich habe stammen alle von Super Low-Cost Midi Kompakt Anlagen 
vom Discounter mit denen man gerade mal die Grundsteuerung wie An/Aus, 
Stumm, Lautstärke, Quelle regeln konnte. Die günstigen Japanischen Hifi 
Türme von anfang der 90er hatten die auch.

Sowas z.B.: 
http://www.kalaydo.de/kleinanzeigen/kompaktanlagen/stereo-musikanlage-mit-plattenspieler-und-fb/a/68463446/?search=a2V5d29yZD1tdXNpa2FubGFnZSZzZWFyY2g9U0VBUkNIX0lEX0JBUF9TQUxFJnZlcnRpY2FsPTU%253D

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 2.9.5 von IRMP und IRSND ist online.

Änderung:

  * Neues Protokoll TECHNICS

Viel Spaß,

Frank

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> 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.

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das braucht dann aber ein wenig mehr RAM. Beim
> Kasikyo-Protokoll mit 48 Bits wären das dann mindestens 96 Bytes.

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

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Achill H. (Firma: AH Consulting GmbH) (achillh)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
+#  ifndef memcpy_P
 #  define memcpy_P                      memcpy
+#  endif

Ich habe das eher "klassisch" aufgelöst:
#elif defined(TEENSY_ARM_CORTEX_M4)
#  define PROGMEM
#  define memcpy_P                      memcpy

#else
#  define PROGMEM
#  define memcpy_P                      memcpy

... auch wenns hier redundant ist.

Noch eine Frage. Das hier:
/* helper function: attachInterrupt wants void(), but irmp_ISR is uint8_t() */
void timerinterrupt()
{
  // only when tsop dont see the ir_led flashing
  irsnd_ISR();              // call irsnd ISR
  irmp_ISR();               // call irmp ISR

/*
  // do not recive when sending (tsop see the ir_led)
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
    irmp_ISR();               // call irmp ISR
  }
*/
}

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Achill H. (Firma: AH Consulting GmbH) (achillh)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.
  // only when tsop dont see the ir_led flashing
  irsnd_ISR();              // call irsnd ISR
  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)
APPLE P:B A:1A C:A 0
APPLE P:B A:1A C:A 1
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111111111111111111111100000000001111111111111111111111111000000000011111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111110000000000111111110000000001111111110000000001111111110000000001111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111110000000001111111111111111111111111100000000011111111100000000011111111100000000011111111100000000011111111000000000011111111000000000111111111111111111111111110000000001111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111000000000111111110000000001111111110000000001111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111100000000011111111111111111111
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111100000000011111111100000000011111111100000000011111111000000000011111111000000000111111111000000000111111111111111111111111110000000001111111111111111111111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111111111111111111111000000000011111111111111111111111110000000000111111110000000001111111110000000001111111110000000001111111110000000001111111111111111111111111100000000011111111111111111111111110000000000111111111111111111111111100000000011111111111111111111111111000000000111111111000000000111111111000000000111111111000000000111111110000000000111111110000000001111111110000000001111111111111111111111111100000000011111111100000000011111111111111111111111111000000000111111111111111111111111110000000001111111100000000001111111100000000011111111100000000011111111111111111111

bei
  // do not recive when sending (tsop see the ir_led)
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
    irmp_ISR();               // call irmp ISR
  }
ü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.
  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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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! :-)

: Bearbeitet durch Moderator
von Achill H. (Firma: AH Consulting GmbH) (achillh)


Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Achill H. (Firma: AH Consulting GmbH) (achillh)


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

von Andy P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat noch jemand das Problem, eine der letzten beiden Remote_butler.apks 
zu installieren?

"Möchten Sie ein Update für diese vorhandene App installieren? Ihre 
vorhandenen Daten bleiben erhalten. Die aktualisierte App erhält Zugriff 
auf:
(Neu:) Infrarotübertragung
(Alle:)
SDKarteninhalt ändern/löschen
SDkarten lesen
Voller Netzwerkzugriff

[ Installieren ]"

und nach Druck auf den Button:
"X Anwendung nicht installiert [ Fertig ]"

Android Lollipop 5.1.1
Kernel 3.10.49
Sony Z5c

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Andy P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Boah, bist du auf Zack! Kaum dreht man sich um, antwortet unser Frank. 
So eine Reaktionsgeschwindigkeit kenn ich nichtmal von 
Serviceunternehemen, die dafür höhere 3stellige Summen pro Jahr 
verlangen. RESPEKT!

Habs grad getestet, die vom 11.11. geht auch nicht. Die Version von der 
Artikelseite selbst geht, fragt aber nicht nach Infrarotübertragung. 
(Hat das Z5c nicht). vllt. liegts daran. Kann auch sein, das mein 
Android hier ein Problem mit dem updaten selbst hat statt der neuen 
Software.
Deshalb frag ich erstmal nach ähnlichen Usererfahrungen.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Andy P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andy P. schrieb:
> Kann auch sein, das mein
> Android hier ein Problem mit dem updaten selbst hat statt der neuen
> Software.

Auflösung: Komplett deinstallieren + Neuinstallation half. Jetzt heißt 
es: alles neu anlernen.

von Andy P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Irgendwie komm ich nicht zu Potte. Mit der neuen .apk sind die 
Protokolle jetzt nach Alphabet sortiert, nicht mehr nach 
Protokollnummer. Somit ist ein Übersetzen der Antwort von "ipclient rec 
<IP> <PORT>" nach Eingabeformular nicht mehr so einfach.
Okay, dacht ich, nutzt du halt die nette Anlernfunktion im Remotebutler.
Die geht nicht, obwohl ein "ipclient rec" vom PC aus funktioniert.
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 wäre nicht so schlimm, wenn der Server nicht ein merkwürdiges 
Verhalten zeigen würde.
REC per TCP:
"user@linux:~/Remote-irmp/IP-Client and IPflash/win32_source/ipclient> 
./ipclient rec 192.168.1.20 10001
answer     = R
error code = +
protocol   = 2
addr       = 0x7282
cmd        = 0x00df
flags      = 0

REC per UDP:
user@linux:~/Remote-irmp/IP-Client and IPflash/win32_source/ipclient> 
./ipclient udprec 192.168.1.20 10001
Sent.
answer     = S
error code = +
protocol   = 2
addr       = 0x7282
cmd        = 0x00df
flags      = 0"

Das Problem ist das Byte "answer". REC antwortet im UDP-Modus mit "S" 
statt richtigerweise mit "R".
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andy P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nichts übers Knie brechen, das ist schon so alles okay. Nur wohl ein 
paar Altlasten in Form von nicht geupdateten AVR.


Frank M. schrieb:
> Andy P. schrieb:

> Ich könnte aber hinter jedem Protokoll auch noch die dazugehörende
> Nummer in Klammern einblenden.
Nein andersrum wäre es sinnvoller- in ipclient einfach:
string protoname['SIRCS','NEC','Samsung','Kaseiko','JVC',...];
und statt:
printf ("protocol   = %d\n", protocol);
einfach ergänzend:
printf ("protocol   = %d", protocol); 
printf (" (name = %s)\n", protoname[protocol]);
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.

> Ja, ich hab da wohl im Protokoll noch irgendwas kaputtrepariert :-(
Nee, alles chic. Im Quelltext ist es ja richtig, nur das Binary des 
Servers scheint noch den Bug zu haben.

> Ich habe in der App bisher nur UDP realisiert. Das manuelle Umstellen
> in der Server.xml-Datei bewirkt daher nichts.
Ah, ok, macht Sinn. Ich habs nur aus dem xml geschlußfolgert.

>
> 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';".
> 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.

Das war wohl der richtige Hinweis. Ich habe wohl 1.1 im Einsatz (nach 
Datumsangaben zu urteilen). Und den Teil später nicht weiter gelesen. Da 
steht ja klar:
[code:]
Changelog:
...
- Bugfix: prüfe auf 'R' und 'S' anstatt beides mal auf 'R'
...[/code]

Ich hab morgen wieder eine Windows-Büchse in zur Hand, da kann ich mal 
AVRStudio draufpacken + irserver neu kompilieren.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andy P. schrieb:
> Nein andersrum wäre es sinnvoller- in ipclient einfach:
>
 printf (" (name = %s)\n", protoname[protocol]); 

Habe es so gemacht:
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.

von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich versuche gerade, einen LED Controller zu bauen. Dazu möchte ich 
gerne IR Fernbedienungs-Signale einlesen, idealerweise NEC (wg. der 
China Remotes!).
Jetzt liegt meine Controller Programm aber in ASM vor und ich habe es 
mangels Kenntnisse nicht geschafft, einen lauffähigen NEC-Decoder zu 
basteln. Allerdings ist im Controller eine funktionierende RC-5 Routine.

Deswegen möchte ich jetzt gerne IRMP nutzen...Allerdings fällt die 
native Nutzung flach, da ich ASM und C nicht mischen kann...

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.

Der IRMP-Controller empfängt also über PD2 das IR Signal (NEC) und soll 
es über PD5 als RC-5 weitergeben. Der zweite Controller liest dann über 
PD1 das RC-5 Signal und interpretiert es entsprechend.

Um es nicht zu kompliziert zu machen, wollte ich in einem ersten Schritt 
ausprobieren, ob dieses "durchreichen" nur mit RC-5 funktioniert.
Also ob der LED Controller sozusagen trotz Zwischenschaltung des IRMP 
Controllers noch auf die RC5 Befehle hört.
Erst im zweiten Schritt soll dann die Umwandlung von NEC->RC-5 folgen.

Allerdings läuft irgendetwas momentan noch schief... Ich bin 
Mircocontrolleranfänger :) Habe jetzt die letzen Wochen mich in ASM 
eingearbeitet und nun in die Grundzüge von C. Allerdings reicht mein 
Wissen jetzt bei weitem nicht aus, weshalb ich euch um Hilfe bitte, mir 
einen kleinen Wink zu geben, woran es haken könnte...

Vielen Dank schon vorab!


Hier noch der Code von IRMP:
/*
 * IRMP_ATTINY.c
 *
 * Created: 16.12.2015 10:18:02
 *  
 * IR Input an PD2
 * Output an PD5
 */ 

#include <avr/io.h>
// run ATtiny4313 @ 8 MHz intern
// FUSES: -U lfuse:w:0xe4:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m 
#define F_CPU       8000000UL
#include "irmp.h"
#include "irsnd.h"


#ifndef F_CPU
#error F_CPU unknown
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * ATMEL AVR part:
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */

#include "irmp.h"
#define BAUD  9600L
#include <util/setbaud.h>

#ifdef UBRR0H

#define UART0_UBRRH                             UBRR0H
#define UART0_UBRRL                             UBRR0L
#define UART0_UCSRA                             UCSR0A
#define UART0_UCSRB                             UCSR0B
#define UART0_UCSRC                             UCSR0C
#define UART0_UDRE_BIT_VALUE                    (1<<UDRE0)
#define UART0_UCSZ1_BIT_VALUE                   (1<<UCSZ01)
#define UART0_UCSZ0_BIT_VALUE                   (1<<UCSZ00)
#ifdef URSEL0
#define UART0_URSEL_BIT_VALUE                   (1<<URSEL0)
#else
#define UART0_URSEL_BIT_VALUE                   (0)
#endif
#define UART0_TXEN_BIT_VALUE                    (1<<TXEN0)
#define UART0_UDR                               UDR0
#define UART0_U2X                               U2X0

#else

#define UART0_UBRRH                             UBRRH
#define UART0_UBRRL                             UBRRL
#define UART0_UCSRA                             UCSRA
#define UART0_UCSRB                             UCSRB
#define UART0_UCSRC                             UCSRC
#define UART0_UDRE_BIT_VALUE                    (1<<UDRE)
#define UART0_UCSZ1_BIT_VALUE                   (1<<UCSZ1)
#define UART0_UCSZ0_BIT_VALUE                   (1<<UCSZ0)
#ifdef URSEL
#define UART0_URSEL_BIT_VALUE                   (1<<URSEL)
#else
#define UART0_URSEL_BIT_VALUE                   (0)
#endif
#define UART0_TXEN_BIT_VALUE                    (1<<TXEN)
#define UART0_UDR                               UDR
#define UART0_U2X                               U2X

#endif //UBRR0H

static void
uart_init (void)
{
    UART0_UBRRH = UBRRH_VALUE;                                                                      // set baud rate
    UART0_UBRRL = UBRRL_VALUE;

#if USE_2X
    UART0_UCSRA |= (1<<UART0_U2X);
#else
    UART0_UCSRA &= ~(1<<UART0_U2X);
#endif

    UART0_UCSRC = UART0_UCSZ1_BIT_VALUE | UART0_UCSZ0_BIT_VALUE | UART0_URSEL_BIT_VALUE;
    UART0_UCSRB |= UART0_TXEN_BIT_VALUE;                                                            // enable UART TX
}

static void
uart_putc (unsigned char ch)
{
    while (!(UART0_UCSRA & UART0_UDRE_BIT_VALUE))
    {
        ;
    }

    UART0_UDR = ch;
}

static void
uart_puts (char * s)
{
    while (*s)
    {
        uart_putc (*s);
        s++;
    }
}

static void
uart_puts_P (PGM_P s)
{
    uint8_t ch;

    while ((ch = pgm_read_byte(s)) != '\0')
    {
        uart_putc (ch);
        s++;
    }
}

static char *
itoh (char * buf, uint8_t digits, uint16_t number)
{
    for (buf[digits] = 0; digits--; number >>= 4)
    {
        buf[digits] = "0123456789ABCDEF"[number & 0x0F];
    }
    return buf;
}

static void
timer1_init (void)
{
#if defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)                // ATtiny45 / ATtiny85:

#if F_CPU >= 16000000L
    OCR1C   =  (F_CPU / F_INTERRUPTS / 8) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 8
    TCCR1   = (1 << CTC1) | (1 << CS12);                                    // switch CTC Mode on, set prescaler to 8
#else
    OCR1C   =  (F_CPU / F_INTERRUPTS / 4) - 1;                              // compare value: 1/15000 of CPU frequency, presc = 4
    TCCR1   = (1 << CTC1) | (1 << CS11) | (1 << CS10);                      // switch CTC Mode on, set prescaler to 4
#endif

#else                                                                       // ATmegaXX:
    OCR1A   =  (F_CPU / F_INTERRUPTS) - 1;                                  // compare value: 1/15000 of CPU frequency
    TCCR1B  = (1 << WGM12) | (1 << CS10);                                   // switch CTC Mode on, set prescaler to 1
#endif

#ifdef TIMSK1
    TIMSK1  = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
#else
    TIMSK   = 1 << OCIE1A;                                                  // OCIE1A: Interrupt by timer compare
#endif
}

#ifdef TIM1_COMPA_vect                                                      // ATtiny84
#define COMPA_VECT  TIM1_COMPA_vect
#else
#define COMPA_VECT  TIMER1_COMPA_vect                                       // ATmega
#endif

ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec
{
   if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
  // call other timer interrupt routines...
}

int
main (void)
{
    IRMP_DATA   irmp_data;

  irmp_init();                // initialize irmp
  irsnd_init();               // initialize irsnd
  timer1_init();               // initialize timer
  sei ();                     // enable interrupts
 
  for (;;)
  {
    if (irmp_get_data (&irmp_data))
    {
      irmp_data.flags = 0;    // reset flags!
      irsnd_send_data (&irmp_data, FALSE);
    }
  }
}
F_INTERRUPTS läuft auf 15000
in der irmpconfig.h und irsndconfig.h habe ich jeweils NEC und RC5 
aktiviert.
DAnn hab ich in den irmpconfig
#if defined (ATMEL_AVR) || defined (__AVR_XMEGA__)                      // use PD2 as IR input on AVR @ ATtiny2313
#  define IRMP_PORT_LETTER                      D
#  define IRMP_BIT_NUMBER                       2
und in der irsndconfig.h
#elif defined(ATMEL_AVR)
#  define IRSND_OCx                             IRSND_OC0B              // use OC0B = PD5 @ ATtiny2313
eingefügt, wobei dann in der irsnd.c noch folgendes nötig war
#if defined (__AVR_ATtiny2313__) || defined (__AVR_ATtiny4313__)        // ATtiny23/43 uses OC0B = PD5
#  if IRSND_OCx == IRSND_OC0B                                       // OC0B
#    define IRSND_PORT_LETTER                       D
#    define IRSND_BIT_NUMBER                        5
#  else
#    error Wrong value for IRSND_OCx, choose IRSND_OC0A or IRSND_OC0B in irsndconfig.h
#  endif

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
int
main (void)
{
  IRMP_DATA   irmp_data;

  irmp_init();                 // initialize irmp
  // irsnd_init () RAUS!
  timer1_init();               // initialize timer
  sei ();                     // enable interrupts

  for (;;)
  {
    if (irmp_get_data (&irmp_data))
    {
      uart_putc (0);                           // start byte
      uart_putc (irmp_data.protocol);          // protocol
      uart_putc (irmp_data.address & 0x00FF);  // address lower byte
      uart_putc (irmp_data.address >> 8);      // address upper byte
      uart_putc (irmp_data.command & 0x00FF);  // command lower byte
      uart_putc (irmp_data.command >> 8);      // command upper byte
    }
  }
}

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
>
> #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:
ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec
{
    irsnd_ISR())          // call irsnd ISR
    irmp_ISR();           // call irmp ISR
}

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:
ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec
{
    irmp_ISR();           // call irmp ISR
}

von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

wow, vielen Dank für die schnelle, kompetente und hilfreiche Antwort!!

Frank M. 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.

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.

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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
    if (irmp_get_data (&irmp_data))
    {
      irmp_data.flags = 0;    // reset flags!
      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:
void
irsnd_init (void)
{
    IRSND_PORT |= (1<<IRSND_BIT);         // set IRSND_BIT to high
    IRSND_DDR |= (1<<IRSND_BIT);          // set IRSND_BIT to output
}

static void
irsnd_off (void)
{
    if (irsnd_is_on)
    {
        IRSND_PORT |= (1<<IRSND_BIT);     // set IRSND_BIT to high
        irsnd_is_on = FALSE;
    }
}

static void
irsnd_on (void)
{
    if (irsnd_is_off)
    {
        IRSND_PORT  &= ~(1<<IRSND_BIT);   // set IRSND_BIT to low
        irsnd_is_on = TRUE;
    }
}

static void
irsnd_set_freq (IRSND_FREQ_TYPE freq)
{
}


OFF heißt hier also BIT = high, ON heißt dann BIT = low. Damit 
simulierst Du dann den Ausgang eines TSOP-Empfängers, welcher im 
Ruhezustand HIGH-Pegel hat.

Der originale Code steuert über einen Transistor eine IR-LED an. Da ist 
die Logik sowieso invertiert. Da ist der Ruhezustand nämlich low - genau 
umgekehrt zum TSOP. Schon allein deshalb konnte das so nicht 
funktionieren. Hinzu kommt dann noch die Modulation mit 
50/50-Tastverhältnis. Die Chance für Deine ASM-RC5-Empfangsroutine, 
danebenzugreifen, liegt hier also bei fifty-fifty.

: Bearbeitet durch Moderator
von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja das mit der Modulation hat geklappt.

Ich habe eine RC-5 Fernbedienung, und trotz zwischenschaltung des 
IRMP-Microcontrollers macht der LED-Mikrocontroller jetzt genau das, was 
er lt. RC-5 Kommando machen soll :)
Vielen Dank!!

Jetzt bastel ich wohl mal an einigen switch-case Verzweigungen, die die 
verschiedenen Tastenumwandlungen darstellen...
Oder hast du hier auf Anhieb eine bessere/schnelle Lösung oder C-Befehl 
parat?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marius schrieb:
> Ich habe eine RC-5 Fernbedienung, und trotz zwischenschaltung des
> IRMP-Microcontrollers macht der LED-Mikrocontroller jetzt genau das, was
> er lt. RC-5 Kommando machen soll :)

Freut mich :-)

> Jetzt bastel ich wohl mal an einigen switch-case Verzweigungen, die die
> verschiedenen Tastenumwandlungen darstellen...
> Oder hast du hier auf Anhieb eine bessere/schnelle Lösung oder C-Befehl
> parat?

Nein, ich wüsste jetzt auch nichts besseres als:
    if (irmp_get_data (&irmp_data))
    {
      irmp_data.flags = 0;    // reset flags!

      if (irmp_data.protocol == IRMP_NEC_PROTOCOL && irmp_data.address == 0x00FF)
      {
          irmp_data.protocol = IRMP_RC5_PROTOCOL;
          irmp_data.address = 0;  // Hier aendern!

          switch (irmp_data.command)
          {
              case 0x11: irmp_data.command = 0x12; break;
              case 0x22: irmp_data.command = 0x13; break;
              case 0x33: irmp_data.command = 0x14; break;
              case 0x44: irmp_data.command = 0x15; break;
              default: irmp_data.command = 0x77; break;
          }

          irsnd_send_data (&irmp_data, FALSE);
      }
    }

Alle oben genannten Zahlen sind natürlich Phantasiewerte.

von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
läuft perfekt :)
Dankeschön!!

Jetzt bin ich nur gerade am überlegen, ob es wirklich der ATTiny4313 
sein muss, auf dem das IRMP Programm läuft, oder ob es einen passenden
preiswerteren (und evtl vom Bauraum her kleineren) µC gibt ??
Die hex Datei hat jetzt ganz genau 4096 byte :)

von Won K. (Firma: Outside the Asylum) (the_sane)


Bewertung
0 lesenswert
nicht lesenswert
Der Tiny85 sollte für die Anwendung reichen, der Preisunterschied zum 
Tiny45 ist nicht groß und es wird nicht so eng.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Won K. schrieb:
> Der Tiny85 sollte für die Anwendung reichen, der Preisunterschied zum
> Tiny45 ist nicht groß und es wird nicht so eng.

Kann ich nur unterschreiben. Der Tiny85 ist dafür ideal.

: Bearbeitet durch Moderator
von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

habe jetzt den Tiny85 da und wollte das Programm, dass auf dem Tiny43 
lief, auf den 85 spielen.
In den Einstellung vom AVR Studio ist das richtige Device auch 
ausgewählt, allerdings scheint noch etwas mit den Bezeichnungen nicht zu 
passen.
Denn ich bekomme lauter Fehlermeldungen:
Error  1  'UBRRH' undeclared 
Warning  2  each undeclared identifier is reported only once for each function it appears in  
Error  3  'UBRRL' undeclared 
Error  4  'UCSRA' undeclared 
Error  5  'U2X' undeclared ... 

usw.

Was habe ich vergessen?
Vielen Dank!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marius schrieb:
> Was habe ich vergessen?

Du hast offenbar die Demo-main.c genommen, in welcher UART-Funktionen 
enthalten sind. Die Demo-main.c gibt die IR-Werte auf dem UART aus. Der 
ATTiny hat jedoch keinen UART.

Wirf bitte aus Deiner main.c alles unterhalb
#include "irmp.h"

raus, also ab:
[c]
#define BAUD  9600L
#include <util/setbaud.h>

#ifdef UBRR0H
[c]

bis einschließlich der Funktion itoh(). Du brauchst diese Funktionen 
allesamt nicht.

Drinbleiben müssen timer1_init(), ISR() und main().

Gruß,

Frank

: Bearbeitet durch Moderator
von Marius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat funktioniert!!

Vielen Dank und frohes Fest!!

von Jojo S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, schon wieder IRMP :-)
Ich kann auch noch eine Portierung anbieten, auf mbed. Es scheint hier 
ja wenig mbed User zu geben, aber da das Projekt ja hier entstanden ist 
möchte ich das auch erstmal hier vorzeigen. Danke an Frank und die 
anderen Mitstreiter für die geniale Arbeit, der Einbau in mbed ist 
wirklich sehr einfach.
Zur Implementierung:
Ich habe erstmal nur den Receiver, den Sender baue ich auch noch. Ich 
habe nur den Input Pin in die IRMP Quellen gepackt, den zyklischen 
Aufruf habe im main gelassen. Das ist durch die Basisfunktionen von mbed 
nur ein Einzeiler und hat den Vorteil das man sich noch in die ISR 
einklinken kann, ich habe zum Testen zB eine Laufzeitmessung eingebaut.
mbed ist auf Anwender Ebene eigentlich C++, eine IRMP Receiver und 
Sender Klasse wäre schöner, ist aber aufwändiger weil dann die globalen 
Variablen entsorgt werden müssten. Mehrere Instanzen eines Receivers an 
einem µC macht vielleicht nicht wirklich Sinn, aber den Inputpin im 
Konstruktor zu übergeben ist bei den mbed Komponenten eigentlich 
Standard und macht die Nutzung noch einfacher.
Da die mbed Welt eine eigene Versionsverwaltung hat halte ich hier einen 
Fork für sinnvoll, solche groben Änderungen in die aktuellen Quellen zu 
würgen ist sicher nicht gut. Nachteil ist natürlich das Änderungen am 
Original IRMP Projekt bei Bedarf nachgezogen werden müssen.
mbed gehört ARM und ich habe in den Nutzungsbedingungen nichts davon 
gefunden das man seine Seele verkauft wenn man da Quellcode hostet. Die 
GNU GPL v2 Notiz bleibt natürlich erhalten und ich werde da auch auf 
mikrocontroller.net verweisen. BTW, gibt es die Doku auch in englisch? 
mbed ist ziemlich MultiKulti.
Es gibt mittlerweile >80 Boards mit verschiedensten Cortex-M von allen 
Herstellern die da unterstützt werden, da wird IRMP noch einige Freunde 
gewinnen. Es hat wich gewundert das es noch nicht da vorhanden ist.
Zu den Laufzeiten die ich in meinem Muster gemessen habe:
Prozesser ist ein LPC1347 Cortex-M3 mit 72 MHz, kompiliert erstmal als 
offline LPCXpresso Projekt mit gcc 4.9.3. Bei Optimierung -Os braucht 
die ISR im Mittel 3 µs und max 28 µs, in der Debug Version 4.1 / 36 µs. 
Aktiviert sind die Standardprotolle und RC5.
Konstruktive Kritik ist willkommen, Diskussionen über C++ bitte gleich 
nach /dev/null verschieben.
So sieht das main.cpp jetzt aus:
#include "mbed.h"
#include "irmp.h"

#define LED_ON  0
#define LED_OFF 1

DigitalOut led(P0_14, 1);
DigitalOut flash(P0_12, 1);

Ticker t;

// only for performance test
Timer   timerPerfTest;
int    timeISRMax = 0;
float  timeISRAvg;
int    timeISRAvgSum = 0;
int    countISRCalls = 0;

void irmpISR(void)
{
  int t1 = timerPerfTest.read_us();

  irmp_ISR();        // call irmp ISR

  int timeISR = timerPerfTest.read_us() - t1;    // calc time spent in worker ISR
  if (timeISR > timeISRMax)             // store maximum
    timeISRMax = timeISR;
  timeISRAvgSum += timeISR;            // sum for avg
  countISRCalls++;
}

int main() {
  printf("IRMP on mbed\n");

    led = LED_OFF;
    timerPerfTest.start();

    IRMP_DATA irmp_data;

    irmp_init();                                                            // initialize irmp
    t.attach_us(&irmpISR, 1E6 / F_INTERRUPTS);                // call ISR 15.000 / s

    // infinite loop, interrupts will blink PORTD pins and handle UART communications.
    while (1)
    {
        flash = !flash;

        if (irmp_get_data (&irmp_data))
        {
            // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir sender
            // irmp_data.command is the command code
          // irm_data.flags is press/release information
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
            // printf("proto %d addr %d cmd %d\n", irmp_data.protocol, irmp_data.address, irmp_data.command );

          // sample decoding, turn LED on / off
          if (irmp_data.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 5)    // old RC5 VCR Remote. TV uses address 0
          {
            if (irmp_data.flags == 0)    // switch only on button press
            {
          switch (irmp_data.command)
          {
          case 0:    // Key '0'
            led = LED_OFF;
            break;
          case 1:    // Key '1'
            led = LED_ON;
            break;
          case 53:    // Key 'play'
            printf("bring me a beer!\n");
            break;
          case 54:    // Key 'stop'
            timeISRAvg = (float)timeISRAvgSum / countISRCalls;
            timeISRAvgSum = 0;
            countISRCalls = 0;
            printf("ISR max / avg runtime [microseconds] : %d / %5.2f\n", timeISRMax, timeISRAvg);
            timeISRMax = 0;
            break;
          }
            }
          }

          // log to stdout
            printf("proto %d addr %d cmd %d flags %x name %s\n", irmp_data.protocol, irmp_data.address, irmp_data.command, irmp_data.flags, irmp_protocol_names[irmp_data.protocol] );
        }
    }

}

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Interessante Portierung, ich kannte mbed noch gar nicht. Welches Board 
benutzt du?

Einen Fork von IRMP-MBED fände ich aber ziemlich unschön.

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für diesen Test jetz einen Nachbau von 
https://github.com/sebseb7/pentarm13uxx ,ist zwar kein 'echtes' mbed 
Board ist aber ähnlich wie der DipCortexM3. Ich habe aber noch andere 
LPCxxx Boards, die sollten jetzt ohne weitere Änderung mit der Lib 
laufen.
Die Anpassungen können natürlich in das Original Repository rein. Das 
mbed hat aber einen Online Compiler mit dem man sein Projekt startet. 
Dann kann man über Import eine Lib auswählen und fertig.
mbed wird gerade auf eine neue Version gestellt, das dauert aber schon 
ewig und ist noch sehr unübersichtlich. Der Einstig über die 'Classic' 
Site ist einfacher: https://developer.mbed.org/. Einmal registrieren und 
rechts oben über 'Compiler' ist man in der Welt.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Jojo,

Jojo S. schrieb:

> Ich kann auch noch eine Portierung anbieten, auf mbed.

Sehr schön, ich werde Deine Änderungen ins IRMP-SVN-Repository 
einpflegen. Danke!

> Ich habe erstmal nur den Receiver, den Sender baue ich auch noch.

Also demnächst noch IRSND? Klasse!

> Da die mbed Welt eine eigene Versionsverwaltung hat halte ich hier einen
> Fork für sinnvoll, solche groben Änderungen in die aktuellen Quellen zu
> würgen ist sicher nicht gut.

Kommt darauf an, wieviel Änderungen notwendig wären. Kann ich aber 
schlecht beurteilen.

> Nachteil ist natürlich das Änderungen am
> Original IRMP Projekt bei Bedarf nachgezogen werden müssen.

Ja.

> BTW, gibt es die Doku auch in englisch? mbed ist ziemlich MultiKulti.

Ich wollte schon immer mal die Doku ins Englische übersetzen, habe aber 
bisher immer den Zeitaufwand gescheut. Ich habe aber schon mal eine 
Formatierung fürs Wiki getestet, mit der man den Doku-Text zweispaltig 
formatieren könnte: Links deutsch, rechts englisch - oder umgekehrt. Die 
Nicht-Fliesstext-Segmente wie Codeausschnitte und Tabellen brauchen ja 
nicht in 2 Sprachen übersetzt werden. Der Code wurde von mir sowieso 
schon immer in Englisch kommentiert.

Vielleicht hat jemand Lust, sich an dem Übersetzungsprojekt zu 
beteiligen? Ich würde dann den Artikel schon mal zweispaltig aufbereiten 
und dann können sich gern Leute kapitelweise daran beteiligen. Wäre 
super, wenn IRMP auch über die Landesgrenzen hinaus bekannter werden 
würde.

> So sieht das main.cpp jetzt aus:

Sehr gut. Ich habe mir sowieso vorgenommen, für jede µC-Familie 
zukünftig ein eigenes main.c bzw. main.cpp anzubieten, damit das wieder 
übersichtlicer wird.

Ich baue Deine Änderungen im Laufe der kommenden Woche ein.

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
Als Nutzer und Fan würde ich mich an der Übersetzung beteiligen.

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
danke für die Rückmeldung.
Ich habe den Receivercode mit einer kurzen Beschreibung jetzt auf mbed 
public gemacht: https://developer.mbed.org/users/JojoS/code/IRMP/

Danke auch das du den Code in das SVN übernimmst, die Änderungen sind ja 
überschaubar. Für mbed Nutzer ist der Import über das eigene System 
einfacher und hier geht das Interesse an mbed glaube ich gegen Null, 
deshalb sollte ein Fork hier nichts ausmachen. Ich lasse den Code auf 
mbed erstmal so, mal sehen wie die Resonanz ist, mir würde eine C++ 
Version besser gefallen. Aber erstmal noch die Sendefunktionen einbauen.

An der Übersetzung kann ich mich auch beteiligen. Wäre es nicht 
einfacher die Seite zu kopieren und dann zu übersetzen? Das Layout mit 
den vielen Illustrationen wird zweispaltig sicher unübersichtlich und 
alleine das Layout zu ändern ist schon viel Arbeit.

Wenn du den Code nochmal reorganisieren möchtest: bei mbed ist aus einem 
Board mittlerweile auch >80 mit vielen verschiedenen Prozessoren 
geworden. Da wurde das über einen HAL (hardware abstraction layer) 
gelöst. Es gibt /hal in dem C-headerfiles als interface für die internen 
Funktionen liegen. Die Implementierung ist dann in 
/targets/controller_xy/hal. Dann gibt es noch /common wo zB das 
plattformunabhängige init() oder analyze() drin ist. In /api sind die 
header für die Funktionen die der User aufrufen darf. Um das dann für 
C++ tauglich nutzbar zu machen (auch mbed code für gpio & co. ist innen 
C) müssen die benutzten Variablen in eine Struktur und die Funktionen 
haben als Argument einen Zeiger auf die Struktur.

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
Johannes, du hast die Lizenz von IRMP im mbed-Repo falsch angegeben, 
nicht Apache, sondern GPL ist richtig.

Das Selbstbau-Board auf github ist nichts für mich. Mir sind da die 
STM32 Nucleo ins Auge gesprungen, die sind recht günstig und sollten für 
einen IR-Empfänger locker reichen. Der NUCLEO-F303K8 beispeilsweise ist 
schön kompakt. Wie sind deine Erfahrungen mit den Dingern?

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Als Lizenz Option kann man da MIT oder Apache oder nichts (?) angeben. 
GPL sehe ich da nicht, habe da keine Erfahrungen. Passt MIT besser?

Ein Nucleo Board habe ich nicht, aber die neuen kleinen im Nano-Format 
gefallen mir auch. Ich habe gerade noch ein China board mit ST32 F103 
C8T6, vielleicht passt der Code. Aber da ist kein STLink dran, das 
kriege ich ad hoc nicht geflasht. Ich habe das in 'meine Hardware' Liste 
gepackt um sehen ob der Code kompiliert wird, das tut er, nur die 
Portnamen müssen angepasst werden.

Edit:
hiernach http://producingoss.com/de/license-choosing.html ist MIT GPL 
kompatibel, ich habe das umgestellt.

von Dirk W. (glotzi)


Bewertung
0 lesenswert
nicht lesenswert
MIT oder Apache sind definiv falsch, ich würde dann wohl lieber nichts 
angeben. Dann gilt wohl das, was im Sourcecode steht. Aber eigentlich 
ist das Frank's Sache, ich wollte nur drauf hinweisen.

Die ST32F103 werden unterstützt:
https://www.mikrocontroller.net/articles/IRMP_auf_STM32_-_ein_USB_IR_Empf%C3%A4nger/Sender/Einschalter_mit_Wakeup-Timer

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, ich denke du hast Recht. Habe jetzt nichts 
angegeben und die Lizenz Info auf der Website ist weg. Damit gelten die 
Angaben im Quelltext, das habe ich ja unverändert übernommen.

Die ST32F103 werden quasi nativ von IRMP unterstützt, aber wenn man den 
Code mit der mbed lib nimmt wird dieser nativ-Code ja nicht genutzt. Das 
ist ja der Charme von mbed, mit den paar Zeilen Änderung läuft das auch 
auf Atmel, Freescale, Nordic, Renesas, ST und was da sonst noch kommen 
mag. Für richtige 'mbed ready' boards braucht man keine Zusatzhardware 
bis auf ein USB Kabel, programmiert wird per Copy auf einen USB Speicher 
der von integrierter mbed Hardware bereitgestellt wird. Bei den ST 
Boards ist das der STLink v2 der eine passende Firmware bekommt. Wenn an 
dem Board ein SWD/JTag Anschluss ist kann man das binärfile aber auch 
mit anderen Tools flashen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Conny G. schrieb:
> Als Nutzer und Fan würde ich mich an der Übersetzung beteiligen.

Vielen Dank für Dein Angebot!

Jojo S. schrieb:
> Ich habe den Receivercode mit einer kurzen Beschreibung jetzt auf mbed
> public gemacht: https://developer.mbed.org/users/JojoS/code/IRMP/

Gut.

> An der Übersetzung kann ich mich auch beteiligen.

Prima! Auch Dir ein Danke!

> Wäre es nicht
> einfacher die Seite zu kopieren und dann zu übersetzen? Das Layout mit
> den vielen Illustrationen wird zweispaltig sicher unübersichtlich und
> alleine das Layout zu ändern ist schon viel Arbeit.

Da habe ich auch lange überlegt. Nachteil bei zwei getrennten Artikeln 
wäre, dass wahrscheinlich nicht jedes Update im Artikel in der jeweils 
anderen Sprache nachgezogen wird. Allerdings ist es auch nicht möglich, 
die Überschriften, die im Inhaltsverzeichnis landen, zweispaltig zu 
machen. Wahrscheinlich ist es doch besser, einen extra Artikel für die 
englischsprachige Version zu erstellen.

Bei der Gelegenheit würde ich gerne IRSND als eigenen Artikel gestalten. 
Das modularisiert das Ganze mehr und die Artikel werden nicht so 
ellenlang.

Was meint Ihr? Ich würde dann heute abend schonmal IRSND von IRMP 
abtrennen und für IRMP und IRSND dann zwei englischsprachige Artikel 
anlegen, indem ich dort erstmal den deutschsprachigen Inhalt 
reinkopiere. Dann kann man den Text besser übersetzen, wenn man auf 
einen Blick den deutschen Text sieht, ohne dauernd in ein zweites 
Fenster wechseln zu müssen.

> Wenn du den Code nochmal reorganisieren möchtest: bei mbed ist aus einem
> Board mittlerweile auch >80 mit vielen verschiedenen Prozessoren
> geworden. Da wurde das über einen HAL (hardware abstraction layer)
> gelöst. Es gibt /hal in dem C-headerfiles als interface für die internen
> Funktionen liegen. Die Implementierung ist dann in
> /targets/controller_xy/hal. Dann gibt es noch /common wo zB das
> plattformunabhängige init() oder analyze() drin ist. In /api sind die
> header für die Funktionen die der User aufrufen darf. Um das dann für
> C++ tauglich nutzbar zu machen (auch mbed code für gpio & co. ist innen
> C) müssen die benutzten Variablen in eine Struktur und die Funktionen
> haben als Argument einen Zeiger auf die Struktur.

Danke für den Tipp. Muss ich mir mal anschauen.

Dirk W. schrieb:
> Das Selbstbau-Board auf github ist nichts für mich. Mir sind da die
> STM32 Nucleo ins Auge gesprungen, die sind recht günstig und sollten für
> einen IR-Empfänger locker reichen. Der NUCLEO-F303K8 beispeilsweise ist
> schön kompakt. Wie sind deine Erfahrungen mit den Dingern?

IRMP läuft bereits seit einem Jahr auf den Nucleo STM32F4xx-Boards. Wird 
auch von mir in folgendem Projekt bereits verwendet: 
WordClock mit WS2812.


Jojo S. schrieb:
> Ich habe gerade noch ein China board mit ST32 F103
> C8T6, vielleicht passt der Code.

Auch da läuft bereits IRMP nativ - ebenso bei obigem Projekt.

Gruß,

Frank

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Was meint Ihr? Ich würde dann heute abend schonmal IRSND von IRMP
> abtrennen und für IRMP und IRSND dann zwei englischsprachige Artikel
> anlegen, indem ich dort erstmal den deutschsprachigen Inhalt
> reinkopiere.

ja, so sollte das einfach gehen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun IRSND von IRMP abgetrennt und jeweils Duplikate für die 
englischsprachige Variante angelegt.

Übersicht:

  IRMP
  IRSND

  IRMP - english
  IRSND - english

Wenn jemand ein bestimmtes Kapitel bearbeiten möchte, sollte er einfach 
dieses Kapitel hier im Thread nennen und dann beginnen. So vermeiden wir 
Doppelarbeit. Nicht, dass sich 2 Leute gleichzeitig auf ein- und 
dasselbe Kapitel stürzen...

Gruß,

Frank

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Is schon spät, aber ein paar Zeilen schaffe ich noch. Es wird nich immer 
Wort für Wort sein, aber mein alter Englischlehrer fand es auch 
wichtiger den Sinn zu treffen.
Bis ich Stop sage...

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
...stop. Bis Download runtergerasselt, darf gerne noch korrigiert 
werden, ich seh nix mehr.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jojo S. schrieb:
> ...stop.

Super, da hast Du ja schon saubere Arbeit geleistet! :-)

> Bis Download runtergerasselt, darf gerne noch korrigiert
> werden, ich seh nix mehr.

Bis auf ein paar vergessene Wörter (z.B. "als" -> "as") ist es perfekt. 
Aber das sind Kleinigkeiten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal

   IRMP - english: IR Protocols in Detail
und
   IRMP - english: Software History

durchgearbeitet. Kleine Änderungen sind noch nötig, aber es wird :-)

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es geht weiter:

Ich habe nun dank Jojos Vorarbeit an der Übersetzung von IRMP den 
englischen Text nun ebenso für IRSND bis "Download" übersetzt. War ja 
fast nur "Abschreibearbeit" :-)

Ebenso habe ich in IRSND die "Software History" nach englisch übersetzt 
und sämtliche Links auf die entsprechenden englisch-sprachigen Titel 
umgeschrieben.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich nichts übersehen habe, ist IRSND - english nun komplett 
übersetzt. :-)

Mag da jemand mal drüberschauen?

Der Großteil steckt allerdings im IRMP-Artikel. Da ist noch jede Menge 
zu tun.

Danke,

Frank

: Bearbeitet durch Moderator
von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nearly done.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jojo S. schrieb:
> Nearly done.

Klasse! Ich habe noch den Rest erledigt (Literature & Acknowledgement). 
Du stehst da natürlich jetzt auch drin ;-)

Vielen vielen Dank, Jojo!

Gruß,

Frank

P.S.
Wäre trotzdem nicht schlecht, wenn da jemand nochmal drüberschauen 
möchte. Ab und zu findet man noch ein deutsches Wort oder einen Satz. 
Manches ist wahrscheinlich auch nicht optimal übersetzt. Aber das sieht 
schon verdammt gut aus! :-)

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich danke auch, die ganze Lib und Tools und dann noch dokumentiert sind 
ja sehr saubere Arbeit. Wenn man das so intensiv liest sieht man das da 
verdammt viel drinsteckt.
Mein China STM32F103 board konnte ich inzwischen auch flashen (mit 
CooCox CoFlash und LPCLink2), aber die mbed Version der lib läuft darauf 
leider nicht. Das ist aber ein Problem der Ticker Implementierung, ich 
habe gesehen das da mehrere Leute Probleme mit haben. Schade, der mbed 
Ansatz ist gut aber in der Praxis stösst man doch öfter auf Probleme. 
Die lib läuft bei mir auf einem LPC4088 (von Embedded Artists) und dem 
LPC1347 Selbstbau. Auf einem LPC1549 der auch einen Cortex-M3 mit 72 MHz 
hat (wie der 1347) läuft es nur ganz müde mit 5 kHz Int, die 
Timergeschichte verbrät viel zu viel Zeit, auch ein Fehler in der mbed 
lib.
Interesse gab es auf der mbed Seite auch noch nicht, aber die Community 
dort ist viel träger als µC.net :-)

Eine weitere Idee: kann IRMP nicht auch Funksignale dekodieren? Der 
Ansatz müsste doch auch passen um z.B. Funkthermometer oder FS20 zu 
verstehen. Hat das hier schonmal jemand in diese Richtung probiert?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jojo S. schrieb:
> Ich danke auch, die ganze Lib und Tools und dann noch dokumentiert sind
> ja sehr saubere Arbeit. Wenn man das so intensiv liest sieht man das da
> verdammt viel drinsteckt.

Das stimmt allerdings. Macht aber auch Spaß :-)

> Mein China STM32F103 board konnte ich inzwischen auch flashen (mit
> CooCox CoFlash und LPCLink2), aber die mbed Version der lib läuft darauf
> leider nicht.

Immerhin läuft IRMP nativ auf dem kleinen Ding. Ist ja schon mal was.

> Schade, der mbed
> Ansatz ist gut aber in der Praxis stösst man doch öfter auf Probleme.

Das ist das Problem bei der Abstraktion: Man muss immer Kompromisse 
eingehen. Das kann dann auch zu Problemen führen.

> Die lib läuft bei mir auf einem LPC4088 (von Embedded Artists) und dem
> LPC1347 Selbstbau.

Prima. Ich plane, die Infos zu der tauglichen Hardware im Artikel noch 
generell etwas auszubauen.

> Auf einem LPC1549 der auch einen Cortex-M3 mit 72 MHz
> hat (wie der 1347) läuft es nur ganz müde mit 5 kHz Int, die
> Timergeschichte verbrät viel zu viel Zeit, auch ein Fehler in der mbed
> lib.

Wahrscheinlich.

> Interesse gab es auf der mbed Seite auch noch nicht, aber die Community
> dort ist viel träger als µC.net :-)

Nicht so ungeduldig. Gut Ding will Weile haben :-)

> Eine weitere Idee: kann IRMP nicht auch Funksignale dekodieren?

Ja, erste Versuche habe ich bereits mit einer 
Aldi-Funksteckdosen-Fernbedienung gemacht. Da kommt garantiert etwas in 
der nächsten Zeit :-)

Gruß und nochmals Dank,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
IRMP und IRSND 3.0.0 sind online.

Änderungen IRMP:

  - Korrektur der Portierung auf ESP8266
  - Portierung auf MBED-Systeme hinzugefügt
  - Mehrere Beispiel-Main-Source-Dateien (plattformabhängig) hinzugefügt

Als Beispiel-Anwendungen habe ich hinzugefügt:

    irmp-main-avr.c           - AVR
    irmp-main-avr-uart.c      - AVR mit UART-Ausgabe
    irmp-main-pic-xc8.c       - PIC (XC8 compiler)
    irmp-main-stm32.c         - STM32
    irmp-main-stellaris-arm.c - TI Stellaris LM4F120 Launchpad
    irmp-main-esp8266.c       - ESP8266
    irmp-main-mbed.cpp        - MBED

Änderungen IRSND:

  - Beispiel-Main-Datei irsndmain.c in irsnd-main-avr.c umbenannt

Die Artikel IRMP und IRMP - english sind beide auf dem neuesten 
Stand.

Viel Spaß mit IRMP!

von Micha H. (Firma: Dg3brb) (kanadakruemel)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
erstmal vielen Dank für die tolle Arbeit. Läuft seit Ewigkeiten in 
meinem VDR als Einschalter und LIRC Quelle.
Zu der Idee mit der Funkanbindung:
Schau doch mal beim SIGNALduino Projekt vorbei. Die machen sowas 
ähnliches schon. Vielleicht kannst Du Dir da noch ein paar Ideen holen.
Siehe http://www.fhemwiki.de/wiki/SIGNALduino
und https://github.com/RFD-FHEM/SIGNALduino.
Ich benutze den SIGNALduino für Intertechno Steckdosen schalten und 
Wettersensoren empfangen.

Gruß,
Micha

von Jojo S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das ist das Problem bei der Abstraktion: Man muss immer Kompromisse
> eingehen. Das kann dann auch zu Problemen führen.

ja, ist richtig. Aber der eine gleich schnelle schafft die ISR ja auch 
in 3 µs, der 1549 verbrät >30µs. Gut ist das die Quellen der mbed lib 
auch public sind. Ich sollte mal was anderes machen, aber es juckt schon 
wieder in den Fingern...

> Ja, erste Versuche habe ich bereits mit einer
> Aldi-Funksteckdosen-Fernbedienung gemacht. Da kommt garantiert etwas in
> der nächsten Zeit :-)

Klasse. Etwas schwieriger ist sicher das mehr Informationen in den 
Telegrammen steckt als nur Typ/Adresse/Kommando.

> Nicht so ungeduldig. Gut Ding will Weile haben :-)
ja ist richtig. Aber IR Fernbedienungen sind ja auch schon out, heute 
läuft alles übers Smartphone :-)
Und die mbed developer Seite wird gerade wieder zugespamt, ein übles 
Problem da das öfter zu sehen ist.

von Reinhard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann mir bitte jemand bestätigen, ob die IR-Fernbedienung MERLIN, die es 
bei Pollin für einen Euro gibt mit einem 38kHz oder 56kHz TSOP 
funktioniert? Leider habe ich widersprüchliche Angaben dazu gefunden. 
Mit 38kHz bekomme ich meine Fernbedienung leider nicht zum Laufen, nicht 
eine Taste wird erkannt. Aktiviert habe ich nur das Merlin Protokoll bei 
20kHz Interrupts.

Danke und viele Grüße,

Reinhard

von Reinhard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit dem 56kHz TSOP 31256 läuft die Merlin Fernbedienung einwandfrei.
Ich habe nur das Merlin Protokoll aktiviert und 20kHz Interrupts 
konfiguriert.

Viele Grüße!!!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Reinhard schrieb:
> Mit dem 56kHz TSOP 31256 läuft die Merlin Fernbedienung einwandfrei.

Sorry, war letzte Woche unterwegs, sonst hätte ich Dir eher antworten 
können.

Im Artikel sind auch die 56kHz eingetragen, siehe:

  https://www.mikrocontroller.net/articles/IRMP#MERLIN

P.S.

Ich sehe gerade: Das wurde erst kürzlich (wahrscheinlich von Dir?) im 
Artikel korrigiert. Ich habe die Änderung im englischsprachigen Artikel 
gerade nachgezogen.

: Bearbeitet durch Moderator
von Daniel W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade IRMP auf einem ATtiny85 zum Laufen zu bekommen aber 
komme nicht so ganz weiter.

Ich nutze das AtmelStudio 7.0
Hat das schon mal einer hinbekommen? Ich habe hier Fehler beim linken.

Der lib Ordner und die lib ist angegeben. Aber die Parameter für den 
avr-gcc sehen auch so komisch aus die das Studio zusammenbaut, sowas wie 
-lirmp.h ich meine da fehlt doch ein Leerzeichen. Bearbeite ich das 
Makefile manuell und nehme das kommen wieder andere Fehler.

Vielleicht ist ja jemand dabei, der das schon am rennen hat.

Gruß
Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Hat das schon mal einer hinbekommen?

Auf einem ATTiny85? Ja, ich. Auch mit ATTiny45. Aber bisher nicht mit 
AtmelStudio 7 probiert.

> Ich habe hier Fehler beim linken.

Welche Fehler? Man kann die kopieren und hier einfügen. ;-)

> Vielleicht ist ja jemand dabei, der das schon am rennen hat.

Zeig einfach mal die Fehlermeldungen.

Hast Du denn irmp.c zum Projekt hinzugefügt?

: Bearbeitet durch Moderator
von Daniel W. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank, danke für deine Unterstützung.

Die .c habe ich nicht angegeben bei Studio 7, ich habe nur die irmp.h 
bei den libraries angegeben.

Fehlerausgabe von Studio 7 ist im Anhang.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> Die .c habe ich nicht angegeben bei Studio 7,

IRMP ist keine vorkompilierte Library, Du musst daher irmp.c als 
Quellcode zum Projekt hinzufügen.

> ich habe nur die irmp.h
> bei den libraries angegeben.

irmp.h ist eine sog. Header-Datei und keine Library. Nimm das wieder 
raus.

Dann sollte es gehen.

von Daniel W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja stimmt, und der andere Fehler mit der avr25 spec habe ich auch 
behoben. Der hat nach "specs-avr25" gesucht aber es lag nur eine 
"specs-attiny85" im Ordner, ich hab die einfach umkopiert.

Gut Danke, dann schaue ich mal ob ich weiter kommt.

Gruß
Daniel

von Reinhard (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

ja, ich habe den Artikel bearbeitet und die 38kHz durch 56kHz ersetzt.

Viele Grüße,

Reinhard

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Reinhard,

Reinhard schrieb:
> ja, ich habe den Artikel bearbeitet und die 38kHz durch 56kHz ersetzt.

Danke für die Info, dann hat sich das ja nun geklärt :-)

von Daniel W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nabend,

ich hab da noch mal eine Frage zum ATtiny85 und dem Interrupt. Ich hab 
alles so wie im Beispiel, F_CPU 8000000UL und F_INTERRUPTS auf 15000 pro 
Sekunde. Allerdings sind das bei mir ca 15000 pro 11 Sekunden. Also 
irgend etwas läuft da zu langsam.

Das Fusebit steht bei mir auf 8 MHz internal 6CK_15CK_64MS, sollte doch 
also passen?!?

Bemerkt habe ich das, da ich ein Taster abfrage ob dieser unter 1s oder 
länger gedrückt wurde und das mache ich über die ISR.

Was kann ich denn noch vergessen haben? Ich muss gestehen ich bin ein 
bissel raus aus der µC Programmierung ;-)

/Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:
> ich hab da noch mal eine Frage zum ATtiny85 und dem Interrupt. Ich hab
> alles so wie im Beispiel, F_CPU 8000000UL und F_INTERRUPTS auf 15000 pro
> Sekunde. Allerdings sind das bei mir ca 15000 pro 11 Sekunden. Also
> irgend etwas läuft da zu langsam.

Offenbar ist die CKDIV8-Fuse bei Dir noch gesetzt. Dann wird der Takt 
intern durch 8 geteilt und der µC läuft nur mit 1MHz.

von Gottfried P. (gottfried_p)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich möchte einen kleinen Beitrag zu diesem tollen Projekt leisten.
Im Anhang die Erweiterung um ein zusätzliches Protokoll, Mitsubishi
Heavy Airconditioner, sowohl IRMP als auch IRSND.
Bitte Datei Info.txt beachten!

GP

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Gottfried,

Gottfried P. schrieb:

> Im Anhang die Erweiterung um ein zusätzliches Protokoll, Mitsubishi
> Heavy Airconditioner, sowohl IRMP als auch IRSND.

Erstmal vielen Dank!

Ich habe Deine Änderungen in den aktuellen Source eingearbeitet. Dabei 
habe ich die uneinheitliche Schreibweise xxxx_MITSUBISHI_xxxx und 
xxxx_MITSU_HEAVY_xxxx vereinheitlicht zu xxxx_MITSU_HEAVY_xxxx.

> Bitte Datei Info.txt beachten!

Danke, habe ich gelesen. Du schreibst da etwas zu Timingverfälschungen, 
die im Empfänger(?) entstehen. Kann es sein, dass Du einen TSOP benutzt 
hast, der nicht ganz zur tatsächlichen Modulationsfrequenz passt?

Außerdem habe ich gesehen, dass Du einige Timing-Parameter von anderen 
Protokollen geändert hast. Das kam mir ziemlich spanisch vor, besonders, 
weil bestimmte Protokolle wie NEC sehr gut im Internet dokumentiert 
sind.

Benutzt Du vielleicht keinen Quarz am Sende-AVR? Während IRMP da 
ziemlich tolerant ist und keinen Quarz braucht, ist dieser für IRSND 
schon sinnvoll, da einige Geräte bzgl. Timing ziemlich penibel sind.

Deine Änderungen kommen dann ins nächste Release. Deine Erläuterungen 
zum MITSU_HEAVY-Protokoll werde ich dann auch in den Artikel schieben.

Vielen Dank,

Frank

: Bearbeitet durch Moderator
von Daniel W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Offenbar ist die CKDIV8-Fuse bei Dir noch gesetzt. Dann wird der Takt
> intern durch 8 geteilt und der µC läuft nur mit 1MHz.

Hallo Frank,

das hatte ich raus genommen. Aber wie ich festgestellt habe war der µC 
echt defekt und scheint genau das nicht gefressen zu haben. Ich hab den 
Haken entfernt, der verify sagte alles ok, beim erneuten auslesen war er 
Haken wieder drin! Ich habe einen anderen µC genommen und jetzt 
funktioniert es! Gibt von AVR auch schon Kopien auf dem Markt?!?

Ich habe mal noch eine andere Frage. Mein Projekt (IR USB Switch) 
funktioniert mittlerweile sehr gut. Also ein kleiner USB Zwischenstecker 
wo man per IR den Strom an und ausstellen kann. Ist Ideal für sowas wie 
die FireTV Sticks etc.

Beim anlernen der Befehle ist es so, dass ich erst den "An" Befehl 
anlerne, diesen dann abspeicher im eeprom und der nächste gelesene Wert 
ist dann das "Aus" Kommando. Allerdings scheint die Fernbedienung das 
Signal so oft zu senden, dass das falsche Signal im Puffer ist. Wie kann 
ich denn nach dem Lesen des ersten Codes das irmp_get_data so 
"zurücksetzen" das alles aus der Pipe ist?

Also um es mal einfach zu sagen, der Codeabschnitt ist mein Problem:
while (1)
{
  if (irmp_get_data  &irmp_data))  
  {
    if (mode == 2)
    {
      // Programmierung/Speicherung Taste AN
      commandArray[0] = irmp_data.address;
      commandArray[1] = irmp_data.command;
      mode = 3;
    }
    else if (mode == 3)
    {
      // Programmierung/Speicherung Taste AUS
      commandArray[2] = irmp_data.address;
      commandArray[3] = irmp_data.command;
      
      // Daten im EEPROM speichern
      eeprom_write_block (commandArray, eeArray, sizeof(commandArray));
      mode = 0;
    }
    else if (mode == 0 || mode == 1)
    {
      // Wenn Code bekannt, schalte USB an oder aus
      if (irmp_data.address == commandArray[0] && irmp_data.command == commandArray[1])
      mode = 1;
      if (irmp_data.address == commandArray[2] && irmp_data.command == commandArray[3])
      mode = 0;          
  }  
}
Gruß
Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Daniel W. schrieb:

> Ich habe einen anderen µC genommen und jetzt funktioniert es!

Freut mich.

> Gibt von AVR auch schon Kopien auf dem Markt?!?

Keine Ahnung, wo hast Du den denn her?

> Allerdings scheint die Fernbedienung das
> Signal so oft zu senden, dass das falsche Signal im Puffer ist. Wie kann
> ich denn nach dem Lesen des ersten Codes das irmp_get_data so
> "zurücksetzen" das alles aus der Pipe ist?

Ja, das Problem kenne ich. Die Pipe-Länge beim IRMP ist maximal 1. Um 
die Pipe zu leeren, reicht ein Einfügen von

   irmp_get_data (&irmp_data);

vor dem eigentlichen irmp_get_data() Aufruf, welcher ausgewertet werden 
soll. Damit schmeisst Du einen vorher zuviel empfangenen Frame weg. Bei 
Deiner Logik ist das nicht ganz so einfach. Deshalb habe ich dort den 
Flush dann nach dem Speichern im EEPROM eingebaut, s.u. Müsste so 
klappen.

Außerdem solltest Du nur Frames ohne Repetition-Flag auswerten - siehe 
erstes if. Genau damit ignorierst Du dann Frames, wenn Du eine Taste zu 
lang drückst.

Also:
while (1)
{
  if (irmp_get_data  (&irmp_data) &&
      (irmp_data.flags & IRMP_FLAG_REPETITION) == 0)  // only if no repetition
  {
    if (mode == 2)
    {
      // Programmierung/Speicherung Taste AN
      commandArray[0] = irmp_data.address;
      commandArray[1] = irmp_data.command;
      mode = 3;
      irmp_get_data  (&irmp_data);   // flush input
    }
    else if (mode == 3)
    {
      // Programmierung/Speicherung Taste AUS
      commandArray[2] = irmp_data.address;
      commandArray[3] = irmp_data.command;

      // Daten im EEPROM speichern
      eeprom_write_block (commandArray, eeArray, sizeof(commandArray));
      mode = 0;
      irmp_get_data  (&irmp_data);   // flush input
    }
    else if (mode == 0 || mode == 1)
    {
      // Wenn Code bekannt, schalte USB an oder aus
      if (irmp_data.address == commandArray[0] && irmp_data.command == commandArray[1])
      {
          mode = 1;
      }
      else if (irmp_data.address == commandArray[2] && irmp_data.command == commandArray[3])
      {
          mode = 0;
      }
  }
}

Beachte auch das else unten. Spart etwas CPU-Zeit.

Gruß,

Frank

: Bearbeitet durch Moderator
von Daniel W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Super danke, läuft sehr gut jetzt.

Dann kann ich ja mal eine Platine Layouten und ein passendes Gehäuse 
suchen ;-)

Vielen Dank für deine Hilfe!

Daniel

von Gottfried P. (gottfried_p)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

> Du schreibst da etwas zu Timingverfälschungen,
> die im Empfänger(?) entstehen. Kann es sein, dass Du einen TSOP benutzt
> hast, der nicht ganz zur tatsächlichen Modulationsfrequenz passt?

> Außerdem habe ich gesehen, dass Du einige Timing-Parameter von anderen
> Protokollen geändert hast. Das kam mir ziemlich spanisch vor, besonders,
> weil bestimmte Protokolle wie NEC sehr gut im Internet dokumentiert
> sind.
> Benutzt Du vielleicht keinen Quarz am Sende-AVR?

Also ich betreibe das auf Basis eines Arduino Uno Klones. Der hat aber 
sehr wohl einen Quarz. Und wie ich im Begleittext geschrieben habe, RC6 
hat der VU+ einfach nicht verstanden mit dem vorgegebenen Timing.
Bzgl. TSOP: ich hab da nicht so genau geschaut. Einmal verwende ich das 
"Verlängerungskabel" das bei VU dabei war (IR-Sensor und IR-Led), in der 
Anwendung einen aus einem Beamer ausgebauten Empfänger. Könnte schon 
sein, dass da die empfangenen Bitzeiten ein bisserl verschieden sind. 
Die Timing-Parameter der für mich interessanten Protokolle habe ich so 
lange geändert, bis kein merklicher Unterschied zwischen Original-FB und 
IRSND am Logic-Analyser zu sehen war. Die Verfälschungen durch den TSOP 
fallen da weg.
Ansonsten könnte natürlich auch sein, dass die vermessenen 
Fernbedienungen ziemlich daneben sind. Besonders bei meiner NEC die zu 
einem Ledstrip gehört lege ich mich da gar nicht fest....

Dank und Anerkennung für das IRMP- und Deine anderen Projekte, 
namentlich Fli4l und Eisfair.

lg Gottfried

von Morpheus1997 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich habe am Wochenende auch angefangen, mich mit dem Thema 
Infrarot-Dekodierung auseinander zu setzen. Ich habe hierfür eine 
Platine mit einem Atmega32, der mit einem 12 MHz Quarz läuft, zusammen 
gelötet, und wollte nun mit deinem Programm mittels UART die Codes von 
verschiedenen Fernbedienungen am PC über HTerm auslesen.

Ich benutze den IRMP Code der Version 3.0.0. Hierbei benutze ich als 
Main-Programm den Code aus "irmp-main-avr-uart". Ich arbeite mit dem AVR 
Studio 5.1 und habe aus den Dateien irmp.c, irmp-main-avr-uart.c, 
irmpprotocols.h, irmpsystem.h, irmp.h und irmpconfig.h ein Projekt 
erstellt. Die Einstellungen sollten soweit alle richtig sein, den 
Mikrocontroller habe ich über das AVR Studio eingestellt (in dem 
makefile ist es somit auch richtig angegeben), den Code habe ich an den 
verwendeten Quarz angepasst, die Fuses auch soweit eingestellt und bei 
der Konfigurationsdatei den verwendeten Pin des angeschlossenen 
TSOP-31238 Infrarot-Empfängers angepasst.

So nun versuche ich wie gesagt, über eine serielle Schnittstelle eine 
Verbindung zum PC aufzubauen. In HTerm antwortet der Mikrocontroller 
jedoch weder auf gesendete Befehle, noch sendet er die dekodierten 
Protokolldaten über die serielle Schnittstelle.

Ich konnte ausschließen, dass es ein Hardware-Fehler ist, denn wenn ich 
die Endlossschleife leicht anpasse, in dem der Mikrocontroller 
beispielsweise jede Sekunde den Buchstaben 'A' sendet, so wird dies auch 
bei HTerm angezeigt. Kommentier ich das jedoch wieder aus und füge 
wieder wie gehabt
for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
            uart_puts_P (PSTR("protocol: 0x"));
            itoh (buf, 2, irmp_data.protocol);
            uart_puts (buf);

#if IRMP_PROTOCOL_NAMES == 1
            uart_puts_P (PSTR("   "));
            uart_puts_P (pgm_read_word (&(irmp_protocol_names[irmp_data.protocol])));
#endif

            uart_puts_P (PSTR("   address: 0x"));
            itoh (buf, 4, irmp_data.address);
            uart_puts (buf);

            uart_puts_P (PSTR("   command: 0x"));
            itoh (buf, 4, irmp_data.command);
            uart_puts (buf);

            uart_puts_P (PSTR("   flags: 0x"));
            itoh (buf, 2, irmp_data.flags);
            uart_puts (buf);

            uart_puts_P (PSTR("\r\n"));
        }
    }

 in die Endlosschleife, so kommt erneut nichts bei HTerm an.

Zusammengefasst sollte als die Hardware-Uart-Anbindung stimmen.
Wahrscheinlich habe ich irgend eine Kleinigkeit übersehen, die man am 
Code noch an den Mikrocontroller anpassen muss, sodass die 
Uart-Kommunikation erfolgreich verläuft. Ich kann jedoch einfach nicht 
herausfinden, woran es genau scheitert.

Vielleicht kannst du mir hier ja helfen.

LG Marcel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Morpheus1997 schrieb:

> So nun versuche ich wie gesagt, über eine serielle Schnittstelle eine
> Verbindung zum PC aufzubauen. In HTerm antwortet der Mikrocontroller
> jedoch weder auf gesendete Befehle, noch sendet er die dekodierten
> Protokolldaten über die serielle Schnittstelle.

Wahrscheinlich ist im HTERM Hardware-Handshake eingestellt. Dann klappt 
das nicht, weil der UART vom AVR keine Hardware-Handshake-Leitungen hat.

Abhilfe: Im HTERM Handshake abstellen - falls möglich, oder PuTTY 
verwenden.

: Bearbeitet durch Moderator
von Morpheus1997 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wahrscheinlich ist im HTERM Hardware-Handshake eingestellt. Dann klappt
> das nicht, weil der UART vom AVR keine Hardware-Handshake-Leitungen hat.
>
> Abhilfe: Im HTERM Handshake abstellen - falls möglich, oder PuTTY
> verwenden.

Hm, ich habs heute ausprobiert, doch leider schafft auch PuTTY keine 
Abhilfe. Die üblichen "Hello-World"-Uart-Programme funktionieren jedoch 
auch hier.

Muss man denn - außer die von mir genannten Punkte - nichts in dem 
Programm ändern?

von Stefan Z. (stefan_z)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde IRMP gerne auf einem NodeMCU v3 mit Arduino IDE nutzen.
Jetzt ist IRMP neuerdings ja schon ESP8266 tauglich - also sollte darauf 
nativ compilen / laufen wenn ich es richtig verstehe.
Wie muss ich die Lib anpassen, dass er mein Board erkennt?
Im Prinzip ist es nur ein ESP8266 auf einem Trägerboard plus 
USB->Seriell Wandler.
Achja und es ist ein ESP-12E Modul - also die neuere Revision.

Wie geht man da vor? (ich bin nicht unbedingt der Hellste was Libraries 
schreiben angeht)

von Klaus R. (klaus2)


Bewertung
0 lesenswert
nicht lesenswert
...kennt jmd die B&O commads für ältere Systeme, ich will mit IRSND eine 
kleine FB für ein beomaster 5500 bauen. Bräuchte Vol +/-, Radio, Stdby, 
Aux, Loudness...

Danke, Klaus.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> ...kennt jmd die B&O commads für ältere Systeme, ich will mit IRSND eine
> kleine FB für ein beomaster 5500 bauen. Bräuchte Vol +/-, Radio, Stdby,
> Aux, Loudness...

Das besondere bei B&O ist die hohe Trägerfrequenz von 455kHz - im 
Gegensatz zu den sonst üblichen 32-40kHz.
Schau mal auf der IRMP Hauptseite:
https://www.mikrocontroller.net/articles/IRMP

Das Dokument unten bei den Anmerkungen beschreibt auch recht genau das 
Protokoll für Beosystem 5500.
http://www.mikrocontroller.net/attachment/33137/datalink.pdf

von Klaus R. (klaus2)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

Danke für die Info. Das mit den 455kHz war mir klar, dachte cih müsste 
dann zB nur den Play-Cmd kennen. Aber da wird ja noch ein etwas 
komplexerer Header mit übertragen, den muss ich natürlich auch noch 
kennen (und mit IRSND übertragen können?!), in meinem Falle möchte ich 
eine MCP5500 nachstellen. Format also local, to Radio, from 
MCP5500...ich ahne, du hast auch einen beomaster? :)

EDIT: Ah, da kann ich das ja fest einstellen: irmp_data.address = 
0x00FF; // set address to 0x00FF - Fehlen mir aber noch die CMDs, außer 
ich muss die selbst mit IRMP auslesen :)

Klaus.

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> ich ahne, du hast auch einen beomaster? :)

So ist es - meiner ist aber nochmal etwas älter und hat überhaupt keine 
Fernbedienung:
http://beocentral.com/beomaster3000-1970s
Ich habe ihn aber in Schleiflack Weiss :-P

Klaus R. schrieb:
> Fehlen mir aber noch die CMDs, außer
> ich muss die selbst mit IRMP auslesen :)

Das würde ich so machen - habe ich bei unbekannten Fernbedienungen auch 
so gemacht, bei mir habe ich so viele Protokolle wie möglich in IRMP 
eingebunden und dann einfach probiert, welches Protokoll die FB nun 
sendet und welche Codes was sind. Dazu geht das serielle Beispiel, das 
bei IRMp bei ist.
Das Problem bei dir ist ein für 455kHz brauchbarer Empfänger, dazu habe 
ich im Moment keine Idee ausser Photodiode und ein ZF Verstärker aus 
einem alten Mittelwellen Radio.

von Klaus R. (klaus2)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
TSOP7000 geht zB, ist aber etwas "pricy" weshalb ich ja extra 
nachfrage...bei beocentral habe ich leider auch nix konkretes gefunden. 
Vll muss der Leidensdruck erst wachsen, indem ich die (gefühlten) 2,5kg 
MCP5500 jedes Mal zwischen Wohnzimmer und Essbereich hin- und 
herschleppen muss :)
Im Zweifelsfall zapfe ich aber den Receiver im beo an, da kommt man gut 
dran.

EDIT: Der beo3000 ist auch ein wahrlich schönes Gerät!

Gruß, Klaus.

: Bearbeitet durch User
von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum!

Bis jetzt habe ich irmp in einigen Umgebungen erfolgreich auf AVR 
eingesetzt.
Jetzt jabe ich mir diese VolmetallFernbedienung angeschafft um etwas in 
der Hand zu haben

http://www.wsdistributing.com/web/wp-content/gallery/vincent-audio/sa-31mk-remote.jpg

Leider scheint das Protokoll keinem der implementierten Protokolle zu 
entsprechen.
Ich verwende einen TSOP4836 und habe nach und nach Protokoll für 
Protokoll aktiviert.

Habt Ihr nähere Informationen zu den Vincent Fernbedienungen bzw. eine 
Lösung für mich ?

Danke und Gruß
Daniel

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Anmerkung:

Google spuckt nur das hier raus

http://www.remotecentral.com/cgi-bin/mboard/rc-prontong/thread.cgi?9405

Ich erkenne den weiteren Kontext aber nicht aus dem was die Jungs da 
schreiben...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Jetzt jabe ich mir diese VolmetallFernbedienung angeschafft um etwas in
> der Hand zu haben
>
> 
http://www.wsdistributing.com/web/wp-content/gallery/vincent-audio/sa-31mk-remote.jpg
>
> Leider scheint das Protokoll keinem der implementierten Protokolle zu
> entsprechen.

Du kannst mit IRMP die gesandten Daten aufzeichnen und den Scan hier 
ablegen. Dann schaue ich mir das an.

Wie das geht, steht hier:

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

von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Super! Danke schon mal!

Mit welchem AVR passt der Source Code ohne Anpassungen direkt?

Dann werde ich einen entsprechenden Versuchsaufbau auf die Beine 
stellen.

Daniel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Mit welchem AVR passt der Source Code ohne Anpassungen direkt?

Für alle, die im Artikel angegeben sind. Du musst nur in irmpconfig.h 
den Pin einstellen, an dem der TSOP hängt.

von Rainer G. (gera)


Bewertung
0 lesenswert
nicht lesenswert
Die Artikel zu IRMP und IRSND sind nur noch ein paar Zeilen lang.
Da scheint was verloren gegangen zu sein.
https://www.mikrocontroller.net/articles/IRMP

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Rainer G. schrieb:
> Die Artikel zu IRMP und IRSND sind nur noch ein paar Zeilen lang.
> Da scheint was verloren gegangen zu sein.

Ja, da hat sich ein Troll ausgetobt. Wurde mittlerweile wieder 
korrigiert. Da dies in der Vergangenheit gehäuft auftrat, bekomme ich 
mittlerweile eine Benachrichtigung, wenn sich IRMP oder IRSND 
ändert. Dann können solche "Aktionen" schnell wieder in Ordnung gebracht 
werden.

von Rainer G. (gera)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte dir mal ne Mail geschickt.
Ist die angekommen ?

Der C18 geht nicht mit der Version 3.00.
Folgendes ist zu ändern:

Die fast Typen müssen deklariert werden.

irmpsystem.h
#if defined(PIC_CCS) || defined(PIC_C18) || defined(ARM_STM32) || 
defined(STELLARIS_ARM_CORTEX_M4)
typedef unsigned char                   uint8_t;
typedef unsigned short                  uint16_t;
#  define uint_fast8_t uint8_t
#  define uint_fast16_t uint16_t
#endif


((_packed_)) kennt der C18 Compiler nicht.

#if defined(PIC_C18)
typedef struct _attribute_
{
    uint8_t      protocol;      // protocol, e.g. NEC_PROTOCOL
    uint16_t     address;       // address
    uint16_t     command;       // command
    uint8_t      flags;         // flags, e.g. repetition
} IRMP_DATA;
#else
typedef struct _attribute_  ((_packed_))
{
    uint8_t      protocol;     // protocol, e.g. NEC_PROTOCOL
    uint16_t     address;      // address
    uint16_t     command;      // command
    uint8_t      flags;        // flags, e.g. repetition
} IRMP_DATA;
#endif


Den IF Teil mit digitalPinHasPWM mag der Compiler überhaupt nicht.
Musste ich kommentieren. Andere Lösung hab ich nicht gefunden.

/*
#elif defined (TEENSY_ARM_CORTEX_M4)  // Teensy3
#  if !digitalPinHasPWM(IRSND_PIN)
#    error need pin with PWM output.
#  endif
*/

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Rainer,

Rainer G. schrieb:
> Ich hatte dir mal ne Mail geschickt.
> Ist die angekommen ?

Ja, die ist angekommen :-)

Ich war leider in den letzten Wochen mit ganz anderen Dingen 
beschäftigt, so dass ich mich (noch) nicht drum kümmern konnte. Ich 
werde die Änderungen nun zeitnah einbauen und mich nochmal bei Dir per 
Mail melden.

Danke,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Die Version 3.0.2 von IRMP und IRSND ist online. Zwei 
Änderungen:

  - Neues Protokoll Mitsubishi Heavy (Klimaanlage)
  - Anpassungen an Compiler PIC C18

Dank an Rainer G. (gera) für die Hinweise für den C18-Compiler.

@Rainer:

Ich habe Deine Änderungen noch etwas anders eingepflegt, ich hoffe, das 
ist in Deinem Sinne. Für das zuletzt aufgeführte Problem mit dem Makro 
digitalPinHasPWM(), das beim C18 überhaupt nicht zum Tragen kommt, habe 
ich leider mangels C18-Compiler auch keine bessere Lösung. Ich habe 
daher den Block - wie von Dir empfohlen - komplett auskommentiert. Da 
geht zwar etwas Komfort für Teensy-Anwender verloren, aber ich denke, 
das ist zu verschmerzen.

von SE (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe da ein kleines Verständnisproblem mit IRSND und einem AtMega88.

Für ein konkretes Prohekt wollte ich IRSND einsetzen. Doch der 
eingestellte PIN bleibt LOW. Der Timer-Interrupt von IRSND wird aber 
aufgerufen.

Den Timer habe ich wie folgt eingestellt:
// Timer for IRSND
void timer1_init (void)
{
  OCR1A   = (F_CPU / F_INTERRUPTS) - 1;    // compare value: 1/15000 of CPU frequency
  TCCR1B  = (1 << WGM12) | (1 << CS10);    // switch CTC Mode on, set prescaler to 1
  TIMSK1  = (1 << OCIE1A);          // OCIE1A: Interrupt by timer compare
}

// timer 1 compare handler, called every 1/10000 sec
ISR(TIMER1_COMPA_vect)                            // Timer1 output compare A interrupt service routine, called every 1/15000 sec
{
  irsnd_ISR();                            // call irsnd ISR
}

in der irsndconfig.h steht:
#elif defined(ATMEL_AVR)
#  define IRSND_OCx                             IRSND_OC2B              // use OC2B

Was mich jetzt verwirrt ist, das der OC2B zum Timer 2 gehört und OC1x 
vom Timer 1 ist nicht in der IRSND vorgesehen. In einem Beitrag in 
diesem Thread stand, das IRSND Timer 1 aber benötigt.

Kann mit jemand auf die Sprünge helfen, wo jetzt mein Denkfehler ist?

von SE (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SE schrieb:
> Kann mit jemand auf die Sprünge helfen, wo jetzt mein Denkfehler ist?

Bin nach langer Suche auf den Fehler gekommen.

Ich hatte meine Fernbedienung vom Kenwood AV-Receiver gescannt.
IRMP zeigte mir Protokoll 2 an.
Also habe ich für IRSND das Protokoll Kenwood eingestellt und Protocol 2 
gesendet.
Der Fehler: Protocol 2 ist NEC. Also NEC bei IRSND reingenommen und 
schon wurde gesendet. ;-)

Vg

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
SE schrieb:
> Bin nach langer Suche auf den Fehler gekommen.

Danke für die Rückmeldung. Als ich eben Deine Fehlerbeschreibung gelesen 
habe, konnte ich mir auch nicht vorstellen, wo da der Fehler wäre.

> Der Fehler: Protocol 2 ist NEC. Also NEC bei IRSND reingenommen und
> schon wurde gesendet. ;-)

NEC ist eigentlich standardmäßig in irsndconfig.h eingeschaltet. Hattest 
Du das vorher versehentlich abgeschaltet?

von SE (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Der Fehler: Protocol 2 ist NEC. Also NEC bei IRSND reingenommen und
>> schon wurde gesendet. ;-)
>
> NEC ist eigentlich standardmäßig in irsndconfig.h eingeschaltet. Hattest
> Du das vorher versehentlich abgeschaltet?

Ja, aber nicht versehentlich. Hatte aus Platzspargründen nur Sony und 
Kasayco drin und alles andere abgeschaltet.

Aber noch kurz zum OC2x.
Wird beim IRSND nur der I/O-PIN hinter dem OC2x genutzt?
Denn zu dem Timer 1 gehört doch der OC1x.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
SE schrieb:
> Aber noch kurz zum OC2x.
> Wird beim IRSND nur der I/O-PIN hinter dem OC2x genutzt?
> Denn zu dem Timer 1 gehört doch der OC1x.

IRSND benötigt 2 Timer. Dabei wird Timer1 genutzt, um das Bitmuster 
auszusenden. Da wird die ISR standardmäßig 15000 mal pro Sekunde 
aufgerufen.

Aber das reicht noch nicht, denn das Signal muss zusätzlich noch 
moduliert werden, üblicherweise mit 32kHz bis 42kHz - je nach Protokoll. 
Dafür wird dann eine PWM mit der nötigen Modulationsfrequenz benötigt. 
Da Timer1 ja schon belegt ist, können dafür PWM-Pins für Timer0 oder 
Timer2 genutzt werden.

Daher findest Du in irsndconfig.h als Kommentar direkt über der Auswahl 
des I/O-Pins:
IRSND_OC2  = OC2  on ATmegas         supporting OC2,  e.g. ATmega8
IRSND_OC2A = OC2A on ATmegas         supporting OC2A, e.g. ATmega88
IRSND_OC2B = OC2B on ATmegas         supporting OC2B, e.g. ATmega88
IRSND_OC0  = OC0  on ATmegas         supporting OC0,  e.g. ATmega162
IRSND_OC0A = OC0A on ATmegas/ATtinys supporting OC0A, e.g. ATtiny84, ATtiny85, ATtiny87/167
IRSND_OC0B = OC0B on ATmegas/ATtinys supporting OC0B, e.g. ATtiny84, ATtiny85

Wie Du siehst, stehen dafür OC0x und OC2x zur Verfügung.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version 3.0.3 von IRMP ist online.

Einzige Änderung:

 - Neues Protokoll: VINCENT

Damit ist die Anzahl der unterstützten Protokolle nun auf die schöne 
runde Zahl von 50 gewachsen. :-)

: Bearbeitet durch Moderator
von SE (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> SE schrieb:
>> Aber noch kurz zum OC2x.
>> Wird beim IRSND nur der I/O-PIN hinter dem OC2x genutzt?
>> Denn zu dem Timer 1 gehört doch der OC1x.
>
> IRSND benötigt 2 Timer. Dabei wird Timer1 genutzt, um das Bitmuster
> auszusenden. Da wird die ISR standardmäßig 15000 mal pro Sekunde
> aufgerufen.
>
> Aber das reicht noch nicht, denn das Signal muss zusätzlich noch
> moduliert werden, üblicherweise mit 32kHz bis 42kHz - je nach Protokoll.
> Dafür wird dann eine PWM mit der nötigen Modulationsfrequenz benötigt.
> Da Timer1 ja schon belegt ist, können dafür PWM-Pins für Timer0 oder
> Timer2 genutzt werden.

Jetzt wird nen Schuh draus.
Danke für den Hinweis. :-)

Vg

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Damit ist die Anzahl der unterstützten Protokolle nun auf die schöne
> runde Zahl von 50 gewachsen. :-)

Ein tolles Projekt! Ließ sich flott für ATMega 8 kompilieren. Ich habe 
da noch diverse ältere Geräte ohne funktionierende Fernbedienung. Macht 
das Sinn, hier mal mit dem IRSND zu scannen, ob man die Tastenkommandos 
rauskriegt?

Ich hatte das schon mit verschiedenen "Universal"-Fernbedienungen 
versucht aber die Ergebnisse sind nicht zufriedenstellend. Wenn sie 
überhaupt mal Protokoll/Adresse(?) treffen, fehlen einfach noch zu viele 
Kommandos. Ich will die Geräte nicht gern wegschmeißen.

Vielleicht hat jemand sowas Ähnliches schon mal gemacht?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Ich habe
> da noch diverse ältere Geräte ohne funktionierende Fernbedienung.

Bei älteren Geräten waren die Empfänger-Chips oft noch in spezielle 
Hardware gegossen. Da lohnt sich schon mal das Aufschrauben und 
Nachsehen. Über den Namen des Chips kann man dann das verwendete 
Protokoll ermitteln und für dieses dann evtl. zusammen mit IRSND ein 
Progrämmchen schreiben, um die Codes per Brute Force herauszufinden.

> Macht
> das Sinn, hier mal mit dem IRSND zu scannen, ob man die Tastenkommandos
> rauskriegt?

Wenn man noch nichtmals weiß, um welches Protokoll es sich handelt, wird 
das wegen der riesigen Zahl der möglichen Kombinationen eine Suche der 
Stecknadel im Heuhaufen. Da müsste man erstmal wenigstens durch das 
Ausschlussverfahren die Zahl der möglichen Protokolle einschränken. Und 
selbst dann kann das immer noch jede Menge an möglichen Codes ergeben, 
die man durchprobieren muss.

Am besten stellst Du mal diese Geräte hier vor. Vielleicht kennt sogar 
jemand das entsprechende Gerät und kann entweder Hinweise oder sogar 
direkt IRMP-Daten dazu liefern.

von Stefan Z. (stefan_z)


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Ein tolles Projekt! Ließ sich flott für ATMega 8 kompilieren. Ich habe
> da noch diverse ältere Geräte ohne funktionierende Fernbedienung. Macht
> das Sinn, hier mal mit dem IRSND zu scannen, ob man die Tastenkommandos
> rauskriegt?

Das ist normalerweise der Weg, ja.
ABER es gab/gibt durchaus Systeme die nicht "passen".
Ich habe z.B. eine Mitsubishi FB aus den frühen 80ern.
Die hält 15 Jahre mit zwei AAA Batterien, sendet aber auch ultra-kurze 
Impulse und das in exotischer Frequenz.

Prinzipiell KANN man JEDES Protokoll erkennen / nutzen, aber so seltsame 
Trägerfrequenzen / Impulslängen werden nicht mit einem TSOP36/38KHz als 
Empfänger laufen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan Z. schrieb:
> ABER es gab/gibt durchaus Systeme die nicht "passen".

Du hast batmans Frage nicht ganz verstanden: Ihm fehlen Fernbedienungen 
zu bestimmten Geräten. Das heißt, er kann diese noch nichtmals 
einscannen, sondern lediglich mit IRSND diverse Codes einfach 
durchprobieren und schauen, wie das Gerät darauf reagiert.

Ein ziemlich aussichtsloses Unterfangen, solang man nicht zumindest das 
verwendete Protokoll durch irgendwelche (externe) Informationen 
bestimmen kann.

: Bearbeitet durch Moderator
von Stefan Z. (stefan_z)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ein ziemlich aussichtsloses Unterfangen, solang man nicht zumindest das
> verwendete Protokoll durch irgendwelche (externe) Informationen
> bestimmen kann.

Ah stimmt. My bad...
Ja dann wird es in der Tat sehr schwierig - der Blick auf die 
Empfänger-ICs wäre vermutlich wirklich die einzige Chance.
Oder in einem Sammler-Forum einen Besitzer der FB finden der auch noch 
einen Arduino oder ein Oszi hat…

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja ich werd mir alles erstmal richtig durchlesen. 50 Protokolle klingt 
viel aber überschaubar. Meint ihr, es dauert zu lange, alle möglichen 
darauf basierenden Codes mal hintereinander durchzublinken? Also per 
Hand wollte ich das nicht versuchen, nech. :)

Ein Gerät ist z.B. ein DVB-S-Receiver mit einem verreckten PT2211 in der 
FB, evt. mal Batterien verpolt, die IR-LED leuchtet/flackert dauerhaft. 
Über den Code kriege ich noch näheres raus, obwohl es sich für das Gerät 
weniger lohnt.

Interessanter aber schwieriger wäre der Fall des VCR Samsung SVX 322, 
den muß ich mal aufmachen, wird wohl aber in den Haupt/Timercontroller 
gehen.

von Stefan Z. (stefan_z)


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Naja ich werd mir alles erstmal richtig durchlesen. 50 Protokolle klingt
> viel aber überschaubar. Meint ihr, es dauert zu lange, alle möglichen
> darauf basierenden Codes mal hintereinander durchzublinken? Also per
> Hand wollte ich das nicht versuchen, nech. :)

Nunja, es ist ja eine Library…
Man KÖNNTE nun ein Programm schreiben, das alle Codes durchprobiert.
Aber das klingt nach Science Fiction :-)
Ich persönlich würde den µC mit größtem Flash dafür wählen - dann kann 
man alle Protokolle aktivieren und loslegen.
Zwischen jedem Protokoll ggfs. nen Tastendruck fordern, dass man weiß 
was denn grad funktioniert hat - wenn es denn ein Treffer ist.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
bei den Universall FB gibt es auch oft einen manuellen Suchmodus. Wenn 
der aktiv ist drückt man die Power Taste, wenn das Gerät reagiert kann 
man andere Tasten probieren. Wenn das Gerät nicht reagiert drückt man 
wieder die Lern-Taste um auf den nächsten Code umzuschalten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Ein Gerät ist z.B. ein DVB-S-Receiver mit einem verreckten PT2211 in der
> FB,

Protokoll ist RC5. Das sollte einfach rauszubekommen sein, da die Zahl 
der Kombinationen überschaubar sind. Die Geräteadressen sind fix an 
einen festen Wert für jede Geräteklasse (Radio, CD-Player, Fernseher 
usw.) gebunden. Das Ein-/aus-Kommando ist auch bekannt für alle 
RC5-Geräte.

Also: RC5-Adresse für DVB-S-Receiver Geräteklasse ergoogeln und dann die 
bekannten RC5-Kommandos ausprobieren. Sollte sich nichts für DVB-S 
finden lassen, dann alle möglichen Geräteadressen in Kombination mit 
Ein-/Aus-Kommando ausprobieren. Die Anzahl der möglichen Geräteadressen 
ist ziemlich beschränkt.

> Interessanter aber schwieriger wäre der Fall des VCR Samsung SVX 322,

Höchstwahrscheinliches Protokoll: SAMSUNG oder SAMSUNG32.

SAMSUNG32:

16 Adress-Bits + 16 Kommando-Bits, damit 4294967296 mögliche 
Kombinationen. Da wird man alt, bis man die durchhat. Zumindest 65536 
Adressen müsste man durchprobieren, in der Hoffnung, dass man mit dem 
Kommando einen Treffer erzielen könnte.

SAMSUNG:

16 Adress-Bits + 4 ID-Bits + 8 Kommando-Bits, damit 268435456 
Kombinationen. Kann man ebenso vergessen.

Stefan Z. schrieb:
> Ich persönlich würde den µC mit größtem Flash dafür wählen - dann kann
> man alle Protokolle aktivieren und loslegen.

Ja, klar... und sich mit Popcorn auf die Couch setzen und warten, bis 
der Fernseher anspringt. Wenn Du Glück hast, siehst Du es gerade noch, 
bevor Dir die Augen zufallen.

von Stefan Z. (stefan_z)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, klar... und sich mit Popcorn auf die Couch setzen und warten, bis
> der Fernseher anspringt. Wenn Du Glück hast, siehst Du es gerade noch,
> bevor Dir die Augen zufallen.

Er wollte wissen wie man es BruteForce macht… :-)
Ich habe nicht behauptet, dass das schnell geht.

von Heinz K. (hagejot)


Bewertung
0 lesenswert
nicht lesenswert
Zuerst einmal vielen Dank für das sehr nützliche Programmpaket.

Beim Testen ist mir eine Kleinigkeit aufgefallen (wenn mich meine 
rostigen C-Kenntnisse nicht täuschen):

In dem Beispielprogramm "irmp-main-avr-uart.c" vom 09.09.2016 dürfte es 
im Buffer
    char        buf[3];
spätestens bei
    itoh (buf, 4, irmp_data.address);
etwas eng werden ;-o

Viele Grüsse

Heinz

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis, es muss natürlich
char        buf[5];
heißen.

Wird in der Zip-Datei und im SVN aktualisiert.

: Bearbeitet durch Moderator
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe da nochmal eine Frage zum NEC/NEC42 Protokoll, bei dem beim 
ersten Tastendruck zwar der komplette Satz mit Adresse und Kommando 
gesendet wird, danaich aber nur noch der Frame 'Tastenwiederholung', 
egal welche Taste gedrückt blieb.

Gibt es eine Chance, das mit IRMP auch auszuwerten oder ist IRMP da 
hilflos, weil ja nicht mehr der ganze Satz gesendet wird? Beim nächsten 
Aufruf von irmp_get_data() bekomme ich jedenfalls kein Repetition Flag. 
Ich habe schon probiert, die IRMP_KEY_REPETITION_LEN von 150ms auf z.B. 
500ms zu erhöhen, dann wird das Flag gesetzt, wenn ich schnell genug auf 
der Fernbedienung hämmere - aber das ist ja nicht der Sinn der Sache.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Gibt es eine Chance, das mit IRMP auch auszuwerten oder ist IRMP da
> hilflos, weil ja nicht mehr der ganze Satz gesendet wird?

IRMP erkennt natürlich die kurzen NEC-Key-Repetition-Frames, welche 
durch längeres Tastendrücken entstehen - aber nur innerhalb einer 
gewissen Zeit. Wenn diese abgelaufen ist (Timeout), werden 
NEC_Repetition-Frames ignoriert, bis wieder ein richtiger Frame kommt.

Das ist auch sinnvoll so. Denn sonst werden versehentlich eingefangene 
Key-Repetition-Frames (z.B. durch wildes Herumschwenken einer ganz 
anderen Fernseh-FB) noch Stunden später ausgewertet, obwohl der 
eigentliche Frame vorher eine ganz andere(!) Adresse enthielt. Diese 
Macke hat zum Beispiel meine Multimedia-Festplatte: Wenn ich diese mal 
kurz bedient habe und anschließend mit meiner Fernseh-FB durch längeres 
Tastendrücken die Lautstärke hochschraube, bekommt das meine 
Multimedia-Festplatte in den falschen Hals und wiederholt den letzten 
Befehl, den sie vor einer halben Stunde mal bekommen hat.

IRMP hatte denselben Fehler auch mal. Ist aber schon 5-6 Jahre her. 
Damals ist das aufgefallen, weil eine Word Clock im Wohnzimmer 
plötzlich bei Bedienung des Fernsehers gesponnen hat. Daher habe ich 
einen Timeout (100ms) dafür eingebaut. Läuft dieser ab, werden 
nachfolgende Repetition-Frames ignoriert.

Wie groß ist denn der zeitliche Abstand bei dieser merkwürdigen FB? 
Größere Abstände als 100ms habe ich noch nicht gesehen.

> Ich habe schon probiert, die IRMP_KEY_REPETITION_LEN von 150ms auf z.B.
> 500ms zu erhöhen,

Das war die falsche Stelle, diese Konstante ist für Protokolle, die 
keinen gesonderten Key-Repetition-Frame kennen, sondern einfach den 
letzten wiederholen.

In irmp.c findest Du:
#define NEC_FRAME_REPEAT_PAUSE_LEN_MAX          (uint_fast16_t)(F_INTERRUPTS * 100.0e-3 * MAX_TOLERANCE_20 + 0.5)

Hier ist der maximal mögliche zeitliche Abstand des Key-Repetition-Frame 
definiert, dass dieser gerade noch erkannt wird: 100.0e-3 entspricht 
100µms. Den Wert könntest Du hier durch Ändern nach Deinem Geschmack 
erhöhen.

Eventuell musst Du dabei aber auch IRMP_KEY_REPETITION_LEN synchron dazu 
erhöhen. Ich glaube aber - ohne in den Source gesehen zu haben - dass 
dieses nicht nötig ist.

: Bearbeitet durch Moderator
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wie groß ist denn der zeitliche Abstand bei dieser merkwürdigen FB?

Die Fernbedienung ist zwar merkwürdig, aber ich habe zwei solche Modelle 
(Analoger SAT Receiver und Billig FFS), die vom Layout sehr gut für das 
Audiocenter für meine Eltern geeignet sind. Die brauchen zwei getrennt 
regelbare TV-Lautstärken für Lautsprecher(Mutter) und Kopfhörer(Vater), 
für die das Layout der alten FB gut geeignet sind. (Kurz: Tiny85 steuert 
per I2C einen TDA8444, der 2 Stück LM1036 Audioprozessoren regelt).

Die Repeat Frames setzen etwa nach 100ms ein (muss ich nochmal genauer 
oszillodingsen), also deutlich später als die o.a. 100µs.
Ich werde mal NEC_FRAME_REPEAT_PAUSE_LEN_MAX so erhöhen, das ich noch 
keinen Überlauf riskiere - vielen Dank, Frank!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Ich werde mal NEC_FRAME_REPEAT_PAUSE_LEN_MAX so erhöhen, das ich noch
> keinen Überlauf riskiere

Da die Konstante mit einem uint_16t-Cast versehen ist, wird sie 
vermutlich auch mit einem 16-Bit-Zähler verglichen. Du darfst Dich also 
ruhig trauen. So schnell sollte der Überlauf nicht zu erreichen sein. 
65536 geteilt durch 15000 ergibt mehr als 4 Sekunden :-)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
So, es klappt bei mir nicht mit den Repeat Codes, aber ich weiss 
wenigstens, warum.
Die standardisierte NEC_REPEAT_START_BIT_PAUSE_TIME liegt bei 2250µs, 
bei meinem beiden Fernbedienungen aber bei 4200µs und liegt damit voll 
im Bereich der normalen NEC_START_BIT_PAUSE_TIME. IRMP erkennt also 
einen normalen FB Code und verlangt mit Recht nun Daten. Da kommt aber 
nur der eine kurze Puls wie in diesem Oszillogramm:
https://www.mikrocontroller.net/attachment/78767/NEC-Repeat.JPG

Und das wird von IRMP verworfen. Es hilft natürlich auch nichts, 
NEC_REPEAT_START_BIT_PAUSE_TIME auf 4200 zu drehen, denn es gibt keine 
Möglichkeit, echten Datenframe und Repeatframe auseinander zu halten.

Macht nix, dann muss ich meinen alten Herrschaften nur sagen, das sie 
tippen müssen. Das Audiodings speichert dann sowieso die Daten im 
EEPROM, so das sie nicht allzuviel hämmern müssen.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> IRMP erkennt also
> einen normalen FB Code und verlangt mit Recht nun Daten.

Ich kann das durchaus als Sonderbedingung in IRMP einbauen, wenn Du es 
möchtest. Ich schau mir das mal im Laufe des Tages näher an.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich kann das durchaus als Sonderbedingung in IRMP einbauen, wenn Du es
> möchtest.

Wenn es möglich ist, wäre das natürlich super - mein Papa ist 93 Jahre 
alt und nur schwer auf ungewohnte Sachen zu schulen. Da die Audiokiste 
was zu Weihnachten ist, würdest du ein altes Ehepaar sehr glücklich 
machen und lobend erwähnt werden :-)

Ich hatte schon probiert, NEC_REPEAT_START_BIT_PAUSE_TIME auf 4200µs 
umzustellen, aber da hatte ich zu einfach gedacht. Im Moment habe ich 
auch nicht die Zeit, mich in den Code einzuarbeiten, da hast du nämlich 
ein voluminöses Stück Software geschaffen :-)

Ich baue heute die Lautsprecherendstufe und den Kopfhörerverstärker - 
Ich schau einfach mal später wieder vorbei.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Version 3.0.5 ist im SVN.

Änderung:

 - 16.12.2016: Unterstützung von Nicht-Standard Nec-Repetition-Frames
   (4500us Pause statt 2250us)

@Matthias: Damit sollte Dein Problem behoben sein. Die Änderung ist 
alleinig in irmp.c.

: Bearbeitet durch Moderator
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> @Matthias: Damit sollte Dein Problem behoben sein. Die Änderung ist
> alleinig in irmp.c.

Es tut mir leid, aber nun ist jeder Frame einer mit gesetztem 
IRMP_FLAG_REPETITION :-(

Es gelingt mir manchmal, durch wiederholtes Drücken das Flag zu toggeln, 
aber selbst bei kürzesten Auslösen wird das Flag gesetzt, oder auch 
gelöscht und dann aber auch nicht im Repeat Fall gesetzt. Am besten 
belassen wir es dabei und nehmen die Änderung wieder raus. Vielen Dank 
für deine Mühe. Wenn ich die Zeit habe, werde ich da nochmal eintauchen, 
aber nun muss ich erstmal noch an der Hardware rumbauen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Es gelingt mir manchmal, durch wiederholtes Drücken das Flag zu toggeln,
> aber selbst bei kürzesten Auslösen wird das Flag gesetzt

Dann schickt die FB wohl immer noch mindestens einen Repetition-Frame 
hinterher.

> Am besten
> belassen wir es dabei und nehmen die Änderung wieder raus. Vielen Dank
> für deine Mühe. Wenn ich die Zeit habe, werde ich da nochmal eintauchen,
> aber nun muss ich erstmal noch an der Hardware rumbauen.

Okay, dann machen wir das später.

Du könntest mir irgendwann einen Scan schicken mit kurzen Tastendrücken 
als Scan schicken, dann weiß ich, wieviele die FB da noch 
hinterherschickt. Die könnte IRMP dann ignorieren.

Oder Du ignorierst in der Anwendung die ersten 1,2 oder 3 
Repetition-Frames. Das ist wohl einfacher, in der Anwendung einen Zähler 
mitzuführen.

von ADG (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schönen Guten Abend
Ich darf euch heute Abend meine Anpassungen für IRSND UND IRMP 
vorstellen

Die Projekte worden so erweitert das es auf der Erweierung(ESP8266) für 
Arduino IDE zum laufen gebracht worden sind.


Die Anpassungen von IRSND  sind in der Datei IRSND.txt zusammengefast 
bzw. IREMP.txt für IREMP.

IRSEND.ino ist für den Arduino Skechfile

Hoffe das ich euch ein bisschen weitergebracht habe und das diese 
Projekte weiter erweitert werden.

mfg
ADG

von ADG (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Guten Abend

Bin gerade dabei mein Fernbedienung für meinen Alten Satresiver 
einzulesen
Dabei ist mir aufgefallen das 2 Sachen merkwürdig sind

Der ATMEGA und der ESP8266 erkennt bei der der Taste "OK" der 
Fernbedienung
folgen den CODE

protocol 7 -> RC5 ?
address  8
command  80

Sollte es nicht IRMP_RECS80EXT_PROTOCOL sein "protocol 12" da es 
Technisat ist und wenn ich nun den Code Sende über IRSND eragiert der 
Reviser nicht.

Vielleicht kann mir von euch Jemand helfen.

Danke ADG


PS.
Habe auch den Scan von IRMP mit beigefügt (F_INTERRUPTS 20000)

000000000000000000000000000000000000001111111111111111111111111111111111 
100000000000000000000000000000000000001111111111111111111111111111111111 
100000000000000000000000000000000000000111111111111111100000000000000000 
000111111111111111110000000000000000000111111111111111110000000000000000 
000111111111111111111111111111111111110000000000000000000000000000000000 
000111111111111111111111111111111111110000000000000000000111111111111111 
110000000000000000000111111111111111110000000000000000000011111111111111 
111111<\n>

000000000000000000000000000000000000001111111111111111100000000000000000 
001111111111111111100000000000000000001111111111111111111111111111111111 
100000000000000000000000000000000000000111111111111111100000000000000000 
000111111111111111100000000000000000000111111111111111110000000000000000 
000111111111111111111111111111111111100000000000000000000000000000000000 
000111111111111111111111111111111111110000000000000000000111111111111111 
110000000000000000000111111111111111110000000000000000000011111111111111 
111111<\n>

000000000000000000000000000000000000001111111111111111111111111111111111 
000000000000000000000000000000000000001111111111111111111111111111111111 
100000000000000000000000000000000000000011111111111111110000000000000000 
000011111111111111110000000000000000000111111111111111110000000000000000 
000011111111111111111111111111111111110000000000000000000000000000000000 
000001111111111111111111111111111111110000000000000000000011111111111111 
111000000000000000000001111111111111111000000000000000000011111111111111 
111111<\n>

000000000000000000000000000000000000001111111111111111000000000000000000 
001111111111111111100000000000000000001111111111111111111111111111111111 
100000000000000000000000000000000000000111111111111111100000000000000000 
000111111111111111110000000000000000000111111111111111110000000000000000 
000111111111111111111111111111111111110000000000000000000000000000000000 
000111111111111111111111111111111111110000000000000000000011111111111111 
110000000000000000000011111111111111111000000000000000000011111111111111 
111111<\n>

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ADG schrieb:
> Ich darf euch heute Abend meine Anpassungen für IRSND UND IRMP
> vorstellen

Vielen Dank! Ich werde die ESP8266-Teile in den aktuellen IRMP-Source 
übernehmen.

ADG schrieb:
> Der ATMEGA und der ESP8266 erkennt bei der der Taste "OK" der
> Fernbedienung
> folgen den CODE
>
> protocol 7 -> RC5 ?
> address  8
> command  80

Wenn ich den beigefügten Scan auswerte, bekomme ich:

protocol 7   = RC5
address 0x08 = dec 8
command 0x57 = dec 87

Bis auf das Kommando stimmt es also überein. Das solltest Du nochmal 
überprüfen.

> Sollte es nicht IRMP_RECS80EXT_PROTOCOL sein "protocol 12" da es
> Technisat ist und wenn ich nun den Code Sende über IRSND eragiert der
> Reviser nicht.

Nein, es ist definitiv RC5. Ich habe mit dem Linux-IRSND genau obige 
Daten ausgegeben und es ergibt sich dasselbe Muster. Zu Deiner Frage 
wegen des Herstellers: Es gibt Hersteller, die durchaus verschiedene 
IR-Protokolle nutzen bzw. genutzt haben. Dazu gehört zum Beispiel auch 
Technisat.

: Bearbeitet durch Moderator
von ADG (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen

und guten Morgen UKW

ja du hast recht habe es auch noch herausgefunden das es RC5ex ist.
Somit habe ich ein Problem mit IRSND von ATMEGA der den Code nicht 
richtig Moduliert auf RC5.

Werde heute Abend den Scann von RC5ex von ATMEGA(IRSEND) dann mal 
posten.
Vielleicht habe ich timeing Probleme am ATMEGA

mfg
ADG

von batman (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Entweder ich mache was falsch oder ich habe einfach nur Pech mit meinen 
exotischen FB. Jedenfalls bekomme ich bestenfalls jede dritte mit IRMP 
überhaupt erkannt und beim Zurücksenden mit IRSND siehts dann noch 
schlechter aus. Kein Problem scheinen generell die langen Frames mit 
langen Pulsen zu machen aber ich habe wohl ziemlich viele Kurzpulser-FB 
- viel altes Geraffel.

Um das Problem zu untersuchen, habe ich mal mit einem Power-Kommando für 
ein DVB-T angefangen, der von IRMP noch als RECS80 erkannt wird aber mit 
IRSND ans Gerät zurückgesendet, keine Reaktion.

Folgendes verstehe ich dabei nicht:
Die originale FB sendet, immer alles pro einzelnem kurzen Knopfdruck, 
abwechselnd 2 versch. Frames (Dateien dt-pow-rec1/2.gif). Nennt man wohl 
Toggeln?
Sende ich die emfangenen IRMP_DATA mit IRSND, sendet der scheinbar 
jedesmal einen anderen Frame (ich habe die ersten 5 als 
dt-pow-snd1-5.gif aufgefangen) aber keins identisch mit den original 
Frames? Protokoll evt. falsch erkannt?

protocol: 0x06   RECS80   address: 0x0005   command: 0x001E   flags: 
0x00

ps: F_INTERRUPTS = 20000, Mega8 @8Mhz mit gut kalibriertem internen Osc.

von ADG (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Beim Testen ist mir heute Abend noch ein Fehler beim ESP8266 irsnd 
Modull aufgefallen

Beim Senden von RC5 wurden die Zeiten nicht eingehalten und daher musste 
ich im IRSEND.ino in der IRS noch einen OFFSET einbauen.

habe mit -160 gute Erfahrung gemacht bei RC5 wenn ihr einen besseren 
Wert findet umso besser

#define INTERRUPT  (F_CPU/F_INTERRUPTS) -160

und in der ISR muss der nächste IRS an erste Stelle




/*---------------------------------------------------------------------
* INTERRUPT FUER IRSND UND IREMP
---------------------------------------------------------------------*/
void timer0_ISR (void){
    // Set-up fure den naechsten  interrupt cyclus
      timer0_write(ESP.getCycleCount() + INTERRUPT);

 if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
}

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin. Die Senderoutine für RECS80 scheint die Frames um ein Bit 
rechtsvorschoben zu senden. Das Toggelbit erscheint auf Pos.3 statt 2. 
Wenn ich den Sendepuffer vorm Senden nach links schiebe, kommen die 
Kommandos teilweise an.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ADG schrieb:
> habe mit -160 gute Erfahrung gemacht bei RC5 wenn ihr einen besseren
> Wert findet umso besser

Erstmal danke, ich werde das im Arduino-Source nachziehen. Mal eine 
Frage wegen des Timers: Kann man den beim ESP8266 nicht so einstellen, 
dass er regelmäßig feuert, ohne dass man ihn in der ISR retriggern muss? 
Dadurch könnte man den Jitter eliminieren.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Die Senderoutine für RECS80 scheint die Frames um ein Bit
> rechtsvorschoben zu senden. Das Toggelbit erscheint auf Pos.3 statt 2.
> Wenn ich den Sendepuffer vorm Senden nach links schiebe, kommen die
> Kommandos teilweise an.

Mit RECS80 hast Du genau dasjenige Uralt-Protokoll erwischt, das im IRMP 
am wenigsten getestet wurde - besser gesagt: gar nicht. Denn es gibt 
kaum noch Geräte, die RECS80 verwenden. So habe ich RECS80 komplett nach 
Dokumentation implementiert - ohne Chance auf irgendwelche Gerätetests.

Ich werde mir die IRSND-Routine dazu nochmal anschauen und 
gegebenenfalls nachbessern.

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dafür hast du es aber schon super getroffen. Die Empfangsroutine IRMP 
funktioniert und im Sendepuffer von IRSND wird das Frame auch schon 
korrekt zusammengebaut (inkl. Startbit!). Dann scheint die Senderoutine 
noch ein Startbit vorne dran zu hängen, also irgendwo ist wohl was 
doppelt gemoppelt.

Ich habe das irsnd.c entsprechend abgeändert, so daß hier kein "1"-Bit 
vorangestellt wird, der Puffer startet dann mit dem Togglebit. Also 
praktisch alles einmal links geschoben, die vordere "1" fällt weg. So 
funktionierts bei mir:
#if IRSND_SUPPORT_RECS80_PROTOCOL == 1
        case IRMP_RECS80_PROTOCOL:
        {
            toggle_bit_recs80 = toggle_bit_recs80 ? 0x00 : 0x80;

            irsnd_buffer[0] = toggle_bit_recs80 | ((irmp_data_p->address & 0x000F) << 4) |
                              ((irmp_data_p->command & 0x003C) >> 2);                                           // STAAACCC
            irsnd_buffer[1] = (irmp_data_p->command & 0x03) << 6;                                               // CCC00000
            irsnd_busy      = TRUE;
            break;
        }
#endif


Sehr nützliches Proggi, danke dafür!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> So funktionierts bei mir:

Danke für den Hinweis, ich werde das so im Source anpassen.

von batman (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir noch eine FB vorgenommen, die von IRMP nicht erkannt wird. 
Ich habe davon sogar mehrere und jede paßt wieder zu einer ganzen Reihe 
früher verbreiteter Fernseher mit dem gleichen oder ähnlichen Chassis. 
Es steckt z.B. im Nordmende F17, Telefunken 618, Thomson ICC5, Saba, 
Ferguson u.a.

Wie die Analyse mittels Oszilloskop ergab, handelt es sich schlicht um 
RECS80 auf Adresse 0x7 mit 400 kHz Resonator Basistakt, ABER diesmal im 
Flashed Mode. D.h. (1) statt Modulation gibts nur einen einzelnen 
IR-Puls pro Bit und (2) wird das Startbit als 2.Toggelbit verwendet - 
ist also nicht konstant.

Erkennung
Letzteres läßt sich durch eine kleine Erweiterung der Erkennung im 
irmp.c beheben. Ob es dann möglicherweise auch andere Protokolle falsch 
als RECS80 erkennt, kann ich nicht ausschließen. Glaube es aber nicht, 
da das doch ziemlich speziell ist.
                    if ( irmp_pulse_time >= RECS80_START_BIT_PULSE_LEN_MIN && irmp_pulse_time <= RECS80_START_BIT_PULSE_LEN_MAX &&
                       ((irmp_pause_time >= RECS80_START_BIT_PAUSE_LEN_MIN && irmp_pause_time <= RECS80_START_BIT_PAUSE_LEN_MAX) ||
                        (irmp_pause_time >= RECS80_0_PAUSE_LEN_MIN         && irmp_pause_time <= RECS80_0_PAUSE_LEN_MAX)))
                    {                                                           // it's RECS80
#ifdef ANALYZE
                        ANALYZE_PRINTF ("protocol = RECS80, start bit timings: pulse: %3d - %3d, pause: %3d - %3d or pause %3d - %3d\n",
                                        RECS80_START_BIT_PULSE_LEN_MIN, RECS80_START_BIT_PULSE_LEN_MAX,
                                        RECS80_START_BIT_PAUSE_LEN_MIN, RECS80_START_BIT_PAUSE_LEN_MAX,
                                        RECS80_0_PAUSE_LEN_MIN,     RECS80_0_PAUSE_LEN_MAX);
#endif // ANALYZE
                        irmp_param_p = (IRMP_PARAMETER *) &recs80_param;
                    }


Timing
Das geänderte Timing (400 statt 455 kHz Basistakt) muß noch man im 
irmpprotocols.h anpassen. Wie ich das sehe, kann man nicht verschiedene 
Timing-Varianten desselben Protokolls gleichzeitig erkennen (und senden) 
können. Daher habe ich mal einen Kompromiß ausgetestet, der anscheinend 
alle meine RECS80 erfolgreich erkennt und sendet. Ich setze das mal als 
Vorschlag rein, ohne Gewähr. Da sich bei RECS80 alle Zeitkonstanten vom 
Basistakt ableiten, braucht man eigentlich nur jeweils diesen im Header 
ändern.
/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * RECS80:
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#define RECS80_CLK             440e+3              // 440 kHz resonator prim.clock (standard is 455 kHz)
#define RECS80_PULSE_TIME                       (5.0*12+4)/RECS80_CLK           // modulated: 1/RECS80_CLK*(5*12+4), flashed: 1/RECS80_CLK*4
#define RECS80_1_PAUSE_TIME                     (3.0*1152)/RECS80_CLK           // 3*To pause time
#define RECS80_0_PAUSE_TIME                     (2.0*1152)/RECS80_CLK           // 2*To pause time
#define RECS80_START_BIT_PULSE_TIME             RECS80_PULSE_TIME               // constant pulse time
#define RECS80_START_BIT_PAUSE_TIME             RECS80_1_PAUSE_TIME             // always 1-bit for modulated mode, 0/1 toggled in flashed mode
#define RECS80_FRAME_REPEAT_PAUSE_TIME          (55296.0/2)/RECS80_CLK          // frame distance / 2 (?)
#define RECS80_ADDRESS_OFFSET                   1                               // skip 1 bit (toggle bit)
#define RECS80_ADDRESS_LEN                      3                               // read 3 address bits
#define RECS80_COMMAND_OFFSET                   4                               // skip 4 bits (1 toggle + 3 address)
#define RECS80_COMMAND_LEN                      6                               // read 6 command bits
#define RECS80_COMPLETE_DATA_LEN                10                              // complete length
#define RECS80_STOP_BIT                         1                               // has stop bit
#define RECS80_LSB                              0                               // MSB...LSB
#define RECS80_FLAGS                            0                               // flags

Pulsbreite
Sämtliche obige Pulse Distance Werte werden nach meiner Erfahrung exakt 
eingehalten, nur bei der Pulsbreite gabs leider problematische 
Abweichungen. Der errechnete (modulierte) Standardpuls mit 455 kHz 
Resonator liegt bei 141us. In Dokus verschiedener Chips findet man aber 
Werte von 158, 167 u.a., während die von mir gemessenen Pulsbreiten 
sogar 250 und mehr sind. Keine Ahnung wieso aber ich mußte dann einen 
Korrekturfaktor von 1.3 zum Theoriewert multiplizieren, damit es 
klappte. Oben hab ich ihn wieder rausgenommen.

Flashed Mode
Eine Flashed Mode Transmission kann man nicht mit einem üblichen TSOP 
Schmalband Receiver empfangen. Zum Scannen des Codes bis ca. 10 cm 
Entfernung tut es als "Breitband-Receiver" ein Fototransistor mit Pullup 
zw. 10k-50kOhm. Größere R strecken die Pulslänge, was manchmal 
vorteilhaft ist.
Senden im Flashed Mode funktioniert dagegen hier ganz normal mit IRSND, 
d.h. die Modulation stört den Breitband-Empfänger(TV) anscheinend nicht. 
Ich empfehle allerdings eine gute Sendepower. Ich pulse 500-600mA, also 
ein knappes Watt. Die originalen Flasher-FB haben alle 2 Sendedioden.

Tastrate
Schließlich, für eine Verbesserung der Effizienz sollte der Träger 
1/3-1/4 Tastrate bekommen, so kann man den Sendestrom pro IR-LED 
verdoppeln, mit entsprechendem Reichweitenvorteil. Mir scheint, das 
Umkonfigurieren der Tastrate ist bei IRSND nicht so leicht zu machen 
aber vielleicht kriegst du es ja hin, Frank. Ansonsten muß man eben ggf. 
mehr Blitzer beschäftigen.

von ADG (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo UKW
(Frage vom 21.12.2016)

Sorry das ich erst jetzt Antworte war anderweitig beschäftigt.
Das mit dem Jitter muss ich mal ausproben und das es ohne ISR geht muss 
ich mal darüber denken.

Kannst du mir die genau Laufzeit von der ISR(IRSND) zukommen lassen

mfg
ADG

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ADG schrieb:
> Das mit dem Jitter muss ich mal ausproben und das es ohne ISR geht muss
> ich mal darüber denken.

Ich meinte das so: Jedesmal, wenn die ISR betreten wird, musst Du einen 
Zeitpunkt angeben, wann sie wieder aktiv werden soll. Das ist ziemlich 
blöd, denn je nach Laufzeit der ISR muss dieser Zeitraum länger oder 
kürzer angegeben werden, damit die ISR in konstanten Zeitabständen 
aufgerufen wird.

Mich wundert, dass das nicht besser geht. Auf jedem mickrigen ATTiny 
kann man sagen: "Feuere 15000 mal in der Sekunde". Und das passiert dann 
auch, egal wie lange die ISR gerade braucht.

Geht das mit dem ESP8266 nicht?

> Kannst du mir die genau Laufzeit von der ISR(IRSND) zukommen lassen

Genau das ist doch das Problem: Die Laufzeit der ISR ist komplett 
unterschiedlich - je nachdem, ob was gesendet werden muss oder nicht. 
Ich kann Dir also keine Laufzeit angeben.

Bei IRMP ist es übrigens genauso: Je nachdem, ob ein Frame empfangen 
wird, ist die Laufzeit entweder extrem kurz (gerade nix los) und sehr 
lang (Suchen nach dem Protokoll nach Empfang des Start-Bits).

Deshalb bieten ja die µCs einen Timer im CTC-Modus, welcher die ISR in 
konstanten Zeitabschnitten aufruft. Dabei ist dieser Zeitabschnitt 
unabhängig von der Laufzeit der ISR. Sowas muss es doch auch für den ESP 
geben?!?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
batman schrieb:
> Wie die Analyse mittels Oszilloskop ergab, handelt es sich schlicht um
> RECS80 auf Adresse 0x7 mit 400 kHz Resonator Basistakt, ABER diesmal im
> Flashed Mode. D.h. (1) statt Modulation gibts nur einen einzelnen
> IR-Puls pro Bit und (2) wird das Startbit als 2.Toggelbit verwendet -
> ist also nicht konstant.

Danke für Deine ausführliche Dokumentation zu Deinen Erfahrungen mit dem 
RECS80-Protokoll. Ich werde Deine Änderungsvorschläge in die nächste 
Version einfließen lassen.

von Marcel (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es gibt da ein Samsung Protokoll das nutzt nicht 4500µs sondern 
irgendetwas um die 1800µs als Startbit. Kann das Jemand implementieren, 
bestätigen oder mir einen Vorschlag machen wie ich das dennoch gut 
umgesetzt bekomme?

Es handelt sich bei dem Gerät um einen AV-Receiver von Samsung. Im 
Anhang mal ein paar Aufzeichnungen zu dem Protokoll und zu den 
funktionierenden und implementierten Samsungprotokollen als Vergleich.

Danke und Gruß
Marcel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcel schrieb:

> es gibt da ein Samsung Protokoll das nutzt nicht 4500µs sondern
> irgendetwas um die 1800µs als Startbit. Kann das Jemand implementieren,
> bestätigen oder mir einen Vorschlag machen wie ich das dennoch gut
> umgesetzt bekomme?

Am besten machst Du mittels IRMP_LOGGING ein paar Scans. Wie das geht, 
ist im Artikel erklärt. Wenn Du sie mir schickst, baue ich das ein.

von Gasparo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
There is any port of for STM32DUINO? This is a very could port of 
ARDUINO por STM32 processor, that have ARM VERSION with good price and 
features.

Thanks.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

für STM32 etc. sind
typedef unsigned char                   uint8_t;
typedef unsigned short                  uint16_t;
in  irmpsystem.h doppelt gemoppelt.

Gruß,
Jörg

von 900ss D. (900ss)


Bewertung
2 lesenswert
nicht lesenswert
Moin Frank,

ich wollte einfach nur DANKE sagen für das schöne Stück Software.

Habe es schon sehr lange auf dem Schirm gehabt, das einfach mal 
auszuprobieren aber wie das so ist. Jetzt gibt es ein kleines Projekt, 
wo ich das einsetzen möchte.

Es war so verblüffend einfach und hat sofort funktioniert, dass ich es 
immer noch nicht glauben kann :-)

Habe hier ein Teensy-3.1 liegen, den ich aber bare-metal programmiere. 
Habe ein paar kleine Änderungen in deinem Source in dem "TEENSY-Zweig" 
dazu gemacht, ins Projekt genommen, Start und geht :-) Unglaublich.

Super und nochmal Danke.

900ss

von Marcel (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Marcel schrieb:
>
>> es gibt da ein Samsung Protokoll das nutzt nicht 4500µs sondern
>> irgendetwas um die 1800µs als Startbit. Kann das Jemand implementieren,
>> bestätigen oder mir einen Vorschlag machen wie ich das dennoch gut
>> umgesetzt bekomme?
>
> Am besten machst Du mittels IRMP_LOGGING ein paar Scans. Wie das geht,
> ist im Artikel erklärt. Wenn Du sie mir schickst, baue ich das ein.

Hallo,

danke für die Antwort. Haben jetzt mal die Daten aufgezeichnet. Siehe 
Anhang.
Danke! Gruß Marcel

von Marcel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zur Ergänzung noch: Taktfrequenz CPU 16MHz Hardware Atmega1284P

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcel schrieb:
> Haben jetzt mal die Daten aufgezeichnet. Siehe Anhang.

Danke, schaue ich mir an. Es ist ein sehr interessantes und absolut 
exotisches Protokoll: 2 verschiedene Pulslängen und 3 verschiedene 
Pausenlängen. Ist mal etwas ganz anderes :-)

Sobald ich mehr herausbekommen habe, melde ich mich wieder.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcel schrieb:
> danke für die Antwort. Haben jetzt mal die Daten aufgezeichnet. Siehe
> Anhang.

Im IRMP-Artikel unter Download findest Du die Version 3.0.7 im SVN.

Änderungen:

  - Neues Protokoll: SAMSUNGAH (ich wusste keinen besseren Namen)
  - Einige Verbesserungen für den ESP8266-Support

Mit dieser Version sollte Deine SAMSUNG-Fernbedienung auszulesen sein. 
Ich habe Adresse und Kommando erstmal folgendermaßen aufgeteilt, weil 
ein Frame 48 Bit hat:

  0..15 Adresse
 16..31 wird ignoriert, ist sowieso bis auf 1 Bit immer 0
 32..48 Kommando

Damit bekommt man für Deine Scans:
# Taste 1:
110000101100101010000000001000001000000010100000 p=51 (SAMSUNGAH), a=0x5343, c=0x0501, f=0x00
----------------------------------------------------------------------
# Taste 2:
110000101100101010000000001000000010111011110000 p=51 (SAMSUNGAH), a=0x5343, c=0x0f74, f=0x00
----------------------------------------------------------------------
# Taste 3:
110000101100101010000000001000001100111001110000 p=51 (SAMSUNGAH), a=0x5343, c=0x0e73, f=0x00
----------------------------------------------------------------------
# Power-Taste:
110000101100101010000000001000000000000000100000 p=51 (SAMSUNGAH), a=0x5343, c=0x0400, f=0x00
----------------------------------------------------------------------
# Lautstaerke UP:
110000101100101010000000001000000000010001100000 p=51 (SAMSUNGAH), a=0x5343, c=0x0620, f=0x00
----------------------------------------------------------------------
# Lautstaerke UP GEHALTEN:
110000101100101010000000001000000000010001100000 p=51 (SAMSUNGAH), a=0x5343, c=0x0620, f=0x00
110000101100101010000000001000000000010001100000 p=51 (SAMSUNGAH), a=0x5343, c=0x0620, f=0x01

Die Adresse ist also immer 0x5343.

Du solltest mal sämtliche Tasten durchtesten, um sicherzustellen, dass 
die Aufteilung Adresse/Kommando so sinnvoll ist. Ich habe die Grenzen 
nämlich ziemlich willkürlich gewählt.

P.S.
Setze F_INTERRUPTS besser runter auf 15000. Die 20000 bedeuten hier nur 
unnötige Belastung des Prozessors. Für die SAMSUNG-FB sind 15000 
Interrupts pro Sekunde völlig ausreichend. Selbst 10000 für F_INTERRUPTS 
würden reichen, um das Protokoll zuverlässig zu erkennen.

: Bearbeitet durch Moderator
von Marcel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das ging aber schnell! Danke werde es ausprobieren  und mich dann 
nochmal melden.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

seit Version 3.0.2:
In file included from irmp/irmp.h:18:0,
                 from src/irmpmain.h:4,
                 from src/irmpmain.c:11:
irmp/irmpsystem.h:161:41: error: conflicting types for 'uint_fast8_t'
 typedef unsigned char                   uint_fast8_t;
                                         ^
In file included from /video/gcc-arm-none-eabi-5_4-2016q3/lib/gcc/arm-none-eabi/5.4.1/include/stdint.h:9:0,
                 from cmsis/core_cm3.h:120,
                 from cmsis_boot/stm32f10x.h:488,
                 from irmp/irmpsystem.h:38,
                 from irmp/irmp.h:18,
                 from src/irmpmain.h:4,
                 from src/irmpmain.c:11:
/video/gcc-arm-none-eabi-5_4-2016q3/arm-none-eabi/include/stdint.h:52:31: note: previous declaration of 'uint_fast8_t' was here
   typedef __UINT_FAST8_TYPE__ uint_fast8_t;
                               ^
Gruß
Jörg

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> seit Version 3.0.2:
> In file included from irmp/irmp.h:18:0,
>                  from src/irmpmain.h:4,
>                  from src/irmpmain.c:11:
> irmp/irmpsystem.h:161:41: error: conflicting types for 'uint_fast8_t'
>  typedef unsigned char                   uint_fast8_t;
>                                          ^

Danke für den Hinweis. Für STM32 gehört das natürlich nicht dahin. Es 
geht doch um STM32?

Gruß,

Frank

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Ja, geht um STM32.
Gruß
Jörg

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Als eifriger Nutzer des IRMP-Codes hätte ich einen Vorschlag zur 
Code-Strukturierung, um die Integration in C++-Projekte (mit header-only 
Libs) einfacher zu gestalten:

a) Auslagerung der Deklaration der Funktionsprototypen irmp_int(), 
irmp_get_data() und irmp_ISR() zusammen mit dem typedef für IRMP_DATA in 
eine eigene Header-Datei.

b) das Cpp-Macro input(x) mit einem #ifndef versehen.

Das wäre super (für die nä. Version).

von Marcel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

kannst Du noch bitte das SAMSUNGAH Protokoll in IRSND übernehmen?

Danke und Gruß Marcel

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marcel schrieb:
> kannst Du noch bitte das SAMSUNGAH Protokoll in IRSND übernehmen?

Gern. Läuft es denn im IRMP? Laut Deinem letzten Beitrag wolltest Du es 
testen und Dich dann nochmal melden...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> a) Auslagerung der Deklaration der Funktionsprototypen irmp_int(),
> irmp_get_data() und irmp_ISR() zusammen mit dem typedef für IRMP_DATA in
> eine eigene Header-Datei.

Ganz habe ich das nicht verstanden. Die externen Deklarationen stehen 
doch bereits in irmp.h? Kannst Du mal schematisch andeuten, wie Du irmp 
nutzt?

"header-only Libs" hört sich danach an, dass Du den IRMP-Source 
includest statt dazuzubinden mittels IRMP_USE_AS_LIB. Ist es das?

> b) das Cpp-Macro input(x) mit einem #ifndef versehen.

#ifndef WAS-Denn?

: Bearbeitet durch Moderator

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.