uiuiui jetzt fragst mich was :)
ich hab mir nur per debugfunktion die werte ausgeben lassen und alle
tasten durchgedrückt um zu kucken ob alle erkannt werden, protokoll war
2 aber die adresse weiss ich nichtmehr.
soll ich nochmal kucken?
kleines Problem (oder eher großes)
dein Code ist doch ähnlich meinem gefundenen für IRSND start stop
meiner funktioniert, getestet mit Oszi 500µs 36kHz on off
meiner:
1
voidtimer0_init(void)
2
{
3
OCR0A=(F_CPU/(2*IR_FREQUENZ))-1;// compare value:
4
#if !FB_LCD_STECKBRETT
5
IR_SND_DDR|=(1<<IR_SND);// set DDR to output
6
IR_SND_PORT&=~(1<<IR_SND);// set pin to low
7
#endif
8
}
9
10
voidtimer0_start(void)
11
{
12
TCCR0A|=(1<<WGM01)|(1<<WGM00)|(1<<COM0A0);// switch CTC Mode on, set prescaler to 1
13
TCCR0B|=(1<<WGM02)|(1<<CS00);
14
TIMSK0|=(1<<OCIE0A);// OCIE0A: Interrupt by timer compare
15
}
16
17
voidtimer0_stop(void)
18
{
19
TIMSK0&=~(1<<OCIE0A);// OCIE0A: Interrupt by timer compare
20
TCCR0B&=~(1<<WGM02)|(1<<CS00);
21
TCCR0A&=~(1<<WGM01)|(1<<WGM00)|(1<<COM0A0);
deiner:
1
staticvoid
2
irsnd_on(void)
3
{
4
if(!irsnd_is_on)
5
{
6
#ifndef DEBUG
7
#if defined (__AVR_ATmega32__)
8
TCCR2|=(1<<COM20)|(1<<WGM21);// = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
9
#else
10
TCCR2A|=(1<<COM2A0)|(1<<WGM21);// = 0x42: toggle OC2A on compare match, clear Timer 2 at compare match OCR2A
TCCR2&=~(1<<COM20);// normal port operation, OC2A disconnected.
30
#else
31
TCCR2A&=~(1<<COM2A0);// normal port operation, OC2A disconnected.
32
#endif // __AVR...
33
IRSND_PORT&=~(1<<IRSND_BIT);// set IRSND_BIT to low
34
#endif // DEBUG
35
irsnd_is_on=FALSE;
36
}
37
}
ergo dachte ich ich ersetzte dein ON/OFF durch meines
aber klappt nicht, irgendwo ist noch der Wurm drin,
nach play +5 sekunden hängt die routine
wenn einer mal schauen mag ?
danke
gruss
jar
mit static volatile usw. muss ich noch üben
am irsnd_busy hats gelegen
Routine läuft erst mal, nur das Gerät fühlt sich noch nicht angesprochen
muss erst mal ein 2ten IRMP bauen zum testen
die Pulse sind nun zu kurz um sie mit der digital cam hilfe zu sehen, im
gegensatz zu vorher 500µs on/off
Das ist ja ein super Projekt, Gratulation an alle. Das ganze läuft ja
auch mit B&O Codes. Nun hab ich einen IR Sender-Empfänger aus einem
alten B&O Fernseher geschraubt.
Die Frage nun, kann man Ihn anstelle eines TSOP-7000 verwenden. Kennt
jemand die Anschlüsse. Beim Empfänger ist auch ein Lichtsensor.
Kann über die beiden IR-Empfänger (TFK B PW82) keine Datenblätter
finden.
Danke für eine kleine Unterstützung.
Hallo Frank,
hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment
ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in
ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.
Hallo Frank,
ich teste IRMP gerade auf einem ATmega324P.
Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier
die Pins nicht stimmen:
1
#if defined (__AVR_ATmega32__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega324P__)
2
// usw.
Vielen Dank für dieses schöne Projekt!!!
Grüße,
Peter
Hallo Frank!
Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete
Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den
Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:
irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00
irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00
Zum Vergleich ein Denon-Code:
irmp send 8 1 2 0
OK
IRMP: proto DENON, address 0001, command 0002, flags 00
IRMP 08:0001:0002:00
4 LeftMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst Press/Release)
5
4 UpMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst Low-Nibble von Command
6
4 DownMove-Bits (wenn IsMouse in Mouse-Bits gesetzt, sonst High-Nibble von Command
7
8 Invertierte Command-Bits
Mit X=RightMove-LeftMove und Y=UpMove-DownMove
bekommt man dann Werte, mit denen man auch etwas anfangen kann.
Mehr dazu in den nächsten Tagen, bin noch am Testen.
Gruß
Uwe
Hi, bin mal ganz neu hier. ;) Und habe leider ein Problem wo ich alleine
absolut nicht mehr weiterkomme. Suche schon seit tagen.^^ Programmieren
kann ich leider nicht wirklich, ich versuche mich mit gesunden
Menschenverstand durch die Codes durch zu arbeiten. Beruf:
Nachrichtentechniker, also eher der Funksektor.
Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade
irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.
Nun hab ich gelesen das dieser Timer0 beim atmega644 TIMER0_COMPA_vect
heißt.
Ich glaube zumindest das ich am Richtigen weg bin aber, ehrlich gesagt
keine Ahnung, Habe nun in der irmp.c TIMER0_COMP_vect in
TIMER0_COMPA_vect geändert aber Ergebnis bleibt das gleiche.. es folgt
ein Fehler mit __vector_16.
Nun hab ich keine Ahnung mehr wie ich weitermachen soll. Deswegen hab
ich mir eure Codes hier angesehen aber irgendwie werde ich da auch nicht
Schlau daraus.
Gehalten hab ich mich an dieses hier:
http://www.ethersex.de/index.php/IRMP
Meine irmp.c --> http://paste2.org/p/1050578
Vielleicht könnt ihr mir ja weiterhelfen hab schon soooo viel tolle
Sachen hier erlesen ;)
Grüße aus Wien
Hallo,
djmaster schrieb:> Ich habe ein etherrape mit ethersex im Einsatz und ich versuche gerade> irmp auf meinem atmega644 zu compilen. Leider kein gutes Ergebnis.
die Portierung nach ethersex ist von mir. Hilfe bekommst Du im IRC
(Details siehe ethersex WIKI).
Hi eku,
eku schrieb:> hast Du Pläne, IRMP_USE_AS_LIB bis zu ende zu implementieren. Im Moment> ist das nur ein Feigenblatt :-) Ich habe zwar eine Einbindung in> ethersex laufen, einen Bibliothek würde aber das ganze vereinfachen.
Dieses define ist eher gedacht, irmp als sog. "Include-Lib" zu nutzen.
Das heisst, man hat irgendwo in seinem Projekt sämtliche Defines, die
normalerweise in irmpconfig.h stehen, in seinem project-irmp.c und macht
anschließend einfach ein
1
#include"../irmp/irmp.c"
Ich benutze diese Methode selbst öfters, um bestimmte Sources, welche
projektunabhängig sind, in mein konkretes Projekt einzubinden. Das hat
zwar nichts mit "echten" Libs im C-Sinne zu tun, hat aber den Vorteil,
dass nur das vom Code übernommmen/compiliert wird, was man gerade
braucht - bei IRMP zum Beispiel nur den NEC-Decoder. Mein Projekt bleibt
dann unabhängig von den Standard-Werten in irmpconfig.h. Das ist
sinnvoll bei µCs, wo es auf jedes gesparte Byte ankommt. Hier wird also
kein Object-File dazugelinkt, sondern der Source selbst mit ins Projekt
eingebunden. Meinetwegen kannst Du das Includen von C-Files (xxx.c) als
No-Go ansehen, für mich ist das aber eine durchaus anwendbare Methode.
Eine "klassische" Lib aus IRMP zu machen, die man dazubindet, halte ich
für einen µC unpraktikabel, da ja dann schon bei Erstellung der Lib klar
sein muss, welche IR-Decoder ich brauche. Es ist aber bei der
universellen Konfigurierbarkeit von IRMP gar nicht möglich, dies vorab
zu entscheiden.
Um auf Deine Frage zurückzukommen: das IRMP_USE_AS_LIB ist für mich kein
Feigenblatt, sondern für mich soweit bereits anwendbar ;-)
Gruß,
Frank
Hallo Peter,
Peter Diener schrieb:> ich teste IRMP gerade auf einem ATmega324P.> Dieser sollte in der irsndconfig noch eingetragen werden, da auch hier> die Pins nicht stimmen:>
eku schrieb:> Mit dem Nubert-Protokoll gibt es Probleme. Die von IRSND gesendete> Sequenz wird von IRMP falsch dekodiert. Welche der Komponenten nun den> Fehler macht, kann ich allerdings nicht sagen. Hier ein Beispiel:>> irmp send 13 9 9 0> OK> IRMP: proto NUBERT, address 0000, command 0009, flags 00> IRMP 13:0000:0009:00
Habe ich gerade versucht, nachzuvollziehen (unter Linux):
# ./irsnd 13 9 9 0 | ./irmp
0000001001 p = 13, a = 0x0000, c = 0x0009, f = 0x00
Stimmt, die dekodierte Adresse ist immer 0, aber das ist kein Wunder:
Nach
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail
gibt es beim Nubert-Protokoll keine Adress-Bits, sondern nur
Kommando-Bits. Daher ist das Verhalten von IRSND korrekt, es ignoriert
nämlich Deine angegebene Adresse und IRMP zeigt immer 0 an.
Beachte auch meine Bemerkungen oberhalb der Tabelle im Artikel, Zitat:
| Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der
| Adressen bzw. Kommandos verschieden, siehe obige Tabelle [2].
| Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite
| Adressen oder Kommandos transparent übertragen.
Gruß,
Frank
Uwe R. schrieb:> Pollin-IR-Tastatur FDC-3402: Mausknubbel enträtselt
Sehr interessant!
> Mehr dazu in den nächsten Tagen, bin noch am Testen.
Ich hoffe, da kommen noch weitere Infos zu.
Gruß,
Frank
Hat jemand die URC Zapper (gibts bei Reichelt günstig) mal ausprobiert?
http://www.reichelt.de/?ARTICLE=77492
Dort steht:
----
Geeignet für die Bedienung von infrarotgesteuerten Fernsehgeräten aller
Marken.
----
Also nehme ich mal an, dass da auf jeden Fall mindestens irgendein
Protokoll unterstützt wird, richtig?
Hallo Frank!
Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB
Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen
Widerspruch doch bitte.
Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von
IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im
Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch
(Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim
Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die
durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale
Empfänger nicht.
eku schrieb:> Hallo Frank!>> Nochmal zum Nubert Protokoll. IRMP dekodiert von der Original-FB> Adressbits, die es laut Deines Artikels nich gibt. Erklär diesen> Widerspruch doch bitte.
Du schriebst weiter oben:
irmp send 13 9 9 0
OK
IRMP: proto NUBERT, address 0000, command 0009, flags 00
IRMP 13:0000:0009:00
irmp send 13 1 1 0
OK
IRMP: proto NUBERT, address 0000, command 0001, flags 00
IRMP 13:0000:0001:00
Hier erkennt IRMP als Adresse den Wert 0. Wo ist da ein Widerspruch?
Bitte gib genauere Infos an, mit "Adressbits, die es laut Deines
Artikels" kann ich nichts anfangen.
> Mit dem Siemens-Protokoll habe ich das Problem, dass nicht alle von> IRSND gesendeten Kommandos von der M740AV akzeptiert werden (im> Gegensatz zur Original-FB). Die Dekodierung durch IRMP erscheint logisch> (Anordnung der COdes auf der FB). Scheinbar ist das Timing kritisch beim> Senden oder IRSND hat danoch einen Fehler. Anmerkung: IRMP dekodiert die> durch IRSND gesendeten Kommandos fehlerfrei, nur eben der originale> Empfänger nicht.
Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing
wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann
IRMP da durchaus "besser" sein als die Hersteller selbst.
Gruß,
Frank
Hallo Frank!
> Benutzt Du einen Quartz am µC zum Senden? IRMP ist beim Timing> wesentlich toleranter als die Hersteller-Empfänger es sind. Daher kann> IRMP da durchaus "besser" sein als die Hersteller selbst.
Ich verwende einen m168 mit 16MHz quarzgetaktet. Laut Protkoldetails im
IRMP-Artikel setzen sich die Daten aus
13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit
zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die
Parität handelt? Das würde zumindest erklären, warum nur die von IRSND
gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die
Parität stimmt. Wie müsste man IRSND ändern, um diese These zu
verifizieren?
Gruß, eku
Haben wir eigentlich eine Vorstellung davon, welche Adressen- und
Datenwerte eigentlich generell so verwendet werden?
Hintergrund ist, dass ich gerade an einem USB-Empfänger bastele, der ein
konfigurierbares HID-Keyboard darstellen soll. Wenn ich beliebige
Fernbedienungen zulassen möchte, habe ich eine Lookup-Tabelle für die
Keycodes, die 5-Byte-Keys (Protokoll + 16-bit Adresse + 16-bit Kommando)
auf 1-2 Bytes Keycode abbildet.
Bei einem 512-Byte-EEprom kriege ich also etwa 70-80 Zuordnungen unter,
was vielleicht reicht, sich aber trotzdem wie Verschwendung anfühlt.
Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando
braucht man eh nie" oder "das Protokoll kann man in die Adresse mit
reinverodern" und trotzdem noch eine gute Erkennung von beliebigen
Fernbedienungen zu haben.
Leider habe ich keine klare Vorstellung davon, was die häufigste
Verwendung von Address- und Kommandonummern ist, und welche
"Zusammenfassung" erfolgversprechend wäre. Habt ihr da Ideen?
Viele Grüße,
Simon
eku schrieb:> 13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 unbekanntes Bit>> zusammen. Könnte es sein, dass es sich bei dem "unbekannten Bit" um die> Parität handelt?
Das kann durchaus sein. Ich habe mir gerade nochmal die Scans von der
M740AV angeschaut. Dabei haben ca. 50% der Frames als letztes Bit den
Wert 0, die anderen haben als letztes Bit den Wert 1.
> Das würde zumindest erklären, warum nur die von IRSND> gesendeten Zeichen vom M740AV erkannt werden, bei denen zufällig die> Parität stimmt.
Ja, sehr gut erkannt!
> Wie müsste man IRSND ändern, um diese These zu verifizieren?
Füge die mit +++ gekennzeichneten Zeilen in irsnd.c ein:
Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade
ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das
letzte Bit betrachte. Aber es könnte auch sein, dass beim
Siemens-Protokoll im letzten Bit tatsächlich die Parität von Adresse +
Kommando herangezogen wird. Um das zu beurteilen, bräuchte ich den Scan
von einer anderen Siemens-FB, welche eine andere Adresse verwendet.
Kannst Du mal testen, ob es nun stimmt?
[/c]
Simon Budig schrieb:> Es wäre also nett, z.B. sagen zu können "das MSB von dem Kommando> braucht man eh nie" oder "das Protokoll kann man in die Adresse mit> reinverodern" und trotzdem noch eine gute Erkennung von beliebigen> Fernbedienungen zu haben.
Das kann man leider überhaupt nicht sagen, wie man die Daten da noch
weiter "komprimieren" kann. Du kannst Dir ja mal selbst ein Bild machen
mit
./irmp <IR-Data/xxxx.txt
bzw.
irmp.exe <IR-Data/xxxx.txt
was da alles so vorkommen kann. Beim Kaseikyo-Protokoll fehlen mir sogar
noch 2 Bits, die ich in irmp_data.command gar nicht unterbringen kann.
Glücklicherweise haben diese bei den bisherigen FB-Scans, die mir
zugesandt wurden, keine relevanten Daten (immer "00").
Frank M. schrieb:> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das> letzte Bit betrachte.
Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die
Invertierung des davor zuletzt gesandten Bits, welches das
niederwertigste Bit des Kommandocodes ist.
Daher ist die folgende Schreibweise als Codekorrektur von IRSND
plausibler (führt aber zu demselben Ergebnis):
Im IRMP-Artikel habe ich nun folgendes zum SIEMENS-Prtokoll angemerkt:
13 Adress-Bits + 1 Repeat-Bit + 7 Daten-Bits + 1 invertiertes Bit
(letztes Bit davor nochmal invertiert)
Gruß,
Frank
Hallo Frank,
Frank M. schrieb:> Frank M. schrieb:>> Hier wird nun zusätzlich geprüft, ob das Kommando gerade oder ungerade>> ist. Zumindest für die M740AV scheint das zu stimmen, wenn ich das>> letzte Bit betrachte.>> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die> Invertierung des davor zuletzt gesandten Bits, welches das> niederwertigste Bit des Kommandocodes ist.
das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen
zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch
testen, ob die Parität auch über die Adresse gebildet wird.
eku schrieb:>> Das letzte Bit ist eigentlich kein Paritätsbit, sondern einfach die>> Invertierung des davor zuletzt gesandten Bits, welches das>> niederwertigste Bit des Kommandocodes ist.>> das war es nicht. Versuche es nun mit der Parität, d.h. die Einsen> zählen ( (parity_even_bit aus der avrlibc). Allerdings muss ich noch> testen, ob die Parität auch über die Adresse gebildet wird.
Komisch, schau Dir mal diesen Output an:
00011011000100001000110 p = 17, a = 0x06c4, c = 0x0023, f = 0x00
Hier ist das letzte Bit immer das invertierte des vorletzten. Oder ist
da noch ein Bug in der Manchester-Codierung des IRMP? Glaube ich
eigentlich nicht, denn RS5 und RC6 funktionieren ja....
Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert
werden?
Gruß,
Frank
Simon K. schrieb:> Hast du mal ausprobiert, was weniger Code verbraucht? Ich vermute fast,> dass die if-Anweisung effizienter ist.
Beide Varianten führen beim ATmega88 zu dem Codezuwachs von je 16 Bytes
- es kommt also exakt auf dasselbe raus.
Hallo Frank,
> Kannst Du mal sagen, welche Kommando-Codes gerade nicht akzeptiert werden?
war mein Fehler. In der Scandatei Siemens-Gigaset-M740AV-15kHz.txt sind
einige Tasten falsch beschriftet. Werde bei Gelegenheit mal eine neue
aufzeichnen. In http://www.m740.de/wiki/Lircd wird das besagte Bit dem
Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN
mit Deinem Fix.
Bei Dekodieren mit IRMP gibt es Interferenzen mit anderen Dekodern. Ich
habe nur noch nicht rausbekommen mit welchem. Siemens alleine dekodiert
meist zuverlässig. Alle Dekoder aktiviert und die Dekodierung gerät zum
Glückspiel.
Siehst Du eine Möglichkeit, die Anzahl der zu testenden Kombinationen
von vorn herein einzuschränken?
Gruß, eku
Hallo Frank,
> In http://www.m740.de/wiki/Lircd wird das besagte Bit dem> Kommando zugeordnet. Geschmackssache. Bitte aktualisiere IRSND im SVN> mit Deinem Fix.
mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten
zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir
aufgestellten Regel, prüft. Ich persönlich plädiere für 1.
Gruß, Erik
eku schrieb:> mittlerweile bin ich der Überzeugung, dass entweder dieses Bit den Daten> zugeschlagen wird oder aber IRMP dessen Gültigkeit, nach der von Dir> aufgestellten Regel, prüft. Ich persönlich plädiere für 1.
Mir gefällt es eigentlich nicht, wenn es dem Kommando zugeschlagen wird.
Gründe:
1. Das Prüfbit gehört offensichtlich nicht zum Kommando
2. Es stört mein Symmetrie-Empfinden (die Kommando-Codes sind nicht
mehr fortlaufend)
3. Die LIRCS-Leute haben sich das Leben da sehr einfach gemacht ;-)
Dass IRMP konsequenterweise das letzte Bit prüfen soll, halte ich für
sinnvoller. Denn genau dafür ist das letzte Bit offenbar da: zur
Prüfung. Genau das macht IRMP auch teilweise bei anderen Protokollen,
z.B. NEC, wo sämtliche invertierten Kommandobits gegengecheckt werden.
Wenn ich das Prüfbit dem Kommando zuschlage, dann hat das folgende
Nachteile:
1. Prüfung auf Gültigkeit nicht mehr sinnvoll
2. Es können irreguläre Codes sowohl empfangen als auch gesendet werden
Daher plädiere ich für 2 ;-)
Ich habe bereits den Check des Prüfbits auf meiner TODO-Liste.
Gruß,
Frank
Hallo Frank,
danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das
Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig.
Könnten die 200usec Bitlänge falsch sein?
Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die
Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert. Da
ist die Logik "Grundig annehmen und später auf Nokia umschalten" falsch.
Würdest Du das bitte korrigieren.
Gruß, eku
eku schrieb:> danke für das Update im SVN. Funktioniert soweit, aqllerdings ist das> Timing bei IRSND kritisch denn die M740AV reagiert nicht zuverlässig.> Könnten die 200usec Bitlänge falsch sein?
Schau Dir bitte die Text-Datei im Anhang an (im Notepad Zeilenumbruch
aktivieren).
Die erste Zeile enthält Deinen Scan von der Taste "Rechts", die Zeile
darunter enthält den von IRSND generierten Frame.
Die Zeilen sind fast identisch. An IRSND kann es also nicht liegen, es
reproduziert das Telegramm perfekt - sogar besser als das Original ;-)
Vielleicht ist Dein damaliger Scan nicht genau genug? Oder stimmt
vielleicht die Modulationsfrequenz nicht?
Du kannst ja mal die Parameter variieren, vielleicht kannst du das
Resultat somit optimieren?
> Und noch ein Problem: Ist nur Nokia und nicht Grundig aktiv (die> Protokolle teilen sich die Timings) wird trotzdem Grundig detektiert.
Habe ich gerade versucht zu reproduzieren: bei mir wird Nokia (protocol
= 16) erkannt. Nokia und Grundig werden auch im Source absolut
gleichberechtigt behandelt. Ich sehe da keine Stelle im Code, wo Dein
beschriebenes Verhalten greifen sollte.
> Da ist die Logik "Grundig annehmen und später auf Nokia umschalten"> falsch.
Kann ich leider nicht reproduzieren.
Gruß,
Frank
Guten Tag
finde dein Projeckt so weit sehr gut.
Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.
Da ich zum größten teil meiner Fernbedinungen RC6 sind
mfg
Müller
Müller schrieb:> Habe da mal ne Frage an euch. Wann wird RC6 in IRSEND eingebaut.
Einen Prototypen für RC6 habe ich laufen, bei RC6A (FBs von Kathrein &
Co) habe ich noch ein Problem, da weiss ich leider noch nicht, ob ich
den Fehler im IRSND oder vielleicht sogar im IRMP habe, da ich den IRSND
immer mit dem IRMP selbst testen muss.
Ich versuche mal, das Problem in den Griff zu bekommen, dann würde ich
hier im Laufe der Woche eine Testversion reinstellen, damit Du das
testen kannst ;-)
Gruß,
Frank
Anbei eine Testversion von IRSND, welche auch das RC6- und
RC6A-Protokoll (Protokollnummern 9 u. 21) unterstützt. Im Zip-Archiv
sind nur die gegenüber der Download-Version geänderten Dateien.
Hier ist auch noch eine Korrektur für IRMP drin, nämlich für das
RC6A-Protokoll. Hier hatte bisher IRMP immer automatisch das
höchstwertige Adressbit gesetzt, wenn es sich um RC6A handelte. Das ist
nun nicht mehr der Fall. Bei der Kathrein-FB wurde bisher als Adresse
0x8046 ausgegeben, nun ist es 0x0046.
Wäre Klasse, wenn jemand IRSND bzgl. RC6 und RC6 testen könnte. Dieses
Manchester-Protokoll mit wechselnden Periodenzeiten (im T-Bit) raubt mir
mal wieder den letzten Nerv...
Gruß,
Frank
Hallo Frank
Habe deine neune Datein bei mir ins Projeckt übernommen
nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was
am eingang geändert ?
Hier ist mein codes
im IRBORD ist das halt mit den normalen programm
im IRBORD2 ist das mit den neune Programmcode von dir
kannst du mal nachschauen ob ich was falsch gemacht habe
Hallo Frank,
habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um
Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND
gesendeten Sequenzen.
Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei
einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).
Anbei ein Scan der wichtigsten Tasten bei 15kHz.
Gruß, eku
eku schrieb:> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND> gesendeten Sequenzen.
Ja, das sieht sehr nach DENON aus, auch die invertierten
Frame-Wiederholungen sind drin. Allerdings sind viele Scans
offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen"
innerhalb der Frames.
Das kann zweierlei Gründe haben:
1. FB war zu weit weg vom IR-Empfänger
2. Modulationsfrequenz der FB passt schlecht zum TSOP.
Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder
gar TSOP1738...
> Was mich an Denon zweifeln lässt, ist die Tatsache, dass IRMP bei> einigen Tasten einen völlig andere Geräteadresse dekodiert (z.B. MENU).
Das findet man öfter bei einigen FBs, da werden dann geräteübergreifende
Adressen benutzt. Das können zum Beispiel Fernseher sein, die Funktionen
einzelner Produkte desselben Herstellers in einem Gerät vereinen, z.B.
Festplatten-Recorder im TV, irgendwelche Spezial-Tuner, Timer oder
sonstwas...
> Anbei ein Scan der wichtigsten Tasten bei 15kHz.
Das ist eindeutig Denon-Code. Allerdings ist die Aufzeichnungsqualität
sehr schlecht.
Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht
benutzt der Sharp zwar das Denon-Protokoll, aber eine andere
Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher
anzuschauen?
Gruß,
Frank
Müller schrieb:> Habe deine neune Datein bei mir ins Projeckt übernommen> nun habe ich ein Problem mein IR-Empfanger geht nicht mehr hast du was> am eingang geändert ?
Nein, aber Du scheinst den neuen Code nicht an Deine Hardware angepasst
zu haben:
irmpconfig.h:
1
<#defineIRMP_PORTPORTC
2
<#defineIRMP_DDRDDRC
3
<#defineIRMP_PINPINC
4
<#defineIRMP_BIT0// use PB6 as IR input on AVR
5
---
6
>#defineIRMP_PORTPORTB
7
>#defineIRMP_DDRDDRB
8
>#defineIRMP_PINPINB
9
>#defineIRMP_BIT6// use PB6 as IR input on AVR
irsndconfig.h
1
<#defineIRSND_PORTPORTB// port D
2
<#defineIRSND_DDRDDRB// ddr D
3
<#defineIRSND_BIT3// OC2A
4
---
5
>#defineIRSND_PORTPORTD// port D
6
>#defineIRSND_DDRDDRD// ddr D
7
>#defineIRSND_BIT7// OC2A
Damals hattest Du es wohl angepasst (siehe obige Unterschiede), dieses
Mal hast Du das offenbar versäumt.
Gruß,
Frank
Frank M. schrieb:> eku schrieb:>> habe hier Probleme mit einem Sharp TV. IRMP meint, dass es sich um>> Denon-Protkoll handelt, der TV reagiert aber nicht auf die von IRSND>> gesendeten Sequenzen.>> Ja, das sieht sehr nach DENON aus, auch die invertierten> Frame-Wiederholungen sind drin. Allerdings sind viele Scans> offensichtlich kaputt, da kommen dann sehr oft lange "Dunkelphasen"> innerhalb der Frames.>> Das kann zweierlei Gründe haben:>> 1. FB war zu weit weg vom IR-Empfänger
War sie nicht.
> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.
Schon möglich.
> Denon benutzt da ja 32kHz, das ist schon eine Ecke weg vom TSOP1736 oder> gar TSOP1738...
Mit der selben Hardware kann ich eine originale Denon-FB problemlos
einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.
> Reagiert das TV auf keines der ausgesandten Kommandos? Vielleicht> benutzt der Sharp zwar das Denon-Protokoll, aber eine andere> Modulationsfrequenz? Hast Du ein Oszilloskop, um Dir das näher> anzuschauen?
Auf keines der ausgesandten Kommandos reagiert der TV. Zugriff auf einen
Oszi habe ich nicht.
eku schrieb:>> 2. Modulationsfrequenz der FB passt schlecht zum TSOP.> Schon möglich.
Welchen IR-Empfänger benutzt Du denn?
Wenn man sich die Scans mit einem Text-Editor anschaut (einer, der auch
mit langen Zeilen bestens zurechtkommt, also nicht Notepad o.ä.), sieht
man sehr schön, dass es immer wieder "Aussetzer" gibt, d.h. dass
IR-Impulse dort, wo sie eigentlich sein sollten, komplett fehlen. Das
Timing von der FB ist ungeheuer exakt, selbst nach über 2300 Scanpunkten
passen die empfangenen Impulse noch ziemlich genau übereinander.
Eigentlich werden nur die ersten beiden Tasten (power + radio) Deines
Scans von IRMP "verstanden", alles andere wird als fehlerhaft verworfen
- was man auch nachvollziehen kann, wenn man mit dem Editor reinschaut.
Hast Du denn beim IRMP auch derart schlechte Ergebnisse bei der
Sharp-FB? Oder war das einfach nur ein "Montags-Scan"? Kannst Du den
Scan wiederholen, damit man eine Aussage über die Qualität der
Reproduzierung machen kann?
> Mit der selben Hardware kann ich eine originale Denon-FB problemlos> einlesen und auch die Geräte mit IRSND bedienen. Null Probleme.
Sehr schön :)
> Auf keines der ausgesandten Kommandos reagiert der TV.
Das Timing der Sharp-FB ist zwar exakt, jedoch ermittelt IRMP leicht vom
DENON-Protokoll abweichende Timingwerte, die aber alle noch in der
IRMP-Toleranz liegen, für das Sharp-TV aber vielleicht schon zu stark
abweichen.
Ersetze mal in irmp.h folgende Zeilen
eku schrieb:> Auf keines der ausgesandten Kommandos reagiert der TV.
Habe da noch eine Idee:
Die Sharp-FB sendet offenbar 3 Frames pro Tastendruck - und nicht nur
zwei, wie es bei DENON wohl sonst üblich ist. IRSND sendet jedenfalls
nur zwei Frames, nämlich:
1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
Die Sharp FB sendet:
1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando
Dieses Verhalten könnte man mit dem IRSND simulieren, indem man
irmp_data.flags = 1 setzt, dann wiederholt IRSND nämlich die beiden
obigen Frames und es käme raus:
1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando
4. Frame: Adresse + invertiertes Kommando
Das ist zwar dann ein Frame zuviel (der letzte), aber wenn Du Glück
hast, ist das Sharp-TV nach dem 3. Frame zufrieden und führt das
Kommando aus.
Gruß,
Frank
Hallo Frank,
danke für deine Analyse. Der TV lässt sich weder von den geänderten
Timings noch von der Framewiederholung beindrucken :-(
Anbei ein erneuter Scan, diesmal beo 10KkHz. Auf der FB steht ga323wjsa.
Man kann sie an allen Ecken des Internets kaufen, aber das Protkoll wird
nicht beschrieben.
Gruß,
eku
Hi eku,
eku schrieb:> danke für deine Analyse. Der TV lässt sich weder von den geänderten> Timings noch von der Framewiederholung beindrucken :-(
Hm, erstmal habe ich jetzt keine Idee mehr, muss ich nochmal drüber
nachdenken.
> Anbei ein erneuter Scan, diesmal beo 10KkHz.
Dieses Mal ist der Scan perfekt und läuft ohne Fehler durch den IRMP
durch.
Hier eine Beispiel-Ausgabe, wo man sehr gut sieht, dass es 3 Frames
sind.
IRMP detektiert also nach dem 2. Frame (in welchem die Kommando-Bits
negiert sind) bereits die Daten. Es folgt aber nochmal der
Original-Frame. So geht das bei allen Tasten im Scan.
In meinen Augen kann das eigentlich nur daran liegen. Vielleicht baue
ich dieses 3-Frame-Telegramm mal als Besonderheit in den IRMP ein -
vielleicht hilft das weiter. Dabei würde ich dann auch die Pausen
zwischen dem 2. und dem 3. Frame mal genau umsetzen - nicht mit dem
Trick der Wiederholung.
Gruß,
Frank
eku schrieb:> passt die Beschreibung von> http://www.sbprojects.com/knowledge/ir/sharp.htm auf meinen Scan? Ist es> am Ende doch ein eigenständiges Protokoll und nur ähnlich dem Denon?
Diese Beschreibung ist tatsächlich sehr ähnlich zum Denon-Protokoll. Im
obigen Link wird von
0 Start-Bits
5 Adress-Bits
8 Daten-Bits
1 Expansion-Bit - immer 1
0 Check-Bit - immer 0
gesprochen. Das macht zusammen 15 Bits.
Das Denon-Protokoll setzt sich zusammen aus:
0 Start-Bits
5 Adress-Bits
10 Daten-Bits
macht also zusammen auch 15 Bits.
Tatsächlich sind die beiden letzten Bits auch "10" in deinen Scans, das
passt also auf die Beschreibung des Expansion- und Check-Bits.
Die Timings sind auch sehr ähnlich:
Denon Sharp
Pulse 275µs 320µs
Pause 0 775µs 680µs
Pause 1 1900µs 1680µs
Tatsächlich sind diese Timings innerhalb der IRMP-Toleranzen identisch,
IRMP kann diese also gar nicht auseinanderhalten. Es passt alles: Anzahl
der Bits und die Timings.
Wenn ich mir die Timings innerhalb Deines Scans anschaue, so liegen sie
ziemlich zwischen den obigen Werten, ich kann also auch nicht genau
sagen, ob es eher Denon- oder Sharp-Timings sind.
Aber was gar nicht passt, ist die Modulationsfrequenz, bei Denon ist sie
32 kHz, bei Sharp ist sie 38 kHz.
Ändere also bitte folgendes zum Testen des IRSND:
1. Modulationsfrequenz von 32 kHz auf 38 kHz:
Alt:
Hallo Frank,
Frank M. schrieb:> Ändere also bitte folgendes zum Testen des IRSND:
funktioniert. Es bedarf noch nicht einmal der Framewiederholung.
Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp
von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab,
unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den
40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen
Code besser und findest bestimmt einen Weg.
Gruß, eku
Hi eku,
eku schrieb:> funktioniert. Es bedarf noch nicht einmal der Framewiederholung.
Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung
der Original-Denon-Timings? Wäre klasse, wenn Du das noch separat testen
würdest.
> Die Erweiterung von IRSND stellt sicher kein Problem dar. Wie IRMP Sharp> von Dennon unterscheiden kann, ist, sieht man mal von den Timings ab,> unklar. Vielleicht kann IRMP es am Expansion- und Check-Bit oder den> 40ms zwischen ersten und zweitem Frame identifizieren. Du kennst Deinen> Code besser und findest bestimmt einen Weg.
Ja, ich werde da nochmal die genauen Unterschiede untersuchen. Mit
Codekenntnis hat das weniger zu tun, eher mit meinen (bescheidenen)
Protokollkenntnissen ;-)
Das Expansion- und Check-Bit sind leider nur ein notwendiges, aber kein
hinreichendes Kriterium für Sharp. Die "10"-Kombi kann durchaus auch bei
Denon vorkommen. Bleiben dann noch die Pausen zwischen den Frames. Da
habe ich noch nicht so genau hingeschaut...
Gruß,
Frank
Hallo Frank,
Frank M. schrieb:> Reicht vielleicht die Änderung der Modulationsfrequenz unter Einhaltung> der Original-Denon-Timings?
nein. Es bedarf definitiv der Sharp-Timings.
Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen
den Frames. Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz
Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch
daran halten.
Gruß, eku
Müller schrieb:> Nun leuft es habe meine Hardware angepasst danke.
Prima. Hast Du die RC6- und RC6A-Protokolle im IRSND schon testen
können?
Gruß,
Frank
Hallo, nettes Projekt.
Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins
für den Empfänger und die IR-Diode frei wählbar sind?
Keine Interrupt-Pins beim Empfangen nötig?
Keine PWM-Pins beim Senden nötig?
MfG
Stefan
form schrieb:> Sehe ich das richtig, das sowohl bei IRMP als auch bei IRSND die Pins> für den Empfänger und die IR-Diode frei wählbar sind?
Beim IRMP: ja.
Beim IRSND: jain, s.u.
> Keine Interrupt-Pins beim Empfangen nötig?
Korrekt, es wird gepollt.
> Keine PWM-Pins beim Senden nötig?
Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.
Siehe auch den entsprechenden Abschnitt "Modulation" im IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#Modulation
Gruß,
Frank
Frank M. schrieb:> Doch, es ist ein PWM-Pin nötig - wegen der Modulationsfrequenz.
wenn nötig ginge auch soft PWM - dazu gibts hier Beispiele in der
Codesammlung
eku schrieb:> Denon (65ms) und Sharp (40ms) unterscheiden sich in der Pause zwischen> den Frames.
Das kann ich nicht bestätigen. Wenn ich mir IR-Data/denon-15kHz.txt
anschaue, ist die Pause zwischen dem ersten und dem zweiten Frame
ziemlich genau 653 Ticks, das macht dann wg. der Scanrate 653/15 = 44ms.
Wenn ich Deine sharp.log dagegenhalte, bekomme ich da ca. 40-43 ms
heraus, also fast denselben Wert.
> Könnte IRMP zur Unterscheidung heranziehen. Bei 10kHz> Abtastung kein Problem dies zu unterscheiden, sofern sich die FB auch> daran halten.
Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du
hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate
vergessen :-)
Oder hast Du da mehr Scans von Denon-FBs?
Gruß,
Frank
Hallo Frank,
Frank M. schrieb:> Das ist mir zu eng. 40ms vs. 65ms wären wirklich schön gewesen, aber du> hast da bei der Denon-FB wohl den Faktor 15 statt 10 wg. der Abtastrate> vergessen :-)
das ist gut möglich. Die Standardabtastrate für Denon beträgt doch aber
10kHz. Eine Implementierung des SHARP-Protokolls in IRSND mit den
Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.
> Oder hast Du da mehr Scans von Denon-FBs?
Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf
verschiedene Geräte umstellen lässt und genau eine Sharp. Über die
Feiertage werde ich mal ein paar Scans aufzeihnen.
Hi eku,
eku schrieb:> Eine Implementierung des SHARP-Protokolls in IRSND mit den> Timings laut Proktollspezifikation würde mir ein Stück weiterhelfen.
Klar, das kann ich gern machen. Aber wie erkläre ich den Anwendern, dass
man das Sharp-Protokoll nehmen muss, wenn IRMP zuvor das Denon-Protokoll
erkannt hat?
> Ich besitze genau eine Denon-FB, die sich per Schiebeschalter auf> verschiedene Geräte umstellen lässt und genau eine Sharp. Über die> Feiertage werde ich mal ein paar Scans aufzeihnen.
Das ist gut. Vielleicht kann man das besser an der Anzahl der Frames
erkennen, die pro Taste geschickt werden. Mein Denon-Scan enthielt da
immer 2 Frames pro Taste, die Sharp-FB schickte immer 3 Frames, nämlich:
Denon:
1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
Sharp:
1. Frame: Adresse + Kommando
2. Frame: Adresse + invertiertes Kommando
3. Frame: Adresse + Kommando
Deshalb bitte beim Einscannen drauf achten, die Tasten möglichst kurz zu
drücken.
Gruß,
Frank
Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im
IRMP-Wikiartikel eingefügt:
http://forum.mikrokopter.de/topic-21060.html
Vielen Dank nochmal an Frank für Deine großartigen Routinen.
Stefan P. schrieb:> Ich habe mein auf IRMP & IRSND basierendes Projekt nun auch mal im> IRMP-Wikiartikel eingefügt:> http://forum.mikrokopter.de/topic-21060.html
Schön! Am witzigsten fand ich es übrigens, mit der Servo-Fernbedienung
den Fernseher lauter/leiser zu drehen...
Das Youtube-Video dazu wäre doch ein prima Link ;-)
Hallo,
bin derzeit dabei einen Umsetzer von ner Opel Lenkradfernbedienung auf
mein Sony Autoradio (Infrarot) mit nem AVR-Mega8 zu machen.
Ich habe vorerst nen kleines Prog geschrieben, was die IR-Codes leicht
zeitverzögert wieder sendet. Getestet wurde dass ganze zuerst mit meinem
TV der das NEC-Protokoll verwendet, was problemlos funktioniert.
Jedoch jeder Versuch ein erfolgreiches SIRCS Protokoll zu versenden ist
bisher gescheitert. Das Protokoll wird anscheinend jedoch richtig
erkannt. So wird mir über den UART bei jedm Tastendruck 1-2 Codes
ausgegeben die als Command im Bereich von 0x4200 bis 0x4247 liegen.
Leider habe ich kein Speicheroszi um mir die Angelegenheit da mal
anzusehen.
Wo könnte mein Problem sein?
Gruß Stefan
Danke für den Tip, auch wenn ich mit den Spannungen an der Soundkarte
vorsichtig sein würde.
Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger
registrierte Signal ist in der Datei "RX.wav" gespeichert das vom
Controler gesendete in "TX.wav". Im Log ist der Pegel vom Senden
aufgrund meiner Beschaltung noch invertiert.
Der nach Irmp ausgewertete Code soll SIRCS mit Adresse 0 und den
Commands 0x4233 gefolgt von 0x4245 sein.
Gruß Stefan
Hallo Stefan,
Stefan Grimm schrieb:> Habe mal einen "Scan" der Taste "Hoch +" gemacht. Das vom IR-Empfänger> registrierte Signal ist in der Datei "RX.wav" gespeichert das vom> Controler gesendete in "TX.wav".
Besser wäre es, wenn Du mal einen Scan per IRMP machst - einmal mit kurz
und einmal mit lang gedrückten Tasten - mindestens zwei.
Wenn die mit IRSND gesandten Daten vom Radio nicht dekodiert werden
können, kann das folgende Gründe haben:
1. Schlechtes Timing:
Quarz am µC verwenden! Die Dekodierer in den industriellen Geräten
sind nicht so timing-tolerant wie IRMP.
2. Falsche Modulationsfrquenz:
Eventuell benutzt die Original-FB zum Radio eine abweichende
Modulationsfrequenz
3. Leichte Abweichungen vom SIRCs-Protokoll
Zum Beispiel kann dies der Fall sein bei der Anzahl der
Wiederholungsframes, die gesandt werden müssen, bevor das Gerät
einen Befehl als gültig erkennt.
4. Bug in IRSND
Wovon ich aber nicht ausgehe ;-)
Kann denn IRMP das per IRSND gesandte Signal wieder dekodieren?
Welche Interruptfrequenz benutzt Du (sowohl beim IRMP als beim IRSND)?
Wie gesagt: eine per IRMP erstellte Scan-Datei (analog zu IR-Data/*.txt)
würde hier weiterhelfen.
Gruß,
Frank
Ok Danke schon mal für die Tipps.
Ich werde heute Abend mal einen Scan machen.
Ich verwende momentan die Standartvorgaben der aktuellen IRSND & IRMP.
Werde mal ne 2.Version meiner Schaltung zum "Rescan" aufbauen.
Gruß Stefan
Abend,
hab hier mal den Log aller Tasten der Fernbedienung.
In der IRMP verwende ich 10000 Interrupts, genauso wie in der IRSND.
habe irgendwie das Gefühl, das beim senden durch die recht großen
Commandos irgendwas schief geht, denn es ist nicht wirklich möglich
Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.
wenn in der oberen Zeile die Daten gespielgelt werden müsste die
Nachricht dann ja 0xEC42 lauten. nur wie sollen die nun in den
Sendbuffer geschrieben werden?, müsste dann 0xEC in den Buffer[0] und
der Rest in Buffer[1] ?
Stefan Grimm schrieb:> habe irgendwie das Gefühl, das beim senden durch die recht großen> Commandos irgendwas schief geht, denn es ist nicht wirklich möglich> Zahlen wie 0x4247 in 3 Nibble beim senden unterzubringen.
Ja, das ist der Knackpunkt. Das SIRCS-Telegramm besteht laut
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail
aus mindestens 12 Bits (3 Nibbles), maximal jedoch aus 20 Bits. Die
Bitlänge ist also variabel. IRSND unterstützt momentan nur die
12-Bit-Variante.
Ich werde mir Deine Scans mal näher ansehen und muss dann überlegen, wie
man dem IRSND die Bitlänge beibringt.
Gruß,
Frank
Hab hier nen kleinen Erfolg zu verbuchen. Habe es hinbekommen, dass die
jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die
Anpassung nicht unbedingt schön ist.
In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define
variabel erhöht.
irsnd_buffer[1]=(command&0x007f)<<1;// Anpassung auf 15 Bit
10
irsnd_busy=TRUE;
11
break;
12
}
Somit funktioniert in meinem Fall das Senden von Befehlen. Es sind Codes
von 0x4200 bis 0x4247 in Verwendung.
Hoffe dennoch das euch die Codes etwas bringen.
Gruß Stefan
Stefan Grimm schrieb:> Hab hier nen kleinen Erfolg zu verbuchen.
Freut mich!
> Habe es hinbekommen, dass die> jeweiligen Kommandos zumindest korrekt gesendet werden, auch wenn die> Anpassung nicht unbedingt schön ist.
Ich werde es in eine allgemeine Form bringen, Vorschlag dazu siehe
unten.
> In der "irsnd_ISR (void)" habe ich die Mindestanzah an Bits per #define> variabel erhöht.>
Ich nehme an, dass bei Dir SIRCS_ADDITIONAL_NUM_OF_BITS den Wert 3 hat?
> sowie in der "irsnd_send_data">
1
>irsnd_buffer[0]=(command&0x7F10)>>7;
2
>irsnd_buffer[1]=(command&0x007f)<<1;// Anpassung auf 15
3
>
Okay, das muss ich dann variabel gestalten für
SIRCS_ADDITIONAL_NUM_OF_BITS von 0 bis 8.
Ich habe mir eine allgemeine Erweiterung folgendermaßen vorgestellt:
1. Erweiterung von IRMP_DATA um: uint8_t additional_bitlen
2. IRMP füllt beim Empfang eines Frames diese Variable mit der Anzahl
der zusätzlich empfangenen Bits. In der Regel ist der Wert also 0,
in Stefans Fall dann aber 3.
3. IRSND wertet im Falle von SIRCS diese neue Variable aus, um damit
die Länge des Frames zu erhöhen.
Meinungen dazu?
Gruß,
Frank
Mir ist noch eine Alternative dazu eingefallen:
Ich baue die Information der zusätzlichen Bitlänge in irmp_data.address
mit ein. Dann kann man auf die neue Variable irmp_data.additional_bitlen
verzichten.
Gruß,
Frank
Genau SIRCS_ADDITIONAL_NUM_OF_BITS ist bei mir 3.
Keine schlechte Idee mit dem Adressfeld.
Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz
so angenehm, aber lässt sich sichrlich machen.
Gruß Stefan
Stefan Grimm schrieb:> Keine schlechte Idee mit dem Adressfeld.
Ja, dieser Weg scheint mir auch vernünftiger zu sein. Ein paar Anwender
werden dann aber bei SIRCs u.U. plötzlich andere Adresswerte bekommen
als bisher. Ich habe dazu mal die gesammelten Scans unter
IR-Data/Sony*.txt angeschaut: Die meisten haben 12, einige 15 und einer
sogar 20 Bits.
Bei den 12er-Frames wird die Adresse gleich bleiben, bei den anderen
zukünftig abweichen. Aber das ist hinnehmbar.
> Das mit dem ganzen Schieben variabel zu machen ist nicht unbedingt ganz> so angenehm, aber lässt sich sichrlich machen.
Ist nicht so schwer.
Gruß,
Frank
Im SVN ist eine neue Version von IRMP und IRSND.
Die Änderungen betreffen nur das SIRCs-Protokoll:
IRMP speichert nun die Anzahl der zusätzlichen Bits gegenüber einem
Standard-SIRCs-Frame der Länge 12 im oberen Byte des Adressfeldes. Bei
Frames mit Standard-Länge bleibt die Adresse 0x0000.
@Stefan Grimm: Damit sollte bei Dir nun die Adresse 0x0300 sein, da bei
Deiner Fernbedienung 3 zusätzliche Bits gesandt werden.
IRSND wertet nun die Längeninformation im Adressfeld aus und passt
dadurch Länge und Frame-Daten dynamisch an.
@Stefan Grimm: Kannst Du das mal testen? Bei mir habe ich es lediglich
unter Linux per Pipe von IRSND-Daten in den IRMP testen können. IRMP
konnte alle von IRSND generierten Frames mit SIRCs-Frame-Längen (12, 15
und 20) einwandfrei dekodieren.
Gruß,
Frank
Hallo Frank,
erstmal vielen dank für das super Projekt. Hat mir sehr geholfen.
Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP
machen? Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme,
die auf den Stack hinweisen, aber ich kann in meinem Teil der Software
nicht wirklich was finden. Und wenns geht wollte ichs vermeiden, IRMP
selbst analysieren zu müssen ;-)
Gruß, Sebastian
Sebastian ... schrieb:> Kannst du (zumindest ungefähre) Angaben zum RAM/Stack-Verbrauch von IRMP> machen?
An RAM werden ungefähr 60 Bytes verbraten, das sind allesamt static
Variablen. Der Stack dürfte ähnlich ausfallen, da nur wenige lokale
Variablen innerhalb der Funktion benötigt werden. Es hängt aber auch
davon ab, wieviele/welche Protokolle Du freischaltest.
> Bei mir ist der RAM grad sehr knapp und ich hab auch Probleme,> die auf den Stack hinweisen, aber ich kann in meinem Teil der Software> nicht wirklich was finden.
Dann poste Deinen Source doch mal. Und gib mal die Größe der
Data-Section an, die beim Übersetzen ausgegeben werden. Welchen µC
verwendest Du?
Typische RAM-Probleme bereiten zum Beispiel Arrays oder Strukturen, die
bereits im Source mit Konstanten gefüllt werden. Diese werden beim Boot
des µC vom Flash ins RAM kopiert, wenn Du diese Daten nicht über PROGMEM
deklarierst.
Gruß,
Frank
Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon
erklären.
Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein
hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab
ein paar größere Arrays im RAM. Mal schaun, ob ich irgendwo noch bischen
was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab
grad nen Mega8).
Sebastian
Sebastian ... schrieb:> Vielen Dank. 60Byte static plus ca. 60 Byte stack dürfte das ganze schon> erklären.
Naja, Stack sollte weniger sein.
> Danke für das Hilfsangebot, aber denke damit sollte ichs auch allein> hinkriegen (ist dann auch ein stück weit Programmiererstolz ;) ). Hab> ein paar größere Arrays im RAM.
Ändern sich die Werte in den Arrays? Wenn nicht, packe sie ins Flash.
Wenn doch, aber nur selten, packe sie ins EEPROM.
> Mal schaun, ob ich irgendwo noch bischen> was einsparen kann. Sonst gibts halt den nächstgrößeren Controller (hab> grad nen Mega8).
Mega8 ist obsolet, wechsle besser auf den pinkompatiblen Mega88 oder auf
den Mega168 mit doppelt soviel Speicher. Dann sollten Deine Probleme der
Vergangenheit angehören.
Gruß,
Frank
Der Mega8 lag halt noch rum. Irgendwann müssen die ja auch mal wegkommen
^^
Ein Teil der Arrays sind nur Kopien ihrer EEPROM-Version und werden fast
nur gelesen und sehr selten geschrieben. Ich habs auch schon probiert,
einfach live aus dem EEPROM zu lesen. Wie erwatet waren die Probleme
weg. Nur hab ich das ganze in der Bedienung unangenehm gemerkt...
Wie gesagt: Wenn mir nichts vernünftiges für die Software einfällt gibts
den nächst größeren Controller. Ich wollte halt gerne wissen, ob das
wirklich ein RAM-problem sein könnte, oder ob ich irgendwas anderes auch
noch falsch gemacht habe.
Gruß, Sebastian
Hallo Frank,
anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz
Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die
Protokolle auseinanderhalten kann.
Gruß, eku
Hallo eku,
eku schrieb:> anbei die versprochenen Aufzeichnungen von Denon und Sharp bei 10kHz> Abtastrate. Ich hoffe, die unterscheiden sich soweit, dass IRMP die> Protokolle auseinanderhalten kann.
Erstmal danke für die Erstellung der Scans.
denon2_kurz_10khz.txt kann ich leider nicht verwenden, irmp erkennt das
Zeugs nicht. Da scheint jeder Frame aus nur 3 Bits zu bestehen.
Auswerten konnte ich also nur denon1, denon3 und sharp.
Leider unterscheiden sie sich nur minimal. Damit kann man definitiv
keine Unterscheidung hinbekommen. Beide senden 3 Frames, wo die Pausen
dazwischen fast identisch sind. Die Abweichungen liegen im einstelligen
Prozentbereich. Da könnte man lediglich über statistische Auswertungen
eine Unterscheidung hinbekommen.
Du hattest ja gesagt, dass das Sharp-Gerät nicht auf die
Original-Denon-Timings reagiert. Wie sieht es denn umgekehrt aus? Kommt
das Denon-Gerät mit den Sharp-Timings zurecht?
Es gäbe ja noch die Möglichkeit, im IRSND mit einem Kompromiss im Timing
zu arbeiten, so dass sowohl Denon als auch Sharp die von IRSND
ausgesandten Frames verstehen. Idee ist also, die etwas verschiedenen
Timingwerte durch entsprechende Versuche soweit anzunähern, dass beide
Geräte damit zurechtkommen.
Könntest Du mal so eine Versuchsreihe starten? Ich kann es leider nicht,
denn ich habe weder ein Gerät von Denon noch eins von Sharp.
irmp mit der Option -a verrät über die Timings Deiner Scans:
Sharp Denon1 Denon3
Puls 320 µs 300 µs 300 µs
Pause0 735 µs 745 µs 745 µs
Pause1 1781 µs 1783 µs 1783 µs
Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich
http://www.mikrocontroller.com/de/IR-Protokolle.php#DENONhttp://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
Vielleicht sind die dort angegebenen Werte
Denon
Puls 275 µs
Pause0 775 µs
Pause1 1900 µs
einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit
neben der Realität?
Deine Denon-Fernbedienungen liegen jedenfalls viel näher an den
Sharp-Timings als an den Timings aus der obigen Dokumentation!
Fazit:
======
Wie wäre es, wenn Du in irmp.h einstellst:
und dann nochmal zunächst IRMP testest mit beiden FBs und anschließend
diese Timings auch für IRSND testest mit Deinem Denon- und Sharp-Gerät?
Ich glaube fest daran, dass beide Geräte die obigen Timings schlucken
;-)
Wenn ja, werde ich die obigen Werte ab sofort im Source verwenden.
Gruß,
Frank
Frank M. schrieb:> Ich kenne eigentlich nur zwei Quellen über das Denon-Protokoll, nämlich
[...]
> Vielleicht sind die dort angegebenen Werte>> Denon> Puls 275 µs> Pause0 775 µs> Pause1 1900 µs>> einfach schlichtweg falsch (abgeschrieben) bzw. liegen viel zu weit> neben der Realität?http://lirc.sourceforge.net/remotes/denon/http://www.hifi-remote.com/johnsfine/DecodeIR.html> Wie wäre es, wenn Du in irmp.h einstellst:
Probiere ich aus.
eku schrieb:> http://lirc.sourceforge.net/remotes/denon/
Zumindest die Werte der ersten 5 FBs in diesem Verzeichnis bekräftigen
meinen Eindruck, dass in der Realität die Denon-Timings eher denen der
Sharp-FB entsprechen und nicht den Werten in meinen herangezogenen
Dokumenten.
> Probiere ich aus.
Bin gespannt.
Gruß,
Franak
Hallo,
möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben
(besonders natürlich Frank M.) einen herzlichen Dank aussprechen.
Tolle Arbeit, ich ziehe meine Hut!
Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit
16Bit-PIC portieren können, die Performance ist super.
Gruß
Daniel
Colt Fish schrieb:> möchte nur kurz allen, die Ihre Energie in dieses Projekt gesteckt haben> (besonders natürlich Frank M.) einen herzlichen Dank aussprechen.> Tolle Arbeit, ich ziehe meine Hut!
Danke fürs Danke :-)
> Habe mir eben in kürzester Zeit den IR-Decoder für ein Projekt mit> 16Bit-PIC portieren können, die Performance ist super.
Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den
Standard-Source mit einfließen zu lassen?
Gruß,
Frank
Frank M. schrieb:> Waren dafür Anpassungen im IRMP-Source nötig, die sich lohnen, in den> Standard-Source mit einfließen zu lassen?
Nicht wirklich. Ich habe nur die Datentypen umbenennen müssen. Der C30
Compiler von Microchip ist ja ebenfalls ein gcc.
Und natürlich das Setup von Timer und Interrupts muss angepasst werden,
welches allerdings stark vom verwendeten Chip abhängt.
Gruß
Daniel
Hi eku,
eku schrieb:> Probiere ich aus.
Ich habe gerade einen systematischen Bug im IRSND entdeckt: sämtliche
gesendete Pausen waren bisher 1 Interrupt-Tick zu lang. Ich habe das
gerade korrigiert und den Source im SVN eingecheckt.
Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt
auch die ermittelten Praxiswerte für das Denon-Timing drin.
Gruß,
Frank
Die letzten Änderungen im SVN seit September 2010 sind nun eingeflossen
in eine neue IRMP- und IRSND-Version 1.9.0.
Änderungen IRMP seit 1.8.1:
- Korrekturen für Siemens-Protokoll
- Neues Protokoll: NIKON
- Speichern der zusätzlichen Bits (>12) im SIRCS-Protokoll in der
Adresse
- Timing-Korrekturen für Denon-Protokoll
Download IRMP:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen IRSND seit 1.8.0:
- Neues Protokoll: RC6A
- Neues Protokoll: RC6
- Neues Protokoll: NIKON
- Beachten der zusätzlichen Bits (>12) im SIRCS-Protokoll
- Korrektur der Pausenlängen
- Timing-Korrekturen für Denon-Protokoll
Download IRSND:
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Viel Spaß,
Frank
Hallo Frank,
> Daher bitte vorher den Source aus dem SVN neu laden. Dort stehen jetzt> auch die ermittelten Praxiswerte für das Denon-Timing drin.
wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun
beide mit dem Denon-Protokoll steuern. Allerdings liegt die
Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor
sie erkannt werden.
In welche Richtung kann ich das Timing noch verändern? Mehr hin zum
Sharp oder wieder zu den alten Denon Werten?
Gruß, eku
Hallo eku,
eku schrieb:> Hallo Frank,>> wir sind auf dem richtigen Weg! Sharp und Denon-Geräte kann ich nun> beide mit dem Denon-Protokoll steuern. Allerdings liegt die> Erkennungsrate bei ca. 80%. Einige Codes muss ich mehrfach senden bevor> sie erkannt werden.
Ist es bei beiden 80%?
> In welche Richtung kann ich das Timing noch verändern? Mehr hin zum> Sharp oder wieder zu den alten Denon Werten?
Als erstes würde ich mal mit der Modulationsfrequenz spielen. In der
Denon-Doku las ich immer was von 32kHz. Aber das glaube ich nicht so
recht. Probiere mal 32kHz, 36kHz und 38kHz.
Wenn das nichts bringt, verschiebe die Timings mal zu den alten
Denon-Werten.
Gruß,
Frank
Hallo Frank,
mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich
sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die
Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp
reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.
Ein kleinerSchönheitsfehler ist mir noch aufgefallen:
irmp/irsnd.c: In function 'ir_tx_put':
irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'
Diese Variable sollte nur für RC6 einkompiliert werden.
Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen
Stand dann noch zu Ethersex portieren.
Gruß, eku
Hallo eku,
eku schrieb:> mit den Timings der Revision 51 und 36kHz Modulationsfrequenz kann ich> sowohl das Denon als ach das Sharp-Gerät fehlerfrei bedienen. Die> Reaktion des Denons ist bei 32kHz und 38kHz schlechter. Der Sharp> reagiert auf 32kHz garnicht und auf 38kHz unzuverlässig.
Vielen Dank für die wichtige Info. Ich werde also 36 kHz in irsnd.c
eintragen und die Timings so lassen, wie sie aktuell sind. Sie
entsprechen ja auch im Wesentlichen den von Dir gescannten Werten und
passen auch zur lirc-DB.
> Ein kleinerSchönheitsfehler ist mir noch aufgefallen:>> irmp/irsnd.c: In function 'ir_tx_put':> irmp/irsnd.c:337: warning: unused variable 'toggle_bit_rc6'>> Diese Variable sollte nur für RC6 einkompiliert werden.
Danke, das war ein Copy-And-Paste-Fehler, die RC5-Bedingung ist hier an
dieser Stelle falsch.
Alt:
Werde ich ebenfalls korrigieren.
> Nochmals vielen Dank für Deine Unterstützung. Ich werde den aktuellen> Stand dann noch zu Ethersex portieren.
Auch von mir vielen Dank für Deine wirklich hilfreichen Experimente.
Gruß,
Frank
eku schrieb:> Ich werde den aktuellen Stand dann noch zu Ethersex portieren.
Ethersex' IRMP ist nun auch auf dem aktuellen Stand. Viel Spaß damit!
http://www.ethersex.de
Hallo Frank,
genau so etwas wie IRMP habe ich gesucht! :) Für ein Uni-Projekt will
ich Infrarot-Signale an einem MSP430 empfangen. Da es so viele
unterschiedliche Protokolle gibt, stellte sich mir die Frage, welche
Protokolle ich implementieren soll. Jetzt sehe ich, dass in IRMP schon
die meisten implementiert und ausgiebig getestet sind.
Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu
bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.
Viele Grüße
Hallo,
ist ja ein tolles Projekt. Ich habe mir das Ganze mal auf einen ATMEGA8
16MHz angepasst und noch eine Ausgabe für die Serielle eingefügt.
So, dann gleich ein paar FB ausprobiert und es klappt recht gut. Nur
eine FB mag so gar nicht. Mit der hatte ich aber auch schon früher
Probleme.
Eine Universal FB konnte sie jedenfalls nicht nachbilden.
Es handelt sich um eine FB für den T-Home X301T Mediareceiver.
Hersteller ist ruwido und es ist bereits die zweite Generation.
Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten
der Reihenfolge nach betätigt.
Kann man da was erkennen?
Gruß Fred
Fred schrieb:> Es handelt sich um eine FB für den T-Home X301T Mediareceiver.> Hersteller ist ruwido und es ist bereits die zweite Generation.>> Im Anhang ist eine Datei, da hab ich mal mit der Logfunktion alle Tasten> der Reihenfolge nach betätigt.
Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl
der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt. Leider sind da
noch ein paar Ungenauigkeiten drin, wo ich nicht weiß, ob das
Aufzeichnungsfehler sind oder etwas anderes.
Ändere in irmp.h mal testweise:
Alt:
Dann ist die Erkennungsrate bei über 70 Prozent.
Aber wie gesagt: das ist nur ein Test, keine endgültige Lösung. Denn das
RC5-Protokoll hat tatsächlich nur 13 Bits.
Gruß,
Frank
iffi schrieb:> genau so etwas wie IRMP habe ich gesucht! :) Für ein Uni-Projekt will> ich Infrarot-Signale an einem MSP430 empfangen.
Wenn Du IRMP auf MSP430 portiert hast, kannst Du mir gerne die
Änderungen nennen (z.B. über #ifdef MSP430), damit ich die Anpassungen
einpflegen kann.
> Jetzt wird es eine Kleinigkeit sein, den Infrarot-Sensor in Gang zu> bringen. Danke, dass du allen dein Projekt zur Verfügung stellst.
Danke fürs Danke :-)
Gruß,
Frank
Frank M. schrieb:> Das scheint ein Manchester-Code mit RC5-Timings zu sein, aber die Anzahl> der Bits ist von 13 (Original-RC5) auf 17 Bit aufgebohrt.
Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt
sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz
zu RC5 jedoch invertiert. Die unter
http://www.mikrocontroller.net/articles/MOTOROLA_VIP1710#Fernbedienung
ist recht ähnlich.
Fred
ich schrieb:> Ich habe mal versucht über die FB was rauszufinden. Das Protokoll nennt> sich r-step und soll 23 bit und Manchestercodierung haben. Im Gegensatz> zu RC5 jedoch invertiert.
Die Bitlänge ist definitiv 17 und nicht 23.
Wenn ich in irmp.c die Toleranz für RC5 von 10% auf 20% hochsetze:
habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz
am µC?
Leider hast Du in der Scan-Datei keine Kommentare eingepflegt. Ich habe
nämlich gesehen, dass von den 44 Tastendrücken, die Du aufgezeichnet
hast, 14 identisch sind, es tatsächlich also nur 30 verschiedene Tasten
waren.
Um nun herauszufinden, ob der Code tatsächlich invertiert ist oder
nicht, bitte ich Dich, zumindest die Tasten 0-9 nochmal aufzuzeichnen
und mit einer Kommentarzeile vor jeder Scan-Zeile zu versehen, siehe
dazu auch die anderen Scan-Dateien im Unterverzeichnis IR-Data.
Gruß,
Frank
Frank M. schrieb:> habe ich sogar eine Erkennungsrate von 100%. Verwendest Du einen Quarz> am µC?
ja, einen 16MHz.
Die Info mit den 23 Bit stammt nicht von mir. Da bin ich mir aber auch
nicht sicher, was da mit dazugerechnet wurde.
Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45
verschiedene Codes in der alten Scandatei sein.
Bewirkt die Invertierung der Manchestercodierung irgendwas?
Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.
Fred
Fred schrieb:> ja, einen 16MHz.
Dann ist die Fernbedienung so "wackelig" ;-)
> Den Scan werde ich noch mal durchführen. Es sollten eigentlich 45> verschiedene Codes in der alten Scandatei sein.
Leider nicht. Die Datei hat 44 Zeilen, aber 14 Codes sind doppelt.
> Bewirkt die Invertierung der Manchestercodierung irgendwas?
Nein, nur dass die Codes invertiert sind und dann "riesengroße" Zahlen
ergeben. Ich glaube nicht, dass die tatsächlich zu invertieren sind. Das
wird man aber besser sehen, wenn die Zeilen kommentiert sind, denn meist
geben die Tasten 0 bis 9 einen fortlaufenden Code ab.
> Mach mich gleich an die Arbeit, wenn ich wieder daheim bin.
Prima.
Gruß,
Frank
Hallo,
erstmal vielen Dank dafür das es Leute gibt die Ihre Projekte anderen
zugänglich machen :)
Hab gerade das erste Mal mit IRMP rumgespielt und bin begeistert. Hab
aber auch eine Fernbedienung gefunden die nicht funktionieren will.
Die Fernbedienung gehört zu einem IMON-Display (für den PC).
Hab mal n Paar tasten gedrückt und das File angehängt :)
Ist das Normal das die einzelnen Befehle sich so stark in der Länge
unterscheiden?
Kann jemand erkennen was das für n Protokoll is?
Danke :)
Schon wieder ich...
Ich habe einen TSOP1838 an PB6 eines mit 8 MHz getakteten Atmega88
angeschlossen, der in einem STK500 steckt.
RX/TX hängen an PD0/PD1 und in der irmpconfig.h wurde das logging
aktiviert.
HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen
Ausgabe.
Muss man sonst noch etwas einstellen, oder was könnte das Problem sein?
Bastian F. schrieb:> HTerm zeigt mir jedoch bei keiner einzigen Fernbedienung irgendeinen> Ausgabe.
Zeig mal Deine irmpconfig.h und deine main-Funktion.
Gruß,
Frank
Martin schrieb:> Die Fernbedienung gehört zu einem IMON-Display (für den PC).>> Hab mal n Paar tasten gedrückt und das File angehängt :)
Habe das mal durch "irmp -a" gejagt. Scheint tatsächlich ein neues
Protokoll zu sein, was aber relativ einfach zu decodieren ist.
> Ist das Normal das die einzelnen Befehle sich so stark in der Länge> unterscheiden?
Sieht so aus, als ob das einfach Schrott ist. Kann es sein, dass da eine
Neonröhre oder ähnliches in der Nähe leuchtete?
> Kann jemand erkennen was das für n Protokoll is?
Eines, welches IRMP noch nicht beherrscht. Ich baue es ein und melde
mich danach nochmal mit einer Lösung.
Gruß,
Frank
Frank M. schrieb:> Zeig mal Deine irmpconfig.h und deine main-Funktion.
Ich befürchte, dass ich das ganze noch nicht wirklich verstanden habe.
Die main Funktion habe ich nämlich nicht verändert und wenn ich mir die
anschaue, wird dort nirgends das Logging bzw die entsprechende Ausgabe
aufgerufen wird.
Bin davon ausgegangen, dass das einfach durch das Setzen der "1"
passiert.
Was muss ich denn eintragen, dass ich eine Ausgabe bekomme?
Hi,
seh dir einfach mal das Projekt hier ganz oben auf der Seite an. In der
main.c ist ein funktionierendes Beispiel zur Ausgabe des "normalen"
Codes.
Gruß Stefan
Hallo,
hat ne Weile gedauert aber ich kam nicht früher heim :-(
So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten
jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile
erhalten. Ich hoffe, das ist so brauchbar.
Für die Atmega8 Version brauchte ich nicht viel anpassen. Im Projekt
den entsprechenden Controller und Takt einstellen und in der
irmpconfig.h
noch den entsprechenden Port wählen.
Fred
Fred schrieb:> So, im Anhang nun die Scans der Tasten 1-0. Ich habe die Tasten> jeweils mehrmals betätigt und dazu auch immer eine ganze Zeile> erhalten. Ich hoffe, das ist so brauchbar.
Ja, der Scan ist sehr gut brauchbar. Was mir auffällt, dass der "Jitter"
wesentlich geringer ist. Die Puls-/Pause-Zeiten in r-step.txt sind
wesentlich exakter als die in t-home.txt.
Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung
(z.B. mit/ohne Quartz) verwendet?
Was mir noch auffiel: Kommen hier beim Manchester-Protokoll zwei Pulse
oder Pausen direkt hintereinander, weichen sie etwas von der doppelten
Dauer, die man erwarten müsste, ab. Ich musste dafür den
Manchester-Decoder im IRMP etwas "aufbohren", um so ein asymmetrisches
Verhalten besser abbilden zu können.
Ausserdem sind die Bits hier tatsächlich "negiert", d.h. bei einer 1
kommt erst der Puls, dann die Pause. Damit erhöht sich die Anzahl der
Bits im Frame von 17 auf 18. Das letzte Bit ist ein Parity-Bit, was von
IRMP nicht ausgewertet wird.
Hier das Ergebnis, gekürzt um die Wiederholungen:
#1 000110010100000010 p = 23, a = 0x0065, c = 0x0001, f = 0x00
#2 000110010100000101 p = 23, a = 0x0065, c = 0x0002, f = 0x00
#3 000110010100000110 p = 23, a = 0x0065, c = 0x0003, f = 0x00
#4 000110010100001001 p = 23, a = 0x0065, c = 0x0004, f = 0x00
#5 000110010100001010 p = 23, a = 0x0065, c = 0x0005, f = 0x00
#6 000110010100001101 p = 23, a = 0x0065, c = 0x0006, f = 0x00
#7 000110010100001110 p = 23, a = 0x0065, c = 0x0007, f = 0x00
#8 000110010100010001 p = 23, a = 0x0065, c = 0x0008, f = 0x00
#9 000110010100010010 p = 23, a = 0x0065, c = 0x0009, f = 0x00
#0 000110010100010101 p = 23, a = 0x0065, c = 0x000a, f = 0x00
Die Adresse ist also 0x65, der Code geht von 0x01 bis 0x0a. Das passt
sehr gut.
Bevor ich den Code veröffentliche, möchte ich obige erste Frage
beantwortet haben. Denn der Ruwiodo-Decoder versteht zwar jetzt
r-step.txt ganz gut, jedoch nicht mehr t-home.txt, welches zu nahe an
den RC5-Timings ist.
Gruß,
Frank
Hallo Frank,
ich hab eben nochmal auf der Fernbedienung rumgedrückt - und siehe da:
alle Befehle gleich lang.
Keine Ahnung was da gestört hatte. Neonröhre hab ich hier nicht. Alles
was zu dem Zeitpunkt geleuchtet hatte war mein Display :)
Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das
ja dann die Arbeit (kenn mich damit ja nich so aus ;)).
Ach... Nochmals danke für deine Arbeit! :)
Martin
Hallo Martin,
Martin schrieb:> Hab dir die neue Datei nochmal angehängt. Vielleicht erleichtert dir das> ja dann die Arbeit (kenn mich damit ja nich so aus ;)).
Danke. Mittlerweile bin ich mit der imon.txt durch. Es handelt sich um
kein Fernbedienungsprotokoll im klassischen Sinne. Es ist weder
Manchester-codiert noch ist ein Pulse-Distance Protokoll. Es ist viel
einfacher, nämlich einfach bitseriell mit 38 Bits, wenn ich mich nicht
verzählt habe.
Das kann IRMP nicht. Einfacher wäre es, einen Software-Uart (i.d.R. 8
Bit) auf 38 Bit umzuschreiben. ;-)
Naja, ich schaue mir nochmal imon2.txt an. Dann entscheide ich, ob ich
das in IRMP einbaue oder nicht.
Gruß,
Frank
Hallo Frank M.,
erstmal vielen Dank für Deine tolle Arbeit.
Ich habe hier auch eine imon-Fernbedienung mit dem Namen "Veris RM200".
Sie gehört zu einem PC-Gehäuse von Antec.
Allerding werden hier im Gegensatz zu Martin´s Protokoll je Tastendruck
zwei Pakete gesendet.
Es wäre schön wenn das Protokoll in deine Software integriert werden
könnte.
Schonmal vielen Dank
Frank M. schrieb:> Hast Du da eine andere Fernbedienung oder eine andere Empfängerschaltung> (z.B. mit/ohne Quartz) verwendet?
Hallo,
ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,
Da ich die Fuses erst danach geändert habe.
Zusätzlich liegt die Samplerate jetzt bei 24000.
Soll ich das mal mit weniger oder eben einer anderen Rate noch mal
scannen?
Vielleicht hat ja noch jemand die FB zum MOTOROLA VIP1710, die sollte ja
so ähnlich sein.
Fred
Fred schrieb:> ich vermute, beim ersten Scan war der Quarz noch nicht aktiv,> Da ich die Fuses erst danach geändert habe.
Ahja, das erklärt das Verhalten. Da die Timings sehr nahe bei RC5
liegen, kann ich hier auch nur die Verwendung eines Quarzes empfehlen.
> Zusätzlich liegt die Samplerate jetzt bei 24000.>> Soll ich das mal mit weniger oder eben einer anderen Rate noch mal> scannen?
24000 ist zuviel, da läuft der Log-Buffer im IRMP über. Wenn Du nochmal
Lust hast, kannst Du das gern mit 15000 wiederholen. Dann bekomme ich
auf jeden Fall genauere Werte.
Gruß,
Frank
@Fred:
Ich habe die Unterstützung der T-Home Mediareceiver-FB (neues Protokoll
"RUWIDO") ins SVN eingecheckt. Du kannst ja mal testen, ob damit die FB
sauber erkannt wird. Du musst aber in irmpconfig.h das RUWIDO-Protokoll
noch freischalten. Standardmäßig ist es abgeschaltet.
Gruß,
Frank
Hallo, melde mich auch mal wieder im IRMP Projekt zurück ;-)
Gibt es schon praktische Erfahrung mit RC6(a) in irsnd? Ich habe das
gerade in Ethersex probiert, da wackelt der Pin garnicht. Hat es jemand
schon mal "nativ" probiert? (RC5, NEC, SIRCS und andere funktionieren
da)
Hab leider meine IRMP Testumgebung vollkommen zerlegt...
Danke für einen Input.
Grüße,
Klaus
So, die Frage hätte ich mir sparen können ;-)
Test war einfacher aufzubauen als gedacht, irsnd schickt alles und irmp
erkennt den Code. Wie zu erwarten.
Hat jemand Ethersex am laufen mit irsnd und könnte RC6 mal testen?
Grüße,
Klaus
Wie genau kann man denn nun loggen?
Wie gesagt, habe ich nur das Logging aktiviert und sonst nichts am
Programm geändert. Und das scheint ja schonmal falsch zu sein.
Wird wohl nur der Aufruf einer Funktion oä sein, aber ich verstehe es
leider nicht, bzw kann diese Funktion nicht finden.
Wäre nett, wenn sich jemand erbarmen würde und mir dies erklären könnte.
Im ersten Entwurf "hier ganz oben auf der Seite" habe ich dahingehend
auch nichts finden können.
Danke!
Hallo,
ich habe nun die Version aus dem SVN neu gezogen und die beiden
Logdateien
erzeugt. Ein mal mit Abtastrate 10000 und 15000.
Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.
Dies wäre aber mit RC80 usw. nötig.
Leider funktioniert die Erkennung von ruwido noch nicht richtig.
Fred
Fred schrieb:> ich habe nun die Version aus dem SVN neu gezogen und die beiden> Logdateien> erzeugt. Ein mal mit Abtastrate 10000 und 15000.
Danke, schaue ich mir an.
> Es ist mit dieser Version nicht mehr möglich auf 20000 zu gehen.
Wieso nicht? Compiler-Fehlermeldung oder was anderes, was nicht mehr
geht?
> Dies wäre aber mit RC80 usw. nötig.
Du meinst RECS80? Hat das mal bei Dir funktioniert? Ich habe bisher von
niemandem eine Rückmeldung zu RECS80 erhalten, der IRMP-Code dazu war
bisher absolut ungetestet.
> Leider funktioniert die Erkennung von ruwido noch nicht richtig.
Wie äußert sich das?
Gruß,
Frank
Fred schrieb:> ich habe nun die Version aus dem SVN neu gezogen und die beiden> Logdateien> erzeugt. Ein mal mit Abtastrate 10000 und 15000.
Ich habe die mal verglichen mit Deiner vorhergehenden r-step.txt. Dort
sind die Pulse und Pausen ziemlich genau doppelt so lang wie in
home10k.txt. Kann es sein, dass Du r-step.txt mit 20kHz aufgenommen
hast? Das hättest Du mir sagen müssen! Jetzt sind die Timingwerte für
das RUWIDO-Protokoll alle viel zu kurz :-(
Bitte um Aufklärung.
Gruß,
Frank
Hallo,
sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben
eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.
Die beiden anderen mit 15000 und 10000. Ich hätte da noch ein 20000 und
25000 erzeugt, aber das ging ja nicht mehr.
Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.
Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst
später gelesen.
Fred
Fred schrieb:> sorry für die unvollständigen Angaben. Ich hatte wie oben beschrieben> eine Abtastrate von 25000 eingestellt und das r-step.txt erzeugt.
Upps, sogar 25000. Ich habe mich schon gewundert, warum ich die 3
Dateien nicht "übereínander" bekommen habe. Die Angabe der Abtastrate
ist absolut wichtig.
> Bei 20000 kommt jetzt "integer overflow in expression" mit 10 warnings.> Das eigendlich nicht mehr wie 20000 gehen sollte, hab ich auch erst> später gelesen.
Das ist logisch, durch die falschen Timingwerte, die um den Faktor 2,5
zu groß sind, laufen bei so hohen Abtastraten die Variablen über.
Ich werde sie um den Faktor 2,5 stauchen, dann nochmal alle 3 Dateien
damit durchchecken und dann, wenn es läuft, ein Update im SVN machen.
Gruß,
Frank
Hallo,
ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder
die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt,
da dies für ein paar Protokolle anscheinend nötig ist.
die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird
aber nicht erkannt, könnte auch was anderes sein. Die sagem.txt stammt
von einer d-box und wird auch nicht erkannt. Bei der kathrein.txt würde
mich nur interessieren, ob das ein bekanntes Verfahren ist. Zusätzlich
noch die r-step.txt mit der gleichen Rate.
Ich hoffe da ist was brauchbares für dich dabei.
Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine
feste Abtastrate vorgeben?
Fred
Fred schrieb:> ich hab mal weiter Scans durchgeführt. Dazu hab ich jetzt erstmal wieder> die alte Version geflasht und hierbei 20000 als Abtastrate eingestellt,> da dies für ein paar Protokolle anscheinend nötig ist.
15kHz wären optimal. Bei 20kHz reicht der Buffer nicht aus, um
Framewiederholungen zu speichern.
> die Datei irc.txt sollte eigentlich das RECS80 Protokoll sein. Es wird> aber nicht erkannt, könnte auch was anderes sein.
Das ist ein Manchester-Protokoll, und zwar ein Mischmasch aus Grundig (9
Datenbits) und Nokia (16 Datenbits). IRC (was ist das?) hat aber nur 13
Datenbits. Das kann ich leicht einbauen.
> Die sagem.txt stammt> von einer d-box und wird auch nicht erkannt.
Ein Pulse-Distance-Protokoll, was leider vom Start-Bit mit dem
Siemens-Protokoll her kollidiert. Deine T-Home-Scans funktionieren bei
mir nun alle wunderbar, kollidieren aber nun vom Timing her mit Denon
und auch dem Siemens-Protokoll. Da bin ich noch etwas am tüfteln, wie
ich dieses auseinanderhalten könnte.
> Bei der kathrein.txt würde mich nur interessieren, ob das ein bekanntes> Verfahren ist.
Nein, das ist was komplett neues, Zwischen den Pulsen sind irre lange
Pausen, die schon nicht mehr als Pausen zwischen Bits, sondern als
Pausen zwischen Frames verstanden werden.
> Zusätzlich noch die r-step.txt mit der gleichen Rate.
Funktioniert wunderbar, leider habe ich da noch diese Konflikte zu
SIEMENS und DENON. Deaktiviere ich diese beide Protokolle, läuft alles
gut.
> Ich hoffe da ist was brauchbares für dich dabei.
Danke, ich werde da das beste draus machen.
> Wegen den Verwirrungen der Abtastrate, sollte man beim logging eine> feste Abtastrate vorgeben?
Nein, das geht nicht. Bei einigen Protokollen sind die Pulse sehr kurz,
dann ist 10kHz ungeeignet. 10kHz haben aber den Vorteil, dass man auch
Frame-Wiederholungen noch sieht. 15kHz ist da ein guter Kompromiss,
siehe oben. Optimal ist es, die Frquenzrate im Dateinamen zu
hinterlegen, wie ich es mit den Beispieldateien unter IR-Data gemacht
habe.
Gruß,
Frank
Hallo,
soll ich die Scans mit 15000 noch mal wiederholen?
das irc ist die FB von Pollin, die bei dem IR-Fernsteuerbausatz
mitgeliefert wird. Im Artikel [[Quellcode für den Pollin Fernsteuer
Bausatz]] wurde eben dieses Verfahren erwähnt. So wie es aber aussieht
ist das aber nicht mehr das was es sein sollte.
Die kathrein scheint wohl so langsam zu sein, da das Gerät dazu nur
einen 8051 mit 1MHz hat und die FB dazu angepasst ist.
Fred
Fred schrieb:> soll ich die Scans mit 15000 noch mal wiederholen?
Wenn Du Spaß daran hast, sehr gern :-)
> das irc ist die FB von Pollin, die bei dem IR-Fernsteuerbausatz> mitgeliefert wird. Im Artikel [[Quellcode für den Pollin Fernsteuer> Bausatz]] wurde eben dieses Verfahren erwähnt. So wie es aber aussieht> ist das aber nicht mehr das was es sein sollte.
Pollin hat da schon 3x die Fernbedienung gewechselt. Das war mal RECS80
mit dem 3004er Controller in der FB.
> Die kathrein scheint wohl so langsam zu sein, da das Gerät dazu nur> einen 8051 mit 1MHz hat und die FB dazu angepasst ist.
Normalerweise verwendet Kathrein das Protokoll RC6A, welches von IRMP
auch unterstützt wird. Aber die scheinen das auch zu wechseln....
Gruß,
Frank
Bastian F. schrieb:> Wie genau kann man denn nun loggen?
Ich verstehe leider überhaupt nicht, was Du möchtest. Möchtest Du
loggen, um eine unbekannte Fernbedienung zu scannen oder willst Du nicht
erstmal schauen, ob IRMP Deine Fernbedienung vielleicht doch erkennt? In
mehr als 80% der Fälle sollte die FB erkannt werden. Du musst dann nur
noch
- Protokoll
- Adresse
- Kommando
auch irgendwo ausgeben, entweder auf dem UART oder auf einem LC-Display.
> Wie gesagt, habe ich nur das Logging aktiviert und sonst nichts am> Programm geändert. Und das scheint ja schonmal falsch zu sein.
Ja, das Logging ist nur für unbekannte FBs. Erstmal solltest Du schauen,
ob IRMP die FB nicht doch erkennt.
> Wird wohl nur der Aufruf einer Funktion oä sein, aber ich verstehe es> leider nicht, bzw kann diese Funktion nicht finden.
Schau Dir die main-Funktion von irmp.c ganz am Ende von main.c an:
1
// This is the main routine if you use GCC Compiler
2
int
3
main(void)
4
{
5
IRMP_DATAirmp_data;
6
7
irmp_init();// initialize rc5
8
timer_init();// initialize timer
9
sei();// enable interrupts
10
11
for(;;)
12
{
13
if(irmp_get_data(&irmp_data))
14
{
15
// ir signal decoded, do something here...
16
// irmp_data.protocol is the protocol, see irmp.h
17
// irmp_data.address is the address/manufacturer code of ir sender
18
// irmp_data.command is the command code
19
}
20
}
21
}
> Wäre nett, wenn sich jemand erbarmen würde und mir dies erklären könnte.
Du musst den Teil nach dem if-Statement schon mit Leben füllen, sonst
bekommst Du kein Ergebnis. Hier kann sich jeder selbst austoben. Ich
verstehe IRMP eher als anzuwendendes Tool und nicht als fertiges
Programm.
Gruß,
Frank
eku schrieb:> versuch doch bitte nur RUWIDO einzukompilieren :-)> error: 'last_value' undeclared
Danke für den Hinweis. Hier der Fix in irmp.c (ziemlich am Anfang):
Alt:
Fred schrieb:> da muss RC5 noch mit rein, dann klappts.
Es klappt dann zwar, aber RC5 ist kein Muss. Der Fehler lag woanders,
siehe letzten Beitrag.
Gruß,
Frank
Hallo,
so, nun hab ich mal wieder etwas Zeit gehabt und konnte mal noch ein
paar Sachen machen.
Ich hab die Kathrein mal mit 10k und 15k protokolliert. Irgendwie, kann
ich da nicht viel erkennen. Darum hab ich einfach mal die FB aufgemacht
und mir den Chip angesehen. Auf der Platine steht übrigens auch RUWIDO,
dürfte aber trotzdem ein anderes Protokoll sein. Der Chip ist mit M709
bezeichnet.
Datenblatt hab ich mal rausgesucht und angehängt. Nach der Schaltung
müsste der Carriermode eingestellt sein.
Mist, ich glaub ich kann hier keine Logs mehr anhängen.
Fred
Sorry, ich kann gar keine Dateien mehr anhängen.
Gebe ich einen Dateianhang ein, lässt sich der Beitrag nicht mehr
senden.
Wie kann ich denn nun dir die Logs etc. zur Verfügung stellen?
Die IRC hat übrigens eine SAB2008 und sollte IR60 sein.
Die Sagem hat einen M34280MK-331FP, dazu konnte ich nichts genaues
finden.
Fred
Fred schrieb:> Wie kann ich denn nun dir die Logs etc. zur Verfügung stellen?
Im IRMP-Source findest Du oben im Kommentar meine E-Mail-Adresse.
Gruß,
Frank
Im SVN ist eine neue IRMP-Version 1.9.2
Die bisherigen Decoderteile für RUWIDO (T-Home-Mediareceiver) und für
SIEMENS (Siemens-Gigaset) konnte ich vereinigen, denn tatsächlich konnte
ich nach den Wirren der unterschiedlichen Scan-Frequenzen nun erkennen,
dass die Timings innerhalb der Toleranzgrenzen gleich sind. Der
Unterschied liegt lediglich in der Länge des Frames:
RUWIDO: 9 Adress-Bits + 7 Kommando-Bits + 1 Check-Bit = 17 Bits
SIEMENS: 11 Adress-Bits + 10 Kommando-Bits + 1 Check-Bit = 22 Bits
Der Decoder nimmt nun beim Empfang zunächst das kürzere RUWIDO-Protokoll
an, wenn das Timing passt, und schaltet dann während des Empfangs auf
das SIEMENS-Protokoll um, wenn der Frame doch länger ist als 17 Bits.
Beide Protokolle sind erst aktivierbar ab einer Sample-Frequenz von 15
kHz.
Viel Spaß,
Frank
Und noch ein Update: Im SVN ist nun die neue IRMP-Version 1.9.5:
Neues Protokoll: KATHREIN
@Fred: Bitte mal mit Deiner IRC-FB testen, danke!
Gruß,
Frank
Leider geht SIEMENS nun nicht mehr zu übersetzen:
irmp/irsnd.c:1088: error: 'SIEMENS_BIT_TIME' undeclared (first use in
this function)
irmp/irsnd.c:1088: error: (Each undeclared identifier is reported only
once
irmp/irsnd.c:1088: error: for each function it appears in.)
irmp/irsnd.c:1092: error: 'SIEMENS_STOP_BIT' undeclared (first use in
this function)
irmp/irsnd.c:1096: error: 'SIEMENS_FRAME_REPEAT_PAUSE_TIME' undeclared
(first use in this function)
irmp/irmp.h:41: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'PAUSE_LEN'
irmp/irmp.h:427: error: expected specifier-qualifier-list before
'uint8_t'
irmp/irmp.h:447: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'irmp_get_data'
irmp/irmp.h:456: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'irmp_ISR'
irmp/irsnd.h:31: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'irsnd_is_busy'
irmp/irsnd.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'irsnd_send_data'
irmp/irsnd.h:45: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'irsnd_ISR'
eku schrieb:> Leider geht SIEMENS nun nicht mehr zu übersetzen:
Sorry, hatte vergessen, die neuen SIEMENS-/RUWIDO-Konstanten an IRSND
anzupassen.
Ist korrigiert.
Gruß,
Frank
jar schrieb:> $Id: irmp.c,v 1.94 2011/02/22 14:24:00 fm Exp $
Das ist meine interne CVS-Version, die hat nichts mit der "offiziellen"
Version des Gesamtpakets zu tun. Dass meine interne Versionsverwaltung
gerade bei 1.94 angekommen ist, ist reiner Zufall. Das bedeutet
lediglich, dass ich mittlerweile 94 historische Versionen von irmp.c
habe. In den anderen Source-Dateien stehen ganz andere Zahlen, je
nachdem, wie oft ich diese in meine interne Versionsverwaltung (CVS)
eingecheckt habe.
Die "offizielle" Version des IRMP-Pakets steht in README.txt - und sonst
nirgendwo ;-)
Gruß,
Frank
Hallo,
hatte nun mal wiede Zeit zum Testen. (Manchmal hat ein Steik auch was
Gutes)
Also die Kathrein und die Ruwido Auswertung funktioniert schon mal
perfekt.
Die IRC (IR60) funktioniert auch schon fast perfekt, nur bei zwei Tasten
wird nichts erkannt. Ich habe eine Log für diese beiden Tasten
angehängt. Vielleicht kann man daran was erkennen.
Die beiden anderen Dateien sind ein Scan mit einer Universal FB. Die
haut im Scanmodus den Power-Off mit allen möglichen Kodierungen raus.
Die zweite Datei zeigt, was erkannt worden ist. Da kann ich für alle
Variationen, die die FB kennt auch noch andere Logs liefern.
Ein kleines Problem hab ich noch entdeckt. Mit der Abtastrate 15k kann
ich z.B. das RECS80 nicht aktivieren. Setze ich 20k, mag der RC5 und
noch ein paar andere nicht.
Das dürfte wohl kein Problem sein, wenn man nur ein Protokoll braucht.
Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes
erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur
noch ein paar Routinen für das LCD.
Momentan haue ich die Daten nur über die Serielle raus. Mal sehen, ob
das mit den LCD Routinen noch in den ATMEGA 8 reinpasst.
Fileupload geht anscheinend auch wieder.
Fred
Fred schrieb:> Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes> erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur> noch ein paar Routinen für das LCD.
Hallo Fred,
http://www.mikrocontroller-projekte.de/Mikrocontroller/IR-LCD/IR-LCD.html
braucht aber einen M168, dafür wenn gewünscht mit Bootloader.
Einfach die aktuellen irmp Files einbauen, habs bei mir mit Version 1.90
laufen und werde die Seite demnächst mal mit der aktuellen Version
updaten.
Grüße,
Klaus
Ach ja, wegen dem Layout und der kompatibilität mit der alten Codevision
Version geht hier leider kein Quarz. Kann mit einem anderen Layout
natürlich angepasst werden.
Klaus
Hallo Fred,
Fred schrieb:> Also die Kathrein und die Ruwido Auswertung funktioniert schon mal> perfekt.
Das freut mich, Danke für Deine Tests :-)
> Die IRC (IR60) funktioniert auch schon fast perfekt, nur bei zwei Tasten> wird nichts erkannt. Ich habe eine Log für diese beiden Tasten> angehängt. Vielleicht kann man daran was erkennen.
Ja, diese 2 Tasten senden einen kürzeren IR60-Frame (5 statt 7 bit) aus.
Kannst Du damit leben, auf diese beiden Tasten zu verzichten? Sonst
müsste ich da noch eine etwas kompliziertere Sonderbehandlung
einbauen...
> Die zweite Datei zeigt, was erkannt worden ist. Da kann ich für alle> Variationen, die die FB kennt auch noch andere Logs liefern.
Wow, nicht schlecht. 211 der 335 erkannten Scans sind NEC-Frames. Womit
ich ja ganz gut mit meiner Meinung liege, dass NEC mittlerweile das am
häufigsten eingesetzte Protokoll ist.
> Ein kleines Problem hab ich noch entdeckt. Mit der Abtastrate 15k kann> ich z.B. das RECS80 nicht aktivieren. Setze ich 20k, mag der RC5 und> noch ein paar andere nicht.
Die einzelnen Protokolle arbeiten mit derart verschiedenen Timings, dass
es schwierig ist, sie alle unter einen Hut zu bekommen. Aus
Speicherplatzgründen verwende ich für die Timing-Messvariablen uint8_t.
Diese können bei 20kHz durchaus überlaufen. Daher ist 15kHz ein guter
Kompromiss. RECS80 bzw. RECS80EXT könnte mit 15kHz vielleicht auch
gerade noch laufen. Ich habe es selbst noch nicht getestet und habe bis
heute von niemandem(!) ein positives Feedback zu RECS80 erhalten.
Nimm am Ende von irmpconfig.h die entsprechenden Passagen, welche RECS80
und RECS80EXT bei unter 20kHz abschalten, einfach raus und teste das mit
15kHz. Wenns geht, werde ich die untere Schranke für RECS80 auf 15kHz
herabsetzen.
> Mir schwebt aber noch ein Universalprüfgerät vor, das einfach alle Codes> erkennt und dies auf dem LCD anzeigt. Mit dem IRMP brauchts dazu nur> noch ein paar Routinen für das LCD.
Wie Klaus Leidinger schon schrieb: so etwas gibt es bereits. Klaus hat
seinen IR-Tester auch im IRMP-Artikel unter "IRMP-Projekte" eingetragen.
Vielleicht tut Ihr Euch zusammen?
> Momentan haue ich die Daten nur über die Serielle raus. Mal sehen, ob> das mit den LCD Routinen noch in den ATMEGA 8 reinpasst.
ATMega8 ist obsolet, nimm den Nachfolger ATMega88 oder - noch besser -
den kompatiblen ATMega168. Damit kannst Du IRMP und IRSND zusammen in
einem µC unterbringen und musst Dir keine Sorge um den Speicher machen.
Gruß,
Frank
Frank M. schrieb:> Ja, diese 2 Tasten senden einen kürzeren IR60-Frame (5 statt 7 bit) aus.> Kannst Du damit leben, auf diese beiden Tasten zu verzichten? Sonst> müsste ich da noch eine etwas kompliziertere Sonderbehandlung> einbauen...
Hallo,
wer macht denn sowas? Steht da auch im Datenblatt was von dieser
komischen Art und Weise einfach kürzere Frames zu senden? Wegen mir wäre
eine Sonderbehandlung nicht nötig. Ich hab halt nur die eine FB die IR60
verwendet, deshalb kann ich nicht sagen, wie das bei anderen FB mit IR60
aussieht. Vielleicht hat ja noch jemand eine (Universal)FB mit IR60 und
könnte das mal testen.
Auch mit 20k und aktivierten RECS80 konnte ich meiner Universal FB da
nichts entlocken. Das ist das billige Teil vom Aldi MD6461.
Beim Scan mit der Universal FB sind aber noch ein paar Codes nicht
erkannt worden. Hast du da schon mal einen Blick darauf geworfen? Wenn
du da noch was brauchst, kann ich da noch ein paar Scans machen und ggf.
den Hersteller der den Code verwendet rausfinden.
Ich nehme eine ATMEGA8 her, weil ich da noch welche habe. :-)
Alternativ hätte ich noch ATMEGA48 (Speicher zu klein) oder dann die
16/32/644 noch.
Für ein einzelnes Protokoll müsste es doch auf einen ATTiny2313 zu
kriegen sein. Da wären aber einigen Anpassungen nötig, ob das dann sich
rentiert.
Fred
Fred schrieb:> wer macht denn sowas? Steht da auch im Datenblatt was von dieser> komischen Art und Weise einfach kürzere Frames zu senden?
Keine Ahnung, kann man aber schön sehen, wenn man sich eine Zeile aus
Deiner missing-Datei in den Editor lädt und dann noch irgendeine aus
Deiner irc15k.txt reinholt. Die missing-Zeilen sind kürzer als alle aus
der irc15k.txt.
> Auch mit 20k und aktivierten RECS80 konnte ich meiner Universal FB da> nichts entlocken. Das ist das billige Teil vom Aldi MD6461.
Ich habe mir die Scans aus der universal-Datei angeschaut. Insgesamt
9mal erkennt IRMP zunächst RECS80 am Startbit, scheitert dann aber an
der Framelänge. Diese sind 6, 7 oder meist 9 Bit lang. IRMP erwartet
aber immer eine Länge von 11 Bits.
Entweder ist die Doku unter
http://www.sbprojects.com/knowledge/ir/recs80.htm
(nach der ich vorgegangen bin) falsch oder es gibt weitere
RECS80-Abarten. Jedenfalls passen die Timings der Startbits und auch der
Datenbits perfekt - es scheitert aber immer an der Framelänge.
> Beim Scan mit der Universal FB sind aber noch ein paar Codes nicht> erkannt worden. Hast du da schon mal einen Blick darauf geworfen?
Ja, siehe oben. Ich werde sie mir auch noch detaillierter anschauen.
IRMP nimmt auch oft RUWIDO an, weil die Startbits passen, scheitert dann
aber später an den Längen der Datenbits, die zu RUWIDO überhaupt nicht
passen. Was das genau ist, kann ich jetzt noch nicht sagen.
> Wenn> du da noch was brauchst, kann ich da noch ein paar Scans machen und ggf.> den Hersteller der den Code verwendet rausfinden.
Ja, darauf komme ich gern nochmal zurück.
> Ich nehme eine ATMEGA8 her, weil ich da noch welche habe. :-)
Okay.
> Für ein einzelnes Protokoll müsste es doch auf einen ATTiny2313 zu> kriegen sein.
Das wird zu knapp - jedenfalls in Verbindung mit einem LCD. Und nur ein
IR-Protokoll ist langweilig ;-)
Gruß,
Frank
Frank M. schrieb:> Ich habe mir die Scans aus der universal-Datei angeschaut. Insgesamt> 9mal erkennt IRMP zunächst RECS80 am Startbit, scheitert dann aber an> der Framelänge. Diese sind 6, 7 oder meist 9 Bit lang. IRMP erwartet> aber immer eine Länge von 11 Bits.
Das Problem habe ich klären können. Ich habe mich damals, als ich das
RECS80-Protokoll in den IRMP eingebaut habe, verzählt. RECS80 hat nur 1
Start-Bit, nicht 2. Das gibt es nur beim RECS80EXT-Protokoll.
Ich habe das im IRMP korrigiert und schon konnte IRMP die RECS80-Frames
von der Universal-Fernbedienung auch lesen. Dass es im Scan von Fred
auch kürzere RECS80-Frames gab, lag einfach daran, dass nach 3 Frames
innerhalb einer Textzeile der Log-Buffer voll war.
Damit sollte das immerwährende Rätsel, ob IRMP überhaupt RECS80
versteht, endlich gelöst sein:
Es geht erst ab Version 1.9.6, habe ich ins SVN eingecheckt :-)
Ausserdem klappt es bestens bei 15kHz, ich habe daher die untere
Scanfrequenz für RECS80 auf 15kHz (statt 20kHz) korrigiert.
Damit sollten nun alle von IRMP unterstützten IR-Protokolle bei 15kHz
prima gelesen werden.
Gruß,
Frank
Sorry, dass ich schon wieder nerven muss.
Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
1
if(irmp_get_data(&irmp_data))
2
{
3
itoa(irmp_data.protocol,protocol,10);
4
itoa(irmp_data.address,address,16);
5
itoa(irmp_data.command,command,16);
6
7
lcd_string(protocol);
8
lcd_string(address);
9
lcd_string(command);
10
}
Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD
funktioniert, daran liegt es nicht).
Am "Outpin" des IR Receivers kann ich mit meinem Multimeter
unterschiedliche Frequenzen messen, wenn ich Knöpfe einer FB drücke,
aber wie gesagt, es kommt nichts an oder wird nichts ausgegeben.
Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01
Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms
PB6 ist der "Eingangspin".
Bastian F. schrieb:> Ich habe jetzt, hier aus dem Thread übernommen, folgendes in main:
1
>if(irmp_get_data(&irmp_data))
2
>{
3
>itoa(irmp_data.protocol,protocol,10);
4
>itoa(irmp_data.address,address,16);
5
>itoa(irmp_data.command,command,16);
6
>
7
>lcd_string(protocol);
8
>lcd_string(address);
9
>lcd_string(command);
10
>}
Wie ist bei Dir protocol, address und command definiert? Bitte zeige die
ganze main-Funktion.
> Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD> funktioniert, daran liegt es nicht).
Wenn Du in den if-Block ein
lcd_string("Hallo");
einbaust, erscheint das dann auf dem LCD, wenn Du eine FB-Taste drückst?
Welche FBs hast Du ausprobiert?
> Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01> Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms
Sieht okay aus.
> PB6 ist der "Eingangspin".
Zeige bitte die entsprechende Stelle in irmpconfig.h. Am besten hängst
Du diese hier mal an, damit man sieht, was Du alles so eingestellt hast.
Gruß,
Frank
Frank M. schrieb:> Wie ist bei Dir protocol, address und command definiert? Bitte zeige die> ganze main-Funktion.
1
main(void)
2
{
3
charprotocol[10];
4
charaddress[10];
5
charcommand[10];
6
7
IRMP_DATAirmp_data;
8
lcd_init();
9
irmp_init();// initialize rc5
10
timer_init();// initialize timer
11
sei();// enable interrupts
12
13
for(;;)
14
{
15
16
if(irmp_get_data(&irmp_data))
17
{
18
itoa(irmp_data.protocol,protocol,10);
19
itoa(irmp_data.address,address,16);
20
itoa(irmp_data.command,command,16);
21
22
lcd_string(protocol);
23
lcd_string(address);
24
lcd_string(command);
25
}
26
}
27
}
>>> Nur leider kommt auf dem LCD nichts an (die Ansteuerung des LCD>> funktioniert, daran liegt es nicht).>> Wenn Du in den if-Block ein>> lcd_string("Hallo");>> einbaust, erscheint das dann auf dem LCD, wenn Du eine FB-Taste drückst?
Nein, hatte ich auch schon getestet, nur vergessen zu erwähnen.
Sieht nach falscher Verkabelung aus, oder?
> Welche FBs hast Du ausprobiert?
Kathrein, Samsung, Grundig, Pioneer, Philips
>> Atmega88, Fuses (direct hex values) low: E2, high: DC, ext.: 01>> Int. RC Osc. 8MHz; Start-up time PWRDWN/RESET : 6 CK/14 CK + 65 ms>> Sieht okay aus.
Wenigstens etwas ;)
>> PB6 ist der "Eingangspin".>> Zeige bitte die entsprechende Stelle in irmpconfig.h. Am besten hängst> Du diese hier mal an, damit man sieht, was Du alles so eingestellt hast.
s.o.
Bastian F. schrieb:> Nein, hatte ich auch schon getestet, nur vergessen zu erwähnen.> Sieht nach falscher Verkabelung aus, oder?
Kann man so nicht sagen, wenn IRMP nichts erkennt, wird auch das "Hallo"
nicht ausgegeben. Du könntest natürlich, um sicher zu gehen, ein
lcd_print ("Start"); mal vor die while-Schleife setzen. Wenn das
kommt, ist das LCD schon mal kein Problem.
Bleibt dann IRMP...
>> Welche FBs hast Du ausprobiert?> Kathrein, Samsung, Grundig, Pioneer, Philips
Komisch... Zumindest die Samsung sollte mit den Standard-Einstellungen
gehen. Hast Du sonst nix japanisches dabei? ;-)
Aktiviere bitte zusätzlich in irmpconfig.h:
IRMP_SUPPORT_RC6_PROTOCOL (wegen deiner Kathrein FB)
IRMP_SUPPORT_RUWIDO_PROTOCOL (nur mal so)
IRMP_SUPPORT_GRUNDIG_PROTOCOL (wegen Grundig)
IRMP_SUPPORT_NOKIA_PROTOCOL (auch wegen Grundig)
Keine Ahnung, was Pioneer so benutzt.
Sonst sieht die irmpconfig.h ganz gut aus.
EDIT: Welche IRMP-Version benutzt Du?
Gruß,
Frank
Wie gesagt, das LCD bzw dessen Ansteuerung funktioniert.
Ich meinte auch eher den IR Receiver, obwohl man da ja eigentlich nicht
vie falsch machen kann. Zumal ich ich ja auch was am Ausgang messen
kann.
(Aber sicherheitshalber mal die Belegung (TSOP1838, Datenblatt im
Anhang. Vcc/Gnd ist wie vorgeschrieben mit Widerstand und Kondensator
beschaltet):
Von vorne gesehen:
Links: Out
Mitte: Gnd
Rechts: Vcc)
Ne, komischerweise nichts japanisches im Haushalt vorhanden.
Habe die von dir erwähnten Protokolle aktiviert, aber keine Änderung.
Ich weiß nicht welche ich vorher hatte, jedenfalls funktioniert es mit
der aktuellsten auch nicht - grade getestet.
Bastian F. schrieb:> Habe die von dir erwähnten Protokolle aktiviert, aber keine Änderung.
Ich habe keine Idee mehr, Du benutzt das AVR-Studio und F_CPU steht auf
8 MHz?
Gruß,
Frank
Sehr seltsam.
Habe mal auf PB4 gewechselt und siehe da, es funktioniert...
Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port
verbinde leuchten die LED je nach Tastendruck unterschiedlich aus,
obwohl nichts davon im Code steht.
Wie kann man dies erklären?
Wie irgendwann oben erwähnt, läuft das ganze auf/mit einem STK500.
Bastian F. schrieb:> Habe mal auf PB4 gewechselt und siehe da, es funktioniert...
Gratuliere! :-)
Ich kenne das STK500 nicht, aber kannn es sein, dass an PB6 ein Quarz
hängt?
> Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port> verbinde leuchten die LED je nach Tastendruck unterschiedlich aus,> obwohl nichts davon im Code steht.
Was ist DDRC?
> Wie kann man dies erklären?
Keine Ahnung, was da auf dem STK500 verdrahtet ist.
Werden nun alle FBs erkannt?
Gruß,
Frank
Version 1.9.8 ist nun im SVN, zwei neue Protokolle zum Testen sind
hinzugekommen:
1. NETBOX: Infrarot-Tastatur für die Netbox, erhältlich bei Pollin unter
der Bestellnr. 711 009 für 1 EUR :-)
Die Netbox-Tastatur wird momentan aber nur erkannt, wenn man das
RC6-Protokoll in IRMP abschaltet. Da muss ich noch was dran tun...
2. NEC16: Eine Abart des Standard-NEC-Protokolls (32 bit), welches nur
16 Bit sendet. Dieses habe ich aus den Universal-FB-Scans von Fred
extrahiert und in den IRMP eingebaut.
Sobald die Netbox-Tastatur rundläuft, werde ich auch ein neues Release
im Download-Bereich des IRMP-Artikels zur Verfügung stellen.
Gruß,
Frank
Hallo,
ich hab nun gleich die neuen Version geholt. Die LCD Routinen sind nun
auch
eingebunden und die Ausgabe funktioniert. Der Flash in nun zu 90%
gefüllt, mal sehen, was da noch für Protokolle reingehen :-)
Im Anhang der Scan wieder mit meiner Universal FB. Es werden schon
einige
mehr erkannt.
Fred
Frank M. schrieb:> Bastian F. schrieb:>>> Habe mal auf PB4 gewechselt und siehe da, es funktioniert...>> Gratuliere! :-)
Danke, nur verstehen tue ich es nicht.
Egal, läuft ja erstmal ;-)
> Ich kenne das STK500 nicht, aber kannn es sein, dass an PB6 ein Quarz> hängt?>>> Was aber zudem sehr komisch ist, dass wenn ich DDRC mit dem LED Port>> verbinde leuchten die LED je nach Tastendruck unterschiedlich aus,>> obwohl nichts davon im Code steht.>> Was ist DDRC?
Die "PCx Reihe".
>> Wie kann man dies erklären?>> Keine Ahnung, was da auf dem STK500 verdrahtet ist.
Erst nachdenken, dann doofe Fragen stellen...
An PORTC hängt auch das Display :-|
> Werden nun alle FBs erkannt?
Alle bis auf die Pioneer.
Da reagiert alles sehr "träge" und es werden nicht alles Tastendrücke
erkannt.
Hallo Uwe,
neue Probleme mit den letzten Änderungen im SVN:
irmp.c: In function 'irmp_rx_process':
hardware/ir/irmp/irmp_lib.c:2712: warning: conversion to 'uint8_t' from
'int' may alter its value
irmp.c:2727: warning: conversion to 'PAUSE_LEN' from 'int' may alter its
value
irmp.c:2911: error: 'irmp_tmp_id' undeclared (first use in this
function)
irmp.c:2911: error: (Each undeclared identifier is reported only once
irmp.c:2911: error: for each function it appears in.)
Die Zeilennummer können abweichen, da ich für ethersex noch ein paar
Anpassungen einfügen musste.
Hi eku,
eku schrieb:> Hallo Uwe,
Wer ist Uwe? ;-)
> irmp.c: In function 'irmp_rx_process':> hardware/ir/irmp/irmp_lib.c:2712: warning: conversion to 'uint8_t' from> 'int' may alter its value
irmp_rx_process() kenne ich nicht - nicht von mir ;-)
> irmp.c:2727: warning: conversion to 'PAUSE_LEN' from 'int' may alter its> value> irmp.c:2911: error: 'irmp_tmp_id' undeclared (first use in this> function)> irmp.c:2911: error: (Each undeclared identifier is reported only once> irmp.c:2911: error: for each function it appears in.)>> Die Zeilennummer können abweichen, da ich für ethersex noch ein paar> Anpassungen einfügen musste.
Da müsstest Du mir dann schon die Stellen im Source zeigen... und auch
die dazugehörige irmpconfig.h. Bei mir compiliert das einwandfrei durch.
Gruß,
Frank
Hallo Frank,
ich habe Probleme mit dem RC5-Code von IRSND. Eine DVD-Player-FB sendet
nachweislich RC5, die von IRMP auch erkannt wird (rc5_org). Ich habe
eine Universal-FB damit angelernt (rc5_uni). Mit beiden kann ich den
DVD-Player steuern. Nutze ich allerdings IRSND gibt es sowohl beim
Anlernen durch die Universal-FB (statt zu lernen wird ein Fehler
gemeldet) als auch bei der Bedienung des DVD-Players Probleme nicht
erkannter Codes.
Kann es an Toleranzen des Timings liegen oder ist der RC5-Code in IRSND
fehlerhaft? Was kann ich tun um Dir die nötigen Diagnosedaten zu
liefern?
Gruß, eku
eku schrieb:> die Variable irmp_tmp_id ist nur für Samsung deklariert, wird aber auch> von Kathrein benutzt.
Schmeiss sie einfach im Kathrein-Code raus. Sie wird dort gesetzt, aber
nicht weiter genutzt. Korrektur werde ich demnächst einchecken.
Gruß,
Frank
eku schrieb:> Kann es an Toleranzen des Timings liegen oder ist der RC5-Code in IRSND> fehlerhaft? Was kann ich tun um Dir die nötigen Diagnosedaten zu> liefern?
IRSND erzeugt unter Linux auf stdout IRMP-Scans. Ich habe mal dieselben
Codes vom IRSND erzeugen lassen. Dann habe ich die Zeichenfolgen von
rc5_org und die von IRSND erzeugten im Editor zeilenweise untereinander
betrachtet. Die Puls-/Pausenfolgen sind identisch - wenn man mal von dem
Toggle-Bit absieht, was man bei IRSND unter Linux nicht testen kann,
weil man da nur einen Frame pro Kommando-Aufruf "senden" kann.
Die von IRSND erzeugten Pulse sind etwas kürzer als die von rs5_org. Die
Puls-/Pausenzeiten sind bei rc5_org ca. 950 µs, die vom IRSND erzeugten
liegen bei 866µs, was etwas näher am dokumentieren Ideal von 889µs
liegt.
Gruß,
Frank
Hallo,
ich hab mal den Scan mit der Universal FB mit den Ausgaben zu verbinden.
Leider klappt das nicht ganz so gut. Wäre das nicht mal noch ne Idee,
das in die Logfunktion zu integrieren? Es würde ja der erkannte
Hersteller genügen.
Also in der Richtung:
#0x11 (wenn z.B. der Siemens Code erkannt wurde)
111100000111110011110000111
# (wenn nicht)
000011111111100000000111111
So wirds vielleicht lesbarer und die anderen Tools dürften damit kein
Problem haben.
Fred
Fred schrieb:> Leider klappt das nicht ganz so gut. Wäre das nicht mal noch ne Idee,> das in die Logfunktion zu integrieren? Es würde ja der erkannte> Hersteller genügen.
Das wird schwierig. Die Log-Funktion arbeitet aus dem Interrupt heraus.
Wann diese ihren Buffer flusht, ist nicht vorhersagbar, läuft daher
asynchron zur Frame-Erkennung. Die Erkennung vor(!) der Ausgabe der
Einsen/Nullen rauszublasen, ist dann fast unmöglich.
Ich schau mal, was ich machen kann.
Gruß,
Frank
Hallo,
war nur mal so eine Idee.
Ich hab mal meine main.c so umgebaut, das "Zeitmarken" in die Log
geschrieben werden. Wenn ich nun den Scan der Universal-FB laufen lasse,
sehe ich anhand der Marken, welche Codes erkannt wurden und welche
nicht. Hast du noch ein paar Codes entdeckt, die sich lohnen würden
näher zu betrachten?
Mal noch so eine nette Idee: Da ich die beiden Pollinboards verwende und
sich darauf ein NF-Verstärker befindet, hab ich mal einen Lautsprecher
angeschlossen und den Eingang mit dem TSOP verbunden. Ich kann jetzt
schon ein paar Codes am Klang erkennen :-)
Fred
Hi Fred,
Telekom schrieb:> Ich hab mal meine main.c so umgebaut, das "Zeitmarken" in die Log> geschrieben werden. Wenn ich nun den Scan der Universal-FB laufen lasse,> sehe ich anhand der Marken, welche Codes erkannt wurden und welche> nicht.
Interessant, die Änderungen kannst Du mir ja mal zeigen.
> Hast du noch ein paar Codes entdeckt, die sich lohnen würden> näher zu betrachten?
Ja, soviel "anderes" als das, was IRMP nicht schon kennt, ist da gar
nicht mehr drin. Ich hab das mal statistisch analysiert. IRMP erkennt
über 80 Prozent. Neben dem NEC16-Protokoll, was ich ja noch eingebaut
habe, kommen da sehr oft Frames vor, die dem NEC-Timing entsprechen,
aber 40 statt 32 Bit haben. Wenn ich das auch einbauen würde, wären wir
bei über 90 Prozent. Aber bisher hat mir noch keiner sowas mal gezeigt,
daher weiß ich nicht, ob der Aufwand sich lohnt, ein NEC40-Protokoll in
den IRMP zu integrieren... Ausserdem müsste ich da überlegen, wie ich
die 40 Bit in eine 16-Bit-Adresse und ein 16-Bit-Kommando zerlege.
Vermutlich wird Redundanz drin sein, die man rausoptimieren kann, um das
in 16+16 Bit reinzuquetschen. Aber ob die paar NEC40-Frames ausreichen?
Da bräuchte ich schon systematische Scans der Tasten 0-9, besser noch
mehr. Alternativ wäre natürlich ein Link auf eine passende Doku
hilfreich.
> Mal noch so eine nette Idee: Da ich die beiden Pollinboards verwende und> sich darauf ein NF-Verstärker befindet, hab ich mal einen Lautsprecher> angeschlossen und den Eingang mit dem TSOP verbunden. Ich kann jetzt> schon ein paar Codes am Klang erkennen :-)lach Sehr nette Idee! :-)
Gruß,
Frank
Hallöchen zusammen,
da ich ARM MCUs einsetze, musste ich ein wenig am IRMP drehen, damit er
anwendbar wird. Meine Änderungen sind nicht gravierend und sicher nicht
optimal, aber funktionieren. Da sie auch für andere interessant sein
könnten, poste ich sie hier.
Im Wesentlichen habe ich das define IRMP_FLEXIBLE_VERSION hinzugefuegt
und die Funktion für die ISR so angepasst, dass sie nun einen
übergebenen Wert verarbeitet. Somit ist man von der Zielarchitektur
relativ unabhängig und übergibt lediglich den Pinstatus.
Vielen Dank an alle Entwickler des IRMP!
Liebe Grüße,
Jan
Jan Berg schrieb:> da ich ARM MCUs einsetze, musste ich ein wenig am IRMP drehen, damit er> anwendbar wird. Meine Änderungen sind nicht gravierend und sicher nicht> optimal, aber funktionieren. Da sie auch für andere interessant sein> könnten, poste ich sie hier.
Erstmal danke für die Änderungsvorschläge. Ich werde sie in ähnlicher
Form übernehmen. Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas
unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder
etwas ähnliches in der Art. Ich muss mal drüber nachdenken.
Gruß,
Frank
ich würde gerne den Timer1 zu Timer 0 tauschen, sehe ich das richtig das
im Prinzip nur um die 15000 Interrupts nötig sind ? deswegen einen 16
Bit Timer nehmen müsste nicht sein ?
wenn ich das soweit überblicke könnte ich auch meine HW mit dani code
ersetzen, Timer0 -> 8 MHz CPU Vorteiler 256 -> Timer compare auf -2 gibt
overflow nach 512 Takte = 64 µs das sind genau 15625 Interrupts pro
Sekunde und damit in die IRMP-ISR, dann müsste der Timer 1 wieder völlig
frei sein, oder hab ich was übersehen ?
danke
jar schrieb:> ich würde gerne den Timer1 zu Timer 0 tauschen, sehe ich das richtig das> im Prinzip nur um die 15000 Interrupts nötig sind ?
Richtig. Es müssen auch nicht exakt 15000 Interrupts/sec sein. Aber Du
solltest den exakten Wert für F_INTERRUPTS angeben.
> deswegen einen 16 Bit Timer nehmen müsste nicht sein ?
Nein, muss nicht sein.
> wenn ich das soweit überblicke könnte ich auch meine HW mit dani code> ersetzen, Timer0 -> 8 MHz CPU Vorteiler 256 -> Timer compare auf -2 gibt> overflow nach 512 Takte = 64 µs das sind genau 15625 Interrupts pro> Sekunde und damit in die IRMP-ISR, dann müsste der Timer 1 wieder völlig> frei sein, oder hab ich was übersehen ?
Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann
baue ich das als Alternative zum 16-Bit-Timer ein.
Gruß,
Frank
Frank M. schrieb:> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann>> baue ich das als Alternative zum 16-Bit-Timer ein.
OK ich versuchs mal, danke spart mir ne Menge reverse engeniering
mit Dani Code meinte ich:
Beitrag "Fernbedien RC5 Empfänger"
Hallo Frank,
Frank M. schrieb:> Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas> unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder> etwas ähnliches in der Art. Ich muss mal drüber nachdenken.
Da gibt doch schon was im Code: IRMP_USE_AS_LIB
Im IRMP-Port nach ethersex habe ich die Port- und Timerprogrammierung
herausgezogen:
https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp
Hi eku,
eku schrieb:>> Die Namensgebung IRMP_FLEXIBLE_VERSION finde ich etwas>> unglücklich gewählt. Eine Alternative wäre IRMP_GENERIC_INTERFACE oder>> etwas ähnliches in der Art. Ich muss mal drüber nachdenken.>> Da gibt doch schon was im Code: IRMP_USE_AS_LIB
Das ist was ganz anderes! Hier geht es darum, den Source per Include zu
laden, um ihn in ein eigenes Projekt einzubinden. Aber nicht zum Linken,
sondern At-Compile-Time. Vielleicht werde ich das Vorgehen dazu mal im
IRMP-Artikel dokumentieren. Bis dato nutze nur ich selbst dieses
Feature.
> Im IRMP-Port nach ethersex habe ich die Port- und Timerprogrammierung> herausgezogen:> https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp
Danke, schaue ich mir an.
Sicherlich kann man den IRMP-Source allgemeiner halten und das
µC-spezifische komplett raushalten. Für Linux und Windows wird das ja
schon gemacht. Den Zustand des IR-Empfängers als Argument an das
IRMP-Working-Horse zu übergeben ist ja keine schlechte Idee von Jan
Berg. Nur kostet so eine Argumentübergabe etwas Zeit (Parameterübergabe
über Stack) und die wollte ich vermeiden. Das hört sich zwar wegen der
ziemlich großen Codelänge der ISR jetzt paradox an, ist aber angesichts
der sehr geringen Durchlaufzeit der Interrupt-Routine als State-Machine
trotzdem sinnvoll. Die ISR verbrät eigentlich nur in dem (kurzen) Moment
Zeit, wenn sie das zugehörige Protokoll zum erkannten Startbit sucht.
Ich muss mal drüber nachdenken.
Gruß,
Frank
Frank M. schrieb:> Sollte gehen. Wenns läuft, schick mir bitte Deine Code-Änderungen. Dann> baue ich das als Alternative zum 16-Bit-Timer ein.
so nun läufts endlich,
1
// wo auch immer
2
voidtimer0_init(void)
3
{
4
TCCR0B=1<<CS02;//divide by 256
5
TCNT0=-2;// 2 * 256 = 512 cycle bei 8 MHz
6
TIMSK0=1<<TOIE0;//enable timer interrupt
7
}
8
9
// in IRMP.C
10
SIGNAL(SIG_OVERFLOW0)
11
{
12
TCNT0=-2;
13
irmp_ISR();
14
}
15
16
//---------------- ab hier nur kalk-hilfe
17
18
19
20
21
/* kleine kalk-Hilfe in qbasic, wer mag kanns auch in C umschreiben
Hallo,
hat schonmal jemand die Pollin Infrarot-Tastatur RUWIDO MERLIN mit
Nummer 711 057 zum Laufen bekommen ?
Bislang habe ich hier nur die BestNr. gesehen, sonst aber noch nichts.
Das ist eine sehr schöne kleine Tastatur !!
Mit der Version 1.9.0 aus der SVN wird jedenfalls nichts erkannt. Ich
könnte mal die Tasten Scannen, wenn das bisher noch keiner versucht hat
?!
Gruß
Torsten
Torsten Kalbe schrieb:> hat schonmal jemand die Pollin Infrarot-Tastatur RUWIDO MERLIN mit> Nummer 711 057 zum Laufen bekommen ?
Witzig, die habe ich mir vor 2 Wochen bestellt. Habe ich mittlerweile
auch hier, bisher hatte ich aber noch keine Zeit gehabt, IRMP daran
anzupassen.
Werde ich in den nächsten Tagen mal testen, denn das ist wirklich eine
schöne kleine Tastatur.
Wenn IRMP damit funktioniert, melde ich mich wieder.
Hallo zusammen,
bin gerade erst auf diese IR-Lib gestossen, echt tolle arbeit! Werde sie
sicher in dem ein oder anderen Projekt verwenden.
Hab auch gleich einen Wunsch: Das Protokoll der LEGO Powerfunctions.
Lego hat sogar ein Dokument dazu veröffentlicht (hängt an).
Wäre es möglich dieses Protokoll hinzuzufügen?
Danke und Gruß
Dominique Görsch
Dominique Görsch schrieb:> Hab auch gleich einen Wunsch: Das Protokoll der LEGO Powerfunctions.> Lego hat sogar ein Dokument dazu veröffentlicht (hängt an).>> Wäre es möglich dieses Protokoll hinzuzufügen?
Das Protokoll ist offenbar ein Pulse-Distance-Protokoll mit 16 Bit,
wobei nur 12 Bit Nutzdaten vorhanden sind.
Es sieht ganz einfach aus. Willst Du das nur decodieren oder auch
senden?
Die eigentlichen Inhalte wird IRMP nicht weiter interpretieren, sondern
Dir einfach die 12 Bit liefern.
Ich bau das mal in den nächsten Tagen ein.
Gruß,
Frank
Sowohl als auch wäre genial. Ich plane zum einen eigene Receiver die
dann mit der LEGO Fernbedienung steuerbar sind, zum anderen aber auch
das automatische Steuern zB von Zügen.
Super, dass du es gleich implementieren willst. Reichen dir die Infos
aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?
Thread beobachten
Seitenaufteilung abschalten