IRMP - Infrared Multi Protocol Decoder

[Fluto (Gast)]

Hallo,

auch auf die Gefahr hin, dass ich gleich gerügt werde, weil ich nicht 
den kompletten thread gelesen habe und die Antwort bereits geschrieben 
wurde:
habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll 
die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt 
steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...
Gruß und danke
Fluto.

[Frank M. (ukw) (Moderator)]

Fluto schrieb:

> habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll
> die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt
> steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...

Habe auch eine Dreambox und kann Dir schon mal sagen, dass die 
Dreambox-FB momentan nicht von IRMP/IRSND unterstützt wird. Mach ich 
vielleicht irgendwann mal...

Gruß,

Frank

[jar (Gast)]

BTW. Kaseikyo

@frank

ich weiss du machst Kaseikyo immer im Blindflug mangels Geräte, soweit 
funktioniert das auch, nur hab ich das Problem das ich mit Tastendruck 
varieren alles von NEC, Siemens, Ruwido simmulieren kann, wohlgemerkt 
mit einer Kaseikyo ! entweder IRMP kommt durcheinander bei halben 
Repeatframes oder bei halben Frames ? oder deine Pausenerkennung ist 
unzuverlässig bezüglich Kaseikyo

was kann ich für dich tun damit du die besser erkennen kannst, bzw. die 
bessere Erkennung in IRMP einpflegen kannst ?

[Joachim B. (jar)]

evt. kanns auch am int. RC Oszi liegen, bin da aber unsicher weil der ab 
Werk ja schon kal. Byte gesetzt hat und die Toleranzen nicht so riesig 
sind

meine Abweichung

//OCR2A = 76;  // Reloadwert Timer 2 rechnerisch richtig wär 78,125,

76/78,125

~2,7% mit Oszi ermittelt für einen anderen Timer, nicht für IRMP, also 
ohne Korrektur muss IRMP mit diesem 2,7% Fehler leben, das kann aber 
nicht die Ursache sein, FBs haben ja deutlich größere Toleranzen

[Martin R. (m-joy)]

Hallo zusammen,
ich möchte das IRSND protokoll bei meinem ATTINY88 benutzen. Leider hat 
der ATTINY88 kein OC0A oder OC0B, sondern nur OC1A und OC1B. Was muss 
ich jetzt hier eintragen, damit es klappt?:
#define IRSND_OCx

grüße

[Joachim B. (jar)]

nimmst halt den OC1A oder 1B statt 0

#define IRSND_OC1A oder
#define IRSND_OC1B

du brauchst aber das passende OC Bein für die Sendediode

oc für output compare, dein TINY88 muss ja sowas auch haben

wäre am PDIP 28,3 Pin15 f. OC1A

[Joachim B. (jar)]

hier müsstest du erweitern:

#elif defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)  // ATtiny45/85 uses OC0A = PB0 or OC0B = PB1
#if IRSND_OCx == IRSND_OC0A                             // OC0A
#define IRSND_PORT                              PORTB   // port B
#define IRSND_DDR                               DDRB    // ddr B
#define IRSND_BIT                               0       // OC0A
#elif IRSND_OCx == IRSND_OC0B                           // OC0B
#define IRSND_PORT                              PORTB   // port B
#define IRSND_DDR                               DDRB    // ddr B
#define IRSND_BIT                               1       // OC0B

mit || defined (_AVR_ATtiny88_)

#elif defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__) || defined (__AVR_ATtiny88__)

und

#elif IRSND_OCx == IRSND_OC1A                           // OC1A
#define IRSND_PORT                              PORTB   // port B
#define IRSND_DDR                               DDRB    // ddr B
#define IRSND_BIT                               1       // OC0B

wenn ich das Datenblatt richtig gelesen hatte

[Martin R. (m-joy)]

ah cool danke :) werde ich testen sobald die schaltung aufgebaut ist. 
super =)

[Cajus H. (cajush)]

Hallo Frank,

da wäre mal wieder ein Problem:
IRSND und KASEIKYO Codes einer Panasonic DVD-RW Fernbedienung.
Ich habe zwei Tasten, deren Codes vom Gerät einfach nicht aktzeptiert 
werden.
Es handelt sich dabei um die Tasten "rot" und "grün". Wenn ich das 
Signal mit IRMP logge, dann wird bei beiden Sendern (original FB und 
IRSND-FB) der gleiche Befehl erkannt. Das Gerät reagiert jedoch nur auf 
die original-FB. Die anderen Tasten scheinen alle zu funktionieren, 
zumindest ist mir noch keine weitere Taste aufgefallen. Ich habe die 
Logs in den Anhang gepackt. Die Tasten "gelb" und "blau" funtionieren 
und sind nur als Referenz in der Logdatei. Irgendwie ist das Signal der 
Original-FB deutlich länger. Bei "rot" und "blau" habe ich außerdem den 
Finger zu lange auf dem Knopf gehabt, weswegen eine Wiederholung 
vorhanden ist.
Ich verwende die letzten Sourcen aus dem SVN, F_INTERRUPTS 15000 auf 
einem ATmega644A (Sender und Empfänger auf getrennter Hardware). Ich 
habe fast alle Protokolle in IRSND und IRMP aktiviert.
Hast Du da einen Tip für mich?
...
Da war doch noch was mit dem SAMSUNG32 Protokoll und der 
Wiederholpause...

Viele Grüße
Cajus

[Cajus H. (cajush)]

Hallo Frank,

ich habe meine Scans mal durch IRMP unter Linux geschickt und ich denke,
ich habe das Problem gefunden. Eines der 4 System-Bits (Genre2) ist 
unterschiedlich.
Das Parity-Byte am Ende dann natürlich auch. hier für Taste "grün", bei 
"rot" das gleiche Bit.

010000000000010000001101000000000100001001001111  original
010000000000010000001101100000000100001011001111  IRSND
123456789012345678901234567890123456789012345678
MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp
                        ^               ^
In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
stand etwas von

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

Wo landen denn die Bits und wie bekomme ich die Bits wieder nach IRSND?
Welche 4 bits gehen denn dann verloren?

Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags" 
unterbringen?
Die unteren 4 Bits werden bei IRSND schon für die Anzahl von 
Wiederholungen verwendet.
Die oberen Bits sind, soweit ich weis, noch frei.
Oder sollte man die IRMP_DATA-Struktur aufzuboren,
z.B. uint8_t flags in uint16_t wandeln?
Dann hätte man noch etwas mehr Luft.

Viele Grüße
Cajus

[Cajus H. (cajush)]

Hallo Frank,

da Du offensichtlich im Moment nur wenig Zeit hast, habe ich mich mal 
daran gesetzt nach den Genre2-Bits im KASEIKYO Protokoll zu schauen.
Ich habe IRMP erweitert, die Genre2 Bits werden jetzt im MSB von flags 
zurückgegeben.
Danach habe ich die DVD-RW-Fernbedienung mal überprüft: Es sind 
tatsächlich nur die zwei Tasten "rot" und "grün", die ein Genre2 <> 0 
haben.
Ich habe allerdings noch einen neueren Blu-ray Player von Panasonic, der 
die gleichen Codes verwendet, dort sind schon 8 Tasten mit Genre2 <> 0.
Ich habe mich schon gewundert, warum meine IRSND-Fernbedienung bei 
diesem Gerät so schlecht funktioniert ...

Vielleicht komme ich am Wochenende dazu die Funktion in IRSND 
einzubauen. Dann werde ich den Diff zu den aktuellen SVN-Sourcen hier 
einstellen.

Falls Du Lust (und Zeit) hast, kannst Du ja vielleicht mal nach dem 
SAMSUNG32 Protokoll und der Wiederholpause sehen und die Änderungen ins 
SVN einchecken.

Viele Grüße
Cajus

[Cajus H. (cajush)]

Hallo Frank,

hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2 
Bits der KASEIKYO Codes berücksichtigt werden. Wie schon erwähnt werden 
die 4 Bits in den oberen 4 Bits der flags eingeblendet. Diese Bits sind 
sowohl in irmp als auch in irsnd noch unbenutzt.
Die Quelle für den angehängten Patch sind die SVN-Sourcen von heute.
Es wäre schön, wenn die Änderung in Deinen offiziellen Sourcen eingebaut 
würden.

Viele Grüße
Cajus

[Joachim B. (jar)]

Cajus H. schrieb:
> Hallo Frank,
> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2
> Bits der KASEIKYO Codes berücksichtigt werden. .......
> Viele Grüße
> Cajus

irgendwie blicke ich noch nicht durch wo genau ich das einfügen muss

kannst du die kompletten Texte mit deiner Änderung einstellen ?

die vielen + u. - verwirren mich

ich kenne - als entfernen und + als einfügen, heisst das aber lt. deimem 
Text nur zusätzlich einfügen an der Stelle oder wegen --- entfernen der 
orignal Texte ?


die Zeillennummern stimmen auch nicht mit meinen Versionen überein, 
weiss nicht ob ich da optimiert habe oder andere Quellen hatte.

Kaseikyo liegt mir ja auch sehr am Herzen, komme vermutlich erst heute 
dazu die IRSND in meinem RS232 zu BAS Konverter (Pollin) umgebaut zu 
RS232 zu IRMP implementieren

wenn das fertig ist werde ich Umbauplan und Source hier einstellen

das Teil versorgt sich selber über RS232 (RTS, DTR und TxD angezapft auf 
LM317CZ vom stromfressenden MAX232 befreit, mit sparsamer Trasischaltung 
ausgeführt) und kann von RS232 bedient werden

[Cajus H. (cajush)]

Hallo Joachim,

sorry, meine Patch-Datei war leider fehlerhaft. Ich habe am IRMP und 
IRSND Source noch einige andere Änderungen vorgenommen, die ich dann von 
Hand aus der Patch-Datei entfernt habe. Dadurch stimmten die 
Zeilennummern aber nicht mehr. Im Anhang sind jetzt die kompletten 
Dateien, Basis sind immer noch die SVN-Sourcen vom 2.12.2011.

Gruß
Cajus

[Martin R. (m-joy)]

huhu, ich möchte nochmal auf den ATTINY88 zurück kommen.
ganz so leicht war es wohl doch nicht... in der irsnd.c
gibt es probleme. Anschinend fehlten definitionen und zwar...

Hier:

irsnd_on (void)
{
    if (! irsnd_is_on)
    {
#ifndef DEBUG
#if   IRSND_OCx == IRSND_OC1A             // use OC2
      TCCR1A |= (1<<COM1A0)|(1<<WGM12);   // toggle OC1A on compare 
match,  clear Timer 1 at compare match OCR1A

.....


hier:

irsnd_off (void)
{
    if (irsnd_is_on)
    {
#ifndef DEBUG
#if   IRSND_OCx == IRSND_OC1A    // use OC2
       TCCR1A &= ~(1<<COM1A0);   // normal port operation, OC1A 
disconnected.
..........


hier:
irsnd_set_freq (uint8_t freq)
{
#ifndef DEBUG
#if IRSND_OCx == IRSND_OC1A
OCR1A = freq;                       // use register OCR2 for OC2
#elif IRSND_OCx == IRSND_OC2A       // use OC2A

uner hier:
irsnd_init (void)
{
#ifndef DEBUG
    IRSND_PORT &= ~(1<<IRSND_BIT);    // set IRSND_BIT to low
    IRSND_DDR |= (1<<IRSND_BIT);      // set IRSND_BIT to output
#if IRSND_OCx == IRSND_OC1A         // use OC2
    TCCR1A = (1<<WGM12);          // CTC mode
    TCCR1A |= (1<<CS10);           // 0x01, start Timer 2, no prescaling




die werte für die timer habe ich jetzt eingesetzt, da diese nicht für 
IRSND_OC1A definiert waren. ich glaube aber da ist ziemlich viel falsch, 
leider weiß ich die richtigen werte nicht da ich total der überblick 
verloren habe :(

kann mir jemand helfen?

[Frank M. (ukw) (Moderator)]

Hallo Cajus,

vorab erstmal eine Entschuldigung, dass ich mich jetzt erst melde. Deine 
Vermutung wg. knapper Zeit war schon ganz richtig.

Cajus H. schrieb:

> 123456789012345678901234567890123456789012345678
> MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp
>                         ^               ^
> In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> stand etwas von
>
>  - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
>    ausgewertet

Da ging es mir um die 4 Bits, die Du oben mit GGGG gekennzeichnet hast. 
Die 4 Bits "gggg" habe ich bisher im IRMP einfach ignoriert, da sie 
nicht mehr in die IRMP_DATA-Struktur passten. Kaseikyo ist da mit 48 
Bits einfach zu fett. Bei den mir bekannten FBs war das auch kein 
Beinbruch, da die gggg-Bits immer 0000 waren.

> Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags"
> unterbringen?

Ja, könnte man. Ich bin zwar mit der Lösung nicht ganz so glücklich, 
weil das eher ein Workaround als eine Lösung ist. Eher müsste man die 
IRMP-Datenstruktur aufblasen, z.B. Adresse und Kommando auf 32 Bits 
erweitern. Das würde aber zu Inkompatibilitäten zu bereits bestehenden 
Projekten führen, z.B. zum V-USB-IRMP-Projekt von Hugo Portisch, welcher 
momentan 6 Bytes über V-USB überträgt.

> Die unteren 4 Bits werden bei IRSND schon für die Anzahl von
> Wiederholungen verwendet.

So ist es, gut erkannt. Die oberen 4 Bits verwende ich teilweise in 
privaten IRMP-Projekten, z.B. bei meiner lernfähigen Fernbedienung.

> Die oberen Bits sind, soweit ich weis, noch frei.
> Oder sollte man die IRMP_DATA-Struktur aufzuboren,
> z.B. uint8_t flags in uint16_t wandeln?

Die Flags sind eigentlich nicht dafür gedacht, für Datenbits herzuhalten 
;-)

> Dann hätte man noch etwas mehr Luft.

Eher sollte man address & command aufbohren. Ich schwanke da hin und 
her... wegen einem einzigen Protokoll die Datengröße verdoppeln... 
kostet Zeit (im IRMP) und Speicher (z.B. in der makro-/lernfähigen FB).

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Hallo Cajus,

Cajus H. schrieb:

> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2
> Bits der KASEIKYO Codes berücksichtigt werden.

Vielen Dank, ich werde Deine Änderungen in den IRMP-Source einbauen. 
Aber die letzte Entscheidung, ob das so bleiben wird, ist darüber noch 
nicht gefallen. Ich finde die Verlagerung von Datenbits in die Flag-Bits 
eigentlich nicht so schön, habe (wie oben beschrieben) aber momentan 
auch keine bessere Lösung.

Gruß,

Frank

[Cajus H. (cajush)]

Hallo Frank,

schön, dass Du wieder da bist!
Ich habe genau wie Du lange hin- und her-überlegt, ob man nicht lieber 
die Datenbits erweitert, aber wegen einem Protokoll?
Wenn Du meine Erweiterungen in IRMP und IRSND einbaust, dann kannst Du 
das Ganze ja in ein #ifdef stecken. Wer kein Kaseikyo verwendet, oder 
die Genre2 Bits nicht braucht, kann den Code ja rauslassen und die Bits 
für andere Zwecke verwenden. Allerdings ist Kaseikyo ziemlich 
gebräuchlich und ich vermute, es werden in Zukunft auch noch andere 
Geräte Gebrauch von den Genre2 Bits machen werden.

Auf die Gefahr, dass ich Dich mit der Frage inzwischen langweile...
Wolltest Du nicht auch noch meine Timing-Änderungen für SAMSUNG32 prüfen 
und in den Code einbauen?
Der Punkt mit der Zwangspause zwischen zwei Befehlen gleicher Kodierung 
ist auch noch offen...
( Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" )

Schöne Feiertage!

Cajus

[Sebastian .. (zahlenfreak)]

Wieso fügst du nicht noch einen weiteren Structmember für IRMP_DATA ein? 
Dann werden keine Flags missbraucht, man spart sichs, daten aus den 
flags zu operieren und die kompatibilität bleibt gewahrt. Alter Code mit 
neuem IRMP ignoriert die gggg-Bits einfach weiterhin. Und das problem 
mit dem unnötigen Speicher wäre auch weniger schlimm - man müsste ja nur 
ein Byte reservieren.


Viele Grüße,

Sebastian

[irmp (Gast)]

hallo,

ich bekomme bei jeder Fernbedienung immer das heraus:

Code:
Address: 0x2X
Command: 0x2X

Hatte schon jemand diesen Fehler??



DANKE

[Michael H. (michael_h45)]

Du gehst wohl auch im Keuschheitsgürtel zum Urologen...
Zeig deinen Code her. Vermutlich ist die Taktfrequenz falsch.

[Dieter (Gast)]

Guten Abend,

ich habe fast das gleich Problem, nur bei mir erkennt er aber den Code.

Code: NEC
Address: 0x2X
Command: 0x2X

[Dieter (Gast)]

du bekommst nur den Code, Address und Command sind leer.

printf("Code: %s\n",Proto[irmp_data.protocol-1]);
printf("Address: 0x%.2X\n",irmp_data.address);
printf("Command: 0x%.2X\n\n",irmp_data.command);

[Martin R. (m-joy)]

huhu, kann mir denn niemand mit dem
IRSND protokoll bei meinem ATTINY88 helfen :(
ich bekomme die timer im protokoll net hin :(
das wär echt voll suuuuuuper !

grüße

[Michael H. (michael_h45)]

du hast die antwort doch schon bekommen. sogar fertig ausgemalt...
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

[Martin R. (m-joy)]

Michael H. schrieb:
> du hast die antwort doch schon bekommen. sogar fertig ausgemalt...
> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

huhu, das funktioniert leider nicht.... ganz so leicht wars wohl net, 
weil die timerbefehle in den funktionen
irsnd_on (void)
irsnd_off (void)
irsnd_set_freq (uint8_t freq)
irsnd_init (void)

für OCR1A nicht vorhanden sind....

[Mario G. (mario)]

Hallo zusammen,
tolles Projekt. Meine Fernbedienungen hab schon ich geloggt aber
hat jemand schon mal probiert die Protokolle von so kleinen 
Modellhubschraubern mit Infrarot zu entschlüsseln.
Ich habe einen kleinen Nincoair 180 ALU G 
(http://www.thalia.de/shop/home/rubrikartikel/ID24972473.html?zUserID=733&zanpid=1596265215589458944)

Anbei ein Log der Fernbedieung. Kann jemand etwas damit anfangen. 
Interruptfrequenz habe ich auf 20000 ISR/s gestellt.

Mario

[Mario G. (mario)]

Hier nochmal ein Scan desselben Hubschraubers mit 10khz. Ich habe es 
schon versucht mit irmp zu analysieren (unter Windows). Er erkennt ein 
irgendwie fehlerhaftes unvollständiges RC5... ich werd nicht schlau 
draus.

[Frank M. (ukw) (Moderator)]

Martin K. schrieb:
> huhu, kann mir denn niemand mit dem
> IRSND protokoll bei meinem ATTINY88 helfen :(
> ich bekomme die timer im protokoll net hin :(
> das wär echt voll suuuuuuper !

IRSND braucht 2 Timer:

  - 8-Bit-Timer  0 für die Modulation des Signals durch PWM, z.B. 36kHz,
    38kHz, 40kHz - je nach Protokoll.

  - 16-Bit-Timer 1 für das Senden des IR-Frames, läuft i.d.R. mit 10
    oder 15 kHz.

Leider kann man auf dem ATTiny88 keine PWM mit dem Timer0 benutzen. 
Genau dieses Feature hat man dem kastrierten ATTiny88 geklaut.

Um das Ganze auf dem ATTiny88 zum Laufen zu bekommen, müsste man das 
Ganze umdrehen:

  - 16-Bit-Timer 1 für die Modulation des Signals durch PWM

  - 8-Bit-Timer  0 für das Senden des IR-Frames

Das Umschreiben ist ein wenig Arbeit, wofür ich gerade wenig Zeit habe.

Aber mal eine Frage: Warum benutzt Du einen 28-Pinner, der so abgespeckt 
ist? Nimm doch einfach einen ATMega88 statt dem ATTiny88. Der scheint 
auf den ersten Blick pinkompatibel zu sein und bietet wesentlich mehr 
Möglichkeiten.

[Frank M. (ukw) (Moderator)]

Mario Grafe schrieb:
> Hier nochmal ein Scan desselben Hubschraubers mit 10khz.

10kHz reicht dafür aus, die Pulse (und Pausen) sind lang genug.

> Ich habe es schon versucht mit irmp zu analysieren (unter Windows).

"Analysieren" macht man in IRMP mit der "Analyze-Option" (-a). Du 
hättest einfach mal

   irmp.exe -a < hubi.txt

eingeben sollen ;-)

Das habe ich gerade mal unter Linux mittels

   ./irmp -a < hubi.txt

gemacht. Dabei kommt raus:

1. Protokoll ist Bi-Phase (Manchester). Das erkennt man daran, dass
   es sowohl 2 verschiedene Puls- auch auch 2 verschiedene Pausenzeiten
   gibt.

2. Startbit ist: ca. 970 µs Puls, dann ca. 275 µs Pause

3. Pulse: 490 µs und 890 µs

4. Pausen: 280 µs und 670 µs

Eigentlich sollten bei Bi-Phase-Protokollen die kurzen Pulslängen 
genauso lang sein wie die kurzen Pausen. Das gleiche gilt für die langen 
Puls-/Pause-Zeiten. Das Timing ist hier stark asymmetrisch und 
dementsprechend schlecht... ist das so ein Billig-Hubschrauber?

Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen 
Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen 
eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.

Gruß,

Frank

[Martin R. (m-joy)]

huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...
das doofe ist ich hab die schaltung schon gemacht weil ichd achte das 
klappt :D naja dann werd ich die schaltung wohl mal mit dem mega88 
aufbauen wenn ich dafür wieder zeit finde hehe =)

danke trotzdem, jetzt weiß ich immerhin woran es liegt ;)

grüüüße

[Frank M. (ukw) (Moderator)]

Martin K. schrieb:
> huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...
> das doofe ist ich hab die schaltung schon gemacht weil ichd achte das
> klappt

Wie gesagt: der ATMega88 scheint weitestgehend pinkompatibel mit dem 
ATTiny88 zu sein. Wenn Du Deinen ATTIny88 nicht fest eingelötet hast, 
kannst Du ihn direkt gegen einen ATMega88 ersetzen.

[Mario G. (mario)]

Hallo Frank,

vielen Dank für die schnelle Antwort.

Frank M. schrieb:
> .. ist das so ein Billig-Hubschrauber?

Ja ist so ein Billigteil (vor allem die Steuerung), fliegt aber 
erstaunlich gut. Wäre lustig wenn man den mit deiner Lib auch steuern 
könnte :)

Frank M. schrieb:
> Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen
> Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen
> eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.

Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?

Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows 
benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15 
bzw. 20kHz-Version kompiliert, oder?

Gruß
Mario

[Frank M. (ukw) (Moderator)]

Mario Grafe schrieb:

> Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?

Es geht nicht um ein bestimmtes Protokoll, sondern nur darum, dass IRMP 
bei Manchester-Codes (Bi-Phase) wie RC5, RC6, Grundig usw. nicht ins 
Schleudern gerät, wenn die Zeiten stark asymmetrisch sind. Dein 
Hubschschrauber-Protokoll wird momentan nicht unterstützt. Kann ich mir 
bei nächster Gelegenheit mal vornehmen...

> Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows
> benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15
> bzw. 20kHz-Version kompiliert, oder?

Die ist mit 10kHz kompiliert.

Gruß,

Frank

[Mario G. (mario)]

Frank M. schrieb:
> Kann ich mir
> bei nächster Gelegenheit mal vornehmen...

Da freu ich mich schon drauf :)
Hast du denn einen Ansatz wie man die Adress- bzw. Kommando-
Bitlängen rausbekommt? Letztenendes muß man schauen wann ein neues 
Startbit kommt, oder? Aber wieder erkennt man die Adressbitlänge?

Falls du noch mehr Logs brauchst, sag Bescheid.
Sobald man den Schubhebel bewegt sendet die Steuerung ohne Pause wild 
drauflos, d.h. es werden permanent Datenpakete geschickt. Evtl. gehen 
einige Bits bei Logging verloren. Vielleicht werde ich mal die Baudrate 
erhöhen...

Gruß
Mario

[P...s (Gast)]

Hallo,

wenn ich eine Fernbedinung dekodieren will, dann wird nur das Protokoll 
erkannt, die Adresse und das Commando steht leer. Ich benutzt die letzte 
Version die noch CodeVision unterstützt, das ist glaub ich die 2.0.0 vom 
16.08.2011.

Hatte jemand auch schon mal so ein Problem? Würde mich über Eurer Hilfe 
freuen.

[Wolfgang B. (wolfgang6444)]

Hallo zusammen,

ich benutze irmp, irsnd und V_USB zusammen mit einer
Funkstrecke auf der Basis der RFM01/02-Module von hope - alles zusammen 
auf atmega8. Das ganze kommuniziert mit vdr per irmplircd. Ich bin
begeistert!

Jetzt wuerde ich gerne meine 'historische" Fernbedienung Grundig TP 400
VT empfangen und insbesondere mit irsnd codes aussenden.

Es handelt sich um einen biphase-code mit 29.5khz-Traeger. Das Startbit
hat ca 500us Puls gefolgt von 2.75ms Pause. Danach kommen 7 Daten-Bits
im biphase-code. Das erste Datenbit ist immer eine '0' (d.h. ca 500us
Puls gefolgt von 500us Pause). Wiederholungen sind durch 96ms Pausen
getrennt. Offenbar wird einfach der gleiche Code weitergesendet (kein
Toggeln erkennbar). Wie man da sinnvoll in Adresse und Daten unterteilt
ist mir unklar.

Ich habe mir den code in irmp.c angesehen. Eine Ergaenzung ist nicht 
direkt
trivial.
Es waere super, wenn mir da jemand helfen koennte oder ein paar Tipps 
haette?

Ich habe auch ein paar scope-traces - aber leider keine gesacannten 
files, da ich z.Z. kein UART in Betrieb habe.
Gruss und vielen Dank

Wolfgang

[Peter K. (peko)]

Hallo Frank,
befasse mich nach endlos langer Zeit mal wieder mit IRMP/IRSND. Das 
Projekt ist ja richtig erwachsen geworden. Mich interessiert hier 
hauptsächlich der RC6A Code. Gibt es Erfahrungen bezüglich IRSND und 
RC6A an "realen" Geräten? Ich habe mal mit einem zweiten IRMP den von 
IRSND ausgesandten Code mit Logging empfangen. Was IRSND da sendet, hat 
rein gar nichts mit dem zu tun, was die originale FB sendet. Bin im 
Moment etwas ratlos, wo hier zu suchen wäre.
PS
SIRCS funktioniert z.B. sowohl in IRMP als auch in IRSND prima.

-peko

[Frank M. (ukw) (Moderator)]

Hallo Peter,

Peter K. schrieb:
> Gibt es Erfahrungen bezüglich IRSND und RC6A an "realen" Geräten?

Nein, ich habe bzgl. RC6A und IRSND kein Feedback.

> Was IRSND da sendet, hat rein gar nichts mit dem zu tun, was die
> originale FB sendet. Bin im Moment etwas ratlos, wo hier zu suchen wäre.

Scans Deiner FB würden mir helfen.

Gruß,

Frank

[Peter K. (peko)]

Hallo Frank,

bei so prompter Antwort schicke ich doch gleich mal einen Scan. 
Erklärungen sind im file enthalten.
-peko

[Frank M. (ukw) (Moderator)]

Peter K. schrieb:
> bei so prompter Antwort schicke ich doch gleich mal einen Scan.

Habs mir angeschaut, kann mir nicht erklären, warum der IRSND bei Dir so 
einen Schrott produziert.

Ich habe gerade mal unter Linux ausprobiert:

       ./irsnd-15kHz 21 0046 0081

Ausgabe:
00000000000000000000000000000000000000001111111111110000000111111100000001111111000000011111111111111000000011111111111111000000000000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000000000001111111000000011111111111111000000000000001111111111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000000000001111111111111111111111111111

Wenn man das mit Deinem Scan der Original-FB vergleicht, passt es perfekt:
000000000000000000000000000000000000000001111111111110000000011111100000001111110000000111111111111100000001111111111111000000000000000000001111111111111000000011111100000001111110000000011111100000001111110000000011111100000001111110000000111111000000000000001111111111111000000011111100000000111111000000000000001111110000000111111111111100000001111110000000111111000000001111110000000111111000000011111110000000111111000000011111100000000111111000000000000001111111111110000000011111100000001111110000000111111000000001111110000000111111000000000000001111111111111111

Also prinzipiell funktioniert IRSND, denn beide Frames sehen (bis auf 
kleinere vernachlässigbare Timing-Unterschiede und damit eine 
schleichende Verschiebung) deckungsgleich aus und werden auch beide von 
IRMP einwandfrei wiedererkannt.

Es muss also ein Problem beim µC sein. Entweder ist da eine 
Inkompatibilität des IRSND-Sources betreffend Zielsystem Linux / ATmega 
oder die Speicherverwaltung auf dem µC ist durcheinander. Ob das am 
IRSND liegt oder an dem, was Du "drumherum" programmiert hast, kann ich 
aber erst sagen, wenn ich das selbst mit 2 µCs getestet habe. Der 
Schrott, den Dein µC ausgibt, sieht nach zerwürfelter Speicherverwaltung 
(Überschreiber auf Stack oder sonst irgendwo im SRAM) aus.

Sag mal bitte was über verwendeten µC, Speicherbedarf Deiner Anwendung 
etc.
Oder wenn Deine IRSND-Anwendung klein ist, poste doch mal den Quellcode.

Gruß,

Frank

[Peter K. (peko)]

Hallo Frank,

jetzt habe ich nochmal alles komprimiert, das Ganze besteht fast nur 
noch aus IRMP / IRSND. Ich nutze main() aus irmp. IRMP dient jetzt nur 
als Trigger zum Senden des RC6A codes: Wenn ein IR-Code empfangen wird, 
geht RC6A raus. Gerade mal eine Blink-LED ist noch mit dabei, damit ich 
sehen kann, daß der µC arbeitet. Ich verwende einen 664P mit 20MHz 
getaktet. Anbei mal die gezippten sources. Ich bin mir nicht sicher, ob 
ich nicht irgendwo ein define vergessen / oder falsch eingestellt habe.

Gruß, peko

[Frank M. (ukw) (Moderator)]

Es steht eine neue Version 2.0.3 von IRMP + IRSND zum Download bereit.

Download über Artikel:

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

und auch übers SVN möglich:

   http://www.mikrocontroller.net/svnbrowser/irmp/

Änderungen IRMP:

  - Bugfix: oberstes Bit in Adresse falsch bei NEC-Protokoll, wenn auch
    NEC42-Protokoll eingeschaltet ist.
  - Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
  - Genre2-Bits werden nun im oberen Nibble von flags gespeichert.

Änderungen IRSND:

  - Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
  - Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
  - Zusätzliche Pause nach dem Senden des letzten Frames

Vielen Dank an Cajus.

Wünsche viel Spaß,

Frank

[Frank M. (ukw) (Moderator)]

IRSND hatte in der Version 2.0.3 den Fehler, dass es nur einen einzigen 
Frame rausschickte.

Deshalb gibt es nun eine Version 2.0.4 - zum Download und im SVN.

Gruß,

Frank

[Mathias O. (m-obi)]

Ähm was ist das genre2 Bit? Wozu ist das da?

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
> Ähm was ist das genre2 Bit? Wozu ist das da?

Stimmt, dazu hätte ich mehr schreiben sollen. Es steht dazu aber einiges 
hier im Thread. Die Genre2-Bits sind 4 Bits aus dem Kaseikyo-Protokoll.

Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4 
Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen. Deshalb werden 
sie nun im oberen Nibble von flags gespeichert bzw. von IRSND 
ausgewertet. Ich bin zwar mit dieser Lösung nicht sehr glücklich, weiß 
aber im Moment auch keine bessere Lösung... außer IRMP_DATA zu 
vergößern. Ob das so bleibt, weiß ich noch nicht.

Das Ganze ist nur relevant, wenn man Kaseikyo nutzt. Die 4 Genre2-Bits 
sind bei Kaseikyo zudem meist 0, so dass diese Änderung nur in ganz 
speziellen Fällen zum Tragen kommt.

Ich werde dies noch im IRMP-Artikel erwähnen.

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4
> Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen

genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit 
bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data, 
mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst 
du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte 
eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt 
wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags

[Frank M. (ukw) (Moderator)]

jar schrieb:
> genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit
> bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data,
> mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst
> du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte
> eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt
> wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags

Wenn Du Dir

 http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail

unter "Kaseikyo" anschaust, dann weißt Du warum. Im Frame stecken 4 + 8 
= 12 Parity-Bits. Die brauche ich nicht, die kann IRSND mühelos wieder 
aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4 
Bits zuviel.

Gruß,

Frank

P.S.
Die Parity-Bits werden selbstverständlich von IRMP berücksichtigt, um 
die Korrektheit der Daten zu prüfen. Gespeichert werden brauchen sie 
aber nicht.

[jar (Gast)]

Frank M. schrieb:
> ie kann IRSND mühelos wieder
> aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4
> Bits zuviel.

danke, so wie ich das nun rauslese haben wir alle 36 relevanten Bits vom 
Kaseikyo, aufgeteilt in IRMP auf 16 Address Bits und 16 Command Bits + 4 
Genre2 Bits in Flags, du schreibst 4 sind zuviel, aber es gab ja User 
die die brauchten, ich konnte zwar alle Kaseikyo Codes auslesen, habe 
aber bis jetzt nur einen schwach senden können, kann aber an den Dioden 
oder der Frequenz liegen, das genau muss ich noch testen, ich bekomme ja 
die Bits aus einem TSOP (3)1736 der spuckt natürlich zwischen 32 und 38 
kHz locker Daten aus, meine Sendediode hat 940nm mit wenig sr, es gibt 
aber auch 950 und 880er nm Dioden mit viel mehr power, aber das ist 
wieder ne andere Baustelle

[KLaus (Gast)]

Hallo

Ich verfolge nun dieses Thread schon seit Wochen .
Derzeit programmiere ich noch alles in Bascom, das wird sich aber 
ändern.
Da ich eh noch nicht so lange mit MC’s bastel is das auch nicht so 
weltbewegend, bin ja nicht festgewachsen 
Aber wird schon a bissal Hirnschmalz nötig sein!

Aber nichts desto trotz , ich hab ein Problem mit der integration von 
IRMP und IRSND in ein fertiges
Gerät, dass ich von der Arbeit gespendet bekomme. Es sind keine Layout 
Änderungen möglich.

Das is so ein Gaswarner für die Chemieindustrie mit einem Atmel an 
Board.
Den oder diese würde ich gerne für zukünftige Projekte verwenden.
Dazu sollte es möglich sein per IR Einstelungen von einem Laptop oder 
2.tem Gaswarner zu übertragen, dies will ich mit rc5 oder anderem z.B. 
Grundig Code übertragen.

Auf einer extra aufgebauten Schaltung (Polin Board) funktioniert IRMP 
tadel los mit 16Mhz Atmega 32! Die Grundig IR Variante hat bei mir die 
stabilste Erkennung.

Ausstattung :
-  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP 
atmega168 Sektion hinzugefügt)
-  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die 
Standardeinstellung vor und nach dem Löschen des orginal beschriebenen 
microcontrollers und sollte auch so bleiben
-  SIR TFBS4711 (irda Transceiver)
Irgend ein Quarz(FSR 12.5) ohne Kondensatoren ist verlötet (evtl ein 
Uhrenquarz ?)

Mein Problem nun :
Der RX pin des IRDA ist auf PG4 (T0/SEG23)
Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)

Ich kann Daten empfangen mit der Log Funktion(in der neuesten IRMP 
allerding lässt  sichs nicht mehr compilieren mit Log Flag) von IRMP, 
aber es wird nie etwas komplett erkannt so das ich keine Adresse , 
Command und sonstige Daten zum Auswerten bekomme.
Beim Senden wird’s wohl  auch nix werden .

Ich hab schon mehrfachi n einigen Foren gelesen , dass es möglich sein 
muss ohne externen quarz IR empfangen und senden zu können.
Aber Wie ?
Hab schon mit den Fuses (ckdiv8) und den FPU einstellungen gespielt aber 
leider nichts.

Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird 
dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings 
auch beim Atmega32 nichts mehr.

Ich denke ich hab fürs empfangen hier ein eindeutiges Timing Problem 
aber wie mach ich das es funktioniert???
Kann mir bitte jemand auf die Sprünge helfen, oder zumindest erstmal 
noch fragen was er zu meiner Problemlösung noch wissen muss ?
Hab schon etliche Nächte weiss werdende Haare gezählt.


Gruß Klaus

[Frank M. (ukw) (Moderator)]

Hallo zusammen,

eine neue Version von IRMP und IRSND steht zum Download bereit. Diese 
ist nun auch für den C18-Compiler (PIC) verfügbar. Ebenso kann man nun 
auch unbekannte Formate auf dem PIC scannen (über USB).

Vielen Dank dafür an gera!

IRMP Version 2.0.4:

 - Bug in IR60-Decoder behoben
 - Bug in CRC-Berechnung von Kaseikyo-Frames behoben
 - Portierung auf C18 Compiler für PIC-Mikroprozessoren
 - Scannen von IR-Frames auf dem PIC (über USB)

IRSND Version 2.0.4:

 - Neues Protokoll: IR60
 - Bug beim Senden von Bi-Phase-Frames (Manchester) behoben
 - Portierung auf C18 Compiler für PIC-Mikroprozessoren

[Frank M. (ukw) (Moderator)]

KLaus schrieb:
> Mein Problem nun :
> Der RX pin des IRDA ist auf PG4 (T0/SEG23)
> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)

IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein 
eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du 
kannst versuchen, den IRDA-Controller direkt über RX/TX als UART 
auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts 
mehr mit IRMP zu tun.

Gruß,

Frank

[jar (Gast)]

KLaus schrieb:
> Ausstattung :
> -  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP
> atmega168 Sektion hinzugefügt)
> -  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die
> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen
> microcontrollers und sollte auch so bleiben
> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird
> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings
> auch beim Atmega32 nichts mehr.

ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann 
auch das was du schon beobachtet hast

[Klaus (Gast)]

jar schrieb:
> KLaus schrieb:
>> Ausstattung :
>> -  Atmel Atmega169PV-8MU  /hab ich fürs compilieren in der IRMP
>> atmega168 Sektion hinzugefügt)
>> -  1Mhz interner Takt (ckdiv8 gesetzt)  - dies ist die
>> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen
>> microcontrollers und sollte auch so bleiben
>> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird
>> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings
>> auch beim Atmega32 nichts mehr.
>
> ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann
> auch das was du schon beobachtet hast

Frank M. schrieb:
> KLaus schrieb:
>> Mein Problem nun :
>> Der RX pin des IRDA ist auf PG4 (T0/SEG23)
>> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)
>
> IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein
> eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du
> kannst versuchen, den IRDA-Controller direkt über RX/TX als UART
> auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts
> mehr mit IRMP zu tun.
>
> Gruß,
>
> Frank

Hallo Frank


Danke für deine Antworten
Aber jetzt werd ich wohl mal kalt duschen gehen müssen, ich dachte 
dieser irda controller lässt sich auch dazu bewegen die Daten korrekt zu 
empfangen und zu senden  da ich ja schon Daten empfing aber eben nur im 
log modus .
Da hab i jetzt echt 2 oder 3 wochen rumgedoktert , oh MAMA MIA , wo werd 
ich noch enden :-(. hätt wohl eher fragen sollen.

Zu aller Anfang versuchte ich alllerdings eine Kommunikation direkt über 
Software Uart mit 2 Gasmeldern.
Ich dachte ich könnte das einfach bei 1Mhz Controllertakt und 2400Baud 
übertragen incl verdunklung der Irda Transceiver.
Schien mir das einfachste . Aber irgendwas mache ich falsch .
Was genau da nicht funktioiert  kann ich erst sagen wann ich wieder an 
diesem Punkt anfange und weitermache. Denke aber es wurden einfach keine 
Daten am empfänger ausgegeben.

Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip 
zwischen uart(controller) und irda transceiver auskommt und trotzdem 
Daten übertragen werden können?

gruß klaus

[jar (Gast)]

es gab mal Irdeo welche über UART ging
mit etwas umlöten geht auch die Kombi WinLirc und IR Assistent

aber das hat nix mit hier zu tun, aber mit einem Tiny85 IR zu seriell 
und an der Seriellen geht das im Prinzip

[jar (Gast)]

Klaus schrieb:
> Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip
> zwischen uart(controller) und irda transceiver auskommt und trotzdem
> Daten übertragen werden können?

willst du wirklich echtes IRDA ?
http://www.infrarotport.de/

[Didi S. (kokisan2000)]

Hallo Frank,

eigentlich ist es garnicht so dramatisch mit dem IrDA Transceiver. Doch 
eines Vorweg. Das IrDA Software Protokoll ist ausgelegt, um 
unterschiedlichste Geräte miteinander zu verbinden. Nach dem OSI Modell 
laufen zwischen zwei Geräten viele Kommunikationen ab, in denen sich die 
Geräte über Protokoll, maximale Geschwindigkeit, Errorkodierung und CRC 
Prüfsumme austauschen. Doch das sind alles sachen, die Du für eine 
eigene Punkt zu Punkt Verbindung NICHT benötigst. Wenn Du den gesamten 
Overhead weglässt, dann bleibt beim TFBS4711 Transceiver ein IR Bauteil 
das im Halbduplex Verfahren Daten senden und empfangen kann - und das 
sehr gut und fehlerfrei innerhalb gewisser Grenzen.

Der TFBS4711 ist ein SIR Bauteil, kann also Daten senden und empfangen 
von 2400 Baud bis 115200 Baud. Das SIR Protokoll ist zum UART Signal 
nicht kompatibel, weil High und Low als RZI (Return to Zero Inverted) 
gesendet werden. Um den Unterschied zum UART zu verstehen, schaue Dir 
doch bitte einmal das Bild 13 im Physical Layer von IrDA an: 
http://www.vishay.com/docs/82513/physical.pdf.
Statt einem "High" auf dem UART muß ein "Low" bereitgestellt werden. Für 
jedes "Low" auf dem UART muß ein "3/16 High" am TFBS4711 angelegt 
werden. Wenn Du den TFBS4711 so ansteuerst, dann funktioniert die 
Übetragung per IR genau so, als ob Du zwei Controller per UART 
kommunizieren lässt.

Du hast jetzt zwei Möglichkeiten:

1) Wenn Du das IrDa Bauteil an einem normalen UART eines Controllers 
anschliessen willst, benötigst Du ein Encoder-Decoder Baustein zwischen 
UART und TFBS4711. Ich habe vor vielen Jahren diese beiden 
mitentwickelt:
http://www.vishay.com/docs/81749/toim5232.pdf
http://www.vishay.com/docs/82546/toim4232.pdf

2) Wenn Du die Möglichkeit hast den TFBS4711 an zwei freien Pins des 
Controllers anzuschliessen, kannst Du das Timing des SIR Protokolles 
einfach selber programmieren.

