Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


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


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
1
namespace Irmp {
2
extern "C" {
3
struct IrmpData {
4
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
5
    uint16_t                            address;                                    // address
6
    uint16_t                            command;                                    // command
7
    uint8_t                             flags;                                      // flags, e.g. repetition
8
} __attribute__ ((__packed__));
9
10
typedef struct IrmpData IRMP_DATA;
11
12
extern void                             irmp_init (void);
13
extern uint_fast8_t                     irmp_get_data (IRMP_DATA *);
14
extern uint_fast8_t                     irmp_ISR (void);
15
16
}
17
constexpr uint8_t Repetition = 0x01;
18
19
}
einfach innerhalb des namespaces die (neue) Headerdatei inkludieren (mit 
Ausnahme des constexpr ...).

Ganz am Ende(!) meiner (einzigen) Implmentierungsddatei kommt dann:
1
constexpr auto finterrupts = IrInterruptFrequency.value;
2
3
static_assert(finterrupts >= 10000, "IR Interrupts frequeny too low");
4
static_assert(finterrupts <= 20000, "IR Interrupts frequeny too high");
5
6
#define F_INTERRUPTS finterrupts
7
8
#define input(x) iRPin::read()
9
10
namespace Irmp {
11
#include "irmp/irmp.c"
12
}

>
> "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:
1
#ifndef input
2
#  define input(x)                              ((x) & (1 << IRMP_BIT))
3
#endif

: Bearbeitet durch User
von Marcel (Gast)


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!

von Jörg R. (jrie)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Marcel (Gast)


Lesenswert?

Hi,

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

Gruß
Marcel

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Stefan B. (n0b0dy)


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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Stefan B. (n0b0dy)


Angehängte Dateien:

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. :-)

von Leo C. (rapid)


Angehängte Dateien:

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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Marcel (Gast)


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

von Leo C. (rapid)


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
1
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

von Text (Gast)


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


???

von Leo C. (rapid)


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.

von Text (Gast)


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.

von Text (Gast)


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?

von Text (Gast)


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

von Andres B. (adb)


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

von Andres B. (adb)


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

von Ulf (Gast)


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

von Oliver (Gast)


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

von Jörg R. (jrie)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Oliver (Gast)


Lesenswert?

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

Grüße
Oliver

von Arthur (Gast)


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.

von Marcel (Gast)


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

von Uwe (Gast)


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

von Helmut K. (chaosbastler)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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:
1
8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits

wurde irgendwann im Extended NEC-Format:
1
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.
1
Taste "1" = 0x11  erste  Reihe, erste  Spalte
2
Taste "2" = 0x12  erste  Reihe, zweite Spalte
3
Taste "3" = 0x12  erste  Reihe, dritte Spalte
4
Taste "4" = 0x21  zweite Reihe, erste  Spalte
5
Taste "5" = 0x22  zweite Reihe, zweite Spalte
6
Taste "6" = 0x23  zweite Reihe, dritte Spalte
7
Taste "7" = 0x31  dritte Reihe, erste  Spalte
8
Taste "8" = 0x32  dritte Reihe, zweite Spalte
9
Taste "9" = 0x33  dritte Reihe, dritte Spalte

Oder auch:
1
Taste "1" = 0x31
2
Taste "2" = 0x32
3
...
4
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
von Helmut K. (chaosbastler)


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

von Matthias F. (frank91)


Angehängte Dateien:

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
von Frank M. (ukw) (Moderator) Benutzerseite


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 :-)

von Klaus R. (klaus2)


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!

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Klaus R. (klaus2)


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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


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!

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


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
von Frank M. (ukw) (Moderator) Benutzerseite


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
von Frank M. (ukw) (Moderator) Benutzerseite


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 :-)

von Klaus R. (klaus2)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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 ;-)

von Klaus R. (klaus2)


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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


Lesenswert?

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

Klaus.

von Klaus R. (klaus2)


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.

von Klaus R. (klaus2)


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.

von Frank L. (Firma: Flk Consulting UG) (flk)


Lesenswert?

Hallo,
Warum die Tasten mit ADC auswerten, wieviele Tasten willst Du abfragen 
und wieviele Pins hast Du frei?

Gruß
Frank

von Frank M. (ukw) (Moderator) Benutzerseite


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 ;)

von Klaus R. (klaus2)


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.
1
/*-----------------------------------------------------------------------------------------------------------------------
2
 * Initialize ADC
3
 *-----------------------------------------------------------------------------------------------------------------------
4
 */
5
static void
6
adc_init (void)
7
{
8
9
  ADMUX = (1<<REFS1);                                    // Interne Referenz 1,1V
10
  ADCSRA = (1<<ADSC) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS1);                  // Frequenzvorteiler 128
11
  ADCSRB |= (0<<ADLAR);                                    // Linksbündig = 1
12
  ADCSRA |= (1<<ADEN);                                    // Enable ADC
13
14
}
15
16
17
/*-----------------------------------------------------------------------------------------------------------------------
18
 * Read ADC value
19
 *-----------------------------------------------------------------------------------------------------------------------
20
 */
21
22
uint16_t ADC_Read(void){
23
24
  uint16_t ADC_value=0;
25
26
  ADMUX  |= (1<<MUX0);                      // Kanal ADC1 (PB2)
27
  
28
  ADCSRA |= (1<<ADSC);                            // eine Wandlung "single conversion"
29
  
30
  while (ADCSRA & (1<<ADSC) ) {}                   // auf Abschluss der Konvertierung warten
31
32
  ADC_value = ADCL;                           // mit uint16_t x
33
  ADC_value += (ADCH<<8);                     // in zwei Zeilen (LSB/MSB-Reihenfolge und
34
                                        // C-Operatorpriorität sichergestellt)
35
  
36
  return ADC_value;                               // ADC auslesen und zurückgeben
37
38
}

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
von Klaus R. (klaus2)


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.

von Klaus R. (klaus2)


Angehängte Dateien:

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
von Klaus R. (klaus2)


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
von Klaus R. (klaus2)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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:
1
if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
2
{
3
    store_in_eeprom (irmp_data.protocol, irmp_data.address, irmp_data.command, irmp_data.flags & 0xF0);
4
}
5
else
6
{
7
    ignore frame;
8
}

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

von Klaus R. (klaus2)


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...:
1
while (ms_cnt < 250)
2
                    {
3
                        // some devices need a repeated frame to accept the command, e.g. POWER command on Toshiba TV to switch off
4
                        if (! cancelled && irmp_data[k].protocol != 0xFF)       // after 250 ms....
5
                        {
6
                            IRMP_DATA id;
7
8
                            if (irmp_get_data (&id))                            // ... receive IR signal again
9
                            {
10
                                if (id.flags == 1)                              // it's a repeated frame, store it!
11
                                {
12
                                    framecnt++;
13
                                }
14
                                cli ();
15
                                ms_cnt = 0;
16
                                sei ();
17
                            }
18
                        }
19
                    }
20
21
                    irmp_data[k].flags = framecnt;

Danke, Klaus.

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


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:
1
irmp_data[k].flags = framecnt;

folgendermaßen ändern:
1
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
von Klaus R. (klaus2)


Lesenswert?

GENAU das hatte ich QnD morgen vor!

Toshiba hat das übrigens geändert ;)

Danke! Klaus.

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


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.

von Klaus R. (klaus2)


Lesenswert?

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

Klaus.

von Klaus R. (klaus2)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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?

von Klaus R. (klaus2)


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.

von Klaus R. (klaus2)


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.

von Klaus R. (klaus2)


