IRMP - Infrared Multi Protocol Decoder

[jar (Gast)]

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

hier setzt du das Portbit gezielt auf Ausgang und lässt alle anderen 
unberührt |=

> PORTB=(1<<PB3);  //PB3 auf 1
hier setzt du das Portbit gezielt auf high und setzt alle anderen zurück 
=
mit |= würden die anderen nicht zurückgesetzt

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

hier setzt du das Portbit gezielt auf low und lässt alle anderen 
unberührt &= ~

[martin (Gast)]

Danke für den Hinweis bei der ersten Codezeile.

Wenn man nur den einen PortPin betrachtet, müsste das ganze aber doch 
funktionieren? Oder ist noch was falsch?

eventuell passen meine Fuses noch nicht so ganz, ich habe aber - wie es 
in der irsndmain.c steht - diese auf :Fuses: lfuse: 0xE2 hfuse: 0xDC

ich werd mal morgen mit dem oszi rangehen.

[Sebastian .. (zahlenfreak)]

Hallo Frank,

ich hab leider schon wieder ein Problem mit dem DENON Protokoll.

Auf den ersten Blick funktionieren die Timeouts, die du damals eingebaut 
hast.
Problem ist, dass, wenn man eine Taste lange drückt, IRMP nach einiger 
Zeit doch wieder auf den falschen Code springt. Ursache dafür ist, dass 
die Pause zwischen original-Frame und repetition-Frame genauso groß ist, 
wie zwischen zwei dieser Blöcke. Dein Code nimmt hier ja an, dass eine 
Pause größer ist als die andere. Auch auf der IRMP wiki Seite sind 
unterschiedlich lange Pausen dokumentiert.

Hab hier eine original DENON FB, die überall gleich lange Pausen hat und 
eine Universal FB, die beim DENON-Protokoll das gleiche Verhalten zeigt.

Von der DENON FB hab ich mal ein log-file mit etwas längeren 
Tastendrücken angehängt. Auf dem Oszi kann man das Verhalten noch 
schöner beobachten.

Gibts vielleicht noch eine Andere Möglichkeit, original und repetition 
zu unterscheiden? Irgendwie müssen das die DENON Geräte ja auch machen.


Und eine andere Frage noch:
Wäre es möglich, irmp noch einen counter zu verpassen, der mitzählt, wie 
lange eine Taste schon gedrückt ist? Sobald man loslässt sollte der 
Timer dann natürlich zurückgesetzt werden. Hab leider zu wenig Ahnung 
von den Sourcen um das zu beantworten.

Viele Grüße,

Sebastian

[Joachim B. (jar)]

hallo Frank,

ich blicke gerade nicht durch, brauche nur auf OC2 ein symetrisches PWM 
Signal 36kHz für den m1284p

PortD 7 ist klar, output für DDRD

wenn ich (F_CPU=20MHz : 36000 : 2 ) - 1 rechne komme ich auf 277 das ist 
mehr als ein 8-Bit Register aufnehmen kann (ich erinnere mich aber das 
es auch 16 Bit Register gibt m32 OCR1A OCR1B ?)

ist IRSND in F_CPU begrenzt ? also kleiner 20 MHz ?

muss ich dann deswegen den Vorteiler setzen, ist ein Vorteiler noch 
nicht im IRSND vorgesehen ?

wäre nett wenn du helfen könntest, ich verliere mich gerade in fast PWM 
Phase correct PWM, blicke gerade nicht mehr durch

brauche eigentlich nur ein symetrisches 36kHz Signal welches on und off 
geschaltet wird (rot Diode an TSOP31736 für eine Abtastung), on off 
möchte ich am TSOP sehen

also für 20MHz und minimal setup wäre willkommen, die ganze IRSND 
einbauen wäre oversized, genau wie den ganzen Quellcode zu durchforsten 
und dann zu verstehen......

vielen Dank
jar

[Joachim B. (jar)]

OK, gelöst

mit Vorteiler 8 passt auch 20 MHz

TCCR2A |= (1<<COM2A0)|(1<<WGM21);  // toggle OC2A on compare match, 
clear Timer 2 at compare match OCR2A

TCCR2B = (1<<CS21);  // 0x01, start Timer 2, no prescaling
OCR2A = 35;

also IRSND arbeitet nur bis F_CPU 18.432 MHz !!!!

[Frank M. (ukw) (Moderator)]

Joachim B. schrieb:
> mit Vorteiler 8 passt auch 20 MHz

Danke für den Tipp, werde ich in IRSND einbauen.

Gruß,

Frank

[Joachim B. (jar)]

Frank M. schrieb:
> Danke für den Tipp, werde ich in IRSND einbauen.

immer wieder gerne, wenn alle zusammenhalten, sich ergänzen, kann das 
Ergebnis nur besser werden

gruss
jar

[Ulli -. (ulli2k)]

Konrad S. schrieb:
> @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 $

Hallo Frank,

ich versuche gerade IRMP und IRSND auf meinem Arduino Board (JeeNode) 
zum laufen zu bekommen.
Leider sehe ich kein Land....
Kannst du mir ein simples Beispiel Projekt inkl. deiner lauffägigen 
IRMP/IRSND Library für Arduino zukommen lassen?

Das würde mir sehr helfen.

Grüße,
  Ulli

[Ulli -. (ulli2k)]

Sorry für den Doppelpost.

Ich habe gerade die aktuelle svn getestet und damit funktioniert IRMP 
mit Arduino. Leider aber kein IRSND.

Ich habe IRSND eingebunden und sende eine Nachricht. Mit meiner Kamera 
sehe ich auch das die Diode blickt.
Nur Ist die Nachricht scheinbar nicht korrekt, da mein Radio nicht 
reagiert.

Kann mir jemand dabei helfen?

@Frank: hast du IRSND am laufen?

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:

> Ich habe gerade die aktuelle svn getestet und damit funktioniert IRMP
> mit Arduino. Leider aber kein IRSND.

Wenn die SVN-Version es auf einem Arduino tut, dann sollte auch die 
Release-Version damit arbeiten. Achnee, da gibt es ja noch das Problem 
der Namensgebung der xor-Variablen... in der SVN-Version ist dieses 
Problem gelöst.

> Ich habe IRSND eingebunden und sende eine Nachricht. Mit meiner Kamera
> sehe ich auch das die Diode blickt.

Das ist schonmal gut.

> Nur Ist die Nachricht scheinbar nicht korrekt, da mein Radio nicht
> reagiert.

Protokoll? Adresse? Kommando? Flags?

Bekommst Du vielleicht beim Übersetzen eine Warnung, dass F_CPU nicht 
gesetzt ist? Oder andere Warnungen?

> @Frank: hast du IRSND am laufen?

Natürlich. Und viele andere auch. Aber ich habe keinen Arduino, so dass 
ich Dein Problem leider nicht direkt nachvollziehen kann.

Zeige bitte mal irsndconfig.h (und vielleicht zum Vergleich auch 
irmpconfig.h) und dann noch den Aufruf von irsnd nebst Inhalte der 
IRMP_DATA-Struct.

Gruß,

Frank

[Ulli -. (ulli2k)]

> Protokoll? Adresse? Kommando? Flags?

Ich habe erst mit IRMP die Daten aufgezeichnet und dann mit IRSND wieder 
weiter versendet. --> Keine Reaktion des z.B. Radios

  if (irmp_get_data (&irmp_data)) {
    Serial.print(irmp_data.protocol);
    Serial.print(" A:");
    Serial.print(irmp_data.address, HEX);
    Serial.print(" C:");
    Serial.print(irmp_data.command, HEX);
    Serial.print(" ");
    Serial.print(irmp_data.flags, HEX);
    Serial.println("");

    delay(1500);
    int result;
    result = irsnd_send_data(&irmp_data, TRUE);
    if (result != 1) Serial.println("ERROR");
    if (result == 1) Serial.println("Sent");
  }

auch mit folgendem Ansatz hat es nicht funktioniert.

   irmp_data.protocol = IRMP_NEC_PROTOCOL; // sende im NEC-Protokoll
   irmp_data.address = 0x857A; 
   irmp_data.command = 0x1F; 
   irmp_data.flags = 0; 
   
   int result;
   result = irsnd_send_data(&irmp_data, TRUE);
   if (result != 1) Serial.println("ERROR");
   if (result == 1) Serial.println("Sent");

>Bekommst Du vielleicht beim Übersetzen eine Warnung, dass F_CPU nicht
gesetzt ist? Oder andere Warnungen?

Nein ich bekomme beim Compiler weder Warnungen noch Fehler.

irsndconfig.h, irmpconfig.h und die Hauptanwendung.c ist anbei.

Ich hoffe du kannst mir dabei weiter helfen....

Ich benutze einen ATmega328P microcontroller mit 16 MHz ceramic 
resonator.

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> Ich habe erst mit IRMP die Daten aufgezeichnet und dann mit IRSND wieder
> weiter versendet. --> Keine Reaktion des z.B. Radios

Der Source sieht soweit in Ordnung aus. Was mir auffällt:

#define US (1000000 / F_INTERRUPTS)
...
Timer1.initialize(US);

Da die initialize-Methode glatte Mikrosekunden erwartet, ergibt sich für 
US der abgerundete Wert 66 statt 66,67. Das macht eine Abweichung von 10 
Prozent. Es kann sein, dass Dein Radio da zu empfindlich ist und nicht 
mehr reagiert.

Wähle daher bitte einen Wert für F_INTERRUPTS, bei welchem die Division 
möglichst nahe an einer Ganzzahl ist. Da für NEC 10.0000 Calls/sec 
ausreichen, setze mal

#define F_INTERRUPTS 10000

sowohl in irmpconfig.h als auch irsndconfig.h und teste erneut.

Alternative für richtiges Runden:

#define US (long) ((1000000.0 / F_INTERRUPTS) + 0.5)

Das müsste dann für US den Wert 67 ergeben - schon besser.


Gruß,

Frank

[Ulli (Gast)]

Ich werde das heute Abend gleich mal versuchen....

Kann ich evtl. noch einen Debug Modus oder etwas ähnliches aktivieren, 
falls es damit nicht funktioniert?

Leider habe ich auch schon ein RC6 Gerät versucht, welches auch nicht 
funktioniert hat.

Danke für deine Unterstützung.

[Frank M. (ukw) (Moderator)]

Ulli schrieb:
> Ich werde das heute Abend gleich mal versuchen....

Ich kenne mich überhaupt nicht mit Arduino aus. Funktioniert das 
überhaupt mit der Modulation des Senders, so wie das in irmp.c gemacht 
wird, auf einem Arduino?

Einerseits benutzt Du Arduino-Methoden, um einen Timer zu 
initialisieren, andererseits greift irsnd.c "direkt" auf die 
Timer-Register des µCs zu, um per PWM das Signal zu modulieren. Ist das 
auf einem Arduino so überhaupt legitim? Oder kann das zu Konflikten 
führen?

[Ulli -. (ulli2k)]

Gute Nachrichten so weit. So ich bin einen Schritt weiter!

Ich habe den IRSND Pin getauscht auf Timer0 und damit in
irsndconfig.h folgendes konfiguriert.
#  define IRSND_OCx                             IRSND_OC0A

Dann habe ich in irsnd.c einen Fehler gefunden
Für einen ATmega328P und der OC0A Konfiguration muss es der Pin PD6 sein 
nicht PB6!!! Bitte korrigiere das Frank!

Danach konnte ich mit F_INTERRUPTS = 10000, 15000 und 20000 NEC_Protocol 
Kommandos versenden, welche mein Radio verstanden hat!!

ABER!!
Leider funktioniert das Senden des Protokolls RC6 nicht. Empfangen 
funktioniert wieder wunderbar. Aber beim Senden wird es von meinem 
Philips TV nicht angenommen.
An was könnte das nun liegen? Ich habe F_INTERRUPTS 10000, 15000 und 
20000 getestet.

Irgendwelche Hinweise?
Wäre sehr dankbar dafür!

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:

> Dann habe ich in irsnd.c einen Fehler gefunden
> Für einen ATmega328P und der OC0A Konfiguration muss es der Pin PD6 sein
> nicht PB6!!! Bitte korrigiere das Frank!

Upps, stimmt. Blöder Fehler. Ich korrigiere das. Aber warum klappte es 
nicht mit OC2A/OC2B - also mit dem Timer2? Ist der vielleicht beim 
Arduino nicht ohne weiteres frei nutzbar?

> Danach konnte ich mit F_INTERRUPTS = 10000, 15000 und 20000 NEC_Protocol
> Kommandos versenden, welche mein Radio verstanden hat!!

Freut mich :-)

> Leider funktioniert das Senden des Protokolls RC6 nicht. Empfangen
> funktioniert wieder wunderbar. Aber beim Senden wird es von meinem
> Philips TV nicht angenommen.

Gib mal bitte die Adresse und ein Beispiel für ein Kommando. Ich habe 
selbst kein RC6-Gerät und konnte das nur testen indem ich unter Linux 
den IRSND-Output in den IRMP schiebe. Eben noch getestet... klappt 
wunderbar.

> Irgendwelche Hinweise?

Leider nein. Eventuell helfen ein paar Scan-Dateien weiter, siehe

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

Gruß,

Frank

[Ulli -. (ulli2k)]

Hier ein Log des Empfängers:
000000000000000000000000000000000000000000111111111110000000011111111111 
100000000111110000000011111100000000000000000000011111111111111111100000 
000011111000000001111100000000111111000000011111100000000111110000000011 
111100000000111110000000011111000000000111110000000011111000000000000000 
111111111111000000001111100000000011111000000000000000111111111111111111 
11

Ist es auch möglich so einen Log vom Ausgang zu bekommen, um diesen 
vergleichen zu können?

Ich bekomm es einfach nicht hin....warum geht nur RC6 nicht aber NEC....

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> Hier ein Log des Empfängers:

Danke, das entspricht Adresse 0x00 und Kommando 0x11

> Ist es auch möglich so einen Log vom Ausgang zu bekommen, um diesen
> vergleichen zu können?

Ich habe gerade mal denselben Code mittels IRSND erzeugt:

00000000000000000000000000000000000000000011111111111000000001111111111110000000011111000000001111110000000000000000000001111111111111111110000000001111100000000111110000000011111100000001111110000000011111000000001111110000000011111000000001111100000000011111000000001111100000000000000011111111111100000000111110000000001111100000000000000011111111111111111111
00000000000000000000000000000000000000001111111111110000000111111111111110000000111111100000001111111000000000000000000000111111111111111111111000000011111110000000111111100000001111111000000011111110000000111111100000001111111000000011111110000000111111100000001111111000000011111110000000000000011111111111111000000011111110000000111111100000000000000111111111111

Die obere Zeile ist Deine, die untere ist der IRSND-Output. Ich sehe da 
keinen signifikanten Unterschied, außer, dass Deine FB etwas längere 
Pulse, aber dafür kürzere Pausen erzeugt. Der Output ist also leicht 
asymetrisch. Beides wird von IRMP mit Adresse 0 und Kommando 0x11 
erkannt. Ist Dein RC6-Empfänger so empfindlich beim Timing? Blödes 
Problem.
Du könntest noch mit der Modulationsfrequenz spielen, also 36kHz vs. 
38kHz.

> Ich bekomm es einfach nicht hin....warum geht nur RC6 nicht aber NEC....

[Ulli -. (ulli2k)]

Hi Frank,

ich habe das Problem gefunden.
Es liegt nicht an deinem Package sondern an der Arduino konfiguration.
Scheinbar konfiguriert Arduino die Timer vor.

Ein
TCCR0A = 0x0;
TCCR0B= 0x0;
für Timer 0

oder ein
  TCCR2B = 0x0;
  TCCR2A = 0x0;
für Timer 2

Vor Aufruf deiner Init Funktionen löst alle Probleme.

Ich glaub ich spine....

Vielen Dank nochmal für deinen Support und dein tolles IRMP und IRSND!!

[Ulli -. (ulli2k)]

genauer gesagt setzt Arduino vorab folgende Bits bei Timer0:
  sbi(TCCR0A, WGM01);
  sbi(TCCR0A, WGM00);
  sbi(TCCR0B, CS01);
  sbi(TCCR0B, CS00);

d.h. folgende zu viel im Vergleich zu IRSND:
  sbi(TCCR0A,WGM00); // Fast PWM statt CTC
  sbi(TCCR0B,CS00); // Prescaler

Lässt sich IRSND umkonfigurieren so das es mit "Fast PWM" anstatt CTC 
läuft?
Ich fürchte Quereinflüsse durch das umkonfigurieren von Arduino.

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> Ein
> TCCR0A = 0x0;
> TCCR0B= 0x0;
> für Timer 0
>
> oder ein
>   TCCR2B = 0x0;
>   TCCR2A = 0x0;
> für Timer 2
>
> Vor Aufruf deiner Init Funktionen löst alle Probleme.

Danke für den Tipp, ich werde das in den IRMP einbauen. Dann sollte das 
Arduino-Problem beseitigt sein.

> Ich glaub ich spine....

Ja. Fragt sich nur, wofür die "Arduino-Timer" verwendet werden. Gibt es 
dazu eine Dokumentation?

> Vielen Dank nochmal für deinen Support und dein tolles IRMP und IRSND!!

Danke fürs Danke :-)

Ulli -- schrieb:

> Lässt sich IRSND umkonfigurieren so das es mit "Fast PWM" anstatt CTC
> läuft?

Könnte klappen. Probiere es doch einfach mal aus.

> Ich fürchte Quereinflüsse durch das umkonfigurieren von Arduino.

Um das zu beurteilen, müsste man erstmal wissen, wofür die vom Arduino 
vorbelegten Timer überhaupt gut sind.

Viel Spaß mit IRMP,

Frank

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> ich habe das Problem gefunden.

Ich habe die Timerinitialisierung korrigiert und die Änderung ins SVN 
eingecheckt. Kannst Du das aktuelle irsnd.c aus dem SVN mal kurz 
gegentesten?

Dank und Gruß,

Frank

[Ulli -. (ulli2k)]

sorry für die späte Antwort!

Yep, jetzt funktionieren die SVN Quellen "Out of the Box"! Super!

Ich habe anbei die Quelle der timer0 Funktionalität von Arduino 
angehängt.
Leider ist nach der Timer0 umkonfiguration die wichtige
Funktion delay und millis nicht mehr brauchbar....

Siehst du eine Möglichkeit das zu verhindern?
Ich habe es schon versucht mit der Manipulation von 
"MICROSECONDS_PER_TIMER0_OVERFLOW"....funktiert aber nicht.....

[Sebastian .. (zahlenfreak)]

Hallo Frank,

hast du mal über meinen Post im 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" 
nachgedacht? Siehst du eine möglichkeit, das DENON protokoll auch bei 
langen Tastendrücken zuverlässig zu erkennen, oder sollte ich mich nach 
einer anderen Fernbedienung umschauen?

Viele Grüße,

Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:

> hast du mal über meinen Post im
> 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
> nachgedacht?

Sorry, irgendwie muss ich Dein Posting überlesen haben.

Ich habe mir das dort angehängte Log mal angeschaut. Leider ist das 
komplett unbrauchbar. Denn dort kommen merkwürdigerweise nicht nur 
Pausenlängen von ca. 732µs, sondern auch 1810µs, 2133µs, 2883µs, 3800µs 
und 5000µs vor - und das schon nach 1 oder 2 Bits im Frame.

> Siehst du eine möglichkeit, das DENON protokoll auch bei
> langen Tastendrücken zuverlässig zu erkennen,

Wenn ich einen brauchbaren Scan zur Verfügung habe.... ;-)

> oder sollte ich mich nach einer anderen Fernbedienung umschauen?

Wenn Du auch eine andere für Deine Anwendung nehmen kannst, ist das 
vielleicht die einfachere Lösung.

Nichtsdestotrotz bin ich natürlich daran interessiert, diese 
Wiederholungsproblematik auch für Denon in den Griff zu bekommen.

Gruß,

Frank

[Sebastian .. (zahlenfreak)]

Frank M. schrieb:
> Sorry, irgendwie muss ich Dein Posting überlesen haben.

Kein Problem, kommt vor.

> Ich habe mir das dort angehängte Log mal angeschaut. Leider ist das
> komplett unbrauchbar. Denn dort kommen merkwürdigerweise nicht nur
> Pausenlängen von ca. 732µs, sondern auch 1810µs, 2133µs, 2883µs, 3800µs
> und 5000µs vor - und das schon nach 1 oder 2 Bits im Frame.

Ich hab dir mal noch ein log erstellt und angehängt. Wenn du noch was 
anderes brauchst gib einfach bescheid. Wenn jetzt wieder was komisches 
drin steht kommt wohl das Logging nicht mit langen Tastendrücken klar. 
Mein Verstärker und ein anderer IRMP empfänger haben während dem logging 
super reagiert. Fernbedienung wahr natürlich auf den Logger gerichtet.


> Wenn Du auch eine andere für Deine Anwendung nehmen kannst, ist das
> vielleicht die einfachere Lösung.
>
> Nichtsdestotrotz bin ich natürlich daran interessiert, diese
> Wiederholungsproblematik auch für Denon in den Griff zu bekommen.

Ich könnte schon eine andere nehmen, wäre aber schade. Die Denon ist 
sozusagen meine Lieblingsfernbedienung ;)  Ich finde es aber super, dass 
du so hinter der Qualität von IRMP her bist!
Ich hab mitlerweile auch mal versucht, den Code zu verstehen. Leider ist 
das ganze ziemlich unübersichtlich. Vorallem dadurch, dass die irmp.c so 
lang ist. Vielleicht könntest du das mal etwas aufteilen? Das würde es 
schon deutlich leichter machen, auch selbst mal direkt am Code zu 
arbeiten.


Viele Grüße,

Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:
> Ich hab dir mal noch ein log erstellt und angehängt.

Die Scan-Datei ist perfekt. Hier der erste Output, bevor wir ins Detail 
gehen:

./irmp-15kHz < Denon_RC-176_mit_Widerholungen_-_versuch_2.txt
#Cassette Deck A/B
001001100101000
001000011010111 p =  8, a = 0x0004, c = 0x0328, f = 0x00
001001100101000
001000011010111 p =  8, a = 0x0004, c = 0x0328, f = 0x01
001001100101000
-------------------------------------------------------------------
#Cassettte Deck Rec
001001111101000
001000000010111 p =  8, a = 0x0004, c = 0x03e8, f = 0x00
001001111101000
001000000010111 p =  8, a = 0x0004, c = 0x03e8, f = 0x01
001001111101000
-------------------------------------------------------------------
#Cassette Deck Pause
001001011101000
001000100010111 p =  8, a = 0x0004, c = 0x02e8, f = 0x00
001001011101000
001000100010111 p =  8, a = 0x0004, c = 0x02e8, f = 0x01
001001011101000
-------------------------------------------------------------------
#Amp Volume Up
010001011000100
010000100111011 p =  8, a = 0x0008, c = 0x02c4, f = 0x00
010001011000100
010000100111011 p =  8, a = 0x0008, c = 0x02c4, f = 0x01
010001011000100
-------------------------------------------------------------------
#Amp Volume Down
010000011000100
010001100111011 p =  8, a = 0x0008, c = 0x00c4, f = 0x00
010000011000100
010001100111011 p =  8, a = 0x0008, c = 0x00c4, f = 0x01
010000011000100
-------------------------------------------------------------------
#Amp Mute
010001101000100
010000010111011 p =  8, a = 0x0008, c = 0x0344, f = 0x00
010001101000100
010000010111011 p =  8, a = 0x0008, c = 0x0344, f = 0x01
010001101000100

Es wird immer ein normaler und ein invertierter Frame (Kommando-Bits 
invertiert) erkannt. Du siehst hier also zunächst 2 Frames, dann gibt 
IRMP die decodierten Daten aus. Anschließend kommen die nächsten 2 
Frames, welche durch den langen Tastendruck erzeugt werden. Auch diese 
werden korrekt erkannt und das Flag auf 0x01 gesetzt.

Dann kommt noch ein 5. Frame, wo aber der dazugehörende invertierte 
Frame fehlt. Das liegt einfach an der beschränkten Länge des 
Log-Buffers. Das Logging bricht einfach ab, wenn der Log-Buffer voll 
ist.

Dies wird auch von IRMP erkannt, wenn wir uns die Details (hier die 
erste Taste) anschauen:

./irmp-15kHz -v < Denon_RC-176_mit_Widerholungen_-_versuch_2.txt
#Cassette Deck A/B
   0.133ms [starting pulse]
   1.200ms [start-bit: pulse =  6, pause = 10]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
   1.200ms [bit  0: pulse =   6, pause =  10] 0
   2.267ms [bit  1: pulse =   6, pause =  10] 0
   4.400ms [bit  2: pulse =   5, pause =  27] 1
   5.467ms [bit  3: pulse =   5, pause =  11] 0
   6.533ms [bit  4: pulse =   6, pause =  10] 0
   8.667ms [bit  5: pulse =   6, pause =  26] 1
  10.800ms [bit  6: pulse =   5, pause =  27] 1
  11.867ms [bit  7: pulse =   4, pause =  12] 0
  12.933ms [bit  8: pulse =   5, pause =  11] 0
  15.067ms [bit  9: pulse =   4, pause =  28] 1
  16.067ms [bit 10: pulse =   5, pause =  10] 0
  18.200ms [bit 11: pulse =   6, pause =  26] 1
  19.267ms [bit 12: pulse =   6, pause =  10] 0
  20.333ms [bit 13: pulse =   6, pause =  10] 0
  21.400ms [bit 14: pulse =   6, pause =  10] 0
stop bit detected
  21.800ms code detected, length = 15
  21.800ms waiting for inverted command repetition
  67.800ms [starting pulse]
  68.867ms [start-bit: pulse =  6, pause = 10]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
  68.867ms [bit  0: pulse =   6, pause =  10] 0
  69.933ms [bit  1: pulse =   6, pause =  10] 0
  72.067ms [bit  2: pulse =   6, pause =  26] 1
  73.133ms [bit  3: pulse =   5, pause =  11] 0
  74.133ms [bit  4: pulse =   4, pause =  11] 0
  75.200ms [bit  5: pulse =   6, pause =  10] 0
  76.267ms [bit  6: pulse =   6, pause =  10] 0
  78.400ms [bit  7: pulse =   5, pause =  27] 1
  80.533ms [bit  8: pulse =   6, pause =  26] 1
  81.600ms [bit  9: pulse =   6, pause =  10] 0
  83.733ms [bit 10: pulse =   5, pause =  27] 1
  84.800ms [bit 11: pulse =   6, pause =  10] 0
  86.933ms [bit 12: pulse =   5, pause =  27] 1
  89.067ms [bit 13: pulse =   5, pause =  27] 1
  91.200ms [bit 14: pulse =   6, pause =  26] 1
stop bit detected
  91.600ms code detected, length = 15
  91.600ms p =  8, a = 0x0004, c = 0x0328, f = 0x00
 135.467ms [starting pulse]
 136.533ms [start-bit: pulse =  5, pause = 11]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
 136.533ms [bit  0: pulse =   5, pause =  11] 0
 137.600ms [bit  1: pulse =   5, pause =  11] 0
 139.733ms [bit  2: pulse =   4, pause =  28] 1
 140.800ms [bit  3: pulse =   5, pause =  11] 0
 141.867ms [bit  4: pulse =   5, pause =  11] 0
 144.000ms [bit  5: pulse =   5, pause =  27] 1
 146.133ms [bit  6: pulse =   5, pause =  27] 1
 147.200ms [bit  7: pulse =   5, pause =  11] 0
 148.200ms [bit  8: pulse =   4, pause =  11] 0
 150.333ms [bit  9: pulse =   5, pause =  27] 1
 151.400ms [bit 10: pulse =   6, pause =  10] 0
 153.533ms [bit 11: pulse =   6, pause =  26] 1
 154.600ms [bit 12: pulse =   7, pause =   9] 0
 155.667ms [bit 13: pulse =   5, pause =  11] 0
 156.733ms [bit 14: pulse =   6, pause =  10] 0
stop bit detected
 157.200ms code detected, length = 15
 157.200ms waiting for inverted command repetition
 203.133ms [starting pulse]
 204.200ms [start-bit: pulse =  5, pause = 11]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
 204.200ms [bit  0: pulse =   5, pause =  11] 0
 205.267ms [bit  1: pulse =   5, pause =  11] 0
 207.400ms [bit  2: pulse =   5, pause =  27] 1
 208.467ms [bit  3: pulse =   5, pause =  11] 0
 209.467ms [bit  4: pulse =   4, pause =  11] 0
 210.533ms [bit  5: pulse =   5, pause =  11] 0
 211.600ms [bit  6: pulse =   6, pause =  10] 0
 213.733ms [bit  7: pulse =   5, pause =  27] 1
 215.867ms [bit  8: pulse =   5, pause =  27] 1
 216.933ms [bit  9: pulse =   6, pause =  10] 0
 219.067ms [bit 10: pulse =   6, pause =  26] 1
 220.133ms [bit 11: pulse =   5, pause =  11] 0
 222.267ms [bit 12: pulse =   4, pause =  28] 1
 224.400ms [bit 13: pulse =   6, pause =  26] 1
 226.533ms [bit 14: pulse =   6, pause =  26] 1
stop bit detected
 226.867ms code detected, length = 15
 226.867ms p =  8, a = 0x0004, c = 0x0328, f = 0x01
 270.800ms [starting pulse]
 271.867ms [start-bit: pulse =  5, pause = 11]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
 271.867ms [bit  0: pulse =   5, pause =  11] 0
 272.933ms [bit  1: pulse =   5, pause =  11] 0
 275.067ms [bit  2: pulse =   5, pause =  27] 1
 276.133ms [bit  3: pulse =   5, pause =  11] 0
 277.133ms [bit  4: pulse =   5, pause =  10] 0
 279.333ms [bit  5: pulse =   6, pause =  27] 1
 281.467ms [bit  6: pulse =   5, pause =  27] 1
 282.533ms [bit  7: pulse =   5, pause =  11] 0
 283.533ms [bit  8: pulse =   5, pause =  10] 0
 285.667ms [bit  9: pulse =   6, pause =  26] 1
 286.733ms [bit 10: pulse =   7, pause =   9] 0
 288.867ms [bit 11: pulse =   6, pause =  26] 1
 289.933ms [bit 12: pulse =   6, pause =  10] 0
 291.000ms [bit 13: pulse =   6, pause =  10] 0
 292.067ms [bit 14: pulse =   5, pause =  11] 0
stop bit detected
 292.467ms code detected, length = 15
 292.467ms waiting for inverted command repetition
  56.067ms error 6: did not receive inverted command repetition

Wie man an der letzten Zeile (error 6) sieht, klappt das mit dem 
Erkennen des fehlenden invertierten Frames. IRMP setzt seine 
Statemachine zurück und erkennt die nächste folgende Taste.

Jetzt zu den Timings:

./irmp-15kHz -v < Denon_RC-176_mit_Widerholungen_-_versuch_2.txt | grep start-bit
   1.200ms [start-bit: pulse =  6, pause = 10]    1. Frame
  68.867ms [start-bit: pulse =  6, pause = 10]    2. Frame
 136.533ms [start-bit: pulse =  5, pause = 11]    3. Frame
 204.200ms [start-bit: pulse =  5, pause = 11]    4. Frame
 271.867ms [start-bit: pulse =  5, pause = 11]    5. Frame

Der invertierte Frame hat einen Abstand von 67.667ms zum ersten.
Der Wiederholungsframe (Nr. 3) hat einen Abstand von 67.666ms zum 2. 
Frame. Die Abstände sind also absolut identisch.

Welche Frames zusammengehören (normaler und invertierter), erkennt IRMP 
nur daran, dass die Bits im Kommando gekippt sind. Nun könnte es 
passieren, dass IRMP sich (aus Zeitnot?) mal verhaspelt und den normalen 
Frame nicht erkennt, dafür aber den invertierten und diesen dann als 
normalen Frame erkennt. Aber dann sollte sich die Statemachine 
zurücksetzen, weil ja der erwartete "invertierte" Frame nicht mehr 
kommt, sondern stattdessen wieder ein normaler.

Ich könnte mir vorstellen, dass das Zurücksetzen der Statemachine in 
diesem Fall (DENON) nicht richtig funktioniert. Ich werde das durch 
Manipulation Deiner Scan-Dateien mit dem Editor mal provozieren und das 
dann testen.

> Ich hab mitlerweile auch mal versucht, den Code zu verstehen. Leider ist
> das ganze ziemlich unübersichtlich. Vorallem dadurch, dass die irmp.c so
> lang ist. Vielleicht könntest du das mal etwas aufteilen? Das würde es
> schon deutlich leichter machen, auch selbst mal direkt am Code zu
> arbeiten.

Es ist schwierig, das weiter aufzuteilen, da die Funktion irmp_ISR() so 
lang ist. Externe Funktionsaufrufe möchte ich vermeiden, da diese in 
einer ISR suboptimal sind. Inlinen kann nicht jeder Compiler - ich denke 
da an die PIC-Portierungen.

Unübersichtlich ist der Code eigentlich eher wegen den vielen 
eingestreuten Preprocessor-Statements. Aber leider lässt sich das nicht 
vermeiden.

Ich werde mal drüber nachdenken, was man da machen kann.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Frank M. schrieb:
> Welche Frames zusammengehören (normaler und invertierter), erkennt IRMP
> nur daran, dass die Bits im Kommando gekippt sind. Nun könnte es
> passieren, dass IRMP sich (aus Zeitnot?) mal verhaspelt und den normalen
> Frame nicht erkennt, dafür aber den invertierten und diesen dann als
> normalen Frame erkennt. Aber dann sollte sich die Statemachine
> zurücksetzen, weil ja der erwartete "invertierte" Frame nicht mehr
> kommt, sondern stattdessen wieder ein normaler.

Wo ich mir mein Geschreibsel nochmal durchlese: Da die 
Tasten-Wiederholungs-Frames denselben Abstand haben wie beiden Frames, 
die zusammengehören, kann man tatsächlich nicht unterscheiden, was 
normaler und was invertierter Frame ist. Wird ein normaler Frame 
verschluckt, wird IRMP den darauf folgenden invertierten Frame als 
normalen ansehen und anschließend den darauf folgenden normalen als 
invertierten - jedenfalls wenn dieser durch langen Tastendruck 
entstanden ist. (Bei Loslassen kommt ein Timeout. Das wäre also kein 
Problem).

Der Abstand der Frames kann also kein Kriterium sein. Aber was mir 
aufgefallen ist: Das letzte Bit im normalen Frame ist bei meinen mir 
vorliegenden Scan-Dateien (3 verschiedene Geräte) immer 0, d.h. der 
Kommando-Code ist immer gerade. Könnte man das als Kriterium nehmen?

@Sebastian: Kannst Du das mal bei Deinem Gerät überprüfen?

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Nochmal Selbstgespräch:

Frank M. schrieb:
> Aber was mir aufgefallen ist: Das letzte Bit im normalen Frame ist
> bei meinen mir vorliegenden Scan-Dateien (3 verschiedene Geräte) immer
> 0, d.h. der Kommando-Code ist immer gerade.

Ich habe gerade mit etwas Recherche eine interessante DENON-eigene 
Dokumentation gefunden:

  http://www.manualowl.com/m/Denon/AVR-3803/Manual/170243

Demnach ist nicht nur das letzte, sondern sind sogar immer die letzten 
beiden Bits gleich 0. Ich habe das mit meinen Scan-Dateien verifiziert: 
es stimmt.

Ich werde dieses als Kriterium zur Unterscheidung des normalen und des 
invertierten Frames für das Denon-Protokoll einbauen. Dann sollte 
Sebastians Problem behoben sein.

[Sebastian .. (zahlenfreak)]

Hallo Frank,

du bist genial!

Frank M. schrieb:
> Wird ein normaler Frame
> verschluckt, wird IRMP den darauf folgenden invertierten Frame als
> normalen ansehen und anschließend den darauf folgenden normalen als
> invertierten - jedenfalls wenn dieser durch langen Tastendruck
> entstanden ist. (Bei Loslassen kommt ein Timeout. Das wäre also kein
> Problem).

Genau das tritt bei mir ständig auf. Ich habe auch den Eindruck, dass es 
besser ist, wenn nur IRMP auf dem Controller läuft, aber auch dann tritt 
das Problem auf.

Das mit den geraden Kommandos klingt super. Jetzt wo du es erwähnst 
würde ich es so aus der Erinnerung auch bestätigen. Heute abend schau 
ich mal meine Fernbedienung durch.

Schonmal vielen Dank für die schnelle Hilfe!

Viele Grüße,
Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:
> Genau das tritt bei mir ständig auf.

Ich habe es eben mit Deiner Scan-Datei reproduzieren können, nachdem ich 
sie mit einem Editor manipuliert habe. Es war dann leicht, das in irmp.c 
zu beheben.

Ich habe die nötige Korrektur gerade ins SVN eingecheckt.

Viel Spaß,

Frank

[Sebastian .. (zahlenfreak)]

Hallo Frank,

ich hab jetzt mal die Codes meiner DENON Fernbedienungen angeschaut. 
Habe keine Taste gefunden, bei der die letzten zwei bits des commandos 
gesetzt sind. Schaut also gut aus.

Die neuen Sourcen hab ich auch schon getestet. Bisher läufts 
einwandfrei.

Nochmal vielen Dank für die schnelle Hilfe!

Grüße, Sebastian

[Ulli (Gast)]

Hallo Frank,

jetzt habe ich mal eine ganz andere Frage. Ich möchte parallel mit dem 
selben Controller IR Signale und OOK 433MHz Signale auswerten.
Genauer gesagt sieht das 433MHz Signal wie unter folgenden Link 
beschrieben aus.
<http://www.firefly-power.de/ARM/RFM12.html>;

Lässt sich irmp so konfigurieren das auch diese Signale zuverlässig 
interpretiert werden?

[Frank M. (ukw) (Moderator)]

Ulli schrieb:
> jetzt habe ich mal eine ganz andere Frage. Ich möchte parallel mit dem
> selben Controller IR Signale und OOK 433MHz Signale auswerten.
> Genauer gesagt sieht das 433MHz Signal wie unter folgenden Link
> beschrieben aus.
> <http://www.firefly-power.de/ARM/RFM12.html>;

Habs mir gerade mal angeschaut. Auf der Seite steht:

       "Die Codierung ähnelt der Manchestercodierung."

Das ist aber Quatsch, denn es handelt sich hier ganz klar um ein 
Pulse-Distance Protokoll.

> Lässt sich irmp so konfigurieren das auch diese Signale zuverlässig
> interpretiert werden?

Ja, um ein neues Pulse-Distance-Protokoll einzubauen, brauche ich ca. 10 
bis 15 Minuten... und nochmal 10 Minuten für einen ersten Test.

[Ulli -. (ulli2k)]

Das hört sich ja spitze an.
Ich habe gerade im irmpconfig.h den Pin angepasst und das Logging über 
IRMP_LOGGING = 1 aktiviert.
Aber ich bekomme keinen Output auf der Uart.
Liegt das an der fehlenden Implementierung?

[Frank M. (ukw) (Moderator)]

Ulli -- schrieb:
> Aber ich bekomme keinen Output auf der Uart.

Welchen µC benutzt Du?

Zeige bitte mal Deine irmpconfig.h

Gruß,

Frank

[Thomas (Gast)]

Hallo,

Ich versuche jetzt schon seit ein paar tagen dem IRMP zum laufen zu 
bekommen aber es will einfach nicht... Langsam gehen mir die Ideen und 
die Motivation aus :(
Was bei mir Funktionieren soll: Wenn ich z.B. die 1 drücke soll z.B. 
Port PD0 gesetzt werden (will damit später Beleuchtung und Steckdosen 
steuern).

Was nicht funktioniert: Momentan versuche ich einfach sobald ein IR 
Signal erkannt wird das eine LED an einem Port leuchtet. Anscheinend 
wird einfach kein IR Signal erkannt, weil wenn ich einen Port ausserhalb 
von "if (irmp_get_data (&irmp_data))" setze leuchtet die LED.
Hier mal mein Code aus main.c an dem ich am rumprobieren bin:

main (void)
{
    IRMP_DATA irmp_data;

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

  
      PORTD = 0xff;  
      DDRD = 0xff; 

    for (;;)
    {
  PORTD =~(1<<PD1);
        if (irmp_get_data (&irmp_data))
        {
      switch ((unsigned char) irmp_data.command)
      {
      case 3: PORTD =~(1<<PD3); ;break;
      }
      PORTD =~(0<<PD1);
      PORTD =~(1<<PD2);
      // 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)
        }
    }
}

Ich habe zusätzlich zu den standarmäßig aktivierten Protokolle sämtliche 
Protokolle die von Phillips verwendet werden da ich hier ne Phillips 
Fernbedienung rumliegen habe. Habs allerdings auch schon mit einer 
Technisat und Denon versucht. Mit dem Interrupt habe ich auch schon hoch 
und runter probiert. Eingangsport ist standart PB 6. Mein 
Mikrocontroller steckt auf einem STK500 und der IR Sensor ist an die 
Stiftleisten angeschlossen. Der IR Sensor ist ein TSOP 31236 der aber 
der direkte nachfolger vom 1736 sein soll.
Ich verwende ein Atmega88A mit internem Oszilator eingestellt auf 8MHz.

Ich hoffe mir kann jemand helfen!

Viele Grüße

Thomas

[Frank M. (ukw) (Moderator)]

Thomas schrieb:

> Hier mal mein Code aus main.c an dem ich am rumprobieren bin:

Zeig bitte erstmal irmpconfig.h, am besten hier als Anhang.

>   PORTD =~(1<<PD1);

Das müsste eigentlich

    PORTD &= ~(1<<PD1);

heißen, denn Du willst doch nur ein einzelnes Bit löschen, oder?

>       case 3: PORTD =~(1<<PD3); ;break;

Dito:

        case 3: PORTD &= ~(1<<PD3); ;break;

Hier auch:

>       PORTD =~(0<<PD1);
>       PORTD =~(1<<PD2);

Überall hast Du das & vergessen.

Wie ist Deine LED beschaltet? Gegen GND oder gegen Vcc?

[Thomas (Gast)]

Danke für deine schnelle Antwort :)

Ja ich bin noch nicht ganz vertraut mit dem Syntax hab das alles in C51 
auf der Technikerschule gelernt und mit sbits die ausgänge beschaltet. 
Hab wohl zu einfach gedacht.

Anbei die Beschaltung der LEDs und die irmpconfig.h

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Anbei die Beschaltung der LEDs und die irmpconfig.h

Die LED leuchtet nur, wenn ein High-Signal vom ATmega erzeugt wird, 
also:

  PORTD |= (1<<PD3);

wenn die LED an PD3 angeschlossen ist. Leider sagst Du nicht, an welchem 
Anschluss des ATmega die LED angeschlossen ist.

Ändere Dein Programm mal folgendermaßen:

main (void)
{
    IRMP_DATA irmp_data;

    irmp_init();                    // initialize irmp
    timer1_init();                  // initialize timer 1
    sei ();                         // enable interrupts
  
    PORTD = 0xff;  
    DDRD = 0xff; 

    for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
            PORTD | = (1<<PD3);
        }
    }
}

Falls die LED woanders angeschlossen ist, ändere PD3 in den 
entsprechenden Wert.

[Thomas (Gast)]

Es hängt an jedem Anschluss von Port D eine LED
Bei PORTD &=(1<<PD3); brennen alle LEDs ausser die an Port 3
Bei PORTD |= (1<<PD3); bleibt alles dunkel
beides ausserhalb der "if (irmp_get_data (&irmp_data))" getestet

Ich glaube nicht das des bei mir momentan an der Port Beschaltung liegt, 
da ich ja ausserhalb des "if (irmp_get_data (&irmp_data))" mir alles 
erklären und nachvollziehen kann. Sobald etwas in dem if passieren soll 
geht nichts.

Was ich mich solangsam frage ist ob da was beim Programmieren schief 
geht? Habe im AVR STudio 4 den internen Osc auf 8MHz stehn und die fuses 
sind nach datenblatt eingestellt... aber das Programm kommt ja auf den 
Controller da ausserhalb von der if ja alles soweit ausgeführt wird. 
Oder das STK 500 macht etwas was es nicht soll... langsam hab ich so en 
Schädel von Datenblätter und Dokumentationen hoch und runter zu lesen :(

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Bei PORTD &=(1<<PD3); brennen alle LEDs ausser die an Port 3

Da fehlt doch ein '~' ?

> Bei PORTD |= (1<<PD3); bleibt alles dunkel

Bitte schreibe erstmal ein Programm, womit Du jede gewünschte LED ein- 
und ausschalten kannst. Wie schaltest Du die LED an PD3 ein?

> Was ich mich solangsam frage ist ob da was beim Programmieren schief
> geht? Habe im AVR STudio 4 den internen Osc auf 8MHz stehn und die fuses
> sind nach datenblatt eingestellt...

Bei den Standard-Einstellungen sind die Fuses so eingestellt, dass der 
interne 8MHz-Takt durch 8 geteilt wird. Der µC rennt dann nur mit 1MHz.

Das kann dann nicht gehen.

Schreibe ein Programm, welches die LED an PD3 im Sekundenrhytmus blinken 
lässt. Ändert die LED nur alle 8 Sekunden den Zustand, sind die Fuses 
falsch.

[Thomas (Gast)]

Oh man... also mit PORTD &=~(1<<PD3); schalte ich die LED ein und mit 
PORTD |=(1<<PD3); wieder aus bei _delay_ms(1000); macht er das jetzt 
auch brav nach einer ~sekunde und nichtmehr nach 8. Das mit der CKDIV8 
fuse habe ich bis jetzt erfolgreich überlesen -.- sorry dafür.
Auf IR Signale gibt es immer noch keine reaktion.

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Oh man... also mit PORTD &=~(1<<PD3); schalte ich die LED ein

Gut.

> und mit PORTD |=(1<<PD3); wieder aus

Prima.

> bei _delay_ms(1000); macht er das jetzt auch brav nach einer ~sekunde
> und nichtmehr nach 8. Das mit der CKDIV8 fuse habe ich bis jetzt
> erfolgreich überlesen -.- sorry dafür.

Immerhin haben wir jetzt schon mal einen Fehler eliminiert.

> Auf IR Signale gibt es immer noch keine reaktion.

Hast Du im Projekt F_CPU korrekt auf 8 MHz gesetzt? Gibt es beim 
Übersetzen irgendwelche Warnungen?

Wie sieht Dein C-Programm aus?

Hier mein Vorschlag. Das Einschalten der LED habe ich abgeändert, damit 
sie dann auch wirklich an geht ;-)

main (void)
{
    IRMP_DATA irmp_data;

    irmp_init();                    // initialize irmp
    timer1_init();                  // initialize timer 1
    sei ();                         // enable interrupts
  
    PORTD = 0xff;  
    DDRD = 0xff; 

    for (;;)
    {
        if (irmp_get_data (&irmp_data))
        {
            PORTD &= ~(1<<PD3);     // LED einschalten
            _delay_ms (1000);       // 1 Sekunde warten
        }
        PORTD |= (1<<PD3);          // LED wieder ausschalten
    }
}

[Thomas (Gast)]

Ja die Frequenz ist richtig eingestellt die Fusebits Extendet, High und 
Low stimmen jetzt auch mit der in der Überschrift von main.c überein. 
Alternativ habe ich es auch mal mit einem 8MHz Quarz getestet (mit LED 
blinken überprüft obs richtig taktet) aber auch kein ergebnis.
Warnung beim Compilieren gibt es auch keine.

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Ja die Frequenz ist richtig eingestellt die Fusebits Extendet, High und
> Low stimmen jetzt auch mit der in der Überschrift von main.c überein.

Gut. Was ist mit der IR-Empfängerschaltung? An welchem ATmega-Pin hängt 
sie und wie sieht die Schaltung aus?

Du hast das LED-Leuchten von 1000ms (1 sek) auf 100ms (1/10 sek) 
gekürzt, das ist Dir bewusst? Naja, sollte man trotzdem sehen...

[Thomas (Gast)]

Frank M. schrieb:
> An welchem ATmega-Pin hängt
> sie und wie sieht die Schaltung aus?

So aufgebaut wie ganz oben im IRMP Artikel nur mit einem TSOP31236. 
Stimmt auch mit dem Datenblatt vom TSOP überein. Out hängt an B6 
Spannung kommt üer das STK500. hab auch schon andere Pins getestet.

