mikrocontroller.net

Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Autor: Wilhelm M. (wimalopaan)
Datum:

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

Wenn ich irmp.h inkludiere, dann bekomme ich tonnenweise #define's, die 
ich nicht haben will. Die sind ja ohne scope ... deswegen möchte ich die 
in meinem C++-Code nicht haben (ich verwende keine Cpp-Makros mehr).

Ich hätte also nur gerne die Prototypen und die typedefs. Dann kann ich 
in einer eigenen Header-Datei statt dem folgenden
namespace Irmp {
extern "C" {
struct IrmpData {
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
    uint16_t                            address;                                    // address
    uint16_t                            command;                                    // command
    uint8_t                             flags;                                      // flags, e.g. repetition
} __attribute__ ((__packed__));

typedef struct IrmpData IRMP_DATA;

extern void                             irmp_init (void);
extern uint_fast8_t                     irmp_get_data (IRMP_DATA *);
extern uint_fast8_t                     irmp_ISR (void);

}
constexpr uint8_t Repetition = 0x01;

}
einfach innerhalb des namespaces die (neue) Headerdatei inkludieren (mit 
Ausnahme des constexpr ...).

Ganz am Ende(!) meiner (einzigen) Implmentierungsddatei kommt dann:
constexpr auto finterrupts = IrInterruptFrequency.value;

static_assert(finterrupts >= 10000, "IR Interrupts frequeny too low");
static_assert(finterrupts <= 20000, "IR Interrupts frequeny too high");

#define F_INTERRUPTS finterrupts

#define input(x) iRPin::read()

namespace Irmp {
#include "irmp/irmp.c"
}

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

Ja: s.o.

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

Ja, das Macro eben, damit ich das obige benutzen kann ;-)
Also etwa:
#ifndef input
#  define input(x)                              ((x) & (1 << IRMP_BIT))
#endif

: Bearbeitet durch User
Autor: Marcel (Gast)
Datum:

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

Entschuldige. Ja wir haben es getestet und es sieht gut aus.
Die Werte sind, bis auf die wechselnden Tasten, immer identisch.
Man kann also sehr gut damit arbeiten =). Danke hierfür!

Autor: Jörg R. (jrie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In 3.0.7 ist SAMSUNGAH defaultmäßig an.
Damit gehen verschiedene andere Protokolle nicht mehr.
Das sollte auf defaultmäßig aus.
Gruß, Jörg

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> In 3.0.7 ist SAMSUNGAH defaultmäßig an.
> Damit gehen verschiedene andere Protokolle nicht mehr.
> Das sollte auf defaultmäßig aus.

Upps, da habe ich vergessen, es nach dem Test wieder abzuschalten. 
Sorry, ich deaktivier das wieder. Danke für den Hinweis.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich wollte mal fragen was der Stand ist bzgl. dem SamsungAh Protokoll 
und IRSND?

Gruß
Marcel

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marcel schrieb:
> ich wollte mal fragen was der Stand ist bzgl. dem SamsungAh Protokoll
> und IRSND?

Sorry, ich bin noch nicht dazu gekommen. Aber ich denke, dass ich das am 
kommenden Wochenende fertigstellen werde.

Autor: Stefan B. (n0b0dy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

würde das Interesse bestehen das Protokoll von MCE Funkfernbedienungen 
für PCs wie es sie z.B. von Medion, Toshiba oder Pearl gibt/gab zu 
integrieren?

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan B. schrieb:
> würde das Interesse bestehen das Protokoll von MCE Funkfernbedienungen
> für PCs wie es sie z.B. von Medion, Toshiba oder Pearl gibt/gab zu
> integrieren?

Ja, auf jeden Fall.

Autor: Stefan B. (n0b0dy)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, auf jeden Fall.

Prima, dann wurdest du mir nicht umsonst im VDR-Portal empfohlen. ;-)

Ich bin leider kein top Programmierer und habe quasi null Erfahrung mit 
Protokollanalyse, trotzdem habe ich mich mal mit dem kleinen Saleae 
Logic Analyzer versucht.
Ich kann gerne mal jeden Tastendruck aufnehmen und hier die Logic oder 
die  CSV Datei(en) anhängen.

Zum Datenabgreifen habe ich einen Empfänger geöffnet, einen IC 
vorgefunden für den man ein Datenblatt findet und der Datenausgang auf 
eine Lötöse geführt wird.

Sagt mir was ihr ihr braucht und ich stelle euch die Daten zur 
Verfügung. :-)

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Heute, bzw. gestern habe ich IRMP auf einem China STM32F103C8T6 Mini 
Development Board mit libopencm3 [1] zum Laufen gebracht. Es waren nur 
geringe Änderungen/Ergänzungen nötig (Diff im Anhang). Wenn Interesse 
besteht, die Änderungen in die Codebasis zu übernehmen, würde ich das 
ganze noch etwas aufhübschen und ein lauffähiges Beispielprogramm 
nachreichen.

Und vielen Dank für den super Decoder. Hat auf Anhieb funktionert. Um 
meinen vor Jahren mal geschriebenen RC5-Decoder anzupassen, hätte ich 
wahrscheinlich länger gebraucht.


[1] https://github.com/libopencm3/libopencm3

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wenn Interesse besteht, die Änderungen in die Codebasis zu übernehmen,
> würde ich das ganze noch etwas aufhübschen und ein lauffähiges
> Beispielprogramm nachreichen.

Sehr gern kann ich Deine Änderungen in die Codebasis übernehmen.

Autor: Marcel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank M. schrieb:
> Marcel schrieb:
> ich wollte mal fragen was der Stand ist bzgl. dem SamsungAh Protokoll
> und IRSND?
>
> Sorry, ich bin noch nicht dazu gekommen. Aber ich denke, dass ich das am
> kommenden Wochenende fertigstellen werde.

Hi,

wollte mal fragem was der aktuelle Stand ist.
Gruß Marcel

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine libopencm3 Anpassungen dürften inzwischen einigermaßen vollständig 
sein. IRSND läuft jetzt auch, und zuletzt habe ich das IRMP-Logging über 
einen USART eingebaut.

Wens interessiert: Die Demoprogramme können unter [2] und das angepasste 
irmp unter [1] heruntergeladen werden.

Am schnellsten gehts mit
git clone --recursive http://cloudbase.mooo.com/git/irmp-demo

irmp und libopencm3 werden dann in Unterverzeichnisse von irmp-demo 
installiert.

[1] http://cloudbase.mooo.com/git/irmp
[2] http://cloudbase.mooo.com/git/irmp-demo

