mikrocontroller.net

Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Gruß,
> Frank

brauchst du noch was ?

hier die KASEIKYO Panasonic VCR FB

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal,
> Gruß,
> Frank

das wundert mich nun etwas,

sagte ich nicht das an dem MAX nur +5 und NULL rauskamen ?

nun nachdem ich den Schluss unter dem SMD PAD (MAX233 9 GND nach 10 
irgendein int. Kondi) gefunden hatte habe ich jetzt endlich +-10V

aber wenn die Scans schon vorher gut waren soll das nicht weiter stören

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hier die KASEIKYO Panasonic VCR FB

Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay. 
55 Scans weisen einen abweichenden Herstellercode auf, welcher für 
Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss 
erstellt worden?

Macht nix, der Rest ist echt brauchbar.

Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie 
möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich 
lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den 
ersten Tasten ;-)

Dank und Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> http://de.wikipedia.org/wiki/Jitter

Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
1. Messung: 000000000000000111111111000000000011111111110000000
2. Messung: 000000000000000011111111100000000111111111100000000
3. Messung: 000000000000001111111110000000000011111111110000000

Trotzdem danke für den interessanten Link.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits) und implementiere das
> JVC-Protokoll.

Anbei die geänderten Sources zum Test.

Neu:

 - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
   ausgewertet

 - Neues Protokoll: JVC

Viel Spaß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist.

hmm, welche ?, könnte die ja nachliefern, hast ja die #Headerzeile dazu

>Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?

ja leider, wollte erst liefern, dann hat mich der Pegel doch nicht ruhen 
lassen und ich ging auf Fehlersuche

> Macht nix, der Rest ist echt brauchbar.
> Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie
> möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich
> lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den
> ersten Tasten ;-)
> Dank und Gruß,
> Frank

na ja man wartet immer auf Bestätigung, ich hab ne LED Quittung 
eingebaut, 1s LED Blink wenn Code erkannt, nur im Logging Mode erkennt 
er ja nix und ich warte vergebens und im HTERM kommen die Daten 
offensichtlich erst verzögert, also bleib ich zu lang drauf und dann 
wollen die Daten nicht enden

einige Tasten sind auch versenkt um Fehlbedienungen zu meiden, deren 
Druckpunkt ist schwer zu fühlen

ich weiss, alles Ausreden, aber wer so lange im Beruf ist der kann wohl 
nicht anders

danke und gruß zurück
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Frank M. schrieb:
> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
> (Berücksichtigung der 4 System-Bits)
> Neu:
>  - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
>    ausgewertet

hmm, aber scheinbar noch etwas wackelig (muss ich mir meine 
Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht 
genau ausgerichtet ist und man nicht lange drückt erkennt er viele 
Zufallscodes, ist nicht so stabil wie RC5, da kenne ich nur ja / erkannt 
oder nein / eben nicht, aber Zufallscodes seh ich nie


> und implementiere das
> JVC-Protokoll.
>  - Neues Protokoll: JVC
ah, erst verwundert, wird nicht angezeigt, dann aber

meine JVC wird erkannt , A + C wird angezeigt aber unter Code nicht JVC 
!

> Viel Spaß,
> Frank

danke den hab ich schon

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um
> Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
Nein, nicht bei dir.
Nur bei Joachim klang es danach, dass er damit die 
Spannungs-Sonderheiten wegen seiner MAX-Beschaltung meinte.

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> meine JVC wird erkannt ,

Gut.

> A + C wird angezeigt

Auch gut.

> aber unter Code nicht JVC

Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über 
ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört 
nicht wirklich zu den IRMP-Sources dazu, denn:

irmp_get_data liefert lediglich

   uint8_t protocol
   uint16_t address
   uint16_t command

protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle 
drin.

Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und 
dort den String "JVC" eintragen.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> hmm, aber scheinbar noch etwas wackelig (muss ich mir meine
> Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht
> genau ausgerichtet ist und man nicht lange drückt erkennt er viele
> Zufallscodes, ist nicht so stabil wie RC5,

Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem 
ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen 
36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch 
und die Fehlerquote nimmt zu.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über
> ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört
> nicht wirklich zu den IRMP-Sources dazu, denn:
>
> irmp_get_data liefert lediglich
>
>    uint8_t protocol
>    uint16_t address
>    uint16_t command
> protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle
> drin.
> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und
> dort den String "JVC" eintragen.
> Gruß,
> Frank

sowas dachte ich schon, nur hab ich die Zuweisung nicht gefunden

aber nun

static char 
*Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern

wie das ich finde nirgends eine Zuweisung von Array auf 20

soweit wie ich C gelernt habe ist durch anhängen von ,"JVC" das Array 
schon ab compile vergrößert, da es ja statisch initialisiert wird, eine 
seperate Zuweisung dürfte nicht (nötig) sein und finde ich auch nicht

hmm es funzt jedenfalls noch nicht

ich tippe auf NEC erkannt und JVC eben nicht

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem
> ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen
> 36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank


TSOP 1736 , aber mein Scan an einer BPW21 lieferte 36 kHz Schwingungen

ich könnte ja noch mal einen OP vorschalten und eine FFT machen

gruss
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
peinlich peinlich

sind ja nur 14 Text STR definiert, hab nicht nachgezählt

musste also 6x "", einfügen das 20 auf "JVC" zeigt ......

ja ich bin aus der Übung und sehe nicht immer alles (sofort)

gruss
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> aber nun
>
> static char
> *Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)" 
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};

Du hast "JVC" an 14. Stelle statt an 20. Stelle eingetragen, damit das 
Array auch nur auf 14 Elemente vergrößert.

>
>> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern
>
> wie das ich finde nirgends eine Zuweisung von Array auf 20

Eben, die Dimension von Proto[] ist nicht angegeben.

> hmm es funzt jedenfalls noch nicht

Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und 
sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der 
Protokolle 1-20 in irmp.h.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Eben, die Dimension von Proto[] ist nicht angegeben.
> Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und
> sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der
> Protokolle 1-20 in irmp.h.
> Gruß,
> Frank


hatte ich doch schon,

Joachim B. schrieb:
> peinlich peinlich
> sind ja nur 14 Text STR definiert, hab nicht nachgezählt
> musste also 6x "", einfügen das 20 auf "JVC" zeigt ......
> ja ich bin aus der Übung und sehe nicht immer alles (sofort)
> gruss
> jar



ich denke ich werde trotzdem noch mal einen Frequenz Scan aller FB 
machen

wie geschrieben mit BPW21 OP und FFT
und mal alle meine FB scannen

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Problem ist, dass Kaseikyo mit
>> 56 kHz
> moduliert wird und der TSOP mit seinen 36kHz bzw. 38kHz
> ziemlich daneben liegt.
> und die Fehlerquote nimmt zu.
> Gruß,
> Frank

wo hast du die Daten her ?

ich kann hier machen was ich will

ich messe burst von 26-28 µs was 35,9 - 38,5 kHz gibt

übrigens alle
>> meine Kaseikyo liegen eher bei 36 kHz ,
nur die JVC scheint um 38 kHz zu liegen

bin verwirrt von deinen 56 kHz

gruss
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> bin verwirrt von deinen 56 kHz

Laut
http://www.mikrocontroller.net/attachment/4246/IR-...

auf Seite 26 (hier "Japan-Code" genannt) sind es 56 kHz. Da habe ich das 
her.

Aber es gibt noch eine zweite Quelle, nach welcher ich das 
Kaseikyo-Protokoll implementiert habe, nämlich:

http://www.roboternetz.de/phpBB2/files/entwicklung...

Und tatsächlich wird hier von 38kHz (auf Seite 8) geredet. Entweder 
werden verschiedene Modulationsfrequenzen bei Kaseikyo eingesetzt oder 
meine erste Quelle hat schlichtweg einen Fehler. Leider habe ich 
persönlich keine Kaseikyo-kompatible FB, kann daher nix dazu sagen.

Leider habe ich auch nicht mehr Doku als diese beiden Quellen. Wenn Du 
da noch irgendeine Doku ausgraben könntest, würde ich mich freuen.

Gruß,

Frank

Autor: Wolfgang Dunczewski (midi-rakete) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein 
UFS-922 Fernbedienung. Wurde das Problem gelöst? Ich habe beim Bau einer 
FB diesen Code enträtselt.....

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Leider habe ich auch nicht mehr Doku als diese beiden Quellen. Wenn Du
> da noch irgendeine Doku ausgraben könntest, würde ich mich freuen.
> Gruß,
> Frank


http://www.sbprojects.com/knowledge/ir/ir.htm
http://www.hifi-remote.com/forums/viewtopic.php?t=6401
http://www.hifi-remote.com/forums/viewtopic.php?t=...
http://www.google.de/url?sa=t&source=web&cd=6&ved=...
http://usa.denon.com/AVR-4308CI_IRCodes.pdf


sehr interessant:
http://ecee.colorado.edu/~mcclurel/vishay_ir_data_...

Kaseikyo 56 kHz muss ein Fehler sein, finde nix, ausser beim Klaus

aber es gibt:
TCE RCA Code (56.7 kHz)

Vishay sagt auch nur:
Kaseikyo Matsushita Code (36.7kHz)

gruss
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach ja , vergessen

irgendwer schrieb mal was von 450 kHz IR Modulation, aber ich bin nicht 
sicher ob das so stimmt, weil :

einige modilieren auch mit x-facher Frequenz wegen oversampling

da können die paar 100 kHz auch vielfache von 36 oder 38 - 40 oder 56 
kHz sein

ggffs kann man später mal in IRSND oversampling einstellen und schauen 
was aus den TSOP rauskommt, ich vermute mit exakt doppelter oder gerade 
Vielfache werden die auch output liefern.......

gruss
jar

Autor: Samuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> peinlich peinlich
Spiegelt deinen Auftritt hier gut wieder.
Du hast mal von jar nüscht Ahnung.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Samuel schrieb:
> Joachim B. schrieb:
>> peinlich peinlich
> Spiegelt deinen Auftritt hier gut wieder.
> Du hast mal von jar nüscht Ahnung.

danke danke, von nüscht würde ich nüscht sagen.....

OK ich bin nicht so der Softi und aus der Übung

aber war der Kommentar nötig ?

na egal wer anonym so was schreibt braucht das wohl

ich komm schon klar, hab halt nicht die Arrays ausgezählt

wer so perfekt ist wie du kann sich anmelden und auch besser Fragen 
beantworten und zum Rest höflich schweigen....

freundlichen gruss
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang Dunczewski (midi-rakete) schrieb:
> Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein
> UFS-922 Fernbedienung. Wurde das Problem gelöst?

Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich 
dokumentiert ist. IRMP unterstützt nur den sog. Mode 0 von RC6, siehe 
auch:

http://www.sbprojects.com/knowledge/ir/rc6.htm

> Ich habe beim Bau einer FB diesen Code enträtselt.....

Dann schieß mal los.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> http://www.sbprojects.com/knowledge/ir/ir.htm

Keine Infos zum Kaseikyo-Protokoll.

> http://www.hifi-remote.com/forums/viewtopic.php?t=6401

Keine Infos zum Kaseikyo-Protokoll.

> 
http://www.hifi-remote.com/forums/viewtopic.php?t=...

Keine Infos zum Kaseikyo-Protokoll.

> http://www.google.de/url?sa=t&source=web&cd=6&ved=.........

Nette Tabelle, aber keine Infos zum Kaseikyo-Protokoll selbst.

> http://usa.denon.com/AVR-4308CI_IRCodes.pdf

Dito.

> sehr interessant:
> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_...

Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird. 
Werde ich im IRMP-Artikel anpassen.

> Kaseikyo 56 kHz muss ein Fehler sein, finde nix, ausser beim Klaus

Der hat es wahrscheinlich von mir....

Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.

Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem 
IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht 
jeden Google-Treffer einfach hier reinzukopieren ;-)

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


Gruß,

Frank

Autor: Wolfgang Dunczewski (midi-rakete) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich..
>
> http://www.sbprojects.com/knowledge/ir/rc6.htm
>
>> Ich habe beim Bau einer FB diesen Code enträtselt.....
>

Ich fand im Web Infos über den RC-6 Mode 6A 20:

[[http://www.guiott.com/wrc/RC6-6.html]]

mit 20 Bit Nutzrate

Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a 
32), aber nicht nach Norm:

Die FB vom UFS-922 macht folgendes:

Leader Pulse (ok)
Start Bit (ok)
Mode Bits 2,1,0 (H,H,L = Mode 6)
Trailer Bit: Flanke immer L>H (nicht offiziell, soll normal toggeln)

Dann folgen 4 Bytes:

Das erste Byte ist immer 10000000 (von links nach rechts wird gesendet)
Das zweite Byte ist immer 01000110

Das dritte Byte enthält das Toggle-Bit TB und
die Ebene/Adresse falls man mehrere FBs hat

TB AD2 AD1 AD0 0000

also normal bei Adresse 0:

10000000
und abwechselnd
00000000

Eigenlich gehört das Togglebit an eine andere Stelle. Das Trailer Bit 
soll eigentlich toggeln. Aber Kathrein lässt ein Bit togglen. Deshalb 
funtioniert fast keine programmierbare FB mit dem Kathrein.

Und im 4. Byte kommen die Befehe 00-FF

nnnnnnnn

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

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang Dunczewski (midi-rakete) schrieb:

> Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a
> 32), aber nicht nach Norm:
> [...]

Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Joachim B. schrieb:
>> sehr interessant:
>> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_...
>
> Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird.
> Werde ich im IRMP-Artikel anpassen.

> Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.
> Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem
> IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht
> jeden Google-Treffer einfach hier reinzukopieren ;-)
> Gruß,
> Frank

immerhin hab trotzdem noch was gefunden, sorry das es mir nicht möglich 
war alle Infos mit den vorhandenen abzugleichen, ich hab hier grad Land 
unter und bin deswegen nur sehr begrenzt konzentriert dabei, ich hoffe 
das geht trotzdem i.O.

gruss
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.
> Gruß,
> Frank

hallo,

wie siehts aus mit KASEIKYO im IRSND ?

würde dann bald ein IRSND Modul aufbauen für

PC -> RS232 -> Atmel IRSND -> IS Sendediode

ich grübel gerade ob der Umweg über Atmel sein muss weil,

kennst du den CT Artikel IRDEO ?
http://www.heise.de/ct/projekte/Fernregie-IRdeo-284185.html
http://irdeo.de/

dort wurde IR Empfang und Senden mit der seriellen Schnitte gemacht, 
funzte so leidlich (sogut win das eben zulässt) mit W2k und XP musste 
der IO (giveio o.ä.) Treiber installiert werden
http://irdeo.de/ntdriver.zip
GIVEIO.SYS (Dale Roberts), LOADDRV (Paula Tomlinson)


senden war übrigens tricky, die IR Modulation 36  38  40 kHz wurde per 
Baudrate / respektive geschickte 1/0 Wahl eingestellt, je nach 1/0 Folge 
und Baudrate ist ja quasi jede IR Modulation machbar, die Start oder 
Stoppbits, wenn sie einzeln erfolgen, scheinen nicht zu stören

leider war es nur eine lernbare FB welche die Codes nur gelernt wieder 
abspielen konnte und mit der Erkennung haperte es leider auch, da ist 
dein Projekt viel weiter und besser, aber ggffs kann man die beiden 
Konzepte zusammenbringen

für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232 
Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

freundliche Grüße
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> wie siehts aus mit KASEIKYO im IRSND ?

Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche 
Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32 
Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.

Ich warte daher immer noch auf die Scan-Dateien Deiner 3 
Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen 
angekündigt hattest.

Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal 
schrieb.

Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber 
noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden 
und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von 
Dir gesehen.

> kennst du den CT Artikel IRDEO ?

Ja, habe ich mal vor Jahren überflogen.

> für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232
> Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)

Sorry, wüsste ich jetzt nicht, wie. Du kannst natürlich den IRSND-Code 
auf eine andere Plattform portieren.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Joachim B. schrieb:
>> wie siehts aus mit KASEIKYO im IRSND ?

> Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche
> Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32
> Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.
>
> Ich warte daher immer noch auf die Scan-Dateien Deiner 3
> Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen
> angekündigt hattest.
>
> Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal
> schrieb.
>
> Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber
> noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden
> und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von
> Dir gesehen.
> Gruß,
> Frank


war wohl ein Missverständniss

auf die VCR FB hab ich nun kein Zugriff mehr, ich hab noch im Ohr, sind 
zwar Störungen drin aber brauchbar

Frank M. schrieb:
> Joachim B. schrieb:
>> hier die KASEIKYO Panasonic VCR FB
>
> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für
> Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss
> erstellt worden?
>
> Macht nix, der Rest ist echt brauchbar.
> Dank und Gruß,
> Frank

die 161 scans reichen nicht von der VCR ?

Ich kann also nur noch
Panasonic TV liefern und Panasonic HDrec/DVD

muss mal sehen ob ich den VCR noch mal bekomme

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> die 161 scans reichen nicht von der VCR ?

Wenn es diese FB ist, welche Du über IRSND auch emulieren willst - ja, 
dann reicht es.

> Ich kann also nur noch
> Panasonic TV liefern und Panasonic HDrec/DVD

Wenn Du die für IRSND nicht brauchst, dann nicht. Wäre aber trotzdem 
nett, wenn Du davon jedoch auch noch je 10 Scans machen könntest, dann 
kann ich das allgemeiner in IRSND machen.

Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.
> Gruß,
> Frank

eigendlich genau diese

Panasonic HDrec/DVD

und die sollst du noch mal bekommen

zur Fernprogrammierung über PC


TV hat ja aus der Ferne irgendie keinen Sinn, da könnte ich gleich winTV 
im Rechner starten

ich hab den IRMP so schön auf 4x MiMh Akku laufen, damit wäre mobiles 
logging auch für den VCR möglich, aber seit der MAX dranhängt läuft der 
TSOP nicht mehr, der MAX braucht 1W sind 200mA und zieht offensichtlich 
den Pegel runter, ohne externe Versorgung geht da leider nix

ich grübel gerade ob ich den MAX rausschmeisse und einfach mit 2 Trasis, 
simple RS232 Konverter baue
http://picprojects.org.uk/projects/simpleSIO/ssio.htm