Angehängte Dateien:

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.

von Klaus R. (klaus2)


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.

von Klaus R. (klaus2)


Lesenswert?

Peter hat (fast) alles fertig, war ja klar :)

Beitrag "Tastenmatrix auslesen über nur 2 Leitungen"

Klaus.

von Klaus R. (klaus2)


Angehängte Dateien:

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

Der Trick ist, gar keine .eep einzuspielen.

von Klaus R. (klaus2)


Lesenswert?

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

Klaus.

von Klaus R. (klaus2)


Angehängte Dateien:

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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Klaus R. (klaus2)


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!

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Klaus R. (klaus2)


Lesenswert?

...ja klar, nur standard irmp. Ich meld mich!

Klaus.

von Frank L. (florenzen)


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

von Daniel (Gast)


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!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

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

von Klaus R. (klaus2)


Lesenswert?

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

Klaus.

von technikus (Gast)


Lesenswert?

Hallo,

hat jemand mal irmp in einem STM32 HAL Projekt genutzt?

Gruß
Stephan

von Gerd E. (robberknight)


Angehängte Dateien:

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.

von Frank M. (ukw) (Moderator) Benutzerseite


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?

von Gerd E. (robberknight)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Gerd E. (robberknight)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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!". :)

von Gerd E. (robberknight)


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:
1
--- a/irmp.c
2
+++ b/irmp.c
3
@@ -5212,6 +5212,23 @@ irmp_ISR (void)
4
         chEvtSignalI(IRMP_EVENT_THREAD_PTR,IRMP_EVENT_BIT);
5
 #endif
6
 
7
+#if IRMP_USE_IDLE_CALL == 1
8
+    // check if there is no ongoing transmission or repetition
9
+    if (!irmp_start_bit_detected &&
10
+        !irmp_pulse_time &&
11
+        !irmp_pause_time &&
12
+        !wait_for_start_space &&
13
+        key_repetition_len > IRMP_KEY_REPETITION_LEN)
14
+// TODO: do we need to check irmp_tmp_address, irmp_tmp_command, irmp_bit ??
15
+// TODO: why is wait_for_space kept set after receiving ir data once and then idle?
16
+    {
17
+        // no ongoing transmission
18
+        // enough time passed since last decoded signal that a repetition won't affect our output
19
+
20
+        irmp_idle();
21
+    }
22
+#endif // IRMP_USE_IDLE_CALL
23
+
24
     return (irmp_ir_detected);
25
 }

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.

von Frank M. (ukw) (Moderator) Benutzerseite


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:
1
    if (! irmp_ir_detected)              // ir code already detected?
2
    {                                    // no...
3
        if (! irmp_start_bit_detected)   // start bit detected?
4
        {                                // no...
5
            ....
6
        }
7
        else
8
        {
9
            if (wait_for_start_space)    // we have received start bit...
10
            {                            // ...and are counting the time of darkness
11
                if (irmp_input)          // still dark?
12
                {                        // yes
13
                    ...
14
                }
15
                else
16
                {                        // receiving first data pulse!
17
                    ...
18
                    wait_for_start_space = 0;
19
                }
20
            }
21
        }
22
    }

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?
1
    if (!irmp_start_bit_detected &&
2
    {
3
        irmp_idle();
4
    }

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

von Gerd E. (robberknight)


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?
>
1
>     if (!irmp_start_bit_detected &&
2
>     {
3
>         irmp_idle();
4
>     }
5
>
>
> 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.

von Frank M. (ukw) (Moderator) Benutzerseite


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:
1
#ifdef ANALYZE
2
    time_counter++;
3
#endif // ANALYZE

Neu:
1
#ifdef ANALYZE
2
    static uint_fast8_t     last_irmp_start_bit_detected = 0xFF;
3
    static uint_fast8_t     last_irmp_pulse_time = 0xFF;
4
5
    if (last_irmp_start_bit_detected != irmp_start_bit_detected || last_irmp_pulse_time != irmp_pulse_time)
6
    {
7
        last_irmp_start_bit_detected    = irmp_start_bit_detected;
8
        last_irmp_pulse_time            = irmp_pulse_time;
9
10
        printf ("%d %d %d\n", time_counter, irmp_start_bit_detected, irmp_pulse_time);
11
    }
12
13
    time_counter++;
14
#endif // ANALYZE

Dann kann man mit
1
    ./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:
1
    if (!irmp_start_bit_detected && !irmp_pulse_time)
2
    {
3
        irmp_idle();
4
    }

Mit
1
    ./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.

von Gerd E. (robberknight)


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:
>
1
>     if (!irmp_start_bit_detected && !irmp_pulse_time)
2
>     {
3
>         irmp_idle();
4
>     }
5
>

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:
1
    if (!irmp_start_bit_detected && !irmp_pulse_time
2
        && key_repetition_len > IRMP_KEY_REPETITION_LEN)
3
    {
4
        irmp_idle();
5
    }
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:
1
if (irmp_ir_detected)
2
{
3
    if (last_irmp_command == irmp_tmp_command &&
4
        last_irmp_address == irmp_tmp_address &&
5
        key_repetition_len < IRMP_KEY_REPETITION_LEN)
6
    {
7
        irmp_flags |= IRMP_FLAG_REPETITION;
8
    }
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.

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Gerd E. (robberknight)


Angehängte Dateien:

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.

von Frank M. (ukw) (Moderator) Benutzerseite


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 :-)

von Gerd E. (robberknight)


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.)

von Markus (Gast)


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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 :-)

von Conny G. (conny_g)


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/

von Frank M. (ukw) (Moderator) Benutzerseite


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

von technikus (Gast)


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

von Jonas (Gast)


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)?

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von technikus (Gast)


Lesenswert?

Super!
Danke

von Frank M. (ukw) (Moderator) Benutzerseite


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

von technikus (Gast)


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

von technikus (Gast)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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
von technikus (Gast)


Lesenswert?

Frank M. schrieb:
> Reicht die Protokoll-Erkennung (IRMP)

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

Gruß
Stephan

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Technikus (Gast)


Lesenswert?

Danke dir!
Ich werde mir den Geber besorgen und testen.

Gruß

von Stefan O. (Gast)


Angehängte Dateien:

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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Stefan Z. (stefan_z)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Joachim B. (jar)


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
von Stefan Z. (stefan_z)


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.

von Joachim B. (jar)


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.

von Stefan Z. (stefan_z)


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…

von Stefan O. (Gast)


Angehängte Dateien:

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

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Stefan Z. (stefan_z)


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…

von Stefan O. (Gast)


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

von Stefan O. (Gast)


Angehängte Dateien:

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

von Stefan O. (Gast)


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:
1
/*---------------------------------------------------------------------------------------------------------------------------------------------------
2
 * METZ:
3
 *---------------------------------------------------------------------------------------------------------------------------------------------------
4
 */
5
#define METZ_START_BIT_PULSE_TIME                870.0e-6                       //  870 usec pulse
6
#define METZ_START_BIT_PAUSE_TIME               2300.0e-6                       // 2300 usec pause
7
#define METZ_PULSE_TIME                          435.0e-6                       //  435 usec pulse
8
#define METZ_1_PAUSE_TIME                       1680.0e-6                       // 1680 usec pause
9
#define METZ_0_PAUSE_TIME                        960.0e-6                       //  960 usec pause
10
#define METZ_FRAME_REPEAT_PAUSE_TIME             122.0e-3                       // frame repeat after 122ms
11
#define METZ_ADDRESS_OFFSET                      1                              // skip 1 bit (toggle bit)
12
#define METZ_ADDRESS_LEN                         6                              // read 6 address bits
13
#define METZ_COMMAND_OFFSET                      7                              // skip 7 bits
14
#define METZ_COMMAND_LEN                        12                              // read 12 bits
15
#define METZ_COMPLETE_DATA_LEN                  19                              // complete length
16
#define METZ_STOP_BIT                            0                              // has no stop bit
17
#define METZ_LSB                                 0                              // MSB...LSB
18
#define METZ_FLAGS                               0                              // flags