Autor: Text (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Leo:

>Am schnellsten gehts mit git clone --recursive http://cloudbase.mooo.com/
> git/irmp-demo

Nein, damit geht's gar nicht:

ssh: Could not resolve hostname cu.loc: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'cu.loc:git/irmp' into submodule path 
'/tmp/irmp-demo/2/irmp-demo/irmp' failed
Failed to clone 'irmp'. Retry scheduled

Wo kommt dieses cu.loc her?

Wenn ich dann in irmp-demo/.git/config

[submodule "irmp"]
  url = cu.loc:git/irmp


durch

[submodule "irmp"]
  url = http://cloudbase.mooo.com/git/irmp

ersetze, kann ich per git submodule init/update
das Repo aktualisieren.

Aber dann:

$ make
libopencm3.rules.mk:93: libopencm3/mk/genlink-config.mk: No such file or 
directory
libopencm3.rules.mk:167: libopencm3/mk/genlink-rules.mk: No such file or 
directory


???

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal danke fürs Testen.

> Wo kommt dieses cu.loc her?

Schlamperei, mein lokaler Nameserver kennt den Host aber.

> Wenn ich dann in irmp-demo/.git/config
>
> [submodule "irmp"]
>   url = cu.loc:git/irmp
> durch
>
> [submodule "irmp"]
>   url = http://cloudbase.mooo.com/git/irmp

Das habe jetzt so auf dem Server korrigiert.

> ersetze, kann ich per git submodule init/update
> das Repo aktualisieren.

> Aber dann:
>
> $ make
> libopencm3.rules.mk:93: libopencm3/mk/genlink-config.mk: No such file or
> directory
> libopencm3.rules.mk:167: libopencm3/mk/genlink-rules.mk: No such file or
> directory

Bei mir wurde wg. obigem Fehler das Submodul libopencm3 nicht richtig 
geladen (Alle Dateien waren gelöscht). Ein 'git reset HEAD' im 
Verzeichnis libopencm3 hats gerichtet.

Die Alternative wäre in einem neuen Verzeichnis nochmal ganz vorne mit
'git clone --recursive ...' anzufangen.

Wenn man libopencm3 schon irgendwo installiert hat, kann man auch im 
irmp-demo Makefile den Pfad (OPENCM3_DIR) dorthin zeigen lassen.

Autor: Text (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
git clone jetzt ok.

Aber immer noch:

$ (cd libopencm3; git reset HEAD)
$ make
libopencm3/mk/genlink-config.mk:63: libopencm3/lib/libopencm3_stm32f1.a 
library variant for the selected device does not exist.
make: Nothing to be done for 'all'.

Das:

>Wenn man libopencm3 schon irgendwo installiert hat, kann man auch im
>irmp-demo Makefile den Pfad (OPENCM3_DIR) dorthin zeigen lassen.

geht allerdings.

Autor: Text (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NB:

Wenn man zuerst im libopencm3 ein

$ make

laufen lässt und dann in  ./irmp-demo
ebenfalls, geht es.

Hätte man das wissen müssen?

Autor: Text (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hätte man das wissen müssen?

Ja, wenn man

>libopencm3/mk/genlink-config.mk:63: libopencm3/lib/libopencm3_stm32f1.a
>library variant for the selected device does not exist.

richtig interpretiert hätte...

Autor: Andres B. (adb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute.
Gibt es beim ATmega 328P irgend welche Besonderheiten die ich beachten 
muss, um die IRMP zum laufen zu bekommen. In Anderen Schaltkreisen 
ATtiny26_16UP und ATtiny 85  klappe das sofort.
Der ATmega 328P soll andere Pinbezeichnungen haben PORTB6 anstand PB6,
oder müssen andere FUSE Bits gesetzt werden,  der Defaultwerte ist 8Mhz 
Werksseitig  ? Selbst mit der irmp-main-avr.c   um eine LED zu Starten 
if (irmp_get_data (&irmp_data)) {PORTD = (1<<PORTD7);} Die IDE ist, AVR 
Studio 7, und im C Compiler - Symbols ist bei (-D) F_CPU=8000000UL 
eigetragen bei Optimization ist (-Os) gesetzt.
Passiert nix.
Liebe Grüße an alle

Autor: Andres B. (adb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab es gefunden, und läuft, Liebe Grüße an Frank.M, ich hatte 
vergessen in den Low Fuse das Häckcen für die interne Teilung durch 8 
rauszunehmen.
Liebe Grüße Andres

Autor: Ulf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieses Projekt is eine super Sache!
Vor vielen Jahren hatte ich mal mit RC5 rumgespielt...

Jetzt soll was mit einer FB vom Schrott angesteuert werden. Die kleinen 
Stolpersteine ließen sich durch lesen der Dokumentation vollständig 
beseitigen.

Danach geguckt, welches Protokoll verwendet wird, alle anderen 
Protokolle wieder ausgeknipst und man kann sich auf die eigentliche 
Applikation konzentrieren.

Vielen herzlichen Dank an alle Beteiligten!
Ulf

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin neu auf dem Gebiet der AVRs. Ziel meines ersten Projektes soll 
es sein, u. a. Relais auf einer Netzteilplatine mittels einer 
Fernbedienung zu schalten. Nicht die schwerste Angelegenheit, aber an 
einer Stelle hänge ich nun. Mein Code sieht folgendermaßen aus:


//wenn Taste auf Fernbedienung gedrückt
if (irmp_get_data (&irmp_data))
{

  //wenn Apple Protokoll
  if (irmp_data.protocol == IRMP_APPLE_PROTOCOL)
  {

    //wenn Play-Taste grdrückt
    if (irmp_data.command == 0x05)
    {

      //wenn Taste nicht lang gehalten (aber entprellt)
      if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
      {

        //wenn ausgeschalteter Zustand
  if(prev==0)
  {

    // toggle Relais
      PORTD ^= ((1<<PD6) | (1<<PD4));

      // toggle LEDs
      PORTB ^= ((1<<PB1) | (1<<PB2));

    prev=1;
  }
      }

      //wenn Taste lang gehalten
      if (irmp_data.flags & IRMP_FLAG_REPETITION)
      {

        //wenn eingeschalteter Zustand
  if(prev==1)
  {

          // toggle Relais
      PORTD ^= ((1<<PD6) | (1<<PD4));

      // toggle LEDs
      PORTB ^= ((1<<PB1) | (1<<PB2));

    prev=0;
  }
      }
    }
  }
}


Natürlich kann man das kürzer schreiben, aber zum Probieren und 
Auskommentieren vorteilhaft.
Ich verwende eine Apple Remote. Durch kurzes Drücken der 
Play/Pause-Taste sollen die Relais anziehen und durch langes Drücken 
wieder abfallen. Das funktioniert auch soweit, allerdings könnte die 
Zeitspanne, bis eine langes Drücken erkannt wird länger sein. Kann man 
das nachjustieren oder muss ich das in meinem Code berücksichtigen?

Des Weiteren ist es bei der Apple Remote der Fall, dass die 
Play/Pause-Taste zwei verschiedene Befehle direkt nacheinander sendet. 
Diese sind 0x5f gefolgt von 0x05. Ich habe festgestellt, dass das lange 
Drücken in Verbindung mit dem Befehl 0x5f nicht erkannt wird, mit dem 
Befehl 0x05 allerdings schon. Wie ist das zu erklären?

Verwende ich nun eine andere Taste, die lediglich einen einzigen Befehl 
sendet, habe ich festgestellt, dass mit meinem obigen Code das 
vermeintlich kurze Drücken dieser Taste zum Ein- und wieder zum 
sofortigen Ausschalten der Relais führt. Der kurze Tastendruck wird also 
vereinzelt bereits als langer Tastendruck erkannt? Auch hier stelle ich 
wieder die gleiche Frage. Kann die Zeitspanne, nach deren Ablauf ein 
langer Tastendruck erkannt wird, vergrößert werden?
Und warum tritt das Verhalten bei der Play/Pause-Taste mit zwei 
gesendeten Befehlen nicht auf?


Viele Grüße
Oliver

Autor: Jörg R. (jrie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kannst du mit einem Repeat Counter machen.
https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103/src/main.c#L669
Zeile 669 bis 675.
MIN_REPEATS entsprechend deinem Bedarf einstellen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Das funktioniert auch soweit, allerdings könnte die Zeitspanne, bis eine
> langes Drücken erkannt wird länger sein. Kann man das nachjustieren oder
> muss ich das in meinem Code berücksichtigen?

Du hast eventuell die Bedeutung des Flags etwas missverstanden. Flag = 1 
heisst nicht unbedingt, dass der Anwender die Taste wesentlich länger 
gedrückt hat. Es heisst eher, dass die FB einen Frame wiederholt 
ausgesandt hat - meist aufgrund eines längeren Tastendrucks. Das können 
auch schon mal 10 Frames (und damit auch 10x IRMP-Daten mit gesetztem 
Flag) lang sein, obwohl Du gefühlt erst eine halbe Sekunde gedrückt 
hast. Die FB feuert dann halt so schnell sie kann.

> Kann man das nachjustieren oder
> muss ich das in meinem Code berücksichtigen?

Jörg hat es mit seiner Antwort schon angerissen.

Hier nochmal mit anderen Worten:

Du musst das selber machen: Zähle einfach, wie oft Du Du einen 
Wiederholungsframe erhältst, also wie oft das Flag = 1 hintereinander 
gesetzt ist. Teste erstmal den Zähler auf 10, wenn dir das zu lang 
vorkommt, dann reduziere den Testwert.

: Bearbeitet durch Moderator
Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke Euch für die Hilfe! Fünf kleine Zeilen ergänzt und es 
funktioniert wie gewünscht.

Grüße
Oliver

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Ich danke Euch für die Hilfe! Fünf kleine Zeilen ergänzt und es
> funktioniert wie gewünscht.

Schön das du uns an der Lösung teil haben läßt, so das Leute mit 
ähnlichen Problemen hier gleich die Lösung finden können.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

da ich irgendwie vergessen worden bin was das Samsung AH Protokoll in 
der IRSND Lib angeht, hab ich mich mal selbst versucht da das Projekt 
sonst umsonst war!

Reicht es folgenden Block in die irsnd.c aufzunehmen mit entsprechenden 
Konstanten in irsndconfig.h?

Leider verstehe ich die Kommentare nich bei den Bitoperationen wie 
AAAAAAAAA oder CCCCCCCC. Evtl. kann mir das jmd. erklären.

#if IRSND_SUPPORT_SAMSUNGAH_PROTOCOL == 1
        case IRMP_SAMSUNGAH_PROTOCOL:
        {
            address = bitsrevervse (irmp_data_p->address, 
SAMSUNGAH_ADDRESS_LEN);
            command = bitsrevervse (irmp_data_p->command, 
SAMSUNGAH_COMMAND_LEN);

            irsnd_buffer[0] = (address & 0xFF00) >> 8; 
// AAAAAAAA
            irsnd_buffer[1] = (address & 0x00FF); 
// AAAAAAAA
            irsnd_buffer[2] = (command & 0xFF00) >> 8; 
// CCCCCCCC
            irsnd_buffer[3] = (command & 0x00FF); 
// CCCCCCCC
            irsnd_busy      = TRUE;
            break;
        }
#endif

Autor: Uwe (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich habe mal einen Versuch gestartet irmp in nodemcu unterzubringen und 
folglich mittels Lua zugänglich zu machen. Das war letztlich garnicht so 
schwer und funktioniert gut. Es reichen dann folgende Aufrufe in Lua:

irmp.init()
irmp.startrecv(
  function(pn, n, a, c, f)
    print(pn..": addr="..a..", cmd="..c..", flag="..f)
  end
)

Mit jedem empfangenen Code wird die Callback-Funktion aufgerufen, die in 
diesem Fall das Protokoll, die Adresse, das Kommando und die Flags 
ausgibt.

z.B.

NEC: addr=47685, cmd=5, flag=1

Wenn daran Interesse besteht, kann ich das mal zusammen packen und z.B. 
hier posten.

  Uwe

Autor: Helmut K. (chaosbastler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

ich benutze das  IR-LCD von Klaus Leidinger. Weshalb wird bei einem 
normalen NEC-Code (8bit-Adresse, 8bit Befehl) der Code immer 4-stellig 
als Hex ausgegeben.
Als Beispiel: Yamaha Fernbedienung RAX9, Power-Taste.
Angezeigt wird: Adresse: 857A , Command: 1F
Ich habe den Schaltplan zum Yamaha Gerät und da stehen auch
die Hex-Codes für die Fernbedienung drin. Power-Taste = Adresse: 7A , 
Command: 1F
Wenn ich jetzt den Code einer Fernbedienung nicht kenne , diesen mit 
IRMP auslese und dann in meinem Programm verwende, würde dies ja nicht 
funktionieren da die FB ja nur die Hex-Adresse 7A sendet u. nicht 857A.
Wie müßte ich denn IRMP abändern wenn ich die Ausgabe auf dem LCD
nicht im Hex- sondern im Dezimal-Format haben möchte.
Ich bin ein kpl. Anfänger was C betrifft.

Im Vorraus besten Dank
Helmut

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut K. schrieb:
> Weshalb wird bei einem normalen NEC-Code (8bit-Adresse, 8bit Befehl) der
> Code immer 4-stellig als Hex ausgegeben.

Das liegt daran, dass der NEC-IR-Code irgendwann später aufgebohrt 
wurde, um mehr verschiedene Geräteadressen zu ermöglichen. Schau Dir das 
aus dem IRMP-Artikel an:

  https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC

Aus dem NEC-Frame:
8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits

wurde irgendwann im Extended NEC-Format:
16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits 

Das heisst: die 8 invertierten Adress-Bits gibt es nicht mehr zwingend, 
sondern sind nun frei wählbar. Dadurch erhöht sich die Anzahl der 
maximalen Geräeteadressen von 265 auf 65536.

Aus diesem Grund verwendet IRMP die kompletten 16 Bit zur Angabe der 
Adresse und ist damit abwärtskompatibel zum alten Standard-NEC-Format. 
Möchtest Du einen NEC-Code per IRSND auch wieder senden, dann musst 
Du für die Adresse deshalb den kompletten 16-Bit-Code für die 
Geräteadresse angeben.

> Ich habe den Schaltplan zum Yamaha Gerät und da stehen auch
> die Hex-Codes für die Fernbedienung drin. Power-Taste = Adresse: 7A

Der invertierte Wert von 7A (alle Bits kippen) ist 85. Das passt also 
perfekt zu 857A, was IRMP ausgibt. Im Yamaha-Handbuch steht halt die 
alte Schreibweise drin, als es noch kein Extended NEC-Format gab.

> Wie müßte ich denn IRMP abändern wenn ich die Ausgabe auf dem LCD
> nicht im Hex- sondern im Dezimal-Format haben möchte.

In IRMP: Gar nicht. IRMP ist lediglich eine Bibliothek, die keine 
Benutzerinteraktion hat und sich schon gar nicht um 
Ausgabe-Zahlenformate kümmert.

Die Ausgabe auf dem LCD hat Klaus dazuprogrammiert, wahrscheinlich zu 
finden in seinem main.c.

Ich halte von der dezimalen Ausgabe in diesem Fall jedoch wenig bis gar 
nichts. Die meisten IR-Fernbedienungen benutzen eine Tastatur-Matrix, 
deren Kommandos hexadezimal codiert sind. Da findest Du dann z.B.
Taste "1" = 0x11  erste  Reihe, erste  Spalte
Taste "2" = 0x12  erste  Reihe, zweite Spalte
Taste "3" = 0x12  erste  Reihe, dritte Spalte
Taste "4" = 0x21  zweite Reihe, erste  Spalte
Taste "5" = 0x22  zweite Reihe, zweite Spalte
Taste "6" = 0x23  zweite Reihe, dritte Spalte
Taste "7" = 0x31  dritte Reihe, erste  Spalte
Taste "8" = 0x32  dritte Reihe, zweite Spalte
Taste "9" = 0x33  dritte Reihe, dritte Spalte

Oder auch:
Taste "1" = 0x31
Taste "2" = 0x32
...
Taste "9" = 0x39

In dezimaler Schreibweise würde man so eine Systematik schwerlich 
erkennen.

> Ich bin ein kpl. Anfänger was C betrifft.

Ich empfehle, Dir zumindest Grundkenntnisse über das Hexadezimal-System 
anzueignen. Gerade bei der Programmierung von µCs hilft es ungemein, 
Werte hexadezimal lesen zu können - zumindest bis 0xFF. Dafür muss man 
nicht konkret wissen, was z.B. 0xE5 in dezimal ist. Es geht lediglich 
um das Verständnis.

Dass das Yamaha-Handbuch die Adresse ebenso in Hex (7A) ausgibt, hat 
schon einen Grund...

: Bearbeitet durch Moderator
Autor: Helmut K. (chaosbastler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank
danke für deine Antwort.

> Frank M. schrieb
>Aus dem NEC-Frame: 8 Adress-Bits + 8 invertierte Adress-Bits
> + 8 Kommando-Bits + 8 invertierte Kommando-Bits
> wurde irgendwann im Extended NEC-Format:
> 16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits

Ich hatte mir so etwas schon gedacht.
Danke

Autor: Matthias F. (frank91)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo

ich habe die IRMP und IRSND Library erweitert.
Nun werden STM32 Controller mit der HAL-Library unterstützt.
Es ist somit möglich ein Projekt mittels STM32CubeMX zu erstellen und 
die Library einzubinden.

Momentan ist die Library so eingestellt, dass wenn man im Cube die 2 
benötigten Pins "IRMP_Receive" und "IRSND_Transmit" bennent, diese 
direkt von der Library übernommen werden.
In diesem Fall muss man nur noch den Timer in irsndconfig.h anpassen

Verwendet habe ich hierfür das Board "NUCLEO F103RB" mit dem Controller 
STM32f103RB.
Da die HAL-Library für alle STM32 Controller gleich ist sollten alle 
anderen Controller auch kein Problem sein.
Getestet habe ich es allerdings nur mit dem STM32f103RB.

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

Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Nun werden STM32 Controller mit der HAL-Library unterstützt.

Vielen Dank, werde ich mir anschauen und ins nächste Release mit 
einbauen :-)

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hat schon mal jmd von euch IRMP Sender & Empfängerroutine als eine 
lernbare FB laufen lassen und dazu vll ein fertiges Projekt? Ich suche 
eine Möglichkeit 10 Tasten mit B&O Codes zu belegen (eine normale 
lernbare FB kann das wg den 455kHz nicht).

Danke!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Artikel "DIY Lernfähige Fernbedienung mit IRMP":

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

Beachte, dass Du wg. den 455 kHz einen passenden TSOP brauchst.

: Bearbeitet durch Moderator
Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...jepp, das weiß ich...Top, da ist ja alles fertig! Das suchte ich als 
Grundlage...wenn ich NICHT lerne müssten ja auch 2xAAA reichen, oder?

Klaus.

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

Bewertung
0 lesenswert
nicht lesenswert
Da Du 10 Tasten brauchst, musst Du entweder die Schaltung und das 
Programm etwas anpassen oder die 5 Tasten in den 3 angebotenen Ebenen 
verwenden.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ist mir klar...wird kein Problem sein, deine Doku ist ja gut. 2xAAA 
natürlich nur mit lowvolt AVR...aber dann gehts, oder? Wie groß wird der 
Code, reichen 4k (Atiny44 hätte ich noch genug da)?

Klaus

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> wenn ich NICHT lerne müssten ja auch 2xAAA reichen, oder?

Neuere TSOPs arbeiten auch schon ab 2,5V. Der TSOP wird in dem oben 
genannten Projekt vom ATmega selbst versorgt und wird abgeschaltet, 
solange man nicht anlernt. Er verbraucht also im Normalbetrieb keinen 
Strom.

Bei 2xAAA solltest Du den Basiswiderstand vor dem Transistor anpassen, 
nämlich z.B. 820 Ohm wählen.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anpassungen auf 3V waren klar, die TSOP 2,5V Info kannte ich nicht - ich 
prüfe ob TSOP7000 das auch kann, Danke! Code wird um die 7k, mal sehen 
ob er unter 4k geht, wenn ich nur B&O nutze.

Werden die Befhele im E² abgelegt, falls mal die Batterie leer ist? Dazu 
fand ich keine Infos (würde das dann mit einer 150er LiPo aufbauen).

Tolles Teil und schon fast ein Youngtimer! :) Danke, Frank!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Wie groß wird der Code, reichen 4k (Atiny44 hätte ich noch genug da)?

Wenn Du nur B&O als Protokoll freischaltest, könnten 4k (knapp) reichen, 
musst Du ausprobieren. Ich hatte den ATmega gewählt, weil der ein 
relativ großes EEPROM zum Speichern der Codes hat. Aber Du kannst 
natürlich die Makro-Fähigkeit rauswerfen, schließlich gibts für jede 
Taste 3 Ebenen und pro Ebene und Tasten 5 Codes, also 15 pro Taste. 5 x 
15 = 75 Codes. Du brauchst aber nur 10.

Sollten IRMP und IRSND zusammen mit dem nötigen Anwendungscode nicht in 
die 4K Flash passen könntest Du folgendes machen:

Die 10 Tasten einmal per IRMP (ohne IRSND) anlernen und dann im EEPROM 
speichern, anschließend die abgespeckte Anwendung mit IRSND (ohne IRMP) 
flashen.

Da bei Dir das Anlernen der 10 Tasten wahrscheinlich ein einmaliger 
Vorgang ist, wäre das ein gangbarer Weg für Dich.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...daran dachte ich auch schon - und ob ich die Tasten über den ADC 
eines Tiny45 einlesen werde...hmmm :) Das mit der LED als Receiver hat 
sich vermtl nie umsetzen lassen, oder (ist ja auch egal, aber sehr 
interessant)?

Klaus.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> - ich prüfe ob TSOP7000 das auch kann, Danke!

TSOP7000 geht ab 2,7V, sollte also passen.

> Code wird um die 7k, mal
> sehen ob er unter 4k geht, wenn ich nur B&O nutze.

Wie gesagt: Du könntest daraus auch 2 Programme machen, eins zum 
Anlernen und eins zum Abspielen. Dann sollte es auf jeden Fall passen.

> Werden die Befhele im E² abgelegt, falls mal die Batterie leer ist?

Ja, die werden im EEPROM gespeichert. Beim ATTiny ist natürlich nicht so 
viel Platz, da musst Du abspecken, siehe Tipps oben. 10 Codes gehen auf 
jeden Fall :-)

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Das mit der LED als Receiver hat sich vermtl nie umsetzen lassen

LED als Receiver? Das wird wohl nur gehen, wenn Du sämtliche Störungen 
aus der Umgebung ausschließen kannst. Nimm lieber einen TSOP, damit geht 
das wesentlich entspannter.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...habe IRMP schonmal verwendet um ein altes Radio aus den 70iger FBbar 
zu machen, da passten in den Attiny auch alles rein für 10 Tasten plus 
das andere Zeug für Releais & Quellenstrg, Anzeige, I2C Poti und so - 
ich versuchs mal am Wochenende, bin schon sehr gespannt :)

Danke & schönen Feierabend!

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> und ob ich die Tasten über den ADC eines Tiny45 einlesen werde..

Ich weiß nicht, ob Du damit den Tiny aufwecken kannst. Normalerweise ist 
der verwendete ATmega im Sleep-Mode und verbrät nur wenige µA, um die 
Batterie zu schonen.

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> ...habe IRMP schonmal verwendet um ein altes Radio aus den 70iger FBbar
> zu machen, da passten in den Attiny auch alles rein für 10 Tasten plus
> das andere Zeug für Releais & Quellenstrg, Anzeige, I2C Poti und so -
> ich versuchs mal am Wochenende, bin schon sehr gespannt :)

Na dann viel Spaß!

Wenns läuft, kannst Du Dein Projekt ja gerne vorstellen :-)

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...dann muss ich wieder Prügel für den dirty-Code enstecken :) Daher 
gibts dann nur Bilder und die B&O Codes (aus dem EEPROM). Aber du weißt 
ja, wie das mit so Vorhaben am WE ist - es kommt immer was dazwischen! 
:)

Gruß, Klaus.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> ...dann muss ich wieder Prügel für den dirty-Code enstecken :)

Wieso "wieder"? ;-)

Ich biete mich gern an, den Code zu überarbeiten, wenn er dann nächstes 
... ähem ... übernächstes Wochenende fertig wird ;-)

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...so, was ich hier an Geräten nicht habe, habe ich entfernt (zudem UART 
+ BOOTLOADER) - bin bei knapp 5k, aber dem Attiny85 ja egal. Afaik läuft 
das auch mit internem RC ausreichend sauber, oder (auch beim 455kHz 
Protokoll)?

Nun muss ich noch kapieren, wie die Tastenroutine genau funktioniert und 
durch den ADC die Tasten auswerten (am besten einfach der existierenden 
Routine "vorgaukeln") - da die üblichen Mikrotaster ja immer 
Doppelkontakte haben, werde ich damit den ADC und einen PCINT0 bedienen 
- dann weckt jeder Tastendruck den uC UND kann per ADC ausgewertet 
werden - oder?

Ich würde nur eine LED verwenden und diese je nach gewählter "Bank" 
n-Mal blinken lassen. Vll auch beim Senden, damit man immer mal wieder 
sieht, "wo" man ist.

EDIT: Aber vll flansche ich das erstmal auf ein BB und teste, ob das B&O 
"Master Control Panel 5500" überhaupt damit läuft - sonst kann ich mir 
das gleich schenken.

Klaus.

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> da die üblichen Mikrotaster ja immer Doppelkontakte haben,

Wäre mir neu, wenn sie Doppelkontakte haben. Ich kenne das nur so, dass 
jeweils zwei der vier Pins immer paarweise miteinander verbunden sind. 
Aber ich lasse mich gern eines besseren belehren :)

> werde ich
> damit den ADC und einen PCINT0 bedienen - dann weckt jeder Tastendruck
> den uC UND kann per ADC ausgewertet werden - oder?

Hm, wenn die Taster wirklich Doppelkontakte haben, ja. Sonst: nein.

> EDIT: Aber vll flansche ich das erstmal auf ein BB und teste, ob das B&O
> "Master Control Panel 5500" überhaupt damit läuft - sonst kann ich mir
> das gleich schenken.

Ja. Alles Step by Step.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grmpf - du hast natürlich Recht. Also einige BAT42 in SMD spendieren, 
auch OK.

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...da ich den TSOP ja eh sockeln muss (wg 38 vs 455 kHz) überlegte ich, 
ob man den OUTPUT Pin (vom uC) der IR Diode nicht als INPUT Pin für den 
TSOP nutzen kann (ggf mit Steckbrücke im TSOP Sockel) - beides 
gleichzeitig braucht man ja eh nicht und es wäre eine weitere 
Optimierung. Geschaltete Stromversorgung für den TSOP entfällt dann eh.
Nun ist mal alles aufs Breadboard gesteckt und ich muss die Register 
noch auf Tiny85 ändern, dann erfolgt ein erster Versuch mit einem 
"normalen" 38kHz Gerät...

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...sooo, nachdem ich kapiert habe, dass IRSND in dem Projekt einfach zu 
alt war (Definitionen für die Tinys fehlten), habe ich die neue Version 
eingebunden und kann nun über 2 Tasten (Select & PWR) immerhin einen 
Befehl aus den 3 Bänken mit dem Tiny schicken. HW und SW sind also 
soweit iO, die Glotze geht an/aus. Nun muss die Abfrage der am ADC 
angeschlossenen Tasten implementiert werden, (für mich) die eigentliche 
Herausforderung an der Sache.

Klaus.

Autor: Frank L. (Firma: Flk Consulting UG) (flk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo,
Warum die Tasten mit ADC auswerten, wieviele Tasten willst Du abfragen 
und wieviele Pins hast Du frei?

Gruß
Frank

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank L. schrieb:
> Warum die Tasten mit ADC auswerten, wieviele Tasten willst Du abfragen
> und wieviele Pins hast Du frei?

Klaus schrieb oben etwas vom ATTiny85. Damit hat man nicht viel 
Spielraum ;)

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...so, auch das mit dem ADC läuft - ABER aus einem mir noch unbekannten 
Grund blockiert der ADC_read(); den IR Empfang / Lernprozess. Das kapier 
ich aber heute wohl nicht mehr...alles was sonst so geplant war, läuft. 
Fast fertig.
/*-----------------------------------------------------------------------------------------------------------------------
 * Initialize ADC
 *-----------------------------------------------------------------------------------------------------------------------
 */
static void
adc_init (void)
{

  ADMUX = (1<<REFS1);                                    // Interne Referenz 1,1V
  ADCSRA = (1<<ADSC) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS1);                  // Frequenzvorteiler 128
  ADCSRB |= (0<<ADLAR);                                    // Linksbündig = 1
  ADCSRA |= (1<<ADEN);                                    // Enable ADC

}


/*-----------------------------------------------------------------------------------------------------------------------
 * Read ADC value
 *-----------------------------------------------------------------------------------------------------------------------
 */

uint16_t ADC_Read(void){

  uint16_t ADC_value=0;

  ADMUX  |= (1<<MUX0);                      // Kanal ADC1 (PB2)
  
  ADCSRA |= (1<<ADSC);                            // eine Wandlung "single conversion"
  
  while (ADCSRA & (1<<ADSC) ) {}                   // auf Abschluss der Konvertierung warten

  ADC_value = ADCL;                           // mit uint16_t x
  ADC_value += (ADCH<<8);                     // in zwei Zeilen (LSB/MSB-Reihenfolge und
                                        // C-Operatorpriorität sichergestellt)
  
  return ADC_value;                               // ADC auslesen und zurückgeben

}

