Infrarot-Decoder MCP2120

Wenn du Mode auf L legst, sollten die Daten durch gereicht werden.
Macht er das?

pegel schrieb:
> Wenn du Mode auf L legst, sollten die Daten durch gereicht werden.
> Macht er das?

Probiere ich morgen mal aus.

Marc H. schrieb:
> Du darfst MODE nicht einfach nur auf High oder Low legen! Du musst dem
> umschalten um vom Command in den Data-Mode zu schalten!

Sicher? Wo liest du das? Auf der Senderseite klappt die Kodierung ja 
auch und dort liegt er auch auf High..

DH schrieb:
>> Du darfst MODE nicht einfach nur auf High oder Low legen! Du musst dem
>> umschalten um vom Command in den Data-Mode zu schalten!

Hier steht auf Seite 5 auch, dass man ihn auf VSS oder VCC legen soll, 
wenn man die Baudrate per Hardware festlegt.

http://ww1.microchip.com/downloads/en/AppNotes/00756a.pdf

So neuer Tag neues Glück.

pegel schrieb:
> Wenn du Mode auf L legst, sollten die Daten durch gereicht werden.
> Macht er das?

Nein macht er nicht. Der Ausgang ändert sich nicht egal was an MODE 
anliegt.
Er liegt durchgehend auf 3,3 V.

Ich habe im Anhang ein Bild vom Ausang des TFDU4301 angehängt. Das 
Signal geht auf den RX-IR Eingang des MCP2120. Das Signal sieht an sich 
gut aus. Was mir aufgefallen ist, ist dass das Signal nicht bis auf 
Masse gezogen wird, sondern nur bis auf ca. 0,4 -0,5 V. Im Datenblatt 
des MCP2120 steht auf Seite 14, dass der Chip maximal 0,2 V als Low 
Pegal erkennt. Deswegen dachte ich zunächst, dass er deswegen die 
negative Flanke nicht erkennt und den Ausgang dauerhaft auf High legt. 
Ich hab dann aber mal mit einem Kabel den Eingang einfach auf Masse 
gezogen und am Ausang tat sich auch dann rein gar nichts. Als würde der 
Chip schlafen...

Mittlerweile habe ich auch schon beide Chips (MCP2120 und TDFU4301) 
Einmal ausgetauscht um einen Defekt auszuschließen. Noch irgendjemand 
ein Idee? Hier noch das Datenblatt.

http://ww1.microchip.com/downloads/en/DeviceDoc/21618b.pdf

Tausend Dank

Bild vergessen...

DH schrieb:
> Der Ausgang ändert sich nicht egal was an MODE
> anliegt.

Das hatte ich im DB falsch interpretiert.
Bei Mode=L geht der TX vom µC wieder direkt an den RX zum µC.

65 kHz? Komische Frequenz. Ob er damit was anfangen kann?

pegel schrieb:
> Das hatte ich im DB falsch interpretiert.
> Bei Mode=L geht der TX vom µC wieder direkt an den RX zum µC.

Mit µC meinst du den MCP2120? Wo steht das im Datenblatt?

pegel schrieb:
> 65 kHz? Komische Frequenz. Ob er damit was anfangen kann?

Hatte mich auch ein wenig gewundert. Aber das Signal wird auf der 
Senderseite auch vom MCP2120 erzeugt. Demnach dachte ich, dass das 
passen sollte. Baudrate liegt bei 115200. Das Signal vom UART ist aber 
ja auch nicht periodisch von daher ist die angezeigte Frequenz wohl 
nicht so ausschlaggebend. BAUD2..1 am MCP2120 ist auf Senderseite und 
Empfängerseite 100. Und auch der Mikrocontroller sendet mit einer 
Baudrate von 115200. Das passt also.

DH schrieb:
> Mit µC meinst du den MCP2120?

Nein, den, der Daten vom und zum MCP2120 schaufelt.

Es sich auch an beiden Seiten die gleichen Quarze?

2.4.1.2. "To place the MCP2120 into Command Mode, the
MODE pin must be at a low level. When in this mode,
any data that is received by the MCP2120’s UART is
"echoed" back to the controller and no encoding/
decoding occurs."

Sollte heissen:

Es befinden sich auch an beiden Seiten die gleichen Quarze?

pegel schrieb:
> Es befinden sich auch an beiden Seiten die gleichen Quarze?

Ja die Quarze sind auf beiden Seiten baugleich und schwingen auch. Mit 
Oszi geprüft. Beide haben 7,3728 MHz.

Mir ist noch nicht klar wie man 115000 bit/s in ein 65000 Impulse/s
Datenstrom kriegt.
Aber vielleicht denke ich verkehrt.

pegel schrieb:
> Mir ist noch nicht klar wie man 115000 bit/s in ein 65000 Impulse/s
> Datenstrom kriegt.
> Aber vielleicht denke ich verkehrt.

Naja ich habe mir das so erklärt, dass die Daten die ich sende, (In 
meinem Fall ein String mit "123") keine feste Abfolge von Nullen und 
Einsen hat und damit auch keine feste Frequenz. Ich denke also, dass das 
was das Oszi da "misst" nix mit der eigentlichen Frequenz der 
Übertragung zu tun hat.

Sende doch mal was anderes. Z.B. 0xAA in einer Schleife.

Dann am Oszi so einstellen das ein oder zwei Byte komplett zu sehen 
sind.

Du denkst also, dass der Chip ein falsches Signal bekommt? Ich denke 
selbst dann müsste er irgendetwas dekodieren und nicht einfach 
durchgehend high ausgeben. Die Pulszeiten von bisschen mehr als 2 µs 
sind ja auch voll okay. Also müsste er das auch wieder zurückwandeln 
können.

Habe gerade an anderer Stelle gelesen, dass der MCP2120 nicht 
gleichzeitig senden und empfangen kann. Anscheinend kann es zu Problemen 
kommen, wenn der TX Pin wie in meinem Fall nicht beschaltet ist. Der 
MCP2120 könnte den floatenden Pin als 0 interpretieren. Man könnte den 
Pin als per Pullup auf logisch 1 ziehen und somit einen inaktiven 
Transmitter "vortäuschen". Denkt ihr, dass das das Problem sein könnte?

Probier es einfach aus.
Vielleicht auch mal ein Reset auslösen und sehen ob sich etwas tut.

Als nächstes würde ich erst mal versuchen die FIGURE 2-2
im Datenblatt nach zu vollziehen und am Oszi die Sendesignale beobachten 
ob die Zeitlich wie in der Abbildung aussehen. Evtl. die Baudrate runter 
setzen.

Ich habe mal die Sende Timings für 115200Baud berechnet.

Ich habe mit dem STM32F103 RS232 und IRDA erzeugt und das berechnete 
Timing passt.
Ich denke es braucht schon ein passendes IRDA Protokoll mit stimmigem 
Timing das Decodiert werden kann.
Mit Startbit und Daten.
"Irgendwas" am Eingang bringt keine Daten am Ausgang.

Also am Besten zuerst Das Sende Timing prüfen.

Die Impulse auf dem Oszi Bild sind auch 2,4µs lang, dass sollten 1,63µs 
sein. Vielleicht ist das schon problematisch.

Ich meine die Impulse auf deinem Oszi Bild, die vom STM32 passen,
so wie im Datenblatt vom MCP.

Hi,

erstmal vielen Dank für deine Mühe !

Hast du die Pulse von dir auch mit dem MCP2120 erzeugt oder per 
Software?

Ich verstehe nicht 100%ig wie du auf die Berechnung kommst.

1 Bit ist klar. 1/115200. Wie hast du CLK berechnet?
Pulslänge sollte auch klar sein. (1/7372800)*12

Ich kann leider erst morgen wieder an das Oszi. Auf der Senderseite 
nutze ich den Open Collector Ausgang des TFDU4301 um eine IR-LED 
anzusteuern. Das mache ich um die Reichweite zu erhöhen, da ich so 
mehrere LEDs gleichzeitig ansteuern könnte. Eventuell gibt es auch dort 
bei der Ansteuerung des PNP-Transsistors Probleme..Im Anhang die 
Schaltung auf Senderseite. Das TXD-Signal kommt vom MCP2120. Vielen Dank 
nochmal für die Hilfe bei der Fehlersuche!

Hallo,

DH schrieb:
> Hast du die Pulse von dir auch mit dem MCP2120 erzeugt oder per
> Software?

nein, weder noch. Das macht das Hardware IRDA im STM32.

DH schrieb:
> 1 Bit ist klar. 1/115200. Wie hast du CLK berechnet?

16 CLK ergeben 1Bit.

Kannst ja mal direkt am IRDA_C und dann an der LED messen und 
vergleichen.
Notfalls zum Test die LED im TFDU direkt nutzen.

Soo..

ich habe heute einiges gemessen. Habe jetzt mit dem Mikrocontroller 0x55 
ausgegeben und eine alternierende Abfolge von Nullen und Einsen zu 
haben. Damit stimmt jetzt die angezeigte Frequenz vom Oszi schonmal. 
57,2 kHz. Das passt für 115200 Baut. Nachdem ich mir die Signale am 
Sender angeschaut habe, bin ich jetzt der Meinung dass das Problem 
bereits auf der Senderseite liegen könnte. In Bild 1 sieht man das 
Eingangssignal vom Mikrocontroller (blau)und die Puls am IR-TX Ausgang 
des MCP2120 (gelb). Das ist allerdings nur eine Momentaufnahme. In der 
laufenden Messung sind die Puls wie in Bild 2 zu sehen verschwommen. Die 
Puls treten also nicht immer an der selben Stelle auf, wobei der Abstand 
zwischen den Pulsen für 8 Bit Übertragung immer gleich ist.   Eventuell 
liegt das an dem Offset, der auf Seite 8 im Datenblatt beschrieben ist?! 
Bis dahin sieht denke ich alles noch okay aus. Die Pulse sind 1,6 µs 
lang und und auch die anderen Berechnungen von dir passen.

Das eigentliche Problem tritt denk ich nach dem TFDU4301 auf. Bild 3 
zeigt das Signal am Ausgang des TFDU4301 vor dem Basiswiderstand. An der 
steigenden Flanke ist eine Stufe zu erkennen. Ich habe keine Ahnung wo 
die herkommt. Allerdings führt sie dazu, dass der Puls vom Signal 
verlängert wird. Denn während der Stufe sperrt der Transistor noch 
nicht. Im vierten Bild ist das Signal, dass an der Basis anliegt. In 
Bild 5 kann man dann die resultierenden Pulse sehen, die auf die LED 
gehen. Der ist dann zu dem Zeitpunkt schon ca. 3,4µs.

Nach dem TFDU4301  Empfängerchip folgt dann Bild 6. Da ist das Signal 
dann 2,24 µs. Vielleicht bekommt der Chip das einfach nicht dekodiert.

Frage ist jetzt..Ist so eine Stufe am Transistor irgendetwas 
charakteristisches, das auf irgendetwas schließen lässt? Ich bin 
überfragt. Vielleicht fällt ja jemand etwas auf. Noch dazu: Elko C37 ist 
noch nicht auf der Platine. Den wollte ich erst einbauen, wenn mehrere 
LEDs an dem Transistor hängen.

Danke

So ein Widerstand Spannungsteiler kann das Signal schon verändern.

Probier doch erst mal die interne LED des TFDU4301 ohne Transistorstufe.
Dazu R10 entfernen und die Anode der LED anschließen.

pegel schrieb:
> Probier doch erst mal die interne LED des TFDU4301 ohne Transistorstufe.
> Dazu R10 entfernen und die Anode der LED anschließen.

Muss ich mal probieren ob das möglich ist. Die Chips sind schon auf 
einer gefertigten Platine. Viel Spielraum ist da nicht. Was mir auch 
noch aufgefallen ist. Wenn der Lastkreis nicht angeschlossen ist, dann 
ist das Signal nach dem TFDU4301 sauber.

DH schrieb:
> Wenn der Lastkreis nicht angeschlossen ist, dann
> ist das Signal nach dem TFDU4301 sauber.

Na also. Da haben wir es.

Falls du einen 74AC14 in der Kiste hast kannst du den als LED Treiber 
probieren. Wichtig: AC nicht HC.

pegel schrieb:
> Na also. Da haben wir es.

Was haben wir? :)

pegel schrieb:
> Falls du einen 74AC14 in der Kiste hast kannst du den als LED Treiber
> probieren. Wichtig: AC nicht HC.

Nein leider nicht. Und wie gesagt. Die Platinen sind schon gefertigt und 
bestückt. Müsste doch eigentlich irgendwie an der Transistorbeschaltung 
liegen, wenn das Signal ansonsten sauber ist oder?!..Für was genau soll 
der Chip helfen? Zum Invertieren oder um die Stufe mit dem 
Schmitt-Trigger zu eleminieren?

Danke dir

Axel S. schrieb:
> Unsinn. Nicht für 115.2kHz.

Wieso nicht? Der kann 24mA treiben und ist schnell.
Was spricht dagegen?

Axel S. schrieb:
> Daß er vollkommen überzogen ist? 24mA könnte übrigens auch der TFDU4301
> alleine treiben, dafür bräuchte er keinen externen Transistor. Die
> Schaltstufe mit dem BCP51 ist vollkommen daneben dimensioniert:
>
> - es fließen gut 25mA Basisstrom, aber kaum 20mA Kollektorstrom
> - der Transistor ist also massiv übersteuert
> - R11 ist zum schnellen Abschalten zu groß

Ich hatte am Anfang erwähnt, dass ich mehr als die eine LED an den 
Transistor hänge will. Da sollten dann bis zu 1 A Pulsstrom fließen. Die 
eine ist momentan nur zu Testzwecken.

Axel S. schrieb:
> Schaltstufe mit dem BCP51 ist vollkommen daneben dimensioniert:

Okay ich werde versuchen R11 zu reduzieren. Sonst noch Vorschläge? 
Dankeschön

DH schrieb:
> Ich hatte am Anfang erwähnt, dass ich mehr als die eine LED an den
> Transistor hänge will.

Daran hatte ich auch gedacht.
Für jede LED einen 74AC14 und die Belastung des TFDU4301 hält sich sehr 
in Grenzen.