Im Internet findest Du Softwarerealisierung des SIR Protokolls wie 
z.B.hier: http://www.gaw.ru/pdf/TI/app/msp430/slaa044.pdf

Wenn Du den Weg weiter verfolgen möchtest, dann müsste ich mal in meinem 
Fundus graben. Ich habe da eventuell noch Sourcecode Relikte für 
Prozessoren ...

Gruß
kokisan

[Didi S. (kokisan2000)]

Hallo Frank,

sorry, meine ausführlichen Hinweise in meinem letzten Beitrag waren 
nicht für Dich, sondern für Klaus gedacht ;-)

Frank, klasse Arbeit mit IRMP !!!

Gruß
kokisan

[Klaus (Gast)]

Hallo erstmaltschuldigung für das späte schreiben , bin gerade beruflich 
unterwegs
Danke für die vielen Anworten
@jar
willst du wirklich echtes IRDA ?


Nein das ist das was ich will .
Mein Bestreben ist es , den IRDA Transceiver mit einem irda transceiver 
kommunizieren zu lassen ohne zusätzliche beschaltung (wie vorgegeben) 
und sowie es didi in seinem ersten block beschrieben hat .
und evtl. auch über eine normale sende und empfangsdiode daten hin und 
herschieben und das ganze mit einem atmega169 bei 3,6 Volt.
Es  muss keine hoche Reichweite haben , 20cm reichen.

@Didi S. (kokisan2000)

Du bist meine Rettung , du hast mich verstanden :-))
Da ich nicht flexibel bin mit meiner Hardware , is ja ein fertig 
verbauter Gasmelder mit Atmega169 und Irda Transceiver
daher kommt für mich nur zweiteres in Frage .
Und ich hab mich grad riesig gefreut da du was zu dem 3/16 Dings 
geschrieben hast und das auch noch auf einfache weise
Ich werde mich mit diesem Thema beschäftigen,dazu kann ich sehr gerne 
deine SourceCode Schnippseln brauchen .
Evtl. hast du noch mehr solcher Erklärungsstützen auf Lager :-)
 wautschis AT gmx dot net
Versuche dann auch mir das gabnze zu erklären was aber am Anfang immer 
ein Riesenberg ist da einzusteigen:-(

Wanns mal klar ist dürfte das ganze gar nicht mehr so schwer werden

[Klaus (Gast)]

@didi
eins hab i  ja noch vergessen
die original firmware die drauf
war konnte alles mit dem chkdiv8 teiler und 1 Mhz Prozessor takt

die programmierer haben das eben auch per programmierung gelöst und das 
mit 1mhz takt
bzw. es ist nooch ein quarz verbaut aber warsch. ein uhrenquarz.
dder gasmelder soll ja 18 monate rückwärts zählen und ausgehen oder wann 
Batterie leer ist.
Die Übertragung der sensor daten fand auch in unmittelbarerer nähe zum 
controllgerät statt.

[Klaus (Gast)]

@jar
willst du wirklich echtes IRDA ?

fix verschrieben

natürlich will ich das nicht! :-)

[Hans W. (stampede)]

Darf das IRMP auch kommerziell genutzt werden?

[Michael S (Gast)]

Hat jemand die Lib schon auf einem atXmega eingesetzt ? Gibts evtl. nen 
Patch ?

Danke
Michael

[Frank M. (ukw) (Moderator)]

Hans W. schrieb:
> Darf das IRMP auch kommerziell genutzt werden?

Da IRMP unter der GPL-Lizenz läuft, kann es auch kommerziell genutzt 
werden.

Sobald Du die erste Million verdient hast, kannst Du mich gern mit 10% 
beteiligen ;-)

[Martin R. (m-joy)]

Huhu, ich habe meine schaltung jetzt vom attiny88 auf den atmega88 
umgebaut. und siehe da es funktioniert ... super :)

aber eine sache funktioniert nicht, und zwar wenn ich am sender folgende 
routine benutze:

    for (VCount=0; VCount<=7; VCount++)
        {
    if( POSITION == VCount )
    {
    V=VCount;
    irmp_data.command  = VCount;    
    send=1;
    }
       }

dann funktioniert es mit diesem am empfänger:

  for (Vcommand=0; Vcommand<=7; Vcommand++)
       {
  if( irmp_data.command == Vcommand )
    {
    V=Vcommand;
    }
      
        }

ich möchte aber sehr viele IR codes benutzen und diese teilen,also 
dachte ich mir ich benutze 0x0A** für eine reihe, und 0x0B** (mit * von 
0-f) für die zweite reihe.
Jetzt habe ich beim sender eingegeben:

    for (VCount=0; VCount<=7; VCount++)
        {
    if( POSITION == VCount )
    {
    V=VCount;
    irmp_data.command  = (VCount + 0x0A00);
    send=1;
    }
       }

und dasselbe eben auch beim empfänger. wenn ich da einen wert aufaddiere 
dann geht es nicht mehr :( weiß jemand woran das liegen könnte...?

grüüße

[Martin R. (m-joy)]

nach etwas rumprobieren bin ich auf die idee gekommen, dass es wohl 
probleme gibt bei den größeren werten....
wenn ich das command
0x0011 schicke, kann ich es emfpangen
bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie 
kann das sein.... what is wrooong?
Ich benutze das NEC Protocol, der rest ist deaktiviert.


grüße

[Frank M. (ukw) (Moderator)]

Martin K. schrieb:
> wenn ich das command
> 0x0011 schicke, kann ich es emfpangen
> bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie
> kann das sein.... what is wrooong?

Wenn Du unter

  http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle

nachschaust, siehst Du, dass das NEC-Protokoll aus

  16 Bit Adresse + 8 Bit Kommando + 8 Bit invertiertes Kommando

besteht. Das NEC-Protokoll unterscheidet also nur 256 Kommandos. Damit 
geht Dein Wertebereich für irmp_data.command von 0x00 bis 0xff. Das 
Senden von 0x0101 ist also dasselbe wie das Senden von 0x0001, da IRSND 
die zusätzlichen Bits außerhalb des Wertebereichs einfach wegblendet.

> Ich benutze das NEC Protocol, der rest ist deaktiviert.

Versuche, mit 8 Bit hinzukommen oder wähle ein anderes Protokoll, wenn 
Du Daten übertragen willst.

Gruß,

Frank

P.S.

Ich verstehe Deine for-Schleifen nicht:

>  for (Vcommand=0; Vcommand<=7; Vcommand++)
>  {
>     if( irmp_data.command == Vcommand )
>     {
>         V=Vcommand;
>     }
>  }

Das kannst Du doch einfach als

     if( irmp_data.command <= 7 )
     {
         V=irmp_data.command;
     }

schreiben. Eine Schleife ist überhaupt nicht notwendig.

[Ephraim H. (ephi)]

Hallo zusammen,

erstmal: ein grandioses Projekt!
Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die 
Volume +/- Befehle einer Apple Remote (die alte), um damit einen 
Motorpoti zu steuern. Das ganze werte ich wie folgt aus:

while(1)
    {
        irmp_get_data(&irmp_data);
        
        if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
        {
            // Volume up
            if((irmp_data.command&0x00FF) == 0x0B)
            {
                // Motor rechts
                PORTD |= (1<<PD5);
                PORTD &= ~(1<<PD6);
            }
            // Volume down
            else if((irmp_data.command&0x00FF) == 0x0D)
            {
                // Motor links
                PORTD |= (1<<PD6);
                PORTD &= ~(1<<PD5);
            }
            else
            {
            // Motor stop
            PORTD &= ~(1<<PD5);
            PORTD &= ~(1<<PD6);
            }
        }
    }

Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal 
kurz Volume up oder down drücke, steht in irmp_data.command so lange 
dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine 
Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss 
ich irmp_data nach dem auslesen irgendwie bereinigen?

Gruß,
Ephraim

[Frank M. (ukw) (Moderator)]

Ephraim Hahn schrieb:
> Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die
> Volume +/- Befehle einer Apple Remote (die alte), um damit einen
> Motorpoti zu steuern. Das ganze werte ich wie folgt aus:
>

>     while(1)
>     {
>         irmp_get_data(&irmp_data);
>

Das ist falsch, Du musst den Rückgabewert prüfen. Wenn 0 zurückkommt, 
wurde nichts empfangen.

Also:

    while(1)
    {
        if (irmp_get_data(&irmp_data))
        {
            ... // hier Deinen restlichen Code einfügen
        }
    }

> Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal
> kurz Volume up oder down drücke, steht in irmp_data.command so lange
> dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine
> Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss
> ich irmp_data nach dem auslesen irgendwie bereinigen?

Wie gesagt: Du musst den Rückgabewert prüfen. irmp_data wartet nicht, 
bis etwas empfangen wird, sondern kommt sofort zurück, wenn keine Daten 
anstehen. In diesem Fall steht natürlich noch das alte Zeugs in der 
Datenstruktur. Ein Zurücksetzen der Datenstruktur ist nicht notwendig, 
da die Daten valide sind, wenn irmp_get_data() TRUE zurückliefert.

Gruß,

Frank

[Ephraim H. (ephi)]

ah okay, das macht Sinn. Probier ich nacher gleich aus, vielen Dank!

[Martin R. (m-joy)]

ohhhjee ich idiot vielen dank.... naatürlich es gibt nur 8 command 
bit... :( ich habe das problem gelöst indem ich einfach zwei 
verschiedene adress bits genutzt habe ;)
vielen dank

p.s. die schleife muss man net verstehen G

[Ephraim H. (ephi)]

Verzeihung, aber ich muss mich noch mal melden.
Konnte die Geschichte erst jetzt testen, da ich noch andere Hardware 
Probleme zu lösen hatte.

Dieser Code hier (wie oben) funktioniert, aber mit besagtem Problem, 
dass er nicht mehr aufhört, wenn ich einmal gedrückt habe, da ich den 
Rückgabewert von /irmp_get_data()/ nicht prüfe.

while(1)
    {
        irmp_get_data(&irmp_data);
 
            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
            {
                // Volume up
                if((irmp_data.command&0x00FF) == 0x0B)
                {
                    // Motor rechts
                    PORTD |= (1<<PD5);
                    PORTD &= ~(1<<PD6);
                }
                // Volume down
                else if((irmp_data.command&0x00FF) == 0x0D)
                {
                    // Motor links
                    PORTD |= (1<<PD6);
                    PORTD &= ~(1<<PD5);
                }
                else
                {
                    // Motor stop
                    PORTD &= ~(1<<PD5);
                    PORTD &= ~(1<<PD6);
                }
            }
    }

Jetzt nehme ich die Überprüfung mit rein:

while(1)
    {
        if(irmp_get_data(&irmp_data))
        {
            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)
            {
                // Volume up
                if((irmp_data.command&0x00FF) == 0x0B)
                {
                    // Motor rechts
                    PORTD |= (1<<PD5);
                    PORTD &= ~(1<<PD6);
                }
                // Volume down
                else if((irmp_data.command&0x00FF) == 0x0D)
                {
                    // Motor links
                    PORTD |= (1<<PD6);
                    PORTD &= ~(1<<PD5);
                }
                else
                {
                    // Motor stop
                    PORTD &= ~(1<<PD5);
                    PORTD &= ~(1<<PD6);
                }
            }
        }
        else
        {
            // Motor stop
            PORTD &= ~(1<<PD5);
            PORTD &= ~(1<<PD6);
        }
    }

Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?

[etMax (Gast)]

Hallo!

Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem 
Atmega8 zum laufen zu bekommen.

Dazu habe ich einfach das aktuelle release genommen und 2 Zeilen 
eingefügt: der aktuell empfangene Command soll auf PortD ausgegeben 
werden.

Ich habe auf meinem STK600 den PORTD des Atmega8 mit den LEDs verbunden 
und den IR-Decoder an PB6 angeschlossen. Leider bleibt PORTD immer auf 
LOW.

Wenn ich PORTD = PINB; hinzufüge, sehe ich die LED an PD6 blinken, also 
das Signal kommt an.

Vielleicht kann sich das mal jemand anschauen, was das Problem ist? Ich 
hab den Quellcode beigelegt.

Vielen Dank und liebe Grüße,
etMax

[Frank M. (ukw) (Moderator)]

Ephraim Hahn schrieb:
>

while(1)
>     {
>         if(irmp_get_data(&irmp_data))
>         {
>             ....
>         }
>         else
>         {
>             // Motor stop
>             PORTD &= ~(1<<PD5);
>             PORTD &= ~(1<<PD6);
>         }
>     }

>
> Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?

Ja, hast Du. Schau Dir mal obigen Code genauer an. Wenn irm_get_data() 
NICHTS empfängt, wird der else-Zweig durchlaufen und damit Dein Motor 
gestoppt. Denke daran: irmp_get_data() wartet NICHT. In 99,9995% der 
Zeit wird der else-Zweig durchlaufen und Dein Motor gestoppt.

Wenn Du mal was sendest, springt der Motor kurz an und wird danach 
direkt wieder gestoppt. Das ist so kurz, dass Du das gar nicht siehst.

Daher: Werfe den unteren else-Zweig komplett raus, also lass folgendes 
stehen:

   while(1)
   {
       if(irmp_get_data(&irmp_data))
       {
           if (...)
           {
               ...
           }
           else if (...)
           {
               ...
           }
           else // NUR HIER MOTORSTOPP!
           {
               ...
           }
       }
       // KEIN else!
   }

Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere 
gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du 
haben möchtest.

Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

etMax schrieb:

> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem
> Atmega8 zum laufen zu bekommen.

Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft 
und nicht mit den werksseitig eingestellten 1 MHz?

Schau mal hier:

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

Gruß,

Frank

[Ephraim H. (ephi)]

>
> Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere
> gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du
> haben möchtest.
>
> Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.
>
> Gruß,
>
> Frank

genau dieses Verhalten ergab sich ja bereits aus meiner allerersten 
Version. Was ich aber will, ist, den Motor nur zu bewegen solange die 
entsprechende Volume Taste gedrückt wird. Nun dachte ich, solange ich 
drücke, ist /irmp_get_data()/ positiv und liefert mir in der struct den 
Befehl. Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt, 
als meine apple remote senden kann, und sich dadurch praktisch nichts 
bewegt, da der Motor stoppt, bevor er überhaupt angelaufen ist? In dem 
Fall müsste ich eine Art delay bzw. timeout für einen empfangenen befehl 
integrieren.

[etMax (Gast)]

Frank M. schrieb:
> etMax schrieb:
>
>> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem
>> Atmega8 zum laufen zu bekommen.
>
> Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft
> und nicht mit den werksseitig eingestellten 1 MHz?
>

Hallo,

ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und 
eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay 
zwischen den Blinkern mache.

[Frank M. (ukw) (Moderator)]

Ephraim Hahn schrieb:
> Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt,
> als meine apple remote senden kann, [...]

Ja, natürlich. Eine FB sendet ca. 10 Frames pro Sekunde. irmp_get_data 
wird aber wesentlich öfter mit FALSE zurückkommen.

Vorschlag der Lösung:

In der timer-ISR einen globalen Zähler hochzählen (static volatile 
uint16_t), diesen in den beiden if-Blöcken, wo Du tatsächlich 
Volume-UP/DOWN empfängst, auf 0 zurücksetzen. Im else-Block prüfen, ob 
ein bestimmer Wert des Zählers überschritten wurde. Dann hast Du Deinen 
Timeout und Du kannst den Motor stoppen.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

etMax schrieb:
> ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und
> eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay
> zwischen den Blinkern mache.

Welche Fernbedienungen hast Du ausprobiert?

Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle 
aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal 
RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter 
"more protocols" steht. Die "exotic protocols" lasse erstmal weg.

Gruß,

Frank

[M. K. (kichi)]

Ich habe mir nicht den ganzen Thread durchgelesen: hat schon jemand das 
Projekt inkl. IRSND auf einen ARM (STM32) portiert?

[Frank M. (ukw) (Moderator)]

Michael K. schrieb:
> Ich habe mir nicht den ganzen Thread durchgelesen: hat schon jemand das
> Projekt inkl. IRSND auf einen ARM (STM32) portiert?

Schau Dir mal Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" an.

[M. K. (kichi)]

Hast du das implementiert oder muss speziell diese Version genommen 
werden? Und wie steht es mit IRSND?

[Frank M. (ukw) (Moderator)]

Michael K. schrieb:
> Hast du das implementiert oder muss speziell diese Version genommen
> werden? Und wie steht es mit IRSND?

Nein, habe ich nicht implementiert. Aber wenn Du Dir die Unterschiede 
durch Suchen nach IRMP_FLEXIBLE_VERSION anschaust, siehst Du, dass Jan 
neben einigen kosmetischen Sachen (die so für den ARM nicht existieren) 
lediglich das Interface der Funktion irmp_ISR() geändert hat, um den 
IRMP-Source komplett hardwareunabhängig zu machen.

Über den hardware-abhängigen Teil

  1) wie lese ich einen PIN?

  2) wie rufe ich irmp_ISR() 10000 mal (oder 15000 mal) pro Sekunde auf?

