Atmega 328P + MCP2120 = IrDA?

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.

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.

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.

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.

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

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.

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

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:
> 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.

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

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

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.

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.

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.

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.