Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

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

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

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

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

hier müsstest du erweitern:

1

#elif defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__)  // ATtiny45/85 uses OC0A = PB0 or OC0B = PB1

2

#if IRSND_OCx == IRSND_OC0A                             // OC0A

3

#define IRSND_PORT                              PORTB   // port B

4

#define IRSND_DDR                               DDRB    // ddr B

5

#define IRSND_BIT                               0       // OC0A

6

#elif IRSND_OCx == IRSND_OC0B                           // OC0B

7

#define IRSND_PORT                              PORTB   // port B

8

#define IRSND_DDR                               DDRB    // ddr B

9

#define IRSND_BIT                               1       // OC0B

mit || defined (_AVR_ATtiny88_)

1

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

und

1

#elif IRSND_OCx == IRSND_OC1A                           // OC1A

2

#define IRSND_PORT                              PORTB   // port B

3

#define IRSND_DDR                               DDRB    // ddr B

4

#define IRSND_BIT                               1       // OC0B

wenn ich das Datenblatt richtig gelesen hatte

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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.

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

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

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

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

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

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

Hallo Frank,

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

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

1

Ausgabe:

2

00000000000000000000000000000000000000001111111111110000000111111100000001111111000000011111111111111000000011111111111111000000000000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000000000001111111000000011111111111111000000000000001111111111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000000000000111111111111110000000111111100000001111111000000011111110000000111111100000001111111000000000000001111111111111111111111111111

3

4

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

5

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

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

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

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

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

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

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

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,

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

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

Darf das IRMP auch kommerziell genutzt werden?

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

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:

1

    for (VCount=0; VCount<=7; VCount++)

2

        {

3

    if( POSITION == VCount )

4

    {

5

    V=VCount;

6

    irmp_data.command  = VCount;    

7

    send=1;

8

    }

9

       }

dann funktioniert es mit diesem am empfänger:

1

  for (Vcommand=0; Vcommand<=7; Vcommand++)

2

       {

3

  if( irmp_data.command == Vcommand )

4

    {

5

    V=Vcommand;

6

    }

7

8

        }

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

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

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.

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:

1

while(1)

2

    {

3

        irmp_get_data(&irmp_data);

4

5

        if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)

6

        {

7

            // Volume up

8

            if((irmp_data.command&0x00FF) == 0x0B)

9

            {

10

                // Motor rechts

11

                PORTD |= (1<<PD5);

12

                PORTD &= ~(1<<PD6);

13

            }

14

            // Volume down

15

            else if((irmp_data.command&0x00FF) == 0x0D)

16

            {

17

                // Motor links

18

                PORTD |= (1<<PD6);

19

                PORTD &= ~(1<<PD5);

20

            }

21

            else

22

            {

23

            // Motor stop

24

            PORTD &= ~(1<<PD5);

25

            PORTD &= ~(1<<PD6);

26

            }

27

        }

28

    }

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

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

1

>     while(1)

2

>     {

3

>         irmp_get_data(&irmp_data);

4

>

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

Also:

1

    while(1)

2

    {

3

        if (irmp_get_data(&irmp_data))

4

        {

5

            ... // hier Deinen restlichen Code einfügen

6

        }

7

    }

> 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

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

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

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.

1

while(1)

2

    {

3

        irmp_get_data(&irmp_data);

4

5

            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)

6

            {

7

                // Volume up

8

                if((irmp_data.command&0x00FF) == 0x0B)

9

                {

10

                    // Motor rechts

11

                    PORTD |= (1<<PD5);

12

                    PORTD &= ~(1<<PD6);

13

                }

14

                // Volume down

15

                else if((irmp_data.command&0x00FF) == 0x0D)

16

                {

17

                    // Motor links

18

                    PORTD |= (1<<PD6);

19

                    PORTD &= ~(1<<PD5);

20

                }

21

                else

22

                {

23

                    // Motor stop

24

                    PORTD &= ~(1<<PD5);

25

                    PORTD &= ~(1<<PD6);

26

                }

27

            }

28

    }

Jetzt nehme ich die Überprüfung mit rein:

1

while(1)

2

    {

3

        if(irmp_get_data(&irmp_data))

4

        {

5

            if(irmp_data.protocol == IRMP_APPLE_PROTOCOL)

6

            {

7

                // Volume up

8

                if((irmp_data.command&0x00FF) == 0x0B)

9

                {

10

                    // Motor rechts

11

                    PORTD |= (1<<PD5);

12

                    PORTD &= ~(1<<PD6);

13

                }

14

                // Volume down

15

                else if((irmp_data.command&0x00FF) == 0x0D)

16

                {

17

                    // Motor links

18

                    PORTD |= (1<<PD6);

19

                    PORTD &= ~(1<<PD5);

20

                }

21

                else

22

                {

23

                    // Motor stop

24

                    PORTD &= ~(1<<PD5);

25

                    PORTD &= ~(1<<PD6);

26

                }

27

            }

28

        }

29

        else

30

        {

31

            // Motor stop

32

            PORTD &= ~(1<<PD5);

33

            PORTD &= ~(1<<PD6);

34

        }

35

    }

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