irmp.c:
1
/* im Anfangsbereich: */
2
#define METZ_START_BIT_PULSE_LEN_MIN            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PULSE_TIME * MIN_TOLERANCE_15 + 0.5) - 1)
3
#define METZ_START_BIT_PULSE_LEN_MAX            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PULSE_TIME * MAX_TOLERANCE_15 + 0.5) + 1)
4
#define METZ_START_BIT_PAUSE_LEN_MIN            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PAUSE_TIME * MIN_TOLERANCE_15 + 0.5) - 1)
5
#define METZ_START_BIT_PAUSE_LEN_MAX            ((uint_fast8_t)(F_INTERRUPTS * METZ_START_BIT_PAUSE_TIME * MAX_TOLERANCE_15 + 0.5) + 1)
6
#define METZ_PULSE_LEN_MIN                      ((uint_fast8_t)(F_INTERRUPTS * METZ_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
7
#define METZ_PULSE_LEN_MAX                      ((uint_fast8_t)(F_INTERRUPTS * METZ_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
8
#define METZ_1_PAUSE_LEN_MIN                    ((uint_fast8_t)(F_INTERRUPTS * METZ_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
9
#define METZ_1_PAUSE_LEN_MAX                    ((uint_fast8_t)(F_INTERRUPTS * METZ_1_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
10
#define METZ_0_PAUSE_LEN_MIN                    ((uint_fast8_t)(F_INTERRUPTS * METZ_0_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
11
#define METZ_0_PAUSE_LEN_MAX                    ((uint_fast8_t)(F_INTERRUPTS * METZ_0_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
12
#define METZ_FRAME_REPEAT_PAUSE_LEN_MAX         (uint_fast16_t)(F_INTERRUPTS * METZ_FRAME_REPEAT_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5)
13
14
/* ... */
15
16
static const char proto_metz[]          PROGMEM = "METZ";
17
18
/* ... */
19
    proto_rcii,
20
    proto_metz,
21
    proto_radio1
22
};
23
24
25
#if IRMP_SUPPORT_METZ_PROTOCOL == 1
26
27
static const PROGMEM IRMP_PARAMETER metz_param =
28
{
29
    IRMP_METZ_PROTOCOL,                                                 // protocol:        ir protocol
30
    METZ_PULSE_LEN_MIN,                                                 // pulse_1_len_min: minimum length of pulse with bit value 1
31
    METZ_PULSE_LEN_MAX,                                                 // pulse_1_len_max: maximum length of pulse with bit value 1
32
    METZ_1_PAUSE_LEN_MIN,                                               // pause_1_len_min: minimum length of pause with bit value 1
33
    METZ_1_PAUSE_LEN_MAX,                                               // pause_1_len_max: maximum length of pause with bit value 1
34
    METZ_PULSE_LEN_MIN,                                                 // pulse_0_len_min: minimum length of pulse with bit value 0
35
    METZ_PULSE_LEN_MAX,                                                 // pulse_0_len_max: maximum length of pulse with bit value 0
36
    METZ_0_PAUSE_LEN_MIN,                                               // pause_0_len_min: minimum length of pause with bit value 0
37
    METZ_0_PAUSE_LEN_MAX,                                               // pause_0_len_max: maximum length of pause with bit value 0
38
    METZ_ADDRESS_OFFSET,                                                // address_offset:  address offset
39
    METZ_ADDRESS_OFFSET + METZ_ADDRESS_LEN,                             // address_end:     end of address
40
    METZ_COMMAND_OFFSET,                                                // command_offset:  command offset
41
    METZ_COMMAND_OFFSET + METZ_COMMAND_LEN,                             // command_end:     end of command
42
    METZ_COMPLETE_DATA_LEN,                                             // complete_len:    complete length of frame
43
    METZ_STOP_BIT,                                                      // stop_bit:        flag: frame has stop bit
44
    METZ_LSB,                                                           // lsb_first:       flag: LSB first
45
    METZ_FLAGS                                                          // flags:           some flags
46
};
47
48
#endif
49
50
/* .... in der Erkennung irgendwo: ...*/
51
52
#if IRMP_SUPPORT_METZ_PROTOCOL == 1
53
                    if (irmp_pulse_time >= METZ_START_BIT_PULSE_LEN_MIN && irmp_pulse_time <= METZ_START_BIT_PULSE_LEN_MAX &&
54
                        irmp_pause_time >= METZ_START_BIT_PAUSE_LEN_MIN && irmp_pause_time <= METZ_START_BIT_PAUSE_LEN_MAX)
55
                    {
56
#ifdef ANALYZE
57
                        ANALYZE_PRINTF ("protocol = METZ, start bit timings: pulse: %3d - %3d, pause: %3d - %3d\n",
58
                                        METZ_START_BIT_PULSE_LEN_MIN, METZ_START_BIT_PULSE_LEN_MAX,
59
                                        METZ_START_BIT_PAUSE_LEN_MIN, METZ_START_BIT_PAUSE_LEN_MAX);
60
#endif // ANALYZE
61
                        irmp_param_p = (IRMP_PARAMETER *) &metz_param;
62
                    }
63
                    else
64
#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

von Lötlackl *. (pappnase) Benutzerseite


Angehängte Dateien:

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"
1
//schnipp
2
#ifndef F_INTERRUPTS
3
#  define F_INTERRUPTS                          20000   // interrupts per second, min: 10000, max: 20000, typ: 15000
4
#endif
5
6
//schnipp
7
#define IRMP_SUPPORT_RC5_PROTOCOL               1       // RC5                  >= 10000                 ~250 bytes
8
...
9
#define IRMP_SUPPORT_RCII_PROTOCOL              1       // RCII T+A             >= 15000                 ~250 bytes

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


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.

von Frank M. (ukw) (Moderator) Benutzerseite


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
1
#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...

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Lötlackl *. (pappnase) Benutzerseite


Angehängte Dateien:

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
von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Stefan O. (Gast)


Angehängte Dateien:

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
>
1
> #define METZ_LSB                                 1
2
>
>
> 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 :
1
#if IRMP_SUPPORT_METZ_PROTOCOL == 1
2
            case IRMP_METZ_PROTOCOL:
3
                irmp_address &= ~0x40;                              // clear toggle bit
4
                if (((~irmp_address)&0x7)==(irmp_address>>3) && ((~irmp_command)&0x3f)==(irmp_command>>6))
5
                {
6
                    irmp_address>>=3;
7
                    irmp_command>>=6;
8
                    rtc = TRUE;
9
                }
10
                break;
11
#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

von Frank M. (ukw) (Moderator) Benutzerseite


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
von Stefan O. (Gast)


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:
1
# Volume Down [55 (METZ) 0x0001 0x001b]
2
   4.350ms [starting pulse]
3
   7.500ms [start-bit: pulse = 17, pause = 46]
