Moin. ich habe zwischen zwei Atmegas eine Infrarotstrecke aufgebaut. Besteht grundsätzlich aus einem TFDU4301 als Transceiver und einem MCP2120 als Dekoder/Encoder für das UART-Signal. Schaltung vom Sender funktioniert und das Signal wird über die IR-LED gesendet. Probleme macht der Empfänger. Die Schaltung vom Empfänger ist im Anhang. Der TFDU4301 empfängt das IR-Signal und gibt auch ein sauberes Signal aus. (TP1) Nur der MCP2120 will einfach nicht funktionieren. Egal was am RX-IR Pin anliegt, der RX-Ausgang, der zum Atmega geht ist durchgehend auf High-Pegel. Ich habe alle Spannungen an den Pins kontrolliert. MODE, ENABLE und !RESET liegen auf High, BAUD-Pins sind der Geschwindigkeit entsprechend geschaltet. Der Quarz schwingt sauber und gleichmäßig. Nur am RX-Ausgang tut sich nix. Jemand eine Idee was das Problem sein könnte? Chip Defekt? Wäre komisch - Kommt direkt von der Rolle..
Angehängte Dateien:
-
IR_Komm.PNG
8,8 KB
Wenn du Mode auf L legst, sollten die Daten durch gereicht werden. Macht er das?
Du darfst MODE nicht einfach nur auf High oder Low legen! Du musst dem umschalten um vom Command in den Data-Mode zu schalten!
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
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.
DH schrieb: > 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? Du darfst ohnehin niemals einen digitalen Input floaten lassen, weil dadurch unzulässig hohe Querströme in der Eingangsstufe auftreten können. Pullup dran und gut. Ich frage mich ohnehin, warum Du nicht einen Chip genommen hast, dessen UART IRDA kann. Jeder PIC24 hat es eingebaut. fchk
Angehängte Dateien:
-
MCP2120_irda.png
13 KB
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.
Angehängte Dateien:
-
IR_Trans.PNG
3,3 KB
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
DH schrieb: > 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. Die Stufe ist ganz normal und an sich kein Problem. Der TFDU hat einen open-collector Ausgang und das Signal wird an diesem Punkt nur durch R11 und die BE-Strecke von K1 gegen +3.3V gezogen. Wenn der TFDU abschaltet, fällt der Strom schnell ab, der Spannungsabfall über R10 geht auf 0. Das ist der schnelle Anstieg. In der Basis-Zone von K1 ist aber noch Ladung gespeichert und die Miller-Kapazität schiebt auch noch ein bißchen nach. Die fließt jetzt langsam über R11 nach +3.3V ab. Der Transistor K1 macht langsam (naja) zu und gegen Ende des kleinen Plateaus bei (3.3-0.7)V sperrt er vollständig. > Allerdings führt sie dazu, dass der Puls vom Signal > verlängert wird. Wenn du willst, daß K1 schneller abschaltet, mach R11 kleiner. Ebenso mach R10 nicht kleiner als nötig. K1 soll nur knapp in die Sättigung gehen. Je mehr du K1 übersteuerst, desto langsamer schaltet er ab. pegel schrieb: > Falls du einen 74AC14 in der Kiste hast kannst du den als LED Treiber > probieren. Unsinn. Nicht für 115.2kHz.
:
Bearbeitet durch User
Axel S. schrieb: > Unsinn. Nicht für 115.2kHz. Wieso nicht? Der kann 24mA treiben und ist schnell. Was spricht dagegen?
pegel schrieb: > Axel S. schrieb: >> Unsinn. Nicht für 115.2kHz. > > Wieso nicht? Der kann 24mA treiben und ist schnell. > Was spricht dagegen? 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ß
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.