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 &= ~
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.
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
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
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
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
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?
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
> 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
1
if(irmp_get_data(&irmp_data)){
2
Serial.print(irmp_data.protocol);
3
Serial.print(" A:");
4
Serial.print(irmp_data.address,HEX);
5
Serial.print(" C:");
6
Serial.print(irmp_data.command,HEX);
7
Serial.print(" ");
8
Serial.print(irmp_data.flags,HEX);
9
Serial.println("");
10
11
delay(1500);
12
intresult;
13
result=irsnd_send_data(&irmp_data,TRUE);
14
if(result!=1)Serial.println("ERROR");
15
if(result==1)Serial.println("Sent");
16
}
auch mit folgendem Ansatz hat es nicht funktioniert.
1
irmp_data.protocol=IRMP_NEC_PROTOCOL;// sende im NEC-Protokoll
2
irmp_data.address=0x857A;
3
irmp_data.command=0x1F;
4
irmp_data.flags=0;
5
6
intresult;
7
result=irsnd_send_data(&irmp_data,TRUE);
8
if(result!=1)Serial.println("ERROR");
9
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.
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:
1
#define US (1000000 / F_INTERRUPTS)
2
...
3
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
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.
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?
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!
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
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....
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:
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....
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!!
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.
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
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
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.....
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
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
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
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:
010000010111011 p = 8, a = 0x0008, c = 0x0344, f = 0x00
40
010001101000100
41
010000010111011 p = 8, a = 0x0008, c = 0x0344, f = 0x01
42
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:
protocol = DENON, start bit timings: pulse: 3 - 7, pause: 23 - 30 or 9 - 13
6
pulse_1: 3 - 7
7
pause_1: 23 - 30
8
pulse_0: 3 - 7
9
pause_0: 9 - 13
10
command_offset: 5
11
command_len: 10
12
complete_len: 15
13
stop_bit: 1
14
1.200ms [bit 0: pulse = 6, pause = 10] 0
15
2.267ms [bit 1: pulse = 6, pause = 10] 0
16
4.400ms [bit 2: pulse = 5, pause = 27] 1
17
5.467ms [bit 3: pulse = 5, pause = 11] 0
18
6.533ms [bit 4: pulse = 6, pause = 10] 0
19
8.667ms [bit 5: pulse = 6, pause = 26] 1
20
10.800ms [bit 6: pulse = 5, pause = 27] 1
21
11.867ms [bit 7: pulse = 4, pause = 12] 0
22
12.933ms [bit 8: pulse = 5, pause = 11] 0
23
15.067ms [bit 9: pulse = 4, pause = 28] 1
24
16.067ms [bit 10: pulse = 5, pause = 10] 0
25
18.200ms [bit 11: pulse = 6, pause = 26] 1
26
19.267ms [bit 12: pulse = 6, pause = 10] 0
27
20.333ms [bit 13: pulse = 6, pause = 10] 0
28
21.400ms [bit 14: pulse = 6, pause = 10] 0
29
stop bit detected
30
21.800ms code detected, length = 15
31
21.800ms waiting for inverted command repetition
32
67.800ms [starting pulse]
33
68.867ms [start-bit: pulse = 6, pause = 10]
34
protocol = DENON, start bit timings: pulse: 3 - 7, pause: 23 - 30 or 9 - 13
35
pulse_1: 3 - 7
36
pause_1: 23 - 30
37
pulse_0: 3 - 7
38
pause_0: 9 - 13
39
command_offset: 5
40
command_len: 10
41
complete_len: 15
42
stop_bit: 1
43
68.867ms [bit 0: pulse = 6, pause = 10] 0
44
69.933ms [bit 1: pulse = 6, pause = 10] 0
45
72.067ms [bit 2: pulse = 6, pause = 26] 1
46
73.133ms [bit 3: pulse = 5, pause = 11] 0
47
74.133ms [bit 4: pulse = 4, pause = 11] 0
48
75.200ms [bit 5: pulse = 6, pause = 10] 0
49
76.267ms [bit 6: pulse = 6, pause = 10] 0
50
78.400ms [bit 7: pulse = 5, pause = 27] 1
51
80.533ms [bit 8: pulse = 6, pause = 26] 1
52
81.600ms [bit 9: pulse = 6, pause = 10] 0
53
83.733ms [bit 10: pulse = 5, pause = 27] 1
54
84.800ms [bit 11: pulse = 6, pause = 10] 0
55
86.933ms [bit 12: pulse = 5, pause = 27] 1
56
89.067ms [bit 13: pulse = 5, pause = 27] 1
57
91.200ms [bit 14: pulse = 6, pause = 26] 1
58
stop bit detected
59
91.600ms code detected, length = 15
60
91.600ms p = 8, a = 0x0004, c = 0x0328, f = 0x00
61
135.467ms [starting pulse]
62
136.533ms [start-bit: pulse = 5, pause = 11]
63
protocol = DENON, start bit timings: pulse: 3 - 7, pause: 23 - 30 or 9 - 13
64
pulse_1: 3 - 7
65
pause_1: 23 - 30
66
pulse_0: 3 - 7
67
pause_0: 9 - 13
68
command_offset: 5
69
command_len: 10
70
complete_len: 15
71
stop_bit: 1
72
136.533ms [bit 0: pulse = 5, pause = 11] 0
73
137.600ms [bit 1: pulse = 5, pause = 11] 0
74
139.733ms [bit 2: pulse = 4, pause = 28] 1
75
140.800ms [bit 3: pulse = 5, pause = 11] 0
76
141.867ms [bit 4: pulse = 5, pause = 11] 0
77
144.000ms [bit 5: pulse = 5, pause = 27] 1
78
146.133ms [bit 6: pulse = 5, pause = 27] 1
79
147.200ms [bit 7: pulse = 5, pause = 11] 0
80
148.200ms [bit 8: pulse = 4, pause = 11] 0
81
150.333ms [bit 9: pulse = 5, pause = 27] 1
82
151.400ms [bit 10: pulse = 6, pause = 10] 0
83
153.533ms [bit 11: pulse = 6, pause = 26] 1
84
154.600ms [bit 12: pulse = 7, pause = 9] 0
85
155.667ms [bit 13: pulse = 5, pause = 11] 0
86
156.733ms [bit 14: pulse = 6, pause = 10] 0
87
stop bit detected
88
157.200ms code detected, length = 15
89
157.200ms waiting for inverted command repetition
90
203.133ms [starting pulse]
91
204.200ms [start-bit: pulse = 5, pause = 11]
92
protocol = DENON, start bit timings: pulse: 3 - 7, pause: 23 - 30 or 9 - 13
93
pulse_1: 3 - 7
94
pause_1: 23 - 30
95
pulse_0: 3 - 7
96
pause_0: 9 - 13
97
command_offset: 5
98
command_len: 10
99
complete_len: 15
100
stop_bit: 1
101
204.200ms [bit 0: pulse = 5, pause = 11] 0
102
205.267ms [bit 1: pulse = 5, pause = 11] 0
103
207.400ms [bit 2: pulse = 5, pause = 27] 1
104
208.467ms [bit 3: pulse = 5, pause = 11] 0
105
209.467ms [bit 4: pulse = 4, pause = 11] 0
106
210.533ms [bit 5: pulse = 5, pause = 11] 0
107
211.600ms [bit 6: pulse = 6, pause = 10] 0
108
213.733ms [bit 7: pulse = 5, pause = 27] 1
109
215.867ms [bit 8: pulse = 5, pause = 27] 1
110
216.933ms [bit 9: pulse = 6, pause = 10] 0
111
219.067ms [bit 10: pulse = 6, pause = 26] 1
112
220.133ms [bit 11: pulse = 5, pause = 11] 0
113
222.267ms [bit 12: pulse = 4, pause = 28] 1
114
224.400ms [bit 13: pulse = 6, pause = 26] 1
115
226.533ms [bit 14: pulse = 6, pause = 26] 1
116
stop bit detected
117
226.867ms code detected, length = 15
118
226.867ms p = 8, a = 0x0004, c = 0x0328, f = 0x01
119
270.800ms [starting pulse]
120
271.867ms [start-bit: pulse = 5, pause = 11]
121
protocol = DENON, start bit timings: pulse: 3 - 7, pause: 23 - 30 or 9 - 13
122
pulse_1: 3 - 7
123
pause_1: 23 - 30
124
pulse_0: 3 - 7
125
pause_0: 9 - 13
126
command_offset: 5
127
command_len: 10
128
complete_len: 15
129
stop_bit: 1
130
271.867ms [bit 0: pulse = 5, pause = 11] 0
131
272.933ms [bit 1: pulse = 5, pause = 11] 0
132
275.067ms [bit 2: pulse = 5, pause = 27] 1
133
276.133ms [bit 3: pulse = 5, pause = 11] 0
134
277.133ms [bit 4: pulse = 5, pause = 10] 0
135
279.333ms [bit 5: pulse = 6, pause = 27] 1
136
281.467ms [bit 6: pulse = 5, pause = 27] 1
137
282.533ms [bit 7: pulse = 5, pause = 11] 0
138
283.533ms [bit 8: pulse = 5, pause = 10] 0
139
285.667ms [bit 9: pulse = 6, pause = 26] 1
140
286.733ms [bit 10: pulse = 7, pause = 9] 0
141
288.867ms [bit 11: pulse = 6, pause = 26] 1
142
289.933ms [bit 12: pulse = 6, pause = 10] 0
143
291.000ms [bit 13: pulse = 6, pause = 10] 0
144
292.067ms [bit 14: pulse = 5, pause = 11] 0
145
stop bit detected
146
292.467ms code detected, length = 15
147
292.467ms waiting for inverted command repetition
148
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:
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. 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
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.
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
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
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
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?
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.
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?
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:
1
main(void)
2
{
3
IRMP_DATAirmp_data;
4
5
irmp_init();// initialize irmp
6
timer1_init();// initialize timer 1
7
sei();// enable interrupts
8
9
10
PORTD=0xff;
11
DDRD=0xff;
12
13
for(;;)
14
{
15
PORTD=~(1<<PD1);
16
if(irmp_get_data(&irmp_data))
17
{
18
switch((unsignedchar)irmp_data.command)
19
{
20
case3:PORTD=~(1<<PD3);;break;
21
}
22
PORTD=~(0<<PD1);
23
PORTD=~(1<<PD2);
24
// ir signal decoded, do something here...
25
// irmp_data.protocol is the protocol, see irmp.h
26
// irmp_data.address is the address/manufacturer code of ir sender
27
// irmp_data.command is the command code
28
// irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
29
}
30
}
31
}
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
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?
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
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:
1
main(void)
2
{
3
IRMP_DATAirmp_data;
4
5
irmp_init();// initialize irmp
6
timer1_init();// initialize timer 1
7
sei();// enable interrupts
8
9
PORTD=0xff;
10
DDRD=0xff;
11
12
for(;;)
13
{
14
if(irmp_get_data(&irmp_data))
15
{
16
PORTD|=(1<<PD3);
17
}
18
}
19
}
Falls die LED woanders angeschlossen ist, ändere PD3 in den
entsprechenden Wert.
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 :(
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.
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.
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 ;-)
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.
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...
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.
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
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 :?
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
1
if(irmp_data.protocol==IRMP_NEC_PROTOCOL&&//
2
>NEC-Protokoll
3
>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.
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.
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:
1
charbuf[20];
2
...
3
uart_init();
4
....
5
6
if(irmp_get_data(&irmp_data))
7
{
8
itoa(irmp_data.protocol,buf,10);// protocol in decimal
9
uart_puts(buf);
10
uart_putc(' ');
11
itoa(irmp_data.address,buf,16);// address in hex
12
uart_puts(buf);
13
uart_putc(' ');
14
itoa(irmp_data.command,buf,16);// command in hex
15
uart_puts(buf);
16
uart_putc('\r');
17
uart_putc('\n');
18
}
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?
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.
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.
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
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
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 :-)
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
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
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?
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.
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
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:
1
externvoidirmp_init(void);
2
externuint8_tirmp_get_data(IRMP_DATA*);
3
externuint8_tirmp_is_busy(void);
4
externuint8_tirmp_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
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.
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:
1
#include<16F1823.h>
2
#include<stdio.h>
3
4
#fuses NOMCLR,NOPROTECT,NOWDT
5
#use delay(clock = 32000000) // Quarz 32 MHz
6
7
8
#include"irmp.h"
9
10
#ifndef F_CPU
11
#error F_CPU unkown
12
#endif
13
14
#INT_TIMER0
15
voidtestfunc_for_timer(){
16
17
irmp_ISR();
18
//delay_ms(2000);
19
output_high(PIN_C0);// LED ON
20
//delay_ms(1000);
21
//output_low(PIN_C0); //LED OFF
22
23
}
24
25
voidmain(){
26
27
IRMP_DATAirmp_data;
28
irmp_init();
29
30
setup_oscillator(OSC_16MHZ);
31
32
// set port c as an output
33
set_tris_c(0b0000000);
34
35
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1|RTCC_8_BIT);//(16Mhz/4)/RTCC_DIV_1=15625 interrupts per second
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 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
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
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)
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:
ISR(COMPA_VECT)// Timer1 output compare A interrupt service routine, called every 1/15000 sec
12
{
13
(void)irsnd_ISR();// call irsnd ISR
14
// call other timer interrupt routines here...
15
}
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?
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
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
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?
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
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
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?
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
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
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....
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!!!
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.
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.
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"
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.
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 ?
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
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
#define IRMP_PIN PORTBbits.RB4 // use RB4 as IR input on PIC
10
#define input(x) (x)
11
#elif defined (PIC_CCS_COMPILER) // PIC CCS Compiler:
12
#define IRMP_PIN PIN_B4 // use PB4 as IR input on PIC
13
#else // AVR:
14
#define IRMP_PORT PORTD
15
#define IRMP_DDR DDRD
16
#define IRMP_PIN PIND
17
#define IRMP_BIT 6 // use PB6 as IR input on AVR
18
#define input(x) ((x) & (1 << IRMP_BIT))
19
#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:
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
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?
1
voidtimer0_init(void)// timer use by IR Interrupts 512 ticks bei 8 MHz = 15625/s
2
{TCCR0B=1<<CS02;// divide by 256
3
TCNT0=-2;
4
TIMSK0|=(1<<TOIE0);//enable timer interrupt
5
}// 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
> 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.
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
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.
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
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?
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
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
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
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:
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.
1
10000 ergibt Adresse 0x0010
2
0101000010 ergibt Kommando 0x0142
Jetzt Deine Taste mit der Bezeichnung "???" in Deinem Scan (1. Zeile):
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):
Der Adressteil für die Tasten 9 & 0 sind annähernd identisch, der Teil
für die Taste '???' aber passt da gar nicht rein:
1
Taste 9: Pausenfolge: lang kurz kurz kurz kurz -> 1 0 0 0 0 -> Adr 0x10
2
Taste 0: Pausenfolge: lang kurz kurz kurz kurz -> 1 0 0 0 0 -> Adr 0x10
3
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
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:
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:
1
#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:
1
for(;;)
2
{
3
if(irmp_get_data(&irmp_data))
4
{
5
MAP_UARTCharPut(UART0_BASE,'Y');
6
LCDWritePos('Y',1,2);
7
}
8
}
> 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!
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).
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
:)!
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
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?
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.
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
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"
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...
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
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
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...
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 ?
@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?
@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!!
1
RECS80
2
error3: timing not correct: data bit 0, pulse: 3, pause: 23
3
error 3: timing not correct: data bit 0, pulse: 4, pause: 17
4
RECS80
5
RECS80
6
error 3: timing not correct: data bit 0, pulse: 4, pause: 20
7
error 3: timing not correct: data bit 0, pulse: 3, pause: 1
8
RECS80
9
error 3: timing not correct: data bit 0, pulse: 4, pause:
10
RECS80
11
error 3: timing not correct: data bit 0, pulse: 22, pause: 82
12
RECS80
13
error 3: timing not correct: data bit 0, pulse: 3, pause: 1
14
RECS80
15
error 3: timing not correct: data bit 0, pulse: 3, pause:
16
RECS80
17
<1>error 3: timing not correct: data bit 1, pulse: 5, pause: 99
18
RECS80
19
<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...?
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.
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.
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.
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
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
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.
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
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:
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:
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.
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
1
# 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
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 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).
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 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 ?
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
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
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
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
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
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.
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?
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
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
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.
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
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
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.
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
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....
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
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.
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
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.
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
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.
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
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
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
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
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
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
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.
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:
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
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)
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
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 ?
ü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 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.
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 ;-)
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 ?
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.
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)
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: 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
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.
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
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.
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.
1
voidtimer0_init(void)
2
{
3
TCCR0=(1<<WGM01)|(1<<CS02)|(1<<CS00);//CTC Modus
4
// TCCR0 |=(1<<CS02); //Presclaer = 256
5
OCR0=255;//Compare Wert
6
TIMSK=(1<<OCIE0);//Timer starten
7
}
Wenn jedenfalls der zweite Timer läuft, klappt der Empfang nicht mehr.
Oder liegt mein Fehler woanders?
Gruß
Joachim
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:
1
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.
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?
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
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
... 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.
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
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.
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
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.
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.
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
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:
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten