Hallo liebes Forum, ich plane mittels gepulstem Infrarot auf einer Frequenz von 38kH (quasi Fernbedienungs-Frequenz) einseitig Informationen zu übermitteln. Bei der Recherche sind mir jedoch einige Fragen gekommen, die hier hoffentlich beantwortet werden können: Wie wichtig ist die Wellenlänge? Müssen Sender und Empfänger die selbe Wellenlänge aufweisen (z.B. 940nm)? Die Frequenz bleibt unverändert. Folglich werden Nachrichten mithilfe des "Duty-Zyklus" übertragen. Regelt dieser jedoch nur die Helligkeit der IR-LED? Die übertragenen Nachricht soll programmiert mit Python >>Startbit. Info. Stoppbit<< enthalten. Welche Module sollte ich für Raspberry Pi dazu nutzen? Könnt ihr mir diese Fragen zumindest näherungsweise beantworten? Und verzeiht, ich bin auf diesem Gebiet eher Amateur, als Profi, jedoch zu lernen bereit. Vielen Dank vorab. Hochachtungsvoll, euer Ernst
Ernst H. schrieb: > Hallo liebes Forum, > ich plane mittels gepulstem Infrarot auf einer Frequenz von 38kH (quasi > Fernbedienungs-Frequenz) einseitig Informationen zu übermitteln. > Bei der Recherche sind mir jedoch einige Fragen gekommen, die hier > hoffentlich beantwortet werden können: > > Wie wichtig ist die Wellenlänge? Müssen Sender und Empfänger die selbe > Wellenlänge aufweisen (z.B. 940nm)? Naja, grob. 10-20nm Abweichung machen nix, 100nm je nach Spektralkurve der Photodiode bzw. des Tageslichtfilters schon. > Die Frequenz bleibt unverändert. Das ist die Trägerfrequenz. > Folglich werden Nachrichten mithilfe > des "Duty-Zyklus" übertragen. Der Träger wird digital moduliert, sprich, ON-OFF. > Die übertragenen Nachricht soll programmiert mit Python >>Startbit. > Info. Stoppbit<< enthalten. Orientiere dich da mal lieber an bestehenden IR-Codes, das ist deutlich einfacher und funktioniert. https://www.mikrocontroller.net/articles/IRMP > Welche Module sollte ich für Raspberry Pi > dazu nutzen? Vermutlich geht jedes beliebige IO-Pin. Kann sein, daß der UART Vorteile hat. > Könnt ihr mir diese Fragen zumindest näherungsweise beantworten? Und > verzeiht, ich bin auf diesem Gebiet eher Amateur, als Profi, jedoch zu > lernen bereit. Was soll der Quark? Niemand muss sich für eine vernünftig formulierte Frage entschuldigen oder schämen, egal auf welchem Niveau. > Vielen Dank vorab. > Hochachtungsvoll, > euer Ernst Auch diese Zeilen sind im Internet unüblich bis überflüssig.
Ernst H. schrieb: > Die übertragenen Nachricht soll programmiert mit Python >>Startbit. > Info. Stoppbit<< enthalten. Welche Module sollte ich für Raspberry Pi > dazu nutzen? Beachte, dass die üblichen IR Empfänger eine gewisse zeit brauchen, um sich auf das Signal einzupendeln. Deswegen sendet man vor der eigentlichen Datenübertragung ein einleitendes Dummy Signal. Da drahtlose Kommunikation relativ fehlerbehaftet ist, würde ich die Nutzdaten mit Prüfsummen versehen und mehrfach übertragen. Dann kann der Empfänger Fehlerhafte Pakete erkennen und verwerfen.
In meiner frühen Handy-Zeit hatte ich ein Nokia-Handy und ein PDA. Ich konnte mit den PDA über die IR-Schnittstelle des Handys surfen. Sogar Online-Spiele (Wie Inselkampf = ein Browsergame der ersten Zeit) machen. Ich denke den TO geht es nicht um eine Fernbedienung. Sondern eine Seriellen Schnittstelle via IR. Die einzige Frage die der TO sich da stellen muss ist. Ob er (falls vorhanden) ein fertiges Protokoll nimmt oder selbst eins schreibt. So lange 2 das gleiche reden, ist es eigentlich egal wie er es macht.
Um RS232 zu übertragen (direkt, und nicht ein spezielles Format für Fernbedienungen), braucht man eine Modulationsfrequenz, die deutlich höher als die Datenrate liegt. Der Empfänger muß dann natürlich dazu passen. Es gab mal 455 kHz für Fernsteuernwendungen mit hoher Datenrate, wenn ich mich richtig erinnere. Eventuell wäre IRDA ja ein Ansatz. Allerdings haben nur wenige Controller einen IRDA-fähigen UART, da das Signal etwas anders aussehen muß als für normales RS232.
Ernst H. schrieb: > Wie wichtig ist die Wellenlänge? Müssen Sender und Empfänger die selbe > Wellenlänge aufweisen (z.B. 940nm)? Dazu guckst du im Datenblatt von Sender und Empfänger das emittierte Spektrum bzw. die Empfindlichkeitskurve an. Für die Übertragung ist nur derjenige Energieanteil des Senders wirkungsvoll, der beim Empfänger durch das Filter kommt. Jeder Energieverlust auf dem Übertragungsweg reduziert die Reichweite. Ein Faktor 4 in der Leistung bedeutet einen Faktor 2 in der Reichweite.
Hallo Falk B. schrieb: > Was soll der Quark? Niemand muss sich für eine vernünftig formulierte > Frage entschuldigen oder schämen, egal auf welchem Niveau. Der "Quark" ist leider dank der bekannten und zu einen Gutteil angemeldeten Forenstörenfriede (die schämen sich nicht mal...) und hochmotivierten Korinthenkackern leider notwendig. Ich selbst habe teilweise schon deutlich heftiger Einschränkungen (dann aber nicht so auf freundlich und direkt mit einer Erklärung und Entschuldigung) gemacht - weil man den Störenfrieden die dummen Kommentare und Frechheiten zumindest etwas erschweren kann, bzw. diese sich dann selbst bloßstellen. Sorry das ich mit den Thema jetzt komme - aber dein, Falk, durchaus vernünftiger und zustimmungsfähiger Anspruch ist leider hier im Forum viel zu oft nicht gegeben und lebbar und die vom TO gegebenen Einschränkungen und "Entschuldigungen" sind in etwa leider notwendig um gerade die dummen und frechen "Antworten" besonders bei den interessantesten Themen einigermaßen im Vorhinein auszubremsen. Ernst H. schrieb: > Vielen Dank vorab. > Hochachtungsvoll, > euer Ernst Ernst das ist wirklich ein wenig übertrieben- ein "Hallo" "Guten Tag" oder ähnliches reicht aus , ich habe auch kein Problem wenn gar kein Gruß oder ähnliches zu lesen ist, davon geht nämlich auch die Welt nicht unter - ist in diesen forum auch kein so großes Thema, kenne aber (durchaus aktiv) ein anderes Forum wo man ähnliche "Nerds" (Ist für mich -meist- ein Ehrentitel) wie hier antreffen kann, wo sich garantiert jemand meldet und gemeckert weil der ach so böse TO direkt ohne ein Hallo (besser aber mehr...)zur Sache gekommen ist ...
Ernst H. schrieb: > Die Frequenz bleibt unverändert. Folglich werden Nachrichten mithilfe > des "Duty-Zyklus" übertragen. Folglich? Quatsch! Das wäre allenfalls eine Möglichkeit. Allerdings wird genau diese von den allermeisten IR-Standards nicht benutzt.
Sebastian schrieb: > Eventuell wäre IRDA ja ein Ansatz. Genau daran habe ich gedacht. Ist mir nur nicht eingefallen. !! Genau SO hieß glaub ich die Schnittstelle auf den Kopfseite meines Nokia. ;) Und dann kann der TO eine relativ brauchbare Speed bekommen.
Ernst H. schrieb: > ich plane mittels gepulstem Infrarot auf einer Frequenz von 38kH (quasi > Fernbedienungs-Frequenz) einseitig Informationen zu übermitteln. Also die Frequenz ist nicht wirklich kritisch. Aber die Amplitude ist es schon - und zwar kurzzeitig so im Bereich bis 10 ms. Der Grund liegt darin, daß die üblichen IR-Empfänger eine Amplitudenregelung haben, so daß unterschiedliche Einfallswinkel usw. ausgeregelt werden. Die Folge davon ist, daß das Informationstelegramm sinnvoll gewählte Codes zur Informationsübertragung haben sollte. Also nix mit gepulstem Infrarot bzw. Ein- Aus- Codierung. Lies ganz einfach mal die Beschreibungen der üblichen Fernbedienungsmodi und mache deine Übertragungen dazu passend. IRDA ist eine andere Nummer. W.S.
Hallo Ernst, das Stichwort "IrDA" ist ja schon gefallen. Schau Dich mal auf https://de.wikipedia.org/wiki/Infrared_Data_Association um. Zunächst mal interesant ist die Intetion hinter IrDA: "In der Infrared Data Association (IrDA)[1] haben sich 1993 circa 50 Unternehmen zusammengeschlossen. [...] IrDA spezifiziert Standards für die optische drahtlose Punkt-zu-Punkt Datenübertragung mittels infrarotem Licht (850 – 900 nm)." Das könnte für dich passen - von daher darf man dann auch ruhig bei der IrDA spickeln. Was dich zunächst mal interessiert ist die IrPHY. Einfach mal rein schauen. Das eckt sich zumeist mit dem von dir Gesagten. Was aber neu für dich sein dürfte, ist die Kanalcodierung (schreckliches Wort). Dahinter steckt, dass man nicht so einfach 0 (aus) und 1 (ein) übertragen kann/soll, sondern Verfahren (Codierungen) verwendet wie RZI, 4PPM, NRZI, ... - und natürlich mit Prüfsummen arbeitet. Das meiste wurde ja schon gesagt. Trotzdem will ich dich dazu animieren, nicht irgendwas, sondern einen der Unterstandards zu implementieren, z.B. SIR. Du tust dich einfacher, kannst aufkommende Fragen präziser formulieren, bei Antworten Dummgelaber von echten Tipps viel einfacher unterscheiden... just my 2ct
> Eventuell wäre IRDA ja ein Ansatz. Allerdings haben nur wenige > Controller einen IRDA-fähigen UART, da das Signal etwas anders aussehen > muß als für normales RS232. Das stimmt nicht. Zu meinem eigenen erstaunen haben eine ganze Menge Controller IRDA. Das muss noch jemand in grossen Umfang einsetzen. (z.B STM32F051, STM32F103, STM32G071, STM32L151, usw...) Es gibt auch noch neue Transciever: TFBS4711 Olaf
Abhängig davon, welche Datenmengen übertragen werden sollen, kann man für einfache Steuerkommandos auch bei dem weit verbreiteten RC-5 etwas abgucken.
https://www.elektronik-keller.de/index.php/atmel-projekte/ir-nec https://www.sbprojects.net/knowledge/ir/nec.php
Hallo liebe Forenmitglieder und hilfsbereite Antwortende, vielen Dank für die vielen Rückmeldungen. Viele Beiträge haben mir mehr geholfen, als ich zunächst erhofft hatte. Jedoch haben manche Beiträge bei mir auch neue Fragen aufgeworfen. Hannes schrieb: > Was dich zunächst mal interessiert ist die IrPHY. Diese hat jedoch (so habe ich das verstanden) eine Reichweite von ca. 1 Meter. Das ist aber etwas zu wenig für mich. Ich glaube ich brauche ungefähr 2 Meter. Welches Protokoll sollte ich dafür verwenden? Falk B. schrieb: > Naja, grob. 10-20nm Abweichung machen nix, 100nm je nach Spektralkurve > der Photodiode bzw. des Tageslichtfilters schon. Würde es mit 100nm Abweichung in der Wellenlänge noch zu IrPhy passen? Viele Grüße an alle. Euer Ernst.
Ernst H. schrieb: > Ich glaube ich brauche ungefähr 2 Meter. > Welches Protokoll sollte ich dafür verwenden? Um was für Datenmengen geht es denn?
c-hater schrieb: > Das wäre allenfalls eine Möglichkeit. Allerdings wird genau diese von > den allermeisten IR-Standards nicht benutzt. Das hat auch seinen Grund, weil für eine vernünftige Funktion der AGC sich das mittlere Verhältnis von Ein- zu Auszeit nicht ändern darf.
Ernst H. schrieb: > Würde es mit 100nm Abweichung in der Wellenlänge noch zu IrPhy passen? Liest du auch? Wolfgang schrieb: > Dazu guckst du im Datenblatt von ... Oder hier: https://www.itwissen.info/IrPHY-IrDA-physical-layer.html
Ernst H. schrieb: > Diese hat jedoch (so habe ich das verstanden) eine Reichweite von ca. 1 > Meter. Das ist aber etwas zu wenig für mich. Ich glaube ich brauche > ungefähr 2 Meter. > Welches Protokoll sollte ich dafür verwenden? Dazu musst du erstmal sagen, welche Art von Daten du übertragen willst? Ein paar Steuerbefehle wie eine Fernbedienung oder größere Datenmengen? Wenn Daten, wieviele und wie schnell?
Ernst H. schrieb: > Diese hat jedoch (so habe ich das verstanden) eine Reichweite von ca. 1 > Meter. Das ist aber etwas zu wenig für mich. Ich glaube ich brauche > ungefähr 2 Meter. > Welches Protokoll sollte ich dafür verwenden? Die Reichweite ist eine Frage der Sendeleistung, auch 10m sind möglich. Irda ist halt aufwändiger, arbeitet mit kurzen Impulsen (<=2us) und braucht entsprechende Umsetzer für uarts. Daher (nochmals) Wieviel Daten? Wie schnell? Notfalls geht codieren/dekodieren auch mit einem Tiny und einfachen IR-Dioden.
Olaf schrieb: > Zu meinem eigenen erstaunen haben eine ganze Menge > Controller IRDA. So ist es. > (z.B > STM32F051, STM32F103, STM32G071, STM32L151, usw...) Und auch alle AVR XMega (sowie deren Erben in Gestalt der neueren Tinys und Megas sowie AVRxxxDy). Und vermutlich noch eine ganze Menge mehr in anderen Controllerfamilien. Aber Vorsicht: Das, was hier geliefert wird, ist nicht wirklich IRDA, sondern nur eine kleiner Teil davon. Bei den AVR-Teilen nennt sich das "IRCOM". Vermutlich mal wieder ein Kunstbegriff zur Vermeidung von Lizenzkosten, ähnlich wie TWI vs. I2C usw. Allerdings ist das genau die Submenge des Standards, die für das Vorhaben des TO relevant wäre. Und da auch fertige Transceiver dafür nach wie vor für kleines Geld problemlos kaufbar sind, ist das durchaus immer noch attraktiv für eine solche Anwendung.
Angehängte Dateien:
-
00-my_plan.png
1,8 MB
Falk B. schrieb: > Dazu musst du erstmal sagen, welche Art von Daten du übertragen willst? > Ein paar Steuerbefehle wie eine Fernbedienung oder größere Datenmengen? > Wenn Daten, wieviele und wie schnell? Hmmm schrieb: > Um was für Datenmengen geht es denn? Konkret will ich über Infrarot Daten von einem Raspberry Pi (4B) zu einem (später mehreren) Raspberry Pi Pico(s) (mit RP2040 Chip) senden. Der Pico empfängt dabei Daten, die ein paar an ihm angeschlossene LEDs leuchten lassen. Vermutlich sind die Datensätze nicht allzu groß, da nur gesendet wird, wenn sich der Zustand der LEDs ändert (von an zu aus, von Blinken zu Dauerleuchten, ...) Zur tatsächlichen Größe der Daten kann ich noch nicht viel sagen. Wenn ich anfange zu senden, soll binnen 1 Sekunde der Zustand der LEDs verändert werden. Mehr kann ich zur Geschwindigkeit noch nicht sagen. Tut mir leid.
Ernst H. schrieb: > Vermutlich sind die Datensätze nicht allzu groß, da nur gesendet wird, > wenn sich der Zustand der LEDs ändert (von an zu aus, von Blinken zu > Dauerleuchten, ...) Wie groß die Datensätze dabei sind, hängt davon ab, um wie viele LED es sich handelt und mit welcher Frequenz sich der Zustand der LEDs (maximal) ändert. Irgendetwas musst du doch über dein Vorhaben wissen?
Ernst H. schrieb: >00-my_plan.png >1,8 MB AUA! Siehe Bildformate. > Konkret will ich über Infrarot Daten von einem Raspberry Pi (4B) zu > einem (später mehreren) Raspberry Pi Pico(s) (mit RP2040 Chip) senden. > Der Pico empfängt dabei Daten, die ein paar an ihm angeschlossene LEDs > leuchten lassen. Warum nicht Bluetooth oder WLAN? Das haben die schon. > Vermutlich sind die Datensätze nicht allzu groß, da nur gesendet wird, > wenn sich der Zustand der LEDs ändert (von an zu aus, von Blinken zu > Dauerleuchten, ...) Wenn die Datensätze in den Picos vorhanden sind, brauchst du nur START/STOP und eine Nummer, so wie es Fernbedienungen machen. > Wenn ich anfange zu senden, soll binnen 1 Sekunde der Zustand der LEDs > verändert werden. Langsam. Nimm einen der gängigen Fernbedienungscodes, da kannst du sämtliche Hard- und Software vom IRMP nutzen. Oder Funk, siehe oben.
Falk B. schrieb: > Wenn die Datensätze in den Picos vorhanden sind, brauchst du nur > START/STOP und eine Nummer, so wie es Fernbedienungen machen. So ist es. Es sind gewisse Funktionen auf dem Pico gespeichert, die mit IR-Signalen aufgerufen werden. Falk B. schrieb: > Nimm einen der gängigen Fernbedienungscodes, da kannst du sämtliche > Hard- und Software vom IRMP nutzen. Oder Funk, siehe oben. Welche Kriterien soll ich nehmen, um den Code zu wählen? Vielen Dank und beste Grüße, euer Ernst
Ernst H. schrieb: > Welche Kriterien soll ich nehmen, um den Code zu wählen? Den, der am einfachsten ist und deine Anforderungen erfüllt. https://www.mikrocontroller.net/articles/IRMP#Unterst%C3%BCtzte_IR-Protokolle RC5 oder NEC, das sind die verbreitesten. Meine Glotze von 2013 nutzt RC5.
Ernst H. schrieb: > Welche Kriterien soll ich nehmen, um den Code zu wählen? Er soll andere Geräte in der Umgebung, die ebenfalls über IR fernsteuerbar sind, nicht stören.
Ernst H. schrieb: > Konkret will ich über Infrarot Daten von einem Raspberry Pi (4B) Schlecht. Der kann von Hause aus erstmal kein IRDA(IRCOM). Es ist aber nicht allzu schwer, es ihm beizubringen. Zumindest nicht schwerer, als ihm irgendwelche (für die Anwendung eigentlich eher suboptimalen) FB-Protokolle beizubringen. > zu einem (später mehreren) Raspberry Pi Pico(s) (mit RP2040 Chip) senden. Der Pico kann zwar von Hause aus auch weder IRDA noch irgendwelche FB-Protokolle, ist aber dank seiner PIOs wirklich sehr leicht dazu zu befähigen. Man muss sich hier nicht mit den mangelnden Echtzeitfähigkeiten eines Linux-OS rumschlagen und hat Hardware, die relativ universell schnelles Bitgeklimpere in Echzeit abhandeln kann, egal mit welchem unsinnigen Scheiß der werte Benutzer gerade die MCU-Cores sinnlos auslastet... Also ich würde den Empfänger für ziemlich unkritisch halten. Das ist wichtig, denn es ist grundsätzlich viel schwieriger, einen Empfänger zu programmieren als einen Sender.
MSP430 unterstützt Irda. https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ti.com/lit/pdf/slaa202&ved=2ahUKEwjY7aak7J_1AhUOS_EDHRhrDZoQFnoECA4QAQ&usg=AOvVaw0LSzeIVlxsWnsu2duDofrq Mit dem MSP4302553 Launchpad als Entwicklungsplattform ist man gut gerüstet https://www.mouser.at/ProductDetail/Texas-Instruments/MSP-EXP430G2ET?qs=sGAEpiMZZMv0NwlthflBi5q4MGrPMKeZUR7aEvcXREw%3D
Gerald K. schrieb: > https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ti.com/lit/pdf/slaa202&ved=2ahUKEwjY7aak7J_1AhUOS_EDHRhrDZoQFnoECA4QAQ&usg=AOvVaw0LSzeIVlxsWnsu2duDofrq Was geht es Alphabet Inc. an, wer sich hier im Forum für die IrDA Application Note SLAA202B von TI mit dem MPS430 interessiert. Es würde völlig reichen, wenn du den Link auf die Ablage bei TI postest: https://www.ti.com/lit/an/slaa202b/slaa202b.pdf
Ernst H. schrieb: > Hannes schrieb: >> Was dich zunächst mal interessiert ist die IrPHY. > > Diese hat jedoch (so habe ich das verstanden) eine Reichweite von ca. 1 > Meter. Das ist aber etwas zu wenig für mich. Ich glaube ich brauche > ungefähr 2 Meter. > Welches Protokoll sollte ich dafür verwenden? Wenn da steht "1 m" - dann ist das so. IrDA will nicht in die Weite übertragen, sondern schnell und viel. Im Extremfall wählt man dann als Codierer Giga-IR mit 512 Mbit/s bzw. 1 Gbit/s. Der Grund für die begrenzte Reichweite: Du willst nicht mit einem Sender (z.B. Computer) womöglich 24/7 Daten ballern (z.B. an einen Drucker) - und damit einen Übertragungskanal monopolisieren und IR für dich und deine Nachbarn unbenutzbar machen. (vgl. Antwort von Wolfgang) Ernst H. schrieb: > Konkret will ich über Infrarot Daten von einem Raspberry Pi (4B) zu > einem (später mehreren) Raspberry Pi Pico(s) (mit RP2040 Chip) senden. > Der Pico empfängt dabei Daten, die ein paar an ihm angeschlossene LEDs > leuchten lassen. > Vermutlich sind die Datensätze nicht allzu groß, da nur gesendet wird, > wenn sich der Zustand der LEDs ändert (von an zu aus, von Blinken zu > Dauerleuchten, ...) Das allerdings klingt leicht anders als in deinem Eingangspost... Da du sogar schon Chips, Module, Anzahl der Stop-Bits, Programmiersprache ausgewählt hast, würde ich das "dann einfach so machen". Ist es das, was Du hören willst? just my 2ct -Hannes
Da weder für den Pi noch für den Pico IRMP verfügbar ist und der Pi sowieso nicht echtzeitfähig ist, um ein zeitstabiles Signal über Bit-Banging zu generieren, bieten sich zwei Lösungen über UART an: 1. Zwei AVRs mit Sender: IRSND und Empfänger: IRMP dazwischen:
1 | Pi4 UART -> AVR-UART -> IR-Diode ----> IR-Empfänger -> AVR-UART -> Pico-UART |
Für diesen Fall empfehle ich das NEC-Protokoll, das liefert eine ausreichende Sicherung. Falsch empfangene IR-Frames werden von IRMP automatisch verworfen. Die folgende Lösung ist noch einfacher, da sie wie eine transparente UART-Verbindung arbeitet und keine besondere Software benötigt: 2. Das UART-Ausgangssignal vom PI mit NE555 auf 38kHz modulieren, einen 38kHz-TSOP direkt an UART vom Pico:
1 | Pi4 -> UART -> NE555 -> IR-Diode -> TSOP-IR-Empfänger -> UART Pico |
Hier muss die Sicherung der Datenintegrität jedoch selber eingebaut werden. Zu beachten: Die Übertragungsrate richtet sich nach der Modulationsfrequenz,
Frank M. schrieb: > Hier muss die Sicherung der Datenintegrität jedoch selber eingebaut > werden. Nicht nur die. Damit die AGC des TSOP nicht rumeiert, ist es ratsam, einen Code zu wählen, der ähnliche Eigenschaften wie der Manchester-Code besitzt (stabiles High/Low-Verhältnis in den Daten)
Wolfgang schrieb: > Nicht nur die. Damit die AGC des TSOP nicht rumeiert, ist es ratsam, > einen Code zu wählen, der ähnliche Eigenschaften wie der Manchester-Code > besitzt (stabiles High/Low-Verhältnis in den Daten) Hier könnte man einen Hammingcode 8/4 wählen. Dann sind es ebenso viele 1en wie 0en in einem Byte. Als Nebeneffekt hat man noch die zusätzliche Datensicherheit. Das reduziert natürlich auch die Netto-Datenübertragungsrate.
Frank M. schrieb: > 2. Das UART-Ausgangssignal vom PI mit NE555 auf 38kHz modulieren, einen > 38kHz-TSOP direkt an UART vom Pico:Pi4 -> UART -> NE555 -> IR-Diode -> > TSOP-IR-Empfänger -> UART Pico UART ist, soweit ich das verstanden habe, bereits im RP2040 und im Raspberry Pi 4B integriert. Muss ich hardwaretechnisch noch irgendetwas außer IR-Sendediode und -Empfänger ergänzen?
Ernst H. schrieb: > Muss ich hardwaretechnisch noch irgendetwas außer IR-Sendediode und > -Empfänger ergänzen? Für die IR-Diode wirst du wahrscheinlich einen Treiber einsetzen wollen - kommt auf die gewünschte Reichweite an.
Wolfgang schrieb: > Für die IR-Diode wirst du wahrscheinlich einen Treiber einsetzen wollen > - kommt auf die gewünschte Reichweite an. Das wäre dann aber bereits ein Software-"Problem", oder?
Ernst H. schrieb: > Das wäre dann aber bereits ein Software-"Problem", oder? Nein, ein Stromproblem. Dein Python-Controller kann nur einige Milliampere am IO-Pin liefern, deine IR-LED möchtest du vielleicht mit deutlich mehr betreiben - kommt auf die gewünschte Reichweite an.
Wolfgang schrieb: > Nein, ein Stromproblem. > Dein Python-Controller kann nur einige Milliampere am IO-Pin liefern, > deine IR-LED möchtest du vielleicht mit deutlich mehr betreiben - kommt > auf die gewünschte Reichweite an. Löse ich das mithilfe eines Erweiterungsboards für das Raspberry Pi oder sollte ich lieber auf einen externen Stromkreis (mit Optokopplern, Transistoren, etc. ...) bauen?
Ernst H. schrieb: > Löse ich das mithilfe eines Erweiterungsboards für das Raspberry Pi oder > sollte ich lieber auf einen externen Stromkreis (mit Optokopplern, > Transistoren, etc. ...) bauen? Ein einfacher Transistor + Basiswiderstand reicht.
Ernst H. schrieb: > Muss ich hardwaretechnisch noch irgendetwas außer IR-Sendediode und > -Empfänger ergänzen? Einen Transistor (plus Widerstände), siehe auch erstes Bild im Artikel IRSND. Du musst aber noch das UART-Signal modulieren. Dafür reicht ein NE555 aus. Google einfach mal nach "IR modulieren NE555".
Ernst H. schrieb: > Frank M. schrieb: >> 2. Das UART-Ausgangssignal vom PI mit NE555 auf 38kHz modulieren, einen >> 38kHz-TSOP direkt an UART vom Pico:Pi4 -> UART -> NE555 -> IR-Diode -> >> TSOP-IR-Empfänger -> UART Pico > > UART ist, soweit ich das verstanden habe, bereits im RP2040 und im > Raspberry Pi 4B integriert. > Muss ich hardwaretechnisch noch irgendetwas außer IR-Sendediode und > -Empfänger ergänzen? Ich würde auch diese zweite Lösung empfehlen. Die Reichweite ist mit rund 5m gut und es ist sehr zuverlässig. IRSND und IREM halte ich für die Aufgabe als Overkill. Und Irda (IRCOM) ist zwar schneller, aber sehr störanfällig bei sehr geringer Reichweite. Manchester ist für die Anwendung unpassend. Es ist kein Ton- oder Magnetträger. Hamming Code ist Overkill. Darüber unterhalten wir uns, wenn es zu Fehlübertragungen kommt, was sehr unwahrscheinlich ist. Einfach UART raus und wieder rein. Wie eine direkte Verbindung. Der TSOP benötigt keine weiteren Komponenten. Die IR Diode natürlich einen Vorwiederstand. Und die Erzeugung der Trägerfrequenz (meist 38kHz, ist beim TSOP spezifiziert). Diese kann, wie vorgeschlagen, mit einem NE555 erzeugt werden. Alternativ ist auch ein kleiner Controller möglich. Dieser übernimmt die Erzeugung der Trägerfrequenz und reicht meistens auch um die LED zu treiben (kein Transistor nötig). Z.B. ein ATtiny13A kann diese Aufgabe hervorragend übernehmen. Ich programmiere dir einen, wenn Du willst. WICHTIG: Das UART Sende-Signal muss invertiert werden, da der Ruhepegel "High" ist. Auch das kann der ATtiny beim Senden übernehmen. Idealerweise kann es auch der Controller machen, das ist mit der Standard UART nicht immer möglich. 2400 Baud ist damit kein Problem. Das scheint heutzutage sehr langsam, ist aber für die Aufgabe schnell genug. Es können rund 240 Byte pro Sekunde gesendet werden. Um 10 LEDs zu steuern, wird man sicher nicht mehr als 10 Byte (80 Bit) benötigen. Das ist in rund 40 ms erledigt. Fernbedienungen sind nicht schneller. Ein passendes Protokoll musst Du dir selbst ausdenken. Aber das ist Software.
:
Bearbeitet durch User
Uwe K. schrieb: > Dieser übernimmt die Erzeugung der > Trägerfrequenz und reicht meistens auch um die LED zu treiben (kein > Transistor nötig). Z.B. ein ATtiny13A kann diese Aufgabe hervorragend > übernehmen. Welchen ich an das Raspberry Pi 4B anschließe? Benötige ich dazu für den ATtiny13A noch weitere externe Komponenten, die ich zwischen ihn und den Rpi schalte? Uwe K. schrieb: > Ich programmiere dir einen, wenn Du willst. Das wäre wirklich sehr nett. Wenn es für dich keine weiteren Mühen bereitet, würde ich das Angebot gerne annehmen. Vielen Dank, der Beitrag #6937491 von Uwe K. war wirklich sehr hilfreich.
Ernst H. schrieb: > Benötige ich dazu für den ATtiny13A noch weitere externe Komponenten, > die ich zwischen ihn und den Rpi schalte? Eigentlich nicht. Schließe ihn am 3.3V und GND an. Die LED braucht natürlich einen Vorwiderstand. Ein 10k Widerstand von RESET an Vcc. Kann man zur Not auch weglassen. Ein 100nF Kondensator zwischen Vcc und GND schadet nicht. Wird auch ohne gehen, aber sonst gibts im Forum Ärger ;-) Der Raspberry liefert nur 50mA an 3.3V. Versuche erstmal, ob es reicht. Sonst lassen wir uns was einfallen. Am Controller ändert sich nichts. >> Ich programmiere dir einen, wenn Du willst. > Das wäre wirklich sehr nett. Wenn es für dich keine weiteren Mühen > bereitet, würde ich das Angebot gerne annehmen. Ein wenig Mühe macht es schon. Ist aber keine große Sache. Welche Bauform brauchst Du? DIP oder SMD EIAJ ?
Uwe K. schrieb: > Ein wenig Mühe macht es schon. Ist aber keine große Sache. > Welche Bauform brauchst Du? DIP oder SMD EIAJ ? Momentan keine, da ich ihn noch nicht bestellt habe. Ich werde mich aber für DIP entscheiden, da ich mit SMD-Controllern keine guten Erfahrungen gemacht habe. Würde als Alternative zum attiny 13 A auch der ATTINY13 20PU gehen? Denn ersterer ist beim Händler meines Vertrauens momentan nicht verfügbar. Vielen Dank noch einmal, dein/euer Ernst
> wenn es zu > Fehlübertragungen kommt, was sehr unwahrscheinlich ist. > Einfach UART raus und wieder rein. Wie eine direkte Verbindung Da muss man schon jede Menge Optimismus haben, um das zu glauben und zu schreiben. IR-Codes sind nicht umsonst so gestrickt, dass laengere 0- bzw. 1-Phasen nicht auftreten koennen. Ein simples asynchrones Signal mit 2400 Baud wird die ALC des Empfaenger schoen an der Nase herumfuehren. Einfaches Gegenrezept: Aus jedem (8 Bit-)Zeichen zwei 8 Bit "Symbole" kodieren, Die Kodierung kann z.B. dem Manchestercode entsprechen. Hat dieser ATTiny13 eigentlich einen HW-UART
Uwe K. schrieb: > Manchester ist für die Anwendung unpassend. Es ist kein Ton- oder > Magnetträger. Was hat das mit Ton- oder Magnetträger zu tun? Es geht um einen konstanten mittleren Signalpegel für die AGC des IR-Empfängers.
Ernst H. schrieb: > Uwe K. schrieb: >> Ein wenig Mühe macht es schon. Ist aber keine große Sache. > > Momentan keine, da ich ihn noch nicht bestellt habe. ;-) > Würde als Alternative zum attiny 13 A auch der ATTINY13 20PU gehen? Der ohne A ist die alte Version und normalerweise teurer, geht aber auch. Ein ATtiny25/45/85 ist die bessere Alternative und meist günstiger.
Uwe K. schrieb: > Ein ATtiny25/45/85 ist die bessere Alternative und meist günstiger. Beeile dich, die sind fast ausverkauft.
Cartman schrieb: >> wenn es zu >> Fehlübertragungen kommt, was sehr unwahrscheinlich ist. >> Einfach UART raus und wieder rein. Wie eine direkte Verbindung > > Da muss man schon jede Menge Optimismus haben, um das zu glauben > und zu schreiben. IR-Codes sind nicht umsonst so gestrickt, dass > laengere 0- bzw. 1-Phasen nicht auftreten koennen. > Ein simples asynchrones Signal mit 2400 Baud wird die ALC des > Empfaenger schoen an der Nase herumfuehren. Nö. Der ALC bezieht sich auf die Trägerfrequenz. Der braucht ein paar Schwingungen, um ein Signal zu erkennen. Ich habe gerade eine Dauersignal auf den TSOP gegeben (mit Trägerfrequenz). Das Signal bleibt dauerhaft über mehrere Sekunden an. Also kein Thema. > Hat dieser ATTiny13 eigentlich einen HW-UART Hat er nicht und braucht er nicht. Er dient als reiner Signalwandler. Ein Software NE555 sozusagen. Auch kein Thema.
Wolfgang schrieb: > Uwe K. schrieb: >> Manchester ist für die Anwendung unpassend. Es ist kein Ton- oder >> Magnetträger. > > Was hat das mit Ton- oder Magnetträger zu tun? > Es geht um einen konstanten mittleren Signalpegel für die AGC des > IR-Empfängers. Das IR Signal ist keine Dauersignal. Nur der aktive Impuls hat eine Trägerfrequenz, um Störeinflüsse zu minimieren. Das Signal kann auch mehrere Sekunden dauern. Das ist dem TSOP egal.
> Der braucht ein paar Schwingungen und die ALC ist in einer Pause wieder voll aufgeregelt. Das duerfte eine asynchrones Telegramm gut verhackstuecken. Da der Aufwand des "Umkodierens" eine reine Erweiterung der Software ist, ohne das es mehr Hardware braucht, waere mir das ohne Umkodierung zu unzuverlaessig. Die ALC eines IRDA-Receivers hat da sicher andere Zeitkonstanten um solche Pausen sicher zu verarbeiten. Auch das ein Portpin des Controllers die LED direkt treiben soll, halte ich fuer eher fragwuerdig. In einer "richtigen" Fernbedienung sitzt da ein Schalttransistor. Und ich habe schon Vorwiderstaende von nir 1 Ohm vor der IR-LED gesehen. Bei solchen Fernbedienungen ist dann auch noch ein Elko von 1000 uF um die Spannung waehrend der Uebertragung zu stuetzen. Solche Fernbedienungen haben dadurch auch eine vorzuegliche Reichweite. Von nichts kommt eben nichts.
Vergesst nicht, dass nicht nur einen TSOP Empfänger gibt. Die haben unterschiedliche Eigenschaften. Es gibt mindestens einen ohne ALC, das weiß ich deswegen, weil ich mal einen verwendet habe und das so brauchte. Cartman schrieb: > Bei solchen Fernbedienungen ist dann auch noch ein > Elko von 1000 uF um die Spannung waehrend der Uebertragung zu > stuetzen. Diesen nach zu rüsten ist eine simple Methode, die Reichweite von außergewöhnlich schwachen Fernbedienungen zu verbessern. Ich hatte damals 100µF verwendet.
1 | +----[===]---|<|----+-------o Batt + |
2 | | | |
3 | |/ | |
4 | ----| === |
5 | |\> | |
6 | | | |
7 | +-------------------+ |
8 | | |
9 | | |
10 | o |
11 | GND (Batt -) |
Cartman schrieb: >> Der braucht ein paar Schwingungen > > und die ALC ist in einer Pause wieder voll aufgeregelt. > Das duerfte eine asynchrones Telegramm gut verhackstuecken. Ein Test mit einem TSOP31238 konnten deine Bedenken nicht bestätigen. Sowohl 2400 als auch 300 Baud zeigte keine Probleme auch bei kritischen Zeichen wie OxFF oder Ox00. > Auch das ein Portpin des Controllers die LED direkt treiben soll, > halte ich fuer eher fragwuerdig. Das Treiben mit dem Controller ist nicht optimal. Kann aber durchaus ausreichend sein. Es spricht nichts gegen einen zusätzlichen Schalttransistor, um die Reichweite zu erhöhen.
> kritischen Zeichen wie OxFF oder Ox00.
Das sind beide gerade keine kritischen Zeichen.
Eher 0x01, 0x02, 0x04, 9x05, 0x08, 0x09,
0x81, 0x82, 0x84, 0x85 ... und deren Einerkomplemente.
Auch wenn der Remoteempfaenger in einem Probeaufbau damit
zureckt kommt, halte ich es trotzdem fuer Pfusch.
Ein HW-UART, der das Signal ueberabtastet, wierde bei
"verschobenen" Flanken innerhalb des Telegramms, das Zeichen
als fehlerhaft markieren.
Aber, ich muss das Ding ja nachher nicht benutzen.
Mir ists also egal.
Es ist ja nicht so, das ich die Hinweise ignoriere. Ich habe zum Thema gefunden, dass die TSDP Empfänger darauf spezialisiert sind: https://www.vishay.com/doc?82666 Leider sind die D Empfänger nicht so gebäuchlich. Trotzdem interessant, dass die Idee nicht neu ist und von der Industrie aufgenommen wurde.
Stefan ⛄ F. schrieb: > Vergesst nicht, dass nicht nur einen TSOP Empfänger gibt. Die haben > unterschiedliche Eigenschaften. Es gibt mindestens einen ohne ALC, das > weiß ich deswegen, weil ich mal einen verwendet habe und das so > brauchte. Und wie soll der heißen? Die "TSOP Empfänger" ohne ALC sind für Lichtschranken, laufen unter "for Light Barrier Systems" und hören meist auf den Vornamen "TSSP"
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.