Frank M. schrieb:
> Du hast das LED-Leuchten von 1000ms (1 sek) auf 100ms (1/10 sek)
> gekürzt, das ist Dir bewusst? Naja, sollte man trotzdem sehen...

Hatte ich geändert weil ich etwas rumprobiert habe.

[jar (Gast)]

häng in die +Leitung Vcc zum TSOP einen 100 Ohm und an dem TSOP zwischen 
Vcc und GND einen Kondi 220nF bis 1µ (10µ)

[Thomas (Gast)]

So vorne weg... es geht! :)

Widerstand und Kondensator war vorher schon drin (habe trotzdem mehrere 
Kondensatoren dann durchgetestet). Dann hab ich es wieder auf den 4,7µF 
Kondensator umgebaut.

Woran es letztendlich lag kann ich nicht sagen... völlig gefrustet das 
wieder nix geht habe ich mir eine einfache Schaltung auf eine 
Lochrasterplatine gelötet und den µController drauf gesteckt und über 
den ISP vom STK 500 verbunden. Habe dann die Einstellungen aus dem neuen 
µController ausgelesen und und die fuses angepasst. Dann das Programm 
draufgespielt und es ging! Komisch ist nur das ich das schon davor 
mehrere male gemacht hab. Erste vermutung war das die leitung vom TSOP 
zum µController zu lang ist. also alles wieder auf STK 500 umgebaut und 
getestet... geht wieder nicht. Nach versuchen mit nem Draht direkt auf 
den µController pin zu gehen ging es. Wieder normal angeschlossen und es 
ging! Also die µController funktionieren jetzt beide.. Ich glaube in dem 
STK 500 wohnen Geister.

Vielen vilen Dank für deine Hilfe!!! :)

Eine kleine frage hätte ich noch.. Ich hab jetzt in meiner Harmony One 
den Videorekorder Toshiba VT-728G aus der Tabelle hinzugefügt und mal 
versucht mit

if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
          irmp_data.address == 23364)                   // Adresse

das Protokoll heraus zu filtern was nicht geklappt hat. Das NEC filtert 
er noch nur mit der Adresse passiert nichts. Mit 23364 0x23364 und 
0x5b44 getestet. Denke ich falsch :?

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> So vorne weg... es geht! :)

Prima.

> Ich glaube in dem STK 500 wohnen Geister.

Wahrscheinlich wird der Pin im STK500 noch für andere Zwecke genutzt. 
Schau Dir mal das Schaltbild zum STK500 an.

> Eine kleine frage hätte ich noch.. Ich hab jetzt in meiner Harmony One
> den Videorekorder Toshiba VT-728G aus der Tabelle hinzugefügt und mal
> versucht mit

if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     //
> NEC-Protokoll
>           irmp_data.address == 23364)                   // Adresse

> das Protokoll heraus zu filtern was nicht geklappt hat. Das NEC filtert
> er noch nur mit der Adresse passiert nichts. Mit 23364 0x23364 und
> 0x5b44 getestet. Denke ich falsch :?

Ich vermute, das hat historische Gründe. Früher (ziemlich am Anfang der 
Entwicklung) wurde im IRMP nicht berücksichtigt, dass beim NEC-Protokoll 
das LSB zuerst gesandt wird. Die Werte im Artikel könnten also 
"Bit-gespiegelt" sein.

dez     binär             hex
23364 = 101101101000100 = 0x5B44

Probiere mal:

dez     binär             hex
 4461 = 001000101101101 = 0x116D

Ich würde da also nicht so viel drauf geben. Am besten, ich lösche diese 
Tabelle, denn viel bringt sie sowieso nicht.

Hast Du keine Möglichkeit, Protokoll, Adresse und Kommando über den UART 
zu senden oder auf einem Display auszugeben?

Ich weiß ja nicht, was Du vorhast, aber das eleganteste ist, die FB 
anzulernen: Einmal Taste drücken, Protokoll, Adresse und Kommando im 
EEPROM speichern. Dann kannst Du später jederzeit diese Taste wieder 
identifizieren.

[Thomas (Gast)]

Ich hab das Gerät aus der Tabelle ausgesucht weil ich es mir einfach 
machen wollte und mir sowieso ein Gerät ausdenken muss welches ich in 
der Harmony One einprogrammiere. Mit 4461 ud 0x116D klappt es auch 
nicht.

Frank M. schrieb:
> Hast Du keine Möglichkeit, Protokoll, Adresse und Kommando über den UART
> zu senden oder auf einem Display auszugeben?

Ja, ich hoffe nur das das auch richtig ist was ich gemacht habe... hab 
den scan aus HTerm mal angehängt. Wenn ich das dann auswerte kommt 
eigentlich nicht viel sinnvolles (für mich) raus hauptsächlich steht 
dann da protocol = UNKNOWN. Was allerdings auch mit sämtlichen scans aus 
dem IR-Data Ordner passiert.

Das ganze soll mal eine Licht- und Steckdosensteuerung werden und 
hauptsächlich meine Funksteckdosen ersetzten das ich wirklich nurnoch 
die Harmony One als Fernbedienung rumliegen habe.

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Ja, ich hoffe nur das das auch richtig ist was ich gemacht habe...

Hm, das soll ein Scan sein? Kann nicht sein, da steht nur Mist drin, 
nämlich 00110000 bzw. 00110001. Und die Blanks dazwischen können auch 
kein Scan-Output sein. Wie hast Du das gemacht?

Aber wenn IRMP sowieso die FB erkennt, dann brauchst Du doch gar nicht 
zu scannen, er reicht doch dann einfach,

  irmp_data.protocol
  irmp_data.address
  irmp_data.command

auf dem UART auszugeben.

Beispiel:

  char buf[20];
  ...
  uart_init ();
  ....

  if (irmp_get_data (&irmp_data))
  {
    itoa (irmp_data.protocol, buf, 10);   // protocol in decimal
    uart_puts (buf);
    uart_putc (' ');
    itoa (irmp_data.address, buf, 16);   // address in hex
    uart_puts (buf);
    uart_putc (' ');
    itoa (irmp_data.command, buf, 16);   // command in hex
    uart_puts (buf);
    uart_putc ('\r');
    uart_putc ('\n');
  }

Jetzt brauchst Du nur noch 3 Funktionen:

uart_init ();
uart_puts ();
uart_putc ();

Entweder holst Du Dir die UART-Fleury-Lib oder kopierst die 
entsprechenden Funktionen irmp_uart_init() usw. aus irmp.c raus, steckst 
sie in Dein main.c und benennst sie um, indem Du das Prefex "irmp_" aus 
den Funktionsnamen rauslöschst. Vielleicht hast Du ja auch eigene 
UART-Routinen?

[Thomas (Gast)]

Frank M. schrieb:
> Hm, das soll ein Scan sein? Kann nicht sein, da steht nur Mist drin,
> nämlich 00110000 bzw. 00110001. Und die Blanks dazwischen können auch
> kein Scan-Output sein. Wie hast Du das gemacht?

Wenn ich das wüsste.. war schon glücklich das HTerm überhaupt was 
ausgespuckt hat :D hab zuvor noch nie mitm UART was gemacht.

Puh! da muss ich mich erstmal einarbeiten. So ganz nachvollziehbar ist 
das mit dem UART noch nicht für mich, scheint etwas komplizierter zu 
werden. Im zweifelsfall geht es erstmal auch so da erstaunlicherweise 
ich kein Gerät habe das das NEC Protokoll verwendet.

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Puh! da muss ich mich erstmal einarbeiten.

Sorry, IRMP ist kein fertiges Programm, eher eine Programmbibliothek. 
Wenn Du etwas mit IRMP anstellen möchtest, musst Du das "Drumherum" 
(sprich: Deine Anwendung) schon selbst auf die Beine stellen. Da sind 
UART-Routinen auch für Deine Anwendung - zumindest fürs Debugging - 
sinnvoll.

[Daniel C. (cecky)]

Hi,

wollte an dieser Stelle einfach mal bedanken!!
Hab IRMP heute zum ersten mal getestet, und es hat nicht mal 30 Minuten 
gedauert (inkl. Hardwareaufbau), und alle 6 Fernbedienungen die ich hier 
zur Hand habe wurden einwandfrei erkannt. Cooles Projekt und meine 
Hochachtung!

Gruß Cecky

[Thomas (Gast)]

Das ist mir klar wollte nur sagen das ich dafür wohl ne weile brauch bis 
ich da durch steig. Und ohne Herausforderungen wäre es ja auch 
langweilig! Trotzdem habe ich die letzten tage sehr viel gerlernt.
Aufjedenfall danke für die Hilfe und das tolle Programm!

Gruß Thomas

[Frank M. (ukw) (Moderator)]

Daniel C. schrieb:
> Hab IRMP heute zum ersten mal getestet, und es hat nicht mal 30 Minuten
> gedauert (inkl. Hardwareaufbau), und alle 6 Fernbedienungen die ich hier
> zur Hand habe wurden einwandfrei erkannt. Cooles Projekt und meine
> Hochachtung!

Danke fürs Danke. Viel Spaß noch mit IRMP :-)

[Frank M. (ukw) (Moderator)]

Thomas schrieb:
> Das ist mir klar wollte nur sagen das ich dafür wohl ne weile brauch bis
> ich da durch steig.

Da muss man sich halt durchbeissen. Aber wenns dabei auch noch Spaß 
macht, wird es Dir bestimmt gelingen :-)

> Und ohne Herausforderungen wäre es ja auch langweilig!

Eben. Drücke Dir die Daumen. Es ist noch kein Meister vom Himmel 
gefallen.

> Trotzdem habe ich die letzten tage sehr viel gerlernt.
> Aufjedenfall danke für die Hilfe und das tolle Programm!

Danke und Gruß,

Frank

[Thorsten (Gast)]

Hallo zusammen,

auch von mir erstmal ein herzliches Danke für die tolle Bibliothek. Ich 
habe IRMP inzwischen auf einem PIC24F und einem PIC32 laufen und bin 
absolut begeistert.

Alle Fernbedienungen, welche ich hier so rumliegen habe funktionieren - 
bis auf eine: Eine Fernbedienung von einer alten Sky Digibox für SKY UK.

Daher meine Frage: Hat jemand so eine Fernbedienung schon zum laufen 
gebracht ?

Gruß
Thorsten

[Frank M. (ukw) (Moderator)]

Thorsten schrieb:

> auch von mir erstmal ein herzliches Danke für die tolle Bibliothek.

Danke :-)

> Alle Fernbedienungen, welche ich hier so rumliegen habe funktionieren -
> bis auf eine: Eine Fernbedienung von einer alten Sky Digibox für SKY UK.

Du könntest ein paar Scans erstellen, dann kann ich Dir mehr sagen. Das 
Logging über IRMP_LOGGING ist aber nur für AVRs realisiert. Für PICs 
gibt es noch IRMP_EXT_LOGGING, welches den Quellcode in irmpextlog.c 
aktiviert. Dafür ist aber eine USB-Schnittstelle erforderlich. 
Vielleicht kannst Du damit was anfangen?

[eku (Gast)]

Hallo Frank,

ist zwar schon wieder ein halbes Jahr her, aber das Thema ist noch 
aktuell.
Du testest mit den im IR-Data Verzeichnis gespeicherten Scans. Und genau 
die Sharp-Scans passieren des Test nicht:

got unexpected inverted command, ignoring it

Es wird kein Code dekodiert. Einkompiliert auschließlich Denon!

Wenn es Deine Zeit erlaubt, nimm Dich bitte des Themas an. Wie ich im 
April schrieb, wird das Sharp Protokoll seit meinem Umstieg von Rev 71 
auf eine neuere Version nicht länger erkannt. Freilich könnte ich auf 
Rev 71 zurückgehen, verliere dann aber die für mich wichtigen 
Korrekturen im Denon Dekoder.

[Frank M. (ukw) (Moderator)]

Hallo eku,

eku schrieb:
> Du testest mit den im IR-Data Verzeichnis gespeicherten Scans. Und genau
> die Sharp-Scans passieren des Test nicht:
>
> got unexpected inverted command, ignoring it

Kann ich nachvollziehen mit

   irmp-10kHz -v < sharp-denon.txt
bzw.
   irmp-10kHz -v < sharp-denon2.txt

Schaue ich mir dieses Wochenende an.

Gruß,

Frank

[Shottky (Gast)]

Hallo Leute!

Ich bin gerade dabei das IRMP auf nem 8-Bitter (PIC16F1823) zu
portieren. Der Compiler ist CCS C Compiler.

Habe aus meiner Sicht alles beachtet was laut dem Artikel von Frank
M. (http://www.mikrocontroller.net/articles/IRMP#F_INTERRUPTS) für die 
Portierung notwendig ist.

Der Timerinterrupt ist auf 15625 interrupts pro Sec. eingestellt und der 
richtige Port für den Sensor habe ich auch ausgewählt. Die 
main()-Routine kann ich gerne bei bedarf posten.

Jedoch habe ich Probleme mit allen (!) Funktionen, die in der irmp.h 
stehen:

extern void                             irmp_init (void);
extern uint8_t                          irmp_get_data (IRMP_DATA *);
extern uint8_t                          irmp_is_busy (void);
extern uint8_t                          irmp_ISR (void);

Mein Compiler zeigt dabei für jede oben genannte Funktion die 
Fehlermeldung, das die Funktion genutzt, aber nicht definiert ist.

Hier der Ausschnitt für das Fehlen von irmp_get_data():
"Error 112 "main.c" Line 35(1,1): Function used but not defined:  ... 
irmp_get_data SCR=1896"

Kann mir jemand hier weiterhelfen, irgendein Tip?
Hatte jemand schon mal das selbe Problem?
Ich komme hier nicht mehr weiter...

Schonmal vielen Dank!
Shottky

[jar (Gast)]

Shottky schrieb:
> Hier der Ausschnitt für das Fehlen von irmp_get_data():
> "Error 112 "main.c" Line 35(1,1): Function used but not defined:  ...
> irmp_get_data SCR=1896"

fehlt das #include ?



WICHTIG
    Im Applikations-Source sollte nur irmp.h per include eingefügt 
werden, also lediglich:

#include "irmp.h"

Alle anderen Include-Dateien werden automatisch über irmp.h "eingefügt". 
Siehe dazu auch die Beispieldatei main.c.

Desweiteren muss die Preprocessor-Konstante F_CPU im Projekt bzw. 
Makefile gesetzt werden. Diese sollte mindestens den Wert 8000000UL 
haben, der Prozessor sollte also zumindest mit 8 MHz laufen.

[Shottky (Gast)]

jar schrieb:
> fehlt das #include ?

Ja, ich habe das Include-File eingefügt.


> Desweiteren muss die Preprocessor-Konstante F_CPU im Projekt bzw.
> Makefile gesetzt werden.

Das habe ich als global #define in den Built Options von MPLAB 
definiert.

Ich hab hier mal mein main.c-File:

#include <16F1823.h>
#include <stdio.h>

#fuses NOMCLR,NOPROTECT,NOWDT
#use delay(clock = 32000000)  // Quarz 32 MHz


#include "irmp.h"

#ifndef F_CPU
#error F_CPU unkown
#endif

#INT_TIMER0
void testfunc_for_timer(){
    
  irmp_ISR();
    //delay_ms(2000);
    output_high(PIN_C0); // LED ON
    //delay_ms(1000);
    //output_low(PIN_C0); //LED OFF 
  
}
    
void main(){
   
  IRMP_DATA irmp_data;  
  irmp_init();

  setup_oscillator(OSC_16MHZ);
 
  // set port c as an output
    set_tris_c(0b0000000);
    
    setup_timer_0 (RTCC_INTERNAL|RTCC_DIV_1|RTCC_8_BIT); //(16Mhz/4)/RTCC_DIV_1=15625 interrupts per second
    enable_interrupts(INT_TIMER0); 
    enable_interrupts(GLOBAL);
  set_timer0(0); //

    while(true)
  {
  //set_timer0(120); //
  output_low(PIN_C0); // LED OFF
  if (irmp_get_data(&irmp_data))
  {
    if (irmp_data.protocol < 50)                   // Adresse 0x1234
    {
    }
  }


  }// end while
}// end main()

[jar (Gast)]

gibt es bei dir uint8_t nicht ?

[Shottky (Gast)]

Hallo jar!

jar schrieb:
> gibt es bei dir uint8_t nicht ?

Das sollte ja eigentlich mittels typedef in der irmpsystem.h definiert 
werden:

#if defined(PIC_CCS) || defined(PIC_C18) || defined(ARM_STM32)
typedef unsigned char                   uint8_t;
typedef unsigned short                  uint16_t;
#endif

Gruß Shottky

[jar (Gast)]

also du hast #include "irmp.h"
 drin und trotzdem kennt er nicht for Prototypen ? ist da ein 
Pfadproblem ?

[jar (Gast)]

streiche for ersetze die

[Shottky (Gast)]

jar schrieb:
> also du hast #include "irmp.h"
>  drin und trotzdem kennt er nicht for Prototypen ?

Ja genau

>  ist da ein Pfadproblem ?

Die Files: irmp.c, irmpprotocols.h, irmpsystem.h, irmp.h und 
irmpconfig.h habe ich allesamt im selben Verzeichnis wie das 
main.c-File. Dadurch sollte  eig. kein Pfadproblemauftreten, oder?

Kann es sein, dass ich zusätzlich im Project-File von MPLAB was 
ändern/einstellen muss?

Gruß Shottky

[jar (Gast)]

Shottky schrieb:
> dass ich zusätzlich im Project-File von MPLAB was
> ändern/einstellen muss?

wie wäre es mit irmp.c einbinden ?

[Shottky (Gast)]

jar schrieb:
> wie wäre es mit irmp.c einbinden ?

Auch das hat leider nichts bewirkt :-(
kA was ich jetzt noch austesten könnte.

[jar (Gast)]

Shottky schrieb:
> kA

ich auch nicht, kenne die PIC Umgebung nicht

[Shottky (Gast)]

jar schrieb:
> ich auch nicht, kenne die PIC Umgebung nicht

IRMP wurde doch schon auf nem PIC portiert.
Vlt. kann mir jemand, der das schon gemacht hat, weiterhelfen?
Oder sagen mit welcher Entwicklungsumgebung IRMP erfolgreich portiert 
wurde?


Gruß Shottky

[Sebastian .. (zahlenfreak)]

Hallo Frank,

ich habe gerade zwei Abende damit Verbracht, IRSND auf einem Tiny44 zum 
laufen zu bringen. Jetzt läuft es zum glück - wie bei IRMP ist das super 
Software!

Das Problem war schlussendlich, dass der Timer1 Compare interrupt aus 
deinem Beispiel-main file vom Compiler nicht in der Interrupttabelle 
angelegt wurde. Sobald ich als Vektor nicht TIMER1_COMPA_vect sondern 
TIM1_COMPA_vect angegeben habe gings.

Mir ist klar, dass das nicht mehr so ganz zum Projekt gehört, aber 
vielleicht kennst du ja die Hintergründe dazu? Der Compiler meckert bei 
beiden Namen nicht. Nur dass halt bei TIMER1_COMPA_vect kein 
Interruptvektor angelegt wird.

Viele Grüße,

Sebastian

[jar (Gast)]

Sebastian ... schrieb:
> Das Problem war schlussendlich, dass der Timer1 Compare interrupt aus
> deinem Beispiel-main file vom Compiler nicht in der Interrupttabelle
> angelegt wurde. Sobald ich als Vektor nicht TIMER1_COMPA_vect sondern
> TIM1_COMPA_vect angegeben habe gings.
>
> Mir ist klar, dass das nicht mehr so ganz zum Projekt gehört, aber
> vielleicht kennst du ja die Hintergründe dazu? Der Compiler meckert bei
> beiden Namen nicht. Nur dass halt bei TIMER1_COMPA_vect kein
> Interruptvektor angelegt wird.

die Hintergründe kenne ich nicht, aber das kein Vector angelegt wird ist 
klar weil in

"C:\PROGRAMME\ATMEL\WinAVR-20100110\avr\include\avr\iotn44a.h"(554) 
#define TIM1_COMPA_vect_num  6
"C:\PROGRAMME\ATMEL\WinAVR-20100110\avr\include\avr\iotn44a.h"(555) 
#define TIM1_COMPA_vect      _VECTOR(6)  /* Timer/Counter1 Compare Match 
A */
"C:\PROGRAMME\ATMEL\WinAVR-20100110\avr\include\avr\iotnx4.h"(410) 
#define TIM1_COMPA_vect      _VECTOR(6)

das #define nun mal so ist wie du festgestellt hast, Abhilfe

neues #define einfügen (würde ich machen, denn das es fehlerhafte Header 
gibt ist ja nicht auszuschliessen)

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:
> Das Problem war schlussendlich, dass der Timer1 Compare interrupt aus
> deinem Beispiel-main file vom Compiler nicht in der Interrupttabelle
> angelegt wurde. Sobald ich als Vektor nicht TIMER1_COMPA_vect sondern
> TIM1_COMPA_vect angegeben habe gings.

Komisch, in der aktuellen irsndmain.c steht drin:

#ifdef TIM1_COMPA_vect                                                      // ATtiny84
#define COMPA_VECT  TIM1_COMPA_vect
#else
#define COMPA_VECT  TIMER1_COMPA_vect                                       // ATmega
#endif

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * timer 1 compare handler, called every 1/10000 sec
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
ISR(COMPA_VECT)                                                             // Timer1 output compare A interrupt service routine, called every 1/15000 sec
{
    (void) irsnd_ISR();                                                     // call irsnd ISR
    // call other timer interrupt routines here...
}

Hier wird also der TIM1_COMPA_vect verwendet.

Ohne diesen speziellen define oben schmeisst mein avr-gcc aus:

../irsndmain.c:49:1: warning: 'TIMER1_COMPA_vect' appears to be a 
misspelled signal handler [enabled by default]

Welche IRMP-Version verwendest Du?

[Sebastian .. (zahlenfreak)]

Habe die Version 2.3.1 die im wiki-Artikel verlinkt ist verwendet. Da 
gibts die Defines zur Interruptbezeichnung noch nicht. Im SVN hab ich 
die defines jetzt auch grade gesehen. Da sollte man vielleicht noch den 
Link im wiki updaten.


Übrigens sind die Pinbelegungen auf dem Tiny44 und dem Tiny24 genau 
gleich wie auf dem 84er. Die könnte man also auch sehr einfach noch 
dazufügen. Zumindest im Tiny44 passt IRSND (mit optimierung) auch ganz 
gut rein.

Viele Grüße,

Sebastian

[Frank M. (ukw) (Moderator)]

Sebastian ... schrieb:
> Habe die Version 2.3.1 die im wiki-Artikel verlinkt ist verwendet. Da
> gibts die Defines zur Interruptbezeichnung noch nicht. Im SVN hab ich
> die defines jetzt auch grade gesehen. Da sollte man vielleicht noch den
> Link im wiki updaten.

Du hast recht. Werde ich aktualisieren.

> Übrigens sind die Pinbelegungen auf dem Tiny44 und dem Tiny24 genau
> gleich wie auf dem 84er. Die könnte man also auch sehr einfach noch
> dazufügen. Zumindest im Tiny44 passt IRSND (mit optimierung) auch ganz
> gut rein.

Ja, ist mir eben auch aufgefallen, als ich mir die entsprechenden 
Stellen im Source ansah. Deshalb habe ich den Quelltext eben um den 
Tiny44 erweitert. Der Tiny24 macht da wohl weniger Sinn.

Heute abend mache ich ein Update.

Vielen Dank,

Frank

[eku (Gast)]

Hallo Frank,

Frank M. schrieb:
> Kann ich nachvollziehen mit
>
>    irmp-10kHz -v < sharp-denon.txt
> bzw.
>    irmp-10kHz -v < sharp-denon2.txt
>
> Schaue ich mir dieses Wochenende an.

schon die Ursache gefunden?

[Frank M. (ukw) (Moderator)]

Hallo eku,

eku schrieb:
> schon die Ursache gefunden?

Mittlerweile ja. Ich hattezuletzt irgendwann eine "verbesserte" 
Erkennung von nicht-invertierenden und invertierenden Denon-Frames 
eingebaut. Kriterium waren dafür die letzten beiden Bits im Frame: Diese 
waren entweder 00 oder 11.

Nun scheint Sharp bei Verwendung des Denon-Protokolls zu tricksen: Sie 
verwenden die beiden letzten Bits als normale Daten-Bits, nämlich die 
Werte 01 und 10, die es im "korrekten" Denon-Protokoll ja gar nicht 
gibt. Dafür lassen sie dann aber auch den invertierten 
Wiederholungsframe weg, der eigentlich zusätzliche Datensicherheit geben 
soll.

Ich habe das im IRMP nun so gelöst:

Sind die beiden letzten Bits...

  00 Standard-Denon, dann warte auf invertierten Wiederholungsframe
  11 Standard-Denon, dann ist dies der invertierte Wiederholungsframe
  10 kein Standard, dann gibt es keinen invertierten Wiederholungsframe
  01 dito

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Die Version 2.3.6 von IRMP und IRSND ist nun als Download verfügbar:

IRMP:

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

  Software-Änderungen seit 2.3.1:

  - Korrekturen Frame-Erkennung beim DENON-Protokoll
  - Neues Protokoll: A1TVBOX
  - Verbesserte Erkennung von DENON-Wiederholungsframes
  - Portierung auf Stellaris LM4F120 Launchpad von TI (ARM Cortex M4)

IRSND:

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

  Software-Änderungen seit 2.3.1:

  - Support für ATtiny44 hinzugefügt
  - Neues Protokoll: A1TVBOX
  - Korrektur Timing beim NIKON-Protokoll

Viel Spaß mit IRMP!

Frank

[Ulli (Gast)]

Hi Frank,

ich habe gerade das Problem das ich den Timer 0 meines Atmega32 auf den 
prescaler 64 stellen muss. Mithilfe des Timer0 erzeuge ich aber das 
Sendesignal des IRSND.

Sehst du eine Chance das irsnd auch mit dem prescaler funktioniert?

[Ulli (Gast)]

oder noch besser.

Hast du eine Idee wie ich die wiring.c Datei auf die timer0 
Einstellungen von irsnd resultierend anpassen kann?

habe IRSND auf folgende konfiguration
#  define F_INTERRUPTS                           14925

[Frank M. (ukw) (Moderator)]

Ulli schrieb:
> ich habe gerade das Problem das ich den Timer 0 meines Atmega32 auf den
> prescaler 64 stellen muss. Mithilfe des Timer0 erzeuge ich aber das
> Sendesignal des IRSND.

Es geht um Arduino, nicht wahr? Das Problem ist, dass die 
Arduino-Runtime-Lib die Timer selbst benutzt. Das kann dann zu größeren 
Problemen an anderen Stellen führen, wenn man daran rumschraubt.

Habe es gerade mal eben durchgerechnet:

Bei einem Prescaler von 64 gehen ist die maximal mögliche Frequenz 
38kHz, wobei die Abweichung dabei ca. 10% beträgt. Statt 38kHz kommen 
dann ca. 35 und ein paar zerquetschte kHz raus. Das kann gutgehen, kann 
aber auch nicht. Auf jeden Fall wird die Reichweite stark eingeschränkt.

Musst Du das unbedingt mit einem Arduino machen? Alternative wäre ein 
ATTiny45, an den Du die IR-Diode nebst Transistor anschließt und den 
ATTiny über Software-UART mit Deinem Arduino-System verbindest.

Gruß,

Frank

[Ulli (Gast)]

Ja ich möchte alles in den Arduino packen.
Es läuft auch alles sehr gut, solange ich es getrennt laufen lasse.

Das Problem ist das meine andere Funktion die Funktion micros() nutzt. 
Diese berechnet jetzt aber nach Anpassung der Timer0 Einstellung von 
irsnd nicht mehr richtig.

Ich schaffe es aber leider nicht die micros funktion auf die neuen 
einstellungen durch IRSND anzupassen.
Theoretich müsste ich ja nur den neuen Takt in die micros berechnung mit 
einbeziehen....

[Ulli (Gast)]

Habe die Lösung gefunden.
Die timing Funktionen welche auf Timer0 basieren auf der Arduino 
Plattform habe ich jetzt umgeschrieben.
Somit läuft IRSND & IRMP & mircos()..... einwandfrei auf einem Board.

Alle die das selbe Problem haben. Anbei die neuen timing funktionen :)

Trotzdem nochmal danke an Frank für die Spitzen IR Anwendung!!!

[eku (Gast)]

Hallo Frank,

Frank M. schrieb:
> Ich habe das im IRMP nun so gelöst:

IRMP erkennt nun wieder die Codes meiner FB, aber liefert mir für jeden 
Code drei Ergebnisse der Art:

D: RX 08 0010 0142 00 (DENON) <- korrekt
D: RX 08 0010 02BD 00 (DENON) <- Müll
D: RX 08 0010 0142 00 (DENON) <- korrekt

Rev. 71 von IRMP dekodiert hingegen korrekt.

Ich habe einenen neuen Scan der Tasten 0-9 sowie die Resultate von IRMP 
angehangen.

[Ulli (Gast)]

Hallo Frank,

jetzt habe ich noch eine HW Frage. Meine derzeitige IR-Diode 
funktioniert leider nur wenn ich Sie direkt auf das Zielgerät richte.
Kannst du eine Diode empfehlen, die dafür besser geeignet ist?
Großer Öffnungswinkel und Leuchtstärke?

Die Verschaltung ist entsprechend deinem Vorschlag. 4.7kOhm, BC337 und 
33Ohm.

Danke.

[jar (Gast)]

welche Diode hast du, es gibt halt von 880nm bis 950nm viele Dioden die 
als IR zählen.

zuerst sollte man 950nm Dioden wählen
der Rv mit 33 Ohm sieht gut aus, der Transistor Rv 4,7k Ohm erscheint 
mir zu hoch, setzt ja eine Stromverstärkung von mindestens 150 voraus, 
ich guck nun nicht das ß vom Trasi aus, würde erst mal auf 2,2k gehen um 
den Tasi in die Sättigung zu fahren, den Rv auf 22 Ohm verringern, im 
Impulsbetrieb können die IR Dioden ruhig bis 1A fahren.

Dioden mit breiterem Winkel, ich finde 15-50° sind halt schwächer, 
eventuell ist deine IR Frequenz falsch, die Empfänger erwarten ja 
zwischen 30-40 kHz üblicherweise, die im IRMP gewählte Empfangsfrequenz 
ist oft auf 36 kHz genommen weil damit der Bereich 30-40 gut abgedeckt 
ist, für Reichweite sollte aber die genaue genommen werden.

Also probiere deine IR Diode zuerst mit Frequenzen von 30-40 kHz für 
Reichweite ! dann kannst du mit verschiedenen Dioden den Winkel 
ermitteln der dir passt, später noch die IR Frequenz von 880nm - 950 nm 
varieren

dummerweise gibt es im freien Handel nicht alle Dioden von 880nm-950nm 
in allen Winkeln von 15-50°

also hilft nur probieren, Dioden nm, IR Frequenz, Winkel, die beste 
Diode noch trimmen in "Überstrom bis 1A"

[Frank M. (ukw) (Moderator)]

Hallo eku,

eku schrieb:

> IRMP erkennt nun wieder die Codes meiner FB, aber liefert mir für jeden
> Code drei Ergebnisse der Art:

Das liegt an meiner letzten Änderung, die ich aufgrund Deines Hinweises 
bzgl. sharp-denon.txt und sharp-denon2.txt gemacht habe.

> D: RX 08 0010 0142 00 (DENON) <- korrekt
> D: RX 08 0010 02BD 00 (DENON) <- Müll
> D: RX 08 0010 0142 00 (DENON) <- korrekt

Ich habe IRMP nun dermaßen angepasst, dass nur noch das letzte Bit 
darauf geprüft wird, ob ein Denon-Wiederholungsframe vorliegt oder 
nicht. Die Änderung ist im SVN eingecheckt. Damit sollte es nun gehen.

Allerdings habe ich nun sharp-denon.txt und sharp-denon2.txt aus 
test-suite.sh rausgeworfen. Da diese Scans uralt sind und dort die 
nötigen Denon-Wiederholungsframes fehlen, sind sie nicht mehr für die 
Beurteilung der IRMP-Erkennungsqualität relevant. Stattdessen habe ich 
nun in die Test-Suite neu übernommen:

sharp_15khz.txt
sharp_kurz_10khz.txt
sharp_lang_10khz.txt

Damit haben wir nun Scans, wo der initiale Frame mit der Bitfolge 00 
(nicht invertiert) beginnt bzw. mit der Folge 10.

> Ich habe einenen neuen Scan der Tasten 0-9 sowie die Resultate von IRMP
> angehangen.

Danke, hat mir weitergeholfen.

Gruß,

Frank

P.S.
Die Erkennung der unterschiedlichsten Form der Denon-Frames bringt mich 
noch um den letzten Nerv. Meines Erachtens hat dieses Protokoll 
grundlegende Designfehler.

[jar (Gast)]

Frank M. schrieb:
> Die Änderung ist im SVN eingecheckt. Damit sollte es nun gehen.

ist svn und tarball immer synchron ?

ich hab die letzte Version (vor heute) in mein Projekt eingepflegt aber 
nix funktioniert.

auffällig war das ich nun nicht mehr irmpconfig.h einbinden muss.

ich hatte mehrfach die Einbindung, alten Code neuen Code versucht um 
Fehlbedienungen meinerseits auszuschliessen, aber mit dem vorletzten 
Code bekomme ich kein Ergebnis, muss ich noch mal die Variablen prüfen ? 
hast du da was geändert, oder an den Laufzeiten ?

[Frank M. (ukw) (Moderator)]

Hallo Ulli,

Ulli schrieb:
> jetzt habe ich noch eine HW Frage. Meine derzeitige IR-Diode
> funktioniert leider nur wenn ich Sie direkt auf das Zielgerät richte.
> [...]
> Die Verschaltung ist entsprechend deinem Vorschlag. 4.7kOhm, BC337 und
> 33Ohm.

Ändere mal den Vorwiderstand von 4.7kOhm auf 1kOhm, so wie es im Artikel 
unterhalb des Schaltbildes in der Bemerkung steht.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

jar schrieb:
> ist svn und tarball immer synchron ?

Der tarball des SVNs wird ja aus dem SVN erzeugt.

Oder meinst Du den Download-Link der zip-Datei? Im Zweifel ist das SVN 
immer aktueller als der Download-Link der zip-Datei im Artikel. 
Letzteren habe ich aber gerade auch noch aktualisiert, so dass nun die 
aktuelle (SVN) und die Release-Version (irmp.zip im Artikel) identisch 
sind.

> auffällig war das ich nun nicht mehr irmpconfig.h einbinden muss.

Schon lange nicht mehr! Siehe roten Kasten unter:

  http://www.mikrocontroller.net/articles/IRMP#Source-Code

> ich hatte mehrfach die Einbindung, alten Code neuen Code versucht um
> Fehlbedienungen meinerseits auszuschliessen, aber mit dem vorletzten
> Code bekomme ich kein Ergebnis, muss ich noch mal die Variablen prüfen ?

Zeig einfach mal Deinen Code.

> hast du da was geändert, oder an den Laufzeiten ?

Nein, nichts grundlegendes.

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> Zeig einfach mal Deinen Code.

die ISR

//---------------------------------------------------------------------------------------------------------------------------------------------------
// timer 0 compare handler, called every F_CPU/512 = 512/8000000 = 64µsec
//---------------------------------------------------------------------------------------------------------------------------------------------------
//
ISR(TIMER0_OVF_vect)
{  extern volatile UWORD count__;
  cli();
  count__++;
  TCNT0 = -2;          // 2 * 256 = 512 cycle      // preload for 250µs RC5
  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
  }
  sei();
}

das Menü / IRMP zeigen

void _Irmp(void)
{  // "16.IRMP"
  __p=_IRMP;
  lcd_set(); 
  lcd_gotoxy(0,0); lcd_puts_p(menus[__p]); 
  lcd_gotoxy(0,1); lcd_puts("R: Code:            ");
  lcd_gotoxy(0,2); lcd_puts("A:                  ");
  lcd_gotoxy(0,3); lcd_puts("C:                  ");
  irPOWER(ON);
}

irmpconfig.h (Ausschnitt)

#ifndef F_INTERRUPTS
#define F_INTERRUPTS                            F_CPU/512 // mit 8000000 int RC und Teiler 256 TCNT0=-2
//#define F_INTERRUPTS                            15000   // interrupts per second, min: 10000, max: 20000, typ: 15000
#endif

#if defined (PIC_C18)                                                   // Microchip C18 Compiler
#include <p18cxxx.h>                                                    // main PIC18 h file

#define IRMP_PIN                                PORTBbits.RB4           // use RB4 as IR input on PIC
#define input(x)                                (x)
#elif defined (PIC_CCS_COMPILER)                                        // PIC CCS Compiler:
#define IRMP_PIN                                PIN_B4                  // use PB4 as IR input on PIC
#else                                                                   // AVR:
#define IRMP_PORT                               PORTD
#define IRMP_DDR                                DDRD
#define IRMP_PIN                                PIND
#define IRMP_BIT                                6                       // use PB6 as IR input on AVR
#define input(x)                                ((x) & (1 << IRMP_BIT))
#endif

ich nutze einen m1284p (übrigens den 1284 scheint es nicht mehr käuflich 
zu geben, die p sind neuer aber gleich) du hast aber irgendwo defines 
für m644 und m664p drin, aber nur m1284 ohne p

im main loop:

    if(__p==_IRMP)
    {  if (irmp_get_data(&irmp_data))
       {
        sek10=0;
        wait_sec=20;
        if(irmp_data.protocol == IRMP_KASEIKYO_PROTOCOL)
          gelbLED(100);
        else
          gruenLED(100);

        lcd_gotoxy(0,1); lcd_puts("R: Code: "); lcd_puts(trimm_string(' ', irmp_protocol_names[irmp_data.protocol], 8));
        lcd_gotoxy(0,2); lcd_puts("A: "); 
        strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.address,s,16)); lcd_puts(trimm_string(' ', s2, 6)); 
        strcpy(s2, "("); strcat(s2, utoa(irmp_data.address,s,10)); strcat(s2, "d)");
        lcd_gotoxy(11,2); lcd_puts(trimm_string(' ', s2, 8));
        lcd_gotoxy(0,3); lcd_puts("C: ");
        strcpy(s2, "0x"); strcat(s2, utoa(irmp_data.command,s,16));  lcd_puts(trimm_string(' ', s2, 6)); 
        strcpy(s2, "("); strcat(s2, utoa(irmp_data.command,s,10)); strcat(s2, "d)");
        lcd_gotoxy(11,3); lcd_puts(trimm_string(' ', s2, 8));
        lcd_gotoxy(12,4); 
        if(irmp_data.protocol==IRMP_RC5_PROTOCOL)
        {  lcd_puts("("); lcd_puts(utoa((irmp_data.address*100+irmp_data.command),s,10)); lcd_puts(")");
        }
        else
          lcd_puts("          ");
        #if IRMP_LOGGING != 0       // 1: log IR signal (scan), 0: do not (default)
          strcpy(temp2,"# Code: "); strcat(temp2,trimm_string(' ', irmp_protocol_names[irmp_data.protocol], 8));
          strcat(temp2,", A: ");  strcat(temp2,utoa(irmp_data.address,s,16)); 
          strcat(temp2,", C: ");  strcat(temp2,utoa(irmp_data.command,s,16)); 
          strcat(temp2,"\r\n");
          if(strlen(temp2_bak)==0)
          uart_puts(temp2);
          if (strcmp(temp2, temp2_bak)!=0)
          {  strcpy(temp2_bak, temp2);
            uart_puts(temp2);
                }
        #endif
        while(irmp_get_data(&irmp_data));
      } // if (irmp_get_data(&irmp_data))
      if (wait_sec)
      {  lcd_gotoxy(16,0); lcd_puts(trimm_string(' ', itoa(wait_sec,s,10), 3));}
      else
      {  lcd_gotoxy(0,1); lcd_puts("R: Code:             ");
        lcd_gotoxy(0,2); lcd_puts("A:                   "); 
        lcd_gotoxy(0,3); lcd_puts("C:                   ");
        lcd_gotoxy(0,4); lcd_puts("                     ");
        lcd_gotoxy(16,0); lcd_puts(trimm_string(' ', itoa(0,s,10), 3));
        sek10=0;
      }
    } // if(__p==_IRMP)

[Frank M. (ukw) (Moderator)]

jar schrieb:
>

> ISR(TIMER0_OVF_vect)
> {  extern volatile UWORD count__;
>   cli();
>   count__++;
>   TCNT0 = -2;          // 2 * 256 = 512 cycle      // preload for 250µs
> RC5
>   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
>   }
>   sei();
> }
>

cli() und sei() haben in einer ISR nichts zu suchen. Das macht das 
Runtime-System sowieso schon. Warum dekrementierst Du TCNT0? Wieso 
benutzt Du Timer0 und nicht Timer1? Wo ist die Timer-Initialisierung? 
Hast Du das mal ohne rc5_ISR() probiert? Funktioniert die rc5_ISR() denn 
noch? Warum benutzt Du Variablen mit fürhrendem Underscore, die in C 
prinzipiell der Runtime-Lib vorbehalten sind?

> #define IRMP_PORT                               PORTD
> #define IRMP_DDR                                DDRD
> #define IRMP_PIN                                PIND
> #define IRMP_BIT                                6

Gibt es schon lange nicht mehr! Welche Version benutzt Du da? Kann es 
sein, dass Du versuchst, eine uralte irmpconfig.h mit dem neuesten IRMP 
zum laufen zu bringen? Das geht nicht! Benutze bitte immer die 
irmpconfig.h, die auch im Source enthalten ist.

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> cli() und sei() haben in einer ISR nichts zu suchen. Das macht das
> Runtime-System sowieso schon.

OK, bis jetzt hats auch nicht geschadet, ist historisch gewachsen

> Warum dekrementierst Du TCNT0? Wieso
> benutzt Du Timer0 und nicht Timer1?

Timer 1 ist belegt

> Wo ist die Timer-Initialisierung?

void timer0_init(void)      // timer use by IR Interrupts 512 ticks bei 8 MHz = 15625/s
{  TCCR0B = 1<<CS02;        // divide by 256
  TCNT0 = -2;
  TIMSK0 |= (1<<TOIE0);    //enable timer interrupt
} // void timer0_init(void)

> Hast Du das mal ohne rc5_ISR() probiert? Funktioniert die rc5_ISR() denn
> noch? Warum benutzt Du Variablen mit fürhrendem Underscore, die in C
> prinzipiell der Runtime-Lib vorbehalten sind?

hab ich irgendwann mal bei Änderungen zur besseren Auffindbarkeit 
eingeführt

>> #define IRMP_PORT                               PORTD
>> #define IRMP_DDR                                DDRD
>> #define IRMP_PIN                                PIND
>> #define IRMP_BIT                                6
>
> Gibt es schon lange nicht mehr! Welche Version benutzt Du da?

mit der funktioniert es doch, uralt ? ich weiss ja nicht

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * irmp.c - infrared multi-protocol decoder, supports several remote control protocols
 *
 * Copyright (c) 2009-2011 Frank Meyer - frank(at)fli4l.de
 *
 * $Id: irmp.c,v 1.116 2012/02/24 11:40:41 fm Exp $

> Kann es
> sein, dass Du versuchst, eine uralte irmpconfig.h mit dem neuesten IRMP
> zum laufen zu bringen? Das geht nicht! Benutze bitte immer die
> irmpconfig.h, die auch im Source enthalten ist.

logisch nutze ich die neuste(n)

irmp.c mit irmp.h
irsnd.c mit irsnd.h
irmpconfig.h

und da ich es ins unterDIR IRMP habe finden sich dort auch
irmpprotocols.h
irmpsystem.h
irmpextlog.h

die ich aber nicht weiter beachtet habe, muss ich da noch rein ?

die Pfade in der APS habe ich natürlich in der neuen Version angepasst, 
aus
#include "irmp.h" alt wurde #include "irmp\irmp.h" neu

um jedes Missverständnis seitens des Compilers zu vermeiden habe ich 
alle alten

irmp*.* zu irmp*_.* umbenannt damit sich alt und neu nicht ins Gehege 
kommen und ich notfalls Fehlermeldungen bekomme.

[Dominic A. (neo123)]

Hallo zusammen,

Erst einmal vielen Dank für dieses tolle Projekt.
Doch leider ist soweit ich weiss der C18 Compiler für PIC veraltet.
Neu ist der XC8. Hat irgendjemand den Code schon für diesen Compiler 
portiert?

Wäre sehr Dankbar.

Grüsse
Neo

[eku (Gast)]

Hallo Frank,

Frank M. schrieb:
> Ich habe IRMP nun dermaßen angepasst, dass nur noch das letzte Bit
> darauf geprüft wird, ob ein Denon-Wiederholungsframe vorliegt oder
> nicht. Die Änderung ist im SVN eingecheckt. Damit sollte es nun gehen.

r114 enthält nur die Testdateien aber keine Änderungen in IRMP selbst.

[Frank M. (ukw) (Moderator)]

Hallo eku,

eku schrieb:

> r114 enthält nur die Testdateien aber keine Änderungen in IRMP selbst.

Tasächlich, habe README.txt und irmp.c beim Checkin vergessen. Habe ich 
nun nachgeholt.

Gruß und Dank,

Frank

[AnthonyVH (Gast)]

First of all, excuse me for my use of English, but my German is really 
bad, especially writing.

I'm trying to get IRMP working on a TI Stellaris Launchpad (Cortex-M4 
chip), but for some reason I can't get it to recognize a signal. The IR 
receiver I'm using is a TSOP38238. My processor is running at 40 MHz.

Logging (added non-blocking UART TX code in extlog file) and callbacks 
(to toggle a LED) both work, so I know the infrared signal is being 
received. Also, when I feed the 0s & 1s string from the log into the 
irmp-15khz program, it correctly decodes the signal.

The firmware I have running right now has nothing in it except for the 
IRMP code and a very simple HD44780 LCD driver, which is not interfering 
in any way (I've tested without it as well).

Does anyone have an idea of what might be wrong?

[eku (Gast)]

Hallo Frank,

Frank M. schrieb:
> Ich habe IRMP nun dermaßen angepasst, dass nur noch das letzte Bit
> darauf geprüft wird, ob ein Denon-Wiederholungsframe vorliegt oder
> nicht. Die Änderung ist im SVN eingecheckt. Damit sollte es nun gehen.

wir kommen dem Ziel näher ;) Bei drei Tasten (siehe Scan) wird ein 
falscher Gerätecode (richtig 0x10) erkannt. Ansonsten sieht es gut aus.

Gruß, eku

[Frank M. (ukw) (Moderator)]

Hi eku,

eku schrieb:

> wir kommen dem Ziel näher ;) Bei drei Tasten (siehe Scan) wird ein
> falscher Gerätecode (richtig 0x10) erkannt. Ansonsten sieht es gut aus.

./irmp-15kHz < sharp_15khz_probs.log

gibt aus:

-------------------------------------------------------------------
# ??? D: RX 08 000F 03E6 00 (DENON)
011111111100110
011110000011001 p= 8 (DENON), a=0x000f, c=0x03e6, f=0x00
011111111100110
-------------------------------------------------------------------
# ??? D: RX 08 000F 02CE 00 (DENON)
011111011001110
011110100110001 p= 8 (DENON), a=0x000f, c=0x02ce, f=0x00
011111011001110
-------------------------------------------------------------------
# MENU D: RX 08 0011 018E 00 (DENON)
100010110001110
100011001110001 p= 8 (DENON), a=0x0011, c=0x018e, f=0x00

Ich sehe da erstmal überhaupt keinen Fehler. Hier die Ausgabe des ersten 
Frames im Verbose-Modus:

./irmp-15kHz -v < sharp_15khz_probs.log

# ??? D: RX 08 000F 03E6 00 (DENON)
   0.133ms [starting pulse]
   1.200ms [start-bit: pulse =  5, pause = 11]