schweigen sich seine Source-Änderungen leider aus. Da ich selber mit ARM 
noch nichts gemacht habe, kann ich Dir da auch nicht weiterhelfen. Aber 
eigentlich musst Du nur die beiden obigen Punkte klären, das ist alles. 
Dann kann man das auch in den aktuellen IRMP integrieren.

Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().
Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion 
timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro 
Sekunde aufgerufen wird.

Wie Du siehst, ist das nicht schwierig. Wenn Du Dich einigermaßen mit 
ARM-Programmierung auskennst, solltest Du das hinbekommen. Deine 
Source-Anpasssungen baue ich gern in den IRMP ein.

Gruß,

Frank

[M. K. (kichi)]

Frank M. schrieb:
> Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().
> Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion
> timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro
> Sekunde aufgerufen wird.
Werde ich tun. Ich komme dann nochmal auf dich zu.

Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt 
doch den Timer 2 dafür, oder?

[Frank M. (ukw) (Moderator)]

Michael K. schrieb:
> Werde ich tun. Ich komme dann nochmal auf dich zu.

Prima, bin gespannt.

> Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt
> doch den Timer 2 dafür, oder?

IRSND benutzt (genauso wie IRMP) einmal den Timer 1 (irsnd_ISR()) und 
zusätzlich den Timer 2 für die Erzeugung der Modulationsfrequenz. Bei 
den ATtinys ist es stattdessen der Timer 0, siehe irsndconfig.h.

Gruß,

Frank

[etMax2 (Gast)]

Frank M. schrieb:
> Welche Fernbedienungen hast Du ausprobiert?
>
> Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle
> aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal
> RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter
> "more protocols" steht. Die "exotic protocols" lasse erstmal weg.

Oh je, ich bin ja ein Idiot...
Ich habe eine RC5-Fernbedienung und war mir sicher, dass RC5 zu den 
Standard-Protokollen gehört...
Danke fürs Drüberschauen, Frank! Jetzt klappt es einwandfrei!

etMax

[Martin (Gast)]

Hallo,

ich versuche gerade eine 44-Tasten-RGB-Fernbedienung eines 5m
LED-Streifens am Atmega88 zum laufen zu kriegen, bis jetzt ohne Erfolg. 
Der RGB Streifen wurde
in der Bucht gekauft und beinhaltet bereits einen Controller und eine
Fernbedienung.

Das IR-Protokoll ist das NEC-Protokoll. Im Anhang habe ich das Timing
für die "Rot"-Taste.
In der IRMPconfig.h wurde nur das NEC-Protokoll aktiviert und der Pin 
für den Empfänger auf PB.5 gesetzt.

Der Atmega88 wurde, wie in der main.c beschrieben, für interne 8MHz
gefused. Für die Übertragung der "Rot"-Taste habe ich folgende Werte
erhalten:

Startbit > 0x00 (Adressbyte) > 0xFF (inv. Adressbyte) > 0x1A
(Commandbyte) > 0xE5 (inv. Commandbyte) > Stopbit

Könnt ihr bitte mal über meine Switch-Case-Anweisung drüber schauen, ob
die Abfrage des irmp_data.command richtig ist?

int
main (void)
{
    IRMP_DATA irmp_data;

    irmp_init();                                                            // initialize irmp
    timer1_init();                                                          // initialize timer 1
    sei ();                                                                 // enable interrupts

  DDRC |= (1 << DDC1) | (1 << DDC2) | (1<<DDC3);

    for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
            //if (irmp_data.protocol == IRMP_NEC_PROTOCOL)// &&     // NEC-Protokoll
        //irmp_data.address == 0x00FF)                   // Adresse 0x1234
        //{
          switch (irmp_data.command)
          {
            case 0x9A65: PORTC|=(1<<PC1); break;          // Taste grün
            case 0x18E7: PORTC|=(1<<PC2); break;          // Taste gelb
            case 0x1AE5: PORTC|=(1<<PC3); break;          // Taste rot
          }
  }
    }
}

Gruß Martin

[Martin (Gast)]

Jetzt hab ichs. Ich darf nur das 8-Bit-Commandbyte verwenden. Jetzt 
gehts:-) Das IRMP ist ein Spitzenprojekt!!:-) Danke Frank für dieses 
Projekt.

Frohe Ostern

[Ulli -. (ulli2k)]

Hallo zusammen,

Ich habe die Library IRMP und IRSND schon mit Erfolg auf einem Atmega8
anwenden können. Dafür erstmal ein dickes Lob für die tolle Lib.

Jetzt habe ich nur das Problem, dass ich an dem Atmega8 die SPI
Schnittstelle dringend benötige. Leider liegt der PWM Pin für die IRSND
Funktion auf dem MOSI Pin PB3. Ist es möglich diesen auf den PB1 (OC1A)
zu verschieben um die SPI Schnittstelle zu nutzen?

Seht ihr da eine Möglichkeit?

[Graf-von-Socke (Gast)]

hallo zusammen
ich möchte gernen meine digicam über infarot ansteuern und habe da 
folgendes gefunden

begin remote

  name  Olympus_RM-1
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       8853  4489
  one           559  1670
  zero          559   555
  ptrail        559
  repeat       8853  2259
  pre_data_bits   16
  pre_data       0x61DC
  gap          107013
  toggle_bit      0


      begin codes
          capture                  0x000000000000807F
          w                        0x00000000000040BF
          t                        0x000000000000C03F
          -                        0x00000000000020DF
          +                        0x000000000000A05F
      end codes

end remote

wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden

mfg

Graf-von-Socke

[Frank M. (ukw) (Moderator)]

Graf-von-Socke schrieb:

> begin remote

Ich vermute mal, dass das eine lirc-Berschreibungsdatei ist? Ich kenne 
mich damit nicht so aus, aber ich versuche mal zu deuten:

>   bits           16

16 Datenbits.

>   header       8853  4489

Das ist ein offenbar vom Timing ein NEC-Startbit, siehe auch:

  http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail

>   one           559  1670
>   zero          559   555

Das sieht ebenso nach NEC-Timing aus.

>   ptrail        559

Könnte das Stoppbit sein.

>   pre_data_bits   16

16 bits vor den Datenbits, scheint die NEC-Adresse zu sein.

>   pre_data       0x61DC

0x61DC ist offenbar die Adresse.

>           capture                  0x000000000000807F
>           w                        0x00000000000040BF
>           t                        0x000000000000C03F
>           -                        0x00000000000020DF
>           +                        0x000000000000A05F

Das scheinen die Kommando-Codes zu sein.

> wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden

Also probiere es mal mit

  IRMP_DATA irmp_data;
  ...

  irmp_data.protocol = IRMP_NEC_PROTOCOL;
  irmp_data.address  = 0x61DC;       // address of camera
  irmp_data.protocol = 0x40BF;       // command "w"
  irmp_data.flags    = 0x00;         // reset flags
  irsnd_send_data (&irmp_data);      // send data

Gruß,

Frank

[Ulli -. (ulli2k)]

hat keiner eine Vorstellung, ob man den IRSEND Pin bei einem Atmega8 von 
PB3 auf PB1 ändern kann und wenn ja wie?

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> hat keiner eine Vorstellung, ob man den IRSEND Pin bei einem Atmega8 von
> PB3 auf PB1 ändern kann und wenn ja wie?

IRSND benötigt den Timer1 bereits für das periodische Aufrufen der 
15kHz-ISR. Wenn Du die ISR über einen anderen Timer laufen lässt, kannst 
Du natürlich IRMP anpassen an OC1A (PB1). Dazu musst Du allerdings den 
Code erweitern.

IRMP benutzt den Timer0 bzw. Timer2 zur Erzeugung der 
Modulationsfrequenz per PWM. Der veraltete ATmega8 ist da ziemlich 
beschränkt. Wenn Du ihn gegen den moderneren ATmega88 tauschst, hast Du 
die Wahl zwischen OC2A (PB3) und OC2B (PD3), ohne den IRSND-Code 
erweitern zu müssen.

Gruß,

Frank

[Ulli -. (ulli2k)]

Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht 
gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht 
ausreichen? Auch nicht mit Code Erweiterung?

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht
> gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht
> ausreichen? Auch nicht mit Code Erweiterung?

Mit Code-Erweiterung gehts auch mit einem ATmega8.

Dann benutzt Du halt Timer 0 oder Timer 2 zum Aufruf der ISR mit 15kHz 
und verwendest Timer1 (und damit OC1A = PB1) als Sender-Ausgang. Aber 
die PWM-Routinen für die Modulation des Timer 1 musst Du dann neu 
schreiben, die habe ich nur für Timer 0 oder Timer 2 implementiert.

[eku (Gast)]

Hallo Frank,

mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC 
einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71 
auf 95 aktualisiert und nun funktioniert die Erkennung nicht:

* DENON wird nur noch sporadisch erkannt
* RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON 
Signalen
* SIEMENS werden nicht mehr alle Tasten erkannt
* die FB meines SHARP (siehe Beiträge Januar 2011) wird nicht mehr 
erkannt

Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du 
alle
nach Änderungen am Quellcode testest. Anscheinend macht es aber die 
Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte 
für meine Probleme verantwortlich sein?

Gruß, eku

[Christian R. (idl0r)]

hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe 
einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was? 
wenn beide versetzt voneinander angeordnet sind ok.. aber 
ueber/nebeneinander?

[Frank M. (ukw) (Moderator)]

Christian Ruppert schrieb:
> hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe
> einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was?
> wenn beide versetzt voneinander angeordnet sind ok.. aber
> ueber/nebeneinander?

Vielleicht arbeiten beide mit unterschiedlichen Modulationsfrequenzen?

[jar (Gast)]

eku schrieb:
> Kürzlich habe ich von Revision 71
> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:
>
> * DENON wird nur noch sporadisch erkannt

so was ähnliches ist mir auch ab und an mal aufgefallen,
habe alles aktiviert was <=15kHz ist und bekam für eine Kaseikyo alles 
von Siemens bis RUWIDO je nach Tastendrück

habe nun wieder die aktuelle in meine SW eingepflegt

 * $Id: irmp.h,v 1.73 2012/02/24 15:00:18 fm Exp $

und prompt kommt wieder der Fehler:
../irmp.h:489:1: warning: "TRUE" redefined

ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif

hatte ich auch in der letzten eingebauten Version nachgerüstet, aber 
jedesmal nachfummeln ist irgendwie unnötig zeitraubend

[jar (Gast)]

Korrektur zur Erkennung

umstellen mit rc5_ISR(); nach (void) irmp_ISR();

half für bessere Erkennung

ändert aber nix am redefine TRUE FALSE Problem





  if (! irsnd_ISR())         // call irsnd ISR
  {                          // if not busy...
    (void) irmp_ISR();      // call irmp 3-16µs
    (void) rc5_ISR();      // call rc5 8-10µs
    }

[Frank M. (ukw) (Moderator)]

eku schrieb:
> mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC
> einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71
> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:
>
> * DENON wird nur noch sporadisch erkannt
> * RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON
> Signalen
> [...]

Ich habe probeweise IRMP mit obigen Protokollen übersetzt und dann gegen 
IR-Data/denon-15kHz.txt laufen lassen... keine Probleme bei der 
Erkennung.

> Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du
> alle
> nach Änderungen am Quellcode testest.

Ja, ich checke sie immer mit test-suite.sh. Das Script schaltet alle 
Protokolle frei und lässt den generierten IRMP gegen die im Shell-Script 
aufgeführten Scan-Dateien laufen. Nur wenn diese fehlerfrei durchgehen, 
gebe ich eine Version frei. Natürlich ist mit diesem Check lediglich 
eine notwendige Bedingung für Fehlerfreiheit gegeben, aber nicht 
unbedingt eine hinreichende.

> Anscheinend macht es aber die
> Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte
> für meine Probleme verantwortlich sein?

Keine Ahnung. Nenne mir bitte die Scan-Dateien unter IR-Data, die von 
Dir sind. Dann kann ich diese nochmal gezielt in Deiner Kombination 
testen.

Gruß,

Frank

[finnjet (Gast)]

Ich stehe zur Zeit vor einem ähnlichen Problem, indem ich für einen 
Kenwood Receiver eine Ansteuerung implementieren möchte.  Es existiert 
eine LIRC Konfiguration, die auch funktioniert:
http://lirc.sourceforge.net/remotes/kenwood/RC-R0813

begin remote

  name  Kenwood_RC-R0813
  bits           24
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9065  4480
  one           580  1660
  zero          580   550
  ptrail        580
  repeat       9060  2230
  pre_data_bits   8
  pre_data       0x1D
  gap          108434
  toggle_bit      0


      begin codes
        power       0x00B946
        thx         0x8043BC
        listenmodeup 0x00fb04
        listenmodedown 0xe0f807
        activeeq    0x60e21d
        speakereq   0x60926d
        inputmode   0x20f906
        dspmode     0x8030cf
        mute        0x0039c6
        stereo      0x00eb14
        vol+        0x00d926
        vol-        0x0059a6
        setup       0xc09867
        sound       0x80ea15
        up          0x80aa55
        down        0x802ad5
        left        0x4000ff
        right       0x40807f
        tunerev     0x4040bf
        tunefwd     0x40c03f
        flip        0xc0906f
        band        0xc0609f
        inputsel    0xc06a95
        a/b         0x0010ef
        auto        0x4020df
        dimmer      0x40b847
        dvd6ch      0xc001fe
        cd/dvd      0x0049b6
        phono       0x0009f6
        tuner       0x008976
        video1      0x006996
        video2      0x0040bf
        video3      0xc0b847
        md/tape     0x00a956
        avaux       0x00c936
        loudness    0x00fa05
        tone        0x80AB54
        bass        0x40EA15


        1       0x00817E
        2       0x0041be
        3       0x00c13e
        4       0x0021de
        5       0x00a15e
        6       0x00619e
        7       0x00e11e
        8       0x0011ee
        9       0x00916e
        0       0x0001fe
        +10     0x00b04f
        +100    0x40f20d


      end codes

end remote

[finnjet (Gast)]

...Sorry! ich wollte nicht die ganze Datei posten!

Die Lirc Remote files sind ja sehr hilfreich, leider habe ich bislang 
keine ausführliche Beschreibung des Formats gefunden.

Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?) 
Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein. 
Die Timings sehen dagegen recht passend aus.

Sehe ich es richtig, dass ich mir hier gewissermaßen ein NEC36 
implementieren muss?

Gruß

[Frank M. (ukw) (Moderator)]

finnjet schrieb:

> Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?)
> Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein.
> Die Timings sehen dagegen recht passend aus.

