IR-Signale unkompliziert senden/empfangen mit lirc / ir-ctl?!?

Moinsen,

Nur das wir von der gleichen Sache reden !?

Das IR Sendebefehle immer aus einer Impulsfolge besteht, die immer und immer wieder gesendet wird solange Mensch den Finger auf dem Knöppel der Fernbedienung hat, muss man immer erst einmal abwarten bis das RasPi als Empfänger dieses Signal auch richtig erkannt hat. Bevor es dann immer mit einer Latenz entsprechend deiner Programmierlogik das Signal genauso wieder über einen anderen GPIO ( IR-Sender ) ausgibt, oder eine Art Dolmetscherfunktion einnimmt, und mit einem anderen IR Code antwortet.
Gleichzeitig im Sinne einer analogen Signalverarbeitung: Signal vorne rein, und hinten nur mit der Verzögerung der Signalweglänge ( mit welcher Geschwindigkeit breiten sich Elektronen in einem stromdurchflossenen Leiter aus ? ) wieder raus - ist nicht, und geht auch nicht !

Jetzt wieder oder leider das Thema, was bezweckst du mit dieser Schaltung ?
- Wenn das RasPi nur eine Art Verlängerung des Übertragungsweges werden soll, vollkommen falscher Ansatz.

- Wenn zu dieser Verlängerungsfunktion eine Protokollfunktion hinzukommen soll, auch der falsche Ansatz.

- Wenn das "große" kleine PI Zero einen Dolmetscher spielen soll, kann man es so machen, aber dann immer mit einer Latenz (Verzögerung ).

Da es hier auf kürzeste Zeiteinheiten bei der Auswertung drauf ankommt, würde ich nicht auf einen "nicht Echtzeit-fähiges System mit einem monströsen Betriebssystem" setzen, sondern diese Aufgabe den kleinen Kerlchen überlassen, die für so etwas prädestiniert sind -> Microcontroller oder µC, wie den kleinsten aus der Reihe Raspberry den PICO. Der kann das genauso, sogar besser, schneller und effizienter, als die großen Brüder. Zudem kannst du für den Fall, das du über diese Übertragung Protokoll führen willst, eine Signalausgabe / Weiterleitung an ein großes PI umsetzen. Rein für eine "Verlängerungs- oder Dolmetscher Funktion" reicht ein µC. Sogar eine noch einfacheres Arduino Board würde dafür vollkommen zureichen.

Ohne jedoch zu wissen, was dein eigentliches Ziel ( du beschreibst nur Zwischenschritte ) würde ich jetzt mal einfach die Behauptung in den Raum stellen, du schraubst auf der falschen Baustelle.

Moinsen,

also noch einmal zusammengefaßt auf die wichtigsten Funktionsbestandteile, ohne auf die Hardware näher einzugehen:

- Ein Programm ( egal was oder wie ) steuert über IR Sendesignale das ein- und ausschalten von 3 Steckdosen als Empfänger.

- du beabsichtigst zudem das diese Programmschaltfunktion übersprochen werden kann ? Also der Empfänger nun nicht mehr die Steckdosen direkt sind, sondern der ausführende Controller, welcher dann auch eine Rückgabe an das Programm macht, das der User ein Signal manuell geändert hat ?
- Wie ist das nun mit den Signal Codes ? Sollen oder könnten die Steckdosenempfänger auch direkt auf das IR-Fernbedienungssignal reagieren, oder soll und muss eine Code-Wandlung ( Dolmetscher Funktion ) stattfinden ?

