Hallo zusammen, nachdem ich erfolgreich das Projekt 'ICMP' getestet habe, möchte ich nun im nächsten Schritt das Projekt 'IRSND' testen, um so Fernbedienungen zu simulieren. Hierzu habe ich auf einem Mikrocontroller den Code vom Projekt IRSND geladen, auf einem Arduino-Board das Projekt 'ICMP', um die Funktion zu überprüfen. Als Mikrocontroller verwende ich einen AtMega1284P mit einem externen 16MHz Quarz. Leider empfange ich auf dem Arduino keine Protokolle ( bei anderen, handelsüblichen Fernbedienungen jedoch schon), und man sieht auch, wenn man eine Kamera vor der IR-LED hält, kein leuchten. Durch ein kleines LED-Blink-Programm konnte ich jedoch erkennen, dass die IR-LED blinkt, die Schaltung somit funktionstüchtig ist, und auch die Fuses gesetzt zu sein scheinen, da die Frequenz etwa passte. Daher gehe ich von einem Software-Fehler aus, die Hardware scheint funktionstüchtig zu sein. Die IR-Diode ist am Pin D6 angeschlossen, somit wird OCB2 als PWM-Pin verwendet. Ich habe einfach mal den gesamten Projekt-Code vom IR-µC angehangen, vielleicht weiß ja einer weiter. Falls die Informationen nicht ausreichen, meldet euch bitte. Einen schönen Abend noch wünscht Morpheus1997
Für diejenigen, die IRSND nicht kennen, hier die Projektseite: http://www.mikrocontroller.net/articles/IRSND Ich hoffe es findet sich noch jemand, der mir helfen kann. Grüße, Morpheus1997
Morpheus1997 schrieb: > nachdem ich erfolgreich das Projekt 'ICMP' getestet habe, Das Ding heist IRMP, nicht ICMP. > Als Mikrocontroller verwende ich einen AtMega1284P mit einem externen > 16MHz Quarz. F_CPU steht auf 16000000 im Projekt? Ich finde es nämlich weder in irsnd-avr-main.cproj noch in Debug/Makefile. > Leider empfange ich auf dem Arduino keine Protokolle ( bei > anderen, handelsüblichen Fernbedienungen jedoch schon), Dann ist was falsch konfiguriert. Ich finde in Deinem RAR-Paket auch zwei Dateien, nämlich: irsnd-avr-main.c irsnd-main-avr.c Welche von beiden Dateien ist denn ins Projekt eingebunden? Bist Du sicher, dass Du das richtige Modul mit main-Funktion verwendest? Eine von beiden main-Funktionen ist leer, das würde erklären, dass nichts ausgegeben wird. > und man sieht > auch, wenn man eine Kamera vor der IR-LED hält, kein leuchten. Laut irsnd-config.h benutzt Du IRSND_OC2B, das wäre PD6. Fragt sich jetzt nur, wie Du die LED angeschlossen ist. So wie im Artikel, mit einem Transistor, welcher das Signal negiert? > Durch ein kleines LED-Blink-Programm konnte ich jedoch erkennen, dass > die IR-LED blinkt, die Schaltung somit funktionstüchtig ist, Wenn Du die IR-LED direkt angeschlossen hast, funktioniert zwar Dein Blink-Programm, aber bestimmt nicht IRSND. Also: Zeig bitte die Schaltung. > und auch > die Fuses gesetzt zu sein scheinen, da die Frequenz etwa passte. "scheinen"? Bitte schreibe hier die Fuses-Werte konkret rein! > Daher gehe ich von einem Software-Fehler aus, die Hardware scheint > funktionstüchtig zu sein. Ich sehe da erstmal keinen Software-Fehler. Da IRSND tausendfach eingesetzt wird, ist auch im IRSND-Teil nicht von einem Fehler auszugehen - schon gar nicht, wenn du so etwas simples wie das NEC-Protokoll verwendest. Eher scheint etwas mit Deiner Konfiguration/Schaltung nicht zu stimmen. > Die IR-Diode ist am Pin D6 angeschlossen, > somit wird OCB2 als PWM-Pin verwendet. Direkt angeschlossen oder über einen Transistor - wie im Artikel angegeben? Ersteres wäre falsch.
Morpheus1997 schrieb: > Ich habe einfach mal den gesamten Projekt-Code vom IR-µC angehangen, > vielleicht weiß ja einer weiter. Es gibt nur sehr wenige mutige Seelen, die ein 126kB RAR auf ihren Rechner entpacken, um den Teil des Programmes, den du selber geschrieben hast, anzuschauen. Da IRMP und IRSND in sich stabil laufen, ist es also sinnvoll, nur die Teile des Programmes als Klartext anzuhängen, die du selber gemacht hast. Die Standardfragen sind: Morpheus1997 schrieb: > und man sieht > auch, wenn man eine Kamera vor der IR-LED hält, kein leuchten. Portpin auch als Ausgang deklariert? Timer ISR auch eingebunden? 'irsndconfig.h' durchgegangen und alles richtig eingestellt?
Matthias S. schrieb: > Portpin auch als Ausgang deklariert? Macht irsnd_init() automatisch. > Timer ISR auch eingebunden? Kommt darauf an, ob er irsnd-avr-main.c oder irsnd-main-avr.c ins Projekt eingebunden hat. In einer der beiden Module steckt nämlich eine leere main-Funktion. Nein..... die ist nicht von mir! ;-) Wenn er Pech hat, hat er das falsche .c ins Projekt genommen. > 'irsndconfig.h' durchgegangen und alles richtig eingestellt? Die config-Datei im Rar-Archiv sieht jedenfalls korrekt aus, was den Output-Pin betrifft. OC2B = PD6
:
Bearbeitet durch Moderator
Frank M. schrieb: > Macht irsnd_init() automatisch. Gibs zu - das macht die Datei nicht automatisch, da hast du ihr beigebracht :-) Mich irritiert, das der TE nix von der IR LED sieht. Selbst wenn die Transistorstufe nicht verbaut ist, müsste man ja, wenn auch invertiert, die IR LED sehen. Wird also vermutlich die fehlende Timer-ISR sein. > Nein..... die ist nicht von mir! ;-) Wie ist die denn da reingerutscht?
Matthias S. schrieb: > Wie ist die denn da reingerutscht? Die ist wohl vom TO selbst:
1 | /*
|
2 | * irsnd_avr_main.c
|
3 | *
|
4 | * Created: 22.08.2016 20:24:10
|
5 | * Author: MHunfeld
|
6 | */
|
7 | |
8 | #include <avr/io.h> |
9 | |
10 | int main(void) |
11 | {
|
12 | while(1) |
13 | {
|
14 | //TODO:: Please write your application code
|
15 | }
|
16 | }
|
Das hier in irsnd-main-avr.c sieht auch nicht koscher aus:
1 | #ifndef F_CPU // Das ist IRSND-Standard
|
2 | # error F_CPU unknown
|
3 | #endif
|
4 | |
5 | #define F_CPU 16000000UL // Das ist vom TO
|
6 | #include <util/delay.h> |
Wenn F_CPU vom Projekt her nicht definiert wäre, hätte der Compiler oben gemeckert - wie von IRSND auch gewünscht. Der TO definiert aber danach(!) nochmal F_CPU neu, vielleicht um so F_CPU zu korrigieren?!? @Morpheus1997: Bekommst Du Compiler-Warnings? Die dürfen NICHT sein. Der #define muss auf jeden Fall raus! Das obige wäre ein Indiz, dass F_CPU im Projekt falsch definiert ist, was für irsnd.c tödlich wäre.
:
Bearbeitet durch Moderator
Hallo, Frank M. schrieb: > F_CPU steht auf 16000000 im Projekt? Ich finde es nämlich weder in > irsnd-avr-main.cproj noch in Debug/Makefile. In der .cproj-Datei sollte man es sehen können. Ich habe es im C-Compiler als 'Symbol' eingetragen. Frank M. schrieb: > Laut irsnd-config.h benutzt Du IRSND_OC2B, das wäre PD6. Fragt sich > jetzt nur, wie Du die LED angeschlossen ist. So wie im Artikel, mit > einem Transistor, welcher das Signal negiert? Genau, mit dem Transistor als Negierer, wie im Schaltbild des jeweiligen Artikels, auch genau die selben Bauteile und Werte. Frank M. schrieb: > Dann ist was falsch konfiguriert. Ich finde in Deinem RAR-Paket auch > zwei Dateien, nämlich: > > irsnd-avr-main.c > irsnd-main-avr.c > > Welche von beiden Dateien ist denn ins Projekt eingebunden? Bist Du > sicher, dass Du das richtige Modul mit main-Funktion verwendest? Eine > von beiden main-Funktionen ist leer, das würde erklären, dass nichts > ausgegeben wird. Ups! Aber ja, ich hatte die richtige Main-Datei eingebunden, die andere wurde lediglich vom AVR-Studio automatisch generiert. Ich habe die andere Datei mit der leeren Main-Funktion gelöscht, das Problem wird dadurch leider nicht gelöst. Matthias S. schrieb: > Mich irritiert, das der TE nix von der IR LED sieht. Selbst wenn die > Transistorstufe nicht verbaut ist, müsste man ja, wenn auch invertiert, > die IR LED sehen. Das verwirrt mich auch. Frank M. schrieb: > Wenn F_CPU vom Projekt her nicht definiert wäre, hätte der Compiler oben > gemeckert - wie von IRSND auch gewünscht. Der TO definiert aber > danach(!) nochmal F_CPU neu, vielleicht um so F_CPU zu korrigieren?!? > > @Morpheus1997: Bekommst Du Compiler-Warnings? Die dürfen NICHT sein. > > Der #define muss auf jeden Fall raus! > > Das obige wäre ein Indiz, dass F_CPU im Projekt falsch definiert ist, > was für irsnd.c tödlich wäre. Ja, ich hatte Warnings bekommen, die sind nun jedoch weg, da ich das define gelöscht habe. Hat jemand sonst noch eine Idee, woran es liegen kann? Ich denke auch, dass es ein Konfigurationsfehler ist.
Okay, das Problem hat sich ein Stück weit gelöst. Ich habe nun eine andere Entwicklungsplattform mit einem anderen Quarz, 12MHz verwendet. Die F_CPU hab ich oberhalb des Codes von irsnd.c definiert, und die Fuses folgendermaßen eingestellt: lfuse:0x7f hfuse:0x19 efuse:0xff Nun kann ich tatsächlich im Sekundentakt IR-Signale empfangen. Allerdings leider noch nicht die erwarteten. Ich würde gerne die Fernbedienung einer Apple-TV simulieren. Hier habe ich beispielsweise für die OK-Taste die Signale irmp_data.address = 0x77E1; irmp_data.command = 0xBA35; ausgelesen. Wenn ich diese Daten jedoch in der main.c eintrage und versende, so empfange ich den Code '87EE AC53' Dementsprechend ist denke ich naheliegend, dass das Timing in irgendeiner Weise noch nicht passt, oder gibt es da eine andere logische Erklärung für? LG Morpheus1997
Bei meinen Versuchen mit NEC und Apple konnte ich immer mal wieder feststellen, das es anscheinend nicht möglich ist, die beiden voneinander eindeutig zu unterscheiden. Mal sagt mein IRMP Receiver, das es sich um Protokoll 2 handelt und manchmal um Protokoll 11 (?). Wenn du ga nicht weiterkommst und zufällig eine Windows32 Kiste mit Soundeingang besitzt, kannst du auch mal den IR Protokoll Analyzer von Ondrej Stanek installieren und dir mit einem alten Klinkenkabel und Phototransistor einen IR Kopf basteln: http://www.ostan.cz/IR_protocol_analyzer/ NEC Protokoll ist da mit drin und du kannst mal deinen eigenen Aufbau mit dem Programm vergleichen. Wohlgemerkt, da kommt kein fertiger IR Empfänger zum Einsatz, sondern lediglich ein IR Phototransistor.
:
Bearbeitet durch User
Morpheus1997 schrieb: > Wenn ich diese Daten jedoch in der main.c eintrage und versende, so > empfange ich den Code '87EE AC53' Apple kann ich Dir nicht empfehlen, da hier die Adresse fix ist. Apple ist eigentlich eine NEC-Variante mit fester Geräteadresse. Das heisst: IRSND ignoriert Deine Adresse und verwendet die feste von Apple. Ich empfehle Dir NEC zur Datenübertragung. Hier kannst Du eine 16-Bit-Adresse auswählen, z.B. FF00 ist hier weit verbreitet. Üblicherweise ist das 2. Adressbyte invertiert zum ersten, muss aber nicht sein. Wenn nicht, handelt es sich um das "Extended Nec Protocol". Als Kommando-Code ist der Werte-Bereich bei NEC 0-255, also ein Byte, nicht zwei. Das zweite Byte ist im NEC-Code die Invertierung des Kommando-Codes und wird von IRSND automatisch selbst generiert. Teste mal: NEC, Adresse FF00, Kommando 0 bis 255 (0x00 - 0xFF). Diese Werte solltest Du mit IRMP 1:1 empfangen können. Beachte bitte immer die Wertebereiche des jeweiligen Protokolls. Nur die wenigstens sind 16-Bit-transparent. Einige bestehen sogar aus Bits weniger als ein Byte. Eine genaue Beschreibung der Protokolle findest Du unter IRMP: Die IR-Protokolle im Detail
:
Bearbeitet durch Moderator
Matthias S. schrieb: > Bei meinen Versuchen mit NEC und Apple konnte ich immer mal wieder > feststellen, das es anscheinend nicht möglich ist, die beiden > voneinander eindeutig zu unterscheiden. Mal sagt mein IRMP Receiver, das > es sich um Protokoll 2 handelt und manchmal um Protokoll 11 (?). Danke für den Tip, wenn ich auf Protokoll 11, also dem eigentlich angedachten Apple-Protokoll umsteige, dann empfange ich zumindest den Adress-code richtig: Ich sende '77E1' und empfange dies auch. Allerdings stimmt der Kommando-Code immer noch nicht. Aus 'BA35' wandelt er nun 'AC8B'. Matthias S. schrieb: > Wenn du ga nicht weiterkommst und zufällig eine Windows32 Kiste mit > Soundeingang besitzt, kannst du auch mal den IR Protokoll Analyzer von > Ondrej Stanek installieren und dir mit einem alten Klinkenkabel und > Phototransistor einen IR Kopf basteln: > > http://www.ostan.cz/IR_protocol_analyzer/ > > NEC Protokoll ist da mit drin und du kannst mal deinen eigenen Aufbau > mit dem Programm vergleichen. > Wohlgemerkt, da kommt kein fertiger IR Empfänger zum Einsatz, sondern > lediglich ein IR Phototransistor. Alles klar, das werde ich bei Gelegenheit mal ausprobieren, auch wenn es immer eine ganz schöne Bastelei ist, den Soundkarteneingang als Oszilloskop zu missbrauchen, wie ich es schon einmal gemacht habe, um Funk-Steckdosen auszulesen. Frank M. schrieb: > Apple kann ich Dir nicht empfehlen, da hier die Adresse fix ist. Apple > ist eigentlich eine NEC-Variante mit fester Geräteadresse. Das heisst: > IRSND ignoriert Deine Adresse und verwendet die feste von Apple. Das Problem ist: Ich habe es auch mit diversen anderen Fernbedienungen versucht, als Beispiel Samsung-TV-Fernbedienungen. Das Protokoll natürlich dementsprechend angepasst. Mir ist es bisher jedoch leider noch nicht gelungen, den selben Code zu empfangen, den ich auch versuche zu senden.
Morpheus1997 schrieb: > Alles klar, das werde ich bei Gelegenheit mal ausprobieren, auch wenn es > immer eine ganz schöne Bastelei ist, den Soundkarteneingang als > Oszilloskop zu missbrauchen, wie ich es schon einmal gemacht habe, um > Funk-Steckdosen auszulesen. Das ist in diesem Fall eine Frage eines alten Klinkenkabels für den Mikroeingang des Rechners und zwei Lötstellen, um daran den Phototransistor anzulöten. (Emitter an Masse/Abschirmung und Kollektor an den Innenleiter) Die Speisung des Mikroeingangs speist den Phototransistor. Irgendwelche anderen Teile braucht man nicht. Das beschreibt Ondrej auch in der Doku. Geeignete Phototransistoren finden sich z.B. in Videorecordern für Bandende und -anfangserkennung.
:
Bearbeitet durch User
Morpheus1997 schrieb: > Danke für den Tip, wenn ich auf Protokoll 11, also dem eigentlich > angedachten Apple-Protokoll umsteige, dann empfange ich zumindest den > Adress-code richtig: Ich sende '77E1' und empfange dies auch. Allerdings > stimmt der Kommando-Code immer noch nicht. Aus 'BA35' wandelt er nun > 'AC8B'. Auszug aus https://www.mikrocontroller.net/articles/IRMP#APPLE : Daten 16 Adress-Bits + 11100000 + 8 Kommando-Bits Du kannst nur 8 Bits als Kommando-Code schicken, das obere Byte des Kommandos ist fix. > Mir ist es bisher jedoch leider noch nicht gelungen, den selben Code > zu empfangen, den ich auch versuche zu senden. Das ist mir allerdings unverständlich.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.