Den ADC habe ich nun über ein mode-flag während RX bzw TX abgeschaltet, 
weil das sonst nicht geht - aber wieso? Iwas bremst der aus...ist das 
sampling eine ISR?

@Frank L.: Mein Ziel ist es das ganze zu minimalisieren - ich hatte iwie 
keinen Lust auf einen AT168 (und auch keinen da) und Tasten über ADC 
auswerten find ich iwie grdstzl pfiffig.

EDIT: cnt = irmp_data[k].flags+1;  // get number of frames to send

-> Die "+1" sorgt bei mir dafür, dass der Fernseher (Toshiba!) stehts 
an->aus->an geht, vermtl in Verbindung mit der neuen irsnd iwie fehl am 
Platze? Gelöscht, geht.

Klaus.

: Bearbeitet durch User
Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
key_poll(); wird in der ISR aufgerufen und triggert dann den 
ADC_read();, der mit while alles blockiert - das muss geändert werden, 
keine Frage.

@ukw: Wieso aber die Befehle immer 2x gesendet werden (ich schalte in 
send_key(); die LED pro Frame einmal an/aus) und der Toshiba dann 
ein->aus->ein geht, ist mir noch nicht klar, da bist du aber eher der 
Profi? Fehlt dann da das Wiederholungs-Flag? Oder hat sich beim Toshiba 
Protokoll etwas geändert? Ich versuche es mal mit anderen IR Geräten...

Klaus.

Autor: Klaus R. (klaus2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ADC wird nun alle x-ms aufgerufen, die Diodenveroderung mit PCINT1 
funktioniert auch, alles läuft. sleep_cpu() musste ersetzt werden, bin 
nun im tiefschlaf im AT85. Fast fertig, dann muss ich noch eine HW (die 
den Namen verdient) mit etwas WAF fertigen...und der TSOP7000 muss mich 
endlich erreichen (oder ich zapfe den Beomaster direkt an).

EDIT: Letztes Problem ist, das durch Umbau auf ADC Tasten der Prog-Modus 
immer einen "Abbruch" erkennt, bin aber noch nicht ganz dahinter 
gekommen, wo & warum...

Klaus.

: Bearbeitet durch User
Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...mit einer JVC FB geht es, es wird nur 1x gesendet (bzw das 
entsprechende "Toggle Bit" gesetzt), der Receiver regiert nur mit "an" 
oder "aus". Vermutung ist also, das im IRMP beim Toshiba Protokoll etwas 
nicht ganz stimmt...falls du Infos brauchst (ein eep Dump zB), gerne.

EDIT: Der Abbruch wurde ausgelöst, weil der ADC dtl seltender die Tasten 
abfragt und daher noch der "alte" Wert drnsteht, was zu einem Abbruch 
führt:

else if (key == KEY_PROG_VALUE)
                        {
                            cancelled = TRUE;
                            break;
                        }

Klaus.

: Bearbeitet durch User
Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...so, wenn ich das Ganze auf der Ziel-HW habe, dann ist wieder das 
Problem, dass die ADC Werte der Tasten etwas unterschiedlich zum 
Breadboard sind - hier wäre nun noch eine Anlern-Routine sinnvoll: 
Drücke 3x Taste n bis LED kurz an geht, dann Taste n+1...usw, die 
Mittelwerte dann inkl. im EEPROM sichern und mit einer erlaubten 
Abweichung zur Auswertung nutzen. Mal sehn...

Klaus.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Wieso aber die Befehle immer 2x gesendet werden (ich schalte in
> send_key(); die LED pro Frame einmal an/aus) und der Toshiba dann
> ein->aus->ein geht, ist mir noch nicht klar,

Ich hatte Dir ja schon geantwortet per Mail, eben gerade nochmal.

Du solltest beim Anlernen grundsätzlich Wiederholungsframes ignorieren, 
also nur die Frames speichern, wo das Repetition-Flag NICHT gesetzt ist.

Pseudocode:
if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
{
    store_in_eeprom (irmp_data.protocol, irmp_data.address, irmp_data.command, irmp_data.flags & 0xF0);
}
else
{
    ignore frame;
}

Damit ist dann auch ausgeschlossen, dass Du beim Senden versehentlich 
Wiederholungsframes erzeugst, die zu 95% unsinnig sind.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ich hatte dir auch schon geantwortet :) und bin davon ausgegangen, 
das irmp & irsnd das in Verbindung mit remotecontrol.c 
(DIY_Lernfähige_Fernbedienung_mit_IRMP) selber regeln - das war aber 
dann wohl falsch. Also muss ich morgen "mal gucken".

EDIT: Vll liegt hier der Hase im Pfeffer...:

while (ms_cnt < 250)
                    {
                        // some devices need a repeated frame to accept the command, e.g. POWER command on Toshiba TV to switch off
                        if (! cancelled && irmp_data[k].protocol != 0xFF)       // after 250 ms....
                        {
                            IRMP_DATA id;

                            if (irmp_get_data (&id))                            // ... receive IR signal again
                            {
                                if (id.flags == 1)                              // it's a repeated frame, store it!
                                {
                                    framecnt++;
                                }
                                cli ();
                                ms_cnt = 0;
                                sei ();
                            }
                        }
                    }

                    irmp_data[k].flags = framecnt;


Danke, Klaus.

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Vll liegt hier der Hase im Pfeffer...:

Ja, glaube ich auch.

> // some devices need a repeated frame to accept
> the command, e.g. POWER command on Toshiba TV to switch off

Mittlerweile kann ich mich daran wieder erinnern. Ich hatte damals auch 
einen Tobshiba-Fernseher. Der wollte immer 2 Frames beim 
Ein-/ausschalten, sonst hat der Fernseher nicht reagiert. Die 
Original-FB hat das auch immer brav bei der Power-Taste so gemacht, egal 
wie kurz man die Power-Taste gedrückt hat.

Aus diesem Grund habe ich auch die Anzahl der Wiederholungen im EEPROM 
gespeichert.

Das war aber wohl ein spezielles Feature meines Fernsehmodells. Ich 
empfehle Dir daher, den Code folgendermaßen zu ändern:

Die letzte Zeile aus Deinem Code-Auszug:
irmp_data[k].flags = framecnt;

folgendermaßen ändern:
irmp_data[k].flags = 0;

Bei Deiner FB sollte es aber eigentlich nur passieren, wenn Du beim 
Anlernen die Taste zu lange drückst. Mit obiger Änderung sollte es dann 
kein Problem mehr sein.

: Bearbeitet durch Moderator
Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GENAU das hatte ich QnD morgen vor!

Toshiba hat das übrigens geändert ;)

Danke! Klaus.

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> GENAU das hatte ich QnD morgen vor!

Gut.

> Toshiba hat das übrigens geändert ;)

Das glaube ich. Ist auch schon 7 Jahre her, wo mir das aufgefallen ist.

Übrigens steht im Artikel der DIY-FB:

"Die Tasten auf der Originalfernbedienung sollten sehr kurz gedrückt 
werden, da die Wiederholbefehle mitgespeichert werden"

Das ist dann mit obiger Änderung dann auch hinfällig.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ich hab so kurz gedrückt wie irgend mgl...keine Chance. Aber das 
Geheimnis scheint ja nun gelüftet...

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hatte heute morgen noch ne Std Zeit - funktioniert nun. Ich glaube, 
das lag aber letztendlich daran, dass der ADC die Tasten zu langsam 
sampelt und daher der Befehl "Taste x gedrückt" 2 Sendezyklen auslöste. 
Habe den Code auch kommentiert und vertikutiert - wenn das auf der 
finalen HW läuft, dann poste ich den auch hier, weil das Ganze schon 
sehr adrett & minimalistisch geworden ist.

Klaus.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Ich glaube, das lag aber letztendlich daran, dass der ADC die Tasten zu
> langsam sampelt und daher der Befehl "Taste x gedrückt" 2 Sendezyklen
> auslöste.

Ja, das klingt plausibel. Hast Du auch schon den Sleep-Modus umgesetzt? 
Wenn ja, wie hoch ist dann noch der Stromverbrauch?

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...nicht für mich messbar, ich bin im kompletten deepsleep Nirvana. Iwo 
im x uA Bereich, damit unerheblich da ich ja ne LiPo nutze (siehe Foto 
oben).

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...so, nachdem ich - mangels debug Möglichkeit aus dem "inneren des 
Attiny" - ewig nach den letzten Fehlern auf der Ziel-HW gesucht habe, 
funktioniert nun auch die Lernroutine der Tasten. Man baut die FB auf, 
wählt schön gleichverteilte Widerstände und beim Einsetzen der Batterien 
drückt man kurz alle Tasten in einer festgelegten Reihenfolge - die ADC 
Werte werden dann im E² abgelegt. Damit sind Toleranzen etc egal...hoffe 
ich ;)

Die Todo & Ideen-Liste wird immer kürzer, einzig eine Doppelbelegung der 
5 Funktionstasten (exkl. SELECT) mit Longpress-Funktion wäre noch 
interessant (z.B. MUTE auf VOL- bei Longpress). Das wären dann 10 Fkt 
pro Bank bei 5 Tasten.

Aber so langsam frage ich mich auch, wieso ich mir nicht einfach eine 
2te Harmony 300 gekauft habe ;)

Klaus.

Autor: Klaus R. (klaus2)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
...so, das war jetzt - auf dem letzten Meter ist dann noch der 
ungesockelte AT85 auf der Ziel HW hopps gegeangen...war ja klar :)

Anbei Bilder & Code als Inspiration...

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
5 Tasten sind im praktischen Betrieb zu wenig, mir fehlen zB Mute und 
Prg1...also muss ich doch noch auf longpress erweitern, vll gleich mit 
Peter Ds Taster-Lib, die aber erst ADC fähig werden müsste...puh O.o

Klaus.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter hat (fast) alles fertig, war ja klar :)

Beitrag "Tastenmatrix auslesen über nur 2 Leitungen"

Klaus.

Autor: Klaus R. (klaus2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...an bestimmten Stellen wird auf "gültiges Protokoll" geprüft oder dies 
auf "ungültig" gesetzt (0xFF) wenn ein Lernvorgang beendet wurde - das 
initiale .eep enthält aber 0-en, so dass erstmal alle Code gültig sind. 
Ich habe hierzu #defines eingeführt mit VALID 23 / INVALID 0 und setze 
diese. Zudem leuchtet die Sende-LED nur sehr kurz, wenn erfolgreich 
gesendet wurde, bleibt aber dtl länger an, wenn man einen "leeren" Platz 
erwischt hat.

Das mit der Doppelbelegung durch longpress ist noch etwas aufwendiger, 
aber die letzte Hürde. Anbei der Code in v2.0

Klaus.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> das initiale .eep enthält aber 0-en

Der Trick ist, gar keine .eep einzuspielen.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...stimmt, wie einfach es sein kann ;) Muss ich mein savecodes flag noch 
auf 0xFF statt auf 0 prüfen.

Klaus.

Autor: Klaus R. (klaus2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich habe nun einen TSOP7000 erhalten (von Sascha, Danke!) und es ist wie 
es hat sein müssen - IRMP erkennt den Code nicht. Hast du eine Idee, ob 
es mehrere Code bei B&O (Mein Receiver ist BJ85 mit Bedienteil "Master 
Control Panel 5500") gibt? Verwundert es dich vll gar nicht? UART wird 
bei mir eng, weil ich ja "minimalistisch" unterwegs bin, könnte ich aber 
auf dem Breadboard iwie drankommen, denke ich.

Vll helfen ja die "screenshots" im Anhang (Überblick / die ersten 3 
Startimpulse) bei einer ersten Idee? Wäre toll, wenn du mir helfen 
könntest...hat aber keine Eile!

Gruß, Klaus.

EDIT: Das scheint es wohl nicht zu sein...ist das "dein" Protokoll`?

Frequency:  455 kHz
Coding:   pulse distance (manchester biphase code)
Frame:   4 start bits + 16 data bits + 1 trailer bit + 1 stopbit
Data:   8 address bits + 8 command bits
Start-Bit 1:   200µs puls, 3125µs pause
Start-Bit 2:   200µs puls, 3125µs pause
Start-Bit 3:   200µs puls, 15625µs pause
Start-Bit 4:   200µs puls, 3125µs pause
0-Bit:   200µs puls, 3125µs pause
1-Bit:   200µs puls, 9375µs pause
R-Bit:   200µs puls, 6250µs pause, repetition of last bit
Trailer bit:   200µs puls, 12500µs pause
Stop bit:   200µs puls
Repetition:   none
Pushbutton repetition:   N-times repetition of original-frames within 
100ms
Bit order:   MSB first

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

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:

> ich habe nun einen TSOP7000 erhalten (von Sascha, Danke!) und es ist wie
> es hat sein müssen - IRMP erkennt den Code nicht.

Schade, wahrscheinlich benutzt(e) B&O verschiedene Codierungen.

> Vll helfen ja die "screenshots" im Anhang (Überblick / die ersten 3
> Startimpulse) bei einer ersten Idee? Wäre toll, wenn du mir helfen
> könntest...hat aber keine Eile!

Am besten wären ein paar Scans (mit eingeschaltetem IRMP_LOGGING, siehe 
Artikel). Leider hat der ATTiny keinen UART. Du müsstest es also 
entweder über SW-UART erstellen oder doch einen AVR nehmen, der auch 
einen HW-UART hat.

Anhand solcher Scans kann ich dann ziemlich flott ein neues Protokoll 
einbauen.

> EDIT: Das scheint es wohl nicht zu sein...ist das "dein" Protokoll`?

Das habe ich auch aufgrund von Scans, die ich von einem User erhalten 
habe, eingebaut. Er hat mir dann auch bestätigt, dass es so 
funktioniert. Wenn ich es richtig in Erinnerung habe, habe ich damals 
auch eine Dokumentation im Internet zu diesem Protokoll gefunden.

Also: Wenn Du mir Scan-Dateien zuschickst, baue ich es gerne ein.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

gut, dann sattel ich den ganzen Kram (bzw nur irmp.h) in der kommenden 
Woche nochmal auf ATMEGA um und schicke dir entsprechende Scans - jetzt 
aufgeben ist keine Option :)

Ich habe in deinem Artikel gelesen, wie man die analysiert, bin mir aber 
unsicher ob deine irmp.exe nach Einlesen der scans direkt die für irmp.h 
relevanten Daten rausspuckt...ich überlasse das daher gerne & dankbar 
dem Profi!

Gruß, Klaus!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Ich habe in deinem Artikel gelesen, wie man die analysiert, bin mir aber
> unsicher ob deine irmp.exe nach Einlesen der scans direkt die für irmp.h
> relevanten Daten rausspuckt...ich überlasse das daher gerne & dankbar
> dem Profi!

Spuckt die Exe schon aus, aber wahrscheinlich ist es besser, Du schickst 
mir die Scans zu. Ich glaube, die Exe kann nur Scans mit 10kHz 
auswerten. Außerdem hat sie schon ein paar Jahre auf dem Buckel.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst ja nicht Dein Projekt portieren. Ein Standard-IRMP reicht 
vollkommen.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ja klar, nur standard irmp. Ich meld mich!

Klaus.

Autor: Frank L. (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

[...]
> Das habe ich auch aufgrund von Scans, die ich von einem User erhalten
> habe, eingebaut. Er hat mir dann auch bestätigt, dass es so
> funktioniert. Wenn ich es richtig in Erinnerung habe, habe ich damals
> auch eine Dokumentation im Internet zu diesem Protokoll gefunden.
[...]

Wenn ich mich richtig erinnere war ich derjenige, der damals die Scans 
gemacht hat.
Die Scans wurden mit einer B&O-Fernbedienung "Video Terminal 
Bang&Olufsen", Baujahr ca. mitte '90 erstellt und die Funktion in IRMP 
von mir auch mit modernen B&O-FB geprüft.
Wahrscheinlich hatte B&O in den 80'ern noch ein anderes Protokoll.

Gruß,
f

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe schon seit viel Jahre auf Deutsch nicht gesprochen.

Ich habe einige IR-scan von Samsung, Akai and Gree.
Wer kann mir helfen in diesem Topik?

If possible in English :)

Danke schon!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Ich habe einige IR-scan von Samsung, Akai and Gree.

I have already answered per E-Mail.... 5 minutes before ;-)

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I will (also) post my B&O scan if it is raining again :)

Klaus.

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat jemand mal irmp in einem STM32 HAL Projekt genutzt?

Gruß
Stephan

Autor: Gerd E. (robberknight)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Als leidenschaftlicher Nutzer von ChibiOS (http://www.chibios.org) 
wollte ich IRMP auch in meinen ChibiOS-basierten Projekten verwenden und 
habe daher eine Integration geschrieben. Da IRMP ja mittlerweile schon 
für einige Plattformen verfügbar ist und daher entsprechende defines 
vorsieht, war das auch gar nicht mal so schwer oder viel Code.

Patch ist angehängt und ich würde mich über eine Aufnahme ins offizielle 
IRMP-Repo oder Kritik und Verbesserungsvorschläge freuen.

Nachdem ChibiOS als RTOS auch so nette Dinge wie Events mitbringt, auf 
die z.B. Threads warten können, habe ich auch dafür eine Unterstützung 
eingebaut. Wenn man das in der irpmconfig.h mit IRMP_USE_EVENT aktiviert 
und einen passenden Threadpointer und Eventflag definiert, bekommt der 
Thread einen Event gesendet sobald gültige IR-Daten empfangen wurden.

In der irmp-main-chibios.c wird gezeigt wie man das verwendet.

Ich habe den Code bei mir jetzt mit ChibiOS/NIL Version 18.2.1 auf einem 
kleinen STM32F030F4 am Laufen und da ist neben IRMP noch genug Platz für 
eine kleine serielle Shell und RGB-LED-Anzeige als Status-Feedback.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Patch ist angehängt und ich würde mich über eine Aufnahme ins offizielle
> IRMP-Repo oder Kritik und Verbesserungsvorschläge freuen.

Kann ich gerne machen, danke dafür. Würdest Du dann im IRMP-Artikel 
die Besonderheiten, die Du angesprochen hast, auch dort dokumentieren?

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Kann ich gerne machen, danke dafür.

Danke.

> Würdest Du dann im IRMP-Artikel
> die Besonderheiten, die Du angesprochen hast, auch dort dokumentieren?

Deutscher und englischer Artikel sind angepasst.

Ich hoffe das passt so.

Du müsstest nur noch die Versionsnummer eintragen wenn Du den neuen 
Release machst.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Deutscher und englischer Artikel sind angepasst.

Super, vielen Dank! :-)

> Du müsstest nur noch die Versionsnummer eintragen wenn Du den neuen
> Release machst.

Ich habs gerade eben eingecheckt. Versionsnummer ist nun 3.1.0, passe 
ich an.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ging ja fix. Wenn alle Opensource-Projekte so schnell beim 
Integrieren von Änderungen wären ;)

Frank M. schrieb:
> Ich habs gerade eben eingecheckt. Versionsnummer ist nun 3.1.0, passe
> ich an.

Wenn ich die SVN-Diffs richtig interpretiere, ist noch das 
GREE-Protokoll neu dazugekommen. Das fehlt noch im Changelog & in der 
Dokumentation.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Das ging ja fix. Wenn alle Opensource-Projekte so schnell beim
> Integrieren von Änderungen wären ;)

Du hast ja auch alles sehr gut vorbereitet. Einmal patch aufgerufen und 
das war's. :)

> Wenn ich die SVN-Diffs richtig interpretiere, ist noch das
> GREE-Protokoll neu dazugekommen. Das fehlt noch im Changelog & in der
> Dokumentation.

Stimmt. Das hatte ich komplett vergessen, da ich es irgendwann 
zwischendurch eingebaut habe. Werde ich mir bei Gelegenheit anschauen 
und dann die Dokumentation entsprechend aktualisieren.

Vielen Dank nochmal und Kompliment auch an die exzellente Umsetzung und 
auch an die perfekte Aktalisierung der Doku - auch der englischen!

Ich halte gerade bei OpenSource Software eine gute Dokumentation für 
äußerst wichtig. Leider wird sie oft genug vernachlässigt. Ich war mal 
vor 20 Jahren bei einem Vortrag von Richard Stallman zugegen, der an die 
anwesenden Entwickler appellierte, sie mögen doch genauso viel Zeit in 
die Doku stecken wie in die Entwicklung der Software. Zur Ermunterung 
sagte er: "Documentation doesn't crash!". :)

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Vielen Dank nochmal und Kompliment auch an die exzellente Umsetzung und
> auch an die perfekte Aktalisierung der Doku - auch der englischen!

Danke für die Blumen.

Mich hat jetzt aber noch der Ehrgeiz gepackt und ich wollte den 
ständigen Aufruf des Timer-IRQs in der (Haupt-)Zeit ohne jegliche 
IR-Daten loswerden so daß der µC dann in den Sleepmode gehen kann. Das 
ChibiOS gibt sich extra große Mühe tickless zu arbeiten, und dann kommt 
das IRMP und macht das alles kaputt ;)

Ich möchte dafür aus der irmp_ISR() eine irmp_idle()-Funktion aufrufen 
die von meinem Hauptprogramm gestellt wird. Darin schalte ich dann den 
Timer aus und einen Pinchange-IRQ an. Wenn der Pinchange kommt, wird der 
Timer wieder gestartet und irmp_ISR() aufgerufen.

Funktioniert soweit schon ganz gut, der Stromverbrauch meines kleinen 
Boards mit dem STM32F030F4 und dem IR-Empfänger ist von 15mA auf 9mA im 
Idle runtergegangen.

Allerdings muss ich zugeben daß ich in der Statemachine der irmp_ISR 
noch nicht so ganz durchsteige.

So sieht mein Code am Ende der irmp_ISR jetzt aus:
--- a/irmp.c
+++ b/irmp.c
@@ -5212,6 +5212,23 @@ irmp_ISR (void)
         chEvtSignalI(IRMP_EVENT_THREAD_PTR,IRMP_EVENT_BIT);
 #endif
 
+#if IRMP_USE_IDLE_CALL == 1
+    // check if there is no ongoing transmission or repetition
+    if (!irmp_start_bit_detected &&
+        !irmp_pulse_time &&
+        !irmp_pause_time &&
+        !wait_for_start_space &&
+        key_repetition_len > IRMP_KEY_REPETITION_LEN)
+// TODO: do we need to check irmp_tmp_address, irmp_tmp_command, irmp_bit ??
+// TODO: why is wait_for_space kept set after receiving ir data once and then idle?
+    {
+        // no ongoing transmission
+        // enough time passed since last decoded signal that a repetition won't affect our output
+
+        irmp_idle();
+    }
+#endif // IRMP_USE_IDLE_CALL
+
     return (irmp_ir_detected);
 }

Wie im Kommentar vermerkt ist mir aufgefallen, daß nach dem ich ein 
IR-Telegramm empfangen habe, wait_for_space immer auf 1 stehen bleibt. 
Das hatte ich am Anfang auch immer für die Idle-Bedingung mit abgefragt.

Hat das einen tieferen Sinn oder ist das an der Stelle einfach nicht 
relevant und wird daher nicht zurückgesetzt?

Fange ich mit meiner jetzigen Abfrage wirklich alle Fälle von 
Übertragung und sonstigen relevanten Pause-Zuständen ab? Oder muss ich 
noch weitere Variablen wie z.B. irmp_tmp_address, irmp_tmp_command, 
irmp_bit beachten?

Getestet habe ich nur mit NEC-Codes.

Wäre nett wenn Du da nochmal drüberschauen könntest.

Wenn es passt kann ich das als Patch mit Beispiel & Doku fertig machen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Wie im Kommentar vermerkt ist mir aufgefallen, daß nach dem ich ein
> IR-Telegramm empfangen habe, wait_for_space immer auf 1 stehen bleibt.

Merkwürdig. Eigentlich sieht es so aus:
    if (! irmp_ir_detected)              // ir code already detected?
    {                                    // no...
        if (! irmp_start_bit_detected)   // start bit detected?
        {                                // no...
            ....
        }
        else
        {
            if (wait_for_start_space)    // we have received start bit...
            {                            // ...and are counting the time of darkness
                if (irmp_input)          // still dark?
                {                        // yes
                    ...
                }
                else
                {                        // receiving first data pulse!
                    ...
                    wait_for_start_space = 0;
                }
            }
        }
    }

wait_for_start_space sollte also nach dem Empfang des ersten 
Daten-Pulses wieder auf 0 zurückgesetzt werden.

> Fange ich mit meiner jetzigen Abfrage wirklich alle Fälle von
> Übertragung und sonstigen relevanten Pause-Zuständen ab?

Warum nicht folgende einfache Bedingung?
    if (!irmp_start_bit_detected &&
    {
        irmp_idle();
    }

Dann sollte der µC außerhalb der Zeit, wenn ein Frame übertragen wird, 
schlafen. Reicht das nicht?

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> wait_for_start_space sollte also nach dem Empfang des ersten
> Daten-Pulses wieder auf 0 zurückgesetzt werden.

wird es auch. Ich meinte wait_for_space.

> Warum nicht folgende einfache Bedingung?
>
>     if (!irmp_start_bit_detected &&
>     {
>         irmp_idle();
>     }
> 
>
> Dann sollte der µC außerhalb der Zeit, wenn ein Frame übertragen wird,
> schlafen. Reicht das nicht?

Naja, also zumindest irmp_pulse_time muss ich noch abfragen, da es ganz 
am Anfang erhöht wird, bevor irmp_start_bit_detected überhaupt gesetzt 
wird.

Außerdem wird im Idle dann natürlich auch key_repetition_len nicht mehr 
erhöht, so daß die ganze Wiederholungserkennung kaputt wäre. Den Check 
sollte ich also auch machen.

Die Frage ist halt ob es irgendwelche anderen Zustände geben kann, bei 
denen eine Übertragung läuft oder irgendwie auf eine Wiederholung 
reagiert wird die ich mit diesen Checks noch nicht abgedeckt hätte.

Weil die Funktionsweise für mich eben nicht ganz offensichtlich war, 
habe ich die Kandidaten, die mir relevant aussahen, auch noch mit 
geprüft. Aber es kann dennoch sein daß ich irgendeinen Fall übersehen 
hab, vorallem welche in den protokollspezifischen Defines. Da gibt es ja 
auch noch eigne Repetition-Logik wie z.B. denon_repetition_len.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:

> wird es auch. Ich meinte wait_for_space.

Upps, da habe ich mich verlesen, sorry. Ich habe das gerade mal unter 
Linux getestet: Tatsächlich bleibt das Flag nach dem Einlesen eines 
kompletten Frames gesetzt. Scheint dann aber keine Rolle mehr zu 
spielen, da dann andere Zustandsvariablen greifen. Muss ich mir nochmal 
in Ruhe anschauen bzw. ich müsste mal alle Zustandsvariablen 
dokumentieren.

> Naja, also zumindest irmp_pulse_time muss ich noch abfragen, da es ganz
> am Anfang erhöht wird, bevor irmp_start_bit_detected überhaupt gesetzt
> wird.

Stimmt, irmp_start_bit_detected wird natürlich erst nach dem Empfang des 
Start-Bits gesetzt. Das war von mir zu kurz gedacht.

Ich habe eben mal unter Linux folgendes im Source testweise eingesetzt:
Alt:
#ifdef ANALYZE
    time_counter++;
#endif // ANALYZE

Neu:
#ifdef ANALYZE
    static uint_fast8_t     last_irmp_start_bit_detected = 0xFF;
    static uint_fast8_t     last_irmp_pulse_time = 0xFF;

    if (last_irmp_start_bit_detected != irmp_start_bit_detected || last_irmp_pulse_time != irmp_pulse_time)
    {
        last_irmp_start_bit_detected    = irmp_start_bit_detected;
        last_irmp_pulse_time            = irmp_pulse_time;

        printf ("%d %d %d\n", time_counter, irmp_start_bit_detected, irmp_pulse_time);
    }

    time_counter++;
#endif // ANALYZE

Dann kann man mit
    ./irmp-10kHz < IR-Data/nec.txt

schön beobachten, wie sich die Zustandsvariablen ändern. Eine von beiden 
ist während des Empfangs eines IR-Frames immer gesetzt - auch bei den 
Repetition-Frames.

Damit sollte diese Bedingung ausreichen:
    if (!irmp_start_bit_detected && !irmp_pulse_time)
    {
        irmp_idle();
    }

Mit
    ./irmp-15kHz < IR-Data/denon-rc-176-repeat-15kHz.txt

sieht man auch, dass es für die sehr speziellen Denon-Repetition-Frames 
einwandfrei klappt.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> ich müsste mal alle Zustandsvariablen
> dokumentieren.

Du warst der, der oben Stallman zum Thema Dokumentation zitierte ;)

> Damit sollte diese Bedingung ausreichen:
>
>     if (!irmp_start_bit_detected && !irmp_pulse_time)
>     {
>         irmp_idle();
>     }
> 

Danke für den Testcode und die Analyse. Ich stimme Dir zu....

...bis auf die Prüfung von key_repetition_len.

Wenn ich diesen Code verwende:
    if (!irmp_start_bit_detected && !irmp_pulse_time
        && key_repetition_len > IRMP_KEY_REPETITION_LEN)
    {
        irmp_idle();
    }
funktioniert alles wie gewünscht. Wenn ich 2x die selbe Taste kurz 
hintereinander drücke, wird das IRMP_FLAG_REPETITION-Bit gesetzt. Mache 
ich das mit längerem Zeitabstand, wird es nicht mehr gesetzt.

Ohne die Prüfung von key_repetition_len wird das 
IRMP_FLAG_REPETITION-Bit immer gesetzt, egal was für ein Zeitabstand 
zwischen den Tastendrücken liegt.

Ist auch klar wenn man sich den Code anschaut:
if (irmp_ir_detected)
{
    if (last_irmp_command == irmp_tmp_command &&
        last_irmp_address == irmp_tmp_address &&
        key_repetition_len < IRMP_KEY_REPETITION_LEN)
    {
        irmp_flags |= IRMP_FLAG_REPETITION;
    }
Wenn hier das key_repetition_len wegen des Sleepmode nicht mehr 
hochgezählt wird, ist die Bedingung halt immer wahr.

Ich denke also die Prüfung auf key_repetition_len > 
IRMP_KEY_REPETITION_LEN ist notwendig.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Wenn hier das key_repetition_len wegen des Sleepmode nicht mehr
> hochgezählt wird, ist die Bedingung halt immer wahr.

Ja, das ist natürlich richtig. Diese Situation ist zur Zeit nicht 
simulierbar, da der Simulator sich zwischen den Frames nicht schlafen 
legt.

> Ich denke also die Prüfung auf key_repetition_len >
> IRMP_KEY_REPETITION_LEN ist notwendig.

Korrekt.

: Bearbeitet durch Moderator
Autor: Gerd E. (robberknight)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok, der Patch mit dem IRMP_USE_IDLE_CALL ist anbei.

Wenn das soweit passt, kann ich das auch wieder im IRMP-Artikel 
dokumentieren.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Wenn das soweit passt, kann ich das auch wieder im IRMP-Artikel
> dokumentieren.

Passt und ist online als 3.1.1 :-)

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Passt und ist online als 3.1.1 :-)

Danke. Die Artikel sind jetzt auch angepasst.

(OT: falls Du das noch nicht kennst: die Übersetzung ins Englische hab 
ich https://www.deepl.com machen lassen. Bis auf ein paar kleine 
Anpassungen bei den Formulierungen kommt der Text direkt aus der 
maschinellen Übersetzung. Ich finde das ist Welten besser als Google 
Translator und Konsorten und schon echt brauchbar so.)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche 
Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht 
IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?

Das war jetzt in nem nicht so oft besetzten Labor so wo die Lampen noch 
nicht durch LED ausgetauscht wurden.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Danke. Die Artikel sind jetzt auch angepasst.

Prima, danke.

> (OT: falls Du das noch nicht kennst: die Übersetzung ins Englische hab
> ich https://www.deepl.com machen lassen.

Kannte ich noch nicht. Aber ein paar kurze Stichprobentests haben mich 
überzeugt. Der ist schon verdammt gut... Lesezeichen gesetzt :-)