1W ist schon heftig
alternativ ginge ja die RS232 anzuzapfen, einige Dioden nach P5 sollte 
wieder mehr Strom liefern, DTR und RTS kann man ja setzen, nur auf + 
setzen , sollten ja ungefähr je 20mA liefern können

so ähnlich hatte ich auch meine PONY Elektronik aus der parallelen 
gespeist, einfach 15 BAT42 an jede signalführende Leitung auf einen 
Pufferkondi, reicht für CMOS Logik und Signal LED 3mA

Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Halbzeit

versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

musste leider im logging CR LF einfügen, ich hoffe das stört nicht

morgen verm. den Rest

freundliche Grüße
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich

Sehr sauberer Scan: keine Störungen, keine Erkennungsfehler. Bei der 
Gelegenheit habe ich erkannt, dass bei Kaseikyo auch bei kurzen 
Tastendrücken immer mindestens zwei Frames verschickt werden. Bei 
längeren Tastendrücken werden drei Frames und mehr gesandt. Ich hatte 
das bisher zwar schon immer vermutet, hatte aber da noch nie geeignete 
Kaseikyo-Scans.

Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste 
Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren 
Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst 
bekommt man immer einen langen Tastendruck zurück - auch wenn man die 
Taste nur kurz gedrückt hat.

> musste leider im logging CR LF einfügen, ich hoffe das stört nicht

Passt perfekt.

Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht 
genau sagen. Habe im Moment viel um die Ohren.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so der 2te Teil

viel Erfolg mit den CRC

gruss
jar

Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste
> Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren
> Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst
> bekommt man immer einen langen Tastendruck zurück - auch wenn man die
> Taste nur kurz gedrückt hat.

gibt es da keine Toggel Bits wie in RC5 ? dort klappt das hervorragend 
mit der Toggelbitauswertung, habe meinen Timer ja mit

Peters RC5 gebaut
Beitrag "Fernbedien RC5 Empfänger"

da klappt das einfach mit toogle Bit auswerten, muss ja nicht erkennen 
ob lang oder kurz

> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
> genau sagen. Habe im Moment viel um die Ohren.
> Gruß,
> Frank

OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und 
postest

viel um die Ohren, wer nicht ;-) (wenn du wüsstest)

gruss
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> gibt es da keine Toggel Bits wie in RC5 ?

Nein, gibt es nur in RC5, RC6 und RECS80. In den anderen 17 Protokollen, 
die IRMP "versteht", gibt es kein Toggle-Bit. Dort gibt es u.a. 
alternative Mechanismen wie zum Beispiel Repetition-Frames (NEC). 
Kaseikyo hat hier nichts, hier arbeite ich mit Timeouts, um längere 
Tastendrücke von X-maligen Tastendrücken zu unterscheiden.

>> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
>> genau sagen. Habe im Moment viel um die Ohren.
> OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und
> postest

Bin doch schon fertig damit. Ich lade hier gleich den Test-Source hoch.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Anbei die geänderten Sources (gegenüber der Download-Version) mit 
verbesserter Unterstützung des Kaseikyo-Protokolls als Test-Version.

Änderungen IRMP
---------------

- Kaseikyo-Protokoll:
  Unterschiedliche Behandlung des 1. Wiederholungsframes (kein langer
  Tastendruck) von nachfolgenden Wiederholungsframes (langer
  Tastendruck).

- Kaseikyo-Protokoll:
  Auswertung der 4 + 8 = 12 "Parity-Bits", um Empfangsfehler zu
  erkennen.

Änderungen IRSND
----------------

- Unterstütrung des Kaseikyo-Protokolls inkl. Parity- und Genre1-Bits.
- Keine Unterstützung der Genre2-Bits beim Kaseikyo-Protokoll

Schwächen
---------

Das Kaseikyo-Protokoll enthält von den 48 Bit insgesamt 36 
Nutzdatenbits. Da die IRMP-Datenstruktur nur 32 Bits (16 Adresse, 16 
Kommando) davon speichern kann, gehen leider 4 Bits verloren. Dabei 
handelt es sich um die sog. Genre2-Bits, die aber meist 0000 sind.

Relevant kann diese Schwäche beim Senden per IRSND werden, da dann die 
Codes einiger bestimmter Tasten (wie MENÜ und OK bei Panasonic) nicht 
gesandt werden können.

Abhilfe könnte hier die Erweiterung der IRMP-Datenstruktur um ein neues 
Byte namens "product" bringen. Muss ich nochmal nachdenken, ob ich das 
einbaue. Wahrscheinlich wird es im nächsten Release enthalten sein.

Gruß,

Frank

Autor: Dirk W. (dirkw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ist IRMP eigentlich mit der neuen Apple Remote (Unibody) kompatibel?

Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt 
verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Einen Debug Trace der Apple Remote habe ich mal angehängt (Trace enthält 
noch eine Taste einer anderen FB zum Vergleich), sowie einen 
aufbereiteten Oszilloskop-Mitschnitt.

CU Dirk

Autor: Klaus L. (kllei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk,

diese Seite: http://en.wikipedia.org/wiki/Apple_remote
lässt darauf schliessen das beide gleich sind.
Laut Apple Seite ist die Unibody Remote mit allen Produkten nach 2005 
eingeführt wurden kompatibel, was nicht das gleiche ist...

Ich hatte die alte (Plastik) FB mit dem iPod 5 Generation getestet, der 
im Oktober 2005 vorgestellt wurde, hatte funktioniert. Diese scans waren 
auch die "Referenz" für Frank. (falls nicht jemand neue scans geliefet 
hat).

Ich glaube dem Wiki Artikel und bin sicher das beide Remote das gleiche 
Protokoll haben.

HTH,
Klaus

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

Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt
> verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.

Ich habe mir gerade den Scan angeschaut. Das Timing ist NEC- und 
APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als 
die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits 
nochmal invertiert ausgibt.

Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am 
Wochenende.

Gruß,

Frank

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Danke Frank :-).


Hab gerade mal ein bisschen gesucht und beim LIRC Projekt folgendes
gefunden:

http://lirc.sourceforge.net/remotes/apple/A1294

> pre_data        0x77E1
> UP                       0x50
> DOWN                     0x30
> LEFT                     0x90
> RIGHT                    0x60
> PLAY                     0xFA
> MENU                     0xC0
> OK                       0x3A


Das würde dem von mir ausgelesenen Protokoll entsprechen.
Scheinbar hat Apple wohl verschiedene Codes in seinen Produkten
hinterlegt.

Wünsche ein schönes WE...


CU Dirk

Autor: Klaus L. (kllei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als
> die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits
> nochmal invertiert ausgibt.

Laut der lirc Seite sind die Adressen von alter und neuer FB gleich, nur 
die Kommandos der Tasten unterscheiden sich:
http://lirc.sourceforge.net/remotes/apple/A1156
http://lirc.sourceforge.net/remotes/apple/A1294

Allerdings stimmen die "Lirc" Werte der alten FB mit der Wiki Seite 
überein, wenn man LSB berücksichtigt.

Ich habe noch mal meine Aufzeichnungen gecheckt, die alte FB wurde von 
IRMP ebenfalls mit Adresse 0x77E1 erkannt,
0x87EE (von der Wiki Seite) in LSB gelesen ergibt 0x77E1

Ach ja, die "alte" FB gibt es wohl auch erst seit Oktober 2005, das 
hatte ich überlesen.
Mal wieder raffiniert gemacht von A**le...

Grüße,
Klaus

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hat schon jemand IRMP und IRSND in ethersex eingebaut?

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und supper Arbeit.

So weit leuft alles bei mir mit dem einlesen der codes. Aber die 
Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste 
ich drücke kommt immer der Code

irmp_data.protoco =9
irmp_data.address =0
irmp_data.command =31

Vieleicht kann mir von euch Jemand helfen

danke

Graf-von-Socke

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

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am
> Wochenende.

Habe gerade mal IRMP an den APPLE-Scan angepasst.

@Dirk:

Ersetze bitte die Zeile:
    else if ((irmp_command & 0xFF00) == 0xD100)

durch
    else if ((irmp_command & 0xFF00) == 0xD100 || (irmp_command & 0xFF00) == 0x4600)

in irmp.c. Dann sollte die FB erkannt werden.

Ich werde das aber anders im nächsten IRMP-Release implementieren. Das 
Problem ist nämlich, dass beide FBs dieselbe NEC-Adresse (0x87ee) haben, 
aber eine unterschiedliche ID verwenden. Damit dann später auch IRSND 
APPLE-Frames versenden kann, welche beide (und auch weitere!) APPLE-FBs 
unterstützt, werde ich zukünftig die bisher von IRMP zurückgegebene 
Adresse 0x87ee ersetzen durch die ID. Das wäre dann bei der FB von Klaus 
die 0xD100 und bei Dirk die 0x4600. Nur so kann eine IRMP-Anwendung auch 
beide APPLE-FBs auseinanderhalten. Daher bitte den obigen Patch erstmal 
als Test/Notlösung sehen...

Die korrekte Fassung kommt dann am Sonntag.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:

> So weit leuft alles bei mir mit dem einlesen der codes. Aber die
> Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste
> ich drücke kommt immer der Code
>
> irmp_data.protoco =9
> irmp_data.address =0
> irmp_data.command =31

IRMP glaubt da anhand des Timings einen RC6-Code zu empfangen. Ich 
glaube aber nicht, dass Microsoft tatsächlich einen von Philips 
entwickelten Code verwendet, sondern (wie so oft) sich etwas eigenes 
ausgedacht hat.

> Vieleicht kann mir von euch Jemand helfen

Da helfen nur Scans. Wie Du diese erstellen kannst, steht im 
IRMP-Artikel:

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

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo hier ist nein Scan ergbis fielicht finden sie etwas


gruß

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Hallo hier ist nein Scan ergbis fielicht finden sie etwas

Danke, scheint ein simpler 32-Bit-Code zu sein. Zwei Tasten reichen da 
aber nicht, ich bräuchte schon so um die 10 Tasten-Scans, um da auch 
eine Struktur zu erkennen. Dann kann ich das in den IRMP integrieren.

Noch als Tipp:
Bitte vor und hinter jedem Kommentar eine neue Zeile beginnen und den 
Kommentar selbst mit dem #-Zeichen einleiten, also:

# Die X Taste
000000000000000000000000000000000000000000000000001111...
# Die Play Taste
000000000000000000000000000000000000000000000000001111...

Ist der Scan mit 10kHz aufgenommen worden?

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok werde ich morgen abend nochmal durchführen
habe was nettes im Internet gefunden fielicht hilft das weiter


........................................................................ 
..
lircd.conf für USB-Empfänger (MCEUSB2)

# this config file was automatically generated
# using lirc-0.8.0-CVS(mceusb2) on Tue Jan 17 15:14:11 2006
#
# contributed by Kyle at shadowmage.org
#
# brand: Microsoft
# model no. of remote control: Xbox 360 Universal Media Remote
# devices being controlled by this remote: Xbox 360
#
# This probably works for the normal Xbox 360 remote too.
#
# TV button sends no signal and toggles Xbox 360/TV mode. TV mode can be
# signals for any device the remote supports. Volume Up, Volume Down and
# Mute always use the TV mode while the Xbox live guide button always 
sends
# to the xbox.

begin remote

  name  Microsoft_Xbox360
  bits           16
  flags RC6|CONST_LENGTH
  eps            30
  aeps          100

  header       2676   870
  one           454   429
  zero          454   429
  pre_data_bits   21
  pre_data       0x37FF0
  gap          106291
  min_repeat      1
  toggle_bit      0

  rc6_mask    0x100000000

      begin codes
          OpenClose                0x8BD7
          XboxFancyButton          0x0B9B
          OnOff                    0x8BF3
          Stop                     0x0BE6
          Pause                    0x8BE7
          Rewind                   0x0BEA
          FastForward              0x8BEB
          Prev                     0x0BE4
          Next                     0x8BE5
          Play                     0x0BE9
          Display                  0x8BB0
          Title                    0x0BAE
          DVD_Menu                 0x8BDB
          Back                     0x0BDC
          Info                     0x8BF0
          UpArrow                  0x0BE1
          LeftArrow                0x8BDF
          RightArrow               0x0BDE
          DownArrow                0x8BE0
          OK                       0x0BDD
          Y                        0x8BD9
          X                        0x0B97
          A                        0x8B99
          B                        0x0BDA
          ChUp                     0x8BED
          ChDown                   0x0BEC

          Start                    0x0BF2
          Play                     0x8BE9
          Enter                    0x0BF4
          Record                   0x8BE8
          Clear                    0x0BF5
          1                        0x8BFE
          2                        0x0BFD
          3                        0x8BFC
          4                        0x0BFB
          5                        0x8BFA
          6                        0x0BF9
          7                        0x8BF8
          8                        0x0BF7
          9                        0x8BF6
          100                      0x0BE2
          0                        0x8BFF
          Reload                   0x8BE3
      end codes

end remote
........................................................................ 
..
Quelle

http://www.vdr-wiki.de/wiki/index.php/Fernbedienun...

Autor: Dirk W. (dirkw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Frank:

Danke dir; die Apple-FB klappt jetzt wunderbar :-)

@Frank, Graf-von-Socke

Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
und jede Taste 3x aufgezeichnet.

CU Dirk

Zusatz:
Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
</n>'s
Bitte vorher ersetzen, falls es den Parser stören sollte ?

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

Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> Danke dir; die Apple-FB klappt jetzt wunderbar :-)

Freut mich. Wie angekündigt, habe ich das mittlerweile allgemeiner 
gelöst: die ID wird nun als Adresse zurückgegeben. So sind Deine 
Fernbedienung und die von Klaus (und auch weitere APPLE-FBs) 
unterscheidbar. Nachteil ist: Die Adresse Deiner FB wird dann eine 
andere sein, nämlich 0x0046. Die von Klaus ist dann 0x00D1.

Update kommt in Kürze als Download im Artikel bzw. über SVN.

> Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
> mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
> Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
> und jede Taste 3x aufgezeichnet.

Vielen Dank! Deine Scans sind wunderbar, Graf-von-Socke hat offenbar 
eine ganz andere Scan-Frequenz genutzt, so dass ich mit seinen Scans 
wenig bis gar nichts anfangen konnte, weil IRMP mit 10kHz erst gar nicht 
RC6 erkannt hat.

Die XBOX benutzt tatsächlich RC6-Code, wer hätte das gedacht. Aber ich 
habe hier genau dieselben Probleme wie mit der Kathrein-FB, deren Scans 
hier schon mal gepostet wurden. Das ist leider kein Mode-0-RC6, wie er 
in

  http://www.sbprojects.com/knowledge/ir/rc6.htm

beschrieben ist. Ich werde mich nochmal mit der RC6-Decodierung 
beschäftigen und hoffe damit, die Kathrein-FB und die XBOX erschlagen zu 
können. Im Moment werden nämlich nur Mode-0-FBs mit 7 + 16 Datenbits 
erkannt. Die XBOX und die Kathrein-FB benutzen einen abweichenden Mode 
mit wesentlich mehr Datenbits. Wenn da jemand irgendeine Doku findet, 
wie die Struktur der Datenbits (Länge der Adresse und der Kommandos) 
ist, würde ich mich freuen.

> Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
> </n>'s
> Bitte vorher ersetzen, falls es den Parser stören sollte ?

Das war kein Problem :-)

Gruß,

Frank

Autor: Achim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden: 
http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

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

Bewertung
0 lesenswert
nicht lesenswert
Achim schrieb:
> Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden:
> http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.

Vielen Dank, das ist ja schon mal ein wenig mehr. Habe den URL direkt 
mal im IRMP-Artikel verlinkt. Jetzt muss ich nur schauen, ob ich den 
Mode 6A mit den Scans in Einklang bringen kann...

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version 1.7.3 von IRMP.

Download:

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

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: JVC

 - Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits.
   ACHTUNG: dadurch neue Command-Codes!

 - Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames

 - Verbesserte Unterstützung des APPLE-Protokolls.
   ACHTUNG: dadurch neue Adress-Codes!

Analog dazu gibt es auch eine neue Version 1.7.3 von IRSND.

Download:

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

Änderungen gegenüber 1.7.2:

 - Neues Protokoll: Kaseikyo (Panasonic u.a.)

Viel Spaß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
und danke für den richtigen scan war mein fehler hatte den scan auf 
20000 eingestellt.

Nun wenn es euch intersesiert bastel ich gerade eine schaltung damit ich 
den
mikrocontroller über mein Handy dazu auffoder die geräere (TV usw) zu 
steuern.

bis dann