4
protocol = METZ, start bit timings: pulse:  16 -  19, pause:  43 -  49
5
pulse_1:   6 -  11
6
pause_1:  26 -  41
7
pulse_0:   6 -  11
8
pause_0:  14 -  24
9
command_offset:  7
10
command_len:     12
11
complete_len:    19
12
stop_bit:         0
13
   9.600ms [bit  0: pulse =   9, pause =  33] 1
14
  11.000ms [bit  1: pulse =   8, pause =  20] 0
15
  12.350ms [bit  2: pulse =   8, pause =  19] 0
16
  14.450ms [bit  3: pulse =   9, pause =  33] 1
17
  16.550ms [bit  4: pulse =   9, pause =  33] 1
18
  18.600ms [bit  5: pulse =   8, pause =  33] 1
19
  20.000ms [bit  6: pulse =   9, pause =  19] 0
20
  21.400ms [bit  7: pulse =   9, pause =  19] 0
21
  23.450ms [bit  8: pulse =   8, pause =  33] 1
22
  25.550ms [bit  9: pulse =   9, pause =  33] 1
23
  26.950ms [bit 10: pulse =   9, pause =  19] 0
24
  29.000ms [bit 11: pulse =   8, pause =  33] 1
25
  31.100ms [bit 12: pulse =   9, pause =  33] 1
26
  33.150ms [bit 13: pulse =   8, pause =  33] 1
27
  34.550ms [bit 14: pulse =   9, pause =  19] 0
28
  35.950ms [bit 15: pulse =   9, pause =  19] 0
29
  38.000ms [bit 16: pulse =   9, pause =  32] 1
30
  39.400ms [bit 17: pulse =   9, pause =  19] 0
31
  40.800ms [bit 18: pulse =   9, pause =  19] 0
32
  40.800ms code detected, length = 19
33
  40.800ms p=55 (METZ), a=0x0001, c=0x001b, f=0x00 checked!
34
  40.850ms [starting pulse]
35
   5.550ms error 1: pause after start bit pulse 8 too long: 311

Viele Grüße
Stefan

von Klaus R. (klaus2)


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.

von Joachim B. (jar)


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.

von 900ss (900ss)


Lesenswert?

Klaus R. schrieb:
> empfehlenswertes für RasPi

Evtl. ist das hier ein Kompromiss?

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

von Klaus R. (klaus2)


Lesenswert?

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

Klaus.

von 900ss (900ss)


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.

von Klaus R. (klaus2)


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.

von 900ss (900ss)


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.
1
GPIO 27 became 1 at 3839270678
2
GPIO 27 became 0 at 3839368284
3
GPIO 27 became 1 at 3840267646
4
GPIO 27 became 0 at 3840369131
5
GPIO 27 became 1 at 3841266373
6
GPIO 27 became 0 at 3841461904
7
GPIO 27 became 1 at 3842267956
8
GPIO 27 became 0 at 3842371996
9
GPIO 27 became 1 at 3843264478
10
GPIO 27 became 0 at 3843467599
11
GPIO 27 became 1 at 3844266506
12
GPIO 27 became 0 at 3844365561
13
GPIO 27 became 1 at 3845273349
14
GPIO 27 became 0 at 3845367674
15
GPIO 27 became 1 at 3846270121
16
GPIO 27 became 0 at 3846368736
17
GPIO 27 became 1 at 3847267424
18
GPIO 27 became 0 at 3847464939
19
GPIO 27 became 1 at 3848271741
20
GPIO 27 became 0 at 3848461172

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

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


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.
von Stefan O. (Gast)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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:
1
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
2
            irmp_data_p->cmdlen   = cmd_len;
3
#endif

Neu:
1
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
2
            irmp_data_p->flags   |= cmd_len << 4;
3
#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:
1
            cmd_len = (irmp_data.flags >> 4) & 0x0F;

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

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


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:
1
#define METZ_COMMAND_LEN                        13                              // read 13 bits
2
#define METZ_COMPLETE_DATA_LEN                  20                              // complete length

Dann läufts ohne Fehlermeldung durch.

: Bearbeitet durch Moderator
von Stefan O. (Gast)


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:
1
#elif defined (__AVR_ATmega8U2__)   \
2
   || defined (__AVR_ATmega16U2__)  \
3
   || defined (__AVR_ATmega32U2__)                                  // ATmega(8|16|32)U2 uses OC0A = PB7 or OC0B = PD0
4
#  if IRSND_OCx == IRSND_OC0A
5
#    define IRSND_PORT_LETTER                       B
6
#    define IRSND_BIT_NUMBER                        7
7
#  elif IRSND_OCx == IRSND_OC0B
8
#    define IRSND_PORT_LETTER                       D
9
#    define IRSND_BIT_NUMBER                        0
10
#  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

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

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
1
-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
von Bastler #7 (Gast)


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)?

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Holger W. (holgerw)


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
von Uwe S. (steinm)


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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Uwe S. (steinm)


Angehängte Dateien:

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

von Frank M. (ukw) (Moderator) Benutzerseite


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.

von Uwe S. (steinm)


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
1
#define GRUNDIG_COMMAND_LEN                     6//9                               //    read 9 command bits
2
#define GRUNDIG_COMPLETE_DATA_LEN               7//10                              //    complete length: 1 start bit + 9 data bits

  Uwe

von Uwe S. (steinm)


Angehängte Dateien:

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

von Bernd (Gast)


Lesenswert?

Hallo

 habe gerade versucht, mit irsnd ein NEC - Datagramm zu erstellen - ging 
nicht, die Modulationsfrequenz war viel zu hoch (~700kHz). Kann es sein, 
dass in der Zeile (irsnd.c)
1
#  define IRSND_FREQ_36_KHZ (IRSND_FREQ_TYPE) ((F_CPU / 36000 / AVR_PRESCALER / 2) - 1)
2
#  define IRSND_FREQ_38_KHZ (IRSND_FREQ_TYPE) ((F_CPU / 38000 / AVR_PRESCALER / 2) - 1)
was nicht stimmt?
F_CPU=20000000,
F_INTERRUPTS=16000

Wenn ich IRSND_FREQ_36[38]_KHZ = 250 setze, ist alles gut.

p.s. falls ich richtig rechne, ergibt sich doch für F_CPU =20MHz und 
F_INTERRUPTS=15k ein Wert, der größer als 8 bit ist. Ist das gewollt?

In void irsnd_init (void) steht für NEC: irsnd_set_freq 
(IRSND_FREQ_36_KHZ),
in uint8_t irsnd_ISR (void): irsnd_set_freq (IRSND_FREQ_38_KHZ); ist das 
so gewollt?

@Frank, kannst Du gelegentlich die Versionsnummern mit in die Quelltexte 
aufnehmen?

Gruß, Bernd

[Mod: Macros in C-Tags gesetzt]

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


Lesenswert?

Bernd schrieb:
> Kann es sein, dass in der Zeile (irsnd.c)
> ...
> was nicht stimmt?

Ich habe in Deinem Beitrag mal die Macros in C-Tags gepackt, damit die 
Operator-Zeichen von der Forumssoftware nicht verschluckt werden.

> p.s. falls ich richtig rechne, ergibt sich doch für F_CPU =20MHz und
> F_INTERRUPTS=15k ein Wert, der größer als 8 bit ist. Ist das gewollt?

Das sehe ich anders. Wegen
1
#  if F_CPU >= 16000000L
2
#    define AVR_PRESCALER                       8
3
#  else
4
#    define AVR_PRESCALER                       1
5
#  endif

ist bei F_CPU = 20MHz dann AVR_PRESCALER = 8.