protocol = DENON, start bit timings: pulse:   3 -   7, pause:  23 -  30 
or   9 -  13
pulse_1:   3 -   7
pause_1:  23 -  30
pulse_0:   3 -   7
pause_0:   9 -  13
command_offset:  5
command_len:     10
complete_len:    15
stop_bit:         1
   1.200ms [bit  0: pulse =   5, pause =  11] 0
   3.333ms [bit  1: pulse =   5, pause =  27] 1
   5.400ms [bit  2: pulse =   4, pause =  27] 1
   7.533ms [bit  3: pulse =   5, pause =  27] 1
   9.600ms [bit  4: pulse =   5, pause =  26] 1
  11.733ms [bit  5: pulse =   6, pause =  26] 1
  13.867ms [bit  6: pulse =   5, pause =  27] 1
  15.933ms [bit  7: pulse =   4, pause =  27] 1
  18.067ms [bit  8: pulse =   5, pause =  27] 1
  20.133ms [bit  9: pulse =   4, pause =  27] 1
  21.200ms [bit 10: pulse =   5, pause =  11] 0
  22.267ms [bit 11: pulse =   5, pause =  11] 0
  24.333ms [bit 12: pulse =   5, pause =  26] 1
  26.467ms [bit 13: pulse =   5, pause =  27] 1
  27.533ms [bit 14: pulse =   5, pause =  11] 0
stop bit detected
  27.933ms code detected, length = 15
  27.933ms info Denon: waiting for inverted command repetition

Die Timings für Puls/Pause sind eindeutig, die Adresse wird korrekt 
berechnet.

Was sind das denn für ???-Tasten? Es ist durchaus üblich, dass bestimmte 
Multifunktionstasten, welche gleichzeitig für einen evtl. vorhandenen 
Receiver, DVD- oder CD-Player gültig sein sollen, eine abweichende 
Adresse verwenden. Kenne ich zum Beispiel von der FB meines 
Toshiba-Fernsehers, wo eine Fast-Forward-/Backward-Taste bei einem 
normalen Fernseher (ohne eingebauten Festplatten-Receiver) nicht 
wirklich Sinn macht, aber trotzdem vorhanden ist.

Beim Sony-Protokoll wird sogar extensiv davon Gebrauch gemacht, so dass 
ich mich damals irgendwann entschlossen habe, den kompletten 
SIRCS-Adressbereich mit ins Kommando irmp_data.command rüberzunehmen, 
weil es die Anwender total verwirrt hat, dass ein- und dieselbe FB mit 
unterschiedlichen Adressen arbeitet.

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

AnthonyVH schrieb:

> Logging (added non-blocking UART TX code in extlog file) and callbacks
> (to toggle a LED) both work, so I know the infrared signal is being
> received.

Perfect :-)

> Also, when I feed the 0s & 1s string from the log into the
> irmp-15khz program, it correctly decodes the signal.

Could you please append here a text file with your log? It would be nice 
if you append your UART TX code in extlog file code, too. Perhaps I can 
release it for future versions of IRMP.

> Does anyone have an idea of what might be wrong?

Did you change something in the original IRMP code? If yes, please show 
me the changes.

You could also insert some debug messages into the IRMP code. If you are 
interested, I will show you the locations where they are reasonable. But 
before you should append the logs here so that I can determine protocol, 
address & command codes.

Regards,

Frank

[eku (Gast)]

Hallo Frank,

Frank M. schrieb:
> Ich sehe da erstmal überhaupt keinen Fehler.

ich würde Deine kostbare Zeit bestimnmt nicht in Anspruch nehmen, wenn 
IRMP es nicht schon einmal als 0x10 dekodiert hätte. Verwende ich die 
Gerätecodes 0x0f und 0x11 in IRSND reagiert der Sharp-TV nicht, mit 0x10 
hingegen schon.

Gruß, eku

[Frank M. (ukw) (Moderator)]

Hi eku,

eku schrieb:
> ich würde Deine kostbare Zeit bestimnmt nicht in Anspruch nehmen, wenn
> IRMP es nicht schon einmal als 0x10 dekodiert hätte.

Hier die IRMP-Auswertung der Taste "0" von Deiner FB:

10000 0101000010
10000 1010111101 p= 8 (DENON), a=0x0010, c=0x0142, f=0x00 checked!

Ich habe mal zwischen dem Adressteil und dem Kommandoteil ein 
Leerzeichen eingefügt. Wie man schön sehen kann, wird die Adresse im 
Wiederholungsframe nicht invertiert, das Kommando jedoch schon.

     10000  ergibt Adresse  0x0010
0101000010  ergibt Kommando 0x0142

Jetzt Deine Taste mit der Bezeichnung "???" in Deinem Scan (1. Zeile):

01111 1111100110
01111 0000011001 p= 8 (DENON), a=0x000f, c=0x03e6, f=0x00

     01111  ergibt Adresse  0x000F
1111100110  ergibt Kommando 0x03E6

Den Unterschied sieht man auch deutlich, wenn man im Text-Editor den 
Scan der Tasten 9 & 0 mit dem Scan der Taste "???" vergleicht (hier nur 
die ersten 5 Bits, welche die Adresse ausmachen):

# 9 [ 8 (DENON) 0x0010 0x0242]
00000111111111111111111111111110000011111111111000001111111111100000111111111110000011111111111
# 0 [ 8 (DENON) 0x0010 0x0142]
0000011111111111111111111111111000001111111111100000111111111110000011111111111000011111111111
# ??? D: RX 08 000F 03E6 00 (DENON)
0000011111111111000001111111111111111111111111110000111111111111111111111111111000001111111111111111111111111110000011111111111111111111111111

Der Adressteil für die Tasten 9 & 0 sind annähernd identisch, der Teil 
für die Taste '???' aber passt da gar nicht rein:

Taste 9: Pausenfolge: lang kurz kurz kurz kurz -> 1 0 0 0 0 -> Adr 0x10
Taste 0: Pausenfolge: lang kurz kurz kurz kurz -> 1 0 0 0 0 -> Adr 0x10
Taste ?: Pausenfolge: kurz lang lang lang lang -> 0 1 1 1 1 -> Adr 0x0F

Also nach Deinem Scan ergibt sich da eine ganz andere Adresse. Dazu 
braucht man noch nichtmals IRMP, das kann man schon im Text-Editor sehen 
und im Kopf dekodieren. Was mir da aber auffällt: 10000 und 01111 sind 
zueinander genau invertiert.

Die Frage ist also: Warum macht das die FB bei der Taste '???'. Bitte 
sag doch mal, was Deine Taste '???' in Wirklichkeit ist.

> Verwende ich die
> Gerätecodes 0x0f und 0x11 in IRSND reagiert der Sharp-TV nicht, mit 0x10
> hingegen schon.

Frage: Was machst Du da? Du setzt beim Senden die Adresse auf 0x10 statt 
0x0F und das Kommando auf 0x03E6 und Dein Sharp-Gerät reagiert genau so, 
als hättest Du die Taste '???' Deiner FB gedrückt?

Gruß,

Frank

[AnthonyVH (Gast)]

Frank M. schrieb:
> Could you please append here a text file with your log? It would be nice
> if you append your UART TX code in extlog file code, too. Perhaps I can
> release it for future versions of IRMP.

I've almost tracked down the problem, I'll explain below. But first I'll 
answer your questions.

I've attached a log with a few button presses from 2 remotes, 1 from my 
TV (SAMSUNG32 code), the other from a Western Digital Live (NEC code).

Below is the code I've added for the Stellaris Launchpad:

Replace initextlog with:

void initextlog (void)
{
  // Stellaris Launchpad UART setup
  unsigned long const baudrate = 115200;

  MAP_SysCtlPeripheralEnable (SYSCTL_PERIPH_UART0);
  MAP_SysCtlPeripheralEnable (SYSCTL_PERIPH_GPIOA);
  MAP_GPIOPinConfigure(GPIO_PA0_U0RX);
  MAP_GPIOPinConfigure(GPIO_PA1_U0TX);
  MAP_GPIOPinTypeUART (GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
  MAP_UARTConfigSetExpClk (UART0_BASE, (MAP_SysCtlClockGet ()), baudrate, (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
}

Replace sentextlog with:

void sendextlog (unsigned char data)
{
  // Prefer to transmit non-blocking if possible
  if (!MAP_UARTCharPutNonBlocking(UART0_BASE, data))
    MAP_UARTCharPut(UART0_BASE, data);
}

The MAP_ functions get compiled to inherent (ROM_) functions if 
possible, thus requiring no linking of the StellarisWare library (the 
Stellaris Launchpad chips have the complete StellarisWare library stored 
in flash). If not possible, they get replaced with links to the 
StellarisWare library and it will get linked in (at the expensense of a 
larger executable). In order to have this work correctly, you have to 
add this to your source code:

#include "driverlib/rom_map.h"

By the way, I believe there is a mistake in irmpsystem.h, 
TARGET_IS_BLIZZARD_RA2 should be TARGET_IS_BLIZZARD_RA1 as far as I 
know.

> Did you change something in the original IRMP code? If yes, please show
> me the changes.

I made no changes. In fact, to make sure I had no modifications 
anywhere, I removed all IRMP files, redownloaded the latest version from 
the SVN and setup the config files (and logging functions) again.

My busy loop in main is:

for (;;)
{
  if (irmp_get_data(&irmp_data))
  {
    MAP_UARTCharPut(UART0_BASE, 'Y');
    LCDWritePos('Y', 1, 2);
  }
}

> You could also insert some debug messages into the IRMP code. If you are
> interested, I will show you the locations where they are reasonable. But
> before you should append the logs here so that I can determine protocol,
> address & command codes.

That might come in handy, not sure, because I've almost tracked down the 
problem I believe. When I commented out the LCD related functions, 
suddenly IRMP started working. So, I've been doing some debugging and it 
turns out that any use of the FPU outside of IRMP will break the IRMP 
code.

The strange thing is that this shouldn't happen, because 
FPUEnableStacking() is called, which handles saving/restoring the FPU 
registers when an interrupt occurs. I'll do some more research and post 
a solution here if I find it.

Thanks for your help!

[AnthonyVH (Gast)]

I've put the problem/question up on electronics.stackexchange.com as 
well. The link is: 
http://electronics.stackexchange.com/questions/57329/cortex-m4f-fpu-problems.

The past few hours of Googling haven't really helped at all. I 
discovered that compiling with -O0 breaks the decoding as well, O1 and 
higher work fine (if I remove all floating point arithmetic outside of 
the timer ISR and functions called from it).

[AnthonyVH (Gast)]

Fixed! The problem turned out to be related to the stack handling. 
Changing to a different linked & startup script (found here: 
https://github.com/eehusky/Stellaris-GCC/tree/master/proj0) fixed my 
problem. So happy after 10+ hours of looking for the problem/solution 
:)!

[Frank M. (ukw) (Moderator)]

AnthonyVH schrieb:
> Fixed!

Congratulations! Could you send me your changes of the complete project 
per e-mail? You will find my mail address in the header of the sources.

Thank you,

Frank

[Ulli (Gast)]

Hallo,

wie wird in irmp eigentlich sicher gestellt das die empfangenen Daten 
auch nicht durch einen folgenden Empfang überschrieben werden?

Verbirgt sich hinter irmp_get_data ein Ringspeicher?

[Frank M. (ukw) (Moderator)]

Ulli schrieb:
> wie wird in irmp eigentlich sicher gestellt das die empfangenen Daten
> auch nicht durch einen folgenden Empfang überschrieben werden?

IRMP empfängt kein weiteres Signal, bis die Anwendung mittels 
irmp_get_data() die letzten Daten "abgeholt" hat.

Das ist im Normalfall auch gar kein Problem, da zwischen den Frames 
meist Pausen von ca. 50msec sind. Die Anwendung hat daher fast eine 
"Ewigkeit" Zeit, die Daten zu übernehmen. Man könnte natürlich leicht 
auf Anwendungsebene einen Ringbuffer implementieren, aber ich sehe dafür 
keinen Anlass.

[Dschingis (Gast)]

Hallo erstmal,

ich versuche nun seit einigen Tagen IRMP für ein STM32-Discovery Board, 
lauffähig zu bekommen habe aber bisher leider keinen Erfog gehabt.

Wäre es möglich die main.c für STM32 zu erweitern?

Ich bin noch Einsteiger und habe noch so meine Probleme mit den Unmengen 
an Einstellungsmöglichkeiten.

Gruß Dschingis

[Karol B. (johnpatcher)]

Dschingis schrieb:
> Wäre es möglich die main.c für STM32 zu erweitern?

Nicht, dass ich es schon probiert hätte, aber die aktuelle Codebasis 
unterstützt das STM32 doch schon. Aber zumindest laut [1] wird das STM32 
unterstützt.

Insofern gehe ich fast davon aus, dass du etwas falsch machst. Das lässt 
sich bei deiner Beschreibung ("leider keinen Erfog") natürlich nicht 
genauer sagen.

[1]: 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

[Dschingis (Gast)]

Aktuell sind in der Beispieldatei main.c Implementierungen für AVR und 
Stellaris_ARM_Cortex_M4 enthalten.

Hier werden jeweils die Timer- und einige andere Einstellungen 
vorgenommen.

Das fehlt aber leider für die STM32 Reihe.

Außerdem verstehe ich noch nicht ganz ob ich die F_CPU einfach per 
#define setzten kann oder ob ich eine Einstellungsmöglichkeit des 
Softwarepaketes übersehen habe.

Aber prinzipiell vielen Dank für die viele Arbeit, ich bin begeistert...

[Dschingis (Gast)]

So, nach einiger Zeit des Testens und Fluchens...
habe ich eine lauffähige main.c für STM32 Chips erstellen können.(siehe 
Anhang)

Ich benutze das STM32VLDISCOVERY, hierbei sollte man beachten, dass man 
bei Implementierung der IRSND die Nummer des Timers auf 3 stellen muss 
(bei Out-Pin PA6).

Ich hoffe ich konnte helfen ...

Gruß Dschingis

[Conny G. (conny_g)]

Hallo Frank,

ich habe vermutlich beim RECS80 einen Fehler gefunden:

es wurde vor der Adresse 1 Bit zuviel gesendet, d.h. Startbit + "1" + 
Toggle usw.
Ich habe das zusätzliche "1" entfernt (0x80) und jetzt geht es, meine 
Änderung siehe unten.

Auch das Erkennen des RECS80 funktioniert nicht, da habe ich mich aber 
noch nicht drangemacht, vermute es ist derselbe Effekt?

VG,
Konrad

#if IRSND_SUPPORT_RECS80_PROTOCOL == 1
  case IRMP_RECS80_PROTOCOL:
  {
//      toggle_bit_recs80 = toggle_bit_recs80 ? 0x00 : 0x40;

//      irsnd_buffer[0] = 0x80 | toggle_bit_recs80 | ((irmp_data_p->address & 0x0007) << 3) |
//            ((irmp_data_p->command & 0x0038) >> 3);                                           // STAAACCC
//      irsnd_buffer[1] = (irmp_data_p->command & 0x07) << 5;                                               // CCC00000
/**********************/
      toggle_bit_recs80 = toggle_bit_recs80 ? 0x00 : 0x80;

      irsnd_buffer[0] = toggle_bit_recs80 | ((irmp_data_p->address & 0x0007) << 4) |
            ((irmp_data_p->command & 0x003C) >> 2);                                           // TAAACCCC
      irsnd_buffer[1] = (irmp_data_p->command & 0x03) << 6;                                               // CC000000
/**********************/
      irsnd_busy      = TRUE;
      break;
  }
#endif

[Mike Sevignani (Gast)]

Heute kommt einfach mal nur ein DANKE an "Frank M." von mir!
Tolles Projekt, das ich perfekt auf diversen ATmega32 umsetzen konnte.

Gruß, Mike

PS: habs noch nicht geschafft, irmp & irsend zusammen auf einen ATmega8 
zu portieren (hab hier noch einige 8er rumliegen), falls jemand etwas 
Code oder einen Link dazu hätte, wäre cool...

[jar (Gast)]

Mike Sevignani schrieb:
> PS: habs noch nicht geschafft, irmp & irsend zusammen auf einen ATmega8
> zu portieren (hab hier noch einige 8er rumliegen), falls jemand etwas
> Code oder einen Link dazu hätte, wäre cool...

muss ich suchen, aber das hatte ich schon mal gemacht (kann sein mit den 
Nachfolgern m88 oder m168), woran liegts ?

ist doch selbiger source code ?

[Conny G. (conny_g)]

@Mike:
ich hab's beides auf einem Atmega8 am Laufen. Ist zwar etwas eng mit 
Speicher, er ist fast voll mit wenigen Protokollen und für Logging muss 
ich immer tunen, damit der Speicher reicht, aber es geht.
Was meinst Du genau mit "nicht geschafft", wo hakt es?

[Conny G. (conny_g)]

@Frank:
Es scheint am Erkennen des Bit Timing zu liegen, tappe allerdings gerade 
noch im Dunkeln an was genau, bisschen Log siehe unten.

Ansonsten auch von mir mal ein großes Kompliment für das aufwändige 
Projekt, sehr respektabel!!

RECS80
error3: timing not correct: data bit 0,  pulse: 3, pause: 23
error 3: timing not correct: data bit 0,  pulse: 4, pause: 17
RECS80
RECS80
error 3: timing not correct: data bit 0,  pulse: 4, pause: 20
error 3: timing not correct: data bit 0,  pulse: 3, pause: 1
RECS80
error 3: timing not correct: data bit 0,  pulse: 4, pause: 
RECS80
error 3: timing not correct: data bit 0,  pulse: 22, pause: 82
RECS80
error 3: timing not correct: data bit 0,  pulse: 3, pause: 1
RECS80
error 3: timing not correct: data bit 0,  pulse: 3, pause: 
RECS80
<1>error 3: timing not correct: data bit 1,  pulse: 5, pause: 99
RECS80
<1><0><1><0><0>error 3: timing not correct: data bit 5,  pulse: 5, pause: 100

Der letzte "Versuch" sieht ganz gut aus, aber warum es dann abbricht...?

[Conny G. (conny_g)]

Vielleicht einfach Störstrahlung? Ich habe gerade die Hand darüber 
gehalten und es wurde bei ein paar Versuchen jetzt 1x ein Kommando 
erkannt....

RECS80
<1><0><1><0><0><0><1><0><0><1>Protocol: 6, Address: 2, Command: 9, Flags: 00

[Conny G. (conny_g)]

Tatsächlich! Wenn ich mit dem Oszi ansehe, was nach dem IR Receiver 
ankommt (TSOP 4838), dann ist das tlw. kaputt und zwar umso mehr mit 
Tageslichteinstrahlung...
Ist der TSOP 4838 dann nicht für SAA3004 geeignet??

Anbei Oszi Screenshot mit Abschirmung des Tageslichts.

[Conny G. (conny_g)]

Also es scheint ein Takt von 20kHz verursachte den Fehler, mit 15 kHz 
funktioniert es jetzt.
Keine Ahnung weshalb mein Oszi diese Fehler gemessen hat, ich hatte aber 
noch etwas bei der Timerkonfiguration fehlerhaft.

Also gute News für Frank:
RECS80 interpretieren funktioniert (mit 15Khz) und mit meinem Fix von 
oben funktioniert das Senden ebenfalls.

[Conny G. (conny_g)]

Allerdings ist IRSND mit 15 kHz nicht zufrieden.
Die Toleranzen auf 20% geändert, dann klappt es (s.u.).
Allerdings kann ich nicht überblicken, ob es bzgl. der 
Protokollerkennung Auswirkungen hat.

irmp.c

#define RECS80_START_BIT_PULSE_LEN_MIN          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_START_BIT_PULSE_LEN_MAX          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RECS80_START_BIT_PAUSE_LEN_MIN          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_START_BIT_PAUSE_LEN_MAX          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RECS80_PULSE_LEN_MIN                    ((uint8_t)(F_INTERRUPTS * RECS80_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_PULSE_LEN_MAX                    ((uint8_t)(F_INTERRUPTS * RECS80_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RECS80_1_PAUSE_LEN_MIN                  ((uint8_t)(F_INTERRUPTS * RECS80_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_1_PAUSE_LEN_MAX                  ((uint8_t)(F_INTERRUPTS * RECS80_1_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
#define RECS80_0_PAUSE_LEN_MIN                  ((uint8_t)(F_INTERRUPTS * RECS80_0_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_0_PAUSE_LEN_MAX                  ((uint8_t)(F_INTERRUPTS * RECS80_0_PAUSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

[Frank M. (ukw) (Moderator)]

Konrad G. schrieb:
> Allerdings ist IRSND mit 15 kHz nicht zufrieden.

Erstmal danke für die aufwändigen Tests. RECS80 konnte ich nie testen - 
mangels geeigneter Fernbedienung. Ich habe das Protokoll einfach mittels 
Infos aus dem Internet implementiert.

> Die Toleranzen auf 20% geändert, dann klappt es (s.u.).

Die Toleranzen sind aber nur für IRMP, nicht für IRSND. IRSND arbeitet 
mit den Idealwerten. Oder meinst Du, dass IRMP nun auch bei 20kHz das 
RECS80-Protokoll erkennt?

Es wäre große klasse, wenn Du mir Logfiles zuschicken könntest. Dann 
kann ich Deine Software-Änderungen nachvollziehen und das ganze auch 
noch weiter optimieren.

> Allerdings kann ich nicht überblicken, ob es bzgl. der
> Protokollerkennung Auswirkungen hat.

Das kann ich leicht testen, für Linux gibt es eine Test-Suite für IRMP, 
welche alle Log-Dateien, die mir vorliegen, durchcheckt und Konflikte 
bei Toleranzerhöhungen mit anderen Protokollen sofort aufdeckt.

Gruß und Dank,

Frank

[Conny G. (conny_g)]

Hallo Frank,

freut mich, wenn es hilfreich ist ;-)
Ja, das meinte ich: um dieselbe Interrupt-Frequenz für beide haben zu 
können habe ich die Toleranzen für IRMP erhöht.
Logfiles: ich zeichne später das Signal auf und schicke es Dir.
D.h. LOGGING auf 1 setzen und die UART-Ausgabe Copy& Paste in eine 
Textdatei und hier als Anhang übermitteln?
Mit welcher Frequenz möchtest Du es gesampelt haben, 15 kHz, 20 kHz oder 
beides?

Übrigens handelt es sich hier um die Fernbedienung einer Schrankwand, 
die 2 Lichtkreise, 1 elektrische Schiebetür und eine Fernseher-Plattform 
(die rein und rausfährt) steuert. In der Fernbedienung ist ein SAA3004 
von Philipps.
Die Befehle sind  1T 010 001011 für die Schiebetür, 1T 010 001010 für 
die Fernseher-Plattform, 1T 010 001001 für das Licht am/im TV-Schrank 
und 1T 010 001000 für das restliche Licht.

Auf welcher Plattform empfiehlst Du IRMP/IRSND gemeinsam zu betreiben?
Ich verwende gerade ATMega8 und der ist zu klein, ich kann nur 5 
Protokolle einschalten... was nimmst Du?

VG,
Konrad

[jar (Gast)]

Konrad G. schrieb:
> Ich verwende gerade ATMega8 und der ist zu klein,

du kannst doch pinkompatibel zum m168 wechseln, oder nach oben keine 
Grenzen, m1284p z.B.

[Conny G. (conny_g)]

Frank,

anbei die Scans in 15 und 20 kHz.

Das sind die erkannten Codes:
Protocol: 6, Address: 2, Command: 8, Flags: 00
Protocol: 6, Address: 2, Command: 9, Flags: 00

VG,
Konrad

[Frank M. (ukw) (Moderator)]

Konrad G. schrieb:
> anbei die Scans in 15 und 20 kHz.

Erstmal Danke.

Deine Scans sind alle 4 mit 20 kHz aufgenommen, da musst Du was falsch 
gemacht haben. Erkennt man schon daran, wenn man die Scans in den Editor 
lädt und die 15er mit den 20er von den Längen der 0en und 1en 
vergleicht. Die sind annähernd identisch.

Es reicht dann, die Toleranzen für die Pulse anzupassen, nämlich:

#define RECS80_START_BIT_PULSE_LEN_MIN          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_START_BIT_PULSE_LEN_MAX          ((uint8_t)(F_INTERRUPTS * RECS80_START_BIT_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)
...
#define RECS80_PULSE_LEN_MIN                    ((uint8_t)(F_INTERRUPTS * RECS80_PULSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
#define RECS80_PULSE_LEN_MAX                    ((uint8_t)(F_INTERRUPTS * RECS80_PULSE_TIME * MAX_TOLERANCE_20 + 0.5) + 1)

Bei den ultralangen Pausen reicht die Toleranz von 10% vollkommen aus. 
Da bedarf es keiner Anpassung.

Ich werde diese Änderung demnächst ins SVN einchecken.

In den 20er-Dateien ist ein wenig Schrott mit drin, da hast Du offenbar 
die Tasten länger gedrückt und der ScanBuffer lief zwischendurch über... 
aber kein Problem. IRMP fängt sich da wieder beim Lesen der 
Scan-Dateien.

> Das sind die erkannten Codes:
> Protocol: 6, Address: 2, Command: 8, Flags: 00
> Protocol: 6, Address: 2, Command: 9, Flags: 00

Ja, kann ich bestätigen:

# IR-Data/tmpsrc/irmp-20kHz < saa3004_15khz_1.txt
0010001000 p= 6 (RECS80), a=0x0002, c=0x0008, f=0x00
# IR-Data/tmpsrc/irmp-20kHz < saa3004_15khz_2.txt
1010001001 p= 6 (RECS80), a=0x0002, c=0x0009, f=0x00

Ich werde die 15kHz-Dateien mal künstlich erzeugen, indem ich die Längen 
in Deinen Scans um das Verhältnis 15/20 kürze. Dann teste ich nochmal 
die 15kHz-Version von IRMP.

Der IRSND kommt dann als nächstes dran. Da melde ich mich nochmal.

Zu Deiner Frage zum ATmega8:

Der ATmega8 ist veraltet und wurde von ATMEL durch den (annähernd) 
pinkompatiblen ATmega88 ersetzt. Diesen gibt es auch mit doppelter und 
vierfachem Speicher: ATmega168 und ATmega328. Meist sind die 328er sogar 
billiger als die 168er.

Vergiss den ATmega8 und ersetze ihn durch einen ATmega168 oder 
ATmega328. Diese haben auch viel mehr Möglichkeiten, was Timer und 
Interrupts betrifft.

[Frank M. (ukw) (Moderator)]

Konrad G. schrieb:
> Allerdings ist IRSND mit 15 kHz nicht zufrieden.

Das liegt einfach daran, dass ich bisher das RECS80-Protokoll im IRSND 
für 15kHz mit der Compiler-Warnung

#  warning F_INTERRUPTS too low, RECS80 protocol disabled (should be at least 20000)

abgeschaltet habe. Diese Warnung hattest Du offenbar überlesen ;-)

Ich habe das nun geändert. 15kHz sind jetzt auch erlaubt.

Die korrigierte Fassung V2.3.8 ist nun im SVN eingecheckt. Kannst Du das 
bitte mal für 15kHz und 20kHz (Senden und Empfangen) testen?

Deine Fernbedienung sendet Pulse von ca. 240µs statt 158µs. Das ist 
schon eine starke Abweichung von der Norm. IRSND sendet also kürzere 
Pulse als Deine FB. Sollte Dein Gerät aber auch schlucken.

Gruß,

Frank

[Redhead (Gast)]

Erstmals vielen Dank für das Projekt, es hat mir sehr weitergeholfen und 
Zeit erspart.

Ich versuche das Projekt mit STM32VLDiscovery zu realisieren. Das main.c 
von Dschingis vom 27.02.2013 funktioniert einwandfrei (ich kann 
verschiedenste Fernbedienungen erkennen).

Leider weiß ich noch nicht welche Taste ich gedrückt habe. Dafür muss 
ich wsl die IRMP_LOGGING im irmpconfig.h auf 1 setzen.

Dadurch bekomme ich im irmp.c eine Fehlermeldung da #include 
<util/setbaud.h> nicht erkannt wird.

Wenn ich die Zeile auskommentiere bekomme ich beim irmp_usart_init 
einige Fehler. Ich bin zwar ein Anfänger, glaube aber, dass diese 
usart_init nicht für den STM32 funktionieren würde, wenn ich setbaud.h 
hinzufüge. Leider weiß ich aber nicht wie ich das File irmp.c 
umschreiben muss, damit das Projekt am STM32 läuft.

Vielen Dank
Redhead

[jar (Gast)]

Redhead schrieb:
> Dadurch bekomme ich im irmp.c eine Fehlermeldung da #include
> <util/setbaud.h> nicht erkannt wird.

ist ja auch nur für AVR ?

du wirst wohl nicht umhin kommen diech mit deinem STM32 und der UART 
Ausgabe zu beschäftigen

Bisher gibt es sieben STM32-Familien
http://www.mikrocontroller.net/articles/STM32

Beitrag "USART mit STM32 Discovery"

http://www.micromouseonline.com/2009/12/31/stm32-usart-basics/#axzz2NQTalW7a

[Redhead (Gast)]

jar schrieb:
> du wirst wohl nicht umhin kommen diech mit deinem STM32 und der UART
> Ausgabe zu beschäftigen

ok, danke.

D.h. ich muss auch das irmp_usart_getc umschreiben. Soweit ich 
verstanden habe, wandelt irmp_usart_getc die entsprechende Taste in den 
zugehürogen Wert um (also die einser Taste in  1).

[jar (Gast)]

Redhead schrieb:
> D.h. ich muss auch das irmp_usart_getc umschreiben. Soweit ich
> verstanden habe, wandelt irmp_usart_getc die entsprechende Taste in den
> zugehürogen Wert um (also die einser Taste in  1).

niemals ! welcher Code die 1 bei dir ist kann IRMP nicht wissen

für eine Taste kommt immer nur Protokoll, Address und Data Code raus

welche Taste sich dahinter verbirgt musst du notieren

Zettel , drücke Taste 1 ergibt
Protokoll, Address und Data Code

usw.

willst du das senden musst du IRSND wieder übergeben Protokoll, Address 
und Data Code

[Redhead (Gast)]

jar schrieb:
> welche Taste sich dahinter verbirgt musst du notieren

ok, jetzt versteh ich es :) werde das machen