Stimmt, diese sehen tatsächlich passend aus. Schalte einfach 
IRMP_LOGGING in irmpconfig.h ein, scanne die Tasten 0...9 ein und poste 
hier die Text-Datei. Ich baue das Protokoll dann ein. Den Aufbau der 
Scan-Datei siehst Du auch als Beispiele unter IR-Data/*.txt. Kommentare 
mit # eingeleitet wären hilfreich.

Hast Du denn schon mal Deine FB mit IRMP getestet?

Gruß,

Frank

[Hans W. (stampede)]

Hallo Frank,

ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt. 
Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für 
den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.

Grüße
Stampede

[Frank M. (ukw) (Moderator)]

Hallo Hans,

Hans W. schrieb:

> ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt.
> Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für
> den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.

Erstmal Danke fürs "Danke" ;-)

Ist bei Deiner Portierung vielleicht irgendetwas wichtiges, das in den 
allgemeinen Source zurückfließen sollte?

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> vielleicht irgendetwas wichtiges, das in den
> allgemeinen Source zurückfließen sollte?

möglicherweise in:

irmp.h:489:1: warning: "TRUE" redefined

ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?

#ifndef FALSE
  #define FALSE 0
#endif
#ifndef TRUE
  #define TRUE !FALSE
#endif

oder lag der Fehler bei mir ?

ansonsten, auch von mir noch mal ein Riesen DANKE

auch wenn ich momentan nicht weiterkomme in der ausschliesslichen 
Nutzung von IRMP allone, in der Verbindung mit "meinen" alten RC5 
Auswertecode tuts ganz hervorragend :-)

alle Versuche das change key bit vom RC5 in IRMP zu generieren sind bis 
jetzt fehlgeschlagen, aber macht nix, irgendwann finde(t) ich (sich) ne 
Lösung
jar

[Frank M. (ukw) (Moderator)]

jar schrieb:
> möglicherweise in:
>
> irmp.h:489:1: warning: "TRUE" redefined

Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist 
eine Folge einer TRUE-Definition, die aus Deinem Source kommt.

Sagt der Compiler nicht, wo die ursprüngliche Definition steht?

> ich mag nun nicht jedesmal suchen wo das herkommt
> wäre folgendes nicht sinnvoll ?
>
> #ifndef FALSE
>   #define FALSE 0
> #endif
> #ifndef TRUE
>   #define TRUE !FALSE
> #endif

Könnte ich machen, aber theoretisch gibt es ja tausend Möglichkeiten 
solcher Konflikte.

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist
> eine Folge einer TRUE-Definition, die aus Deinem Source kommt.

die ich bestimmt auch brauche an der Stelle ;-)

klaro um das abzukürzen suche ich alle meine TRUE def und bau das bei 
mir ein

dann muss das in IRMP.H nicht geändert werden, sollte auch klappen 
(hoffe ich)

danke
jar

PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht 
auszuschliessen das man immer wieder drüber stolpert, also so dumm ist 
mein Gedanke nicht das auch in irmp.h einzubauen

[Frank M. (ukw) (Moderator)]

jar schrieb:
> PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht
> auszuschliessen das man immer wieder drüber stolpert, also so dumm ist
> mein Gedanke nicht das auch in irmp.h einzubauen

Ich habe es jetzt so geändert:

#ifndef TRUE
#define TRUE                                    1
#define FALSE                                   0
#endif

Kommt mit dem nächsten Release.

[jar (Gast)]

Frank M. schrieb:
> #ifndef TRUE
> #define TRUE                                    1
> #define FALSE                                   0
> #endif
>
> Kommt mit dem nächsten Release

Klasse, braucht man nicht mehr zusätzlich Hand anzulegen beim Einbau !

danke
jar

[Sebastian (Gast)]

Hallo zusammen,

ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch 
so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit 
20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren, 
und die sehen auch plausibel aus. Nun dachte ich, dass das Senden 
deutlich einfacher ist, aber das will einfach nicht laufen. Die 
Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel 
aufgebaut. Ich hab schon folgende Dinge überprüft:
 - 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz 
duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.
 - ein/ausschalten der PWM passt auch
 - ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd 
erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC 
empfängt auch genau dieselbe Bitfolge.

Bin gerade etwas ratlos. Hat vielleicht noch jemand nen heißen Tipp für 
mich?

Viele Grüße
Sebastian

[Sebastian .. (zahlenfreak)]

Hallo Frank,

ich hab da ein etwas seltsames Problem mit IRMP:

Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass 
eine Taste reproduzierbar andere Daten liefert als normalerweise. Das 
hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe, 
danach gehen wieder alle wie gewohnt.

Von dem Fehler sind mehrere (alle?) Tasten meiner FB betroffen.
Der (falsche) Code, den IRMP ausgibt, wenn der Fehler auftritt, scheint 
dann erstmal immer der gleiche zu sein, konnte das aber noch nicht 
verifizieren. Es ist aber auf jeden Fall nicht bei jeder Taste der 
gleiche.

Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der 
Bug bei
Protocol 8
Address 4
Command 1E8 und 0E8

Bei anderen Tasten auch, aber da müsste ich die richtigen Codes erst 
wieder raussuchen.

Hatte auch schon überlegt, ob vielleicht die Fernbedienung einen Bug 
hat, aber eine andere mit NEC-protocol zeigt das gleiche Verhalten, wenn 
auch deutlich schwerer zu provozieren.

Ich weiß momentan nicht so recht weiter. In meiner Software hab ich 
nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.

Vielleicht hat hier ja jemand eine Idee, was das sein könnte. Bei Bedarf 
mach ich natürlich gerne noch weitere Versuche.

Viele Grüße,
Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian schrieb:
> ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch
> so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit
> 20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren,
> und die sehen auch plausibel aus.

Welches IR-Protokoll?

> Nun dachte ich, dass das Senden
> deutlich einfacher ist, aber das will einfach nicht laufen. Die
> Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel
> aufgebaut. Ich hab schon folgende Dinge überprüft:
>  - 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz
> duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.
>  - ein/ausschalten der PWM passt auch
>  - ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd
> erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC
> empfängt auch genau dieselbe Bitfolge.

Es lässt sich mit IRMP auch wieder dekodieren?

Es kann sein, dass der Original-Empfänger vom Timing her empfindlicher 
ist als IRMP, welcher auch noch bei größeren zeitlichen Abweichungen das 
Signal noch erkennt.

Ein IRMP-Scan (siehe auch IR-Data/*.txt) von der Original-FB wäre nicht 
schlecht.

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:
> ich hab da ein etwas seltsames Problem mit IRMP:
>
> Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass
> eine Taste reproduzierbar andere Daten liefert als normalerweise.

Wie sehen die Daten bzgl. Protokollnr, Adresse und Kommando-Code vorher 
und nachher aus?

> Das
> hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe,
> danach gehen wieder alle wie gewohnt.

Das hört sich so an, als ob irgendetwas in der Statemachine nicht 
korrekt zurückgesetzt wird.

Hilfreich wäre ein IRMP-Scan mit einer Tastenfolge, wo der Fehler 
auftritt. Dann müsste ich das unter Linux reproduzieren können.

> Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der
> Bug bei
> Protocol 8
> Address 4
> Command 1E8 und 0E8

Das oben ist der korrekte? Wie sieht der fehlerhafte Code aus?

> Ich weiß momentan nicht so recht weiter. In meiner Software hab ich
> nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.

Gibt es außer IRMP noch weitere Software-Module, die in beiden Projekten 
stecken?

Ich bräuchte da Scans... sonst kann ich Dir wahrscheinlich nicht helfen.

[Sebastian (Gast)]

Hallo Frank,

anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba 
CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die 
Pulslänge misst. Vielleicht fällt dir ja noch was auf.

Viele Grüße
Sebastian

[jar (Gast)]

Sebastian schrieb:
> Der PIC läuft mit
> 20Mhz und die ISR mit 9,766kHz.

ist unter 10 kHz nicht etwas knapp ?
ich denke IRMP will als minimum 10kHz ?

[Frank M. (ukw) (Moderator)]

Hallo Sebastian,

Sebastian schrieb:

> anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba
> CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die
> Pulslänge misst. Vielleicht fällt dir ja noch was auf.

Beide Scans lassen sich einwandfrei decodieren, auch wenn ich sagen 
muss, dass die 9766Hz beim Denon-Protokoll schon arg knapp sind.

# ./irmp  <rx_denon_9766Hz.txt
-------------------------------------------------------------------
#1
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#2
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#3
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#4
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#5
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00


# ./irmp-20kHz < rx_test_19990Hz.txt
-------------------------------------------------------------------
#1 denon vol+
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#2 denon vol+
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#3 denon vol+
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00
-------------------------------------------------------------------
#4 nec vol+
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00
-------------------------------------------------------------------
#5 nec vol+
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00
-------------------------------------------------------------------
#6 nec vol+
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

Zu rx_denon_9766Hz.txt:

Du hast bei #1 bis #5 immer dieselbe Taste gedrückt, oder?

Zu rx_test_19990Hz.txt: auch kein Problem.

Wenn ich Dein vorhergendes Posting richtig verstanden habe, hast Du 
lediglich ein Problem beim Senden dieser Codes mittels IRSND.

Wenn ich den Output von IRSND in den IRMP mittels Unix-Pipe schicke, 
klappt alles sauber:

# ./irsnd 8 0008 023c 0 | ./irmp
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

# ./irsnd-20kHz 8 0008 023c 0 | ./irmp-20kHz
010001000111100
010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

# ./irsnd-20kHz 2 bf40 001a 0 | ./irmp-20kHz
00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

Vergleich des IRSND-Outputs mit Deiner Text-Datei:

# ./irsnd-20kHz 2 bf40 001a 0 
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111...
# tail -1 rx_test_19990Hz.txt
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000000000000111111111100000000000011111111110000000000000111111111100000000000001111111110000000000000111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111100000000000001111111111111111111111111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111110000000000000111111111000000000000011111111110000000000000111111111111111111111111111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111111111111111111111111111000000000000111111111...

Bis auf minimale, zu vernachlässigende Abweichungen ist der Output 
derselbe.

Kannst Du den IRSND mittels zweitem µC auch scannen?

Gruß,

Frank

[Sebastian (Gast)]

Hallo Frank,

ja, #1-#5 in rx_denon_9766Hz.txt ist immer dieselbe Taste.

OK, du meinst also, dass das von IRMP decodierte Signal OK ist. Davon 
gehe ich auch aus. Ich verstehe nur nicht, warum das Senden im IRSND 
nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden 
des Denon/Nec Protokoll?

Das Scannen des IRSND Signals über einen 2. µC werde ich die mal 
testen...

Gruß
Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian schrieb:
> OK, du meinst also, dass das von IRMP decodierte Signal OK ist.

Ja.

> Ich verstehe nur nicht, warum das Senden im IRSND
> nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden
> des Denon/Nec Protokoll?

Für das NEC-Protokoll sind 10kHz (oder Deine 9,7kHz) ausreichend. Daher 
sollte Dein Toshiba-Fernseher problemlos klarkommen. Ich habe auch einen 
Toshiba, den ich mit IRSND und 10kHz problemlos bedienen kann.

Bei Denon ist das jedoch kritisch, siehe auch:

  http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle

Auszug für Denon:

In der Praxis (diverse Scans von verschiedenen IRMP-Anwendern) sind es:

0-Bit   310µs Puls, 745µs Pause
1-Bit   310µs Puls, 1780µs Pause

Laut diverser Dokus im Netz sind es jedoch:

0-Bit   275µs Puls, 775µs Pause)
1-Bit   275µs Puls, 1900µs Pause)

Das sind gerade mal 3 Timer-Takte zum Generieren der Pulse. Da könnte 
die Abweichung schon so groß sein, dass der Denon-Empfänger das nicht 
mehr akzeptiert. Bei 15kHz und mehr sollten die Abweichungen wesentlich 
geringer sein.

Ich habe gerade mal Deine 1990er Scans durch den IRMP-Analyzer 
geschickt:

pulse avg:  5.7= 284.9 us, min:  5= 250.0 us, max:  7= 350.0 us, tol: 22.8%
pause avg: 15.2= 759.8 us, min: 14= 700.0 us, max: 16= 800.0 us, tol:  7.9%
pause avg: 35.9=1794.4 us, min: 34=1700.0 us, max: 37=1850.0 us, tol:  5.3%

Die Pulse entsprechen eher den Werten aus der Doku, der Rest eher den 
Erfahrungen, die bisher mit Denon-FBs gemacht wurden.

Du könntest also mal

#define DENON_PULSE_TIME                         310.0e-6                       //  310 usec pulse in practice,  275 in theory

in

#define DENON_PULSE_TIME                         275.0e-6                       //  310 usec pulse in practice,  275 in theory

ändern. Ich bezweifle aber, dass das was bringt. Irgendetwas anderes ist 
da faul, denn zumindest Dein Toshiba sollte problemlos mit dem 
IRSND-Output klarkommen.

> Das Scannen des IRSND Signals über einen 2. µC werde ich die mal
> testen...

Ja, ich glaube, das bringt uns eher weiter.

Gruß,

Frank

[Sebastian .. (zahlenfreak)]

Hallo Frank,

Vielen Dank schonmal für deine Antwort und sorry, dass ich so lange 
brauche. Ist zur Zeit leider etwas stressig hier.


Hier jetzt also die Ergebnisse:
Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch 
zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch 
bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich 
wieder eine beliebige andere Taste drücke. Der Falsch erkannte Code ist 
"characteristisch" für die Taste und jedes mal der gleiche, wenn der 
Fehler auftritt.
Der Fehler dürfte ziemlich sicher in IRMP liegen. Habe testweise einen 
Controller nur mit IRMP geflasht. Den Code habe ich nur um eine simple 
UART-routine erweitert, die die erkannten codes ausgibt.
Außerdem ist aufgefallen, dass, wenn der extra eingerichtete Controller 
die codes falsch erkannt hat, ein anderes Projekt gleichzeitig die 
Commandos richtig decodiert. Bei dem anderen Projekt tritt der Fehler 
prinzipiell aber auch auf. Die Fernbedienung kanns also nicht sein. 
Vielleicht noch der Empfänger. Das sind zwei unterschiedliche in den 
beiden Projekten. Wäre aber komisch...

Der fehler tritt auch mit anderen Tasten auf, aber mit diesen habe ichs 
jetzt mal nachvollzogen. Auch mit einer anderen Fernbedienung 
(NEC-protocol) habe ich den Bug schon gehabt, aber wie gesagt kaum 
reproduzierbar.

Anbei sind Scans der vier Tasten mit 20kHz. Sobald ich zeit finde, 
scanne ich auch die ganze Fernbedienung ein, aber jetzt muss ich erstmal 
ins Bett.

Viele Grüße,

Sebastian



Die (vermutlich) Richtigen Codes sind:

Stop-Taste
Protocol 0x08
Address 0x0004
Command 0x01E8


Play >-Taste
Protocol 0x08
Address 0x0004
Command 0x00E8

Pause -Taste
Protocol 0x08
Address 0x0004
Command 0x02E8

Play < -Taste
Protocol 0x08
Address 0x0004
Command 0x03A8




Stop -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0217

Play > -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x317

Pause -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0117

Play < -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0057

[Frank M. (ukw) (Moderator)]

Hallo Sebastian,

Sebastian ... schrieb:
> Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch
> zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch
> bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich
> wieder eine beliebige andere Taste drücke.
>

Ich glaube zu verstehen, was da falsch läuft. Das Denon-Protokoll 
schickt jeden Frame zweimal raus, wobei beim zweiten mal die 
Command-Bits invertiert sind. Zwischen diesen beiden Frames ist eine 
Pause von 65ms.

IRMP wartet immer den 2. Frame ab und vergleicht die Command-Bits, ob 
sie invertiert sind. Soweit okay, aber: Bekommt IRMP mal den ersten 
Frame nicht richtig mit, klinkt er sich beim 2. Frame ein und wartet 
dann auf den vermeintlichen 2. Frame mit invertierten Bits. Drückst Du 
die Taste dann nochmal, nimmt er den 1. Original-Frame als invertierten 
Frame auf und bestätigt diesen als vermeintlich richtigen Code. Aus 
diesem "falschen Takt" kommt IRMP nur wieder raus, wenn irgendwann 
wieder eine Übertragunsstörung auftritt.

Diesen Fehler kann man hier auch gut erkennen:

> Die (vermutlich) Richtigen Codes sind: [...]
> Command 0x01E8
> Stop -Taste Falscher Code [...]
> Command 0x0217

0x01E8 = 01 1110 1000
0x0217 = 10 0001 0111

Man sieht, dass hier alle 10 Bits gekippt sind. Das gleiche gilt auch 
für die anderen Kommando-Codes, die Du genannt hast.

Um diesen Fehler zu beheben, muss ich eine Abbruchbedingung in IRMP 
einbauen, wie lange er auf den 2. Frame warten soll. Ist die Zeit 
wesentlich größer als 65ms, sollte IRMP den empfangenen Frame einfach 
verwerfen und wieder "von vorn" anfangen.

> Anbei sind Scans der vier Tasten mit 20kHz.

Danke. Aus irgendeinem Grunde kommt der IRMP mit den Scans nicht ganz 
klar. Er erkennt zwar Denon, bricht aber dann irgendwann die Decodierung 
ab. Das schaue ich mir nochmal genauer an, kann sein, dass bei 20kHz der 
Log-Buffer überläuft und die Scans nicht lang genug sind für 2 Frames.

Warum verwendest Du 20kHz und nicht 15kHz?

Gruß,

Frank

[Sebastian .. (zahlenfreak)]

Hallo Frank,

das klingt ja schonmal sehr gut!


Das mit den Scans scheint meine Schuld bzw die der Fernbedienung zu 
sein. Das dürften unvollständige Kommandos sein. Sorry dafür.
Kam so, dass ich wiederholungen vermeiden wollte, also möglichst kurz 
gedrückt hab. Aber die FB scheint die Übertragung wieder abzubrechen, 
wenn man zu kurz drückt. Jedenfalls Reagieren ein IRMP-Projekt und der 
original-Verstärker nur, wenn ich die Taste etwas länger drücke. Dann 
sind auch die scans des gleichzeitig laufenden Scan-IRMPs länger.

Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem 
Tastendruck. Und mit 15kHz.
Die 20kHz kamen übrigens aus der überlegung "viel hilft viel" ;) Das 
Verhalten mit kurzen und langen scans hab ich aber bei 15 und 20 kHz 
gleichermaßen.


Viele Grüße,

Sebastian

[Frank M. (ukw) (Moderator)]

Hallo Sebastian,

Sebastian ... schrieb:

> Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem
> Tastendruck. Und mit 15kHz.

Nachdem ich alle Kommentarzeilen mit "#" auch als solche gekennzeichnet 
und in irmp.c die Zeile

#define DENON_PULSE_LEN_MAX                     ((uint8_t)(F_INTERRUPTS * DENON_PULSE_TIME * MAX_TOLERANCE_10 + 0.5) + 1)

in

#define DENON_PULSE_LEN_MAX                     ((uint8_t)(F_INTERRUPTS * DENON_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

geändert habe, ging der Scan einwandfrei durch.

Deine FB scheint außergewöhnlich lange Pulse zu machen. Ich empfehle Dir 
daher, die Toleranz in irmp.c auf 20% zu erhöhen - so wie oben 
geschrieben. Ich werde das ebenso ins nächste Release einbauen.

Mittlerweile habe ich eine Abbruchbedingung in der IRMP-Statemachine 
eingebaut, damit die invertierten Frames beim Denon-Protokoll nicht als 
Initial-Frames erkannt werden. Funktioniert soweit mit künstlich 
generierten "fehlerhaften" Scan-Dateien tadellos. Desweiteren habe ich 
das Denon-Timing im IRSND auch verbessern können, so dass das Verhalten 
(nach 65ms kommt der invertierte Frame) nun exakt nachgebildet wird.

Damit sollten Deine Probleme erledigt sein. Das neue Release kommt in 
Kürze.

Viele Grüße,

Frank

[Frank M. (ukw) (Moderator)]

Es steht eine neue Version 2.2.0 von IRMP + IRSND zum Download bereit.

Download über Artikel:

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

und auch übers SVN möglich:

   http://www.mikrocontroller.net/svnbrowser/irmp/

Die wichtigsten Änderungen IRMP:

    - Portierung auf ARM STM32
    - Bugfix Frame-Erkennung beim Denon-Protokoll

Die wichtigsten Änderungen IRSND:

    - Portierung auf ARM STM32 (ungetestet!)
    - Bugfix Timing für 2. Frame beim Denon-Protokoll

Da IRMP/IRSND nun auf den Zielsystemen AVR/PIC/STM32 läuft, war eine 
größere Umstrukturierung des Sources notwendig, um weiterhin die 
Konfigurationsdateien irmpconfig.h und irsndconfig.h möglichst einfach 
und übersichtlich zu belassen.

Die IR-Protokoll-spezifischen Definitionen haben dafür eine neue 
Include-Datei irmpprotocols erhalten. Ebenso sind die für die 
verschiedenen Zielsysteme notwendigen Konstanten in die neue Datei 
irmpsystem.h gewandert.

Anzupassen ist weiterhin lediglich eine Datei, nämlich irmpconfig.h bzw. 
irsndconfig.h.

Achja, noch eine Kleinigkeit: Der Applikationssource darf nun nur noch 
irmp.h bzw. irsnd.h per Include einfügen. Alle anderen notwendigen 
H-Dateien werden automatisch von irmp.h bzw. irsnd.h per Include 
eingefügt.

Also:

#include "irmp.h"

main ()
{
  ....
}

Siehe auch die dazugehörigen Beispiel-Dateien main.c bzw. irsndmain.c.

Sämtliche Änderungen und neue Dateien wurden auch im Artikel IRMP 
dokumentiert bzw. aktualisiert.

Vielen Dank an kichi (Michael K.) für seine unermüdliche Arbeit an der 
STM32-Portierung.

Wünsche viel Spaß,

Frank

P.S.
@Sebastian: Mit diesem Release sollten Deine Probleme mit dem 
Denon-Protokoll behoben sein.

[Frank M. (ukw) (Moderator)]

Hallo zusammen,

ein paar Bugs wurden in der STM32-Portierung gefunden und behoben. Im 
SVN unter

   http://www.mikrocontroller.net/svnbrowser/irmp/

ist daher jetzt die Version 2.2.1 eingecheckt.

Die Änderungen betreffen nur die STM32-Variante. Für AVRs und PICs hat 
sich gegenüber 2.2.0 nichts geändert. Sobald die Tests von IRSND unter 
STM32 abgeschlossen sind, wird es auch neue Zip-Dateien direkt zum 
Download aus dem IRMP-Artikel geben.

Viele Grüße,

Frank

[Hugo P. (portisch)]

Hallo!

Ich habe mal eine kleine Zwischenfrage:
Ich wollte nun den USB IR Remote Receiver updaten.

Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.
Leider kann aber der Compiler (AVR Studio 5) die Defines von der 
"irmpconfig.h" nicht mehr lesen.

Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:
#if IRMP_LOGGING == 1
drinnen.

Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden 
ist.
Was gibt es da für einen Trick um das wieder hinzubekommen?

[Frank M. (ukw) (Moderator)]

Hallo Hugo,

Hugo Portisch schrieb:

> Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.
> Leider kann aber der Compiler (AVR Studio 5) die Defines von der
> "irmpconfig.h" nicht mehr lesen.

Kann ich mir überhaupt nicht erklären, denn in irmp.h steht nun
das

  #include irmpconfig.h

drin.

Das heisst, irmpconfig.h wird eingebunden und dadurch auch z.B. 
IRMP_LOGGING definiert.

> Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:
> #if IRMP_LOGGING == 1
> drinnen.

Sollte ganz normal (also wie immer) gehen.

Ich habe gerade mal testweise in das Beispiel-main.c von IRMP eingefügt:

#if IRMP_LOGGING == 1
xxxxxx
#endif

und IRMP_LOGGING auf 1 in irmpconfig.h gestellt.

Beim Neucompilieren bekomme ich sofort den (gewünschten) Syntax-Error 
als Indikator, dass IRMP_LOGGING den korrekten Wert hat.

> Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden
> ist.

Doch, wird sie - über irmp.h

> Was gibt es da für einen Trick um das wieder hinzubekommen?

Es ist eigentlich kein Trick notwendig, siehe oben.

Kann es sein, dass Dein Compiler nicht bemerkt, dass Du irmpconfig.h 
geändert hast und er deshalb Dein main-Modul nicht neu übersetzt? Du 
solltest auf jeden Fall irmpconfig.h mit in Dein Projekt einfügen. Sonst 
fehlt die Abhängigkeit und die entsprechenden C-Sources werden nicht neu 
übersetzt, wenn Du irmpconfig.h änderst.

Im Notfall hilft auch eine Neuübersetzung des kompletten Codes.

Gruß,

Frank

[Sebastian .. (zahlenfreak)]

Hallo Frank,

schonmal vielen vielen Dank für den schnellen Bugfix! So guten Support 
sieht man selten. Leider kam das Update genau zu meiner Abreise in den 
Urlaub, ich konnte also noch nichts testen. Sobald ich zurück bin werde 
ich aber die neue Version ausprobieren und berichten.


Viele Grüße,

Sebastian

[Dirk W. (glotzi)]

Hallo,

die Merlin Tastatur von Pollin scheint wohl doch mit IRMP zu 
funktionieren: man muss nur den richtigen TSOP benutzen und das RUWIDO 
Protokoll enablen.

So stehts zumindest hier:
http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg118182#msg118182

Allerdings geht dann wohl nur noch die Merlin. Hat jemand ne Idee wie 
man das etwas allgemeingültiger hinbekommt?

[Martin S. (drunkenmunky)]

Kann mir jemand gerade sagen, wie groß der Flash von einem PIC18 sein 
muss, wenn mal alle Protokolle aktivieren will? Bin gerade am Controller 
auswählen und es wär super, wenn das jemand auf die Schnelle weiß.

Danke,
Gruß

[jar (Gast)]

den PIC kenne ich nicht, der Atmel braucht ca. 8k

[Frank M. (ukw) (Moderator)]

Dirk W. schrieb:
> die Merlin Tastatur von Pollin scheint wohl doch mit IRMP zu
> funktionieren: man muss nur den richtigen TSOP benutzen und das RUWIDO
> Protokoll enablen.
>
> So stehts zumindest hier:
> http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg118182#msg118182

Die Merlin-Tastatur scheint eine Modulationsfrequenz von 56kHz zu 
benötigen. Damit sind die anderen Protokolle, die meist nah bei 38kHz 
arbeiten, gar nicht mehr oder nur schwach zu empfangen.

> Allerdings geht dann wohl nur noch die Merlin. Hat jemand ne Idee wie
> man das etwas allgemeingültiger hinbekommt?

Schließe einfach zwei TSOPs an zwei verschiedene Pins desselben Ports 
des µCs an: einen mit 56kHz, den anderen mit 38kHz. Passe dann das 
input()-Makro (im neuesten Source ist das in irmp.h, früher in 
irmpconfig.h) dermaßen an, dass beide TSOPs eingelesen werden und 
verknüpfe beide Signale.

Alternativ könnte man die TSOP-Ausgänge mit einem AND-Gatter verbinden 
und dann den Ausgang des Gatters an den µC anschließen.

Beispiel:

irmpconfig.h

#  define IRMP_PORT_LETTER                      B
#  define IRMP_BIT_NUMBER_1                     6
#  define IRMP_BIT_NUMBER_2                     5

irmp.h:

#  define IRMP_BIT_1                            IRMP_BIT_NUMBER_1
#  define IRMP_BIT_2                            IRMP_BIT_NUMBER_2

#  define input(x)                              ((x) & ((1 << IRMP_BIT_1) | (1 << IRMP_BIT_2)) == ((1 << IRMP_BIT_1) | (1 << IRMP_BIT_2)))

Wenn einer der beiden TSOPs das Ausgangssignal auf LOW (TSOPs sind 
active low!) zieht, wird input(x) eine 0 liefern - wie gewünscht.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:
> Kann mir jemand gerade sagen, wie groß der Flash von einem PIC18 sein
> muss, wenn mal alle Protokolle aktivieren will?

Alle Protokolle zu aktivieren ist nicht unbedingt sinnvoll. Die als 
"exotic protocols" in irmpconfig.h angegebenen Protokolle würde ich nur 
dann aktivieren, wenn man sie explizit braucht. Zudem wirst Du einen 
Konflikt bekommen, wenn Du DENON und RUWIDO gleichzeitig aktivierst, da 
man beide Protokolle nicht so einfach auseinanderhalten kann. Das Timing 
ist einfach zu ähnlich. Ausserdem ist es Quatsch, wenn man das 
Bang&Olufsen-Protokoll aktiviert, was einen TSOP mit 455 kHz erfordert, 
wobei die meisten anderen Protokolle mit 38kHz arbeiten. Man wird da mit 
nur einem TSOP nicht alles empfangen können.

> Bin gerade am Controller
> auswählen und es wär super, wenn das jemand auf die Schnelle weiß.

Ich kann es nur für den AVR angeben. Wenn man alle Protokolle aktiviert, 
aber die "exotischen" weglässt (s.o.), dann sind es bei einem ATmega88 
4420 Bytes fürs Flash.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

jar schrieb:
> den PIC kenne ich nicht, der Atmel braucht ca. 8k

Das ist Unsinn. Theoretisch sind es 6,5k (alle 30 Protokolle aktiviert), 
tatsächlich sind es aber nur 4,5k - siehe dazu mein vorheriges 
Statement.

[jar (Gast)]

Frank M. schrieb:
> Das ist Unsinn

OK, ich hatte nur mal deine flash Verbräuche addiert

natürlich machen alle zusammen akktiviert so keinen Sin 455kHz und 56kHz 
aber wir lernen ja dazu, für einen IR Tester haben sehr wohl alle 
aktiviert Sinn, Ausnahme die "faule" Frequenzen

[Frank M. (ukw) (Moderator)]

jar schrieb:
> OK, ich hatte nur mal deine flash Verbräuche addiert

Das sind nur ungefähre Angaben. Je nach Kombination der aktivierten 
Protokolle können es auch weniger "verbrauchte" Bytes sein, da einige 
Protokolle gemeinsamen Code verwenden. Hat man z.B. schon mal ein 
Protokoll mit Manchester-Codierung ausgewählt, verbraucht ein zweites 
Manchester-Protokoll evtl. weniger als angegeben.

Gruß,

Frank

[Martin S. (drunkenmunky)]

Ok danke, das hilft mir schon mal weiter.

Hätte noch ein paar Fragen...

Mit welchen Strom muss man die IR LED ungefähr betreiben, damit man eine 
"gute" Übertragung erhält (also nicht nur direkt, sondern auch über 
Reflektionen durch Wände)?

Sollte die Strahlungsleistung der LED so hoch wie möglich sein? Da 
gibt's ja welche von 1 mW/sr bis über 100 mW/sr.

Habt ihr Erfahrungen mit verschiedenen Abstrahlwinkeln der LEDs gemacht?

Was empfehlt ihr für eine "universelle" Empfängerfrequenz? Wo gibt es 
denn bezahlbare 455 kHz Empfänger?

Sehe ich das richtig, dass man für den Empänger jeden beliebigen 
digitalen Eingang nehmen kann? Und für die LED einen 
Hardware-PWM-Ausgang?

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:
> Mit welchen Strom muss man die IR LED ungefähr betreiben, damit man eine
> "gute" Übertragung erhält (also nicht nur direkt, sondern auch über
> Reflektionen durch Wände)?

Soviel, wie die IR-LED an Strom verkraftet. Das Datenblatt zur LED 
sollte Auskunft geben. Da IRSND die LED ja nicht mit einem Konstantstrom 
versorgt, sondern wegen der Modulation (und auch wegen des 
IR-Protokolls!) nur immer eine Teilzeit wirklich "an" ist, darf der 
Strom 2-3 mal höher als der typische Konstantstrom sein - vorausgesetzt, 
die LED verkraftet solche "Pulse" auch. Das steht aber auch 
normalerweise im Datenblatt.

> Sollte die Strahlungsleistung der LED so hoch wie möglich sein? Da
> gibt's ja welche von 1 mW/sr bis über 100 mW/sr.

Kommt drauf an, wieviele Meter Du überbrücken willst. ;-)

> Habt ihr Erfahrungen mit verschiedenen Abstrahlwinkeln der LEDs gemacht?

Ich habe nur die IRMP-Artikel erwähnte SFH409 (3mm IR-LED) getestet. Da 
muss man schon ziemlich genau zielen - gerade, wenn man auch keinen 
Reflexionsspiegel hinter der LED hat. Je größer der Abstrahlwinkel, 
desto besser. Allerdings dürfte da die Reichweite schlechter werden.

> Was empfehlt ihr für eine "universelle" Empfängerfrequenz?

Mit 38kHz für den TSOP emfängst Du so alles zwischen 36 und 40kHz. Damit 
bist Du gut dabei.

> Wo gibt es denn bezahlbare 455 kHz Empfänger?

Google mal nach TSOP7000. Hier ein Treffer:

  http://www.mara-elektronik.de/TSOP7000

Fragt sich nur, ob 4,50 EUR für Dich bezahlbar heisst.

> Sehe ich das richtig, dass man für den Empänger jeden beliebigen
> digitalen Eingang nehmen kann?

Ja.

> Und für die LED einen Hardware-PWM-Ausgang?

Ja, vorzugsweise einer, der in irsndconfig.h in den Kommentaren 
angegeben ist.


Gruß,

Frank

[Martin S. (drunkenmunky)]

Danke für schnelle und ausführliche Antwort!

Das Einschaltverhältnis der schnellen PWM Frequenz ist 50%, oder? Um es 
genau zu berechnen, darf der Effektivwert des Diodenstroms nicht größer 
sein als der konstant Zugelassene (oder der arithmetische Mittelwert?)? 
Klar, der hängt dann noch vom verwendeten Protokoll ab.

D.h. du betreibst die LED mit 200 bis 300mA? Das erzeugt ja dann ne 
Menge Verlustleistung im Vorwiderstand.

Betreibst du die LED dann mit der gleichen Spannung wie den uC? Kann das 
zu Problemen führen?

[Fridolin O. (muebau)]

Hi,
ich betreibe IRMP mit der MERLIN Tastatur:
http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg118182#msg118182

Nun zeigt sich nach den ersten Versuchen aber das die Erkennungsrate 
recht schlecht ist. Ich bekomme eine Mischung von RUWIDO (23) und 
SIEMENS (17). Aktiviert habe ich nur RUWIDO. Meine 
"MediaMall"-Fernbedienung (RUWIDO) funktioniert einwandfrei.

Was sollte ich nun versuchen?

muebau

[Klaus L. (Gast)]

Martin S. schrieb:
> Was empfehlt ihr für eine "universelle" Empfängerfrequenz? Wo gibt es
> denn bezahlbare 455 kHz Empfänger?

Darisus hat wohl auch noch welche:
http://darisusgmbh.de/shop/product_info.php/info/p34359_TSOP7000-----Miniatur-Infrarotempf-nger-455kHz.html

Grüße,
Klaus

[Frank M. (ukw) (Moderator)]

Fridolin Onteca schrieb:
> Hi,
> ich betreibe IRMP mit der MERLIN Tastatur:
> http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg118182#msg118182
>
> Nun zeigt sich nach den ersten Versuchen aber das die Erkennungsrate
> recht schlecht ist. Ich bekomme eine Mischung von RUWIDO (23) und
> SIEMENS (17). Aktiviert habe ich nur RUWIDO. Meine
> "MediaMall"-Fernbedienung (RUWIDO) funktioniert einwandfrei.

Die Merlin-Tastatur wird von IRMP nur schlecht bis gar nicht 
unterstützt. Vielleicht ist dieses Programm besser für Dich geeignet:

  Beitrag "AVR ATmega48 RUWIDO Merlin IR Keyboard Dekoder (Pinchange Interrupt basiert)"

Günter hat seine spezielle Lösung für die Merlin-Tastatur an IRMP stark 
angelehnt.

Vielleicht implementiere ich irgendwann eine saubere Erkennung für die 
Merlin-Tastatur im IRMP. Bis dahin kann ich nur auf Günters Programm 
verweisen.

Viele Grüße,

Frank

[Frank M. (ukw) (Moderator)]

Neue Version 2.2.2 von IRMP + IRSND:

Download über Artikel:

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

und auch übers SVN möglich:

   http://www.mikrocontroller.net/svnbrowser/irmp/

Die wichtigsten Änderungen IRMP:

    - Portierung auf ARM STM32 abgeschlossen
    - Include-Korrektur in irmpextlog.c
    - Bugfix, wenn nur NEC und NEC42 aktiviert

Die wichtigsten Änderungen IRSND:

    - Portierung auf ARM STM32 abgeschlossen

Viel Spaß mit IRMP,

Frank

[Christoph (Gast)]

@Frank M.

Gibt es etwas neues zum Thema Dreambox ?


Gruß Christoph

[Frank M. (ukw) (Moderator)]

Christoph schrieb:
> Gibt es etwas neues zum Thema Dreambox ?

Sorry, neín. Mache ich vielleicht nächste Woche.

Gruß,

Frank

[Sebastian .. (zahlenfreak)]

Hallo Frank,

ich bin jetzt endlich auch mal dazu gekommen, den Denon Bugfix zu testen 
(Version 2.2.2). Sorry, dass es so lange gedauert hat.
Hin und wieder wird noch ein Tastendruck falsch erkannt und der falsche 
Code zurückgeliefert. Aber so wie ich dich verstanden habe, lässt sich 
das nicht beheben. Ist auch nicht so schlimm.
Aber IRMP bleibt auf jeden Fall nicht mehr bei dem falschen Code hängen. 
Funktioniert in der Hinsicht jetzt einwandfrei. Das ist sehr gut.
Vielen Dank für deine tolle und Arbeit und den schnellen Bugfix!

Viele Grüße,
Sebastian

[Sebastian (Gast)]

Frank M. schrieb:
>> Das Scannen des IRSND Signals über einen 2. µC werde ich die mal
>
>> testen...
>
>
>
> Ja, ich glaube, das bringt uns eher weiter.

Hallo Frank,

bin leider erst jetzt wieder dazu gekommen, mich mit dem Projekt zu 
beschäftigen. Mittlerweile habe ich auch gute Nachrichten. Nachdem ich 
spontan noch an ein Speicher Oszi gekommen bin, konnte ich mir die 
Signale von der FB und das vom PIC gesendete Signal mal am IR Receiver 
anschauen und musste feststellen, dass die Abweichung der beiden Signale 
bei 1-10µs lag. Um's kurz zu machen, es lag einfach am Winkel, aus dem 
ich zum TV/Receiver gesendet hab. Mit der Original FB ging das zwar, 
aber nicht mit dem PIC. Hätte ich mal lieber gleich ein längeres Kabel 
für die IR Diode genommen, dann hätte ich uns ne Menge Zeit/Nerven 
gespart. Aber nochmal vielen vielen Dank für deine Unterstützung.

Gruß
Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian schrieb:
> Hätte ich mal lieber gleich ein längeres Kabel
> für die IR Diode genommen, dann hätte ich uns ne Menge Zeit/Nerven
> gespart.

Welchen Basiswiderstand verwendest Du am Transistor vor der IR-Diode? 
Ich bin erst kürzlich darauf gekommen, dass 4,7K (so wie im IRMP-Artikel 
im Schaltbild zu sehen) eventuell etwas hoch sind. Vielleicht wäre 1K 
besser, um so die Reichweite zu erhöhen.

Gruß,

Frank

[Phil M. (Gast)]

Hey Community,

Bin vor Kurzem auf IRMP gestoßen, sofort alle Bauteile besorgt und aufs 
Steckbrett gepackt!
Super Arbeit! Nur leider will das ganze nicht bei mir ;-)
Verwende einen atmega168, einen TSOP 4836 und 2x 10 µF Elkos in Reihe, 
somit 5µF.
Habe durch LED Test herausgefunden, dass irmp_get_data immer 0 
zurückliefert, also kein Protokoll erkannt wird...
Ich habe es mit ner Sony, Bose, Epson und Telsky Fernbedienung 
probiert... leider alles tot.
Habe zusätzlich jetzt UART_Logging eingeschaltet, (vorher mit Testcode 
geguckt, ob die Verbindung funktioniert) nur leider liefert dieser in 
sehr unregelmäßigen Abständen (ca. 30 sek bis 1 min.) "trash". Bild habe 
ich angefügt.
UART derzeit nur mit Epson und Telsky probiert, jedoch schreibt er gar 
nichts an den PC, wenn man Tasten drückt, sondern einfach so 
zwischendurch.

Würde mich sehr über eine Antwort freuen!!
Vielen Dank
Gruß Phil

[Michael H. (michael_h45)]

Phil M. schrieb:
> Elkos in Reihe
Wirklich? In Reihe?


CLKDIV8 Fuse?

[Phil M. (Gast)]

Hey Michael,

Ich wollte eigentlich heute die passenden 4.7 uF Elkos holen, hab mich 
aber leider vergriffen und 47 uF geholt... solange verwende ich 2 Elkos 
10uF in Reihe, um die Kapazität zu halbieren. Ist da ein Denkfehler?

CLKDIV8 Fuse ist nicht gesetzt, ich habe einen externen 16 MHz Quarz mit 
22pF Kondensatoren als Taktgeber, mit derselben Schaltung funktioniert 
ja auch der UART Testcode, somit kann es schlecht am Timing liegen.

Ich habe in dem IRMP Code nur einen Hinweis auf 9600 Baud gefunden, 
nichts über Stop Bit und co.
Deshalb habe ich standartmäßig 1 stop bit, no parity und no flow control 
gewählt... ist das richtig?

Außerdem habe ich noch über den includes in der main.c die Taktfrequenz 
mit F_CPU 16000000UL angegeben.

Vielen Dank für die überaus schnelle Antwort!
Gruß Phil

[Michael H. (michael_h45)]

Phil M. schrieb:
> 10uF in Reihe, um die Kapazität zu halbieren. Ist da ein Denkfehler?
Aah, alles klar! Ich dachte, du hättest die in Reihe zur Versorgung!
Du kannst auch 47uF parallel schalten, das ist überhaupt kein Problem - 
im Gegenteil, es verbessert die Tiefpass- und Versorgungscharakteristig.
Die 4,7uF aus einem Datenblatt sind ein Minimalwert oder Richtangabe.

> ja auch der UART Testcode, somit kann es schlecht am Timing liegen.
stimmt.

> Deshalb habe ich standartmäßig 1 stop bit, no parity und no flow control
> gewählt... ist das richtig?
ja.

> Außerdem habe ich noch über den includes in der main.c die Taktfrequenz
> mit F_CPU 16000000UL angegeben.
Ob das UL-aftertag nötig ist, oder nicht, kann ich dir auf die Schnelle 
nicht sagen. Aber probiers doch mal ohne aus.


Kriegst du warnings beim Compilerlauf?

[Phil M. (Gast)]

Ich bekomme Warnings vom Compiler, wenn ich die F_CPU nicht einfüge.
Dann meckert nämlich delay.h (die ich im projekt nirgendwo gebraucht 
sehe), dass kein Takt angegeben ist und nimmt dann 1 MHz.
Deshalb habe ich das gleich eingefügt
Sonst keine weiteren Warnings!
PS: Mit den 47 uF wirds derzeit auch noch nicht besser ;-)

Gruß Phil

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:

> Verwende einen atmega168, einen TSOP 4836 und 2x 10 µF Elkos in Reihe,
> somit 5µF.

Sind auch 100nF zwischen Vcc und GND bzw. zwischen AVcc und GND?

Kommt dieser "Trash" einfach so? Oder wenn Du auf eine Taste der 
Fernbedienung drückst

> UART derzeit nur mit Epson und Telsky probiert, jedoch schreibt er gar
> nichts an den PC, wenn man Tasten drückt, sondern einfach so
> zwischendurch.

Zeige bitte Dein Programm und sämtliche Fuse-Einstellungen. Das sieht 
für mich so aus, als ob der µC nicht mit den gewünschten 16MHz läuft.

Phil M. schrieb:
> Ich bekomme Warnings vom Compiler, wenn ich die F_CPU nicht einfüge.

Sorge dafür, dass F_CPU in allen .c-Dateien zur Verfügung steht. Das 
geht am einfachsten, wenn Du F_CPU in Deiner IDE einstellst bzw. Du 
F_CPU im Makefile angibst.

Gruß,

Frank

[Phil M. (Gast)]

Frank M. schrieb:
> Sind auch 100nF zwischen Vcc und GND bzw. zwischen AVcc und GND?

Die Entstörkondensatoren sind vorhanden.

Frank M. schrieb:
> Kommt dieser "Trash" einfach so? Oder wenn Du auf eine Taste der
> Fernbedienung drückst

Dieser "Trash" kam bei den ersten 2 Testläufen unabhängig von der 
Fernbedienung. Hatte das Logging nebenher laufen und auf einmal tauchte 
es auf...danach habe ich es gar nicht mehr gesehen, UART war tot.

Frank M. schrieb:
> Zeige bitte Dein Programm

#define F_CPU 16000000
#include "irmp.h"

#ifndef F_CPU
#error F_CPU unkown
#endif

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

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

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

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

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Timer 1 output compare A interrupt service routine, called every 1/15000 sec
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifdef TIM1_COMPA_vect                                                      // ATtiny84
ISR(TIM1_COMPA_vect)
#else
ISR(TIMER1_COMPA_vect)
#endif
{
  (void) irmp_ISR();                                                        // call irmp ISR
  // call other timer interrupt routines...
}

int
main (void)
{
  DDRC = 0xFF;
    IRMP_DATA irmp_data;
    irmp_init();                                                            // initialize irmp
    timer1_init();                                                        // initialize timer 1
    sei ();                                                                 // enable interrupts

    for (;;)
    {
    //PORTC = irmp_data.flags;
    PORTC |= 0x01; //Status LED
        if (irmp_get_data (&irmp_data))
        {
            // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir sender
            // irmp_data.command is the command code
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
      PORTC = irmp_data.flags;
        }
    }
}

Frank M. schrieb:
> und sämtliche Fuse-Einstellungen.

Bild im Anhang.

Frank M. schrieb:
> Sorge dafür, dass F_CPU in allen .c-Dateien zur Verfügung steht. Das
> geht am einfachsten, wenn Du F_CPU in Deiner IDE einstellst

Ich verwende AVR-Studio 5.1 /Atmel Studio 6.
In beiden habe ich schon lange gesucht und keine Einstellung für die 
Taktfrequenz wie in AVR studio 4 gefunden.

Vielen Dank für die schnelle Hilfe!

Gruß Phil

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:
> Die Entstörkondensatoren sind vorhanden.

Gut.

Hast Du beachtet, dass der TSOP4836 ein anderes Pinout als z.B. ein 
TSOP1736 hat?

Beim TSOP4836 ist:

1 Out
2 GND
3 Vs

>   DDRC = 0xFF;

Port C komplett auf Ausgang?
Wo hängt denn Dein TSOP dran?
Hast Du F_CPU auch in irmp.c gesetzt?

Schreibe mal statt

#define F_CPU 16000000

besser

#define F_CPU 16000000UL

oder besser: trage es ins Projekt ein (s. weiter unten).

Kannst Du mal Deine irmpconfig.h zeigen?

> Bild im Anhang.

Scheint laut http://www.engbedded.com/fusecalc/ in Ordnung zu sein.

> Ich verwende AVR-Studio 5.1 /Atmel Studio 6.
> In beiden habe ich schon lange gesucht und keine Einstellung für die
> Taktfrequenz wie in AVR studio 4 gefunden.

Die Forumssuche nach "AVRStudio F_CPU" wirft jede Menge Treffer, z.B. 
diesen Link:

Beitrag "Re: define F_CPU in AVR Studio 5, nur wo?"

Gruß,

Frank

[Phil M. (Gast)]

Frank M. schrieb:
> Hast Du beachtet, dass der TSOP4836 ein anderes Pinout als z.B. ein
> TSOP1736 hat?

Jo ;-)

Frank M. schrieb:
> Port C komplett auf Ausgang?
> Wo hängt denn Dein TSOP dran?

TSOP hängt an B1, siehe irmp_config.
PortC auf Ausgang, da ich darüber die Flags darstellen wollte zum Test. 
klappt aber nicht. Nur die eine Status LED leuchtet

Frank M. schrieb:
> Kannst Du mal Deine irmpconfig.h zeigen?

#ifndef _IRMPCONFIG_H_
#define _IRMPCONFIG_H_

#ifndef _IRMP_H_
#  error please include only irmp.h, not irmpconfig.h
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change F_INTERRUPTS if you change the number of interrupts per second,
 * Normally, F_INTERRUPTS should be in the range from 10000 to 15000, typical is 15000
 * A value above 15000 costs additional program space, absolute maximum value is 20000.
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifndef F_INTERRUPTS
#  define F_INTERRUPTS                          15000   // interrupts per second, min: 10000, max: 20000, typ: 15000
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change settings from 1 to 0 if you want to disable one or more decoders.
 * This saves program space.
 *
 * 1 enable  decoder
 * 0 disable decoder
 *
 * The standard decoders are enabled per default.
 * Less common protocols are disabled here, you need to enable them manually.
 *
 * If you want to use FDC or RCCAR simultaneous with RC5 protocol, additional program space is required.
 * If you don't need RC5 when using FDC/RCCAR, you should disable RC5.
 * You cannot enable both DENON and RUWIDO, only enable one of them.
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */

// typical protocols, disable here!             Enable  Remarks                 F_INTERRUPTS            Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL             1       // Sony SIRCS           >= 10000                 ~150 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL               1       // NEC + APPLE          >= 10000                 ~300 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL           1       // Samsung + Samsung32  >= 10000                 ~300 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL        1       // Matsushita           >= 10000                  ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL          1       // Kaseikyo             >= 10000                 ~250 bytes
#define IRMP_SUPPORT_DENON_PROTOCOL             1       // DENON, Sharp         >= 10000                 ~250 bytes

// more protocols, enable here!                 Enable  Remarks                 F_INTERRUPTS            Program Space
#define IRMP_SUPPORT_RC5_PROTOCOL               0       // RC5                  >= 10000                 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL               0       // RC6 & RC6A           >= 10000                 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL               0       // JVC                  >= 10000                 ~150 bytes
#define IRMP_SUPPORT_NEC16_PROTOCOL             0       // NEC16                >= 10000                 ~100 bytes
#define IRMP_SUPPORT_NEC42_PROTOCOL             0       // NEC42                >= 10000                 ~300 bytes
#define IRMP_SUPPORT_IR60_PROTOCOL              0       // IR60 (SDA2008)       >= 10000                 ~300 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL           0       // Grundig              >= 10000                 ~300 bytes
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // Siemens Gigaset      >= 15000                 ~550 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL             0       // Nokia                >= 10000                 ~300 bytes