Damit kommt für
1
#  define IRSND_FREQ_38_KHZ (IRSND_FREQ_TYPE) ((F_CPU / 38000 / AVR_PRESCALER / 2) - 1)
raus:
1
  (uint8_t) ((20000000 / 38000 / 8 / 2) - 1) = 31

Der Wert 31 passt durchaus in ein uint8_t. Das hatte ich damals schon 
berücksichtigt, dass bei größerem CPU-Takt hier ein Overflow auftreten 
könnte.

AVR_PRESCALER wird dann später auch genutzt beim Setzen von TCCR2 bzw. 
TCCR2B bzw. TCCR0 bzw. TCCR0B - je nach AVR-Typ.

> Wenn ich IRSND_FREQ_36[38]_KHZ = 250 setze, ist alles gut.

Das sieht jetzt aber so aus, als ob bei Dir AVR_PRESCALER auf 1 steht, 
also das obige #if nicht funktioniert. Oder hast Du in den Source 
eingegriffen?

Wo hast Du denn F_CPU gesetzt? Im Projekt selbst, also da, wo es 
hingehört? Ändere den Wert mal in 20000000UL - wie im Artikel empfohlen. 
Wenn ich es richtig in Erinnerung habe, konnten ältere avr-gcc solche 
großen Werte ohne den Zusatz "UL" nicht richtig verarbeiten.

Es könnte auch sein, dass das Makro IRSND_FREQ_38_KHZ generell in 
16-Bit-Integer gerechnet wird, solange da kein ausgezeichneter Long-Wert 
im Ausdruck angegeben wird. Die Angabe von 20000000UL (mit UL) könnte es 
also schon richten.

Welche avr-gcc-Version nutzt Du?
Welchen AVR-µC nutzt Du?

Du kannst leicht überprüfen, ob der avr-gcc den richtigen Wert für 
AVR_PRESCALER wählt.

Schreibe einfach mal:
1
#  if F_CPU >= 16000000L
2
#    define AVR_PRESCALER                       8
3
xxxxxxxx // produce syntax error
4
#  else
5
#    define AVR_PRESCALER                       1
6
#  endif

Wenn der avr-gcc den Syntax-Error findet, dann nimmt er den richtigen 
Wert.

Bernd schrieb:
> In void irsnd_init (void) steht für NEC: irsnd_set_freq
> (IRSND_FREQ_36_KHZ),
> in uint8_t irsnd_ISR (void): irsnd_set_freq (IRSND_FREQ_38_KHZ); ist das
> so gewollt?

Ja, das ist gewollt. In irsnd_init() wird erstmal ein Standardwert 
gesetzt, deshalb steht da auch im Kommentar "default frequency" 
dahinter. Da steht auch nichts von NEC, das ist ganz allgemein zu sehen.

Später, wenn Du das gewollte Protokoll auswählst, wird dann die 
protokollspezifische Frequenz genommen, also 38kHz für NEC, was auch 
richtig ist.

> @Frank, kannst Du gelegentlich die Versionsnummern mit in die
> Quelltexte aufnehmen?

Hm, hatte ich die nicht mal drin? Werde ich prüfen.

: Bearbeitet durch Moderator
von Bernd (Gast)


Lesenswert?

@Frank
F_CPU wird über eine h-Datei korrekt und als erstes in main.c 
inkludiert. Trotzdem ist der Wert an der Definitionsstelle AVR_PRESCALER 
F_CPU==1000000. Ursache dürfte bei mir delay.h sein. Da bringt der 
Compiler manchmal eine Warnung und manchmal nicht.

Danke für die schnelle Hilfe, komme nun (hoffentlich) allein weiter.

Gruß
Bernd

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Bernd schrieb:
> Ursache dürfte bei mir delay.h sein. Da bringt der Compiler manchmal
> eine Warnung und manchmal nicht.

Wenn delay.h meckert, hast Du eben nicht überall F_CPU definiert. Dann 
wird übrigens F_CPU blöderweise auf 1MHz gesetzt, statt mit einem Fehler 
auszusteigen.

IRMP und IRSND benutzen auch gar keine Delays.

F_CPU gehört als Option in Dein Projekt. Jede IDE für AVR bietet die 
Möglichkeit, F_CPU in den Projekteinstellungen zu definieren, damit es 
für alle C-Files einheitlich gilt. Wenn Du ohne IDE arbeitest, gehört es 
halt ins Makefile: -DF_CPU=20000000UL

Hast Du das mal mit "UL" hinter 20000000 ausprobiert?

: Bearbeitet durch Moderator
von Armin J. (arminj)


Lesenswert?

Hallo Frank,

ich wollte mal Irmp auf dem Arduiono laufen lassen um es mit 2 anderen 
Arduino IR libraries zu vergleichen.
Leider ist es nicht direkt lauffähig.
Es sind aber nur einige Änderungen zu machen, wenn man sich auskennt.

Ich würde es auch gerne als Arduio library zusammenstellen, da muss man 
nur eine library.properties und eine keywords.txt hinzufügen (hab ich 
beides schon gemacht) und leider alle mains entfernen, aber das wars 
auch schon.

Bestände da Interesse, es ist übrigens die beste der 3 Libraries und es 
wäre doch schade, sie einer größeren Community vorzuenthalten.

Wie könnte man das organisatorisch mit den Updates und dem 
zusammenstellen machen, Arduino verlangt ein Github Repo als Master. 
Soll ich / kann ich da noch das svn2github.py anpassen? Gibt es schon 
einen github account (für die Word Clock) den man benutzen kann?

Beste Grüße
Armin

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> Es sind aber nur einige Änderungen zu machen, wenn man sich auskennt.

Ich kenne mich mit den Arduino-Spitzfindigkeiten so gut wie gar nicht 
aus.

> Ich würde es auch gerne als Arduio library zusammenstellen, da muss man
> nur eine library.properties und eine keywords.txt hinzufügen (hab ich
> beides schon gemacht) und leider alle mains entfernen, aber das wars
> auch schon.

Das klingt sehr gut. Kannst Du gern machen!

> Bestände da Interesse, es ist übrigens die beste der 3 Libraries und es
> wäre doch schade, sie einer größeren Community vorzuenthalten.

Auf jeden Fall.

> Wie könnte man das organisatorisch mit den Updates und dem
> zusammenstellen machen, Arduino verlangt ein Github Repo als Master.
> Soll ich / kann ich da noch das svn2github.py anpassen? Gibt es schon
> einen github account (für die Word Clock) den man benutzen kann?

Das svn2github stammt nicht von mir. Nein, es gibt noch keinen github 
account. Soll ich einen anlegen?

von Stefan Z. (stefan_z)


Lesenswert?

Bin auch 100% für eine Arduino Version, hatte ich auch schon angeregt, 
liegt aber klar außerhalb meines Skillsets.
Da IRMP ja multi-platform ist, könnte man als Fernziel auch noch eine 
Integration in PlatformIO in Betracht ziehen, bzw. das von vornherein 
berücksichtigen. Der Arduino Editor ist ja schon extrem schrecklich im 
Vergleich zu jeder richtigen IDE…

von 900ss (900ss)


Lesenswert?

Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für 
Arduino zu verwenden.
Die Leute, die das nicht hinbekommen, die werden dann an anderer Stelle 
scheitern wo etwas konfiguriert werden muss oder doch trotz richtiger 
Konfiguration etwas nicht funktioniert.
Es ist so eine super gut funktionierende Library und ohne großen Aufwand 
fast überall so einzubinden.

von Stefan Z. (stefan_z)


Lesenswert?

900ss D. schrieb:
> Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für
> Arduino zu verwenden.

Es ist aber auch nicht elegant, so wie es jetzt ist.
GIT in PlatformIO eintragen, Compiler saugt die aktuelle / gewünschte 
Version.
Oder eben in der Arduino IDE direkt verfügbar.

Ich sehe den Nachteil nicht, das endlich mal offiziell und sauber zu 
machen.

von Joachim B. (jar)


Lesenswert?

900ss D. schrieb:
> Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für
> Arduino zu verwenden.

die irmp.c,v 1.164 2014/09/15 läuft bei mir astrein im Arduino

eine neuere Version hat die Arduino IDE überfordert

900ss D. schrieb:
> Es ist so eine super gut funktionierende Library und ohne großen Aufwand
> fast überall so einzubinden.

ja, aber sie ist in der aktuellen Version ziemlich fett geworden, ich 
hatte es ja versucht, aber die Arduino IDE hatte verweigert, die kam mit 
denganzen Verschachtelungen nicht mehr zurecht.

von Armin J. (arminj)


Lesenswert?

Das klingt doch ermutigend.
Dann will ich mal.

Frank es ist wohl am besten, wenn du ein Github Repository Irmp anlegst 
und mich https://github.com/ArminJo dafür auch gleich berechtigst.
Soll ich erst mal die Library dort zusammenbauen und später schauen wir 
dann, wie wir die Synchronisation mit svn hinkriegen?

Und noch 2 Sachen:
1. Der Arduino Standardport in den Sourcen ist zurzeit B6, das 
funktioniert garantiert auf keinem Arduino, da alle dort den Quarz 
haben.
Kann man das ändern, z.B. auf D6 oder D4, oder muss das 
rückwärtskompatibel bleiben?

2. Muss die irmp.c weiter eine C Source sein, oder kann ich auch ein cpp 
draus machen? Dann funktioniert nämlich das Logging aus der Tüte mit der 
Arduino Klasse Serial. Ist jetzt nicht sooo wichtig, wäre aber nett. 
Vielleicht auch nur für die Arduino Version...

Und wie lasse ich Dir Änderungen für das svn zukommen? Vielleicht baue 
ich erst mal die library und sage dann, welche Files ich wo geändert 
hab.

@900ss D. Natürlich läuft es nach einer Stunde im Arduino, wenn man das 
mit dem Port mal gerafft hat und die kapitalen Fehler in Arduino 
Beispiel bei der Protokollnamensausgabe nicht stören....

von 900ss (900ss)


Lesenswert?

Stefan Z. schrieb:
> das endlich mal offiziell und sauber zu machen

Wenn alle Software so sauber wie diese Library wäre, dann würde einiges 
besser funktionieren. ....kopfschüttel.....

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> ja, aber sie ist in der aktuellen Version ziemlich fett geworden, ich
> hatte es ja versucht, aber die Arduino IDE hatte verweigert, die kam mit
> denganzen Verschachtelungen nicht mehr zurecht.

Dann hast Du vermutlich etwas kaputtrepariert. Nenn doch bitte mal eine 
Fehlermeldung.

Was meinst Du mit "Verschachtelungen"? Die ganzen #ifdefs? Die sind doch 
überhaupt kein Problem für den Preprozessor, da kannst Du auch 
irgendeinen uralten nehmen.

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Dann hast Du vermutlich etwas kaputtrepariert. Nenn doch bitte mal eine
> Fehlermeldung.

ist schon wieder einige Jahre her, zwischen 2014 und jetzt sinds ja 
wieder >4 Jahre.
Ich probiere das nun nicht mit jeder IDE oder gcc Version neu.
Die IDE hatte ich irgendwann von 1.0.5 über 1.6.x zu 1.8.5 bis 1.8.8 
gewechselt.

Vielleicht war der Unterschied auch nur damals alles angekreuzt um einen 
Universaltester zu bauen, klappte. Später alles angekreuzt und die IDE 
schmierte ab.

> Was meinst Du mit "Verschachtelungen"? Die ganzen #ifdefs? Die sind doch
> überhaupt kein Problem für den Preprozessor, da kannst Du auch
> irgendeinen uralten nehmen.

mag ja sein, vielleicht ist meinem Rechner XP win32 mit 2GB Ram auch nur 
die Puste ausgegangen.

Ich sollte es mal mit der IDE 1.8.8 unter win7 64Bit und 8GB Ram noch 
mal versuchen, aber momentan habe ich zu viele andere Baustellen.

wenn ich was an meiner wordclock ändern will bleibe ich erst mal bei der 
IRMP von 2014, da die funktioniert mit nur einem Dekoder aus einer FB 
brauche ich da nichts anfassen.

: Bearbeitet durch User
von Stefan Z. (stefan_z)


Lesenswert?

900ss D. schrieb:
> Stefan Z. schrieb:
>> das endlich mal offiziell und sauber zu machen
>
> Wenn alle Software so sauber wie diese Library wäre, dann würde einiges
> besser funktionieren. ....kopfschüttel.....

Die Aussage bezog sich offensichtlich auf die Einbindung in das Arduino 
/ POI Rep System. Denn das finde ich deutlich sauberer als wenn jeder 
User das erst wieder für sich macht und nach Updates neu machen muss.

Dass IRMP super edel gebaut ist weiß ich natürlich.

von 900ss (900ss)


Lesenswert?

Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu 
unterstützen. Diese IDE ist das Grauen schlechthin. So einen furchtbaren 
und nichts beherrschenden Editor gibt es kaum ein zweites mal. Die IDE 
ist zwar im Laufe der Zeit etwas besser geworden aber immer noch 
grottig.

Und dann das Buildsystem hinter dem Arduino- Zeugs ist sowas von 
durcheinander, dass sucht auch seines gleichen. Wenn man 
Arduino-Projekte ohne die IDE bauen möchte, ist das sehr aufwendig bis 
es geht. Solch ein Chaos. Und komm mir keiner, es gibt ja ein Plugin für 
Eclipse. Das ist seit Jahren buggy. Ich habe es mehrmals probiert. Taugt 
nicht.

Nun, Arduino ist zum schnellen Basteln erfunden worden und genau dafür 
ist sie auch gut und hat da einen guten Platz.
Aber leider steigen alle Hersteller auf dieses Zeug ein, alles ist 
plötzlich Arduino kompatibel und man kommt um dieses Zeug kaum herum, 
selbst im professionellen Bereich. Und diese Entwicklung finde ich übel.
Und jetzt auch noch IRMP......ich heul gleich ;)

So, war auch etwas OT aber musste ich loswerden. :)

von Armin J. (arminj)


Lesenswert?

900ss D. schrieb:
> Und komm mir keiner, es gibt ja ein Plugin für
> Eclipse. Das ist seit Jahren buggy. Ich habe es mehrmals probiert. Taugt
> nicht.

Ich empfehle da Sloeber: http://eclipse.baeyens.it/ , mach ich mit 
meinen Schülern...
Ist Arduino Ökosystem mit echter IDE.

von Stefan Z. (stefan_z)


Lesenswert?

900ss D. schrieb:
> Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu
> unterstützen. Diese IDE ist das Grauen schlechthin. So einen furchtbaren
> und nichts beherrschenden Editor gibt es kaum ein zweites mal. Die IDE
> ist zwar im Laufe der Zeit etwas besser geworden aber immer noch
> grottig.
Darum PlatformIO!
MS Visual Studio Code kostet auch nix und kann alles - wenn man 
rausfindet wie…