Vielen Dank

[jar (Gast)]

Redhead schrieb:
> D.h. ich muss auch das irmp_usart_getc umschreiben

wieso get ? wäre doch nur für IRSND ?

IRMP schickt alles seriell raus, also irmp_usart_putc

irmp_usart_getc wäre doch für IRSND ?

also er bekommt Protokoll Address und Code an der seriellen und schickt 
es als IR raus, oder durchblicke ich gerade was nicht ?

wo hast du überhaupt
irmp_usart_getc gefunden ? ich finde das nicht, weder in irmp noch in 
irsnd ?

[Frank M. (ukw) (Moderator)]

jar schrieb:
> IRMP schickt alles seriell raus, also irmp_usart_putc

irmp_usart* sind für LOGGING. Das braucht Redhead doch überhaupt gar 
nicht. Sein IRMP erkennt ja bereits Protokoll, Adresse und Kommando. Er 
braucht daher kein LOGGING der Frames.

Er muss halt seine mit IRMP ermittelten Werte irgendwo ablesen. Das kann 
ein Display sein oder eine Terminal-Emulation via RS232 - egal wie. Aber 
er soll die Finger von irmp_usart* lassen ;-)

Ich weiß ja nicht, was Redhead will. Wenn er lediglich ein paar Tasten 
seiner FB auswerten will, gibt es für ihn 2 Möglichkeiten:

1. Er sendet die nötigen Befehle über seine FB, gibt Protokoll, Adresse
   und Kommando irgendwohin aus (Display, UART oder Morsecode), schreibt
   sie auf einen Zettel und programmiert sie dann fest in sein Programm.

2. Er baut in seine Anwendung eine kleine Anlernroutine, welche
   Protokoll, Adresse und Kommando ins EEPROM schreibt. Seine
   eigentliche Anwendung liest das EEPROM dann wieder aus und checkt
   dann diese Angaben gegen die zukünftig von IRMP gelesenen Werte.

Ich halte Weg 2 für sinnvoller. Erstens ist man dann nicht auf eine 
feste Fernbedienung angewiesen und zweitens spart man sich das Display 
und den Zettel ;-)

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> irmp_usart* sind für LOGGING.

stimmt ja LOGGING (schon wieder vergessen), geben eh nur einsen und 
nullen aus

wobei ich natürlich über die UART den Empfang von Protokoll Address und 
Code ausgebe und natürlich nicht die IRMP_UART verwende

[Redhead (Gast)]

jar schrieb:
> wo hast du überhaupt
>
> irmp_usart_getc gefunden ? ich finde das nicht, weder in irmp noch in
>
> irsnd ?

Ich habe eh putc gemeint :)

Frank M. schrieb:
> irmp_usart* sind für LOGGING. Das braucht Redhead doch überhaupt gar
>
> nicht. Sein IRMP erkennt ja bereits Protokoll, Adresse und Kommando. Er
>
> braucht daher kein LOGGING der Frames.

Ahhh, ist ja eigentlich ganz simpel. Jetzt verstehe ich es auch.

Vielen Dank nochmals, dass ihr mir weitergeholfen habt

[Stefan Z. (stefan_z)]

Ich habe hier grad eine Telefunken 1560 liegen und irgendwie werde ich 
nicht ganz schlau draus...
Sie wird als SIEMENS erkannt, wirft aber bei jeder Taste den selben Code 
aus.
Vermutlich erkennt er das Protokoll falsch.
Ich verwende die aktuellste Arduino-Version (die ich gefunden habe):
https://gitorious.org/arduino-addons/irmp-arduino
Protokolle habe ich alle aktiviert.

Ist die Arduino-Portierung veraltet oder ist das Protokoll einfach so 
exotisch?

Hier mal zwei unterschiedliche Tasten als Debugging-Beispiel:
IRMP test sketch
US: 50
SIEMENS Proto:17 A:2AA C:150A 0
000000000000011111111111111111111111111111100000000000111111111111111111 
111111111111100000000000011111111100000000000011111111100000000000011111 
111111111111111111111111100000000000011111111100000000000111111111111111 
111111111111111100000000000011111111110000000000011111111100000000000011 
111111111111111111111111111110000000000011111111111111111111111111111110 
000000000011111111110000000000001111111110000000000011111111110000000000 
0011111111100000000000111111111100000000000111111111111111
SIEMENS Proto:17 A:2AA C:150A 0
000000000001111111111111111111111111111111000000000001111111111111111111 
111111111111100000000000111111111000000000000011111111000000000000111111 
111111111111111111111111100000000000111111111000000000000111111111111111 
111111111111111100000000000011111111000000000000111111111111111111111111 
111111100000000000011111111000000000000111111111111111111111111111111000 
000000000111111111100000000000011111111111111111111111111111110000000000 
111111111100000000000011111111110000000000111111111110000000000011111111 
1111111111

Viele Grüße
Stefan

[Fred (Gast)]

Hallo Frank,

nun habe ich das Projekt schon längere Zeit nicht mehr verfolgt aber ein
Kollege hat mich vor eine Aufgabe gestellt, die förmlich nach diesem
schreit. :-)

Er hat für seinen HTPC eine IR Fernbedienung von hama mit IR-USB 
Empfänger.
Damit lassen sich alle Funktionen des HTPC steuern. Nur wenn das Gerät
ausgeschaltet ist (ich glaub S4) kann man es mit diesem Teil nicht
einschalten.
Also hätte ich jetzt mit IRMP einen kleinen 2. Empfänger aufgebaut und
nur den Einschaltbefehl ausgewertet und den Startknopf gebrückt.

Ein Testaufbau mit einer RC6 Fernbedienung hat hier einwandfrei 
funktioniert.
Nun habe ich die hama in die Hände bekommen und scheitere am Protokoll.

Die hama hat die Nr. 00052451 und scheint ein OEM zur VRC-1100 von ORtek
zu sein.

Kennst du das Teil zufällig oder kannst mir mit dem Protokoll auf die
Sprünge helfen?

In der Hardcopy sind die ersten drei Telegramme vom Powerbefehl. Die
4. Zeile ist der OK Befehl.

Das erste Telegramm (1. Zeile) unterscheidet sich von den 
Folge-telegrammen (2. und 3. Zeile).

Eine Logdatei mit 10k hab ich auch erzeugt und angehängt.

Gruß Fred

[Stefan Z. (stefan_z)]

Fred schrieb:
> Die hama hat die Nr. 00052451 und scheint ein OEM zur VRC-1100 von ORtek
> zu sein.

Alternative Idee zur IR-Umleitung:
Der Hama-Empfänger meldet sich ja als HID-Gerät beim Host an.
Ggfs. kann der Kollege ja wake-on-keyboard oder sowas am PC selber übers 
Bios einschalten. Bei mir am Mac sendet die Powertaste zumindest den 
passenden HID-Code.
Und an meinem ollen PC habe ich das erstmal explizit ausschalten müssen.

[Stefan Z. (stefan_z)]

Bei der Telefunken 1560 ist mir jetzt grad noch was interessantes 
aufgefallen:
Der Bedienteil unten links für allgemeine TV-Einstellungen (laut-leise, 
Farbe, etc.) wird vom TSOP nicht erkannt.
Also mal die Kamera draufgehalten und siehe da:
Er sendet, aber viel "dunkler" als bei den anderen Tasten.

Der Logic-Analyzer bringt die Lösung:
Anscheinend wird hier mit einem 400kHz Signal moduliert und eine sehr 
kurze An-Zeit genutzt (um Batterie zu sparen vermutlich.)

Anbei mal der Ausschnitt von Logic - oben das ganze Paket (um die 90 ms) 
und die Vergrößerung des 1. Bits (um die 20 µs).

Kennt das jemand, oder weiß mehr?

[Frank M. (ukw) (Moderator)]

Stefan Z. schrieb:
> Ich habe hier grad eine Telefunken 1560 liegen und irgendwie werde ich
> nicht ganz schlau draus...
> Sie wird als SIEMENS erkannt, wirft aber bei jeder Taste den selben Code
> aus.

Siemens ist definitiv falsch. Das Start-Bit hat nur dasselbe Timing wie 
das Siemens-Protokoll. Daher kommt IRMP vollkommen auf die falsche Spur.

> Vermutlich erkennt er das Protokoll falsch.

Ja.

> Ist die Arduino-Portierung veraltet oder ist das Protokoll einfach so
> exotisch?

Definitiv das Protokoll.

> Hier mal zwei unterschiedliche Tasten als Debugging-Beispiel:

Danke, das nächste Mal bitte als txt-Datei im Anhang, dann muss ich die 
Umbrüche nicht korrigieren.

Das Protokoll, was da benutzt wird, ist kein Bi-Phase 
(Manchester)-Protokoll (wie z.B. das Siemens-Protokoll), sondern ein 
Pulse-Distance-Protokoll.

Start-Bit: ca. 770 µs Puls, ca. 2000 µs Pause
14 Datenbits: ca. 770 µs Puls, ca. 2000 µs Pause oder ca. 620 Pause

Das Start-Bit könnte auch schon ein Datenbit sein, da es kein von den 
Datenbits abweichendes Timing hat.

Fakt ist: das Protokoll ist dem IRMP unbekannt. Ich könnte das Protokoll 
einbauen, wenn Dir die Sache mit der (sehr sehr alten?) 
Telefunken-Fernbedienung wichtig ist. Dazu brauche ich aber Deine 
Mitarbeit, nämlich eine Log-Datei mit möglichst vielen Tasten, darunter 
auch die Tasten 0-9.

Zu den "Sondertasten", die eine abweichende Modulationsfrequenz von 
400kHz verwenden:

Das hört sich ultra-exotisch an. Vermutlich wird da nicht nur eine 
andere Frequenz, sondern auch ein anderes Protokoll benutzt. Offenbar 
hast Du eine Gruppe von Tasten auf der FB, die für mehrere 
Telefunken-Geräte gelten sollen und eine weitere Gruppe, die nur für den 
Fernseher vorgesehen sind.

Wenn Du beide Gruppen auswerten willst, brauchst Du ja schon 2 
verschiedene TSOPs als IR-Empfänger - wegen den unterschiedlichen 
Modulationsfrequenzen. Das macht das Ganze dann nicht einfacher ;-)

Gruß,

Frank

[Frank M. (ukw) (Moderator)]

Fred schrieb:
> Die hama hat die Nr. 00052451 und scheint ein OEM zur VRC-1100 von ORtek
> zu sein.

Ich werde mal danach suchen.

> Eine Logdatei mit 10k hab ich auch erzeugt und angehängt.

Eine erste Analyse mit IRMP unter Linux zeigt:

  - Protokoll ist bisher unbekannt.
  - Es handelt sich um ein Bi-Phase (Manchester) Protokoll.
  - 1 Start-Bit, 18 Datenbits, kein Stop-Bit.

Kann ich in IRMP integrieren, wenn es unbedingt diese FB sein soll ;-)

Gruß,

Frank

[Stefan Z. (stefan_z)]

Hey, danke für das flotte Feedback.

Ja die Telefunken ist exotisch - aber auch der feuchte Traum aller 
90er-Jahre Video-Enthusiasten :-)
Doku hab ich keine gefunden, aber anscheinend war die 1560 dazu da zwei 
Videorecorder zu steuern plus halt eine Glotze. Man kann Code A/B 
wählen, dann werden wirklich alle 38kHz Codes umgestellt und es gibt 
auch ein paar Zusatz-Funktionen wo Makros abgeschickt werden. Das Ganze 
wird garniert mit Uhr auf dem Display, Timerfunktionen und natürlich den 
fetten ALPS-Jogshuttle mit Feder-Ring und Drehknopf :-)
Attraktiv halt, wenn man damit seine µC-Bauten steuern möchte.

Und da Ihr ja wirklich alles an Protokollen integriert habt was zu 
finden ist, passt das doch ganz gut, oder? ;-)

Die Codes werde ich gleich mal alle aufzeichnen und ein nettes ZIP draus 
machen.

Zu den 400kHz Tasten:
Jau, das finde ich auch sehr komisch - vor allem weil ja die Fernseher 
das auch beherrscht haben müssen. Entweder konnten die Telefunken das 
zusätzlich zu den bekannten Fernbedienungen (die haben ja anscheinend in 
verschiedenen Phasen verschiedenen Protokolle genutzt), oder es gab ganz 
besondere Modelle für den Einsatz mit dieser FB. Müsste man mal in einem 
TV-Forum nachfragen...
Um das Signal zu empfangen müsste man den TSOP halt durch einen 
generischen IR-Empfänger ersetzen, der dann halt auf die 400kHz lauscht.
In der Tat ein unattraktiver Gedanke... Aber wer will heute auch schon 
noch dauernd Farbsättigung und Kontrast verstellen? :-)

Ich mach mal ne Codetabelle und Fotos...

Die Ortek-FB sollte im XBMC-Projekt komplett erfasst sein - die Hama 
tuts auf jeden Fall direkt am USB vom Raspberry mit XBMC.

[Frank M. (ukw) (Moderator)]

Stefan Z. schrieb:
> Die Codes werde ich gleich mal alle aufzeichnen und ein nettes ZIP draus
> machen.

Es reichte eine Textdatei - garniert mit Kommentaren über jeder 
Scanzeile. Schau Dir einfach mal die Beispiel-Scan-Dateien im 
Unterverzeichnis IR-Data des IRMP-Projekts an:

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

Drücke bitte die Tasten immer nur ganz kurz, damit ich etwaige 
automatisch generierte Wiederholungsframes erkennen kann.

Als Schmankerl kannst Du dann am Schluß noch 1 oder 2 Tasten, die Du 
bereits mit kurzem Tastendruck gescannt hast, auch mal länger drücken 
und zusätzlich (mit entsprechendem Kommentar) anhängen. Dann erkenne ich 
das Timing von Wiederholungsframes besser, die durch längeres Drücken 
entstanden sind.

Gruß,

Frank

[jar (Gast)]

Stefan Z. schrieb:
> Zu den 400kHz Tasten:
> Jau, das finde ich auch sehr komisch - vor allem weil ja die Fernseher
> das auch beherrscht haben müssen.

es gibt durchaus mehr Geräte die 400kHz verwenden, nur fällt mir auch 
nicht ein wie man die leicht ohne TSOP 30-40 KHz Chips verarbeiten kann

[Stefan Z. (stefan_z)]

So das wären mal die wichtigsten Codes der Telefunken 1560.
Alle im Modus 50us aufgenommen.
Die Zahlentasten liefern leider keine erkennbaren 38kHz Codes - 
vermutlich wird hier auch 400kHz genutzt. Zumindest blinkt die "Senden" 
Anzeige an der FB.

Das Jog Shuttle hat eine recht Komplexe Belegung - habe ich hier erstmal 
nur im "digitalen" PROGR.-Modus reingepackt. Im JOG-Modus hat der 
Federring außen sechs Positionen pro Richtung und wirft auch noch ein 
Signal bei Rückstellung aus. Und das auch getrennt nach von links oder 
rechts Rückstellen. Schon recht pfiffig gemacht.

Das JOG-Rad sendet pro Schritt drei mal die selbe Nachricht wenn ich das 
recht erkenne.

Modus A und B unterscheiden sich auf den ersten Blick nur durch 
geänderte Start-Codes.
Für die ersten zwei tasten hab ich das mal mit reingepackt.
1-0-1-0-1-1-1-1-1 ist A und
1-0-1-0-1-1-1-0-1-1 ist B
Die Gesamt-Nachricht verlängert sich dabei um ein Bit!

Die Pausen bei Tasten-Wiederholung sind die selben wie in den bei den 
Dreier-Nachrichten.

Was mir noch aufgefallen ist:
Ab und zu sendet er eine kurze Nachricht:
000011111111111111 (IRMP 50us Modus)
Ob das so eine Art toter Mann Schalter ist?

Wenn man die Uhr stellt scheint er auch was zu senden, vermutlich auch 
in 400kHz.

Für den 400kHz-Empfang könnte man doch so einen hier nehmen, oder?
http://dx.com/p/high-sensitivity-ir-receiver-photosensitive-diode-light-sensor-for-arduino-152264
Und dann halt "zu Fuß" mit dem Arduino erkennen. (kein sonderlich 
attraktiver Gedanke)

Ansonsten ist die Fernbedienung mal ein geiles Beispiel für gute, 
deutsche Wertarbeit im goldenen Zeitalter der Unterhaltungselektronik.
Wie man am Platinenbild sehen kann wurden sogar die Vias alle 
abgedichtet.
Das Jog ist von ALPS, zum benutzten µC gibt es ein Datenblatt und auch 
sonst ist das Teil wirklich sauber verschraubt und alles.

[jar (Gast)]

Stefan Z. schrieb:
> Für den 400kHz-Empfang könnte man doch so einen hier nehmen, oder?
> http://dx.com/p/high-sensitivity-ir-receiver-photo...
> Und dann halt "zu Fuß" mit dem Arduino erkennen. (kein sonderlich
> attraktiver Gedanke)

schaut so aus, wenn das IC wirklich ein LM393 ist also Komperator, dann 
ist Verstärkung schon mal gesichert, nur noch eine FFT nachschalten und 
um 400kHz und an/aus erkennen

[Stefan Z. (stefan_z)]

jar schrieb:
> schaut so aus, wenn das IC wirklich ein LM393 ist also Komperator, dann
> ist Verstärkung schon mal gesichert, nur noch eine FFT nachschalten und
> um 400kHz und an/aus erkennen

Wenn man nur einen "Ausschnitt" der FFT braucht wäre das ein 
RC-Filterglied, oder?
Also 400khZ isolieren - das was der TSOP mit seiner Center-Frequenz 
macht.
Die Auswertung im µC wird dann aber nervig, weil die Pausen des Signals 
grad mal noch 375ns sind.
Wobei ich grad sehe, dass es immer die selben 8 Bits sind in einer 
400kHz Frequenz, die das "übergeordnete" Bit setzen. Die Gesamtlänge ist 
immer um die 20µS und die des Gesamt-Befehlt 90ms (was ja wiederum recht 
lang ist im Vergleich zu den Sendeimpulsen).
Man könnte also nur die Summe der Impulse als 1 werten.

Schauen wir mal....

[Timo S. (kaffeetas)]

Stefan Z. schrieb:
> Wenn man die Uhr stellt scheint er auch was zu senden, vermutlich auch
> in 400kHz.

Ich habe mal kurz das Datenblatt des µC[1] mit deinem Bild 
verglichen....

Da ist als Taktquelle nur ein Uhrenquarz dran, da der Chip keinen 
internen Taktgenerator hat kann er auch nicht auf 400kHz senden.