// exotic protocols, enable here!               Enable  Remarks                 F_INTERRUPTS            Program Space
#define IRMP_SUPPORT_KATHREIN_PROTOCOL          0       // Kathrein             >= 10000                 ~200 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL            0       // NUBERT               >= 10000                  ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL      0       // Bang & Olufsen       >= 10000                 ~200 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL            0       // RECS80 (SAA3004)     >= 15000                  ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL         0       // RECS80EXT (SAA3008)  >= 15000                  ~50 bytes
#define IRMP_SUPPORT_THOMSON_PROTOCOL           0       // Thomson              >= 10000                 ~250 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL             0       // NIKON camera         >= 10000                 ~250 bytes
#define IRMP_SUPPORT_NETBOX_PROTOCOL            0       // Netbox keyboard      >= 10000                 ~400 bytes (PROTOTYPE!)
#define IRMP_SUPPORT_FDC_PROTOCOL               0       // FDC3402 keyboard     >= 10000 (better 15000)  ~150 bytes (~400 in combination with RC5)
#define IRMP_SUPPORT_RCCAR_PROTOCOL             0       // RC Car               >= 10000 (better 15000)  ~150 bytes (~500 in combination with RC5)
#define IRMP_SUPPORT_RUWIDO_PROTOCOL            0       // RUWIDO, T-Home       >= 15000                 ~550 bytes
#define IRMP_SUPPORT_LEGO_PROTOCOL              0       // LEGO Power RC        >= 20000                 ~150 bytes

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here for ATMEL AVR
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#if defined (ATMEL_AVR)                                                 // use PB6 as IR input on AVR
#  define IRMP_PORT_LETTER                      B
#  define IRMP_BIT_NUMBER                       1

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here for PIC C18 compiler
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#elif defined (PIC_C18)                                                 // use RB4 as IR input on PIC
#  define IRMP_PIN                              PORTBbits.RB4

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here for PIC CCS compiler
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#elif defined (PIC_CCS)
#  define IRMP_PIN                              PIN_B4                  // use PB4 as IR input on PIC

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here for ARM STM32
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#elif defined (ARM_STM32)                                               // use C13 as IR input on STM32
#  define IRMP_PORT_LETTER                      C
#  define IRMP_BIT_NUMBER                       13

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Handling of unknown target system: DON'T CHANGE
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#elif !defined (UNIX_OR_WINDOWS)
#  error target system not defined.
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Set IRMP_LOGGING to 1 if want to log data to UART with 9600Bd
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifndef IRMP_LOGGING
#  define IRMP_LOGGING                          1       // 1: log IR signal (scan), 0: do not. default is 0
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Use external logging routines
 * If you enable external logging, you have also to enable IRMP_LOGGING above
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifndef IRMP_EXT_LOGGING
#  define IRMP_EXT_LOGGING                      0       // 1: use external logging, 0: do not. default is 0
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Set IRMP_PROTOCOL_NAMES to 1 if want to access protocol names (for logging etc), costs ~300 bytes RAM!
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifndef IRMP_PROTOCOL_NAMES
#  define IRMP_PROTOCOL_NAMES                   0       // 1: access protocol names, 0: do not. default is 0
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Use Callbacks to indicate input signal
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#ifndef IRMP_USE_CALLBACK
#  define IRMP_USE_CALLBACK                     0       // 1: use callbacks. 0: do not. default is 0
#endif

#endif /* _WC_IRMPCONFIG_H_ */

Frank M. schrieb:
> oder besser: trage es ins Projekt ein (s. weiter unten).

habe es im Projekt als "F_CPU=16000000UL" eingetragen.
Hat er auch angenommen, da delay.h nicht meckert.
Ich werde gleich testen, obs klappt.

Vielen Dank!
Gruß Phil

[Phil M. (Gast)]

Statusbericht:

Habe F_CPU jetzt im Projekt global eingetragen.
Leider meldet sich der µC immer noch nicht zu Wort.
Die Status LED lässt er leuchten, woran man erkennen kann, dass der µC 
arbeitet.
über UART ist der controller immer noch tot, auch kein "trash" kommt.
Ich habe den code ja so geschrieben, dass eigentlich mehrere LEDs 
angehen (irmp_flags) sollten, soblad ein Protokoll erkannt wurde.

if (irmp_get_data (&irmp_data))
        {
            // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir sender
            // irmp_data.command is the command code
            // irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
      PORTC = irmp_data.flags;
        }

Leider klappt dies nicht.

Vielen Dank!

Gruß Phil

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:
> über UART ist der controller immer noch tot, auch kein "trash" kommt.
> Ich habe den code ja so geschrieben, dass eigentlich mehrere LEDs
> angehen (irmp_flags) sollten, soblad ein Protokoll erkannt wurde.

irmp_flags ist entweder 0 (keine Wiederholung) oder 1 (Wiederholung). Da 
Du sowieso immer das Bit 0 in der Endlosschleife anschaltest, wirst Du 
da kaum was sehen, denn die anderen Bits werden durch die flags sowieso 
nicht gesetzt.

Besser wäre so etwas:

    for (;;)
    {
        PORTC |= 0x01; //Status LED

        if (irmp_get_data (&irmp_data))
        {
            PORTC = 0xFF;
            _delay_ms (1000);
            PORTC = 0x00;
        }
    }

Dann sollten alle LEDs am PORTC für eine Sekunde leuchten, sobald IRMP 
etwas erkannt hat.

Gruß,

Frank

[Phil M. (Gast)]

Hey Frank!

Habe den Port von PB1 auf PB0 geändert.
An diesem funktioniert es!!
Ich möchte euch allen hier aus dem Forum sehr danken für die tollen und 
schnellen Antworten!
Werde mir jetzt auch n Konto erstellen und mal gucken, ob  ich meinen 
Beitrag auch hier leisten kann ;-)

Die Sony Fernbedienung erkennt er (alle Leds an = Protokoll erkannt), 
die Bose aber nicht.
UART funktioniert jetzt, d.h. ich kann dir ruhig n scan von der bose 
schicken, wenn du noch keinen hast.

Vielen Dank nochmal!

L.G. Phil

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:
> Habe den Port von PB1 auf PB0 geändert.
> An diesem funktioniert es!!

Sehr merkwürdig.... habe keine Erklärung dafür.
Trotzdem Gratulation :)

> UART funktioniert jetzt, d.h. ich kann dir ruhig n scan von der bose
> schicken, wenn du noch keinen hast.

Kannst Du gern machen. Bitte zumindest Scans von den Tasten 0-9 schicken 
- je mehr, desto besser. Das Format einer Scan-Datei kannst Du Dir in 
den Dateien unter IR-Data anschauen - simple Text-Datei mit Kommentaren, 
eingeleitet durch '#'.

Gruß,

Frank

[Phil M. (Gast)]

Habe eben gemerkt, dass der TSOP die ganze Zeit an PB0 angeschlossen 
war, und es eben auf PB1 eingestellt war. Sowas ist echt peinlich...

Anbei der Bose-Scan. Dies ist nur eine Radio-Fernbedienung mit Tasten 
1-6, deshalb hab ich noch Play, Eject und Power On hinzugefügt.

http://c0021679.cdn1.cloudfiles.rackspacecloud.com/BoseWaveMusicSystem_remote.jpg

Vielen Dank!

Gruß Phil

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:
> Habe eben gemerkt, dass der TSOP die ganze Zeit an PB0 angeschlossen
> war, und es eben auf PB1 eingestellt war. Sowas ist echt peinlich...

Dafür müsstest Du eigentlich ein Bier ausgeben ;-)

> Anbei der Bose-Scan. Dies ist nur eine Radio-Fernbedienung mit Tasten
> 1-6, deshalb hab ich noch Play, Eject und Power On hinzugefügt.

Danke, schaue ich mir an.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Phil M. schrieb:
> Anbei der Bose-Scan.

Anbei die Änderungen fürs BOSE-Protokoll.

Das war ziemlich einfach: 16 Bits, davon ist das erste Byte das Kommando 
und das zweite Byte ist einfach zwecks Fehlererkennung invertiert. IRMP 
berücksichtigt die Fehlererkennung und verwirft solche Frames 
automatisch.

Tausche einfach die 3 Dateien in der Zip-Datei aus und stelle Deine 
Pinkonfiguration neu ein. Du solltest BOSE nicht zusammen mit RC5 oder 
RUWIDO einschalten, da es hier noch Konflikte in der Erkennung gibt. 
Zumindest für RC5 werde ich die noch ausbügeln. Daher ist der Source 
erstmal hier nur zum Test.

Gruß,

Frank

EDIT:
Da ist noch ein Fehler drin:

Zeile 1211 in irmp.c:

Alt:
#if IRMP_SUPPORT_NEC_PROTOCOL == 1

Neu:
#if IRMP_SUPPORT_BOSE_PROTOCOL == 1

Sonst klappt es nur, wenn Du auch NEC enabled hast.

[Phil M. (Gast)]

Hey Frank!

Die Bose-Protokoll-Routine funktioniert, vielen Dank!

Gruß Phil

[Martin S. (drunkenmunky)]

Hallo,

ich probiere gerade IRSND auf einem PIC18 zum laufen zu bekommen.

Es kommt aber die Fehlermeldung:
Error - could not find definition of symbol 'SetDCPWM1' in file 
'./build/default/production/irsnd.o'.

In der Funktion irsnd_set_freq() wird ja OpenPWM(freq) aufgerufen. In 
der irsnd.h gibt's ja das define

 # define OpenPWM(x)                          OpenPWM1(x)

und OpenPWM1() wird ja wohl die von Microchip bereitgestellte Funktion 
von der Library in pwm.h sein, oder? Muss man die dann noch irgendwo mit 
einbinden? Hab ich schon gemacht, Fehler ist aber immer noch da...

[Martin S. (drunkenmunky)]

Servus,

also ich hab das Problem gefunden. PWM 1 bis 3 ist bei meinem Controller 
eine Enhanced PWM. Also muss man entweder normale PWM 4 nehmen oder es 
in der irsnd.h auf die Enhanced anpassen.

#  if IRSND_OCx == IRSND_PIC_CCP1        
#    define IRSND_PIN                           TRISCbits.TRISC2        // RC2 = PWM1
#    define SetDCPWM(x)                         SetDCEPWM1(x)
#    define ClosePWM                            CloseEPWM1
#    define OpenPWM(x)                          OpenEPWM1(x, ECCP_1_SEL_TMR12)
#  endif

Jetzt läuft bei mir senden und empfangen.

Klasse Projekt! Vielen Dank!

[Martin S. (drunkenmunky)]

Eine Frage hätte ich allerdings noch.

Ich habe die Fernbedienung eines Philips TV ausgelesen und es wurde als 
RC6 Code erkannt, was ja gut sein kann. Z.B. Adress = 0, Comannd = 12 
für dein Einschaltknopf. Wenn ich das aber sende, reagiert der TV nicht. 
NEC Protokoll geht ohne Problem. Habe leider auch grad kein Oszi da zum 
Messen. Bei Senden ist es egal, wenn man alle Protokolle einschaltet, 
oder?

Weiß vielleicht jemand, woran das liegen könnte?

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:
> Eine Frage hätte ich allerdings noch.
>
> Ich habe die Fernbedienung eines Philips TV ausgelesen und es wurde als
> RC6 Code erkannt, was ja gut sein kann. Z.B. Adress = 0, Comannd = 12
> für dein Einschaltknopf. Wenn ich das aber sende, reagiert der TV nicht.

Kann IRMP das gesendete Telegramm wieder dekodieren? Läuft Dein PIC mit 
Quarz? Einige kommerzielle Geräte achten sehr genau auf das Timing.

Gruß,

Frank

P.S.
Danke für die TIPs zum PIC mit der "Enhanced PWM" :-)

[Martin S. (drunkenmunky)]

Frank M. schrieb:
> Kann IRMP das gesendete Telegramm wieder dekodieren?

Sollte er das können? Habe gedacht, wenn die ISR so aufgebaut ist:

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

wird nur empfangen, wenn nicht grad gesendet wird.

Frank M. schrieb:
> Läuft Dein PIC mit Quarz?

Ich verwende den internen Oszillator, der auf 1% kalibiriert wurde und 
im Datenblatt bei einer Temperatur von 0 bis 70°C mit einer Toleranz von 
+/- 2% angegeben wird. Ich denk mit einem Quarz ist man auch nicht 
besser dran, oder?

Ich habe den Timer so eingestellt, dass alle 67us ein Interrupt kommt. 
Sollte ich dann F_INTERRUPTS besser auf 14925 statt 15000 stellen? 
Bringt es viel, wenn man mit 20 kHz arbeitet?

[Joachim B. (jar)]

Martin S. schrieb:
> Ich habe den Timer so eingestellt, dass alle 67us ein Interrupt kommt.
> Sollte ich dann F_INTERRUPTS besser auf 14925 statt 15000 stellen?

ich denke man sollte F_INTERRUPTS auf die richtige Zahl stellen, bei mir
F_CPU/Teiler, bei dir wäre ja 14925 richtig (1/67µs)

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:

> Ich verwende den internen Oszillator, der auf 1% kalibiriert wurde und
> im Datenblatt bei einer Temperatur von 0 bis 70°C mit einer Toleranz von
> +/- 2% angegeben wird. Ich denk mit einem Quarz ist man auch nicht
> besser dran, oder?

Sollte reichen.

> Ich habe den Timer so eingestellt, dass alle 67us ein Interrupt kommt.
> Sollte ich dann F_INTERRUPTS besser auf 14925 statt 15000 stellen?

Ja, solltest Du. F_INTERRUPTS sollte auf dem exakten Wert stehen. Naja, 
bei 14925 ist die Abweichung allerdings minimal.

> Bringt es viel, wenn man mit 20 kHz arbeitet?

Nein.

Noch eine andere Idee: Vielleicht stimmt die Modulationsfrequenz von 
36kHz nicht. Geh mal auf 38kHz für RC6. Suche dafür nach

            irsnd_set_freq (IRSND_FREQ_36_KHZ);

(findest Du mehrfach, z.Z. für RC6 und RC6A).

[Martin S. (drunkenmunky)]

Habe beides angepasst. Hat aber beides nicht geholfen. Da werde ich dann 
wohl mal mit einem Oszi nachmessen müssen...

Oder sonst noch Tips?

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:
> Oder sonst noch Tips?

Leider nein.

Außer Du nimmst erst mit der Original-Fernbedienung einen IRMP-Scan auf 
und anschließend nochmal mit IRMP vom IRSND-Sender. Da brauchst Du aber 
dann 2 PICs dafür.