Bevor du aber das Zero mit irgendwelchen Unsinn streßt, weil was macht dieses Zero denn sonst noch, außer das ein Python Programm im Kreis läuft, würde ich die Geschichte "Senden der eigentlichen Steuercodes" auslagern. Egal ob eine PICO W oder eine ESP8266 / ESP32 - das Zero kann u.a. via WLAN mit den µC Kommunizieren. Der µC ist ausschließlich für die Code Weitersendung in der entsprechenden Signalcodierung verantwortlich. Das Problem beim Zero, sofern es kein Zero II ( Zwei ) ist, ist der Singlecore Prozessor. Da in dem Zero auch noch eine BS werkelt welches die Prozesszuteilung regelt, also bestimmt, welcher Prozess gerade aktiv in der CPU ist, du aber rein durch die CPU nur mit einem Prozess arbeiten kannst, wird das möglicher Weise zeitkritisch. Das kommt drauf an, was und wie oft und wie lange du die "Änderungsfernbedienung" betätigst. Hier würde ich einen Cut machen, wenn der Code als Block richtig erkannt ist, bietet sich MQTT an, diesem abgestellten µC einen Befehl zu senden was dieser zu tun hat. Damit geht die Hauptlast einer Signalsendung an diesen über, du bekommst mehr Bewegungsfreiraum, Thema Sichtverbindung zu den Empfängern, und das Programm kann sich auch wieder über MQTT bestätigen lassen, dass die Codesendung erfolgt ist. Damit hast du einen viel größeren Latenzspielraum auf dem Zero.

Jetzt weiss auch keiner was deine Python Proggi macht, Wetterdaten ? Wenn es nur ein Luftfeuchte- Temperatursensor ggf mit einem Luftdrucksensor ist, zudem noch ein Windrichtungs- /Geschwindigkeitssensor ist, oder auch noch ein Helligkeitssensor ist, sollte das rein, von der Auswertelogik auch in ein PICO oder ESP passen. Diese haben im Gegensatz zum Zero 2 Cores, also eine bessere Aufgabenverteilung ist umsetzbar.

Rein und wieder raus ist über die GPIOs 15 und 16 möglich. Nur sorgt jedes fremde und auch nicht akzeptierte Signal am EIngangs-PIN ( Welchen IR Empfänger verwendest du ? ) für eine Unterbrechung / Störung im Sendevorgang. Das heißt um ins Detail zu gehen, wenn der IR Empfänger etwas auffängt, und das vom Kernelmodul als Signal erkannt wird, hört augenblicklich auch die weitergeleitete Übertragung auf. Das erklärt den Effekt, dass du nicht immer an den End-Empfängern die gewünschte Schaltreaktion beobachten kannst.

Empfangen zum lernen ja, zu steuern von irgendwelchen anderen, nicht auf die GPIO direkt zugreifenden Software-Routinen auch noch ja. Aber dieser Mischbetrieb auf dieser Single Core CPU des Zero kannst du dein Vorhaben aus rein der Betrachtungsweise der Fehleranfälligkeit zu 80% vergessen. Oder du schaffst es vor dem Sendebetrieb das Empfangsmodul im Kernel zu deaktivieren, dass dieses dir nicht dazwischen spucken kann. Und müsstest es logischer Weise nach der Code Sendung auch wieder aktivieren können.

Moinsen,

Du rennst etwas hinterher was zusammen niemals auf einem Single Core System funktionieren wird !
Dazu musst du den gesamten Hintergrund verstehen, oder ansatzweise verinnerlichen was ich versucht habe auszudrücken.

Durch das Kernel-Modul wird eine ständige Empfanngsbereitschaft gewährleistet. Wenn nun dieser Sensor auf etwas reagiert, dabei ist es egal ob es sich um eine echtes Nutzsignal, oder eine Störsignal handelt, dann geht der Prozessor vereinfacht ausgedrückt, in die Empfnagsroutine. Also er zählt die Impulse und stellt deren Länge fest. Dafür gibt es leider auf dem RasPi keine Helfer, also die CPU muss es selber erledigen. Zudem hat bei einem System wie das PI nicht die Anwendung den Hut auf, und bestimmt was gerade passiert, das macht der Kernel. Deswegen hatte ich auch die Frage gestellt, was macht das System sonst noch so außer das dein Python-Programm im Kreis läuft, irgendwelche Sensoren abfragt und ( auf schönes Wetter wartet ) ?
Jetzt hast du nur einen Core, also kommt nun der Shell Befehl oder wie auch immer umgesetzt, das er ein solches Signal generieren soll und über einen GPIO ausgeben soll. Kommt nun aber ein neuer Empfangsimpuls hinzu, wird automatisch der Sendeprozess unterbrochen.
Wenn du jetzt schon, so habe ich das erlesen, vielleicht auch falsch verstanden, sagst wenn du ohne Empfangsbereitschaft etwas sendest, dann klappt die "Sendende" Übertragung immer. Also hast du doch deinen Fehler im System schon spezifiziert. Ständige Empfangsbereitschaft mit der programmgesteuerten Sendung, bzw der Weitersendung, führt meist zu einem Übertragungsfehler. Wobei hier noch gar nicht geklärt ist, oder darauf eingegangen wurde in welchem optischen Verhältnis sich der Sender und der Empfänger befindet ? Nicht das es durch IR reflektierende Materialien zu einem Rückkopplungseffekt kommt. Hast, oder kannst du diesen Umstand zu 100 % ausschließen ?