Ist die Oberseite bestückt?

Grüße
 Timo

[1] 
http://pdf1.alldatasheet.com/datasheet-pdf/view/6889/NEC/UPD17201A.html

[Stefan Z. (stefan_z)]

Timo S. schrieb:
> Da ist als Taktquelle nur ein Uhrenquarz dran, da der Chip keinen
> internen Taktgenerator hat kann er auch nicht auf 400kHz senden.
Gute Frage, ja.
Der Quarz scheint auch etwas gelitten zu haben, die Uhr geht locker um 1 
Minute pro Tag nach :-)
Werde ich mal neu bestücken müssen.
Steht nix drauf außer: KO1H

> Ist die Oberseite bestückt?
Nur mit passiven teilen wie Jog und Schaltern/Tastern und Hühnerfutter.
Siehe Bilder anbei, hab sie nochmal auseinandergenommen.

Ggfs. sind ja die 400kHz nur eine Begleiterscheinung.
Aber sie sind eindeutig real, denn die Pausen werden ja zuverlässig 
erkannt im Logic und haben auch immer die gleiche Dauer.

[Frank M. (ukw) (Moderator)]

Stefan Z. schrieb:
> So das wären mal die wichtigsten Codes der Telefunken 1560.

Danke, XLS-Datei ist zwar suboptimal, da die Linux-/Windows-Version von 
IRMP nur TXT-Dateien frisst, aber ich habe die Daten dann selbst in eine 
TXT-Datei rüberkopiert. Beim nächsten Mal musst Du das selber machen ;-)

> Alle im Modus 50us aufgenommen.

Ähem... Du meinst mit F_INTERRUPTS = 20000? Ich hatte es vor ein paar 
Tagen so verstanden, dass die zwei Beispiel-Scans von Dir mit 
F_INTERRUPTS = 15000 aufgezeichnet wurden:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Da konnte ich auch die Kollision mit dem SIEMENS-Protokoll direkt 
nachvollziehen.

Ich habe nun anhand Deines Scans das Telefunken-Protokoll in IRMP 
eingebaut - funktioniert soweit, wenn SIEMENS im IRMP abgeschaltet ist.

Um jetzt eine Test-Version rauszugeben, brauche ich von Dir aber jetzt 
noch die Angabe des F_INTERRUPTS-Wertes.

Gruß,

Frank

[Stefan Z. (stefan_z)]

Frank M. schrieb:
> Stefan Z. schrieb:
>> So das wären mal die wichtigsten Codes der Telefunken 1560.
>
> Danke, XLS-Datei ist zwar suboptimal, da die Linux-/Windows-Version von
> IRMP nur TXT-Dateien frisst, aber ich habe die Daten dann selbst in eine
> TXT-Datei rüberkopiert. Beim nächsten Mal musst Du das selber machen ;-)
>
>> Alle im Modus 50us aufgenommen.
>
> Ähem... Du meinst mit F_INTERRUPTS = 20000? Ich hatte es vor ein paar
> Tagen so verstanden, dass die zwei Beispiel-Scans von Dir mit
> F_INTERRUPTS = 15000 aufgezeichnet wurden:
Hmm nee habe das schon auf 20000 geändert. Da steht es auch jetzt noch 
bei mir.

> Da konnte ich auch die Kollision mit dem SIEMENS-Protokoll direkt
> nachvollziehen.
> Ich habe nun anhand Deines Scans das Telefunken-Protokoll in IRMP
> eingebaut - funktioniert soweit, wenn SIEMENS im IRMP abgeschaltet ist.
sweet!

> Um jetzt eine Test-Version rauszugeben, brauche ich von Dir aber jetzt
> noch die Angabe des F_INTERRUPTS-Wertes.
wie gesagt: 20000 hier in meiner config.

[Stefan Z. (stefan_z)]

Hier noch mal die ersten 10 Tasten als 66us Scan.
Also mit F_INTERRUPTS = 15000

[Frank M. (ukw) (Moderator)]

Es gibt nun im SVN eine neue IRMP-Version 2.3.9

Änderungen:

   - Neues Protokoll ORTEK (Hama)
   - Neues Protokoll TELEFUNKEN

Stefan Z. schrieb:
> Hier noch mal die ersten 10 Tasten als 66us Scan.
> Also mit F_INTERRUPTS = 15000

Danke, wird von IRMP nun einwandfrei erkannt.

Du findest im SVN im Ordner IR-Data die Datei telefunken-1560-20kHz.txt, 
in welcher alle Deine Scans aus der XLS-Datei enthalten sind. Diese 
werden von IRMP allesamt korrekt erkannt.

Bitte teste mal die neue Version.

@Fred:

Deine Hama-FB sollte nun auch erkannt werden, wenn Du das 
ORTEK-Protokoll aktivierst. Im Moment ist da noch ein kleiner Haken: 
Jeder Tastendruck erzeugt offenbar 3 Frames. Deshalb gibt IRMP im Moment 
noch alles dreifach zurück, einmal mit flags = 0x00 und zweimal mit 
flags = 0x01 (Wiederholung). Das liegt daran, dass ich von 3 speziellen 
Bits im ORTEK-Frame bisher nur 2 entschlüsselt habe. Die Funktion des 3. 
Bits ist mir im Moment noch unklar. Da muss ich also noch nachbessern.

Dafür brauche ich aber Deine Hilfe: Zeichne bitte nochmal eine beliebige 
Taste (am besten die 0) auf, indem Du diese Taste so kurz wie möglich 
drückst. Ich will mir mit den minimal 3 Frames sicher sein.

Vielen Dank und Gruß,

Frank

[Stefan Z. (stefan_z)]

Frank M. schrieb:
> Du findest im SVN im Ordner IR-Data die Datei telefunken-1560-20kHz.txt,
> in welcher alle Deine Scans aus der XLS-Datei enthalten sind. Diese
> werden von IRMP allesamt korrekt erkannt.
>
> Bitte teste mal die neue Version.

Habs mal schnell in die Arduino-Lib eingebastelt und es läuft!
Super Sache, vielen Dank!

Bleibt nur noch die Frage, ob das wirklich ein eigenes 
Telefunken-Protokoll ist oder von was anderem abstammt. Oder ob es nur 
für diese Videorecorder gedacht war.

[Fred (Gast)]

Frank M. schrieb:
> Eine erste Analyse mit IRMP unter Linux zeigt:
>
>   - Protokoll ist bisher unbekannt.
>   - Es handelt sich um ein Bi-Phase (Manchester) Protokoll.
>   - 1 Start-Bit, 18 Datenbits, kein Stop-Bit.
>
> Kann ich in IRMP integrieren, wenn es unbedingt diese FB sein soll ;-)

Hallo,

das wäre natürlich ganz toll. :-)

Aber wie ich gerade sehe, ist das schon im SVN enthalten?!?
Wie geht denn das? Hattest du schon eine FB greifbar?

An eine Art Manchestercodierung hatte ich auch gedacht, nur
habe ich da die Logik dahinter nicht erkannt.

Wenn ich es nun genauer ansehe, scheint es doch klar zu sein.
Mich haben die unterschiedlichen Pulse und Pausen verwirrt.

Kann ich doch noch mit Scans o.ä. behilflich sein?

Gruß Fred

[Frank M. (ukw) (Moderator)]

Fred schrieb:

> Aber wie ich gerade sehe, ist das schon im SVN enthalten?!?

Ja, hatte ich hier doch gestern geschrieben:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Bitte testen, bzw. die dort an Dich gerichtete Bitte ausführen ;-)

> Wie geht denn das? Hattest du schon eine FB greifbar?

Nein, aber Deine Logs, siehe hier:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

> Kann ich doch noch mit Scans o.ä. behilflich sein?

Ja, siehe mein Posting von gestern, da steht:

@Fred:

Deine Hama-FB sollte nun auch erkannt werden, wenn Du das
ORTEK-Protokoll aktivierst. Im Moment ist da noch ein kleiner Haken:
Jeder Tastendruck erzeugt offenbar 3 Frames. Deshalb gibt IRMP im Moment
noch alles dreifach zurück, einmal mit flags = 0x00 und zweimal mit
flags = 0x01 (Wiederholung). Das liegt daran, dass ich von 3 speziellen
Bits im ORTEK-Frame bisher nur 2 entschlüsselt habe. Die Funktion des 3.
Bits ist mir im Moment noch unklar. Da muss ich also noch nachbessern.

Dafür brauche ich aber Deine Hilfe: Zeichne bitte nochmal eine beliebige
Taste (am besten die 0) auf, indem Du diese Taste so kurz wie möglich
drückst. Ich will mir mit den minimal 3 Frames sicher sein.

Gruß,

Frank

[Fred (Gast)]

Hallo Frank,

das hab ich doch glatt überlesen :-)

Ich habe nun etwas experimentiert, die kürzeste Sequenz besteht immer
aus drei Frames. Weniger geht einfach nicht.
Wie man aber auch im Bild sieht gibt es eine Startframe(1) dann 1-x
Wiederholungsframes(2) und einen Stopframe(3).
So hat es sich bei allen Tastendrücken mit einer Taste verhalten.

Im Anhang hab ich nun einen 10k Log mit alle Tasten der Fernbedienung
durchgeführt. Es sollten immer nur drei Frames sein.

Vielleicht kann man nun die Logik anhand aller Tasten erkennen-


Gruß Fred

[Frank M. (ukw) (Moderator)]

Hallo Fred,

Fred schrieb:

> Ich habe nun etwas experimentiert, die kürzeste Sequenz besteht immer
> aus drei Frames. Weniger geht einfach nicht.

Okay, das hilft mir schon mal weiter.

> Wie man aber auch im Bild sieht gibt es eine Startframe(1) dann 1-x
> Wiederholungsframes(2) und einen Stopframe(3).

Ja, genau so habe ich das auch verstanden. Ob es ein Start-, 
Wiederholungs- oder Stop-Frame ist, erkennt man an zwei Bits. Bleibt 
noch das dritte unbekannte. Ich vermute, dass es ein CRC-Bit ist.

> Im Anhang hab ich nun einen 10k Log mit alle Tasten der Fernbedienung
> durchgeführt. Es sollten immer nur drei Frames sein.

Super, vielen Dank. Wenn es ein CRC-Bit ist, dann bekomme ich es raus. 
Wenn nicht, wird IRMP es einfach ignorieren. Dann habe ich aber leider 
keine (oder nur eine geringe) Chance, per IRSND den Frame beim Senden 
wieder vollständig zu rekonstruieren...

Ich melde mich, sobald ich die Bedeutung des Bits verstanden habe.

Viele Grüße,

Frank

[Fred (Gast)]

Hallo Frank,

bist du schon etwas weitergekommen?

Ich habe mal versucht die Logdatei in eine lesbarere Form zu bringen.
Wenn mir da jetzt kein Fehler unterlaufen ist, sind die Frames für
die Maus ein Bit kürzer.

Nach der Startsequenz kommt 0 für Tasten und 1 für die Maus,
danach fix die 1010 und danach die 2 Bit für die Frameart.

Nun scheinen 6 Bit für den Code zu kommen und dann noch 4 Bit,
die sich nur zwischen Start und den anderen beiden Frames unterscheidet.
Also kann es eigentlich keine CRC o.ä. sein.

Anderes ist es bei der Maus, da sind es nur 5 Bit und dann diese 4 Bit.
Hier unterscheiden sie sich aber wieder zwischen Wiederholung und Ende.
Es gibt aber auch keinen Startframe.

Irgendwie verwirrt mich das Ganze. Oder habe ich einen Fehler in der 
Umsetzung?

Gruß Fred

[jar (Gast)]

hallo Frank,

sollte der Test im SVN nicht mal geändert werden ?

"Auch die japanischen Hersteller haben versucht, einen eigenen Standard 
zu etablieren, nämlich das sog. Kaseikyo- (oder auch "Japan-") 
Protokoll. Dieses ist mit einer Bitlänge von 48 sehr universell und 
allgemein verwendbar. Richtig durchgesetzt hat es sich aber bis heute 
nicht. Ich selbst habe persönlich noch keine einzige Fernbedienung 
gesehen, die das Kaseikyo-Protokoll nutzt."

bei mir alle Panasonic Festplattenrecorder DMR-EX79 und DMR-EX93

sorry das ich noch mal nerve, warum gibst du das toogle bit bei RC5 
nicht aus ?, ich weiss du hast mehrere Methoden genannt wie man 
Wiederholung oder Neudrücken erkennen kann, aber warum soll das der 
Anwender machen wenn das toogle bit schon in der FB erzeugt wird ?

Es muss doch einen Grund geben warum du das toogle bit nicht ausgibst, 
für Address und Data ist es zwar nicht nötig, aber deswegen nicht 
ausgeben ? ich sehe den Grund dafür nicht, das toogle bit kann auch vom 
Anwender bei Bedarf ignoriert werden wenn nötig, es schon im IRMP zu 
unterschlagen sehe ich nicht als zwingend an.....

LG jar

[Frank M. (ukw) (Moderator)]

jar schrieb:
> sollte der Test im SVN nicht mal geändert werden ?

Ja, mach ich - auch wenn ich bis heute immer noch keine FB in den Händen 
hatte, die das Kaseikyo-Protokoll verwendet.

> sorry das ich noch mal nerve, warum gibst du das toogle bit bei RC5
> nicht aus ?, ich weiss du hast mehrere Methoden genannt wie man
> Wiederholung oder Neudrücken erkennen kann, aber warum soll das der
> Anwender machen wenn das toogle bit schon in der FB erzeugt wird ?

Ganz einfach:

Weil bis auf 2 weitere Protokolle alle anderen von den über 30 
Protokollen, die IRMP unterstützt, überhaupt kein Toggle-Bit haben.

Warum soll IRMP bei 3 Protokollen die Toggle-Bits ausgeben und bei den 
anderen Protokollen den User im Regen stehen lassen?

> Es muss doch einen Grund geben warum du das toogle bit nicht ausgibst,
> für Address und Data ist es zwar nicht nötig, aber deswegen nicht
> ausgeben ? ich sehe den Grund dafür nicht, das toogle bit kann auch vom
> Anwender bei Bedarf ignoriert werden wenn nötig, es schon im IRMP zu
> unterschlagen sehe ich nicht als zwingend an.....

Dann müsste der Anwender die 3 Protokolle, die ein Toggle-Bit haben, 
anders handhaben als die anderen 29 Protokolle. Das ist doch Unsinn. 
Wenn ich eine X-beliebige FB anlernen will und die Werte Protokoll, 
Adresse und Kommando im EEPROM speichere, reicht das doch! Warum soll 
ich als Anwender jetzt noch RC5, RC6 und RECS80 anders abwickeln 
müssen als die anderen Protokolle?

IRMP hat ein einheitliches Konzept für alle unterstützten Protokolle, 
wie man lang gedrückte Tasten erkennt. Du persönlich hast leider das 
Problem, dass Du es nicht schaffst, dieses Konzept in Deinen alten 
RC5-Decoder, den Du noch verwendest, reinzubauen. Du hängst Dich viel zu 
stark an Dein altes Programm. Komm weg vom Toggle-Bit! Irgendwann ist 
Deine RC5-FB kaputt und dann nimmst Du eine NEC-FB und jammerst, dass Du 
dann gar kein Toggle-Bit mehr hast....

Also: schreib Dein Programm um, statt es zu vergewaltigen.

[Frank M. (ukw) (Moderator)]

Fred schrieb:
> bist du schon etwas weitergekommen?

Sorry, habe am Wochenende keine Zeit dafür gefunden.

> Ich habe mal versucht die Logdatei in eine lesbarere Form zu bringen.
> Wenn mir da jetzt kein Fehler unterlaufen ist, sind die Frames für
> die Maus ein Bit kürzer.

Hast Du das manuell im Kopf gemacht?

> Irgendwie verwirrt mich das Ganze. Oder habe ich einen Fehler in der
> Umsetzung?

Kann ich Dir noch nicht sagen. Hier der Output vom IRMP, wenn ich ihn 
auf Deine Logs loslasse:

# Power
001010110011111110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x00
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010100011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
-------------------------------------------------------------------
# Power lang
001010110011111110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x00
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010010011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
001010100011110110 p=33 (ORTEK), a=0x000a, c=0x000f, f=0x01
-------------------------------------------------------------------
# ok
001010111011101110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x00
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010101011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
-------------------------------------------------------------------
# ok lang
001010111011101110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x00
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010011011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
001010101011100110 p=33 (ORTEK), a=0x000a, c=0x002e, f=0x01
-------------------------------------------------------------------
# 0
001010111010100110 p=33 (ORTEK), a=0x000a, c=0x002a, f=0x00
001010011010101010 p=33 (ORTEK), a=0x000a, c=0x002a, f=0x01
001010101010101010 p=33 (ORTEK), a=0x000a, c=0x002a, f=0x01
-------------------------------------------------------------------
# 1
001010111101000110 p=33 (ORTEK), a=0x000a, c=0x0034, f=0x00
001010011101001010 p=33 (ORTEK), a=0x000a, c=0x0034, f=0x01
001010101101001010 p=33 (ORTEK), a=0x000a, c=0x0034, f=0x01
-------------------------------------------------------------------
# 2
001010111101101110 p=33 (ORTEK), a=0x000a, c=0x0036, f=0x00
001010011101100110 p=33 (ORTEK), a=0x000a, c=0x0036, f=0x01
001010101101100110 p=33 (ORTEK), a=0x000a, c=0x0036, f=0x01
-------------------------------------------------------------------
# 3
001010110000010010 p=33 (ORTEK), a=0x000a, c=0x0001, f=0x00
001010010000011100 p=33 (ORTEK), a=0x000a, c=0x0001, f=0x01
001010100000011100 p=33 (ORTEK), a=0x000a, c=0x0001, f=0x01
-------------------------------------------------------------------
# 4
001010110101001010 p=33 (ORTEK), a=0x000a, c=0x0014, f=0x00
001010010101000010 p=33 (ORTEK), a=0x000a, c=0x0014, f=0x01
001010100101000010 p=33 (ORTEK), a=0x000a, c=0x0014, f=0x01
-------------------------------------------------------------------
# 5
001010110011100110 p=33 (ORTEK), a=0x000a, c=0x000e, f=0x00
001010010011101010 p=33 (ORTEK), a=0x000a, c=0x000e, f=0x01
001010100011101010 p=33 (ORTEK), a=0x000a, c=0x000e, f=0x01
-------------------------------------------------------------------
# 6
001010111000011010 p=33 (ORTEK), a=0x000a, c=0x0021, f=0x00
001010011000010010 p=33 (ORTEK), a=0x000a, c=0x0021, f=0x01
001010101000010010 p=33 (ORTEK), a=0x000a, c=0x0021, f=0x01
-------------------------------------------------------------------
# 7
001010110100101010 p=33 (ORTEK), a=0x000a, c=0x0012, f=0x00
001010010100100010 p=33 (ORTEK), a=0x000a, c=0x0012, f=0x01
001010100100100010 p=33 (ORTEK), a=0x000a, c=0x0012, f=0x01
-------------------------------------------------------------------
# 8
001010110101100110 p=33 (ORTEK), a=0x000a, c=0x0016, f=0x00
001010010101101010 p=33 (ORTEK), a=0x000a, c=0x0016, f=0x01
001010100101101010 p=33 (ORTEK), a=0x000a, c=0x0016, f=0x01
-------------------------------------------------------------------
# 9
001010111001100110 p=33 (ORTEK), a=0x000a, c=0x0026, f=0x00
001010011001101010 p=33 (ORTEK), a=0x000a, c=0x0026, f=0x01
001010101001101010 p=33 (ORTEK), a=0x000a, c=0x0026, f=0x01

Das 7. und 8. Bit ist zuständig für die Kennzeichnung des Frames:

11: Start-Frame
01: Ist n'ter Wiederholungsframe, n >= 1
10: Stop-Frame

Das letzte Bit scheint immer 0 zu sein. Das vorletzte Bit ist immer 1. 
Aber das drittletzte Bit ist mal 0, mal 1 im Start-Frame, dann 
invertiert im Wiederholungs- und Stop-Frame. Das sieht mir nach einem 
Parity-Bit aus. CRC war auch die falsche Formulierung dafür ;-)

Letzte Frage: Spuckt IRMP denn jetzt Protokoll, Adresse und Kommando bei 
Deiner HAMA-FB aus? Bitte aktiviere erstmal nur die 6 
Standard-Protokolle und ORTEK. Wenn man nämlich noch FDC aktiviert, gibt 
es einen Konflikt bei der Erkennung, den ich erst noch beseitigen muss.

Gruß,

Frank

[jar (Gast)]

Frank M. schrieb:
> Warum soll IRMP bei 3 Protokollen die Toggle-Bits ausgeben und bei den
> anderen Protokollen den User im Regen stehen lassen?

verstehe ich ja, aber wenn vorhanden warum nicht ausgeben ?

dein Konzept von IRMP ist toll, IRMP absolut genial, aber ECHTE 
GELIEFERTE Daten von 3 Protokollen nur deswegen zu unterdrücken weil 
andere sie nicht liefern kanns doch auch nicht sein ?

ich verstehe ja was du schreibst aber verstehen tue ich deswegen 
trotzdem die Datenmanipulation nicht (was anderes ist es ja nicht wenn 
du Daten aus dem Datenstrom nicht weiterleitest)

[jar (Gast)]

wenn du wenigstens das toogle bit als MSB im Data ausgeben würdest, das 
würde andere die es nicht brauche nicht stören, MSB einfach ignorieren 
oder als &7F FF maskieren

[jar (Gast)]

ach ne, ich weiss zu wenig, damit würden ja codes um F0 00 rausfallen

ich glaube ich verstehe langsam warum du nicht ausgeben möchtest, das 
Data Code Paket ist zu klein ?

[jar (Gast)]

übrigens Panasonic

Kaseikyo

die Daten von Recorder 1 und Recorder 2 unterscheiden sich im LSB ist 
ein Kommando c0 10 im einem ist es im anderen c0 11 immer LSB +1

[jar (Gast)]

genauer gesagt nicht LSB sondern nibble
+0
+1
+2
+3

[Frank M. (ukw) (Moderator)]

jar schrieb:
> dein Konzept von IRMP ist toll, IRMP absolut genial, aber ECHTE
> GELIEFERTE Daten von 3 Protokollen nur deswegen zu unterdrücken weil
> andere sie nicht liefern kanns doch auch nicht sein ?

Doch. Der Anwender muss sich um eventuell vorhandene Toggle-Bits nicht 
kümmern. Er wertet einfach die Flags aus. Ist im flag das Bit 
IRMP_FLAG_REPETITION gesetzt, dann handelt es sich um einen langen 
Tastendruck. Einfacher gehts nicht.

> ich verstehe ja was du schreibst aber verstehen tue ich deswegen
> trotzdem die Datenmanipulation nicht (was anderes ist es ja nicht wenn
> du Daten aus dem Datenstrom nicht weiterleitest)

Ich manipuliere keine Daten. Das Toggle-Bit von RC5 gehört weder zur 
Adresse noch zum Kommando. Und genau diese gibt IRMP zurück. Wenn ein 
Anwender ein- und dieselbe Taste mehrfach oder lang drückt, bekommt er 
IMMER dasselbe Kommando zurück.

Merkst Du eigentlich nicht, dass Du der einzige Anwender bist, der damit 
ein Problem hat? Ich weiß auch, warum: Du hast ein uraltes Programm, was 
mühsam das Toggle-Bit auswertet, um damit lange und kurze Tasten 
auszuwerten. Und Du schaffst es einfach nicht, das Programm 
umzuschreiben und einfach flags auf IRMP_FLAG_REPETITION zu testen.

[jar (Gast)]

Frank M. schrieb:
> Ich manipuliere keine Daten.

ich mag nicht streiten, aber

> Das Toggle-Bit von RC5 gehört weder zur
> Adresse noch zum Kommando.

OK weiß ich und akzeptiere ich, aber ich hoffe wir sind einig das es im 
gesendeten IR Strom ist und nicht ausgegeben wird ?

wenn Infos wo ankommen aber nicht weitergeleitet werden, ist das nicht 
Zensur ? (oder darf man das nicht Datenmanipulation nennen ?)

> Merkst Du eigentlich nicht, dass Du der einzige Anwender bist, der damit
> ein Problem hat?