Autor: Conny G. (conny_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche
> Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht
> IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?
>
> Das war jetzt in nem nicht so oft besetzten Labor so wo die Lampen noch
> nicht durch LED ausgetauscht wurden.

Ähnliches hab ich früher schon gelesen.
Auf die Schnelle ("neonlicht stört ir fernbedienung") z.B. das hier 
gefunden:

https://www.tt-board.de/forum/threads/leuchtstoffroehre-vs-infrarot.46583/

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche
> Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht
> IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?

Ja, das ist allgemein bekannt.

Bei IRMP können solche gestörten IR-Frames ziemlich gut aussortiert 
werden, da hier die Pulse nicht nur stumpfsinnig aufgezeichnet werden, 
sondern immer erst das Protokoll ermittelt und dann sämtliche 
Pulse/Pausen auf Plausibilität geprüft werden.

Dabei werden on-the-fly bzw. abschließend folgende Regeln geprüft:

1. Sind die Puls-/Pause-Zeiten innerhalb der für das Protokoll
   definierten Toleranzen?

Das gilt für jedes Protokoll.

2. Sind CRCs/Parity-Bits im Protokoll enthalten?

Wenn ja, stimmen diese mit den empfangenen Daten überein?

Beispiele:

Kaseikyo (Japan) Protokoll: 4 + 8 Parity Bits
LEGO: 4 Bits CRC

3. Sind Redundanzen im Frame enthalten?

Wenn ja, stimmen diese (nach eventueller Transformation) überein?

Beispiele NEC, SAMSUNG und BOSE:

Daten liegen sowohl als nicht-invertierte als auch als invertierte
Bits in demselben Frame vor.

4. Werden die IR-Frames mit n-facher Wiederholung gesandt?

Wenn ja, stimmen die Frames vom Inhalt auch überein?

Beispiele:

DENON: im 2. Frame ist das Kommando invertiert.
SAMSUNG48: der 1. Frame wird immer ein zweites Mal wiederholt.
KASEIKYO: der 1. Frame wird optional innerhalb 50ms wiederholt
SONY (SIRCS): der 1. Frame wird optional innerhalb 50ms wiederholt

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias F. schrieb:
> Hal


Habe die STM32 HAL Implementierung soweit getestet. Frank hast kannst du 
die Erweiterung von Matthias F. aus Beitrag #5328596 noch übernehmen?

Gruß
Stephan

Autor: Jonas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
Habe die STM32 HAL Implementierung soweit getestet.


technikus eine Frage an Sie oder an jemanden, der es geschafft hat. Ich 
habe versucht, ein Projekt STM32 mit HAL auszuführen, aber es 
funktioniert nicht. Es ist möglich, dass ich etwas falsch mache. Obwohl 
es keine Fehler gibt. Können Sie mir Ihre Projektumsetzung per E-Mail 
schicken (jonkul001@utp.edu.pl)?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Frank hast kannst du
> die Erweiterung von Matthias F. aus Beitrag #5328596 noch übernehmen?

Die habe ich aus irgendwelchen Gründen übersehen/vergessen. Hole ich 
nach.

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super!
Danke

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Frank hast kannst du die Erweiterung von Matthias F. aus Beitrag
> #5328596 noch übernehmen?

Die Änderungen sind nun online, die Doku wurde angepasst.

Viel Spaß,

Frank

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas,

beschreib doch mal dein Problem.
Bekommst du Fehler beim Compilieren?
Im Grunde wird irmp ja nur initialisiert und in der Timer ISR 
aufgerufen.
Die ISR Frequenz ist sehr wichtig. Bei STM32 ist die richtige Clock 
Config wichtig.
Ich toggle immer erst eine LED in der ISR und prüfe mit dem Oszilloskop 
die Frequenz...

Gruß
Stephan

Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

gerne möchte ich mir eine T+A Fernbedienung zulegen um mein DIY 
Vorverstärker zu steuern. Deshalb habe den Hersteller angefragt welches 
Protokoll implementiert ist.
Hier die Antwort:
RC2
Habe das Dokument vom Hersteller hier hochgeladen
https://filehorst.de/d/cFypmGgi

Ist es denkbar das Protokoll anhand dieser Daten in irmp zu 
implementiern?
Dann würde ich mir das Teil bestellen.

Danke und Gruß
Stephan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> Ist es denkbar das Protokoll anhand dieser Daten in irmp zu
> implementiern?

Ja. Das ist einfacher Manchester Code ("bi-phase"). Allerdings gibt es 
als Besonderheit noch dieses Pre-Bit vor dem eigentlichen Start-Bit. Ich 
würde es als Protokoll mit 2 unterschiedlichen Start-Bits 
implementieren.

Reicht die Protokoll-Erkennung (IRMP) oder soll auch gesendet werden 
(IRSND)?

Noch eines: Die 31,25 kHz Modulationsfrequenz sind etwas ungewöhnlich. 
Ich würde dafür nicht unbedingt einen TSOP nehmen, der auf 38kHz 
abgestimmt ist, sondern eher einen für 30kHz, wie den TSOP31230. Oder 
den TSOP31233 für 33kHz.

: Bearbeitet durch Moderator
Autor: technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Reicht die Protokoll-Erkennung (IRMP)

Danke für die schnelle Antwort!
IRMP, also Empfang würde reichen.

Gruß
Stephan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
technikus schrieb:
> IRMP, also Empfang würde reichen.

Die Version 3.1.3 ist online.

Neuerung:

 - Neues Protokoll: RC II (T+A)

Den IRMP-Artikel habe ich ebenso aktualisiert. Dank der sehr guten 
Dokumentation zu diesem Protokoll konnte ich die Erkennung des 
Protokolls zügig umsetzen. Zum Testen habe ich eine Scan-Datei 
IR-Data/rcii-15kHz.txt mit dem Editor erstellt, welche alle Codes der FB 
berücksichtigt. Es könnte noch sein, dass man noch etwas an den 
Toleranzen schrauben muss. Das wird sich dann herausstellen, sobald die 
Fernbedienung mit IRMP gestestet werden kann.

Viel Spaß,

Frank

: Bearbeitet durch Moderator
Autor: Technikus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke dir!
Ich werde mir den Geber besorgen und testen.

Gruß

Autor: Stefan O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade IRMP so zu erweitern, dass er das Merlin-Protokoll 
vollständig und Fehlerfrei unterstützt, im Moment wird nur ein Teil 
fehlerhaft unterstützt.

Die Herausforderung ist, dass es eine variable Länge hat und Manchester 
kodiert ist. Das Dunkel am Ende kann, muss aber nicht, Teil des letzten 
Bits sein:

Beispiel für Taste loslassen:
Start-Bits: 10
Adresse:    00000001
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1111...


Beispiel für die Taste A:
Start-Bits: 10
Adresse:    00000001
Kommando:   00000100
End-Bit:    1
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1010101010011010|01|1111...

Beispiel für die Taste B:
Start-Bits: 10
Adresse:    00000001
Kommando:   00000101
End-Bit:    0
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1010101010011001|10|1111...

Wie man aus den Trennstrichen sieht, ist das letzte Bit z.T. im 
Endbereich wo es nicht mehr hell wird.

Die Anzahl der Kommando-Bytes kann zwischen 0 und 4 liegen, wenn ein 
Kommando-Byte kommt, dann kommt auch ein End-Bit am Schluss des Frames 
welches immer das Inverse des Bits davor ist.

Ich habe schon etwas rumgebastelt, aber ich bekomme es nicht hin, das 
alles geht, entweder 01 am Ende geht oder 10.
Die Kommando-Länge habe ich bereits auf 32 Bit geändert wenn Merlin 
aktiviert ist, dazu kommt noch ein Feld was dann die Kommando-Länge 
enthalten soll.
Ich verstehe auch noch nicht alles in dem Code, vielleicht kann mir 
jemand helfen das einzubauen. Im Idealfall würde es auch das offizielle 
IRMP übernommen, aber es erfordert halt eine Erweiterung der API.

Vielen Dank
Stefan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Ich verstehe auch noch nicht alles in dem Code, vielleicht kann mir
> jemand helfen das einzubauen.

Kannst Du Scans mittels IRMP_LOGGING erstellen und diese dann hier zur 
Verfügung stellen? Das wäre das einfachste für mich.

Autor: Stefan Z. (stefan_z)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstaunlich, dass es immer noch Protokolle gibt, die nicht in IRMP 
integriert sind :-)

Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library 
zu integrieren, so dass man es einfach über die IDE aktuelle halten und 
auf allen µC nutzen kann? Ich frage für nen Freund… hust

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Z. schrieb:
> Erstaunlich, dass es immer noch Protokolle gibt, die nicht in IRMP
> integriert sind :-)

Doch, das Merlin-Protokoll, um welches es geht, ist bereits integriert. 
Aber offenbar ist die Integration unvollständig, ich kann halt nur das 
umsetzen, was man mir als Stoff (in Form von Scans) liefert. Denn ich 
kann nicht alle Fernbedienungen der Welt vorrätig haben. Außerdem weiß 
ich aus Erfahrung, dass es zu vielen Protokollen etliche 
herstellerspezifische "Erweiterungen" gibt. Wahrscheinlich ist dies hier 
auch der Fall.

> Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library
> zu integrieren, so dass man es einfach über die IDE aktuelle halten und
> auf allen µC nutzen kann? Ich frage für nen Freund… hust

Klar, mach. ;-)

Das Arduino-Problem ist wohl folgendes: IRMP braucht einen 
Timer-Interrupt. Da kann man unter Arduino wohl nicht jeden x-beliebigen 
Timer nehmen, weil das Arduino-Runtime-System bereits einen für sich 
reserviert - jedenfalls bei AVR. Wie das bei anderen µC-Familien ist, 
entzieht sich meiner Kenntnis.

Es gibt bereits Portierungen von IRMP für Arduino, einfach mal im 
IRMP-Artikel nach Arduino suchen. Diese Ports wurden aber wohl immer 
nur für einen speziellen µC durchgeführt und niemals so allgemein 
formuliert, wie es der IRMP-Source generell ist. Zudem kann ich über die 
Qualität der jeweiligen Portierung nichts sagen.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Z. schrieb:
> Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library
> zu integrieren,

das habe ich mit einer älteren Version von IRMP schon geschafft (ist ja 
"nur" C), einfach einen arduinofreien Timer wählen, ABER die letzten 
IRMP waren so monster groß das die IDE überlastet wurde.

: Bearbeitet durch User
Autor: Stefan Z. (stefan_z)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Klar, mach. ;-)

Ich bin mir nicht sicher, ob das zielführend wäre.
Ich habe vor Jahren mal eine IRMP Version auf Arduino umgebastelt, die 
nutze ich auch noch, aber sauber war das nicht zu 100%.

Arduino ist ja eh an so vielen Stellen total bekloppt.
Die seltsame Board-From die keinen Sinn ergibt.
Die Abstände der Pinleisten.
Die Platzierung der Bohrlöcher.

IRMP kann man aber schon auf andere Timer umbiegen, vor allem weil 
Arduino doch nur T0 für Millis u.Ä. nutzt:
"The standard Arduino has 3 timers, timer0 is 8 bit and used for the 
millis() and micros() functions. Timer1 is 16 bit and not used by 
default, timer2 is another 8 bit timer like timer0 but not used by 
default."
http://sphinx.mythic-beasts.com/~markt/ATmega-timers.html

Es hatte mich nur gewundert, weil IRMP ja schon sehr 
"Scheckheftgepflegt" ist und super sauber implementiert.
Vielleicht sehe ich es mal als persönliches Lern-Projekt, aber das ist 
schon einschüchternd viel was man wissen muss, um auf dem Level dann die 
Integration in Arduino zu machen.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Z. schrieb:
> Die seltsame Board-From die keinen Sinn ergibt.
> Die Abstände der Pinleisten.

ergibt schon Sinn, bastelsicher verdrehsicher für Shields!

auch wenns uns nicht gefällt für Lochrasteraufbauten, ich hatte einfach 
etwas Lochraster um 1,27mm verschoben eingesetzt.

Autor: Stefan Z. (stefan_z)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Stefan Z. schrieb:
>> Die seltsame Board-From die keinen Sinn ergibt.
>> Die Abstände der Pinleisten.
>
> ergibt schon Sinn, bastelsicher verdrehsicher für Shields!

Gut, da hätte man auch einfach asymmetrisch arbeiten können (was de 
fakto eh so ist, nur dass zusätzlich noch schief verschoben wird in alle 
Dimensionen), oder einen Elko so platziert, dass es physisch unmöglich 
wäre zu verpolen.

Ist halt ein Standard der leicht "bitter" schmeckt.
Von dem delay() im ersten Hallo Welt mal ganz abgesehen…

Autor: Stefan O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vielen Dank für die schnelle Reaktion.
Ich habe es jetzt geschafft es zu implementieren: Das Problem war, dass 
sich die Toleranzgrenzen überlappen und ein kurzer auch als langer 
erkannt wurde (aber nicht andersherum) und man daher zwingend erst auf 
kurz prüfen müssen.

Da das Protokoll vorher nicht richtig implementiert war (Adresse wurde 
falsch erkannt, war im Manchester-Code verschoben, Kommandos erhielten 
ein zusätzliches Bit am Anfang), ist es nicht kompatibel mit der 
vorherigen Implementierung, da sich Adresse als auch Kommandos 
unterscheiden.
Es werden jetzt Kommandos bis 4 Byte erkannt (länger geht mit der 
Tastatur nicht), erkannt und das Prüfbit wird überprüft.

Zur Implementierung:
-Wenn Merlin aktiviert ist, wird die Kommando-Länge auf 32 Bit gesetzt 
und es gibt das Feld cmdlen in IRMP_DATA (leider sind die aktivierten 
Protokolle nicht in der irmpsystem.h verfügbar, daher hab ich das da 
nochmal definiert, sehr unschön).

-Wenn er Merlin erkannt hat und eine Pause kommt die länger ist als eine 
lange Pause, setzt er die Frame-Länge auf die aktuelle Länge und setzt 
"got_light".

-Wenn er in dann in dem if(got_light) ist und die aktuelle Länge den 
Frame-Länge entspricht, baut er basierend auf der letzten 
Pausen/Pulslänge und Zustand die letzten ein bis zwei Bits (da die Pause 
dazugehören kann aber nicht muss ist das der schwierige Teil)

-In irmp_get_data prüft er dann die korrekte Länge (entweder 10 oder 
11+n*8) und das letzte Bit und setzt die Länge des Kommandos in Byte (0 
bis 4).

-Da nach der Adresse noch 33 Bit folgen können wegen dem Prüfbit, habe 
ich die Adresse auf 9 Bit definiert, nachdem das letzte Bit überprüft 
wurde wird in irmp_get_data das Bit von der Adresse ins Kommando 
geschoben.

-Da die Erkennung ob Merlin in keinster Weise geändert wurde und auch in 
keinem nicht-Merlin spezifischen Teil was geändert ist (außer das 
Kommando jetzt 32 Bit), sollte kein anderes Protokoll irgendwie 
beeinflusst werden.

-Die Menge an Programmspeicher, welcher benötigt wird wächst von ~300 
Byte auf ~1200 Byte.

Ich würde mich freuen, wenn das in das offizielle IRMP übernommen werden 
kann.
Das mit dem IR Logging klappt nicht richtig bei mir, die serielle 
Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder 
nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer 
bei 20kHz aufnehmen, sollte dann doch das gleiche sein?

Vielen Dank
Stefan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Ich habe es jetzt geschafft es zu implementieren: Das Problem war, dass
> sich die Toleranzgrenzen überlappen und ein kurzer auch als langer
> erkannt wurde (aber nicht andersherum) und man daher zwingend erst auf
> kurz prüfen müssen.

Die Reihenfolge der Prüfung sollte hier nicht maßgeblich sein, vielmehr 
sollte man dafür sorgen, dass sich die Toleranzgrenzen nicht überlappen.

> Da das Protokoll vorher nicht richtig implementiert war

Bist Du Dir sicher, dass wir hier von demselben Protokoll sprechen?

MERLIN bezieht sich auf die Pollin-FB 
https://www.pollin.de/p/infrarot-fernbedienung-merlin-620185 (Artikelnr. 
620 185). Es gibt unter IR-Data eine Datei merlin-15kHz.txt, die über 
die Test-Suite (siehe test-suite.sh) auf Reproduzierbarkeit getestet 
wird.

> (Adresse wurde
> falsch erkannt, war im Manchester-Code verschoben, Kommandos erhielten
> ein zusätzliches Bit am Anfang),

Das hört sich nach einer ganz anderen FB an. Wenn dem so ist, dann 
sollte dem Protokoll Deiner FB auch ein anderer Name gegeben werden. Um 
was handelt es sich? Ich lese bei Dir "Tastatur", geht es hier um eine 
IR-Tastatur für den PC?

> Es werden jetzt Kommandos bis 4 Byte erkannt (länger geht mit der
> Tastatur nicht), erkannt und das Prüfbit wird überprüft.

Ja, die Tatsache, dass in IRMP sowohl Adresse als auch Kommando auf 16 
Bit beschränkt sind, hat mich später schon gestört, weil es durchaus 
auch Protokolle gibt, welche mehr Bits verwenden. Trotzdem konnte ich 
meist Redundanzen (CRCs, Parity-Bits und Wiederholungen) erkennen, 
welche dann besser lediglich geprüft, aber nicht in command oder 
address mit abgespeichert wurden. Zur Reproduzierung des Original-Frames 
werden dann in IRSND die notwendigen Bytes wieder neu berechnet und in 
den zu sendenden Frame wieder eingeführt.

Bist Du Dir da sicher, dass mehr als 16 Bit an reiner Information 
notwendig sind? Durch die Verwendung von mehr als 16 Bits wird IRMP zu 
einer größeren Reihe an real existierenden Anwendungen inkompatibel - 
siehe Abschnitt

  https://www.mikrocontroller.net/articles/IRMP#Hardware_.2F_IRMP-Projekte

Hier wird meist die Struct über UART oder USB als feste Größe 
verschickt. Durch Deine Änderungen

   1. Erweiterung der Struct um Variable cmdlen
   2. Erweiterung des Typs von command auf 32 Bit

laufen viele dieser Anwendungen ohne Anpassung nicht mehr.

Ich habe schon öfters überlegt, address und command auf 32 Bits zu 
erweitern, um es mir bei manchen Protokollen leichter zu machen, aber 
immer wieder diese Änderung verworfen, nämlich aus dem einfachen Grund, 
dass die 8-Bit-AVRs bei 32Bit-Variablen-Operationen (wie z.B. Shifts 
etc) grottenlangsam werden und so etwas in einer ISR tödlich ist.

Frage: Welchen µC setzt Du hier konkret ein? Hast Du es mit einem AVR-µC 
getestet?

Ich kann mir durchaus vorstellen, ab Version 4.0 einen Schnitt zu machen 
und address und command generell auf 32-Bit zu erweitern (bei 
Verzicht(!) auf cmdlen). Vorher muss aber greprüft werden, ob die 
8-Bit-AVRs da noch mithalten können und bei welcher Taktfrequenz.

> Zur Implementierung:
> -Wenn Merlin aktiviert ist, wird die Kommando-Länge auf 32 Bit gesetzt
> und es gibt das Feld cmdlen in IRMP_DATA (leider sind die aktivierten
> Protokolle nicht in der irmpsystem.h verfügbar, daher hab ich das da
> nochmal definiert, sehr unschön).

Das mit der Nochmal-Definition in irmpsystem.h ist ein NoGo, das müsste 
anders gelöst werden, z.B. durch generelles Arbeiten mit 32-Bit, siehe 
oben. Ich könnte mir auch vorstellen, lediglich bei den 32-Bit-µCs auf 
32 Bit zu gehen. Dann bleiben die AVRs halt bei 16 Bit und unterstützen 
Dein "Merlin-Protokoll" nicht.

> -Wenn er Merlin erkannt hat und eine Pause kommt die länger ist als eine
> lange Pause, setzt er die Frame-Länge auf die aktuelle Länge und setzt
> "got_light".

Hm, sehr speziell. Besser wäre eine Anpassung der Toleranzen, so dass 
sich diese "in beiden Richtungen" nicht mehr überschneiden.

> -In irmp_get_data prüft er dann die korrekte Länge (entweder 10 oder
> 11+n*8) und das letzte Bit und setzt die Länge des Kommandos in Byte (0
> bis 4).

Bist Du Dir da sicher mit den variablen Bitlängen? Hast Du da irgendeine 
Dokumentation zu Deiner Tastatur?

> -Da die Erkennung ob Merlin in keinster Weise geändert wurde und auch in
> keinem nicht-Merlin spezifischen Teil was geändert ist (außer das
> Kommando jetzt 32 Bit), sollte kein anderes Protokoll irgendwie
> beeinflusst werden.

Mir scheint, dass IRMP bei Deiner FB fälschlicherweise wegen der 
Start-Bits auf MERLIN springt, das Protokoll aber hier ein ganz anderes 
ist. Wie gesagt, MERLIN steckt hier in der Test-Suite und ist daher 
ziemlich gesichert, was die Erkennung betrifft.

> -Die Menge an Programmspeicher, welcher benötigt wird wächst von ~300
> Byte auf ~1200 Byte.

Hui, das ist eine Menge Holz. Naja, kommt auf den Prozessor an. Außerdem 
habe ich gesehen, dass Du F_INTERRUPTS auf 20000 gesetzt hast. Ist das 
für Dein "Merlin" so notwendig?

> Ich würde mich freuen, wenn das in das offizielle IRMP übernommen werden
> kann.

Sorry, in dieser Form bestimmt nicht, das fängt mit der inkompatiblen 
Änderung von IRMP_DATA an und hört auch nicht mit mit dem festen #define 
von IRMP_SUPPORT_MERLIN_PROTOCOL an der falschen Stelle auf. Als 
allererstes wäre überhaupt zu klären, ob wir beide überhaupt dasselbe 
"Merlin-Protokoll" meinen.

Hast Du mal nach Deinen Änderungen die Test-Suite aufgerufen, um zu 
prüfen, ob noch alles so läuft wie vorher?