> Und dann das Buildsystem hinter dem Arduino- Zeugs ist sowas von
> durcheinander, dass sucht auch seines gleichen. Wenn man
> Arduino-Projekte ohne die IDE bauen möchte, ist das sehr aufwendig bis
> es geht. Solch ein Chaos.
Durchaus, aber inzwischen tuts das schon ganz geschmeidig, wenn man die 
Libraries gekonnt auswählt. Wie gesagt: PlatformIO.

> Nun, Arduino ist zum schnellen Basteln erfunden worden und genau dafür
> ist sie auch gut und hat da einen guten Platz.
Eben. Dank der vielen Libraries weiß man zumindest schnell ob ein Teil 
funktioniert.

> Aber leider steigen alle Hersteller auf dieses Zeug ein, alles ist
> plötzlich Arduino kompatibel und man kommt um dieses Zeug kaum herum,
> selbst im professionellen Bereich. Und diese Entwicklung finde ich übel.
> Und jetzt auch noch IRMP......ich heul gleich ;)
Aber, aber, wer wird denn gleich Tränen vergießen?
IRMP bleibt doch guter Code, jetzt halt noch erweitert um auf Arduino zu 
compilieren - was ja wie erwähnt mit einer Stunde basteln eh schon geht.

Am Ende ists doch eh nur C(++) Code der auf einer Zielplattform durch 
den Compiler raschelt. Wäre halt nice wenn ich ein neues Projekt 
aufmache, den GIT link in die .ini paste, dann ein paar Zeilen Code und 
ZACK! habe ich eine IRMP Remote auf einem Arduino, ESP, etc.

Man darf auch nicht vergessen, dass nicht nur die µCs schneller/fetter 
werden (Moore's Law), sondern sich auch die Komplexität/Macht der 
Entwicklungstools alle paar Jahre verdoppelt. Was ja bei den Anwendungen 
heute auch ein wichtiger Vorteil ist!
Vor 15 Jahren musste man noch einen riesen Aufriss für eine 
Multimediaanwendung machen, heute code ich sowas an einem Abend im 
Browser - inkl. Video-In, GPU Rendering und kompletter GUI.

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


Lesenswert?

Armin J. schrieb:
> Frank es ist wohl am besten, wenn du ein Github Repository Irmp anlegst
> und mich https://github.com/ArminJo dafür auch gleich berechtigst.

Habe ich gemacht: https://github.com/ukw100/IRMP

> Soll ich erst mal die Library dort zusammenbauen und später schauen wir
> dann, wie wir die Synchronisation mit svn hinkriegen?

Jepp.

> 1. Der Arduino Standardport in den Sourcen ist zurzeit B6, das
> funktioniert garantiert auf keinem Arduino, da alle dort den Quarz
> haben.
> Kann man das ändern, z.B. auf D6 oder D4, oder muss das
> rückwärtskompatibel bleiben?

Klar kannst Du das ändern. Der Default muss zu nichts kompatibel sein.

> 2. Muss die irmp.c weiter eine C Source sein, oder kann ich auch ein cpp
> draus machen? Dann funktioniert nämlich das Logging aus der Tüte mit der
> Arduino Klasse Serial. Ist jetzt nicht sooo wichtig, wäre aber nett.
> Vielleicht auch nur für die Arduino Version...

Für die Arduino-Version ist das okay.

> Und wie lasse ich Dir Änderungen für das svn zukommen? Vielleicht baue
> ich erst mal die library und sage dann, welche Files ich wo geändert
> hab.

Das wäre am besten. Bei größeren Änderungen sind diff-Files hilfreich.

Dank und Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

900ss D. schrieb:
> Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu
> unterstützen.

Ich kann Deine Meinung ja verstehen, aber es tut ja keinem weh, Arduino 
zusätzlich zu unterstützen. Es wird ja weiterhin auch ohne Arduino 
gehen.

von 900ss (900ss)


Lesenswert?

Frank M. schrieb:
> Es wird ja weiterhin auch ohne Arduino
> gehen.

Das ist auch gut so :)

Noch etwas OT:
Das ist bei vielen Libraries oder Projekten leider nicht der Fall. Man 
kann sie ohne Arduino nicht bauen, weil dort viele Abhängigkeiten zu 
Arduino bestehen. Man kann es dann besser neu machen. Bei IRMP ist alles 
in sich geschlossen, da wird jetzt Arduino "oben drüber" gebaut. Dann 
ist es auch ok. Aber bei vielem ist es eben nicht so und dadurch ist man 
dann zu dem Zeugs verdonnert oder muss es neu machen. Es gibt einige 
gute Libs für Arduino aber man kann sie nur mit Arduino nutzen, obwohl 
es ja nur Code für ein AVR (o.a.) uc ist. Das stört mich. Ohne Arduino 
kann bald niemend mehr ein Projekt bauen.

Stefan Z. schrieb:
> Eben. Dank der vielen Libraries weiß man zumindest schnell ob ein Teil
> funktioniert.

Hmmm... bedingt stimme ich dir zu. Man weiß oft nicht, wenn es nicht 
funktioniert, ob es nicht doch die Library ist.

Beitrag #5791752 wurde von einem Moderator gelöscht.
von Armin J. (arminj)


Lesenswert?

So die Arduino library ist fertig!
https://github.com/ukw100/IRMP

Jetzt werde ich noch ein bischen an der Doku schreiben.

@Frank, guck dir mal die library.properties an, ob die 
Verantwortlichkeiten und Mailadressen in deinem Sinne sind. Die Zeile 
paragraph= werde ich noch im Rahmen der Doku erweitern.

Beitrag #5792177 wurde von einem Moderator gelöscht.
von Armin J. (arminj)


Lesenswert?

Hi,
ich versuche gerade IRMP zu verstehen und bin dabei über folgendes 
gestolpert:
1
                    {
2
#ifdef ANALYZE
3
                        ANALYZE_PRINTF ("protocol = UNKNOWN\n");
4
#endif // ANALYZE
5
6
                        irmp_start_bit_detected = 0;                            // wait for another start bit...
7
                    }