das weiß ich nicht !

> ...Du schaffst es einfach nicht, das Programm
> umzuschreiben und einfach flags auf IRMP_FLAG_REPETITION zu testen.

das bestreite ich nicht, ich merkte nur an das was gesendet wird nicht 
als volle Info aus IRMP kommt ;-)

[jar (Gast)]

lieber oder verehrter Frank,

ich denke du bist sauer, das tut mir leid, anders kann ich mir diesen 
Satz nicht erklären:

"Auch die japanischen Hersteller haben versucht, einen eigenen Standard 
zu etablieren, nämlich das sog. Kaseikyo- (oder auch "Japan-") 
Protokoll. Dieses ist mit einer Bitlänge von 48 sehr universell und 
allgemein verwendbar. Richtig durchgesetzt hat es sich aber bis heute 
nicht - auch wenn man es hie und da im heimischen Haushalt vorfindet."

wenn ich die Popularität bei Idealo schaue
http://www.idealo.de/preisvergleich/AlleTestProdukte/4654.html?param.resultlist.sortKey=clicks

dann liegen auf Seite 1 von 15 Festplattenrecordern 10x Panasonic
un die verwenden ?

[Frank M. (ukw) (Moderator)]

jar schrieb:

> OK weiß ich und akzeptiere ich, aber ich hoffe wir sind einig das es im
> gesendeten IR Strom ist und nicht ausgegeben wird ?

Es werden vom IRMP viele Bits nicht ausgegeben. Man denke nur an die 48 
Bits vom Kaseikyo-Protokoll. Da passen schon technisch gesehen nur 16 
(Adresse) + 16 (Kommando) + 4 (oberes Nibble von flags) = 36 Bits in die 
IRMP-Struct. Damit "unterdrücke" ich insg. 48 - 36 = 12 Bits!

Aber: Diese 12 Bits sind redundant, d.h. es sind CRCs und Checksums. 
IRSND kann sie beim Senden spielend aus den 36 IRMP-Bits rekonstruieren. 
Deshalb gehören sie auch nicht in die IRMP-Struct.

Genauso ist es bei Deinem popeligen Toggle-Bit. Es gehört da nicht rein! 
Auch IRSND produziert ein korrektes Toggle-Bit aus der IRMP-Struct.

> wenn Infos wo ankommen aber nicht weitergeleitet werden, ist das nicht
> Zensur ? (oder darf man das nicht Datenmanipulation nennen ?)

Zensur? Ich darf sogar ein Programm schreiben, was Dir nur ein einziges 
Bit von Deiner RC5-FB ausspuckt.

IRMP unterliegt der GPL. Du darfst es nach Herzenslust für Deine 
Bedürfnisse anpasssen. Ich verstehe nicht, warum ich mir da Arbeit 
machen soll, damit Du Dir Arbeit sparst. Du bist allein mit Deinem 
Toggle-Bit-Problem, weil Du Deine Anwendung nicht an IRMP anpasst. 
Stattdessen erwartest Du, dass ich IRMP an Deine Anwendung anpasse. So 
geht das nicht!

>> Merkst Du eigentlich nicht, dass Du der einzige Anwender bist, der damit
>> ein Problem hat?
> das weiß ich nicht !

Ich aber. Keiner der IRMP-Anwender hat bisher den Wunsch nach einem 
Toggle-Bit geäußert. Warum auch? Dafür gibt es irmp_data.flags. Das ist 
viel einfacher.

> das bestreite ich nicht, ich merkte nur an das was gesendet wird nicht
> als volle Info aus IRMP kommt ;-)

Doch, die Info Protokoll, Adresse, Kommando und langer Tastendruck ist 
da. IRMP ist kein Programm, was einen RAW-Datenstrom ausgibt. Den 
erwartest Du aber. Dann ist IRMP nicht das richtige Programm für Dich.

[Frank M. (ukw) (Moderator)]

jar schrieb:
> dann liegen auf Seite 1 von 15 Festplattenrecordern 10x Panasonic
> un die verwenden ?

Wahrscheinlich Kaseikyo. Ja und? Wieviel Prozent der Haushalte haben 
einen Festplattenrecorder? Frag mal lieber, wieviel Prozent einen 
Fernseher, einen CD/DVD-Player oder ein Kombigerät haben. Meine benutzen 
da alle das NEC-Protokoll.

Aber wir können ja mal eine Umfrage machen.... wer hat was zu Hause im 
realen Einsatz?

Ich lege mal vor:

Frank: 6 x NEC, 1 x Dreambox (von IRMP nicht unterstützt... seufz)

[jar (Gast)]

Frank M. schrieb:
> Frank: 6 x NEC, 1 x Dreambox (von IRMP nicht unterstützt... seufz)

Jar: 3x Samsung32, 3x  Kaseikyo, 3x RC5, 1x NEC. (vom JVC TV weiss ich 
grad nicht)

[Sebastian .. (zahlenfreak)]

Sebastian: 2x NEC, 2x DENON


Davon abgesehen muss ich jetzt doch mal eine Lanze für Frank brechen.

Jar, es ist absolut in Ordnung, dass du dir das Toggle-Bit für RC5 
wünschst. Ich verstehe sogar, dass es dir momentan die Arbeit leichter 
machen würde. Aber du musst auch verstehen, dass du hier jemand bittest 
Arbeit kostenlos für dich zu machen. Und das nachdem er von sich aus 
schon sehr viel Arbeit in diese Software gesteckt hat. Das ist in 
Ordnung, aber du musst verstehen, dass Frank dann selbst entscheidet, 
was er umsetzt und was nicht. Und selbst wenn er einfach keine Lust 
hätte (was meiner Ansicht nach nicht der Fall ist) müsstest du das 
Akzeptieren.
Frank hat dir sogar mehrmals erläutert, warum das Toggle-bit aus 
technischer Sicht nicht zu IRMP passt. Irgendwann sollte man 
akzeptieren, dass es nicht umgesetzt wird.
Und im Übrigen kann ich mich an keinen Fall erinnern, in dem Frank einen 
Wunsch aus dem Forum ausgeschlagen hätte, wenn er technisch sinnvoll 
unsetzbar war. Im gegenteil: Oft war die Lösung schon nach wenigen Tagen 
voll funktionsfähig in IRMP integriert. Ich selbst hatte auch schon 
Änderungswünsche. Meist hab ich dann länger gebraucht die Änderungen zu 
testen als Frank gebraucht hat, sie zu implementieren. Im Forum gibt es 
nicht viele, die ein Projekt so engagiert betreuen wie Frank. Da ist es 
absolut legitim, wenn er dann doch mal was nicht umsetzt.

Viele Grüße,

Sebastian

[Stefan Z. (stefan_z)]

Sebastian ... schrieb:
> Oft war die Lösung schon nach wenigen Tagen
> voll funktionsfähig in IRMP integriert.

Da schließe ich mich an - siehe das Telefunken-Protokoll von letzter 
Woche...
Das Toggle-Bit ist einfach redundant - und fertig.
Entweder du erweiterst den Code um eine Option (bzw. Compiler-Weiche um 
den Code nicht aufzublähen), oder du passt eben deinen Code an.

[Fred (Gast)]

Hallo Frank,

nun bin ich mal wieder dazugekommen etwas mit der ORTEK zu testen.
Ich habe die aktuelle Version von heute verwendet und alle Protokolle
aktiviert. Hier gibt es tatsächlich Erkennungprobleme. Also
Siemens, FDC und Netbox deaktiviert und dann klappt es.

Es wird Protokoll 0x21 und Addresse 0x000A erkannt.
Nur die Maustasten und -kreuz geben nichts zurück.

Gruß Fred

[Joachim B. (jar)]

Sebastian ... schrieb:
> Sebastian: 2x NEC, 2x DENON
> Davon abgesehen muss ich jetzt doch mal eine Lanze für Frank brechen.

brauchst du nicht, ich bin ja seit IRMP durchaus ein Fan und kein 
"Gegner"

> Jar, es ist absolut in Ordnung, dass du dir das Toggle-Bit für RC5
> wünschst. Ich verstehe sogar, dass es dir momentan die Arbeit leichter
> machen würde.
> Aber du musst auch verstehen,

ne muss (oder will?) ich nicht

> du musst verstehen, dass Frank dann selbst entscheidet,
> was er umsetzt und was nicht.

das wiederum verstehe ich

> Und selbst wenn er einfach keine Lust
> hätte (was meiner Ansicht nach nicht der Fall ist)
> müsstest du das verstehen
> Frank hat dir sogar mehrmals erläutert, warum das Toggle-bit aus
> technischer Sicht nicht zu IRMP passt.

OK ich gestehe das ich kein so guter Progger bin, das ich es eben nicht 
verstehe und selbst wenn das toggle bit nur Redundanz ist, was ist 
schlecht an Redundanz ?

> Irgendwann sollte man
> akzeptieren, dass es nicht umgesetzt wird.

werde ich wohl müssen

> Und im Übrigen kann ich mich an keinen Fall erinnern, in dem Frank einen
> Wunsch aus dem Forum ausgeschlagen hätte, wenn er technisch sinnvoll
> unsetzbar war. Im gegenteil: Oft war die Lösung schon nach wenigen Tagen
> voll funktionsfähig in IRMP integriert. Ich selbst hatte auch schon
> Änderungswünsche. Meist hab ich dann länger gebraucht die Änderungen zu
> testen als Frank gebraucht hat, sie zu implementieren. Im Forum gibt es
> nicht viele, die ein Projekt so engagiert betreuen wie Frank. Da ist es
> absolut legitim, wenn er dann doch mal was nicht umsetzt.

eben weil Frank so intensiv und schnell viele Wünsche umsetzt hatte ich 
ein klein wenig Hoffnung das er evt. über meinen Wunsch noch mal 
nachdenkt und einen Weg findet es zu integrieren, klar gehen ihm die 
Bits aus, aber ich erinnere mich an eine Speziallösung wo er benötigte 
Daten in ein Nibble auslagerte, obwohl es eigentlich nicht in seine 
Datenstruktur passte.

[Jemand (Gast)]

Hallo zusammen,

zuerst: IRMP ist super! Damit habe sogar ich es geschafft mit wenig 
zeitaufwand eine IR Fernbedienung in mein kleines LED Projekt 
einzubauen.

Und ndatürlich habe ich auch eine kleine Frage:
Mir scheint es also ob ein zweiter timer (hier Timer 0 bei einem Mega16) 
den Empfang stört.

void timer0_init (void)
{
  TCCR0 = (1<<WGM01)|(1<<CS02)|(1<<CS00);                             //CTC Modus
//  TCCR0 |=(1<<CS02); //Presclaer = 256
  OCR0=255;      //Compare Wert
  TIMSK=(1<<OCIE0);  //Timer starten
}

Wenn jedenfalls der zweite Timer läuft, klappt der Empfang nicht mehr. 
Oder liegt mein Fehler woanders?

Gruß
Joachim

[Karol B. (johnpatcher)]

Jemand schrieb:
> Oder liegt mein Fehler woanders?

Ja.

Was machst du denn in der entsprechenden OC ISR? Vielleicht dauert die 
zu lange und der AVR "verschluckt" Interrupts?

Übrigens:

  TIMSK=(1<<OCIE0);  //Timer starten

Der Kommentar ist hier ein wenig irreführend. "Starten" tust du den 
Timer/Counter durch das Setzen eines entsprechenden Prescalers. Das 
Register TIMSK ist dafür verantwortlich, dass du verschiedene Interrupts 
in Bezug auf die Timer ein bzw. ausschalten kannst.

In deinem Fall kann es durchaus sein, dass du den Timer/Counter, welcher 
für IRMP zuständig ist, wieder deaktivierst, weil du TIMSK mit "=" und 
nicht mit "|=" beschreibst und damit eventuell vorher getätigte 
Einstellungen überschreibst.

[Jemand (Gast)]

Hallo!
@Karol: 100 Punkte! :-)
Genau daran lag es. Ich habe TIMSK komplett überschrieben. Und danke für 
den Hinweis!

Gruß
Joachim

[Conny G. (conny_g)]

Hallo Frank,
vielen Dank für Deine Tests und Modifikationen beim RECS80.

Ich hatte nun 2 Wochen keine Möglichkeit weiter zu machen und habe jetzt 
erstmal meine Hardware ein Stück weiter gebracht - den Prototypen meines 
mit 868 Mhz Funk angesteuerten IR-Satelliten fertig stellen.

(Ganz nebenbei, falls Dich mal interessiert, was man so mit IRMP/IRSND 
anstellt:
Zielsetzung: meine sich entwickelnde Mini-Home Automation Zentrale - 
Raspberry Pi und angeschlossene AVR-Schaltungen - soll auch IR in allen 
Räumen / für alle Geräte können, u.a. über SiriProxy, z.B. per 
Sprachkommando IR-Serien auslösen, z.B. TV/Audio auf Apple TV 
umschalten, Apple TV einschalten.
Mit Siri Funksteckdosen schalten und eine eigene 
bissle-intelligenter-als-Funksteckdose-Relaissatelliten schalten geht 
schon: "Espressomaschine ausschalten!" oder "Espressomaschine Status?" 
-> "Die Espressomaschine ist aus.", großer Spass ).

Gestern/heute habe ich die neue Version (gerade gelesen es ist schon 
nicht mehr die neueste) eingebaut und zumindest geht gerade das Senden 
des RECS80 nicht mehr, es kommt kein Signal aus dem Atmel.
Beim Durchsehen des Code habe ich die Ursache gerade aber nicht finden 
können. Ansonsten fehlte noch meine Modifikation bzgl. des doppelten 
Startbits in der neuen Version, übersehen oder Absicht?

Gerade zum Doppelcheck nochmal die meine alte Version verwendet, da 
geht's.
Wie kann ich helfen das Problem zu finden?

[Markus (Gast)]

Guten Abend

Ich habe mal eine kurze Frage. Es gibt ja ein paar Protokolle die von 
IRMP und IRSND noch nicht unterstützt werden und somit auch nicht 
verarbeitet und gesendet werden können. Jetzt würde ich aber gerne so 
ein nicht unterstüzten Protokoll per IRSND senden um mein Gerät im 
Schrank zu bedienen. Meine Frage ist jetzt kann ich das irgendwie 
Software mäßig realiesieren? Ich würde gerne einfach das Signal was per 
IRMP empfangen wurde 1:1 per IRSND senden. Aber dafür muss ich es ja 
manual auf eine Trägerfrequenz z.B 36khz modellieren. Oder kann ich das 
über die Callback Funktion machen?

Gruß
Markus

[Conny G. (conny_g)]

Hallo Markus,

was Du machen möchtest ist ein Repeater, wie dieser hier:
http://www.ocinside.de/go_d.html?http://www.ocinside.de/html/modding/ir_repeater/ir_repeater_d.html

diese Schaltung hab ich auch schon mal nachgebaut und funktioniert so:
der TSOP demoduliert das Signal (von den 36 od. 38 kHz) und gibt Dir die 
zugrundeliegenden 0/1.
Dahinter hat die Schaltung einen "Schwingkreis" der 38 kHz moduliert und 
dieser wird vom Signal des TSOP über einen Transistor 
ein-/ausgeschaltet.
Schliesslich verstärkt ein weiterer Transistor das Signal des 
Schwingkreises für die IR-LEDs.

Das könnte man auch über einen AVR machen:
das TSOP-Signal wird mit dem AVR empfangen und das Timing protokolliert.
Und dann entweder per Hand oder PWM die 36/38 kHz moduliert und diese 
gemäß dem aufgezeichneten Timing ein-/ausgeschaltet.

Das wäre ein Weg der ganz auf IRMP/IRSND verzichtet und wo Du das 
Protokoll etc. nicht kennen musst.

VG,
Konrad

[Conny G. (conny_g)]

... vergass vorab noch zu sagen: IRMP/IRSND gehen grundsätzlich von dem 
Ansatz aus das Protokoll zu erkennen, d.h. IRSND kann nicht senden ohne 
ein implementiertes Protokoll und IRMP muss das Protokoll ebenfalls 
erkennen um die Daten aufzuzeichnen.

[Markus (Gast)]

Danke Konrad

das habe ich mir fast gedacht. An einen Repeater habe ich auch schon 
gedacht. Habe nur gedacht da man ja mit IRMP auch unbekannte Protokolle 
scannen kann, man diese evtl. auch einfach wieder auf einen Träger 
modelieren und wieder senden kann. Da ich IRMP und IRSND auf jedenfall 
benötige, wollte ich versuchen auf zusätzliche Hardware zu verzichten. 
Ein weiterer Vorteil wäre gewesen das die unbekannten Signale nur dann 
gesendet würden wenn IRMP sie nicht kennt, der Repeater würde ja alle 
Signale weiterleiten.

Gruß
Markus

[Conny G. (conny_g)]

Ach so... man kann mit IRMP auch unbekannte Protokolle scannen? Das ist 
mir jetzt neu, bist sicher?

[Markus (Gast)]

Ja, hier ist der Link

http://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_IR-Protokollen

[Karol B. (johnpatcher)]

Sorry Markus, aber du scheinst hier einiges durcheinander zu bringen. 
Der "Scanner" gibt einfach nur die Hell bzw. Dunkelphasen via UART aus. 
Das ist in erster Linie eine Hilfestellung, um das Protokoll dann in 
IRMP einzupflegen. Mit dem "Kern" von IRMP bzw. IRSND hat das nichts zu 
tun.

Mir persönlich scheinst du dir selbst nicht ganz klar zu sein, was du da 
eigentlich willst. Der Ansatz von IRMP setzt - wie schon gesagt - 
voraus, dass das Protokoll erkannt bzw. unterstützt wird.

[Sebastian .. (zahlenfreak)]

Was ist das denn für eine exotische Fernbedienung/Gerät?
Erstelle doch einfach mal einen Scan deiner Fernbedienung und stelle es 
hier in den Thread. Wie das geht steht im Artikel und an mehreren 
Stellen im Thread.
Frank kann sich dann das Log anschauen. In den meisten Fällen hat er 
solche Protokolle dann auch implementiert.
Ohne solch einen Scan wird IRMP/IRSND deine Fernbedienung nicht 
untersützen.

Sebastian

[Conny G. (conny_g)]

Markus,
Nachtrag noch zur Repeaterschaltung oben: die Schaltung, die ich 
verlinkt habe, hat m.E. Ein paar Problemchen, ich habe sie deshalb 
modifiziert:
- der NE555 Schwingkreis ist dort ein bisschen ungewöhnlich verschaltet 
(gegenüber der NE555 Standardschaltung) und hat bei mir auch nicht 
korrekt auf 38 kHz geschwungen, hab ich als Standardschaltung 
implementiert
- die LED Verstärkerstufe verhielt sich komisch, das Signal nach dem 
Transistor war "verschmiert". Inzwischen ist mir klar, dass das daran 
liegen könnte, dass der Transistor zur sehr gesättigt wird und zu 
langsam abschaltet. Das müsste man nochmal sauber berechnen, aber 
jedenfalls war's mit einem BC337 schon mal besser als mit dem BC139.

[Markus (Gast)]

Das ganze ist wegen einer Dreambox Fernbedienung die ja momentan noch 
nicht unterstützt wird. Der Grund für meine Idee ist der: Ich steuere 
einen DVD-Player und Verstärker die verdeckt stehen mit einer 
Fremdfernbedienung, mithilfe von IRMP und IRSND wandele ich die Signale 
der Fremdfernbedienung wieder um und steure damit den DVD-Player und 
Verstärker. Das alles funktioniert auch wunderbar, nur leider kann ich 
damit meine Dreambox die auch verdeckt steht nicht steuern. Meine Idee 
war deshalb, wenn IRMP das Signal nicht kennt soll es einfach 1:1 
weitergeleitet werden damit ich auch die Dreambox steuern kann. Wenn das 
ohne weiteres nicht geht werde ich einfach wie Konrad vorgeschlagen hat 
einen Repeater in meine Schaltung einbauen, die einfach alle Signale 1:1 
weiterleitet.

Ich hoffe das es jetzt ein wenig verständlicher ist.

[Stefan Z. (stefan_z)]

Markus schrieb:
> Das ganze ist wegen einer Dreambox Fernbedienung die ja momentan noch
> nicht unterstützt wird. Der Grund für meine Idee ist der: Ich steuere
> einen DVD-Player und Verstärker die verdeckt stehen...

Dafür gibts aber ganz einfache und billige Fertiglösungen.
Habe sogar noch eine unbenutzt hier rumliegen. Wurde obsolet als ich 
feststellte wie toll HDMI CEC mit dem Raspberry ist :-)
http://www.amazon.de/Infrarot-Verlängerung-IRV-200-für-HiFi--Heimkino-Geräte/dp/B006806UFA/ref=sr_1_1?s=ce-de&ie=UTF8&qid=1365439805&sr=1-1&keywords=Infrarot-Verlängerung+IRV-200+für+bis+zu+3+HiFi-%2FHeimkino-Geräte

[Moritz Kerner (Gast)]

Hallo Frank,
erstmal herzlichen Dank für diese tolle Programmierarbeit! Und speziell, 
dass du diese Software unentgeltlich weitergibst :-). Spende kommt 
garantiert!
Ich habe mit Hilfe deiner Software einen IR-Wandler (B&O > div. IR) 
mittels ATmega32 programmiert und funktioniert grundsätzlich auch. Nur 
so +/- jedes 20. Mal wird ein empfangener Code nicht umgesetzt? Ich habe 
vieles getestet (Toleranzen, , verschiedene Fernbedienungen, F 15kHz, F 
20kHz = etwas besser, ...) aber keine 100%ige Lösung gefunden :-/.

Deshalb übermittle ich dir hiermit einen Scan meiner B&O Fernbedienung, 
vielleicht hast du ja mal Zeit darüberzuschauen.

Vielen vielen Dank, Moritz

[Frank M. (ukw) (Moderator)]

Hallo Moritz,

Moritz Kerner schrieb:

> Ich habe mit Hilfe deiner Software einen IR-Wandler (B&O > div. IR)
> mittels ATmega32 programmiert und funktioniert grundsätzlich auch.

Das heisst, Du setzt Befehle einer B&O-FB auf andere Protokolle um?

> Nur so +/- jedes 20. Mal wird ein empfangener Code nicht umgesetzt?

Ich habe mir mal Deine Scans angeschaut. Nachdem ich die ganzen 
Zeilenumbrüche wieder entfernt hatte, konnte ich sie auch verwenden ;-)

15kHz ist okay, das reicht. Die Timings sind sehr gut, sie stimmen 
ziemlich genau mit den theoretischen Werten überein. Die Toleranzen 
brauchst Du da auch nicht anzupassen, die gewählten reichen. Die FB ist 
vom Timing her auch sehr genau.

Hier ein Output vom Linux-IRMP:

-------------------------------------------------------------------------------
START PULSES:
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 8
pulse avg:  3.0= 200.0 us, min:  3= 200.0 us, max:  3= 200.0 us, tol:  0.0%
-------------------------------------------------------------------------------
START PAUSES:
 44 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 7
 45 oooooooo 1
pause avg: 44.1=2941.7 us, min: 44=2933.3 us, max: 45=3000.0 us, tol:  2.0%
-------------------------------------------------------------------------------
PULSES:
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 160
  4 ooo 8
pulse avg:  3.0= 203.2 us, min:  3= 200.0 us, max:  4= 266.7 us, tol: 31.3%
-------------------------------------------------------------------------------
PAUSES:
 44 oooooooooooooooooooooo 25
 45 oo 3
pause avg: 44.1=2940.5 us, min: 44=2933.3 us, max: 45=3000.0 us, tol:  2.0%
 91 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 66
 92 ooooooooooooooooooooooooooooooo 35
pause avg: 91.3=6089.8 us, min: 91=6066.7 us, max: 92=6133.3 us, tol:  0.7%
-------------------------------------------------------------------------------

Dass da ab und zu etwas nicht erkannt wird, muss an etwas anderem 
liegen. Ich hatte jedenfalls bei Deinen Scans eine Erkennungsrate von 
100%.

Kannst Du mal Deine irmpconfig.h, irsndconfig.h und Deine ISR zeigen? 
Vielleicht auch noch die main-Funktion...

Gruß,

Frank

[Conny G. (conny_g)]

Hallo Frank,
meinen Post vom 3.4. schon gesehen?
Vg,
Konrad