> Das mit dem IR Logging klappt nicht richtig bei mir, die serielle
> Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder
> nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer
> bei 20kHz aufnehmen, sollte dann doch das gleiche sein?

Wenn Du den Logic-Analyzer-Output wieder ins IRMP-Loggin-Format 
zurückübersetzt, damit man unter Linux mit "irmp -a" im Analyzer-Modus 
das Protokoll näher analysieren kann, dann ja ;-)

Gruß,

Frank

: Bearbeitet durch Moderator
Autor: Stefan Z. (stefan_z)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Das mit dem IR Logging klappt nicht richtig bei mir, die serielle
> Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder
> nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer
> bei 20kHz aufnehmen, sollte dann doch das gleiche sein?

20kHz ist aber zu wenig bei einem 36kHz Empfänger.
Aber Rohdaten vom TSOP abzugreifen sollte ja mit 10 Zeilen Code und 
einem Arduino auch einfach sein, wobei die Logging Funktion von IRMP für 
mich früher immer gut funktionierte…

Autor: Stefan O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Reihenfolge der Prüfung sollte hier nicht maßgeblich sein, vielmehr
> sollte man dafür sorgen, dass sich die Toleranzgrenzen nicht überlappen.
Ich habe die Toleranzen auf 10% reduziert, geht immer noch problemlos.
Es könnte sein, dass die Toleranzgrenzen so groß gewählt (30%) waren 
damit der Fehler in der Implementierung ausgeglichen wird.

> Bist Du Dir sicher, dass wir hier von demselben Protokoll sprechen?
Sicher bin ich mir nicht, da ich die Fernbedienung dort nicht besitze, 
sondern diese Tastatur: 
https://www.mikrocontroller.net/articles/IR-Tastatur_Merlin_Ruwido
Das Protokoll SIEMENS_OR_RUWIDO erkennt gar nichts, MERLIN erkennt in 
seinem derzeitigen Zustand einzelne Tastendrücke inkorrekt, aber 
reproduzierbar.

> MERLIN bezieht sich auf die Pollin-FB
> https://www.pollin.de/p/infrarot-fernbedienung-merlin-620185 (Artikelnr.
> 620 185). Es gibt unter IR-Data eine Datei merlin-15kHz.txt, die über
> die Test-Suite (siehe test-suite.sh) auf Reproduzierbarkeit getestet
> wird.
Test-Suite läuft problemlos, auch merlin-15kHz.txt wird korrekt erkannt 
(das ist genau das Protokoll das ich meine, meine Tastatur gibt exakt 
solche Werte aus!), jedoch sind die Soll-Werte falsch:
Adresse muss 0x0001 sein und statt 0x0122 muss es 0x0022 sein etc. Das 
meinte ich damit als ich schrieb, es ist inkompatibel zur vorherigen 
fehlerhaften Implementierung. Argument warum vorher falsch und jetzt 
richtig folgt im nächsten Absatz.

> Bist Du Dir da sicher, dass mehr als 16 Bit an reiner Information
> notwendig sind? Durch die Verwendung von mehr als 16 Bits wird IRMP zu
> einer größeren Reihe an real existierenden Anwendungen inkompatibel

Ja, definitiv: Es können mehrere Tasten gleichzeitig gedrückt werden 
(bis zu 4) und die Tastatur überträgt dann genau die 4 8-Bit Codes der 
Tasten direkt hintereinander (32 Bit). Dies ist absolut konsistent und 
die Codes entsprechen für alle Standard-Tasten exakt den USB HID Codes. 
Daher bin ich mir auch so sicher, dass die Erkennung vorher falsch war, 
weil wie ich es jetzt habe ist es konsistent.

> Frage: Welchen µC setzt Du hier konkret ein? Hast Du es mit einem AVR-µC
> getestet?
Ein ATmega644P mit 18,432 MHz. Es soll später auf einem ATmega32U2 bei 
16MHz laufen (warte noch auf die Leiterplatte, wird wohl Ende November 
bis ich das testen kann)

> Hm, sehr speziell. Besser wäre eine Anpassung der Toleranzen, so dass
> sich diese "in beiden Richtungen" nicht mehr überschneiden.

Hier das Problem (ausgabe von irmp-15khz):
protocol = MERLIN, start bit timings: pulse:   2 -   4, pause:   5 -   8
pulse:   1 -   5 or   2 -  10
pause:   1 -   5 or   2 -  10

Problem scheint zu sein, dass die Werte einfach verdoppelt werden, was 
exakt korrekt wäre, aber bei den auf- und abgerundeten Werten halt zu 
sowas führt.


> Mir scheint, dass IRMP bei Deiner FB fälschlicherweise wegen der
> Start-Bits auf MERLIN springt, das Protokoll aber hier ein ganz anderes
> ist. Wie gesagt, MERLIN steckt hier in der Test-Suite und ist daher
> ziemlich gesichert, was die Erkennung betrifft.
Nein, defintiv nicht. Mit der vorherigen Implementierung kann ich 
einzelne Tastendrücke empfangen, die genau wie in der Testdatei 
aussehen. Nur die Erkennung vorher war meiner Ansicht nach mit den oben 
genannten Gründen falsch.

> Hui, das ist eine Menge Holz. Naja, kommt auf den Prozessor an. Außerdem
> habe ich gesehen, dass Du F_INTERRUPTS auf 20000 gesetzt hast. Ist das
> für Dein "Merlin" so notwendig?
Ja, für die letzten Bits ist es etwas speziell, daher wohl. 15kHz geht 
auch, ist aber an der Grenze (kurzer Puls darf 1 lang sein).

> Das mit der Nochmal-Definition in irmpsystem.h ist ein NoGo, das müsste
> anders gelöst werden, z.B. durch generelles Arbeiten mit 32-Bit, siehe
> oben. Ich könnte mir auch vorstellen, lediglich bei den 32-Bit-µCs auf
> 32 Bit zu gehen. Dann bleiben die AVRs halt bei 16 Bit und unterstützen
> Dein "Merlin-Protokoll" nicht.

Ja, das mit der irmpsystem.h ist klar, war nur zum testen, wäre das so 
übernommen worden hätte ich mich arg gewundert.

Mein Vorschlag:
Statt auf 32 Bit zu gehen wenn Merlin aktiviert ist, eine Option mit der 
man 32 Bit einschaltet. Dann kann man beim Kompilieren selber 
entscheiden unabhängig vom Protokoll. Für cmdlen genauso, wenn man es 
nicht aktiviert bleibt es ABI-kompatibel zu vorherigen Version.

> 20kHz ist aber zu wenig bei einem 36kHz Empfänger.
> Aber Rohdaten vom TSOP abzugreifen sollte ja mit 10 Zeilen Code und
> einem Arduino auch einfach sein, wobei die Logging Funktion von IRMP für
> mich früher immer gut funktionierte…

Der Empfänger ist sogar 56 KHz, aber das Protokoll reizt das zum Glück 
nicht aus.

Ich werde sonst gleich mal eine Testdatei basteln mit Kommandos der 
Tastatur.


Nochmal was ganz anderes:
Da mein Projekt auch IR Befehle wieder senden können soll (vom HTPC zu 
Fernseher etc.) habe ich mal eben meine Fernbedienungen untersucht. Ich 
habe einen alten Metz TV, da wird nichts erkannt. Es scheint ein 
Pulse-Distance-Protokoll zu sein:

Start: 866µs Pulse / 2300µs Pause
Bit A: 433µs Pulse /  956µs Pause
Bit B: 433µs Pulse / 1648µs Pause

Irgendeine Idee was das ist?

Viele Grüße
Stefan

Autor: Stefan O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe die zu erwartenden Werte in der merlin-15kHz-correct.txt 
angepasst und eine weitere Test-Datei für die Tastatur angelegt, welche 
Kommandos von 0, 1 und 2 Byte Länge überprüft (für 3 und 4 Byte müsste 
das Testprogramm wohl angepasst werden).

Noch eine Bestätigung das ich das selbe Merlin-Protokoll meine: In der 
Testdatei merlin-15kHz.txt sind die Kommandos für die Ziffern 1 bis 0 
(10?), die sind genau wie bei meiner Tastatur. Vorher stand da 0x011e 
bis 0x0127, USB HID codes für die Ziffern 1,2, ... bis 0 sind 0x1e bis 
0x27, die werden jetzt auch erkannt.

Wenn man sich Merlin vorher anschaut machen schon die Werte im Header 
für Adresse- und Kommandoposition bzw. -länge keinen Sinn (sie 
überlappen sich), dazu kommt in dem Kommentar steht was anderes als im 
define direkt davor.

Ich bin mir doch sehr sehr sicher das ich es richtig habe und es vorher 
falsch implementiert war.

Natürlich bricht die neue Implementierung die Kompatibilität, 
möglicherweise kann man das auch wieder mit defines Regeln, man muss 
zusätzlich zu
IRMP_SUPPORT_MERLIN_PROTOCOL noch 
IRMP_MERLIN_PROTOCOL_OLD_IMPLEMENTATION oder 
IRMP_MERLIN_PROTOCOL_NEW_IMPLEMENTATION definieren (ich würde kein 
default setzen, damit man sich beim Kompilieren überlegen muss was man 
möchte).

> wobei die Logging Funktion von IRMP für
> mich früher immer gut funktionierte…
Da ist jetzt vielleicht die Grenze vom AVR erreicht weil ich 32 Bit und 
20 kHz aktiviert habe...

Nochwas: Ich verwende avr-gcc 8.2 als Kompiler (habe ich selber 
kompiliert weil ich einen AVR dieser neuen tiny1-Serie verwendet habe 
und die erst ab 8 unterstützt werden). Möglicherweise gab es mal 
Optimierungen das 32-Bit jetzt schneller läuft, soweit ich weiß habe ich 
da mal was gelesen, weiß aber gerade nicht bei welcher Version das war.

Viele Grüße
Stefan

Autor: Stefan O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten, hab 
keine Ahnung ob es noch woanders genutzt wird, die Aufteilung 
Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach 
Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich. 
Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt 
aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen 
großen Bereich verteilt zu sein:

irmpprotocols.h:
/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * METZ:
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#define METZ_START_BIT_PULSE_TIME                870.0e-6                       //  870 usec pulse
#define METZ_START_BIT_PAUSE_TIME               2300.0e-6                       // 2300 usec pause
#define METZ_PULSE_TIME                          435.0e-6                       //  435 usec pulse
#define METZ_1_PAUSE_TIME                       1680.0e-6                       // 1680 usec pause
#define METZ_0_PAUSE_TIME                        960.0e-6                       //  960 usec pause
#define METZ_FRAME_REPEAT_PAUSE_TIME             122.0e-3                       // frame repeat after 122ms
#define METZ_ADDRESS_OFFSET                      1                              // skip 1 bit (toggle bit)
#define METZ_ADDRESS_LEN                         6                              // read 6 address bits
#define METZ_COMMAND_OFFSET                      7                              // skip 7 bits
#define METZ_COMMAND_LEN                        12                              // read 12 bits
#define METZ_COMPLETE_DATA_LEN                  19                              // complete length
#define METZ_STOP_BIT                            0                              // has no stop bit
#define METZ_LSB                                 0                              // MSB...LSB
#define METZ_FLAGS                               0                              // flags

irmp.c:
/* im Anfangsbereich: */
#define METZ_START_BIT_PULSE_LEN_MIN            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PULSE_TIME * MIN_TOLERANCE_15 + 0.5) - 1)
#define METZ_START_BIT_PULSE_LEN_MAX            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PULSE_TIME * MAX_TOLERANCE_15 + 0.5) + 1)
#define METZ_START_BIT_PAUSE_LEN_MIN            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PAUSE_TIME * MIN_TOLERANCE_15 + 0.5) - 1)
#define METZ_START_BIT_PAUSE_LEN_MAX            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PAUSE_TIME * MAX_TOLERANCE_15 + 0.5) + 1)
#define METZ_PULSE_LEN_MIN                      ((uint_fast8_t)(F_INTERRUPTS * METZ_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define METZ_PULSE_LEN_MAX                      ((uint_fast8_t)(F_INTERRUPTS * METZ_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define METZ_1_PAUSE_LEN_MIN                    ((uint_fast8_t)(F_INTERRUPTS * METZ_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define METZ_1_PAUSE_LEN_MAX                    ((uint_fast8_t)(F_INTERRUPTS * METZ_1_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define METZ_0_PAUSE_LEN_MIN                    ((uint_fast8_t)(F_INTERRUPTS * METZ_0_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define METZ_0_PAUSE_LEN_MAX                    ((uint_fast8_t)(F_INTERRUPTS * METZ_0_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define METZ_FRAME_REPEAT_PAUSE_LEN_MAX         (uint_fast16_t)(F_INTERRUPTS * METZ_FRAME_REPEAT_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5)

/* ... */

static const char proto_metz[]          PROGMEM = "METZ";

/* ... */
    proto_rcii,
    proto_metz,
    proto_radio1
};


#if IRMP_SUPPORT_METZ_PROTOCOL == 1

static const PROGMEM IRMP_PARAMETER metz_param =
{
    IRMP_METZ_PROTOCOL,                                                 // protocol:        ir protocol
    METZ_PULSE_LEN_MIN,                                                 // pulse_1_len_min: minimum length of pulse with bit value 1
    METZ_PULSE_LEN_MAX,                                                 // pulse_1_len_max: maximum length of pulse with bit value 1
    METZ_1_PAUSE_LEN_MIN,                                               // pause_1_len_min: minimum length of pause with bit value 1
    METZ_1_PAUSE_LEN_MAX,                                               // pause_1_len_max: maximum length of pause with bit value 1
    METZ_PULSE_LEN_MIN,                                                 // pulse_0_len_min: minimum length of pulse with bit value 0
    METZ_PULSE_LEN_MAX,                                                 // pulse_0_len_max: maximum length of pulse with bit value 0
    METZ_0_PAUSE_LEN_MIN,                                               // pause_0_len_min: minimum length of pause with bit value 0
    METZ_0_PAUSE_LEN_MAX,                                               // pause_0_len_max: maximum length of pause with bit value 0
    METZ_ADDRESS_OFFSET,                                                // address_offset:  address offset
    METZ_ADDRESS_OFFSET + METZ_ADDRESS_LEN,                             // address_end:     end of address
    METZ_COMMAND_OFFSET,                                                // command_offset:  command offset
    METZ_COMMAND_OFFSET + METZ_COMMAND_LEN,                             // command_end:     end of command
    METZ_COMPLETE_DATA_LEN,                                             // complete_len:    complete length of frame
    METZ_STOP_BIT,                                                      // stop_bit:        flag: frame has stop bit
    METZ_LSB,                                                           // lsb_first:       flag: LSB first
    METZ_FLAGS                                                          // flags:           some flags
};

#endif

/* .... in der Erkennung irgendwo: ...*/

#if IRMP_SUPPORT_METZ_PROTOCOL == 1
                    if (irmp_pulse_time >= METZ_START_BIT_PULSE_LEN_MIN && irmp_pulse_time <= METZ_START_BIT_PULSE_LEN_MAX &&
                        irmp_pause_time >= METZ_START_BIT_PAUSE_LEN_MIN && irmp_pause_time <= METZ_START_BIT_PAUSE_LEN_MAX)
                    {
#ifdef ANALYZE
                        ANALYZE_PRINTF ("protocol = METZ, start bit timings: pulse: %3d - %3d, pause: %3d - %3d\n",
                                        METZ_START_BIT_PULSE_LEN_MIN, METZ_START_BIT_PULSE_LEN_MAX,
                                        METZ_START_BIT_PAUSE_LEN_MIN, METZ_START_BIT_PAUSE_LEN_MAX);
#endif // ANALYZE
                        irmp_param_p = (IRMP_PARAMETER *) &metz_param;
                    }
                    else
#endif // IRMP_SUPPORT_METZ_PROTOCOL == 1

Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen 
Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte 
damit umgegangen werden?

Viele Grüße
Stefan

Autor: Lötlackl *. (pappnase) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich des RCII-Protokolls ist IRMP zumindest mit meinem Equipment 
nicht in der Lage, diesen zu erkennen. Getestet mit einer originalen 
Fernbedienung von T+A, Programm wurde compiliert für einen ATmega168 
@16MHz, Empfänger an PORTB 0.
Habe nur die RC5- und RCII-Protokolle aktiviert. Signal kommt auch an, 
das Oszi-Bild steht für eine "0".
RC5 wird erkannt.
Habe ich etwas übersehen?
Ich weiß, mein Scope ist schon etwas "abgerockt".

Auszug aus der "irmpconfig.h"
//schnipp
#ifndef F_INTERRUPTS
#  define F_INTERRUPTS                          20000   // interrupts per second, min: 10000, max: 20000, typ: 15000
#endif

//schnipp
#define IRMP_SUPPORT_RC5_PROTOCOL               1       // RC5                  >= 10000                 ~250 bytes
...
#define IRMP_SUPPORT_RCII_PROTOCOL              1       // RCII T+A             >= 15000                 ~250 bytes

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Ich habe die Toleranzen auf 10% reduziert, geht immer noch problemlos.
> Es könnte sein, dass die Toleranzgrenzen so groß gewählt (30%) waren
> damit der Fehler in der Implementierung ausgeglichen wird.

Ich stelle die Toleranzen immer erstmal großzügig ein, weil ich aus 
Erfahrung weiß, dass diverse Fernbedienungen teilweise erheblich von den 
Sollwerten abweichen. Solange das nicht in Konflikt mit anderen 
Protokollen steht, lasse ich das so. Sollte es einen Konflikt mit 
anderen Protokollen geben, verkleinere ich anschließend die Toleranzen.

> Sicher bin ich mir nicht, da ich die Fernbedienung dort nicht besitze,
> sondern diese Tastatur:
> https://www.mikrocontroller.net/articles/IR-Tastatur_Merlin_Ruwido

Ah, okay.

> Test-Suite läuft problemlos, auch merlin-15kHz.txt wird korrekt erkannt
> (das ist genau das Protokoll das ich meine, meine Tastatur gibt exakt
> solche Werte aus!), jedoch sind die Soll-Werte falsch:
> Adresse muss 0x0001 sein und statt 0x0122 muss es 0x0022 sein etc. Das
> meinte ich damit als ich schrieb, es ist inkompatibel zur vorherigen
> fehlerhaften Implementierung. Argument warum vorher falsch und jetzt
> richtig folgt im nächsten Absatz.