8
                    if (irmp_start_bit_detected) {
für mich sieht das so aus, dass die Bedingung immer false ist, oder 
übersehe ich da was?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> Hi, ich versuche gerade IRMP zu verstehen und bin dabei über
> folgendes gestolpert:                    {
> #ifdef ANALYZE
>                         ANALYZE_PRINTF ("protocol = UNKNOWN\n");
> #endif // ANALYZE
>
>                         irmp_start_bit_detected = 0;
> // wait for another start bit...
>                     }
>                     if (irmp_start_bit_detected) {
>
> für mich sieht das so aus, dass die Bedingung immer false ist, oder
> übersehe ich da was?

Ja, Du übersiehst die Zeile direkt darüber, also hier die 1. Zeile:
1
                    else
2
#endif // IRMP_SUPPORT_RCMM_PROTOCOL == 1
3
                    {
4
#ifdef ANALYZE
5
                        ANALYZE_PRINTF ("protocol = UNKNOWN\n");
6
#endif // ANALYZE
7
                        irmp_start_bit_detected = 0;                            // wait for another start bit...
8
                    }
9
10
                    if (irmp_start_bit_detected)
11
                    {

In das obige "else" geht er nur, wenn ganz spezielle Bedingungen 
vorliegen. Beachte auch, dass die noch weiter darüberliegenden 
if-Bedingungen noch ein "else" darüber stehen haben - je nachdem, welche 
Protokolle aktiviert sind.

Ja, die vielen Preprocessor-Statements machen das ziemlich 
unübersichtlich. Aber nur so kann man den Code auf die tatsächlich 
genutzten Protokolle reduzieren, damit das auch noch auf einem ATTiny 
läuft.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:


Frank M. schrieb:
> In das obige "else" geht er nur

DANKE!

Bei mir steht das aktive else ca 650 Zeilen vorher, das hab ich glatt 
übersehen ;-).
Aber alles gut, ich würde es genauso machen...

Ich versuche gerade IRMP (erstmal nur NEC) mit PinChangeInterrupt zu 
betreiben. Klappt schon recht gut.

von Armin J. (arminj)


Lesenswert?

So,

ich bin so weit, die Library https://github.com/ukw100/IRMP ist jetzt 
schön und einfach gemacht.

Wenn Frank zustimmt, würde ich dann ein Release bauen, und beantragen, 
es als  Arduino Library aufzunehmen.

von Boris S. (cool-man)


Lesenswert?

Hallo Frank,
hab Probleme beim kompilieren des Arduino Samples. Als Board hab ich 
Olimex Mod Wifi ESO 8266DEV ausgewählt und bin nur auf kompilieren 
gegangen. Wird jedoch abgebrochen da /util/setbaud.h nicht gefunden 
wird. Diese hab ich versucht nach zu installieren wird aber weiterhin 
nicht gefunden. Hast du eine Idee ?

(Eigenltich möchte ich nur IR Codes analysieren, und wollte es auf dem 
Wemos D1 Mini zum laufen bringen).

Installiert habe ich die IRMP.zip  von dieser Webseite.

Grüsse

von E. K. (eku)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

ich habe hier eine Onkyo RC-911R FB, die das NEC-Protokoll verwendet - 
zumindest alle Tasten bis auf eine. Im oberen Bereich befinden sich 12 
Tasten zur Selektion der Quelle, die letzte davon ist mit Bluetooth 
beschriftet und wird von IRMP nicht erkannt. Angehangene Protokolldatei 
wurde mit 15kHz Taktung aufgezeichnet. Wirf bitte einen Blick darauf.

Danke vorab.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Die Bluetooth-Taste benutzt auch das NEC-Protokoll. Allerdings verletzt 
sie die Regel, dass im vierten und letzten Byte die Bits invertiert zum 
dritten Byte wiederholt werden.

Bits im 3. Byte: 00001010
Bits im 4. Byte: 01110000

Aus diesem Grund wird das Ergebnis verworfen, da von einem 
Übertragungsfehler ausgegangen wird.

Bei allen anderen Tasten wird die Regel befolgt, z.B. bei PHONO:

Bits im 3. Byte: 11010000
Bits im 4. Byte: 00101111

Hier sieht man schön, wie 1 und 0 immer übereinander bzw. untereinander 
stehen.

Wie könnte man jetzt lösen, dass die Taste trotzdem erkannt wird? Ich 
möchte die obige Regel eigentlich nicht außer Kraft setzen, denn sie 
passt sonst immer. Noch niemand hat mir je einen Code präsentiert, wo 
auch diese Regel verletzt wird. Außerdem ist sie im Internet gut 
dokumentiert.

Ich schlage folgendes vor:

Ich führe ein neues Protokoll "ONKYO" ein, auf welches gewechselt wird, 
wenn die Regel verletzt wird. Dann bekommt man nicht nur 2 Bytes für die 
Adresse (Extended NEC), sondern auch 2 Byte (statt nur eins) für das 
Kommando.

Interessant ist bei dieser FB auch, dass nicht nur die BLUETOOTH-Taste 
eine abweichende Adresse benutzt, sondern auch die Taste BD/DVD. Kann es 
sein, dass man diese FB für verschiedene Onkyo-Geräte verwenden kann?

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


Lesenswert?

Boris S. schrieb:
> hab Probleme beim kompilieren des Arduino Samples. Als Board hab ich
> Olimex Mod Wifi ESO 8266DEV ausgewählt und bin nur auf kompilieren
> gegangen. Wird jedoch abgebrochen da /util/setbaud.h nicht gefunden
> wird.

Ich vermute mal, dass util/setbaud.h nur für AVRs existiert. Ich selbst 
habe auch nicht den Arduino-Port gemacht, sondern Armin J. Du findest 
seinen letzten Beitrag hier genau über Deinem. Vielleicht kann Armin ja 
noch etwas dazu sagen.

Ich selbst kann nur vermuten, dass der Arduino-Code tatsächlich nur für 
AVRs getestet wurde.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Ich führe ein neues Protokoll "ONKYO" ein, auf welches gewechselt wird,
> wenn die Regel verletzt wird.

Gesagt, getan, ist online als Version 3.1.4.

Viel Spaß,

Frank

von Armin J. (arminj)


Lesenswert?

Hallo Frank,

ich teste gerade die ESP Versionen für Arduino und dabei ist mir 
aufgefallen, dass das PENTAX + GREE Protokoll inkompatibel mit dem Lego 
+ RCMM Protokoll ist, weil es bei #define F_INTERRUPTS 20000 zu 8 Bit 
Überlauf bei den Konstanten PENTAX_START_BIT_PULSE_TIME und 
GREE_START_BIT_PULSE_TIME kommt.
Sollte man die beiden Protokolle nicht genauso bei 20000 abschalten, wie 
Lego + RCMM bei 15000 abgeschaltet wird?

von Boris S. (cool-man)


Lesenswert?

Hallo Armin,

ich versuche IRMP es auf eine ESP8266 zum laufen zu bringen, in meinem 
Fall ein Wemos D1 Mini. Aber wenn ich auch das Borad Olimex Mod Wifi ESO 
8266DEV nehme, kommen diverse Fehlermeldungen. z.B. liegt 
/util/setbaud.h nicht vor. Ich glaube das brauche ich eigentlich nicht. 
Mir geht es spezielle um ACP25 Protokoll (hab ein baugleiche Klimaanlage 
von Trotec).

Hast du eine Idee ?

Grüss

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Armin,

Armin J. schrieb:
> Sollte man die beiden Protokolle nicht genauso bei 20000 abschalten, wie
> Lego + RCMM bei 15000 abgeschaltet wird?

Ja, das ist eine gute Idee. Ich habe es gemacht und ins SVN als Version 
3.1.5 eingecheckt. Die Änderungen sind alleinig in irmp.h:
1
#if IRMP_SUPPORT_PENTAX_PROTOCOL == 1 && F_INTERRUPTS > 16000
2
#  warning F_INTERRUPTS too high, PENTAX protocol disabled (should be max 16000)
3
#  undef IRMP_SUPPORT_PENTAX_PROTOCOL
4
#  define IRMP_SUPPORT_PENTAX_PROTOCOL          0
5
#endif
6
7
#if IRMP_SUPPORT_GREE_PROTOCOL == 1 && F_INTERRUPTS > 16000
8
#  warning F_INTERRUPTS too high, GREE protocol disabled (should be max 16000)
9
#  undef IRMP_SUPPORT_GREE_PROTOCOL
10
#  define IRMP_SUPPORT_GREE_PROTOCOL            0
11
#endif

P.S.
Ich habe hier mal 16000 als obere Schranke gewählt. Das sollte reichen, 
um den Wert für den Startbit-Counter noch unter 256 zu halten. 18000 
sollte zwar auch noch gehen, könnte aber knapp bei späteren 
Toleranzänderungen werden.

Startbit-Länge bei Pentax ist 13 msec.

Dann gilt für den Zählwert:
1
0.013 * 16000 = 208
2
208 + 5% = 218.4

: Bearbeitet durch Moderator
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.