Forum: Mikrocontroller und Digitale Elektronik Probleme mit "IRSND"


von Morpheus1997 (Gast)


Angehängte Dateien:

Lesenswert?

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

von Morpheus1997 (Gast)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
}

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Morpheus1997 (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Morpheus1997 (Gast)


Lesenswert?

Weiß sonst noch jemand weiter? Werden weitere Informationen benötigt?

von Morpheus1997 (Gast)


Lesenswert?

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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Morpheus1997 (Gast)


Lesenswert?

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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.