Das überzeugt mich. Bei einigen Protokollen, bei denen mir lediglich ein 
paar wenige Scans vorlag und keine Dokumentation dazu, musste ich bei 
der Verteilung der Bits auf Adressen und Kommandos einfach raten. Es 
musste halt so passen, dass die Adresse immer dieselbe ist. Ob damit die 
Breite der Adresse korrekt ist, kann ich natürlich nicht immer 
garantieren.

Fazit:

Ich versuche, Dein korrigiertes Merlin-Protokoll in den IRMP einzubauen 
- unter optionaler Erweiterung der IRMP-Struct-Members auf 32 Bit. Wählt 
man den Standard "16 Bit" in der Konfiguration, ist halt Merlin nicht 
verfügbar. Das lässt sich aber durchaus verschmerzen, da es nicht sooo 
verbreitet ist.

Vielen Dank für Deine Arbeit.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten,
> hab keine Ahnung ob es noch woanders genutzt wird, die Aufteilung
> Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach
> Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich.

Ja, meist passt das dann - wenigstens ungefähr.

> Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt
> aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen
> großen Bereich verteilt zu sein:

Wenn dieser Effekt auftritt, kann es sein, dass die Bitreihenfolge auf 
LSB statt MSB eingestellt werden muss. Wenn die Werte dann 
"vernünftiger" erscheinen, kannst Du davon ausgehen, dass das Umdrehen 
der Bits richtig war.

Von daher würde ich Dich bitten, mal
#define METZ_LSB                                 1

auszuprobieren.

> Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen
> Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte
> damit umgegangen werden?

Ja, das kann man meist wegwerfen, weil IRMP die Abstände zwischen den 
Frames misst, um festzustellen, ob es sich um eine lang gedrückte Taste 
handelt oder nicht. Hast Du das getestet, ob flag korrekt gesetzt wird?

Zum Umgang: Meist ist es einfacher, es erst am Ende, also bei 
irmp_get_data() wegzuwerfen. Dann bleibt der Eingriff in die 
zeitkritische ISR "minimalinvasiv".

Ich werde das METZ-Protokoll gerne übernehmen. Interessant wäre jedoch 
noch der Test auf LSB-Reihenfolge.

Was immer ganz wünschenswert ist, ist eine Scan-Datei zu einem neuen 
Protokoll. Dann kann man sie in die Test-Suite mit aufnehmen und damit 
auch gewährleisten, dass bei zukünftigen Änderungen der Decoder noch 
vernünftig arbeitet. Vielleicht probierst Du nochmal, den UART zum 
Laufen zu überreden. Alternativ kann man so eine Scan-Datei auch mit 
einem Editor "künstlich anlegen", wenn man das Protokoll gut kennt. Ist 
aber ein wenig Arbeit...

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lötlackl *. schrieb:
> Bezüglich des RCII-Protokolls ist IRMP zumindest mit meinem Equipment
> nicht in der Lage, diesen zu erkennen. Getestet mit einer originalen
> Fernbedienung von T+A, Programm wurde compiliert für einen ATmega168
> @16MHz, Empfänger an PORTB 0.

Es kann durchaus sein, dass TA hier ein anderes Protokoll als das 
"hauseigene" Protokoll verwendet. Das kommt sogar ziemlich oft vor, z.B. 
wenn das betreffende Gerät oder die Entwicklung lediglich eingekauft 
oder einfach nur "umgelabelt" wurde. Um das zu entscheiden, solltest Du 
ruhig ein paar mehr Protokolle aktivieren.

Alternativ machst Du mit IRMP ein paar Scans. Dann kann ich ziemlich 
schnell herausfinden, ob IRMP das Protokoll kennt oder nicht. Wenn es 
noch unbekannt ist, kann ich es einbauen. Falls Du es also nicht selbst 
herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)

> Habe nur die RC5- und RCII-Protokolle aktiviert. Signal kommt auch an,
> das Oszi-Bild steht für eine "0".
> RC5 wird erkannt.

RC5... gilt das jetzt für die TA-Fernbedienung oder für eine andere? 
Wenn für die TA-FB, dann hast Du ja schon das verwendete Protokoll 
gefunden.

> Ich weiß, mein Scope ist schon etwas "abgerockt".

Leider kann ich da nicht wirklich Zeiten ablesen, nur die Verhältnisse 
von Puls/Pause zueinander. Bei einer 0, wo alle Pausen und Pulse gleich 
lang ist, ist das aber wenig aussagekräftig. Ich kann daher nur 
erkennen, dass da ein längeres Startbit ist, kann aber wegen der 
gleichlangen Verhältnisse nicht sagen, ob danach Manchester-, 
Pulse-Distance-, Pulse-Width- oder Pulse-Position-Code folgt. 
Aussagekräftiger wären daher Frames, wo verschiedene 
Pulse-/Pausen-Verhältnisse erkennbar sind - unter Angabe der Zeiten.

Einfacher wirds aber mit IRMP_LOGGING, siehe oben.

> #  define F_INTERRUPTS                          20000   // interrupts

Da würde ich nicht unbedingt mit so einem hohen Wert anfangen, sonder 
erstmal moderat 15000 Interrupts/Sekunde wählen.

Wie gesagt: Wenn IRMP tatsächalich bei der TA-FB RC5 erkennt, dann ist 
es auch RC5 (und nicht RCII) und der Drops ist gelutscht.

: Bearbeitet durch Moderator
Autor: Lötlackl *. (pappnase) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es kann durchaus sein, dass TA hier ein anderes Protokoll als das
> "hauseigene" Protokoll verwendet. Das kommt sogar ziemlich oft vor, z.B.
> wenn das betreffende Gerät oder die Entwicklung lediglich eingekauft
> oder einfach nur "umgelabelt" wurde. Um das zu entscheiden, solltest Du
> ruhig ein paar mehr Protokolle aktivieren.

Frank M. schrieb:
> Da würde ich nicht unbedingt mit so einem hohen Wert anfangen, sonder
> erstmal moderat 15000 Interrupts/Sekunde wählen.


Das hatte ich anfangs sogar, und auch 15000 Interrupts/Sekunde benutzt. 
Ich habe es zwecks Fehlereingrenzung nur auf die beiden Protokolle 
zurechtgestutzt.

Frank M. schrieb:
> RC5... gilt das jetzt für die TA-Fernbedienung oder für eine andere?
> Wenn für die TA-FB, dann hast Du ja schon das verwendete Protokoll
> gefunden.

RC5 gilt für eine andere Fernbedienung. Die habe ich nur beispielhaft 
aufgeführt, um Zweifel über die Funktionsfähigkeit meines Aufbaus zu 
zerstreuen. Viele andere Protokolle wurden schließlich richtig erkannt, 
nur eben RCII nicht.

Frank M. schrieb:
> Alternativ machst Du mit IRMP ein paar Scans. Dann kann ich ziemlich
> schnell herausfinden, ob IRMP das Protokoll kennt oder nicht. Wenn es
> noch unbekannt ist, kann ich es einbauen.
Es ist definitiv RCII, weil ich dieses Protokoll ohne Träger für meine 
TV-Mimik (nur noch eine Fernbedienung für "alles") in einer anderen 
Schaltung implementiert habe. Die Mimik empfängt dabei RC5-Befehle und 
übersetzt sie bei Bedarf nach RCII. Die T+A-Dinger haben einen so 
genannten "R-Link"-Eingang, dort gibt es nur +5V, GND und den 
Signaleingang, ideal, um einen TSOP*** dranzuklöppeln. Und das 
funktioniert sogar mit der originalen FB wie auch mit meiner Mimik.

Frank M. schrieb:
> Falls Du es also nicht selbst
> herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)

So siehts wohl aus.

Anbei noch ein Bild besagter Mimik.

Trotzdem Danke und einen schönen Abend.

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

Bewertung
0 lesenswert
nicht lesenswert
Lötlackl *. schrieb:
> Frank M. schrieb:
>> Falls Du es also nicht selbst
>> herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)
>
> So siehts wohl aus.

Wenn Du die Scans dann hier reinstellst, kann ich anschließend IRMP 
daran anpassen.

Autor: Stefan O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Stefan O. schrieb:
>> Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten,
>> hab keine Ahnung ob es noch woanders genutzt wird, die Aufteilung
>> Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach
>> Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich.
>
> Ja, meist passt das dann - wenigstens ungefähr.
>
>> Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt
>> aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen
>> großen Bereich verteilt zu sein:
>
> Wenn dieser Effekt auftritt, kann es sein, dass die Bitreihenfolge auf
> LSB statt MSB eingestellt werden muss. Wenn die Werte dann
> "vernünftiger" erscheinen, kannst Du davon ausgehen, dass das Umdrehen
> der Bits richtig war.
>
> Von daher würde ich Dich bitten, mal
>
> #define METZ_LSB                                 1
> 
>
> auszuprobieren.
Hatte ich schon, war ebenfalls Murks, aber ich habe ein Muster erkannt 
und mir  das mal genauer angeschaut: Die Adresse/Kommando wird zweimal 
hintereinander übertragen, davon beim zweiten mal mit invertierten Bits. 
Stimmt für alle Tasten und die Ziffern 0-9 sind jetzt die Kommandos 0 
bis 9, auch alle anderen Tastengruppen liegen sinnvoll hintereinander. 
Hier wird das überprüft :
#if IRMP_SUPPORT_METZ_PROTOCOL == 1
            case IRMP_METZ_PROTOCOL:
                irmp_address &= ~0x40;                              // clear toggle bit
                if (((~irmp_address)&0x7)==(irmp_address>>3) && ((~irmp_command)&0x3f)==(irmp_command>>6))
                {
                    irmp_address>>=3;
                    irmp_command>>=6;
                    rtc = TRUE;
                }
                break;
#endif
>
>> Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen
>> Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte
>> damit umgegangen werden?
>
> Ja, das kann man meist wegwerfen, weil IRMP die Abstände zwischen den
> Frames misst, um festzustellen, ob es sich um eine lang gedrückte Taste
> handelt oder nicht. Hast Du das getestet, ob flag korrekt gesetzt wird?
>
> Zum Umgang: Meist ist es einfacher, es erst am Ende, also bei
> irmp_get_data() wegzuwerfen. Dann bleibt der Eingriff in die
> zeitkritische ISR "minimalinvasiv".
Das Flag wurde richtig gesetzt für Wiederholung, in irmp_get_data geht 
es genauso.
>
> Ich werde das METZ-Protokoll gerne übernehmen. Interessant wäre jedoch
> noch der Test auf LSB-Reihenfolge.
>
> Was immer ganz wünschenswert ist, ist eine Scan-Datei zu einem neuen
> Protokoll. Dann kann man sie in die Test-Suite mit aufnehmen und damit
> auch gewährleisten, dass bei zukünftigen Änderungen der Decoder noch
> vernünftig arbeitet. Vielleicht probierst Du nochmal, den UART zum
> Laufen zu überreden. Alternativ kann man so eine Scan-Datei auch mit
> einem Editor "künstlich anlegen", wenn man das Protokoll gut kennt. Ist
> aber ein wenig Arbeit...
Ich habe eine Testdatei angehängt, es gibt jedoch 2 Probleme:
-Erst wenn die Start-Pulse/Pause-Toleranz runter auf 5% ist, wird 
Grundig/Nokia nicht mehr fälschlicherweise als Metz erkannt. Ich weiß 
nicht ob das sinnvoll ist (mit meiner Fernbedienung OK, aber wie ist die 
Streuung?) oder ob die Protokolle sich gegenseitig ausschließen sollten.
-Er erkennt zwar richtig, aber er irgendwo findet er noch ein start 
pulse und hat dann ein timeout, weiß nicht genau warum.

Frank M. schrieb:
> Ich versuche, Dein korrigiertes Merlin-Protokoll in den IRMP einzubauen
> - unter optionaler Erweiterung der IRMP-Struct-Members auf 32 Bit. Wählt
> man den Standard "16 Bit" in der Konfiguration, ist halt Merlin nicht
> verfügbar. Das lässt sich aber durchaus verschmerzen, da es nicht sooo
> verbreitet ist.
Vielen Dank! Das Drücken von nur einer oder zwei Tasten geht ja noch mit 
16 Bit, weiß nicht wie das mit der Merlin-Fernbedienung die du verlinkt 
hattest ist und ob der Aufwand lohnt mit einem Haufen ifdefs ein Teil 
des Merlin-Protokolls mit 16 Bit zu unterstützen.
Was wichtig ist: Wenn man während die Tastatur einen Frame sendet eine 
weitere Taste drückt, ist es nicht unwahrscheinlich, das Blödsinn 
gesendet wird, es ist daher unbedingt erforderlich nur die korrekten 
Längen zuzulassen und das letzte Bit zu prüfen wie das mein Code macht.

> Vielen Dank für Deine Arbeit.
Sehr gerne, ich möchte es ja nutzen :)


Viele Grüße
Stefan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Hatte ich schon, war ebenfalls Murks, aber ich habe ein Muster erkannt
> und mir  das mal genauer angeschaut: Die Adresse/Kommando wird zweimal
> hintereinander übertragen, davon beim zweiten mal mit invertierten Bits.
> Stimmt für alle Tasten und die Ziffern 0-9 sind jetzt die Kommandos 0
> bis 9, auch alle anderen Tastengruppen liegen sinnvoll hintereinander.
> Hier wird das überprüft :#if IRMP_SUPPORT_METZ_PROTOCOL == 1

Sehr gut!

> Das Flag wurde richtig gesetzt für Wiederholung, in irmp_get_data geht
> es genauso.

Prima, das reicht.

> Ich habe eine Testdatei angehängt [...]

Danke.

> -Erst wenn die Start-Pulse/Pause-Toleranz runter auf 5% ist, wird
> Grundig/Nokia nicht mehr fälschlicherweise als Metz erkannt.

5% für Start-Bits ist - aus eigener Erfahrung - akzeptabel. Eventuell 
kann man die Toleranz auch noch für Grundig/Nokia etwas 
herunterschrauben, dann hat man mehr Spielraum.

> -Er erkennt zwar richtig, aber er irgendwo findet er noch ein start
> pulse und hat dann ein timeout, weiß nicht genau warum.

Das habe ich nicht verstanden.

Gruß,

Frank

: Bearbeitet durch Moderator
Autor: Stefan O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> 5% für Start-Bits ist - aus eigener Erfahrung - akzeptabel. Eventuell
> kann man die Toleranz auch noch für Grundig/Nokia etwas
> herunterschrauben, dann hat man mehr Spielraum.

Ich hatte bei mir in der Erkennung Metz vor Grundig/Nokia und er hat die 
Dateien Dbox.txt und die Grundig Dateien als Metz erkannt bis ich die 
Toleranz runter auf 5% hatte. Vielleicht ist es andersherum besser.

Frank M. schrieb:
> Das habe ich nicht verstanden.

Hier die Ausgabe von irmp beim Überprüfen der Testdatei, du wirst aus 
der Meldung sicher mehr Rückschlüsse ziehen können:
# Volume Down [55 (METZ) 0x0001 0x001b]
   4.350ms [starting pulse]
   7.500ms [start-bit: pulse = 17, pause = 46]
protocol = METZ, start bit timings: pulse:  16 -  19, pause:  43 -  49
pulse_1:   6 -  11
pause_1:  26 -  41
pulse_0:   6 -  11
pause_0:  14 -  24
command_offset:  7
command_len:     12
complete_len:    19
stop_bit:         0
   9.600ms [bit  0: pulse =   9, pause =  33] 1
  11.000ms [bit  1: pulse =   8, pause =  20] 0
  12.350ms [bit  2: pulse =   8, pause =  19] 0
  14.450ms [bit  3: pulse =   9, pause =  33] 1
  16.550ms [bit  4: pulse =   9, pause =  33] 1
  18.600ms [bit  5: pulse =   8, pause =  33] 1
  20.000ms [bit  6: pulse =   9, pause =  19] 0
  21.400ms [bit  7: pulse =   9, pause =  19] 0
  23.450ms [bit  8: pulse =   8, pause =  33] 1
  25.550ms [bit  9: pulse =   9, pause =  33] 1
  26.950ms [bit 10: pulse =   9, pause =  19] 0
  29.000ms [bit 11: pulse =   8, pause =  33] 1
  31.100ms [bit 12: pulse =   9, pause =  33] 1
  33.150ms [bit 13: pulse =   8, pause =  33] 1
  34.550ms [bit 14: pulse =   9, pause =  19] 0
  35.950ms [bit 15: pulse =   9, pause =  19] 0
  38.000ms [bit 16: pulse =   9, pause =  32] 1
  39.400ms [bit 17: pulse =   9, pause =  19] 0
  40.800ms [bit 18: pulse =   9, pause =  19] 0
  40.800ms code detected, length = 19
  40.800ms p=55 (METZ), a=0x0001, c=0x001b, f=0x00 checked!
  40.850ms [starting pulse]
   5.550ms error 1: pause after start bit pulse 8 too long: 311

Viele Grüße
Stefan

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

wenn man IRMP kennt und es daher sehr zu schätzen weiß, verzweifelt man 
unter Linux mit LIRC geradezu. Man muss sehr krude Sachen machen um eine 
FB anzulernen, alles ist sehr unkomfortabel und funktioniert dann doch 
nicht.

Hast du eine Implementierung oder kennst etwas empfehlenswertes für 
RasPi? IRMP wird wohl wg der fehlenden interruptfähigkeit nicht 
portierbar sein?

Danke, Klaus.

Autor: Joachim B. (jar)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Klaus R. schrieb:
> wenn man IRMP kennt und es daher sehr zu schätzen weiß, verzweifelt man
> unter Linux mit LIRC geradezu. Man muss sehr krude Sachen machen um eine
> FB anzulernen, alles ist sehr unkomfortabel und funktioniert dann doch
> nicht.

ja kenne ich

> Hast du eine Implementierung oder kennst etwas empfehlenswertes für
> RasPi? IRMP wird wohl wg der fehlenden interruptfähigkeit nicht
> portierbar sein?

könnte doch machbar sein, ich hatte mal gelesen das um 1µs (oder waren 
das 100µs) machbar sind, damit sollte es eigentlich gehen können.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> empfehlenswertes für RasPi

Evtl. ist das hier ein Kompromiss?

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

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...eigentlich nicht. Außer Frank sagt, es geht aus dem und dem Grund gar 
nicht anders.

Klaus.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, auf dem Rpi eine IRQ-Rate mit 15kHz hinzugekommen um IRMP zu 
treiben ist schon sehr sportlich. Ich denke selbst mit Kernel-Treiber 
wird das haarig.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...das befürchte ich auch. Man müsste die IRQ ja quasi nur auslagern und 
die serialisierten Daten dann verarbeiten (was wohl mit der VUSB Lsg 
passiert). Ziel ist, dass der RasPi unterscheidliche andere Geräte 
steuert (433Mhz, RC5, 455kHz IR, ...) und quasi als Server dient und man 
auch das Inet-Radio steuern kann. Ich hatte große Hoffnung auf LIRC, 
aber iwie erscheint mir das extrem merkwürdig zu sein und eher ein 
"netter Versuch".

Klaus.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

für den RPi habe ich gerade mal einen Test gemacht.
Es gibt dort die pigpio library mit GPIO Support.

Dort kann ein Portpin mit 200kHz (default, geht auch langsamer) gepollt 
werden. Man kann einen Callback einrichten, der bei Pin change 
aufgerufen wird. Dort bekommt man dann einen Tickcounter in usec 
mitgeliefert. Man kann also die Zeitdifferenz zwischen den Pegelwechseln 
errechnen.

Könnte man den Mechanismus in IRMP nutzen um damit das IR-Signal zu 
dekodieren? Jetzt wird doch sicher nichts anderes gemacht, nur das IRMP 
das Signal sampled und dann die Zeiten berechnet.

Ich stecke jetzt garnicht tiefer in IRMP drin. Aber evtl. lässt sich das 
ja "leicht" nutzen.

Ich habe mal einen DCF77-Empfänger an einen Pin gehängt und in der 
Callbackfunktion dann nur die Zeiten und den Pinzustand geloggt. Die 
Zeiten sind in usec.

Man kann gut die 100/200ms Signale vom DCF erkennen.
GPIO 27 became 1 at 3839270678
GPIO 27 became 0 at 3839368284
GPIO 27 became 1 at 3840267646
GPIO 27 became 0 at 3840369131
GPIO 27 became 1 at 3841266373
GPIO 27 became 0 at 3841461904
GPIO 27 became 1 at 3842267956
GPIO 27 became 0 at 3842371996
GPIO 27 became 1 at 3843264478
GPIO 27 became 0 at 3843467599
GPIO 27 became 1 at 3844266506
GPIO 27 became 0 at 3844365561
GPIO 27 became 1 at 3845273349
GPIO 27 became 0 at 3845367674
GPIO 27 became 1 at 3846270121
GPIO 27 became 0 at 3846368736
GPIO 27 became 1 at 3847267424
GPIO 27 became 0 at 3847464939
GPIO 27 became 1 at 3848271741
GPIO 27 became 0 at 3848461172

Ein Timer mit 10-20kHz geht leider nicht in der Lib.

: Bearbeitet durch User
Autor: Lötlackl *. (pappnase) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es fällt mir wieder wie Schuppen von den Augen, es ist schon etwas 
länger her, als ich das Sendeprotokoll implementierte. Das Oszi-Bild 
zeigt lediglich das Startkommando, ein vollständiges Telegramm 
beinhaltet aber noch etwas mehr.
Siehe auch: 
https://www.ta-hifi.de/wp-content/uploads/tua_ir_commands.pdf
Ich zitiere:
"A telegram consists of a 10-bit start command
(Start), one or more 10-bit commands (CMD) and a 10-bit end command 
(END)."
In dieser Beziehung ist das von technikus verlinkte PDF etwas ungenau.
Vielleicht ist das der Grund, weshalb IRMP mit RCII nichts anfangen 
kann.

Gute N8

: Bearbeitet durch User
Beitrag #5616429 wurde vom Autor gelöscht.
Autor: Stefan O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe die Leiterplatten am Samstag bekommen und IRMP läuft problemlos mit 
32-Bit-Kommandos auf einem ATmega32u2 mit 16 MHz. Der macht bei mir 
jetzt 2 USB-HID-Geräte: Eine HID-Tastatur, die Merlin-Tastatur 
funktioniert damit wie eine normale Tastatur (auch 
Tastenkombinationen/lange Drücken funktioniert ganz normal), nur bei 
sehr schnellem Tippen fehlen z.T. Buchstaben (das liegt aber nicht am 
Empfänger, die werden nicht vollständig gesendet wenn schon die nächste 
Taste kommt). Das zweite ist ein universelles HID-Gerät welches 
IR-Befehle mit IRSND senden kann.

Ich werde Schaltplan/Layout/Quellcode gerne veröffentlichen, warte aber 
bis die nächste IRMP-Version draußen ist, jetzt geht es nur mit meiner 
angepassten Version.

Viele Grüße
Stefan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> Habe die Leiterplatten am Samstag bekommen und IRMP läuft problemlos mit
> 32-Bit-Kommandos auf einem ATmega32u2 mit 16 MHz.

Freut mich zu hören.

> Ich werde Schaltplan/Layout/Quellcode gerne veröffentlichen, warte aber
> bis die nächste IRMP-Version draußen ist, jetzt geht es nur mit meiner
> angepassten Version.

Beim Einbau in den IRMP ist da noch eine Frage aufgetaucht: Ist cmdlen 
als eigener Struct-Member von IRMP_DATA speziell für das 
Merlin-Protokoll tatsächlich notwendig?

Ich schlage vor, diese Information besser als Zusatzinfo in "flags" 
unterzubringen. Das wird für spezielle Genre-Flags im Kaseikyo-Protokoll 
nämlich auch schon so gemacht, weil die bisherigen 16 Bit dort auch 
nicht ausreichten.

Für solche protokollspezifischen Zusatzinformationen sind nämlich in 
flags die oberen 4 Bit reserviert. Wenn ich es richtig verstanden habe, 
reichen diese 4 Bits auch aus, um cmd_len zu speichern, da es nur die 
Werte von 1 bis 4 annehmen kann.

ich plädiere daher dafür:
Alt:
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
            irmp_data_p->cmdlen   = cmd_len;
#endif

Neu:
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
            irmp_data_p->flags   |= cmd_len << 4;
#endif

Dann kann cmdlen in der neuen IRMP-Struct komplett entfallen. Wenn Du in 
der Anwendung dann cmd_len wieder auswerten möchtest, schreibst Du:
            cmd_len = (irmp_data.flags >> 4) & 0x0F;

Oder kürzer, da die Flags immer nur 8 Bit breit sind:
            cmd_len = irmp_data.flags >> 4;
Wärest Du damit einverstanden?

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> protocol = METZ, start bit timings: pulse:  16 -  19, pause:  43 -  49
> [...]
>    5.550ms error 1: pause after start bit pulse 8 too long: 311

Ich habe das Metz-Protokoll eingebaut. Die obige Fehlermeldung erscheint 
typischerweise, wenn man ein Bit zuwenig einliest.

Ich habe das so korrigiert:
#define METZ_COMMAND_LEN                        13                              // read 13 bits
#define METZ_COMPLETE_DATA_LEN                  20                              // complete length

Dann läufts ohne Fehlermeldung durch.

: Bearbeitet durch Moderator
Autor: Stefan O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das mit cmdlen in den Flags ist eine sehr gute Idee! Die Werte können 
zwischen einschließlich 0 und 4 liegen (Länge 0 bedeutet alle Tasten 
wurden losgelassen, es wird nur Adresse übertragen), 3 Bit wären also 
sogar schon ausreichend.

In der irsnd.c war noch keine Definition für den ATmega32U2, habe ich 
ergänzt:
#elif defined (__AVR_ATmega8U2__)   \
   || defined (__AVR_ATmega16U2__)  \
   || defined (__AVR_ATmega32U2__)                                  // ATmega(8|16|32)U2 uses OC0A = PB7 or OC0B = PD0
#  if IRSND_OCx == IRSND_OC0A
#    define IRSND_PORT_LETTER                       B
#    define IRSND_BIT_NUMBER                        7
#  elif IRSND_OCx == IRSND_OC0B
#    define IRSND_PORT_LETTER                       D
#    define IRSND_BIT_NUMBER                        0
#  endif // IRSND_OCx

Ich weiß nicht ob du das Metz-Protokoll auch direkt in irsnd eingebaut 
hast, sonst probiere ich das am Wochenende mal.

Viele Grüße
Stefan

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stefan O. schrieb:
> das mit cmdlen in den Flags ist eine sehr gute Idee!

Ich habe hier mal die aktuelle Fassung von IRMP angehängt. Wenn das 
alles so bei Dir funktioniert, dann mache ich daraus ein neues Release. 
Wichtig ist, dass man hier im Projekt IRMP_32_BIT auf 1 setzt, also die 
Compileroption
-DIRMP_32_BIT=1

verwendet. Ich wollte das eigentlich mit in irmpconfig.h aufnehmen, 
überlege aber noch, wie ich das realisiere. irmpconfig.h wird nämlich 
aus gutem grund nach irmpsystem.h includiert. Dafür ist es aber dann zu 
spät.

> Ich weiß nicht ob du das Metz-Protokoll auch direkt in irsnd eingebaut
> hast, sonst probiere ich das am Wochenende mal.

Das METZ-Protokoll ist zwar im IRMP-Source drin, aber nicht in IRSND. Da 
kannst Du Dich gern austoben :-)

P.S.
IR-Data und damit die Test-Suite habe ich ebenso um Deine Scan-Dateien 
erweitert.

: Bearbeitet durch Moderator
Autor: Bastler #7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://www.mikrocontroller.net/articles/IRMP#Kodierungen
legt nahe das IRMP auch als 'HFMP' für ASK auf 433/868 MHz funktionieren 
könnte.

Kommt er gut mit Bit-Rauschen klar wenn gerade kein Signal Übertragen 
wird, oder braucht er eine Rauschsperre (Squelch)?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler #7 schrieb:
> https://www.mikrocontroller.net/articles/IRMP#Kodierungen
> legt nahe das IRMP auch als 'HFMP' für ASK auf 433/868 MHz funktionieren
> könnte.

Ja, ich habe da mal vor ein, zwei Jahren auch mit experimentiert, das 
dann aber mangels Interesse nicht weiter verfolgt.

> Kommt er gut mit Bit-Rauschen klar wenn gerade kein Signal Übertragen
> wird, oder braucht er eine Rauschsperre (Squelch)?

IRMP sollte ganz gut damit klarkommen. Wenn etwas empfangen wird, was 
keinem Muster zugeordnet werden kann, wird die Statemachine 
zurückgesetzt. Rauschen sollte also nichts weiter bewirken, als dass 
IRMP sich jedesmal wieder neu in die Startlöcher hockt, bis was "echtes" 
wie z.B. eine Präambel kommt.

Autor: Holger W. (holgerw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
komme gerade nicht weiter. Ich möchte einen RC5 weitersenden.
irrcv sagt mir:

 // RC5 C0C
uint32_t address = 0x10;
uint32_t command = 0xC;
uint64_t data = 0xC0C;

Wie muss denn jetzt der irsend.sendRC5 aussehen, damit er genau den 
Befehl sendet?

irsend.sendRC5(0x10CC0C,24) ???
Wie wird Data "zusammengebaut"?


Holger


ok, hab zu kompliziert gedacht. Einfach den Wert 0xC0C senden...passt 
jetzt

: Bearbeitet durch User
Autor: Uwe S. (steinm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier eine alte Fernbedienung eines Videorecorders von Grundig. 
Es handelt sich um eine VIDEO PILOT 615. Ein TSOP für 38kHz kann das IR 
Signal sauber erkennen. Das Ausgangssignal entspricht weitgehend dem in 
https://www.mikrocontroller.net/attachment/77507/Grundig_10bit.pdf 
beschriebenen Signal, allerdings mit dem Unterschied, das hier nur 7 Bit 
(1 Startbit und 6 Datenbits) gesendendet werden. Sieht ganz so aus, als 
fehlten die Gruppenbits. Die Daten selbst passen zu den Codes in der 
Befehlsliste des obigen Dokuments.

Nun die Frage: Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit 
aus. Reicht es daraus 7 Bit zu machen, um diese alte Fernbedienung zu 
erkennen?

  Uwe

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe S. schrieb:
> Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit aus. Reicht es
> daraus 7 Bit zu machen, um diese alte Fernbedienung zu erkennen?

Ja, kann gut sein, probiere es einfach aus. Du musst dafür nur 
irmpprotocols.h anpassen.

Wenn es klappt, kann ich auch in den Source einen Timeout-Handler 
einbauen, damit IRMP sowohl 10 Bit als auch 7 Bit erkennen kann.

Dafür wäre eine Scan-Datei (IRMP_LOGGING auf 1) sehr sinnvoll, damit ich 
das testen kann.

Autor: Uwe S. (steinm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Uwe S. schrieb:
>> Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit aus. Reicht es
>> daraus 7 Bit zu machen, um diese alte Fernbedienung zu erkennen?
>
> Ja, kann gut sein, probiere es einfach aus. Du musst dafür nur
> irmpprotocols.h anpassen.
Das hat erstaunlich gut geklappt. Damit wird die Fernbedienung schon 
erkannt.

> Wenn es klappt, kann ich auch in den Source einen Timeout-Handler
> einbauen, damit IRMP sowohl 10 Bit als auch 7 Bit erkennen kann.
>
> Dafür wäre eine Scan-Datei (IRMP_LOGGING auf 1) sehr sinnvoll, damit ich
> das testen kann.
Ich habe in der Schaltung leider keine serielle Ausgabe. Angehängt ist 
daher eine modifizierte Ausgabe von Sigrok. 0 steht für hell und 1 für 
dunkel, abgetastet mit 20 kHz. Im angehängten Screenshot sieht man das 
Signal auch grafisch aufbereitet. Der erste Frame ist immer gleich. Im 
zweiten Frame ist dann das eigentliche Kommando. Dieses wird so oft 
wiederholt, wie die Taste gedrückt wird. Nach Loslassen der Taste kommt 
nochmal der Frame vom Anfang (im Bild und dem Dump nicht vorhanden). Das 
entspricht weitesgehend der 10Bit Grundig Fernbedienung. Die Daten 
werden LSB gesendet. Die in der Beschreibung der 10Bit 
Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte 
gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit) 
gesendet. Laut Beschreibung sollte es aber "S001100" sein. Das ist auch 
bei anderen Tasten so. Das letzte Bit könnte natürlich auch ein Stop bit 
sein, denn bisher habe ich keine Taste gefunden, deren letztes Bit nicht 
"1" war.

Noch eine Frage zu den Frames. Kümmert sich IRMP um die Frames und deren 
Interpretation oder muss ich das selbst machen?

  Uwe

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe S. schrieb:
> Das hat erstaunlich gut geklappt. Damit wird die Fernbedienung schon
> erkannt.

Prima.

> Ich habe in der Schaltung leider keine serielle Ausgabe.

Schade.

> Angehängt ist
> daher eine modifizierte Ausgabe von Sigrok. 0 steht für hell und 1 für
> dunkel, abgetastet mit 20 kHz.

Okay, danke. Die Aufzeichnung kann ich verarbeiten.

> Die in der Beschreibung der 10Bit
> Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte
> gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit)
> gesendet. Laut Beschreibung sollte es aber "S001100" sein.

Kann sein, dass Du die Anzahl der Bits in irmpprotcols.h um 1 zu hoch 
eingestellt hast. Am besten zeigst Du auch alle Änderungen, die Du in 
irmpprotocols.h vorgenommen hast.

> Noch eine Frage zu den Frames. Kümmert sich IRMP um die Frames und deren
> Interpretation oder muss ich das selbst machen?

Da kümmert sich IRMP selbst drum. Ab einer längeren Ruhepause weiß die 
Statemachine, dass der Frame zuende ist - egal ob vollständig oder 
nicht. Die Statemachine wird dann automatisch zurückgesetzt.

Autor: Uwe S. (steinm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Uwe S. schrieb:

[...]

>> Die in der Beschreibung der 10Bit
>> Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte
>> gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit)
>> gesendet. Laut Beschreibung sollte es aber "S001100" sein.
>
> Kann sein, dass Du die Anzahl der Bits in irmpprotcols.h um 1 zu hoch
> eingestellt hast. Am besten zeigst Du auch alle Änderungen, die Du in
> irmpprotocols.h vorgenommen hast.
Nur diese beiden Zeilen
#define GRUNDIG_COMMAND_LEN                     6//9                               //    read 9 command bits
#define GRUNDIG_COMPLETE_DATA_LEN               7//10                              //    complete length: 1 start bit + 9 data bits

  Uwe

Autor: Uwe S. (steinm)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

mit der kleinen Korrektur der GRUNDIG_COMMAND_LEN von 9 auf 6 und 
GRUNDIG_COMPLETE_DATA_LEN von 10 auf 7 habe ich mal alle Tasten der FB 
aufgezeichnet. Das Scannen selbst habe ich mit sigrok und pulseview mit 
einer Abtastrate von 20kHz gemacht und das Ergebnis in die Datei 
IR-Data/Grundig_Video-Pilot-615-20kHz.txt der angehängten Zip-Datei 
geschrieben.
In jeder Zeile steht die Abtastung einer Taste. Das dann durch 
irmp-20kHz geschickt, ergibt die Ausgabe in 
IR-Data/Grundig_Video-Pilot-615-20kHz.out

Sieht soweit alles recht ordentlich aus, aber wie erweitert man den 
Quellcode von IRMP entsprechend, damit sowohl die 10-Bit als auch die 
6-Bit FB von Grundig erkannt wird? Und was passiert mit den Start- und 
End-Code, der bei jeder Taste gedrückt wird? Kümmert sich irmp darum 
oder muss ich das in der Anwendung selbst machen.

  Uwe

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.