Aktualisierung
Die IRMP-Software kann unter IRMP --> Download
heruntergeladen werden.
Hallo zusammen,
Anmerkung:
Dieser Source entstand im Rahmen des Projektes "WordClock", siehe
Artikel
http://www.mikrocontroller.net/articles/Word_Clock
bzw. Thread, der alles zum Auslösen gebracht hat:
http://www.mikrocontroller.net/topic/156661
Da RC5 nicht nur veraltet, sondern mittlerweile obsolet ist und immer
mehr die elektronischen Geräte der fernöstlichen Unterhaltungsindustrie
in unseren Haushalten Einzug finden, ist es an der Zeit, einen
IR-Decoder vorzustellen, der ca. 90% aller bei uns im täglichen Leben zu
findenden IR-Fernbedienungen "versteht".
IRMP - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf
einmal decodieren kann, beherrscht folgende Protokolle:
SIRCS: Sony.
NEC: NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC,
Pioneer, Toshiba, Xoro, Orion, NoName
und viele weitere japanische Hersteller.
SAMSUNG: Samsung
MATSUSHITA: Matsushita
KASEIKYO: Panasonic, Denon und andere japanische Hersteller, welche
Mitglied
der "Japan's Association for Electric Home Application"
sind.
RECS80 Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
Zum Source-Code
irmp.c:
Zu Anfang werden die verschiedenen Signalformen und -Zeiten
dokumentiert. Ein Blick darauf zum Verständnis ist bestimmt ganz
interessant :-)
IRMP decodiert sämtliche oben aufgelisteten Protokolle in einer ISR.
Möchte man davon einige aus Platzgründen deaktivieren, sind die
entsprechenden Werte in irmp.c
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // flag: support SIRCS,
1=yes, 0=no
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // flag: support NEC,
1=yes, 0=no
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // flag: support
Samsung, 1=yes, 0=no
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // flag: support
Matsushita, 1=yes, 0=no
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // flag: support
Kaseikyo, 1=yes, 0=no
#define IRMP_SUPPORT_RECS80_PROTOCOL 1 // flag: support RECS80,
1=yes, 0=no
auf 0 zu setzen. Dann wird der Decoder für diese Protokolle nicht
mitübersetzt.
Diese Protokolle weisen Bitlängen - teilweise variabel, teilweise fest -
von 12 bis 48 Bit auf. Diese werden über Preprocessor-Defines
beschrieben.
IRMP trennt diese IR-Telegramme prinzipiell in 3 Bereiche:
1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando
Mittels der Funktion
irmp_get_data (IRMP_DATA * irmp_data_p)
kann man ein decodiertes Telegramm abrufen. Der Return-Wert ist 1, wenn
ein Telegramm eingelesen wurde, sonst 0. Im ersten Fall werden die
Struct-Members
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
gefüllt, einen Beispiel-Aufruf nebst Erklärung findet man in main.c,
welches lediglich ein Grundgerüst darstellen soll.
Das "Working Horse" von IRMP ist die Interrupt Service Routine
irmp_ISR() welche 10.000 mal pro Sekunde aufgerufen werden sollte.
Weicht dieser Wert ab, muss die Preprocessor-Konstante F_INTERRUPTS
angepasst werden. Dieser kann durchaus höher werden, aber nicht
wesentlich kleiner. Sonst wird es kritisch mit der Protokoll-Erkennung.
irm_ISR detektiert zunächst die Länge und die Form des/der Startbits und
ermittelt daraus das verwendete Protokoll. Sobald das Protokoll erkannt
wurde, werden die weiter einzulesenden Bits parametrisiert, um dann
möglichst effektiv in den weiteren Aufrufen das komplette IR-Telegramm
einzulesen.
Um direkt Kritikern den Wind aus den Segeln zu nehmen:
Ich weiss, die ISR ist ziemlich groß. Aber da sie sich wie eine State
Machine verhält, ist der tatsächlich ausgeführte Code pro Durchlauf
relativ gering. Solange es "dunkel" ist (und das ist es ja die meiste
Zeit ;-)) ist die aufgewendete Zeit sogar verschwindend gering. Im
WordClock-Projekt werden mit ein- und demselben Timer 8 ISRs aufgerufen,
davon ist die irmp_ISR() nur eine unter vielen. Bei mindestens 8 MHz
CPU-Takt traten bisher keine Timining-Probleme auf. Daher sehe ich bei
der Länge von irmp_ISR überhaupt kein Problem.
Achja, ein Quarz ist nicht unbedingt notwendig, es funktioniert auch mit
dem internen Oszillator des AVRs, wenn man die Prescaler-Fuse
entsprechend gesetzt hat, dass die CPU auch mit 8MHz rennt ... Die
Fuse-Werte für einen ATMEGA88 findet man in main.c
Zur Hardware: IRMP sollte so ziemlich für alle ATMegas übersetzbar sein,
das Beispiel-Projekt wurde auf ATMEGA88 eingestellt.
Der Pin, an dem der IR-Empfänger angeschlossen wird, ist frei wählbar
und wird in irmp.c über
#define IRMP_PORT PORTB
#define IRMP_DDR DDRB
#define IRMP_PIN PINB
#define IRMP_BIT 6 // use PB6 as IR input
eingestellt.
Als letztes:
irmp.c lässt sich auch unter Linux direkt kompilieren, um damit
Infrarot-Scans, welche in Dateien gespeichert sind, direkt zu testen. Im
Unterordner IR-Data finden sich solche Dateien, die man dem IRMP direkt
zum "Fraß" vorwerfen kann, nämlich folgendermaßen:
cc irmp.c -o irmp # IRMP compilieren
./irmp.c < IR-Data/Samsung_DVD_Rec_00062C.txt # irmp ausführen
IRMP gibt dann das erkannte Protokoll und weitere Timing-Daten aus.
Diese Dateien haben mir bei der Entwicklung des IRMP enorm geholfen,
Dank an Vlad Tepesch, der diese Dateien mittels 10000Hz-ISR gescannt und
über UART protokolliert hat!
Achja: Der Decoder für das RECS80-Protokoll ist ungetestet und wurde
anhand von Dokumentationen im Internet erstellt und lediglich mittels
künstlich erzeugten Scan-Dateien getestet... daher: keine Gewähr!
Viel Spaß damit!
Frank M.
Sehr geil, ich werde mal schauen, ob ich es zum laufen bekomme. Ich habe
eine ähnliche Sache gebaut: Eine lernbare Fernbedienung.
Ich verwende jedoch keine 10000Hz Routine, die die Sachen einscannt,
sondern ich lege den IR Eingang auf den externen IRQ0 Pin und erkenne
das Ende des IR Codes mit dem ISR(TIMER1_OVF_vect). Die Hauptroutine hat
in dieserm Fall gar nichts mehr zu machen und kann sich auf etwas ganz
anderes konzentrieren, man spart sich die Preprozessor-Konstante:
int main(){
TCNT1 = 0; //Timer1 gestoppt lassen, bei 65ms Überlauf
IRQ0_aktivieren(); //INT0_vect wartet auf erste IR Signal flanke
while (etwas_empfangen){
empfangspuffer_auswerten();
ausgabe_auf_dem_lcd_display();
etwas_empfangen = 0;
}
}
ISR(INT0_vect){
empfangspuffer(position) = TCNT1; //gemessene Flankenlänge
// abspeichern
position++ //für die nächste Abspeicherung vorbereiten
TCNT1 = 0; //Timer auf 0 zur Messung der nächsten
//Flankenlänge
Timer1_aktivieren();
}
ISR(TIMER1_OVF_vect){ //IR Ende wenn 65ms keine Flankenänderung
Timer1_deaktivieren();
etwas_empangen = 1; //nun kann main es auswerten
empfangspuffer(position) = 60000 //IR Ende Markierung in den Puffer
// schreiben. Eindeutig, weil
//keine IR Flanke wäre 60ms lang
}
Der Empfangspuffer sieht dann so aus:
17382 //erste Messung ist müll, je nach dem wann erste IR Flanke kam
09000 //Start Bit 9000ms
00560 //erstes Pausensignal 560ms
00560 //erstes Datenbit
00560 //Pausensignal zum Datenbit
01200 //zweites Datenbit
00560 //Pausensignal zum Datenbit
.
.
.
60000 //Ende Markierung
Die Auswertung ist dann einfach, wie z.B. Du sie selbst geschrieben
hast. Ich selbst habe keine Auswerung geschrieben, sondern ich lege die
Daten in einem EEPROM ab und sende sie auf Befehl wieder raus:
int main(){
pin_ir = 0;
position ++ //erste Müllmessung im Puffer ignorieren
TCNT1 = empfangspuffer(position); //Timer1 füttern
position ++ //Puffer auf nächste Position
Timer1_aktivieren();
while (1); //keine weiteren Aktionen mehr,
// sendung erfolgt automatisch über IRQ
}
ISR(TIMER1_OVF_vect){
port_ir ^= (1<<pin_ir); //IR Ausgang einfach nur toggeln
TCNT1 = (65535-empfangspuffer(position)); //Timer neu füttern
if (empfangspuffer(position) == 60000) timer1_deaktivieren;
position++ //Puffer auf nächste Position
}
Hallo Frank!
In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?
Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und
das Ergebnis in eine FIFO legen. Eine Dekoderfunktion sammelt die Werte
aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin
liegt der Vorteil Deiner Implementierung?
eku schrieb:
> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und> das Ergebnis in eine FIFO legen.
Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans
Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben,
um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.
> Eine Dekoderfunktion sammelt die Werte> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin> liegt der Vorteil Deiner Implementierung?
Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen
Startbit wird das Protokoll sofort erkannt und dann werden die weiteren
Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die
ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in
denen alles nötige gespeichert ist - hier als struct definiert:
1
typedefstruct
2
{
3
uint8_tprotocol;// protocol, i.e. IRMP_NEC_PROTOCOL
4
uint16_taddress;// address
5
uint16_tcommand;// command
6
}IRMP_DATA;
Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei
Werte, die man über ein if oder switch checken kann, z.B. hier eine
Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:
Die Werte muss man natürlich für eine unbekannte Fernbedienung einmal
auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im
Programm hart zu kodieren. Oder man hat eine Anlernroutine, wo man
einmal die gewünschten Tasten drücken muss, um sie anschließend im
EEPROM abzuspeichern.
Einfacher gehts doch nicht, oder?
Gruß,
Frank
Hallo Frank,
wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.
Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code
nur 1x ausgewertet.
Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach
der wiederholung müsste man das kommando erneut auslösen.
Hallo Frank!
Frank M. schrieb:
> eku schrieb:>>> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?>>> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und>>> das Ergebnis in eine FIFO legen.>>>> Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans>> Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben,>> um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.>>>>> Eine Dekoderfunktion sammelt die Werte>>> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin>>> liegt der Vorteil Deiner Implementierung?>>>> Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen>> Startbit wird das Protokoll sofort erkannt und dann werden die weiteren>> Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die>> ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in>> denen alles nötige gespeichert ist
Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls
in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf
die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch
Variablen in der ISR initialisieren. Die einen Indirektion bei der
Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht
fallen. Der Code würde noch dazu leserlicher.
Sebastian___ schrieb:
> Hallo Frank,> wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.> Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code> nur 1x ausgewertet.
Der Code wird lediglich innerhalb einer gewissen Zeitspanne ignoriert,
nämlich innerhalb der Wiederholungszeitspanne.
> Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach> der wiederholung müsste man das kommando erneut auslösen.
Nein, soviel ich weiß, wird bei SIRCs nach den Wiederholungen dann das
Kommando erneut gesandt, wenn Du die Taste gedrückt hältst. Aber erst
nach einer gewissen Pause, die wesentlich größer ist als die Zeitspanne
zwischen 2 Wiederholungen. Und dann greift die ISR wieder zu.
Gruß,
Frank
eku schrieb:
> Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls> in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf> die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch> Variablen in der ISR initialisieren. [...]
Stimmt.
> [...] Die einen Indirektion bei der> Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht> fallen. Der Code würde noch dazu leserlicher.
Hm, ob ich da tatsächlich was einspare? Werde mir den Code diesbezüglich
demnächst nochmal anschauen.
Gruß,
Frank
Hallo Frank!
Frank M. schrieb:
> Nein, soviel ich weiß, wird bei SIRCs nach den Wiederholungen dann das>> Kommando erneut gesandt, wenn Du die Taste gedrückt hältst. Aber erst>> nach einer gewissen Pause, die wesentlich größer ist als die Zeitspanne>> zwischen 2 Wiederholungen. Und dann greift die ISR wieder zu.
Mir gefällt dieses Ping-Pong zwischen ISR und main() nicht. Die ISR
wartet mit der Erkennung bis main() vorheriges abgeholt hat. Eine
FIFO entkoppelt die Routinen.
eku schrieb:
> Mir gefällt dieses Ping-Pong zwischen ISR und main() nicht. Die ISR> wartet mit der Erkennung bis main() vorheriges abgeholt hat. Eine> FIFO entkoppelt die Routinen.
Die ISR wartet nicht (eine ISR sollte niemals warten), sie ignoriert
halt IR-Befehle, bis die main das letzte Kommando abgeholt hat.
Wenn der Mensch an der Fernbedienung schnell hintereinander 2 Tasten
drückt, dann willst Du das tatsächlich durch ein FIFO puffern? Zwischen
den beiden Tastendrücken vergeht für den µC eine Ewigkeit.... bis dahin
hat er die erste Taste längst abgearbeitet.
Bei einer RS232 halte ich ja ein FIFO für sinnvoll, aber für eine IR-FB?
Willst Du etwa mit einem IR-Sender Daten mit konstanter Geschwindigkeit
übermitteln? Ja, dann wäre das sinnvoll. Sonst nicht - für mich
jedenfalls.
Gruß,
Frank
bei SIRC ist es jeden fall so das man da nicht zwischen den Repeats
unterscheiden kann.
Taste kurz gedrückt = 3x command im 45ms Raster.
Taste länger gedrückt = nx command im 45ms Raster.
Ich habe mir das mal auf dem Oszi angeschaut. (ist ein Sony DVD Player)
Sebastian___ schrieb:
> bei SIRC ist es jeden fall so das man da nicht zwischen den Repeats> unterscheiden kann.> Taste kurz gedrückt = 3x command im 45ms Raster.> Taste länger gedrückt = nx command im 45ms Raster.
Hm, das ist wirklich blöd. Leider habe ich keine Sony-Fernbedienung, um
das zu testen, hatte da lediglich die Scans von Vlad Tepesch.
Ich habe da gerade nochmal in den Source geschaut:
Wenn also die Zeiten bei heruntergedrückter Taste tatsächlich nicht
größer sind als die Wiederholzeit, muss man wirklich erst die Taste
loslassen....
Dumm gelaufen. Man könnte natürlich bis 3 zählen und die vierte
Wiederholung wieder zulassen. Fragt sich nur, ob das definitiv immer so
ist, dass Sony-Fernbedienungen grundsätzlich jeden Code 3 mal
wiederholen.
Gruß,
Frank
um sowas zu testen und solche codes zu simulieren würde ich einen
simulator für AVRs benutzen - namentlich proteus isis.
gibt viele möglichkeiten, sich dort eine passende quelle
zusammenzubauen.
demo und info unter:
http://www.labcenter.co.uk/products/vsm_overview.cfm
frank, falls du das machen willst und ich dir helfen kann, schreib mich
doch kurz an.
holli
Michael M. schrieb:
> um sowas zu testen und solche codes zu simulieren würde ich einen> simulator für AVRs benutzen - namentlich proteus isis.
Ist erstmal eine gute Idee, aber der Code von irmp trägt den Simulator
in sich mit :-) Ich kann dem Code (wenn man ihn unter Linux übersetzt)
einfach eine Datei zum Fraß vorwerfen. Diese Datei kann ein echter Scan
einer Fernbedienung sein oder eine künstlich erzeugte.
Ein weiterer Simulator wäre daher kein Gewinn für mich - sehe ich
jedenfalls momentan so. Und er beantwortet mir auch nicht die Frage, ob
jede Sony-Fernbedienung den Code immer genau 3x wiederholt.
Trotzdem danke für den Tipp, vielleicht kann ich ihn bei Gelegenheit für
ein ganz anderes Projekt verwenden :-)
@Sebastian___
Ich werde einfach mal meine SIRCS-Scandatei nehmen, ein Telegramm
(sprich Zeile) ver-N-fachen mit dem Editor, wobei ich eine Pause von
45ms einbaue. Dann den Code dahingehend ändern, dass er die 4te, 7te,
10te (usw) Wiederholung wieder auswertet statt sie zu ignorieren.
Wäre Dir damit geholfen?
Gruß,
Frank
Ich habe mir gerade nochmal die gängigen Quellen angeschaut, wo SIRCS
als Code beschrieben wird. Nirgendwo steht da was von 2 weiteren
automatischen Wiederholungen (also 3 Telegramme), immer liest man nur
solches wie dieses:
"Commands are repeated every 45ms(measured from start to start) for as
long as the key on the remote control is held down."
Ich habe mir daraufhin nochmal die Scan-Datei Sony_Bravia_RM-ED0009.txt
näher angeschaut. Da sind die Wiederholungen auch drin, aber offenbar
nicht für alle Tasten wird wiederholt, z.B.
power, rot, gelb, grün, blau, up, down, left, right, vol+, vol-: keine
Wiederholung
theatre, digital, tools, buch(?): 2 Wiederholungen, also insg. 3
Telegramme
Rätselhaft das ganze...
Gruß,
Frank
Ich kann das ganze ja bei gelegenheit nochmal wiederholen.
vielleicht sind auch zu viele einsen zwischen den wiederholungen, so
dass meine Scan-Routine, den scan schon vorher abgebrochen hat.
ich hatte da 200 samples gewartet
wenn man sich die wiederholten scans aber anschaut, sieht man, dass die
wiederholungen nach 190 einsen kommen.
wenn das Kommando also am Ende ein paar einsen hat, dann wird die
Abrruchbedingung überschritten.
Pack doch den code zum Scannen nochmal mit rein, dann können die anderen
auch ein paar Scans machen.
Vlad Tepesch schrieb:
> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen> auch ein paar Scans machen.
Ich war einfach bisher zu faul, den Code fürs Scanning aus dem
WordClock-Code zu extrahieren, so dass er isoliert zur Verfügung
steht...
gebe ich ja zu :-)
Hole ich jetzt nach.
Es wäre klasse, wenn die anderen ihre Fernbedienungen, die bisher nicht
unterstützt werden, einscannen würden. Dann kann ich den Code diesbzgl.
erweitern.
Gruß,
Frank
Aktualisierung
Die IRMP-Software kann unter IRMP | Download
heruntergeladen werden.
Vlad Tepesch schrieb:
> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen> auch ein paar Scans machen.
Okay, ich habe nun die nötigen Routinen aus dem WordClock-Source
extrahiert und direkt mit in irmp.c integriert.
In der Zeile
1
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not (default)
kann nun das Logging eingeschaltet werden, wenn man den Wert auf 1
setzt.
Dann werden die Hell- und Dunkelphase auf dem UART mit 9600Bd
ausgegeben:
1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen
uart_init() und uart_putc() angepasst werden, kommt auf den verwendeten
AVR-µC an.
README.txt ist entsprechend angepasst - am Ende der Datei.
Getestet habe ich es allerdings noch nicht... sollte aber passen.
Gruß,
Frank
Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.
Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).
Somit kann das Polling entfallen und man hat eine Speichersparende
lösung.
Das ist aber nicht ganz so einfach. ;)
Sebastian___ schrieb:
> Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.
Verstehe ich jetzt nicht so recht. Das Ding läuft doch auf
Interrupt-Basis, nämlich einem Timer-Interrupt.
> Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).> Somit kann das Polling entfallen und man hat eine Speichersparende> lösung.
Warum ist das speichersparend?
Gruß,
Frank
ja eben,
das frisst rechenleistung wen man keinen timer irq damit blockieren
will.
Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen
der flankengesteuert reagiert. Und nur noch ab und zu mal im timer IRQ
auf timeout zu prüfen.
Sebastian___ schrieb:
> Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen> der flankengesteuert reagiert.
Ahso, flankengetriggert. Ich hatte da eben was von Zeitbasis gelesen...
deshalb hatte ich das nicht direkt kapiert. Aber klar, Du brauchst bei
jeder Flanke auch die dazugehörige Zeit.
Klingt ja ganz gut, bin gespannt.
Aber ich sehe da immer noch nicht die Speichereinsparung, ich lass mich
da von Dir überraschen ;-)
Gruß,
Frank
Speichereinsparung war drauf bezogen im Vergleich zu der hier geposteten
Interruptgesteuerten Routine die ja das komplette data Frame gesichert
hat und dann in der Main auswertet.
im prinzip geht deine Routine auch flankengetriggert, man muss nur ne
zeitbasis hinzufügen (aus timer) und für ne abbuchbedingung sorgen wenn
keine flanken mehr kommen.
Wenn ich soweit bin werde ich mal ein bischen was dazu posten.
Deine Defines der verschiedenen protokolle sind auf jeden fall sehr
hilfreich.
Hallo ich habe noch einen kleine Fehler gefunden, das
MATSUSHITA_PROTOCOL wird nie erkannt, nur das SAMSUNG_PROTOCOL.
die Defines für das erkennen der start Bits haben eine zu große
Toleranz, wenn man die für :
#define MATSUSHITA_START_BIT_PULSE_LEN_MIN
#define MATSUSHITA_START_BIT_PULSE_LEN_MAX
#define MATSUSHITA_START_BIT_PAUSE_LEN_MIN
#define MATSUSHITA_START_BIT_PAUSE_LEN_MAX
und
#define SAMSUNG_START_BIT_PULSE_LEN_MIN
#define SAMSUNG_START_BIT_PULSE_LEN_MAX
#define SAMSUNG_START_BIT_PAUSE_LEN_MIN
#define SAMSUNG_START_BIT_PAUSE_LEN_MAX
auf 20% setzt, geht die Protokollerkennung.
Sebastian___ schrieb:
> die Defines für das erkennen der start Bits haben eine zu große> Toleranz, wenn man die für :> [...] auf 20% setzt, geht die Protokollerkennung.
Super, danke für den Tipp! Werde ich anpassen.
Gruß,
Frank
Frank M. schrieb:
> Sebastian___ schrieb:>> die Defines für das erkennen der start Bits haben eine zu große>> Toleranz, wenn man die für :>> [...] auf 20% setzt, geht die Protokollerkennung.>> Super, danke für den Tipp! Werde ich anpassen.
Habe ich gerade mal gemacht und gegen die Scan-Datei
Samsung_DVD_Rec_00062C.txt laufen lassen: Bei 20% Toleranz für SAMSUNG
erkennt die Routine keine Samsung mehr. Selbst bei 40% klappt das nicht
mehr, erst bei 50% geht es. Das liegt wohl daran, dass Vlads Samsung-FB
stark von den Timingwerten abweicht... Die 50%, die ich da eingestellt
hatte, kamen nicht von ungefähr ;-)
Das heisst: Wir haben hier einen Konflikt, beide Startbits (von Samsung
und Matsushita) sind ähnlich lang - jedenfalls innerhalb der großzügigen
Toleranzen von 50%.
Wenn Du in der Zeile
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1
die 1 auf 0 setzt, sollte die Matsushita auch erkannt werden - ohne
Änderung der Toleranzen. Hat natürlich den Nachteil, dass immer nur eins
von beiden Protokollen gleichzeitig erkannt werden kann....
Es gibt einen großen Unterschied zwischen Samsung und Matsushita:
Die Anzahl der Bits pro Telegramm und das Sync-Bit mit sehr langer
Dunkelphase zwischendrin bei der Samsung, d.h. nach den ersten 16 Bit.
Damit kann man beide Protokolle definitiv auseinanderhalten.
Kannst Du mir so eine Scan-Datei für die Matsushita erstellen? Dann
würde ich die Unterscheidung anhand des Sync-Bits einbauen.
Gruß,
Frank
Das ist leider nicht so einfach mit den Daten schicken. Da ich nur
kleine Teile aus deinem Code nutze und die Codes auf einem Oszi anschaue
und mit einer Universalfernbedinung teste.
Sebastian___ schrieb:
> Das ist leider nicht so einfach mit den Daten schicken. Da ich nur> kleine Teile aus deinem Code nutze und die Codes auf einem Oszi anschaue> und mit einer Universalfernbedinung teste.
Auch gut, dann erstelle ich die Matsushita-Daten künstlich. Die
Timing-Daten zur Matsushita-FB kannst Du aber schon so bestätigen, oder?
Gruß,
Frank
Vlad Tepesch schrieb:
> hast du die Abbruchbedingung für die Scans ein wenig angehoben?> 200 scheint ja zu kurz zu sein.
Nein, habe ich nicht gemacht. Werde ich nachholen.
Gruß,
Frank
@Frank M. (ukw):
Ich fände es sehr hilfreich, wenn du den Code mit ein paar kleinen
Erläuterungen als Artikel hier mit reinstellst und am Besten im "Word
Clock" Artikel darauf verweist. Das ganze kann man ja schon als
eigenständig betrachten.
IR schrieb:
> Ich fände es sehr hilfreich, wenn du den Code mit ein paar kleinen> Erläuterungen als Artikel hier mit reinstellst und am Besten im "Word> Clock" Artikel darauf verweist. Das ganze kann man ja schon als> eigenständig betrachten.
Ich hatte den Code für die IR-Decodierung absichtlich isoliert und hier
reingestellt, damit er unabhängig vom WordClock-Projekt Verwendung
findet.
Gern lege ich einen Artikel an, hatte mir Vlad sowieso schon
vorgeschlagen ;-)
Mache ich am Wochenende.
Gruß,
Frank
Es gibt nun einen eigenen Artikel zu IRMP. Das hat auch den Vorteil,
dass die Software zum Download immer auf dem neuesten Stand ist und hier
der Leser nicht immer erst alle Beiträge lesen muss, um die letzte
Version zu finden.
Artikel-Link: http://www.mikrocontroller.net/articles/IRMP
Download: http://www.mikrocontroller.net/articles/IRMP#Download
Software-Stand: 05.02.2010
In dieser Version wurde auch der Konflikt zwischen dem Samsung- und dem
Matsushita-Protokoll ausgeräumt, beide Protokolle werden nun ohne
Klimmzüge zuverlässig erkannt.
@Vlad: Sorry, die Scan-Länge habe ich noch nicht vergrößert, hole ich
nach.
Gruß,
Frank
Hi!
Erstmal: danke für dieses schöne Stück code :)
Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir
bestellt habe ;)
Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib
meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für
meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte
rc5-protokoll auch von der IRMP-Lib erkannt wird?
Gruß, DiPi
p.s.: bisher habe ich diese rc5-routine benutzt:
Beitrag "Fernbedien RC5 Empfänger"
Di Pi schrieb:
> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir> bestellt habe ;)
Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche
FBs damit so laufen...
> Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib> meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für> meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte> rc5-protokoll auch von der IRMP-Lib erkannt wird?
RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,
sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir
nochmal ;-)
Gruß,
Frank
Frank M. schrieb:
> RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,> sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir> nochmal ;-)
So ziemlich alle FB bei mir laufen auf RC5. Gerade bei Universal-FBs ist
das noch weit verbreitet und sollte der Vollstädigkeit halber mit
eingebunden werden. Gerade einfache Projekte im µC Bereich nutzen of
noch RC5.
Frank M. schrieb:
>> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir>> bestellt habe ;)>> Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche> FBs damit so laufen...LED RGB REMOTE
http://www.reichelt.de/?;ARTICLE=92594
Frank M. schrieb:
> RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,> sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir> nochmal ;-)>
Stimmt schon, wenn man sich so umsieht bentutzen nur noch die "soliden
alten deutschen Marken" den RC5 Code. Auf der anderen Seite, ist er sehr
verbreitet gewesen und deswegen sind Massenhaft gebrauchte RC5 im
Umlauf, die noch gut weiter verwendet werden könnten. Das spricht für
RC5.
Ist aber auch so ein Super "gemeinnütziges Projekt".
GrußWilli
Ich meinte genau die Remote, die Michael M. genannt hat.
Es wäre eine schöne sache, wenn neben den sechs bereits implementierten
Protokollen auch noch RC5 vertreten wäre (genauso ein- und
ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit
einer Lib abzudecken.
Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden
sollen.
Viele Grüße, DiPi
ich vermute übrigens, die RGB FB sendet NEC-code.
hier mal ein csv-file und bild mit einem scan der off-taste. sample rate
50kHz.
T->A: 9,14ms
A->B: 4,42ms
B->C: 660us
Michael M. schrieb:
> ich vermute übrigens, die RGB FB sendet NEC-code.> hier mal ein csv-file und bild mit einem scan der off-taste. sample rate> 50kHz.> T->A: 9,14ms> A->B: 4,42ms> B->C: 660us
Ja, das ist das NEC-Protokoll.
Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel
dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte
:-)
Gruß,
Frank
Frank M. schrieb:
> Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel> dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte> :-)
klar, gerne!
Michael M. schrieb:
> Frank M. schrieb:>> Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel>> dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte>> :-)> klar, gerne!
Danke, ist eingebaut:
http://www.mikrocontroller.net/articles/IRMP#Protokolle
Gruß,
Frank
Michael M. schrieb:
> ui, da hat es aber eine prominente position bekommen =)
Ich wollte ein wenig Farbe in den Artikel bekommen ;-)
Aber das Bild ist zweimal drin, weiter unten nochmal miniaturisiert
unter Angabe Deiner gemessenen Zeiten.
Gruß,
Frank
da fällt mir grade was auf:
in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt
vorgeschlagene RC tiefpass falsch aufgebaut.
der aufbau in dem bild dürfte die empfindlichkeit um einiges
verschlechtern.
Michael M. schrieb:
> in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt> vorgeschlagene RC tiefpass falsch aufgebaut.
Du hast Recht: eigentlich gehört der Kondensator direkt zwischen Pin1
und Pin2 des TSOP, mein Fehler.
> der aufbau in dem bild dürfte die empfindlichkeit um einiges> verschlechtern.
Davon ist witzigerweise nichts zu merken ;-) Genau mit diesem Fehler
habe ich mir einen IR-Empfänger aufgebaut, der bei einer Distanz von 5m
überhaupt keine Probleme hat.
Trotzdem danke für den Tipp, ich habe das Schaltbild korrigiert (evtl.
muss man einmal im Browser Refresh drücken). Ich werde das bei
zukünftigen Schaltungen berücksichtigen.
Gruß,
Frank
Di Pi schrieb:
> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der> Hinweis auf eine noch fehlende Implementierung ist weg.)
Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen
flötengegangen. Ist nun wieder drin.
Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich
die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-,
Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll
benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird
einfach der jeweilige Code solange wiederholt, bis man die Taste
loslässt.
Die Sache mit Erkennung der Wiederholungssequenz steht trotzdem auf
meiner TODO-Liste.
Gruß,
Frank
Di Pi schrieb:
> Es wäre eine schöne sache, wenn neben den sechs bereits implementierten> Protokollen auch noch RC5 vertreten wäre (genauso ein- und> ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit> einer Lib abzudecken.> Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden> sollen.
Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und
macht das Projekt auf jeden Fall nicht uninteressanter.
Frank M. schrieb:
> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich> die spezielle Wiederholungs-Sequenz augesandt wird.
Meine "Cyberhome" (alter DVD-Player) sendet sie.
Michael K. schrieb:
> [RC5]> Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und> macht das Projekt auf jeden Fall nicht uninteressanter.
Leider ist das schon einiges an Mehraufwand, denn RC5 passt überhaupt
nicht in das Schema rein, wie die meisten anderen Protokolle aufgebaut
sind. RC5 ist bi-phasen-kodiert (Manchester) und damit kann man die Bits
nicht in das Schema:
0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec hell, y µsec dunkel
pressen. Sondern:
0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec dunkel(!), y µsec hell(!)
Und da liegt das Problem: je nach Folge der 1en und 0en gibt es
verschieden lange Hell- oder Dunkelphasen.
Siehe auch: http://www.sbprojects.com/knowledge/ir/rc5.htm
Konsequenz: RC5 muss durch einen Extra-Code geschleust werden. Allein
schon die Erkennung des Start-Bits als RC5-Code gestaltet sich als
schwierig. Ursprünglich gab es 2 Start-Bits, die beide "1" sein mussten:
1. Start-Bit: 889µs dunkel, 889µs hell
2. Start-Bit: 889µs dunkel, 889µs hell
Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt,
das "sieht" man also schon mal gar nicht. Aber man kann das als RC5
durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von
konstant 889µs folgt. Bis dahin passt das alles noch...
Aber:
Das RC5-Protokoll wurde nach einiger Zeit abgeändert ("RC5-Extended") -
nämlich derart, dass das 2. Start-Bit zu einem invertierten Kommando-Bit
6 umfunktioniert wurde, um mehr Kommandos umsetzen zu können.
Damit sehen die beiden ersten Bits folgendermaßen aus:
Entweder:
Start-Bit: 889µs dunkel, 889µs hell
Kommando-Bit 6: 889µs dunkel, 889µs hell
oder:
Start-Bit: 889µs dunkel, 889µs hell
Kommando-Bit 6: 889µs hell, 889µs dunkel
Das heisst: wir haben entweder eine Hellphase von 1 x 889µs bei den
ersten beiden Bits oder eine Hellphase von 2 x 889µs.
Peter Daneggers RC5-Decoder hat es da wesentlich einfacher: Dieser ist
fest auf RC5 und dessen Manchester-Codierung fixiert und hart drauf
programmiert. Wenn man nichts anderes berücksichtigen muss, ist das sehr
sehr einfach.
Ich werde mir jedoch erst einmal Gedanken machen müssen, wie man
RC5-Code als solchen überhaupt erkennen kann. Der Rest ist dann einfach:
sobald klar ist, dass es sich um RC5 handelt, muss dann in der
State-Machine in einen Manchester-Decoder gesprungen werden - also in
eine Sonderbehandlung. Da kann dann der Code von Peter Dannegger
herhalten.
Also bitte etwas Geduld, RC5 kann man nicht einfach durch
Preprocessor-Konstanten parametrisieren, wie ich das mit den anderen
Protokollen gemacht habe.
Gruß,
Frank
Frank Boe schrieb:
>> [Wiederholungs-Sequenz beim NEC-Protokoll]> Meine "Cyberhome" (alter DVD-Player) sendet sie.
Michael M. schrieb:
> meine yamaha-fb auch.
Okay, ich baus ein, ist ja nicht wirklich schwierig :-)
Gruß,
Frank
Frank M. schrieb:
> Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt,> das "sieht" man also schon mal gar nicht. Aber man kann das als RC5> durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von> konstant 889µs folgt. Bis dahin passt das alles noch...>
Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch
nur als RC5 Startbit.
Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die
ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt
wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher
und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs
Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den
Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.
Gruß Willi
P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit
Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen? Meine
hat diese Woche Nachtdienst, da bleibt dann auch mal wieder etwas mehr
Zeit.
Toralf Wilhelm schrieb:
> Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch> nur als RC5 Startbit.
Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended
RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6
benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich
erstmal einfach um das Classic-RC5.
> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den> Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.
Danke für den Tipp, das werde ich mir nochmal durch die Gehirnwendungen
laufen lassen.
> P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit> Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen?
Verheiratet, Frau ist tolerant und auch toll-erant ;-)
Gruß,
Frank
Frank M. schrieb:
> Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended> RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6> benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich> erstmal einfach um das Classic-RC5.
Genauso mache ich es, einfach immer extended RC5 und das Bit invertiert
als Bit6 einfügen.
> Verheiratet, Frau ist tolerant
Du glücklicher!
> und auch toll-erant ;-)
Mist da war sie wieder, meine Legasthenie.
Gruß Willi
Toralf Wilhelm schrieb:
> Frank M. schrieb:> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den> Bitspeicher eingeschoben.
Habe das jetzt so eingebaut, aber mit einer leichten Änderung des
Algorithmus: ob das neue Bit invertiert oder nicht invertiert neu
eingeschoben wird bei einem kurzen Puls, ist nicht abhängig von der
letzten Pulsdauer, sondern von der Pause davor.
Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert
Kurze Pause vor kurzem Puls: neues Bit = letztes Bit
Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall
läuft das nun. Den Code stelle ich heute abend oder morgen zum Download
bereit.
Dank und Gruß,
Frank
Frank M. schrieb:
> Toralf Wilhelm schrieb:>> Frank M. schrieb:>> Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert> Kurze Pause vor kurzem Puls: neues Bit = letztes Bit>> Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall> läuft das nun. Den Code stelle ich heute abend oder morgen zum Download> bereit.>
Ja da habe ich mich nicht sehr deutlich ausgedrückt, ich messe jeden
Flankenwechsel egal ob Puls oder Pause. Mich interessiert nur die Länge.
Aber Du hast das schon richtig verstanden.
Gruß Willi
RC5 ist nun implementiert, der vom Compiler generierte Code ist kaum
größer geworden, weil ich noch ein paar Sachen optimiert habe. Download
findet Ihr im IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#Download
Noch ein Tipp am Rande:
Jedes von IRMP unterstützte IR-Protokoll "verbrät" ungefähr 200 Byte an
Code. Wer sparen muss, weil ihm der Flash-Speicher ausgeht, der sollte
die Unterstützung von KASEIKYO und/oder RECS80 ausschalten. Beides sind
eher exotische Protokolle, ausserdem ist die Modulationsfrequenz von
56Khz beim Kaseikyo-Protokoll weit ab von den Frequenzen, die von den
anderen Protokollen verwendet werden.
Über Feedback zum RC5 würde ich mich freuen, ich habe hier nur mit
künstlich generierten Scan-Dateien getestet, da ich selbst keine RC5-FB
habe.
Viel Spaß,
Frank
Neue Version unter http://www.mikrocontroller.net/articles/IRMP#Download
:
Beim NEC-Protokoll werden nun auch die "Repetition Frames" erkannt. Wenn
die FB so eine Wiederholungssequenz aussendet, ersetzt IRMP diese
einfach durch das zuletzt empfangene Kommando.
Gruß,
Frank
Habe noch einen Bug korrigiert:
Die Puls/Pausen-Counter waren immer um 1 zu niedrig, das gab manchmal
Probleme bei der SIRCS-Erkennung bei Sony-FBs mit stark abweichenden
Timings.
Download-Zip-Datei habe ich aktualisiert.
Gruß,
Frank
Wie testest du das eigentlich? Hast du von jedem Protokoll ne
Fernbedienung zuhause? ;) Oder haste bei nem Pollin
1kg-Fernbedienungspaket zugegriffen hehe.
Simon K. schrieb:
> Wie testest du das eigentlich?
Steht im ersten Beitrag ganz oben, nicht gelesen? ;-)
irmp kann man auch unter Linux compilieren und dann mit einer Scan-Datei
füttern. Wie man eine Scan-Datei mit IRMP erstellt, ist ebenso oben
beschrieben. Ich teste den Code ausschließlich unter Linux, das geht
wesentlich einfacher und schneller. Wenn dann alles wie gewünscht läuft,
schicke ich den Source noch einmal durch den AVR-Compiler und flashe ihn
dann.
> Hast du von jedem Protokoll ne Fernbedienung zuhause? ;)
Nein, 7 von 9 Fernbedienungen bei mir arbeiten mit dem NEC-Protokoll.
Dann habe ich noch eine Samsung. Den Rest teste ich entweder mit
Scan-Dateien, die mir Vlad Tepesch zur Verfügung gestellt hat (steht
auch oben) oder mit künstlich erzeugten Dateien, die man einfach mit
einem ASCII-Editor erstellt. Jedes Telegramm wird einfach pro Zeile mit
0en (Puls) und 1en (Pause) beschrieben, fertig. Beispiel-Dateien sind im
ZIP-Archiv enthalten.
> Oder haste bei nem Pollin 1kg-Fernbedienungspaket zugegriffen hehe.
Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das
Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar
Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst
kürzlich auf besonderen Wunsch dazukam) oder noch was anderes... Mal
sehen, bin zum Testen mit realer Hardware schon länger nicht mehr
gekommen.
Wenn mir jemand Scan-Dateien schickt, welche von IRMP nicht erkannt
wird, prüfe ich das und baue den Decoder dafür ein, wenn ich das für
sinnvoll halte. Aber ich bin der Meinung, dass IRMP bereits jetzt über
90% aller Fernbedienungen, die heutzutage so im Umlauf sind, bereits
erkennt.
Gruß,
Frank
> Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das> Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar> Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst> kürzlich auf besonderen Wunsch dazukam)
Genau so ist es!
RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube
auch alles was Thomson war - Telefunken/Saba/Nordmende)
Gruß Willi
Toralf Wilhelm schrieb:
> Genau so ist es!>> RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube> auch alles was Thomson war - Telefunken/Saba/Nordmende)
Da wäre ich mir nicht so sicher. Laut
http://www.mikrocontroller.net/attachment/67261/Pollin-IR-Codes.txt
gibt es bei der Fernbedienung "Technisat DSR-B" (Pollin-Bestellnummer
620062) zwei Ausführungen. Da bei mir kein 9V-Block einzusetzen ist,
nehme ich an, dass es die erste im Text aufgeführte FB ist. Und diese
enthält einen SAA3004 (SA2004 gibt es nicht, das scheint ein Vertipper
zu sein) als IR-Encoder. Durch das Datenblatt steige ich noch nicht ganz
durch, habe auch erstmal nur flüchtig draufgeguckt.
Kandidat könnte RECS80 sein, welches ja die zweite FB mit der
Bestellnummer 620062 benutzt. Spricht auch deswegen dafür, weil eine
LED, die beim damaligen Test vom µC synchron geschaltet wurde, um das
Signal sichtbar zu machen, nur ganz ganz schwach leuchtete, wenn ich
eine Taste drückte. Bei RECS80 sind die Impulse ultrakurz, nämlich nur
158µs. Die Pausen hingegen sind 32 mal länger! Ein echter Batteriesparer
also ;-)
Bei einer Timerfrequenz von 10000 kHz macht das gerade mal 1 oder 2
Impulse. Da ich erst gestern den Bug gefixed habe, dass der Pulscounter
immer 1 zu niedrig war, könnte das schon der Grund sein, warum die FB
damals beim flüchtigen Test nach dem Auspacken nicht erkannt wurde. Da
wurde nämlich schnell mal aus einem Puls gar keiner mehr ;-)
Da hilft alles nix: Ich muss das mit der "echten" Hardware und mit dem
aktuellen IRMP-Code nochmal testen, im Notfall einen Scan machen...
Wenn sie dann aber funktionieren, sind das unschlagbar billige Teile ;-)
Gruß,
Frank
Hi Leute,
tolles Projekt !!
Ich habe aber leider ein gänzlich anderes Problem.
Weiß Jemand ob es eine Art Datenbank gibt, wo man herausfinden kann,
welches IR Protokoll ein Gerät benutzt ?
Hintergrund meiner Frage ist, das ich einen Digital Sat receiver
(Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher
von mir getestete Universalfernbedienung funktioniert.
Der IR Epfänger funktioniert.
Habe mir die Signale mit dem Scope angeschaut.
Würde den Sat Receiver ungern wegwerfen, denn wenn ich bedenke wieviel
Dreck bei der Produktionen einen Neuen ensteht ...
Vielleicht hat ja Jemand einen guten Tip.
Wünsche allen noch schönen Tag
Gruß
Siegmar
siegmar schrieb:
> Hintergrund meiner Frage ist, das ich einen Digital Sat receiver> (Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher> von mir getestete Universalfernbedienung funktioniert.
Mein erster Gedanke wäre die Lirc-DB.
Sicher, dass der Receiver tatsächlich was empfängt?
Google sagt, dass der Receiver öfters Wärmeprobleme hat und deswegen
sehr oft der IR-Empfang nach einiger Zeit ausfällt. Andere konnten den
Empfang verbessern, indem sie die Blende vor dem IR-Sensor ausgebaut
haben. Aber einen Hinweis, wie man eine Universal-FB damit zum Laufen
bekommt, habe ich nicht gefunden.
Gruß,
Frank
Frank M. schrieb:
> Sicher, dass der Receiver tatsächlich was empfängt?
Hallo Frank,
ja, ich hab das Oszi dran gehabt und saubere Impulse gesehn.
Eine Universalfernbedienung hat alle mölichen Protokolle durchgepulst
und ich hab mir dann auf dem Oszi die Signale angeschaut.
Die Originalfernbedienung hab ich leider nicht mehr !!
Danke für deinen Tipp
Noch einen schönen Abend
Gruß
Siegmar
Von der Philips-Universal-FB-Seite (http://www.pronto.philips.com)
gibt's einen Link auf http://onlyoneremote.com. Dort kann eine Datenbank
für sehr viele Hersteller heruntergeladen werden, darunter auch viele
Philips-Codesets. Öffnen kann man die Datei mit den Konfigurationstools
von Philips, die man kostenlos herunterladen kann, nachdem man sich
registriert hat.
Leider kann man in den Philips-Tools nur die Bitfolgen ansehen, die man
selbst aufgezeichnet hat. Vielleicht kannst du ja aber mit etwas reverse
engineering was brauchbares aus der Datenbank holen. Vielleicht kennst
du ja auch jemanden mit einer Philips-UFB der dir helfen könnte.
Hallo Frank,
cooles Projekt, ich habe es gestern mal provisorisch aufgebaut und
gleich ein paar Anmerkungen und Fragen dazu:
RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B.
die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt
auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten
gehen sehr stabil.
Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch
Taste 2 und 6 besonders auffällig)
Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt
wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal
angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan
ist invertiert, dann wird das Bitvergleichen einfacher.
An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes
werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn
Du hier unterstützen kannst/möchtest.
SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich
noch nicht testen.
Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und
auch gleich den DEBUG Mode in die AVR Variante eingebaut. Ich denke mal
dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal
das Ergebnis zu beinflussen. Die Abweichungen habe ich allerdings auch
ohne DEBUG bzw. IRMP_LOGGING
Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den
Oszillaor benutzt. Könnte am Timing etwas verändern, oder? Ich habe um
die Abarbeitung zu beschleunigen einen 16MHz Quarz und den Compiler auf
maximalen speed optimiert.
Der Interrupt ist ebenfalls mit 10kHz eingestellt.
Kannst Du mir ein paar Tipps geben wo ich ansetzen kann?
Vielen Dank für den Code und Deine Unterstützung.
Grüße,
Klaus
Hallo Klaus,
Klaus Leidinger schrieb:
> RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B.> die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt> auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten> gehen sehr stabil.
Da wäre eine über den UART übertragene Scan-Datei klasse, wenn Du da mal
die Tasten 0-9 aufzeichnen könntest.
> Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch> Taste 2 und 6 besonders auffällig)
Dito.
> Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt> wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal> angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan> ist invertiert, dann wird das Bitvergleichen einfacher.
Werde ich mir mal näher anschauen und dann noch was dazu schreiben. Wenn
Du schon beim Einscannen über UART bist, kannst Du das ja auch direkt
mal für diese FB tun.
> An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes> werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn> Du hier unterstützen kannst/möchtest.
Doku zu älterem DENON-Protokoll ist mir mal über den Weg gelaufen, wenn
Du da einen Link hättest, wäre nett.
> SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich> noch nicht testen.
Prima.
> Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und> auch gleich den DEBUG Mode in die AVR Variante eingebaut.
Das ist schlecht. Die DEBUG-Variante ist eigentlich nur zum Testen unter
Linux gedacht, auf dem AVR verändern Dir direkte printf-Ausgaben zu sehr
das Zeitverhalten. Daher halte ich das für überhaupt nicht sinnvoll.
> Ich denke mal> dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal> das Ergebnis zu beinflussen.
Eben. Lass das besser mit dem DEBUG-Modus auf dem AVR. Schalte lediglich
IRMP_LOGGING ein. Die empfangenen Bytes werden gepuffert und sollten
daher das Zeitverhalten während der Aufzeichnung nicht beeinflussen.
> Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den> Oszillaor benutzt. Könnte am Timing etwas verändern, oder?
Mit einem Quarz sollte es eher besser sein. Wie gesagt, der DEBUG-Modus
ist nicht für die Ausgabe geeignet, da er in der ISR direkt ausgeführt
ist. Unter Linux oder Windows ist das absolut zeitunkritisch, weil da
die Daten ja dann aus der Datei gelesen werden.
Gruß,
Frank
Albert K. schrieb:
> Hallo Klaus, steht die "portierte" Version für CV zum Download an?>
Hallo Albert,
Du hast Post.
Wennn der Code "stabil" ist, stelle ich die gerne zur Verfügung.
Falls mehr Leute Interesse daran haben, könnte Frank dann die
#ifdef CV
vielleicht in den Original Code mit reinnehmen?
Mal sehen wieviel Aufwand das wird ;-)
Grüße,
Klaus
Klaus Leidinger schrieb:
> Falls mehr Leute Interesse daran haben, könnte Frank dann die> #ifdef CV> vielleicht in den Original Code mit reinnehmen?
Klar, mache ich. Schick mir bitte die geänderten Dateien zu.
Gruß,
Frank
Michael K. schrieb:
> Leider kann man in den Philips-Tools nur die Bitfolgen ansehen, die man> selbst aufgezeichnet hat. Vielleicht kannst du ja aber mit etwas reverse> engineering was brauchbares aus der Datenbank holen. Vielleicht kennst> du ja auch jemanden mit einer Philips-UFB der dir helfen könnte.
Danke für den Tip.
Ob es micht weiter bringt ?
Wenn ich nur wüßte, welche Codierung der SAT Receiver benutzt.
Nun ja ....... mal sehn.
Trotzdem Danke und noch einen schönen Tag
Gruß
Siegmar
Frank M. schrieb:
> Di Pi schrieb:>> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der>> Hinweis auf eine noch fehlende Implementierung ist weg.)>> Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen> flötengegangen. Ist nun wieder drin.>> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich> die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-,> Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll> benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird> einfach der jeweilige Code solange wiederholt, bis man die Taste> loslässt.
Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)
Di Pi schrieb:
> Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)
Danke für die Info. Mit der Download-Version vom 13.02. im IRMP-Artikel
sollte das auch von IRMP erkannt werden.
Gruß,
Frank
Es gibt eine neue Version von IRMP zum Download:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Erkennung von NEC-Protokoll-Varianten, z.B. Apple-Fernbedienung
- Neuer Decoder: RC6
- Neuer Decoder: Denon und Denon-Varianten
- Verbesserung des RC5-Decoders (Bugfixes)
Vielen Dank an Klaus Leidinger, der mich mit den entsprechenden
Scan-Dateien versorgte ;-)
Desweiteren gibt es nun im Unterverzeichnis IR-Data ein irmp.exe, mit
dem man Scan-Dateien auch unter Windows analysieren kann.
Beispiel:
1. Eingabeaufforderung starten
2. In das Verzeichnis irmp\IR-Data wechseln
3. Aufruf von:
irmp.exe <rc5x.txt
Da manche Ausgaben sehr lang werden, empfiehlt es sich, diese in eine
Datei zu lenken oder in den more weiterzuleiten, damit man seitenweise
blättern kann:
irmp.exe <rc5x.txt | more
Viel Spaß,
Frank
...
und für die Codevision Nutzer ist die main.c entsprechend angepasst...
einfach das //#define CODEVISION auskommentieren.
Danke an Frank, auch für die Nachtschichten ;-)
Klaus
Klaus Leidinger schrieb:
> ...> und für die Codevision Nutzer ist die main.c entsprechend angepasst...> einfach das //#define CODEVISION auskommentieren.
Upps, hab ich doch tatsächlich vergessen... ich schreibs noch mit in den
Artikel.
Gruß,
Frank
ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt -
u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan
durchgetestet habe.
Chris M. schrieb:
> ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt -> u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan> durchgetestet habe.
Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich
nach Infos aus dem Internet implementiert, ohne es jemals testen zu
können.
Gute Idee, eine Liste von Fernbedienungen in den Artikel einzufügen,
vielleicht ist die Angabe der Adresse aber besser in Hex sinnvoll?
Wer noch weitere FBs mit IRMP getestet hat, kann diese ja auch noch im
Artikel eintragen, zum Beispiel die Reichelt-RGB-FB.
Gruß,
Frank
Frank M. schrieb:
> Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich> nach Infos aus dem Internet implementiert, ohne es jemals testen zu> können.
Ja problemlos - mit der Version die Du um den 10.02. veröffentlicht
hattest ging noch nichts und ich dachte schon die wird noch ein ganz
anderes Protokol nutzen. Auch die RC5 Codes stimmen nun mit der anderen
Software von Peter Dannegger die ich nutze überein.
Moin,
habe den Code heute zum ersten Mal ausprobiert. Läuft auf einem Atmega16
einwandfrei mit NEC Protokoll.
Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data
habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem
Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob
ich einen Auto-Repeat haben möchte oder nicht.
Mag vielleicht auch noch für andere hilfreich sein...
Viele Grüsse
Michael
Michael Urban schrieb:
> Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data> habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem> Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob> ich einen Auto-Repeat haben möchte oder nicht.
Ist das generell sinnvoll und damit von allgemeinem Interesse?
Ich meine, nicht nur für NEC, auch bei RC5 und RC6 könnte man das gewiss
einbauen...
@Michael: Für was brauchst Du das?
Gruß,
Frank
was versteht ihr unter Wiederholung?
a) den mehrfachen Empfang eines Frames, weil das Protokoll so
implementiert ist, dass es jeden Frame 3x verschickt
b) eine Wiederholung durch dauerhaft gedrückte Taste
Vlad Tepesch schrieb:
> was versteht ihr unter Wiederholung?> a) den mehrfachen Empfang eines Frames, weil das Protokoll so> implementiert ist, dass es jeden Frame 3x verschickt> b) eine Wiederholung durch dauerhaft gedrückte Taste
b)
Das Protokoll "darunter" soll ja gerade für die Applikation
unsichtbar/uninteressant sein.
Gruß,
Frank
Moin,
ich meinte die Erkennung, ob ein Kommando erstmalig gesendet wird oder
aufgrund eines Wiederholungsframes erzeugt wurde.
Ich brauchte das, weil ich die Fernbedienung zur Eingabe von Daten
verwende - und wenn man da nicht kurz genug drückt, dann "prellt" die
Sache eben...
Ich habe das ganz einfach gelöst:
Die Datenstruktur IRMP_DATA habe ich durch ein viertes Feld ergänzt:
1
typedefstruct
2
{
3
uint8_tprotocol;// protocol, i.e. NEC_PROTOCOL
4
uint16_taddress;// address
5
uint16_tcommand;// command
6
uint8_trepetition;// repetition frame
7
}IRMP_DATA;
an der entsprechenden Stelle für die Erkennung von repetition frames:
irmp_address=last_irmp_address;// address is last address
5
irmp_command=last_irmp_command;// command is last command
6
irmp_repetition=1;// Marker repetition flag
7
}
(Variablendeklarationen, etc. habe ich hier jetzt mal weggelassen)
Das funktioniert bei allen Protokollen, die einen repetition frame
besitzen
In der Auswerteroutine im Programm kann mann jetzt irmp_data.repetition
auswerten und selbst entscheiden, ob man die Wiederholung haben will
oder nicht.
Ich habe z.B. für die Zahlentasten, die ich zur Eingabe verwende, die
Wiederholungen ignoriert, für Cursortasten sie aber eingeschaltet
gelassen.
Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für
mich ist es ein nutzbares Feature.
Viele Grüsse
Michael
> Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für> mich ist es ein nutzbares Feature.
Okay, ich bau das so ähnlich ein, aber etwas allgemeingültiger:
1
#define IRMP_FLAG_REPETITION 0x01
2
#define IRMP_FLAG_WASWEISSICH 0x02
3
....
4
5
typedefstruct
6
{
7
uint8_tprotocol;// protocol, i.e. NEC_PROTOCOL
8
uint16_taddress;// address
9
uint16_tcommand;// command
10
uint8_tflags;// flags, e.g. repetition frame
11
}IRMP_DATA;
Denn wer weiß, vielleicht kommen da noch ein paar Flags hinzu?
Dann wird bei länger gedrückter Taste das Bit IRMP_FLAG_REPETITION in
flags gesetzt - nicht nur bei NEC, sondern auch bei RC5 und RC6. Bei den
anderen Protokollen ist das schwerlich möglich, ausser ich arbeite mit
Timeouts ("wenn derselbe Befehl innerhalb X Millisekunden reinkommt,
dann hat der User schon länger den Finger auf der Taste")... mal sehen.
In main() kann man das dann so abfragen:
Timeouts würde ich dafür nicht verwenden (oder abschaltbar machen). Was
ich an diesem Projekt nämlich am meisten schätze ist die Möglichkeit,
alles nicht benötigte per Flag abzuschalten.
Di Pi schrieb:
> Timeouts würde ich dafür nicht verwenden (oder abschaltbar machen). Was> ich an diesem Projekt nämlich am meisten schätze ist die Möglichkeit,> alles nicht benötigte per Flag abzuschalten.
Ich dachte einfach an einen Zähler, der bei jedem Call der ISR
hochgezählt wird. Wenn
a) ein neuer Frame erkannt wird und
b) der Zähler einen gewissen Wert (REP_TIMEOUT) nicht übersteigt und
c) erkanntes ProtoKoll = letztes Protokoll und
d) Adresse = letzte Adresse und
e) Kommando = letztes Kommando
dann setze das Repetition-Flag.
Der Zähler wird bei jedem erkannten Protokoll einfach wieder auf 0
gesetzt.
REP_TIMEOUT müsste auf ca. 0,2 Sekunden stehen. Jede FB schafft bei
Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so
schnell einzeln auf der FB rum.
Meinetwegen kann ich das auch abschaltbar machen, aber ich schätze den
zusätzlichen Aufwand an µC-Code auf max. 50 Bytes.
Gruß,
Frank
Wenn es wirklich nur 50 Bytes sind, ists meiner Meinung nach nicht
nötig, es per Flag abschaltbar zu machen.
Ich habe mir noch nicht so detaillierte Gedanken über die konkrete
Umsetzung gemacht. Dein Ansatz aber klingt für mich sehr plausibel und
wirklich klein.
Er könnte sogar diverse Togglebits komplett ablösen (und dadurch den
code verkleinern), wenn man davon ausgeht, dass
"
>Jede FB schafft bei>Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so>schnell einzeln auf der FB rum.
"
immer gilt.
Es gibt eine neue Version von IRMP zum Download:
http://www.mikrocontroller.net/articles/IRMP#Download
Einzige Änderung: Neue Variable flags in IRMP_DATA zur Erkennung von
langen Tastendrücken
Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich
einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im
Struct-Member flags gesetzt, wenn eine Taste auf der Fernbedienung
längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando
innerhalb kurzer Zeitabstände ausgesandt wird.
Beispiel:
1
if(irmp_data.flags&IRMP_FLAG_REPETITION)
2
{
3
finger_blau(irmp_data.command);
4
}
5
else
6
{
7
einzeln(irmp_data.command);
8
}
Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu
"entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION
ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die
wiederholte Auswertung ein und desselben Kommandos aber durchaus
gewünscht sein - zum Beispiel, um LEDs zu faden.
Es gibt eine neue Version vom IRMP zum Download:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
1. SIRCS: Korrekte Erkennung und Unterdrückung von automatischen
Frame-Wiederholungen
Eine Sony-Fernbedienung wiederholt automatisch jeden Frame 2-3 mal. Das
wurde nicht immer korrekt als solche erkannt. Solche Wiederholungen
werden nun weggefiltert.
2. SIRCS: Device-ID-Bits werden nun in irmp_data.command und nicht mehr
in irmp_data.address gespeichert
Je nach Sony-FB-Tasten (z.B. für TV-Kanal oder für Videotext) werden
unterschiedliche ID-Kennungen mitgeschickt. IRMP hat diese bisher in der
Adresse abgebildet. Das ist aber nicht praxisgerecht, weil dann ein- und
dieselbe Fernbedienung unterschiedliche Adressen aufweist. Die
ID-Kennung wird nun zusammen mit dem Kommando in der Variablen
irmp_data.command abgelegt. Somit hat nun jede Sony-FB ein- und dieselbe
Adresse, nämlich 0.
Ausnahme: Ist der Frame 20 Bits statt 12 oder 15 Bits lang (nur bei
neueren FBs), werden die letzten 5 Bits in der Adresse abgelegt.
3. Vergrößerung des Scan-Buffers (zwecks Protokollierung)
Der Scan-Buffer wurde vergrößert, um solche automatischen
Wiederholungen, wie sie z.B. von Sony-FBs ausgesandt werden, überhaupt
zu erkennen und als solche für Scans zu protokollieren. Da der
Scan-Buffer im Normalfall abgeschaltet ist, hat das keine Auswirkung auf
die Größe des Programms.
Gruß,
Frank
Hi Frank,
zunächst mal vielen Dank für das große Engagement bei diesem
Softwareprojekt. Das trifft genau mein Thema, ich habe gerade ein
Projekt geatartet um verschiedene Kommandos der "vielen" Fernbedienungen
meiner Anlage aufzufangen um dann Zusatzfunktionen auszulösen.
Vielleicht hier mal kurz meine Erfahrungen mit deiner Software nach den
ersten 2..3 h herumspielen:
Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing,
(gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz
externem Quarz läuft es wesentlich besser.
Zu den Protokollen, die ich mit original FB testen kann:
SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit
ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene
Codes bei gleichem Tastendruck gezeigt werden.
NEC von einer Yamaha-FB läuft richtig super.
KASEIKYO von einer Panasonic Blueray FB läuft auch super.
SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.
Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu
90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses
Protokolls wäre ich am stärksten interessiert...
Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung
nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es
kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke
will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht
nun nicht mehr, alles sieht gleich aus.
Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP
ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn
eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9
aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das
Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei
SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen
bitverdreht, konnte ich noch nicht checken.
Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum
Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines
Zeitbudgets gerne tun.
-Peter
Peter Kostov schrieb:
> typischerweise haben Zifferntasten 1..9> aufsteigende Codes
Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da
scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl
1..9 als auch alle anderen Tasten). Sicher, dass dein Hersteller nicht
vllt einfach absteigend nummeriert?
Hi Peter,
Peter Kostov schrieb:
> Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing,> (gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz> externem Quarz läuft es wesentlich besser.
Interessant, die anderen, die mich mit IR-Scans und anderen Infos
versorgen, benutzen den internen Oszillator und haben keine
Timing-Probleme.
> SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit> ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene> Codes bei gleichem Tastendruck gezeigt werden.
Da bräuchte ich einen Scan von mehreren Tasten. Dazu bitte IRMP_LOGGING
einschalten, über den UART mitprotokollieren und mir die Scans schicken
- am besten mit einem Kommentar "# Taste 1" vor jeder Zeile.
Beispiel-Dateien sind im Ordner IR-Data.
> KASEIKYO von einer Panasonic Blueray FB läuft auch super.
Hier würden mich auch Scans interessieren, weil ich nämlich gerade das
Programm für eine IR-Sende-Funktion schreibe, welcher man die
IRMP-Datenstruktur übergibt. Diese Funktion rekonstruiert aus den
IRMP-Daten wieder den Original-Frame und gibt diesen dann über eine
IR-Diode aus. Beim Kaseikyo-Protokoll sind das aber 48 Bits, von welchen
ich beim Decodieren einige ignoriere, um sie überhaupt in die
IRMP-Datenstruktur pressen zu können. D.h. beim Decodieren gehen
Informationen verloren. Diese sind zwar fürs Decodieren der Tasten nicht
wichtig, aber für das Encodieren des kompletten Frames. Wäre also nett,
wenn Du mir da entsprechende Scans schicken könntest, da ich selber noch
nie eine Kaseikyo-kompatible FB gesehen habe ;-)
> SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.
Bitte Scans her. Ich passe das dann an.
> Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu> 90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses> Protokolls wäre ich am stärksten interessiert...
RC6 sieht verschiedene Modes vor und kann ziemlich kompliziert werden.
Ich habe bisher nur Mode 0 implementiert, der auch hier
http://www.sbprojects.com/knowledge/ir/rc6.htm
dokumentiert ist. Da RC6 teilweise(!) dieselben Timings wie RC5 benutzt,
kann das dann schnell "verwechselt" werden - jedenfalls dann, wenn der
Frame nicht den Mode 0, sondern irgendeinen anderen verwendet.
Auch hier helfen mir nur Scans.
> Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung> nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es> kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke> will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht> nun nicht mehr, alles sieht gleich aus.
Die Infos gehen ja nicht verloren, die Device-IDs landen halt nun im
Byte "command" statt "address". Daher sollte die TV-Power- und die
DVD-Power-Taste durchaus ein unterschiedliches Kommando liefern. Vor
dieser Änderung waren halt die Adressen verschieden aber die Kommandos
gleich.
Bist Du sicher, dass da alles gleich aussieht? Dann muss es auch vor
dieser Änderung gleich ausgesehen haben.
> Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP> ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn> eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9> aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das> Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei> SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen> bitverdreht, konnte ich noch nicht checken.
Einige Protokolle senden mit MSB-First, andere mit LSB-First. Die
Arbeit, die Bits in der jeweils "richtigen" Reihenfolge zu speichern,
wollte ich mir nicht machen. Hauptsache, die empfangenen Codes sind
verschieden. Ist die Bitreihenfolge für Dich wichtig?
> Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum> Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines> Zeitbudgets gerne tun.
Danke im voraus für die Scans ;-)
Gruß,
Frank
Di Pi schrieb:
> Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da> scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl> 1..9 als auch alle anderen Tasten).
Interessant, bei RC5 sind die Codes für die Tasten eigentlich fest
definiert, d.h. jede RC5-FB sollte das gleiche Command senden, wenn man
die Taste "1" drückt. Die Adressen können natürlich voneinander
abweichen.
> Sicher, dass dein Hersteller nicht vllt einfach absteigend nummeriert?
Das Problem ist die Bitreihenfolge. Einige Protokolle arbeiten mit
MSB...LSB, andere mit LSB...MSB. Diese verschiedenen Bitreihenfolgen
beachte ich nicht. Halte ich auch (bisher) nicht für wichtig.
Hauptsache, jede Taste wird mit einem unterschiedlichen Code empfangen.
RC5 sendet übrigens mit MSB first, d.h. die Bitreihenfolge ist hier im
IRMP "richtig" herum. Die Commands müssen dann für die Tasten 1-9 immer
folgendermaßen aussehen:
Taste 1: command 0x0001
Taste 2: command 0x0002
...
Taste 9: command 0x0009
Ich werde die Bitreihenfolge im IRMP-Artikel mal dokumentieren. Dann
kann sich jeder selbst überlegen, ob er die Bits nach dem Empfang
nochmal "drehen" will oder nicht. Ich würde es nicht tun, halte ich für
unnötigen Verschleiss des µCs ;-)
Gruß,
Frank
Hallo Frank,
anbei Scans von verschiedensten Codes. Insbesondere die letzten Tests
mit der Kathrein FB sehen sehr merkwürdig aus, da IRMP meistens SIRCS
meldet, es ist definitiv kein SIRCS. Ich vermute sehr stark RC5 / RC6,
irgendetwas mit einem Toggle-Bit, damit kommt meine programmierbare FB
nicht klar.
Interessant auch die Samsung Scans, die vom IRMP auf "höherem Layer" gar
nicht angezeigt werden.
Getestet wurde das Ganze mit einem ATMEGA32@16MHz.
-Peter
Hallo Peter,
Peter K. schrieb:
> anbei Scans von verschiedensten Codes.
Vielen Dank für die Arbeit, die Du Dir gemacht hast. Ich schaue sie mir
im Laufe des Tages an und melde mich dann.
Gruß,
Frank
Ich habe nun die einzelnen Scans von Peter durchgearbeitet:
Sony-RM-S-310:
Protokoll: SIRCS
Erkennung: 100%
Sony-RMT-V406:
Protokoll: SIRCS
Erkennung: 100%
Sony-RM-U305C:
Protokoll: SIRCS
Erkennung : 100% (nach Anpassung der SIRCS-Toleranzen)
Sony-RMT-D142P-DVD:
Protokoll: SIRCS
Erkennung : 100%
Panasonic-Blue-Ray:
Protokoll: KASEIKYO
Erkennung: 100% (nach Anpassung der Kaseikyo-Toleranzen)
Prinzipiell kommt jeder Code 2x, beim 2. Mal ist Repetition-Flag
gesetzt.
@Peter: Du hast die Tasten aber nur kurz gedrückt? Wenn ja, muss ich
Kaseikyo-Wiederholungen wegfiltern
Yamaha-RAV388:
Protokoll: NEC
Erkennung: 100%
Auch hier kommt jeder Code 2x, Repetition-Flag ist ebenso gesetzt.
Beim NEC-Protokoll habe ich das bisher aber noch nicht erlebt, dass
Frames wiederholt werden.
@Peter: Nochmal die Frage: auch da jede Taste nur 1x kurz gedrückt?
Samsung_TV:
Diese FB benutzt zwar die gleichen Timings wie das bisherige SAMSUNG-
Protokoll, aber es fehlt das längere Sync-Bit an 16. Stelle. Ausserdem
ist die Länge nur 32 statt 37 Bits.
Protokoll: SAMSUNG2 (NEU!)
Erkennung: 100% (nach Anpassung des Source auf IRMP_SAMSUNG2_PROTOKOL)
Siehe auch IRMP-Artikel, wurde angepasst bzgl. SAMSUNG2
Kathrein-UFS-912-Remote:
Das ist echt ein harter Brocken. Das Protokoll ist RC6, aber der Frame
besteht nicht aus 20 Bits, sondern aus 36 Bits. Der RC6-Mode ist ein
anderer als der bisher bekannte, ausserdem liegt das Timing der
Start-Bits sehr nahe am SIRCS-Protokoll. Da muss ich noch ein wenig
Arbeit reinstecken...
Den Download im IRMP-Artikel werde ich heute abend aktualisieren, dann
klappt es auch mit allen oben genannten Fernbedienungen einwandfrei.
Ausnahme: Kathrein-FB, da kann es evtl. länger dauern.
Gruß,
Frank
Hi Frank,
na das Verarbeiten der Infos geht ja schnell... Ich werde heute abend
nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang
gedrückt" schicken. Wenns interessiert, kann ich auch noch verschiedene
andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.
-Peter
Hi Peter,
Peter K. schrieb:
> na das Verarbeiten der Infos geht ja schnell...
Die meiste Arbeit war das Separieren in verschiedene Dateien und die
Anpassung der Kommentare mit dem Editor ;-)
> Ich werde heute abend> nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang> gedrückt" schicken.
Prima, wäre klasse, wenn Du folgende Form wählen würdest:
1. Für jede FB eine eigene Datei
2. Vor jedem Scan eine Kommentar-Zeile, die mit '#' beginnt.
Beispiel für Sony-RM-S-310.txt:
# Taste: Power
00000000000000000000000000111100000000000000111100000000...
# Taste: 1
00000000000000000000000000111100000000000000111100000000...
usw.
> Wenns interessiert, kann ich auch noch verschiedene> andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.
Kannst Du gerne machen.
Gruß,
Frank
Neue Version von IRMP zum Download verfügbar:
http://www.mikrocontroller.net/articles/IRMP#Download
Erweiterungen/Änderungen:
- Neues Protokoll: SAMSUNG32 (Mix aus SAMSUNG & NEC-Protokoll)
- Änderung/Anpassung der SIRCS- und Kaseikyo-Timing-Toleranzen
Dank an Peter K. für die Scans.
Gruß,
Frank
Peter K. schrieb:
> KASEIKYO von einer Panasonic Blueray FB läuft auch super.
Hallo Peter,
Du hast anscheinend eine KASEIKYO FB, die müsste ja mit 56KHz senden.
Hast Du einen TSOP1756 als Empfänger? Oder was sonst?
Ich hatte hier gerade ein Problem mit einem SFH 5110-36, der hat nicht
mal mehr die 40KHz der Sony FB erkannt, ein TSOP1736 geht bei Sony noch,
aber nicht bei 56KHz.
Hat eventuell jemand einen Tipp für einen breitbandigeren Empfänger?
Vielen Dank und viele Grüße an die IR Fans ;-)
Klaus
Hi Klaus,
ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor
Jahren mal bei "C" gekauft. Die funktioniert mit allen FB (Sony,
Samsung, Yamaha, Panasonic) in ca. 50cm Entfernung. Das "DX"-Verhalten
aus mehreren Metern Entfernung hab ich noch nicht getestet.
-Peter
Hi Frank,
anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen
Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment
länger. Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei
das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf
der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer
über? Ich muss gestehen daß ich bisher mir noch nicht näher angucken
konnte wie du das ganze implementiert hast.
Aber: Samsung wird jetzt gut erkannt, prima!
Ciao - Peter
Mehr Zeit müsste man haben :)
Peter K. schrieb:
> ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor
OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so
was gibts wohl nicht mal mehr bei P*llin...
Danke für die Info,
Klaus
ich möchte mit einer Anwendung einige wenige Tasten einer (vorab
unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben
können (in genau diesem Protokoll).
Hat jemand einen Tip für eine dazupassende generische *Sende*routine?
-Michael
Michael Haberler schrieb:
> ich möchte mit einer Anwendung einige wenige Tasten einer (vorab> unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben> können (in genau diesem Protokoll).>> Hat jemand einen Tip für eine dazupassende generische *Sende*routine?
IRSND - diese hat gerade Klaus im Test ;-)
IRSND ist das Gegenstück zu IRMP. IRSND generiert aus der
IRMP-Datenstruktur den Frame und schickt ihn auf eine IR-LED. Ich werde
spätestens am Wochenende den IRSND zum Download ablegen.
Gruß,
Frank
Hi Peter,
Peter K. schrieb:
> anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen> Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment> länger.
Vielen Dank, sehr aufschlussreich. Der Frame wird nur 1x geschickt, wenn
Du kurz drückst. Bei der Taste 3 (länger gedrückt) gab es zwei Frames,
wobei IRMP dann korrekterweise das Repetition-Flag in irmp_data.flags
gesetzt hat. Ist also alles okay.
> Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei> das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf> der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer> über?
Könnte sein, da muss ich mir die Log-Funktion nochmal näher ansehen.
Diese hatte Vlad Tepesch für das WordClock-Projekt erstellt und ich habe
sie kurzerhand "assimiliert" ;-)
> Aber: Samsung wird jetzt gut erkannt, prima!
Freut mich. Ohne Logging stürzt das Programm auch nicht ab, oder?
> Mehr Zeit müsste man haben :)
Wie wahr...
Gruß,
Frank
Ich zitiere mich mal selbst ;-)
>OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so>was gibts wohl nicht mal mehr bei P*llin...
Als universeller Empfänger wäre wohl der U2538B prinzipiell geeignet:
Beitrag "Schaltung mit IR-Empfänger (LED) gesucht"
Mal sehen, wann der verfügbar wird, im Moment hat ihn digikey auch
nicht.
Klaus
Hi!
Zuerst: super Arbeit hier!
Ich bin ain AVR Anfänger und habe dazu nun etwas Unsicherheit um den
Code für den Atmeg8 zu verwenden!
1. F_CPU, benutze einen Quarz 12MHz:
1
main.c: #define F_CPU 12000000
2. Timer Register geändert:
1
TIMSK = 1 << OCIE1A; // OCIE1A: Interrupt by timer compare (use TIMSK for ATMEGA162)
Hugo Portisch schrieb:
> 1. F_CPU, benutze einen Quarz 12MHz:>
1
main.c: #define F_CPU 12000000
Wenn Du genau hinschaust, gilt das nur für den Codevision Compiler, Du
siehst da was von
#ifdef CODEVISION
...
#define F_CPU 8000000
...
#endif
Hier nützt eine Änderung gar nichts, wenn Du den WinAVR (gcc) als
Compiler nutzt. In diesem Fall musst Du im Projekt unter
Project -> Configuration Options
den Processor_ und die _Taktrate einstellen.
> 2. Timer Register geändert:
Sieht gut aus.
> 3. PD3 als Input:> * Change hardware pin here:
Korrekt.
> Habe aber etwas weiter oben im irmp.c das gefunden: static int PINB;> Muss ich denn auch auf PIND ändern?
Das ist nicht für Dich relevant, da dieses Statement im Block
#ifdef DEBUG
...
#endif
eingebettet ist. Das ist nur zum Debuggen unter Linux oder Windows.
Gruß,
Frank
Eine neue Version von IRMP ist unter
http://www.mikrocontroller.net/articles/IRMP#Download
verfügbar.
Änderungen:
1) Neues Protokoll: Apple
2) Bit-Order ist nun dem jeweiligen Protokoll angepasst.
Zu 1)
Das Apple-Protokoll ist bis auf eine Kleinigkeit identisch mit dem
NEC-Protokoll und wird mit IRMP_SUPPORT_NEC_PROTOCOL == 1 erschlagen.
Bisher wurde die Apple-FB immer als NEC-Protokoll ausgegeben, was aber
eigentlich "gelogen" ist. Die Apple-FB hat daher jetzt einen eigenen
Bezeichner IRMP_APPLE_PROTOCOL erhalten, damit der zukünftige Encoder
IRSND den Apple-Frame wieder reproduzieren kann.
Zu 2)
Es hat hier schon einige gestört, dass bei Protokollen, welche das LSB
zuerst ausgeben, die Tasten 1-9 scheinbar willkürliche Muster in
irmp_data.command haben. Die gesendete Bitreihenfolge wird nun von IRMP
berücksichtigt, bisher wurde immer mit MSB first gespeichert. Nun haben
bei vielen FBs die Tasten 1-9 auch eine aufsteigende Reihenfolge in
irmp_data.command. Dasselbe gilt natürlich auch für die Adresse.
Nachteil: Diejenigen, die Adressen und Kommandos von bestimmten
Fernbedienungen bisher schon aufgezeichnet, gespeichert und verwendet
haben, müssen das leider noch mal wiederholen, da nun für die
LSB-Protokolle (siehe IRMP-Artikel) ganz andere Werte als bisher
herauskommen. Sorry, aber Klaus Leidinger hat mich mittlerweile davon
überzeugt, dass diese Lösung die bessere ist ;-)
Gruß,
Frank
Frank M. schrieb:
> Änderungen:>> 1) Neues Protokoll: Apple
Für alle CV Nutzer: damit stimmt diese Sequenz im aktuellen Download für
den CodeVision Teil natürlich nicht mehr. Ich werde das anpassen und
Frank schicken.
@Frank: Du bist immer für eine Überraschung gut ;-)
Klaus
Klaus Leidinger schrieb:
> @Frank: Du bist immer für eine Überraschung gut ;-)
Sorry, aber danke für Deine Anpassung in der main-Funktion des
Codevision-Teils. Beim nächsten mal denke ich dran :-)
Den Download habe ich eben aktualisiert.
Gruß,
Frank
Eine neue Version von IRMP ist unter
http://www.mikrocontroller.net/articles/IRMP#Download
verfügbar.
Grund:
Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen
RC5-Frame oder anderen "Schrott-Daten"
Der Fehler sorgte dafür, dass bei nachfolgenden Frames anderer
Protokolle das Bit 6 im command prinzipiell immer gesetzt war. Durch
Plausibilitätskontrollen wurden dann weitere empfangene Nicht-RC5-Frames
verworfen oder falsch abgebildet - bis zum Reset des AVR oder bis wieder
ein vollständiger RC5-Frame empfangen wurde.
Vielen Dank an Klaus Leidinger, der diesem Fehler durch unermüdliches
nächtelanges Suchen auf die Spur kam :-)
Gruß,
Frank
Hallo,
wie bereits angekündigt, gibt es nun eine Alpha-Version von IRSND.
IRSND ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit
IRMP empfangen wurden, wieder den Original Frame, der dann über eine
Infrarot-Diode ausgegeben werden kann.
IRSND unterstützt die folgenden Protokolle:
* SIRCS
* NEC
* SAMSUNG
* SAMSUNG32
* MATSUSHITA
* RECS80
* RC5
* DENON
* APPLE
IRSND unterstützt folgende Protokolle (noch) nicht:
* KASEIKYO
* RC6
Näheres dazu steht im IRMP-Artikel, nämlich unter
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
Der Download-Link ist dort auch zu finden.
Vielen Dank an Klaus Leidinger, der mich bei der Entwicklung von IRSND
tatkräftig als Tester unterstützt hat :-)
Gruß,
Frank
Hi,
ich hätte da noch eine Frage zu dem Timer.
Ich habe Irmp mit V-USB kombiniert.
Bei einem PC geht es ohne Probleme, bei einem anderen PC wird der AVR
nicht als USB-Gerät erkannt.
Durch testen habe ich rausgefunden, wenn ich den Timer-Init raus lasse,
geht es:
1
int main(void)
2
{
3
uchar i;
4
5
6
wdt_enable(WDTO_2S);
7
/* Even if you don't use the watchdog, turn it off here. On newer devices,
8
* the status of the watchdog (on/off, period) is PRESERVED OVER RESET!
9
*/
10
DBG1(0x00, 0, 0); /* debug output: main starts */
11
/* RESET status: all port bits are inputs without pull-up.
12
* That's the way we need D+ and D-. Therefore we don't need any
13
* additional hardware initialization.
14
*/
15
odDebugInit();
16
usbInit();
17
usbDeviceDisconnect(); /* enforce re-enumeration, do this while interrupts are disabled! */
18
i = 0;
19
while(--i){ /* fake USB disconnect for > 250 ms */
20
wdt_reset();
21
_delay_ms(1);
22
}
23
usbDeviceConnect();
24
25
//clear irmp_data
26
irmp_data.protocol = 0;
27
irmp_data.address = 0;
28
irmp_data.command = 0;
29
irmp_data.flags = 0;
30
31
irmp_init(); // initialize irmp code
32
//timer_init(); // initialize timer
33
34
sei();
35
36
DBG1(0x01, 0, 0); /* debug output: main loop starts */
37
for(;;){ /* main event loop */
38
DBG1(0x02, 0, 0); /* debug output: main loop iterates */
vermutlich bekommst du probleme mit dem timing seitens usb, wenn die
v-usb routinen vom timer interrupt unterbrochen werden.
die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das
der funktion guttut, steht auf einem anderen blatt.
Michael M. schrieb:
> die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das> der funktion guttut, steht auf einem anderen blatt.
Vermutlich geht das so nicht, weil die V-USB-Funktionen laut
http://www.obdev.at/products/vusb/index-de.html einen "edge triggered
interrupt" benötigen.
Da müsste man schon gezielt den Timer1-Interrupt ein-/ausschalten.
@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen
vorzeitigen return einbaust?
Gruß,
Frank
Michael M. schrieb:
> hm, wo steht das denn? ich hab nur das hier gefunden:>> No UART, timer, input capture unit or other special hardware is required
Direkt in der Zeile darunter:
"No UART, timer, input capture unit or other special hardware is
required (except one edge triggered interrupt)."
Gruß,
Frank
@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen
2
vorzeitigen return einbaust?
3
4
Gruß,
5
6
Frank
Ja, wenn ich irmp_ISR(); auskommentiere dann geht es!
Das komische ist halt, dass an einem PC ohne Probleme geht.
An dem PC wo ich den Empfänger eigentlich einsetzen will geht es nicht
:(
Da ich leider den Beitrag nicht editieren kann:
V-USB benötigt ja die D+ Line auf einen Interrupt Pin. Am besten INT0.
Beim Atmega8 PD2.
Die TSOP1736 habe ich auf PD3 (INT1) gelegt.
Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet,
oder?
Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?
Das problem beim V-USB ist, das ein anderer IRQ den externen IRQ für den
USB um max 20µs verzögern darf. Dh. wenn man andere IRQs mit dem USB
nutzen will muß man dafür sorgen das der USB IRQ immer möglichst ohne
latenz abgearbeitet werden kann, sonst passt das timeing für die USB
frames nicht mehr.
Das Polling vom usb in der Main ist unktitisch. Wichtig ist NUR das der
externe IRQ für den USB immer sofort bearbeitet werden kann.
Hugo Portisch schrieb:
> Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet,> oder?
Richtig.
> Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?
Nein, das wird nichts bringen. Aber da es mit dem einen Board geht und
mit dem anderen nicht, liegt der AVR wohl knapp am Timing vorbei.
Schalte doch mal in irmp.c diejenigen Protokolle ab, die Du nicht
brauchst. Vielleicht hilft das schon... obwohl, solange kein IR-Signal
reinkommt, macht die ISR auch so gut wie gar nichts.
Gruß,
Frank
Man O Man, ich dreh noch durch!
Bei auskommentieren des irmp_ISR(); geht es bei beiden PCs.
Mit der Funktion geht es nur bei einem.
Auch ein "Abspecken" der IR-Funktionen auf NEC, RC5 & RC6 bringt nichts.
Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem
Reset/Boot gestartet wird?
Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init
mit dem Host vorbei ist es keine Probleme mehr geben sollte...
Danke!
Hugo Portisch schrieb:
> Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem> Reset/Boot gestartet wird?
Dafür gibt es mehrere Möglichkeiten, zum Beispiel könntest Du
timer_init() erst nach 2 Sekunden aufrufen, z.B. so:
1
_delay_ms(2000);
2
timer_init();
> Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init> mit dem Host vorbei ist es keine Probleme mehr geben sollte...
Gruß,
Frank
Habe es geschafft!
Dem _delay habe ich nicht getraut, da warscheinlich auch das USBPoll
benötigt wird.
Ich starte nun den Timer0 beim Reset.
Nach 0xFF durchläufen wird Timer0 abgeschaltet und der Timer1 für das IR
Polling gestartet.
Somit fängt der IR Timer erst ~5s nach dem Reset an.
AVR wird als USB Gerät erkannt und funktioniert einwandfrei!
Ist zwar nicht so schön geht aber nun!
Anbei das neue Projekt!
Danke für Hilfe und für Irmp!
Hi, nochmal ich!
Kann die Beiträge einfach nicht editieren :(
Da es nun am zweiten PC läuft habe ich mir den Empfang der IR Codes
angesehen.
Es geht sehr träge und es wird nicht jeder Code erkannt.
Beim anderen PC geht es ohne Probleme, schnelle Erkennung und es werden
auch alle Tasten erkannt.
NEC wird z.B am 2. PC gar nicht erkannt.
Woran kann das jetzt noch liegen, oder wie kann ich dem Problem auf die
Spur kommen?
Hugo Portisch schrieb:
> Habe es geschafft!
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
funktioniert es einwandfrei?
Hugo Portisch schrieb:
> Kann die Beiträge einfach nicht editieren :(
Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages,
danach nicht mehr.
Micha schrieb:
> Hugo Portisch schrieb:>> Habe es geschafft!> Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du> den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
HID ist nicht zwingend eine tastatur oder maus.
siehe http://en.wikipedia.org/wiki/USB_human_interface_device_class> Hugo Portisch schrieb:>> Kann die Beiträge einfach nicht editieren :(> Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages,> danach nicht mehr.
15 min sind es. und es geht auch dann nicht mehr, wenn jemand nach dem
zu editierenden betrag etwas geschrieben hat.
dass der link zum editieren auch nach 15min noch angezeigt wird, ist ein
(schon bekannter) fehler.
sry für den OTp
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
2
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
3
funktioniert es einwandfrei?
Kein "Tastaturersatz"...
Per USB-Polling des AVRs können die Codes gelesen werden (Protokoll,
Adress, Command & Flags). Er wird als USB-HID betrieben, somit sind
keine Treiber notwendig.
Bei HID ist ein Feature Transfer von <=8 Bytes recht einfach. Die
Struckt von Irmp sind ja nur 6Bytes ;).
Was man mit den Daten dann macht ist jedem selber überlassen.
Ich z.B. benütze es als Input-Plugin für DVBViewer.
Der AVR lernt auch den ersten empfangen Befehl. Per Flag kann dann
dieser Befehl zum schalten eines Optokopplers verwendet werden um die
Powertaste des PCs zu betätigen (Einschalten des PCs per Fernbedienung).
Werde dann noch eine Beispiel-Host Anwendung bereitstellen.
Man könnte aber auch ein Programm schreiben, dass die Codes in
Tastendrücke umwandelt. So ist ja die Idee von Irmp.
Jedoch will ich das nicht im AVR machen, sondern auf der Host Seite.
Somit muss ich für neue Befehle den AVR nicht neu programmieren.
Ein kleines Update zu dem USB Problem bei dem einem Mainboard.
Ich glaube fast, dass es am USB von Mainbaord liegt.
Die Codes werden schon richtig vom AVR ausgewertet, jedoch funktioniert
das Polling über USB nur sehr träge.
Beim anderen PC flutschen die Daten sofort rüber. Steuerung des
DVBViewer geht Super.
Werde mir einmal eine PCI-USB Karte ausleihen, damit ich den Fehler
weiter eingrenzen kann.
Hallo Frank,
geniale Sache, dieses IRSND. Habe heute mal damit etwas rumgespielt und
kann bestätigen, daß SIRCS funktioniert (andere Protos hab ich noch
nicht getestet). Allerdings ist es ziemlich unempfindlich, kann sein daß
es an meiner IR-Diode liegt oder aber am Timing. Zu weitergehenden
Untersuchungen bin ich leider noch nicht gekommen.
Da einige Timerregister insbesondere beim Mega32 anders heißen und auch
der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein
paar "if defined" reingebaut. Es wäre schön, wenn du dies in deine
sourcen übernehmen könntest, das würde helfen, die Software leicht auf
einem Mega32 oder Mega644P (mit den beiden hab ich herumgespielt) laufen
zu lassen. Weitere AVR-Typen könnte man bei Bedarf hinzufügen.
Die modifizierten sourcefiles sind hier angehängt.
-Peter
Hallo Peter,
Peter K. schrieb:
> Da einige Timerregister insbesondere beim Mega32 anders heißen und auch> der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein> paar "if defined" reingebaut.
Danke für Deine Vorschläge, werde ich so übernehmen.
Gruß,
Frank
Christian F. schrieb:
> IRMP löft auch auf einen PIC
Super! Kann man Deine Portierung irgendwie in den Source übernehmen?
Wäre doch eine echte Bereicherung.
Gruß,
Frank
Hallo Frank!
irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu
unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time.
Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.
Ich würde den Code zum Einlesen aus irmp_ISR() herausziehen und den
aktuellen Wert per Argument übergeben, z.B.:
eku schrieb:
> irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu> unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time.> Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.
In meinem aktuellen Source ist es mittlerweile ein Makro. Das habe ich
im Zusammenhang mit Christians PIC-Portiertung gemacht. Ich werde dafür
sorgen, dass dieses Makro zukünftig nur noch einmal aufgerufen wird,
nämlich am Anfang von irmp_ISR().
> Der Aufrufer kann dann auch die Phase umkehren, falls der IR-Empfänger> high-aktiv ist.
Das kann er dann im Makro direkt tun.
Danke für die Anregung,
Frank
Eine neue Version von IRMP ist unter
http://www.mikrocontroller.net/articles/IRMP#Download
verfügbar.
Zum einen ist die PIC-Portierung von Christian F. (blueicebox) in den
Source eingeflossen, zum anderen habe ich die Anregung von eku
übernommen, den Input-Pin nur noch an einer Stelle und immer zur
gleichen Zeit abzufragen.
Vielen Dank an Christian für seine Tipps zur PIC-Portierung.
Gruß,
Frank
Hallo,
könnte mir jemand einen Tip oder Code geben wie ich die drei Telegramme
1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando
auf meinem LCD ausgebe. Benutze das Programm von Peter Fleury.
So bekomme ich immer eine Fehlermeldung:
1
if(irmp_get_data(&irmp_data))
2
{
3
/* clear display and home cursor */
4
lcd_clrscr();
5
// ir signal decoded, do something here...
6
7
// irmp_data.protocol is the protocol, see irmp.h
8
lcd_puts(irmp_data.protocol);
9
// irmp_data.address is the address/manufacturer code of ir sender
10
lcd_puts(irmp_data.address);
11
// irmp_data.command is the command code
12
lcd_puts(irmp_data.command);
../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes
pointer from integer without a cast
muss ich hier itoa anwenden?
Bin Anfänger und sitze schon drei Tage dran und bekomms nicht hin.
Markus B. schrieb:
> ../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes> pointer from integer without a cast> muss ich hier itoa anwenden?
lcd_puts möchte einen C-String, Du übergibst aber Zahlen. Das geht
nicht. Also musst Du vorher die Zahlen in Strings - z.B. mit itoa() -
umwandeln, z.B. so:
1
#include<stdlib.h>
2
...
3
4
main()
5
{
6
charprotocol[10];
7
charaddress[10];
8
charcommand[10];
9
10
...
11
if(irmp_get_data(&irmp_data))
12
{
13
itoa(irmp_data.protocol,protocol,10);
14
itoa(irmp_data.address,address,10);
15
itoa(irmp_data.command,command,10);
16
17
lcd_clrscr();
18
lcd_puts(protocol);
19
lcd_puts(" ");
20
lcd_puts(address);
21
lcd_puts(" ");
22
lcd_puts(command);
23
}
Das dritte Argument gibt die Zahlenbasis an. Eventuell ist es
sinnvoller, address & command in Hex auszugeben statt dezimal. Dann muss
das dritte Argument für itoa() 16 sein.
Gruß,
Frank
lcd_putS puttet einen string. was es als parameter erwartet ist eine
adresse (pointer) zum ersten zeichen dieses strings, den es anzeigen
soll.
was du übergibst, ist eine zahl.
du kannst also entweder deine zahlen zu einem string konvertieren (itoa)
und dann anzeigen lassen.
oder du schaust mal, ob peter nicht genau für diesen falle eine funktion
geschrieben hat, die zahlen aus einer variablen anzeigen lässt.
Hallo,
ich habe Probleme mit den Timer-Einstellungen auf einem Atmega8. Timer 1
ist leider schon durch PWM belegt, so dass ich Timer 2 verwenden muss.
Ich verwende als F_CPU 8Mhz (interner Takt).
Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle
kennt er anscheinend, auf andere reagiert er nicht.
Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?
Hier meine Timer-Init mit Prescaler 8:
1
OCR2 = ((F_CPU/8) / F_INTERRUPTS) - 1; // compare value: 1/10000 of CPU frequency/prescaler = 99
2
3
TCCR2 |= (1 << WGM21); // switch CTC Mode on,
4
TCCR2 |= (1 << CS20);
5
TCCR2 |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
Chris schrieb:
> Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle> kennt er anscheinend, auf andere reagiert er nicht.
Welche Protokolle werden von IRMP erkannt, welche nicht?
> Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?
Ja, solange er hinreichend genau geht.
> Hier meine Timer-Init mit Prescaler 8:>
Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da
erreicht werden soll (IMHO ist der Name auch irreführend).
Darum habe ich mir auch gleich eine (wenigstens für mich) leichter
vertändliche Version gebastelt. Die hat auch ein besseres
Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die
Bitschiebe-Orgie entfällt ;-).
Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz
gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.
Verstehe ich nicht. F_CPU stimmt auf jeden Fall, sonst würden andere
Sachen auch nicht funktionieren.
Damit konnte ich folgende Protokolle empfangen:
Code: 9 Address: 0x00 Command: 0x00
Code: A Address: 0x2D2D Command: 0xA758
Code: 7 Address: 0x05 Command: 0x02
Code: 2 Address: 0xF708 Command: 0x02
Ein Preset auf der Fernbedienung wird nicht erkannt, wahrscheinlich ist
das ein Exot.
Chris schrieb:
> Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz> gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.
Dein Denkfehler liegt wohl hier:
TCCR2 |= (1 << CS20);
TCCR2 |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
Damit wird der Prescaler lt. ATMega8-Datenblatt nicht auf 8, sondern auf
32 gesetzt. Demnach müsste OCR2 dann 24 sein:
OCR2 = ((F_CPU/32) / F_INTERRUPTS) - 1; // compare value: 1/10000 of
Mit Deinem empirisch ermittelte Wert von 25 lagst Du also schon fast
richtig ;-)
Um den Prescaler auf 8 zu setzen, müsstest Du lediglich CS21 setzen.
Gruß,
Frank
Werner B. schrieb:
> Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da> erreicht werden soll (IMHO ist der Name auch irreführend).
Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein
besserer eingefallen ;-)
> Darum habe ich mir auch gleich eine (wenigstens für mich) leichter> vertändliche Version gebastelt. Die hat auch ein besseres> Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die> Bitschiebe-Orgie entfällt ;-).
Wow, Deine Version spart wirklich einiges ein!
Vielen Dank, werde ich so übernehmen.
Gruß,
Frank
P.S.
Es gibt noch eine kürzere (und damit auch schnellere) Version:
1
staticuint16_t
2
lsb_neu(uint16_tx)
3
{
4
x=((x>>1)&0x5555)|((x<<1)&0xaaaa);
5
x=((x>>2)&0x3333)|((x<<2)&0xcccc);
6
x=((x>>4)&0x0f0f)|((x<<4)&0xf0f0);
7
x=((x>>8)&0x00ff)|((x<<8)&0xff00);
8
returnx;
9
}
Nur arbeitet hat das Ding einen Nachteil: es arbeitet konstant mit der
Länge 16 ;-)
Da ich heute zufällig beim Durchforsten des Sources nach
Optimierungsmöglichkeiten bemerkt habe, dass die RECS80-Startbit-Timings
komplett falsch in IRMP definiert waren, habe ich die Timings nicht nur
angeglichen, sondern auch noch zusätzlich die Erkennung des "RECS80
Extended-Protokolls" eingebaut, damit ich endlich mal selbst ein paar
Technisat-FBs von Pollin (für 95 Cent!), die den SAA3008 (und damit das
RECS80EXT-Protokoll) benutzen, testen kann.
Vorab schon mal eine neue Version von IRMP unter
http://www.mikrocontroller.net/articles/IRMP#Download
Die Erweiterung auf RECS80EXT kostete nur 50 Bytes im Binary, ist aber
selbstverständlich - wie alle anderen Protokolle auch - abstellbar.
Und noch eine Neuigkeit:
Das kompilierte Binary von IRMP ist - trotz der Erweiterung auf
RECS80EXT - durch diverse Code-Optimierungen, die ich in den letzten
Tagen vorgenommen habe, nun ca. 350 Bytes kleiner geworden :-)
Gruß,
Frank
IRSND ist nun auch angepasst, Änderungen:
- Korrektur der RECS80-Startbit-Timings
- Neues Protokoll: RECS80 Extended
- Diverse Codeoptimierungen, u.a. die von Werner, siehe oben.
Download:
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Gruß,
Frank
Frank M. schrieb:
> Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein> besserer eingefallen ;-)
z.B. bitsreverse
Edit:
ich sehe gerade deinen Coding Style. Also besser bits_reverse.
Werner B. schrieb:
> z.B. bitsreverse
Sehr gut. Habe ich gerade übernommen. Ebenso noch eine Korrektur für
TCCR2,
Dank an Werner. Download ist aktualisiert.
> Edit:> ich sehe gerade deinen Coding Style. Also besser bits_reverse.
Nö, die erste Version finde ich besser. Man kanns mit den Underscores
auch übertreiben ;-)
Gruß,
Frank
DiPi schrieb:
> In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...
mirror() bzw. mirror_bits() habe ich auch schon mal gesehen,
bitsreverse() finde ich aber am aussagekräftigsten.
Gruß,
Frank
Hallo Frank,
habe heute die neuen IRMP für neue scans genutzt. Anbei 2 scans, einmal
von meiner Kathrein UFS912 FB - ein RC6 Code. Da stimmt wohl irgendetwas
noch nicht... Ich habe 2 Tasten jeweils 3mal einzeln gedrückt. Das
Einzige, was sich im Command ändert, ist das LSB. Dies ist jedoch das
Togglebit wie es mir scheint. Mehr ändert sich am Command nicht, egal
welche Taste gedrückt wird. Auch bei RC5 Commands habe ich den Effekt
beobachtet. Leider kann ich keinen RC5 scan machen weil der Controller
abstürzt.
Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes
Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.
Soviel für heute...
-Peter
Hallo Frank,
hier noch ein Nachtrag zum Thema IRMP und IRSND: Habe einige Tests mit
Kaseikyo (Panasonic Blue Ray) gemacht.
Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie
jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code
wieder mit IRSND aussende, passiert am Player nichs.
IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32
Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.
Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch
einige Problemchen - siehe meinen vorherigen post.
-Peter
Hi Peter,
Peter K. schrieb:
> Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie> jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code> wieder mit IRSND aussende, passiert am Player nichs.
Siehe IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
Zitat:
| IRSND unterstützt folgende Protokolle (noch) nicht:
|
| * KASEIKYO
| * RC6
Um aus den 32-bit-IRMP-Daten wieder das 48-Bit-Kaseikyo-Protokoll zu
reproduzieren, ist noch ein wenig Gehirnschmalz bzw. Verständnis
meinerseits bzgl. Kaseikyo notwendig. IRMP filtert aus dem
Kaseikyo-Protokoll nur das raus, was zum Decodieren interessant ist,
Parity-Bits und andere Infos gehen dabei verloren. Beim Encodieren
braucht man sie dann aber wieder. Da muss ich noch ein wenig forschen,
um die Parity-Bits und den Rest im IRSND wieder zu rekonstruieren: 32
Bit IRMP -> 48 Bit Kaseikyo.
> IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32> Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.
Freut mich :-)
> Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch> einige Problemchen - siehe meinen vorherigen post.
RC6 ist ein komplexes System von variablen Modi: je nach RC6-Modus sind
die RC6-Daten komplett anderes strukturiert. Im Moment ist RC6 ein
erhebliches Problem, da IRMP im Moment nur den sogenannten Mode0
unterstützt. Die Kathrein-FB benutzt aber einen anderen Mode - mit
erheblich mehr Bits im Telegramm. Da sind dann nur spärliches Infos zu
finden. Ich bin aber weiterhin dran.
Danke für die Scans, werde ich mir anschauen.
Gruß,
Frank
Peter K. schrieb:
> Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes> Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.
Ich habe mir das Protokoll angeschaut, das ist was ganz Neues, aber auch
ziemlich triviales. Ich habe es mal eingebaut in den IRMP, verbrät
zusätzliche 50 Bytes an Code, ist natürlich abschaltbar.
Wie die anderen Protokolle auch ist das "NUBERT-Protokoll" (so habe ich
das mal getauft, solange es da keine Vergleichsvariante gibt) im
IRMP-Artikel dokumentiert.
Es hat 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit und wird immer 2x
gesendet.
Die Timings habe ich empirisch aus dem Scan ermittelt.
Die automatische Wiederholung wird von IRMP unterdrückt, eine
Wiederholung durch langen Tastendruck wird von IRMP im Flags-Byte
gekennzeichnet - so wie sich das gehört ;-)
Wie sich diese 10 Bit Daten in Adresse + Kommando aufteilen, weiß ich
nicht, da ich keine Dokumentation dazu gefunden habe. Hat Deine
Nubert-FB noch mehr Tasten? Deine 2 Tasten zur Analyse, wie sich Adresse
und Kommando aufteilen, sind da als Vergleich ziemlich mager ;-)
Ich habe daher alle 10 Daten-Bits in das Kommando gelegt, d.h. als
Adresse gibt IRMP immer 0 zurück.
Achja: Deine beiden Volume-Tasten senden das Kommando 0x0082 und 0x0084.
Neue Version von IRMP unter
http://www.mikrocontroller.net/articles/IRMP#Download
Gruß,
Frank
Nun gibt es auch eine neue Version von IRSND.
Download:
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen:
* Neues Protokoll: Nubert
Damit kann Peter nun seine Subwoofer auch über IRSND voll
aufdrehen ;-)
* Korrektur der Pausen zwischen Wiederholungen von Frames
Gruß,
Frank
Hallo,
damit zur Software auch ein Stück Hardware zum ausprobieren kommt, habe
ich heute mein kleines IR-LCD Projekt online gestellt.
Die Hardware basiert auf der IRMP und IRSND Software von Frank mit ein
paar kleinen Erweiterungen. Die Software wird auch noch ein bischen
wachsen ;-)
Schaut es Euch mal an, Feedback auch gerne hier im Forum, so lange es
Frank nicht zu lästig wird ;-) sonst eröffne ich einen neuen Beitrag.
Viele Grüße und viel Spaß,
Klaus
Das komplette Projekt findet Ihr hier:
http://www.mikrocontroller-projekte.de -> IR-LCD
@Klaus Leidinger,
da IR Sendedioden (zumindest meine hier) im Impulsbetrieb bis zu 3A für
10uS verkraften, kannst du R2 auf fast 1 Ohm verkleiner (Ich verwende
1,2 Ohm).
Das erhöht die Reichweite beträchtlich. R3 begrenzt den Strom falls sich
der AVR mal "aufhängt" (Wobei ich nicht verstehe warum die Sendediode
und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc
und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren
C spendieren).
Gruß
Werner
Werner B. schrieb:
> (Wobei ich nicht verstehe warum die Sendediode> und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc> und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren> C spendieren)
Senden und Empfangen wird ja nicht gleichzeitig benutzt, und die
Sendediode soll ja aus dem Elko gespeist werden. Außerdem war es schon
recht eng ;-)
Je nach Verwendungszweck ist ja eine unterschiedliche Bestückung
machbar. Für eine Entwicklungsplattform war mir der Weg mit lieber "zu
großen" Widerständen sicherer.
Reichweitentests habe ich noch nicht gemacht, ich werde aber gerne Deine
/ Eure Erfahrungen dokumentieren.
Danke für Dein Feedback.
Viele Grüße,
Klaus
Hi eku,
eku schrieb:
> Warum verwendest Du keine Variadic Macros
Weil ich ein alter Knochen bin, der C 1984 unter UNIX kennengelernt
habe. Die Variadic Macros gibt es erst seit 1999. Ich hatte es zwar mal
am Rande mitbekommen, dann aber wieder verdrängt, da ich es damals nicht
brauchte.
Ich werde es bei Gelegenheit umstellen, vielen Dank für den Hinweis.
Gruß,
Frank
Hallo Frank!
Zwei meiner Fernbedienungen können nicht dekodiert werden:
Nokia Dbox2
Siemens Gigaset M740AV
Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1
aufzeichne?
Hallo Frank,
was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine
separate Header-Datei (z.B. irmpconfig.h) auszulagern? Ich finde das
momentan etwas unübersichtlich: jede Menge defines und diese dann auch
noch im .h und im .c verteilt, so dass man (zumindest ich) nicht so
recht weiß an welcher Schraube man drehen kann und was man besser so
belassen sollte.
Ansonsten finde ich dieses Projekt großartig und möchte mich vielmals
dafür bedanken.
eku schrieb:
> Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1> aufzeichne?
Ja, müsste reichen, am besten so viele Tasten wie möglich und dann in
der Form:
# Taste 1
000011110000.......
# Taste 2
000011110000.......
Also pro Taste ein Kommentar, eingeleitet mit '#' und alle Tasten einer
FB in derselben Datei.
Gruß,
Frank
Micha schrieb:
> was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine> separate Header-Datei (z.B. irmpconfig.h) auszulagern?
Ja, ist wohl sinnvoll. Mache ich.
Gruß,
Frank
Hallo Frank,
ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit
dem Verhalten von IRMP irgendwie nicht klar. Dazu anbei die kleine
Log-Datei. Ich habe mal jedes Bit, das irmp_store_bit bekommt, in ein
Array schreiben lassen und schaue es mir nach empfangenen Code an.
Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen
und man kann am Binärcode Adresse und Command gut erkennen.
Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir
überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch
relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt
ist...) erst an 21. Stelle.
Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)
-Peter
Peter K. schrieb:
> ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit> dem Verhalten von IRMP irgendwie nicht klar.
Ich bin selbst nicht mit der Umsetzung des RC6-Protokolls im IRMP
zufrieden. Es funktioniert zwar mit der RC6-Fernbedienung von Klaus
Leidinger, welche im sog. "Mode 0" läuft, aber nicht mit RC6-FBs, die
einen anderen Mode benutzen.
Der "Mode 0" ist hier dokumentiert:
http://www.sbprojects.com/knowledge/ir/rc6.htm
Dabei ist da was ganz fieses drin, nämlich:
"Finally the header is terminated by the trailer bit TR. Please note
that the bit time of this symbol is twice as long as normal bits! This
bit also serves as the traditional toggle bit, which will be inverted
whenever a key is released. This allows the receiver to distinguish
between a new key or a repeated key. "
Das Toggle-Bit ist also doppelt so breit wie die anderen Bits. Im
Zusammenhang mit der Bi-Phase-Codierung haben dann die Pulse und die
Pausen ganz blöde Längen, nämlich - je nach Nachbar-Bits(!) - die ein-
oder 1,5-fache Länge. Das bringt den Code von IRMP arg ins Schleudern.
Ich hatte das damals anhand der Scans von Klaus dann so "hingefrickelt",
aber mir war klar, dass dieser Code nicht allgemeingültig funktionieren
könne.
Mangels anderer RC6-Scans habe ich da aber nichts mehr weiter dran
getan, hat mich schon so genug Nerven gekostet ;-)
Nun habe ich von Dir die Kathrein-Scans erhalten und musste einsehen,
dass meine Art, wie ich Bi-Phase-Signale decodiere, an seine Grenzen
stößt - was auch wieder mit der doppelten Länge des Toggle-Bits zu tun
hat. Dieses folgt nämlich den sog. drei Mode-Bits. Und die haben bei Dir
andere Werte - eben nicht "Mode 0". Und damit funktioniert die Art und
Weise, wie ich die doppelte Länge des Toggle-Bits "behandle", nicht
mehr.
Ich werde also den RC6-Part im IRMP neu schreiben müssen, so hat das
keinen Zweck... einfach zu viel Code-Gebastel und Rumprobiererei.
> Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen> und man kann am Binärcode Adresse und Command gut erkennen.
Ja, bei gleichen Signal-Längen (RC5) funktioniert der Code, bei
wechselnden Bit-Breiten (RC6) macht er die Grätsche.
> Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir> überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch> relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt> ist...) erst an 21. Stelle.
Das sollte eigentlich überhaupt nicht auftauchen, da IRMP die
Toggle-Bits (RC5 und RC6) ignoriert.
> Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)
Ich bin gerade an einem anderen Algorithmus für RC6 dran, habe Dich und
Deine Kathrein-FB nicht vergessen. Allerdings wolltest Du mir noch Scans
von einer weiteren Kathrein-FB zur Verfügung stellen, wenn ich das
richtig in Erinnerung habe.
Achja: dass IRMP "zwischendurch" bei Deiner RC6-FB meint, da plötzlich
RC5-Code zu erkennen, ist leicht erklärt: RC6 benutzt exakt die Hälfte
der Bit-Breite von RC5, nämlich 444µs. Bei einer Bi-Phase-Codierung
addieren sich dann oft die Pulse von 2 Nachbar-Bits auf die doppelte
Breite - und damit exakt auf die Puls-Breite eines RC5-Bits von 889µs.
Gruß,
Frank
Christoph schrieb:
> Wäre es nicht eine gute Idee den Sourcecode in das neue svn> einzustellenß
Danke für die Anregung, ich habe das direkt beantragt und auch schon
einen Platz für IRMP auf dem SVN-Server von mikrocontroller.net von
Andreas erhalten. Ich schiebe den Source demnächst ins SVN und melde
mich dann nochmal dazu.
Trotzdem wird man die Sources auch weiterhin "klassisch" über den
Download-Link herunterladen können.
> Dann müsste man nicht immer den aktuelllen Sourcecode herunterladen.
Das müsstest Du bei SVN ja auch ;-)
Die Verwendung eines SVN bietet eigentlich genau dann Vorteile, wenn
mehrere Leute an einem Source arbeiten. Dafür ist es eigentlich gedacht
- nicht zum Publizieren von Code. Das ist nur ein Seiteneffekt von SVN.
Gruß,
Frank
Hallo Frank!
> Zwei meiner Fernbedienungen können nicht dekodiert werden:>> Nokia Dbox2>> Siemens Gigaset M740AV
LIRCD kennt die Siemens Gigaset Fernbedienung als
bits 8
eps 30
aeps 100
one 0 0
zero 0 0
pre_data_bits 24
pre_data 0x10
gap 210000
min_repeat 2
toggle_bit 25
Hallo Frank,
danke für die prompte Antwort. Ja, die zweite Kathrein-FB... Die ist
etwas ein Sorgenkind, wahrscheinlich ist es kein RC6 Code. Ich kann mit
der neuesten Version von IRMP nichts scannen. IRMP in einer
Test-Compilierung reagiert gar nicht darauf. Allerdings - und das ist
merkwürdig, habe ich die gleiche IRMP-Version in meinem eigentlichen
Projekt zusammen mit Softwaremodulen des U.Radig-Webservers compiliert.
Dort zeigt IRMP an, dass diese FB RC5 machen würde. Allerdings reportet
IRMP jedes Mal andere Cmd / Addr, so dass ich annehme, das da irgendwas
in der Decodierung nicht stimmt. Leider ist bei diesem Projekt der RAM
schon so voll, dass ich kein IRMP Logging mehr machen kann. Also komme
ich momentan beim Scannen dieser 2. FB nicht so richtig voran. Mal
schaun was ich da noch machen kann.
Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne
Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich
immer genau auf bestimmte Releases beziehen.
-Peter
Hallo Peter,
Peter K. schrieb:
> Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne> Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich> immer genau auf bestimmte Releases beziehen.
Ja, hatte ich auch schon mal dran gedacht. Die nächste Version wird dann
einfach mal 1.0 heißen ;-)
Gruß,
Frank
Hi eku,
eku schrieb:
>> Zwei meiner Fernbedienungen können nicht dekodiert werden:>>>> Nokia Dbox2>>>> Siemens Gigaset M740AV>> LIRCD kennt die Siemens Gigaset Fernbedienung als> [...]
Ich hatte Dir darauf schon mal geantwortet:
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Schick mir einfach Scans und ich versuche, diese FBs einzubauen -
entweder durch Vergrößerung der Toleranzen des jeweiligen (bekannten)
Protokolls oder durch neue Parametrisierung.
Gruß,
Frank
IRMP ist jetzt auch im SVN auf mikrocontroller.net:
http://www.mikrocontroller.net/svnbrowser/irmp/
Ich werde den Link auch noch in den IRMP-Artikel einfügen, den
Download-Link im Artikel wird es aber auch weiterhin geben.
Gruß,
Frank
Andreas Schwarz schrieb:
> Du kannst auch direkt auf einen aktuellen Snapshot als .tar.gz> verlinken, dann musst du nicht von Hand ein Paket erstellen:> http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar
Danke für den Tipp, hatte ich schon gesehen bzw. kenne ich schon aus
anderen Open-Source-Projekten. Das tar.gz-Format ist in der Windows-Welt
leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts
anfangen - erst wenn ich die Datei in .tgz umbenenne.
Wäre es auch möglich, den Tarball als "Zipball" zur Verfügung zu
stellen? Dann wäre es ideal.
Gruß,
Frank
Frank M. schrieb:
> Das tar.gz-Format ist in der Windows-Welt> leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts> anfangen - erst wenn ich die Datei in .tgz umbenenne.
Mit 7-Zip funktioniert es auch unter Windows ohne Probleme.
Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
worden. Die Binaries und der Code für den PC könnte man doch in ein
Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
Simon K. schrieb:
> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen> worden. Die Binaries und der Code für den PC könnte man doch in ein> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen
Code", der Source ist für beide derselbe. Das einzige, was hier
PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.
Dafür bedarf es meiner Meinung nach keines Unterverzeichnisses.
Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
vielen Threads herum, lässt seinen Mecker los und verschwindet dann
wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
nehmen.
Gruß,
Frank
Hi Vlad,
Vlad Tepesch schrieb:
> Das größere Problem an dem SVN repository ist, dass auf Top-Level-Ebene> keine Ordner für Branches oder Tags angelegt wurden.
Hätte ich diese anlegen können/müssen? Das Repository hat Andreas
Schwarz auf meine Bitte hin angelegt. Ich musste dann nur noch die
Dateien reinschieben. Muss Andreas als SVN-Verwalter da was tun oder
kann ich das auch als reiner "SVN-Anwender"?
Gruß,
Frank
Hallo zusammen,
erstmal höchstes Lob für dieses Projekt an Frank M. und seine Helfer!
Ich teste derzeit ein wenig mit dem IRMP und mir stellt sich folgende
Frage:
Durch das IRMP_FLAG_REPETITION kann ich auswerten, ob eine Taste kurz
oder lange gedrückt wurde. Aber wie erfahre ich wann sie losgelassen
wird/wurde?
> Beispiel:>> if (irmp_data.flags & IRMP_FLAG_REPETITION)> {> finger_blau (irmp_data.command);> }> else> {> einzeln (irmp_data.command);> }> Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu> "entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION> ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die> wiederholte Auswertung ein und desselben Kommandos aber durchaus> gewünscht sein - zum Beispiel, um LEDs zu faden.
Wenn ich mit meiner FB im NEC Protokoll die "Plus" oder "Minus" Taste
länger gedrückt halte, bekomme ich zwar bei der zweiten Auswertung das
Repetition Flag gesetzt, aber weiter bekomme ich keine Auswertungen,
d.h.ich bekomme nicht mit, wann die Taste losgelassen wurde :-)
Oder habe ich da einen falschen Denkansatz...
Gruß Jens
naja, wenn das signal nicht mehr kommt, wurde die taste losgelassen. Die
FBs senden ja keine extra-sequenz, wenn man eine taste loslässt.
Sie senden nur solange die taste gedrückt ist immer wieder in festen
zeitabständen eine bestimmte bitfolge, die IRMP immer wieder aufs neue
interpretiert.
@ Di Pi
Guten Morgen,
die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen
(mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem
IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.
Also, das/mein Problem muss woanders liegen
Gruß Jens
Hallo Jens,
Jens C. schrieb:
> die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen> (mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem> IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.
Ich habe das mal gerade emuliert mit dem IRMP-Executable und
IR-Data/nec-repetition.txt. Da gibt es tatsächlich ein Problem mit den
Wiederholungen von Repetition-Frames. Diese werden zwar erkannt, aber
bis auf den ersten Repetition-Frame werden alle weitere verworfen.
Ich schaue gleich mal nach dem Grund und melde mich dann nochmal.
Gruß,
Frank
P.S.
Ich hatte Dein Schreiben auch erstmal so verstanden wie Di Pi...
Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich
lösen. Daher gibt es eine neue Version zum Download:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Bugfix beim Erkennen von mehrfachen NEC-Repetition-Frames
- Konfiguration in irmpconfig.h ausgelagert, siehe Doku im
IRMP-Artikel
- Einführung einer Programmversion in README.txt: Version 1.0
Frank M. schrieb:
> Simon K. schrieb:>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen>> worden. Die Binaries und der Code für den PC könnte man doch in ein>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.>> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen> Code", der Source ist für beide derselbe. Das einzige, was hier> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.
Ach so. Aber die Source Files kann man doch von den Executables
separieren.
> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in> vielen Threads herum, lässt seinen Mecker los und verschwindet dann> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst> nehmen.
Was lässt dich das annehmen? Soll ich mich dafür entschuldigen, dass ich
nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man
sich auch der Kritik annehmen können. Ansonsten könntest du deinen Kram
nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.
Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf
mich einen ziemlich eingebildeten Eindruck.
>> gefunden in main.c im Codevison Teil.>> Warum das ?
Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um
die Sources alle ins main zu integrieren, damit man sie dann alle durch
einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine
andere Möglichkeit gibt (Erstellen eines Makefiles etc), um die einzeln
zu übersetzenden Module zusammenzulinken, entzieht sich meiner Kenntnis.
Wenn Du es besser weisst, wäre ich für Verbesserungsvorschläge dankbar.
Gruß,
Frank
Simon K. schrieb:
> Frank M. schrieb:>> Simon K. schrieb:>>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen>>> worden. Die Binaries und der Code für den PC könnte man doch in ein>>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.>>>> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen>> Code", der Source ist für beide derselbe. Das einzige, was hier>> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.>> Ach so. Aber die Source Files kann man doch von den Executables> separieren.
Schauen wir mal in die Liste der Dateien im SVN:
IR-Data/
README.txt
irmp.aps
irmp.c
irmp.exe
irmp.h
irmpconfig.h
irsnd.aps
irsnd.c
irsnd.exe
irsnd.h
irsndmain.c
main.c
Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository,
die übrigens im dazugehörenden Artikel
http://www.mikrocontroller.net/articles/IRMP ausführlichst dokumentiert
sind. Gestern waren es übrigens sogar noch lediglich 9 Dateien.
Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich
nur die Ignore-List unter
http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus
dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist.
Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im
Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich
lesen".
Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis,
um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen
zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in
einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner
IR-Data ein wenig komplizierter und für den Anwender unverständlicher -
Stichwort: "../IR-Data".
>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst>> nehmen.>> Was lässt dich das annehmen?
Weil es mir schon mal sauer aufgestoßen ist, nämlich im
WordClock-Thread:
http://www.mikrocontroller.net/topic/156661#1482557
Zitat:
| Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig
| "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche
| "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im
| Desaster.
Mittlerweile wurden 320 Platinen der "amateuerhaften"
WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind
180 dazugehörende Frontplatten produziert worden. Die "amateurhafte"
Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels
HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.
Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich
erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die
Leute von oben herab behandelst?
> Soll ich mich dafür entschuldigen, dass ich> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
Nein, mich stört das
Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an
das Markieren-Gehabe von Katzen.
> Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man> sich auch der Kritik annehmen können.
Du nennst das "Kritik". Ich nicht.
> Ansonsten könntest du deinen Kram> nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.
Wenn Du Dir diesen Thread (oder auch den WordClock-Thread) mal
genauestens durchlesen würdest, wirst Du feststellen, dass ich auf
angebrachte Kritik immer eingegangen bin. Deine Kritik ist aber
einfach nur von oben herablassend, deshalb schreibst Du ja jetzt hier
auch wieder mal "deinen Kram". Diese Formulierung spricht Bände.
> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf> mich einen ziemlich eingebildeten Eindruck.
Glashaus, Steine.
Gruß,
Frank
Frank M. schrieb:
>>> #include "irmp.c">> >>> gefunden in main.c im Codevison Teil.>>>> Warum das ?>> Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um> die Sources alle ins main zu integrieren, damit man sie dann alle durch> einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine
Ja, genau das ist der Grund.
Alle die sich mit CV auskennen, wissen natürlich das das auch im Setup
eingestellt werden kann... und können es problemlos ändern. So brauche
ich das Projektfile nicht dazupacken.
Viele Grüße,
Klaus
Frank M. schrieb:
> Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository,
Du bist echt nicht kritikfähig. Beruhig dich, lass es halt so, aber
unterlasse solche dämlichen Bemerkungen, dass ich nicht ernst zu nehmen
sei.
EDIT: Der einzige der hier Leute von oben herab behandelt bist du, wenn
überhaupt.
> Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich> nur die Ignore-List unter> http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus> dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist.> Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im> Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich> lesen".
Nö habe ich nicht.
> Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis,> um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen> zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in> einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner> IR-Data ein wenig komplizierter und für den Anwender unverständlicher -> Stichwort: "../IR-Data".
Ist doch wunderbar, wie gesagt, dann lass es halt so. Es ist ja dein
Projekt.
>>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in>>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann>>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst>>> nehmen.>>>> Was lässt dich das annehmen?>> Weil es mir schon mal sauer aufgestoßen ist, nämlich im> WordClock-Thread:>> http://www.mikrocontroller.net/topic/156661#1482557>> Zitat:>> | Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig> | "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche> | "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im> | Desaster.
Ganz toll, da kann selbst ich mich nicht mehr dran erinnern.
> Mittlerweile wurden 320 Platinen der "amateuerhaften"> WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind> 180 dazugehörende Frontplatten produziert worden. Die "amateurhafte"> Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels> HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.
Schön, habe ich mich halt geirrt. Irren ist menschlich. Zu dem Zeitpunkt
wo ich das gepostet hat, war das auch (von mir) so noch nicht abzusehen.
Oder willst du mir jetzt vorhalten, dass ich mich geirrt habe? Ich habe
nämlich kein Problem damit.
Außerdem: Wo denn sonst noch? Liest du alle Threads in denen ich poste?
> Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich> erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die> Leute von oben herab behandelst?
Haha, ist klar! Kritikfähigkeit, wo bist du? Oberlehrerhaft? Ich denke
wir missverstehen uns.
>> Soll ich mich dafür entschuldigen, dass ich>> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?>> Nein, mich stört das> Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an> das Markieren-Gehabe von Katzen.
Und mich stört das: Du urteilst über Sachen die du nicht weißt. Ich habe
ein paar Wochen lang den Thread verfolgt, bis es mir zu viele Posts
wurden pro Tag.
>> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf>> mich einen ziemlich eingebildeten Eindruck.>> Glashaus, Steine.
Ja, oder so ähnlich.
Der schlauere gibt auch nach. In dem Sinne.
Hugo Portisch schrieb:
> jetzt muss ich wegen der Logging Funtkion einmal nachfragen:> Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix> defined!?
Ja, momentan sind es zwei. Früher waren es mal 4, aber dann lief der
Scanner bei sehr kurzen Impulsen erst gar nicht los. Daher hab ich das
auf 2 geändert. Davon solltest Du aber nicht ausgehen, dass das so
bleibt. Vielmehr solltest Du für das Logging über USB einfach die Zahl
c_startcycles übertragen und nicht das c_startcycles x Nullen. Der PC
kann dann aus der Zahl 2 (oder 4 oder wasweiss ich) einfach zwei 0en
machen.
Gruß,
Frank
Frank M. schrieb:
> Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich> lösen.
[...]
Auch von mir ein Dankeschön, auch wenn's erst spät kommt. Ich bin zur
Zeit "etwas" überlastet und erst heute zum ausprobieren gekommen.
Gruß
f
Hallo Frank,
das Projekt ist echt supper Großes lob!
Eine frage hätte ich allerdings.
Ist es theroretisch auch möglich die IR-Signale einer
Bang & Olufsen FB zu erkennen?
Problem könnte sein das die Trägerfrequenz bei 455Khz liegt,
und ich nix brauchbares zum Protokoll gefunden habe.
(Kann mann da evtl die eingangsschaltung anpassen oder
geht das mit dem aufbau)
Gruß
Da bin ich mal gespannt...
Hatte noch vergessen zu erwähnen das ich im Forum
ein Projekt von Rene
(http://www.gutwenger.com/ -> Projekt Beo2pc) gefunden habe
Da stört halt das Beolink "Auge",welches er als
empfänger nutzt, für 70,- =)
Frank Lorenzen schrieb:
> Morgen oder übermorgen werde ich eine B&O FB aufzeichnen und die Daten> an Frank schicken.
Hi Frank,
welchen Empfänger zum demodulieren benutzt Du für die B&O Signale? Die
IR sendet ja mit 455KHz. Hast Du den von B&O oder einen TSOP7000
aufgetrieben? (wo?)
Danke für eine Info,
Klaus
Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell
bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr
erhältlich weil abgekündigt.
TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht
fragst du bei denen mal an ob sie erwarten nochmal welche zu bekommen?
Bei TME nicht von den Preisen verwirren lassen! Die muß man erst von
Zloty auf Euro umstellen ;-)
HtH.
Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000
abgekündigt ist
Gruß
f
Es gibt hier http://www.vishay.com/ir-receiver-modules/agc-list ein
Hilfstool zur Auswahl, aber ich bin etwas verunsichert. Ich würde gerne
möglichst viele Protokolle empfangen können, daher sollte es ein
AGC1-Receiver werden. Auf der anderen Seite ist dieser am
empfindlichsten ggü. Störungen - stellt dies für IRMP ein Problem dar?
Der Empfänger läuft als IR-Tastatur von ione und ich habe (noch) keine
Ahnung welches Protokoll das ist. Ein TSOP17xx kommt nicht in Frage, da
ich nur 3,3V zur Verfügung habe.
455KHz ist eine gängige Frequenz für ZF-Verstärker im HF-Bereich. Im
Prinzip kann man also alles aus diesem Bereich übernehmen. Eine
Fotodiode mit TCA440 beispielsweise.
Ich weiß leider nicht einmal die Frequenz. Ich habe beim Hersteller aber
eben wegen des Protokolls angefragt - mal sehen was die antworten.
Vielleicht ist es ja irgendein bereits unterstütztes Standardprotokoll.
Zum Thema B&O Fernbedienungen habe ich gestern von einem Bekannten recht
interessante Informationen bekommen:
Das B&O Fernbedienungs-System wurde wohl bisher von Loewe hergestellt.
Da Loewe aber mittlerweile zu großen Teilen von Sharp aufgekauft wurde
und Sharp an der Produktion von Baugruppen für B&O wohl wenig Interesse
zeigt wird es in Zukunft wohl ein neues FB-System von B&O geben.
Man munkelt die Fernbedienung soll der Harmony sehr ähnlich sehen ;-)
Ob dieses System dann aber noch 455kHz IR unterstützt?
Gruß
f
Frank Lorenzen hat mir die B&O-Daten geschickt, ein Scan hat aber erst
mit einer Interrupt-Frequenz von 15kHz funktioniert, da die Pulsdauern
extrem kurz sind und die Scan-Routine erst bei einer Mindestlänge
startet.
Interessantes Protokoll, was da benutzt wird. Die Pulsdauern sind immer
gleich, im Durchschnitt lediglich 210 usec, das spart Strom. Die Pausen
bestimmen die Wertigkeit der Bits - wie bei den meisten anderen
Protokollen auch.
Der Aufbau ist:
4 Startbits + 18 Datenbits.
1. Startbit: Pause 3000 usec, entspricht einer 0
2. Startbit: Pause 3000 usec, entspricht einer 0
3. Startbit: Pause 15000 usec, das eigentliche Startbit
4. Startbit: Pause 3000 usec, entspricht einer 0
Die Werte der 18 Datenbits selbst werden über drei statt zwei
verschiedenen Pausenzeiten gebildet, das macht das ganze so besonders:
Pause 3000 usec: 0
Pause 9000 usec: 1
Pause 6000 usec: Wiederholung des letzten Bits
Mit dieser Regel werden aus den Tasten "0" bis "9" die numerischen Werte
0 bis 9, das passt also ganz gut. Eine Adresse scheint die FB nicht
auszusenden, die ersten drei Datenbits sind immer 0, so passen die 18
Bits glücklicherweise gut in die 16 Code-Bits von IRMP.
War nicht ganz einfach, das Ding zu knacken - wegen der dritten
Pausenzeit von 6000 usec, die ich erstmal verstehen musste. Morgen baue
ich den Algorithmus in den IRMP ein, vervollständige die Protokoll-Doku
im IRMP-Artikel und stelle eine neue Version zum Download zur Verfügung.
Gruß,
Frank
Version 1.1 von IRMP ist verfügbar:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Neues Protokoll: BANG_OLUFSEN (B&O)
@Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte
einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der
Scan-Datei testen konnte. Danke Dir noch einmal für die Scan-Datei,
diese ist nun auch im Verzeichnis IR-Data abgelegt, einmal als 10kHz-
und einmal als 15kHz-Verion.
Gruß,
Frank
Micha schrieb:> Würde es sich bzgl. deiner Änderung von eben [...] nicht anbieten ein enum> zu verwenden, oder gibt es bestimmte Gründe warum du das nicht machst?
Natürlich kann ich auch ein enum nehmen. So habe ich halt die Zahlen
konkret vor mir und muss nicht immer mit dem Finger abzählen, was denn
nun die IRMP-Ausgabe "protocol = 14" konkret bedeutet ;-)
Okay, ich stelle das beim nächsten Update um.
Gruß,
Frank
Micha schrieb:> Du kannst ja auch dort den (?) enum nehmen... Also z.B.> "protocol = IRMP_BANG_OLUFSEN_PROTOCOL"
Ja, das ist mir schon klar, dass ich das kann. Mir ging es darum, dass
jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer
numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die
"14" bedeutet.
> Siehe:> http://openbook.galileocomputing.de/c_von_a_bis_z/015_c_strukturen_010.htm
Mir sind enums nach mittlerweile 25 Jahren C-Programmierng wohlbekant,
aber danke für den schönen Link ;-)
Gruß,
Frank
Frank M. schrieb:> Mir ging es darum, dass> jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer> numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die> "14" bedeutet.
Verstehe. Damit hast du natürlich recht. Das war nur ein Vorschlag und
deswegen stellte ich oben die Frage nach den Gründen...
Micha schrieb:> Nachteilig ist allerdings der erhöhte Speicherbedarf, da enums 16bit> haben (können?)...
enums werden immer auf den kleinst-möglichen Typ abgebildet, der möglich
ist.
Beispiel A:
1
enumzahl{NU_LL,EINS,ZWEI,DREI,VIER};
2
3
uint8_t
4
funktion(enumzahlxx)
5
{
6
xx>>=4;
7
returnxx;
8
}
Dann steht in der lss-Datei:
1
00000046<funktion>:
2
uint8_tfunktion(enumzahlxx)
3
{
4
xx>>=4;
5
returnxx;
6
}
7
46:8295swapr24
8
48:8f70andir24,0x0F;15
9
4a:0895ret
Die lss-Datei ist dann identisch beim Code von:
1
uint8_tfunktion(uint8_txx)
2
{
3
xx>>=4;
4
returnxx;
5
}
Die Variable xx ist also in beiden Fällen 8 Bit breit.
Beispiel B:
1
enumzahl{NU_LL=-2,EINS,ZWEI,DREI,VIER};
2
3
uint8_t
4
funktion(enumzahlxx)
5
{
6
xx>>=4;
7
returnxx;
8
}
Jetzt braucht die Beispiel-Funktion wesentlich mehr Speicherplatz:
1
00000046<funktion>:
2
uint8_t
3
funktion(enumzahlxx)
4
{
5
xx>>=4;
6
returnxx;
7
}
8
46:8595asrr24
9
48:8595asrr24
10
4a:8595asrr24
11
4c:8595asrr24
12
4e:0895ret
EDIT:
Hier wird 4x mittels asr geschoben, weil nun int8_t statt uint8_t
verwendet wird.
Beispiel C:
1
enumzahl{NU_LL=300,EINS,ZWEI,DREI,VIER};
2
3
uint8_t
4
funktion(enumzahlxx)
5
{
6
46:24e0ldir18,0x04;4
7
48:9695lsrr25
8
4a:8795rorr24
9
4c:2a95decr18
10
4e:e1f7brne.-8;0x48<funktion+0x2>
11
xx>>=4;
12
returnxx;
13
}
14
50:0895ret
Hier wird dann tatsächlich eine 16-Bit-Operation verwendet, weil der
Wertebereich von 0-255 überschritten wurde.
Ergo: Wenn man den Wertebereich von 0 bis 255 nicht überschreitet, ist
alles in Butter. Trotzdem lasse ich das so, wie es ist - aus obigen
Gründen.
Gruß,
Frank
Frank M. schrieb:
[...]
> Änderungen:> - Neues Protokoll: BANG_OLUFSEN (B&O)>> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der> Scan-Datei testen konnte.
Das ging aber schnell! Ich teste selbstverständlich - leider nicht mehr
heute sondern erst morgen, mein Testaufbau hat aus unerfindlichen
Gründen den Geist aufgegeben.
Ich habe noch eine zweite B&O Fernbedienung gefunden, sieht von Design
auch wie eine Beolink 1000 aus hat aber weniger und anders beschriftete
Tasten ("Video Terminal Bang & Olufsen" steht drauf). Die Teste ich
morgen gleich mal mit.
Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für
die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft
ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen
könnte.
Gruß,
f
Frank Lorenzen schrieb:> Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für> die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft> ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen> könnte.
Die kannst Du ja dann bei der Gelegenheit mal direkt scannen und mir die
Datei zuschicken.
Gruß,
Frank
[...]
>> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte>> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der>> Scan-Datei testen konnte.
[...]
Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.
Danke dir.
Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.
Gruß,
f
Frank Lorenzen schrieb:> Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.
Freut mich.
> Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.
Danke für den Test - auch wenn ich Dir nicht den Schlaf rauben wollte
;-)
Gruß,
Frank
Hallo Zusammen,
habe einige Probleme IRMP+IRSND für einen IR-Tranciever gemeinsam zum
Laufen zu bewegen.
AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9, Kompilleren klappt, Flashen
auch, irsndmain.c wird nicht mitkompilliert.
Mangels MAX232 und LCD wollte ich einfach eine Led toggeln, damit ich
erkennen kann, ob definierter Tastendruck erkannt wird. Das habe ich
ohne Erfolg mit TSOP7000 (B&O) und TSOP1738 (Apple) probiert. Output
TSOP hängt an Pin9. Der TSOP1738 könnte auch ein TSOP1736 sein. Kam aus
der Bastelkiste und ich kann mich nicht mehr genau erinnern, welchen ich
damals bestellt hatte.
In der Steckbrett-Schaltung ist zusätzlich ein BC548 mit Fotodiode oder
einfache Led an Pin17 untergebracht. Ein irmp_send_data lässt die
normale Led zumindest wie ein IR-Code blinken, aber mit einer Fotodiode
reagiert kein getestetes Gerät.
Jetzt ein anderer Test: Direktes Durchschleifen des IR-Signals auf eine
normale Led, die dann in der Theorie genauso blinken sollte wie der
empfangene Code. TSOP7000 keine Reaktion. Beim TSOP1738 reagiert die
Led ab und zu mal auf einen Tastendruck - die Led blinkt aber nur sehr
kurz auf und das sieht keinesfalls wie ein IR-Code-Blinken aus. Auf eine
RC5-FB reagiert er gar nicht.
Entweder liegt ein einem fehlerhaften zusammenfügen der Sourcen von IRMP
und IRSND und der Anpassungen an den Atmega8 oder an der Schaltung? Oder
beides ;-)
Habe den Quell-Code mal angehängt. Wäre für einen Hinweis dankbar.
Gruß, Kum
Hallo noch mal,
also ich vermute ein Timing-Problem. Beim Empfang funktioniert es schon
nicht richtig und ab und zu denkt irmp es hätte was dekodiert und
schickt dieses verkrüppelte Paket an irsnd und daher blinkt es mal kurz
auf. Lasse ich ein definiertes Paket direkt von irsnd abarbeiten, dann
erscheint es wie IR-Code-Blinken, aber wahrscheinlich zu langsam bzw.
irgendwie fehlerhaft. Komme einfach nicht dahinter...
Viele Grüße, Kum
Lieber Frank, Lieber Frank,
wie peinlich. Den Kalkulator von Mark (<-- auch ein ganz, ganz netter
Kerl) habe ich benutzt und war mir da auch ganz sicher. Oje, oje, ist
das peinlich ... vielen, vielen Dank für den Hinweis. Neue Fuses: die
Schaltung und das noch viel tollere Stück Software rennt wie der Teufel!
Dann kann ich jetzt weiter damit rumspielen ... ich freu mich.
Viele Grüße, Kum
Hallo Frank L. und B&O Anwender,
Frank Lorenzen schrieb:> Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell> bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr> erhältlich weil abgekündigt.>> TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht> ...> Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000> abgekündigt ist>
Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten,
dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens
sortiert (nicht nur) im Bereich IR-Empfänger.
Ich hoffe das war keine unzulässige Werbung...
Viele Grüße,
Klaus
Klaus Leidinger schrieb:> Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten,> dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens> sortiert (nicht nur) im Bereich IR-Empfänger.>> Ich hoffe das war keine unzulässige Werbung...
Gerade diese Tips, bezüglich Lieferquellen, finde ich besonders wertvoll
!!
Noch einen schönen Abend
Gruß
Siegmar
Hallo Zusammen,
stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im
Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code
kein
#define IRSND_SUPPORT_APPLE_PROTOCOL
finden. Auch kein umswitchen von NEC zu Apple analog zu IRMP. Dort wird
zunächst NEC geprüft, und dann auf Apple geswitched, weil Protokolle
sehr ähnlich. Bei IRSND müsste es doch eine ähnliche Vorgehensweise
geben, oder nicht? Wenn Apple --> switch zu NEC. Diesen Part kann ich
aber nirgends finden.
Vielen Dank, Kum
J. Kum schrieb:> stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im> Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code> kein>> #define IRSND_SUPPORT_APPLE_PROTOCOL>> finden.
Tut mir leid, das hat historische Gründe:
Das Apple-Protokoll lief früher im IRMP als NEC-Protokoll mit einem
bestimmten Bit-Muster in den Datenbits des Frames (keine Invertierung,
sondern festes Bitmuster in den Datenbits 24 bis 31). Später habe ich
das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach
vergessen. Ich werde das im IRSND nachholen.
Gruß,
Frank
Frank M. schrieb:
> Später habe ich> das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach> vergessen. Ich werde das im IRSND nachholen.
Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen
es in irsnd.c einzupflegen, aber das ging vollends in die Hose.
Vielen lieben Dank für dein Engagement.
Viele Grüße, Kum
J. Kum schrieb:> Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen> es in irsnd.c einzupflegen, aber das ging vollends in die Hose.
Hier ist der Fix, den kannst Du in irsnd selbst einbauen:
Wie bisher:
1
caseIRMP_NEC_PROTOCOL:
2
{
3
...
4
}
Darunter einfügen (also noch vor dem #endif:
1
caseIRMP_APPLE_PROTOCOL:
2
{
3
irsnd_protocol=IRMP_NEC_PROTOCOL;// APPLE protocol is NEC with fix bitmask instead of inverted command
Das wars. Ein IRSND_SUPPORT_APPLE_PROTOCOL wird es nicht geben, denn es
ist einfach IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen. Ich werde das
auch so nochmal im IRMP-Artikel erläutern.
Gruß,
Frank
Neue Version von IRSND im Downloadbereich:
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen:
- Unterstützung des APPLE-Protokolls
- Konfiguration über irmpconfig.h - analog zum IRMP
- Einige Codeoptimierungen, um Flash-Speicher zu sparen
Viel Spaß,
Frank
Hallo Frank,
endlich bin ich heute dazu gekommen den IRMP mal aufzubauen und zu
testen. Hab mal alle FB aus meinem Sortiment zu Hause rausgekramt, um zu
sehen, was die alle so "senden". Da kamen schon einige Protokolle
zusammen:
NEC, RC5x, RC5, SIRC, RC6, KASEIKYO
Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ:
TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es
möglich ist, diese mit in IRMP zu integrieren.
Im Anhang findest du die Scans.
Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.
Vielleicht kann das ja mal einer gebrauchen.
Danke schon mal für deine/eure Unterstützung...
Gruß
PatrickHH
Hallo Patrick,
Patrick Hh schrieb:> Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ:> TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es> möglich ist, diese mit in IRMP zu integrieren.> Im Anhang findest du die Scans.
Ich habe mir die Scans angeschaut: Das ist eine Manchester-Codierung -
ähnlich zu RC5, aber doch wieder ganz anders...
> Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.> Vielleicht kann das ja mal einer gebrauchen.
Die Doku ist spitze, sie beschreibt genau die Signale, die ich in Deinen
Scans fand. :-)
Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere.
Leider ist es wegen der Manchester-Codierung nicht damit getan, einfach
nur die Preprocessor-Konstanten für die Timings zu definieren.
Gruß,
Frank
Das ging ja schnell!
Das hört sich ja schon mal ganz gut an. Ist auch nicht so eilig für
mich.
Dann viel Erfolg. Mal sehen ob es klappt.
Schönen Abend noch...
PatrickHH
Frank M. schrieb:> Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere.
Habe es erfolgreich einbauen können, kostet auch nur "150" weitere Bytes
im Binary.
@Patrick:
Bevor ich nun ein neues Release mache, würde ich das gerne einmal von
Dir testen lassen, deshalb hänge ich hier nur mal die geänderten Sources
dran, bevor ich ein neues Download-Paket zusammenstelle.
Wäre auch nicht schlecht zu wissen, wie IRMP auf längere Tastendrücke
reagiert, eventuell muss ich da noch nacharbeiten. Hilfreich wäre da ein
Scan mit länger gedrückter Taste - aber nicht zu lang, da sonst der
Log-Buffer überläuft.
Das Grundig-Protokoll hat einiges gemeinsam mit RC5. Ich werde mal
schauen, ob ich da noch einiges an gemeinsamen Code für RC5 und Grundig
zusammenfassen kann, um noch etwas an Flash-Speicher einzusparen.
Gruß,
Frank
Super,
ich werde es heute Vormittag mal testen (Jetzt ist es schon zu spät).
Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller,
wenn er gerade nichts Empfängt, schlafen zu legen? Ich denke da an den
externen Interrupt. Wenn der TSOP ein Signal bekommt, dann erwacht der
Controller und macht dann seine IR-Erkennung.
Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.
Denn jetzt ist der Sromverbrauch schon bei 15mA.
Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen.
Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)
Gruß
PatrickHH
Hallo Frank,
es Fuktioniert! Codes werden Zuverlässig erkannt. Wenn eine Taste länger
gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition
Flag wird dann aber nicht gesetzt.
Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger
gedrückt habe.
Bezüglich Repetition Flag und SIRC:
Bei mir wird bei einem längeren Tastendruck der Code nur einmal
Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine
Wiederholung! Ist das so gewollt?
Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch
von meiner SonyFB einige Scans gemacht.
Danke nochmal und Gruß
PatrickHH
Hallo Patrick,
Patrick Hh schrieb:> Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller,> wenn er gerade nichts Empfängt, schlafen zu legen?
Ja, wäre möglich.
> Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.> Denn jetzt ist der Sromverbrauch schon bei 15mA.
Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht.
Und den kannst Du nicht "schlafen legen".
> Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen.> Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)
Muss ich mir erstmal selbst anschauen, ich habe mich bisher damit noch
nicht beschäftigt.
Gruß,
Frank
Patrick Hh schrieb:> es Fuktioniert! Codes werden Zuverlässig erkannt.
Freut mich :-)
> Wenn eine Taste länger> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition> Flag wird dann aber nicht gesetzt.
Hatte ich befürchtet. Aus Deinen Scans ging das nämlich nicht hervor.
> Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger> gedrückt habe.
Prima, werde ich mir anschauen.
> Bezüglich Repetition Flag und SIRC:> Bei mir wird bei einem längeren Tastendruck der Code nur einmal> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine> Wiederholung! Ist das so gewollt?
Nein, aber ich muss zugeben, dass ich das mangels Sony-FB auch niemals
austesten konnte.
> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch> von meiner SonyFB einige Scans gemacht.
Sehr schön, dann bekomme ich das dann wohl auch für SIRCs endlich mal
richtig gelöst.
Gruß und Dank,
Frank
Patrick Hh schrieb:> es Fuktioniert!
Eins vergaß ich noch zu fragen: mit welchem IR-Empfänger hast Du die
Signale aufgenommmen? In der Grundig-Doku las ich was von 485kHz, das
ist genaz schön viel für einen "normalen" TSOP.
Gruß,
Frank
Patrick Hh schrieb:> Wenn eine Taste länger> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition> Flag wird dann aber nicht gesetzt.
Ich habe gerade Deine Scans mit
./irmp < IR-Data/Grundig_TP715_lange.txt |less
unter Linux getestet.
Da bei längerem Drücken der Scan-Buffer irgendwann überläuft, geht der
Scan zwar nach 3 Frames einer jeden Taste voll in die Hose, aber irmp
setzt bei mir trotzdem das Repetition-Flag beim zweiten Frame:
# 1 lange (wird in IRMP als 11 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x01
-------------------------------------------------------------------
# 2 lange (wird in IRMP als 12 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x01
-------------------------------------------------------------------
# 0 ganz lange (wird in IRMP als 10 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x01
Kannst Du das nochmal überprüfen?
Gruß,
Frank
Hi Frank,
also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch
noch mal getestet -> Funktioniert auch.
Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme
das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich
habs (noch) nicht so mit der "C" Programmierung.
Ich lasse mir den Code und das Flag (wie im Artikel beschrieben) via
RS232 (danke an Klaus Leidinger) senden. Eigentlich nicht viel.
> Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht.> Und den kannst Du nicht "schlafen legen".
Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!
Gruß
PatrickHH
Patrick Hh schrieb:> Bezüglich Repetition Flag und SIRC:> Bei mir wird bei einem längeren Tastendruck der Code nur einmal> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine> Wiederholung! Ist das so gewollt?> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch> von meiner SonyFB einige Scans gemacht.
Hallo!
Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.
Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,
und der Samsung Empfang verhält sich genauso, es werden keine neuen
Codes bei langem Tastendruck ausgewertet.
Scans kann ich leider nicht machen da aus unerklärlichen gründen die
eingebauten UART Funktionen bei mir nicht funktionieren wollen, ich zeig
die empfangenen Bytes mit der UART Routine von Peter Flury an.
mfg,
Bjoern
Tishima schrieb:> Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,> und der Samsung Empfang verhält sich genauso, es werden keine neuen> Codes bei langem Tastendruck ausgewertet.
Das Problem mit dem SIRCs-Code habe ich dank Patricks Scan-Datei
reproduzieren können. Sony-FBs senden bei jedem (kurzem) Tastendruck 2
bis 3 Wiederholungen. IRMP erkennt aber auch die vierte, fünfte usw.
Wiederholung als Low-Level-Wiederholung statt als langen Tastendruck und
unterdrückt diese dann.
In manchen SIRCs-Dokus steht, dass jeder Frame 2mal (in anderen Dokus
steht 3mal) automatisch wiederholt wird.
Jetzt habe ich ein Problem: Patrick hat 3 Tasten lange gedrückt.
Taste A: 8 Frames aufgezeichnet
Taste B: 9 Frames aufgezeichnet
Taste C: 9 Frames aufgezeichnet
Wie habe ich das nun zu verstehen?
Möglichkeit 1:
Taste A: 1 Frame + 1 automatische Wiederholung - das ganze 4 mal?
Taste B: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?
Taste C: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?
Warum wiederholt die FB bei Taste A jeden Tastendruck nur 2mal, bei den
Tasten B und C dreimal? Das widerspricht sich.
Möglichkeit 2:
Taste A: 1 Frame + 1 automatische Wiederholung + 6 Wiederholungen wegen
langer Taste
Taste B: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen
langer Taste
Taste C: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen
langer Taste
Das hieße dann: Der erste Frame wird automatisch wiederholt, alle
weiteren geben die Länge des Tastendrucks wieder und werden daher nicht
automatisch 2- bzw. 3-fach gesendet...
Ich tendiere zu Möglichkeit 2, habe leider nichts spezielles darüber
gefunden, wie lange Tastendrücke codiert werden.
Dein Problem mit der Samsung-FB scheint ähnlich gelagert zu sein, werde
ich mir näher anschauen.
Gruß,
Frank
Hi Patrick,
Patrick Hh schrieb:> also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch> noch mal getestet -> Funktioniert auch.
Okay, dann habe ich das mit den 485kHz falsch interpretiert.
> Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme> das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich> habs (noch) nicht so mit der "C" Programmierung.
Gut, dann muss ich nochmal den Source prüfen. Danke für Deine
Bestätigung.
> Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!
Laut Datenblatt zieht der 5mA. Nun gut, da scheint der Wert im
Datenblatt ein Maximalwert zu sein.
Gruß,
Frank
Hallo,
was ich noch in meinen Unterlagen zu SIRC gefunden habe ist:
"Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal
bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler
ausgegangen."
Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät
unterschiedlich sein können.
Vielleicht hilft die Info...
Gruß
PatrickHH
Patrick Hh schrieb:> "Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal> bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler> ausgegangen."
"Zweimalige Wiederholung" heisst 3x derselbe Frame, okay.
Aber was passiert bei längerem Tastendruck? Habe ich dann N x 3 Frames?
Oder 3 Frames + N weitere?
Gegen N x 3 Frames spricht, dass die erste Taste aus Deinem Scan exakt 8
Frames erzeugt hat. Das ist nicht durch 3 teilbar.
> Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät> unterschiedlich sein können.
Noch schlimmer. Wie lange unterdrücke ich also Wiederholungen, bevor ich
sie wieder an die Applikation mit gesetztem Repetition-Bit weitergebe?
Ich habe mir jetzt nochmal sämtliche Sony-FB-Scans im Verzeichnis
IR-Data angeschaut, die ich von verschiedenen Leuten bekommen habe.
Dort habe ich folgende Häufigkeiten finden können:
49 x 3 Frames
65 x 4 Frames
18 x 5 Frames
2 x 6 Frames
4 x 7 Frames
2 x 8 Frames
3 x 9 Frames
Auffallend ist:
1. Es werden mindestens 3 Frames gesandt.
2. Danach kann jede x-beliebige Anzahl von Frames erfolgen, es gibt
keine ganzzahligen Vielfachen von 2 oder 3 Frames.
Ergo werde ich den Code derart ändern, dass die erste und zweite
Wiederholung des Original-Frames ignoriert wird und anschließend jede
weitere Wiederholung des Frames (innerhalb des Zeitrahmens natürlich)
mit gesetztem Repetition-Bit an die Applikation wieder zurückgemeldet
wird.
Gruß,
Frank
Tishima schrieb:> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,> und der Samsung Empfang verhält sich genauso, es werden keine neuen> Codes bei langem Tastendruck ausgewertet.
Frage: geht es um SAMSUNG oder SAMSUNG32?
Gruß,
Frank
Eine neue Version von IRMP ist unter
http://www.mikrocontroller.net/articles/IRMP#Download
verfügbar.
Änderungen:
1) Neues Protokoll: Grundig
2) Behandlung von automatischen Frame-Wiederholungen beim SIRCS-,
SAMSUNG32- und NUBERT-Protokoll verbessert.
Zu Punkt 2:
Beim SIRCS-Protokoll werden nun bei Frame-Wiederholungen nur noch der
zweite und der dritte Frame ignoriert, alle weiteren Wiederholungen
werden als langer Tastendruck gewertet und das entsprechende
Repetition-Flag gesetzt.
Bei SAMSUNG32 und NUBERT wird jeder 2. Wiederholungsframe ignoriert,
weil hier wohl immer 2 Frames gesendet werden. Ein dritter, fünfter usw.
Frame wird als langer Tastendruck gewertet und das entsprechende
Repetition-Flag gesetzt.
Viel Spaß,
Frank
P.S.
@Patrick:
Da bei meinen Tests mit Grundig einwandfrei das Repetition-Flag gesetzt
wird, wenn derselbe Frame N-fach wiederholt wird, kann ich das
Verhalten, was bei Dir auftritt, nicht nachvollziehen. Hilfreich wäre da
ein Auszug des Sources, den Du zur Ausgabe von irmp_data.flags
verwendest.
Ha
Frank M. schrieb:> Frage: geht es um SAMSUNG oder SAMSUNG32?>> Gruß,>> Frank
Hallo!
Kann ich jetzt momentan garnicht sagen. Der Ausgabestring ist ja bei
beiden SAMSUNG im Beispiel Code gleich. An das Protkoll Byte kann ich
mich garnicht erinnern. Wenn ich meine Universalfernbedienung nochmal
dazu überedet kriege SAMSUNG Codes auszuspucken, werde ich mal aufs
Protokoll Byte achten.
gruß,
Bjoern
Hallo!
So habe eben den neuen Code getestet.
Sirc wird nun sauber bei mir erkannt, jedoch beim Samsung32 Code haut
ein langer Tastendruck immer noch nicht hin.
gruß,
Bjoern
Neue Version 1.3.1 von IRMP verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Bit-Maske für SAMSUNG32 korrigiert, das niederwertigste Bit wurde
bisher
komplett ignoriert
- Timing-Werte für SAMSUNG32 geändert
Ebenso ist nun die Version 1.3.1 von IRSND verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen:
- GRUNDIG-Protokoll hinzugefügt
- Behandlung von Frame-Wiederholungen für SIRCS, SAMSUNG32 und NUBERT
korrigiert
Viel Spaß,
Frank
Hi Frank,
> zu: Grundig
also hier mal meine main.c.
Als Compiler nehme ich GCC. Als Controller nehme ich einen Mega8.
Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die
Codes angezeigt, jedoch ohne das Flag.
> zu: SIRC
Den Code kann ich erst am Wochenende testen. Dann gibts Feedback.
Gruß
Patrick
Tishima schrieb:> Sirc wird nun sauber bei mir erkannt,
Prima, freut mich.
> jedoch beim Samsung32 Code haut ein langer Tastendruck immer noch nicht hin.
Was bekommst du stattdessen? N x denselben Befehl? Oder nur 1x?
Und es handelt sich definitiv um SAMSUNG32?
IRMP erkennt lange Tastendrücke bei Protokollen, die nicht explizit
einen Repetition-Frame oder einen anderen Mechanismus dafür bieten,
einfach daran, dass die Frame-Wiederholungen innerhalb von 100 msec
reinkommen.
Um da jetzt weiterzukommen, bräuchte ich einen Scan von Dir. Du sagtest,
Du benutzt die Fleury-Lib auf dem UART? Lass die mal weg, dann sollte es
gehen. Der Scan wird mit 9600Baud, 8bit, no parity ausgegeben.
Gruß,
Frank
P.S.
Ich habe gerade eben eine neue Version 1.3.1 hochgeladen, da war sowieso
noch ein Fehler beim Erkennen des SAMSUNG-Kommando-Codes. Das
niederwertigste Bit wurde verschlabbert. Dürfte aber keine Änderung bei
Dir bzgl. langer Tastendrücke bringen.
Hi Patrick,
Patrick Hh schrieb:> Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die> Codes angezeigt, jedoch ohne das Flag.
Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt
die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist.
Schaue ich mir an.
Gruß,
Frank
Hi Frank,
> Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt> die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist.
Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich
beim dauer Drücken das Flag gesetzt.
PatrickHH
Patrick Hh schrieb:> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich> beim dauer Drücken das Flag gesetzt.
Hm, dann kann es nicht an der main-Funktion liegen, habe sie mir auch
angeschaut, sieht alles okay aus.
Bin nun etwas ratlos. Warum klappt das bei mir mit den Scans und bei Dir
nicht?
Gruß,
Frank
Patrick Hh schrieb:> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich> beim dauer Drücken das Flag gesetzt.
Ich habe mir nochmal die Doku zum Grundig-Protokoll angeschaut. Dort
haben die Info-Frames, die bei längerem Tastendruck wiederholt werden,
einen Abstand von 117,76ms.
In der Scan-Datei müssten die Info-Frames bei einem so großem Abstand
eigentlich alle in einer separaten Zeile stehen. Tun sie aber nicht, sie
sind alle in einer Zeile.
Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen
zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks
Übersichtlichkeit? In den Scans haben die Info-Frames nämlich lediglich
einen Abstand von 2ms. Dieser Zeitrahmen liegt weit unterhalb der 100ms,
die ich zur Erkennung von langen Tastendrücken als obere Grenze
definiert habe. Das würde auch erklären, warum bei der Auswertung der
Scans das Repetition-Bit auch gesetzt wird.
Meine Bitte: Ändere mal in irmp.c die Zeile
ab und teste die Grundig-FB nochmals mit langen Tastendrücken.
Die 100ms sind als Grenze wohl zu knapp, denn laut Grundig-Doku sind wir
mit 117ms knapp drunter. Fragt sich nur, warum in den Scans nur 2ms als
Pausen zwischen den Frames zu sehen sind....
Gruß,
Frank
Hallo Bjoern,
Tishima schrieb:> [...] jedoch beim Samsung32 Code haut> ein langer Tastendruck immer noch nicht hin.
Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe
Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll
keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der
Grundig-FB sein.
Gruß,
Frank
Hi Frank,
> Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen> zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks> Übersichtlichkeit?
Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht.
Denn mein Terminal Programm setzt nach jeder Übertragung ein "CR/LF" am
Ende. Das habe ich eigentlich nur entfernt. Vielleicht lag es ja daran.
Kann am Wochenende ja nochmal ein anderes Terminal Programmm benutzen
und nochmals einen Scan machen.
> Meine Bitte: Ändere mal in irmp.c die Zeile......
Werde ich testen. Wird aber erst am Wochenende was.
Gruß
PatrickHH
Hi Patrick,
Patrick Hh schrieb:> Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht.
Jau, dann hattest Du mich mit der Scan-Datei auf die falsche Fährte
geführt und ich dachte, 100ms reichen völlig aus ;-)
> Werde ich testen. Wird aber erst am Wochenende was.
Bin mir nun ziemlich sicher, dass es mit der Änderung funktionieren
wird.
Gruß,
Frank
Frank M. schrieb:> Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe> Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll> keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der> Grundig-FB sein.
Hallo!
Habe soeben die neue Version getestet mit ner Phillips
Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt,
auch ohne das ich den Wert auf 150 geaendert habe.
Meine Pollin UFB will nun garkeinen SAMSUNG32 Code mehr ausspucken
obwohl ich mir sicher bin den selben device Code eingeben zu haben, wie
bei den letzten Tests.
Aber die UFB ist eh der letzte Chinaschrott und wird von mir nicht mehr
verwendet.
So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um
meine Software zu steuern die ich benötige.
Viel, Spaß noch....
mfg,
Bjoern
Tishima schrieb:> Habe soeben die neue Version getestet mit ner Phillips> Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt,> auch ohne das ich den Wert auf 150 geaendert habe.
Freut mich :-)
> So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um> meine Software zu steuern die ich benötige.
Viel Spaß, ich hoffe, Du erzählst nachher etwas über Dein Projekt, wenn
es dann fertig ist.
Frank
Hi Frank,
ich habe die neue Version getestet:
SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun
auch gesetzt.
Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die
REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die
im Datenblatt stehen.
Vielen Dank nochmal für deine Unterstützung...
Gruß
PatrickHH
Frank M. schrieb:> eku schrieb:>>> Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1>>> aufzeichne?>> Ja, müsste reichen, am besten so viele Tasten wie möglich und dann in> der Form:
Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2
(dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls
wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.
Die Unterstützung sowohl in IRMP als auch in IRSND wäre super!
Hi Patrick,
Patrick Hh schrieb:> SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun> auch gesetzt.
Freut mich.
> Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die> REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die> im Datenblatt stehen.
Gut. Dann werde ich auf Nummer sicher gehen und die REPETITION TIME fürs
nächste Release auf 130ms setzen.
Gruß,
Frank
eku schrieb:> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.
Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch
Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein-
und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die
Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da
ein System reinbekomme.
Die D-Box scheint eine Abart des Grundig-Protokolls zu verwenden,
offenbar ist hier einfach das Telegramm länger als 10 Bits, nämlich 16.
Deshalb steigt der Grundig-Code nach 10 Bits aus und die restlichen 6
Bits werden als RC5 erkannt, da die verbliebenen Daten-Bits ohne
Start-Bit so "aussehen" wie RC5. Ich schaue, dass ich die beiden
Protokolle über eine variable Längenerkennung auseinanderdividiert
bekomme. Dann sollte die Erkennung sowoh für D-Box als auch für Grundig
funktionieren.
Gruß,
Frank
Frank M. schrieb:> Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch> Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein-> und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die> Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da> ein System reinbekomme.
Laut LIRC Datensatz gelten folgende Parameter:
1
bits 8
2
eps 30
3
aeps 100
4
one 0 0
5
zero 0 0
6
pre_data_bits 24
7
pre_data 0x10
8
gap 210000
9
min_repeat 2
10
toggle_bit 25
und für doe DBox
[code]
bits 8
eps 30
aeps 100
one 0 0
zero 0 0
pre_data_bits 24
pre_data 0x10
gap 210000
min_repeat 2
toggle_bit 25
[code]
Hilft Dir das?
eku schrieb:> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.
Ich habe das Nokia-Protokoll in den IRMP integriert. Mein erster
Eindruck hat sich bestätigt: Das Nokia-Protokoll unterscheidet sich nur
durch 16 Datenbits (8 Adressbits + 8 Kommandobits) statt 9 Datenbits (0
Adressbits + 9 Kommandobits) beim Grundig-Protokoll. Das Timing ist
annähernd gleich.
Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange
Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues
Release für IRMP erstellen.
Gruß,
Frank
P.S.
An der Gigaset-FB bin ich noch dran.
Hallo Frank!
Frank M. schrieb:> Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange> Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues> Release für IRMP erstellen.
Die Dekodierung funktioniert nun. Aus Mangel einer Grundig-FB kann ich
nicht testen, ob diese auch noch geht. Die dekodierten Codes
unterscheiden sich allerdings von
http://lirc.sourceforge.net/remotes/nokia/DBOX2. Hat das was zu
bedeuten?
Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.
1
irmp/irsnd.c: In function 'ir_tx_process':
2
irmp/irsnd.c:526: error: 'SIRCS_REPETITION_CNT' undeclared (first use in this function)
3
irmp/irsnd.c:526: error: (Each undeclared identifier is reported only once
4
irmp/irsnd.c:526: error: for each function it appears in.)
5
irmp/irsnd.c:527: error: 'SIRCS_REPETITION_TIME' undeclared (first use in this function)
6
irmp/irsnd.c:576: error: 'SAMSUNG32_REPETITION_CNT' undeclared (first use in this function)
7
irmp/irsnd.c:577: error: 'SAMSUNG32_REPETITION_TIME' undeclared (first use in this function)
8
irmp/irsnd.c:661: error: 'DENON_REPETITION_CNT' undeclared (first use in this function)
9
irmp/irsnd.c:662: error: 'DENON_REPETITION_TIME' undeclared (first use in this function)
10
irmp/irsnd.c:678: error: 'NUBERT_REPETITION_CNT' undeclared (first use in this function)
11
irmp/irsnd.c:679: error: 'NUBERT_REPETITION_TIME' undeclared (first use in this function)
12
irmp/irsnd.c:713: error: 'GRUNDIG_REPETITION_CNT' undeclared (first use in this function)
13
irmp/irsnd.c:714: error: 'GRUNDIG_REPETITION_TIME' undeclared (first use in this function)
eku schrieb:> Die Dekodierung funktioniert nun.
Freut mich!
> Aus Mangel einer Grundig-FB kann ich nicht testen, ob diese> auch noch geht.
Macht nix, das habe ich bereits mit den mir vorliegenden
Grundig-Scan-Dateien gemacht. War ein wenig Arbeit, eine vernünftige
Abbruchbedingung zu finden, um Grundig und Nokia zu unterscheiden, die
sich tatsächlich nur in der Anzahl der Bits unterscheiden ;-)
> Die dekodierten Codes> unterscheiden sich allerdings von> http://lirc.sourceforge.net/remotes/nokia/DBOX2.
Ich weiß nicht, wie lirc die Codes generiert, ich vermute, die haben da
noch einen weiteren Abstraktionslayer mit drin.
Die Codes, die IRMP ausspuckt, halte ich jedoch für absolut plausibel,
da Taste 0 = 0x00, Taste 1 = 0x01, .... Taste 9 = 0x09 ist. Ausserdem
habe ich heute morgen noch eine weitere Nokia-TV-Scan-Datei per Mail von
einem anderen IRMP-Anwender erhalten, so dass ich da einen Quercheck
machen konnte. Lediglich die Adresse unterschied sich, passt also alles
wunderbar.
> Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.
Das liegt daran, dass ich den IRMP-/IRSND-Source in der Zwischenzeit
weiterbearbeitet und optimiert habe, deshalb hatte ich auch nur die 3
Dateien zwecks Test hier ins Zip-Archiv gepackt. Mit dem nächsten
Release gibt es dann wieder einen einheitlichen Stand.
Vielen Dank fürs Feedback,
Frank
eku schrieb:> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) [...]
Wie gestern schon angedeutet: Die Pulse/Pausen sind arg kurz. Es handelt
sich um ein 23-bittiges Manchester-Protokoll, wobei jeder Frame einmal
zusätzlich wiederholt wird. Leider ist die Aufzeichnungsrate von
10000/sec hier zu niedrig, um eindeutige Werte zu erhalten. Fast jede
Wiederholung ist nicht identisch mit dem Original-Frame, weil ein Puls
mehr oder weniger schon das Bit im Frame kippen lässt.
Kannst Du dieselben Scans nochmal mit F_INTERRUPTS 15000 machen? Dann
sollte die Genauigkeit ausreichen.
Gruß,
Frank
eku schrieb:> Samplerate 15kHz anbei.
Vielen Dank, die Datei ist echt brauchbar. Ich habe das Protokoll soweit
"enschlüsseln" und den IRMP-Source anpassen können. Ich habe mal zum
Testen die geänderten Sources angehängt.
Leider bleibt noch eine klitzekleine Unklarheit:
In der 10kHz-Datei wurde jeder Frame wiederholt, wobei in der
Wiederholung immer das 15te Bit invertiert wurde. Dieses Bit hat
offenbar eine ähnliche Bedeutung wie das Toggle-Bit beim RC5-Protokoll.
In der 15kHz-Datei gibt es diese Frame-Wiederholungen nicht.
Das kann zwei Gründe haben:
a) Du hast beim 10kHz-Scan die Tasten länger gedrückt. Dann ist das
15. Bit ein Flag für langen Tastendruck.
oder
b) Die Wiederholungen wurden wegen der höheren Samplerate
"verschluckt", d.h. es werden immer (auch bei kurzen
Tastendrücken) 2 Frames verschickt, wobei das 15. Bit den
automatischen Wiederholungs-Frame kenntlich macht.
Ich tippe mal auf Fall b).
Aber das lässt sich leicht herausfinden:
Sollten beim angehängten Source auch bei kurzem(!) Tastendruck
konsequent immer 2 identische Frames erkannt werden und IRMP beim
zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b)
und ich muss das im Source noch gesondert behandeln.
Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS =
15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal
bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate
bei der niedrigeren Samplerate treffen.
Gruß,
Frank
Frank M. schrieb:> Sollten beim angehängten Source auch bei kurzem(!) Tastendruck> konsequent immer 2 identische Frames erkannt werden und IRMP beim> zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b)> und ich muss das im Source noch gesondert behandeln.>> Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS => 15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal> bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate> bei der niedrigeren Samplerate treffen.
Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame.
Allerdings braucht es nur wenige Millisekunden für die
Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt
wird.
Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur
sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon
vermutetest, grenzwertig.
Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch
eine Stellschraube, um vielleicht mit 10kHz hinzukommen?
eku schrieb:> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur> sporadisch von IRMP als solche erkannt.
Gerade noch einmal getestet. Der Gerätecode wird nicht zuverlässig
decodiert.
eku schrieb:> Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame.
Prima.
> Allerdings braucht es nur wenige Millisekunden für die> Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt> wird.
Dann lasse ich das mit der Extra-Auswertung des 15. Bits. Da ich dieses
nur "ab und zu" im 10kHz-Scan gesehen habe, kann es auch sein, dass es
einfach ein zufällig gekipptes Bit war. Wie gesagt, bei 10kHz liegen die
Zeiten zu nah beieinander, um noch zuverlässig 0 oder 1 erkennen zu
können.
> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur> sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon> vermutetest, grenzwertig.
Okay, dann werde ich das im Source so machen, dass bei 10kHz der
SIEMENS-Gigaset-Decoder unter Angabe einer Warnung deaktiviert wird.
> Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch> eine Stellschraube, um vielleicht mit 10kHz hinzukommen?
Nein. Bei dem 10kHz-Scan überlappen sich die Puls-/Pausenlängen
teilweise. Hat einfach keinen Zweck.
Danke für Dein Feedback,
Frank
eku schrieb:> Mit 15kHz werden keine anderen Protokolle erkannt. Woran kann das> liegen?
Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene
Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass
bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal
gegenchecken.
Welche anderen Protokolle hast Du denn getestet?
Notfalls könntest Du mal auf 14kHz runtergehen.
Gruß,
Frank
Hy,
ich versuche gerade das IRMP zu benutzen um damit NEC Codes zu meinem
Receiver zu schicken. Der will aber nicht reagierren.
Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den
richtigen Code an, den ich sende, aber der Receiver mag nicht.
Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild
abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und
danach nur noch sowas wie "Taste noch gedrückt" ?
Das Timing der Repeats ist dieses:
9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit
9,1mS Low los.
Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich
dieses Signal noch anzuhängen ??
Gruß
Torsten
Frank M. schrieb:> Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene> Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass> bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal> gegenchecken.
Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast
uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.
> Welche anderen Protokolle hast Du denn getestet?
NEC, Nubert, Denon, RC5, Grundig, Nokia
> Notfalls könntest Du mal auf 14kHz runtergehen.
Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird
nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit
verbreitern
müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS > 10000
überlasse ich Dir.
Torsten Kalbe schrieb:> Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den> richtigen Code an, den ich sende, aber der Receiver mag nicht.
Das heisst also, der reagiert überhaupt nicht? Oder nur 1mal auf eine
Taste?
> Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild> abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und> danach nur noch sowas wie "Taste noch gedrückt" ?> Das Timing der Repeats ist dieses:> 9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit> 9,1mS Low los.
Das entspricht genau dem, was in
http://www.mikrocontroller.net/articles/IRMP#Protokolle
unter Protokoll "NEC, Tastenwiederholung" steht:
9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause
Dieser Frame wird eigentlich nur geschickt, um eine Taste zu
wiederholen, also dem Empfänger mitzuteilen, dass Du noch immer die
Taste drückst.
> Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich> dieses Signal noch anzuhängen ??
Schickt Deine Original-FB denn diesen Wiederholungsframe auch aus, wenn
Du die Taste nur kurz drückst? Wenn nicht, reagiert dann der Empfänger
in Deinem Gerät?
Wenn Deine FB diesen Wiederholungsframe generell sendet, egal wie lange
Du die Taste drückst, dann würde ich dieses absonderliche Verhalten
Deiner FB über ein Bit in irmp_data.flags nachbilden.
Gruß,
Frank
eku schrieb:> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.
Werde ich mir ansehen.
> Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird> nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit> verbreitern müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS> 10000 überlasse ich Dir.
Das wäre bitter, denn nicht nur der Code würde größer werden, sondern
auch das Laufzeitverhalten könnte kritisch werden.
Ich werde das überprüfen und dann nach einer geeigneten Lösung suchen.
Gruß,
Frank
eku schrieb:> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.
Entfernen darf man die Casts auf keinen Fall, denn dann sind die
Konstanten alle Floats und die Floating-Point-Lib wird dann aktiv.
Die größten Werte im Source sind
NEC_START_BIT_PULSE_TIME mit 9000e-6
bzw.
BANG_OLUFSEN_START_BIT3_PAUSE_TIME mit 15625e-6
Damit rechne ich jetzt mal aus:
Bei 15kHz:
15000 x 15625e-6 x 1.05 + 1 = 247,09375 -> 247
Das passt also alles noch in den Wertebereich von 0 bis 255. Das Problem
muss woanders liegen. Irgendwas läuft bei 15kHz über, aber was? Ich habe
auch in Erinnerung, dass Klaus Leidinger den IRMP damals auch mit 15kHz
erfolgreich getestet hat...
Ich werde weitersuchen,
Frank
eku schrieb:> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte> Flash.
1 kByte sind 30%. Das ist mir zuviel. Ich vermute auch, dass diese
"Gewaltaktion" eigentlich nicht notwendig ist, siehe meine Berechnungen
oben.
Es gibt irgendwo ein 8-Bit-Problem im Source bei 15kHz, aber mir wäre es
lieber, den Übeltäter zu finden statt den Teufel mit dem Bezelbub
auszutreiben...
Gruß,
Frank
Frank M. schrieb:> Da kommt heraus bei 15kHz:>> 15000 x 9000e-6 x 1.4 + 0.5 + 1 = 136,5 -> 137
Rechenfehler, korrekt ist:
15000 x 9000e-6 x 1.4 + 0.5 + 1 = 190,5 -> 190.
Der Wert bleibt trotzdem unter 256...
Ich habe auch eben mal ein kleines Programm geschrieben, um mir alle
Timingwerte ausgeben zu lassen. Keines erzeugt bei 15kHz einen
8-Bit-Überlauf.
Also weiter suchen...
Gruß,
Frank
Sind es denn auch genau 15kHz? Zum Beispiel mit 15,625kHz (Ist ja eine
durchaus übliche Frequenz, wenn man einen 2^n Vorteiler benutzt).
Bang & Olufsen:
15625 x 15625e-6 x 1.05 + 1 = 257,3
Zur Tastenwiederholung bei NEC.
Der Receiver reagiert garnicht.
Wenn ich die Taste an der FB dauerhaft drücke bekomme ich auch dauernd
das Wiederholungssignal.
Die Taste so kurz zu drücken ist nicht wirklich einfach, außerdem sehe
ich das dann ja auch nicht, was tatsächlich gesendet wird.
Ich müßte mal den zusätzlichen IR Empfänger direkt über den Receiver
legen, damit ich dann mit dem Scope das Signal nachmessen kann.
Ich hab aber mal versucht die Taste ganz kurz zu drücken, da scheint der
auch zu reagieren.
Das Signal selber, welches ich verschicke sieht vom Timing nahezu gleich
aus, da habe ich an den Defines extra nachverändert, aber der Receiver
reagiert trotzdem nicht.
Ich habe auch schonmal die IR Diode aus der FB an meiner Schaltung
benutzt, weil ich eine ungewöhnliche Wellenlänge vermutet habe.
Das wars auch nicht.
Sehr merkwürdig.....
Gruß
Torsten
Torsten Kalbe schrieb:> Zur Tastenwiederholung bei NEC.>> Der Receiver reagiert garnicht.
Kannst Du mir Scan-Dateien zukommen lassen? Die Tasten 0-9 würden
reichen.
Gruß,
Frank
eku schrieb:> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte> Flash.
Ich habe gerade mal stichprobenweise einige der mir vorliegenden
Scan-Dateien mit dem Editor von 10kHz auf 15kHz "gestreckt", indem ich
immer 00 durch 000 und 11 durch 111 ersetzt habe. Dann IRMP mit 15kHz
unter Linux übersetzt und gegen die Scan-Dateien laufen lassen.
Ergebnis: überhaupt kein Problem, alle Scans wurden einwandfrei erkannt
und dekodiert. Das NEC-Protokoll lief bei mir sogar noch bei 20kHz
korrekt (mit entsprechend gestreckten Scan-Dateien).
Allerdings habe ich beim 20kHz-Test dann auch vom Compiler Warnungen
bzgl. IRMP_TIMEOUT_LEN bekommen. Das läuft über ab 15425 Hz:
1
#define IRMP_TIMEOUT_TIME 16500.0e-6 // timeout after 16.5 ms darkness
F_INTERRUPTS darf also durchaus zwischen den Werten 10000 und 15000
liegen.
Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass
bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also
Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll
immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version
das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht
bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING
aktiviert? Das kostet natürlich auch noch einiges an Zeit.
Gruß,
Frank
ähm, ja, eigentlich schon.
Muß ich dann nur die Zeile
#define IRMP_LOGGING 0
// 1: log IR signal (scan), 0: do not (default)
verändern in #define IRMP_LOGGING 1
// 1: log IR signal (scan), 0: do not (default)
Und dann den Empfäng mit Hterm pro Taste Speichern ?
oder kannst Du mit vielleicht die fertige Hex mailen ?
Torsten Kalbe schrieb:> ähm, ja, eigentlich schon.> Muß ich dann nur die Zeile> #define IRMP_LOGGING 0> // 1: log IR signal (scan), 0: do not (default)> verändern in #define IRMP_LOGGING 1> // 1: log IR signal (scan), 0: do not (default)>> Und dann den Empfäng mit Hterm pro Taste Speichern ?
Ja, genau, siehe auch IRMP-Artikel.
Am besten schreibst Du dann am Schluss noch jeweils einen Kommentar vor
jede Zeile, eingeleitet mit '#', z.B.
# Taste 1
0000011100000....
Gruß,
Frank
Torsten Kalbe schrieb:> So, da ist dann mal der Scan von der FB mit NEC Protokoll.
Danke, habe es mir angeschaut, bei jeder Taste wird nicht nur der
normale NEC-Protokoll-Frame geschickt, sondern immer auch zusätzlich
noch ein Repetition-Frame. Da ich annehme, dass Du die Tasten (bis auf
Taste 1) immer nur kurz gedrückt hast, will Dein Empfänger wohl auch
immer den Repetition-Frame "sehen", bevor er reagiert.
Ich werde in den IRSND einbauen, dass man über das Setzen eines Flags
genau dieses (atypische) Verhalten reproduzieren kann.
Vielen Dank für den Scan,
Frank
Torsten Kalbe schrieb:> Oh, so eine Anpassung wäre ja Klasse, aber es würde ja auch erstmal eine> "Testversion" reichen, vielleicht liegt es ja doch noch an was anderem.
Ich dachte auch an eine "Testversion", nur war die mal nicht eben in 5
Minuten zusammengehackt ;-)
Ich habe nun irsnd folgendermaßen erweitert, dass irmp_data.flags die
Anzahl der Tasten-Wiederholungen angibt, also:
flags = 0: Normales Senden des Frames - wie bisher
flags = 1: 1-malige Wiederholung
flags = 2: 2-malige Wiederhulung
usw.
Dabei gelten folgende Besonderheiten:
Bei SIRCS werden sowieso immer 3 Frames gesandt - so erfordert es das
Protokoll. Bei flags = 1 werden dann daraus 4 Frames, bei flags = 2 dann
5 Frames usw.
Bei NEC werden die Wiederholungen als Repetition-Frames gesandt, also
nicht der komplette Frame n-mal wiederholt.
Für Grundig und Nokia werden im Moment noch alle Pakete (welche aus 3
Frames bestehen, nämlich Start-Frame + Info-Frame + Stop-Frame) n-malig
wiederholt, also nicht nur der Info-Frame, wie es sein soll. Da muss ich
noch nacharbeiten.
Bei allen anderen Protokollen wird einfach der Original-Frame n-mal
wiederholt, mit entweder (mir) bekannten Pause-Zeiten zwischen den
Frames oder mit der (von mir willkürlich gewählten) Pause-Zeit von
45msec.
Um nun Dein Problem mit dem Skymaster-Empfänger zu lösen, musst Du vor
dem Aufruf von irsnd_send_data() einfach irmp_data.flags = 1 setzen.
Dann wird erst der Original-Frame gesandt, anschließend eine Pause von
40ms gemacht und letztendlich der Repetition-Frame gesandt.
Im Anhang die Testversion.
Viel Glück!
Frank
Hallo Frank,
erstmal vielen Dank für die schnelle Anpassung !!
Das Problem lag aber an einer anderen Stelle, manchmal kann es so
einfach sein.
Nachdem ich den Receiver auseinander geschraubt hatte, und direkt am
Empfänger gemessen habe, ist mir noch eine andere Idee eingefallen.
Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC
Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet,
und schon hat es sofort funktioniert !!
Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat
gereicht !!
Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte
erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen
zu gebrauchen sein.
Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,
da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.
Gruß
Torsten
Torsten Kalbe schrieb:> Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC> Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet,> und schon hat es sofort funktioniert !!
Danke für die Rückmeldung :-)
> Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat> gereicht !!
Prima.
> Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte> erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen> zu gebrauchen sein.
Ja, auf jeden Fall, damit kann man dann direkt ein Kommando n-fach
schicken, was durchaus sinnvoll sein kann, z.B. zur Regelung von
Lautstärken oder Helligkeiten etc.
> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.
Ich werde im IRMP-Artikel entsprechend vermerken, dass die ganze
Geschichte mit Quarz um einiges stabiler ist.
Gruß,
Frank
Torsten Kalbe schrieb:> Hallo Frank,>> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.>
Hallo Torsten,
die Xtal Pins sind in meiner Schaltung leider für das LCD benutzt (wegen
Kompatibilität mit Codevision). Für GCC kann die Pinbelegung natürlich
auch einfach geändert werden. Ein Kalibrieren des Oszillators würde
vielleicht auch helfen?
Gruß,
Klaus
Ich hatte den mit dem internen Wert calibriert, das hat aber nicht
geholfen.
Das bringt auch nichts, wenn der am Jittern ist. Der Mega8 ist da noch
gut, der Mega48/88/168 ist total am Jittern, wenn das dann bei der
Signalgenerierung passiert, könnte ich mir gut vorstellen, das da
vielleicht ein paar Bits nicht mehr erkannt werden ??
Ich hab hier das dazu passende Mesbild mal angehängt, Quelle dazu ist:
http://www.scienceprog.com/avr-internal-oscillator-jitter-research/
Sagt mal, hat schon jemand das Protokol einer Siku Controll angeschaut.
Das ist eine Infrarot Fernbedienung für Modellauutos, wird gerner im
1/87 bereich benutzt. Das läuft allerdings mit 455khz und ist ständig am
senden.
Gruß
Neue Version 1.5.0 von IRMP verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Neues Protokoll: SIEMENS (Gigaset)
Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen:
- Neues Protokoll: Siemens (Gigaset)
- Simulation von langen Tastendrücken durch Angabe von Wiederholungen
in der Variablen irmp_data.flags.
irmp_data_p.flags gibt die Anzahl der Wiederholungen an, z.B.
irmp_data_p.flags = 0: Verhalten wie bisher
irmp_data_p.flags = 1: 1 Wiederholung, d.h. Ausgabe von 2 Frames
irmp_data_p.flags = 2: 2 Wiederholungen, d.h. Ausgabe von 3 Frames
usw.
Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause
(protokollabhängig) neu ausgegeben oder ein protkollspezifischer
Wiederholungsframe (z.B. für NEC) gesendet.
ZU BEACHTEN:
Da bisher irmp_data_p.flags von IRSND nicht ausgewertet wurde, ist
unbedingt ab Version 1.5.0 darauf zu achten, dass irmp_data_p.flags vor
dem Aufruf von irsnd_send_data() einen definierten Wert hat!
Viel Spaß,
Frank
Hallo Frank!
Frank M. schrieb:> Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass> bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also> Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll> immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version> das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht> bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING> aktiviert? Das kostet natürlich auch noch einiges an Zeit.
Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende
Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will
einfach nicht funktionieren. An der Interrupthäufigkeit kann es
eigentlich nicht liegen.
Hast Du noch 'ne Idee, wo ich suchen könnte?
Hi eku,
> Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende> Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will> einfach nicht funktionieren. An der Interrupthäufigkeit kann es> eigentlich nicht liegen.
Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf
16 Bit?
Zeigst Du mal Deine Timer-(Initialisierungs-)Routinen?
Gruß,
Frank
Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht
genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt
ist. Wenn
also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz rauskommen, dann
stellst Du halt F_INTERRUPTS auf 14750 und gut ist.
1
>#errorF_CPUtolarge
Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich schlecht
nachvollziehbar. Sind es 8MHz mit internem Oszillator?
1
ir_rx_process(data);
Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute,
Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht mehr
funktioniert.
Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:
Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf
16 Bit?
Also:
A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
Ergebnis möglichst knapp unter 15000 ist.
B. Setze F_INTERRUPTS auf den exakten berechneten Wert.
C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf
Gruß,
Frank
Frank M. schrieb:> eku schrieb:>> #define IR_HZ 15000 /* interrupts per second */>> Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht> genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt> ist. Wenn also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz> rauskommen, dann stellst Du halt F_INTERRUPTS auf 14750 und gut ist.>> #error F_CPU to large
Mein AVR soll neben IRMP noch andere Aufgaben erfüllen, mit nur einer
ISR. Warum soll ich Werte selbst berechnen, wenn es der Präprozessor
übernimmt.
> Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich> schlecht nachvollziehbar. Sind es 8MHz mit internem Oszillator?
16MHz Quarz
> ir_rx_process (data);>> Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute,> Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht> mehr funktioniert.
Nö, ich habe IRMP und IRSND in eine Bibliothek gepackt. Den eingelesenen
Wert gebe ich an irmp_ISR(). Ansonsten habe ich nichts verändert.
> Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:>> Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll> funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen> auf 16 Bit?
Ja, bis auf Denon funktionieren die anderen Protokolle mit 15kHz und
16Bit-Zählern.
> Also:>> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das> Ergebnis möglichst knapp unter 15000 ist.>> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.>> C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf
Probeweise werde ich das mal so machen. Mittelfristig soll IRMP/IRSND
aber im Kontext meiner Anwendung für den AVR laufen. Ich stelle mir das
als Modul für Ethersex auf einem Pollin Net-IO vor. Kommando- und
Webinterface zur Fernbedienung der HiFi-Geräte.
Frank M. schrieb:> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das> Ergebnis möglichst knapp unter 15000 ist.>> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.
F_INTERUPTS=16000000/8/133=15037
Siemens, Nokia, RCx, Nec, Grundig gehen, nur Denon nicht. Hilft ein
IRMP_LOGGING zur Analyse?
eku schrieb:> Siemens, Nokia, RCx, Nec, Grundig gehen
Auch mit 8-Bit-Zählern? Freut mich.
> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?
Ja.
Gruß,
Frank
Frank M. schrieb:>> Siemens, Nokia, RCx, Nec, Grundig gehen>> Auch mit 8-Bit-Zählern? Freut mich.
Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der
Compiler
>> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?>> Ja.
Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz
geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser.
Ich hatte zu8nächste Rundungsfehler bei den Konstanten (10kHz +50%) in
Verdacht, aber die Verdoppelung macht es nicht besser.
eku schrieb:> Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der> Compiler
Gut, das habe ich auch erwartet.
> Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz> geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser.
Ersetze in irmp.c die Zeile
Hallo Frank!
Frank M. schrieb:> Ersetze in irmp.c die Zeile
Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.
PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.
PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus
China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.
eku schrieb:> Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.
Na slso.
> PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.
Das verstehe ich nicht. Wann kommt denn eine Warnung? Die Aussage, wann
keine Warnung kommt, hilft mir nicht weiter. Redest Du von IRMP oder
IRSND?
Am besten zeigst Du mal den Compiler-Output.
> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.
Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ
einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir
das mal näher an.
Gruß,
Frank
Frank M. schrieb:> eku schrieb:>> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus>> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.>> Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ> einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir> das mal näher an.
Habe das Protokoll soweit dekodiert. Von den insgesamt 42 Bits (1
Start-Bit, 40 Daten-Bits, 1 Stop-Bit) werden nur effektiv 12 Bits
genutzt. Anbei eine Testversion. Nette Geschichte, damit kann man eine
PC-Tastatur einfach an einen µC anbinden.
Wäre klasse, wenn Du mal sämtliche Tasten scannen könntest, ich habe
noch nicht entscheiden können, ob das Protokoll mit LSB- oder MSB-first
funktioniert. Meine Vermutung ist LSB-first, aber richtig kann man das
erst erkennen, wenn sämtliche Tasten der Matrix (es sieht nach einem
Matrix-Code aus) bekannt ist.
Auf jeden Fall bestelle ich mir mal ein paar von den Dingern. Bei 1,95
EUR ist das ja kein großes Risiko ;-)
Gruß,
Frank
Dann kann man den Toleranzwert für DENON_1_PAUSE_LEN_MIN wieder auf 20
Prozent zurückschrauben, also die obige Änderung in irmp.c wieder
rückgängig machen, denn die Abweichungen der Denon-FB von den
Idealwerten sind dann wieder wesentlich geringer.
Sorry, mein Fehler. Werde ich im nächsten Release berücksichtigen.
Gruß,
Frank
Neue Version 1.6.0 von IRMP verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen:
- Neues Protokoll: FDC (IR keyboard)
- Timings vom DENON-Protokoll korrigiert
Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen:
- Neues Protokoll: FDC (IR keyboard)
- Timings vom DENON-Protokoll korrigiert
Damit kann man nun die bei Pollin erhältliche Infrarot-Tastatur FDC-3402
(Bestellnr. 711 056) auch am µC nutzen.
Achtung:
Die Protokolle SIEMENS und FDC werden sowohl für IRMP als auch für IRSND
beim Compilieren automatisch abgeschaltet, wenn F_INTERRUPTS kleiner als
14500 Hz ist. Grund: Die Erkennung bei niedrigeren Scan-Raten ist nicht
stabil.
Das ganze erkennt man in irmpconfig.h an folgendem Block:
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // DO NOT CHANGE! F_INTERRUPTS too low!
32
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // DO NOT CHANGE! F_INTERRUPTS too low!
33
#endif
Analoges gilt für irsndconfig.h.
Den IRMP-Artikel habe ich an den entsprechenden Stellen angepasst.
@Hugo Portisch:
Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich
schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.
Gruß,
Frank
Hallo Frank!
Vielen Danke für die prompte Reaktion. Ich komme erst am Abend zum
Testen.
Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen
der Quellen zu ersparen:
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not (default)^M
11
+#endif^M
12
^M
13
#endif /* _WC_IRMPCONFIG_H_ */^M
Der UART-Code kompoliert nicht auf einem Mega32. Die Registernamen
enthalten keine Null ('0'). Die Initialisierung der Baudrate besser wie
folgt (Mega32, andere Registernamen anpassen):
eku schrieb:> Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen> der Quellen zu ersparen:
Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit
die UART-Register bzw. -Kontanten portabel definiert, so dass das
Übersetzen nun auf jedem ATMEGA funktionieren sollte.
Kommt dann im nächsten Release.
Gruß,
Frank
>>@Hugo Portisch:>>Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich>>schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.
Ok, danke für die Info!
Wie sieht denn dann der empfange Code der FDC aus?
Also als IRMP_DATA Struct?
Stehen in Command dann die ASCII Werte?
Was für Werte hat z.B. die Windows Taste, STRG, Alt,...
Entsprechen diese dieser Liste:
http://msdn.microsoft.com/en-us/library/ms645540.aspx
Bitte 1-2 Beispiele als irmp_data posten damit ich das sehen kann.
Danke!
Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies
direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine
"normale" Tastatur funktioniert.
Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur
mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird
es schon happig alle Protokolle mit hineinzupacken...
Hugo Portisch schrieb:> Wie sieht denn dann der empfange Code der FDC aus?> Also als IRMP_DATA Struct?>> Stehen in Command dann die ASCII Werte?> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...
Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen
getrennte Codes gesendert werden.
>>Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen>>getrennte Codes gesendert werden.
Auch wär interressant wie es dann mit mehreren Tastendrücke aussieht.
Also z.B. STRG-C, WIN-D, SHIFT-A, STRG-ALT-ENTF,....
Hugo Portisch schrieb:> Wie sieht denn dann der empfange Code der FDC aus?> Also als IRMP_DATA Struct?
Ich habe mal den Output vom IRMP unter Linux angehängt.
> Stehen in Command dann die ASCII Werte?> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...
Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die
Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.
Im Moment werte ich die Bits 0-15 als Adresse, die Bits 25-36 als
Kommando aus. Wenn man sich den Scan der FDC-Tastatur im Detail (siehe
irmp-fdc-detail.txt) anschaut, dann sieht man, dass bei der
"Wiederholung" sich in den Bits 20-24 etwas ändert. Ob das jetzt ein
Repetition-Code ist, der durch längeres Drücken entstanden ist, oder
tatsächlich die Zustände "Drücken" und "Loslassen" beschreibt, weiss ich
noch nicht. Dazu habe ich noch zu wenig Infos.
> Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies> direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine> "normale" Tastatur funktioniert.
Jau :-)
Eher noch interessanter finde ich, einen µC einfachst mit einer
kompletten PC-Tastatur auszustatten - für die Bedienung von Menüs,
Konfigurationen etc.
> Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur> mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird> es schon happig alle Protokolle mit hineinzupacken...
Das wird knapp.
Ich sehe da aber noch Einsparungspotential. Durch geeignete
Parametrisierung könnte ich die Behandlung der Manchester-basierten
Protokolle (Bi-Phase) für RC5, RC6, GRUNDIG, NOKIA und SIEMENS noch
weiter zusammenfassen und dadurch Code einsparen. Könnte dann aber etwas
CPU-intensiver werden.
Gruß,
Frank
Hier nochmal eine kompaktere Darstellung, siehe Anhang. Sehr schön sieht
man hier, dass die 4 Bits 20-23 in der Wiederholung von 0 auf 1
wechseln.
Entweder ist das ein "Loslassen"-Flag oder das Zeichen für eine
Wiederholung. Das müsste eku mal systematisch testen - durch kurze und
lange Tastendrücke.
Da bei einigen Tasten der zweite Frame fehlt, nehme ich mal an, dass eku
hier die jeweilige Taste nur kurz gedrückt hat. Damit wären die 4
1er-Bits ein Zeichen für die Wiederholung, nicht das Loslassen.
Gruß,
Frank
Frank M. schrieb:> Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die> Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.
Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung
stehenden Tasten-Scans bitweise gruppiert:
Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste
gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.
Fragt sich nur, was die Bits bedeuten, die ich mit Fragezeichen versehen
habe. Vielelicht die Bits für STRG, ALT, SHIFT?
Bin gespannt auf mehr Input von eku.
Gruß,
Frank
Frank M. schrieb:> Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste> gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.
Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)
eku schrieb:> Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)
Och, lass mich doch... das ist spannender als Sudoku-Spielen ;-)
Gruß,
Frank
Hallo,
ich bekomme leider mit der Pollin Tastatur immer nur RC5 oder Siemens
Protokoll angezeigt. Bei mit läuft das ganze auf einem Mega 168 mit 8mHz
Quarz.
Hab natürlich die Version 1.6 und den F_INTERRUPTS auf 15000 gestellt.
Gruß
Torsten
Frank M. schrieb:> Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit> die UART-Register bzw. -Kontanten portabel definiert, so dass das> Übersetzen nun auf jedem ATMEGA funktionieren sollte.>> Kommt dann im nächsten Release.
Ich nutze SVN und freue mich über jeden Commit. Ich brauche kein
Release, Zwischenstand aus SVN reicht mit.
Torsten Kalbe schrieb:> Ich hab hier mal einen kleinen Scan von den Tasten 0 bis 9 eingestellt,> vielleicht hilft das für eine kurze Analyse.
Deine Tastatur hat ein ganz anderes Timing.
Die Pulszeiten in Deinem Scan sind etwa doppelt so lang wie die bei eku.
Ausserdem gibt es zwischendurch "Aussetzer", wo die Pulszeiten sogar auf
die 4-fache Länge anwachsen.
Dagegen haben die Pause-Zeiten nur die Hälfte der Länge wie bei der
Tastatur von eku - und das mit einer erheblichen Streuung.
Ein paar Fragen dazu:
1. Bist Du sicher, dass der Interrupt-Takt 15kHz und nicht mehr beträgt?
2. Welchen Timer benutzt Du?
3. Werden andere FBs bei 15kHz und 8MHz-Takt ohne Probleme erkannt?
4. Gab es Compiler-Warnungen?
5. Bist Du sicher, dass der Quarz auch genutzt wird und nicht nur der
interne Oszillator läuft?
Vielleicht reicht auch bei der Vielzahl der mittlerweile unterstützten
Protokolle und dem erhöhten Interrupt-Takt von 15kHz der Takt von 8MHz
nicht mehr aus.
Schalte mal soviel wie möglich an Protokollen ab und teste dann nochmal.
Ich habe mir die Tastatur mittlerweile selbst bestellt, damit ich in den
nächsten Tagen auch mal selbst testen kann.
Gruß,
Frank
Na,
also was den Quarz angeht, das habe ich im AVR Studio so eingestellt,
bzw. die Fuse so gesetzt.
Ob der Proz. wirklich den Interrupt-Takt 15kHz hat müßte ich mal
nachschauen/messen.
Ich nutze den OCR1A.
Andere FBs mit 15kHz habe ich nicht.
Ich werde morgen mal nachmessen, ich kann auch den wirklichen Takt des
IR Signals mal mit dem Scope nachmessen, dann sehen wir ja was los ist.
Gruß
Torsten
Hallo Frank!
Änderungswunsch für irmp_ISR(): return irmp_ir_detected;
Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine
Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen.
Konsequenterweise könnte der Test auf irmp_ir_detected in
irmp_get_data() entfallen. "Geradeaus-" uns "Kasko-"Programmierer
benötigen den Test.
Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück. Die
while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man
über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf
reagiert.
eku schrieb:> Änderungswunsch für irmp_ISR(): return irmp_ir_detected;
Kann ich gerne einbauen. Ich selbst würde das aber nicht nutzen und auch
nicht in Beispielen dokumentieren. Denn normalerweise wird irmp_ISR()
aus einer Interrupt-Funktion aufgerufen... und diese ist
definitionsgemäß void.
Okay, Du könntest Dir dann in der Applikation eine globale Variable
setzen und dann irmp_get_data() gezielt aufrufen.
Aber wo ist der Unterschied? irmp_get_data() macht sofort einen return,
wenn irmp_ir_detected == FALSE. Das einzige, was Du maximal sparst, ist
ein Funktionsaufruf.
> Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine> Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen.
Ich sehe da keinen Vorteil, sorry. Ich sehe da nur schlechten
Programmierstil.
> Konsequenterweise könnte der Test auf irmp_ir_detected in> irmp_get_data() entfallen.
Nein, werde ich auf keinen Fall rausnehmen, sonst muss der Programmierer
genau das machen, was ich oben beschrieb: irmp_ISR() aufrufen, den
Return-Wert in einer globalen Variablen speichern und in der
main-Routine dann auf diese globale Variable testen.
Da ich mich schon seit 25 Jahren mit UNIX beschäftige, selbst auch schon
einige Device-Treiber für UNIX und LINUX geschrieben habe, denke ich,
dass mein Verfahren eher einem vernünftigen Interface entspricht.
> "Geradeaus-" uns "Kasko-"Programmierer benötigen den Test.
Was sind "Geradeaus-" uns "Kasko-"Programmierer? ;-)
Beschreibe bitte ein Szenario, wo das nötig ist. Das einzige, was Du mit
Deinem Verfahren sparst, ist ein Funktionsaufruf aus Deiner
Main-Routine.
> Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück.
Ja, aber nur deshalb, damit man irmp_ISR() und irsnd_ISR() so
kombinieren kann, dass sie sich nicht ins Gehege kommen, vergleiche dazu
den IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#Source-Code_2
<zitat>
Möchte man IRMP und IRSND parallel verwenden (also als Sender und
Empfänger) schreibt man die ISR folgendermaßen:
1
ISR(TIMER1_COMPA_vect)
2
{
3
if(!irsnd_ISR())// call irsnd ISR
4
{// if not busy...
5
irmp_ISR();// call irmp ISR
6
}
7
// call other timer interrupt routines...
8
}
Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR
des Empfängers auf. Damit ist der Empfänger solange abgeschaltet,
während irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine
ist für IRMP und IRSND dann natürlich dieselbe.
</zitat>
> Die> while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man> über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf> reagiert.
Naja, darüber kann man streiten. Wenn der Ausgangsbuffer eines seriellen
Kanals voll ist, dann wartet die UNIX-Systemfunktion write() auch, bis
wieder "Platz" da ist. Jedenfalls im Normalfall - solange man das nicht
mittels eines ioctl-Aufrufs umstellt. Dasselbe gilt in der Regel
eigentlich auch für Windows-Systemfunktionen. Analoges gilt auch für
TCPIP-Stacks, wenn Du da auf Sockets schreibst. Die Dinger warten immer,
wenn das Gerät (z.B. Ethernet-Karte) zu langsam ist.
<EDIT>
Die Dinger warten immer aus Sicht der Applikation, nicht aus der Sicht
des Kernels natürlich.
</EDIT>
Ich schlage da folgenden Kompromiss vor:
Das heisst: mittels TRUE oder FALSE für do_wait kannst du selbst
bestimmen, ob irsnd_send_data() sofort mit einem Fehler zurückkommen
soll oder selbst wartet, bis das "Ausgabegerät" - also die IR-Diode -
wieder frei ist.
Gruß,
Frank
P.S.
Ich werde im Laufe des Tages mal ein Update im SVN einspielen.
Frank M. schrieb:> Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung> stehenden Tasten-Scans bitweise gruppiert:
Mittlerweile bin ich bei der "Entschlüsselung" weiter. Die Matrix ist
noch einfacher, als ich zunächst gedacht habe. Ausserdem steckt in dem
IR-Telegramm der Tastatur Redundanz drin, nämlich nicht nur Zeile und
Spalte, sondern auch noch ein Key-Code, der sich eigentlich aus Zeile
und Spalte berechnen lässt.
Im Moment sieht das bisher entschlüsselte Format folgendermaßen aus:
(Alle Binärzahlen mit LSB-first lesen!)
Verbleibt nur noch die Entschlüsselung der 6 Bits, die ich mit "STATUS"
bezeichnet habe. Da vermute ich mal, dass dort die Zustände der
Sondertasten - wie SHIFT, STRG, ALT usw. - gesendet werden. Es kann
natürlich auch sein, dass die ADRESSE im Telegramm in Wirklichkeit
kürzer ist und weitere Bits des Blocks ADRESSE mit Infos versehen sind.
Die bekomme ich aber erst raus, wenn weitere Scans vorliegen.
Da obige Binär-Zahlengruppen immer mit LSB-first gelesen werden müssen,
ergibt sich folgende Matrix:
Frank M. schrieb:> Okay, Du könntest Dir dann in der Applikation eine globale Variable> setzen und dann irmp_get_data() gezielt aufrufen.
Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in
Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt
hoffentlich meine Änderungswünsche:
Eine Verriegelung von Sender und Empfänger habe ich bewusst "ausgebaut".
Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du
lässt alles so wie es ist.
eku schrieb:> Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in> Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt> hoffentlich meine Änderungswünsche:
Nett, Du könntest damit ja Megabytes an Daten übertragen ;-)
> Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du> lässt alles so wie es ist.
Nein, ich baue den Return-Wert in irmp_ISR() ja ein, kann ja durchaus
für manche Szenarien sinnvoll sein. Ebenso das wait-Flag in irsnd_ISR().
Gruß,
Frank
Sodele, Version 1.6.1 ist nun im SVN.
Änderungen:
- Interface von irmp_ISR() geändert: gibt flag zurück, ob Frame
empfangen wurde
- Interface von irsnd_send_data() geändert: Nun auch Senden ohne
Warteschleife möglich
- UART-Routinen angepasst, damit das IRMP-Logging ohne Änderung
auf allen ATMEGAs läuft
- Debug-Output-Format angepasst für:
Silent-Mode: Option -s
Verbose-Mode: Option -v
Normal-Mode: <keine Option>
Da diese (teils gravierenden) Änderungen noch nicht im IRMP-Artikel
dokumentiert sind, gibt es auch noch keinen Download über den Artikel.
Vielmehr werde ich dort vermerken, dass die SVN-Version keine
Release-Version ist.
Gruß,
Frank
Frank M. schrieb:> Ich werde im Laufe des Tages mal ein Update im SVN einspielen.
Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef
UBRR0H'.
eku schrieb:> Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef> UBRR0H'.
Upps, ich hatte das durch eine schematische Änderung in die Konstante
UART0_UDR_BIT_VALUE geändert... war natürlich Käse.
Ist korrigiert,
Frank
Hallo,
ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.
Gemessen mit einem Tektronix 2014.
2120 mS Low
920 µS High
330 µS Low
690 µS High
310 µS Low
680 µS High
Die 690 µS High, 310 µS Low wiederholen sich 6 mal.
Dann kommt
190 µS High
350 µS Low
Das wiederholt sich auch viele male und wird dann auch mal von einer
690 µS High, 310 µS Low Kombination unterbrochen.
Ich hab das mal so ins define umgesetzt
#define FDC_START_BIT_PULSE_TIME 2120.0e-6
#define FDC_START_BIT_PAUSE_TIME 920.0e-6
#define FDC_PULSE_TIME 330.0e-6
#define FDC_1_PAUSE_TIME 690.0e-6
#define FDC_0_PAUSE_TIME 190.0e-6
Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin
bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann
auch noch RC5 und Siemens mit auf.
Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die
FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen
anderen.
Gruß
Torsten
Hallo Frank und Torsten!
Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und
SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von
anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.
Hy eku,
dann versuch doch mal die defines von mir und schalte den Siemens und
RC5 ab, dann sollte es gehen.
Vielleicht hilft das Frank um zu erkennen woran es noch liegen kann.
Ich bin gerne bereit das hier weiter mit dem Scope zu vermessen.
Um nochmal auf die Taktung zu kommen.
Ich habe bei mir mal einen Pin wechseln lassen, wenn der in den OCR
Interrupt geht.
Mit dem 8mhz Quarz habe ich exakt 15kHz, mache ich das mit dem internen
RC Oscal bin ich bei 15,6kHz.
Daran ändern auch das auslesen des Oscal Calibration Byte nichts, das
kann an der Toleranz liegen.
Gruß
Hallo Torsten,
Torsten Kalbe schrieb:> ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.> Gemessen mit einem Tektronix 2014.>> 2120 mS Low
Sicher, dass es nicht 2120 µs waren? ms kommt mir verdammt lang vor ;-)
> 920 µS High> 330 µS Low> 690 µS High> 310 µS Low> 680 µS High>> Die 690 µS High, 310 µS Low wiederholen sich 6 mal.> Dann kommt>> 190 µS High> 350 µS Low>> Das wiederholt sich auch viele male und wird dann auch mal von einer> 690 µS High, 310 µS Low Kombination unterbrochen.
Das sieht ziemlich kaputt aus. Diese Timings habe ich auch im Scan
gesehen, konnte es aber kaum glauben, denn bei ekus Tastatur waren
Timings:
Start-Bit 1390µs Puls, 640µs Pause
0-Bit 200µs Puls, 145µs Pause
1-Bit 200µs Puls, 475µs Pause
Stop-Bit 200µs Puls
Siehe auch IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP#Protokolle
Dort habe ich alle Timings dokumentiert.
Bis auf das Start-Bit waren also alle Pulse gleich lang. Bei Dir ist das
komplett anders. Die 190µs-Pause fällt auch komplett aus dem Rahmen.
> Ich hab das mal so ins define umgesetzt>> #define FDC_START_BIT_PULSE_TIME 2120.0e-6
Korrekt
> #define FDC_START_BIT_PAUSE_TIME 920.0e-6
Korrekt.
> #define FDC_PULSE_TIME 330.0e-6
Jepp.
> #define FDC_1_PAUSE_TIME 690.0e-6> #define FDC_0_PAUSE_TIME 190.0e-6
Da glaube ich eher, dass es umgekehrt ist. Die 0en kommen öfter vor als
die 1en. Aber das ist erstmal nebensächlich, dann ist das bei Dir halt
erstmal invertiert.
> Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin> bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann> auch noch RC5 und Siemens mit auf.
Das passiert, wenn sich ein Bit im Frame nicht an die vorgegebenen
Zeiten hält. Dann "sucht" IRMP nach dem nächsten Start-Bit, um sich
wieder zu synchronisieren. Dabei "erkennt" IRMP dann ein Daten-Bit des
FDC-Stroms als Start-Bit von RC5 oder Siemens und klinkt sich dann dort
wieder ein - fälschlicherweise. Da muss man dann die Toleranzen für die
Daten-Bits höher drehen - nicht für die Start-Bits. Ich schicke Deinen
Scan gleich nochmal durch den IRMP unter Linux und passe die Toleranzen
an. Vielleicht klappt das. Allerdings sind bei Deiner Tastatur
erhebliche Streungen im Timing. Vielleicht ist das Ding ja einfach nur
kaputt?
> Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die> FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen> anderen.
Gut, ein Hoffnungsschimmer. Dann probiere ich mal, das als
"FDC2"-Protokoll zu implementieren. Blöd, dass es da wieder eine
Variante gibt. Bin mal gespannt, was meine bestellten Tastaturen
aussenden... hoffentlich nicht noch eine dritte Variante...
Gruß,
Frank
Hi eku,
eku schrieb:> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und> SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.
Wieso das? Das lief doch vorgestern noch bei Dir... ich habe die Timings
seitdem nicht mehr geändert... merkürdig.
Habe gerade nochmal den Source im SVN gegen die Scan-Datei von Dir
laufen lassen: FDC wird eindeutig erkannt. Du musst da noch irgendwas
geändert haben... eine andere Erklärung habe ich nicht. Oder spinnt
Deine Tastatur jetzt auch so rum wie die von Torsten?
Gibt es da vielleicht auf der Unterseite der Tastatur einen
Schiebeschalter, mit dem man das Protokoll umschalten kann, damit sich 2
baugleiche Tastaturen in einem Raum nicht ins Gehege kommen? Bei
Funktastaturen habe ich das schon öfter mal gesehen...
Gruß,
Frank
Das Start-Bit ist okay, die Pulsdauern schwanken zwischen 5 und 7, also
zwischen 330µs und ca. 470µs.
Die Pausen sind offenbar:
9 - 11 = 600µs - 733µs für 1-Bit
1 - 3 = 66µs - 200µs für 0-Bit
Und diese Zeile ist der Knackpunkt (s.o.):
pulse: 14 pause: 1
Hier wurde gar keine Pause aufgezeichnet, weil sie einfach zu kurz war!
Dadurch "verlängert" sich die Pulsdauer auf ziemlich genau das Doppelte.
In Wirklichkeit sind das aber 2 Bits, nämlich in etwa so was:
pulse: 7 pause: 0 <--- Pause zu kurz, wird nicht erkannt
pulse: 7 pause: 1 <--- Pause wird erkannt
Fazit: 15kHz sind zu kurz, um diese Frames mit den sehr kurzen Pulsen
verlässlich zu detektieren. Das obige Phänomen tritt bei fast allen
Tasten in Deinem Scan auf, nämlich ungefähr bei 50% der Scans.
Du könntest mal auf 20kHz hochgehen - und die Compiler-Warnungen
entweder ignorieren oder vermeiden, indem Du z.B. BANG_OLUFSEN (und
evtl. weitere) abschaltest, bis alle Compiler-Warnungen weg sind.
Gruß,
Frank
Torsten Kalbe schrieb:> Ich hab alle Protokolle ausser dem FDC abgeschaltet, aber trotzdem zwei> Warnungen bekommen.
Okay, darum kümmern wir uns später.
> Tasten 1 bis 4 hängen hier an.
Danke, habe ich mir angeschaut, Deine ausgewählten Timings nochmal ein
wenig abgeändert, die Toleranzen geändert und das Ganze als Protokol
FDC2 (= 19) implementiert. Der Source ist im SVN. Damit werden Deine
Tasten bei 20kHz erkannt. Das Ergebnis der Codes ist identisch mit denen
von eku.
Deine Tastatur encodiert die Tasten also genauso wie die von eku, aber
das Timing ist verschieden.
Nochmals meine Frage: Kein Schiebeschalter unter der Tastatur, wo man
das Timing vielleicht umschalten kann, damit man 2 baugleiche Tastaturen
in einem Raum nutzen kann?
Test bitte mal den Source bei 20kHz. Sollte Deine Tasten nun einwandfrei
erkennen.
Ein Knackpunkt ist aber da noch: Ich musste die Toleranzen für RC5 auf
0% runterschrauben, da das FDC2-Protokoll vom Startbit her mit dem
RC5x-Protokoll kollidiert. Da muss ich mir also was einfallen lassen,
denn im Moment wird bei Toleranz von 0% kein RC5 mehr erkannt :-(
Naja, erstmal ist die SVN-Version als Testversion zu sehen.
Gruß,
Frank
Hi eku,
eku schrieb:> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und> SIEMENS.
Ich bin mir ziemlich sicher, dass Du es geschafft hast, Deine Tastatur
auf das Timing von Torsten umzuschalten, welches ich mittlerweile als
FDC2 implementiert habe (siehe SVN). Das Timing von FDC2 kollidiert
tatsächlich mit RC5 - vom Startbit her. Da suche ich noch nach einer
Lösung.
> Beim Testen ist mir noch aufgefallen, dass last_pause noch von> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.
Danke für den Tipp, tatsächlich wird es bei allen Manchester-codierten
Protokollen benutzt, also auch noch für Grundig und Nokia. Werde ich
korrigieren.
Gruß,
Frank
Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen
Jumper oder ähnliches.
EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.
Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?
Pollin schreibt zu der Tastatur, das man Applikationen im Internet
finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da
auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.
Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.
Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp für 1
Euro.
Torsten Kalbe schrieb:> Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen> Jumper oder ähnliches.
Hm, blöd.
> EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.
Es funktioniert aber bei mir mit den Scan-Dateien, die eku hier
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
angehängt hat.
Hier die Timing-Daten, die ich aus ekus Scan-Dateien gewonnen habe:
Zwischen diesen Werten liegt ungefähr ein Faktor 1,5.
Dafür gibt es folgende Möglichkeiten als Erklärung:
1. Beide Tastaturen arbeiten vom Timing her tatsächlich identisch
und einer von Euch beiden arbeitete bei der Scan-Aufnahme mit
einem Fehler von 150% bei der Timerparametrisierung.
2. Die Tastaturen arbeiten mit einer Abweichnung von 150% - vielleicht
kosten sie deshalb nur knapp 2 EUR bei Pollin ;-)
Das FDC1-Timing (von eku) kollidiert aber seit Version 1.6.1 nicht mehr
mit RC5 (weil ich die Toleranzen für RC5 auf 10% reduziert habe), das
ist nur beim FDC2-Timing (von Dir) der Fall. Also könnte es sein, dass
die Möglichkeit 1 bei eku der Fall war (zum Zeitpunkt des Scannens), er
den Fehler mittlerweile korrigiert hat und deshalb nun in dieselbe
RC5-Falle reinläuft wie Du.
Oder seine Tastatur hat sich umgestellt auf das andere Timing. Nur ein
neuer Scan von eku kann das aufklären.
Ich bin gespannt auf die Lieferung meiner Tastaturen - ich hatte einfach
mal frech 5 Stück bestellt. Dann hoffe ich, dass wir mehr Licht ins
Dunkel bringen.
> Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?
Glaube ich nicht.
> Pollin schreibt zu der Tastatur, das man Applikationen im Internet> finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da> auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.
Nein, da habe ich nichts gefunden.
> Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.
Ja.
> Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp> für 1 Euro.
Nämlich welchen?
Gruß,
Frank
Moin,
das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja
das Timing bestätigt, welches ich mit der Schaltung gescant habe.
Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man
durch drücken einer solchen gefolgt von einer zweiten das Timing
verstellen, das wäre eine Möglichkeit.
Die zweite Tastatur ist diese:
http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html
Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch
mal einen Scan zu schicken.
Torsten Kalbe schrieb:> das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja> das Timing bestätigt, welches ich mit der Schaltung gescant habe.
Stimmt. Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei
einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch
Pulsdauern bei eku um den Faktor 1,5 kürzer sind. Dafür haben die Pausen
in ekus Scan-Datei eine wesentlich geringere Schwankung, so dass der
Fall "Pause=0" bei ihm trotz kürzerer Zeiten nicht auftritt. Deshalb
funktionierte es mit seinen Scan-Dateien und meinem linux-irmp mit 15kHz
perfekt.
Damit bleiben als Möglichkeiten übrig:
1. Beide Tastaturen arbeiten vom Timing her identisch und eku hat
versehentlich mit 10kHz statt 15kHz (wie angegeben) gescannt.
2. Die Tastaturen arbeiten tatsächlich mit einer Abweichnung von 150%
> Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man> durch drücken einer solchen gefolgt von einer zweiten das Timing> verstellen, das wäre eine Möglichkeit.
Jau.
Frage: Hattest Du die 1.6.2 mit den von mir angepassten Timings und dem
neuen Protokoll "FDC2" (=19) aus dem SVN nochmal testen können?
> Die zweite Tastatur ist diese:> http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html
Ahja. Die Beschriftung der Tasten ist laut Pollin aber verschieden. Hast
Du da eine mit deutschem Layout?
> Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch> mal einen Scan zu schicken.
Gern!
Gruß,
Frank
Frank M. schrieb:> Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei> einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch> Pulsdauern bei eku um den Faktor 1,5 kürzer sind.
Ich komme erst am Wochenende dazu, weitere Scans aufzuzeichnen. Das
FDC-Protokoll mag zwar im Linux-IRMP erkannt werden, bei mir mit 15kHz
definiitiv nicht, auch wenn ich RCx und SIEMENS abklemme. Mehr dazu
morgen.
15kHz und FDC: return von irmp_ISR() und irmp_get_data() ist jeweils 1,
aber proto, address und command sind Null
20kHz und FDC: dito
kurze Tastendruck: 3 Frames, 2. und 3. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat
20kHz und FDC2: proto FDC2, address 3F, command 0x00-0xFF
kurze Tastendruck: 2 Frames, 2. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat
Mit 20kHz liefert irmp_ISR() häufig 1 (irmp_detected), auch wenn keine
IR-Signale gesendet werden.
Hallo Leute,
die Tastatur habe ich noch nicht mit dem neuen FD2 getestet, mache ich
aber heute noch.
Meine andere Tastatur von Pollin hat eine QWERTY Layout, die Return und
Sondertasten sind in einer mir momentan fremden Sprache :-)
Ich habe soeben einen neuen Scan einer IR Fernbedienung für
Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln
können, dann kann ich nämlich endlich meine Rennbahn entsprechend
verbessern !!
Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast
selber entschlüsselt :-))
Hier eine erste Analyse:
Eine Fernbedienung kann eine Senderadresse von 0 bis 3 haben,
daher 4 Fahrzeuge.
Es können 3 AD Werte und 8 Schalterstellungen gesendet werden.
Die oberen zwei bits scheinen festzulegen, was gesendet wird.
Davon ausgehend das ein langer Puls, 900µS, 1 entspricht:
00, 10, 01, hier werden die AD Werte gesendet
11, dann werden die Schalterstellungen gesendet.
Die nächsten zwei Bits sind dann die vier möglichen Adressen.
Ist das vielleicht zu implementieren ?
Habe jetzt die neu SVN installiert und das funktioniert sehr gut !
Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.
Taste 1 entspricht 0x02 und Taste a ist 0x1F.
Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in
einen Editor laden und könnte dann das Diagramm sehen ?
Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie
in Deiner Doku zu sehen ist ?
Ich habe allerdings nur Windows laufen.
Gruß
Torsten
Hi Torsten,
Torsten Kalbe schrieb:> Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast> selber entschlüsselt :-))
Sieht sehr einfach aus, sag mir noch die Frequenz, mit der Du das
gescannt hast.
> Ist das vielleicht zu implementieren ?
Jau, das kriege ich hin. Ich melde mich dann, komme aber wohl frühestens
heute abend dazu.
Gruß,
Frank
Torsten Kalbe schrieb:> Habe jetzt die neu SVN installiert und das funktioniert sehr gut !
Freut mich.
> Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.> Taste 1 entspricht 0x02 und Taste a ist 0x1F.
Passt, das ist der "Keycode", den ich oben in die Matrix geladen habe.
> Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in> einen Editor laden und könnte dann das Diagramm sehen ?
Nein, kein Diagramm, Du siehst im Editor halt Folgen von 0en (Puls) und
1en
(Pause). Bei Dir sind sie 1,5mal länger, also z.B.
00000000000000000000
0000000000000
> Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie> in Deiner Doku zu sehen ist ?
Die Bilder sind ein Oszi-Bild, nix weiter.
> Ich habe allerdings nur Windows laufen.
Dann scanne Deine Rennbahn-FB mit 10kHz ein und gebe dann ein:
irmp.exe -a < rennbahn.txt
Dann siehst Du eine Häufigkeitsverteilung als "Spektrum", das Ding
"malt" Dir dann mit ASCII-Zeichen ein paar (unförmige) Glockenkurven.
Geht aber erst mit Version 1.6.3, die ich gestern nachmittag ins SVN
eingecheckt habe.
Beispiel für eine ekus Scan mit 15kHz:
Daraus kann man die Länge der Pulse/Pausen dann direkt ablesen :-)
irmp.exe -l <rennbahn.txt
Dann siehst Du die Längen der Pulse und Pausen in Zahlen - als Listing.
irmp.exe -v <rennbahn.txt
Zeigt Dir dann Protokoll-Infos an - aber nur, wenn irmp das Protokoll
bereits kennt.
irmp.exe <rennbahn.txt
Dasselbe, aber kompakter, Fehler werden unterdrückt.
Zusammenfassung:
-a analyze
-l list
-v verbose
Das oben beschriebene gilt - wie gesagt - nur mit der neuesten
SVN-Version, bei den vorherigen Versionen haben die Optionen andere
Bedeutungen/Ausgabeformate.
Gruß,
Frank
Hallo Torsten,
Torsten Kalbe schrieb:> Ich habe soeben einen neuen Scan einer IR Fernbedienung für> Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln> können, dann kann ich nämlich endlich meine Rennbahn entsprechend> verbessern !!
Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN.
Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.
Jeder Frame hat 13 Bits, ich habe sie allesamt mit MSB in irmp_data.code
abgelegt. Das Ermitteln der Bedeutung der Bits überlasse ich damit Dir,
Du brauchst Dir ja einfach nur mal die von IRMP ausgegebenen Codes als
Binärzahl hinzuschreiben.
Viel Spaß,
Frank
Hy,
das funktioniert klasse !!!
Die 13 bits sind auch sehr einfach aufgeteilt. Es müßte aber so
eingebaut werden, das auch irmp_data.address benutzt wird.
Da es ja in Summe nur 13 bits insgesamt sind, sind die oberen drei immer
null.
Dann folgen zwei, die die Art der Daten angeben, dann folgen die
eigentlichen zwei Adressbits, dann 7 Datenbits, das letzte Bit ist wohl
sowas wie ein Verify, das sorgt dafür, das immer eine ungerade Zahl an 1
bits gesendet wird.
Aufgeteilt ist es also so:
xxxCCAADDDDDDDDV
Ich weis jetzt nicht, wie kompliziert es ist, aber ich fände es am
besten, wenn die mit AA bezeichneten bits im irmp_data.address
übertragen werden, dort wo jetzt immer Null kommt:
xxxxxxxx xxxxxxAA
Ins irmp_data.command käme dann:
xxxxxCCV DDDDDDDD
Gruß
Torsten
Mir ist jetzt noch etwas aufgefallen.
Bei den Datenbits scheint es LSB first zu sein, also so:
xxxCCAA D0 D1 D2 D3 D4 D5 D6 D7 V
besser wäre dann, wenn das irmp_data.command so aussähe:
xxxxxCCV D7 D6 D5 D4 D3 D2 D1 D0
Natürlich kann man diese ganze Bitmanipulation auch im Hauptprogramm
machen, aber bei den anderen Protokollen wird das ja auch entprechend
übergeben.
Was ich gerade feststelle ist, das es bei den Adress IDs auch so ist.
Bei den Commandbits wird es dann genauso sein, daher wäre auch da eine
entsprechende Sortierung besser.
Also nochmal, bisher kommt das alles so im irmp_data.command an:
xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
Demnach sollte irmp_data.address so aussehen:
xxxxxxxx xxxxxx A1 A0
Das irmp_data.command würde ich so aufbauen:
xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
Das verify-Bit habe ich ganz nach vorne gestellt. Damit ergibt sich, das
der zweite Char dann die Daten sind und im ersten steht der Befehl und
das Verify. Der Befehl kann dann direkt ausmaskiert werden, ohne danach
noch geschoben zu werden.
Wäre das so ok, bzw. hab ich das verständlich rübergebracht ?
Frank M. schrieb:> Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN.> Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.
Hier machts sich eine Designschwäche des Dekoders bemerkbar. Dies
passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt
auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das
Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren
Protokollen in die Sackgasse.
Hi Torsten,
Torsten Kalbe schrieb:> Also nochmal, bisher kommt das alles so im irmp_data.command an:>> xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V>> Demnach sollte irmp_data.address so aussehen:> xxxxxxxx xxxxxx A1 A0>>> Das irmp_data.command würde ich so aufbauen:>> xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
Du kannst in irmp.h folgendes einstellen:
1
#define RCCAR_LSB 1 // LSB...MSB
Dann hast Du das schon mal auf LSB first umgestellt.
Der Frame sieht nach Deinen Ausführungen so aus:
Bit 0 1 2 3 4 5 6 7 8 9 10 11 12
C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
Dann sollte in irmp_data.address die Adresse stehen.
Jetzt zu den Kommando-Bits, das ist ein wenig schwierig, denn IRMP kann
über die Preprocessor-Konstanten bisher nur Adress-Bits und
Kommando-Bits in irmp_data.address und irmp_data.command aufteilen, wenn
sie direkt aufeinanderfolgend sind.
Wenn Du schreibst:
1
#define RCCAR_COMMAND_OFFSET 4 // skip 4 bits
2
#define RCCAR_COMMAND_LEN 9 // read 9 bits
... dann fehlen Dir C0 und C1. Das Ganze funktioniert also nicht.
Daher empfehle ich, die Preprocessor-Konstanten bis auf die
LSB-Geschichte unangetastet zu lassen und erstmal alles als data
aufzufassen, also bitte nur ändern:
1
#define RCCAR_LSB 1 // LSB...MSB
Die Aufteilung in Adresse und Kommando kannst Du erst am Ende machen,
nämlich in irmp_get_data().
Dazu fügst Du folgenden Block in irmp_get_data im case-switch ein -
analog zu den anderen:
eku schrieb:> Hier machts sich eine Designschwäche des Dekoders bemerkbar.
Ja, ich weiss, das hatte Dich ja schon vor Monaten (im Januar) gestört.
> Dies passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt> auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das> Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren> Protokollen in die Sackgasse.
Du hast nur zu einem Teil recht. In diesem Fall (RC5 und FDC2) würde
auch das nachträgliche Auswerten des Gesamtframes nichts bringen. Es gab
nämlich im FDC2-Protokoll durchaus Scans, die komplett ohne Fehler
durch den RC5-Decoder durch laufen. Diese würden auch mit Deiner
nachträglichen Methode fälschlicherweise als RC5 erkannt werden.
Der Grund liegt am Manchester-Code. Dieser besetzt leider mit den 4
möglichen Abfolgen
1-fach Länge Puls
2-fach Länge Puls
1-fach Länge Pause
2-fach Länge Pause
ein breites Spektrum an möglichen Zeiten. Da bei RC5 das Start-Bit nicht
ausgezeichnet ist (es hat dieselben Timings wie die nachfolgenden
Daten), ist das geradezu ein Multiprotokoll-Decoder-Killer. Die
Entwickler bei Siemens haben aus den Erfahrungen auch gelernt und das
bei RC6 geändert: dort gibt es ein Start-Bit mit einem Timing, das nicht
in den Daten selbst verwendet wird.
Bei den Pulse-Distance-Protokollen ist das anders. Da gibt es nur 2
Möglichkeiten (im Start-Bit):
1-fach Länge Puls
1-fach Länge Pause
Daher gibt es hier naturgemäß untereinander wesentlich weniger Konflikte
- bisher nämlich keine.
Deine damals schon vorgeschlagene Methode, den Frame erst nachträglich
zu bewerten und zu dekodieren, ist wesentlich aufwendiger und kostet
nicht nur einen Buffer zum Speichern des Frames, sondern auch einen
wesentlichen Mehraufwand an Code. Ausserdem würde Deine Methode in der
Kombination RC5+FDC2 oder RC5+RCCAR genauso kläglich versagen, denn auch
bei der nachträglichen Auswertung würdest Du bestimmte FDC- und
RCCAR-Frames komplett als RC5 auffassen können, ohne eine Regel zu
verletzen.
IRMP wechselt sogar on-the-fly das erkannte Protokoll, z.B. vom SAMSUNG
auf das SAMSUNG32-Protokoll, ebenso vom Grundig- auf das
Nokia-Protokoll, wenn plötlzich mitten im Frame andere Bedingungen
auftreten. Was IRMP nicht kann, ist von einem Manchester-Protokoll auf
ein Puls-Distanz-Protokoll zu wechseln, da hier die bisher decodierten
Bits nicht mehr "umzurechnen" sind.
Mein Fazit: Aus obigen Gründen halte ich an der Methode, wie IRMP die
Protokolle detektiert, fest. Dass es bei mittlerweile 20 Protokollen,
die IRMP "versteht", zu Konflikten kommen kann, halte ich für durchaus
normal. Wenn diese Konflikte auch nur bei exotischen Protokollen (bzw.
Kombinationen) auftreten, halte ich das auch für durchaus akzeptabel.
Ich kann mir auch nicht vorstellen, dass ein Decoder für eine Rennbahn
auch noch RC5 kennen muss.
Bei den Main-Stream-Protokollen gibt es im IRMP keine Konflikte. Das
reicht für die meisten Anwendungen aus.
Gruß,
Frank
eku schrieb:> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um> den Überlauf bei höheren Sampleraten zu verhindern.
Habe ich mir auch schon überlegt, die Variable last_pause muss dann aber
auch auf 16 Bit erhöht werden.
Kostet zusätzliche 220 Programmcode und mehr Prozessorlast.
Ich überlege es mir noch (bzw. suche nach einer Alternativlösung, evtl.
unter Benutzung einer Überlaufvariablen). Umschalten auf 16 Bit würde
ich das auch erst ab F_INTERRUPT > 15000. Darunter braucht man es nicht.
Gruß,
Frank
Hallo Frank,
jo das funktioniert.
Aber warum soll denn die Adresse nicht schon damit ummaskiert werden,
das würde doch immerhin eine gewisse Gleichmäßigkeit zu den anderen
Protokollen haben.
Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
#define RCCAR_ADDRESS_OFFSET 2 // skip 2 bits
#define RCCAR_ADDRESS_LEN 2 // read 2 address bits
Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in
den IRSND einfügen.
Das habe ich schon gemacht:
in der irsndconfig.h habe ich eingefügt:
1
#define IRMP_SUPPORT_RCCAR_PROTOCOL 1 // flag: support RC car
Was muß mit dem has_stop_bit gemacht werden und wie ist es mit den
repetitions, sowas gibt es da alles nicht.
Was wohl noch fehlt sind die eigentlichen Daten, da blicke ich aber noch
nicht ganz durch was da gemacht werden muß ?
Auf jeden Fall müßte da ja auch wieder "zurückgeschoben" werden, aber
ich weis nicht genau wo das dann hin muß
Hi eku,
eku schrieb:> Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten> (vgl. Beitrag "Re: IRMP - Infrared Multi Protocol Decoder").
Danke, habe sie nun mal durch den IRMP geschickt, Deine Tastatur hat
dasselbe Timing wie Torsten, die Tasten werden alle als FDC2-Protokoll
erkannt.
Das heisst, dass Dein damaliger Scan key15.txt aus
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
tatsächlich nur mit 10kHz erzeugt wurde - und nicht mit 15kHz, wie Du
angegeben hast.
Was auffällig ist: die Timings Deiner Tastatur sind wesentlich exakter,
sie würde auch bei 10kHz von IRMP einwandfrei erkannt werden. Die
Streuungen der Puls-/Pausenlängen sind bei Torstens Tastatur wesentlich
breiter, gerade die Pausen werden zwischendurch arg kurz, so dass hier
20kHz als Scan-Rate benutzt werden muss.
Woran liegt das? Vielleicht doch am benutzten IR-Empfänger?
Daher Frage an Euch beide (eku und Torsten): welche IR-Empfänger nutzt
Ihr?
Ich werde das FDC2-Protokoll in FDC umbenennen und das FDC1-Protokoll
aus dem IRMP wieder rausnehmen. Es gibt keine zwei verschiedenen
Timings, es gibt nur eins.
Ich melde mich dann später wegen der Tastatur-Matrix nochmal.
Gruß,
Frank
Hi Torsten,
Torsten Kalbe schrieb:> ich benutze diesen hier von Reichelt, ich ein 36kHz Typ.>> SFH 5110-36
Danke für die Info. Bin gespannt, ob eku einen mit höherer Frequenz
benutzt und deshalb sein Timing besser ist.
> Ich hatte mir das Signal ja auch auf dem Oszilloskop angeschaut, und da> konnte ich solche Ausreisser ja garnicht sehen.
Ich habe die Analyze-Funktion von IRMP mal ein wenig ausgebaut, hier die
Timings von ekus Tastatur:
eku schrieb:> ich benutze das Pollin ATMEL Addon-Board V1.0 (810 053) mit TSOPxx36,> der breitbandiger als der SFH 5110-36 ist.
Das könnte der Unterschied sein:
Wenn das FDC-Keyboard mit 40kHz oder höher sendet, könnte der
SFH-Empfänger seine Probleme damit haben. Beim TSOP1736 gibt es keine
Probleme mit einer 40kHz-Modulation, da wird "nur" die Reichweite ein
wenig geringer.
Ich habe zu Hause sowohl TSOP1736 als auch TSOP1738 zum Testen.... aber
leider ist immer noch keine FDC-Tastatur angekommen. Pollin lässt sich
mal wieder ein wenig Zeit...
Gruß,
Frank
Ich schraube die nächsten Tagen nochmal meine Tastatur auseinander und
hänge das Scope an die IR-LED, dann sehen wir was da für eine Frequenz
drauf liegt.
Pollin hat bei meiner letzten Lieferung auch über eine Woche gebraucht,
die haben wohl momentan gut zu tun....
hallo,
sorry schon mal für die dumme frage aber:
was läuft hier beim Kompilieren falsch?
meine makefile (arbeite unter linux und will es für einen atmega168
erstellen)
1
# controller
2
MCU = atmega168
3
4
# frequency
5
F_CPU = 20000000UL
6
7
# main application name (without .hex)
8
# eg 'test' when the main function is defined in 'test.c'
9
TARGET = main
10
11
# c sourcecode files
12
# eg. 'test.c foo.c foobar/baz.c'
13
SRC = $(TARGET).c irmp.c
14
15
# asm sourcecode files
16
# eg. 'interrupts.S foobar/another.S'
17
ASRC =
18
19
# headers which should be considered when recompiling
Max M. schrieb:> was läuft hier beim Kompilieren falsch?> # use more debug-flags when compiling> DEBUG = 1
Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man
IRMP nativ für Linux übersetzt.
Gruß,
Frank
Hi Torsten,
Torsten Kalbe schrieb:> Tastatur läuft auf 38kHz, hab ich grad nachgemessen.
Danke für die Info. Das sollte Dein IR-Empfänger aber noch packen. Oder
hast Du alternativ einen 38kHz-Empfänger zur Hand?
Gruß,
Frank
Hallo Torsten,
Torsten Kalbe schrieb:> Um das ganze zu vervollständigen möchte ich das RCCar jetzt auch noch in> den IRSND einfügen.
Du hast das schon ganz gut hinbekommen, aber ein paar wichtige Sachen
fehlen noch. Solange es dafür keine Doku gibt, wie man einen Encoder in
IRSND einbaut, wirds auch schwierig.
Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht
kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)
Gruß,
Frank
Hy,
also ich habe einen TSOP1738 Empfänger hier, mit dem könnte ich ein paar
Scans machen. Ich bin mir aber garnicht sicher, welchen ich ursprünglich
mal verwendet hatte....
Zum RCCar und der Doku, das kann ich dann sicherlich mal versuchen.
Hi eku,
eku schrieb:> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um> den Überlauf bei höheren Sampleraten zu verhindern.
Wird jetzt abhängig von F_INTERRUPTS gemacht, sobald IRMP_TIMEOUT_LEN
(das ist die Konstante mit dem höchsten Zeitwert) droht überzulaufen,
werden irmp_pause_time und last_pause als uint16_t definiert.
So kommt der erhöhte Codebedarf nur bei höheren Frequenzen zum Tragen -
aktuell ab 15875Hz und mehr. Ist eingecheckt im SVN als Version 1.6.5.
Gruß,
Frank
Hallo Frank!
Schade das sich RC5 und FDC ausschließen. Im
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
beschreibst Du ja, woran es liegt. Fällt Dir vielleicht noch ein Kniff
ein, wie es doch gehen könnte?
Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames
erkannt, egal wie kurz ich sie betätige. Alle Maustasten werden immer
als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten
Bits begründet sind.
In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" schreibst Du noch
was von anderen Bits,
Frank M. schrieb:> Ich schaue, dass ich RCCAR diese Woche in den IRSND einbaue. Vielleicht> kannst Du das dann "abgucken" und im IRMP-Artikel dokumentieren ;-)
FDC- und RCCAR-Protokoll sind nun auch im IRSND drin - eingecheckt im
SVN.
Demnächst gibt es dann ein neues Release.
Gruß,
Frank
eku schrieb:> Schade das sich RC5 und FDC ausschließen.
Ja, sehr schade.
> Fällt Dir vielleicht noch ein Kniff ein, wie es doch gehen könnte?
Im Moment "verrennt" sich der IRMP im RC5, weil er das Start-Bit früher
gegen RC5 checkt als gegen FDC. Vielleicht drehe ich die Reihenfolge
rum, denn ein FDC-Frame ist länger als ein RC5-Frame. Ich könnte ihn
also zunächst in den FDC-Decoder reinlaufen lassen und wenn plötzlich
völlige Dunkelheit herrscht, aber noch nicht alle vermeintlichen
FDC-Bits empfangen wurden, die bisherigen Bits in RC5-Manchester-Code
"umrechnen". Das könnte vielleicht gehen, ich werde mal drüber
nachdenken.
> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames> erkannt, egal wie kurz ich sie betätige.
Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht
ausnahmslos. Ich könnte die Regel einbauen, dass ein Frame mindestens 2x
reinkommen muss (einmal mit vier 0-en im REPEAT-Block des Frames, einmal
mit vier 1-en). Erst alle weiteren Repeat-Frames werden dann als
tatsächlicher langer Tastendruck erkannt werden. Meinst Du das so?
Wenn Du meinst, dass das so besser wäre, mache ich das. Allerding
wundere ich mich, dass ich diesen 2. Frame nur bei manchen Tastendrücken
gesehen habe....
> Alle Maustasten werden immer> als 0000 dekodiert. Ich vermute, dass beides an den nicht dekodierten> Bits begründet sind.
Ja, die Maustasten werden noch nicht ausgewertet. Dafür werden die
bisher nicht dekodierten Bits genutzt. Diese werden noch ignoriert.
Mich hätte aber schon mal interessiert, wie z.B. eine Tastenkombination
STRG-C gesandt wird. Es kann nicht sein, dass zunächst der Keycode für
STRG, dann der für C gesandt wird. Was ist bei der nächsten Taste? Da
muss der Empfänger doch wissen, ob die STRG-Taste überhaupt noch
gedrückt ist. Kannst Du das mal testen, evtl. mit Kombinationen von
STRG, ALT, SHIFT?
Gruß,
Frank
Frank M. schrieb:> Max M. schrieb:>>> was läuft hier beim Kompilieren falsch?>> # use more debug-flags when compiling>> DEBUG = 1>> Das muss weg oder auf 0. Debuggen kann man unter Linux nur, wenn man> IRMP nativ für Linux übersetzt.>> Gruß,>> Frank
Danke für den Hinweis hab es gerade abgeändert.
nun bekomm ich aber immer noch fehler... woran liegt jetzt bitte das?
Frank M. schrieb:>> Zum FDC-Protokoll noch ein paar Punkte: Jede Taste wird als zwei Frames>> erkannt, egal wie kurz ich sie betätige.>> Im Deinen Scans sehe ich die Wiederholung nur ab und zu, nicht> ausnahmslos.
Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die
Interruptroutine aus und es werden weniger Sequenzen
erkannt/protkolliert?
eku schrieb:> Könnte das an IRMP_LOGGION=1 liegen? Die Uart-Ausgabe bremst die> Interruptroutine aus und es werden weniger Sequenzen> erkannt/protkolliert?
Die Uart-Ausgabe wird erst gestartet, wenn über eine längere Zeit kein
Signal mehr am IR-Eingang anliegt. Bis dahin wird gepuffert. In Deinem
allerersten Scan sandte fast jede Taste 2 Frames. Der lief mit 10kHz. In
Deinem Scan mit 20kHz kam es nur vereinzelt zu Frame-Wiederholungen. Das
kann daran liegen, dass bei 20kHz der Logging-Buffer schneller voll ist,
denn hier wird das Doppelte an Speicher für einen Frame benötigt.
Okay, Du hast zwar meine Frage nicht beantwortet, aber ich nehme mal an,
dass Du es auch für besser hältst, den ersten und zweiten Frame zusammen
zu betrachten und erst weitere Frames (ab dem 3.) als Wiederholungen -
analog zum SIRCS-Protokoll.
Gruß,
Frank
P.S.
Meine Pollin-Tastaturen sind gestern eingetroffen. Leider bin ich in den
nächsten Tagen viel unterwegs und werde es wohl auch nicht am Wochenende
schaffen, die Dinger mal selbst zu testen.
Die Zeile ist irgendwie Unsinn.
Hier soll ein main.elf gelinkt werden, welches sich aus main.o, irmp.o
und irmp.h zusammensetzt. So versucht nun der avr-gcc, das irmp.h für
sich allein zu übersetzen. Das ist aber Quatsch, denn irmp.h ist kein
eigenständiger Source, sondern nur eine Include-Datei. Das ist in der
Zeile definitiv zu viel.
Da der make ja schon beim Linken angekommen ist, müsste die Compilierung
von irmp.c und main.c bereits geschehen sein und Du müsstest dort
bereits ein main.o und irmp.o vorliegen haben. Ist dem so?
Gruß,
Frank
Max M. schrieb:> ja das ist so aber warum will er die header datei linken?
Keine Ahnung, ich habe mal eben Dein Makefile unter Linux abgespeichert,
die führenden Blanks in den Kommando-Zeilen durch TABs ersetzt und
anschließend eingegeben:
Wie man hier in der letzten Zeile sieht, werden nur main.o und irmp.o
zusammen gelinkt - kein irmp.h. Das ist so vollkommen korrekt. Hast Du
vielleicht Dein Makefile, was Du hier gepostet hattest, nochmal nachher
geändert? Für mich sieht es so aus, als ob Du entweder die SRC-Variable
im Makefile um irmp.h erweitert hast oder gar OBJECTS. Überprüfe das
bitte nochmal oder nimm das Makefile, was Du hier gepostet hattest und
setze lediglich DEBUG auf 0.
Gruß,
Frank
P.S.
Wenn Du das hiesige Makefile nimmst, musst Du wohl die führenden TABs
reparieren. Ich musste das jedenfalls, bevor ich Dein Makefile testen
konnte. Du kannst natürlich die letzte angezeigte Zeile auch einfach per
Copy&Paste in der Shell ausführen ;-)
Hallo Frank!
Mit der SVN-Version von IRMP werden nicht mehr alle Codes des
Siemens-Protokolls erkannt. Samplerate ist 15kHz, kein anderes Protkoll
aktiv.
DOS-Zeileenden in test-suite.sh sind Mist
./test-suite.sh
-bash: ./test-suite.sh: /bin/sh^M: bad interpreter: Datei oder
Verzeichnis nicht gefunden
Hi eku,
eku schrieb:> DOS-Zeileenden in test-suite.sh sind Mist
Weiß ich schon seit 25 Jahren ;-)
Nee, im Ernst, ich nutze unter Linux noch meinen eigenen CVS-Server.
Wenn ich dann unter Windows das Script wieder auschecke, geraten die
DOS-Zeilenenden da rein. Wenn ich dann anschließend über SVN (unter
Windows) das Script wieder einchecke, isses dann kaputt. Ich werde das
Script im CVS explizit auf binary setzen, dann passiert das nicht mehr.
> [code]> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error
Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die
SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und
dann laufen lassen. Geht ganz normal durch.
Auch Deine obitge Zeile mit Siemens-Gigaset-M740AV-15kHz.txt läuft
anstandslos durch. Wie hast Du denn irmp-15kHz erzeuhgt? Wenn, dann
solltest Du die Linux-Binaries mit
make -f makefile.lnx
erstellen.
> Das ging schon mal besser ;-(
Das geht immer noch so gut ;-)
Gruß,
Frank
Frank M. schrieb:>> [code]>> $ ../irmp-15kHz -v < Siemens-Gigaset-M740AV-15kHz.txt|grep error>>> Kann ich nicht nachvollziehen. Ich habe mir dazu extra nochmal die> SVN-Version geholt, aus test-suite.sh die DOS-Zeilenenden entfernt und> dann laufen lassen. Geht ganz normal durch.
Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und
teste noch einmal!
eku schrieb:> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und> teste noch einmal!
Sag mal, kannst Du mit solchen Infos nicht sofort rauskommen, damit ich
mir nicht einen Wolf suchen muss?
Sobald DENON eingeschaltet ist, funktioniert die SIEMENS-Erkennung.
Bin dran,
Frank
eku schrieb:> Bitte setze in irmpconfg.h alle Protokolle außer Siemens auf 0 und> teste noch einmal!
Ist korrigiert und eingecheckt. Es fehlte ein else im Code. Der Fehler
trat nur auf bei deaktiviertem DENON-Protokoll.
Gruß,
Frank
Frank M. schrieb:> Der Fehler trat nur auf bei deaktiviertem DENON-Protokoll.
Danke. Die Testsuite sollte zusätzlich jedes Protokoll für sich testen,
damit solche Fehler früher auffallen. Dazu braucht es aber Binaries für
jedes Protokoll. Sollte per Makefile nichht zu kompliziert sein.
Fehlt noch ein Lösung für den Ausschluss von RC5 und FDC/RCCAR wie in
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" geschrieben.
Im SVN ist eine neue Testversion, welche den Konflikt zwischen RC5 und
FDC bzw. RCCAR aufhebt.
Kurze Schilderung der Lösung:
Wird RC5 erkannt und passt das Start-Bit zeitlich auch als
FDC-Protokoll, dann laufen 2 Decoder los. Sobald einer von beiden einen
Timing-Fehler erkennt, beendet er sich und der andere gewinnt. Dasselbe
gilt für das RCCAR-Protokoll. Funktioniert mit meinen vorliegenden
Scan-Daten tadellos.
Man sollte sich aber wirklich überlegen, ob man RC5 und FDC bzw. RC5 und
RCCAR in Kombination einschalten sollte. Der Decoder für FDC kostet nur
50 Bytes im Binary, wenn RC5 deaktiviert ist. Ist sowohl RC5 als auch
FDC eingeschaltet, dann erhöht sich der Platzbedarf des "dualen
Decoders" auf 500 Bytes. Dasselbe gilt für das RCCAR-Protokoll.
Naja, wer RC5 unbedingt braucht... ich brauchs nicht ;-)
Viel Spaß,
Frank
Frank M. schrieb:> Naja, wer RC5 unbedingt braucht...
Das hängt doch in erster Linie von den rumliegenden Fernbedienungen ab.
Und so alt ist mein DVD-Spieler nun auch nicht. Problematisch ist in
meinen Augen, dass es so viele unterschiedliche Protokolle existieren.
Hallo Frank!
Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array
ir_protos legt und darüber das Protkoll detektiert, spart das noch
einmal Flash für die vielen Vergleiche:
1
uint8_ti;
2
for(i=0;i<NELEMS(ir_protos);i++)
3
{
4
if(pulse_time>=ir_protos[i].start_len_min&&
5
pulse_time<=ir_protos[i].start_len_max&&
6
pause_time>=ir_protos[i].pause_len_min&&
7
pause_time<=ir_protos[i].pause_len_max)
8
{
9
DPRINTF("protocol %d\n",i);
10
ir_data.protocol=i;
11
ir_protop=&ir_protos[i];
12
break;
13
}
14
}
15
if(i==NELEMS(ir_protos))
16
{
17
DPRINTF("protocol UNKNOWN\n");
18
/* wait for another start bit */
19
start_bit_detected=0;
20
}
Bitte Variablennamen **kreativ** an irmp anpassen.
Ich habe gestern abend mal meine FDC-Pollin-Tastatur mit IRMP getestet.
Dabei konnte ich noch ein paar Geheimnisse lüften. Die vermeintlichen
REPEAT-Bits im Frame kennzeichnen keine Wiederholung, sondern das
Drücken bzw. Loslassen einer Taste. Damit können dann auch
Tasten-Kombinationen wie
SHIFT + A
ALT + M
STRG + C
usw.
erkannt werden.
Ich habe IRMP dahingehend angepasst, dass in den untersten 7 Bit der
Keycode der Taste gespeichert ist und im oberen 8. Bit vermerkt wird, ob
die Taste gedrückt oder losgelassen wird. Die entsprechende Änderungen
im IRMP habe ich als Version 1.6.9 ins SVN eingecheckt.
Ebenso habe ich prototypisch eine kleine C-Funktion geschrieben, welche
aus einem Keycode oder einer Keycode-Folge (bei obigen
Tastenkombinationen) den zugehörigen ASCII-Code ermittelt, siehe Anhang.
Diese kann entweder direkt auf dem µC zur Ermittlung der Taste oder auf
dem Host, wo die irmp-Datenstruktur hin übertragen wird, eingesetzt
werden.
Gruß,
Frank
Hi eku,
eku schrieb:> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array> ir_protos legt und darüber das Protkoll detektiert, spart das noch> einmal Flash für die vielen Vergleiche:
Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das
kann durchaus was bringen. Werde ich testen.
Gruß,
Frank
Neue Version 1.7.0 von IRMP verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen gegenüber 1.6.0:
- Neues Protokoll: RCCAR
- Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
- Konflikte FDC <--> RC5 beseitigt
- Interrupt-Frequenz nun bis zu 20kHz (und mehr) möglich
Ebenso ist nun die Version 1.7.0 von IRSND verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen gegenüber 1.6.0:
- Neues Protokoll: RCCAR
Die Dokumentation im IRMP-Artikel habe ich auch angepasst bzw.
erweitert, siehe:
http://www.mikrocontroller.net/articles/IRMP
Für die Pollin-FDC-Tastatur habe ich im Artikel ein eigenes Kapitel
vorgesehen, wo sämtliche Tasten/Keycodes und die Anwendung mit IRMP
dokumentiert sind:
http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen
@Hugo Portisch:
Kannst loslegen mit der USB-Portierung ;-)
@eku & @ Torsten Kalbe:
Ich habe bei der FDC-Tastatur und einem TSOP1736 als Empfänger nur eine
Reichweite von max. 15cm, das ist viel zu wenig. Klar, die
Modulationsfrequenz der FDC-Tastatur ist 38kHz, daher sollte die
Reichweite bei meinem Aufbau schon eingeschränkt sein. Aber ich dachte
schon, dass ein paar Meter drin sein müssten. Naja, ich werden den
TSOP1736 mal durch einen TSOP1738 ersetzen und dann nochmal testen.
Welche Reichweite schafft Ihr mit der Tastatur?
Viel Spaß,
Frank
Hallo Frank!
Frank M. schrieb:> Tastenerkennung für FDC-Protokoll (IR-keyboard) erweitert
Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich
mich erinnere sind da mehr als nur 4 Richtungen möglich.
#warning F_INTERRUPTS too low, RECS80EXT protocol disabled (should be at least 20000)
11
#endif
Wo sind denn die undefs für das 'disabled' geblieben?
Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand
der aktivierten Protokolle automatisch gesetzt werden. Warum den
Benutzer damit belasten. Dann entfallen auch die Warnungen und
Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?
Frank M. schrieb:> eku schrieb:>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array>> ir_protos legt und darüber das Protkoll detektiert, spart das noch>> einmal Flash für die vielen Vergleiche:> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das> kann durchaus was bringen. Werde ich testen.
Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?
Hi eku,
eku schrieb:> Was liefert eigentlich das Steuerkreuz rechts der Tastatur? Soweit ich> mich erinnere sind da mehr als nur 4 Richtungen möglich.
Das Ding ist nach meinen Versuchen her ziemlich unbrauchbar, da kommen
relativ wirkürlich 4 verschiedene Bits für oben, unten, rechts, oben und
bei Zwischenstellungen dann die Summen davon. Leider ist das aber so
ungenau, dass da beim Drücken des Steuerkreuzes nach rechts so ziemlich
alles kommt zwischen unten, unten-rechts, rechts, oben-rechts und oben.
Daher habe ich aufgegeben, das Steuerkreuz zu decodieren. Es wird
schlichtweg ignoriert.
> Wo sind denn die undefs für das 'disabled' geblieben?
Vergessen ;-)
Werde ich dieses Wochenende korrigieren.
> Prinzipiell sollte F_INTERRUPTS auf den höchsten benötigten Wert anhand> der aktivierten Protokolle automatisch gesetzt werden. Warum den> Benutzer damit belasten. Dann entfallen auch die Warnungen und> Automatismen zur Deaktivierung von Protkollen. Gegenteilige Meinungen?
Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer
neuen Idee. ;-)
Ob eine 20kHz-Interrupt-Rate bei einer CPU-Frequenz von 8MHz noch
sinnvoll ist, kann ich nicht beurteilen. Wenn man alle Protokolle
einschaltet, könnte es dabei eng werden. Um das herauszubekommen, müsste
man mal die Belastung der CPU in der ISR messen.
Ich halte wenig von Deiner Idee, die Interrupt-Frequenz selbst zu
bestimmen, denn ich möchte den Anwender von IRMP nicht übermäßig
bevormunden. Vielleicht hat er durchaus Gründe, die ISR mit 15kHz
anzusprechen statt mit 10kHz, auch wenn 10kHz reichen würde. Auch kommt
es darauf an, welchen Timer er nimmt. Die Wahl des Timers und die Wahl
der Vorteiler/Timing-Register bestimmt die Frequenz und nicht umgekehrt.
Gruß,
Frank
eku schrieb:> Frank M. schrieb:>> eku schrieb:>>> Wenn man die "static PROGMEM IRMP_PARAMETER" Blöcke in ein Array>>> ir_protos legt und darüber das Protkoll detektiert, spart das noch>>> einmal Flash für die vielen Vergleiche:>> Gute Idee, geht zwar nicht ganz so glatt, wie Du es darstellst, aber das>> kann durchaus was bringen. Werde ich testen.>> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?
Nein, da habe ich mich noch nicht durchringen können, das umzusetzen.
Ich schwanke nämlich mittlerweile, ob ich diese "Optimierung" überhaupt
machen soll, nämlich aus folgenden Gründen:
1. Jetzt werden die Startbit-Timings gegen Konstanten geprüft. Das ist
mit nur wenigen CPU-Takten möglich. Beim Testen der Timings gegen
Variablen in einer for-Schleife dauert der Check eines Protokolls
gegen die Startbit-Timings wesentlich länger, weil dann erstmal
die Variablen in Register geladen werden müssen, um sie gegen die
ermittelten Timing-Werte zu testen. Bei knapp 20 Protokollen kommt
da einiges an Laufzeit zusammen, was da zusätzlich verbraten wird.
Da dies alles innerhalb eines einzigen ISR-Laufes passieren muss,
kann das arg knapp werden. Man spart zwar Speicherplatz, aber auf
Kosten von Laufzeit.
2. Wenn Du Dir die Startbit-Timing-Checks anschaust, wirst Du sehen,
dass nur die wenigsten aller Tests identisch sind. Bei den
Manchester-Protokollen (RC5, RC6, Grundig, usw.) sind 4 Tests
notwendig, bei den anderen nur 2 Tests - aber nur, wenn sie
ausgezeichnete Startbits haben. Beim Denon-Protokoll, welches
keine Startbits aufweist, muss ich hingegen wieder 4 Tests machen,
weil das erste Bit schon eine 0 oder eine 1 sein kann. Ausserdem
kommen dann evtl. weitere Tests hinzu, beim RC5-Protokoll können
(wegen des erweiterten RC5-X-Protokolls) auch die ersten beiden
Puls-Pausen-Werte schon verschieden sein. Desweiteren kommt dann
noch das "Starten" eines zweiten Parallel-Decoders hinzu, um
den Konflikt zwischen RC5<->FDC und RC5<->RCCAR zu lösen.
Wenn man diese ganzen Sonderbedingungen in die for-Schleife
zusätzlich einbaut, wird das ähnlich viel Code verschlingen
wie jetzt auch.
Man könnte einen Kompromiss eingehen:
Diejenigen Pulse-Distance-Protokolle, für die keine Sonderbedingungen
anfallen, kann man in einer for-Schleife zusammenfassen - also SIRCs,
NEC, SAMSUNG, MatSUSHITA, KASEIKYO und noch ein paar andere. Aber ob
sich das dann noch lohnt? Weiß ich nicht.
Mir schwebt eine andere Optimierung vor: Im Moment ist die Ermittlung
des Protokolls aus den Startbit-Timings eine lineare Suche. Ab einer
bestimmten Anzahl wird dies ineffektiv, weil dann N Tests gemacht werden
müssen. Wenn man die lineare Suche gegen eine baumartige Suche ersetzen
würde, geht das effektiver und spart Zeit. Die ISR kommt nämlich
irgendwann ab einem bestimmten N (Anzahl der Protokolle) an seine
Grenzen, und zwar genau nach dem Empfang des Startbits: hier geht die
Sucherei los... und das kann lang dauern. Wenn man das durch eine
Intervallschachtelung ersetzt, braucht man nur noch log2(N) viele Tests.
Ungefährer Algorithmus:
Man teilt die Protokolle in 2 Gruppen: Diejenigen mit kurzen und
diejenigen mit langen Startbits. Dann kann man schon mal 50% der
Protokolle auf einen Schlag ausschließen. Dann werden die diese 2
Gruppen wieder in Untergruppen zerschlagen, so dass man mit einem
weiteren Test von den 50% wieder 50% ausschließen kann. Dann bleiben nur
noch 25% übrig usw.
Die Kunst besteht nun darin, diesen Abfragebaum zur Compilezeit
zusammenzustellen - oder zumindest in der init-Funktion. Da denke ich
noch drüber nach, wie ich das bewerkstellige.
Gruß,
Frank
Hi Frank!
Frank M. schrieb:> Du kommst jedesmal, wenn ich was umbaue nach Deinen Wünschen, mit einer> neuen Idee. ;-)
In den 25 Jahren Deiner Softwareentwicklung hast Du bestimmt
mitbekommen:
* Softwareentwicklung ist ein iterativer Prozess
* der Kunde hat immer neue Wünsche an die Software
* ein Programm, das fertig ist, ist veraltet
Lass Dich von mir nicht entmutigen!
eku schrieb:> Lass Dich von mir nicht entmutigen!
Nönö, alles noch im grünen Bereich ;-)
Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat,
wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer
Reichweite von nur 15cm bin ich nicht zufrieden. Ich weiß, dass ein
TSOP1738 bei der Tastatur besser geeignet wäre, jedoch kann ich mir
diese geringe Reichweite damit nicht allein erklären.
Gruß,
Frank
eku schrieb:> Gibt es schon Erkenntnisse bezüglich Speicherverbrauch?
Ich habe das gerade mal getestet:
Alle Startbit-Timings in eine struct gepackt und dann zwei for-Schleifen
(eine mit ausgezeichneten Startbits: 2 Tests, eine für diejenigen
Protokolle, die direkt mit den Daten beginnen: 4 Tests) gebaut.
Ergebnis: Wenn alle Protokolle aktiviert sind, liegt die Ersparnis bei
150 Bytes. Leider steigt die Größe des Datensegments dabei um 140 Byte.
Wenn weniger Protokolle aktiviert sind, dann ist der Gewinn noch
geringer.
Das kann man also vergessen: es bringt nichts. Im Gegenteil: die
Laufzeit vergrößert sich drastisch wegen des Ladens aller Startbit-Werte
aus der struct in die Register, um den Vergleich durchführen zu können.
Das Einzige, was mir an der Änderung gefällt, ist, dass der Source
"schöner" aussieht ;-)
Ich werde daher diese Änderung erstmal auf Eis legen und später
vielleicht wieder aufgreifen, nämlich dann, wenn ich die lineare Suche
durch eine Intervallschachtelung ersetzen werde.
Gruß,
Frank
Frank M. schrieb:> Ich hatte Dich noch gefragt, welche Reichweite Deine FDC-Tastatur hat,> wahrscheinlich hast Du es überlesen... mit meinem TSOP1736 und einer> Reichweite von nur 15cm bin ich nicht zufrieden.
Nicht überlesen, nur gerade den AVR nicht dabei :-)
Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen
Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.
Hy,
ich kann die Reichweite auch nicht so einfach testen, was größer als ein
paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit
einem 9Volt Block betreiben und die Straße unsicher machen.
Gruß
Torsten
Gehört zwar vielleicht nicht direkt hierher, hat aber mit IRMP zu tun:
wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art
Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein
Zeichen über die UART sendet?
Ich will nicht den kompletten IR-Frame senden, sondern wirklich nur ein
einzelnes 8-bit-Zeichen. Nach Möglichkeit sollte das Ganze lernbar sein,
d.h. nicht festgelegt auf bestimmte IR-Protokolle/-Kommandos. Auch
verschiedene Protokolle sollten möglich sein.
BTW: IRMP ist ein richtig feines Stück Software... Vielen Dank dafür!
eku schrieb:> Also mein TSOP1736 auf dem Pollin AVR Add-On reagiert noch am anderen> Ende des Zimmers, d.h. mehr als drei Meter sind kein Problem.Torsten Kalbe schrieb:> ich kann die Reichweite auch nicht so einfach testen, was größer als ein> paar Meter sein sollte. Dann müßte ich meinen Testempfänger mal mit> einem 9Volt Block betreiben und die Straße unsicher machen.
Danke fürs Feedback, da muss meine Tastatur (eine von 5, die ich
bestellt hatte) nicht in Ordnung sein, normale Fernbedienungen werden
nämlich auch bei mir auf 3-5 Meter erkannt. Muss ich heute abend mal die
zweite Tastatur auspacken....
Gruß,
Frank
Micha schrieb:> wie lässt sich effektiv (speicher- und laufzeittechnisch) eine Art> Lookup-Tabelle erstellen, die anhängig von empfangenen IR-Daten ein> Zeichen über die UART sendet?
Das ginge mit einer Hash-Funktion. Da hatte mal jemand so etwas im
Februar diesen Jahres hier in der Codesammlung vorgestellt:
Beitrag "Universeller IR-Receiver für viele Protokolle"
Hier wird aus dem IR-Frame ein 32-Bit-Hash-Wert berechnet - ohne
Kenntnis des Protokolls. Hat aber ein paar Stolpersteine... z.B. die
Behandlung von Repetition-Frames, Eindeutigkeit usw.
Da Du sogar alles in ein einziges Byte packen möchtest, sind doppelte
Rückgabewerte vorprogrammiert. Auch bei einem 32-Bit-Hash-Wert kann man
nicht ausschließen, dass zwei verschiedene Fernbedienungen auf
irgendwelchen Tasten denselben Hash-Wert ergeben. Aber es ist halt
relativ unwahrscheinlich - jedenfalls dann, wenn die Hash-Funktion "gut"
ist. Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert
zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle -
kannste vergessen.
Gruß,
Frank
Frank M. schrieb:> Aber eine Hash-Funktion, die nur einen eindeutigen 8-Bit-Wert> zurückgeben soll - und das ohne Kenntnisse irgendwelcher Protokolle -> kannste vergessen.
Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie
schätzt du die Chancen dann ein?
Micha schrieb:> Frank M. schrieb:> Und wenn ich nur ein Protokoll "gleichzeitig" zulassen würde? Wie> schätzt du die Chancen dann ein?
Das kommt darauf an, wieviele Tasten Du unterscheiden möchtest. Sind es
lediglich die Tasten 0-9, kommst Du mit 4 Bit aus. Wenn wir uns noch das
NEC-Protokoll anschauen, dann ist die Chance, dass Du in Deinem Haushalt
2 NEC-kompatible Fernbedienungen hast, schon relativ groß. Dass es
Überschneidungen bei den Tasten '0' bis '9' gibt, ist auch relativ
wahrscheinlich.
Du müsstest Dich also nicht nur auf ein Protokoll einschränken, sondern
auch noch auf eine Adresse konzentrieren, um ein Kommando einer FB
eindeutig zu erkennen. Wenn Du bis zu 32 Tasten unterscheiden möchtest,
sind 5 Bit weg und Du hast noch 3 Bit, um verschiedene FBs anhand ihrer
Adresse zu unterscheiden. Das wird arg knapp.
IRMP nutzt nicht umsonst 16 Bit für die Adresse und 16 Bit für das
Kommando. Meist kommt man mit 8 Bit für die Adresse und 8 Bit für das
Kommando aus - aber nicht immer.
Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der
den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:
1. Byte: irmp_data.protocol
2. und 3. Byte: irmp_data.address
4. und 5. Byte: irmp_data.command
6. Byte: irmp_data.flags
Du könntest natürlich auch mittels IRMP alles in ein Byte packen:
a) Nur ein Protokoll aktivieren, alle anderen deaktivieren
b) irmp_data.address auf einen festen Wert prüfen, also nur
eine Adresse zulassen
c) Für die Tasten, die Du übertragen willst, einen case-switch
bauen, der bestimmte Werte von irmp_data.command in die Werte
1, 2, 3, 4, usw. übersetzt.
Man könnte noch einen Schritt weiter gehen: Bei 32 verschiedenen Tasten
hast Du dann noch 3 Bits übrig. Damit könntest Du in den 8 Bits
folgendes codieren:
RAACCCCC
wobei:
R = Repetition Flag
AA = 00 Adresse FB Nr. 1
01 Adresse FB Nr. 2
10 Adresse FB Nr. 3
11 Adresse FB Nr. 4
CCCCC = 32 verschiedene Tasten
Somit könntest Du dann zumindest für 4 verschiedene FBs 32 verschiedene
Tasten-Codes übertragen.
Das obige gilt aber nur für IRMP - unter der Voraussetzung, dass man
nicht nur das Protokoll, sondern auch schon die Tastencodes kennt. Eine
Hash-Funktion zu finden, die ohne Kenntnis des Protokolls alles in 8 Bit
ohne Dubletten stopft, halte ich für illusorisch. Und dann auch noch
"anlernbar"? Da müsste sich die Hash-Funktion selbst modifizieren,
sobald ein neuer Code angelernt werden soll, um Dubletten zu vermeiden.
Okay, letzter Versuch:
Du nimmst die 32-Bit-Hashfunktion aus
Beitrag "Universeller IR-Receiver für viele Protokolle"
und trägst den ermittelten 32-Bit-Hash-Wert in eine 256 x 4 Byte große
Tabelle ein. Dann kannst Du den 8-Bit-breiten Index auf diese Tabelle
nutzen, um eine Taste zu identifizieren. Kostet Dich leider 1KB RAM ;-)
Gruß,
Frank
Frank M. schrieb:> Warum willst Du Dich unbedingt auf 8 Bit beschränken? Hugo Portisch, der> den IRMP im USB-IR-Receiver nutzt, überträgt einfach 6 Bytes, nämlich:
Ich habe ähnliches vor wie Hugo, allerdings wollte ich den AVR (einen
ATtiny84) "direkt als Tastatur" nutzen, also ohne dlls und dergleichen.
Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste
zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer
FB"...
Micha schrieb:> Anlernbar sollte heißen, dass man die IR-Kommandos beliebig einer Taste> zuweisen kann, à la "Drücken Sie jetzt die Taste für 'a' auf Ihrer> FB"...
Wo ist das Problem? Du nimmst IRMP und eine NEC-kompatible
Fernbedienung. Da sind die Codes zwischen 0x00 und 0xFF.
Zu jeder Taste (z.B. 'a') merkst Du Dir imrp_data.command.
Gruß,
Frank
Frank M. schrieb:> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.
Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was
eigenes zu basteln.
Ich werd mal verschiedenes testen. Vielen Dank für die Tipps!
Frank M. schrieb:> Du nimmst IRMP und eine NEC-kompatible Fernbedienung. Da sind die Codes> zwischen 0x00 und 0xFF.
Das wäre natürlich eine Möglichkeit. Nachdem ich eine
Universal-Fernbedienung habe ist das Protokoll eh relative egal - ich
muss mir halt ein entsprechendes Gerät aus der Datenbank suchen.
Wenn ich so darüber nachdenke müsste es sogar möglich sein mir was
eigenes zu basteln.
Ich werd mal Verschiedenes testen. Vielen Dank für die Tipps!
Hallo zusammen,
es gibt einen Bugfix für IRMP - Version 1.7.2, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen gegenüber 1.7.1:
- Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um
"Geisterkommandos" zu verhindern.
Was ist ein "Geisterkommando"?
Folgende Situation:
1. IRMP empfängt NEC-Kommonda A und weitere Repetition-Frames
2. Danach wird die Taste B lange gedrückt und IRMP empfängt das
Kommando nicht vollständig - z.B. wegen zu geringer Reichweite oder
weil die Katze durch den Strahl läuft.
3. Die FB sendet nun Repetition-Frames für Kommando B und IRMP
interpretiert diese Wiederholungen als Wiederholungen für Kommando A!
Frank Lorenzen hat mich auf den Fehler aufmerksam gemacht, denn er
konnte dieses Phänomen tatsächlich im "real life" erleben... naja...
nicht die Katze war schuld ;-) Vielen Dank dafür!
Viel Spaß,
Frank
Frank M. schrieb:> Version 1.7.2
In irsndconfig.h ist noch die alte Behandlung für
IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h
anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.
eku schrieb:> In irsndconfig.h ist noch die alte Behandlung für> IRSND_SUPPORT_SIEMENS_PROTOCOL. Würdest Du das bitte an irmpconfig.h> anpassen, d.h. Ausgabe einer Warnung mit Deaktivierung des Protokolls.
Ich hatte nur IRMP angepasst. IRSND hat noch die alte Version ;-)
Aber klar, ich korrigiere das.
Gruß,
Frank
Frank M. schrieb:
[...]
> Änderungen gegenüber 1.7.1:>> - Bugfix: Einführen eines Timeouts für NEC-Repetition-Frames, um> "Geisterkommandos" zu verhindern.
[...]
Funktioniert einwandfrei :-)
> Viel Spaß,>> Frank
Vielen Dank für den schnellen Bugfix.
Viele Grüße,
Frank
puh alles durchgelesen,
nur habe ich das mit dem Widerholungsflag noch nicht gesehen
kein loslassen, Lautstärke Helligkeit geht ja mit repeat, aber bei
Programmwahl wäre das ja unglücklich, ergo muss das Bit loslasen
interpretieren
ist da schon was eingebaut ?
IRMP ist erstmal geil, bin schon am nachbauen,
Probleme bereitet mit bis jetzt nur der heftige Aufwand (für mich)
entweder, Neubau, + Codeumschreibung, denn im Prinzip liegen hier 2(3)
Geräte mit mega644(32), TSOP1736, LCD, LED, Triber für LCD HG-LED und
Taster
alle Codes zeigen auf einen mega 88 der einzige Plan (den ich bis jetzt
gefunden hatte) aber auf einen mega 168
klar könnte ich aus dem Code für mega 88 die Ports ohne Plan extrahieren
da meine HW quasi schon fast steht mal eben die beiden Codes und Quellen
verheiratet, was aber logisch schief ging, ich nutze halt timer1 für die
LCD HG LED per pwm OCRA und OCRB für den Kontrast
Ziel ist es aber nach Dekodierung meiner pansonic FB einen FB Sender zu
generieren der per PC aktiviert wird, über VNC meinen HD Recorder
fernzuprogramieren, aber da ich nicht noch mehr IR Sendedioden frei
plazieren möchte, was ist mit IR zu RF 433 MHz Umsetzung, 433 Empfänger
und IR Sender sind vorhanden, da die ja auf alle FB reagiren vermute ich
die Trägerfrequenz 30 - 40 kHz ist denen egal, morsen die in 433 Mhz nur
das an und aus der IR LED ?, wie könnte man ein RF(m?) 12 Modul den
Transmitter dafür nutzen ?
hier gibt es ja Beispiele für Atmel atmel mit Sender und Empfänger, also
per seriell Umsetzung, aber ich weiss nicht ob es digital oder analog
ist was da gesendet wird, habe so eine Funk FB mal belaucht mit dem Oszi
und Empfängermodul, aber nur Grundrauschen bekommen oder Störsignale,
weiss aber nicht ob die 433 Module dafür gehen.
wenn sich dazu jemand äussern kann würde mich freuen,
den PC als fernbedienten IR/433 MHz Sender zu nutzen aus dem ganzen
I-Net muss doch mehr interessieren ?
Rückmeldung der Programmierung geht natürlich toll per winTV und den HD
Rec am AV Modulator ins Subkabelnetz gespeist, muss also auf dem PC nur
winTV starten, den HDrec Kanal einstellen und schon kann ich alles
programmieren, mit 433 MHz brauch ich nicht mal ne Sichtverbindung PC
HDrec (das macht die IR Pyramide)
so
1 Nachbau läuft mit 644 intern 8MHz
meine panasonic DVD wird als KASEIKYO erkannt
nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code
bringen obwohl 2 getrennte Tasten ist mir noch unklar
loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie
ich das dem PC erkläre
erst mal das Prototypeboard auf Akku umstellen und heim alle FB testen
alle in Urlaub ? oder sind meine Fragen zu doof ?
egal, noch ein Versuch
so nun verschiedenste FB durchprobiert
Samsung wird als solche erkannt
drei Panasonic als Kaseikyo
nur alle OFF Knöpfe bringen den selben Code (2002/3d0)
aber natürlich reagieren die Geräte nicht so
VHS off Kaseikyo 2002/3d0 nur der VHS geht aus
HDrec off Kaseikyo 2002/3d0 nur der HDrec geht aus
TV off Kaseikyo 2002/3d0 weder der HDrec noch der VHS geht aus
alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine"
andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl
wo soll ich nun suchen ?
Jitter ? auf 8 MHz Quarz umstricken ?
internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere
Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi
wird ?
1s soll ja nach 10000 ISR aufrufen vergangen sein
ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen
in ISR wird uint16 VAR++
in main auf uint16 VAR >= 10000 abgefragt und 0 gesetzt und LED Bit xor
gesetzt
muss ja 1s Puls / Pause rauskommen
jar schrieb:>> 1s soll ja nach 10000 ISR aufrufen vergangen sein>> ergo lasse ich eine uint16 VAR immer wieder von 0-10000 laufen>> muss ja 1s Puls / Pause rauskommen
Kommando zurück, man sollte RC5 auch enabeln
hatte ich schon mal dann aber neu angefangen und vergessen
wer also noch Codes braucht kann sich ja melden, ich versuche dann den
Max nachzurüsten und aufzuzeichnen
und suche immer noch ne Lösung für 433 MHz send statt IR (das IR
überlasse ich den IR Pyramiden)
hat schon jemand IRSND am PC zu USB mit Atmel ?
wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu
rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul
puh, schwerer als gedacht
also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5
geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die
Frequenz erst mal nicht vermessen hab,
Interrupt auf 15k hochgesetzt hat nix gebracht, den Rest nicht
verschlechtert aber der JVC nicht geholfen.
Der Oszi liefert schönen Stream sieht aber dem RC5 der erkannt wird
nicht ähnlich
Anlage in der Zip:
ein PIC vom Oszi
hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5
und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS
umgesetzt
ich hoffe das Projekt lebt noch und sind alle nur in Urlaub
ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf
Antworten auf meine Fragen
liebe gruesse
jar
jar schrieb:> meine panasonic DVD wird als KASEIKYO erkannt
Prima.
> nur warum die Tasten OFF (2002/3d0) und TV OFF (2002/3d0) denselben Code> bringen obwohl 2 getrennte Tasten ist mir noch unklar
Beim Kaseikyo-Protokoll (48 Bit!) werfe ich sämtliche CRCs raus.
Vielleicht etwas zuviel...
Aktiviere bitte IRMP_LOGGING und schicke mir die Scan-Dateien. Dann
werde ich den Unterschied schon finden.
> loggen kann ich (noch) nicht, kein Maxim spendiert und keine Ahnung wie> ich das dem PC erkläre
Du startest einfach ein Terminal-Emulationsprogramm (z.B. HyperTerm) und
speicherst die Ausgabe.
jar schrieb:> alle in Urlaub ? oder sind meine Fragen zu doof ?
Ja, bis gestern :-)
> Samsung wird als solche erkannt
Gut.
> drei Panasonic als Kaseikyo
Auch gut.
> nur alle OFF Knöpfe bringen den selben Code (2002/3d0)
Wie gesagt: ich brauche die Scans dazu.
> alle RC5 FB zeigen im IRMP nix an (interner 8MHz), dabei geht "meine"> andere Schaltung mit 8 MHz Quarz und Fleury RC5 Lib wohl
Scan schicken. Vielleicht haben wir hier nur eine zu starke Abweichung
vom RC5-Timing.
> Jitter ? auf 8 MHz Quarz umstricken ?
Quarz ist auf jeden Fall gut. Bitte auch hier die Scan-Datei schicken,
dann kann ich Dir mehr sagen.
> internen auf 8 MHz kalibrieren (keine Ahnung wie das geht) meine andere> Idee, einfach an den Teilern drehen bis 1s Blink LED 1s auf dem Oszi> wird ?
IRMP ist vom Timing her ziemlich tolerant. Bist Du sicher, dass Dein
Timer mit der richtigen Frequenz läuft? Zeigst Du bitte mal die Passagen
Deiner Timer-Initialisierung?
Joachim B. schrieb:> Kommando zurück, man sollte RC5 auch enabeln
RC5 geht also jetzt?
> wer also noch Codes braucht kann sich ja melden, ich versuche dann den> Max nachzurüsten und aufzuzeichnen
Ja, wäre nicht schlecht.
> und suche immer noch ne Lösung für 433 MHz send statt IR (das IR> überlasse ich den IR Pyramiden)
Du meinst die 433 MHz-Sender/Empfänger von Pollin, die RFM12?
Sag mal genau, was Du willst. Sowas vielleicht:
IR Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????
> hat schon jemand IRSND am PC zu USB mit Atmel ?
Meines Wissens nicht. Nur IRMP zu USB, siehe
Beitrag "USB IR Remote Receiver (V-USB + IRMP)"> wenn hier keiner ne bessere Idee hat nehme ich einen Atmal als USB zu> rs232 Umsetzer und frickel da IRSND ein, ggffs mit 433 MHz Modul
Male bitte mal ein Schaubild, ich verstehe nicht ganz, was Du vorhast.
Joachim B. schrieb:> also die JVC RM C085 wird nicht erkannt, obwohl JVC unter Nec als RC5> geführt wird, aus dem TSOP1736 kommt schönes Signal raus so das ich die> Frequenz erst mal nicht vermessen hab,
Bitte Scan schicken.
> Anlage in der Zip:> ein PIC vom Oszi
Nützt mir nichts.
> hardcopy -> Ref1 ist unbekannte JVC und Ref2 ist bekannte Pinnacle RC5
Nützt mir nichts.
> und die Daten als 2x CSV (JVC-FB und Pinnacle FB RC5) und einmal zu XLS> umgesetzt
Nützt mir nichts.
> ich hoffe das Projekt lebt noch und sind alle nur in Urlaub
Jau :-)
> ich mache mich nun an die 433 MHz Umsetzung und hoffe weiter auf> Antworten auf meine Fragen
Siehe oben.
Gruß,
Frank
hmmm, schade das die die CSV Dateien nix nutzen
jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so
weiter, ist das für dich nicht lesbar ?
ist Exelformat und die XLS ist schon zu µs umgesetzt
oszi zu CSV oder XLS ist halt schneller als HW bauen
ich verstehe auch nicht manche Kommentare im Quellcode
mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes
http://www.sbprojects.com/knowledge/ir/jvc.htm
JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich
auf dem Oszi, aber im Quellcode nicht ???
ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms
und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?
also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten
433 MHz
Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben
sondern statt IR Diode auf einen 433 MHz Sender ähnlich den
Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke
433 MHz - IR Sender)
da zwei 433 MHz Empfänger mit IR Sendedioden schon im Zimmer stehen wäre
es doch schön wenn der PC den IR Code statt in IR zu senden 433 MHz
senden würde, dann spart man sich die PC IR Sendediode Ausrichtung zu
den Geräten. ausgerichtet sind die Pyramiden ja schon
Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers
I-Net (VNC)
war der Urlaub schön ?
liebe gruesse
achim
Joachim B. schrieb:> hmmm, schade das die die CSV Dateien nix nutzen> jede Zeile ist 10µs also ist bei Zeile 70 der Wechsel bei 700 µs und so> weiter, ist das für dich nicht lesbar ?
Es muss nicht für mich, sondern für IRMP lesbar sein, ich analysiere die
Scans mit IRMP unter Linux, siehe auch Artikel:
http://www.mikrocontroller.net/articles/IRMP#IRMP_unter_Linux_und_Windows
Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln,
das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn
der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du
eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en
und 1en in einer langen Zeile z.B. so:
000000011111111111111000111000111.....
Davor schreibst Du noch einen Kommentar:
# OFF-Taste TV
000000011111111111111000111000111.....
# OFF-Taste VCR
000000011111111111111000111000111.....
> ist Exelformat und die XLS ist schon zu µs umgesetzt
Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.
> oszi zu CSV oder XLS ist halt schneller als HW bauen
Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.
> ich verstehe auch nicht manche Kommentare im Quellcode
Welche?
> mal wird JVC als RC5 bezeichnet mal als NEC aber hier steht was anderes> http://www.sbprojects.com/knowledge/ir/jvc.htm
JVC ist nicht notwendigerweise RC5 oder NEC. JVC ist einfach ein
Hersteller, der verschiedene IR-Protokolle verwendet. Meist jedoch NEC.
> JVC unterscheidet in 1 und Null bits zu 1 ms und 2 ms und das sehe ich> auf dem Oszi, aber im Quellcode nicht ???
Schau Dir im IRMP-Artikel folgende Tabelle an:
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail_2
Da sind alle Timings der von IRMP unterstützten Protokolle aufgeführt.
Im Quellcode findest Du diese Timings wieder in irmp.h. Sie sind in der
Header-Datei, da sie auch von IRSND verwendet werden.
> ich dachte auch mein JVC hat zu große Abweichung im Timing, aber ! 1ms> und 2ms sind nahezu exakt nur warum werden die nicht erkannt ?
Wie gesagt: Scan-Datei hilft weiter.
> also wenn es nicht anders geht muss ich den MAX wohl noch nachrüsten
Jepp :-)
> Ziel ist es später im PC den Code nicht auf eine IR Diode auszugeben> sondern statt IR Diode auf einen 433 MHz Sender ähnlich den> Funkfernedienungen oder der FB Transmitter (IR Empfänger - Funkstrecke> 433 MHz - IR Sender)
Also:
IR Funk IR
IR-FB -----> RFM-Sender mit IRMP -----> RFM-Empf. mit IRSND ------>
fernzubedienendes Gerät
Geht mit IRSND, siehe IRMP-Artikel.
Das einzige, was fehlt, ist der Code für die RFM-Module. Aber da gibt es
ja hier im Forum genügend Quellcode, wo man sich bedienen kann.
Gruß,
Frank
Sag mal genau, was Du willst. Sowas vielleicht:
IR Funk
IR-FB ---------> RFM12 ---------> RFM12 ------> Und was dann????
so ähnlich,
wenn der Atmel oder PC erst mal alle KASEIKYO Codes kennt soll der PC
diese senden (notfalls über den Umweg eines Atmels)
aber es soll KASEIKYO nicht in IR gesendet werden, sondern in 433 MHz
und ja ich denke an die RM12 Module, diese senden dann ungerichtet vom
PC auf die Empfängerpyramiden die das dann zu IR Strahlung gerichtet
umsetzen bis zum HD Recorder
Kaseikyo Code von PC (ggffs mit Hilfe eines ATMEGA) als 433 MHz an
Funkempfängerpyramide - in IR an HDrec
PC kaseikyo Code ---------> RFM12 ---------> Funkempfängerpyramide
------> IR ------> HD Rec
Joachim B. schrieb:> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers> I-Net (VNC)
Dann würde doch folgendes reichen:
USB-to-RS232 -> MAX232 -> AVR
Den USB-to-RS232-Wandler bekommst Du überall für ein paar Euros
nachgeworfen. Dann kannst Du über die COM-Schnittstelle Befehle an den
AVR senden. Dort läuft IRSND, welcher die Befehle per IR-LED wieder
aussendet.
Anregungen findest Du vielleicht hier:
http://www.klaus-leidinger.de/mp/Mikrocontroller/IR-LCD/IR-LCD.html> war der Urlaub schön ?
Danke, oft über 40°C und viel Sonne :-)
Gruß,
Frank
P.S.
Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch
nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von
Scans bekomme ;-)
Frank M. schrieb:> Joachim B. schrieb:>> Ziel des ganzen, per PC den HD Recorder zu programmieren, auch übers>> I-Net (VNC)>> Dann würde doch folgendes reichen:>> USB-to-RS232 -> MAX232 -> AVR>> war der Urlaub schön ?> Danke, oft über 40°C und viel Sonne :-)> Gruß,> Frank>> P.S.> Ausgerechnet Kaseikyo unterstützt IRSND (das Gegenstück zu IRMP) noch> nicht. Könnte sich aber ändern, wenn ich genügend "Futter" in Form von> Scans bekomme ;-)
also da denke ich eher an:
http://www.embedded-projects.net/index.php?page_id=135
mit
http://www.embedded-projects.net/index.php?page_id=160
da habe ich etwas mitgewirkt (Platinengröße für USB Stickgehäuse), der
kann auch als USB zu RS232 Umsetzer arbeiten (über virtcom Treiber) und
statt den Code als RS232 auzugeben wird das Kommando direkt als KASEIKYO
ausgegeben (mittels IRSND an 433 MHz)
Ich muss dann eben die RS232 Schnitte nachrüsten in meinem IRMP (seufs
geht nicht wirklich leicht auf dem Steckbrett, muss wohl erst ne Platine
schnitzen) damit ich dich mit KASEIKYO Codes füttern kann
dann ist da noch das 433 MHz Problem, senden empfangen mag ja in den
RS232 Atmel Funkstrecken gehen, ist aber digital, meine Versuche eine
China Funk FB (Cam RF Remote Auslöser , Canon Pentax, alle nach dem
selben Prinzip, 4 DIP für Sende/Empfang an Cam mit kleinen Handsender
mit Stabantenne) zu belauchen mit den Modulen war erfolglos, scheint mir
analog zu sein....
Frank M. schrieb:> Du kannst natürlich Deine XLS-Dateien wieder ins IRMP-Format umwandeln,>> das geht so: für jede zehntausendstel Sekunde schreibst Du eine 1, wenn>> der Empfänger aus war, für jede zehntausendstel Sekunde schreibst Du>> eine 0, wenn der Empfänger aktiv war. Das gibt dann eine Folge von 0en>> und 1en in einer langen Zeile z.B. so:>>>> 000000011111111111111000111000111.....>>>> Davor schreibst Du noch einen Kommentar:>>>> # OFF-Taste TV>> 000000011111111111111000111000111.....>> # OFF-Taste VCR>> 000000011111111111111000111000111.....>>>>> ist Exelformat und die XLS ist schon zu µs umgesetzt>>>> Nützt mir nichts. IRMP "versteht" halt nur das IRMP-Format selbst.>>>>> oszi zu CSV oder XLS ist halt schneller als HW bauen>>>> Naja, einen MAX232 dranbauen ist auch nicht soooo schwierig.
zu umwandeln, low aktiv oder high aktiv ?
in Ruhe kommen 5V aus dem TSOP 1736 wenn IR Signale erkannt werden
wechselt es zu low
also 1 = 0 ? und 0 = 1 ?
dem MAX anbauen ist schwierig, weil 1. kein max232 in der Kiste, aber in
der Datenbank, aber max233 in der Kiste aber nur SMD und da muss ich
löten, dito macht sub-d in dem steckbrett keinen sinn und in smd hab ich
den nicht, also muss ich max233 auf SMD und dann auf Lochraster mit
SUB-D verheiraten bevor es ans Steckbrett geht, ist schon nicht trivial
für mich mit meene ollen ogen :|
so, ich baue grad mit dem max233 auf (murphy, natürlich habe ich den nur
als SO und in der LBR gibt es den nur in DIL und die SO Variante hat
andere Pinbelegung, deswegen erst mal Symbol und Dev in Eagle bauen,
mann mann mann, das Leben könnte doch einfacher sein)
kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr.
Leidinger ?)
und warum muss Vcc an Ri ?
mit den Datenrichtungen DTE / DCE komme ich regelmäßig durcheinander
wer ist hier eigendlich was ? ich denke mal Atmel spielt Modem und
betrachte ihn als DCE und nicht als DTE
glücklicherweise scheint bis jetzt im Plan alles zu stimmen
liebe gruesse
jar
Joachim B. schrieb:> kann jemand kurz sagen wozu der Taster ist vergessen ? :o (Plan von Hr.> Leidinger ?)
gefunden bootloader, SW nachladen, kann also raus,
bleibt also die Frage:
> und warum muss Vcc an Ri ?
liebe gruesse
jar
Joachim B. schrieb:> bleibt also die Frage:>> und warum muss Vcc an Ri ?
Wovon redest Du? Vom Pullup am Reset-Pin in der Schaltung von Klaus
Leidinger?
Gruß,
Frank
Frank M. schrieb:> Joachim B. schrieb:>>> bleibt also die Frage:>>> und warum muss Vcc an Ri ?>> Wovon redest Du? Schaltung von Klaus Leidinger?>> Gruß,>> Frank
ja schrieb ich das nicht ?
bald kann ich scans von den FB loggen, dann schick ich alles was ich an
FB finde
liebe gruesse
jar
und nun ? ich wusste ich hasse logging
#ifndef IRMP_LOGGING
#define IRMP_LOGGING 1 // 1: log IR
signal (scan), 0: do not (default)
#endif
ich verstehe logging auf 1 ?
steht ja auch da, 1 log IR
aber dann :
#if IRMP_LOGGING == 0
// USART initialization has to be done here if Logging is off
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART Receiver: Off
// USART Transmitter: On
// USART0 Mode: Asynchronous
// USART Baud Rate: 9600
#define BAUDRATE 9600L
UCSR0A=0x00;
UCSR0B=0x08;
UCSR0C=0x06;
UBRR0H = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) >> 8; //
store baudrate (upper byte)
UBRR0L = ((F_CPU+BAUDRATE*8)/(BAUDRATE*16)-1) & 0xFF;
#endif
also wird das UART init wenn logging off ?
nix verstehen.....
bei build gibt:
../irmp.c:645: error: 'U2X' undeclared (first use in this function)
UART0_UCSRA &= ~(1<<U2X);
ich finde die DEF von U2X nirgends ,
wo gehört sie wie hin ?
danke (sorry das ich blöd bin, ist immer schwer sich in fremden code
zurechtzufinden und mit dem uart hab ich noch nie im atmel gearbeitet,
tippe da muss irgendwo ein init vergessen sein)
liebe grüße jar
so uart ausgabe läuft,
irgendwie uart.c und .h vergessen
da der at644 irgendwie nicht drin lief eben ein paar defs geändert
egal läuft
nur com terminal spuckt nix aus
aber hterm aber mit sonderzeichen
nun weiss ich leider immer noch nicht wie ich mitloggen soll
entweder es ist zu dünne erklärt oder ich bin unfähig....
blicke grad nicht durch warum com terminal nix zeigt aber hterm und
welches pc log prgramm laufen muss und unter xp laufen kann, mal eben
linus booten ist grad nicht möglich und den rücken verdrehen zum anderen
rechner auch nicht so lang sind meine kabel nicht
gruss
jar
Joachim B. schrieb:> aber hterm aber mit sonderzeichen
Du musst hterm auf 9600 Bd 8 Bit no Parity stellen.
> entweder es ist zu dünne erklärt oder ich bin unfähig....
Da ich von den IRMP-Anwendern bereits Dutzende Scan-Dateien erhalten
habe, sollten die Erklärungen im IRMP-Artikel eigentlich reichen ;-)
Gruß,
Frank
so
versuch mal dein Glück bitte
wenn das erfolgreich ist scanne ich alle Tasen und mher FBs
ich glaube meine Schaltung spinnt noch ein bissl,
nicht so leicht scans einzufangen wenn irgendjemand
irgendwo auf die FB drückt,
muss wohl in ein dunkles Zimmer ohne Fenster
und ohne IR Pyramiden,
die fangen sich offensichtlich auch was ein
lg
jar
Joachim B. schrieb im Beitrag #1813217:
> so ?> 11111111111111111110000......
Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads
enorm gewachsen ist ;-)
Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten
erstmal eine halbe Stunde scrollen...
Gruß,
Frank
Joachim B. schrieb:> versuch mal dein Glück bitte
Habe es mir eben mal kurz angeschaut: Der Scan ist mit 15kHz
aufgezeichnet worden... hättest Du auch sagen können ;-)
> nicht so leicht scans einzufangen wenn irgendjemand> irgendwo auf die FB drückt,> muss wohl in ein dunkles Zimmer ohne Fenster> und ohne IR Pyramiden,> die fangen sich offensichtlich auch was ein
Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in
die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat
sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein
kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch
noch ab und an anderer Schrott zwischendurch zu sehen.
Ich muss Deine Scans erstmal ein wenig säubern, bevor ich da näheres
erkenne. Besser wäre es allerdings, mit 10kHz zu scannen (reicht für
Kaseikyo vollkommen aus) und wirklich dafür zu sorgen, dass keine
anderen IR-Sender dazwischenfunken.
Gruß,
Frank
Frank M. schrieb:> Joachim B. schrieb im Beitrag #1813217:>> so ?>> 11111111111111111110000......>> Klasse, Du hast es geschafft, dass die Fensterbreite dieses Threads> enorm gewachsen ist ;-)>> Wäre wohl besser, den Beitrag zu löschen, sonst muss man zum Antworten> erstmal eine halbe Stunde scrollen...>> Gruß,>> Frank
ich hab versucht zu löschen, geht nicht, ist mir ja auch peinlich, aber
ich wollte kein Umbrüche drin haben
ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !
kannst du mit den Scans was anfangen ?
hier noch mal
alle meine FB
die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten,
muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit
warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin
sein ?
habe mal jvc dazugelinkt
Joachim B. schrieb:> ich habe den Beitrag gemeldet, wenn ein Mod bitte diesen löscht !
Ich hatte ihn auch schon gemeldet ;-)
> kannst du mit den Scans was anfangen ?
Ja, habe ein Ergebnis. Die beiden verschiedenen OFF-Tasten bringen
folgende 48 Daten-Bits:
1
1 2 3 4
2
123456789012345678901234567890123456789012345678
3
010000000000010000001101000000001011110010110001 p = 5, a = 0x2002, c = 0x03d0, f = 0x00
4
010000000000010000000001000000001011110010111101 p = 5, a = 0x2002, c = 0x03d0, f = 0x00
5
ccccccccccccccccPPPPssssppppppppffffffffCCCCCCCC
IRMP ermittelt daraus jeweils die Adresse 0x2002 und das Kommando
0x03d0. Tatsächlich unterscheiden sich aber die 48 Bits genau an 4
Stellen, nämlich Bit21-22 und Bit45-46.
Dabei haben die 48 Bits folgenden Aufbau:
c = 16 Hersteller (customer) Bits
P = 4 Parity Bits
s = 4 System-Bits
p = 8 Produkt-Bits
f = 8 Funktions-Bits
C = 8 Datenüberprüfungs-Bits
Der signifikante Unterschied der beiden Tasten liegt in den 4
System-Bits, die von IRMP bisher komplett ignoriert wurden - einfach,
weil ich dafür keine genauen Infos herausgefunden habe, was diese Bits
genau bedeuten. Dass IRMP überhaupt Datenbits bei Kaseikyo ignoriert,
hat einen einfachen Grund: Ich muss die 48 bit irgendwie in 16 Adress-
und 16 Kommando-Bits pressen. Ich muss mir also überlegen, wie ich die 4
Systembits da noch unterbringe. Gib mir also bitte etwas Zeit ;-)
> alle meine FB> die Kaseikyo würde ich scannen wenn du sagst du kannst sie auswerten,> muss ich dann wirklich alle Tasten scannen ? ist ein Haufen Arbeit
10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)
> warum wird die JVC immer noch nicht erkannt ? der Code sollte doch drin> sein ?
Ich werde mir den JVC-Scan anschauen. Ist der auch mit 15kHz gescannt?
Gruß,
Frank
Frank M. schrieb:> Ich werde mir den JVC-Scan anschauen.
Das Ding benutzt zwar die NEC-Timings, das Protokoll ist aber komplett
anders aufgebaut: Nach jeweils 16 der insgesamt 50 Bits wird eine
längere Pause von ca. 22msec eingelegt. Ausserdem scheinen die Daten
(die nur eine Länge von 16 Bit haben) insgesamt 2x wiederholt zu werden.
Also ist der Aufbau:
1 NEC-Start-Bit
16 Daten-Bits
1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits
1 Stop-Bit + Pause (Synchronisation?)
16 Daten-Bits
Näheres kann ich Dir erst sagen, wenn Du mich mit mehr JVC-Scans
versorgst.
Gruß,
Frank
Frank M. schrieb:> 10 Tasten reichen. Bitte aber nicht einfach nur die Zahlen 0-9 ;-)
mach ich nach Wunsch oder Querbeet ?
Frank M. schrieb:> Frank M. schrieb:>>> Ich werde mir den JVC-Scan anschauen.>> Das Ding benutzt zwar die NEC-Timings,...> Gruß,> Frank
auch das, s.o.
mach ich nach Wunsch oder Querbeet ?
Joachim B. schrieb:> mach ich nach Wunsch oder Querbeet ?
Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre
nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man
meist gut eine Systematik ablesen.
Gruß,
Frank
Frank M. schrieb:> Joachim B. schrieb:>> mach ich nach Wunsch ?>> Querbeet - halt die Tasten, die Du für am wichtigsten erachtestest. Wäre> nicht schlecht, wenn die Nummerntasten 0, 1, 2 dabeiwären, da kann man> meist gut eine Systematik ablesen.> Gruß,> Frank
so getan, aber nicht alle 10er Tasten 1-5 jeweils doppelt
ich hoffe ich habe mich nicht ver C&P und verguckt
ich sehe Jitter ? oder Frequenzabweichung, da ich ja doppelt gescant
hatte erwarte ich 1 und 0 immer fast gleich, mal eine mehr oder weniger
muss dann Jitter sein ? oder Frequenzabweichung ?
so ich werde dann mal das 128 x 64 gLCD anfrickeln mit LED Beleuchtung
jetzt hängt ja nur das 4x20 Z dran unbeleuchtet
wenn dir Scans fehlerhaft scheinen oder fehlen, bitte sofort melden,
schick ich dann nach
die pana VCR FB fehlt mir noch, muss ich nachreichen, habe nur noch 3
Tage Zugriff drauf
Joachim B. schrieb:> ich sehe Jitter ? oder Frequenzabweichung,
Ich sehe da zwischendurch viel Schrott, auch mal zwischendurch
Samsung32-Frames. Ausserdem sind da bei den ersten paar Tasten
unerklärliche Zeilenumbrüche drin. Funkt da was dazwischen?
Hatte ich auch heute vormittag in
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
geschrieben.
Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte
auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht
notwendig und verlängert die Scans unnötig.
Gruß,
Frank
Frank M. schrieb:> Bitte ausschließen, dass Deine "Pyramiden" dazwischenfunken und bitte> auch die Scan-Frequenz auf 10kHz zurückschrauben. 15kHz sind hier nicht> notwendig und verlängert die Scans unnötig.> Gruß,> Frank
die heutigen scans ohne OFF Taste ohne Störungen von den Pyramiden, die
sind daheim (die zuvor gescanten OFF Tasten hab ich aber reinkopiert um
Arbeit zu sparen)
auf 10kHz umgestellt, nach Durchsicht der config brauche ich die wohl
nicht
IRMP_SUPPORT_FDC_PROTOCOL
IRMP_SUPPORT_RCCAR_PROTOCOL
IRMP_SUPPORT_SIEMENS_PROTOCOL
IRMP_SUPPORT_RECS80_PROTOCOL
SUPPORT_RECS80EXT_PROTOCOL
Siemens könnte evt. noch kommen, dann wird man sehen
>15kHz sind hier nicht> notwendig und verlängert die Scans unnötig.> Gruß,> Frank
aber hilft das nicht der Genauigkeit der Auswertung, weniger
Jitterfehler ?
Frank M. schrieb:> Allerdings... die erste Zeile ist nur ein Fragment, die kann man nur in> die Tonne stopfen. Die anderen 3 Zeilen sind brauchbar, allerdings hat> sich da in die zweite Zeile neben eines Kaseikyo-Frames auch noch ein> kompletter SAMSUNG32-Frame mit reingeschmuggelt. Ausserdem ist da auch> noch ab und an anderer Schrott zwischendurch zu sehen.> Gruß,> Frank
das hatte ich wohl überlesen,
ist halt doof wenn Frau beim Scan der Panasonic die Samsung bedient weil
sie lauter oder leiser haben will (ich hatte vesucht aufzupassen,
klappte wohl nicht immer) ausserdem sehe ich ab und an unmotiviert die
IR Pyramiden blinken, war wohl keine gute Idee die alten scans
dazuzulinken, OK und 15 kHz hatte ich verschwiegen, aber du findest
offensichtlich alle Gemeinheiten die dir die User wohl unterjubeln (ohne
Absicht)
also wie gesagt,
auf 10 kHz ist umgestellt (immer noch die Frage, wäre für Scan nicht 15
kHz genauer?)
IR Pyramiden sind nicht hier und @work kann kein weiteres IR Signal
stören, ausser Schmutz auf der Versorgungsleitung oder
Maschineninduktion, hier sind schon irgendwo heftige Stanzen zu hören,
aber wo die sind habe ich noch nicht rausgefunden, so ein Stahlbetonbau
lääst die Gräusche zwar weit durch aber schlecht ortbar
ich sanne neu bei Bedarf
Joachim B. schrieb:> auf 10 kHz ist umgestellt
Gut.
> (immer noch die Frage, wäre für Scan nicht 15 kHz genauer?)
Nein, 10kHz reicht bei Deinen FBs vollkommen aus.
> ich sanne neu bei Bedarf
Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein
(Berücksichtigung der 4 System-Bits) und implementiere das
JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar
10kHz-Scans liefern würdest.
Gruß,
Frank
Frank M. schrieb:> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein> (Berücksichtigung der 4 System-Bits)
super DANKE dafür ! und bitte bitte IRSND nicht vergessen darauf kommt
es ja hauptsächlich an (Ziel nicht aus den Augen verlieren will)
>und implementiere das> JVC-Protokoll. Da wäre es aber klasse, wenn Du mir von der JVC ein paar> 10kHz-Scans liefern würdest.
klaro das hat Zeit ist weniger für mich mehr für alle deren FB nicht
mehr geht
ich hoffe ich habe keine copy paste Fehler drin
(einige scans waren zu lang und dann läuft hterm leicht über, im scroll
fenster und man erwischt den anfang nicht)
heute frisch gescant 10 kHz ohne IR Pyramiden
#Sondertasten (VCR/DVD play rec usw.) unter Schiebeklappe bitte nicht
noch auch, nur wenn die Not gross ist :-)
Joachim B. schrieb:> heute frisch gescant 10 kHz ohne IR Pyramiden
Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal, die
FBs senden nicht soooo genau. Ausserdem kommt schon durch das Pollen in
der ISR ein Fehler von +/- 1 zustande. IRMP arbeitet aber mit
Toleranzen, deshalb ist das überhaupt nicht tragisch.
Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.
Gruß,
Frank
Frank M. schrieb:> Ich kümmere mich erstmal um Kaseikyo, dann melde ich mich wieder.> Gruß,> Frank
fein morgen scanne ich alle meine Panasonic FB Kaseikyo neu
VCR NV FJ630 VHS
TV TX-L32S10ES
DVD/HDrec Panasonic DMR-EX 79
10 kHz ohne IR Pyramidenstörungen
Frank M. schrieb:> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein> (Berücksichtigung der 4 System-Bits)> Gruß,> Frank
brauchst du noch was ?
hier die KASEIKYO Panasonic VCR FB
Frank M. schrieb:> Die Scans sehen sehr gut aus. Die Abweichungen (Jitter) sind normal,> Gruß,> Frank
das wundert mich nun etwas,
sagte ich nicht das an dem MAX nur +5 und NULL rauskamen ?
nun nachdem ich den Schluss unter dem SMD PAD (MAX233 9 GND nach 10
irgendein int. Kondi) gefunden hatte habe ich jetzt endlich +-10V
aber wenn die Scans schon vorher gut waren soll das nicht weiter stören
Joachim B. schrieb:> hier die KASEIKYO Panasonic VCR FB
Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.
55 Scans weisen einen abweichenden Herstellercode auf, welcher für
Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss
erstellt worden?
Macht nix, der Rest ist echt brauchbar.
Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie
möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich
lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den
ersten Tasten ;-)
Dank und Gruß,
Frank
Frank M. schrieb:> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein> (Berücksichtigung der 4 System-Bits) und implementiere das> JVC-Protokoll.
Anbei die geänderten Sources zum Test.
Neu:
- Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
ausgewertet
- Neues Protokoll: JVC
Viel Spaß,
Frank
Frank M. schrieb:> Joachim B. schrieb:>> hier die KASEIKYO Panasonic VCR FB>> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für> Panasonic 0x2002 ist.
hmm, welche ?, könnte die ja nachliefern, hast ja die #Headerzeile dazu
>Ist die Datei auch schon mit dem MAX-Kurzschluss> erstellt worden?
ja leider, wollte erst liefern, dann hat mich der Pegel doch nicht ruhen
lassen und ich ging auf Fehlersuche
> Macht nix, der Rest ist echt brauchbar.> Achja, noch eine Bitte: Beim Scannen bitte immer die Tasten so kurz wie> möglich drücken. Beim JVC-Scan hast Du da offenbar des öfteren ziemlich> lange den Finger auf den Tasten gehabt - jedenfalls zu Anfang bei den> ersten Tasten ;-)> Dank und Gruß,> Frank
na ja man wartet immer auf Bestätigung, ich hab ne LED Quittung
eingebaut, 1s LED Blink wenn Code erkannt, nur im Logging Mode erkennt
er ja nix und ich warte vergebens und im HTERM kommen die Daten
offensichtlich erst verzögert, also bleib ich zu lang drauf und dann
wollen die Daten nicht enden
einige Tasten sind auch versenkt um Fehlbedienungen zu meiden, deren
Druckpunkt ist schwer zu fühlen
ich weiss, alles Ausreden, aber wer so lange im Beruf ist der kann wohl
nicht anders
danke und gruß zurück
jar
Frank M. schrieb:> Frank M. schrieb:> Ich baue erstmal die angekündigten Änderungen für Kaseikyo ein> (Berücksichtigung der 4 System-Bits)> Neu:> - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame> ausgewertet
hmm, aber scheinbar noch etwas wackelig (muss ich mir meine
Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht
genau ausgerichtet ist und man nicht lange drückt erkennt er viele
Zufallscodes, ist nicht so stabil wie RC5, da kenne ich nur ja / erkannt
oder nein / eben nicht, aber Zufallscodes seh ich nie
> und implementiere das> JVC-Protokoll.> - Neues Protokoll: JVC
ah, erst verwundert, wird nicht angezeigt, dann aber
meine JVC wird erkannt , A + C wird angezeigt aber unter Code nicht JVC
!
> Viel Spaß,> Frank
danke den hab ich schon
Frank M. schrieb:> Ja, und? Ist hier die Bezeichnung "Jitter" falsch, wenn es um> Messabweichungen von Rechtecksignalen wie bei den folgenden geht?
Nein, nicht bei dir.
Nur bei Joachim klang es danach, dass er damit die
Spannungs-Sonderheiten wegen seiner MAX-Beschaltung meinte.
Joachim B. schrieb:> meine JVC wird erkannt ,
Gut.
> A + C wird angezeigt
Auch gut.
> aber unter Code nicht JVC
Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über
ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört
nicht wirklich zu den IRMP-Sources dazu, denn:
irmp_get_data liefert lediglich
uint8_t protocol
uint16_t address
uint16_t command
protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle
drin.
Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und
dort den String "JVC" eintragen.
Gruß,
Frank
Joachim B. schrieb:> hmm, aber scheinbar noch etwas wackelig (muss ich mir meine> Abblockkondis ansehen oder meine 5V Versorgung ?), wenn die FB nicht> genau ausgerichtet ist und man nicht lange drückt erkennt er viele> Zufallscodes, ist nicht so stabil wie RC5,
Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem
ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen
36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch
und die Fehlerquote nimmt zu.
Gruß,
Frank
Frank M. schrieb:> Den Satz verstehe ich nicht. Hast Du im main() eine Text-Ausgabe über> ein Text-Array drin und vermisst nun das Wörtchen "JVC"? Das gehört> nicht wirklich zu den IRMP-Sources dazu, denn:>> irmp_get_data liefert lediglich>> uint8_t protocol> uint16_t address> uint16_t command> protocol hat den Wert 20 bei JVC, siehe irmp.h, da sind alle Protokolle> drin.> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern und> dort den String "JVC" eintragen.> Gruß,> Frank
sowas dachte ich schon, nur hab ich die Zuweisung nicht gefunden
aber nun
static char
*Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)"
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};
> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern
wie das ich finde nirgends eine Zuweisung von Array auf 20
soweit wie ich C gelernt habe ist durch anhängen von ,"JVC" das Array
schon ab compile vergrößert, da es ja statisch initialisiert wird, eine
seperate Zuweisung dürfte nicht (nötig) sein und finde ich auch nicht
hmm es funzt jedenfalls noch nicht
ich tippe auf NEC erkannt und JVC eben nicht
Frank M. schrieb:> Was für einen IR-Empfänger nutzt Du? TSOP1736 oder 1738? Das Problem> ist, dass Kaseikyo mit 56 kHz moduliert wird und der TSOP mit seinen> 36kHz bzw. 38kHz ziemlich daneben liegt. Die Entfernung sinkt drastisch> und die Fehlerquote nimmt zu.> Gruß,> Frank
TSOP 1736 , aber mein Scan an einer BPW21 lieferte 36 kHz Schwingungen
ich könnte ja noch mal einen OP vorschalten und eine FFT machen
gruss
jar
peinlich peinlich
sind ja nur 14 Text STR definiert, hab nicht nachgezählt
musste also 6x "", einfügen das 20 auf "JVC" zeigt ......
ja ich bin aus der Übung und sehe nicht immer alles (sofort)
gruss
jar
Joachim B. schrieb:> aber nun>> static char> *Proto[]={"SIRCS","NEC","SAMSUNG","MATSUSH","KASEIKYO","RECS80","RC5(x)"
,"DENON","RC6","SAMSG32","APPLE","RECS80x","NUBERT","JVC"};
Du hast "JVC" an 14. Stelle statt an 20. Stelle eingetragen, damit das
Array auch nur auf 14 Elemente vergrößert.
>>> Du müsstest bei Deiner Textausgabe das Text-Array auf 20 vergrößern>> wie das ich finde nirgends eine Zuweisung von Array auf 20
Eben, die Dimension von Proto[] ist nicht angegeben.
> hmm es funzt jedenfalls noch nicht
Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und
sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der
Protokolle 1-20 in irmp.h.
Gruß,
Frank
Frank M. schrieb:> Eben, die Dimension von Proto[] ist nicht angegeben.> Trage alle fehlenden Namen ein (die einzelnen nicht zu lang machen!) und> sorge dafür, dass "JVC" an 20. Stelle steht, siehe Nummern der> Protokolle 1-20 in irmp.h.> Gruß,> Frank
hatte ich doch schon,
Joachim B. schrieb:> peinlich peinlich> sind ja nur 14 Text STR definiert, hab nicht nachgezählt> musste also 6x "", einfügen das 20 auf "JVC" zeigt ......> ja ich bin aus der Übung und sehe nicht immer alles (sofort)> gruss> jar
ich denke ich werde trotzdem noch mal einen Frequenz Scan aller FB
machen
wie geschrieben mit BPW21 OP und FFT
und mal alle meine FB scannen
Frank M. schrieb:> Das Problem ist, dass Kaseikyo mit>> 56 kHz> moduliert wird und der TSOP mit seinen 36kHz bzw. 38kHz> ziemlich daneben liegt.> und die Fehlerquote nimmt zu.> Gruß,> Frank
wo hast du die Daten her ?
ich kann hier machen was ich will
ich messe burst von 26-28 µs was 35,9 - 38,5 kHz gibt
übrigens alle
>> meine Kaseikyo liegen eher bei 36 kHz ,
nur die JVC scheint um 38 kHz zu liegen
bin verwirrt von deinen 56 kHz
gruss
jar
Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein
UFS-922 Fernbedienung. Wurde das Problem gelöst? Ich habe beim Bau einer
FB diesen Code enträtselt.....
ach ja , vergessen
irgendwer schrieb mal was von 450 kHz IR Modulation, aber ich bin nicht
sicher ob das so stimmt, weil :
einige modilieren auch mit x-facher Frequenz wegen oversampling
da können die paar 100 kHz auch vielfache von 36 oder 38 - 40 oder 56
kHz sein
ggffs kann man später mal in IRSND oversampling einstellen und schauen
was aus den TSOP rauskommt, ich vermute mit exakt doppelter oder gerade
Vielfache werden die auch output liefern.......
gruss
jar
Samuel schrieb:> Joachim B. schrieb:>> peinlich peinlich> Spiegelt deinen Auftritt hier gut wieder.> Du hast mal von jar nüscht Ahnung.
danke danke, von nüscht würde ich nüscht sagen.....
OK ich bin nicht so der Softi und aus der Übung
aber war der Kommentar nötig ?
na egal wer anonym so was schreibt braucht das wohl
ich komm schon klar, hab halt nicht die Arrays ausgezählt
wer so perfekt ist wie du kann sich anmelden und auch besser Fragen
beantworten und zum Rest höflich schweigen....
freundlichen gruss
jar
Wolfgang Dunczewski (midi-rakete) schrieb:> Ich lese oben, dass es Probleme gibt/gab mit dem Code einer Kathrein> UFS-922 Fernbedienung. Wurde das Problem gelöst?
Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich
dokumentiert ist. IRMP unterstützt nur den sog. Mode 0 von RC6, siehe
auch:
http://www.sbprojects.com/knowledge/ir/rc6.htm> Ich habe beim Bau einer FB diesen Code enträtselt.....
Dann schieß mal los.
Gruß,
Frank
Frank M. schrieb:> Nein, die Kathrein benutzt einen RC6-Mode, der nicht oder nur spärlich..>> http://www.sbprojects.com/knowledge/ir/rc6.htm>>> Ich habe beim Bau einer FB diesen Code enträtselt.....>
Ich fand im Web Infos über den RC-6 Mode 6A 20:
[[http://www.guiott.com/wrc/RC6-6.html]]
mit 20 Bit Nutzrate
Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a
32), aber nicht nach Norm:
Die FB vom UFS-922 macht folgendes:
Leader Pulse (ok)
Start Bit (ok)
Mode Bits 2,1,0 (H,H,L = Mode 6)
Trailer Bit: Flanke immer L>H (nicht offiziell, soll normal toggeln)
Dann folgen 4 Bytes:
Das erste Byte ist immer 10000000 (von links nach rechts wird gesendet)
Das zweite Byte ist immer 01000110
Das dritte Byte enthält das Toggle-Bit TB und
die Ebene/Adresse falls man mehrere FBs hat
TB AD2 AD1 AD0 0000
also normal bei Adresse 0:
10000000
und abwechselnd
00000000
Eigenlich gehört das Togglebit an eine andere Stelle. Das Trailer Bit
soll eigentlich toggeln. Aber Kathrein lässt ein Bit togglen. Deshalb
funtioniert fast keine programmierbare FB mit dem Kathrein.
Und im 4. Byte kommen die Befehe 00-FF
nnnnnnnn
Wolfgang Dunczewski (midi-rakete) schrieb:> Die Kathrein nutzt "in etwa" diesen als 32 Bit Version (RC-6 mode 6a> 32), aber nicht nach Norm:> [...]
Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.
Gruß,
Frank
Frank M. schrieb:>> Joachim B. schrieb:>> sehr interessant:>> http://ecee.colorado.edu/~mcclurel/vishay_ir_data_formats.pdf>> Danke, immerhin steht da drin, dass Kaseikyo mit 36.7kHz moduliert wird.> Werde ich im IRMP-Artikel anpassen.> Insgesamt ist Deine Liste nicht so der Renner, trotzdem danke dafür.> Vielleicht hättest Du Dir vorher mal die Literatur-Hinweise aus dem> IRMP-Artikel angucken sollen, um entsprechend auszufiltern und nicht> jeden Google-Treffer einfach hier reinzukopieren ;-)> Gruß,> Frank
immerhin hab trotzdem noch was gefunden, sorry das es mir nicht möglich
war alle Infos mit den vorhandenen abzugleichen, ich hab hier grad Land
unter und bin deswegen nur sehr begrenzt konzentriert dabei, ich hoffe
das geht trotzdem i.O.
gruss
jar
Frank M. schrieb:> Vielen Dank für die Infos, werde ich mir mal zu Gemüte führen.> Gruß,> Frank
hallo,
wie siehts aus mit KASEIKYO im IRSND ?
würde dann bald ein IRSND Modul aufbauen für
PC -> RS232 -> Atmel IRSND -> IS Sendediode
ich grübel gerade ob der Umweg über Atmel sein muss weil,
kennst du den CT Artikel IRDEO ?
http://www.heise.de/ct/projekte/Fernregie-IRdeo-284185.htmlhttp://irdeo.de/
dort wurde IR Empfang und Senden mit der seriellen Schnitte gemacht,
funzte so leidlich (sogut win das eben zulässt) mit W2k und XP musste
der IO (giveio o.ä.) Treiber installiert werden
http://irdeo.de/ntdriver.zip
GIVEIO.SYS (Dale Roberts), LOADDRV (Paula Tomlinson)
senden war übrigens tricky, die IR Modulation 36 38 40 kHz wurde per
Baudrate / respektive geschickte 1/0 Wahl eingestellt, je nach 1/0 Folge
und Baudrate ist ja quasi jede IR Modulation machbar, die Start oder
Stoppbits, wenn sie einzeln erfolgen, scheinen nicht zu stören
leider war es nur eine lernbare FB welche die Codes nur gelernt wieder
abspielen konnte und mit der Erkennung haperte es leider auch, da ist
dein Projekt viel weiter und besser, aber ggffs kann man die beiden
Konzepte zusammenbringen
für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232
Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)
freundliche Grüße
jar
Joachim B. schrieb:> wie siehts aus mit KASEIKYO im IRSND ?
Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche
Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32
Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.
Ich warte daher immer noch auf die Scan-Dateien Deiner 3
Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen
angekündigt hattest.
Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal
schrieb.
Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber
noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden
und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von
Dir gesehen.
> kennst du den CT Artikel IRDEO ?
Ja, habe ich mal vor Jahren überflogen.
> für mich wäre ja nur IR Sender nötig wenn ich das ohne Atmel am RS232> Port erreiche spart das Arbeit und Geld (nix gegen die Atnelbastelleien)
Sorry, wüsste ich jetzt nicht, wie. Du kannst natürlich den IRSND-Code
auf eine andere Plattform portieren.
Gruß,
Frank
Frank M. schrieb:> Joachim B. schrieb:>> wie siehts aus mit KASEIKYO im IRSND ?> Wie ich schon schrieb: dafür brauche ich Futter, damit ich sämtliche> Paritätsbits aus den Daten wieder erzeugen kann. Nur so kann ich die 32> Bit IRMP-Datenstruktur auf die vollen 48bit-Kaseikyo-Frames aufblasen.>> Ich warte daher immer noch auf die Scan-Dateien Deiner 3> Kaseikyo-Fernbedienungen, die Du mir schon vor ein paar Tagen> angekündigt hattest.>> Ich brauche von jeder dieser 3 FB ca. 10 Tasten, wie ich schon mal> schrieb.>> Du hattest hier mal für die Panasonic VCR FB Scans reingestellt, wo aber> noch erhebliche Störungen drin waren. Du hattest den Grund wohl gefunden> und wolltest den Scan wiederholen. Bisher hab ich da aber nix neues von> Dir gesehen.> Gruß,> Frank
war wohl ein Missverständniss
auf die VCR FB hab ich nun kein Zugriff mehr, ich hab noch im Ohr, sind
zwar Störungen drin aber brauchbar
Frank M. schrieb:> Joachim B. schrieb:>> hier die KASEIKYO Panasonic VCR FB>> Danke, habe ich mir angeschaut, leider sind nur 161 von 216 Scans okay.> 55 Scans weisen einen abweichenden Herstellercode auf, welcher für> Panasonic 0x2002 ist. Ist die Datei auch schon mit dem MAX-Kurzschluss> erstellt worden?>> Macht nix, der Rest ist echt brauchbar.> Dank und Gruß,> Frank
die 161 scans reichen nicht von der VCR ?
Ich kann also nur noch
Panasonic TV liefern und Panasonic HDrec/DVD
muss mal sehen ob ich den VCR noch mal bekomme
Joachim B. schrieb:> die 161 scans reichen nicht von der VCR ?
Wenn es diese FB ist, welche Du über IRSND auch emulieren willst - ja,
dann reicht es.
> Ich kann also nur noch> Panasonic TV liefern und Panasonic HDrec/DVD
Wenn Du die für IRSND nicht brauchst, dann nicht. Wäre aber trotzdem
nett, wenn Du davon jedoch auch noch je 10 Scans machen könntest, dann
kann ich das allgemeiner in IRSND machen.
Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.
Gruß,
Frank
Frank M. schrieb:> Sag mir bitte auch, welche FB Du mit IRSND emulieren möchtest.> Gruß,> Frank
eigendlich genau diese
Panasonic HDrec/DVD
und die sollst du noch mal bekommen
zur Fernprogrammierung über PC
TV hat ja aus der Ferne irgendie keinen Sinn, da könnte ich gleich winTV
im Rechner starten
ich hab den IRMP so schön auf 4x MiMh Akku laufen, damit wäre mobiles
logging auch für den VCR möglich, aber seit der MAX dranhängt läuft der
TSOP nicht mehr, der MAX braucht 1W sind 200mA und zieht offensichtlich
den Pegel runter, ohne externe Versorgung geht da leider nix
ich grübel gerade ob ich den MAX rausschmeisse und einfach mit 2 Trasis,
simple RS232 Konverter baue
http://picprojects.org.uk/projects/simpleSIO/ssio.htm
1W ist schon heftig
alternativ ginge ja die RS232 anzuzapfen, einige Dioden nach P5 sollte
wieder mehr Strom liefern, DTR und RTS kann man ja setzen, nur auf +
setzen , sollten ja ungefähr je 20mA liefern können
so ähnlich hatte ich auch meine PONY Elektronik aus der parallelen
gespeist, einfach 15 BAT42 an jede signalführende Leitung auf einen
Pufferkondi, reicht für CMOS Logik und Signal LED 3mA
Halbzeit
versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich
musste leider im logging CR LF einfügen, ich hoffe das stört nicht
morgen verm. den Rest
freundliche Grüße
jar
Joachim B. schrieb:> versucht alle Tasten je 2x zu scannen, Tastendruck so kurz wie möglich
Sehr sauberer Scan: keine Störungen, keine Erkennungsfehler. Bei der
Gelegenheit habe ich erkannt, dass bei Kaseikyo auch bei kurzen
Tastendrücken immer mindestens zwei Frames verschickt werden. Bei
längeren Tastendrücken werden drei Frames und mehr gesandt. Ich hatte
das bisher zwar schon immer vermutet, hatte aber da noch nie geeignete
Kaseikyo-Scans.
Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste
Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren
Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst
bekommt man immer einen langen Tastendruck zurück - auch wenn man die
Taste nur kurz gedrückt hat.
> musste leider im logging CR LF einfügen, ich hoffe das stört nicht
Passt perfekt.
Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht
genau sagen. Habe im Moment viel um die Ohren.
Gruß,
Frank
Frank M. schrieb:> Ich muss da im IRMP bzgl. Kaseikyo noch nacharbeiten: die erste> Wiederholung des Frames muss unterdrückt werden. Erst alle weiteren> Wiederholungsframes sind als langer Tastendruck auszuwerten. Sonst> bekommt man immer einen langen Tastendruck zurück - auch wenn man die> Taste nur kurz gedrückt hat.
gibt es da keine Toggel Bits wie in RC5 ? dort klappt das hervorragend
mit der Toggelbitauswertung, habe meinen Timer ja mit
Peters RC5 gebaut
Beitrag "Fernbedien RC5 Empfänger"
da klappt das einfach mit toogle Bit auswerten, muss ja nicht erkennen
ob lang oder kurz
> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht> genau sagen. Habe im Moment viel um die Ohren.> Gruß,> Frank
OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und
postest
viel um die Ohren, wer nicht ;-) (wenn du wüsstest)
gruss
jar
Joachim B. schrieb:> gibt es da keine Toggel Bits wie in RC5 ?
Nein, gibt es nur in RC5, RC6 und RECS80. In den anderen 17 Protokollen,
die IRMP "versteht", gibt es kein Toggle-Bit. Dort gibt es u.a.
alternative Mechanismen wie zum Beispiel Repetition-Frames (NEC).
Kaseikyo hat hier nichts, hier arbeite ich mit Timeouts, um längere
Tastendrücke von X-maligen Tastendrücken zu unterscheiden.
>> Wann ich das Enkodieren in den IRSND einbaue, kann ich Dir noch nicht>> genau sagen. Habe im Moment viel um die Ohren.> OK danke erst Mal, ich bekomm ja Bescheid wenn du hier weiterbist und> postest
Bin doch schon fertig damit. Ich lade hier gleich den Test-Source hoch.
Gruß,
Frank
Anbei die geänderten Sources (gegenüber der Download-Version) mit
verbesserter Unterstützung des Kaseikyo-Protokolls als Test-Version.
Änderungen IRMP
---------------
- Kaseikyo-Protokoll:
Unterschiedliche Behandlung des 1. Wiederholungsframes (kein langer
Tastendruck) von nachfolgenden Wiederholungsframes (langer
Tastendruck).
- Kaseikyo-Protokoll:
Auswertung der 4 + 8 = 12 "Parity-Bits", um Empfangsfehler zu
erkennen.
Änderungen IRSND
----------------
- Unterstütrung des Kaseikyo-Protokolls inkl. Parity- und Genre1-Bits.
- Keine Unterstützung der Genre2-Bits beim Kaseikyo-Protokoll
Schwächen
---------
Das Kaseikyo-Protokoll enthält von den 48 Bit insgesamt 36
Nutzdatenbits. Da die IRMP-Datenstruktur nur 32 Bits (16 Adresse, 16
Kommando) davon speichern kann, gehen leider 4 Bits verloren. Dabei
handelt es sich um die sog. Genre2-Bits, die aber meist 0000 sind.
Relevant kann diese Schwäche beim Senden per IRSND werden, da dann die
Codes einiger bestimmter Tasten (wie MENÜ und OK bei Panasonic) nicht
gesandt werden können.
Abhilfe könnte hier die Erweiterung der IRMP-Datenstruktur um ein neues
Byte namens "product" bringen. Muss ich nochmal nachdenken, ob ich das
einbaue. Wahrscheinlich wird es im nächsten Release enthalten sein.
Gruß,
Frank
Hallo,
Ist IRMP eigentlich mit der neuen Apple Remote (Unibody) kompatibel?
Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt
verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.
Einen Debug Trace der Apple Remote habe ich mal angehängt (Trace enthält
noch eine Taste einer anderen FB zum Vergleich), sowie einen
aufbereiteten Oszilloskop-Mitschnitt.
CU Dirk
Hallo Dirk,
diese Seite: http://en.wikipedia.org/wiki/Apple_remote
lässt darauf schliessen das beide gleich sind.
Laut Apple Seite ist die Unibody Remote mit allen Produkten nach 2005
eingeführt wurden kompatibel, was nicht das gleiche ist...
Ich hatte die alte (Plastik) FB mit dem iPod 5 Generation getestet, der
im Oktober 2005 vorgestellt wurde, hatte funktioniert. Diese scans waren
auch die "Referenz" für Frank. (falls nicht jemand neue scans geliefet
hat).
Ich glaube dem Wiki Artikel und bin sicher das beide Remote das gleiche
Protokoll haben.
HTH,
Klaus
Dirk W. schrieb:> Hab mir gestern eine gekauft und wollte sie in meinem aktuellen Projekt> verwenden; funktionierte aber leider nicht. Keinerlei Reaktion von IRMP.
Ich habe mir gerade den Scan angeschaut. Das Timing ist NEC- und
APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als
die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits
nochmal invertiert ausgibt.
Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am
Wochenende.
Gruß,
Frank
Hi,
Danke Frank :-).
Hab gerade mal ein bisschen gesucht und beim LIRC Projekt folgendes
gefunden:
http://lirc.sourceforge.net/remotes/apple/A1294> pre_data 0x77E1> UP 0x50> DOWN 0x30> LEFT 0x90> RIGHT 0x60> PLAY 0xFA> MENU 0xC0> OK 0x3A
Das würde dem von mir ausgelesenen Protokoll entsprechen.
Scheinbar hat Apple wohl verschiedene Codes in seinen Produkten
hinterlegt.
Wünsche ein schönes WE...
CU Dirk
Frank M. schrieb:> APPLE-kompatibel, allerdings verwendet Deine APPLE-FB eine andere ID als> die APPLE-FB von Klaus - nämlich genau da, wo NEC eigentlich die Bits> nochmal invertiert ausgibt.
Laut der lirc Seite sind die Adressen von alter und neuer FB gleich, nur
die Kommandos der Tasten unterscheiden sich:
http://lirc.sourceforge.net/remotes/apple/A1156http://lirc.sourceforge.net/remotes/apple/A1294
Allerdings stimmen die "Lirc" Werte der alten FB mit der Wiki Seite
überein, wenn man LSB berücksichtigt.
Ich habe noch mal meine Aufzeichnungen gecheckt, die alte FB wurde von
IRMP ebenfalls mit Adresse 0x77E1 erkannt,
0x87EE (von der Wiki Seite) in LSB gelesen ergibt 0x77E1
Ach ja, die "alte" FB gibt es wohl auch erst seit Oktober 2005, das
hatte ich überlesen.
Mal wieder raffiniert gemacht von A**le...
Grüße,
Klaus
Hallo und supper Arbeit.
So weit leuft alles bei mir mit dem einlesen der codes. Aber die
Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste
ich drücke kommt immer der Code
irmp_data.protoco =9
irmp_data.address =0
irmp_data.command =31
Vieleicht kann mir von euch Jemand helfen
danke
Graf-von-Socke
Frank M. schrieb:> Das ist ein Klacks, die neue ID in den IRMP einzubauen. Mache ich am> Wochenende.
Habe gerade mal IRMP an den APPLE-Scan angepasst.
@Dirk:
Ersetze bitte die Zeile:
in irmp.c. Dann sollte die FB erkannt werden.
Ich werde das aber anders im nächsten IRMP-Release implementieren. Das
Problem ist nämlich, dass beide FBs dieselbe NEC-Adresse (0x87ee) haben,
aber eine unterschiedliche ID verwenden. Damit dann später auch IRSND
APPLE-Frames versenden kann, welche beide (und auch weitere!) APPLE-FBs
unterstützt, werde ich zukünftig die bisher von IRMP zurückgegebene
Adresse 0x87ee ersetzen durch die ID. Das wäre dann bei der FB von Klaus
die 0xD100 und bei Dirk die 0x4600. Nur so kann eine IRMP-Anwendung auch
beide APPLE-FBs auseinanderhalten. Daher bitte den obigen Patch erstmal
als Test/Notlösung sehen...
Die korrekte Fassung kommt dann am Sonntag.
Gruß,
Frank
Graf-von-Socke schrieb:> So weit leuft alles bei mir mit dem einlesen der codes. Aber die> Ferbedinung von der XBOX 360 macht schwierwigkeiten.Egal welche Taste> ich drücke kommt immer der Code>> irmp_data.protoco =9> irmp_data.address =0> irmp_data.command =31
IRMP glaubt da anhand des Timings einen RC6-Code zu empfangen. Ich
glaube aber nicht, dass Microsoft tatsächlich einen von Philips
entwickelten Code verwendet, sondern (wie so oft) sich etwas eigenes
ausgedacht hat.
> Vieleicht kann mir von euch Jemand helfen
Da helfen nur Scans. Wie Du diese erstellen kannst, steht im
IRMP-Artikel:
http://www.mikrocontroller.net/articles/IRMP
Gruß,
Frank
Graf-von-Socke schrieb:> Hallo hier ist nein Scan ergbis fielicht finden sie etwas
Danke, scheint ein simpler 32-Bit-Code zu sein. Zwei Tasten reichen da
aber nicht, ich bräuchte schon so um die 10 Tasten-Scans, um da auch
eine Struktur zu erkennen. Dann kann ich das in den IRMP integrieren.
Noch als Tipp:
Bitte vor und hinter jedem Kommentar eine neue Zeile beginnen und den
Kommentar selbst mit dem #-Zeichen einleiten, also:
# Die X Taste
000000000000000000000000000000000000000000000000001111...
# Die Play Taste
000000000000000000000000000000000000000000000000001111...
Ist der Scan mit 10kHz aufgenommen worden?
Gruß,
Frank
Ok werde ich morgen abend nochmal durchführen
habe was nettes im Internet gefunden fielicht hilft das weiter
........................................................................
..
lircd.conf für USB-Empfänger (MCEUSB2)
# this config file was automatically generated
# using lirc-0.8.0-CVS(mceusb2) on Tue Jan 17 15:14:11 2006
#
# contributed by Kyle at shadowmage.org
#
# brand: Microsoft
# model no. of remote control: Xbox 360 Universal Media Remote
# devices being controlled by this remote: Xbox 360
#
# This probably works for the normal Xbox 360 remote too.
#
# TV button sends no signal and toggles Xbox 360/TV mode. TV mode can be
# signals for any device the remote supports. Volume Up, Volume Down and
# Mute always use the TV mode while the Xbox live guide button always
sends
# to the xbox.
begin remote
name Microsoft_Xbox360
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100
header 2676 870
one 454 429
zero 454 429
pre_data_bits 21
pre_data 0x37FF0
gap 106291
min_repeat 1
toggle_bit 0
rc6_mask 0x100000000
begin codes
OpenClose 0x8BD7
XboxFancyButton 0x0B9B
OnOff 0x8BF3
Stop 0x0BE6
Pause 0x8BE7
Rewind 0x0BEA
FastForward 0x8BEB
Prev 0x0BE4
Next 0x8BE5
Play 0x0BE9
Display 0x8BB0
Title 0x0BAE
DVD_Menu 0x8BDB
Back 0x0BDC
Info 0x8BF0
UpArrow 0x0BE1
LeftArrow 0x8BDF
RightArrow 0x0BDE
DownArrow 0x8BE0
OK 0x0BDD
Y 0x8BD9
X 0x0B97
A 0x8B99
B 0x0BDA
ChUp 0x8BED
ChDown 0x0BEC
Start 0x0BF2
Play 0x8BE9
Enter 0x0BF4
Record 0x8BE8
Clear 0x0BF5
1 0x8BFE
2 0x0BFD
3 0x8BFC
4 0x0BFB
5 0x8BFA
6 0x0BF9
7 0x8BF8
8 0x0BF7
9 0x8BF6
100 0x0BE2
0 0x8BFF
Reload 0x8BE3
end codes
end remote
........................................................................
..
Quelle
http://www.vdr-wiki.de/wiki/index.php/Fernbedienung_-_Microsoft_XBOX_360_Universal_Media_Remote
Hi,
@Frank:
Danke dir; die Apple-FB klappt jetzt wunderbar :-)
@Frank, Graf-von-Socke
Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB
mit dem Gedanken gespielt die XBOX360 FB zu nehmen.
Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht
und jede Taste 3x aufgezeichnet.
CU Dirk
Zusatz:
Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden
</n>'s
Bitte vorher ersetzen, falls es den Parser stören sollte ?
Dirk W. schrieb:> Danke dir; die Apple-FB klappt jetzt wunderbar :-)
Freut mich. Wie angekündigt, habe ich das mittlerweile allgemeiner
gelöst: die ID wird nun als Adresse zurückgegeben. So sind Deine
Fernbedienung und die von Klaus (und auch weitere APPLE-FBs)
unterscheidbar. Nachteil ist: Die Adresse Deiner FB wird dann eine
andere sein, nämlich 0x0046. Die von Klaus ist dann 0x00D1.
Update kommt in Kürze als Download im Artikel bzw. über SVN.
> Weiß nicht ob's euch hilft, aber ich hatte vor meiner Apple FB> mit dem Gedanken gespielt die XBOX360 FB zu nehmen.> Hab meinen Trace mal angehängt. Wurde mit 15000 gemacht> und jede Taste 3x aufgezeichnet.
Vielen Dank! Deine Scans sind wunderbar, Graf-von-Socke hat offenbar
eine ganz andere Scan-Frequenz genutzt, so dass ich mit seinen Scans
wenig bis gar nichts anfangen konnte, weil IRMP mit 10kHz erst gar nicht
RC6 erkannt hat.
Die XBOX benutzt tatsächlich RC6-Code, wer hätte das gedacht. Aber ich
habe hier genau dieselben Probleme wie mit der Kathrein-FB, deren Scans
hier schon mal gepostet wurden. Das ist leider kein Mode-0-RC6, wie er
in
http://www.sbprojects.com/knowledge/ir/rc6.htm
beschrieben ist. Ich werde mich nochmal mit der RC6-Decodierung
beschäftigen und hoffe damit, die Kathrein-FB und die XBOX erschlagen zu
können. Im Moment werden nämlich nur Mode-0-FBs mit 7 + 16 Datenbits
erkannt. Die XBOX und die Kathrein-FB benutzen einen abweichenden Mode
mit wesentlich mehr Datenbits. Wenn da jemand irgendeine Doku findet,
wie die Struktur der Datenbits (Länge der Adresse und der Kommandos)
ist, würde ich mich freuen.
> Hatte ich ganz vergessen; Im Trace sind noch an einigen Zeilenenden> </n>'s> Bitte vorher ersetzen, falls es den Parser stören sollte ?
Das war kein Problem :-)
Gruß,
Frank
Achim schrieb:> Ich habe eine Dokumentation zum Mode 6A von RC6 gefunden:> http://slycontrol.ru/scr/kb/rc6.htm. Ich hoffe die hilft dir weiter.
Vielen Dank, das ist ja schon mal ein wenig mehr. Habe den URL direkt
mal im IRMP-Artikel verlinkt. Jetzt muss ich nur schauen, ob ich den
Mode 6A mit den Scans in Einklang bringen kann...
Gruß,
Frank
Es gibt eine neue Version 1.7.3 von IRMP.
Download:
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen gegenüber 1.7.2:
- Neues Protokoll: JVC
- Kaseikyo-Protokoll: Berücksichtigung der Genre-Bits.
ACHTUNG: dadurch neue Command-Codes!
- Kaseikyo-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames
- Verbesserte Unterstützung des APPLE-Protokolls.
ACHTUNG: dadurch neue Adress-Codes!
Analog dazu gibt es auch eine neue Version 1.7.3 von IRSND.
Download:
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen gegenüber 1.7.2:
- Neues Protokoll: Kaseikyo (Panasonic u.a.)
Viel Spaß,
Frank
Hallo
und danke für den richtigen scan war mein fehler hatte den scan auf
20000 eingestellt.
Nun wenn es euch intersesiert bastel ich gerade eine schaltung damit ich
den
mikrocontroller über mein Handy dazu auffoder die geräere (TV usw) zu
steuern.
bis dann
Hi,
noch interessant ist eventuell folgende Seite:
http://www.picbasic.nl/info_rc6_uk.htm
und folgendes Dokument (Seite: 28)
http://home.hccnet.nl/m.majoor/files/pronto.pdf
Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..
Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis
das ich zum Vergleich herangezogen hatte war unterschiedlich.
Hab's trotzdem mal angehängt; vielleicht hilft es ??
CU Dirk
Hallo zusammen
Habe nun ein anders Problem auf meine ATMEGA8 leuft alles supper.
Bin nun wegen platzmagel auf einen ATMGA 168 umgestigen nun leuft nur
noch ISR aber es werden keine IR-CODES Ausgeben
gruß
Graf-von-Socke
Dirk W. schrieb:> noch interessant ist eventuell folgende Seite:> http://www.picbasic.nl/info_rc6_uk.htm
Super Link! Danke. Damit werde ich RC6/RC6A wohl endlich in den Griff
bekommen.
> Hatte vor kurzem auch mal probiert RC6a per Hand zu dekodieren ..> Hab wohl allerdings einen Fehler gemacht, denn das Ergebnis> das ich zum Vergleich herangezogen hatte war unterschiedlich.>> Hab's trotzdem mal angehängt; vielleicht hilft es ??
Danke, werde ich mir anschauen.
Gruß,
Frank
Joachim B. schrieb:> hattest du meine Frage per Mail bekommen ?> darf man dich per Mail fragen ?
Habe ich bekommen. Da ich aber erst Freitag aus dem Urlaub gekommen bin
und eine Antwort auf Deine Mail etwas länger dauert, bin ich noch nicht
dazu gekommen, Deine Mail zu beantworten.
Gruß,
Frank
So, ich habe RC6A als extra Protokoll No. 21 eingebaut. Damit sollte
nicht nur die XBOX-FB funktionieren, sondern endlich auch die
Kathrein-FB, an der ich schon längere Zeit rumdoktere.
Anbei die gegenüber der Download-Version geänderten Sources als
Testversion. Sobald mir jemand sagt, dass es läuft, gibt es ein neues
Release.
Viel Spaß,
Frank
Graf-von-Socke schrieb:> werde es mal gleich ausprobieren ob es geht
Nimm aber 10kHz, das reicht vollkommen. 20kHz braucht man nur für
Protokolle, die enorm kurze Pulse nutzen. Ds ist bisher bisher lediglich
bwi RECS80 der Fall.
15kHz sind auch okay, verbät aber schon mehr CPU-Zeit.
Gruß,
Frank
Nochnal Hallo
habe es gestest und funktioniert supper gemacht.
Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit
dem nicht leüft !
gruß
Graf-von-Socke
Graf-von-Socke schrieb:> habe es gestest und funktioniert supper gemacht.
Freut mich :-)
> Und haben Sie schon mal wegen den ATMGA 168 nachgeschaut warum es mit> dem nicht leüft !
irmp läuft auch auf einem ATMEGA 162 ohne Codeänderung, z.B. im
WordClock-Projekt. Hast Du denn auch den Prozessor-Typ im WinAVR-Projekt
ausgewechselt? Man kann i.a. nicht einfach das HEX-File für einen
ATMEGA8 auf einen 168er laden.
Und unbedingt die Fuses beachten! Siehe
http://www.engbedded.com/fusecalc/
Gruß,
Frank
Hallo Frank
Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen
ATMEGA 168 genommen den ich noch hatte wie müssen die Fuses-bits
aussehn
gruß
Graf-von-Socke
Graf-von-Socke schrieb:> Jo habe habe ich gemach siehe an den 2 Bildern. Habe eine jungfreulichen> ATMEGA 168 genommen den ich noch hatte wie müssen die Fuses-bits> aussehn
Ein jungfräulicher 168er läuft mit 1MHz internem Oszillator. Benutzt Du
tatsächlich einen 3,686400 MHz Quarz, wie Du das im Projekt angegeben
hast?
Ich kann Dir erst die Fuses-Einstellung nennen, wenn Du obige Frage
beantwortet hast.
Gruß,
Frank
Jo da es auf der Testplatine drauf ist. Hatte damit noch keine Probelem
da ich schon fiel mt UART gemach habe und die frequenz mit UART sehr gut
leuft
siehe http://www.wormfood.net/avrbaudcalc.php
gruß
Graf-von-Socke schrieb:> Jo da es auf der Testplatine drauf ist.
Vorausgesetzt, der µC läuft mit 5V, würde ich wählen:
Low: 0xc7
High: 0xdc
Extended: 0xf9
Achtung: der µC lässt sich dann auch nur noch flashen, wenn der Quarz
auch wirklich angeschlossen ist.
Du kannst Dir die Werte aber auch selbst ausrechnen lassen, siehe
http://www.engbedded.com/fusecalc/
Gruß,
Frank
Danke
nun leuft alles Danke
hatte ein nettes erreignis. Mein Quartz wolte nicht muste erst mit dem
Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten
Kennst du eigendlich den X-PORT
gruß
Graf-von-Socke
Graf-von-Socke schrieb:> nun leuft alles Danke
Prima.
> hatte ein nettes erreignis. Mein Quartz wolte nicht muste erst mit dem> Frequenz Generator einen Beipass legen. Muss bestimmt nachlöten
Deshalb meine obige Warnung :-)
> Kennst du eigendlich den X-PORT
Du meinst den "XPORT Ethernet Wandler Ethernet zu seriell" von
Lantronix?
Gruß,
Frank
Jo
Den meine ich finde den ganz nett aber er ist halt bischen teuer. Aber
was man geschenkt bekommt sagt man nicht nein.
Bin nun dabei eine Schalung zu entwickeln damit jeder PC (auch Handy)
auf den µC zu greifen kann und die Infrarot Befehle absetzen kann.
Der Grund dafür ist meine Frau die findt das die vielen Gräte aus den
Blickfang verschwinden und daher fand ich deinen Ansatz hier sehr
hilfreich.
Gruß
Graf-von-Socke
Hi Frank,
auch hier Bestätigung. Super gemacht; System und Command Byte
funktionieren.
Bist du dir allerdings bei der Customer ID sicher ?
Ich bekomme hier als Ausgabe 0xffef bin mir aber
ziemlich sicher daß die MS ID 0x800F ist.
CU Dirk
Dirk W. schrieb:> auch hier Bestätigung. Super gemacht; System und Command Byte> funktionieren.
Sehr schön, danke für die Rückmeldung :-)
Achja, das MSB der 14 Bits (das ist das MSB des System-Bytes) ignoriere
ich: das scheint nämlich zu togglen - ähnlich dem Toggle-Bit "TR" bei
Mode 0, was dort ziemlich weit vorne direkt hinter den Mode-Bits liegt.
Das ist mir beim XBOX-Scan als auch bei der Kathrein-FB aufgefallen:
Beim Mode 6A wechselt das eigentliche Toggle-Bit nicht, dafür aber das
oberste Bit vom System-Byte.
> Bist du dir allerdings bei der Customer ID sicher ?
Nein, sonst hätte ich ja keine Testversion gemacht ;-)
> Ich bekomme hier als Ausgabe 0xffef bin mir aber> ziemlich sicher daß die MS ID 0x800F ist.
Okay, ich überprüfe das nochmal. Ich stehe echt auf Kriegsfuß mit der
Manchester-Deokodierung. Wenn ein Bit falsch ist, kippen alle Bits
dahinter mit :-(
Die Hölle ist nämlich das "eigentliche" RC6-Toggle-Bit "TR", welches die
doppelte Länge der anderen Bits hat. Da ich mir immer nur Längen
zwischen zwei Flankenwechseln anschaue, macht mir diese wechselnde
Frequenz das Leben schwer, denn es kann da als Länge nicht nur 1-fache
und 2-fache Länge, sondern auch die 1,5-fache Länge auftreten. Ich
vermute mal, dass genau da das Bit kippt - und damit auch die
Custtomer-ID, die danach folgt.
Gruß,
Frank
Neue Version 1.8.0 von IRMP verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download
Änderungen gegenüber 1.7.3:
- Neues Protokoll: RC6A
Damit werden nun die XBOX und auch die Kathrein-FBs unterstützt.
Ebenso ist nun die Version 1.8.0 von IRSND verfügbar, Download unter
http://www.mikrocontroller.net/articles/IRMP#Download_IRSND
Änderungen gegenüber 1.7.3:
- Neues Protokoll: JVC
- Anpassung des APPLE-Encoders an IRMP-Version 1.7.3.
Im IRSND fehlt jetzt nur noch die Unterstützung des
RC6-/RC6A-Protokolls, dann sind beide Software-Module wieder
"symmetrisch". Bin da nun dran.
Die Dokumentation im IRMP-Artikel habe ich angepasst bzw.
erweitert, siehe:
http://www.mikrocontroller.net/articles/IRMP
Viel Spaß,
Frank
wollte nur noch mal danke sagen,
deine Tipps wo ich meinen source anpassen musste waren erfolgreich,
brauchte wirklich nur noch die irmp.c/.h einbinden und die irmpconfig.h
anpassen und es funzt sofort, RC6 hab ich noch nicht testen können, aber
der Rest läuft wie gehabt was ein gutes Zeichen ist......
gruss
jar
eku schrieb:> Ganz toll ,Frank. Nur leider wird irmp_ISR immer länger. Wie steht es> mit den Optmierungen aus> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" ?
Schlecht. Ich hatte mal testweise so eine Version gemacht, wo (nach
Deiner Idee) in einer Schleife über die Protokolle mittels Timingwerten
das richtige Protokoll ermittelt werden sollte. Dabei mussten noch
Pulse-Distance-Protokolle mit Start-Bit von denen ohne Start-Bit (z.B.
Denon) und auch die Manchester-codierten Protokolle extra abgearbeitet
werden. Also gab es schon einmal 3 Schleifen...
Ergebnis:
1. Keine Flash-Speicher-Ersparnis, da die Konstruktion der 3 Schleifen
inkl. zusätzlichen Speicherbedarf der Startbit-Werte für die
einzelnen Protokolle alles wieder auffraß. Am Ende wurde sogar mehr
Flash-Speicher benötigt als vorher.
2. Viel Größere Laufzeiten, da die Pulse-/Pause-Werte nicht mehr mit
Konstanten, sondern mit Variableninhalten abgeglichen werden
mussten. Der Variablenzugriff war wegen Indirektion über
startbitstructarray[idx]->value
nicht gerade effizient.
Kampakter bekommt man den Code wohl nicht, da kann man nur an Feinheiten
tunen. Ab und zu stolpere ich mal über eine Stelle, die optimiere ich
dann "on-the-fly", wenn es ohne größeren Aufwand geht.
Ich erwähnte damals zwar, dass man die linearen Vergleiche, die
unmittelbar nach Eintreffen des Startbits auftreteten, noch optimieren
könnte. Das würde aber auch keine Verkleinerung des Codes verursachen,
eher eine (leichte) Vergrößerung. Lediglich die "Suche" nach dem
richtigen Protokoll ginge dann etwas schneller. Die Arbeit habe ich mir
aber noch nicht gemacht, da hier der Gewinn bei 20 Protokollen eher
marginal ist. Bei 1000 Protokollen wäre das was anderes ;-)
Mein Fazit:
Wenn Dir der Code zu groß ist, schalte die nicht benötigten Protokolle
ab. Dann wirst Du sehen, dass IRMP selbst eigentlich nicht größer ist
als vorher. Ein neues Protokoll im IRMP verursacht im allgemeinen keine
Vergrößerung des Codes - solange man es ausgeschaltet(!) lässt ;-)
Wenn jemand ein neu implementiertes Protokoll tatsächlich nutzen will,
kann er schlecht erwarten, dass der Code gleich groß bleibt.
Gruß,
Frank
Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste
:-)
In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber
eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn
man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?
Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine
Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert
denn da?
Viele Grüße,
Simon
Simon Budig schrieb:> Frank, vielen Dank für IRMP, das leistet bei mir gerade gute Dienste> :-)
Freut mich :-)
> In irmpconfig.h steht als Maximum für F_INTERRUPTS 15000 - das ist aber> eher ein veralteter Wert, oder? Oder muss man was spezielles tun, wenn> man darüber hinausgeht (Manche Protokolle verlangen ja 20kHz)?
Ja, es sind auch 20kHz möglich, habe ich vergessen, das zu
aktualisieren. Allerdings wird dann etwas mehr Speicherplatz benötigt,
da dann einige Variablen vom Typ her automatisch über den Preprocessor
von uint8_t auf uint16_t wechseln. Auch wird mehr CPU-Zeit verbraten.
RECS80, das einzige Protokoll, welches 20kHz erfordert, ist auch noch
nicht in der Praxis getestet worden.
> Ich habe übrigens beobachtet, dass bei F_INTERRUPTS=16000 eine> Verringerung der Codegröße eintritt (um ca. 130-135 Bytes). Was passiert> denn da?
Du meinst bei Erhöhung auf 16000? Müsste dann eigentlich größer werden,
siehe oben.
Gruß,
Frank
Simon Budig schrieb:> Mhm. Ich habe mir gerade mal den Assembler angeguckt. Offensichtlich> verschwindet bei F_INTERRUPTS = 16000 die gesamte if-Abfrage bei Zeile> 2020 (if (irmp_pause_time > IRMP_TIMEOUT_LEN)) in irmp.c, anscheinend> beschließt der Compiler, dass das nicht eintreffen kann und schmeißt den> Code weg.
Das darf nicht sein, eigentlich wird ab ca. 16000 Hz IRMP_TIMEOUT_LEN
größer als 255 und deshalb auch irmp_pause_time dann vom Typ uint16_t.
Das scheint aber nicht zu funktionieren. Kein Wunder, dass der Compiler
dann das if-Statement wegwirft. Ich werde das überprüfen.
Danke für den Tipp und Deine "Messungen" :-)
Gruß,
Frank
Frank M. schrieb:> Fehler gefunden, es ist eine Änderung in irmp.c notwendig.> Werde ich noch am Wochenende im Paket ändern.
[x] Done
Download-Version ist nun 1.8.1.
Gruß,
Frank
der Bug bei U2X ist leider immer noch da, habe wie gesagt nur irmp.c/h
eingebunden, meine main und die irmpconfig geändert sowie logging on und
defines fürs steckbrett, , muss am verwendeten m644 liegen, ich weiss
nur nicht wann und warum dieser U2X Fehler im irmp-uart kommt, wenn ich
das einfach auskommentier gehts ja, aber der code sollte ja so laufen
Fehlermeldung:
../irmp.c:593:26: error: util/setbaud.h: No such file or directory
finde ich auch in meinem winAVR nicht
als helfende krücke noch
#if IRMP_LOGGING != 0 // 1: log IR signal (scan), 0: do not
(default)
uart_init(UART_BAUD_SELECT(9600,F_CPU));
#endif
mit uart.c/h eingebunden Peter Fleury
modified by Patrick Kaplan for ATMega644 usage
und uart_init aufruf statt irmp-uart_init
Joachim B. schrieb:> Fehlermeldung:> ../irmp.c:593:26: error: util/setbaud.h: No such file or directory
Meines liegt unter
C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h
und ist Bestand der avr-libc.
Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version -
damit meine ich jetzt nicht die WinAVR-Version, sondern Deine
avr-gcc-Version.
> finde ich auch in meinem winAVR nicht
Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.
> so gehts, nur warum
Weil genau die U2X-Geschichte in setbaud.h definiert wird.
Gruß,
Frank
Frank M. schrieb:> Meines liegt unter> C:\Programme\WinAVR-20100110\avr\include\util\setbaud.h> und ist Bestand der avr-libc.> Wo liegt Dein avr\include-Verzeichnis? Überprüfe mal Deine Version -> damit meine ich jetzt nicht die WinAVR-Version, sondern Deine> avr-gcc-Version.>> finde ich auch in meinem winAVR nicht> Dann fehlt da was bei Dir. setbaud.h gibt es schon länger.
setbaud.h fehlt, ergo muss bei meiner letzten Installation was schief
gelaufen sein
1
VerzeichnisvonC:\Programme\atmel
2
3
10.12.200801:11<DIR>.
4
10.12.200801:11<DIR>..
5
07.01.201021:50<DIR>AVRTools
6
17.03.200820:32<DIR>BASCOM-AVR
7
02.09.200814:23432.040CodeCompareSetup.exe
8
25.11.200801:00<DIR>Grafikkonverter
9
07.03.200821:01<DIR>PonyProg2000
10
04.03.200820:25<DIR>WinAVR
komisch nur das alle meine anderen Projekte laufen, also habe ich nie
was vermisst
was muss ich also noch wie einbinden ?
vielen Dank
Joachim B. schrieb:> bin leider noch nicht weiter, so siehts aus:> ../irmp.c: In function 'irmp_uart_init':> ../irmp.c:657: error: 'U2X' undeclared (first use in this function)
Du hast offenbar nicht die aktuelle IRMP-Version vom 04.09.2010. Da wird
für bestimmte µCs U2X als U2X0 definiert.
Gruß,
Frank
stimmt da war ich unterwegs, habs also nicht mitbekommen
so geladen, eingespielt, aber immer noch Probleme...
ich glaub ich lasse meine Einbindung von P.Fleury UART.C/H damit klappts
ja
DAANNKEEE
Hey,
super geile Sache.
Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay
Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.
Ahhh noch was vergessen,
meine beiden Fernbedienungen (sind verschiedene) der Marke Smart
Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.
Fabi S schrieb:> Wollt nur kurz mitteilen das meine LG Fernbedienung vom TV und BluRay> Player mit dem Samsung(32) Protokoll einwandfrei funktionieren.
Freut mich.
> meine beiden Fernbedienungen (sind verschiedene) der Marke Smart> Electronics (Receiver usw.) funktionieren mit dem NEC Protokoll.
Aber sie werden unterschiedliche Adressen haben, oder?
Gruß,
Frank
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?
Dominique Görsch schrieb:> Super, dass du es gleich implementieren willst. Reichen dir die Infos> aus dem Paper oder kann ich dir noch anderweitig (zB mit Scans) helfen?
Es wäre natürlich nett, wenn Du auch ein paar Scans machen könntest.
Graue Theorie ist die eine Geschichte, Praxis oft eine andere :-)
Gruß,
Frank
Kein Problem, werde ich machen. Muss deinen Code dafür nur etwas
umstricken weil ich in meiner Firmware sowieso UART mit 250kBaud (USB)
drin hab. Wird heute aber wohl eher nixmehr...
Dominique Görsch schrieb:> 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.
Im SVN ist nun ein IRMP/IRSND mit dem LEGO-Protokoll zu finden.
Maßgeblich sind in irmp_data.command die unteren 12 Bits, die je nach
Inhalt von der Anwendung zu prüfen sind - anlehnend an die
LEGO-Dokumentation. irmp_data.address ist immer 0.
IRMP liest die 16 Bits des LEGO-Telegramm ein und checkt das letzte
Nibble im XOR-Verfahren gegen die anderen 3 Nibbles. Kommt der richtige
Wert raus, gibt IRMP die 12 Bit an Nutzdaten zurück.
Umgekehrt kann man die 12 Bits an IRSND in irmp_data.command übergeben.
IRSND "konstruiert" daraus das fehlende letzte Nibble und schickt
anschließend den kompletten Frame mit 16 Bit raus.
Als letzte Info: Man braucht eine Interrupt-Frequenz von 20kHz, da die
Pulse ziemlich kurz sind. Wenn Du noch Scans machen möchtest, dann bitte
mit 20kHz.
Ich hoffe, ich habe keinen Fehler gemacht, bitte testen.
Gruß,
Frank
Torsten K. schrieb:> wie ist es denn mit der Unterstützung für die kleine Pollin Tasttatur> "Merlin" ?> Hast Du da schon was erreichen können ?
Nein, noch nicht. Da werde ich wohl vor dem nächsten Wochenende nicht zu
kommen. Wenn Du mir helfen willst, kannst Du gern vorabe schon mal ein
paar Scans mit IRMP machen. Das würde mir eine Menge Arbeit abnehmen.
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.>> Gruß,>> Frank
läuft prima, erstzt nun den dani code und mein Timer kann immer mehr,
nicht nur timen, sondern auch FB testen :-)
an Frank (ukw)
habe eine FB die IRMP nicht erkennt
daewoo Videorecorder V-737
die FB ist defekt, nur noch 3/4 ? Tasten funktionieren IR Led leuchtet
output_2011-04-15_09-02-22.log
Tasten PROG, <- , -INDEX
habe eine Nachbau FB bestellt
1 90 11 54 22 daewoo 97p1r2taa0 DAEWOO 97P1RA1AA0
die sendet auf den Tasten (PROG Taste nicht gefunden)
Tasten <- , -INDEX
output_2011-04-15_09-05-56.log
kannst du den Code erkennen ?
kannst du die "gleichen" Codes ? vergleichen ?
und evt. sagen um was für einen Code es sich handelt ?
#define F_INTERRUPTS 17857
#define F_CPU 8000000
wenn nötig, mehr Codes aus der Ersatz FB
Hi Joachim,
Joachim B. schrieb:> an Frank (ukw)>> habe eine FB die IRMP nicht erkennt
Doch, wird erkannt. Das ist das NEC16-Protokoll (eine verkürzte Variante
des 32-Bit-NEC-Protokolls, dafür aber mit Sync-Bit nach den 8
Adressbits).
Protokoll: 27
Adresse: 0x0015
Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des
SVN.
Gruß,
Frank
Frank M. schrieb:> Habe ich erst vor ein paar Wochen eingebaut, findest Du im Download des> SVN.>> Gruß,>> Frank
hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme
?
manche Codes brauchen doch sogar 20000 ! OK mit 15500 gehts aber wenn
20000 geht sollte 17857 nicht meckern
../irmp.c:1106: warning: integer overflow in expression
../irmp.c:1107: warning: integer overflow in expression
../irmp.c:1108: warning: integer overflow in expression
../irmp.c:1109: warning: integer overflow in expression
../irmp.c:1157: warning: integer overflow in expression
../irmp.c:1158: warning: integer overflow in expression
../irmp.c:1159: warning: integer overflow in expression
../irmp.c:1160: warning: integer overflow in expression
../irmp.c:1260: warning: integer overflow in expression
../irmp.c:1261: warning: integer overflow in expression
../irmp.c:1262: warning: integer overflow in expression
../irmp.c:1263: warning: integer overflow in expression
../irmp.c: In function 'irmp_ISR':
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2033: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2035: warning: integer overflow in expression
../irmp.c:2079: warning: integer overflow in expression
../irmp.c:2080: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2184: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression
../irmp.c:2186: warning: integer overflow in expression
Joachim B. schrieb:> hast du ne Idee warum ich bei F_INTERRUPTS 17857 -> 25 warnings bekomme> ?
Habs mir gerade angeschaut, das hat was mit einer kürzlich von mir
geänderten Behandlung der 2-fachen Längen von Pulsen/Pausen im
Manchester-Decoder zu tun. Ich wollte da Code einsparen, hab aber nicht
bedacht, dass da Variablen "platzen" könnten. Ich repariere das am
Wochenende. Entweder Du gehst auf 15kHz runter oder Du verzichtest
erstmal auf RC5 und Co.
Gruß,
Frank
Frank M. schrieb:> Ich repariere das am> Wochenende.
fein, gib dann mal Bescheid, dann lade ich die reparierte
hast du schon die 8-bit Timer0 Variante eingebaut ?
Joachim B. schrieb:> hast du schon die 8-bit Timer0 Variante eingebaut ?
Nein, habe ich noch nicht. Bei der 16-Bit-Timer-Variante werden die
Werte für die Timer-Register über eine Formel, die lediglich von F_CPU
und F_INTERRUPTS abhängig sind, automatisch initialisiert. Da muss man
nichts anpassen.
Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann
die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht
so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und
her, wie ich das am besten allgemeingültig in den Code einbaue.
Frank M. schrieb:> Bei Deiner Timer0-Variante muss man eine Tabelle heranziehen und dann> die Werte abtippen und damit den eigentlichen Code ändern. Das ist nicht> so schön, geht aber wohl nicht anders. Deshalb überlege ich noch hin und> her, wie ich das am besten allgemeingültig in den Code einbaue.
ich weiss
lauter #if F_CPU == && F_INTRRUPTS ==
ist auch keine Lösung
schade das der Precompiler nicht rechnen kann
die Teilerstufen sind auch nicht linear 2^n
wegen 0 8 64 256 1024 gibt 2^0 2^3 2^6 2^8 2^10
kleiner 6 step 3
else step 2
eine Tabelle einfügen ?
Hallo Frank,
erst mal ein großes Lob, Dein IRMP ist große Klasse!
Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu
basteln, die mit einem 5" Touch etwa so viel kann wie die Philips
Pronto.
Leider hat Philips die Herstellung dieser genialen Fernbedienungen
eingestellt und es gibt keinen Hersteller, der etwas vergleichbares
anbieten kann, zumindest nicht unter 1400€.
Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und
IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen
gebracht.
Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP
nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen
älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die
Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der
Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur
Modulationsfrequenz, sollte aber trotzdem noch gehen.
Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?
Es wäre schön, wenn man das Protokoll noch implementieren könnte.
Gruß
Cajus
Hoppla, irgendwie ist mein Dateianhang doppelt vorhanden!?
Weis jemand wie man Dateianhänge wieder löschen kann?
Cajus H. schrieb:> erst mal ein großes Lob, Dein IRMP ist große Klasse!
Danke :-)
> Ich spiele mit dem Gedanken mir eine programmierbare Fernbedienung zu> basteln, die mit einem 5" Touch etwa so viel kann wie die Philips> Pronto.
Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine
programmierbare FB handelt, bei dem das Tastenlayout auf dem Display
frei wählbar ist?
Vielleicht schaust Du Dir dazu mal
http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP
an. Diese kann die Codes lernen und im EEPROM abespeichern. Ich weiß,
hier gibt es zwar nur 5 Tasten, aber vielleicht kannst Du da was von
übernehmen oder zumindest die eine oder andere Anregung erhalten :-)
> Ich habe also alle 20 Originalfernbedienungen aus dem Keller geholt und> IRMP mit allen Protokollen (ausser Lego) auf meinem ATmega32 zum Laufen> gebracht.
Super!
> Dabei bin ich auf eine Fernbedienung gestossen, die scheinbar von IRMP> nicht erkannt wird. Es handelt sich um eine Fernbedienung für einen> älteren Thomson TV, die Fernbedienung nennt sich "mb100". Die> Modulationsfrequenz ist ca. 33kHz (mit dem Oszi nachgemessen), der> Empfänger ist ein TSOP1738 (38kHz), also passt nicht ganz zur> Modulationsfrequenz, sollte aber trotzdem noch gehen.>> Könntest Du mal schauen, ob Du mit den Scans etwas anfangen kannst?> Es wäre schön, wenn man das Protokoll noch implementieren könnte.
Habs mir gerade mal kurz mit "irmp-15kHz -a" unter Linux angeschaut. Das
Protokoll ist sehr einfach gehalten:
- Jeder Frame wird 2 mal wiederholt (also insgesamt 3 Frames)
- Kein Startbit
- Framelänge 12 Bit
- Pulslänge: 550 µs
- Pausen: 1990 µs oder 4523µs
Ich schaue mal, ob ich das morgen früh mal einbaue, sollte nicht
schwierig sein. Dank der Fülle Deiner Scans sollte ich auch noch
herausbekommen, wieviele Bits zur Adresse und wieviele zum Kommando
gehören.
Eine Frage hätte ich noch: Hast Du die Tasten kurz gedrückt oder länger?
Die 2 Wiederholungen eines jeden Frames sind etwas untypisch. Eventuell
müsstest Du das nochmal testen, sobald IRMP das Thomson-Protokoll
"versteht". Nicht dass zumindest der 3. Frame eine Wiederholung ist, die
durch langes Drücken einer Taste zustandekam...
Gruß,
Frank
Mich hat es doch in den Fingern gejuckt und ich habe gerade mal das
Thomson-Protokoll in den IRMP eingebaut. Da es so einfach ist, hat es
gerade mal 20 Minuten gebraucht :-)
Neue Erkenntnisse:
- Der Frame setzt sich aus einer 4-Bit-Adresse und 8-Bit Daten zusammen
- MSB oder LSB first ist noch unbekannt, lässt sich leider nicht aus den
Tasten 0 bis 9 erkennen
- Frame-Wiederholungen werden im Moment noch als Tasten-Wiederholungen
(flag = 0x01) erkannt. Das muss noch angepasst werden, sobald klar
ist, wieviele Frames bei kurzem! Tastendruck erzeugt werden
@Cajus H. (cajush):
Teste das bitte mal. Gemeinsam sollten wir das dann hinbekommen.
Im Anhang findest Du die gegenüber dem SVN geänderten Sources.
Achja: Da kommt im Moment noch eine Compiler-Warnung, die Du ignorieren
kannst... ist halt noch ein Prototyp.
Gruß,
Frank
Hallo Frank,
>> Philips Pronto...> Das sagt mir jetzt nichts, aber ich vermute, dass es sich um eine> programmierbare FB handelt, bei dem das Tastenlayout auf dem Display> frei wählbar ist?
Ja genau und zwar WIRKLICH frei wählbar mit Tastenform, Tastengröße,
Anordnung der Tasten, beliebige Macros und vielem mehr. Es gab eine
Variante mit Graustufen-Touch und eine Variante mit Farb-Touch, ich habe
eine ältere Graustufen-Variante mit relativ kleinem Touch. Im Anhang
sind ein paar Seiten meiner Pronto.
Als Basis für eine Touch-FB habe ich dieses Modul im Auge
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=459
, erweitert um einen ATmega mit IRSND.
> Thomson Protokoll...
Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und
lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR
kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.
Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog
zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob
kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen
Tasten.
Ich habe Dir außerdem mal meine Source-Dateien angehängt.
Darin sind ein paar kleine Änderungen:
- Versionsnummer aktualisiert (sollte man eigentlich besser in einer
Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul
;-)
- printf-Unterstützung auch für gcc (war nur für CODEVISION drin)
- Namen der Protokolle erweitert
Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
Ich habe mal angefangen die Codes meiner FBs in eine Tabelle zu packen,
aber vielleicht gibt es schon eine vergleichbare Sammlung. Ich habe den
aktuellen Stand der Liste auch mal angehängt, es fehlen noch einige FBs.
Eigentlich eine Anwendung für eine Datenbank...
Gruß
Cajus
Hallo Frank,
hier noch einmal meine modifizierten IRMP Sourcen, bei den obigen hatte
sich ein Fehler eingeschlichen, der das Übersetzen mit IRMP_LOGGING = 0
verhinderte. Das resultierte daher, weil ich Deine Uart-Initialisierung
nach main() kopiert hatte, die Definition der Register aber nur bei
IRMP_LOGGING = 1 gemacht wird. Daher habe ich diese Definitionen nach
irmp.h verlegt.
Ich habe die Version nach irmp.h verschoben und gebe bei printf nur noch
%s aus.
In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch
schon in der letzten Version meiner Sourcen behoben hatte: irmp.c
vor
static PROGMEM IRMP_PARAMETER thomson_param =
steht
#if IRMP_SUPPORT_DENON_PROTOCOL == 1
das sollte vermutlich
#if IRMP_SUPPORT_THOMSON_PROTOCOL == 1
heissen, oder?
Gruß
Cajus
Hallo Frank,
hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger
gedauert.
Gemacht mit F_INTERRUPTS 20000.
Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.
Gruß
Torsten
Cajus H. schrieb:>> Thomson Protokoll...> Ich habe eine Scan-Datei in den Anhang gepackt, bei der ich kurze und> lange Tastendrücke dokumentiert habe. Der kurze Tastendruck ist SEHR> kurz, normalerweise kommen zwei Ausgaben mit Code,Address und Command.> Man kann ausserdem erkennen, dass das letzte Bit ein Toggle-Bit (analog> zum RC5 von Philips) ist. Das Bit togglet bei jedem Tastendruck, egal ob> kurz oder lang. Es togglet auch beim Drücken von unterschiedlichen> Tasten.
Sehr gut. Bei kurzen Tastendrücken gibt es nur einen einzigen Frame. Das
macht die Sache leichter. Danke für den Tipp mit dem Toggle-Bit. IRMP
blendet das nun aus. Damit konnte ich dann sehen, dass die
Bit-Reihenfolge MSB-First ist, denn die untereinander liegenden Tasten
0,4,7 / 2,5,8 / 3,6,9 haben damit eine aufsteigende Reihenfolge. Das
ergibt folgende Codeänderungen:
> Ich habe Dir außerdem mal meine Source-Dateien angehängt.> Darin sind ein paar kleine Änderungen:> - Versionsnummer aktualisiert (sollte man eigentlich besser in einer> Header-Datei festlegen als in der printf-Ausgabe, ich war aber zu faul> ;-)
Die Versionsnummer, die im Codevision-Teil steht, habe ich nie gepflegt.
Ich überlege mittlerweile auch, die Codevision-Unterstützung komplett
rauszuwerfen, da ich diese mangels Codevision-Compiler sowieso nicht
unterstützen kann. Das würde den Code etwas übersichtlicher machen -
zumindest in main.c.
> - printf-Unterstützung auch für gcc (war nur für CODEVISION drin)
Schaue ich mir mal an. Eigentlich hat das aber nichts im IRMP zu suchen.
Die main.c ist eigentlich nur ein Beispiel-Code und nicht wirklich
Bestandteil des IRMP.
> - Namen der Protokolle erweitert
Ja, eben, das wurde nicht gepflegt. Eigentlich will ich das auch gar
nicht ;-)
> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?
Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu
machen, weiß ich nicht.
Cajus H. schrieb:> In Deinem Code war auch noch ein kleiner Fehler, den ich allerdings auch> schon in der letzten Version meiner Sourcen behoben hatte: irmp.c>> vor> static PROGMEM IRMP_PARAMETER thomson_param => steht> #if IRMP_SUPPORT_DENON_PROTOCOL == 1> das sollte vermutlich> #if IRMP_SUPPORT_THOMSON_PROTOCOL == 1> heissen, oder?
Ja, danke, das war ein Copy&Paste-Fehler.
Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN
einchecken.
Gruß,
Frank
Torsten K. schrieb:> hier sind ein paar Scans der Pollin Merlin Tastatur, hat etwas länger> gedauert.
Vielen Dank. Auf den ersten Blick ist das ein Bitserielles Protokoll -
analog zur Netbox. Also weder Manchester noch Pulse-Distance, wie es bei
Fernbedienungen üblich ist. Ich schaue mal, dass ich da einen ersten
Prototyp im Laufe der kommenden Woche baue.
> Wenn Du noch mehr brauchst, oder bei Fragen, sag bescheid.
Danke, ich melde mich dann :-)
Gruß,
Frank
Frank M. schrieb:>> Gibt es eigentlich irgendwo eine Sammlung mit Scancodes?>> Es gibt das LIRC-Projekt. Ob es sinnvoll ist, für IRMP auch so etwas zu> machen, weiß ich nicht.
fände ich sinnvoll, wenn z.B. eine FB kaputt geht kann man nix machen,
würde man die Codes finden könnte man eine FB nachprogrammieren und sei
es wenn man IRSND nur dazu benutzt eine lernfähige anzulernen, ich
musste für Vaters VCR FB die teure Nachbau FB bestellen, hätte ich die
Codes gefunden, genügte IRSND + eine billige Lern FB
@frank (ukw)
gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?
ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt,
Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu
einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste
irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie
ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich
bekomme 2 steps zum einstellen, mit toogle bit wärs leichter
danke
gruss
jar
Joachim B. schrieb:> gibt es die Möglichkeit das RC5 toogle Bit wieder einzufügen ?
Ich sehe dafür eigentlich keine Notwendigkeit. IRMP ignoriert das
Toggle-Bit, weil es meines Erachtens überflüssig ist. Zum "Entprellen"
der Tastatur stellt IRMP andere (kompatible) Methoden zur Verfügung,
s.u.
> ich hatte ja vorher den dani RC5 Code drin und nun auf IRMP umgestellt,> Address und Data konnte ich kompatibel erstellen, aber mir fehlt zu> einfachen Auswertung das toogle Bit für gleiche Taste oder neue Taste
Das ist einfach: IRMP setzt in flags das BIT IRMP_FLAG_REPETITION, wenn
eine Wiederholung durch langen Tastendruck entsteht, siehe auch
IRMP-Artikel.
Einfache Abfrage:
1
if(irmp_data.flags&IRMP_FLAG_REPETITION)
2
{
3
// Benutzer hält die Taste länger runter
4
// entweder:
5
// ich ignoriere die (Wiederholungs-)Taste
6
// oder:
7
// ich benutze diese Info, um einen Repeat-Effekt zu nutzen
8
}
9
else
10
{
11
// Es handelt sich um eine neue Taste
12
}
So ist das für alle von IRMP unterstützten Protokolle kompatibel gelöst
- egal, ob das Protokoll ein Toggle-Bit bereitstellt oder nicht.
> irgendwie schaffe ich es nicht nur 1 Tastendruck auszuwerten, egal wie> ich drücke entweder wird nix erkannt, zu kurz, oder zu lang und ich> bekomme 2 steps zum einstellen, mit toogle bit wärs leichter
Ignoriere einfach alle Frames, wo das Bit IRMP_FLAG_REPETITION gesetzt
ist.
Also in Deinem Fall:
1
if(!(irmp_data.flags&IRMP_FLAG_REPETITION))
2
{
3
// Es handelt sich um eine neue Taste
4
// ACTION!
5
}
Und schon hast Du Deine FB-Tasten "entprellt" ;-)
Gruß,
Frank
Frank M. schrieb:> Also in Deinem Fall:> if (! (irmp_data.flags & IRMP_FLAG_REPETITION))> {> // Es handelt sich um eine neue Taste> // ACTION!> }>> Und schon hast Du Deine FB-Tasten "entprellt" ;-)>> Gruß,>> Frank
funzt, nur natürlich kein repeat mehr.....
ich muss mal sehen evt. muss ich aus diesen Infos das toogle Bit
nachbauen
oder ich blicke noch nicht durch wie ich kurz und lang auswerten kann
ohne delay !
ich weiss die Lösung hast du schon beschrieben, nur muss ich das in
meinen Code pressen, oder meinen code neu schreiben, mal sehen
danke
jar
Joachim B. schrieb:> funzt, nur natürlich kein repeat mehr.....
Wie hast Du denn mit dem Toggle-Bit das Repeat gemacht? Wenn das
Toggle-Bit sich nicht(!) ändert, dann Repeat wegen langem Tastendruck?
Das entspricht doch dem Fall, dass das IRMP-Flag gesetzt ist.
Brauchst Du für jede Taste ein Repeat? Oder nur für bestimmte?
> ich weiss die Lösung hast du schon beschrieben, nur muss ich das in> meinen Code pressen, oder meinen code neu schreiben, mal sehen
Vielleicht zeigst Du mal einen Auszug aus Deinem Code?
Gruß,
Frank
Hallo Frank,
>> Thomson Protokoll...> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN> einchecken.
Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)
Nachdem ich die Fernbedienungen aller z.Zt. in Gebrauch befindlichen
Geräte mit IRMP einlesen konnte stehe ich nun vor der Aufgabe IRSND in
Betrieb zu nehmen. Der aktuelle Code aus dem SVN funktionierte auf
Anhieb, zumindest kam ein IR-Signal im 1 sec. Rythmus. Wie ich oben
schon erwähnt habe, möchte ich eine Programmierbare FB mit Touch-Screen
bauen. Die Touch-Software erkennt einen Tastendruck und sendet einen
"Taste Gedrückt" Event an IRSND, zusammen mit dem Wert für Protokoll,
Adresse und Komando. Wird der Finger vom Touch genommen kommt der "Taste
Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende
Kommando senden.
Frage: Wie lässt sich das mit IRSND realisieren?
Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event
dürfte nicht funktionieren. Ich habe Funktionen, die unterschiedlich auf
lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen:
Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer
Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h.
neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der
gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer
als neuen Tastendruck. Würde ich also den Befehl "Licht ein/heller" so
lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde
jede Wiederholung mit invertiertem Toggle Bit ausgesendet. Dies würde
vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem
Tastendruck nicht die Funktion Dimmen, sondern nur
ein-aus-ein-aus-ein-aus erkannt wird.
Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das
unterstützen?
Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl
der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment,
in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten
bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".
Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND
einbauen?
Gruß
Cajus
Hallo Cajus,
Cajus H. schrieb:>> Ich werde meine Änderungen bzgl. Thomson-Protkoll morgen mal ins SVN>> einchecken.> Kann es sein, dass Du noch nicht dazu gekommen bist? ;-)
Upps, habe ich das tatäschlich vergessen? Naja, bis auf die 3 defines
habe ich da nichts großartiges geändert. Okay, werde ich nachholen.
> [...] Wird der Finger vom Touch genommen kommt der "Taste> Losgelassen" Event. In der Zwischenzeit sollte IRSND das entsprechende> Kommando senden.>> Frage: Wie lässt sich das mit IRSND realisieren?
Gute Frage. Ich würde auf den ersten Blick sagen, dass Du, bis das
Loslassen-Event kommt, immer wieder irsnd_send_data() aufrufst.
> Ein einfaches Wiederholen des Komandos bis zum Taste Losgelassen Event> dürfte nicht funktionieren.
Warum nicht? Wenn das Problem lediglich das Toggle-Bit ist, werden wir
das auch lösen können. Ich habe da auch schon eine Idee, siehe weiter
unten.
> Ich habe Funktionen, die unterschiedlich auf> lange und kurze Tastendrücke reagieren. Beispiel Licht Schalten/Dimmen:> Ein kurzer Tastendruck schaltet das Licht ein/aus, ein langer> Tastendruck dimmt heller/dunkler. Hier wird RC5 Code verwendet, d.h.> neben der "gedrückt-Zeit" das Togglebit wird mit ausgewertet. Wird der> gleiche Code mit anderem Toggle-Bit empfangen, so wertet das der Dimmer> als neuen Tastendruck.
Wenn ich es recht in Erinnerung habe, toggelt IRSND das Toggle-Bit nicht
in Wiederholungen, die durch den flags-Wert angegeben ist, sondern nur
bei erneutem Aufruf von irsnd_send_data(). So sollte es jedenfalls
sein... und so brauchst Du das ja prinzipiell auch.
> Würde ich also den Befehl "Licht ein/heller" so> lange wiederholen, bis der Taste Losgelassen Event eintrifft, dann würde> jede Wiederholung mit invertiertem Toggle Bit ausgesendet.
Korrekt.
> Dies würde> vom Dimmer aber als neuer Tastendruck gewertet, wodurch bei einem langem> Tastendruck nicht die Funktion Dimmen, sondern nur> ein-aus-ein-aus-ein-aus erkannt wird.
Okay, habe ich verstanden. Ist das Dein eigens entwickelter Dimmer?
Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible
Geschichte, wenn man an andere IR-Protokolle denkt ;-)
> Berücksichtigt IRSND eigentlich das Toggle-Bit bei Codes, die das> unterstützen?
Ja, sollte IRSND berücksichtigen. Bei jedem erneuten Aufruf von
irsnd_send_data() wird getogglet, innerhalb der flags-Wiederholungen
nicht.
> Ich habe gesehen, IRSND hat den Parameter flags, mit dem man die Anzahl> der Wiederholungen vorgeben kann. Das Problem dabei ist, in dem Moment,> in dem die Taste gedrückt wird, weis ich noch nicht wie lange sie unten> bleibt! Man bräuchte daher ein flag "sende bis auf Widerruf".
Ja, genau DAS ist das Problem, was ich bei meiner lernfähigen FB, die
mein Sohn und ich im gesonderten Artikel vorgestellt hatten, auch hatte.
Deshalb rufe ich irsnd_send_data() in einer Schleife mit flags = 0 auf,
wenn ich Wiederholungen senden möchte (Code dazu s. ganz unten). Da wird
aber das Toggle-Bit immer wieder geändert... nicht schön.
Ich hätte folgenden Vorschlag zur Änderung der Software:
1. Die Anzahl der Wiederholungen werden im unteren Nibble von
flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.
Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...
siehe Punkt 2.
Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.
2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos
wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann
natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.
3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden
von Wiederholungen nach Abschluss des aktuell gesendeten Frames
unterbindet. Damit kann man dann das endlose Senden dann wieder
stoppen.
Fürs API würde ich folgende 4 Konstanten vorsehen:
#define IRSND_NO_REPETITIONS 0 // no repetitions
#define IRSND_MAX_REPETITIONS 14 // max # of repetitions
#define IRSND_ENDLESS_REPETITION 15 // endless repetions
#define IRSND_REPETITION_MASK 0x0F // lower nibble of flags
Du könntest dann beim "Taste Gedrückt" Event die Funktion
irsnd_send_data() mit flags = IRSND_ENDLESS_REPETITION aufrufen. Sobald
Deine Software das "Taste Losgelassen" Event schickt, rufst Du
irsnd_stop() auf.
Wäre Dir damit geholfen?
> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND> einbauen?
Ja, kann ich machen. Ich komme zu all diesen Änderungen aber frühestens
am Sontagabend (spät!).
Gruß,
Frank
P.S.
IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch
noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die
Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man
irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird
das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man
direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.
Ich habe das in der DIY-FB erstmal als Hack folgendermaßen gelöst:
1
while(cnt>0)// send cnt frames
2
{
3
irsnd_send_data(&(irmp_data[k]),TRUE);// send IR code now
4
5
while(irsnd_is_busy())// HACK: wait until IRSND is ready
6
{
7
;
8
}
9
10
_delay_ms(50);// wait 50 msec to force a pause between frames
11
cnt--;
12
};
Ich weiß, das ist unschön. Deshalb werde ich den Bug in IRSND
schnellstmöglich fixen.
Hallo Frank,
> Ist das Dein eigens entwickelter Dimmer?
Ja
> Sowas am Toggle-Bit festzumachen, ist eine höchst inkompatible> Geschichte, wenn man an andere IR-Protokolle denkt ;-)
Dem will ich nicht widersprechen, aber die Abhängigkeit vom Toggle-Bit
ist nicht auf meinem Mist gewachsen. Ich habe bei diversen alten Philips
TV Geräten und anderen mit RC5 arbeitenden FBs eine ähnliches Verhalten
festgestellt: Lautstärke + gedrückt halten hat nur funktioniert, wenn
sich das Toggle Bit NICHT geändert hat.
> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von> flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.> Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...> siehe Punkt 2.>> Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.
OK. Ich hoffe es schreit dann keiner "Ich brauche aber 20
Wiederholungen!"
> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos> wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann> natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.
Gut. Vielleicht sollte man eine "Notabschaltung" nach einigen Sekunden
vorsehen (per #define sollte reichen), sonst ist bei batteriebetriebenen
Geräten und einem verloren gegangenen Loslass-Event jedes mal die
Batterie alle ;-). So etwas kann man auch in main() realisieren, dann
bläht das nicht die Interrupt Routine auf.
> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden> von Wiederholungen nach Abschluss des aktuell gesendeten Frames> unterbindet. Damit kann man dann das endlose Senden dann wieder> stoppen.
Perfekt!
> Wäre Dir damit geholfen?
Sehr!
>> Und noch eine Bitte: Könntest Du das neue Thomson Protokoll in IRSND>> einbauen?> Ja, kann ich machen.
Danke!
Bitte im Thomson Protokoll auch das Toggle-Bit berücksichtigen!
> IRSND hat im Moment auch noch einen unschönen Bug...> Nach Aussenden des gewünschten Frames wird die Pause-Zeit zum> nächsten Frame nicht eingehalten...
Danke für den Hinweis. Ich sehe das aber nicht als so schlimm an, das
kann ruhig in main() erledigt werden. Schreib doch einfach den Hinweis
und den Code in irsndmain.c. Ich halte das für völlig ausreichend.
Gruß
Cajus
Frank M. schrieb:> Ich hätte folgenden Vorschlag zur Änderung der Software:>> 1. Die Anzahl der Wiederholungen werden im unteren Nibble von> flags abgelegt, es sind dann nur noch Werte von 0 bis 15 möglich.> Mehr als 15 Wiederholungen (in einem Satz) braucht keiner, außer...> siehe Punkt 2.>> Damit gewinne ich 4 Bit, die ich zukünftig als flags gebrauchen kann.
Die Änderung ist nun im SVN.
> 2. Der Wert flags = 15 führt dazu, dass IRSND die Frames endlos> wiederholt, also bis in alle Ewigkeit sendet. Hier würde dann> natürlich ein Toggle-Bit nicht geändert werden - wie jetzt auch.
Bei flags == IRSND_ENDLESS_REPETITION wird der erzeugte Frame endlos
geschickt. Nein, stimmt nicht ganz: Nach max. 256 Frames wird aufgehört,
um die Batterie nicht komplett leerzulutschen :-)
Auch diese Änderung ist im SVN.
> 3. Es gibt eine neue Funktion irsnd_stop(), welche das weitere Senden> von Wiederholungen nach Abschluss des aktuell gesendeten Frames> unterbindet. Damit kann man dann das endlose Senden dann wieder> stoppen.
Ist nun auch im SVN.
> Fürs API würde ich folgende 4 Konstanten vorsehen:>> #define IRSND_NO_REPETITIONS 0 // no repetitions> #define IRSND_MAX_REPETITIONS 14 // max # of repetitions> #define IRSND_ENDLESS_REPETITION 15 // endless repetions> #define IRSND_REPETITION_MASK 0x0F // lower nibble of flags
Ist ebenso umgesetzt.
> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.
Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber
ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann
eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt
wird.
Desweiteren habe ich das THOMSON-Protokoll in den IRSND eingebaut.
Cajus H. (cajush):
Kannst Du das bitte testen und berichten?
Gruß,
Frank
Hallo Frank,
Frank M. schrieb:> Cajus H. (cajush):>> Kannst Du das bitte testen und berichten?
Da ist ein Copy&Paste Fehler in irmp.c
nach
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
static PROGMEM IRMP_PARAMETER netbox_param =
sollte vermutlich
static PROGMEM IRMP_PARAMETER merlin_param =
heissen...
Danach arbeitet IRMP gut und liefert sinnvolle Werte für das Thomson
Protokoll.
IRSND - mein main() sieht so aus:
int main (void)
{
IRMP_DATA irmp_data;
irsnd_init(); // initialize irsnd
timer_init(); // initialize timer
sei(); // enable interrupts
for (;;)
{
irmp_data.protocol = IRMP_THOMSON_PROTOCOL;
irmp_data.address = 0x03;
irmp_data.command = 0x1d;
irmp_data.flags = 15;
irsnd_send_data (&irmp_data, TRUE);
_delay_ms (10000);
irsnd_stop ();
_delay_ms (3000);
}
}
Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde
Pause und wieder von vorne. Es passiert aber folgendes:
- 10 Sekunden Senden
- 3 Sekunden Pause
- Senden bis die Batterie alle ist.
Scheinbar funktioniert das irsnd_stop(); nur einmal ?!
Wenn ich
irmp_data.flags = 14;
setze, dann funktioniert es. (auch mit dem irsnd_stop(), vermutlich weil
das Senden von 14 Wiederholungen keine 10 Sekunden dauert...)
Das Beenden des Sendens nach 256 Wiederholungen funktioniert, außer im
Fall oben, da hört IRSND mit dem Senden nicht mehr auf,
Gruß
Cajus
Hallo Cajus,
Cajus H. schrieb:> Da ist ein Copy&Paste Fehler in irmp.c
Danke, ist korrigiert.
> Es sollte also 10 Sekunden das Kommando 0x1d senden, dann 3 Sekunde> Pause und wieder von vorne. Es passiert aber folgendes:> - 10 Sekunden Senden> - 3 Sekunden Pause> - Senden bis die Batterie alle ist.
Danke für den Test, ich habe den Fehler gefunden und korrigiert.
irsnd_stop() sollte nun tun, was es soll.
Klappt das denn nun auch mit dem Toggle-Bit, so wie Du es mir
beschrieben hat? Kann Dein Dimmer nun lange Tastendrücke von mehrfachen
Tastendrücken per Toggle-Bit unterscheiden?
> Scheinbar funktioniert das irsnd_stop(); nur einmal ?!
Nein, es funktionierte keinmal. irsnd_stop() hatte die falsche Variable
zurückgesetzt. Das hatte schlicht und ergreifend "Null Effekt".
Korrektur ist im SVN eingecheckt.
Gruß,
Frank
Hallo Torsten,
Torsten K. schrieb:> gibts schon was neues zur Pollin Merlin Tastatur, oder hab ich das hier> überlesen ??
Sorry, habs noch nicht geschafft, die Merlin-Tastatur komplett auf alle
Tastendrücke durchzuchecken. Ich hoffe, ich schaffe es im Laufe der
Woche.
Gruß,
Frank
Frank M. schrieb:> och, wird erkannt. Das ist das NEC16-Protokoll
hmm, guten abend
habe gerade mal das aktuelle aus dem SVN installiert
NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO
kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste
lasse)
SAMSUNG32 ist stabil
KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS
IRMP - Infrared Multi Protocol Decoder
--------------------------------------
Version IRMP: 2.0.0-pre4 20.05.2010
Version IRSND: 1.9.4 22.05.2010
??? wunder einige Sourcen waren vom 22.5. also aktuell
irgendwas ist instabil
evt. schaust mal ?
gruss
jar
Joachim B. schrieb:> NEC16 flattert nun über alle möglichen Erkennungen NEC16 MERLIN RUWIDO> kommt alles mögliche bei repeat (also wenn ich den Finger auf der Taste> lasse)
Was meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal
MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle
eingeschaltet?
> KASEIKYO flattert wenig aber ich sehe dabei auch gel. MERLIN und SIEMENS
Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?
> irgendwas ist instabil
Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist
angeschlossen und aktiv?
Gruß,
Frank
Frank M. schrieb:> as meinst Du damit? Dass bei einer NEC16-FB zwischendurch auch mal> MERLIN oder RUWIDO erkannt wird? Welche Protokolle hast Du alle> eingeschaltet?
genau bleibe ich auf der Taste werden reium alle mal erkannt
alle ausser on >15000 Hz und Prototyp Protokoll 99
> Hier also KASEIKYO-FB, wo ab und zu MERLIN bzw. SIEMENS ausgegeben wird?> Ich bräuchte Deine irmpconfig.h, um das nachzustellen. Quarz ist> angeschlossen und aktiv?
ohne Quarz, war aber vorher stabiler
noch ein kleines Problem:
wird nach
irmp_get_data(&irmp_data)
das irmp_get_data FLAG nicht gelöscht ?
ich kann nur zwischen den Drücken unterscheiden wenn ich zwischendurch
eine andere Taste drücke
drücke ich die Taste 1x und halte fest, lasse los und drück die selbe
toogelt das Repeat Bit nicht, erst wenn ci zwischendurch ne andere
drücke, dabei sollte z.B. TASTE 1 toggeln, wenn losgelassen und wieder
gedrückt wird ..
keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)
ich versuchs mal anders zu erklären
DU kennst doch typische Puls- Pausenlängen
ergo müsste es doch in IRMP auffallen wenn zwischen 2 Tastendrücken der
selbe Code kommt oder innerhalb der Repeatframezeit der selbe Code
einläuft und das Repeatflag entsprechend gesetzt wird.
Ich blick immer noch nicht durch wielange IRMP das Flag "Code erkannt"
vorrätig hält, für mein Geschmack wäre es richtig bis man es ausgelesen
hat, man guckt ja als Controller nicht ständig :-)
bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche
den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir
wieder einen KEY wenn vorhanden
und da ich KEY und IR benutze wäre es schön wenn man das zusammen
bekommt
nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen
sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann
ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem
Vorcode ist, trotzem ist er neu und es sollte toggeln....
Joachim B. schrieb:> keine Antwort ? liegts an mir (weil ich mich unwissend anstelle?)
Ich habe Dir bisher nicht antworten können, weil ich noch ein
Privatleben ohne µC und Elektronik habe ;-)
> ich versuchs mal anders zu erklären> [...]
Da ich an den Timingparametern nichts geändert habe, kann ich mir im
Moment gar nicht vorstellen, wo Deine Probleme herrühren. Im Moment kann
ich mir da nur den fehlenden Quarz vorstellen. Sonst helfen mir da nur
intensive Tests weiter.
Am Donnerstagabend habe ich vielleicht Zeit, Dein Szenario
durchzuspielen. Dann kann ich Dir auch antworten. Vorher schaffe ich es
leider nicht, sorry.
> nur muss ich ja die IR Flags befragen und wenn da ewig welche abzuholen> sind kann ich nicht erkennen ob ich den schon mal geholt habe, bzw. kann> ja ein neuer KEY , ähhh, IR Code sein der durchaus identisch mit dem> Vorcode ist, trotzem ist er neu und es sollte toggeln....
Wenn der nächste IR-Frame innerhalb IRMP_KEY_REPETITION_LEN (150 msec)
reinkommt, dann geht IRMP davon aus, dass die FB automatisch repetiert.
Dann wird das Repetition-Flag gesetzt. Das funktioniert sehr gut. Wenn
Du selber mit dem Finger repetierst, wirst Du das nicht so schnell
schaffen und IRMP setzt dann auch nicht(!) das Repetition-Flag. Also
vergiss das mit dem Toggle, das geht nur bei RC5, RC6 und Thomson. Bei
den 27 anderen FB-Protokollen, die IRMP unterstützt, gibt es gar kein
Toggle-Bit. Daher kann ich das auch gar nicht auswerten.
EDIT: Wenn Du das Toggle-Bit simulieren musst, weil Du anderen Code
verwendest, der nicht auf das RC5-Toggle-Bit verzichten kann, dann mach
einfach folgendes:
- Repetition-Flag gesetzt: dann nicht togglen
- Repetition-Flag nicht gesetzt: dann togglen
Dann sollte auch RC5-Legacy-Code zusammen mit IRMP funktionieren ;-)
Gruß,
Frank
Joachim B. schrieb:> bei meiner KEY Abfrage mache ich es so, lese KEY, werte Key aus, lösche> den gelesen KEY und wenn nix zu tun ist und KEY leer ist, dann hole dir> wieder einen KEY wenn vorhanden
Wenn was zu tun ist: Wie lange brauchst Du, um den Key abzuarbeiten?
Bitte möglichst in msec angeben :-)
Sobald IRMP einen Frame eingelesen hat, sperrt er den Empfang weiterer
IR-Signale solange, bis Du den Code auch abholst.
Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.
1. Du hältst den Finger auf eine FB-Taste
2. IRMP empfängt 1. Frame
3. Du holtst ihn ab und verarbeitest den Key...
4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten
5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang
6. Es kommt der 3. Frame, aber IRMP empfängt nicht
7. Du bist mit der Verarbeitung fertig - mitten im Frame 3
8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei
9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und
fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines
ohne ausgezeichnetes Start-Bit.
Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht
sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame
davor nicht abgeholt hast.
Gruß,
Frank
natürlich darfst du ein Privatleben haben, ich hab momentan keines und
bin deswegen so ungeduldig ?
Frank M. schrieb:> Ich kann mir ein Szenario vorstellen, wo das in die Hose geht.>> 1. Du hältst den Finger auf eine FB-Taste
logisch, ich weiss ja nicht wann der Code vollständig empfangen wurde
bis das gewünschte passiert, vermutlich auch das Problem das der Buffer
meiner lernfähigen FB nie reicht für 4-8 Fernbedienungen (wie der
Aufdruck und die Werbung behaupten), immer sagt die lern FB : Buffer
voll obwohl nur 2 halbe FBs (Kaseikyo) gelernt wurden.
Kann aber auch sein die Befehle wurden immer länger und der Speicher der
FB (alte >5 Jahre und NEUE !!! grad gekauft ) ist zu knapp
> 2. IRMP empfängt 1. Frame> 3. Du holtst ihn ab und verarbeitest den Key...> 4. Währenddessen empfängt IRMP den 2. Frame und speichert die Daten> 5. Du verarbeitest aber immer noch den 1. Key -> IRMP sperrt den Empfang> 6. Es kommt der 3. Frame, aber IRMP empfängt nicht
das könnte genau so laufen
> 7. Du bist mit der Verarbeitung fertig - mitten im Frame 3> 8. Du holst den 2. Frame ab, IRMP gibt den Empfang wieder frei> 9. Ein Restfragment vom 3. Frame wird von IRMP aufgezeichnet und> fälschlicherweise als irgendein Protokoll erkannt, vorzugsweise eines> ohne ausgezeichnetes Start-Bit.>> Wenn dem so ist, kann ich das nur lösen, indem IRMP den Empfang nicht> sperrt, aber das Ergebnis anschließend verwirft, solange Du den Frame> davor nicht abgeholt hast.
wielange KEY dauert ? oder die Abarbeitung nach KEY ? das letztere werde
ich nie rausfinden, es gibt nur 6 Tasten die in jedem Menue und
Untermenue je nach Bedingung verschiedenes tun, also die
Verarbeitungsdauer nach KEY lesen ist unbestimmt
ein Riesendanke für deine Bemühungen
ich hatte mir was überlegt, aber das scheint auch nicht zu klappen
ich dachte wenn ich ein Bit selber toggeln lasse, in der Art,
...
klappt aber auch nicht, evt. kannst du ein Flag einbauen welches immer
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
wurde also die FB Taste mal nicht gedrückt war
warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code
vorhanden ?
dann könnte man sich diese Quälerei sparen, im RC5 wird es ja
mitgeliefert und ich brauche nicht zu tricksen
wenn der Umbau aber klappt mit toggle selber erzeugen -
(nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer
toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt
wurde also die FB Taste mal nicht gedrückt war )
- für alle Codes waere das auch fein
Joachim B. schrieb:> warum ist das toggleBIT eigendlich nicht im IRMP erkannten RC5 Code> vorhanden ?
Weil Du dann für ein- und dieselbe Taste zwei unterschiedliche Codes
bekommen würdest.
> dann könnte man sich diese Quälerei sparen, im RC5 wird es ja> mitgeliefert und ich brauche nicht zu tricksen
Die "Quälerei" hast Du nur deshalb, weil Du Code benutzt, der Original
RC5 sehen will. IRMP wandelt die Daten aber in ein portables Format, was
für alle Protokolle einheitlich ist.
> wenn der Umbau aber klappt mit toggle selber erzeugen ->> (nach meinem Vorschlag: evt. kannst du ein Flag einbauen welches immer> toggelt wenn eine neue Taste kommt oder wenn eine FramePause erkannt> wurde also die FB Taste mal nicht gedrückt war )
Ich habe doch schon geschrieben: Wenn Repetition-Flag nicht gesetzt,
dann togglen, wenn Flag gesetzt, dann nicht togglen. Hast Du das
überlesen?
> - für alle Codes waere das auch fein
Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen
Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das
Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so
ein Toggle-Bit.
Gruß,
Frank
Joachim B. schrieb:> ich hatte mir was überlegt, aber das scheint auch nicht zu klappen
1
>voidfb(void)
2
>{
3
>if(irmp_get_data(&irmp_data)&&!strcmp((char
4
>*)Proto[irmp_data.protocol-1],"RC5(x)"))
5
>{
6
>L_Com&=0x8000;// loesche L_Com aber behalte das alte toggleBIT
Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?
1
>L_Com^=(1<<15);
Auch hier:
Wie kommst Du auf die Idee, dass das Toggle-Bit an der 16. Stelle sitzt?
Schau Dir bitte http://www.sbprojects.com/knowledge/ir/rc5.htm an.
merke_rc5 wird bei Dir gesetzt aber nie benutzt?
Machs doch einfach so:
1
voidfb(void)
2
{
3
staticuint16_ttoggle_bit;
4
...
5
6
toggle_bit^=(1<<11);// Togglen
7
L_Com|=toggle_bit;
8
...
9
}
Und noch etwas:
Dein
if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))
ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:
if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)
Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein
Zeichenkettenvergleich. Warum machst Du so etwas?
Gruß,
Frank
Zusatz:
Was soll der Ausdruck ((irmp_data.address*100) + irmp_data.command) &
0x7fff)
Adresse mal hundert + Kommando? Verstehe ich nicht. Damit baust Du
jedenfalls nicht den Original-Frame zusammen, sondern irgendeine
Zufallszahl.
Frank M. schrieb:> Warum sollte ich ein Toggle-Bit künstlich einbauen? Die anderen> Protokolle kennen doch gar kein Toggle-Bit. Dafür gibt es doch das> Repetition-Flag in IRMP. Das ist doch viel einfacher zu handhaben als so> ein Toggle-Bit.> Gruß,> Frank
also im RC5 Code wäre es nicht künstlich eingebaut, da wird das
mitgeliefert und damit lief mein altes Programm genau wie geplant, ich
verstehe halt nicht warum IRMP das nicht durchreichen kann ?
Frank M. schrieb:> Dein>> if (... !strcmp((char *)Proto[irmp_data.protocol-1], "RC5(x)"))>> ist suboptimal und kostet viel CPU-ZEIT. Warum nicht einfach:>> if (... irmp_data.protocol == IRMP_RC5_PROTOCOL)>> Das ist nur ein int16-Vergleich und geht wesentlich schneller als Dein> Zeichenkettenvergleich.
ja klar
> Warum machst Du so etwas?
weil das für mich der schnellste Weg war ohne IRMP vollständig zu
erkunden ?
ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das
mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja
korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns
erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum
nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun
Frank M. schrieb:> Deine fb-Funktion ist absoluter Murks, der else-Block ganz am Ende> gehört da auch nicht hin.>> Ich schreibe das mal neu:> ...> So einfach ist das. :-)
ich probiere es ;-)))
Joachim B. schrieb:> also im RC5 Code wäre es nicht künstlich eingebaut, da wird das> mitgeliefert und damit lief mein altes Programm genau wie geplant, ich> verstehe halt nicht warum IRMP das nicht durchreichen kann ?
Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe
Taste 2 verschiedene Codes bekommen.
> weil das für mich der schnellste Weg war ohne IRMP vollständig zu> erkunden ?
Die Konstante steht in irmp.h und im IRMP-Artikel steht ein
Anwendungsbeispiel:
http://www.mikrocontroller.net/articles/IRMP#Anwendung_von_IRMP
Zitat:
> ich wusste RC5 wird per String ausgegeben wenn erkannt, also war das> mein Unterscheidungsmerkmal, natürlich suboptimal und kann man ja> korrigieren, zur Codeoptimierung kann ich ja später vordringen wenns> erst mal läuft, wenn natürlich schon vorher gute Ideen einfliessen warum> nicht zur Laufzeit der Prog.Entwicklung einfliessen lassen, mach ich nun
Jetzt verstehe ich auch, warum Du wolltest, dass ich die Texte in main.c
vervollständige... :-)
> ich probiere es ;-)))
Viel Glück! :-)
funktioniert nicht :-(
Codes werden mehrfach erkannt und sofort ohne Zwischenstop falsch
abgearbeitet
also Menue -> ENTER -> Untermenue und da warten bis andere Taste oder
ENTER wieder neu ! gedrückt wird
wird in einem Rutsch abgearbeitet, keine Chance im Untermenue noch
Optionen zu wählen
wenn ich also auf der FB Taste gedrückt bleibe ! werden die Aktionen im
ca. 10s ? Takt durchgeführt, z.B. Licht an/aus
obwohl ich ja die Taste nie losgelassen hatte
wenn ich kurz drücke, passiert entweder nix ! oder Licht geht an und
gleich wieder aus, einen statischen ON/OFF Zustand kann ich so nicht
erreichen
Joachim B. schrieb:> funktioniert nicht :-(
Du hattest auch meine Frage bzgl. der Position des Toggle-Bits nicht
beantwortet. Wo muss das stecken? An der 16. Stelle? Oder wie im
Original an der 12. Stelle?
Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das
Toggle-Bit stecken muss.
Frank M. schrieb:> Habe ich doch geschrieben: Dann würdest Du im IRMP für ein- und dieselbe> Taste 2 verschiedene Codes bekommen.
ja und ? das war schon immer so, der einzige Unterschied wäre das
originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das
jemanden stört !
ich hab das ToggleBIT von (1<<11) nur nach (1<<15) verschoben um unten
Platz zu behalten
ich habe Adresse mit 100 multipliziert weil mir Adresse 30 als 3000 und
7 als 700 sympatisch war und ich bei RC5 nie mehr als 100 Commands sah
und weil ich hauptberuflich kein Infomatiker bin
deswegen kämpfe ich ja an allen Fronten gleichzeitig
eagle nervt fast mit wöchenlichen Updates und jedesmal muss ich an allen
Stellen die LIBs importieren die wires beim Start neu intialisieren, das
nervt und wehe man vergisst an einem Rechner irgendeine Einstellung....
eine zeitlang waren meine avr_gcc und ASTUDIO nicht auf allen Rechnern
auf den gleichen Stand aber alles lief, dann hatte ich auf einem Rechner
ein update gemacht und nix lief mehr, dann habe ich alles gelöscht die
REG geputzt und noch mal von vorne und nix ging (irgendwas in der REG
übersehen?), also noch mal von vorne und damit das nicht wieder passiert
habe ich den win_avr PATH geändert um sicherzugehen, seit dem nervt mich
MAKE wenn ich an dem einen oder anderen Rechner arbeite das er die LIBs
nicht findet, gleichwohl ich weiss nicht wie das passiert, werden die
FILENAMEN nun manchmal in UPPER Case importiert, was den Linker wieder
ärgert C++ ist nicht in gnu99c enthalten, dabei benutze ich kein C++
wenn ich dann manuell im DIR die Filenamen wieder zu lower Case mache
ist es wieder OK, jedenfalls temporär
Ein RC5x-Frame sieht folgendermaßen aus:
C6 T A4 A3 A2 A1 A0 C5 C4 C3 C2 C1 C0
Die Zeile
1
L_Com=(i_>>6&0x1F)*100;
Speichert in L_Com das Hundertfache von der Adresse: A4 A3 A2 A1 A0.
Dabei werden die Kommando-Bits und auch das Toggle-Bit weggeschnitten.
Die Zeile
1
L_Com+=(i_&0x3F)|(~i_>>7&0x40);
sollte wohl C6 C5 C4 C3 C2 C1 C0 speichern, wobei C6 invertiert ist nach
dem RC5x-Protokoll.
Aber das scheint ein Programmierfehler zu sein: Wenn ich richtig zähle,
stimmt aber die Bitposition für das C6 nicht.
@Joachim B.
Das Toggle-Bit an 12. Stelle wird hier jedenfalls komplett ignoriert.
Ich brauche den alten RC5-Code, sonst kann ich Dir nicht helfen.
Joachim B. schrieb:> ja und ? das war schon immer so, der einzige Unterschied wäre das> originale RC5 ToogleBIT welches ausmaskiert werden kann wenn das> jemanden stört !
Sorry, Du hast den Sinn und Zweck von IRMP nicht verstanden. IRMP
speichert den Frame in einem kompatiblen Format ab und nicht im
RC5-Format. Ein IRMP-Anwender braucht gar nicht zu wissen, was RC5 ist
und dass da ein Toggle-Bit ist, was ausmaskiert werden muss!
Der Vorteil von IRMP ist doch gerade die Protokoll-Unabhängigkeit. Soll
der jetzt da reinschreiben: "Wenn protokoll gleich RC5, schmeiß dass
Toggle-Bit weg"?
Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den
Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht
akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source
von Dir, sonst wird das nix.
Frank M. schrieb:> Zeig doch mal den Rest Deines RC5-Programms, damit man sieht, wo das> Toggle-Bit stecken muss.
etwas mehr Code als IRMP noch nicht integriert war
Frank M. schrieb:> Nein, die Einführung eines eines allgemeinen Toggle-Bits in IRMP für den> Spezialfall, dass Dein alter Code wieder läuft, ist für mich nicht> akzeptabel. Ich helfe Dir gern. Aber ich brauch dafür den alten Source> von Dir, sonst wird das nix.
ich verstehe das ja, nur wie soll man das lösen das das so gewünschte
programmtechnisch läuft ?
alle Lösungsversuche liefen bis jetzt schief, es scheint als wenn das
nicht funktioniert
warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?
der State hat ja nie gewechselt, ergo dürfte
1
if(!(irmp_data.flags&IRMP_FLAG_REPETITION))
2
{
3
toggle_bit^=(1<<15);// Togglen
4
L_Com|=toggle_bit;
5
}
nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das
togglebit unverändert und __p == HAUPTMENU
Joachim B. schrieb:> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?> der State hat ja nie gewechselt, ergo dürfte
Jetzt zeige bitte den neuen Source, welcher IRMP nutzt, damit ich das
vergleichen kann.
Gruß,
Frank
Joachim B. schrieb:> warum geht mein Licht an und aus wenn ich auf der Taste power bleibe ?> der State hat ja nie gewechselt, ergo dürfte>>
1
>if(!(irmp_data.flags&IRMP_FLAG_REPETITION))
2
>{
3
>toggle_bit^=(1<<15);// Togglen
4
>L_Com|=toggle_bit;
5
>}
6
>
>> nie das toggleBIT ändern, mit L_Com ist gleicher Befehl und das> togglebit unverändert und __p == HAUPTMENU
Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem
Tastendruck?
Frank M. schrieb:> Wenn Du diesen Block weglässt, passiert dann das gewünschte bei langem> Tastendruck?
wie schon mal
langer Tastendruck z.B. Licht an/aus lässt eine NEUE Taste genau einmal
reagieren, ob ich draufbleibe oder loslasse und nochmal drücke ändert
nix, nie wieder reagiert die Routine auf die gewünschte Taste bis ich
eine andere drücke erst dann wird wieder z.B. Licht geschaltet
evt. geht das Licht auch so schnell an und aus das ich es nicht merke
denn up und downscrollen funktioniert ja
aber wenn ich im Untermenue mehrfach die TAB-Taste drücke, springt die
nur 1x wie beim Licht, ich muss zwischendurch eine andere Taste drücken
damit TAB wieder einmal reagiert
neuer Code anbei
die Idee warum ich dafür IRMP nutzen möchte
wie du schon sagtes RC5 stirbt aus und mein Timer sollte (lernfähig) mit
allen FB arbeiten, gleichwohl ist die "Funktion" alle FB erkennen toll
und hilfreich als Tester in ein Gehäuse gepresst und kann quasi nebenbei
von meinem Timer erledigt werden, alle Codes erkenne ich ja, nur kann
ich so die IR Fähigkeit der Bedienung vergessen, es sei denn wir finden
ne Lösung
die Möglichkeit nur zur Bedienung auf RC5 Decoder auszuweichen und zum
Test IRMP zu nutzen gäbs ja auch noch, aber damit verbaue ich mir die
Lernfähigkeit der Timerbedienung für alle FB
hi frank,
ich hab nun den RC5 Aufruf in die ISR hinter dem IRMP Aufruf gesetzt und
bei RC5 erkannt werte ich dieses nur aus, ergo mein Hauptcode
funktioniert wieder wie gewünscht,
kein repeat da wo er nicht sein darf,
aber repeat da wo gewünscht
ich kann repeaten bei scroll up/down und nie repeaten bei Licht an/aus
oder ENTER
ich leg das mal in den Zip
vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP
nutzen)
eines ist mir aufgefallen
ich hole pro main loop genau 1x den RC5 Code ab und der wird von mir
gleich danach gelöscht
Joachim B. schrieb:> vielleicht fällt dir noch was ein (ich würde sehr gerne für alle FB IRMP> nutzen)
Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen
anzuschauen.
Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann
musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den
letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder
nicht. Das ist alles viel zu umständlich. Dein Source würde sich
vereinfachen, wenn Du einfach das Flag konsequent abfragst. Es bringt
nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die
Anpassung Deines Sources an IRMP.
Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5
Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit
gefragt, um da durchzusteigen. Ich machs irgendwann in den nächsten
Tagen, bin aber viel unterwegs. Kann also etwas dauern.
Gruß,
Frank
Frank M. schrieb:> Ich weiß nicht, ob ich es schaffe, mir das in den nächsten Tagen> anzuschauen.>> Wenn Du gern alle FBs mit IRMP für Dein Programm nutzen möchtest, dann> musst Du Dich gedanklich vom Toggle-Bit lösen. Du vergleichst immer den> letzten mit dem vorletzten Befehl, um herauszufinden, obs togglet oder> nicht. Das ist alles viel zu umständlich. Dein Source würde sich> vereinfachen, wenn Du einfach das Flag konsequent abfragst.
das hatten wir doch versucht ? ohne Erfolg :-(
> Es bringt> nichts, die IRMP-Werte an Dein Programm anzupassen. Besser wäre die> Anpassung Deines Sources an IRMP.
klar ich bin sehr dafür !
> Leider ist Dein Source nicht soooo übersichtlich, dass ich mir das in 5> Minuten zu Gemüte führen kann, da ist schon etwas Detektivarbeit> gefragt, um da durchzusteigen.
genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top
down Entwicklung (erwähnte ich das ich kein Softi bin :D)
PS. brauchst du noch den umfangreichen Rest ?
> Ich machs irgendwann in den nächsten> Tagen, bin aber viel unterwegs. Kann also etwas dauern.
alles klar, danke, ich werde mich nun mal um die Straffung und
Bereinigung kümmern, einiges gefällt mir selber nicht mehr, z.B. mein
"Multitask" viel zu umständlich (ich hasse delays, jede Menge Timercode
den man so im Netz findet lässt die CPU ewig in delay-Schleifen unnütz
warten, dabei kann man in der Zeit auch was anderes tun, die ADC
befragen, das LCD updaten, die Uhr weiterlaufen lassen, die DCF77 Bits
befragen die Tastatur abholen und natürlich auf Events reagieren wie LED
zurücksetzen
Joachim B. schrieb:> das hatten wir doch versucht ? ohne Erfolg :-(
Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und
mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so
gut kennst :-)
Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:
- Das toggle-Bit muss komplett raus.
- Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig
- Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus
(das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die
Hose)
> klar ich bin sehr dafür !
Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann
mit Leben füllst (reinschreiben konkreter numerischer Werte + Test).
Dann sollte das machbar sein.
> genau deswegen wird er ja so pö a pö neugeschrieben, war eben ne top> down Entwicklung (erwähnte ich das ich kein Softi bin :D)> PS. brauchst du noch den umfangreichen Rest ?
Dieses "pö a pö" ist der falsche Weg, das macht alles nur
unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu
schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste
machen soll, z.B.
TAB kurz: nächster Menüpunkt Funktion: menu_down()
TAB lang: Untermenüaufruf, Funktion: sub_menu()
So in der Richtung...
Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da
erst übernächste Woche zu.
Frank M. schrieb:> Wir? Nein! Bis heute kannte ich Deinen Source doch überhaupt nicht. Und> mich beschleicht das Gefühl, dass Du Deinen Source auch nicht (mehr) so> gut kennst :-)
hmm du hattest gesagt wie und ich habs eingetippt, mit der Folge,
Versuch 1
das bei "ewigem" Tastendruck die LED trotzdem an und aus ging, also die
Einmalabfrage nicht klappte
Versuch 2
die einmal Abfrage zwar klappte, aber nur einmal, Taste loslassen hatte
danach keinerlei Wirkung mehr, erst der Tastenwechsel und zurück lies
die Taste wieder erkennen
> Folgende Maßnahmen sind notwendig, um vom RC5-Protokoll wegzukommen:> - Das toggle-Bit muss komplett raus.> - Der Vergleich alter <--> neuer Frame muss raus, ist überflüssig> - Das Multiplizieren/Addieren der Adresse mit dem Kommando muss raus> (das funktioniert nur mit RC5 so, bei NEC geht das schon voll in die> Hose)
OK
> Ich schlage vor, dass ich dafür ein Grundgerüst schreibe, dass Du dann> mit Leben füllst (reinschreiben konkreter numerischer Werte + Test).> Dann sollte das machbar sein.
noch mehr OK
> Dieses "pö a pö" ist der falsche Weg, das macht alles nur> unübersichtlicher. Besser ist es, die Funktion fb() komplett neu zu> schreiben. Schreib doch mal auf, was die Funktion bei welcher Taste> machen soll, z.B.>> TAB kurz: nächster Menüpunkt Funktion: menu_down()> TAB lang: Untermenüaufruf, Funktion: sub_menu()>> So in der Richtung...
da grübel ich ja gerade, IR und Tastatur sind gleichberechtigt
entweder ich lese die Taste und weise dem einen IR Code zu und erledige
die Aufgaben da, oder ich lese den IR Code und setze KEY und erledige
die Aufgaben da ????
natürlich muss ich dann KEY Test und IR Test irgendwie sonderbehandeln
> Aber ich bin in der nächsten Woche komplett ausgelastet, ich komme da> erst übernächste Woche zu.
no Problem, mache ich erst mal den Rumpf weiter (Display ist größer
geworden, von 20 x 4 alphanumerisch auf 21 x 8 Z -aber grafisch- )
Ich muss eh die Screens neu definieren, den RAM Verbrauch eindämmen,
Grafik ohne Lesemöglichkeit kostet, und Strings gleich aus dem flash zu
lesen, oder ins EEPROM schieben um da ändern zu können
also ich bin beschäftigt solange du noch nicht kannst
Danke und viel Erfolg
Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich
mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit
gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838)
kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.
Michael K. schrieb:> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit> gesammelt, zwecks Realisierbarkeit? Die neueren TSOPs (z.B. TSOP34838)> kommen ja mit weniger als 1mA aus - da würde sich das IMO schon lohnen.
hmm, bedingt, was meinst du damit ? als Sender oder Empfänger ?
im Prinzip einfach, an einer TastenMatrix für IRSND den pin-change
wakeup und senden, als Empfänger dito pinchange belauscht den TSOP
ich habe es in meinem Timer1 gemacht, luca in einem Cam Trigger, da
werden sogar die Puls/Pausenzeiten per sleep realisiert, also jedes
delay schickt die CPU schlafen bis die Zeit um ist
Michael K. schrieb:> Weiter oben wurde mal wegen Stromsparmechanismen diskutiert. Hat sich> mal jemand weiter damit auseinandergesetzt und/oder Erfahrungen damit> gesammelt, zwecks Realisierbarkeit?
Das ist eigentlich nicht Sache des IRMP - als Bibliothek betrachtet.
> Die neueren TSOPs (z.B. TSOP34838) kommen ja mit weniger als 1mA> aus - da würde sich das IMO schon lohnen.
Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des
TSOPs über einen ATMega-Pin steuert. Ich habe das so in der Lernfähigen
Fernbedienung so umgesetzt, die auch IRMP nutzt:
http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP
Dafür muss dann aber das Programm "wissen", wann es den TSOP einschalten
muss, damit etwas empfangen werden kann. Der Stromverbrauch bei diesem
Mini-Projekt liegt bei weit unter 1µA.
Gruß,
Frank
Frank M. schrieb:> Es geht auch mit den älteren TSOPs, wenn man die Stromversorgung des> TSOPs über einen ATMega-Pin steuert.
dann geht das folgende aber nicht, der TSOP muss ja Vcc haben damit er
ein output an pin change AVR senden kann
Michael K. schrieb:> Ich meinte als Empfänger, der allzeit bereit sein soll.
klaro, schick die CPU schlafen der TSOP bleibt auch on an Vcc und weckt
mit Signal out an einen PIN Change den AVR, das AVR delay dürfte
vernachlässigbar sein ? irgendwas um 65 CLK also bei 20 MHz AVR 3µs,
Frank wird das eher wissen ob das delay die Auswertung stört
@frank, mal zu meinem "Problem" geschaut ?
Hallo zusammen,
ich verwende IRMP zusammen mit dem IR-Receiver in Hugo Portisch. Da der
IR-Receiver einen älteren Stand aus dem letzen Jahr enthält, habe ich
ein Upgrade auf IRMP-SVN-Head gemacht. Das funktioniert soweit auch gut,
bis auf folgendes:
1. ich kann keine Frequenzen > 10000 benutzen, dann wird nichts mehr
erkannt. Das könnte auch ein IR-Receiver spezifisches Problem sein. Im
Thread dort habe ich schon nachgefragt aber keine Antwort bekommen. BTW
der ältere Stand aus dem letzen Jahr hat das gleiche Problem.
2. Die Ruwido Merlin funktioniert bei mir nicht, es wird nur Müll
erkannt. Wie ist denn der genaue Status der Merlin Implementierung?
Sollte das funktionieren?
Folgende Protokolle funktionieren bei mir: RC6A, Samsung32, FDC
Keyboard.
Dirk W. schrieb:> Im Thread dort habe ich schon nachgefragt aber keine Antwort bekommen.
Ich habe dir doch dort geantwortet
(Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)").
Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung,
daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit
dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware
sollte nach der Neukompilierung laufen (ich habe es nicht getestet).
Um das zu beheben müsste für jedes Makro in irmp.c, Zeile 385 bis 599,
eine Variable her, deren Inhalt bei einer Änderung neu berechnet werden
müsste. Das hätte einen Speicherverbrauch zur Folge der den Rahmen eines
AVR sprengt.
Michael K. schrieb:> Mit IRMP hat das Problem nichts zu tun. Derzeit gibt es keine Lösung,> daher sollte der Regler IMO in ruhe gelassen werden. Anders sieht es mit> dem Makro F_INTERRUPTS aus: das kann geändert werden und die Firmware> sollte nach der Neukompilierung laufen (ich habe es nicht getestet).
Ich habe natürlich F_INTERRUPTS in der IRMP Source geändert und nicht
über die Windows-DLL. Es funktionert (bei mir) nicht.
Hallo,
Mal eine frage: Wäre es möglich, dass IRMP auch das Ausgangssignal des
Funkempfängers von z.B. der Logitech Harmony 900 dekodieren kann? Dessen
Ausgang ist eigentlich dazu da einen extra IR Sender anzuschließen. Da
dieser Sender aber nur IR-Dioden enthält, gehe ich davon aus, dass das
Signal bereits mit der Trägerfrequenz versehen ist, usw.
IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das
Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert
das ohne extra Hardware allgemein nicht?
P.S.: Die Frage habe ich auch schon im USB IR Empfänger Thread gestellt,
aber eventuell bin ich hier "richtiger".
KLez schrieb:> IRMP müsste also zuerst noch die Trägerfrequenz rausrechnen um an das> Nutzsignal zu kommen... Ist es möglich das einzubauen oder funktioniert> das ohne extra Hardware allgemein nicht?
Ja, das sollte möglich sein.
Gruß,
Frank
Frank M. schrieb:> Ja, das sollte möglich sein.
Hallo Frank,
Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es
so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit
10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig
um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen
Denkfehler?
Wie würdest Du das ganze implementieren?
Viele Grüße
KLez schrieb:> Ich habe gerade nochmal geschaut und glaube ehrlichgesagt nicht, dass es> so einfach möglich ist. Wie ich lesen konnte pollst Du den Eingang mit> 10KHz... Das ist nach meinem Verständnis also um das 3,8 fache zu wenig> um eine 38Khz Trägerfreuqenz raus zu rechnen, oder habe ich gerade einen> Denkfehler?
Eine 38kHz Trägerfrequenz hat eine Periodenlänge von ca. 26 µsec. Du
musst die Pulse von ca. 13 µsec softwaremäßig auf mehr als 26 µsec
verlängern, damit IRMP ein durchgängiges Signal "sieht".
> Wie würdest Du das ganze implementieren?
Ich würde mir einen PCINT-Interrupt auf das Eingangssignal setzen. Dort
setze ich ein globales Flag namens ir_signal, z.B. so:
1
#define IR_OFF 1 // no IR signal
2
#define IR_ACTIVE 0 // IR signal active
3
4
volatileuint8_tir_signal=IR_OFF;
5
6
ISR(PCINT1_vect)
7
{
8
ir_signal=IR_ACTIVE;// IR is active
9
}
In der normalen Timer_ISR, die Du ja sowieso für den Aufruf der IRMP-ISR
brauchst, würde ich nach(!) dem Aufruf von irmp_ISR() dieses Flag wieder
zurücksetzen, also:
1
ISR(TIMER1_COMPA_vect)
2
{
3
(void)irmp_ISR();
4
ir_signal=IR_OFF;
5
}
In irmpconfig.h setzt Du:
1
#define input(x) ir_signal
Der Trick ist, dass Du damit jeden Puls des Trägersignals solange
softwaremäßig verlängerst, dass die IRMP-ISR ihn mindestens einmal
"sieht". Da der PCINT bei aktivem IR-Signal viel öfter kommt als die
IRMP-ISR ausgelöst wird, sollte das so klappen.
Gruß,
Frank
Dirk W. schrieb:> Darf ich deine Aufmerksamkeit auf diesen Beitrag> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"> lenken. Vorallem Punkt 2 würde mich interessieren.
Sorry, zum Punkt 1 kann ich nichts beitragen, ich habe mich bisher nicht
so tief in Hugos V-USB Port reingehängt.
Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe
zwischwendurch viele andere interessante Sachen gemacht. ;-)
Ich melde mich dazu nochmal.
Gruß,
Frank
Frank M. schrieb:> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe> zwischwendurch viele andere interessante Sachen gemacht. ;-)>> Ich melde mich dazu nochmal.
Danke fürs Feedback. Ich habe inzwischen noch eine Netbox Tastatur hier
und die funktioniert auch nicht. Es wird nur gelegentlich RC6A erkannt.
Evtl. hängt das mit den Merlin Problem zusammen.
Bei der FDC Tastatur ist mir aufgefallen, dass wenn ich längere Zeit
eine Taste festhalte nicht auschliesslich Events mit Protokoll FDC
geschickt werden, sondern auch welche mit Protokoll Merlin. Das kann
aber auch Zufall sein, dass irgendwas überläuft und ausgerechnet Merlin
Codes geschickt werden. Die Codes sehen auch ziemlich seltsam aus.
Hallo Frank M,
Vielen Dank für Deine Ausführung! Ich werde mal damit ein wenig
experimentieren. Trotzdem noch eine Frage: Wäre es nicht einfacher einen
seperaten Eingang dafür zu nehmen und das Signal direkt auf den
Interrupt des AVR zu legen? Dann müsste dieser doch nur noch die Flanken
zählen und das Ergebnis an irmp übergeben.
Hallo,
ich hatte mal wieder Zeit etwas zu basteln. Dazu hab ich natürlich die
aktuelle Version vom svn gezogen und mal mit allen FB durchprobiert.
Funktioniert fast perfekt, nur mit dieser Sagem FB für die d-box klappt
es nicht so richtig. Es wird als Merlin erkannt und zeigt aber
verschiedene Adressen und Codes an. Scheint nicht ganz das gleiche zu
sein.
Da ich das Ganze mal sauber aufgebaut haben wollte und nicht nur auf dem
Experimentierboard, hsb ich die Pollin RS232-Bas Platine verwendet.
Mit minimalen Änderungen kann man die dazu verwenden und muß sich keine
eigen Platine ätzen.
Angefügt hab ich mal meine main.c die momentan nur zum Testen der FB
dient.
Wenn ich mal wieder dazukommen werden ich noch eine Anpassung der FDC
Tastatur schreiben, damit sie an einen PC angebunden werden kann.
Fred
Hallo Frank,
um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM
Variablen als const zu markieren, was auch nur logisch ist. Könntest Du
den SVN Quellcode diesbezüglich bitte aktualisieren.
Danke.
eku schrieb:> um IRMP mit dem aktuellen GCC 4.6.1 zu übersetzen sind alle PROGMEM> Variablen als const zu markieren, was auch nur logisch ist. Könntest Du> den SVN Quellcode diesbezüglich bitte aktualisieren.
Ist erledigt.
Gruß,
Frank
Hallo!
Nachdem ich die Frage hier
Beitrag "USB IR Remote Receiver (V-USB + IRMP)"
schonmal gestellt habe und dabei auf dieses Forum verwiesen wurde
versuch ichs nun hier:
Ich habe diesen Empfänger:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver
laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:
Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.
Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?
Muß dazu sagen daß ich ein absoluter Laie bin was das Thema
programmieren o.ä. angeht....
Hallo Frank,
würdest Du bitte den Mitschnitt im Anhang analysieren. Mir ist es nicht
gelungen, die Fernbedienung eines SAT-Receivers von Medion mit
irgendeinem Protokoll zu dekodieren. Manchmal sprang der RC5-Algorithmus
an, lieferte aber unabhängig von der gedrückten Taste den selben Code.
Danke.
Frank M. schrieb:> Zum Punkt 2: Muss ich zu Hause nachschauen, wie weit ich da bin, habe> zwischwendurch viele andere interessante Sachen gemacht. ;-)>> Ich melde mich dazu nochmal.
Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu
meiner Anfrage bzgl. Merlin Tastatur ist?
Hallo eku,
eku schrieb:> würdest Du bitte den Mitschnitt im Anhang analysieren.
Habs mir gerade mal im Editor und mit "irmp -a" angeschaut. Das
Protokoll ist einfach, aber ziemlich blöde für irmp.
Eigenschaften:
1. Bitserielles Protokoll mit Datenrate von 600Bd
2. 1 Startbit ohne Pause, 8 Datenbits, 1 Stopbit
3. Jeder Frame wird 2x gesendet.
Blöd für IRMP ist der Punkt 2: Ohne Pause nach dem Startbit kann das
Protokoll nicht eindeutig erkannt werden, weil schon der erste Puls
1-fache bis 9-fache Länge haben kann.
Ich kann das Protokoll zwar einbauen in IRMP, aber man müsste sämtliche
anderen Protokolle deaktivieren, damit dieses eindeutig erkannt wird.
Die Geschichte ist also für einen Multiprotoll-Decoder ziemlich
unsinnig.
Einfacher wäre es, den TSOP direkt an den UART zu hängen und den UART
auf 600 Bd einzustellen. Dann kann man die Bytes direkt mit jeder
üblichen UART-Lib auslesen. Im IRMP wäre es sowieso nichts anderes als
ein Software-Uart.
Gruß,
Frank
Dirk W. schrieb:> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu> meiner Anfrage bzgl. Merlin Tastatur ist?
Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich
zugeben. Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.
Gruß,
Frank
Frank M. schrieb:> Sorry, Dirk. Ich hatte dazu wenig Lust in der letzten Zeit, muss ich> zugeben.
Dafür habe ich vollstes Verständnis, daher frage ich auch jetzt erst
nach, ist ja alles deine Freizeit.
> Ich versuche, mich in der kommenden Woche mal dazu aufzuraffen.
Wäre schön. Wie gesagt, mir geht es nur darum: funzt die Merlin mit dem
Head-Stand oder nicht. Also ein reiner Funktionstest.
Toll das!! :))
Großes Lob, Frank!
Ich habe das in einen AT90USB "eingebaut", der zugleich sich als HID
Keyboard ausgibt. So kann ich die empfangenen RC5-Signale als
Tastendruck ans Media Center übergeben! :)
Als HID USB nutze ich LUFA. Bei mir funktioniert alles soweit. Mein Code
für die FB-Auswertung sieht im Groben wie folgt aus:
1
if(irmp_get_data(&irmp_data))
2
{
3
if(irmp_data.address==19)
4
{
5
if(!(irmp_data.flags&IRMP_FLAG_REPETITION))
6
{switch(irmp_data.command)
7
{caseir_hoch:Taste=t_hoch;break;
8
caseir_runter:Taste=t_runter;break;
9
caseir_links:Taste=t_links;break;
10
caseir_rechts:Taste=t_rechts;break;
11
caseir_enter:Taste=t_enter;break;
12
default:break;
13
}
14
}
15
}
16
}
17
else
18
{
19
Taste=0;
20
}
Wenn ich nun die Abfrage nach dem IRMP_FLAG_REPETITION weglasse,
reagiert alles rattenschnell. Allerdings läuft LUFA öfter durch als IRMP
mir Werte liefern kann. Was zur Folge hat, dass meine Variable "Taste"
zwischendurch Null gesetzt wird, obwohl ich die FB-Taste gedrückt halte,
und LUFA das als schnelle hintereinanderfolgende Tastendrücke
interpretiert. Sprich, ich drücke nur kurz für ein Zeichen, aber bekomme
mein Zeichen auf dem Bildschirm mehrmals ausgegeben.
Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings
habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste
mehrmals schnell hintereinander drücken will (für track skippen oder
Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder
Tastendruck wird erkannt. Woran kann das liegen?
Ich habe versucht, das mit einem Zähler aufzufangen, der abschätzt, ob
das nächste Telegramm länger als 117ms gebraucht hat, was ich dann als
neuen Tastendruck interpretiere. Erst nach Ablauf des Zählers setze ich
meine Variable "Taste" zu Null. Das hat aber zur Folge, dass LUFA nach
losgelassener Taste merklich länger das Zeichen ausgibt, bevor es die
Ausgabe stoppt. Das spricht einerseits dafür, dass mein Zähler deutlich
länger als 117ms braucht - sonst würde ich es nicht merken können -,
aber wenn ich den Zählerwert nur leicht heruntersetze, habe ich das
Problem mit ohne IRMP_FLAG_REPETITION-Abfrage wieder. (?)
Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem
Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach
losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder
beliebiger fester Wert >0x80, mich interessiert nicht unbedingt welche
Taste losgelassen wurde, sondern dass eine losgelassen wurde)? Das
wäre nämlich schneller und sicherer als mein Zähler! Ich hatte versucht,
selber Hand anzulegen, aber ich habe Deinen Code leider doch nicht voll
und ganz verstanden.
Danke und Gruß
narkus schrieb:> Toll das!! :))> Großes Lob, Frank!
Danke :-)
> if (irmp_data.address == 19)
Besser:
> if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)
So kann Dir keine andere FB, die auch die Adresse 19 (aber ein anderes
Protokoll) hat, dazwischenfunken.
> Dafür ist ja IRMP_FLAG_REPETITION da (siehe Codeschnipsel). Allerdings> habe ich so umgekehrt das Problem, wenn ich gerade mal eine Taste> mehrmals schnell hintereinander drücken will (für track skippen oder> Ähnliches), scheinen Telegramme verloren zu gehen, nicht jeder> Tastendruck wird erkannt. Woran kann das liegen?
IRMP unterscheidet über die Konstante
IRMP_KEY_REPETITION_LEN
in irmp.c, ob es sich um eine schnell gedrückte Wiederholungstaste
handelt oder ob die FB selbst "repetiert" - durch langen Tastendruck.
Offenbar schaffst Du es, innerhalb von 150msec die Taste mehr als einmal
zu drücken... Du bist da ganz schön schnell :-)
Verkleinere den Wert einfach mal - z.B. von 150.0 auf 120.0 oder 100.0.
> Ich denke idealer Weise an folgende Lösung: Kannst Du denn deinem> Programm nicht ähnlich der Pollin IR-Tastatur beibringen, nach> losgelassener Taste dem Kommando das 8. Bit hinzuzufügen (oder> beliebiger fester Wert >0x80, mich interessiert nicht unbedingt *welche*> Taste losgelassen wurde, sondern dass eine losgelassen wurde)?
Das würde ich ungern machen wollen. Es gibt nämlich durchaus FBs, die
16-Bit-Kommandos rausschicken, da bräuchte ich dann ein 17. Bit.
Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im
IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang
gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und
entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit
nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag
setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen
Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das
Toggle-Bit.
Ich schaue mal, dass ich das am Wochenende so einbaue. Du könntest
parallel dazu aber mal den Wert der Konstanten IRMP_KEY_REPETITION_LEN
testweise herabsetzen und hier berichten.
Gruß,
Frank
P.S.
Hast Du ein Schaltbild zu Deiner Lösung? Ich habe mit den
AT90USB-Dingern noch nie was gemacht. Vielleicht wäre das ja eine
Erwähnung im IRMP-Artikel wert....
Frank M. schrieb:> Was ich besser fände: Bei RC5 und RC6 gibt es das sog. Toggle-Bit im> IR-Frame. Dieses könnte ich im IRMP auswerten, ob eine Taste lang> gedrückt wurde oder ob der Anwender diese kurz gedrückt hatte und> entsprechend das Repetition-Flag setzen. Ändert sich das Toggle-Bit> nicht und bleibt der Code derselbe, würde ich dann das Repetition-Flag> setzen - unabhängig von IRMP_KEY_REPETITION_LEN (was ich für die anderen> Protokolle aber weiterhin benötige!). Im Moment ignoriert IRMP das> Toggle-Bit.
das sieht nach meinem "alten" Problem aus, hatte ich ja auch schon mal
gewünscht, evt. kommts doch noch in IRMP, dann kann ich endlich die RC5
ISR rauswerfen :-)
jar schrieb:> das sieht nach meinem "alten" Problem aus,
Nicht ganz: Du hast dir immer gewünscht, dass Dir IRMP das Toggle-Bit
liefert, damit Du den Code nicht umschreiben musst. ;-)
Sorry, das werde ich nicht machen. Ich brauche eine Lösung für alle
von IRMP unterstützten Protokolle. Ich kann für RC5/RC6 das Toggle-Bit
auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.
Frank M. schrieb:> Ich kann für RC5/RC6 das Toggle-Bit> auswerten, um das Repetition-Flag korrekt zu setzen... aber mehr nicht.
das würde ja reichen :-)
aber wie der letzte User das beschreibt erinnert mich genau ! an mein
Problem mit der Auswertung, hab ich ja deutlich genug beschrieben, wir
dokterten ja auch gemeinsam mit allen möglichen Ideen rum, nur nix half
es ist doch so das entweder noch Repeatcodes im Buffer liegen und
nachgeliefert werden auch wenn die eigendliche Aktion schon gelaufen ist
oder wie auch immer, mit 1x drücken bekomme ich entweder kein Licht an
oder gleich wieder aus weil mir das toogle Bit fehlt, nur deswegen
bedine ich meinen Timer ja mit RC5 und werte die Bedienung mit RC5 aus,
an dieser Stelle ist IRMP nur gut um Codes zu liefern (hört sich jetzt
härter an als es gemeint ist !
ne wirklich, finde IRMP gut nutze es auch gerne, nur du wolltest vor
Monaten mal meine Code durchgucken warum ich mit IRMP nicht bedienen
kann, der mit RC5 prima läuft.....
>Besser:>>> if (irmp.protocol == IRMP_RC5_PROTOCOL && irmp_data.address == 19)
Stimmt!! :))
Ich bin tatsächlich ein schneller Drücker! Ich habe
IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen
Tastendrücken kaum noch ein Problem. Interessanter Weise wird das
IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb
der 117,zerquetschte ms liegt. Vielleicht hält aber auch mein Sender den
RC5 nicht zu 100% ein, müsste ich mal mitm Oszi kontrollieren. Ich nehme
das jetzt mal so hin.
Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das
repetition flag funktioniert. Andererseits hilft es mir nicht bei der
Aussage, wie lange eine Taste gedrückt gehalten wurde repektive wann sie
losgelassen wurde.
Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte
ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen
Tastendruck auszuwerten. Wenn ich jedoch Null erhalte, setze ich auch
meine Variable "Taste" auf Null. Mein Programm kann somit nicht ohne
selbst mitlaufendem Timer erkennen, ob eine Taste nicht mehr gedrückt
wird. Und dieser Timer erzeugt ei mir die eingangs schon erwähnte
merkliche Latenz beim Loslassen.
narkus schrieb:> Ich bin tatsächlich ein schneller Drücker! Ich habe> IRMP_KEY_REPETITION_LEN auf 100.0 gesetzt, und habe mit schnellen> Tastendrücken kaum noch ein Problem.
Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt, die das
RC5-Toggle-Bit als zusätzliches Kriterium heranzieht, ob eine Taste lang
oder kurz gedrückt wurde.
Bitte teste das nochmal mit dem alten Wert von IRMP_KEY_REPETITION_LEN =
150. Es sollte nun für RC5 auch mit dem 150er Wert zuverlässig
funktionieren. Die 150msec brauche ich nämlich für diverse andere
Protokolle, ich kann es also nicht pauschal auf 100 setzen.
> Interessanter Weise wird das> IRMP_FLAG_REPETITION noch richtig gesetzt, obwohl dieser Werte unterhalb> der 117,zerquetschte ms liegt.
Die 150msec beschreiben den Abstand zwischen 2 Frames - exkl. dem 1.
Frame. Bei der RC5-Repetition-Time von ca. 115msec, die man in diversen
Quellen findet, ist mir nicht ganz klar, ob der 1. Frame mitgestoppt
wird, z.B. hier:
http://users.telenet.be/davshomepage/rc5.htm> Vielleicht hält aber auch mein Sender den RC5 nicht zu 100% ein,> müsste ich mal mitm Oszi kontrollieren.
Könnte auch sein. Wäre prima, wenn Du das mal nachmessen würdest.
> Toggle Bit ist zwar nett, aber einerseits brauche ich es nicht, wenn das> repetition flag funktioniert.
Das Toggle-Bit bekommst Du auch nicht zu sehen. IRMP zieht es nun aber
als zusätzliches Kriterium hinzu, um zu entscheiden, ob eine Taste lang
oder mehrfach kurz gedrückt wurde.
> Das Problem liegt darin, dass die Funktion irmp_get_data() Nullwerte> ausgibt, owohl sie eigentlich gerade dabei ist, einen möglichen langen> Tastendruck auszuwerten.
Was sollte sie dann machen? Hängen und warten, bis der Frame komplett
angekommen ist?
Ich könnte eine Funktion
irmp_busy ()
bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame
eingelesen wird.
Ein irmp_get_data(), welches blockiert, bis der Frame komplett ist,
halte ich für nicht notwendig. Dies kann man einfach mit:
Frank M. schrieb:> Ich könnte eine Funktion>> irmp_busy ()>> bereitstellen, die TRUE zurückliefert, wenn gerade ein neuer Frame> eingelesen wird.
wäre auch toll
oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste
erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht
ein neuer Tastendruck im Buffer lauert ?
jar schrieb:> oder gibt es eine Möglichkeit den Buffer zu leeren wenn eine Taste> erkannt wurde ? damit wenn ich die Taste auswerte und interagiere nicht> ein neuer Tastendruck im Buffer lauert ?
Könnte man natürlich auch einbauen. Die meisten Frames dauern ca. 30 -
40 msec. Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da
alles in der Zwischenzeit machen willst? ;-)
Frank M. schrieb:> Das ist doch eine halbe Ewigkeit, ich frage mich da, was Du da> alles in der Zwischenzeit machen willst? ;-)
nun ja ich will nur das mein Programm funktioniert, mit jeder FB nicht
nur mit RC5
eigendlich ganz einfach, man drückt doch solange die Taste bis das
gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht
das dann das Licht wieder ausgeht weil noch was nachkommt, kürzer
drücken geht nur wenn man weiss das der Code ankommt, aber die
Rückmeldung ist doch Licht an, ich hoffe du verstehst warum das toogle
Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ,
nach Erkennung Buffer leeren bis zur nächsten Abfrage.....
jar schrieb:> eigendlich ganz einfach, man drückt doch solange die Taste bis das> gewünschte eintritt, z.B. Licht an dann lässt man los, will aber nicht> das dann das Licht wieder ausgeht weil noch was nachkommt,
Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem
Repetition-Flag - fertig.
> ich hoffe du verstehst warum das toogle> Bit recht nützlich ist im RC5, das macht es einem leichter, alternativ,> nach Erkennung Buffer leeren bis zur nächsten Abfrage.....
Naja, um das Toggle-Bit auszuwerten, brauchst Du immer den letzten und
den aktuellen Zustand des Toggle-Bits, um diese dann beide zu
vergleichen. Mit dem Repetition-Flag von IRMP ist es noch einfacher:
Wenn gesetzt, handelt es sich um einen langen Tastendruck -> wegwerfen,
fertig. Dass IRMP intern(!) genau das Toggle-Bit (bei RC5) dafür
auswertet, um das Repetition-Flag zu setzen, muss Dich als IRMP-Anwender
nicht kümmern.
Frank M. schrieb:> Das ist doch einfach: Du ignorierst einfach alle Frames mit gesetztem> Repetition-Flag - fertig.
sagst du, aber das hatten wir doch alles schon durch und es lief nicht
(wie gewünscht)
ich weiss ehrlich nicht warum du das immer wieder widerholst, entweder
IRMP liefert das richtige Tooglebit was im RC5 ja vorhanden ist
transparent durch oder man muss dafür eben wie ich es nun mache in der
ISR RC5 und IRMP laufen lassen......
klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber
nur deswegen ein geliefertes Toogle Bit zu repaet frames zu übersetzen
und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du
hast da einen ganz schönen Dickkopf
ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es
doch einfach durch und/oder gib uns ne leere_buffer Routine die auf
Wunsch alles cleart
jar schrieb:> sagst du, aber das hatten wir doch alles schon durch und es lief nicht> (wie gewünscht)
Das läuft bei Dir nur deshalb nicht, weil Du Deinen Source nicht
umschreibst und stattdessen versuchst, aus den IRMP-Daten (die nicht
mehr protokollspezifisch sind) wieder RC5-Daten zu konstruieren - und
das auch noch unzureichend.
> ich weiss ehrlich nicht warum du das immer wieder widerholst, [...]
Ich wiederhole mich immer wieder, weil Du Dich immer wiederholst. IRMP
arbeitet korrekt, Du wendest aber IRMP nicht korrekt an! Solange Du
immer wieder und wieder auf dem Toggle-Bit rumreitest, werde ich wieder
und wieder das Repetition-Flag hervorkramen - ganz einfach :-)
Denk einfach daran: die Mehrheit aller anderen IR-Protokolle hat
überhaupt kein Toggle-Bit. Und trotzdem funktioniert es.
> klar verstehe ich deinen Wunsch IRMP für alle gleich zu behandeln, aber> nur deswegen ein geliefertes Toogle Bit zu repaet frames zu übersetzen> und das toogle Bit zu unterschlagen kann auch nicht so richtig sein, du> hast da einen ganz schönen Dickkopf
Das Toggle-Bit gehört nicht in die IRMP-Daten. Soll ich mir das dann für
die anderen 30 IR-Protokolle aus den Rippen schneiden?!?
Du hast den Dickkopf: Du reitest auf dem Toggle-Bit herum, weil Du zu
faul bist, Deinen Code, der RC5-Spezifika nutzt, portabel umzuschreiben.
Was willst Du denn in 5 Jahren machen, wenn es keine RC5-FB mehr gibt?
> ich möchte doch nix exotisches, im RC5 steckt das toogle Bit, reiche es> doch einfach durch [...]
Nein, wenn ich es durchreiche, würde ja jeder zweite identische
Tastendruck unterschiedliche IRMP-Daten liefern.
> und/oder gib uns ne leere_buffer Routine die auf Wunsch alles cleart
Hier hast Du sie:
Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers
auf einen PC zu Implementieren und die Bitmuster über USB-IR
Sender/Empfänger zu senden/empfangen
Würde gerne verschiedene Fernseher über einen zentralen Server steuern
und hierzu einen USB-IR Sender verwenden welche ich direkt bei der
IR-Empfangsfenster beim Fernseher anbringe.
PimmingerA schrieb:> Sieht wer eine Möglichkeit genau die Funktion des Senders & Empfängers> auf einen PC zu Implementieren und die Bitmuster über USB-IR
will ich auch hier gibt es irgenwo einen Thread IRMP mit USB
wenn ich mich richtig erinnere so als USB RS232 Umsetzer
Atmel mit USB Clientfunktion zu RS232 Umsetzer gibts ja schon, die
Treiber für win gibts auch, braucht man nur RS232 Codes an die virtuelle
COM zu schicken, bzw gleich IRMP im Atmel zu integrieren und zu senden
vom PC schickt man nur das Byte Protkoll, Adress, Command
nur mir fehlte bis jetzt noch die Zeit mich da einzulesen unbd das zu
bauen
evt. schaust du mal und meldest rück ?
ist leider nur Receiver ?
wir brauchen ja IRSND
IRMP + IRSND in einem Atmel zu bringen geht ja
USB zu RS232 Umsetzer auch
beides zusammen sollte auch gehen, vom PC angesprochen als virtuelle COM
nur das wir im Atmel nix mehr an die serrielle Schnitte RX + TX ausgeben
und empfangen, stattdessen IRMP und IRSND nutzen
Idee im Kopf fertig, nur noch nicht in echt
ggffs könnte man Fertigmodule umbauen RS232 Pegelwandler auslöten, IR
Sende Diode und TSOP einbauen, müsste halt nur Atmel basierend sein und
genügend Codeplatz und ISP Schnitte haben
Robert (mein Sohn) und ich hatten mal für die DIY-Fernbedienung
(basierend auf IRMP/IRSND)
http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP
testweise ein Kommando-Interface geschrieben, was über die UART lief -
aber nicht veröffentlicht.
Das Schaltbild könnte man dann vereinfachen auf:
1. TSOP an ATMEGA zum Empfang der Codes über IRMP
2. Transistor + IR-Sendediode an ATmega für IRSND
Eine kleine EXE, die dann das Protokoll, Adresse und Kommando über UART
an den ATmega schickte, hatten wir damals auch schon programmiert.
Wir hatten das nur noch nicht veröffentlicht, weil wir eigentlich für
den PC noch eine GUI schreiben wollten, damit man sich selbst eine
persönliche Fernbedienung unter Windows "zusammenklicken" kann. Dazu war
aber noch keine Zeit bisher.
Ich kann das heute abend mal raussuchen und hier einstellen. Die
aktuelle EXE will einfach Protokoll-Nummer, Adresse, Kommando und
Wiederholungsfaktor als Argument.
Gruß,
Frank
Wenn ich Euch richtig verstanden habe, dann wollt ihr über die
USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und
dort dann das Timing im MC erzeugen und über einen Pin auf die
IR-Endstufe ausgeben?
Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es
um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm
machen und runterschicken - funktioniert dies auch oder hat da wer eine
Ahnung?
PimmingerA schrieb:> Wenn ich Euch richtig verstanden habe, dann wollt ihr über die> USB-Schnittstelle des PCs nur die Daten runterschicken auf einen MC und> dort dann das Timing im MC erzeugen und über einen Pin auf die> IR-Endstufe ausgeben?
Jepp.
> Ich wollte mir die Elektronik ersparen und einen USB-IR-Converter den es> um 10-20 Euro gibt an den PC anschließen und das Timing im PC-Programm> machen und runterschicken - funktioniert dies auch oder hat da wer eine> Ahnung?
Hast Du mal einen Link oder Schaltplan von diesem "USB-IR-Converter",
dass man das mal nachlesen kann? Kann funktionieren, kann auch nicht. Ob
Du unter Windows hinreichend genaue Timings hinbekommst, kann ich nicht
sagen.
Für die PC -> µC Lösung braucht man:
1. ATmega88 oder ATmega168
2. Transistor + IR-Diode
3. TSOP
4. Ein paar Kondensatoren + Widerstände
Alles in allem macht das ungefähr einen Preis von ca. 5 Euro - ohne das
Stückchen Lochrasterplatine ;-)
Achja, man braucht noch einen USB->UART-Wandler, z.B. diesen hier:
http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024
Ich wollte einen Standsender oder Empfänger von HAMA hernehmen ... da
gibt es vom Hersteller natürlich keine Schaltpläne ;O)
Aber ich werde es nun eh über ein kleines MC-Interface lösen, da mein
Gefühl mir sagt, dass ich da das Timing besser im Griff habe.
Ich werde einen ATMEGA8 PDIP verwenden - hier ist die USB-Schnittstelle
mit ein paar BauteilenWorkAround schon dabei - dann brauche ich den
USB/UART Umsetzer nicht oder?
Dann werde ich 2 Pins brauchen für Sender und Empfänger - so wie von Dir
beschrieben.
Den Source Deines Exe-files wäre toll - bzw. die Tabellen der ganzen
Codec-Daten ;O)
IRMP braucht für alle Protokolle ca 4k IRSND dito wenn ich das richtig
überschlagen habe
auf Platine bauen hab ich keinen Lust, deswegen denke ich an Pollin
RS232 BAS Wandler 10 €
anstelle der RS232 Buchse und Wandlerchip USB mit Schutzdioden und R
anstelle das BAS Ausgang TSOP Trasi und IR Sendediode
nur wird das Modul nur mit mega8 geliefert, kein Platz mehr für den
V-USB, evt. Chip größer wählen, oder AVR Net I/O 20 € dann könnte man
die Codes auch über Router schicken ohne PC oder eben USB Stecker und
Beschaltung nachfrickeln, da ist ein mega32 drauf Platz genug
was benötigt v-usb an SW Platz ?
Hey Frank!
So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code
getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll!
Super!! :)
So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden
Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten
erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.
Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben,
so kann ich dann gesichert meine variablen zurücksetzen, wenn
tatsächlich kein Empfang mehr stattfindet, sprich keine Taste egal ob
kurz oder lang gedrückt wurde. Mein Code könnte dann so aussehen:
1
if(irmp_get_data(&irmp_data))
2
{
3
if(!irmp_data.busy&&(irmp_data.protocol==IRMP_RC5_PROTOCOL)&&(irmp_data.address==19))// << Hier mitprüfen, ob busy
Frank M. schrieb:> Ich habe nun ins SVN eine neuere Version von IRMP eingecheckt
ich hab auch mal wieder geschaut, komme am IRMP grad nicht weiter, macht
aber nix
doofe Frage,
wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss
man im quelltext nie ändern
eine weitere Funktion im IRMP.C
char *get_irmp_prot_str(protokoll)
könnte das dann immer liefern
warum diese Version ? c erlaubt doch
sei();
???
#asm("sei");
was bringt der ASM als Vorteil ?
jar schrieb:> wäre es nicht möglich den proto_str in die IRMP.C einzubinden, dann muss> man im quelltext nie ändern
Nein, ganz im Gegenteil: Da er nur im Codevision-Teil des
IRMP-Demo(!)programms main.c steht, fliegt er demnächst komplett raus.
Der Protokoll-Name als String ist nicht Bestandteil der IRMP-LIB.
Vergleiche macht man mittels:
1
if(irmp_data.protocol==IRMP_NEC_PROTOCOL)
2
{
3
...
4
}
und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich
Dir vor Monaten schon mal gesteckt ;-)
Frage: Benutzt Du den Codevision-Compiler?
> eine weitere Funktion im IRMP.C> char *get_irmp_prot_str(protokoll)
Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden. Die
Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da
aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich
auch nicht ein, die Strings zum Bestandteil der Lib zu machen.
> warum diese Version ? c erlaubt doch> sei();
Ja, klar, wird auch so genutzt, siehe AVR-GCC-Teil von main.c.
> #asm("sei");
Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern
von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert
hat. Offenbar kennt der Codevision-Compiler kein sei().
> was bringt der ASM als Vorteil ?
Dass er auch für Codevision funktioniert.
Aber warum machst Du da dauernd im Codevision-Teil rum? Die
Codevision-Unterstützung werfe ich sowieso demnächst raus, da ich keinen
Codevision-Compiler habe.
Gruß,
Frank
narkus schrieb:> So, war länger nicht dabei. Also, ich habe jetzt den aktuellen Code> getestet und das mitm RC5 läuft jetzt mitm 150er Wert so wie es soll!> Super!! :)
Freut mich.
> So ein busy wäre sehr sinnvoll. Sonst kann ich keinen lang anhaltenden> Tastendruck erkennen, ohne dass ich parallel einen Timer des letzten> erkannten Empfangs mitlaufen lasse. Gerne auch als Flag.
Was soll IRMP zwischen 2 Frames zurückliefern? Jede FB macht auch bei
lang anhaltender Taste Pausen zwischen den Frames.
Stell Dir folgende Situation vor:
A1. FB sendet ersten Frame
A2. IRMP liest ersten Frame ein
A3. Applikation holt ersten Frame ab
A4. FB macht eine Pause von ca. 40 msec
A5. FB sendet zweiten Frame
A6. IRMP liest ersten Frame ein
A7. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.
Wenn ich nun ein busy-Flag einbaue, passiert folgendes:
B1. FB sendet ersten Frame
B2. IRMP setzt Busy-Flag
B3. IRMP liest ersten Frame ein
B4. IRMP setzt Busy-Flag zurück
B5. Applikation holt ersten Frame ab
B6. FB macht eine Pause von ca. 40 msec
B7. FB sendet zweiten Frame
B8. IRMP setzt Busy-Flag
B9. IRMP liest ersten Frame ein
B10. IRMP setzt Busy-Flag zurück
B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.
Problem ist die Zeit zwischen B5 und B7, da ist das Busy-Flag nicht
gesetzt! Hilft Dir das weiter?
> Solange IRMP was tut, sollte irmp_get_data() weiterhin TRUE zurückgeben,
Sorry, das geht nicht, denn damit würde irmp_get_data()
aufruf-inkompatibel zu bisherigen Versionen werden. Bisherige Programme,
die IRMP verwenden, müssten alle in ihrer Logik umgeschrieben werden.
Ich kann Dir höchstens eine Funktion irmp_is_busy() anbieten, die TRUE
oder FALSE zurückliefert. Aber erst müssten wir klären, in welchem State
diese Funktion was zurückliefert.
Gruß,
Frank
Frank M. schrieb:> und nicht mittels strcmp() auf einen Protokollnamen! Aber das habe ich> Dir vor Monaten schon mal gesteckt ;-)
das mache ich doch nicht (mehr) aber als IR Tester gebe ich natürlich
den Protokollnamen aufs LCDaus !
> Frage: Benutzt Du den Codevision-Compiler?
nö !
>> eine weitere Funktion im IRMP.C>> char *get_irmp_prot_str(protokoll)> Nein, kostet nur jede Menge Flash, die unsinnig verbraten werden.
OK muss ! ich akzeptieren
> Protokoll-Strings sind nur sinnvoll für die Ausgabe auf einem LCD. Da> aber die LCD-Routinen auch nicht Bestandteil der IRMP-Lib sind, sehe ich> auch nicht ein, die Strings zum Bestandteil der Lib zu machen.
na ja, kann man auch anders sehen, als IR Tester ist für mich der
Protokollname Bestandteil der IRMP, könnte man mit #if define LCD_H
einbinden
> Du bist im Codevision-Teil von main.c. Der stammt nicht von mir, sondern> von Klaus Leidinger, der damals mal das main.c auf Codevision-C portiert
da bin ich grad wieder irrtümlich reingerutscht zwischen 2 Tätigkeiten,
ich finde es gut wenn die coderversion endlich rausfliegt, dann
entfallen derlei Irrtümer
danke jar
Neue Version IRMP und IRSND im SVN:
1. Unterstützung von ATtiny85 (bisher nur ATmegas)
2. Codevision-Unterstützung gelöscht
3. Array von IRMP-Protokollnamen zur Verfügung gestellt
4. Kleinere Bugfixes
@jar:
Um auf die Protokollnamen zugreifen zu können, muss
#define IRMP_PROTOCOL_NAMES 0 // 1: access protocol names, 0: do not (default),
auf 1 gesetzt werden. Dies verbraucht im Moment noch ca. 300 Bytes RAM,
da die Strings noch nicht als PROGMEM gespeichert werden.
Man kann dann mit irmp_protocol_names[irmp_data.protocol] auf den
Protokollnamen zugreifen. Die Protokollnamen wurden so gekürzt, dass sie
die Länge von 8 nicht überschreiten.
Gruß,
Frank
Frank M. schrieb:> Neue Version IRMP und IRSND im SVN:>> 1. Unterstützung von ATtiny85 (bisher nur ATmegas)
Hallo Frank, hast du auch ein funktionierendes Projekt für einen
ATtiny85?
Ich habe momentan mit dem aktuellen Projekt aus dem SVN und einen Tiny45
nur den Pin von PB6 auf PB4 geändert und eine LED an PB0, die an gehen
soll, wenn etwas erkannt wird. Am Oszi kann ich sehen, dass der TSOP
funktioniert, aber die LED geht nie an :(
Fuses habe ich auf interne 8MHz (Divider/8 aus).
meine main:
1
int
2
main(void)
3
{
4
IRMP_DATAirmp_data;
5
6
irmp_init();// initialize irmp
7
DDRB|=(1<<PB0);
8
timer1_init();// initialize timer 1
9
sei();// enable interrupts
10
11
for(;;)
12
{
13
if(irmp_get_data(&irmp_data))
14
{
15
PORTB|=(1<<PB0);
16
// ir signal decoded, do something here...
17
// irmp_data.protocol is the protocol, see irmp.h
18
// irmp_data.address is the address/manufacturer code of ir sender
19
// irmp_data.command is the command code
20
// irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
21
}
22
}
23
}
Hast du eine Idee an was es liegen kann? Habe alle Protokolle und mit 3
verschd. FB ausprobiert.
Danke im Vorraus!
73 DL3YC
Hallo Sebastian,
Sebastian Weiß schrieb:> Fehler gefunden: es fehlt die ISR in der main!
Sorry, die ISR hatte ich beim Rauswerfen der Codevision-Unterstützung
tatsächlich "wegoptimiert" - sprich versehentlich gelöscht. Ist nun
wieder drin.
Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny
funktioniert, denn meines Erachtens war da noch ein
Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt
hier einen Prescaler von 4 und nicht von 2.
Kannst Du mal Deine timer1_init()-Funktion zeigen? Ich habe jetzt
folgende im SVN eingecheckt:
1
void
2
timer1_init(void)
3
{
4
#if defined (__AVR_ATtiny85__) // ATtiny85:
5
OCR1A=(F_CPU/F_INTERRUPTS/4)-1;// compare value: 1/15000 of CPU frequency, presc = 4
6
TCCR1=(1<<CTC1)|(1<<CS11)|(1<<CS10);// switch CTC Mode on, set prescaler to 4
7
#else // ATmegaXX:
8
OCR1A=(F_CPU/F_INTERRUPTS)-1;// compare value: 1/15000 of CPU frequency
9
TCCR1B=(1<<WGM12)|(1<<CS10);// switch CTC Mode on, set prescaler to 1
10
#endif
11
12
#ifdef TIMSK1
13
TIMSK1=1<<OCIE1A;// OCIE1A: Interrupt by timer compare
14
#else
15
TIMSK=1<<OCIE1A;// OCIE1A: Interrupt by timer compare
16
#endif
17
}
Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11
wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu
bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das
zum Laufen zu bekommen. Kannst Du das so bestätigen?
Gruß,
Frank
Neue Versionen von IRMP und IRSND im SVN:
IRMP:
1. Unterstützung für ATtiny84 (zusätzlich zu ATTiny85) hinzugefügt.
2. Fehlende ISR in main.c wieder eingefügt
3. Div. Fehler in timer1_init korrigiert (für ATmega & ATTtiny)
IRSND:
1. Unterstützung für ATTiny84 und ATTiny85 hinzugefügt
2. Unterstützung der IR-Protokolle NEC16 und NEC24
Gruß,
Frank
Dirk W. schrieb:> Hmm, darf ich nach 4 Wochen mal vorsichtig fragen wie denn der Status zu> meiner Anfrage bzgl. Merlin Tastatur ist?
Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über
IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt
den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den
Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar
erwischt oder es handelt sich um einen Serienfehler. Letzteres würde
erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.
Ich kann da also nichts weiter machen. Da das Merlin-Protokoll vom
Startbit-Timing ähnlich zu anderen IR-Protokollen ist und daher immer
mal bei der Erkennung "dazwischenfunkt", wenn es aktiviert ist, habe ich
mich entschlossen, die Unterstützung für die Merlin-Tastatur komplett
aus dem IRMP herauszuwerfen. Vom Timing her arbeitet die Tastatur auch
nicht gerade sehr exakt, so dass ab und zu auch verschiedene Codes für
ein- und dieselbe Taste decodiert werden.
Fazit: Merlin fliegt raus.
Sorry,
Frank
Frank M. schrieb:> Ich habe am Wochenende einige Tests mit der Merlin gemacht.
Danke fürs Feedback, hatte schon gar nicht mehr damit gerechnet.
> ... Entweder habe ich da ein defektes Exemplar> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.
Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im
Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.
> Fazit: Merlin fliegt raus.
Sehr schade.
Dirk W. schrieb:> Hmm, seltsam. Ich und andere User auch, können die Merlin via lirc im> Rawmode ohne Probleme benutzen. Ich werde nochmal nachfragen.
Vielleicht ist wirklich nur meine Tastatur defekt. Ich meine, ich habe
irgendwo im Keller noch ein zweites Exemplar davon vergraben. Ich werde
das heute abend mal rauswühlen und damit nochmal testen.
> Sehr schade.
Okay, wenn es mit der Tastatur im Keller doch geht, dann baue ich es
wieder ein. Hast mich überredet, denn eigentlich ist das wirklich eine
niedliche Tastatur ;-)
Frank M. schrieb:> Ich habe am Wochenende einige Tests mit der Merlin gemacht. Wie ich über> IR_LOGGING per IRMP fesstellen konnte, gibt es einige Tasten, die exakt> den gleichen IR-Frame senden. Das war bei mir zum Beispiel bei den> Tasten "t" und "n" der Fall. Entweder habe ich da ein defektes Exemplar> erwischt oder es handelt sich um einen Serienfehler. Letzteres würde> erklären, warum Pollin diese Tastaturen zum Schleuderpreis anbietet.
Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche
nicht? Bei mir ist es so, dass noch nicht mal das Merlin Protokoll
erkannt wurde.
Hallo Frank,
Frank M. schrieb:> Trotzdem wundert es mich, dass es bei Dir nun auf dem ATtiny> funktioniert, denn meines Erachtens war da noch ein> Copy-and-Paste-Fehler meinerseits beim Setzen von TCCR1. Man benötigt> hier einen Prescaler von 4 und nicht von 2.> [...]> Wichtig sind hier die beiden Zeilen für den ATTiny85: Neben dem Bit CS11> wird auch noch CS10 im TCCR1-Register gesetzt, um den Prescaler auf 4 zu> bekommen. Eigentlich müsstest Du das auch so korrigiert haben, um das> zum Laufen zu bekommen. Kannst Du das so bestätigen?
Nein, ich habe sie unverändert übernommen, auch die F_INTERRUPTS sind
noch bei 15k.
Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim
Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas
ist.
Mein Wert mit Prescaler 2 ist mit OCR1A = (F_CPU / (2 * F_INTERRUPTS)
/ 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte
das anders sein?
Gruß Sebastian
Nachtrag:
meine Timer1_init():
1
void
2
timer1_init(void)
3
{
4
#if defined (__AVR_ATtiny45__) // ATtiny85:
5
OCR1A=(F_CPU/(2*F_INTERRUPTS)/2)-1;// compare value: 1/28800 of CPU frequency, presc = 2
6
TCCR1=(1<<CTC1)|(1<<CS11);// switch CTC Mode on, set prescaler to 2
7
#else // ATmegaXX:
8
OCR1A=(F_CPU/(2*F_INTERRUPTS))-1;// compare value: 1/28800 of CPU frequency
9
TCCR1B=(1<<WGM12)|(1<<CS10);// switch CTC Mode on, set prescaler to 1
10
#endif
11
12
#ifdef TIMSK1
13
TIMSK1=1<<OCIE1A;// OCIE1A: Interrupt by timer compare
14
#else
15
TIMSK=1<<OCIE1A;// OCIE1A: Interrupt by timer compare
Hallo Sebastian,
Sebastian Weiß schrieb:> Der Grund warum hier eine Veränderung benötigt wird ist doch, dass beim> Tiny Timer1 ein 8bit-Timer statt eines 16bit-Timers wie bei den Megas> ist.
Richtig.
> Mein Wert mit Prescaler 2 ist mit OCR1A = (F_CPU / (2 * F_INTERRUPTS)> / 2) - 1 rund 132 und passt somit in die 8bit Variable - warum sollte> das anders sein?
Ja. Aber wenn Du Dir die Zuweisung einmal genauer anschaust, steckt der
Faktor 2 zweimal drin. Also hat man faktisch einen Divisor mit dem Wert
4. Die obige Zuweisung ist also identisch mit:
1
OCR1A=(F_CPU/F_INTERRUPTS/4)-1;
Und damit müsste der Prescaler auch auf 4 gestellt werden, also:
1
TCCR1=(1<<CTC1)|(1<<CS11)|(1<<CS10);
statt
1
TCCR1=(1<<CTC1)|(1<<CS11);
damit auch der Prescaler von 4 rauskommt.
Oder habe ich da jetzt einen Denkfehler?
Gruß,
Frank
Dirk W. schrieb:> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche> nicht?
Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer
das Merlin-Protokoll.
Aber was auffiel:
1. Bei längerem Herunterdrücken einer Taste kippte ab und zu ein bit,
d.h. man erhielt dann bei den Wiederholungen einen anderen Code.
2. Manche Tasten sendeten denselben IR-Frame. Das führe ich mal auf
einen Defekt meiner Tastatur zurück, z.B. Kurzschluss in der
Tastatur-Matrix oder ähnliches.
> Bei mir ist es so, dass noch nicht mal das Merlin Protokoll erkannt wurde.
Doch, bei mir schon. Allerdings habe ich alle anderen exotischen
Protokolle abgeschaltet, also nur die Standard-Protokolle von SIRCS bis
DENON eingeschaltet und zusätzlich nur noch Merlin. Du kannst das ja
auch mal mit dieser Konstruktion testen. Ich kann mir durchaus
vorstellen, dass die anderen Exoten wie Ruwido und andere mit ähnlichem
Startbit-Timing stören könnten.
Frank M. schrieb:> Dirk W. schrieb:>> Ich muss nochmal nachfragen: wurde keine Taste erkannt oder nur manche>> nicht?>> Es werden bei mir eigentlich alle Tasten erkannt, auf jeden Fall immer> das Merlin-Protokoll.
Ok, danke für die Info.
Dann habe ich mit meinem V-USB Receiver wohl noch ein ganz anderes
Problem. Bei mir funktionieren auch keine Frequenzen > 10000, egal
welche Remote ich benutze. Ich frage mich jetzt doch, ob das ein
prinzipielles Problem des Portisch-Receivers ist.
Hallo Frank,
was du beschreibst ist logisch, aber trotzdem falsch.
Ich habe die neueste SVN-Version gezogen und probiert - es funktioniert
nicht.
Meine main():
1
int
2
main(void)
3
{
4
IRMP_DATAirmp_data;
5
6
irmp_init();// initialize irmp
7
DDRB|=(1<<PB0);// initialize LED
8
timer1_init();// initialize timer 1
9
sei();// enable interrupts
10
11
for(;;)
12
{
13
if(irmp_get_data(&irmp_data))
14
{
15
// toggle LED
16
if(PORTB&(1<<PB0))
17
PORTB&=~(1<<PB0);
18
else
19
PORTB|=(1<<PB0);
20
// ir signal decoded, do something here...
21
// irmp_data.protocol is the protocol, see irmp.h
22
// irmp_data.address is the address/manufacturer code of ir sender
23
// irmp_data.command is the command code
24
// irmp_protocol_names[irmp_data.protocol] is the protocol name (if enabled, see irmpconfig.h)
25
}
26
}
27
}
Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann
funktioniert alles soweit.
Kannst du dir das erklären?
Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl
Probleme, weil es auf der falschen Zeitbasis aufsetzt?
Nebenbei:
Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd.
FB.
NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht
erkannt. Auf einem 2. Board mit einem ATMega8 und Anzeige von Protokoll,
Addresse und Befehl per UART funktioniert die Erkennung dort.
Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS =
10000 geht SAMSUNG, aber NEC nicht mehr.
Ich probiere es weiter.
Gruß DL3YC
Hallo Sebastian,
Sebastian Weiß schrieb:> Ändere ich aber den Prescaler wieder zurück zu 2, also lösche CS10, dann> funktioniert alles soweit.> Kannst du dir das erklären?
Nein, das kann ich mir momentan überhaupt nicht erklären. Da mir aber
die ATTtiny85 ausgegangen sind, habe ich mir gestern neue bestellt, um
das selbst zu testen. Es muss ja eine Erklärung dafür geben.
Wahrscheinlich habe ich nur an der falschen Stelle im Datenblatt
geschaut.
> Nun möchte ich dazu auch IRSND benutzen, aber das hat dann wohl> Probleme, weil es auf der falschen Zeitbasis aufsetzt?
Nein, das sollte gehen. Du willst IRMP & IRSND verwenden? Dann muss die
ISR dafür so aussehen (s.a. IRMP-Artikel):
1
ISR(TIMER1_COMPA_vect)
2
{
3
if(!irsnd_ISR())// call irsnd ISR
4
{// if not busy...
5
irmp_ISR();// call irmp ISR
6
}
7
// call other timer interrupt routines...
8
}
Wenn dann noch die Konstanten F_INTERRUPTS in irmpconfig.h und
irsndconfig.h denselben Wert haben, ist alles perfekt.
> Ich habe NEC, SAMSUNG und RC5 aktiviert, also ich teste mit 3 verschd.> FB.> NEC und RC5 funktioniert(meine LED togglet). Aber SAMSUNG wird nicht> erkannt.
Hast Du mal SAMSUNG32 als alternatives Protokoll ausgewählt? Sonst
schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind. Wenn
es dann auch nicht geht, schalte IRMP_LOGGING an und schicke mir ein
paar Scans.
> Mit F_INTERRUPTS = 20000 geht dann auch RC5 nicht und mit F_INTERRUPTS => 10000 geht SAMSUNG, aber NEC nicht mehr.
In der Regel sind F_INTERRUPTS = 15000 die richtige Wahl.
Gruß,
Frank
Frank M. schrieb:> Sonst> schalte soviele Protokolle an, wie mit Deinem ATmega8 möglich sind.
PS ich hatte mal überschlagen, alle <= 15000 F_Interrupt Protokolle
brauchen ca 4k und für IRSND auch, reicht der ATmega8 oder braucht man
schon den 16 ?
hat einer einen Link für einen Adapter von ISP 6 auf ISP 10, meine Kabel
sind alle auf 10pol aber der letzte gekaufte hat 6pol mag keine neuen
Kabel bauen lieber einen Adapter Stecker ISP6 auf Kupplung ISP10
Nocheinmal Rückmeldung von mir:
Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem
ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode
habe ich gegen eine 950nm-IR-LED getauscht.
Vielen Dank für das tolle Projekt und den guten Support!
73! DL3YC
Sebastian Weiß schrieb:> Bei mir funktioniert jetzt alles wie gewollt (IRMP + IRSND) auf dem> ATtiny45. Einzige Änderung der Prescaler s.o. und meine IR-Sendediode> habe ich gegen eine 950nm-IR-LED getauscht.
Freut mich, dass es funktioniert. Aber ich muss da nochmal nachhaken:
Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im
Projekt eingetragen?
Gruß,
Frank
Frank M. schrieb:> Mit welcher Frequenz läuft Dein ATtiny? Was ist bei Dir als F_CPU im> Projekt eingetragen?
Beides 8 MHz. Ich kann es mir auch noch nicht erklären. Deswegen habe
ich gerade einen Test gemacht mit:
Per Fuse den Takt ausgegeben und gemessen - 8,74MHz.
In der Timer-ISR Pin togglen lassen und gemessen - 8,275kHz.
Pintogglen halbiert die Frequenz also sind es ~16,5kHz
Reale CPU-Frequenz / Timerwert(OCR1A) / Prescaler müsste 16,5kHz
ergeben.
8740000/133/2=32857 -> da stimmt was nicht!
Somit gibt es trotz einem Prescaler von 2 einen 15kHz Interrupt.
Gruß Sebastian
Sebastian Weiß schrieb:> Beides 8 MHz. Ich kann es mir auch noch nicht erklären.
Ich habe den Fehler gefunden. Fälschlicherweise habe ich das
OCR1A-Register auch beim ATtiny85 genommen, obwohl es hier das
OCR1C-Register sein muss. Bei Dir hat es nur deshalb funktioniert, weil
der errechnete Wert mit dem Prescaler 2 statt 4 ungefähr einen Wert von
256 (in Wirklichkeit 266) ergibt. Da das OCR1C-Register mit 0 vorbelegt
ist, hat der Timer immer bis 256 durchgezählt. Dadurch hattest Du dann
mit einer Abweichung von ca. 5 Prozent die "richtige" Abtastrate. Da
IRMP mit Toleranzen von bis zu 40% klarkommt, funktionierte das dann bei
Dir.
Hier der korrekte Code von timer1_init() für ATtiny85:
1
#if defined (__AVR_ATtiny45__) || defined (__AVR_ATtiny85__) // ATtiny45 / ATtiny85:
2
OCR1C=(F_CPU/F_INTERRUPTS/4)-1;// compare value: 1/15000 of CPU frequency, presc = 4
3
TCCR1=(1<<CTC1)|(1<<CS11)|(1<<CS10);// switch CTC Mode on, set prescaler to 4
4
....
Und jetzt passt das auch wieder zusammen mit dem Prescaler von 4.
Den Code im SVN habe ich korrigiert.
Gruß,
Frank
gera schrieb:> Gibt es auch ein Code für den C18 Compiler.
Bisher nicht. Der hardware-abhängige Teil beschränkt sich auf die Angabe
des input-Makros (s. irmpconfig.h) und der Definition des Timers.
Bekommst Du das hin? Wäre nett, wennn Du mir dann die Änderungen für den
PIC-C18-Compiler zur Verfügung stellen könntest.
Gruß,
Frank
Hallo,
Habe mal versucht den Code zu übersetzen.
Zwei Probleme:
1. Wie übersetze ich diese Zeile (input gibt es bei C18 nicht)
irmp_input = input(IRMP_PIN);
Mein Versuch ?
irmp_input = IRMP_PIN;
2. Die Input Pin
#define IRMP_PIN PIN_B4 // use PB4 as IR input on PIC
Mein Versuch:
#define IRMP_PIN LATBbits.LATB4 // use PB4 as IR input on PIC
oder evtl das hier ?
#define IRMP_PIN PORTBbits.RB4 // use PB4 as IR input on PIC
Was ist die richtige Übersetzung ?
So läuft schon mal bis jetzt der Compiler durch.
Zum Testen bin ich noch nicht gekommen.
Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine
eingebaut.
Passt das so ?
Benutze einen 18F2550 mit 20MHz Quarz.
Gruß
Hallo,
Compilieren kann ich es jetzt ohne Probleme.
Leider wird nichts erkannt.
Den Timer0 hab ich auf 10000Hz eingestellt, Timer0 Int funktioniert
soweit.
Muss ich irgendwo noch was eintragen ? CPU-Frequenz, ... ?
Oder kann man es einfach so benutzen.
Benutze Version 1.90
HW: 18F2550, Quarz 20Mhz, Takt 40Mhz
Gruß
gera
gera schrieb:> Den Timer0 habe ich auf 10000 Hz gestellt und eine INT Routine> eingebaut.> Passt das so ?
Hast Du auch F_INTERRUPTS in irmpconfig.h angepasst? Dort ist in der
SVN-Version standardmäßig 15000 als Wert eingetragen.
Gruß,
Frank
Im IRMP-Artikel
http://www.mikrocontroller.net/articles/IRMP
steht nun die Version 2.0.1 sowohl für IRMP als auch für IRSND zum
Download bereit. Diese Version entspricht der letzten SVN-Version. Somit
sind nun die Download-Dateien wieder zum SVN synchron.
Hier die Änderungen gegenüber der letzten Download-Version vom Januar:
IRMP:
- Neues Protokoll: KATHREIN
- Neues Protokoll: RUWIDO
- Neues Protokoll: THOMSON
- Neues Protokoll: IR60
- Neues Protokoll: LEGO
- Neues Protokoll: NEC16
- Neues Protokoll: NEC42
- Neues Protokoll: NETBOX (Prototyp)
- Portierung auf ATtiny84 und ATtiny85
- Verbesserung von Tastenwiederholungen bei RC5
- Verbessertes Decodieren von Bi-Phase-Protokollen
- Korrekturen am RECS80-Decoder
- Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol
IRSND:
- Neues Protokoll: THOMSON
- Neues Protokoll: LEGO
- Neues Protokoll: NEC16
- Neues Protokoll: NEC42
- Portierung auf ATtiny84 und ATtiny85
- Korrektur von Pausenlängen
- Korrekturen von irsnd_stop()
- Korrektur des SIEMENS-Timings
- Umstellung auf 36kHz Modulationsfrequenz für DENON-Protokoll
- Korrektur Behandlung zusätzlicher Bits im SIRCS Protokoll
Viel Spaß,
Frank
Hallo,
Nach langer Suche habe den Fehler gefunden.
War ein blöder Schreibfehler in einer define-Anweisung.
Funktioniert soweit mit Microchip C18 !
Vielen Dank für die Library !
Ich hab mir mal die 2.01 runtergeladen und werde die Änderungen in diese
Version einarbeiten.
Wo soll ich es dann schicken ?
Gruß
gera schrieb:> Nach langer Suche habe den Fehler gefunden.
Prima!
> Funktioniert soweit mit Microchip C18 !
Ich werde Deine Änderungen in den IRMP-Source übernehmen, vielen Dank.
> Wo soll ich es dann schicken ?
Da mich Deine Mail schon erreicht hat, hast Du meine Adresse offenbar
gefunden. Ich antworte Dir dort zu Deinem RC6-Problem.
vielen Dank erstmal für dieses Projekt, eine super Arbeit. Es hat auf
Anhieb funktioniert, eine Creative Fernbed. RM-1500 geht einwandfrei.
2 Fragen habe ich jedoch:
1. Ich habe eine JVC RM-SV511UE remote, von der ich gern das Steuerkreuz
nutzen möchte. Nur geht die right-Taste irgendwie überhaupt nicht, die
up/down/left/enter Tasten gehen einwandfrei:
down
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3358
irmp_data.flags : 0
up
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3342
irmp_data.flags : 0
left
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3374
irmp_data.flags : 0
enter
irmp_data.protocol: 20
irmp_data.address : 15
irmp_data.command : 3406
irmp_data.flags : 0
right
nichts
Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug?
Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.
2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP
interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin
change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder
ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder
wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die
state machine damit nicht klarkommt etc.
Vielen Dank für das tolle Projekt.
Gruß
Tom S. schrieb:> vielen Dank erstmal für dieses Projekt, eine super Arbeit.
Danke fürs Danke :-)
> Die Taste selbst sendet def. ein IR-Signal. Ist das ein bekannter bug?> Ansonsten kann ich gerne das Logging aktivieren falls das weiterhilft.
Ja, da bräuchte ich Logging-Daten. Am besten von allen 4 Richtungen des
Steuerkreuzes.
> 2. Ich möchte das ganze in ein RTOS integrieren und dazu den IRMP> interrupt erst einschalten wenn was am pin passiert, z.B. über einen pin> change interrupt, und nach ein paar Sek. Pause den IRMP interrupt wieder> ausschalten. Ist das prinzipiell mit dem vorliegenden code machbar, oder> wird es Probleme geben weil z.B. counter hochgezählt werden müssen, die> state machine damit nicht klarkommt etc.
Das müsste machbar sein. Schalte den Timer-Interrupt einfach beim ersten
Toggle ein und nach einer bestimmten Zeit wieder ab.
Gruß,
Frank
Hallo,
anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie
gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.
IRMP timer irq ist 14400 Hz.
Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich
dann also demnächst mal probieren.
Danke und Grüße
Hallo Tom,
Tom S. schrieb:> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.
Ich habe mir den Log eben angeschaut: Die Taste right sendet 17 statt 16
Bits. Da das JVC-Timing exakt dem NEC-Timing entspricht, startet IRMP
erstmal mit dem Protokoll NEC bei der Startbit-Erkennung. Kommt nach dem
16. Bit dann eine Pause (weil es eben JVC und nicht NEC ist), schaltet
IRMP auf JVC um. Das passiert aber leider nicht, wenn da statt der Pause
noch ein 17. Bit hinterhergeschickt wird.
Da muss ich mir etwas einfallen lassen, habe da auch schon eine Idee...
> IRMP timer irq ist 14400 Hz.
Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen
Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600
entspricht? ;-)
> Das Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich> dann also demnächst mal probieren.
Ja, finde ich spannend. Sollte meiner Meinung auch problemlos
funktionieren. Du könntest den Timer-Interrupt eigentlich auch sofort
abstellen, sobald IRMP den Frame erkannt hat und nicht erst nach einer
"gewissen" Zeit. Dazu müsstest Du aber in den IRMP-Source eingreifen.
Gruß,
Frank
Tom S. schrieb:> anbei der log für die JVC für alle 5 Tasten des Steuerkreuzes. Wie> gesagt, nur die Taste right liefert bei irmp_get_data() null zurück.
Im SVN ist nun eine neue Version, mit der jetzt auch die Taste "right"
erkannt wird. War doch etwas mehr Arbeit als ich dachte. Läuft aber
jetzt :-)
P.S.
Wenn Du Adresse und Code in Hex schreibst, wird die Systematik der
Tastencodes besser ersichtlich:
# up p=20 addr=0x000F cmd=0x0d0e
# down p=20 addr=0x000F cmd=0x0d1e
# left p=20 addr=0x000F cmd=0x0d2e
# right p=20 addr=0x000F cmd=0x0d3e
# enter p=20 addr=0x000F cmd=0x0d4e
Frank M. schrieb:> B1. FB sendet ersten Frame> B2. IRMP setzt Busy-Flag> B3. IRMP liest ersten Frame ein> B4. IRMP setzt Busy-Flag zurück> B5. Applikation holt ersten Frame ab> B6. FB macht eine Pause von ca. 40 msec> B7. FB sendet zweiten Frame> B8. IRMP setzt Busy-Flag> B9. IRMP liest ersten Frame ein> B10. IRMP setzt Busy-Flag zurück> B11. Applikation holt zweiten Frame ab, Repetition-Flag ist gesetzt.
Hmm, B4 (Busy-Flag zurücksetzen) ist eigentlich falsch. IRMP sollte busy
sein, solange ein wiederholter Tastendruck erkannt werden kann. Und das
ist frühestens nach 114 ms der Fall!
Wird auf der FB eine Taste gedrückt gehalten, so sollte eine RC5 FB alle
114 ms das Paket erneut senden. D.h. innerhalb dieser Zeit muss ich
davon ausgehen, dass die Taste noch gedrückt ist!
Somit darf das Busy-Flag frühestens nach 114 ms (geben wir paar Sekunden
Puffer drauf, für FBs, die sich nicht ganz daran halten) zurückgesetzt
werden!
Zur Sicherheit kann man das Toggle-Bit vergleichen, falls es jemand doch
schaffen sollte, innerhalb dieser Zeit diese Taste oder eine neue
gedrückt zu haben. ;)
Was meinst Du dazu?
Grüße
Hallo Frank,
danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die
right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine
Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt
gingen, negativ beeinflussen werden :)
Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP
wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des
Protokolls im Hause JVC.
>Wie kommt diese "komische" Zahl zustande? Benutzt Du vielleicht einen>Soft-UART mit einer Abtastrate von 28800, was einer Baudrate von 9600>entspricht? ;-)
Nein, hat nichts mit einer UART zu tun. Ich habe einen 14.7456 MHz Quarz
und wollte eine "glatte" interrupt Frequenz haben, also habe ich clk/8
verwendet und OCR0A auf 127 gesetzt :)
Enablen des IRMP Interrupts nur bei Infrarot-Aktivität werde ich am WE
probieren.
Danke und Grüße
Tom S. schrieb:> danke für prompte Änderungen. Ich kann bestätigen das jetzt auch die> right Taste geht (und mit hex siehst besser aus). Ich hoffe das Deine> Änderung der IRMP_TIMEOUT_TIME nicht andere remotes, die bis jetzt> gingen, negativ beeinflussen werden :)
Ich checke nach Source-Änderungen einen Großteil der Scans im Ordner
IR-Data unter Linux komplett durch, siehe IR-Data/test-suite.sh. Erst,
wenn alle Scans ohne Fehler erkannt werden, gebe ich die Software raus.
> Da es eine Original JVC remote ist und der bisherige JVC Teil in IRMP> wahrscheinlich gut getestet ist, gibt es wohl zumindest 2 Varianten des> Protokolls im Hause JVC.
JVC ist relativ spät dazugekommen, gibt es erst seit ein paar Monaten.
Also soooo gut getestet war es bisher nicht. Aber es sind tatsächlich
Differenzen im Protokoll-Verhalten zwischen den beiden
JVC-Fernbedienungen, deren Scans ich bisher erhalten habe. Das konnte
ich aber erst anhand Deiner Right-Taste erkennen.
Gruß,
Frank
Frank M. schrieb:> irmp_protocol_names[irmp_data.protocol]Frank M. schrieb:> @jar:>> Um auf die Protokollnamen zugreifen zu können, muss
hallo, bin grad wieder bei
muss nun mein code anpassen
kannst du evt. in irmp.h ein
#ifndef TRUE vor line 486 setzen ?
#ifndef FALSE
#define FALSE 0
#endif
#ifndef TRUE
#define TRUE !FALSE
#endif
oder liegt der Fehler bei mir
../irmp.h:486:1: warning: "TRUE" redefined
Hallo Frank,
meine programmierbare Fernbedienung mit 5" Touch-Screen ist fast fertig
und ich feile an den letzten Kleinigkeiten.
Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die
beide das SAMSUNG32 Protokoll verwenden.
Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn
meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV
Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange
drücken, bis diese vom TV aktzeptiert wird.
Problem 2: Beim hintereinander-senden von mehreren Befehlen (z.B. "2",
"4", "Enter" für die Anwahl des Programmes 24) wird nur der erste Befehl
vom TV aktzeptiert.
zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am
Ozszilloskop verglichen.
Mir sind folgende Unterschiede aufgefallen:
a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch
einzelne Frames, wenn man die Taste kurz genug drückt.
b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz.
IRSND=1450us, die Original-FB's haben 1680us und 1710us
c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz.
IRSND=450us, die Original-FB's haben 550us und 580us
Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und
_PULSE_TIME) stimmen aber exakt!
Ich habe also folgende Änderungen in irmp.h vorgenommen:
#define SAMSUNG_1_PAUSE_TIME 1700.0e-6 // 1700 usec pause
#define SAMSUNG_0_PAUSE_TIME 550.0e-6 // 550 usec pause
#define SAMSUNG32_FRAMES 1 // SAMSUNG32 sends each frame
1 time
Danach funktionierte meine FB wesentlich besser!
zu Problem 2: Ich konnte das Problem beheben, indem ich zwischen die
Sendebefehle eine 50ms Pause eingefügt habe.
In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als
fixed gepostet:
>> IRSND hat im Moment auch noch einen unschönen Bug, den ich dabei auch>> noch loswerden möchte: Nach Aussenden des gewünschten Frames wird die>> Pause-Zeit zum nächsten Frame nicht eingehalten, wenn man>> irsnd_send_data() direkt wieder aufruft. Innerhalb von flags > 0 wird>> das korrekt eingehalten, aber nach dem letzten gesendeten Frame kann man>> direkt wieder mittels irsnd_send_data() "feuern". Das ist unschön.> Diesen Bug habe ich nun auch gefixt. Ist zwar noch nicht optimal, aber> ich bin erstmal damit zufrieden. Die Pause wird nämlich erst dann> eingefügt, wenn auch tatsächlich ein 2. Frame auf die Reise geschickt> wird.
Kann es sein, dass noch nicht ganz funktioniert?
Viele Grüße
Cajus
frage zu IRSND
wo muss ich die CPU definieren ?
../irsnd.c:197:2: error: #error mikrocontroller not defined, please fill
in definitions here.
holt IRSND sich das nicht aus astudio win-gcc den projekt options ? da
hab ich doch die CPU gewählt
und wenn ich schon definieren muss, wie bitte ? für atmega1284p
|| defined (_AVR_ATmega1284P_) //
ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3
or OC0B = PB4
es fehlte der Prozessor 1284p
noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU
Definition der Port PD7 bekannt sein ? warum muss man den noch extra
eingeben ?
noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die
Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss
nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie
noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird
es auch so im Dir angezeigt
Joachim B. schrieb:> und wenn ich schon definieren muss, wie bitte ? für atmega1284p>> || defined (_AVR_ATmega1284P_) //> ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3> or OC0B = PB4>> es fehlte der Prozessor 1284p
Ja, den habe ich einfach vergessen. Eintragen und fertig:
1
#elif defined (__AVR_ATmega164__) \
2
|| defined (__AVR_ATmega324__) \
3
|| defined (__AVR_ATmega644__) \
4
|| defined (__AVR_ATmega644P__) \
5
|| defined (__AVR_ATmega1284__) \
6
|| defined (__AVR_ATmega1284P__) // ATmega164|324|644|644P|1284 uses OC2A = PD7 or OC2B = PD6 or OC0A = PB3 or OC0B = PB4
> noch eine kleine Anmerkung, sollte mit der Nennung OC2A und der CPU> Definition der Port PD7 bekannt sein ? warum muss man den noch extra> eingeben ?
Musst Du ja eben nicht. In irsndconfig einfach OC2A auswählen und
fertig. Über das obige #if in irsnd.c "weiß" dann der Compiler, welcher
Portpin verwendet wird.
> noch ne doofe Frage, in astudio und im Arbeitsdir, wechseln manchmal die> Dateinamen zu Uppercase Letter, das provoziert den c++ Fehler, ich weiss> nicht wieso alle meine Dateinamen manchmal groß werden, auch wenn sie> noch klein sind öffnet AStudio diese in Großbuchstaben und manchmal wird> es auch so im Dir angezeigt
Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade
um solche Probleme zu vermeiden.
Gruß,
Frank
Frank M. schrieb:> Ich habe alle IRMP-/IRSND-Sources mit Kleinbuchstaben angelegt, gerade> um solche Probleme zu vermeiden.
das habe ich auch, nur mein Problem ist ja das die urplötzlich groß
werden
ich vermute aber das passiert durch primalscript wenn ich ausserhalb vom
astudio mal eine *.c öffne
also wenns nicht astudio macht, dann wer anderes, ich wollte nur mal
hören ob den Fehler jemand kennt
Hallo zusammen
Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut
ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.
Ein wirklich schönes Projekt....
Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c
zu entfernen und insbesondere die input-Funktion ohne Parameter als
extern zu deklarieren. Dann muss auf jeder Platform nur noch eine
entsprechende Funktion generiert werden, und man muss weniger an irmp
ändern.
Dann ist mir noch aufgefallen, das die IRQ-Routine für mein Gefühl recht
viel Zeit beansprucht. 5-7us, damit verbraucht die IR-Erkennung bei
15000 IRQs/s etwa 10% der Rechenleistung des SAM7. Bei einem AVR sieht
das bestimmt noch schlechter aus(?)
Die Ethernut-Anbindung kann Ich auch an Interessiert weitergeben. Unter
www.klkl.de werde Ich in den nächsten Tagen eine Seite dazu schreiben.
Vielen Dank, irmp hat mich schnell an mein Ziel gebracht
Gruß Klaus
Hallo Joachim,
Joachim B. schrieb:> Build error weil :> (void) irsnd_send_data (&irmp_data, TRUE);
Stimmt, da habe ich vergessen, den Artikel anzupassen. Werde ich
nachholen.
> eine Idee warum der genau nach einmal Aufruf abstürzt ? hab ich was beim> Einbinden übersehen ?
Kann ich erstmal nicht sehen. Schickt er denn tatsächlich 1+5 Frames
raus, so wie du mit
> irmp_data.flags = 5; // keine Wiederholung!
eingestellt hast?
Am leichtesten siehst Du das, wenn Du Dir die IR-LED mit einer
Digitalkamera anschaust. Bei 6 Frames müsste es schon mehr als eine
halbe Sekunde flackern.
Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data()
macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)
Gruß,
Frank
Hallo Klaus,
Klaus Kloos schrieb:> Ich habe das irmp Projekt erfolgreich auf einem ARM SAM7x unter ethernut> ans laufen bekommen. Die minimalen Änderungen schicke Ich hier mit.
Vielen Dank für die Änderungen, werde ich in den IRMP-Source einbauen.
Leider hast Du Deine eigene Input-Funktion weggelassen, hätte mich schon
interessiert.
> Mein Vorschlag wäre es die Hardwareabhängigkeiten weitgehend aus irmp.c> zu entfernen und insbesondere die input-Funktion ohne Parameter als> extern zu deklarieren. Dann muss auf jeder Platform nur noch eine> entsprechende Funktion generiert werden, und man muss weniger an irmp> ändern.
Ich wollte eigentlich aus "Zeitgründen" vermeiden, eine externe Funktion
in der ISR dafür aufzufrufen. Ließe sich Deine input-Funktion nicht auch
als Makro in irmpconfig.h realisieren?
Gruß,
Frank
Frank M. schrieb:> Da ich nicht weiß, was das Programm nach Ausführen von irsnd_send_data()> macht, kann ich Dir auch nicht sagen, wo es danach abstürzt ;-)> Gruß,> Frank
bin einen Schritt weiter, kann mehrfach das Kommando mit KEY_ENTER
auslösen
mir fehlt im Moment noch ein 2ter IRMP Empfänger, deine Idee mit der LED
hatte ich schon umgesetzt, parallel zur IR ist eine UH rt LED zum
gucken, einmal hab ich die IR mit der Cam im Handy gecheckt, öfter tut
erst mal nicht Not
habe die Pollin RS232 zu FBAS bekommen, werde den ATmega 8 zu 168
tauschen und den TSOP und IR Dioden bestücken, RS232 zu USB nehme ich
die billigen 9,95 Teile, die aber nur 0 und +V liefern, doof mal sehen
ob RTS und DTR genug Strom liefern zum betreiben vons ganze, deswegen
wollte ich ja v-usb, da wäre der Strom gleich mitgekommen, aber den USB
Adapter aufbohren mag ich nicht
muss man eigendlich den Buffer leeren ? mit
1
while(irmp_get_data(&irmp_data));
kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR
Cams nachrüsten ?
Hallo Cajus,
Cajus H. schrieb:> Das aktuelle Problemkind sind zwei verschieden-alte Samsung LCD-TV, die> beide das SAMSUNG32 Protokoll verwenden.> Problem 1: Das von IRSND generierte Signal wird vom TV nur erkannt, wenn> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange> drücken, bis diese vom TV aktzeptiert wird.
Könnte das eine falsche Modulationsfrequenz sein? Die schlechte
Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei
den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz
sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten
im Internet finden konnte.
> zu Problem 1: Ich habe die Signale von IRSND und den Original-FB's am> Ozszilloskop verglichen.> Mir sind folgende Unterschiede aufgefallen:> a) IRSND sendet immer zwei Frames, die Fernbedienungen senden auch> einzelne Frames, wenn man die Taste kurz genug drückt.
Upps! Danke für die Info! Ich hatte bisher nur Samsung32-Scans bekommen,
wo immer 2 Frames hintereinander kamen. Die Leute drücken leider beim
Scannen meist länger die Taste, damit es auch "garantiert" ankommt. Hat
den Nachteil, dass ich dann falsche Schlussfolgerungen ziehe. ;-)
Also ist für SAMSUNG32 in
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail
der Eintrag
Wiederholung einmalig nach 45ms
falsch und es muss heißen:
Wiederholung keine.
> b) die Pause-Zeit für den Bitwert "1" von IRSND ist zu kurz.> IRSND=1450us, die Original-FB's haben 1680us und 1710us> c) die Pause-Zeit für den Bitwert "0" von IRSND ist zu kurz.> IRSND=450us, die Original-FB's haben 550us und 580us
Danke auch dafür, ich werde das mit den mir vorliegenden Scans
gegenprüfen. Ich habe da dieselben Werte wie für das SAMSUNG-Protokoll
angenommen, da es im Rahmen der Messungenauigkeiten war und sich
ansonsten das SAMSUNG- und das SAMSUNG32-Protokoll doch sehr ähneln.
> Die übrigen Zeiten aus den Definitionen in irmp.h (_START_BIT_xx und> _PULSE_TIME) stimmen aber exakt!
Und das ohne Dokumentation :-) Ich habe mir das Samsung32-Protokoll
nämlich lediglich anhand von Scans zusammengereimt.
> Ich habe also folgende Änderungen in irmp.h vorgenommen:> #define SAMSUNG_1_PAUSE_TIME 1700.0e-6 // 1700 usec pause> #define SAMSUNG_0_PAUSE_TIME 550.0e-6 // 550 usec pause> #define SAMSUNG32_FRAMES 1 // SAMSUNG32 sends each frame> 1 time> Danach funktionierte meine FB wesentlich besser!
Danke, ist aber die falsche Stelle, da sich damit auch die Timings für
das SAMSUNG-Protokoll (ohne 32) ändern. Tatsächlich muss ich da wohl
SAMSUNG und SAMSUNG32 vom Timing her trennen.
> In Deinem Beitrag vom 20.05.2011 11:43 hattest Du dieses Problem als> fixed gepostet:
Ja, das stimmt, hatte ich eigentlich gefixed... dachte ich jedenfalls
:-)
Werde ich aber nochmal überprüfen.
Viele Grüße,
Frank
Hallo Frank
Hier die wichtigsten Teile zu input-Funktion.
Für den Zeitbedarf ist es eigentlich unerheblich, ob eine externe oder
eine Funktion aus der gleichen Code-Datei aufgerufen wird. Der Linker
packt diese ja später zusammen, egal woher die Funktionen kommen. Der
Optimierer hat nur etwas schlechtere Chancen überflüssiges zu entsorgen.
Wenn man die input-Funktion als 'wie ist denn der Stand auf dem
IR-Eingang' versteht, dann kann dort der übergebene Parameter weg.
Ich betrachte irmp als autarkes Modul. Die Hardware-Abhaengigkeiten sind
bei mir im aufrufenden Thread. Um die Funktion in irmpconfig() mit
meiner input-Funktion ans compilieren zu bekommen müsste Ich dort wieder
Dateien für den SAM7 einbinden.
Vielleicht kann man ein define vorsehen, womit dann die input-Funktion
extern erwartet wird?
/*!
* \def IO_PIO_PDS_REG
* \brief Pin data status register of the button interface.
*/
#define IO_PIO_PDS_REG PIOB_PDSR
/*!
* \def IO_IR_BIT
* \brief used PIO bit. */
#define IO_IR_BIT 29
bei der Thread-Initialisierung
/* Initialize GPIO lines for IR-Read. */
outr(IO_PIO_PE_REG, IO_IR);
outr(IO_PIO_OD_REG, IO_IR);
outr(IO_PIO_PUE_REG, IO_IR);
/*!
* \brief hier die Funktion fuer irmp um den Status des IO-Pins zu
ermitteln
*/
uint8_t input(uint8_t test)
{
return ( (~inr(IO_PIO_PDS_REG) & IO_IR) == 0);
}
Gruß Klaus
Joachim B. schrieb:> @frank, hattest du das gelesen ?
Ja, habe ich eben gelesen.
> muss man eigendlich den Buffer leeren ? mit>
1
>while(irmp_get_data(&irmp_data));
2
>
Sollte man machen, wenn man dem User (z.B. fürs Anlernen) sagen will:
"Drücke JETZT Taste auf FB".
Dann sollte man irgendwelche Frames, die man sich DAVOR "eingefangen"
hat (z.B. weil die Freundin vorher ferngesehen hat) wegwerfen. Wenn Du
aber sowieso permanent in einer Endlosschleife irmp_get_data() aufrufst,
wäre oben genannte Zeile sinnfrei.
>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR>> Cams nachrüsten ?
Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in
den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber
nicht immer sind dafür Zeit und Lust vorhanden ;-)
Gruß,
Frank
Frank M. schrieb:>>> kannst du für IRSND noch die Codes für Sony Panasonic Canon Nikon DSLR>>> Cams nachrüsten ?>> Steht natürlich auf meiner TODO-Liste. Jedes Protokoll, welches ich in> den IRMP einbaue, will ich später dann auch in den IRSND einbauen. Aber> nicht immer sind dafür Zeit und Lust vorhanden ;-)>> Gruß,>> Frank
ja ist klar, meine todo ist auch länger als meine Zeit, brauchst du die
Parameter für die Cams ? ich hab im Moment nur Q&D Code erzeugt der
funktioniert, würde den gerne rauswerfen wenn IRSND eh schon drin
ist....
mangels aller IR Sender kann ich die logisch nicht in IRMP scannen
@ Frank
Frage zu IRSND irmp_data.flags steht ja für Wiederholungen,
offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen
6 Aussendungen bedeuten, mein TV Samsung32 hat aber jeweils nur 5 Prg
weitergeschaltet,
(immerhin wenn man 99 wiederholungen proggt kann man so schnell als
möglich zappen)
deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben
keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+
geschaltet und nicht 6
bin leicht verwirrt davon
der Absturz in meiner HW kann nur an der Dauer gelegen haben, bei 5
repeat wird mein(e) Interrupt(s) zu lange unterbrochen, da kommt alles
durcheinander
Joachim B. schrieb:> Frage zu IRSND irmp_data.flags steht ja für Wiederholungen,> offensichtlich bedeutet 0 eine Aussendung, also müsste 5 Wiederholungen> 6 Aussendungen bedeuten, [...]
Ja.
> mein TV Samsung32 hat aber jeweils nur 5 Prg weitergeschaltet,> (immerhin wenn man 99 wiederholungen proggt kann man so schnell als> möglich zappen)> deswegen war ich in dem Glauben 5 bedeutet 5x aussenden und 0 eben> keinmal, aber eben getestet, 0 bedeutet 1 Sendung aber 5 hat nur 5 PRG+> geschaltet und nicht 6
Wie schon Cajus in
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
andeutete, muss da wohl jeweils eine Zwangspause gemacht werden. Diese
wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft,
aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0
aufruft. Die von Cajus gemachten Verbesserungsvorschläge für SAMSUNG32
werde ich in den Source einarbeiten, Du kannst dies ja auch schonmal
parallel bei Dir machen.
Gruß,
Frank
Frank M. schrieb:> muss da wohl jeweils eine Zwangspause gemacht werden. Diese> wird zwar gemacht, wenn man irsnd_send_data() mit flags = 5 aufruft,> aber nicht, wenn man 6x hintereinander irsnd_send_data() mit flags = 0> aufruft.
da muss ein Verständnisproblem vorliegen
du schreibst die Zwangspause wird benötigt und gemacht für
"irsnd_send_data() mit flags = 5"
wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?
also 1 +5 Wiederholungen
"6x hintereinander irsnd_send_data() mit flags = 0"
hab ich nicht versucht, also kann deine Erklärung nicht passen ???
Joachim B. schrieb:> wenns so wäre warum dann nur 5 Weiterschaltungen und nicht 6 ?
Das weiß ich nicht. Vielleicht akzeptiert das Gerät nicht mehr als 5
Wiederholungen in so kurzer Zeit?
Gruß,
Frank
Frank M. schrieb:> Vielleicht akzeptiert das Gerät nicht mehr als 5> Wiederholungen in so kurzer Zeit?
das wäre ja leicht zu testen :-) mach ich am WE
mit FLAGS 1, FLAGS 2, FLAGS 3, FLAGS 4, FLAGS 5, FLAGS 6,
müsste ja 2, 3, 4, 5, 6, 7 Weiterschaltungen geben :-)
Hallo Frank,
>> ...Samsung LCD-TV, die beide das SAMSUNG32 Protokoll verwenden.>> Das von IRSND generierte Signal wird vom TV nur erkannt, wenn>> meine FB in geringem Abstand vor dem TV mit Zielfernrohr auf das TV>> Gerät gerichtet wird. Außerdem muss man jede Taste ziemlich lange>> drücken, bis diese vom TV aktzeptiert wird.> Könnte das eine falsche Modulationsfrequenz sein? Die schlechte> Reichweite spricht jedenfalls dafür. Kannst Du Modulationsfrequenz bei> den Original-Fernbedienungen mit einem Scope (o.ä.) messen? Die 38kHz> sind beim Samsung32-Protokoll nur "geraten", da ich darüber keine Daten> im Internet finden konnte.
nein, ich habe die Frequenzen überprüft. 37.3 und 37.5 kHz. Das scheint
mir innerhalb der Toleranz zu sein. Außerdem ist das Problem nach der
Timing-Änderung wesentlich besser was ebenfalls gegen eine falsche
Modulationsfrequenz spricht.
Ich habe übrigens auch die Wellenlängen der IR-LEDs der original-FBs mit
der von mir verwendeten LED verglichen. Diese sind ebenfalls identisch.
Die vorgeschlagenen Änderungen werde ich vermutlich in Kürze im
SVN-Repository wiederfinden, dann werden sie auch den Weg in meine
Sourcen finden.
Hast Du noch vor die Zwangspause bei Befehlen gleichen Typs einzubauen?
(bei flags=0). Wäre ganz schick, insbesondere bei Macros für
Sendernummern ("2","3","Enter")
Viele Grüße
Cajus
Hallo zusammen,
ich versuche hier gerade ein kleines Heimproblem zu beheben: Bisher
musste ich TV und Reciever hier immer mit 2 Fernbedienungen einschalten,
die Fernbedienung für den Reciever brauchte ich danach aber nie wieder,
also ging es mir auf den Geist immer 2 FBs rumliegen zu haben. Also
dachte ich mir: Wäre es nicht prima, das durch eine unauffällige Kiste
zu ersetzen, die auf das Power-On via Infrarot von der TV-Remote wartet
und daraufhin das Power-On für den Reciever sendet.
Also genau das mit IRMP und IRSND realisiert, auf einen Formfaktor
verkleinert, in dem es bequem in ein kleines Digitalthermometer passt,
was nun in der Linie Sofa -> TV steht. Geht prima. Nach jetzt ca. 6
Wochen kam mir das Problem der zu geringen Batterielaufzeit in den Sinn
- ich musste jetzt das zweite mal die 2 x AAA-Zellen wechseln.
Der AtTiny45 den ich benutze ist bereits auf einen SleepMode
eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der
Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom
Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch
super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP, der an
Vcc hängt. Also wollte ich diesen nun über einen Portpin schaltbar
machen. Also vor der IRMP-ISR das Ding anschalten, danach wieder aus,
keine Magie.
Nun wird allerdings nichts mehr deokdiert, das Umschalten des Portpins
kann ich mit dem Oszi nachvollziehen, geht, ist etwa 10% der Zeit an,
den Rest aus. Ich habe den Vcc-Pin des TSOP einfach an den µC gelötet
und schalte so, wenn er an sein soll, den Pin Hi.
Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären?
Brauch der TSOP eine Art "Einschwingzeit", ist mein Vorgehen komplett
unangebracht? Was gibts für ne bessere Idee, das Ding auf Stromsparen zu
optimieren?
mfg,
Stefan
DK3SB schrieb:> Am Data-Ausgang ist nun aber nix zu messen - könnt ihr mir das erklären?> Brauch der TSOP eine Art "Einschwingzeit", [...]
Ja, so wird es wohl sein. Der TSOP empfängt dann ja auch keine
vollständigen Bits mehr, wenn er nur für einen Bruchteil der Zeit, die
ein Bit braucht, eingeschaltet ist.
> Was gibts für ne bessere Idee, das Ding auf Stromsparen zu optimieren?
Welchen TSOP benutzt Du? Die neueren TSOP312xx (3mA?) sollen etwas
sparsamer sein als die TSOP17xx (5mA).
Alternative wäre eine Selbstbau-FB, die mit IRMP/IRSND arbeitet, siehe
z.B.
http://www.mikrocontroller.net/articles/DIY_Lernf%C3%A4hige_Fernbedienung_mit_IRMP
Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber
die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix
verwenden.
Gruß,
Frank
DK3SB schrieb:> Der AtTiny45 den ich benutze ist bereits auf einen SleepMode> eingestellt, den er immer betritt, wenn nix zu tun ist (was etwa 90% der> Zeit der Fall ist schätze ich), aufwachen tut er durch die ISR vom> Timer, in dem dann IRSND und IRMP aufgerufen werden. Das ging auch> super, es verbleibt aber die Dauerhafte Stromaufnahme des TSOP
ich persönlich würde den TINY nicht per Timer aufwachen lassen sondern
vom Pegelwechsel des TSOP, die Zeit für das Tinyaufwachen dürfte noch
reichen um den Befehl auszuwerten, das senkt schon mal den
Stromverbrauch, aber jeder IR Befehl weckt natürlich ! den Tiny ! also
um dickere Akkus und Wechsel wirst du nicht rumkommen ! ich staune nur
das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben
nur um 1mA gebraucht
Joachim B. schrieb:ich staune nur
> das der neue mit 3mA weniger verbrauchen soll, meine alten TSOP 17 haben> nur um 1mA gebraucht
Meine TSOP auch, aber im Datenblatt stehen halt die 5mA bzw. 3mA - warum
auch immer.
Frank M. schrieb:> Das Ding kommt mit einigen µA aus. Wahrscheinlich reichen Dir die aber> die 5 Tasten nicht, hier könnte man evtl. eine Tastatur-Matrix> verwenden.
genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen
die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der
TSOP abgeschaltet sein ! und trotzdem ist eine Tastenmatrix mit viel
mehr ! Tasten möglich, zum Anlernen weckt man den auf kann bei IR
Empfang in anlernen gehen, sonst nach aufwecken nur senden ! da braucht
der TSOP dann keinen Strom saugen, trotzdem scheint mir dazu auch der
168 von den Port unterdimensioniert wenn ich mal durchzähle 48-60 Tasten
keine Seltenheit, heisst 8x8 Matrix und so viele Ports + LEDs sind
selten frei, sieht eher nach mega32 bis 1284(p)aus, dafür auch im DIL40
zu bekommen
PS. Senden 18mA ? (für Reichweite sollte man die 100mA mindestens
ausnutzen, für schwache Batterien eher etwas drüber, damit das auch noch
geht wenn der Batteriepegel sinkt) ich hab den Rv für die IR Sende Diode
auf 22 Ohm verkleinert und für bessere Winkel lieber 2 IR Dioden in
Reihe gelegt, meine 3mm Dioden finde ich recht schmal im Abstrahlwinkel,
kann aber am Steckbrettaufbau liegen, nach unten ist das Brett der
Begrenzer, optimal sitzen ja Dioden so das sie vorne über die Kante
stehen und in keine Richtug eingeschränkt werden, aber mehr als 50°
Dioden fand ich nicht in 3mm, als 5mm geht mehr, will aber optisch zu
den LED (3mm) kompatibel bleiben
Joachim B. schrieb:> genau ! ich grübel gerade, irgendwo hatte ich eine Tastenmatrix gesehen> die mit einem ! Pinchange Interrupt geweckt wird, da darf dann auch der> TSOP abgeschaltet sein !
Klar.
> PS. Senden 18mA ?
Ja, aber es sind 18mA im Mittel. Der max. Strom durch die Sendediode ist
natürlich höher, nämlich fast 100mA. Dies liegt zum einen an der
Modulation mit einem Puls-Pausen-Verhältnis 50:50, andererseits an den
Pausen des jeweiligen IR-Protokolls. Der mittlere Strom von 18mA ist
genau das, was die IR-Sendediode (im Mittel) verkraftet - bei max.
Sendeleistung. Das passt also ganz gut so.
Danke für eure Anregungen, ein paar kleine Kommentare dazu:
1. Die 5mA Verbrauch für TSOP 1738 sind quatsch, im Datenblatt steht
dieser Wert in der Tabelle der "Absolute Maxmium Ratings", bei den
"Normal Conditions" stehen da ~1mA, und das ist auch der reelle
Verbrauch.
2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung
quatsch. Ich möchte meine Samsung-Remote benutzen, sie hat alle
Funktionen und sieht dazu noch gut aus. Das war der Grund, eine solche
"Verlängerung" für die zweite Fernbedienung zu bauen, und was anderes
möchte ich auch garnicht. Das Thermometer sieht dekorativ aus, nur war
halt das Batteriewechseln aller 2-3 Wochen mir nun aufgefallen.
Darum suche ich auch nach Stromsparmaßnahmen für den TSOP - gibt es
eventuell einen speziell auf Stromverbrauchsminimierung ausgelegten
Ersatz?
Abschalten kann man ihn wohl nicht, ich sehe in der kurzen On-Zeit kein
Logisch-Hi am DATA-Out, wo es ja eigentlich sein müsste, das kommt erst
später.
Aber nunja:
3. Ein Aufwachen auf die Pegelwechsel funktioniert hier nicht, da IRMP
in festen Zeitintervallen aufgerufen werden will. Was man machen könnte,
nach einer Art "Timeout" den Interrupt zu deaktivieren und auf externe
Pegelwechsel zu triggern, wodurch er wieder aktiviert wird. Aber wie
schon gesagt ist der AtTiny nicht mein Hauptstromverbrauch im Moment, er
schläft etwa 90% der Zeit. Der TSOP der aber nicht abgeschalten wird
braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann
ich nix machen, denke ich mittlerweile.
Danke trotzdem euch allen für eure Vorschläge, falls noch jemand was
hat: Bin ich immer offen für!
Stefan Biereigel schrieb:> 2. Eine Neue lernfähige Fernbedienung zu bauen wäre für meine Anwendung> quatsch. Ich möchte meine Samsung-Remote benutzen
also Quatsch finde ich zu hart, why not ?
für mich wäre Selbstbau einer neuen in dem Grund begründet da alle meine
lerndenden zu wenig Bittiefe haben und ich eine mit 433 Mhz will, habe
eina alte die nach 1/4 Funktionen programiert voll meldet ! kaufe eine
Neue (10 Jahre später) in der Hoffnung das die mehr Speicher hat und ich
hab noch nicht mal alle Tasten 2er ! FB drin meldet die neue auch voll !
ich glaub da muss man selber bauen (*grummel grummel, gibt nix
vernüftiges zu kaufen mit anlernen Bittiefe und Funk und Reichweite !)
> Der TSOP der aber nicht abgeschalten wird> braucht seine 1-2mA Dauerstrom und zieht die Batterie leer, dagegen kann> ich nix machen, denke ich mittlerweile.
sag ich doch, also doch richtige FB selber bauen
Gut, da gehen wohl unsere Vorstellungen etwas auseinander, schätze ich.
Ich möchte gern die bestehende FB weiternutzen, sie hat ja echt nur EINE
Taste nicht, auch schon dran gedacht habe ich, meinen µC einfach in die
FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste
keinen Strom verbrauchen wenn ich nix machen will ... Aber das ist alles
eher unpraktikabel. Zur großen Not muss ich halt mit dem Batteriewechsel
leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den
AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und
weiter runter gehen) - mal sehen wie es damit aussieht.
Zum Thema Universal-FBs, auch wenn hier etwas OT:
Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter
einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben.
Meine Chamäleon(s) die ich in der Vergangenheit nutzte konnten alle mehr
lernen als ich lernen wollte, damals gabs noch: VCR, DVD, SAT, TV,
Radio, PC
Jetzt hat sich das gesamte Geraffel auf TV + Reciever gekürzt, da wollt
ich eigentlich dass eine FB reicht.
Stefan Biereigel schrieb:> auch schon dran gedacht habe ich, meinen µC einfach in die> FB einzubauen, so könnte ich auf Taste reagieren (Ext. Int) und müsste> keinen Strom verbrauchen wenn ich nix machen will
das würde ich in deinem Fall für am sinnvollsten halten, weil ein immer
an TSOP einfach unsinnig ist und immer wieder den Tiny per Timer
aufwachen lassen genauso, also kleiner Tiny mit Int an Taste und eigener
IR Sendediode
> Zur großen Not muss ich halt mit dem Batteriewechsel> leben, aber zuerstmal versuche ich noch den Attiny45-20 gegen den> AtTiny45-10 zu tauschen, der soll in der Spannung variabler sein (und> weiter runter gehen) - mal sehen wie es damit aussieht.
oder so !
> Zum Thema Universal-FBs, auch wenn hier etwas OT:> Wenn man da Geld reinsteckt und nicht das 5€-Modell von [hier Discounter> einsetzen] kauft, kann man für etwas mehr schon nen gutes Teil haben.
nein und immer wieder nein, ich hab alle universell von 100-400 €
ausprobiert, die letzte Logitech Harmony ? 350€ so ein Sche*ss
anlernen ? ist nicht -> Codes nur über Logi Server download und wenn der
mal abgeschaltet wird hat man 350 € Elektronikschrott !
Reichweite, kaum das ich das Wohnzimmer verlassen hatte war Ende mit
Funk, das konnte und kann die 10 Jahre alte viel besser, Anlernen und
Reichweite !
am grausamsten war die Programmierung, man muss erst mal alle Geräte und
FBs vorstellen, dann darf man, muss man Macros programmieren, wer nur
mal testeise eine programmiert kann später nicht mehr nachrüsten, alles
auf Reset und dann alle Geräte und Macros neu anlernen, ja so eine
Schrottprogrammierung und Menüs gibt es wirklich für 350 €
kein Wunder das mein Modell auch schon eine Rückgabe war, ich habs auch
wieder zurückgegeben, für das Geld erwarte ich mehr, mehr Reichweite,
mehr Funktionalität und mehr Komfort
Frank M. schrieb:> Klar
Frage an den Autor,
bin grad dabei die IR SND einer größeren Funktionalität zuzuführen
würde also gerne irmp_data erweitern mit Tasten-Name und Geräte-Name
2 Möglichkeiten
1 die schlechtere, ich erweitere das Feld, inkompatibel !
2 die bessere ? und da bin ich als nicht gelernter Progger unsicher
ich baue ein neues Array wo irmp_data drin steckt + G-Name und T-Name
hast du dazu ne Idee ?
oder noch besser einen Vorschlag ?
und das möglichst platzsparend ?
also Idee
1.
STRUCT {
g-name char[8];
t-name char[8];
IRMP_DATA;
}uni;
ist schon mal doof, verschwendet Platz
Idee
2.
STRUCT {
t-name char[8];
IRMP_DATA;
}g-name;
spart Platz, nur wie greife ich von aussen auf G-Name zu ?
jar schrieb:> 1.> STRUCT {> g-name char[8];> t-name char[8];> IRMP_DATA;> }uni;
Das ist die einzig vernünftige Möglichkeit, jedoch sind in den obigen
Zeilen einige syntaktische Fehler drin :-)
Wenn schon, dann so:
1
#define MAXDEVICENAMELEN 8
2
#define MAXKEYNAMELEN 8
3
4
typedefstruct
5
{
6
chardevicename[MAXDEVICENAMELEN+1];
7
charkeyname[MAXKEYNAMELEN+1];
8
IRMP_DATAirmp_data;
9
}EXT_IRMP_DATA;
Dann kann man zum Beispiel folgendermaßen drauf zugreifen:
1
EXT_IRMP_DATAext;
2
...
3
strcpy(ext.devicename,"TV");
4
strcpy(ext.keyname,"Volume+");
5
ext.irmp_data.protcol=IRMP_SAMSUNG_PROTOCOL;
6
ext.irmp_data.address=0x0012;
7
ext.irmp_data.command=0x0034;
8
ext.irmp_data.flags=0;
Das Erweitern auf ein Array (Du willst bestimmt mehr als eine Taste)
überlasse ich Dir :-)
Gruß,
Frank
danke, aber da muss ich noch mal drüber schlafen
ich weigere mich für jedes Gerät mehrfach den Namensplatz zu
verschwenden, so üppig ist EEPROM Platz nicht im Atmel, da hat man ja
mehr Platz im flash :-)
evt. nehme ich statt NAME 8+1 x-mal f. jede Taste und jedes Gerät (sieht
irgendwie nach linearen 2-dimensionalen Array aus)
n-Tasten * m-Geräte egal ob Gerät x die Menge an Tasten von Gerät y hat
ein u_int8 für 256 Geräte und weise den Namen in einer table zu
Hallo,
auch auf die Gefahr hin, dass ich gleich gerügt werde, weil ich nicht
den kompletten thread gelesen habe und die Antwort bereits geschrieben
wurde:
habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll
die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt
steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...
Gruß und danke
Fluto.
Fluto schrieb:> habe eine dreambox dm800se und würde nur gern wissen, welches Protokoll> die haben / freigeschaltetes werden muss b.z.w. ob die überhaupt> steuerbar sind. Habe irgendwo etwas von einem TWIRP- Protokol gelesen...
Habe auch eine Dreambox und kann Dir schon mal sagen, dass die
Dreambox-FB momentan nicht von IRMP/IRSND unterstützt wird. Mach ich
vielleicht irgendwann mal...
Gruß,
Frank
BTW. Kaseikyo
@frank
ich weiss du machst Kaseikyo immer im Blindflug mangels Geräte, soweit
funktioniert das auch, nur hab ich das Problem das ich mit Tastendruck
varieren alles von NEC, Siemens, Ruwido simmulieren kann, wohlgemerkt
mit einer Kaseikyo ! entweder IRMP kommt durcheinander bei halben
Repeatframes oder bei halben Frames ? oder deine Pausenerkennung ist
unzuverlässig bezüglich Kaseikyo
was kann ich für dich tun damit du die besser erkennen kannst, bzw. die
bessere Erkennung in IRMP einpflegen kannst ?
evt. kanns auch am int. RC Oszi liegen, bin da aber unsicher weil der ab
Werk ja schon kal. Byte gesetzt hat und die Toleranzen nicht so riesig
sind
meine Abweichung
//OCR2A = 76; // Reloadwert Timer 2 rechnerisch richtig wär 78,125,
76/78,125
~2,7% mit Oszi ermittelt für einen anderen Timer, nicht für IRMP, also
ohne Korrektur muss IRMP mit diesem 2,7% Fehler leben, das kann aber
nicht die Ursache sein, FBs haben ja deutlich größere Toleranzen
Hallo zusammen,
ich möchte das IRSND protokoll bei meinem ATTINY88 benutzen. Leider hat
der ATTINY88 kein OC0A oder OC0B, sondern nur OC1A und OC1B. Was muss
ich jetzt hier eintragen, damit es klappt?:
#define IRSND_OCx
grüße
nimmst halt den OC1A oder 1B statt 0
#define IRSND_OC1A oder
#define IRSND_OC1B
du brauchst aber das passende OC Bein für die Sendediode
oc für output compare, dein TINY88 muss ja sowas auch haben
wäre am PDIP 28,3 Pin15 f. OC1A
Hallo Frank,
da wäre mal wieder ein Problem:
IRSND und KASEIKYO Codes einer Panasonic DVD-RW Fernbedienung.
Ich habe zwei Tasten, deren Codes vom Gerät einfach nicht aktzeptiert
werden.
Es handelt sich dabei um die Tasten "rot" und "grün". Wenn ich das
Signal mit IRMP logge, dann wird bei beiden Sendern (original FB und
IRSND-FB) der gleiche Befehl erkannt. Das Gerät reagiert jedoch nur auf
die original-FB. Die anderen Tasten scheinen alle zu funktionieren,
zumindest ist mir noch keine weitere Taste aufgefallen. Ich habe die
Logs in den Anhang gepackt. Die Tasten "gelb" und "blau" funtionieren
und sind nur als Referenz in der Logdatei. Irgendwie ist das Signal der
Original-FB deutlich länger. Bei "rot" und "blau" habe ich außerdem den
Finger zu lange auf dem Knopf gehabt, weswegen eine Wiederholung
vorhanden ist.
Ich verwende die letzten Sourcen aus dem SVN, F_INTERRUPTS 15000 auf
einem ATmega644A (Sender und Empfänger auf getrennter Hardware). Ich
habe fast alle Protokolle in IRSND und IRMP aktiviert.
Hast Du da einen Tip für mich?
...
Da war doch noch was mit dem SAMSUNG32 Protokoll und der
Wiederholpause...
Viele Grüße
Cajus
Hallo Frank,
ich habe meine Scans mal durch IRMP unter Linux geschickt und ich denke,
ich habe das Problem gefunden. Eines der 4 System-Bits (Genre2) ist
unterschiedlich.
Das Parity-Byte am Ende dann natürlich auch. hier für Taste "grün", bei
"rot" das gleiche Bit.
010000000000010000001101000000000100001001001111 original
010000000000010000001101100000000100001011001111 IRSND
123456789012345678901234567890123456789012345678
MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp
^ ^
In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
stand etwas von
- Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame
ausgewertet
Wo landen denn die Bits und wie bekomme ich die Bits wieder nach IRSND?
Welche 4 bits gehen denn dann verloren?
Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags"
unterbringen?
Die unteren 4 Bits werden bei IRSND schon für die Anzahl von
Wiederholungen verwendet.
Die oberen Bits sind, soweit ich weis, noch frei.
Oder sollte man die IRMP_DATA-Struktur aufzuboren,
z.B. uint8_t flags in uint16_t wandeln?
Dann hätte man noch etwas mehr Luft.
Viele Grüße
Cajus
Hallo Frank,
da Du offensichtlich im Moment nur wenig Zeit hast, habe ich mich mal
daran gesetzt nach den Genre2-Bits im KASEIKYO Protokoll zu schauen.
Ich habe IRMP erweitert, die Genre2 Bits werden jetzt im MSB von flags
zurückgegeben.
Danach habe ich die DVD-RW-Fernbedienung mal überprüft: Es sind
tatsächlich nur die zwei Tasten "rot" und "grün", die ein Genre2 <> 0
haben.
Ich habe allerdings noch einen neueren Blu-ray Player von Panasonic, der
die gleichen Codes verwendet, dort sind schon 8 Tasten mit Genre2 <> 0.
Ich habe mich schon gewundert, warum meine IRSND-Fernbedienung bei
diesem Gerät so schlecht funktioniert ...
Vielleicht komme ich am Wochenende dazu die Funktion in IRSND
einzubauen. Dann werde ich den Diff zu den aktuellen SVN-Sourcen hier
einstellen.
Falls Du Lust (und Zeit) hast, kannst Du ja vielleicht mal nach dem
SAMSUNG32 Protokoll und der Wiederholpause sehen und die Änderungen ins
SVN einchecken.
Viele Grüße
Cajus
Hallo Frank,
hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2
Bits der KASEIKYO Codes berücksichtigt werden. Wie schon erwähnt werden
die 4 Bits in den oberen 4 Bits der flags eingeblendet. Diese Bits sind
sowohl in irmp als auch in irsnd noch unbenutzt.
Die Quelle für den angehängten Patch sind die SVN-Sourcen von heute.
Es wäre schön, wenn die Änderung in Deinen offiziellen Sourcen eingebaut
würden.
Viele Grüße
Cajus
Cajus H. schrieb:> Hallo Frank,> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2> Bits der KASEIKYO Codes berücksichtigt werden. .......> Viele Grüße> Cajus
irgendwie blicke ich noch nicht durch wo genau ich das einfügen muss
kannst du die kompletten Texte mit deiner Änderung einstellen ?
die vielen + u. - verwirren mich
ich kenne - als entfernen und + als einfügen, heisst das aber lt. deimem
Text nur zusätzlich einfügen an der Stelle oder wegen --- entfernen der
orignal Texte ?
die Zeillennummern stimmen auch nicht mit meinen Versionen überein,
weiss nicht ob ich da optimiert habe oder andere Quellen hatte.
Kaseikyo liegt mir ja auch sehr am Herzen, komme vermutlich erst heute
dazu die IRSND in meinem RS232 zu BAS Konverter (Pollin) umgebaut zu
RS232 zu IRMP implementieren
wenn das fertig ist werde ich Umbauplan und Source hier einstellen
das Teil versorgt sich selber über RS232 (RTS, DTR und TxD angezapft auf
LM317CZ vom stromfressenden MAX232 befreit, mit sparsamer Trasischaltung
ausgeführt) und kann von RS232 bedient werden
Hallo Joachim,
sorry, meine Patch-Datei war leider fehlerhaft. Ich habe am IRMP und
IRSND Source noch einige andere Änderungen vorgenommen, die ich dann von
Hand aus der Patch-Datei entfernt habe. Dadurch stimmten die
Zeilennummern aber nicht mehr. Im Anhang sind jetzt die kompletten
Dateien, Basis sind immer noch die SVN-Sourcen vom 2.12.2011.
Gruß
Cajus
huhu, ich möchte nochmal auf den ATTINY88 zurück kommen.
ganz so leicht war es wohl doch nicht... in der irsnd.c
gibt es probleme. Anschinend fehlten definitionen und zwar...
Hier:
irsnd_on (void)
{
if (! irsnd_is_on)
{
#ifndef DEBUG
#if IRSND_OCx == IRSND_OC1A // use OC2
TCCR1A |= (1<<COM1A0)|(1<<WGM12); // toggle OC1A on compare
match, clear Timer 1 at compare match OCR1A
.....
hier:
irsnd_off (void)
{
if (irsnd_is_on)
{
#ifndef DEBUG
#if IRSND_OCx == IRSND_OC1A // use OC2
TCCR1A &= ~(1<<COM1A0); // normal port operation, OC1A
disconnected.
..........
hier:
irsnd_set_freq (uint8_t freq)
{
#ifndef DEBUG
#if IRSND_OCx == IRSND_OC1A
OCR1A = freq; // use register OCR2 for OC2
#elif IRSND_OCx == IRSND_OC2A // use OC2A
uner hier:
irsnd_init (void)
{
#ifndef DEBUG
IRSND_PORT &= ~(1<<IRSND_BIT); // set IRSND_BIT to low
IRSND_DDR |= (1<<IRSND_BIT); // set IRSND_BIT to output
#if IRSND_OCx == IRSND_OC1A // use OC2
TCCR1A = (1<<WGM12); // CTC mode
TCCR1A |= (1<<CS10); // 0x01, start Timer 2, no prescaling
die werte für die timer habe ich jetzt eingesetzt, da diese nicht für
IRSND_OC1A definiert waren. ich glaube aber da ist ziemlich viel falsch,
leider weiß ich die richtigen werte nicht da ich total der überblick
verloren habe :(
kann mir jemand helfen?
Hallo Cajus,
vorab erstmal eine Entschuldigung, dass ich mich jetzt erst melde. Deine
Vermutung wg. knapper Zeit war schon ganz richtig.
Cajus H. schrieb:> 123456789012345678901234567890123456789012345678> MMMMMMMMMMMMMMMMppppGGGGggggCCCCCCCCCCiipppppppp> ^ ^> In Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"> stand etwas von>> - Kaseikyo: es werden nun die 4 System-Bits (Genre2) im Frame> ausgewertet
Da ging es mir um die 4 Bits, die Du oben mit GGGG gekennzeichnet hast.
Die 4 Bits "gggg" habe ich bisher im IRMP einfach ignoriert, da sie
nicht mehr in die IRMP_DATA-Struktur passten. Kaseikyo ist da mit 48
Bits einfach zu fett. Bei den mir bekannten FBs war das auch kein
Beinbruch, da die gggg-Bits immer 0000 waren.
> Könnte man die 4 Bits nicht in den oberen 4 Bits von "flags"> unterbringen?
Ja, könnte man. Ich bin zwar mit der Lösung nicht ganz so glücklich,
weil das eher ein Workaround als eine Lösung ist. Eher müsste man die
IRMP-Datenstruktur aufblasen, z.B. Adresse und Kommando auf 32 Bits
erweitern. Das würde aber zu Inkompatibilitäten zu bereits bestehenden
Projekten führen, z.B. zum V-USB-IRMP-Projekt von Hugo Portisch, welcher
momentan 6 Bytes über V-USB überträgt.
> Die unteren 4 Bits werden bei IRSND schon für die Anzahl von> Wiederholungen verwendet.
So ist es, gut erkannt. Die oberen 4 Bits verwende ich teilweise in
privaten IRMP-Projekten, z.B. bei meiner lernfähigen Fernbedienung.
> Die oberen Bits sind, soweit ich weis, noch frei.> Oder sollte man die IRMP_DATA-Struktur aufzuboren,> z.B. uint8_t flags in uint16_t wandeln?
Die Flags sind eigentlich nicht dafür gedacht, für Datenbits herzuhalten
;-)
> Dann hätte man noch etwas mehr Luft.
Eher sollte man address & command aufbohren. Ich schwanke da hin und
her... wegen einem einzigen Protokoll die Datengröße verdoppeln...
kostet Zeit (im IRMP) und Speicher (z.B. in der makro-/lernfähigen FB).
Gruß,
Frank
Hallo Cajus,
Cajus H. schrieb:> hier wäre dann die Änderung an irmp.c und irsnd.c, mit der die Genre2> Bits der KASEIKYO Codes berücksichtigt werden.
Vielen Dank, ich werde Deine Änderungen in den IRMP-Source einbauen.
Aber die letzte Entscheidung, ob das so bleiben wird, ist darüber noch
nicht gefallen. Ich finde die Verlagerung von Datenbits in die Flag-Bits
eigentlich nicht so schön, habe (wie oben beschrieben) aber momentan
auch keine bessere Lösung.
Gruß,
Frank
Hallo Frank,
schön, dass Du wieder da bist!
Ich habe genau wie Du lange hin- und her-überlegt, ob man nicht lieber
die Datenbits erweitert, aber wegen einem Protokoll?
Wenn Du meine Erweiterungen in IRMP und IRSND einbaust, dann kannst Du
das Ganze ja in ein #ifdef stecken. Wer kein Kaseikyo verwendet, oder
die Genre2 Bits nicht braucht, kann den Code ja rauslassen und die Bits
für andere Zwecke verwenden. Allerdings ist Kaseikyo ziemlich
gebräuchlich und ich vermute, es werden in Zukunft auch noch andere
Geräte Gebrauch von den Genre2 Bits machen werden.
Auf die Gefahr, dass ich Dich mit der Frage inzwischen langweile...
Wolltest Du nicht auch noch meine Timing-Änderungen für SAMSUNG32 prüfen
und in den Code einbauen?
Der Punkt mit der Zwangspause zwischen zwei Befehlen gleicher Kodierung
ist auch noch offen...
( Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" )
Schöne Feiertage!
Cajus
Wieso fügst du nicht noch einen weiteren Structmember für IRMP_DATA ein?
Dann werden keine Flags missbraucht, man spart sichs, daten aus den
flags zu operieren und die kompatibilität bleibt gewahrt. Alter Code mit
neuem IRMP ignoriert die gggg-Bits einfach weiterhin. Und das problem
mit dem unnötigen Speicher wäre auch weniger schlimm - man müsste ja nur
ein Byte reservieren.
Viele Grüße,
Sebastian
huhu, kann mir denn niemand mit dem
IRSND protokoll bei meinem ATTINY88 helfen :(
ich bekomme die timer im protokoll net hin :(
das wär echt voll suuuuuuper !
grüße
Michael H. schrieb:> du hast die antwort doch schon bekommen. sogar fertig ausgemalt...> Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
huhu, das funktioniert leider nicht.... ganz so leicht wars wohl net,
weil die timerbefehle in den funktionen
irsnd_on (void)
irsnd_off (void)
irsnd_set_freq (uint8_t freq)
irsnd_init (void)
für OCR1A nicht vorhanden sind....
Hallo zusammen,
tolles Projekt. Meine Fernbedienungen hab schon ich geloggt aber
hat jemand schon mal probiert die Protokolle von so kleinen
Modellhubschraubern mit Infrarot zu entschlüsseln.
Ich habe einen kleinen Nincoair 180 ALU G
(http://www.thalia.de/shop/home/rubrikartikel/ID24972473.html?zUserID=733&zanpid=1596265215589458944)
Anbei ein Log der Fernbedieung. Kann jemand etwas damit anfangen.
Interruptfrequenz habe ich auf 20000 ISR/s gestellt.
Mario
Hier nochmal ein Scan desselben Hubschraubers mit 10khz. Ich habe es
schon versucht mit irmp zu analysieren (unter Windows). Er erkennt ein
irgendwie fehlerhaftes unvollständiges RC5... ich werd nicht schlau
draus.
Martin K. schrieb:> huhu, kann mir denn niemand mit dem> IRSND protokoll bei meinem ATTINY88 helfen :(> ich bekomme die timer im protokoll net hin :(> das wär echt voll suuuuuuper !
IRSND braucht 2 Timer:
- 8-Bit-Timer 0 für die Modulation des Signals durch PWM, z.B. 36kHz,
38kHz, 40kHz - je nach Protokoll.
- 16-Bit-Timer 1 für das Senden des IR-Frames, läuft i.d.R. mit 10
oder 15 kHz.
Leider kann man auf dem ATTiny88 keine PWM mit dem Timer0 benutzen.
Genau dieses Feature hat man dem kastrierten ATTiny88 geklaut.
Um das Ganze auf dem ATTiny88 zum Laufen zu bekommen, müsste man das
Ganze umdrehen:
- 16-Bit-Timer 1 für die Modulation des Signals durch PWM
- 8-Bit-Timer 0 für das Senden des IR-Frames
Das Umschreiben ist ein wenig Arbeit, wofür ich gerade wenig Zeit habe.
Aber mal eine Frage: Warum benutzt Du einen 28-Pinner, der so abgespeckt
ist? Nimm doch einfach einen ATMega88 statt dem ATTiny88. Der scheint
auf den ersten Blick pinkompatibel zu sein und bietet wesentlich mehr
Möglichkeiten.
Mario Grafe schrieb:> Hier nochmal ein Scan desselben Hubschraubers mit 10khz.
10kHz reicht dafür aus, die Pulse (und Pausen) sind lang genug.
> Ich habe es schon versucht mit irmp zu analysieren (unter Windows).
"Analysieren" macht man in IRMP mit der "Analyze-Option" (-a). Du
hättest einfach mal
irmp.exe -a < hubi.txt
eingeben sollen ;-)
Das habe ich gerade mal unter Linux mittels
./irmp -a < hubi.txt
gemacht. Dabei kommt raus:
1. Protokoll ist Bi-Phase (Manchester). Das erkennt man daran, dass
es sowohl 2 verschiedene Puls- auch auch 2 verschiedene Pausenzeiten
gibt.
2. Startbit ist: ca. 970 µs Puls, dann ca. 275 µs Pause
3. Pulse: 490 µs und 890 µs
4. Pausen: 280 µs und 670 µs
Eigentlich sollten bei Bi-Phase-Protokollen die kurzen Pulslängen
genauso lang sein wie die kurzen Pausen. Das gleiche gilt für die langen
Puls-/Pause-Zeiten. Das Timing ist hier stark asymmetrisch und
dementsprechend schlecht... ist das so ein Billig-Hubschrauber?
Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen
Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen
eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.
Gruß,
Frank
huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...
das doofe ist ich hab die schaltung schon gemacht weil ichd achte das
klappt :D naja dann werd ich die schaltung wohl mal mit dem mega88
aufbauen wenn ich dafür wieder zeit finde hehe =)
danke trotzdem, jetzt weiß ich immerhin woran es liegt ;)
grüüüße
Martin K. schrieb:> huhuu vielen dank, sorry ich wusste nicht dass es so viel arbeit ist...> das doofe ist ich hab die schaltung schon gemacht weil ichd achte das> klappt
Wie gesagt: der ATMega88 scheint weitestgehend pinkompatibel mit dem
ATTiny88 zu sein. Wenn Du Deinen ATTIny88 nicht fest eingelötet hast,
kannst Du ihn direkt gegen einen ATMega88 ersetzen.
Hallo Frank,
vielen Dank für die schnelle Antwort.
Frank M. schrieb:> .. ist das so ein Billig-Hubschrauber?
Ja ist so ein Billigteil (vor allem die Steuerung), fliegt aber
erstaunlich gut. Wäre lustig wenn man den mit deiner Lib auch steuern
könnte :)
Frank M. schrieb:> Wenn ich das richtig in Erinnerung habe, habe ich mal vor einigen> Monaten die Unterstützung von stark asymmetrischen Bi-Phase-Protokollen> eingebaut. Muss ich mir bei Gelegenheit nochmal ansehen.
Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?
Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows
benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15
bzw. 20kHz-Version kompiliert, oder?
Gruß
Mario
Mario Grafe schrieb:> Wie hast du denn das Protokoll bezeichnet? Welches muß ich aktivieren?
Es geht nicht um ein bestimmtes Protokoll, sondern nur darum, dass IRMP
bei Manchester-Codes (Bi-Phase) wie RC5, RC6, Grundig usw. nicht ins
Schleudern gerät, wenn die Zeiten stark asymmetrisch sind. Dein
Hubschschrauber-Protokoll wird momentan nicht unterstützt. Kann ich mir
bei nächster Gelegenheit mal vornehmen...
> Noch eine Frage: Ich habe zur Analyse die "irmp.exe" unter Windows> benutzt. Ist das die Version für 10kHz? Für Windows hast du keine 15> bzw. 20kHz-Version kompiliert, oder?
Die ist mit 10kHz kompiliert.
Gruß,
Frank
Frank M. schrieb:> Kann ich mir> bei nächster Gelegenheit mal vornehmen...
Da freu ich mich schon drauf :)
Hast du denn einen Ansatz wie man die Adress- bzw. Kommando-
Bitlängen rausbekommt? Letztenendes muß man schauen wann ein neues
Startbit kommt, oder? Aber wieder erkennt man die Adressbitlänge?
Falls du noch mehr Logs brauchst, sag Bescheid.
Sobald man den Schubhebel bewegt sendet die Steuerung ohne Pause wild
drauflos, d.h. es werden permanent Datenpakete geschickt. Evtl. gehen
einige Bits bei Logging verloren. Vielleicht werde ich mal die Baudrate
erhöhen...
Gruß
Mario
Hallo,
wenn ich eine Fernbedinung dekodieren will, dann wird nur das Protokoll
erkannt, die Adresse und das Commando steht leer. Ich benutzt die letzte
Version die noch CodeVision unterstützt, das ist glaub ich die 2.0.0 vom
16.08.2011.
Hatte jemand auch schon mal so ein Problem? Würde mich über Eurer Hilfe
freuen.
Hallo zusammen,
ich benutze irmp, irsnd und V_USB zusammen mit einer
Funkstrecke auf der Basis der RFM01/02-Module von hope - alles zusammen
auf atmega8. Das ganze kommuniziert mit vdr per irmplircd. Ich bin
begeistert!
Jetzt wuerde ich gerne meine 'historische" Fernbedienung Grundig TP 400
VT empfangen und insbesondere mit irsnd codes aussenden.
Es handelt sich um einen biphase-code mit 29.5khz-Traeger. Das Startbit
hat ca 500us Puls gefolgt von 2.75ms Pause. Danach kommen 7 Daten-Bits
im biphase-code. Das erste Datenbit ist immer eine '0' (d.h. ca 500us
Puls gefolgt von 500us Pause). Wiederholungen sind durch 96ms Pausen
getrennt. Offenbar wird einfach der gleiche Code weitergesendet (kein
Toggeln erkennbar). Wie man da sinnvoll in Adresse und Daten unterteilt
ist mir unklar.
Ich habe mir den code in irmp.c angesehen. Eine Ergaenzung ist nicht
direkt
trivial.
Es waere super, wenn mir da jemand helfen koennte oder ein paar Tipps
haette?
Ich habe auch ein paar scope-traces - aber leider keine gesacannten
files, da ich z.Z. kein UART in Betrieb habe.
Gruss und vielen Dank
Wolfgang
Hallo Frank,
befasse mich nach endlos langer Zeit mal wieder mit IRMP/IRSND. Das
Projekt ist ja richtig erwachsen geworden. Mich interessiert hier
hauptsächlich der RC6A Code. Gibt es Erfahrungen bezüglich IRSND und
RC6A an "realen" Geräten? Ich habe mal mit einem zweiten IRMP den von
IRSND ausgesandten Code mit Logging empfangen. Was IRSND da sendet, hat
rein gar nichts mit dem zu tun, was die originale FB sendet. Bin im
Moment etwas ratlos, wo hier zu suchen wäre.
PS
SIRCS funktioniert z.B. sowohl in IRMP als auch in IRSND prima.
-peko
Hallo Peter,
Peter K. schrieb:> Gibt es Erfahrungen bezüglich IRSND und RC6A an "realen" Geräten?
Nein, ich habe bzgl. RC6A und IRSND kein Feedback.
> Was IRSND da sendet, hat rein gar nichts mit dem zu tun, was die> originale FB sendet. Bin im Moment etwas ratlos, wo hier zu suchen wäre.
Scans Deiner FB würden mir helfen.
Gruß,
Frank
Peter K. schrieb:> bei so prompter Antwort schicke ich doch gleich mal einen Scan.
Habs mir angeschaut, kann mir nicht erklären, warum der IRSND bei Dir so
einen Schrott produziert.
Ich habe gerade mal unter Linux ausprobiert:
./irsnd-15kHz 21 0046 0081
Also prinzipiell funktioniert IRSND, denn beide Frames sehen (bis auf
kleinere vernachlässigbare Timing-Unterschiede und damit eine
schleichende Verschiebung) deckungsgleich aus und werden auch beide von
IRMP einwandfrei wiedererkannt.
Es muss also ein Problem beim µC sein. Entweder ist da eine
Inkompatibilität des IRSND-Sources betreffend Zielsystem Linux / ATmega
oder die Speicherverwaltung auf dem µC ist durcheinander. Ob das am
IRSND liegt oder an dem, was Du "drumherum" programmiert hast, kann ich
aber erst sagen, wenn ich das selbst mit 2 µCs getestet habe. Der
Schrott, den Dein µC ausgibt, sieht nach zerwürfelter Speicherverwaltung
(Überschreiber auf Stack oder sonst irgendwo im SRAM) aus.
Sag mal bitte was über verwendeten µC, Speicherbedarf Deiner Anwendung
etc.
Oder wenn Deine IRSND-Anwendung klein ist, poste doch mal den Quellcode.
Gruß,
Frank
Hallo Frank,
jetzt habe ich nochmal alles komprimiert, das Ganze besteht fast nur
noch aus IRMP / IRSND. Ich nutze main() aus irmp. IRMP dient jetzt nur
als Trigger zum Senden des RC6A codes: Wenn ein IR-Code empfangen wird,
geht RC6A raus. Gerade mal eine Blink-LED ist noch mit dabei, damit ich
sehen kann, daß der µC arbeitet. Ich verwende einen 664P mit 20MHz
getaktet. Anbei mal die gezippten sources. Ich bin mir nicht sicher, ob
ich nicht irgendwo ein define vergessen / oder falsch eingestellt habe.
Gruß, peko
Es steht eine neue Version 2.0.3 von IRMP + IRSND zum Download bereit.
Download über Artikel:
http://www.mikrocontroller.net/articles/IRMP#Downloadhttp://www.mikrocontroller.net/articles/IRMP#Download_IRSND
und auch übers SVN möglich:
http://www.mikrocontroller.net/svnbrowser/irmp/
Änderungen IRMP:
- Bugfix: oberstes Bit in Adresse falsch bei NEC-Protokoll, wenn auch
NEC42-Protokoll eingeschaltet ist.
- Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
- Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
Änderungen IRSND:
- Timing von SAMSUNG- und SAMSUNG32-Protokoll korrigiert
- Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
- Zusätzliche Pause nach dem Senden des letzten Frames
Vielen Dank an Cajus.
Wünsche viel Spaß,
Frank
IRSND hatte in der Version 2.0.3 den Fehler, dass es nur einen einzigen
Frame rausschickte.
Deshalb gibt es nun eine Version 2.0.4 - zum Download und im SVN.
Gruß,
Frank
Mathias O. schrieb:> Ähm was ist das genre2 Bit? Wozu ist das da?
Stimmt, dazu hätte ich mehr schreiben sollen. Es steht dazu aber einiges
hier im Thread. Die Genre2-Bits sind 4 Bits aus dem Kaseikyo-Protokoll.
Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4
Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen. Deshalb werden
sie nun im oberen Nibble von flags gespeichert bzw. von IRSND
ausgewertet. Ich bin zwar mit dieser Lösung nicht sehr glücklich, weiß
aber im Moment auch keine bessere Lösung... außer IRMP_DATA zu
vergößern. Ob das so bleibt, weiß ich noch nicht.
Das Ganze ist nur relevant, wenn man Kaseikyo nutzt. Die 4 Genre2-Bits
sind bei Kaseikyo zudem meist 0, so dass diese Änderung nur in ganz
speziellen Fällen zum Tragen kommt.
Ich werde dies noch im IRMP-Artikel erwähnen.
Gruß,
Frank
Frank M. schrieb:> Leider ist das Kaseikyo-Protokoll mit 48 Bit so fett, dass die 4> Genre2-Bits nicht mehr in die IRMP_DATA-Struct passen
genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit
bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data,
mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst
du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte
eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt
wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags
jar schrieb:> genau das verstehe ich immer noch nicht, du schreibst immer von 48 Bit> bei Kaseikyo, aber in IRMP gibt es nur 16 Bit Address und 16 Bit Data,> mit den 4 zusätzlichen (Genre2) landen wir bei 36 Bit, warum schreibst> du bei Kaseikyo immer von 48 Bit, ich gehe davon aus das Protocolbyte> eine IRMP spezifische ist, die nur festlegt welches Protokoll erkannt> wurde und keine Nutzdaten aus der IR Übertragung trägt, genau wie Flags
Wenn Du Dir
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail
unter "Kaseikyo" anschaust, dann weißt Du warum. Im Frame stecken 4 + 8
= 12 Parity-Bits. Die brauche ich nicht, die kann IRSND mühelos wieder
aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4
Bits zuviel.
Gruß,
Frank
P.S.
Die Parity-Bits werden selbstverständlich von IRMP berücksichtigt, um
die Korrektheit der Daten zu prüfen. Gespeichert werden brauchen sie
aber nicht.
Frank M. schrieb:> ie kann IRSND mühelos wieder> aus den 36 Daten-Bits wieder reproduzieren. Aber auch 36 Bits sind 4> Bits zuviel.
danke, so wie ich das nun rauslese haben wir alle 36 relevanten Bits vom
Kaseikyo, aufgeteilt in IRMP auf 16 Address Bits und 16 Command Bits + 4
Genre2 Bits in Flags, du schreibst 4 sind zuviel, aber es gab ja User
die die brauchten, ich konnte zwar alle Kaseikyo Codes auslesen, habe
aber bis jetzt nur einen schwach senden können, kann aber an den Dioden
oder der Frequenz liegen, das genau muss ich noch testen, ich bekomme ja
die Bits aus einem TSOP (3)1736 der spuckt natürlich zwischen 32 und 38
kHz locker Daten aus, meine Sendediode hat 940nm mit wenig sr, es gibt
aber auch 950 und 880er nm Dioden mit viel mehr power, aber das ist
wieder ne andere Baustelle
Hallo
Ich verfolge nun dieses Thread schon seit Wochen .
Derzeit programmiere ich noch alles in Bascom, das wird sich aber
ändern.
Da ich eh noch nicht so lange mit MC’s bastel is das auch nicht so
weltbewegend, bin ja nicht festgewachsen
Aber wird schon a bissal Hirnschmalz nötig sein!
Aber nichts desto trotz , ich hab ein Problem mit der integration von
IRMP und IRSND in ein fertiges
Gerät, dass ich von der Arbeit gespendet bekomme. Es sind keine Layout
Änderungen möglich.
Das is so ein Gaswarner für die Chemieindustrie mit einem Atmel an
Board.
Den oder diese würde ich gerne für zukünftige Projekte verwenden.
Dazu sollte es möglich sein per IR Einstelungen von einem Laptop oder
2.tem Gaswarner zu übertragen, dies will ich mit rc5 oder anderem z.B.
Grundig Code übertragen.
Auf einer extra aufgebauten Schaltung (Polin Board) funktioniert IRMP
tadel los mit 16Mhz Atmega 32! Die Grundig IR Variante hat bei mir die
stabilste Erkennung.
Ausstattung :
- Atmel Atmega169PV-8MU /hab ich fürs compilieren in der IRMP
atmega168 Sektion hinzugefügt)
- 1Mhz interner Takt (ckdiv8 gesetzt) - dies ist die
Standardeinstellung vor und nach dem Löschen des orginal beschriebenen
microcontrollers und sollte auch so bleiben
- SIR TFBS4711 (irda Transceiver)
Irgend ein Quarz(FSR 12.5) ohne Kondensatoren ist verlötet (evtl ein
Uhrenquarz ?)
Mein Problem nun :
Der RX pin des IRDA ist auf PG4 (T0/SEG23)
Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)
Ich kann Daten empfangen mit der Log Funktion(in der neuesten IRMP
allerding lässt sichs nicht mehr compilieren mit Log Flag) von IRMP,
aber es wird nie etwas komplett erkannt so das ich keine Adresse ,
Command und sonstige Daten zum Auswerten bekomme.
Beim Senden wird’s wohl auch nix werden .
Ich hab schon mehrfachi n einigen Foren gelesen , dass es möglich sein
muss ohne externen quarz IR empfangen und senden zu können.
Aber Wie ?
Hab schon mit den Fuses (ckdiv8) und den FPU einstellungen gespielt aber
leider nichts.
Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird
dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings
auch beim Atmega32 nichts mehr.
Ich denke ich hab fürs empfangen hier ein eindeutiges Timing Problem
aber wie mach ich das es funktioniert???
Kann mir bitte jemand auf die Sprünge helfen, oder zumindest erstmal
noch fragen was er zu meiner Problemlösung noch wissen muss ?
Hab schon etliche Nächte weiss werdende Haare gezählt.
Gruß Klaus
Hallo zusammen,
eine neue Version von IRMP und IRSND steht zum Download bereit. Diese
ist nun auch für den C18-Compiler (PIC) verfügbar. Ebenso kann man nun
auch unbekannte Formate auf dem PIC scannen (über USB).
Vielen Dank dafür an gera!
IRMP Version 2.0.4:
- Bug in IR60-Decoder behoben
- Bug in CRC-Berechnung von Kaseikyo-Frames behoben
- Portierung auf C18 Compiler für PIC-Mikroprozessoren
- Scannen von IR-Frames auf dem PIC (über USB)
IRSND Version 2.0.4:
- Neues Protokoll: IR60
- Bug beim Senden von Bi-Phase-Frames (Manchester) behoben
- Portierung auf C18 Compiler für PIC-Mikroprozessoren
KLaus schrieb:> Mein Problem nun :> Der RX pin des IRDA ist auf PG4 (T0/SEG23)> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)
IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein
eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du
kannst versuchen, den IRDA-Controller direkt über RX/TX als UART
auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts
mehr mit IRMP zu tun.
Gruß,
Frank
KLaus schrieb:> Ausstattung :> - Atmel Atmega169PV-8MU /hab ich fürs compilieren in der IRMP> atmega168 Sektion hinzugefügt)> - 1Mhz interner Takt (ckdiv8 gesetzt) - dies ist die> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen> microcontrollers und sollte auch so bleiben> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings> auch beim Atmega32 nichts mehr.
ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann
auch das was du schon beobachtet hast
jar schrieb:> KLaus schrieb:>> Ausstattung :>> - Atmel Atmega169PV-8MU /hab ich fürs compilieren in der IRMP>> atmega168 Sektion hinzugefügt)>> - 1Mhz interner Takt (ckdiv8 gesetzt) - dies ist die>> Standardeinstellung vor und nach dem Löschen des orginal beschriebenen>> microcontrollers und sollte auch so bleiben>> Beim Atmega32 gehst auch mit 8Mhz internem Takt (nur das Thomson wird>> dann nicht mehr erkannt), bei 1Mht internem Takt rührt sich allerdings>> auch beim Atmega32 nichts mehr.>> ich denke mit 1 MHz geht eh nix mehr, egal welcher Atmel, das wäre dann> auch das was du schon beobachtet hastFrank M. schrieb:> KLaus schrieb:>> Mein Problem nun :>> Der RX pin des IRDA ist auf PG4 (T0/SEG23)>> Der TX Pin des IRDA ist auf PB4 (OC0A/PCINT12)>> IRMP funktioniert nicht mit IRDA. Diese IRDA-Controller benutzen ein> eigenes Protokoll, dass Du überhaupt nicht beeinflussen kannst. Du> kannst versuchen, den IRDA-Controller direkt über RX/TX als UART> auszulesen bzw. Daten darüber zu senden. Das hat dann aber gar nichts> mehr mit IRMP zu tun.>> Gruß,>> Frank
Hallo Frank
Danke für deine Antworten
Aber jetzt werd ich wohl mal kalt duschen gehen müssen, ich dachte
dieser irda controller lässt sich auch dazu bewegen die Daten korrekt zu
empfangen und zu senden da ich ja schon Daten empfing aber eben nur im
log modus .
Da hab i jetzt echt 2 oder 3 wochen rumgedoktert , oh MAMA MIA , wo werd
ich noch enden :-(. hätt wohl eher fragen sollen.
Zu aller Anfang versuchte ich alllerdings eine Kommunikation direkt über
Software Uart mit 2 Gasmeldern.
Ich dachte ich könnte das einfach bei 1Mhz Controllertakt und 2400Baud
übertragen incl verdunklung der Irda Transceiver.
Schien mir das einfachste . Aber irgendwas mache ich falsch .
Was genau da nicht funktioiert kann ich erst sagen wann ich wieder an
diesem Punkt anfange und weitermache. Denke aber es wurden einfach keine
Daten am empfänger ausgegeben.
Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip
zwischen uart(controller) und irda transceiver auskommt und trotzdem
Daten übertragen werden können?
gruß klaus
es gab mal Irdeo welche über UART ging
mit etwas umlöten geht auch die Kombi WinLirc und IR Assistent
aber das hat nix mit hier zu tun, aber mit einem Tiny85 IR zu seriell
und an der Seriellen geht das im Prinzip
Klaus schrieb:> Kann mir evtl jemand ein Example zeigen das ohne encoder/decoder chip> zwischen uart(controller) und irda transceiver auskommt und trotzdem> Daten übertragen werden können?
willst du wirklich echtes IRDA ?
http://www.infrarotport.de/
Hallo Frank,
eigentlich ist es garnicht so dramatisch mit dem IrDA Transceiver. Doch
eines Vorweg. Das IrDA Software Protokoll ist ausgelegt, um
unterschiedlichste Geräte miteinander zu verbinden. Nach dem OSI Modell
laufen zwischen zwei Geräten viele Kommunikationen ab, in denen sich die
Geräte über Protokoll, maximale Geschwindigkeit, Errorkodierung und CRC
Prüfsumme austauschen. Doch das sind alles sachen, die Du für eine
eigene Punkt zu Punkt Verbindung NICHT benötigst. Wenn Du den gesamten
Overhead weglässt, dann bleibt beim TFBS4711 Transceiver ein IR Bauteil
das im Halbduplex Verfahren Daten senden und empfangen kann - und das
sehr gut und fehlerfrei innerhalb gewisser Grenzen.
Der TFBS4711 ist ein SIR Bauteil, kann also Daten senden und empfangen
von 2400 Baud bis 115200 Baud. Das SIR Protokoll ist zum UART Signal
nicht kompatibel, weil High und Low als RZI (Return to Zero Inverted)
gesendet werden. Um den Unterschied zum UART zu verstehen, schaue Dir
doch bitte einmal das Bild 13 im Physical Layer von IrDA an:
http://www.vishay.com/docs/82513/physical.pdf.
Statt einem "High" auf dem UART muß ein "Low" bereitgestellt werden. Für
jedes "Low" auf dem UART muß ein "3/16 High" am TFBS4711 angelegt
werden. Wenn Du den TFBS4711 so ansteuerst, dann funktioniert die
Übetragung per IR genau so, als ob Du zwei Controller per UART
kommunizieren lässt.
Du hast jetzt zwei Möglichkeiten:
1) Wenn Du das IrDa Bauteil an einem normalen UART eines Controllers
anschliessen willst, benötigst Du ein Encoder-Decoder Baustein zwischen
UART und TFBS4711. Ich habe vor vielen Jahren diese beiden
mitentwickelt:
http://www.vishay.com/docs/81749/toim5232.pdfhttp://www.vishay.com/docs/82546/toim4232.pdf
2) Wenn Du die Möglichkeit hast den TFBS4711 an zwei freien Pins des
Controllers anzuschliessen, kannst Du das Timing des SIR Protokolles
einfach selber programmieren.
Im Internet findest Du Softwarerealisierung des SIR Protokolls wie
z.B.hier: http://www.gaw.ru/pdf/TI/app/msp430/slaa044.pdf
Wenn Du den Weg weiter verfolgen möchtest, dann müsste ich mal in meinem
Fundus graben. Ich habe da eventuell noch Sourcecode Relikte für
Prozessoren ...
Gruß
kokisan
Hallo Frank,
sorry, meine ausführlichen Hinweise in meinem letzten Beitrag waren
nicht für Dich, sondern für Klaus gedacht ;-)
Frank, klasse Arbeit mit IRMP !!!
Gruß
kokisan
Hallo erstmaltschuldigung für das späte schreiben , bin gerade beruflich
unterwegs
Danke für die vielen Anworten
@jar
willst du wirklich echtes IRDA ?
Nein das ist das was ich will .
Mein Bestreben ist es , den IRDA Transceiver mit einem irda transceiver
kommunizieren zu lassen ohne zusätzliche beschaltung (wie vorgegeben)
und sowie es didi in seinem ersten block beschrieben hat .
und evtl. auch über eine normale sende und empfangsdiode daten hin und
herschieben und das ganze mit einem atmega169 bei 3,6 Volt.
Es muss keine hoche Reichweite haben , 20cm reichen.
@Didi S. (kokisan2000)
Du bist meine Rettung , du hast mich verstanden :-))
Da ich nicht flexibel bin mit meiner Hardware , is ja ein fertig
verbauter Gasmelder mit Atmega169 und Irda Transceiver
daher kommt für mich nur zweiteres in Frage .
Und ich hab mich grad riesig gefreut da du was zu dem 3/16 Dings
geschrieben hast und das auch noch auf einfache weise
Ich werde mich mit diesem Thema beschäftigen,dazu kann ich sehr gerne
deine SourceCode Schnippseln brauchen .
Evtl. hast du noch mehr solcher Erklärungsstützen auf Lager :-)
wautschis AT gmx dot net
Versuche dann auch mir das gabnze zu erklären was aber am Anfang immer
ein Riesenberg ist da einzusteigen:-(
Wanns mal klar ist dürfte das ganze gar nicht mehr so schwer werden
@didi
eins hab i ja noch vergessen
die original firmware die drauf
war konnte alles mit dem chkdiv8 teiler und 1 Mhz Prozessor takt
die programmierer haben das eben auch per programmierung gelöst und das
mit 1mhz takt
bzw. es ist nooch ein quarz verbaut aber warsch. ein uhrenquarz.
dder gasmelder soll ja 18 monate rückwärts zählen und ausgehen oder wann
Batterie leer ist.
Die Übertragung der sensor daten fand auch in unmittelbarerer nähe zum
controllgerät statt.
Hans W. schrieb:> Darf das IRMP auch kommerziell genutzt werden?
Da IRMP unter der GPL-Lizenz läuft, kann es auch kommerziell genutzt
werden.
Sobald Du die erste Million verdient hast, kannst Du mich gern mit 10%
beteiligen ;-)
Huhu, ich habe meine schaltung jetzt vom attiny88 auf den atmega88
umgebaut. und siehe da es funktioniert ... super :)
aber eine sache funktioniert nicht, und zwar wenn ich am sender folgende
routine benutze:
1
for(VCount=0;VCount<=7;VCount++)
2
{
3
if(POSITION==VCount)
4
{
5
V=VCount;
6
irmp_data.command=VCount;
7
send=1;
8
}
9
}
dann funktioniert es mit diesem am empfänger:
1
for(Vcommand=0;Vcommand<=7;Vcommand++)
2
{
3
if(irmp_data.command==Vcommand)
4
{
5
V=Vcommand;
6
}
7
8
}
ich möchte aber sehr viele IR codes benutzen und diese teilen,also
dachte ich mir ich benutze 0x0A** für eine reihe, und 0x0B** (mit * von
0-f) für die zweite reihe.
Jetzt habe ich beim sender eingegeben:
for (VCount=0; VCount<=7; VCount++)
{
if( POSITION == VCount )
{
V=VCount;
irmp_data.command = (VCount + 0x0A00);
send=1;
}
}
und dasselbe eben auch beim empfänger. wenn ich da einen wert aufaddiere
dann geht es nicht mehr :( weiß jemand woran das liegen könnte...?
grüüße
nach etwas rumprobieren bin ich auf die idee gekommen, dass es wohl
probleme gibt bei den größeren werten....
wenn ich das command
0x0011 schicke, kann ich es emfpangen
bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie
kann das sein.... what is wrooong?
Ich benutze das NEC Protocol, der rest ist deaktiviert.
grüße
Martin K. schrieb:> wenn ich das command> 0x0011 schicke, kann ich es emfpangen> bei 0x0101 klappts dann nicht mehr.... vielleicht liegts ja daran? wie> kann das sein.... what is wrooong?
Wenn Du unter
http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle
nachschaust, siehst Du, dass das NEC-Protokoll aus
16 Bit Adresse + 8 Bit Kommando + 8 Bit invertiertes Kommando
besteht. Das NEC-Protokoll unterscheidet also nur 256 Kommandos. Damit
geht Dein Wertebereich für irmp_data.command von 0x00 bis 0xff. Das
Senden von 0x0101 ist also dasselbe wie das Senden von 0x0001, da IRSND
die zusätzlichen Bits außerhalb des Wertebereichs einfach wegblendet.
> Ich benutze das NEC Protocol, der rest ist deaktiviert.
Versuche, mit 8 Bit hinzukommen oder wähle ein anderes Protokoll, wenn
Du Daten übertragen willst.
Gruß,
Frank
P.S.
Ich verstehe Deine for-Schleifen nicht:
> for (Vcommand=0; Vcommand<=7; Vcommand++)> {> if( irmp_data.command == Vcommand )> {> V=Vcommand;> }> }
Das kannst Du doch einfach als
if( irmp_data.command <= 7 )
{
V=irmp_data.command;
}
schreiben. Eine Schleife ist überhaupt nicht notwendig.
Hallo zusammen,
erstmal: ein grandioses Projekt!
Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die
Volume +/- Befehle einer Apple Remote (die alte), um damit einen
Motorpoti zu steuern. Das ganze werte ich wie folgt aus:
1
while(1)
2
{
3
irmp_get_data(&irmp_data);
4
5
if(irmp_data.protocol==IRMP_APPLE_PROTOCOL)
6
{
7
// Volume up
8
if((irmp_data.command&0x00FF)==0x0B)
9
{
10
// Motor rechts
11
PORTD|=(1<<PD5);
12
PORTD&=~(1<<PD6);
13
}
14
// Volume down
15
elseif((irmp_data.command&0x00FF)==0x0D)
16
{
17
// Motor links
18
PORTD|=(1<<PD6);
19
PORTD&=~(1<<PD5);
20
}
21
else
22
{
23
// Motor stop
24
PORTD&=~(1<<PD5);
25
PORTD&=~(1<<PD6);
26
}
27
}
28
}
Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal
kurz Volume up oder down drücke, steht in irmp_data.command so lange
dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine
Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss
ich irmp_data nach dem auslesen irgendwie bereinigen?
Gruß,
Ephraim
Ephraim Hahn schrieb:> Im wesentlichen funktioniert das bei mir auch grandios. Ich empfange die> Volume +/- Befehle einer Apple Remote (die alte), um damit einen> Motorpoti zu steuern. Das ganze werte ich wie folgt aus:>
1
>while(1)
2
>{
3
>irmp_get_data(&irmp_data);
4
>
Das ist falsch, Du musst den Rückgabewert prüfen. Wenn 0 zurückkommt,
wurde nichts empfangen.
Also:
1
while(1)
2
{
3
if(irmp_get_data(&irmp_data))
4
{
5
...// hier Deinen restlichen Code einfügen
6
}
7
}
> Funktioniert soweit prima, bis auf eine Kleinigkeit: Wenn ich einmal> kurz Volume up oder down drücke, steht in irmp_data.command so lange> dieser Befehl, bis ich einen anderen sende. D.h. ich muss irgendeine> Taste drücken, um den Motor zu stoppen. Ist das ein Fehler? Oder muss> ich irmp_data nach dem auslesen irgendwie bereinigen?
Wie gesagt: Du musst den Rückgabewert prüfen. irmp_data wartet nicht,
bis etwas empfangen wird, sondern kommt sofort zurück, wenn keine Daten
anstehen. In diesem Fall steht natürlich noch das alte Zeugs in der
Datenstruktur. Ein Zurücksetzen der Datenstruktur ist nicht notwendig,
da die Daten valide sind, wenn irmp_get_data() TRUE zurückliefert.
Gruß,
Frank
ohhhjee ich idiot vielen dank.... naatürlich es gibt nur 8 command
bit... :( ich habe das problem gelöst indem ich einfach zwei
verschiedene adress bits genutzt habe ;)
vielen dank
p.s. die schleife muss man net verstehen G
Verzeihung, aber ich muss mich noch mal melden.
Konnte die Geschichte erst jetzt testen, da ich noch andere Hardware
Probleme zu lösen hatte.
Dieser Code hier (wie oben) funktioniert, aber mit besagtem Problem,
dass er nicht mehr aufhört, wenn ich einmal gedrückt habe, da ich den
Rückgabewert von /irmp_get_data()/ nicht prüfe.
1
while(1)
2
{
3
irmp_get_data(&irmp_data);
4
5
if(irmp_data.protocol==IRMP_APPLE_PROTOCOL)
6
{
7
// Volume up
8
if((irmp_data.command&0x00FF)==0x0B)
9
{
10
// Motor rechts
11
PORTD|=(1<<PD5);
12
PORTD&=~(1<<PD6);
13
}
14
// Volume down
15
elseif((irmp_data.command&0x00FF)==0x0D)
16
{
17
// Motor links
18
PORTD|=(1<<PD6);
19
PORTD&=~(1<<PD5);
20
}
21
else
22
{
23
// Motor stop
24
PORTD&=~(1<<PD5);
25
PORTD&=~(1<<PD6);
26
}
27
}
28
}
Jetzt nehme ich die Überprüfung mit rein:
1
while(1)
2
{
3
if(irmp_get_data(&irmp_data))
4
{
5
if(irmp_data.protocol==IRMP_APPLE_PROTOCOL)
6
{
7
// Volume up
8
if((irmp_data.command&0x00FF)==0x0B)
9
{
10
// Motor rechts
11
PORTD|=(1<<PD5);
12
PORTD&=~(1<<PD6);
13
}
14
// Volume down
15
elseif((irmp_data.command&0x00FF)==0x0D)
16
{
17
// Motor links
18
PORTD|=(1<<PD6);
19
PORTD&=~(1<<PD5);
20
}
21
else
22
{
23
// Motor stop
24
PORTD&=~(1<<PD5);
25
PORTD&=~(1<<PD6);
26
}
27
}
28
}
29
else
30
{
31
// Motor stop
32
PORTD&=~(1<<PD5);
33
PORTD&=~(1<<PD6);
34
}
35
}
Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?
Hallo!
Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem
Atmega8 zum laufen zu bekommen.
Dazu habe ich einfach das aktuelle release genommen und 2 Zeilen
eingefügt: der aktuell empfangene Command soll auf PortD ausgegeben
werden.
Ich habe auf meinem STK600 den PORTD des Atmega8 mit den LEDs verbunden
und den IR-Decoder an PB6 angeschlossen. Leider bleibt PORTD immer auf
LOW.
Wenn ich PORTD = PINB; hinzufüge, sehe ich die LED an PD6 blinken, also
das Signal kommt an.
Vielleicht kann sich das mal jemand anschauen, was das Problem ist? Ich
hab den Quellcode beigelegt.
Vielen Dank und liebe Grüße,
etMax
>> Und nun tut sich garnichts mehr. Habe ich irgendetwas übersehen?
Ja, hast Du. Schau Dir mal obigen Code genauer an. Wenn irm_get_data()
NICHTS empfängt, wird der else-Zweig durchlaufen und damit Dein Motor
gestoppt. Denke daran: irmp_get_data() wartet NICHT. In 99,9995% der
Zeit wird der else-Zweig durchlaufen und Dein Motor gestoppt.
Wenn Du mal was sendest, springt der Motor kurz an und wird danach
direkt wieder gestoppt. Das ist so kurz, dass Du das gar nicht siehst.
Daher: Werfe den unteren else-Zweig komplett raus, also lass folgendes
stehen:
1
while(1)
2
{
3
if(irmp_get_data(&irmp_data))
4
{
5
if(...)
6
{
7
...
8
}
9
elseif(...)
10
{
11
...
12
}
13
else// NUR HIER MOTORSTOPP!
14
{
15
...
16
}
17
}
18
// KEIN else!
19
}
Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere
gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du
haben möchtest.
Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.
Gruß,
Frank
etMax schrieb:> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem> Atmega8 zum laufen zu bekommen.
Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft
und nicht mit den werksseitig eingestellten 1 MHz?
Schau mal hier:
http://www.engbedded.com/fusecalc/
Gruß,
Frank
>> Die Volume-Tasten regeln dann den Links-/Rechtslauf, jede andere> gedrückte Taste stoppt den Motor. Das ist vermutlich auch das, was Du> haben möchtest.>> Fazit: Wenn NICHTS empfangen wurde, dann auch NICHTS tun.>> Gruß,>> Frank
genau dieses Verhalten ergab sich ja bereits aus meiner allerersten
Version. Was ich aber will, ist, den Motor nur zu bewegen solange die
entsprechende Volume Taste gedrückt wird. Nun dachte ich, solange ich
drücke, ist /irmp_get_data()/ positiv und liefert mir in der struct den
Befehl. Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt,
als meine apple remote senden kann, und sich dadurch praktisch nichts
bewegt, da der Motor stoppt, bevor er überhaupt angelaufen ist? In dem
Fall müsste ich eine Art delay bzw. timeout für einen empfangenen befehl
integrieren.
Frank M. schrieb:> etMax schrieb:>>> Ich stehe grade auf dem Schlauch: Ich versuche, die IRMP mit einem>> Atmega8 zum laufen zu bekommen.>> Hast Du die Fuses vom ATmega8 auch so angepasst, dass er mit 8 MHz läuft> und nicht mit den werksseitig eingestellten 1 MHz?>
Hallo,
ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und
eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay
zwischen den Blinkern mache.
Ephraim Hahn schrieb:> Kann es sein, da aber irmp_get_data() wesentlich öfter empfängt,> als meine apple remote senden kann, [...]
Ja, natürlich. Eine FB sendet ca. 10 Frames pro Sekunde. irmp_get_data
wird aber wesentlich öfter mit FALSE zurückkommen.
Vorschlag der Lösung:
In der timer-ISR einen globalen Zähler hochzählen (static volatile
uint16_t), diesen in den beiden if-Blöcken, wo Du tatsächlich
Volume-UP/DOWN empfängst, auf 0 zurücksetzen. Im else-Block prüfen, ob
ein bestimmer Wert des Zählers überschritten wurde. Dann hast Du Deinen
Timeout und Du kannst den Motor stoppen.
Gruß,
Frank
etMax schrieb:> ja, meine Fuses stehen auf e4 d9 . F_CPU ist auf 8000000 definiert und> eine Lampe blinkt auch im Sekundentakt, wenn ich 10 mal 100ms delay> zwischen den Blinkern mache.
Welche Fernbedienungen hast Du ausprobiert?
Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle
aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal
RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter
"more protocols" steht. Die "exotic protocols" lasse erstmal weg.
Gruß,
Frank
Michael K. schrieb:> Hast du das implementiert oder muss speziell diese Version genommen> werden? Und wie steht es mit IRSND?
Nein, habe ich nicht implementiert. Aber wenn Du Dir die Unterschiede
durch Suchen nach IRMP_FLEXIBLE_VERSION anschaust, siehst Du, dass Jan
neben einigen kosmetischen Sachen (die so für den ARM nicht existieren)
lediglich das Interface der Funktion irmp_ISR() geändert hat, um den
IRMP-Source komplett hardwareunabhängig zu machen.
Über den hardware-abhängigen Teil
1) wie lese ich einen PIN?
2) wie rufe ich irmp_ISR() 10000 mal (oder 15000 mal) pro Sekunde auf?
schweigen sich seine Source-Änderungen leider aus. Da ich selber mit ARM
noch nichts gemacht habe, kann ich Dir da auch nicht weiterhelfen. Aber
eigentlich musst Du nur die beiden obigen Punkte klären, das ist alles.
Dann kann man das auch in den aktuellen IRMP integrieren.
Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().
Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion
timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro
Sekunde aufgerufen wird.
Wie Du siehst, ist das nicht schwierig. Wenn Du Dich einigermaßen mit
ARM-Programmierung auskennst, solltest Du das hinbekommen. Deine
Source-Anpasssungen baue ich gern in den IRMP ein.
Gruß,
Frank
Frank M. schrieb:> Punkt 1) ist simpel: Schreibe in irmpconfig.h ein Macro namens input().> Punkt 2) ist auch nicht viel schwieriger: Schreibe eine Funktion> timer_init() und sorge damit dafür, dass irmp_ISR() 15000 mal pro> Sekunde aufgerufen wird.
Werde ich tun. Ich komme dann nochmal auf dich zu.
Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt
doch den Timer 2 dafür, oder?
Michael K. schrieb:> Werde ich tun. Ich komme dann nochmal auf dich zu.
Prima, bin gespannt.
> Wie sieht ist es mit der Hardwareunabhängigkeit von IRSND aus? Du nutzt> doch den Timer 2 dafür, oder?
IRSND benutzt (genauso wie IRMP) einmal den Timer 1 (irsnd_ISR()) und
zusätzlich den Timer 2 für die Erzeugung der Modulationsfrequenz. Bei
den ATtinys ist es stattdessen der Timer 0, siehe irsndconfig.h.
Gruß,
Frank
Frank M. schrieb:> Welche Fernbedienungen hast Du ausprobiert?>> Ich sehe, dass Du in irmpconfig.h lediglich die Standsrd-Protokolle> aktiviert hast, die ich als wichtig empfinde. Aktiviere bitte auch mal> RC5, RC6, NEC16, NEC42, GRUNDIG, SIEMENS, NOKIA - also alles, was unter> "more protocols" steht. Die "exotic protocols" lasse erstmal weg.
Oh je, ich bin ja ein Idiot...
Ich habe eine RC5-Fernbedienung und war mir sicher, dass RC5 zu den
Standard-Protokollen gehört...
Danke fürs Drüberschauen, Frank! Jetzt klappt es einwandfrei!
etMax
Hallo,
ich versuche gerade eine 44-Tasten-RGB-Fernbedienung eines 5m
LED-Streifens am Atmega88 zum laufen zu kriegen, bis jetzt ohne Erfolg.
Der RGB Streifen wurde
in der Bucht gekauft und beinhaltet bereits einen Controller und eine
Fernbedienung.
Das IR-Protokoll ist das NEC-Protokoll. Im Anhang habe ich das Timing
für die "Rot"-Taste.
In der IRMPconfig.h wurde nur das NEC-Protokoll aktiviert und der Pin
für den Empfänger auf PB.5 gesetzt.
Der Atmega88 wurde, wie in der main.c beschrieben, für interne 8MHz
gefused. Für die Übertragung der "Rot"-Taste habe ich folgende Werte
erhalten:
Startbit > 0x00 (Adressbyte) > 0xFF (inv. Adressbyte) > 0x1A
(Commandbyte) > 0xE5 (inv. Commandbyte) > Stopbit
Könnt ihr bitte mal über meine Switch-Case-Anweisung drüber schauen, ob
die Abfrage des irmp_data.command richtig ist?
Jetzt hab ichs. Ich darf nur das 8-Bit-Commandbyte verwenden. Jetzt
gehts:-) Das IRMP ist ein Spitzenprojekt!!:-) Danke Frank für dieses
Projekt.
Frohe Ostern
Hallo zusammen,
Ich habe die Library IRMP und IRSND schon mit Erfolg auf einem Atmega8
anwenden können. Dafür erstmal ein dickes Lob für die tolle Lib.
Jetzt habe ich nur das Problem, dass ich an dem Atmega8 die SPI
Schnittstelle dringend benötige. Leider liegt der PWM Pin für die IRSND
Funktion auf dem MOSI Pin PB3. Ist es möglich diesen auf den PB1 (OC1A)
zu verschieben um die SPI Schnittstelle zu nutzen?
Seht ihr da eine Möglichkeit?
hallo zusammen
ich möchte gernen meine digicam über infarot ansteuern und habe da
folgendes gefunden
begin remote
name Olympus_RM-1
bits 16
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100
header 8853 4489
one 559 1670
zero 559 555
ptrail 559
repeat 8853 2259
pre_data_bits 16
pre_data 0x61DC
gap 107013
toggle_bit 0
begin codes
capture 0x000000000000807F
w 0x00000000000040BF
t 0x000000000000C03F
- 0x00000000000020DF
+ 0x000000000000A05F
end codes
end remote
wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden
mfg
Graf-von-Socke
Graf-von-Socke schrieb:> begin remote
Ich vermute mal, dass das eine lirc-Berschreibungsdatei ist? Ich kenne
mich damit nicht so aus, aber ich versuche mal zu deuten:
> bits 16
16 Datenbits.
> header 8853 4489
Das ist ein offenbar vom Timing ein NEC-Startbit, siehe auch:
http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail> one 559 1670> zero 559 555
Das sieht ebenso nach NEC-Timing aus.
> ptrail 559
Könnte das Stoppbit sein.
> pre_data_bits 16
16 bits vor den Datenbits, scheint die NEC-Adresse zu sein.
> pre_data 0x61DC
0x61DC ist offenbar die Adresse.
> capture 0x000000000000807F> w 0x00000000000040BF> t 0x000000000000C03F> - 0x00000000000020DF> + 0x000000000000A05F
Das scheinen die Kommando-Codes zu sein.
> wie muss ich das nun verstehen und wie muss ich das auf irsend anwenden
Also probiere es mal mit
Ulli -- schrieb:> hat keiner eine Vorstellung, ob man den IRSEND Pin bei einem Atmega8 von> PB3 auf PB1 ändern kann und wenn ja wie?
IRSND benötigt den Timer1 bereits für das periodische Aufrufen der
15kHz-ISR. Wenn Du die ISR über einen anderen Timer laufen lässt, kannst
Du natürlich IRMP anpassen an OC1A (PB1). Dazu musst Du allerdings den
Code erweitern.
IRMP benutzt den Timer0 bzw. Timer2 zur Erzeugung der
Modulationsfrequenz per PWM. Der veraltete ATmega8 ist da ziemlich
beschränkt. Wenn Du ihn gegen den moderneren ATmega88 tauschst, hast Du
die Wahl zwischen OC2A (PB3) und OC2B (PD3), ohne den IRSND-Code
erweitern zu müssen.
Gruß,
Frank
Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht
gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht
ausreichen? Auch nicht mit Code Erweiterung?
Ulli -- schrieb:> Frank: D.h. ja, mit einem Atmega8 kann ich IRMP und IRSND nicht> gleichzeitig mit der SPI Schnittstelle benutzen, da die Timer nicht> ausreichen? Auch nicht mit Code Erweiterung?
Mit Code-Erweiterung gehts auch mit einem ATmega8.
Dann benutzt Du halt Timer 0 oder Timer 2 zum Aufruf der ISR mit 15kHz
und verwendest Timer1 (und damit OC1A = PB1) als Sender-Ausgang. Aber
die PWM-Routinen für die Modulation des Timer 1 musst Du dann neu
schreiben, die habe ich nur für Timer 0 oder Timer 2 implementiert.
Hallo Frank,
mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC
einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71
auf 95 aktualisiert und nun funktioniert die Erkennung nicht:
* DENON wird nur noch sporadisch erkannt
* RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON
Signalen
* SIEMENS werden nicht mehr alle Tasten erkannt
* die FB meines SHARP (siehe Beiträge Januar 2011) wird nicht mehr
erkannt
Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du
alle
nach Änderungen am Quellcode testest. Anscheinend macht es aber die
Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte
für meine Probleme verantwortlich sein?
Gruß, eku
hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe
einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was?
wenn beide versetzt voneinander angeordnet sind ok.. aber
ueber/nebeneinander?
Christian Ruppert schrieb:> hm, passt vielleicht nicht ganz zum thema aber trotzdem.. ich habe> einige schaltungen mit 2 TSOPs gesehen, bringt das tatsaechlich was?> wenn beide versetzt voneinander angeordnet sind ok.. aber> ueber/nebeneinander?
Vielleicht arbeiten beide mit unterschiedlichen Modulationsfrequenzen?
eku schrieb:> Kürzlich habe ich von Revision 71> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:>> * DENON wird nur noch sporadisch erkannt
so was ähnliches ist mir auch ab und an mal aufgefallen,
habe alles aktiviert was <=15kHz ist und bekam für eine Kaseikyo alles
von Siemens bis RUWIDO je nach Tastendrück
habe nun wieder die aktuelle in meine SW eingepflegt
* $Id: irmp.h,v 1.73 2012/02/24 15:00:18 fm Exp $
und prompt kommt wieder der Fehler:
../irmp.h:489:1: warning: "TRUE" redefined
ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?
#ifndef FALSE
#define FALSE 0
#endif
#ifndef TRUE
#define TRUE !FALSE
#endif
hatte ich auch in der letzten eingebauten Version nachgerüstet, aber
jedesmal nachfummeln ist irgendwie unnötig zeitraubend
Korrektur zur Erkennung
umstellen mit rc5_ISR(); nach (void) irmp_ISR();
half für bessere Erkennung
ändert aber nix am redefine TRUE FALSE Problem
if (! irsnd_ISR()) // call irsnd ISR
{ // if not busy...
(void) irmp_ISR(); // call irmp 3-16µs
(void) rc5_ISR(); // call rc5 8-10µs
}
eku schrieb:> mein IRMP hat NEC, RC5, DENON, NUBERT, GRUNDIG, NOKIA, SIEMENS und FDC> einkompiliert und tastet mit 15kHz ab. Kürzlich habe ich von Revision 71> auf 95 aktualisiert und nun funktioniert die Erkennung nicht:>> * DENON wird nur noch sporadisch erkannt> * RUWIDO wird erkannt obwohl nicht einkompiliert, z.B. bei DENON> Signalen> [...]
Ich habe probeweise IRMP mit obigen Protokollen übersetzt und dann gegen
IR-Data/denon-15kHz.txt laufen lassen... keine Probleme bei der
Erkennung.
> Meine zugelieferten Scans liegen in IR-Data und ich nehme an, dass Du> alle> nach Änderungen am Quellcode testest.
Ja, ich checke sie immer mit test-suite.sh. Das Script schaltet alle
Protokolle frei und lässt den generierten IRMP gegen die im Shell-Script
aufgeführten Scan-Dateien laufen. Nur wenn diese fehlerfrei durchgehen,
gebe ich eine Version frei. Natürlich ist mit diesem Check lediglich
eine notwendige Bedingung für Fehlerfreiheit gegeben, aber nicht
unbedingt eine hinreichende.
> Anscheinend macht es aber die> Kombination der aktivierten Protokolle. Welche Deiner Änderungen könnte> für meine Probleme verantwortlich sein?
Keine Ahnung. Nenne mir bitte die Scan-Dateien unter IR-Data, die von
Dir sind. Dann kann ich diese nochmal gezielt in Deiner Kombination
testen.
Gruß,
Frank
...Sorry! ich wollte nicht die ganze Datei posten!
Die Lirc Remote files sind ja sehr hilfreich, leider habe ich bislang
keine ausführliche Beschreibung des Formats gefunden.
Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?)
Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein.
Die Timings sehen dagegen recht passend aus.
Sehe ich es richtig, dass ich mir hier gewissermaßen ein NEC36
implementieren muss?
Gruß
finnjet schrieb:> Meine Frage dazu ist folgende: 24 Daten Bits + 8 Pre-data (address?)> Bits scheint mir ja weder das normale NEC noch NEC48 Protokoll zu sein.> Die Timings sehen dagegen recht passend aus.
Stimmt, diese sehen tatsächlich passend aus. Schalte einfach
IRMP_LOGGING in irmpconfig.h ein, scanne die Tasten 0...9 ein und poste
hier die Text-Datei. Ich baue das Protokoll dann ein. Den Aufbau der
Scan-Datei siehst Du auch als Beispiele unter IR-Data/*.txt. Kommentare
mit # eingeleitet wären hilfreich.
Hast Du denn schon mal Deine FB mit IRMP getestet?
Gruß,
Frank
Hallo Frank,
ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt.
Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für
den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.
Grüße
Stampede
Hallo Hans,
Hans W. schrieb:> ich möchte einfach mal "DANKE" sagen für dieses hervorragende Projekt.> Gut dokumentiert, innerhalb von 30min in meinen Code eingebunden und für> den verwendeten PIC32 portiert. Lief auf Anhieb, so soll es sein.
Erstmal Danke fürs "Danke" ;-)
Ist bei Deiner Portierung vielleicht irgendetwas wichtiges, das in den
allgemeinen Source zurückfließen sollte?
Gruß,
Frank
Frank M. schrieb:> vielleicht irgendetwas wichtiges, das in den> allgemeinen Source zurückfließen sollte?
möglicherweise in:
irmp.h:489:1: warning: "TRUE" redefined
ich mag nun nicht jedesmal suchen wo das herkommt
wäre folgendes nicht sinnvoll ?
#ifndef FALSE
#define FALSE 0
#endif
#ifndef TRUE
#define TRUE !FALSE
#endif
oder lag der Fehler bei mir ?
ansonsten, auch von mir noch mal ein Riesen DANKE
auch wenn ich momentan nicht weiterkomme in der ausschliesslichen
Nutzung von IRMP allone, in der Verbindung mit "meinen" alten RC5
Auswertecode tuts ganz hervorragend :-)
alle Versuche das change key bit vom RC5 in IRMP zu generieren sind bis
jetzt fehlgeschlagen, aber macht nix, irgendwann finde(t) ich (sich) ne
Lösung
jar
jar schrieb:> möglicherweise in:>> irmp.h:489:1: warning: "TRUE" redefined
Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist
eine Folge einer TRUE-Definition, die aus Deinem Source kommt.
Sagt der Compiler nicht, wo die ursprüngliche Definition steht?
> ich mag nun nicht jedesmal suchen wo das herkommt> wäre folgendes nicht sinnvoll ?>> #ifndef FALSE> #define FALSE 0> #endif> #ifndef TRUE> #define TRUE !FALSE> #endif
Könnte ich machen, aber theoretisch gibt es ja tausend Möglichkeiten
solcher Konflikte.
Gruß,
Frank
Frank M. schrieb:> Es gibt im IRMP-Source ausschließlich diese Stelle. Das redefine ist> eine Folge einer TRUE-Definition, die aus Deinem Source kommt.
die ich bestimmt auch brauche an der Stelle ;-)
klaro um das abzukürzen suche ich alle meine TRUE def und bau das bei
mir ein
dann muss das in IRMP.H nicht geändert werden, sollte auch klappen
(hoffe ich)
danke
jar
PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht
auszuschliessen das man immer wieder drüber stolpert, also so dumm ist
mein Gedanke nicht das auch in irmp.h einzubauen
jar schrieb:> PS. da IRMP aber immer in andere Projekte integriert wird ist es nicht> auszuschliessen das man immer wieder drüber stolpert, also so dumm ist> mein Gedanke nicht das auch in irmp.h einzubauen
Ich habe es jetzt so geändert:
Frank M. schrieb:> #ifndef TRUE> #define TRUE 1> #define FALSE 0> #endif>> Kommt mit dem nächsten Release
Klasse, braucht man nicht mehr zusätzlich Hand anzulegen beim Einbau !
danke
jar
Hallo zusammen,
ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch
so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit
20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren,
und die sehen auch plausibel aus. Nun dachte ich, dass das Senden
deutlich einfacher ist, aber das will einfach nicht laufen. Die
Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel
aufgebaut. Ich hab schon folgende Dinge überprüft:
- 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz
duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.
- ein/ausschalten der PWM passt auch
- ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd
erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC
empfängt auch genau dieselbe Bitfolge.
Bin gerade etwas ratlos. Hat vielleicht noch jemand nen heißen Tipp für
mich?
Viele Grüße
Sebastian
Hallo Frank,
ich hab da ein etwas seltsames Problem mit IRMP:
Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass
eine Taste reproduzierbar andere Daten liefert als normalerweise. Das
hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe,
danach gehen wieder alle wie gewohnt.
Von dem Fehler sind mehrere (alle?) Tasten meiner FB betroffen.
Der (falsche) Code, den IRMP ausgibt, wenn der Fehler auftritt, scheint
dann erstmal immer der gleiche zu sein, konnte das aber noch nicht
verifizieren. Es ist aber auf jeden Fall nicht bei jeder Taste der
gleiche.
Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der
Bug bei
Protocol 8
Address 4
Command 1E8 und 0E8
Bei anderen Tasten auch, aber da müsste ich die richtigen Codes erst
wieder raussuchen.
Hatte auch schon überlegt, ob vielleicht die Fernbedienung einen Bug
hat, aber eine andere mit NEC-protocol zeigt das gleiche Verhalten, wenn
auch deutlich schwerer zu provozieren.
Ich weiß momentan nicht so recht weiter. In meiner Software hab ich
nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.
Vielleicht hat hier ja jemand eine Idee, was das sein könnte. Bei Bedarf
mach ich natürlich gerne noch weitere Versuche.
Viele Grüße,
Sebastian
Sebastian schrieb:> ich hab ja mittlerweile IRMP auf einem PIC16F917 (mit CCS Compiler (auch> so'n Kandidat für dreckstool.de)) zum laufen bekommen. Der PIC läuft mit> 20Mhz und die ISR mit 9,766kHz. Ich kann also die IR Signale decodieren,> und die sehen auch plausibel aus.
Welches IR-Protokoll?
> Nun dachte ich, dass das Senden> deutlich einfacher ist, aber das will einfach nicht laufen. Die> Schaltung und die Bauteile des Sendezweigs sind nach dem Artikel> aufgebaut. Ich hab schon folgende Dinge überprüft:> - 36/38kHz Trägerfrequenz --> gemessen mit Multimeter 35.95/38.15kHz> duty cycle jeweils 49.6%. Sieht auf'm Scope eigentlich auch gut aus.> - ein/ausschalten der PWM passt auch> - ich hab mir das binär Signal zu einem empfangen Kommando mit irsnd> erzeugt und sende das direkt aus einem Puffer. Der IR-Receiver am PIC> empfängt auch genau dieselbe Bitfolge.
Es lässt sich mit IRMP auch wieder dekodieren?
Es kann sein, dass der Original-Empfänger vom Timing her empfindlicher
ist als IRMP, welcher auch noch bei größeren zeitlichen Abweichungen das
Signal noch erkennt.
Ein IRMP-Scan (siehe auch IR-Data/*.txt) von der Original-FB wäre nicht
schlecht.
Sebastian ... schrieb:> ich hab da ein etwas seltsames Problem mit IRMP:>> Die meiste Zeit läuft alles einwandfrei. Nur manchmal kommt es vor, dass> eine Taste reproduzierbar andere Daten liefert als normalerweise.
Wie sehen die Daten bzgl. Protokollnr, Adresse und Kommando-Code vorher
und nachher aus?
> Das> hält dann so lange an, bis ich wieder eine andere Taste gedrückt habe,> danach gehen wieder alle wie gewohnt.
Das hört sich so an, als ob irgendetwas in der Statemachine nicht
korrekt zurückgesetzt wird.
Hilfreich wäre ein IRMP-Scan mit einer Tastenfolge, wo der Fehler
auftritt. Dann müsste ich das unter Linux reproduzieren können.
> Meine Ferbedienung ist eine DENON RC-176, definitiv aufgetreten ist der> Bug bei> Protocol 8> Address 4> Command 1E8 und 0E8
Das oben ist der korrekte? Wie sieht der fehlerhafte Code aus?
> Ich weiß momentan nicht so recht weiter. In meiner Software hab ich> nichts gefunden, zumal ich den Bug auch schon in zwei Projekten hatte.
Gibt es außer IRMP noch weitere Software-Module, die in beiden Projekten
stecken?
Ich bräuchte da Scans... sonst kann ich Dir wahrscheinlich nicht helfen.
Hallo Frank,
anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba
CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die
Pulslänge misst. Vielleicht fällt dir ja noch was auf.
Viele Grüße
Sebastian
Hallo Sebastian,
Sebastian schrieb:> anbei die Scans von den beiden Fernbedienungen (Denon RC-1016, Toshiba> CT-90327). Ich habe mir allerdings selbst eine ISR geschrieben, die die> Pulslänge misst. Vielleicht fällt dir ja noch was auf.
Beide Scans lassen sich einwandfrei decodieren, auch wenn ich sagen
muss, dass die 9766Hz beim Denon-Protokoll schon arg knapp sind.
00000010111111010101100010100111 p = 2, a = 0xbf40, c = 0x001a, f = 0x00
Zu rx_denon_9766Hz.txt:
Du hast bei #1 bis #5 immer dieselbe Taste gedrückt, oder?
Zu rx_test_19990Hz.txt: auch kein Problem.
Wenn ich Dein vorhergendes Posting richtig verstanden habe, hast Du
lediglich ein Problem beim Senden dieser Codes mittels IRSND.
Wenn ich den Output von IRSND in den IRMP mittels Unix-Pipe schicke,
klappt alles sauber:
1
# ./irsnd 8 0008 023c 0 | ./irmp
2
010001000111100
3
010000111000011 p = 8, a = 0x0008, c = 0x023c, f = 0x00
4
5
# ./irsnd-20kHz 8 0008 023c 0 | ./irmp-20kHz
6
010001000111100
7
010000111000011 p = 8, a = 0x0008, c = 0x023c, f = 0x00
8
9
# ./irsnd-20kHz 2 bf40 001a 0 | ./irmp-20kHz
10
00000010111111010101100010100111 p = 2, a = 0xbf40, c = 0x001a, f = 0x00
Vergleich des IRSND-Outputs mit Deiner Text-Datei:
Hallo Frank,
ja, #1-#5 in rx_denon_9766Hz.txt ist immer dieselbe Taste.
OK, du meinst also, dass das von IRMP decodierte Signal OK ist. Davon
gehe ich auch aus. Ich verstehe nur nicht, warum das Senden im IRSND
nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden
des Denon/Nec Protokoll?
Das Scannen des IRSND Signals über einen 2. µC werde ich die mal
testen...
Gruß
Sebastian
Sebastian schrieb:> OK, du meinst also, dass das von IRMP decodierte Signal OK ist.
Ja.
> Ich verstehe nur nicht, warum das Senden im IRSND> nicht klappt. Welchen Wert für F_INTERRUPT empfiehlst du für's Senden> des Denon/Nec Protokoll?
Für das NEC-Protokoll sind 10kHz (oder Deine 9,7kHz) ausreichend. Daher
sollte Dein Toshiba-Fernseher problemlos klarkommen. Ich habe auch einen
Toshiba, den ich mit IRSND und 10kHz problemlos bedienen kann.
Bei Denon ist das jedoch kritisch, siehe auch:
http://www.mikrocontroller.net/articles/IRMP#Pulse-Distance_Protokolle
Auszug für Denon:
In der Praxis (diverse Scans von verschiedenen IRMP-Anwendern) sind es:
0-Bit 310µs Puls, 745µs Pause
1-Bit 310µs Puls, 1780µs Pause
Laut diverser Dokus im Netz sind es jedoch:
0-Bit 275µs Puls, 775µs Pause)
1-Bit 275µs Puls, 1900µs Pause)
Das sind gerade mal 3 Timer-Takte zum Generieren der Pulse. Da könnte
die Abweichung schon so groß sein, dass der Denon-Empfänger das nicht
mehr akzeptiert. Bei 15kHz und mehr sollten die Abweichungen wesentlich
geringer sein.
Ich habe gerade mal Deine 1990er Scans durch den IRMP-Analyzer
geschickt:
Die Pulse entsprechen eher den Werten aus der Doku, der Rest eher den
Erfahrungen, die bisher mit Denon-FBs gemacht wurden.
Du könntest also mal
1
#define DENON_PULSE_TIME 310.0e-6 // 310 usec pulse in practice, 275 in theory
in
1
#define DENON_PULSE_TIME 275.0e-6 // 310 usec pulse in practice, 275 in theory
ändern. Ich bezweifle aber, dass das was bringt. Irgendetwas anderes ist
da faul, denn zumindest Dein Toshiba sollte problemlos mit dem
IRSND-Output klarkommen.
> Das Scannen des IRSND Signals über einen 2. µC werde ich die mal> testen...
Ja, ich glaube, das bringt uns eher weiter.
Gruß,
Frank
Hallo Frank,
Vielen Dank schonmal für deine Antwort und sorry, dass ich so lange
brauche. Ist zur Zeit leider etwas stressig hier.
Hier jetzt also die Ergebnisse:
Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch
zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch
bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich
wieder eine beliebige andere Taste drücke. Der Falsch erkannte Code ist
"characteristisch" für die Taste und jedes mal der gleiche, wenn der
Fehler auftritt.
Der Fehler dürfte ziemlich sicher in IRMP liegen. Habe testweise einen
Controller nur mit IRMP geflasht. Den Code habe ich nur um eine simple
UART-routine erweitert, die die erkannten codes ausgibt.
Außerdem ist aufgefallen, dass, wenn der extra eingerichtete Controller
die codes falsch erkannt hat, ein anderes Projekt gleichzeitig die
Commandos richtig decodiert. Bei dem anderen Projekt tritt der Fehler
prinzipiell aber auch auf. Die Fernbedienung kanns also nicht sein.
Vielleicht noch der Empfänger. Das sind zwei unterschiedliche in den
beiden Projekten. Wäre aber komisch...
Der fehler tritt auch mit anderen Tasten auf, aber mit diesen habe ichs
jetzt mal nachvollzogen. Auch mit einer anderen Fernbedienung
(NEC-protocol) habe ich den Bug schon gehabt, aber wie gesagt kaum
reproduzierbar.
Anbei sind Scans der vier Tasten mit 20kHz. Sobald ich zeit finde,
scanne ich auch die ganze Fernbedienung ein, aber jetzt muss ich erstmal
ins Bett.
Viele Grüße,
Sebastian
Die (vermutlich) Richtigen Codes sind:
Stop-Taste
Protocol 0x08
Address 0x0004
Command 0x01E8
Play >-Taste
Protocol 0x08
Address 0x0004
Command 0x00E8
Pause -Taste
Protocol 0x08
Address 0x0004
Command 0x02E8
Play < -Taste
Protocol 0x08
Address 0x0004
Command 0x03A8
Stop -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0217
Play > -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x317
Pause -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0117
Play < -Taste Falscher Code
Protocol 0x08
Address 0x0004
Command 0x0057
Hallo Sebastian,
Sebastian ... schrieb:> Drücke ich die unten genannten Tasten oft genug im Wechsel (reichen auch> zwei davon), wird irgendwann mal eine konsequent falsch erkannt. Auch> bei mehrmaligem drücken kommt immer der gleiche falsche code bis ich> wieder eine beliebige andere Taste drücke.>
Ich glaube zu verstehen, was da falsch läuft. Das Denon-Protokoll
schickt jeden Frame zweimal raus, wobei beim zweiten mal die
Command-Bits invertiert sind. Zwischen diesen beiden Frames ist eine
Pause von 65ms.
IRMP wartet immer den 2. Frame ab und vergleicht die Command-Bits, ob
sie invertiert sind. Soweit okay, aber: Bekommt IRMP mal den ersten
Frame nicht richtig mit, klinkt er sich beim 2. Frame ein und wartet
dann auf den vermeintlichen 2. Frame mit invertierten Bits. Drückst Du
die Taste dann nochmal, nimmt er den 1. Original-Frame als invertierten
Frame auf und bestätigt diesen als vermeintlich richtigen Code. Aus
diesem "falschen Takt" kommt IRMP nur wieder raus, wenn irgendwann
wieder eine Übertragunsstörung auftritt.
Diesen Fehler kann man hier auch gut erkennen:
> Die (vermutlich) Richtigen Codes sind: [...]> Command 0x01E8> Stop -Taste Falscher Code [...]> Command 0x0217
0x01E8 = 01 1110 1000
0x0217 = 10 0001 0111
Man sieht, dass hier alle 10 Bits gekippt sind. Das gleiche gilt auch
für die anderen Kommando-Codes, die Du genannt hast.
Um diesen Fehler zu beheben, muss ich eine Abbruchbedingung in IRMP
einbauen, wie lange er auf den 2. Frame warten soll. Ist die Zeit
wesentlich größer als 65ms, sollte IRMP den empfangenen Frame einfach
verwerfen und wieder "von vorn" anfangen.
> Anbei sind Scans der vier Tasten mit 20kHz.
Danke. Aus irgendeinem Grunde kommt der IRMP mit den Scans nicht ganz
klar. Er erkennt zwar Denon, bricht aber dann irgendwann die Decodierung
ab. Das schaue ich mir nochmal genauer an, kann sein, dass bei 20kHz der
Log-Buffer überläuft und die Scans nicht lang genug sind für 2 Frames.
Warum verwendest Du 20kHz und nicht 15kHz?
Gruß,
Frank
Hallo Frank,
das klingt ja schonmal sehr gut!
Das mit den Scans scheint meine Schuld bzw die der Fernbedienung zu
sein. Das dürften unvollständige Kommandos sein. Sorry dafür.
Kam so, dass ich wiederholungen vermeiden wollte, also möglichst kurz
gedrückt hab. Aber die FB scheint die Übertragung wieder abzubrechen,
wenn man zu kurz drückt. Jedenfalls Reagieren ein IRMP-Projekt und der
original-Verstärker nur, wenn ich die Taste etwas länger drücke. Dann
sind auch die scans des gleichzeitig laufenden Scan-IRMPs länger.
Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem
Tastendruck. Und mit 15kHz.
Die 20kHz kamen übrigens aus der überlegung "viel hilft viel" ;) Das
Verhalten mit kurzen und langen scans hab ich aber bei 15 und 20 kHz
gleichermaßen.
Viele Grüße,
Sebastian
Hallo Sebastian,
Sebastian ... schrieb:> Anbei jetzt also ein Komplettscan der FB mit ein wenig längerem> Tastendruck. Und mit 15kHz.
Nachdem ich alle Kommentarzeilen mit "#" auch als solche gekennzeichnet
und in irmp.c die Zeile
geändert habe, ging der Scan einwandfrei durch.
Deine FB scheint außergewöhnlich lange Pulse zu machen. Ich empfehle Dir
daher, die Toleranz in irmp.c auf 20% zu erhöhen - so wie oben
geschrieben. Ich werde das ebenso ins nächste Release einbauen.
Mittlerweile habe ich eine Abbruchbedingung in der IRMP-Statemachine
eingebaut, damit die invertierten Frames beim Denon-Protokoll nicht als
Initial-Frames erkannt werden. Funktioniert soweit mit künstlich
generierten "fehlerhaften" Scan-Dateien tadellos. Desweiteren habe ich
das Denon-Timing im IRSND auch verbessern können, so dass das Verhalten
(nach 65ms kommt der invertierte Frame) nun exakt nachgebildet wird.
Damit sollten Deine Probleme erledigt sein. Das neue Release kommt in
Kürze.
Viele Grüße,
Frank
Es steht eine neue Version 2.2.0 von IRMP + IRSND zum Download bereit.
Download über Artikel:
http://www.mikrocontroller.net/articles/IRMP#Downloadhttp://www.mikrocontroller.net/articles/IRMP#Download_IRSND
und auch übers SVN möglich:
http://www.mikrocontroller.net/svnbrowser/irmp/
Die wichtigsten Änderungen IRMP:
- Portierung auf ARM STM32
- Bugfix Frame-Erkennung beim Denon-Protokoll
Die wichtigsten Änderungen IRSND:
- Portierung auf ARM STM32 (ungetestet!)
- Bugfix Timing für 2. Frame beim Denon-Protokoll
Da IRMP/IRSND nun auf den Zielsystemen AVR/PIC/STM32 läuft, war eine
größere Umstrukturierung des Sources notwendig, um weiterhin die
Konfigurationsdateien irmpconfig.h und irsndconfig.h möglichst einfach
und übersichtlich zu belassen.
Die IR-Protokoll-spezifischen Definitionen haben dafür eine neue
Include-Datei irmpprotocols erhalten. Ebenso sind die für die
verschiedenen Zielsysteme notwendigen Konstanten in die neue Datei
irmpsystem.h gewandert.
Anzupassen ist weiterhin lediglich eine Datei, nämlich irmpconfig.h bzw.
irsndconfig.h.
Achja, noch eine Kleinigkeit: Der Applikationssource darf nun nur noch
irmp.h bzw. irsnd.h per Include einfügen. Alle anderen notwendigen
H-Dateien werden automatisch von irmp.h bzw. irsnd.h per Include
eingefügt.
Also:
1
#include"irmp.h"
2
3
main()
4
{
5
....
6
}
Siehe auch die dazugehörigen Beispiel-Dateien main.c bzw. irsndmain.c.
Sämtliche Änderungen und neue Dateien wurden auch im Artikel IRMP
dokumentiert bzw. aktualisiert.
Vielen Dank an kichi (Michael K.) für seine unermüdliche Arbeit an der
STM32-Portierung.
Wünsche viel Spaß,
Frank
P.S.
@Sebastian: Mit diesem Release sollten Deine Probleme mit dem
Denon-Protokoll behoben sein.
Hallo zusammen,
ein paar Bugs wurden in der STM32-Portierung gefunden und behoben. Im
SVN unter
http://www.mikrocontroller.net/svnbrowser/irmp/
ist daher jetzt die Version 2.2.1 eingecheckt.
Die Änderungen betreffen nur die STM32-Variante. Für AVRs und PICs hat
sich gegenüber 2.2.0 nichts geändert. Sobald die Tests von IRSND unter
STM32 abgeschlossen sind, wird es auch neue Zip-Dateien direkt zum
Download aus dem IRMP-Artikel geben.
Viele Grüße,
Frank
Hallo!
Ich habe mal eine kleine Zwischenfrage:
Ich wollte nun den USB IR Remote Receiver updaten.
Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.
Leider kann aber der Compiler (AVR Studio 5) die Defines von der
"irmpconfig.h" nicht mehr lesen.
Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:
#if IRMP_LOGGING == 1
drinnen.
Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden
ist.
Was gibt es da für einen Trick um das wieder hinzubekommen?
Hallo Hugo,
Hugo Portisch schrieb:> Nun darf ja nurmehr die "irmp.h" ins Projekt eingebunden werden.> Leider kann aber der Compiler (AVR Studio 5) die Defines von der> "irmpconfig.h" nicht mehr lesen.
Kann ich mir überhaupt nicht erklären, denn in irmp.h steht nun
das
#include irmpconfig.h
drin.
Das heisst, irmpconfig.h wird eingebunden und dadurch auch z.B.
IRMP_LOGGING definiert.
> Ich habe z.B. in der "configUSBIRRemoteReceiver.h" ein:> #if IRMP_LOGGING == 1> drinnen.
Sollte ganz normal (also wie immer) gehen.
Ich habe gerade mal testweise in das Beispiel-main.c von IRMP eingefügt:
1
#if IRMP_LOGGING == 1
2
xxxxxx
3
#endif
und IRMP_LOGGING auf 1 in irmpconfig.h gestellt.
Beim Neucompilieren bekomme ich sofort den (gewünschten) Syntax-Error
als Indikator, dass IRMP_LOGGING den korrekten Wert hat.
> Das ist aber nun immer 0 weil die irmpconfig.h nicht mehr eingebunden> ist.
Doch, wird sie - über irmp.h
> Was gibt es da für einen Trick um das wieder hinzubekommen?
Es ist eigentlich kein Trick notwendig, siehe oben.
Kann es sein, dass Dein Compiler nicht bemerkt, dass Du irmpconfig.h
geändert hast und er deshalb Dein main-Modul nicht neu übersetzt? Du
solltest auf jeden Fall irmpconfig.h mit in Dein Projekt einfügen. Sonst
fehlt die Abhängigkeit und die entsprechenden C-Sources werden nicht neu
übersetzt, wenn Du irmpconfig.h änderst.
Im Notfall hilft auch eine Neuübersetzung des kompletten Codes.
Gruß,
Frank