Autor: Dirk W. (dirkw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

noch interessant ist eventuell folgende Seite:
http://www.picbasic.nl/info_rc6_uk.htm

und folgendes Dokument (Seite: 28)
http://home.hccnet.nl/m.majoor/files/pronto.pdf

Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
das ich zum Vergleich herangezogen hatte war unterschiedlich.

Hab's trotzdem mal angehängt; vielleicht hilft es ??


CU Dirk

Autor: Graf-von-Sokce (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Habe nun ein anders Problem auf meine ATMEGA8 leuft alles supper.
Bin nun wegen platzmagel auf einen ATMGA 168 umgestigen nun leuft nur 
noch ISR aber es werden keine IR-CODES Ausgeben

gruß

Graf-von-Socke

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

Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> noch interessant ist eventuell folgende Seite:
> http://www.picbasic.nl/info_rc6_uk.htm

Super Link! Danke. Damit werde ich RC6/RC6A wohl endlich in den Griff 
bekommen.

> Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
> Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
> das ich zum Vergleich herangezogen hatte war unterschiedlich.
>
> Hab's trotzdem mal angehängt; vielleicht hilft es ??

Danke, werde ich mir anschauen.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hattest du meine Frage per Mail bekommen ?
darf man dich per Mail fragen ?

gruss
jar

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> hattest du meine Frage per Mail bekommen ?
> darf man dich per Mail fragen ?

Habe ich bekommen. Da ich aber erst Freitag aus dem Urlaub gekommen bin 
und eine Antwort auf Deine Mail etwas länger dauert, bin ich noch nicht 
dazu gekommen, Deine Mail zu beantworten.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe RC6A als extra Protokoll No. 21 eingebaut. Damit sollte 
nicht nur die XBOX-FB funktionieren, sondern endlich auch die 
Kathrein-FB, an der ich schon längere Zeit rumdoktere.

Anbei die gegenüber der Download-Version geänderten Sources als 
Testversion. Sobald mir jemand sagt, dass es läuft, gibt es ein neues 
Release.

Viel Spaß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Suppi
werde es mal gleich ausprobieren ob es geht

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> werde es mal gleich ausprobieren ob es geht

Nimm aber 10kHz, das reicht vollkommen. 20kHz braucht man nur für 
Protokolle, die enorm kurze Pulse nutzen. Ds ist bisher bisher lediglich 
bwi RECS80 der Fall.

15kHz sind auch okay, verbät aber schon mehr CPU-Zeit.

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochnal Hallo

habe es gestest und funktioniert supper gemacht.

Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit 
dem nicht leüft !

gruß

Graf-von-Socke

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> habe es gestest und funktioniert supper gemacht.

Freut mich :-)

> Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit
> dem nicht leüft !

irmp läuft auch auf einem ATMEGA 162 ohne Codeänderung, z.B. im 
WordClock-Projekt. Hast Du denn auch den Prozessor-Typ im WinAVR-Projekt 
ausgewechselt? Man kann i.a. nicht einfach das HEX-File für einen 
ATMEGA8 auf einen 168er laden.

Und unbedingt die Fuses beachten! Siehe 
http://www.engbedded.com/fusecalc/

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen 
ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits 
aussehn

gruß

Graf-von-Socke

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen
> ATMEGA 168 genommen den ich noch hatte wie müssen die  Fuses-bits
> aussehn

Ein jungfräulicher 168er läuft mit 1MHz internem Oszillator. Benutzt Du 
tatsächlich einen 3,686400 MHz Quarz, wie Du das im Projekt angegeben 
hast?

Ich kann Dir erst die Fuses-Einstellung nennen, wenn Du obige Frage 
beantwortet hast.

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo da es auf der Testplatine drauf ist. Hatte damit noch keine Probelem 
da ich schon fiel mt UART gemach habe und die frequenz mit UART sehr gut 
leuft

siehe http://www.wormfood.net/avrbaudcalc.php


gruß

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:
> Jo da es auf der Testplatine drauf ist.

Vorausgesetzt, der µC läuft mit 5V, würde ich wählen:

Low:      0xc7
High:     0xdc
Extended: 0xf9

Achtung: der µC lässt sich dann auch nur noch flashen, wenn der Quarz 
auch wirklich angeschlossen ist.

Du kannst Dir die Werte aber auch selbst ausrechnen lassen, siehe

  http://www.engbedded.com/fusecalc/

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke

nun leuft alles Danke

hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem 
Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten


Kennst du eigendlich den X-PORT


gruß
Graf-von-Socke

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

Bewertung
0 lesenswert
nicht lesenswert
Graf-von-Socke schrieb:

> nun leuft alles Danke

Prima.

> hatte ein nettes erreignis. Mein Quartz wolte nicht  muste erst mit dem
> Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten

Deshalb meine obige Warnung :-)

> Kennst du eigendlich den X-PORT

Du meinst den "XPORT Ethernet Wandler Ethernet zu seriell" von 
Lantronix?

Gruß,

Frank

Autor: Graf-von-Socke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo

Den meine ich finde den ganz nett aber er ist halt bischen teuer. Aber 
was man geschenkt bekommt sagt man nicht nein.

Bin nun dabei eine Schalung zu entwickeln damit jeder PC (auch Handy) 
auf den µC zu greifen kann und die Infrarot Befehle absetzen kann.

Der Grund dafür ist meine Frau die findt das die vielen Gräte aus den 
Blickfang verschwinden und daher fand ich deinen Ansatz hier sehr 
hilfreich.


Gruß

Graf-von-Socke

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

auch hier Bestätigung. Super gemacht; System und Command Byte 
funktionieren.

Bist du dir allerdings bei der Customer ID sicher ?
Ich bekomme hier als Ausgabe 0xffef bin mir aber
ziemlich sicher daß die MS ID 0x800F ist.


CU Dirk

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

Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:

> auch hier Bestätigung. Super gemacht; System und Command Byte
> funktionieren.

Sehr schön, danke für die Rückmeldung :-)

Achja, das MSB der 14 Bits (das ist das MSB des System-Bytes) ignoriere 
ich: das scheint nämlich zu togglen - ähnlich dem Toggle-Bit "TR" bei 
Mode 0, was dort ziemlich weit vorne direkt hinter den Mode-Bits liegt. 
Das ist mir beim XBOX-Scan als auch bei der Kathrein-FB aufgefallen: 
Beim Mode 6A wechselt das eigentliche Toggle-Bit nicht, dafür aber das 
oberste Bit vom System-Byte.

> Bist du dir allerdings bei der Customer ID sicher ?

Nein, sonst hätte ich ja keine Testversion gemacht ;-)

> Ich bekomme hier als Ausgabe 0xffef bin mir aber
> ziemlich sicher daß die MS ID 0x800F ist.

Okay, ich überprüfe das nochmal. Ich stehe echt auf Kriegsfuß mit der 
Manchester-Deokodierung. Wenn ein Bit falsch ist, kippen alle Bits 
dahinter mit :-(

Die Hölle ist nämlich das "eigentliche" RC6-Toggle-Bit "TR", welches die 
doppelte Länge der anderen Bits hat. Da ich mir immer nur Längen 
zwischen zwei Flankenwechseln anschaue, macht mir diese wechselnde 
Frequenz das Leben schwer, denn es kann da als Länge nicht nur 1-fache 
und 2-fache Länge, sondern auch die 1,5-fache Länge auftreten. Ich 
vermute mal, dass genau da das Bit kippt - und damit auch die 
Custtomer-ID, die danach folgt.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Dirk W. schrieb:
> Bist du dir allerdings bei der Customer ID sicher ?

Fehler gefunden und behoben.

Ersetze in irmp.c die Zeilen 2078/2079
    irmp_store_bit (0);
    last_value = 0;

durch folgendes:

    if (irmp_param.complete_len == RC6_COMPLETE_DATA_LEN_LONG) // RC6 mode 6A
    {
        irmp_store_bit (1);
        last_value = 1;
    }
    else    // RC6 mode 0
    {
        irmp_store_bit (0);
        last_value = 0;
    }

Nun kommt als Customer-ID auch 0x800F raus - wie gewünscht ;-)

Gruß,

Frank

Autor: Dirk W. (dirkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

jetzt funktioniert es ... ^_^

Ich protokollier dann gerade mal die Tasten, damit
ich meine alte PC FB gegen die XBOX FB tauschen kann ^_^


CU Dirk

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

Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.8.0 von IRMP verfügbar, Download unter

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

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: RC6A

Damit werden nun die XBOX und auch die Kathrein-FBs unterstützt.

Ebenso ist nun die Version 1.8.0 von IRSND verfügbar, Download unter

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

Änderungen gegenüber 1.7.3:

  - Neues Protokoll: JVC
  - Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.

Im IRSND fehlt jetzt nur noch die Unterstützung des 
RC6-/RC6A-Protokolls, dann sind beide Software-Module wieder 
"symmetrisch". Bin da nun dran.

Die Dokumentation im IRMP-Artikel habe ich angepasst bzw.
erweitert, siehe:

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

Viel Spaß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wollte nur noch mal danke sagen,

deine Tipps wo ich meinen source anpassen musste waren erfolgreich, 
brauchte wirklich nur noch die irmp.c/.h einbinden und die irmpconfig.h 
anpassen und es funzt sofort, RC6 hab ich noch nicht testen können, aber 
der Rest läuft wie gehabt was ein gutes Zeichen ist......


gruss
jar

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Neue Version 1.8.0 von IRMP verfügbar,

Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es 
mit den Optmierungen aus 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es
> mit den Optmierungen aus
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?

Schlecht. Ich hatte mal testweise so eine Version gemacht, wo (nach 
Deiner Idee) in einer Schleife über die Protokolle mittels Timingwerten 
das richtige Protokoll ermittelt werden sollte. Dabei mussten noch 
Pulse-Distance-Protokolle mit Start-Bit von denen ohne Start-Bit (z.B. 
Denon) und auch die Manchester-codierten Protokolle extra abgearbeitet 
werden. Also gab es schon einmal 3 Schleifen...

Ergebnis:

1. Keine Flash-Speicher-Ersparnis, da die Konstruktion der 3 Schleifen
   inkl. zusätzlichen Speicherbedarf der Startbit-Werte für die
   einzelnen Protokolle alles wieder auffraß. Am Ende wurde sogar mehr
   Flash-Speicher benötigt als vorher.

2. Viel Größere Laufzeiten, da die Pulse-/Pause-Werte nicht mehr mit
   Konstanten, sondern mit Variableninhalten abgeglichen werden
   mussten. Der Variablenzugriff war wegen Indirektion über

            startbitstructarray[idx]->value

   nicht gerade effizient.

Kampakter bekommt man den Code wohl nicht, da kann man nur an Feinheiten 
tunen. Ab und zu stolpere ich mal über eine Stelle, die optimiere ich 
dann "on-the-fly", wenn es ohne größeren Aufwand geht.

Ich erwähnte damals zwar, dass man die linearen Vergleiche, die 
unmittelbar nach Eintreffen des Startbits auftreteten, noch optimieren 
könnte. Das würde aber auch keine Verkleinerung des Codes verursachen, 
eher eine (leichte) Vergrößerung. Lediglich die "Suche" nach dem 
richtigen Protokoll ginge dann etwas schneller. Die Arbeit habe ich mir 
aber noch nicht gemacht, da hier der Gewinn bei 20 Protokollen eher 
marginal ist. Bei 1000 Protokollen wäre das was anderes ;-)

Mein Fazit:

Wenn Dir der Code zu groß ist, schalte die nicht benötigten Protokolle 
ab. Dann wirst Du sehen, dass IRMP selbst eigentlich nicht größer ist 
als vorher. Ein neues Protokoll im IRMP verursacht im allgemeinen keine 
Vergrößerung des Codes - solange man es ausgeschaltet(!) lässt ;-)

Wenn jemand ein neu implementiertes Protokoll tatsächlich nutzen will, 
kann er schlecht erwarten, dass der Code gleich groß bleibt.


Gruß,

Frank

Autor: Simon B. (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste 
:-)

In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber 
eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn 
man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine 
Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert 
denn da?

Viele Grüße,
        Simon

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

Bewertung
0 lesenswert
nicht lesenswert
Simon Budig schrieb:
> Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste
> :-)

Freut mich :-)

> In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber
> eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn
> man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?

Ja, es sind auch 20kHz möglich, habe ich vergessen, das zu 
aktualisieren. Allerdings wird dann etwas mehr Speicherplatz benötigt, 
da dann einige Variablen vom Typ her automatisch über den Preprocessor 
von uint8_t auf uint16_t wechseln. Auch wird mehr CPU-Zeit verbraten. 
RECS80, das einzige Protokoll, welches 20kHz erfordert, ist auch noch 
nicht in der Praxis getestet worden.

> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
> denn da?

Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden, 
siehe oben.

Gruß,

Frank

Autor: Simon B. (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Simon Budig schrieb:
>> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
>> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
>> denn da?
>
> Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden,
> siehe oben.

Deswegen war ich ja irritiert...

Aber ich beobachte hier das Gegenteil. Ich habe gerade mal eine kleine 
Reihe gemacht:

F_INTERRUPTS  |   text  | data  |  bss  |    dec  |  vgl. zu 16000
--------------+---------+-------+-------+---------+----------------
        6000  |  11108  |  180  |  113  |  11401  |  +118
        7000  |  11124  |  180  |  113  |  11417  |  +134
        8000  |  11112  |  180  |  113  |  11405  |  +122
        9000  |  11126  |  180  |  113  |  11419  |  +136
       10000  |  11126  |  180  |  113  |  11419  |  +136
       11000  |  11130  |  180  |  113  |  11423  |  +140
       12000  |  11130  |  180  |  113  |  11423  |  +140
       13000  |  11130  |  180  |  113  |  11423  |  +140
       14000  |  11126  |  180  |  113  |  11419  |  +136
       15000  |  11130  |  180  |  113  |  11423  |  +140
       16000  |  10990  |  180  |  113  |  11283  |     0
       17000  |  10990  |  180  |  113  |  11283  |     0
       18000  |  10990  |  180  |  113  |  11283  |     0
       19000  |  10988  |  180  |  113  |  11281  |    -2
       20000  |  10988  |  180  |  113  |  11281  |    -2
       21000  |  10982  |  180  |  113  |  11275  |    -8
       22000  |  10982  |  180  |  113  |  11275  |    -8
       23000  |  10982  |  180  |  113  |  11275  |    -8
       24000  |  10982  |  180  |  113  |  11275  |    -8

Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich 
verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile 
2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend 
beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den 
Code weg.

Viele Grüße,
        Simon

PS: Zur Klarstellung: In der Codegröße ist natürlich noch jede Menge 
anderer Kram drin (LUFA, Displayansteuerung). Die Zahlen dürfen nicht 
zur Beurteilung der Größe von IRMP herangezogen werden, interessant sind 
hier nur die relativen Änderungen.

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

Bewertung
0 lesenswert
nicht lesenswert
Simon Budig schrieb:
> Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich
> verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile
> 2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend
> beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den
> Code weg.

Das darf nicht sein, eigentlich wird ab ca. 16000 Hz IRMP_TIMEOUT_LEN 
größer als 255 und deshalb auch irmp_pause_time dann vom Typ uint16_t. 
Das scheint aber nicht zu funktionieren. Kein Wunder, dass der Compiler 
dann das if-Statement wegwirft. Ich werde das überprüfen.

Danke für den Tipp und Deine "Messungen" :-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Fehler gefunden, es ist eine Änderung in irmp.c notwendig.

Alt:
#include "irmp.h"
#ifndef IRMP_USE_AS_LIB
#include "irmpconfig.h"
#endif

Neu:
#ifndef IRMP_USE_AS_LIB
#include "irmpconfig.h"
#endif
#include "irmp.h"

Werde ich noch am Wochenende im Paket ändern.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Fehler gefunden, es ist eine Änderung in irmp.c notwendig.
> Werde ich noch am Wochenende im Paket ändern.

[x] Done

Download-Version ist nun 1.8.1.

Gruß,

Frank

Autor: Simon B. (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht besser aus:

  F_INTR |   text  | data  |  bss  |    dec  |  vgl. zu 16000
---------+---------+-------+-------+---------+-----------------
   5000  |  11104  |  180  |  113  |  11397  |  -268
   6000  |  11108  |  180  |  113  |  11401  |  -264
   7000  |  11124  |  180  |  113  |  11417  |  -248
   8000  |  11112  |  180  |  113  |  11405  |  -260
   9000  |  11126  |  180  |  113  |  11419  |  -246
  10000  |  11126  |  180  |  113  |  11419  |  -246
  11000  |  11130  |  180  |  113  |  11423  |  -242
  12000  |  11130  |  180  |  113  |  11423  |  -242
  13000  |  11130  |  180  |  113  |  11423  |  -242
  14000  |  11126  |  180  |  113  |  11419  |  -246
  15000  |  11130  |  180  |  113  |  11423  |  -242
  16000  |  11370  |  180  |  115  |  11665  |     0
  17000  |  11370  |  180  |  115  |  11665  |     0
  18000  |  11372  |  180  |  115  |  11667  |    +2
  19000  |  11372  |  180  |  115  |  11667  |    +2
  20000  |  11376  |  180  |  115  |  11671  |    +6
  21000  |  11370  |  180  |  115  |  11665  |     0
  22000  |  11370  |  180  |  115  |  11665  |     0
  23000  |  11372  |  180  |  115  |  11667  |    +2
  24000  |  11372  |  180  |  115  |  11667  |    +2
  25000  |  11372  |  180  |  115  |  11667  |    +2

Vielen Dank und viele Grüße,
        Simon

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der Bug bei U2X ist leider immer noch da, habe wie gesagt nur irmp.c/h 
eingebunden, meine main und die irmpconfig geändert sowie logging on und 
defines fürs steckbrett, , muss am verwendeten m644 liegen, ich weiss 
nur nicht wann und warum dieser U2X Fehler im irmp-uart kommt, wenn ich 
das einfach auskommentier gehts ja, aber der code sollte ja so laufen

Fehlermeldung:
../irmp.c:593:26: error: util/setbaud.h: No such file or directory

finde ich auch in meinem winAVR nicht
void
irmp_uart_init (void)
{
    UART0_UBRRH = UBRRH_VALUE;                                                                      // set baud rate
    UART0_UBRRL = UBRRL_VALUE;
/*
#if USE_2X
    UART0_UCSRA |= (1<<U2X);
#else
    UART0_UCSRA &= ~(1<<U2X);
#endif
*/
#if USE_2X
    UART0_UCSRA |= (1<<U2X0);
#else
    UART0_UCSRA &= ~(1<<U2X0);
#endif

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

so gehts, nur warum

lg
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
als helfende krücke noch

#if IRMP_LOGGING != 0       // 1: log IR signal (scan), 0: do not 
(default)
    uart_init(UART_BAUD_SELECT(9600,F_CPU));
#endif


mit uart.c/h eingebunden Peter Fleury
modified by Patrick Kaplan for ATMega644 usage

und uart_init aufruf statt irmp-uart_init

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:

> Fehlermeldung:
> ../irmp.c:593:26: error: util/setbaud.h: No such file or directory

Meines liegt unter 
C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h

und ist Bestand der avr-libc.

Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version - 
damit meine ich jetzt nicht die WinAVR-Version, sondern Deine 
avr-gcc-Version.

> finde ich auch in meinem winAVR nicht

Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

> so gehts, nur warum

Weil genau die U2X-Geschichte in setbaud.h definiert wird.

Gruß,

Frank

Autor: Joachim B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Meines liegt unter
> C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h
> und ist Bestand der avr-libc.
> Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version -
> damit meine ich jetzt nicht die WinAVR-Version, sondern Deine
> avr-gcc-Version.
>> finde ich auch in meinem winAVR nicht
> Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.

setbaud.h fehlt, ergo muss bei meiner letzten Installation was schief 
gelaufen sein
 Verzeichnis von C:\Programme\atmel

10.12.2008  01:11    <DIR>          .
10.12.2008  01:11    <DIR>          ..
07.01.2010  21:50    <DIR>          AVR Tools
17.03.2008  20:32    <DIR>          BASCOM-AVR
02.09.2008  14:23           432.040 CodeCompareSetup.exe
25.11.2008  01:00    <DIR>          Grafikkonverter
07.03.2008  21:01    <DIR>          PonyProg2000
04.03.2008  20:25    <DIR>          WinAVR


komisch nur das alle meine anderen Projekte laufen, also habe ich nie 
was vermisst
was muss ich also noch wie einbinden ?

vielen Dank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, setbaud ist wieder da, neuste winAVR installiert

muss noch testen

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin leider noch nicht weiter, so siehts aus:
Build started 9.9.2010 at 15:33:42

avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT main.o
 -MF dep/main.o.d  -c  ../main.c

avr-gcc -I"C:\Programme\atmel\WinAVR\avr\include\util"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                     -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT irmp.o

 -MF dep/irmp.o.d  -c  ../irmp.c

../irmp.c: In function 'irmp_uart_init':
../irmp.c:657: error: 'U2X' undeclared (first use in this function)
../irmp.c:657: error: (Each undeclared identifier is reported only once
../irmp.c:657: error: for each function it appears in.)
make: *** [irmp.o] Error 1
Build failed with 3 errors and 0 warnings...

was muss ich noch machen ?

include file search path, hab ich doch in project options ??? grübel
C:\Programme\atmel\WinAVR\avr\include\util\

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

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> bin leider noch nicht weiter, so siehts aus:

> ../irmp.c: In function 'irmp_uart_init':
> ../irmp.c:657: error: 'U2X' undeclared (first use in this function)

Du hast offenbar nicht die aktuelle IRMP-Version vom 04.09.2010. Da wird 
für bestimmte µCs U2X als U2X0 definiert.

Gruß,

Frank

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stimmt da war ich unterwegs, habs also nicht mitbekommen

so geladen, eingespielt, aber immer noch Probleme...

ich glaub ich lasse meine Einbindung von P.Fleury UART.C/H damit klappts 
ja

DAANNKEEE

Autor: Fabi S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,
super geile Sache.
Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay 
Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

Autor: Fabi S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahhh noch was vergessen,
meine beiden Fernbedienungen (sind verschiedene) der Marke Smart 
Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

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

Bewertung
0 lesenswert
nicht lesenswert
Fabi S schrieb:
> Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay
> Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.

Freut mich.

> meine beiden Fernbedienungen (sind verschiedene) der Marke Smart
> Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.

Aber sie werden unterschiedliche Adressen haben, oder?

Gruß,

Frank

Autor: Fabi S (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uiuiui jetzt fragst mich was :)
ich hab mir nur per debugfunktion die werte ausgeben lassen und alle 
tasten durchgedrückt um zu kucken ob alle erkannt werden, protokoll war 
2 aber die adresse weiss ich nichtmehr.
soll ich nochmal kucken?

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

Bewertung
0 lesenswert
nicht lesenswert
Fabi S schrieb:
> soll ich nochmal kucken?

Nö, brauchst Du nicht.

Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
kleines Problem (oder eher großes)

dein Code ist doch ähnlich meinem gefundenen für IRSND start stop

meiner funktioniert, getestet mit Oszi 500µs 36kHz on off
meiner:
void timer0_init(void)
{
    OCR0A  = (F_CPU / ( 2 * IR_FREQUENZ )) - 1;               // compare value: 
#if !FB_LCD_STECKBRETT
  IR_SND_DDR |= (1<<IR_SND);                                  // set DDR to output
    IR_SND_PORT &= ~(1<<IR_SND);                                // set pin to low
#endif
}

void timer0_start(void)
{
    TCCR0A  |= (1 << WGM01) | (1 << WGM00) | (1 << COM0A0);   // switch CTC Mode on, set prescaler to 1
  TCCR0B   |= (1 << WGM02) | (1<<CS00);
    TIMSK0  |= (1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
}

void timer0_stop(void)
{
  TIMSK0  &= ~(1 << OCIE0A);                                   // OCIE0A: Interrupt by timer compare
  TCCR0B   &= ~(1 << WGM02) | (1<<CS00);
    TCCR0A  &= ~(1 << WGM01) | (1 << WGM00) | (1 << COM0A0);

deiner:
static void
irsnd_on (void)
{
    if (! irsnd_is_on)
    {
#ifndef DEBUG
#if defined (__AVR_ATmega32__)
        TCCR2 |= (1<<COM20)|(1<<WGM21);                 // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
#else
        TCCR2A |= (1<<COM2A0)|(1<<WGM21);               // = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
#endif  // __AVR...
#endif // DEBUG
        irsnd_is_on = TRUE;
    }
}

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 *  Switch PWM off
 *  @details  Switches PWM off
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
static void
irsnd_off (void)
{
    if (irsnd_is_on)
    {
#ifndef DEBUG
#if defined (__AVR_ATmega32__)
        TCCR2 &= ~(1<<COM20);                                                           // normal port operation, OC2A disconnected.
#else
        TCCR2A &= ~(1<<COM2A0);                                                         // normal port operation, OC2A disconnected.
#endif  // __AVR...
        IRSND_PORT  &= ~(1<<IRSND_BIT);                                                 // set IRSND_BIT to low
#endif // DEBUG
        irsnd_is_on = FALSE;
    }
}


ergo dachte ich ich ersetzte dein ON/OFF durch meines

aber klappt nicht, irgendwo ist noch der Wurm drin,

nach play +5 sekunden hängt die routine

wenn einer mal schauen mag ?

danke
gruss
jar

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit static volatile usw. muss ich noch üben

am irsnd_busy hats gelegen

Routine läuft erst mal, nur das Gerät fühlt sich noch nicht angesprochen

muss erst mal ein 2ten IRMP bauen zum testen

die Pulse sind nun zu kurz um sie mit der digital cam hilfe zu sehen, im 
gegensatz zu vorher 500µs on/off

Autor: Bruno I. (bjnas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja ein super Projekt, Gratulation an alle. Das ganze läuft ja 
auch mit B&O Codes. Nun hab ich einen IR Sender-Empfänger aus einem 
alten B&O Fernseher geschraubt.

Die Frage nun, kann man Ihn anstelle eines TSOP-7000 verwenden. Kennt 
jemand die Anschlüsse. Beim Empfänger ist auch ein Lichtsensor.

Kann über die beiden IR-Empfänger (TFK B  PW82) keine Datenblätter 
finden.

Danke für eine kleine Unterstützung.

Autor: Bruno I. (bjnas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch die Platine

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Bruno I. (bjnas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man, das ging ja fix. Da war ich wohl schlampig.

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment 
ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in 
ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.

Autor: Peter D. (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich teste IRMP gerade auf einem ATmega324P.
Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier 
die Pins nicht stimmen:
#if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega324P__)
// usw.

Vielen Dank für dieses schöne Projekt!!!

Grüße,

Peter

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete 
Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den 
Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:

irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00

irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00

Zum Vergleich ein Denon-Code:

irmp send 8 1 2 0
OK
IRMP: proto DENON, address 0001, command 0002, flags 00
IRMP 08:0001:0002:00

Autor: Uwe R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt

IR-Daten:
8 Adress-Bits
8 Mouse-Bits (Bit0=lButtonDown, Bit1=rButtonDown, Bit3=IsMouse, Bit4=IsLeftMove, Bit5=IsDownMove)
4 RightMove-Bits
4 LeftMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst Press/Release)
4 UpMove-Bits   (wenn IsMouse in Mouse-Bits gesetzt, sonst Low-Nibble von Command
4 DownMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst High-Nibble von Command
8 Invertierte Command-Bits
Mit X=RightMove-LeftMove und Y=UpMove-DownMove
bekommt man dann Werte, mit denen man auch etwas anfangen kann.
Mehr dazu in den nächsten Tagen, bin noch am Testen.

Gruß
Uwe

Autor: djmaster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, bin mal ganz neu hier. ;) Und habe leider ein Problem wo ich alleine 
absolut nicht mehr weiterkomme. Suche schon seit tagen.^^ Programmieren 
kann ich leider nicht wirklich, ich versuche mich mit gesunden 
Menschenverstand durch die Codes durch zu arbeiten. Beruf: 
Nachrichtentechniker, also eher der Funksektor.

Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade 
irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.
hardware/ir/irmp/irmp.c:114: Warnung: #pragma push_macro  wird ignoriert
hardware/ir/irmp/irmp.c:118: Warnung: #pragma push_macro  wird ignoriert
hardware/ir/irmp/irmp.c:133: Warnung: #pragma pop_macro  wird ignoriert
hardware/ir/irmp/irmp.c:134: Warnung: #pragma pop_macro  wird ignoriert
hardware/ir/irmp/irmp.c:328: Warnung: »TIMER0_COMP_vect« scheint ein falsch geschriebener Signal-Handler zu sein
hardware/ir/irmp/irmp.c: In Funktion »TIMER0_COMP_vect:

Nun hab ich gelesen das dieser Timer0 beim atmega644 TIMER0_COMPA_vect 
heißt.
Ich glaube zumindest das ich am Richtigen weg bin aber, ehrlich gesagt 
keine Ahnung, Habe nun in der irmp.c TIMER0_COMP_vect in 
TIMER0_COMPA_vect geändert aber Ergebnis bleibt das gleiche.. es folgt 
ein Fehler mit __vector_16.
Nun hab ich keine Ahnung mehr wie ich weitermachen soll. Deswegen hab 
ich mir eure Codes hier angesehen aber irgendwie werde ich da auch nicht 
Schlau daraus.

Gehalten hab ich mich an dieses hier: 
http://www.ethersex.de/index.php/IRMP
Meine irmp.c --> http://paste2.org/p/1050578

Vielleicht könnt ihr mir ja weiterhelfen hab schon soooo viel tolle 
Sachen hier erlesen ;)

Grüße aus Wien

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

djmaster schrieb:
> Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade
> irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.

die Portierung nach ethersex ist von mir. Hilfe bekommst Du im IRC 
(Details siehe ethersex WIKI).

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment
> ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in
> ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.

Dieses define ist eher gedacht, irmp als sog. "Include-Lib" zu nutzen. 
Das heisst, man hat irgendwo in seinem Projekt sämtliche Defines, die 
normalerweise in irmpconfig.h stehen, in seinem project-irmp.c und macht 
anschließend einfach ein
#include "../irmp/irmp.c"

Ich benutze diese Methode selbst öfters, um bestimmte Sources, welche 
projektunabhängig sind, in mein konkretes Projekt einzubinden. Das hat 
zwar nichts mit "echten" Libs im C-Sinne zu tun, hat aber den Vorteil, 
dass nur das vom Code übernommmen/compiliert wird, was man gerade 
braucht - bei IRMP zum Beispiel nur den NEC-Decoder. Mein Projekt bleibt 
dann unabhängig von den Standard-Werten in irmpconfig.h. Das ist 
sinnvoll bei µCs, wo es auf jedes gesparte Byte ankommt. Hier wird also 
kein Object-File dazugelinkt, sondern der Source selbst mit ins Projekt 
eingebunden. Meinetwegen kannst Du das Includen von C-Files (xxx.c) als 
No-Go ansehen, für mich ist das aber eine durchaus anwendbare Methode.

Eine "klassische" Lib aus IRMP zu machen, die man dazubindet, halte ich 
für einen µC unpraktikabel, da ja dann schon bei Erstellung der Lib klar 
sein muss, welche IR-Decoder ich brauche. Es ist aber bei der 
universellen Konfigurierbarkeit von IRMP gar nicht möglich, dies vorab 
zu entscheiden.

Um auf Deine Frage zurückzukommen: das IRMP_USE_AS_LIB ist für mich kein 
Feigenblatt, sondern für mich soweit bereits anwendbar ;-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Peter Diener schrieb:
> ich teste IRMP gerade auf einem ATmega324P.
> Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier
> die Pins nicht stimmen:
>
> #if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) ||
> defined (__AVR_ATmega324P__)
> // usw.
> 

Danke, habe ich so übernommen, kommt ins nächste Release.

> Vielen Dank für dieses schöne Projekt!!!

Danke fürs Danke :-)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete
> Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den
> Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:
>
> irmp send 13 9 9 0
> OK
> IRMP: proto NUBERT, address 0000, command 0009, flags 00
> IRMP 13:0000:0009:00

Habe ich gerade versucht, nachzuvollziehen (unter Linux):

# ./irsnd 13 9 9 0 | ./irmp
0000001001 p = 13, a = 0x0000, c = 0x0009, f = 0x00

Stimmt, die dekodierte Adresse ist immer 0, aber das ist kein Wunder:

Nach

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

gibt es beim Nubert-Protokoll keine Adress-Bits, sondern nur 
Kommando-Bits. Daher ist das Verhalten von IRSND korrekt, es ignoriert 
nämlich Deine angegebene Adresse und IRMP zeigt immer 0 an.

Beachte auch meine Bemerkungen oberhalb der Tabelle im Artikel, Zitat:

| Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der
| Adressen bzw. Kommandos verschieden, siehe obige Tabelle [2].
| Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite
| Adressen oder Kommandos transparent übertragen.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Uwe R. schrieb:
> Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt

Sehr interessant!

> Mehr dazu in den nächsten Tagen, bin noch am Testen.

Ich hoffe, da kommen noch weitere Infos zu.

Gruß,

Frank

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand die URC Zapper (gibts bei Reichelt günstig) mal ausprobiert?

http://www.reichelt.de/?ARTICLE=77492

Dort steht:

----
Geeignet für die Bedienung von infrarotgesteuerten Fernsehgeräten aller 
Marken.
----

Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein 
Protokoll unterstützt wird, richtig?

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein
> Protokoll unterstützt wird, richtig?

Davon gehe ich aus.

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB 
Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen 
Widerspruch doch bitte.

Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von 
IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im 
Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch 
(Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim 
Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die 
durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale 
Empfänger nicht.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Hallo Frank!
>
> Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB
> Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen
> Widerspruch doch bitte.

Du schriebst weiter oben:

irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00

irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00

Hier erkennt IRMP als Adresse den Wert 0. Wo ist da ein Widerspruch?
Bitte gib genauere Infos an, mit "Adressbits, die es laut Deines 
Artikels" kann ich nichts anfangen.

> Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von
> IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im
> Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch
> (Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim
> Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die
> durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale
> Empfänger nicht.

Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing 
wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann 
IRMP da durchaus "besser" sein als die Hersteller selbst.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

> Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing
> wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann
> IRMP da durchaus "besser" sein als die Hersteller selbst.

Ich verwende einen m168 mit 16MHz quarzgetaktet. Laut Protkoldetails im 
IRMP-Artikel setzen sich die Daten aus

13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit

zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die 
Parität handelt? Das würde zumindest erklären, warum nur die von IRSND 
gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die 
Parität stimmt. Wie müsste man IRSND ändern, um diese These zu 
verifizieren?


Gruß, eku

Autor: Simon B. (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben wir eigentlich eine Vorstellung davon, welche Adressen- und 
Datenwerte eigentlich generell so verwendet werden?

Hintergrund ist, dass ich gerade an einem USB-Empfänger bastele, der ein 
konfigurierbares HID-Keyboard darstellen soll. Wenn ich beliebige 
Fernbedienungen zulassen möchte, habe ich eine Lookup-Tabelle für die 
Keycodes, die 5-Byte-Keys (Protokoll + 16-bit Adresse + 16-bit Kommando) 
auf 1-2 Bytes Keycode abbildet.

Bei einem 512-Byte-EEprom kriege ich also etwa 70-80 Zuordnungen unter, 
was vielleicht reicht, sich aber trotzdem wie Verschwendung anfühlt.

Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando 
braucht man eh nie" oder "das Protokoll kann man in die Adresse mit 
reinverodern" und trotzdem noch eine gute Erkennung von beliebigen 
Fernbedienungen zu haben.

Leider habe ich keine klare Vorstellung davon, was die häufigste 
Verwendung von Address- und Kommandonummern ist, und welche 
"Zusammenfassung" erfolgversprechend wäre. Habt ihr da Ideen?

Viele Grüße,
        Simon

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> 13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit
>
> zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die
> Parität handelt?

Das kann durchaus sein. Ich habe mir gerade nochmal die Scans von der 
M740AV angeschaut. Dabei haben ca. 50% der Frames als letztes Bit den 
Wert 0, die anderen haben als letztes Bit den Wert 1.

> Das würde zumindest erklären, warum nur die von IRSND
> gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die
> Parität stimmt.

Ja, sehr gut erkannt!

> Wie müsste man IRSND ändern, um diese These zu verifizieren?

Füge die mit +++ gekennzeichneten Zeilen in irsnd.c ein:
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
        case IRMP_SIEMENS_PROTOCOL:
        {
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC0

            if ((irmp_data_p->command % 2) == 0)         // +++
            {                                            // +++
                irsnd_buffer[2] |= 0x04;                 // +++
            }                                            // +++
            irsnd_busy      = TRUE;
            break;
        }
#endif

Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade 
ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das 
letzte Bit betrachte. Aber es könnte auch sein, dass beim 
Siemens-Protokoll im letzten Bit tatsächlich die Parität von Adresse + 
Kommando herangezogen wird. Um das zu beurteilen, bräuchte ich den Scan 
von einer anderen Siemens-FB, welche eine andere Adresse verwendet.

Kannst Du mal testen, ob es nun stimmt?

[/c]

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

Bewertung
0 lesenswert
nicht lesenswert
Simon Budig schrieb:

> Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando
> braucht man eh nie" oder "das Protokoll kann man in die Adresse mit
> reinverodern" und trotzdem noch eine gute Erkennung von beliebigen
> Fernbedienungen zu haben.

Das kann man leider überhaupt nicht sagen, wie man die Daten da noch 
weiter "komprimieren" kann. Du kannst Dir ja mal selbst ein Bild machen 
mit

  ./irmp <IR-Data/xxxx.txt

bzw.

  irmp.exe <IR-Data/xxxx.txt

was da alles so vorkommen kann. Beim Kaseikyo-Protokoll fehlen mir sogar 
noch 2 Bits, die ich in irmp_data.command gar nicht unterbringen kann. 
Glücklicherweise haben diese bei den bisherigen FB-Scans, die mir 
zugesandt wurden, keine relevanten Daten (immer "00").

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

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
> letzte Bit betrachte.

Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die 
Invertierung des davor zuletzt gesandten Bits, welches das 
niederwertigste Bit des Kommandocodes ist.

Daher ist die folgende Schreibweise als Codekorrektur von IRSND 
plausibler (führt aber zu demselben Ergebnis):
#if IRSND_SUPPORT_SIEMENS_PROTOCOL == 1
        case IRMP_SIEMENS_PROTOCOL:
        {
            irsnd_buffer[0] = ((irmp_data_p->address & 0x0FFF) >> 5);                                           // SAAAAAAA
            irsnd_buffer[1] = ((irmp_data_p->address & 0x1F) << 3) | ((irmp_data_p->command & 0x7F) >> 5);      // AAAAA0CC
            irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?

            if (!(irmp_data_p->command & 0x01))   // +++
            {                                     // +++
                irsnd_buffer[2] |= 0x04;          // +++  // 00000c
            }                                     // +++
            irsnd_busy      = TRUE;
            break;
        }
#endif

Im IRMP-Artikel habe ich nun folgendes zum SIEMENS-Prtokoll angemerkt:

13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 invertiertes Bit 
(letztes Bit davor nochmal invertiert)

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Noch kürzer:

Alt:
  irsnd_buffer[2] = (irmp_data_p->command << 3);                                                      // CCCCC?

Neu:
  irsnd_buffer[2] = (irmp_data_p->command << 3) | ((~irmp_data_p->command & 0x01) << 2);              // CCCCCc

Dann kann der ganze nachfolgende if-Block entfallen. Ich habe das so nun 
im IRSND übernommen. Kommt ins nächste Release.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast, 
dass die if-Anweisung effizienter ist.

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Frank M. schrieb:
>> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
>> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
>> letzte Bit betrachte.
>
> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
> Invertierung des davor zuletzt gesandten Bits, welches das
> niederwertigste Bit des Kommandocodes ist.

das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen 
zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch 
testen, ob die Parität auch über die Adresse gebildet wird.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
>> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
>> Invertierung des davor zuletzt gesandten Bits, welches das
>> niederwertigste Bit des Kommandocodes ist.
>
> das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen
> zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch
> testen, ob die Parität auch über die Adresse gebildet wird.

Komisch, schau Dir mal diesen Output an:
 ./irmp-15kHz <IR-Data/Siemens-Gigaset-M740AV-15kHz.txt
-------------------------------------------------------------------
# Power
00011011000100000010110 p = 17, a = 0x06c4, c = 0x000b, f = 0x00
-------------------------------------------------------------------
# 1
00011011000100000000010 p = 17, a = 0x06c4, c = 0x0001, f = 0x00
-------------------------------------------------------------------
#2
00011011000100000000101 p = 17, a = 0x06c4, c = 0x0002, f = 0x00
-------------------------------------------------------------------
# 3
00011011000100000000110 p = 17, a = 0x06c4, c = 0x0003, f = 0x00
-------------------------------------------------------------------
# 4
00011011000100000001001 p = 17, a = 0x06c4, c = 0x0004, f = 0x00
-------------------------------------------------------------------
# 5
00011011000100000001010 p = 17, a = 0x06c4, c = 0x0005, f = 0x00
-------------------------------------------------------------------
# 6
00011011000100000001101 p = 17, a = 0x06c4, c = 0x0006, f = 0x00
-------------------------------------------------------------------
# 7
00011011000100000001110 p = 17, a = 0x06c4, c = 0x0007, f = 0x00
-------------------------------------------------------------------
# 8
00011011000100000010001 p = 17, a = 0x06c4, c = 0x0008, f = 0x00
-------------------------------------------------------------------
# 9
00011011000100000010010 p = 17, a = 0x06c4, c = 0x0009, f = 0x00
-------------------------------------------------------------------
# 0
00011011000100000010101 p = 17, a = 0x06c4, c = 0x000a, f = 0x00
-------------------------------------------------------------------
# HELP
00011011000100000100110 p = 17, a = 0x06c4, c = 0x0013, f = 0x00
-------------------------------------------------------------------
# Hoch
00011011000100000101101 p = 17, a = 0x06c4, c = 0x0016, f = 0x00
-------------------------------------------------------------------
# Links
00011011000100000011001 p = 17, a = 0x06c4, c = 0x000c, f = 0x00
-------------------------------------------------------------------
# OK
00011011000100000011101 p = 17, a = 0x06c4, c = 0x000e, f = 0x00
-------------------------------------------------------------------
# Rechts
00011011000100000011110 p = 17, a = 0x06c4, c = 0x000f, f = 0x00
-------------------------------------------------------------------
# Runter
00011011000100000100001 p = 17, a = 0x06c4, c = 0x0010, f = 0x00
-------------------------------------------------------------------
# EXIT
00011011000100000011010 p = 17, a = 0x06c4, c = 0x000d, f = 0x00
-------------------------------------------------------------------
# Mute
00011011000100000101110 p = 17, a = 0x06c4, c = 0x0017, f = 0x00
-------------------------------------------------------------------
# Menu
00011011000100000110010 p = 17, a = 0x06c4, c = 0x0019, f = 0x00
-------------------------------------------------------------------
# EPG
00011011000100000110110 p = 17, a = 0x06c4, c = 0x001b, f = 0x00
-------------------------------------------------------------------
# INFO
00011011000100000111001 p = 17, a = 0x06c4, c = 0x001c, f = 0x00
-------------------------------------------------------------------
# REW
00011011000100000111010 p = 17, a = 0x06c4, c = 0x001d, f = 0x00
-------------------------------------------------------------------
# STOP
00011011000100000111101 p = 17, a = 0x06c4, c = 0x001e, f = 0x00
-------------------------------------------------------------------
# FF
00011011000100000111110 p = 17, a = 0x06c4, c = 0x001f, f = 0x00
-------------------------------------------------------------------
# Rot
00011011000100001000001 p = 17, a = 0x06c4, c = 0x0020, f = 0x00
-------------------------------------------------------------------
# Gruen
00011011000100001000010 p = 17, a = 0x06c4, c = 0x0021, f = 0x00
-------------------------------------------------------------------
# Gelb
00011011000100001000101 p = 17, a = 0x06c4, c = 0x0022, f = 0x00
-------------------------------------------------------------------
# Blau
00011011000100001000110 p = 17, a = 0x06c4, c = 0x0023, f = 0x00

Hier ist das letzte Bit immer das invertierte des vorletzten. Oder ist 
da noch ein Bug in der Manchester-Codierung des IRMP? Glaube ich 
eigentlich nicht, denn RS5 und RC6 funktionieren ja....

Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert 
werden?

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast,
> dass die if-Anweisung effizienter ist.

Beide Varianten führen beim ATmega88 zu dem Codezuwachs von je 16 Bytes 
- es kommt also exakt auf dasselbe raus.

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

> Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert werden?

war mein Fehler. In der Scandatei Siemens-Gigaset-M740AV-15kHz.txt sind 
einige Tasten falsch beschriftet. Werde bei Gelegenheit mal eine neue 
aufzeichnen. In http://www.m740.de/wiki/Lircd wird das besagte Bit dem 
Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN 
mit Deinem Fix.

Bei Dekodieren mit IRMP gibt es Interferenzen mit anderen Dekodern. Ich 
habe nur noch nicht rausbekommen mit welchem. Siemens alleine dekodiert 
meist zuverlässig. Alle Dekoder aktiviert und die Dekodierung gerät zum 
Glückspiel.
Siehst Du eine Möglichkeit, die Anzahl der zu testenden Kombinationen 
von vorn herein einzuschränken?

Gruß, eku

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

> In http://www.m740.de/wiki/Lircd wird das besagte Bit dem
> Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN
> mit Deinem Fix.

mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten 
zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir 
aufgestellten Regel, prüft. Ich persönlich plädiere für 1.


Gruß, Erik

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten
> zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir
> aufgestellten Regel, prüft. Ich persönlich plädiere für 1.

Mir gefällt es eigentlich nicht, wenn es dem Kommando zugeschlagen wird.

Gründe:

1. Das Prüfbit gehört offensichtlich nicht zum Kommando

2. Es stört mein Symmetrie-Empfinden (die Kommando-Codes sind nicht
   mehr fortlaufend)

3. Die LIRCS-Leute haben sich das Leben da sehr einfach gemacht ;-)

Dass IRMP konsequenterweise das letzte Bit prüfen soll, halte ich für 
sinnvoller. Denn genau dafür ist das letzte Bit offenbar da: zur 
Prüfung. Genau das macht IRMP auch teilweise bei anderen Protokollen, 
z.B. NEC, wo sämtliche invertierten Kommandobits gegengecheckt werden.

Wenn ich das Prüfbit dem Kommando zuschlage, dann hat das folgende 
Nachteile:

1. Prüfung auf Gültigkeit nicht mehr sinnvoll
2. Es können irreguläre Codes sowohl empfangen als auch gesendet werden

Daher plädiere ich für 2 ;-)

Ich habe bereits den Check des Prüfbits auf meiner TODO-Liste.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das 
Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig. 
Könnten die 200usec Bitlänge falsch sein?

Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die 
Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert. Da 
ist die Logik "Grundig annehmen und später auf Nokia umschalten" falsch. 
Würdest Du das bitte korrigieren.


Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das
> Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig.
> Könnten die 200usec Bitlänge falsch sein?

Schau Dir bitte die Text-Datei im Anhang an (im Notepad Zeilenumbruch 
aktivieren).

Die erste Zeile enthält Deinen Scan von der Taste "Rechts", die Zeile 
darunter enthält den von IRSND generierten Frame.

Die Zeilen sind fast identisch. An IRSND kann es also nicht liegen, es 
reproduziert das Telegramm perfekt - sogar besser als das Original ;-)
Vielleicht ist Dein damaliger Scan nicht genau genug? Oder stimmt 
vielleicht die Modulationsfrequenz nicht?

Du kannst ja mal die Parameter variieren, vielleicht kannst du das 
Resultat somit optimieren?

> Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die
> Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert.

Habe ich gerade versucht zu reproduzieren: bei mir wird Nokia (protocol 
= 16) erkannt. Nokia und Grundig werden auch im Source absolut 
gleichberechtigt behandelt. Ich sehe da keine Stelle im Code, wo Dein 
beschriebenes Verhalten greifen sollte.

> Da ist die Logik "Grundig annehmen und später auf Nokia umschalten"
> falsch.

Kann ich leider nicht reproduzieren.

Gruß,

Frank

Autor: Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag

finde dein Projeckt so weit sehr gut.
Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.

Da ich zum größten teil  meiner Fernbedinungen RC6 sind


mfg

Müller

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

Bewertung
0 lesenswert
nicht lesenswert
Müller schrieb:

> Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.

Einen Prototypen für RC6 habe ich laufen, bei RC6A (FBs von Kathrein & 
Co) habe ich noch ein Problem, da weiss ich leider noch nicht, ob ich 
den Fehler im IRSND oder vielleicht sogar im IRMP habe, da ich den IRSND 
immer mit dem IRMP selbst testen muss.

Ich versuche mal, das Problem in den Griff zu bekommen, dann würde ich 
hier im Laufe der Woche eine Testversion reinstellen, damit Du das 
testen kannst ;-)

Gruß,

Frank

Autor: Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Ich danke dir schon mal im voraus. dann bin ich mal gespannt und fiel 
glück das du es hin bekommts

mfg

Müller

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

Bewertung
0 lesenswert
nicht lesenswert
Anbei eine Testversion von IRSND, welche auch das RC6- und 
RC6A-Protokoll (Protokollnummern 9 u. 21) unterstützt. Im Zip-Archiv 
sind nur die gegenüber der Download-Version geänderten Dateien.

Hier ist auch noch eine Korrektur für IRMP drin, nämlich für das 
RC6A-Protokoll. Hier hatte bisher IRMP immer automatisch das 
höchstwertige Adressbit gesetzt, wenn es sich um RC6A handelte. Das ist 
nun nicht mehr der Fall. Bei der Kathrein-FB wurde bisher als Adresse 
0x8046 ausgegeben, nun ist es 0x0046.

Wäre Klasse, wenn jemand IRSND bzgl. RC6 und RC6 testen könnte. Dieses 
Manchester-Protokoll mit wechselnden Periodenzeiten (im T-Bit) raubt mir 
mal wieder den letzten Nerv...

Gruß,

Frank

Autor: Müller (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank

Habe deine neune Datein bei mir ins Projeckt übernommen
nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was 
am eingang geändert ?

Hier ist mein codes

im IRBORD ist das halt mit den normalen programm
im IRBORD2 ist das mit den neune Programmcode von dir


kannst du mal nachschauen ob ich was falsch gemacht habe

Autor: eku (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um 
Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND 
gesendeten Sequenzen.

Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei 
einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).

Anbei ein Scan der wichtigsten Tasten bei 15kHz.

Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um
> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND
> gesendeten Sequenzen.

Ja, das sieht sehr nach DENON aus, auch die invertierten 
Frame-Wiederholungen sind drin. Allerdings sind viele Scans 
offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen" 
innerhalb der Frames.

Das kann zweierlei Gründe haben:

1. FB war zu weit weg vom IR-Empfänger
2. Modulationsfrequenz der FB passt schlecht zum TSOP.

Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder 
gar TSOP1738...

> Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei
> einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).

Das findet man öfter bei einigen FBs, da werden dann geräteübergreifende 
Adressen benutzt. Das können zum Beispiel Fernseher sein, die Funktionen 
einzelner Produkte desselben Herstellers in einem Gerät vereinen, z.B. 
Festplatten-Recorder im TV, irgendwelche Spezial-Tuner, Timer oder 
sonstwas...

> Anbei ein Scan der wichtigsten Tasten bei 15kHz.

Das ist eindeutig Denon-Code. Allerdings ist die Aufzeichnungsqualität 
sehr schlecht.

Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht 
benutzt der Sharp zwar das Denon-Protokoll, aber eine andere 
Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher 
anzuschauen?

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Müller schrieb:
> Habe deine neune Datein bei mir ins Projeckt übernommen
> nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was
> am eingang geändert ?

Nein, aber Du scheinst den neuen Code nicht an Deine Hardware angepasst 
zu haben:

irmpconfig.h:
< #define IRMP_PORT                               PORTC
< #define IRMP_DDR                                DDRC
< #define IRMP_PIN                                PINC
< #define IRMP_BIT                                0       // use PB6 as IR input on AVR
---
> #define IRMP_PORT                               PORTB
> #define IRMP_DDR                                DDRB
> #define IRMP_PIN                                PINB
> #define IRMP_BIT                                6       // use PB6 as IR input on AVR


irsndconfig.h
< #define IRSND_PORT                              PORTB   // port D
< #define IRSND_DDR                               DDRB    // ddr D
< #define IRSND_BIT                               3       // OC2A
---
> #define IRSND_PORT                              PORTD   // port D
> #define IRSND_DDR                               DDRD    // ddr D
> #define IRSND_BIT                               7       // OC2A

Damals hattest Du es wohl angepasst (siehe obige Unterschiede), dieses 
Mal hast Du das offenbar versäumt.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> eku schrieb:
>> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um
>> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND
>> gesendeten Sequenzen.
>
> Ja, das sieht sehr nach DENON aus, auch die invertierten
> Frame-Wiederholungen sind drin. Allerdings sind viele Scans
> offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen"
> innerhalb der Frames.
>
> Das kann zweierlei Gründe haben:
>
> 1. FB war zu weit weg vom IR-Empfänger

War sie nicht.

> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.

Schon möglich.

> Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder
> gar TSOP1738...

Mit der selben Hardware kann ich eine originale Denon-FB problemlos 
einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.

> Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht
> benutzt der Sharp zwar das Denon-Protokoll, aber eine andere
> Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher
> anzuschauen?

Auf keines der ausgesandten Kommandos reagiert der TV. Zugriff auf einen 
Oszi habe ich nicht.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

>> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.
> Schon möglich.

Welchen IR-Empfänger benutzt Du denn?

Wenn man sich die Scans mit einem Text-Editor anschaut (einer, der auch 
mit langen Zeilen bestens zurechtkommt, also nicht Notepad o.ä.), sieht 
man sehr schön, dass es immer wieder "Aussetzer" gibt, d.h. dass 
IR-Impulse dort, wo sie eigentlich sein sollten, komplett fehlen. Das 
Timing von der FB ist ungeheuer exakt, selbst nach über 2300 Scanpunkten 
passen die empfangenen Impulse noch ziemlich genau übereinander.

Eigentlich werden nur die ersten beiden Tasten (power + radio) Deines 
Scans von IRMP "verstanden", alles andere wird als fehlerhaft verworfen 
- was man auch nachvollziehen kann, wenn man mit dem Editor reinschaut.

Hast Du denn beim IRMP auch derart schlechte Ergebnisse bei der 
Sharp-FB? Oder war das einfach nur ein "Montags-Scan"? Kannst Du den 
Scan wiederholen, damit man eine Aussage über die Qualität der 
Reproduzierung machen kann?

> Mit der selben Hardware kann ich eine originale Denon-FB problemlos
> einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.

Sehr schön :)

> Auf keines der ausgesandten Kommandos reagiert der TV.

Das Timing der Sharp-FB ist zwar exakt, jedoch ermittelt IRMP leicht vom 
DENON-Protokoll abweichende Timingwerte, die aber alle noch in der 
IRMP-Toleranz liegen, für das Sharp-TV aber vielleicht schon zu stark 
abweichen.

Ersetze mal in irmp.h folgende Zeilen
#define DENON_PULSE_TIME                        275.0e-6                        //  275 usec pulse
#define DENON_1_PAUSE_TIME                      1900.0e-6                       // 1900 usec pause

durch
#define DENON_PULSE_TIME                        300.0e-6                        //  300 usec pulse
#define DENON_1_PAUSE_TIME                      1800.0e-6                       // 1800 usec pause

und teste IRSND erneut.

> Zugriff auf einen Oszi habe ich nicht.

Das ist schade.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Auf keines der ausgesandten Kommandos reagiert der TV.

Habe da noch eine Idee:

Die Sharp-FB sendet offenbar 3 Frames pro Tastendruck - und nicht nur 
zwei, wie es bei DENON wohl sonst üblich ist. IRSND sendet jedenfalls 
nur zwei Frames, nämlich:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando

Die Sharp FB sendet:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando

Dieses Verhalten könnte man mit dem IRSND simulieren, indem man 
irmp_data.flags = 1 setzt, dann wiederholt IRSND nämlich die beiden 
obigen Frames und es käme raus:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando
4. Frame: Adresse + invertiertes Kommando

Das ist zwar dann ein Frame zuviel (der letzte), aber wenn Du Glück 
hast, ist das Sharp-TV nach dem 3. Frame zufrieden und führt das 
Kommando aus.

Gruß,

Frank

Autor: eku (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

danke für deine Analyse. Der TV lässt sich weder von den geänderten 
Timings noch von der Framewiederholung beindrucken :-(

Anbei ein erneuter Scan, diesmal beo 10KkHz. Auf der FB steht ga323wjsa. 
Man kann sie an allen Ecken des Internets kaufen, aber das Protkoll wird 
nicht beschrieben.

Gruß,
eku

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> danke für deine Analyse. Der TV lässt sich weder von den geänderten
> Timings noch von der Framewiederholung beindrucken :-(

Hm, erstmal habe ich jetzt keine Idee mehr, muss ich nochmal drüber 
nachdenken.

> Anbei ein erneuter Scan, diesmal beo 10KkHz.

Dieses Mal ist der Scan perfekt und läuft ohne Fehler durch den IRMP 
durch.

Hier eine Beispiel-Ausgabe, wo man sehr gut sieht, dass es 3 Frames 
sind.
# ./irmp < sharp.log
-------------------------------------------------------------------
# power
100000110100010
100001001011101 p =  8, a = 0x0010, c = 0x01a2, f = 0x00
100000110100010
-------------------------------------------------------------------
...

IRMP detektiert also nach dem 2. Frame (in welchem die Kommando-Bits 
negiert sind) bereits die Daten. Es folgt aber nochmal der 
Original-Frame. So geht das bei allen Tasten im Scan.

In meinen Augen kann das eigentlich nur daran liegen. Vielleicht baue 
ich dieses 3-Frame-Telegramm mal als Besonderheit in den IRMP ein - 
vielleicht hilft das weiter. Dabei würde ich dann auch die Pausen 
zwischen dem 2. und dem 3. Frame mal genau umsetzen - nicht mit dem 
Trick der Wiederholung.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

passt die Beschreibung von 
http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es 
am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

noch eine Quelle: S.15 in 
http://tinkerish.com/docs/ir%20remote%20control%20...

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> passt die Beschreibung von
> http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es
> am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?

Diese Beschreibung ist tatsächlich sehr ähnlich zum Denon-Protokoll. Im 
obigen Link wird von

  0 Start-Bits
  5 Adress-Bits
  8 Daten-Bits
  1 Expansion-Bit - immer 1
  0 Check-Bit - immer 0

gesprochen. Das macht zusammen 15 Bits.

Das Denon-Protokoll setzt sich zusammen aus:

  0 Start-Bits
  5 Adress-Bits
 10 Daten-Bits

macht also zusammen auch 15 Bits.

Tatsächlich sind die beiden letzten Bits auch "10" in deinen Scans, das 
passt also auf die Beschreibung des Expansion- und Check-Bits.

Die Timings sind auch sehr ähnlich:

          Denon       Sharp
Pulse     275µs       320µs
Pause 0   775µs       680µs
Pause 1  1900µs       1680µs

Tatsächlich sind diese Timings innerhalb der IRMP-Toleranzen identisch, 
IRMP kann diese also gar nicht auseinanderhalten. Es passt alles: Anzahl 
der Bits und die Timings.

Wenn ich mir die Timings innerhalb Deines Scans anschaue, so liegen sie 
ziemlich zwischen den obigen Werten, ich kann also auch nicht genau 
sagen, ob es eher Denon- oder Sharp-Timings sind.

Aber was gar nicht passt, ist die Modulationsfrequenz, bei Denon ist sie 
32 kHz, bei Sharp ist sie 38 kHz.

Ändere also bitte folgendes zum Testen des IRSND:

1. Modulationsfrequenz von 32 kHz auf 38 kHz:

Alt:
   case IRMP_DENON_PROTOCOL:
   {
       ...
       irsnd_set_freq (IRSND_FREQ_32_KHZ);

Neu:
   case IRMP_DENON_PROTOCOL:
   {
       ...
       irsnd_set_freq (IRSND_FREQ_38_KHZ);

2. Timings in irmp.h:
#define DENON_PULSE_TIME                        320.0e-6                        //  320 usec pulse
#define DENON_1_PAUSE_TIME                      1680.0e-6                       // 1680 usec pause
#define DENON_0_PAUSE_TIME                       680.0e-6                       //   680 usec pause
#define DENON_FRAMES                            2                               // DENON sends each frame 2 times

Probiere das einmal mit irmp_data.flags = 0 und dann, wenn das nichts 
hilft, mit irmp_data.flags = 1.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Ändere also bitte folgendes zum Testen des IRSND:

funktioniert. Es bedarf noch nicht einmal der Framewiederholung.

Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp 
von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab, 
unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den 
40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen 
Code besser und findest bestimmt einen Weg.

Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> funktioniert. Es bedarf noch nicht einmal der Framewiederholung.

Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung 
der Original-Denon-Timings? Wäre klasse, wenn Du das noch separat testen 
würdest.

> Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp
> von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab,
> unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den
> 40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen
> Code besser und findest bestimmt einen Weg.

Ja, ich werde da nochmal die genauen Unterschiede untersuchen. Mit 
Codekenntnis hat das weniger zu tun, eher mit meinen (bescheidenen) 
Protokollkenntnissen ;-)

Das Expansion- und Check-Bit sind leider nur ein notwendiges, aber kein 
hinreichendes Kriterium für Sharp. Die "10"-Kombi kann durchaus auch bei 
Denon vorkommen. Bleiben dann noch die Pausen zwischen den Frames. Da 
habe ich noch nicht so genau hingeschaut...

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung
> der Original-Denon-Timings?

nein. Es bedarf definitiv der Sharp-Timings.

Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen 
den Frames. Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz 
Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch 
daran halten.

Gruß, eku

Autor: Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Frank

für deine Hilfe nun da kann woll mal wieder alles aufeindander.

Nun leuft es habe meine Hardware angepasst danke.

mfg
Müller

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

Bewertung
0 lesenswert
nicht lesenswert
Müller schrieb:

> Nun leuft es habe meine Hardware angepasst danke.

Prima. Hast Du die RC6- und RC6A-Protokolle im IRSND schon testen 
können?

Gruß,

Frank

Autor: form (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, nettes Projekt.
Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins 
für den Empfänger und die IR-Diode frei wählbar sind?

Keine Interrupt-Pins beim Empfangen nötig?
Keine PWM-Pins beim Senden nötig?

MfG
Stefan

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

Bewertung
0 lesenswert
nicht lesenswert
form schrieb:

> Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins
> für den Empfänger und die IR-Diode frei wählbar sind?

Beim IRMP: ja.
Beim IRSND: jain, s.u.

> Keine Interrupt-Pins beim Empfangen nötig?

Korrekt, es wird gepollt.

> Keine PWM-Pins beim Senden nötig?

Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.

Siehe auch den entsprechenden Abschnitt "Modulation" im IRMP-Artikel:

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

Gruß,

Frank

Autor: jar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.

wenn nötig ginge auch soft PWM - dazu gibts hier Beispiele in der 
Codesammlung

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hast Du schon Zeit und Muse gehabt, das SHARP Protokoll zu 
implemetieren?

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen
> den Frames.

Das kann ich nicht bestätigen. Wenn ich mir IR-Data/denon-15kHz.txt 
anschaue, ist die Pause zwischen dem ersten und dem zweiten Frame 
ziemlich genau 653 Ticks, das macht dann wg. der Scanrate 653/15 = 44ms.

Wenn ich Deine sharp.log dagegenhalte, bekomme ich da ca. 40-43 ms 
heraus, also fast denselben Wert.

> Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz
> Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch
> daran halten.

Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du 
hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate 
vergessen :-)

Oder hast Du da mehr Scans von Denon-FBs?

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

Frank M. schrieb:
> Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du
> hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate
> vergessen :-)

das ist gut möglich. Die Standardabtastrate für Denon beträgt doch aber 
10kHz. Eine Implementierung des SHARP-Protokolls in IRSND mit den 
Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.

> Oder hast Du da mehr Scans von Denon-FBs?

Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf 
verschiedene Geräte umstellen lässt und genau eine Sharp. Über die 
Feiertage werde ich mal ein paar Scans aufzeihnen.

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> Eine Implementierung des SHARP-Protokolls in IRSND mit den
> Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.

Klar, das kann ich gern machen. Aber wie erkläre ich den Anwendern, dass 
man das Sharp-Protokoll nehmen muss, wenn IRMP zuvor das Denon-Protokoll 
erkannt hat?

> Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf
> verschiedene Geräte umstellen lässt und genau eine Sharp. Über die
> Feiertage werde ich mal ein paar Scans aufzeihnen.

Das ist gut. Vielleicht kann man das besser an der Anzahl der Frames 
erkennen, die pro Taste geschickt werden. Mein Denon-Scan enthielt da 
immer 2 Frames pro Taste, die Sharp-FB schickte immer 3 Frames, nämlich:

Denon:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando

Sharp:

1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando

Deshalb bitte beim Einscannen drauf achten, die Tasten möglichst kurz zu 
drücken.

Gruß,

Frank

Autor: Stefan P. (form)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im 
IRMP-Wikiartikel eingefügt:
http://forum.mikrokopter.de/topic-21060.html

Vielen Dank nochmal an Frank für Deine großartigen Routinen.

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan P. schrieb:
> Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im
> IRMP-Wikiartikel eingefügt:
> http://forum.mikrokopter.de/topic-21060.html

Schön! Am witzigsten fand ich es übrigens, mit der Servo-Fernbedienung 
den Fernseher lauter/leiser zu drehen...
Das Youtube-Video dazu wäre doch ein prima Link ;-)

Autor: Stefan G. (dreamer83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin derzeit dabei einen Umsetzer von ner Opel Lenkradfernbedienung auf 
mein Sony Autoradio (Infrarot) mit nem AVR-Mega8 zu machen.
Ich habe vorerst nen kleines Prog geschrieben, was die IR-Codes leicht 
zeitverzögert wieder sendet. Getestet wurde dass ganze zuerst mit meinem 
TV der das NEC-Protokoll verwendet, was problemlos funktioniert.
Jedoch jeder Versuch ein erfolgreiches SIRCS Protokoll zu versenden ist 
bisher gescheitert. Das Protokoll wird anscheinend jedoch richtig 
erkannt. So wird mir über den UART bei jedm Tastendruck 1-2 Codes 
ausgegeben die als Command im Bereich von 0x4200 bis 0x4247 liegen.

Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal 
anzusehen.

Wo könnte mein Problem sein?

Gruß Stefan

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Grimm schrieb:
> Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal
> anzusehen.
Beitrag "Re: IR Signal - Welches Protokoll?"
Soundkarte reicht.

Autor: Stefan G. (dreamer83)
Datum:
Angehängte Dateien:
  • TX.wav (49,3 KB, 116 Downloads)
  • RX.wav (67,3 KB, 111 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip, auch wenn ich mit den Spannungen an der Soundkarte 
vorsichtig sein würde.

Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger 
registrierte Signal ist in der Datei "RX.wav" gespeichert das vom 
Controler gesendete in "TX.wav". Im Log ist der Pegel vom Senden 
aufgrund meiner Beschaltung noch invertiert.
Der nach Irmp ausgewertete Code soll SIRCS mit Adresse 0 und den 
Commands 0x4233  gefolgt von 0x4245 sein.

Gruß Stefan

Autor: Stefan G. (dreamer83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal ne grobe Übersicht über die beiden Logs.

Die Signale stehen zueinander in keinem zeitlichen Verältniss.

Gruß Stefan

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

Stefan Grimm schrieb:

> Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger
> registrierte Signal ist in der Datei "RX.wav" gespeichert das vom
> Controler gesendete in "TX.wav".

Besser wäre es, wenn Du mal einen Scan per IRMP machst - einmal mit kurz 
und einmal mit lang gedrückten Tasten - mindestens zwei.

Wenn die mit IRSND gesandten Daten vom Radio nicht dekodiert werden 
können, kann das folgende Gründe haben:

1. Schlechtes Timing:

   Quarz am µC verwenden! Die Dekodierer in den industriellen Geräten
   sind nicht so timing-tolerant wie IRMP.

2. Falsche Modulationsfrquenz:

   Eventuell benutzt die Original-FB zum Radio eine abweichende
   Modulationsfrequenz

3. Leichte Abweichungen vom SIRCs-Protokoll

   Zum Beispiel kann dies der Fall sein bei der Anzahl der
   Wiederholungsframes, die gesandt werden müssen, bevor das Gerät
   einen Befehl als gültig erkennt.

4. Bug in IRSND

   Wovon ich aber nicht ausgehe ;-)

Kann denn IRMP das per IRSND gesandte Signal wieder dekodieren?
Welche Interruptfrequenz benutzt Du (sowohl beim IRMP als beim IRSND)?

Wie gesagt: eine per IRMP erstellte Scan-Datei (analog zu IR-Data/*.txt) 
würde hier weiterhelfen.

Gruß,

Frank

Autor: Stefan G. (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Danke schon mal für die Tipps.

Ich werde heute Abend mal einen Scan machen.

Ich verwende momentan die Standartvorgaben der aktuellen IRSND & IRMP.

Werde mal ne 2.Version meiner Schaltung zum "Rescan" aufbauen.

Gruß Stefan

Autor: Stefan G. (dreamer83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Abend,

hab hier mal den Log aller Tasten der Fernbedienung.

In der IRMP verwende ich 10000 Interrupts, genauso wie in der IRSND.

habe irgendwie das Gefühl, das beim senden durch die recht großen 
Commandos irgendwas schief geht, denn es ist nicht wirklich möglich 
Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.
case IRMP_SIRCS_PROTOCOL:
  { command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
    irsnd_buffer[0] = (command & 0x0FF0) >>  4;   // CCCCCCCC
    irsnd_buffer[1] = (command & 0x000F) << 4;    // CCCC0000

    irsnd_busy      = TRUE;
    break;
  }

wenn in der oberen Zeile die Daten gespielgelt werden müsste die 
Nachricht dann ja 0xEC42 lauten. nur wie sollen die nun in den 
Sendbuffer geschrieben werden?, müsste dann 0xEC in den Buffer[0] und 
der Rest in Buffer[1] ?

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan Grimm schrieb:

> habe irgendwie das Gefühl, das beim senden durch die recht großen
> Commandos irgendwas schief geht, denn es ist nicht wirklich möglich
> Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.

Ja, das ist der Knackpunkt. Das SIRCS-Telegramm besteht laut

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

aus mindestens 12 Bits (3 Nibbles), maximal jedoch aus 20 Bits. Die 
Bitlänge ist also variabel. IRSND unterstützt momentan nur die 
12-Bit-Variante.

Ich werde mir Deine Scans mal näher ansehen und muss dann überlegen, wie 
man dem IRSND die Bitlänge beibringt.

Gruß,

Frank

Autor: Stefan G. (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab hier nen kleinen Erfolg zu verbuchen. Habe es hinbekommen, dass die 
jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die 
Anpassung nicht unbedingt schön ist.

In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define 
variabel erhöht.
  complete_data_len = SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS; 

sowie in der "irsnd_send_data"
case IRMP_SIRCS_PROTOCOL:
{
//command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN);
  command = bitsrevervse (irmp_data_p->command, SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS);

//  irsnd_buffer[0] = (command & 0x0FF0) >> 4;     // CCCCCCCC
//  irsnd_buffer[1] = (command & 0x000F) << 4;     // CCCC0000
    irsnd_buffer[0] = (command & 0x7F10) >> 7;     
    irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15 Bit
    irsnd_busy      = TRUE;
    break;
}
Somit funktioniert in meinem Fall das Senden von Befehlen. Es sind Codes 
von 0x4200 bis 0x4247 in Verwendung.

Hoffe dennoch das euch die Codes etwas bringen.

Gruß Stefan

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan Grimm schrieb:
> Hab hier nen kleinen Erfolg zu verbuchen.

Freut mich!

> Habe es hinbekommen, dass die
> jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die
> Anpassung nicht unbedingt schön ist.

Ich werde es in eine allgemeine Form bringen, Vorschlag dazu siehe 
unten.

> In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define
> variabel erhöht.
>
  complete_data_len =
> SIRCS_MINIMUM_DATA_LEN+SIRCS_ADDITIONAL_NUM_OF_BITS; 

Ich nehme an, dass bei Dir SIRCS_ADDITIONAL_NUM_OF_BITS den Wert 3 hat?

> sowie in der "irsnd_send_data"
>
>     irsnd_buffer[0] = (command & 0x7F10) >> 7;
>     irsnd_buffer[1] = (command & 0x007f) << 1;     // Anpassung auf 15
> 

Okay, das muss ich dann variabel gestalten für 
SIRCS_ADDITIONAL_NUM_OF_BITS von 0 bis 8.

Ich habe mir eine allgemeine Erweiterung folgendermaßen vorgestellt:

1. Erweiterung von IRMP_DATA um: uint8_t additional_bitlen

2. IRMP füllt beim Empfang eines Frames diese Variable mit der Anzahl
   der zusätzlich empfangenen Bits. In der Regel ist der Wert also 0,
   in Stefans Fall dann aber 3.

3. IRSND wertet im Falle von SIRCS diese neue Variable aus, um damit
   die Länge des Frames zu erhöhen.

Meinungen dazu?

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Mir ist noch eine Alternative dazu eingefallen:

Ich baue die Information der zusätzlichen Bitlänge in irmp_data.address 
mit ein. Dann kann man auf die neue Variable irmp_data.additional_bitlen 
verzichten.

Gruß,

Frank

Autor: Stefan G. (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau SIRCS_ADDITIONAL_NUM_OF_BITS ist bei mir 3.

Keine schlechte Idee mit dem Adressfeld.

Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz 
so angenehm, aber lässt sich sichrlich machen.

Gruß Stefan

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan Grimm schrieb:

> Keine schlechte Idee mit dem Adressfeld.

Ja, dieser Weg scheint mir auch vernünftiger zu sein. Ein paar Anwender 
werden dann aber bei SIRCs u.U. plötzlich andere Adresswerte bekommen 
als bisher. Ich habe dazu mal die gesammelten Scans unter 
IR-Data/Sony*.txt angeschaut: Die meisten haben 12, einige 15 und einer 
sogar 20 Bits.

Bei den 12er-Frames wird die Adresse gleich bleiben, bei den anderen 
zukünftig abweichen. Aber das ist hinnehmbar.

> Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz
> so angenehm, aber lässt sich sichrlich machen.

Ist nicht so schwer.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Im SVN ist eine neue Version von IRMP und IRSND.

Die Änderungen betreffen nur das SIRCs-Protokoll:

IRMP speichert nun die Anzahl der zusätzlichen Bits gegenüber einem 
Standard-SIRCs-Frame der Länge 12 im oberen Byte des Adressfeldes. Bei 
Frames mit Standard-Länge bleibt die Adresse 0x0000.

@Stefan Grimm: Damit sollte bei Dir nun die Adresse 0x0300 sein, da bei 
Deiner Fernbedienung 3 zusätzliche Bits gesandt werden.

IRSND wertet nun die Längeninformation im Adressfeld aus und passt 
dadurch Länge und Frame-Daten dynamisch an.

@Stefan Grimm: Kannst Du das mal testen? Bei mir habe ich es lediglich 
unter Linux per Pipe von IRSND-Daten in den IRMP testen können. IRMP 
konnte alle von IRSND generierten Frames mit SIRCs-Frame-Längen (12, 15 
und 20) einwandfrei dekodieren.

Gruß,

Frank

Autor: Sebastian .. (zahlenfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

erstmal vielen dank für das super Projekt. Hat mir sehr geholfen.

Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP 
machen? Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme, 
die auf den Stack hinweisen, aber ich kann in meinem Teil der Software 
nicht wirklich was finden. Und wenns geht wollte ichs vermeiden, IRMP 
selbst analysieren zu müssen ;-)

Gruß, Sebastian

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

Bewertung
0 lesenswert
nicht lesenswert
Sebastian ... schrieb:

> Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP
> machen?

An RAM werden ungefähr 60 Bytes verbraten, das sind allesamt static 
Variablen. Der Stack dürfte ähnlich ausfallen, da nur wenige lokale 
Variablen innerhalb der Funktion benötigt werden. Es hängt aber auch 
davon ab, wieviele/welche Protokolle Du freischaltest.

> Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme,
> die auf den Stack hinweisen, aber ich kann in meinem Teil der Software
> nicht wirklich was finden.

Dann poste Deinen Source doch mal. Und gib mal die Größe der 
Data-Section an, die beim Übersetzen ausgegeben werden. Welchen µC 
verwendest Du?

Typische RAM-Probleme bereiten zum Beispiel Arrays oder Strukturen, die 
bereits im Source mit Konstanten gefüllt werden. Diese werden beim Boot 
des µC vom Flash ins RAM kopiert, wenn Du diese Daten nicht über PROGMEM 
deklarierst.

Gruß,

Frank

Autor: Sebastian .. (zahlenfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon 
erklären.
Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein 
hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab 
ein paar größere Arrays im RAM. Mal schaun, ob ich irgendwo noch bischen 
was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab 
grad nen Mega8).

Sebastian

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

Bewertung
0 lesenswert
nicht lesenswert
Sebastian ... schrieb:
> Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon
> erklären.

Naja, Stack sollte weniger sein.

> Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein
> hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab
> ein paar größere Arrays im RAM.

Ändern sich die Werte in den Arrays? Wenn nicht, packe sie ins Flash. 
Wenn doch, aber nur selten, packe sie ins EEPROM.

> Mal schaun, ob ich irgendwo noch bischen
> was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab
> grad nen Mega8).

Mega8 ist obsolet, wechsle besser auf den pinkompatiblen Mega88 oder auf 
den Mega168 mit doppelt soviel Speicher. Dann sollten Deine Probleme der 
Vergangenheit angehören.

Gruß,

Frank

Autor: Sebastian .. (zahlenfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Mega8 lag halt noch rum. Irgendwann müssen die ja auch mal wegkommen 
^^

Ein Teil der Arrays sind nur Kopien ihrer EEPROM-Version und werden fast 
nur gelesen und sehr selten geschrieben. Ich habs auch schon probiert, 
einfach live aus dem EEPROM zu lesen. Wie erwatet waren die Probleme 
weg. Nur hab ich das ganze in der Bedienung unangenehm gemerkt...

Wie gesagt: Wenn mir nichts vernünftiges für die Software einfällt gibts 
den nächst größeren Controller. Ich wollte halt gerne wissen, ob das 
wirklich ein RAM-problem sein könnte, oder ob ich irgendwas anderes auch 
noch falsch gemacht habe.

Gruß, Sebastian

Autor: eku (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz 
Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die 
Protokolle auseinanderhalten kann.

Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo eku,

eku schrieb:

> anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz
> Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die
> Protokolle auseinanderhalten kann.

Erstmal danke für die Erstellung der Scans.

denon2_kurz_10khz.txt kann ich leider nicht verwenden, irmp erkennt das 
Zeugs nicht. Da scheint jeder Frame aus nur 3 Bits zu bestehen.

Auswerten konnte ich also nur denon1, denon3 und sharp.

Leider unterscheiden sie sich nur minimal. Damit kann man definitiv 
keine Unterscheidung hinbekommen. Beide senden 3 Frames, wo die Pausen 
dazwischen fast identisch sind. Die Abweichungen liegen im einstelligen 
Prozentbereich. Da könnte man lediglich über statistische Auswertungen 
eine Unterscheidung hinbekommen.

Du hattest ja gesagt, dass das Sharp-Gerät nicht auf die 
Original-Denon-Timings reagiert. Wie sieht es denn umgekehrt aus? Kommt 
das Denon-Gerät mit den Sharp-Timings zurecht?

Es gäbe ja noch die Möglichkeit, im IRSND mit einem Kompromiss im Timing 
zu arbeiten, so dass sowohl Denon als auch Sharp die von IRSND 
ausgesandten Frames verstehen. Idee ist also, die etwas verschiedenen 
Timingwerte durch entsprechende Versuche soweit anzunähern, dass beide 
Geräte damit zurechtkommen.

Könntest Du mal so eine Versuchsreihe starten? Ich kann es leider nicht, 
denn ich habe weder ein Gerät von Denon noch eins von Sharp.

irmp mit der Option -a verrät über die Timings Deiner Scans:

           Sharp       Denon1     Denon3
Puls       320 µs      300 µs     300 µs
Pause0     735 µs      745 µs     745 µs
Pause1    1781 µs     1783 µs    1783 µs

Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich

   http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON
   http://www.mikrocontroller.net/attachment/4246/IR-...

Vielleicht sind die dort angegebenen Werte

           Denon
Puls       275 µs
Pause0     775 µs
Pause1    1900 µs

einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit 
neben der Realität?

Deine Denon-Fernbedienungen liegen jedenfalls viel näher an den 
Sharp-Timings als an den Timings aus der obigen Dokumentation!

Fazit:
======

Wie wäre es, wenn Du in irmp.h einstellst:
#define DENON_PULSE_TIME         310.0e-6  //  310 usec pulse
#define DENON_1_PAUSE_TIME      1780.0e-6  // 1780 usec pause
#define DENON_0_PAUSE_TIME       745.0e-6  //  745 usec pause

und dann nochmal zunächst IRMP testest mit beiden FBs und anschließend 
diese Timings auch für IRSND testest mit Deinem Denon- und Sharp-Gerät?

Ich glaube fest daran, dass beide Geräte die obigen Timings schlucken 
;-)

Wenn ja, werde ich die obigen Werte ab sofort im Source verwenden.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich
[...]
> Vielleicht sind die dort angegebenen Werte
>
>            Denon
> Puls       275 µs
> Pause0     775 µs
> Pause1    1900 µs
>
> einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit
> neben der Realität?

http://lirc.sourceforge.net/remotes/denon/
http://www.hifi-remote.com/johnsfine/DecodeIR.html

> Wie wäre es, wenn Du in irmp.h einstellst:

Probiere ich aus.

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

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> http://lirc.sourceforge.net/remotes/denon/

Zumindest die Werte der ersten 5 FBs in diesem Verzeichnis bekräftigen 
meinen Eindruck, dass in der Realität die Denon-Timings eher denen der 
Sharp-FB entsprechen und nicht den Werten in meinen herangezogenen 
Dokumenten.

> Probiere ich aus.

Bin gespannt.

Gruß,

Franak

Autor: Colt F. (Firma: TUC) (coltfish)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben 
(besonders natürlich Frank M.) einen herzlichen Dank aussprechen.
Tolle Arbeit, ich ziehe meine Hut!

Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit 
16Bit-PIC portieren können, die Performance ist super.

Gruß
Daniel

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

Bewertung
0 lesenswert
nicht lesenswert
Colt Fish schrieb:

> möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben
> (besonders natürlich Frank M.) einen herzlichen Dank aussprechen.
> Tolle Arbeit, ich ziehe meine Hut!

Danke fürs Danke :-)

> Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit
> 16Bit-PIC portieren können, die Performance ist super.

Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den 
Standard-Source mit einfließen zu lassen?

Gruß,

Frank

Autor: Colt F. (Firma: TUC) (coltfish)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den
> Standard-Source mit einfließen zu lassen?

Nicht wirklich. Ich habe nur die Datentypen umbenennen müssen. Der C30 
Compiler von Microchip ist ja ebenfalls ein gcc.
Und natürlich das Setup von Timer und Interrupts muss angepasst werden, 
welches allerdings stark vom verwendeten Chip abhängt.

Gruß
Daniel

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

Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> Probiere ich aus.

Ich habe gerade einen systematischen Bug im IRSND entdeckt: sämtliche 
gesendete Pausen waren bisher 1 Interrupt-Tick zu lang. Ich habe das 
gerade korrigiert und den Source im SVN eingecheckt.

Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt 
auch die ermittelten Praxiswerte für das Denon-Timing drin.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Die letzten Änderungen im SVN seit September 2010 sind nun eingeflossen 
in eine neue IRMP- und IRSND-Version 1.9.0.

Änderungen IRMP seit 1.8.1:

  - Korrekturen für Siemens-Protokoll
  - Neues Protokoll: NIKON
  - Speichern der zusätzlichen Bits (>12) im SIRCS-Protokoll in der
    Adresse
  - Timing-Korrekturen für Denon-Protokoll

Download IRMP:

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

Änderungen IRSND seit 1.8.0:

  - Neues Protokoll: RC6A
  - Neues Protokoll: RC6
  - Neues Protokoll: NIKON
  - Beachten der zusätzlichen Bits (>12) im SIRCS-Protokoll
  - Korrektur der Pausenlängen
  - Timing-Korrekturen für Denon-Protokoll

Download IRSND:

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

Viel Spaß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

> Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt
> auch die ermittelten Praxiswerte für das Denon-Timing drin.

wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun 
beide mit dem Denon-Protokoll steuern. Allerdings liegt die 
Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor 
sie erkannt werden.

In welche Richtung kann ich das Timing noch verändern? Mehr hin zum 
Sharp oder wieder zu den alten Denon Werten?

Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo eku,

eku schrieb:
> Hallo Frank,
>
> wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun
> beide mit dem Denon-Protokoll steuern. Allerdings liegt die
> Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor
> sie erkannt werden.

Ist es bei beiden 80%?

> In welche Richtung kann ich das Timing noch verändern? Mehr hin zum
> Sharp oder wieder zu den alten Denon Werten?

Als erstes würde ich mal mit der Modulationsfrequenz spielen. In der 
Denon-Doku las ich immer was von 32kHz. Aber das glaube ich nicht so 
recht. Probiere mal 32kHz, 36kHz und 38kHz.

Wenn das nichts bringt, verschiebe die Timings mal zu den alten 
Denon-Werten.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich 
sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die 
Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp 
reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.

Ein kleinerSchönheitsfehler ist mir noch aufgefallen:

irmp/irsnd.c: In function 'ir_tx_put':
irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'

Diese Variable sollte nur für RC6 einkompiliert werden.


Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen 
Stand dann noch zu Ethersex portieren.

Gruß, eku

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo eku,

eku schrieb:

> mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich
> sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die
> Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp
> reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.

Vielen Dank für die wichtige Info. Ich werde also 36 kHz in irsnd.c 
eintragen und die Timings so lassen, wie sie aktuell sind. Sie 
entsprechen ja auch im Wesentlichen den von Dir gescannten Werten und 
passen auch zur lirc-DB.

> Ein kleinerSchönheitsfehler ist mir noch aufgefallen:
>
> irmp/irsnd.c: In function 'ir_tx_put':
> irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'
>
> Diese Variable sollte nur für RC6 einkompiliert werden.

Danke, das war ein Copy-And-Paste-Fehler, die RC5-Bedingung ist hier an 
dieser Stelle falsch.

Alt:
#if IRSND_SUPPORT_RC5_PROTOCOL == 1
    static uint8_t  toggle_bit_rc6;
#endif

Neu:
#if IRSND_SUPPORT_RC6_PROTOCOL == 1 || IRSND_SUPPORT_RC6A_PROTOCOL == 1
    static uint8_t  toggle_bit_rc6;
#endif

Werde ich ebenfalls korrigieren.

> Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen
> Stand dann noch zu Ethersex portieren.

Auch von mir vielen Dank für Deine wirklich hilfreichen Experimente.

Gruß,

Frank

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pollin hat eine neue IR-Tastatur:  711 057

Autor: eku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Ich werde den aktuellen Stand dann noch zu Ethersex portieren.

Ethersex' IRMP ist nun auch auf dem aktuellen Stand. Viel Spaß damit!

http://www.ethersex.de

Autor: iffi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

genau so etwas wie IRMP habe ich gesucht! :)  Für ein Uni-Projekt will 
ich Infrarot-Signale an einem MSP430 empfangen. Da es so viele 
unterschiedliche Protokolle gibt, stellte sich mir die Frage, welche 
Protokolle ich implementieren soll. Jetzt sehe ich, dass in IRMP schon 
die meisten implementiert und ausgiebig getestet sind.

Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu 
bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.

Viele Grüße

Autor: Fred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist ja ein tolles Projekt. Ich habe mir das Ganze mal auf einen ATMEGA8
16MHz angepasst und noch eine Ausgabe für die Serielle eingefügt.

So, dann gleich ein paar FB ausprobiert und es klappt recht gut. Nur 
eine FB mag so gar nicht. Mit der hatte ich aber auch schon früher 
Probleme.
Eine Universal FB konnte sie jedenfalls nicht nachbilden.

Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
Hersteller ist ruwido und es ist bereits die zweite Generation.

Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten 
der Reihenfolge nach betätigt.

Kann man da was erkennen?

Gruß Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
> Hersteller ist ruwido und es ist bereits die zweite Generation.
>
> Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten
> der Reihenfolge nach betätigt.

Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl 
der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt. Leider sind da 
noch ein paar Ungenauigkeiten drin, wo ich nicht weiß, ob das 
Aufzeichnungsfehler sind oder etwas anderes.

Ändere in irmp.h mal testweise:

Alt:
#define RC5_ADDRESS_OFFSET                      2                               // skip 2 bits (2nd start + 1 toggle)
#define RC5_ADDRESS_LEN                         5                               // read 5 address bits
#define RC5_COMMAND_OFFSET                      7                               // skip 5 bits (2nd start + 1 toggle + 5 address)
#define RC5_COMMAND_LEN                         6                               // read 6 command bits
#define RC5_COMPLETE_DATA_LEN                   13                              // complete length

Neu:
#define RC5_ADDRESS_OFFSET                      1                               // skip 1 bit
#define RC5_ADDRESS_LEN                         3                               // read 3 address bits
#define RC5_COMMAND_OFFSET                      4                               // skip 4 bits
#define RC5_COMMAND_LEN                         13                              // read 13 command bits
#define RC5_COMPLETE_DATA_LEN                   17                              // complete length

Dann ist die Erkennungsrate bei über 70 Prozent.

Aber wie gesagt: das ist nur ein Test, keine endgültige Lösung. Denn das 
RC5-Protokoll hat tatsächlich nur 13 Bits.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
iffi schrieb:

> genau so etwas wie IRMP habe ich gesucht! :)  Für ein Uni-Projekt will
> ich Infrarot-Signale an einem MSP430 empfangen.

Wenn Du IRMP auf MSP430 portiert hast, kannst Du mir gerne die 
Änderungen nennen (z.B. über #ifdef MSP430), damit ich die Anpassungen 
einpflegen kann.

> Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu
> bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.

Danke fürs Danke :-)

Gruß,

Frank

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl
> der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt.

Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt 
sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz 
zu RC5 jedoch invertiert. Die unter 
http://www.mikrocontroller.net/articles/MOTOROLA_V... 
ist recht ähnlich.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:

> Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt
> sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz
> zu RC5 jedoch invertiert.

Die Bitlänge ist definitiv 17 und nicht 23.

Wenn ich in irmp.c die Toleranz für RC5 von 10% auf 20% hochsetze:
#define RC5_START_BIT_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RC5_START_BIT_LEN_MAX                   ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RC5_BIT_LEN_MIN                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RC5_BIT_LEN_MAX                         ((uint8_t)(F_INTERRUPTS * RC5_BIT_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz 
am µC?

Leider hast Du in der Scan-Datei keine Kommentare eingepflegt. Ich habe 
nämlich gesehen, dass von den 44 Tastendrücken, die Du aufgezeichnet 
hast, 14 identisch sind, es tatsächlich also nur 30 verschiedene Tasten 
waren.

Um nun herauszufinden, ob der Code tatsächlich invertiert ist oder 
nicht, bitte ich Dich, zumindest die Tasten 0-9 nochmal aufzuzeichnen 
und mit einer Kommentarzeile vor jeder Scan-Zeile zu versehen, siehe 
dazu auch die anderen Scan-Dateien im Unterverzeichnis IR-Data.

Gruß,

Frank

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz
> am µC?

ja, einen 16MHz.

Die Info mit den 23 Bit stammt nicht von mir. Da bin ich mir aber auch 
nicht sicher, was da mit dazugerechnet wurde.

Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45 
verschiedene Codes in der alten Scandatei sein.

Bewirkt die Invertierung der Manchestercodierung irgendwas?

Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.


Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> ja, einen 16MHz.

Dann ist die Fernbedienung so "wackelig" ;-)

> Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45
> verschiedene Codes in der alten Scandatei sein.

Leider nicht. Die Datei hat 44 Zeilen, aber 14 Codes sind doppelt.

> Bewirkt die Invertierung der Manchestercodierung irgendwas?

Nein, nur dass die Codes invertiert sind und dann "riesengroße" Zahlen 
ergeben. Ich glaube nicht, dass die tatsächlich zu invertieren sind. Das 
wird man aber besser sehen, wenn die Zeilen kommentiert sind, denn meist 
geben die Tasten 0 bis 9 einen fortlaufenden Code ab.

> Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.

Prima.

Gruß,

Frank

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal vielen Dank dafür das es Leute gibt die Ihre Projekte anderen 
zugänglich machen :)

Hab gerade das erste Mal mit IRMP rumgespielt und bin begeistert. Hab 
aber auch eine Fernbedienung gefunden die nicht funktionieren will.

Die Fernbedienung gehört zu einem IMON-Display (für den PC).

Hab mal n Paar tasten gedrückt und das File angehängt :)
Ist das Normal das die einzelnen Befehle sich so stark in der Länge 
unterscheiden?
Kann jemand erkennen was das für n Protokoll is?

Danke :)

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fred: Kannst du mir bitte mal deine portierte Version für den Atmega8 
zukommen lassen?
Danke,
Basti

bastian.felten[ät]gmail[dot]com

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon wieder ich...
Ich habe einen TSOP1838 an PB6 eines mit 8 MHz getakteten Atmega88 
angeschlossen, der in einem STK500 steckt.
RX/TX hängen an PD0/PD1 und in der irmpconfig.h wurde das logging 
aktiviert.
HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen 
Ausgabe.

Muss man sonst noch etwas einstellen, oder was könnte das Problem sein?

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

Bewertung
0 lesenswert
nicht lesenswert
Bastian F. schrieb:
> HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen
> Ausgabe.

Zeig mal Deine irmpconfig.h und deine main-Funktion.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:

> Die Fernbedienung gehört zu einem IMON-Display (für den PC).
>
> Hab mal n Paar tasten gedrückt und das File angehängt :)

Habe das mal durch "irmp -a" gejagt. Scheint tatsächlich ein neues 
Protokoll zu sein, was aber relativ einfach zu decodieren ist.

> Ist das Normal das die einzelnen Befehle sich so stark in der Länge
> unterscheiden?

Sieht so aus, als ob das einfach Schrott ist. Kann es sein, dass da eine 
Neonröhre oder ähnliches in der Nähe leuchtete?

> Kann jemand erkennen was das für n Protokoll is?

Eines, welches IRMP noch nicht beherrscht. Ich baue es ein und melde 
mich danach nochmal mit einer Lösung.

Gruß,

Frank

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zeig mal Deine irmpconfig.h und deine main-Funktion.

Ich befürchte, dass ich das ganze noch nicht wirklich verstanden habe.
Die main Funktion habe ich nämlich nicht verändert und wenn ich mir die 
anschaue, wird dort nirgends das Logging bzw die entsprechende Ausgabe 
aufgerufen wird.
Bin davon ausgegangen, dass das einfach durch das Setzen der "1" 
passiert.
Was muss ich denn eintragen, dass ich eine Ausgabe bekomme?

Autor: Stefan G. (dreamer83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

seh dir einfach mal das Projekt hier ganz oben auf der Seite an. In der 
main.c ist ein funktionierendes Beispiel zur Ausgabe des "normalen" 
Codes.

Gruß Stefan

Autor: Fred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat ne Weile gedauert aber ich kam nicht früher heim :-(

So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten
jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile
erhalten. Ich hoffe, das ist so brauchbar.

Für die Atmega8 Version brauchte ich nicht viel anpassen. Im Projekt
den entsprechenden Controller und Takt einstellen und in der 
irmpconfig.h
noch den entsprechenden Port wählen.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:
> So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten
> jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile
> erhalten. Ich hoffe, das ist so brauchbar.

Ja, der Scan ist sehr gut brauchbar. Was mir auffällt, dass der "Jitter" 
wesentlich geringer ist. Die Puls-/Pause-Zeiten in r-step.txt sind 
wesentlich exakter als die in t-home.txt.

Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung 
(z.B. mit/ohne Quartz) verwendet?

Was mir noch auffiel: Kommen hier beim Manchester-Protokoll zwei Pulse 
oder Pausen direkt hintereinander, weichen sie etwas von der doppelten 
Dauer, die man erwarten müsste, ab. Ich musste dafür den 
Manchester-Decoder im IRMP etwas "aufbohren", um so ein asymmetrisches 
Verhalten besser abbilden zu können.

Ausserdem sind die Bits hier tatsächlich "negiert", d.h. bei einer 1 
kommt erst der Puls, dann die Pause. Damit erhöht sich die Anzahl der 
Bits im Frame von 17 auf 18. Das letzte Bit ist ein Parity-Bit, was von 
IRMP nicht ausgewertet wird.

Hier das Ergebnis, gekürzt um die Wiederholungen:

#1 000110010100000010 p = 23, a = 0x0065, c = 0x0001, f = 0x00
#2 000110010100000101 p = 23, a = 0x0065, c = 0x0002, f = 0x00
#3 000110010100000110 p = 23, a = 0x0065, c = 0x0003, f = 0x00
#4 000110010100001001 p = 23, a = 0x0065, c = 0x0004, f = 0x00
#5 000110010100001010 p = 23, a = 0x0065, c = 0x0005, f = 0x00
#6 000110010100001101 p = 23, a = 0x0065, c = 0x0006, f = 0x00
#7 000110010100001110 p = 23, a = 0x0065, c = 0x0007, f = 0x00
#8 000110010100010001 p = 23, a = 0x0065, c = 0x0008, f = 0x00
#9 000110010100010010 p = 23, a = 0x0065, c = 0x0009, f = 0x00
#0 000110010100010101 p = 23, a = 0x0065, c = 0x000a, f = 0x00

Die Adresse ist also 0x65, der Code geht von 0x01 bis 0x0a. Das passt 
sehr gut.

Bevor ich den Code veröffentliche, möchte ich obige erste Frage 
beantwortet haben. Denn der Ruwiodo-Decoder versteht zwar jetzt 
r-step.txt ganz gut, jedoch nicht mehr t-home.txt, welches zu nahe an 
den RC5-Timings ist.

Gruß,

Frank

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich hab eben nochmal auf der Fernbedienung rumgedrückt - und siehe da: 
alle Befehle gleich lang.
Keine Ahnung was da gestört hatte. Neonröhre hab ich hier nicht. Alles 
was zu dem Zeitpunkt geleuchtet hatte war mein Display :)

Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das 
ja dann die Arbeit (kenn mich damit ja nich so aus ;)).

Ach... Nochmals danke für deine Arbeit! :)


Martin

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

Martin schrieb:
> Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das
> ja dann die Arbeit (kenn mich damit ja nich so aus ;)).

Danke. Mittlerweile bin ich mit der imon.txt durch. Es handelt sich um 
kein Fernbedienungsprotokoll im klassischen Sinne. Es ist weder 
Manchester-codiert noch ist ein Pulse-Distance Protokoll. Es ist viel 
einfacher, nämlich einfach bitseriell mit 38 Bits, wenn ich mich nicht 
verzählt habe.

Das kann IRMP nicht. Einfacher wäre es, einen Software-Uart (i.d.R. 8 
Bit) auf 38 Bit umzuschreiben. ;-)

Naja, ich schaue mir nochmal imon2.txt an. Dann entscheide ich, ob ich 
das in IRMP einbaue oder nicht.

Gruß,

Frank

Autor: herby (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank M.,

erstmal vielen Dank für Deine tolle Arbeit.
Ich habe hier auch eine imon-Fernbedienung mit dem Namen "Veris RM200".
Sie gehört zu einem PC-Gehäuse von Antec.
Allerding werden hier im Gegensatz zu Martin´s Protokoll je Tastendruck
zwei Pakete gesendet.
Es wäre schön wenn das Protokoll in deine Software integriert werden 
könnte.

Schonmal vielen Dank

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung
> (z.B. mit/ohne Quartz) verwendet?

Hallo,

ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,
Da ich die Fuses erst danach geändert habe.

Zusätzlich liegt die Samplerate jetzt bei 24000.

Soll ich das mal mit weniger oder eben einer anderen Rate noch mal 
scannen?

Vielleicht hat ja noch jemand die FB zum MOTOROLA VIP1710, die sollte ja 
so ähnlich sein.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,
> Da ich die Fuses erst danach geändert habe.

Ahja, das erklärt das Verhalten. Da die Timings sehr nahe bei RC5 
liegen, kann ich hier auch nur die Verwendung eines Quarzes empfehlen.

> Zusätzlich liegt die Samplerate jetzt bei 24000.
>
> Soll ich das mal mit weniger oder eben einer anderen Rate noch mal
> scannen?

24000 ist zuviel, da läuft der Log-Buffer im IRMP über. Wenn Du nochmal 
Lust hast, kannst Du das gern mit 15000 wiederholen. Dann bekomme ich 
auf jeden Fall genauere Werte.

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
@Fred:

Ich habe die Unterstützung der T-Home Mediareceiver-FB (neues Protokoll 
"RUWIDO") ins SVN eingecheckt. Du kannst ja mal testen, ob damit die FB 
sauber erkannt wird. Du musst aber in irmpconfig.h das RUWIDO-Protokoll 
noch freischalten. Standardmäßig ist es abgeschaltet.

Gruß,

Frank

Autor: Klaus L. (kllei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, melde mich auch mal wieder im IRMP Projekt zurück ;-)

Gibt es schon praktische Erfahrung mit RC6(a) in irsnd? Ich habe das 
gerade in Ethersex probiert, da wackelt der Pin garnicht. Hat es jemand 
schon mal "nativ" probiert? (RC5, NEC, SIRCS und andere funktionieren 
da)

Hab leider meine IRMP Testumgebung vollkommen zerlegt...

Danke für einen Input.

Grüße,
Klaus

Autor: Klaus L. (kllei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, die Frage hätte ich mir sparen können ;-)
Test war einfacher aufzubauen als gedacht, irsnd schickt alles und irmp 
erkennt den Code. Wie zu erwarten.

Hat jemand Ethersex am laufen mit irsnd und könnte RC6 mal testen?

Grüße,
Klaus

Autor: Klaus L. (kllei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, in Ethersex fehlt der Teil der RC6 sendet in der Datei irsnd_lib.c
Werde ich dann mal einbauen.
Sorry für das kleine Selbstgespräch ;-)

Klaus

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie genau kann man denn nun loggen?
Wie gesagt, habe ich nur das Logging aktiviert und sonst nichts am 
Programm geändert. Und das scheint ja schonmal falsch zu sein.
Wird wohl nur der Aufruf einer Funktion oä sein, aber ich verstehe es 
leider nicht, bzw kann diese Funktion nicht finden.
Wäre nett, wenn sich jemand erbarmen würde und mir dies erklären könnte.
Im ersten Entwurf "hier ganz oben auf der Seite" habe ich dahingehend 
auch nichts finden können.
Danke!

Autor: Fred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nun die Version aus dem SVN neu gezogen und die beiden 
Logdateien
erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.
Dies wäre aber mit RC80 usw. nötig.

Leider funktioniert die Erkennung von ruwido noch nicht richtig.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> ich habe nun die Version aus dem SVN neu gezogen und die beiden
> Logdateien
> erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Danke, schaue ich mir an.

> Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.

Wieso nicht? Compiler-Fehlermeldung oder was anderes, was nicht mehr 
geht?

> Dies wäre aber mit RC80 usw. nötig.

Du meinst RECS80? Hat das mal bei Dir funktioniert? Ich habe bisher von 
niemandem eine Rückmeldung zu RECS80 erhalten, der IRMP-Code dazu war 
bisher absolut ungetestet.

> Leider funktioniert die Erkennung von ruwido noch nicht richtig.

Wie äußert sich das?

Gruß,

Frank

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> ich habe nun die Version aus dem SVN neu gezogen und die beiden
> Logdateien
> erzeugt. Ein mal mit Abtastrate 10000 und 15000.

Ich habe die mal verglichen mit Deiner vorhergehenden r-step.txt. Dort 
sind die Pulse und Pausen ziemlich genau doppelt so lang wie in 
home10k.txt. Kann es sein, dass Du r-step.txt mit 20kHz aufgenommen 
hast? Das hättest Du mir sagen müssen! Jetzt sind die Timingwerte für 
das RUWIDO-Protokoll alle viel zu kurz :-(

Bitte um Aufklärung.

Gruß,

Frank

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben
eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.
Die beiden anderen mit 15000 und 10000. Ich hätte da noch ein 20000 und
25000 erzeugt, aber das ging ja nicht mehr.

Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.
Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst 
später gelesen.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:

> sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben
> eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.

Upps, sogar 25000. Ich habe mich schon gewundert, warum ich die 3 
Dateien nicht "übereínander" bekommen habe. Die Angabe der Abtastrate 
ist absolut wichtig.

> Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.
> Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst
> später gelesen.

Das ist logisch, durch die falschen Timingwerte, die um den Faktor 2,5 
zu groß sind, laufen bei so hohen Abtastraten die Variablen über.

Ich werde sie um den Faktor 2,5 stauchen, dann nochmal alle 3 Dateien 
damit durchchecken und dann, wenn es läuft, ein Update im SVN machen.

Gruß,

Frank

Autor: Fred (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder 
die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt, 
da dies für ein paar Protokolle anscheinend nötig ist.

die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird 
aber nicht erkannt, könnte auch was anderes sein. Die sagem.txt stammt 
von einer d-box und wird auch nicht erkannt. Bei der kathrein.txt würde 
mich nur interessieren, ob das ein bekanntes Verfahren ist. Zusätzlich 
noch die r-step.txt mit der gleichen Rate.

Ich hoffe da ist was brauchbares für dich dabei.
Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine 
feste Abtastrate vorgeben?

Fred

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

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:
> ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder
> die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt,
> da dies für ein paar Protokolle anscheinend nötig ist.

15kHz wären optimal. Bei 20kHz reicht der Buffer nicht aus, um 
Framewiederholungen zu speichern.

> die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird
> aber nicht erkannt, könnte auch was anderes sein.

Das ist ein Manchester-Protokoll, und zwar ein Mischmasch aus Grundig (9 
Datenbits) und Nokia (16 Datenbits). IRC (was ist das?) hat aber nur 13 
Datenbits. Das kann ich leicht einbauen.

> Die sagem.txt stammt
> von einer d-box und wird auch nicht erkannt.

Ein Pulse-Distance-Protokoll, was leider vom Start-Bit mit dem 
Siemens-Protokoll her kollidiert. Deine T-Home-Scans funktionieren bei 
mir nun alle wunderbar, kollidieren aber nun vom Timing her mit Denon 
und auch dem Siemens-Protokoll. Da bin ich noch etwas am tüfteln, wie 
ich dieses auseinanderhalten könnte.

> Bei der kathrein.txt würde mich nur interessieren, ob das ein bekanntes
> Verfahren ist.

Nein, das ist was komplett neues, Zwischen den Pulsen sind irre lange 
Pausen, die schon nicht mehr als Pausen zwischen Bits, sondern als 
Pausen zwischen Frames verstanden werden.

> Zusätzlich noch die r-step.txt mit der gleichen Rate.

Funktioniert wunderbar, leider habe ich da noch diese Konflikte zu 
SIEMENS und DENON. Deaktiviere ich diese beide Protokolle, läuft alles 
gut.

> Ich hoffe da ist was brauchbares für dich dabei.

Danke, ich werde da das beste draus machen.

> Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine
> feste Abtastrate vorgeben?

Nein, das geht nicht. Bei einigen Protokollen sind die Pulse sehr kurz, 
dann ist 10kHz ungeeignet. 10kHz haben aber den Vorteil, dass man auch 
Frame-Wiederholungen noch sieht. 15kHz ist da ein guter Kompromiss, 
siehe oben. Optimal ist es, die Frquenzrate im Dateinamen zu 
hinterlegen, wie ich es mit den Beispieldateien unter IR-Data gemacht 
habe.

Gruß,

Frank

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

soll ich die Scans mit 15000 noch mal wiederholen?

das irc ist die FB von Pollin, die bei dem IR-Fernsteuerbausatz 
mitgeliefert wird. Im Artikel [[Quellcode für den Pollin Fernsteuer 
Bausatz]] wurde eben dieses Verfahren erwähnt. So wie es aber aussieht 
ist das aber nicht mehr das was es sein sollte.

Die kathrein scheint wohl so langsam zu sein, da das Gerät dazu nur 
einen 8051 mit 1MHz hat und die FB dazu angepasst ist.

Fred

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

Bewertung
0 lesenswert
nicht lesenswert