Ephraim Hahn schrieb:
>

1

while(1)

2

>     {

3

>         if(irmp_get_data(&irmp_data))

4

>         {

5

>             ....

6

>         }

7

>         else

8

>         {

9

>             // Motor stop

10

>             PORTD &= ~(1<<PD5);

11

>             PORTD &= ~(1<<PD6);

12

>         }

13

>     }

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

1

   while(1)

2

   {

3

       if(irmp_get_data(&irmp_data))

4

       {

5

           if (...)

6

           {

7

               ...

8

           }

9

           else if (...)

10

           {

11

               ...

12

           }

13

           else // NUR HIER MOTORSTOPP!

14

           {

15

               ...

16

           }

17

       }

18

       // KEIN else!

19

   }

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

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

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

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

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

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

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.

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

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

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?

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

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

1

  IRMP_DATA irmp_data;

2

  ...

3

4

  irmp_data.protocol = IRMP_NEC_PROTOCOL;

5

  irmp_data.address  = 0x61DC;       // address of camera

6

  irmp_data.protocol = 0x40BF;       // command "w"

7

  irmp_data.flags    = 0x00;         // reset flags

8

  irsnd_send_data (&irmp_data);      // send data

Gruß,

Frank

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

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

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?

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.

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?

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?

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

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

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

1

#ifndef TRUE

2

#define TRUE                                    1

3

#define FALSE                                   0

4

#endif

Kommt mit dem nächsten Release.

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

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.

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.

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.

1

# ./irmp  <rx_denon_9766Hz.txt

2

-------------------------------------------------------------------

3

#1

4

010001000111100

5

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

6

-------------------------------------------------------------------

7

#2

8

010001000111100

9

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

10

-------------------------------------------------------------------

11

#3

12

010001000111100

13

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

14

-------------------------------------------------------------------

15

#4

16

010001000111100

17

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

18

-------------------------------------------------------------------

19

#5

20

010001000111100

21

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

22

23

24

# ./irmp-20kHz < rx_test_19990Hz.txt

25

-------------------------------------------------------------------

26

#1 denon vol+

27

010001000111100

28

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

29

-------------------------------------------------------------------

30

#2 denon vol+

31

010001000111100

32

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

33

-------------------------------------------------------------------

34

#3 denon vol+

35

010001000111100

36

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

37

-------------------------------------------------------------------

38

#4 nec vol+

39

00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

40

-------------------------------------------------------------------

41

#5 nec vol+

42

00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

43

-------------------------------------------------------------------

44

#6 nec vol+

45

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:

1

# ./irsnd 8 0008 023c 0 | ./irmp

2

010001000111100

3

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

4

5

# ./irsnd-20kHz 8 0008 023c 0 | ./irmp-20kHz

6

010001000111100

7

010000111000011 p =  8, a = 0x0008, c = 0x023c, f = 0x00

8

9

# ./irsnd-20kHz 2 bf40 001a 0 | ./irmp-20kHz

10

00000010111111010101100010100111 p =  2, a = 0xbf40, c = 0x001a, f = 0x00

Vergleich des IRSND-Outputs mit Deiner Text-Datei:

1

# ./irsnd-20kHz 2 bf40 001a 0 

2

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111111111111111111111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111110000000000011111111111111111111111111111111110000000000011111111111000000000001111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111111111111111111111111111100000000000111111111...

3

# tail -1 rx_test_19990Hz.txt

4

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111111111111111111111111111111111111111111110000000000000111111111100000000000011111111110000000000000111111111100000000000001111111110000000000000111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111100000000000001111111111111111111111111111111100000000000001111111110000000000000111111111111111111111111111111110000000000000111111111100000000000011111111111111111111111111111111100000000000011111111111111111111111111111111000000000000011111111110000000000000111111111000000000000011111111110000000000000111111111111111111111111111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111110000000000001111111111000000000000011111111111111111111111111111111000000000000011111111111111111111111111111111000000000000111111111111111111111111111111111000000000000111111111...

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

Kannst Du den IRSND mittels zweitem µC auch scannen?

Gruß,

Frank

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:

1

pulse avg:  5.7= 284.9 us, min:  5= 250.0 us, max:  7= 350.0 us, tol: 22.8%

2

pause avg: 15.2= 759.8 us, min: 14= 700.0 us, max: 16= 800.0 us, tol:  7.9%

3

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

1

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

in

1

#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