Moinsen,

Ich sage es mal frei heraus.
Wenn du den Kids was beibringen willst, oder ihnen eine Lernplattform für Linux und Python bieten willst, musst du selber lernen, oder verinnerlichen, dass nicht jedes System für gewisse Aufgaben wirklich geeignet ist.
Auch an einem normalen PC hat der Prozessor seine Helferlein. Gut bei den modernen CPU verschiebt sich das gerade etwas, weil auch der RAM Controller, oder die Fähigkeit einer Bildausgabe ( grafische Fähigkeiten ) mit in den CPU Chip wandert. Aber wenn man an die Anfangszeiten der Computertechnik zurückdenkt, war die Aufteilung noch klar geregelt.

Dann kommt noch etwas Physik hinzu, hier die Optik und die Ausbreitung von Wellen ( wozu auch Licht zählt ), egal ob diese für das menschlichen Auge sichtbar ist oder nicht. Dazu zählt eben auch, dass IR-Licht als Wärmestrahlung nicht nur von klassischen Spiegeln wie für den sichtbaren Bereich reflektiert wird, sondern auch von anderen Materialien. Dazu zählen verschiedene Kunststoffe, aber auch gewisse Hölzer, so das zB auch Echtholzfunier an Einrichtungsgegenständen, oder auch verschiedene Metalloberflächen können hier für eine Signalreflexion sorgen, so das dein gerade ausgesendetes Nutzsignal auch vom Empfänger wieder wahrgenommen wird.

Ja, ein Microcontroller ist da etwas ganz anderes. Er hat oder benötigt kein Betriebssystem, wird direkt programmiert, was aber beim PICO nicht das "große" Problem ist. Zudem ist dieser PR2040 µC bezüglich der Spannungen, bzw der Signalpegel an den GPIOs vollständig kompatibel zu den größeren Raspberry Pi = 3,3V ! Also lässt sich sehr bequem oder einfach mit ein paar grundsätzlichen vorbereitenden Gedanken eine Kommunikation zB über RS232 ( hier muss man bei kurzen Abständen nicht erst auf einen 5 V TTL Pegel, oder via der MAX232 auf einen Standardpegel (+-15V) diese GPIO Signale konvertieren, sondern kann RX[Sender] mit TX[Empfänger] und TX[Sender] mit RX[Empfänger] direkt verbinden) , I²C oder SPI zwischen einem vollwertigen Computer ( PI ) und einem µC ( RasPi PICO ) aufbauen. Dazu kann man Protokoll-basierte Rückkopplungseffekte nutzen. Dazu mal nur die Schematische Darstellung / Beschreibung:

* das "große" PI Zero hat eine Nutzsignal via IR Empfänger erkannt

* das Python-Programm trifft eine Entscheidung und erstelle einen Befehl für den µC

* dieser Befehl wird in einem Buffer ( Befehlspuffer ) zwischengespeichert

* der Buffer wird Stück für Stück geleert, wartet aber auf eine Rückmeldung vom µC das der Befehl ausgeführt wurde.

* der µC übernimmt den Befehl, und aktiviert eine Interrupt ( Unterbrechungs )-Sperre. Also er nimmt nun keine neuen Befehle mehr entgegen.