Gruß,

Frank

[Martin S. (drunkenmunky)]

Ok, danke. Die Hardware habe ich zum Glück zwei mal. Sobald meine 
Prüfungen vorbei sind, werde ich es testen und dann berichten.

[Martin S. (drunkenmunky)]

Die Logging Funktion ist ja noch gar nicht für PIC implementiert. Mal 
sehen, ob ich noch irgendwann Zeit finde, dies zu ergänzen.

Aber den Fehler habe ich mittlerweile gefunden. Es liegt daran, dass die 
Interrupt-Routine zum senden zu lange benötigt. Es sollte ja eigentlich 
alle 67us ein Interrupt erzeugt werden, aber die Bearbeitung dauer über 
90us. Dann stimmt natürlich das ganze Timing nicht mehr. Das wundert 
mich etwas da ich schon den schnellsten PIC18 mit 16 MIPS (64 MHz) 
verwende (ohne Compileroptimierung, da Lite). Alle 100us Interrupt 
funktioniert jetzt, aber dann kann man ja nicht alle Protokolle nutzen.

Wieso wird nicht zuerst die du sendende Bitfolge berechnet und dann im 
Interrupt nur die PWM an/aus geschalten? Die Routine ist schon ganz 
schön lang...

Würde mich mal interessieren, wie andere das mit PICs bewerkstelligt 
haben. Wäre nett, wenn mal jemand von seinen Erfahrungen berichten 
würde!

[Frank M. (ukw) (Moderator)]

Martin S. schrieb:
> Die Logging Funktion ist ja noch gar nicht für PIC implementiert. Mal
> sehen, ob ich noch irgendwann Zeit finde, dies zu ergänzen.

Schau bitte mal nach in irmpextlog.c, dort ist speziell für PICs mit 
USB-Anschluss ein Logging implementiert. UART-Logging für PICs gibt es 
allerdings (noch) nicht.

> Aber den Fehler habe ich mittlerweile gefunden. Es liegt daran, dass die
> Interrupt-Routine zum senden zu lange benötigt. Es sollte ja eigentlich
> alle 67us ein Interrupt erzeugt werden, aber die Bearbeitung dauer über
> 90us. Dann stimmt natürlich das ganze Timing nicht mehr. Das wundert
> mich etwas da ich schon den schnellsten PIC18 mit 16 MIPS (64 MHz)
> verwende (ohne Compileroptimierung, da Lite). Alle 100us Interrupt
> funktioniert jetzt, aber dann kann man ja nicht alle Protokolle nutzen.

Das ist allerdings sehr merkwürdig, da das auch die ATmegas mit "nur" 8 
MHz problemlos schaffen. Die Interrupt-Routine sieht zwar lang aus, ist 
aber ein Zustandsautomat, wo nur wenige Befehle pro ISR-Aufruf 
abgearbeitet werden. Ausserdem wird sehr wohl das Muster, das gesandt 
werden muss, außerhalb der ISR vor dem eigentlichen Senden 
"zusammengebaut". Ich kann mir das nur so erklären, dass irgendein 
Code-Abschnitt in der ISR nicht optimal übersetzt wird. Da müsste man 
sich das Assembler-Listing, das vom C-Compiler erzeugt wird, mal näher 
unter die Lupe nehmen...

> Wieso wird nicht zuerst die du sendende Bitfolge berechnet und dann im
> Interrupt nur die PWM an/aus geschalten? Die Routine ist schon ganz
> schön lang...

Wie gesagt, die Bitfolge wird bereits in irsnd_send_data() vor dem 
Senden und nicht in der ISR berechnet. Vielleicht könnte man aber noch 
den großen Case-Switch, wo vor dem Absenden des Start-Bits die 
jeweiligen Puls-/Pause-Längen gesetzt werden, noch rausziehen und vorab 
machen. Aber das wird nicht die Ursache sein, da dies nur 1x pro Frame 
passiert. Hier liegt etwas ganz anderes (PIC-spezifisches?) im Argen. 
Wäre prima, wenn Du mal einen Blick in den produzierten Assembler-Output 
des Compilers werfen könntest.

Gruß,

Frank

[Bernhard M. (boregard)]

Hallo,

vielleicht erzeugt derCompiler ja "lahmen" Code, da, Zitat "(ohne 
Compileroptimierung, da Lite)"

Gruß,
Bernhard

[Joachim B. (jar)]

Frage, hat einer Quellen für Service Codes ?

es gibt für Panasonic HD Recorder (Kaseikyio) eine Service FB die
DVD/HD Recorder Ländercode free schaltet, man kann die kaufen, wäre aber 
ziemlich Unfug wenn man die nur einmalig braucht und hier jedem hier 
IR-SND zur Verfügung steht

Irgendwie müsste mal ein Code Sammlung entstehen so das man auch ohne 
OriginalFB alles nachgebildet werden kann.

was meint ihr ?

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> Frage, hat einer Quellen für Service Codes ?

Eine Möglichkeit, "undokumentierte" Befehle herauszubekommen, ist, sich 
eine Tabelle anzulegen, welche Kommandos die herkömmliche FB sendet und 
dann gezielt per IRSND die "Lücken", also nicht-verwendete 
Kommando-Codes auszuprobieren. Bei irgendeinem wird das Gerät dann schon 
reagieren ;-)

[Joachim B. (jar)]

Frank M. schrieb:
> welche Kommandos die herkömmliche FB sendet und
> dann gezielt per IRSND die "Lücken", also nicht-verwendete
> Kommando-Codes auszuprobieren.

ziemlich aussichtslos bei

drücke 6 warte 10s drücke Taste Service Menü usw.

ich kann keine Kombination aus nicht vorhandenen Tasten in Verbindung 
mit Sequenzen und Zwischenzeiten probieren.

ich versuche mal so eine Service FB zu bekommen

es gab mal IRDEO wo an der seriellen PC Schnitte .....

evt. gehts ja damit ? (Bytefolgen)
0082 0015 0089 0004 00F2 0033 0017 0010 0091 0013

mal probieren

[Maik (Gast)]

Hallo,
ich versuche gerade das Signal einer Lego IR zu empfangen.
Leider funktioniert die Erkennung des Startpulses nicht.

Der erste Puls passt einfach nicht in die Tolleranz.
Ich verwende einen SFH505A mit tON=100uS and tOFF=200us.

Wenn ich das Signal mit einem Logic Analyzer betrachte,
dann geht das IR Signal zuerst für 505uS auf Low und ist dann
für 710uS auf High. Die gesamte Impulslänge ist dann 1215uS.

Mann könnte doch tON und tOFF in der Software rausrechnen!
Wird das gemacht?

Wie wird mit diesem Fehler umgegangen?

Danke

Maik

[Frank M. (ukw) (Moderator)]

Maik schrieb:

> ich versuche gerade das Signal einer Lego IR zu empfangen.
> Leider funktioniert die Erkennung des Startpulses nicht.

Kannst Du Scans erstellen und hier einstellen? Dann schaue ich es mir 
an.

> Mann könnte doch tON und tOFF in der Software rausrechnen!
> Wird das gemacht?

Das wird nicht gemacht, da ich bisher davon ausging, dass die 
IR-Empfänger ein zeitrichtiges Signal ausgeben.

> Wie wird mit diesem Fehler umgegangen?

Momentan gar nicht.

Gruß,

Frank

[Konrad S. (maybee)]

@Frank M.

Ich habe eben IRMP (Danke für diese Super-Software!) auf einem Arduino 
verwendet. Im Abschnitt für das IRMP_KASEIKYO_PROTOCOL musste ich die 
lokale Variable "xor" umbenennen, das scheint bei Arduino ein 
reservierter Bezeichner zu sein.

Version IRMP:  2.2.2 25.05.2012
 * $Id: irmp.c,v 1.123 2012/05/24 08:16:28 fm Exp $

[Frank M. (ukw) (Moderator)]

Konrad S. schrieb:
> Ich habe eben IRMP (Danke für diese Super-Software!) auf einem Arduino
> verwendet. Im Abschnitt für das IRMP_KASEIKYO_PROTOCOL musste ich die
> lokale Variable "xor" umbenennen, das scheint bei Arduino ein
> reservierter Bezeichner zu sein.

Danke, ich habe "xor" in "xor_value" umbenannt - sowohl in irmp.c als 
auch in irsnd.c. Kommt mit dem nächsten Release.

Gruß,

Frank

[Carsten Presser (Gast)]

Hi,

ich hab ein Protokoll gefunden das ich nicht identifizieren kann.
Im Anhang ein Foto vom Oszi (hab leider kein Hardcopy) vom Anfang der 
Sequenz.
Die Fernbedienung gehört zu einer Dreambox-8000.

'Abgeschrieben' ergibt sich folgende Puls-Pause-Folge
Puls 320
Pause 1000
Puls 320
Pause 2000
Puls 320
Pause 1000
Puls 320
Pause 2760 (!?)
Puls 320
Pause 1000
Puls 320
Pause 1000
Puls 320
Pause 800 (!?)
Puls 320
Pause 2000
Puls 320
Pause 12920 (!?)
Puls 320
Pause 1000
Puls 320
Pause 2360 (Taste0) ...  1000 (Taste9) als zwischenwert: 5->1640, 
3->1900, 7->1360


Interessant ist das in dem zweite Block (nach der 12ms-Pause) die Pausen 
unterschiedliche Längen haben je nachdem welche Taste gedrückt wird.
Die Pausen-Länge skaliert auch mit dem Wert der Taste (also 0-9).

Das ganze scheint also nicht 'diskret' kodiert zu sein.

vllt. hat hier ja jemand eine Idee was das für ein Proto ist :)

[Frank M. (ukw) (Moderator)]

Carsten Presser schrieb:
> Die Fernbedienung gehört zu einer Dreambox-8000.

Tut mir leid, die Dreambox-FB wird nicht von IRMP unterstützt. Das 
Protokoll ist leider ziemlich kompliziert und weicht von den 
Standard-Protokollen so weit ab, dass für diese Fernbedienung besser ein 
eigener spezieller Decoder geschrieben werden müsste. Das 
Dreambox-Protokoll passt einfach schlecht bis gar nicht zum Konzept des 
IRMP.

Mich persönlich ärgert das auch, denn ich habe ebenso eine Dreambox in 
meinem Wohnzimmer.

[Carsten Presser (Gast)]

Frank M. schrieb:
> Tut mir leid, die Dreambox-FB wird nicht von IRMP unterstützt. Das
> Protokoll ist leider ziemlich kompliziert und weicht von den
> Standard-Protokollen so weit ab, dass für diese Fernbedienung besser ein
> eigener spezieller Decoder geschrieben werden müsste.

Gibts es denn irgendwo Doku zu dem Protokoll? Oder mal ein Name?
So wirklich viel hat Googeln mir zu dem Thema bisher nicht gebracht.

Ich hab schon nen eigenen Decoder (keinen so schönen wie deiner), der 
aber dank einer Auflösung von 0.3us das Protokoll schaffen sollte :)
Ich dachte nur, ich frage mal hier nach, weil sich in im Thread viele 
Leute aufhalten die viel Ahnung von IR-Protokollen haben.

[jar (Gast)]

Frank M. schrieb:
> Tut mir leid, die Dreambox-FB wird nicht von IRMP unterstützt. Das
> Protokoll ist leider ziemlich kompliziert und weicht von den
> Standard-Protokollen so weit ab, dass für diese Fernbedienung besser ein
> eigener spezieller Decoder geschrieben werden müsste. Das
> Dreambox-Protokoll passt einfach schlecht bis gar nicht zum Konzept des
> IRMP.

und ein eigener ist nicht möglich ? so nachgeschaltet ?

Carsten Presser schrieb:
> Ich hab schon nen eigenen Decoder (keinen so schönen wie deiner), der
> aber dank einer Auflösung von 0.3us das Protokoll schaffen sollte :)
> Ich dachte nur, ich frage mal hier nach, weil sich in im Thread viele
> Leute aufhalten die viel Ahnung von IR-Protokollen haben.

momentan behelfe ich mich ja mit IRMP vor RC5 Dannegger

also wenn der Interrupt kommt, hüpf ich erst in die IRMP und gleich 
danach in die RC5, so habe ich alle IRMP Protokolle zum auswerten, sowie 
Programmkompatiblität mit meiner FB wegen toogle Bit, ich weiss Frank 
das sollte auch mit IRMP gehen, aber bis jetzt läufts so ohne weitere 
Versuche, wenn ich Zeit finde werde ich mein Problem mit dem toogle Bit 
angehen

ich denke evt. wäre eine eigene Dekoderroutine nach IRMP auch hier 
möglich, die dann eben das gewünschte hinter IRMP (wenn das weiterhin 
gebraucht wird) dekodiert.

[Frank M. (ukw) (Moderator)]

Carsten Presser schrieb:
> Gibts es denn irgendwo Doku zu dem Protokoll? Oder mal ein Name?
> So wirklich viel hat Googeln mir zu dem Thema bisher nicht gebracht.

Schau Dir mal

 Beitrag "Re: Dreambox mit RC5 "bedienen""

an. Einige behaupten, das Protokoll heisst TWIRP, andere sagen, es wäre 
XMP-1. Ich tippe auf letzteres, wenn ich mir diverse IRMP-Scanlogs von 
Dreambox-FBs anschaue.

Wenn man sich anstrengt beim Googlen, findet man über XMP-1 schon 
diverse Dokumentationen bzw. Schnippselchen. Leider habe ich mir die 
Links nicht explizit gemerkt, dass ich sie jetzt hier aufführen konnte. 
Jedenfalls kam ich damals zu dem Schluss, dass man XMP-1 mittels IRMP 
schlecht bis gar nicht "einfangen" kann.

Gruß,

Frank

[martin (Gast)]

Hallo

Ich habe einen Verstärker mit IR-in an dem bei IR-Bedienung ein 
IR-Singnal anliegt. Ich möchte nun mit einem µC den Verstärker steuern. 
Beitrag "IR-IN des Hifi-Verstärkers per µC ansteuern"

Ich verwende einen Atmega32 auf einem Board mit 8MHz Quarz. USB ISP 
Programmer ist vorhanden.

Ich habe mir das Projekt IRSND mal ins AtmelStudio geladen, leider 
kämpfe ich noch mit ein paar noobsachen.

Ohne Änderungen des Codes kommen bei mir Fehler:
#warning "F_CPU not defined for <util/delay.h>"
#error mikrocontroller not defined, please fill in definitions here.


1.) Wo kann ich die Frequenz jetzt einstellen?
 - Im AtmelStudio selbst?
 - Aber sie ist doch schon in den Fusebits definiert?!
 - Wo und wie im code?

2.) Brauche ich noch ein Hauptprogramm oder werfe ich meinen Teil in 
irsndmain.c ganz unten ran?

3.) Wo genau in den files und wie wird der Controller  definiert?

Ich habe schon gesehen dass Frank sehr viel Zeit in sein Projekt 
gesteckt hat, und das mit Erfolg! Vielleicht gibts einen Kenner hier der 
einem Anfänger wie mir weiterhelfen kann.

[Frank M. (ukw) (Moderator)]

martin schrieb:

> Ich habe mir das Projekt IRSND mal ins AtmelStudio geladen, leider
> kämpfe ich noch mit ein paar noobsachen.

Welche Studio-Version? 4, 5 oder 6?

> Ohne Änderungen des Codes kommen bei mir Fehler:
> #warning "F_CPU not defined for <util/delay.h>"
> #error mikrocontroller not defined, please fill in definitions here.

> 1.) Wo kann ich die Frequenz jetzt einstellen?
>  - Im AtmelStudio selbst?

Ja, Du musst F_CPU=8000000UL oder einen adäquaten Wert im Projekt 
einstellen.

>  - Aber sie ist doch schon in den Fusebits definiert?!

Nein, da sagst Du nur, ob Du einen Quarz verwendest und in welchem 
Frquenzbereich.

>  - Wo und wie im code?

Sie oben: im Projekt selber. Wenn Du nicht weisst, google einfach mal 
nach AVR Studio F_CPU einstellen.

> 2.) Brauche ich noch ein Hauptprogramm oder werfe ich meinen Teil in
> irsndmain.c ganz unten ran?

irsndmain ist nur ein Beispiel. Es kommt natürlich darauf an, was Du 
machen willst. IRMP und IRSND sind lediglich Bibliotheken zur Einbindung 
in eigene Anwendungen.

> 3.) Wo genau in den files und wie wird der Controller  definiert?

Du stellst Im AVR Studio das Target, d.h. den µC ein. Offenbar hast Du 
da gar nicht ATmega32 eingestellt.

Gruß,

Frank

[martin (Gast)]

Hallo und vielen Dank für die Antworten, haben mir sehr weitergeholfen.

Ich bin auf eclipse umgestiegen, da ich mit AtmelStudio nicht mehr 
weiterkam.
Das hakte dann einen Tag, und schließlich lief es dann.

Jetzt möchte ich noch wissen was ich ändern muss damit er nicht auf den 
Träger aufmoduliert, sondern das "normale" Signal rauswirft.

zitat:
Um nun mittels IRSND zu senden, musst Du lediglich die
Modulationsfunktion deaktivieren, so dass keine Frequenz, sondern ein
LOW-Signal erzeugt wird.

[Frank M. (ukw) (Moderator)]

martin schrieb:

> Jetzt möchte ich noch wissen was ich ändern muss damit er nicht auf den
> Träger aufmoduliert, sondern das "normale" Signal rauswirft.

Ersetze die Funktionen irsnd_off(), irsnd_on(), irsnd_set_freq() und 
irsnd_init() durch folgende:

static void
irsnd_on (void)
{
    if (! irsnd_is_on)
    {
        HIER PORT-PIN AUF LOW!

#if IRSND_USE_CALLBACK == 1
        if (irsnd_callback_ptr)
        {
            (*irsnd_callback_ptr) (TRUE);
        }
#endif // IRSND_USE_CALLBACK == 1

        irsnd_is_on = TRUE;
    }
}

static void
irsnd_off (void)
{
    if (irsnd_is_on)
    {
        HIER PORT-PIN AUF HIGH!

#if IRSND_USE_CALLBACK == 1
        if (irsnd_callback_ptr)
        {
           (*irsnd_callback_ptr) (FALSE);
        }
#endif // IRSND_USE_CALLBACK == 1

        irsnd_is_on = FALSE;
    }
}

static void
irsnd_set_freq (IRSND_FREQ_TYPE freq)
{
    return;
}

void
irsnd_init (void)
{
    HIER PORT-PIN AUF OUTPUT und auf HIGH!
}

Gruß,

Frank

[martin (Gast)]

Guter Frank, bitte hilf mir noch einmal. :)

HIER PORT-PIN AUF OUTPUT und auf HIGH!
HIER PORT-PIN AUF LOW!

(ich verwende OC0 )

[Michael H. (michael_h45)]

Ach bitte, du wirst doch wohl einen Pin setzen können!?

[martin (Gast)]

Stimmt das so?

HIER PORT-PIN AUF OUTPUT und auf HIGH!

DDRB |= (1 << DDB3);  //PB3 auf Ausgang
DDRB =(1 << DDB3);  //PB3 auf 1



HIER PORT-PIN AUF LOW!

DDRB =(0 << DDB3);       //PB3 auf 0

[Chris (Gast)]

Grundlagen:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Ausg.C3.A4nge

[martin (Gast)]

Ich hab mir vor einiger Zeit schon den Kopf über folgende Syntax 
zerbrochen:

(1 << n) : Zuerst wird durch die '<<'-Ausdrücke eine "1" n-mal nach 
links geschoben

und dann:
DDRB =(1 << DDB3);

Meine interpretation: Es wird "DDB3" mal eine 1 nach links geschoben.
?

Ok ich hab da was mit dem verwechselt mit DDRB und PORTB, richtig müsste 
der Code also lauten:

//HIER PORT-PIN AUF OUTPUT und auf HIGH!:
DDRB |= (1 << DDB3);  //PB3 auf Ausgang
PORTB=(1<<PB3);  //PB3 auf 1


//HIER PORT-PIN AUF LOW!:
PORTB &= ~(1<<PB3); //PB3 auf 0