Hi zusammen, nachdem mir in einem anderen Beitrag (Beitrag "IR-Emfänger TSOP 4838 an ATmega328P") schon sehr bei der Implementierung einer Infrarotverbindung per IRMP und IRSND geholfen wurde könnte ich nochmals Hilfe gebrauchen. Da die Thematik doch eine andere ist mach ich besser einen neuen Thread auf. Die Datenrate, welche ich bisher erreichen konnte reicht für meine Zwecke leider nicht aus, weshalb ich darüber nachdenke auf eine Verbdindung per IrDA umzusteigen. Ich möchte dabei gerne weiterhin meine Atmega328p nutzen. Jetzt meine Frage, reicht es den Schnittstellen-IC MCP2120 zwischen den MC und den IR-Tranciever zu hängen, um eine einfache Übertragung von Strings zwischen zwei Mikrocontrollern zu realisierer oder benötigt es noch die Implementierung eines Protokoll-Stacks auf dem MC. Ich wundere mich nur weil es auch noch den MCP2155 gibt. Wird der zwingend benötigt oder reicht der MCP2120. Ich blicke da nicht ganz durch. Danke schonmal :)
Nimm einfach die Transceiver TFDU4301 oder TFDU4101, findest Du bei Mouser. Such dort einfach mal nach IR-Transceiver. Frag mich bitte nicht, wo der Unterschied zwischen den beiden oben genannten Transceivern ist. Dazu solltest Du dann beide Datenblätter genau studieren. Die Transceiver kannst Du direkt an RX und TX eines UARTs hängen, denn sie können Senden und Empfangen. Ein zusätzlicher Chip wie der MCP2120 ist nicht notwendig. Da der UART dann mit 115200 Bd laufen sollte, empfehle ich Dir, einen entsprechenden Baudratenquarz für die ATmegas zu verwenden.
Danke für deine Antwort. Das klingt ja schonmal vielverspechend. Hätte nicht gedacht, dass es so ohne weiteres funktioniert. Was genau ist dann der Sinn dieser Bausteine? Das die Bautrate dort eingestellt werden kann? Datenblätter der zwei Transceiver kann ich natürlich selbst lesen. Muss es zwingend ein solcher Transceiver sein? Ich sehe laut Blockschaltbild im Datenblatt, dass da noch einiges an "Peripherie" Abseits der eigentlichen Dioden verbaut ist. Ich frage deshalb, da es so geplant ist, dass es mittig auf dem Tisch eine Station geben wird, die an alle Spieler Signale sendet, selbst aber nicht empfangen muss. Sie muss aber natürlich in alle Richtung der Spieler senden. Deswegen wäre es super wenn es einen Aufbau geben würde wie beim IRSND, wo man dann mehrere LEDs in alle Richtung mit einem Transistor schalten könnte. Ich könnte natürlich auch in alle Richtung einen Transceiver verschalten aber wäre das ja ein wenig übertrieben. Könnte man das irgendwie eleganter lösen? Echt super wie einem hier geholfen wird !
IR-Bastelei schrieb: > Muss es zwingend ein solcher Transceiver sein? Ich denke schon. Auf Sender-Seite macht der Baustein die Modulation und vermutlich auch noch irgendwelches Framing. Auf Empfängerseite entsprechend die schmalbandige Verstärkung, AGC, Demodulation etc. pp. > geplant ist, dass es mittig auf dem Tisch eine Station geben wird, die > an alle Spieler Signale sendet, selbst aber nicht empfangen muss. Sie > muss aber natürlich in alle Richtung der Spieler senden. Das ist nicht so günstig. Aber einige dieser Transceiver (z.B. der TDFU4100, dessen Datenblatt hier gerade herumfliegt) haben den Treiberausgang für die IR-LED herausgeführt. Da kannst du dann nachverstärken und externe LED ansteuern. So viele wie du halt brauchst, um 360° abzudecken.
Axel S. schrieb: > Ich denke schon. Auf Sender-Seite macht der Baustein die Modulation und > vermutlich auch noch irgendwelches Framing. Auf Empfängerseite > entsprechend die schmalbandige Verstärkung, AGC, Demodulation etc. pp. Okay. Sowas habe ich mir auch gedacht. Axel S. schrieb: > Das ist nicht so günstig. Aber einige dieser Transceiver (z.B. der > TDFU4100, dessen Datenblatt hier gerade herumfliegt) haben den > Treiberausgang für die IR-LED herausgeführt. Da kannst du dann > nachverstärken und externe LED ansteuern Das wäre dann denk ich der IRED_C-Pin?! (Beim TFDU4101) Was meinst du mit nachverstärken? Kann ich den Treiberausgang an einen Transistor (B) hängen?
IR-Bastelei schrieb: > Axel S. schrieb: >> Ich denke schon. Auf Sender-Seite macht der Baustein die Modulation und >> vermutlich auch noch irgendwelches Framing. Auf Empfängerseite >> entsprechend die schmalbandige Verstärkung, AGC, Demodulation etc. pp. > > Okay. Sowas habe ich mir auch gedacht. > >> einige dieser Transceiver (z.B. der >> TDFU4100, dessen Datenblatt hier gerade herumfliegt) haben den >> Treiberausgang für die IR-LED herausgeführt. Da kannst du dann >> nachverstärken und externe LED ansteuern > > Das wäre dann denk ich der IRED_C-Pin?! (Beim TFDU4101) Jep. Vcc2 läßt du einfach unbeschaltet (der käme sonst ein Widerstand nach Vcc hin, als Vorwiderstand für die eingebaute IR-LED) > Was meinst du mit nachverstärken? Kann ich den Treiberausgang an einen > Transistor (B) hängen? Du mußt sogar. Ich suche das Datenblatt deines Transceivers jetzt nicht raus. Aber der TDFU4100 kann z.B. nur maximal 280mA treiben (nominal 200mA). Das reicht zwar für eine, gerichtet strahlende IR-LED aus, aber nicht für mehrere, die in alle Richtungen strahlen sollen. Sieh den Pin einfach als L-aktiven open-collector Logik-Ausgang an. Das Signal kannst du jetzt mit z.B. einem pnp-Transistor verstärken. Oder einem p-MOSFET. Oder nach Invertierung mit einem n-MOSFET. Was immer dir am besten paßt.
IR-Bastelei schrieb: > So in die Richtung? Zumindest ungefähr. Allerdings gehört R7 direkt an die Basis von Q1 (vulgo: auf die andere Seite von R6) und sollte dann Faktor 10 kleiner sein. Auch R6 sollte vermutlich etwas kleiner sein - du willst Q1 ja satt durchschalten. Ob die LED mit ca. 65mA genug Licht machen, mußt du sehen. Mehr Strom vertragen sie durchaus. Und für Q1 dürfte es gern auch ein Transistor sein, der etwas mehr Strom liefert. Z.B. ein BD136 oder 2SB772. Und vergiß nicht einen dicken Stützkondensator von einigen 100µF direkt an den 5V.
IR-Bastelei schrieb: > So mehr richtig? Danke Jein. So lange du nur 65mA pro LED durchjagst, ist der BC327 ausreichend. Einen dickeren Transistor brauchst du nur, wenn du den LED mehr Strom gönnen willst (bzw. mußt). Der BC160 erscheint mir auch nicht sehr geeignet. Die Stromverstärkung ist für 100mA spezifiziert und bei 1A nur noch ca. 1/5 davon. Der BC327 sieht übrigens ganz ähnlich aus, aber der ist ja auch nur bis 500mA zugelassen. Mit dem Basisstrom solltest du es auch nicht übertreiben: du willst ja recht schnell schalten. Für ~350mA Kollektorstrom brauchst du nicht unbedingt 45mA Basisstrom. Die Hälfte (R6=220R) reicht sicher auch. Und der Transistor schaltet schneller, wenn er nicht ganz so gnadenlos übersteuert wird.
Top! Danke. Dann werde ich es so mal ausprobieren. Der Wert der Vorwiderstände wird dann wenn es so weit ist experimentell bestimmt. Schwer zu sagen was da notwendig sein wird. Mit dem BD136 sind ja gut Kapazitäten vorhanden.
chris schrieb: > Welche Datenrate ist das Ziel ? Es gibt noch kein Ziel. Das maximale was der Transceiver kann ist ja eine Baudrate von 115200. Wieso?
Das limit beim 4838 sind die 800 burst je sekunde. Be 26uS je Zyklus sind dies dann 48 Zyklen je bit. Angenommen high 15 zyklen + 4bit Wert + 17 zyklen oder mehr low sind dise dann 4bit, welche man in diese fixen 48 Timeslots reinbekommt. Macht man dann auch noch biphase coding, dies geht, sind es dann 5 bit. 800*5 = 4000 bits.
chris schrieb: > Das limit beim 4838 sind die 800 burst je sekunde. Thema verfehlt? Wir sind hier nicht beim TSOP4838 (die Typbezeichnung hättest du übrigens ruhig ausschreiben können) sondern bei IRDA/SIR. Ich habe übrigens gerade mal im Datenblatt des TDFU4101 gelesen. Für mich sieht das nicht so aus, daß der direkt mit UART Signalen klar kommen würde. Die Pins heißen zwar RXD und TXD, die typische Schaltung im Datenblatt zeigt aber, daß sie mit IRTX und IRRX eines (nicht weiter bezeichneten) IC verbunden werden müssen. Und das wäre dann ein SIR Encoder/Decoder. Wie der genannte MCP2120.
Ja, den Bezeichner hätte ich ausschreiben sollen, und vorher hatte ich nach der geforderten Baudrate gefragt, weil im Vorherigen Thread vom Eingangspost die Rede von 752 bits/sec mittels IR Fernsteuerprotocol war, wobei der TSSOP4838 direkt mit 1200 bps angesteuert werden kann, was dann 960 bits/sec sind. Einfach ein 38khz pwm und Diode von TX auf PWM und RX über Transistor als Inverter. Der TSOP48338 bzw TSOP34338 kann 2400bps , dies sind dann 1920 echte bits/sec aber mit entsprechender Modulation kann auch TSOP4838 echte 4000 bits/sec bzw TSIO34338 auch mehr. Weiterer Unterschied ist: IRDA = max 1mt, +-15 Grad IR = 10mt ist kein Problem, 40mt möglich. IR SIR ist einfach, 3 Pulse eines 600khz Signals mit 20-60% Tastverhältnis ausgeben in 52uS Abstand wenn eine 1 beim seriellen Signal da ist. Der Empfang ist derselbe wie bei rs232, nur dass das Timing kritischer ist. Dies ist dann 19.2 kbits/sec , dies jedoch über Arduino zu machen ist nicht einfach, da ist der MCP2120 schon ok, ob es diesen braucht und ob der Abstand/Winkel passt ist eine andere Frage.
Axel S. schrieb: > Ich habe übrigens gerade mal im Datenblatt des TDFU4101 gelesen. Für > mich sieht das nicht so aus, daß der direkt mit UART Signalen klar > kommen würde. Die Pins heißen zwar RXD und TXD, die typische Schaltung > im Datenblatt zeigt aber, daß sie mit IRTX und IRRX eines (nicht weiter > bezeichneten) IC verbunden werden müssen. Und das wäre dann ein SIR > Encoder/Decoder. Wie der genannte MCP2120. Ja stimmt. Ich denke du meinst Fig. 2 ? Vom Blockschaltbild sehen der TFDU4100 und TFDU4101 recht gleich aus. Komisch.. Mich wundert auch, dass Frank M. (ukw) so überzeugt sagte, dass es funktioniert. Wenn ich das richtg sehe ist der TFDU4100 auch obsolet. Außer in der Bucht gibts den nicht so ohne Weiteres.
Der TFDU4100 ist überall erhältlich, nur eben bei Digikey nicht, dafür dann andere typen. Ja, klar geht es, aber ... ein Treiber treibt die IR-Led mit 1,4-1,6uS und 80 oder 300 mA welche man dann durch externen Widerstand noch verändern kann, oder auch mit externen Transistoren umschaltbare Leistung. Wenn man ohne Treiber arbeitet, dann muss man den Widerstand für ca 20-25mA dimensionieren, wie bei jeder anderen Led. Gleichzeitig bedeutet dies, dass die maximale Distanz dann ca 5-10cm sowie mit dem Risiko, dass wenn viel Umgebungslicht oder Störlicht vorhanden ist, auch nichts mehr funktioniert.
IR-Bastelei schrieb: > Es gibt noch kein Ziel. Das maximale was der Transceiver kann ist ja > eine Baudrate von 115200. Wieso? es gibt IR Transceiver bis 4Mbaud war IRDA nicht höher als 115k? https://en.wikipedia.org/wiki/Infrared_Data_Association ok sowohl als auch
Höhere Geschwindigkeiten als 115.2k sind alle längst abgekündigt, von RHOM sind noch einige obsolete Typen erhältlich , sonst sind schon länger keine mehr erhältlich. Hintergrund sind die LED Lampen sowie Leuchtstoffröhren in E27 Fassungen welche höhere Geschwindigkeiten unmöglich gemacht haben.
chris schrieb: > Der TFDU4100 ist überall erhältlich, Beispiel? chris schrieb: > Wenn man ohne Treiber arbeitet, ohne Treiber? Damit meinst du ohne TFDUxxxx oder Ähnliches?
Der TFDU4101 is der TFDU4100 mit Shutdown Pin für MCU`s welche nur 2-3mA treiben können, dafür ist die Empfindlichkeitsumschaltung weggefallen und die ACG Einstellung ist vom Werk vorgegeben mit diversen Bestellnummern. Ich meinte ein TFDUxxxx ohne TOIM4232 oder MCP21XX zu betreiben, bei geringer Entfernung (<20cm) geht dies. Wie gesagt, da die Led dann nicht mehr mit 1.4-1.6 uS mit 80 oder 300mA betrieben wird darf diese dann nur mehr mit 20-25mA für Dauerbetrieb leuchten. TFDU6102 ist die schnellere Variante welche bis zu 4Mbit funktioniert. TFDU7100 hingegen hat zusätzlich zu den 4Mbit noch einen 36-38khz RC Epmfänger integriert. All diese TFDU sind Pinkompatibel und habe dasselbe Layout.
IR-Bastelei schrieb: > Axel S. schrieb: >> Ich habe übrigens gerade mal im Datenblatt des TDFU4101 gelesen. Für >> mich sieht das nicht so aus, daß der direkt mit UART Signalen klar >> kommen würde. Die Pins heißen zwar RXD und TXD, die typische Schaltung >> im Datenblatt zeigt aber, daß sie mit IRTX und IRRX eines (nicht weiter >> bezeichneten) IC verbunden werden müssen. Und das wäre dann ein SIR >> Encoder/Decoder. Wie der genannte MCP2120. > > Ja stimmt. Ich denke du meinst Fig. 2 ? Vom Blockschaltbild sehen der > TFDU4100 und TFDU4101 recht gleich aus. Komisch.. Nicht komisch. Der 4101 ist der Nachfolger. Der hat jetzt u.a. eine Strombegrenzung beim Sender. > Wenn ich das richtg sehe ist der TFDU4100 auch obsolet. Außer in der > Bucht gibts den nicht so ohne Weiteres. Logo. Ich hatte den vor Ewigkeiten mal verbaut, als Gegenstück zu meinem Palm. Deswegen lag das Datenblatt noch auf der Platte. Ansonsten sind mittlerweile alle IRDA-Transceiver obsolet. Dieses Segment des Marktes wurde komplett von Bluetooth gefressen.
Langsam möchte ich meinen Plan umsetzen. Habe dafür mal einen Schaltplan erstellt. Denkt ihr, dass es so jetzt funktionieren sollte? Mit allen BAUD-Pins = 0 sollte mit dem 7,3728 MHz Quarz eine Baudrate von 9600 hergestellt werden. (Datenblatt Seite 6 : http://ww1.microchip.com/downloads/en/DeviceDoc/21618b.pdf)
Da zu der Schaltung anscheinend niemand eine Meinung hat habe ich nochmal eine allgemeine Frage. Wofür genau wird ein Protokoll-Stack wie zum Beispiel der MCP2150 benötigt. Nur dann wenn die Sendeeinheit nicht an dem UART hängt? Ich dachte durch UART_TX(Atmega) --> MC2120 --> IR_Trasceiver ~~~> IR_Transceiver --> MCP2120 --> UART_RX (Atmega) könnte ich bereits einfache Strings durch die Luft schieben. Oder liege ich dort falsch? Oft lese ich von einem sehr kompliziert zu implementierenden Protokoll-Stack für IrDA.
IR-Bastelei schrieb: > Da zu der Schaltung anscheinend niemand eine Meinung hat habe ich > nochmal eine allgemeine Frage. Wofür genau wird ein Protokoll-Stack wie > zum Beispiel der MCP2150 benötigt. Nur dann wenn die Sendeeinheit nicht > an dem UART hängt? > > Ich dachte durch > > UART_TX(Atmega) --> MC2120 --> IR_Trasceiver ~~~> IR_Transceiver --> > MCP2120 --> UART_RX (Atmega) > > könnte ich bereits einfache Strings durch die Luft schieben. Oder liege > ich dort falsch? Oft lese ich von einem sehr kompliziert zu > implementierenden Protokoll-Stack für IrDA. Der MCP2120 ist nur dafür da, die entsprechenden Signalformen für IR-Sender und Empfänger zu generieren. Bessere Microcontroller wie PIC24 und PIC32 können das bereits alleine ohne Zusatzbeschaltung, und wer nicht durch andere Randbedingungen festgelegt ist, nimmt auch solche Controller, schon allein aus Kosten- und Platzgründen. Weitere Intelligenz enthält der MCP2120 nicht. Dafür braucht es Software. Der IRDA-Stack ist ziemlich komplex. Vergleiche es mit Ethernet. Da gibts ja auch die physikalische Schicht, ein definiertes Paketformat, dann TCP für eine zuverlässige Übertragung auch bei Paketverlusten und darauf Dienste wie Mail oder Web. Ähnlich ist es bei IRDA auch. Lies mal als Einführung das hier: http://www.actisys.com/IrDAOverview-Word.pdf fchk
Frank K. schrieb: > Der MCP2120 ist nur dafür da, die entsprechenden Signalformen für > IR-Sender und Empfänger zu generieren. Jo das weiß ich. Frage ist ob das reicht für einfachste Anwendung (Strings zu verschicken). Im Prinzip kodiert der Chip ja nur den UART um und auf der anderen Seite wieder zurück. Ich würde ja auch den MCP2150 nutzen, allerdings liest man hier im Forum überall das der "zickig" ist. Gibt es Alternativen zum MCP2150? Danke
IR-Bastelei schrieb: > Frank K. schrieb: >> Der MCP2120 ist nur dafür da, die entsprechenden Signalformen für >> IR-Sender und Empfänger zu generieren. > > Jo das weiß ich. Frage ist ob das reicht für einfachste Anwendung > (Strings zu verschicken). Im Prinzip kodiert der Chip ja nur den UART um > und auf der anderen Seite wieder zurück. Nein, das reicht nicht. Du brauchst eine Sicherungsschicht. Die kann auch in Software implementiert werden. Ob DU das kannst, weiß ich nicht. fchk
Frank K. schrieb: > Ob DU das kannst, weiß ich nicht. Nein, deswegen suche ich ja nach einem Chip der das für mich übernimmt..
Frank K. schrieb: > IR-Bastelei schrieb: >> Frage ist ob das reicht für einfachste Anwendung >> (Strings zu verschicken). Im Prinzip kodiert der Chip ja nur den UART um >> und auf der anderen Seite wieder zurück. > > Nein, das reicht nicht. Das würde ich so nicht sagen, ohne zu wissen, was der TE denn nun im Detail vor hat. Wenn er standardkompatibles IRDA sprechen will, braucht er natürlich noch den IRDA Protokollstack. Aber so wie ich das verstanden habe, will er das ja gar nicht. > Du brauchst eine Sicherungsschicht. Oder auch nicht. Im Prinzip kann es ohne funktionieren. Und ebenso im Prinzip wird es mit Sicherungsschicht ... sicherer. Das muß nicht unbedingt "funktionsfähiger" bedeuten. Aber zumindest wird eine Sicherungsschicht Übertragungsfehler erkennbar machen. Andererseits reicht womöglich eine simple Prüfsumme für den gleichen Effekt.
:
Bearbeitet durch User
Axel S. schrieb: > Das würde ich so nicht sagen, ohne zu wissen, was der TE denn nun im > Detail vor hat. Wenn er standardkompatibles IRDA sprechen will, braucht > er natürlich noch den IRDA Protokollstack. Aber so wie ich das > verstanden habe, will er das ja gar nicht. Ich möchte einfach Strings von einem Mikrocontroller zum anderen transportieren und das relativ zuverlässig. Sehr verwirrend das ganze. Einer sagt es funktioniert einfach wenn man den Transceiver an den UART hängt der andere sagt es geht auf keinen Fall ohne Protokoll-Stack und dazwischen noch einige andere Varianten. Was ich sonst noch gefunden habe ist der SC16IS750 von NXP. https://www.nxp.com/docs/en/data-sheet/SC16IS740_750_760.pdf? Der kann auch IrDA aber wenn ich das richtig sehe auch nur die physikalische Schicht. Ich bin zwar kein absoluter Neuling in Sachen Mikrocontrollerprogrammierung aber einen IrDA-Stack traue ich mir dann doch nicht zu. Was ist denn nun eigentlich mit dem MCP2150. Taugt der was oder nicht? Schonmal jemand erfolgreich mit gearbeitet? Oder mit alternativen ICs? Vielen Dank nochmal.
IR-Bastelei schrieb: > Axel S. schrieb: >> Das würde ich so nicht sagen, ohne zu wissen, was der TE denn nun im >> Detail vor hat. Wenn er standardkompatibles IRDA sprechen will, braucht >> er natürlich noch den IRDA Protokollstack. Aber so wie ich das >> verstanden habe, will er das ja gar nicht. > > Ich möchte einfach Strings von einem Mikrocontroller zum anderen > transportieren und das relativ zuverlässig. Sehr verwirrend das ganze. > Einer sagt es funktioniert einfach wenn man den Transceiver an den UART > hängt der andere sagt es geht auf keinen Fall ohne Protokoll-Stack Es geht definitiv ohne Protokollstack. Das ist doch am Ende einfach nur eine serielle Verbindung, die über einen speziellen physical layer geführt wird. Allerdings können hier (im Gegensatz zu einer Leitung) jederzeit Störungen reinpfuschen. Sei es, daß die Verbindung unterbrochen ist (jemand fuchtelt mit der Hand vor dem Empfänger herum) oder daß Fremdsignale (IR-Fernbedienungen, Leuchtstofflampen) Datenbits vorgaukeln, die der Sender gar nicht gesendet hat. Je stärker dein Sender ist und je besser Sender und Empfänger aufeinander ausgerichtet sind, desto geringer werden die Störungen sein. Auf Empfängerseite können solche Störungen einerseits zu "Geister"- Frames führen: der UART erkennt ein Startbit, wo gar keins war. Oder sie können zu Framefehlern führen: das Stopbit wird von einer Störung verdeckt. Deswegen muß der Empfänger diese Fehler auf UART-Seite abfragen und entsprechend reagieren. Auf der Senderseite kann man es dem Empfänger einfacher machen, indem man Synchronisationszeichen sendet. Z.B. enhält 0xFF im seriellen Strom nur ein 0-Bit - das Startbit. Damit ist es gut geeignet, um den Empfänger auf die Frames zu synchronisieren. Denn sonst kann es ja passieren, daß er das Startbit verpaßt und ein 0-Bit im Datenwort für das Startbit hält. Und natürlich würde man seine Nachrichten irgendwie sichern müssen. Im einfachsten Fall mit einer Prüfsumme. Möglicherweise aber auch mit Längenangabe im Header, einer laufenden Nummer und einem CRC. Und wenn die Nachricht nur 7-Bit Zeichen enthält, würde man wahrscheinlich das 8. Bit als Parity-Bit senden. Probier es halt einfach aus. Häng ein Display an deinen Empfänger oder kopple ihn an ein Terminal auf dem Laptop. Und dann sende mal was und probiere aus, wie Entfernung, Ausrichtung, Fremdlicht etc. deine Übertragung beeinflussen.
IR-Bastelei schrieb: > Axel S. schrieb: >> Das würde ich so nicht sagen, ohne zu wissen, was der TE denn nun im >> Detail vor hat. Wenn er standardkompatibles IRDA sprechen will, braucht >> er natürlich noch den IRDA Protokollstack. Aber so wie ich das >> verstanden habe, will er das ja gar nicht. > > Ich möchte einfach Strings von einem Mikrocontroller zum anderen > transportieren und das relativ zuverlässig. Sehr verwirrend das ganze. > Einer sagt es funktioniert einfach wenn man den Transceiver an den UART > hängt der andere sagt es geht auf keinen Fall ohne Protokoll-Stack und > dazwischen noch einige andere Varianten. Irgendetwas wirst Du machen müssen, sonst erreichst Du das "relativ zuverlässig" nicht. Du musst Dich schützen vor - Datenverfälschung (CRC z.B.) - Datenverluste (Paketzähler mit Bestätigung z.B.) Ein standardkonformer IRDA-Stack hat den Vorteil, dass Du auch fertige Geräte als Sender oder Empfänger verwenden kannst, und dass diese Lösung getestet und erprobt ist und keine ernsthaften Designfehler hat. Wenn Du das nicht brauchst, kannst Du Dir auch was eigenes ausdenken, was ggf einfacher ist, aber trotzdem hinreichend gut funktioniert. > https://www.nxp.com/docs/en/data-sheet/SC16IS740_750_760.pdf? > > Der kann auch IrDA aber wenn ich das richtig sehe auch nur die > physikalische Schicht. Genau. > Was ist denn nun eigentlich mit dem MCP2150. Taugt der > was oder nicht? Schonmal jemand erfolgreich mit gearbeitet? Oder mit > alternativen ICs? Keine Ahnung - hab ich nie gebraucht. Wenn, dann solltest Du auch den MCP2155 nehmen. Der hat die Bitcodierungsschicht mit eingebaut. Dann gibt es noch das hier: http://www.actisys.com/instantir.html Das ist ein Kabel-Ersatz für Geräte, die sonst kein IRDA können. Das ganze Protokoll ist eingebaut, da musst Du nichts weiter machen. Idiotensicher also. fchk
Hallo. Ich melde mich mal wieder zurück. Beim Erstellen meiner Schaltung ist mir aufgefallen wie groß der 470µF Cap in der Schaltung ist. Das hat mich dann ein wenig stutzig gemacht. Deswegen überdenke ich diesen gerade nochmal. Ich verstehe nämlich nicht so ganz wofür der da sein muss. Der Transceiver muss ja nicht viel Strom schalten sondern nur die Basis des Transistors bedienen. Axel S. schrieb: > Und vergiß nicht einen dicken Stützkondensator von einigen 100µF > direkt an den 5V. Hier wurde geschrieben, dass man ihn nicht vergessen sollte. Mal angenommen die LEDs werden mit einer eigenen Spannungsquelle versorgt. Also an E und C liegt eine separate Spannungsquelle an. Nicht die, die auch den Rest der Schaltung versorgt. Dann sollte doch auch 10µF oder ähnliches am Transceiver reichen oder? Schaltung ist ja bereits weiter oben im Beitrag. Vielleicht steh ich auch auf dem berühmten Schlauch :)
IR-Bastelei schrieb: > Beim Erstellen meiner Schaltung > ist mir aufgefallen wie groß der 470µF Cap in der Schaltung ist. Das hat > mich dann ein wenig stutzig gemacht. Deswegen überdenke ich diesen > gerade nochmal. Ich verstehe nämlich nicht so ganz wofür der da sein > muss. der soll die gesamte VCC 3,3V stützen nicht nur den Transceiver, wenn die ganzen IR LEDs einschalten soll ja die Schaltung nicht abschmieren! PS so groß muss der nicht sein, ich nutze gerne 8mm 1000µF/6,3V Elkos https://i.ebayimg.com/thumbs/images/g/RzoAAOSwIylZ0T4w/s-l225.jpg 470µ/6,3V könnten noch kleiner sein, ich finde gerade keine
Joachim B. schrieb: > der soll die gesamte VCC 3,3V stützen nicht nur den Transceiver, wenn > die ganzen IR LEDs einschalten soll ja die Schaltung nicht abschmieren! Ah okay dann habe ich das missverstanden. Aber wenn die LEDs an einer extra Spannungsquelle hängen sollte der hinfällig werden oder? Joachim B. schrieb: > PS so groß muss der nicht sein, ich nutze gerne 8mm 1000µF/6,3V Elkos Ich bastel in SMD :)
IR-Bastelei schrieb: > Joachim B. schrieb: >> PS so groß muss der nicht sein, ich nutze gerne 8mm 1000µF/6,3V Elkos > > Ich bastel in SMD :) Ausrede, gibts auch als SMD https://ae01.alicdn.com/kf/HTB1PmttaA.HL1JjSZFlq6yiRFXa2/J047-50pcs-1000UF-6-3V-8mm-10-2mm-SMD-Aluminum-electrolytic-capacitor.jpg habe ich am PI1 als Eingangskondi gesetzt weil der 220µF echt zu dünne war, am USB Ausgang auch als Stützkondi wenn man was dickeres (wlan Stick, oder dicker USB Speicher Stick) einsteckt damit der PI nicht abschmiert.
:
Bearbeitet durch User
IR-Bastelei schrieb: > Axel S. schrieb: >> Und vergiß nicht einen dicken Stützkondensator von einigen 100µF >> direkt an den 5V. > > Hier wurde geschrieben, dass man ihn nicht vergessen sollte. Mal > angenommen die LEDs werden mit einer eigenen Spannungsquelle versorgt. > Also an E und C liegt eine separate Spannungsquelle an. Nicht die, die > auch den Rest der Schaltung versorgt. Dann sollte doch auch 10µF oder > ähnliches am Transceiver reichen oder? Sicher. Mein Hinweis bezog sich konkret auf die von dir gezeigte Schaltung. Da hängen die LED an der gleichen Spannung wie der Rest und dann muß der Stützkondensator natürlich an diese Spannung. Wenn du die LED mittlerweile separat versorgst, dann kann es auch ohne gehen - kommt halt drauf an, was deine Versorgung liefern kann. Der Kondensator soll einerseits sicherstellen, daß die LED auch wirklich mit dem projektierten Impulsstrom betrieben werden und so die geforderte Reichweite schaffen. Und zum anderen soll er verhindern, daß die Spannung so weit zusammenbricht, daß dein µC abkackt. Der letzere Punkt entfällt bei echt getrennter Versorgung natürlich.
Okay dann hatte ich es ja richtig verstanden. Die LEDs werde ich jetzt wohl serparat an einen 9V Block oder so hängen. Mal sehen wie lange der bei den 600mA bis 1A Pulsstrom mitmacht. Vielleicht häng ich parallel zu dem dann einfach einen Elko.
Na dann brauchst du mit Sicherheit nen guten Elko und ich würde auch mit einer Kollektorschaltung mit Stromgegenkopplung treiben, damit die Pulsleistung halbwegs stabil bleibt. Bei einem 9V Block wächst der Innenwiderstand in den Himmel und der Kurschlußstrom in die Erde. :)
IR-Bastelei schrieb: > Die LEDs werde ich jetzt wohl serparat an einen 9V Block oder so hängen. Alles andere, nur kein 9V-Block. Wie mein Vorgänger schon sagte: Der Innenwiderstand dieser Dinger ist viel zu hoch.
Also das geht schon, eigentlich sogar ganz gut, wie ein paar alte RECS80 Fernbedienungen von mir beweisen. Da muß man sich das Knowhow abgucken. Ich meine es sind z.B. immer 2 IR in Serie drin, unter anderem.
batman schrieb: > z.B. immer 2 IR in Serie drin, unter anderem. Ja die LEDs in Serie zu schalten habe ich auch überlegt aber ich bin mir nicht sicher ob die das Timing irgendwie beeinflussen. Ob dann an der ersten LED noch der selbe Puls ankommt wie an der letzen. Als Transistor habe ich jetzt übrigens einen BCP51 rausgesucht. Habe irgendwo gelesen, dass der das SMD-Pendant zum BD136 sein soll. https://www.infineon.com/dgdl/Infineon-BCP51_BCP52_BCP53-DS-v01_01-en.pdf?fileId=db3a304314dca38901156ad4194521c9 sollte passen denk ich. Frank M. schrieb: > Alles andere, nur kein 9V-Block. Wie mein Vorgänger schon sagte: Der > Innenwiderstand dieser Dinger ist viel zu hoch. Bringt dafür auf kleinen Bauraum die höchste Spannung. Dafür natürlich wesentlich weniger Kapazität.
IR-Bastelei schrieb: > batman schrieb: >> z.B. immer 2 IR in Serie drin, unter anderem. > > Ja die LEDs in Serie zu schalten habe ich auch überlegt aber ich bin mir > nicht sicher ob die das Timing irgendwie beeinflussen. Ob dann an der > ersten LED noch der selbe Puls ankommt wie an der letzen. Was für ein Unsinn. >> Alles andere, nur kein 9V-Block. Wie mein Vorgänger schon sagte: Der >> Innenwiderstand dieser Dinger ist viel zu hoch. > > Bringt dafür auf kleinen Bauraum die höchste Spannung. Dafür natürlich > wesentlich weniger Kapazität. Die Spannung ist weitgehend egal. Die Energiemenge (Wattstunden) zählt. Da bist du mit zwei AA deutlich besser, bei kaum mehr Bauraum. Kannst dann natürlich keine 2 IR-LED mehr in Reihe schalten. Mußt du aber auch nicht.
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.