* jetzt kümmert sich der µC ausschließlich darum den IR Sende-Code zu erzeugen, und gibt diesen als LOW-HIGH Folge über einen GPIO aus, ob nun nur einmal oder mehrmals um die Datenübertragung sicher zustellen - hier ist der Programmierer gefragt.

* wenn dieser Prozess abgeschlossen ist, gibt der µC eine Rückmeldung wieder über das verwendete Übertragungsprotokoll, oder das entsprechende Bus-System zurück, das der Befehl erfolgreich ausgeführt wurde, und hebt Interrupt Sperre wieder auf. Er ist jetzt wieder Empfangsbereit für neue Befehle.

* das große Zero nimmt die Rückmeldung entgegen, löscht diesen einen Befehl aus dem Buffer und sendet wenn vorhanden den nächsten Befehl an den µC.

Du kannst diesen ganzen IR Sende- und Empfangskremepl auch komplett in den µC auslagern.
Das PICO mit seinen nur 20mA kannst du sowohl über die 3,3 V oder 5,0 V direkt aus dem PI Zero versorgen. Wenn der µC ein gültiges IR Signal erkannt hat, dieses auch zuordnen kann, also weiss was er damit zu tun hat, kann er sowohl einen Befehl an das Zero senden, "Hallo der User hat dazwischen gefunkt und will jetzt das oder das haben!" damit das Python-Programm informiert wird, hier ist einer User-Interaktion erfolgt, kann das neue IR Signal absenden, währenddessen für diesen kurzen Moment der Übertragung der IR Empfänger abgeschaltet wird. Trotzdem kann der µC immer noch auf dem Übertragungskanal / Bus zB. RS232 lauschen ob anders lautende Befehle eintreffen, denn der PICO hat 2 getrennte Cores die unabhängig voneinander einen Vollzugriff auf die gesamte Hardware haben. Auch das PICO lässt sich mit eingeschränkter Echtzeitfähigkeit ebenfalls mit einem Python , hier einem µPython oder einem CircuitPython programmieren und betreiben. Damit hättest du für die Kids / Schüler einen zusätzlichen Lerneffekt. Die Kosten sind Überschaubar, und die bisherige Außenhardware wie IR Sender und Empfänger ließen sich ohne Kompatibilitätsprobleme am PICO weiterverwenden.

Hallo @konse ,

Bei zwei unterschiedlichen Schnittstellen /dev/lirc0 und /dev/lirc1 für Senden und Empfangen braucht man wohl auch zwei lircd-Instanzen mit unterschiedlicher Konfiguration z.B. /etc/lirc/lirc_options.conf und /etc/lirc/lirc_options1.conf mit unterschiedlichen Einträgen für device=, output= pid-file= listen= u.s.w.

In der Original-lirc-Doku : https://www.lirc.org/html/conf…ion-guide.html#appendix-9 gibt es einen entsprechenden Absatz und - hier - hat jemand auch so einen Ansatz beschrieben.

Bitte auch prüfen, welche Schnittstelle bei dir Sender und welche Empfänger ist mit ir-ctl -f -d /dev/lirc0 und ir-ctl -f -d /dev/lirc1 da Linux die Schnittstellen nicht eindeutig nummeriert. Und bin mir nicht sicher, ob nach jedem Boot-Vorgang das auch immer wirklich die gleiche Nummerierung ist. Kann man mit udev lösen, dazu ja auch ein Hinweis in der Original-Doku (s.o.).

Es sollte aber auch mit der neuen Kernel-Schittstelle und ir-ctl funktionieren, vielleicht läuft da bei dir im Hintergrund noch ein lircd - Dämon, der das verhindert. Mal mit z.B ps -e | grep lirc prüfen und alle lirc-Prozesse beenden.

Hier hat jemand in einem Blog Teil 1 und Teil 2 das mit der neuen Kernel-Schnittstelle beschrieben und am Ende von Teil 2 so etwas Ähnliches mit Triggerhappy gemacht.

Ich hatte so eine Konfiguration mit IR-Sender und -Empfänger noch nicht selbst am Laufen, aber vielleicht helfe dir die Hinweise ja weiterzuhelfen.

Gruß Martin