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

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!
Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Vorneweg: Ich bin noch kein Experte, eher der Probiertyp der sich intuitiv durch viele Infos durchwühlt bis er sein Ziel erreicht.
    Damit bin ich bisher ganz gut gefahren, aber hier eindeutig an einer Grenze angelangt was mein Verständnis anbetrifft.

    Ausgangslage:

    -Raspberry PI Zero

    -Raspbian 11.5 Bullseye

    -lirc 0.10.1-6.3


    Funktionierende GPIO Konfiguration zum senden und empfangen von IR-Signalen.


    IR-Signale von der Fernsteuerung empfangen läuft perfekt, ich kann damit Shell-Befehle auslösen.


    IR-Signale senden per irsend läuft auch perfekt, ich kann damit andere Geräte steuern mit dem gleichen Befehl welche die IR-Fernsteuerung sendet.


    ABER: Senden und empfangen bekomme ich nicht parallel zum Laufen. Es ist wie verhext.

    Mein Ziel: Ich möchte gleichzeitig flexibel senden und empfangen von IR-Signalen ohne vor dem Senden irgendwelche configs umschreiben zu müssen oder services neu zu starten.

    Nun, nach tagelangem herumprobieren über Wochen hiermit die Frage an die Experten, wie kann ich das realisieren?


    1. Die Voraussetzung für erfolgreiches empfangen ist diese hier:
    Mit folgender Konfiguration in der /boot/config.txt

    ...

    # Uncomment this to enable infrared communication.

    dtoverlay=gpio-ir,gpio_pin=17

    #dtoverlay=gpio-ir-tx,gpio_pin=18

    #dtoverlay=gpio-ir-tx,gpio_pin=27

    dtoverlay=pwm-ir-tx

    ...


    Dann kann ich einwandfrei mit irw alle Tasten meiner IR-Fernsteuerung empfangen und damit Shell-Commands über irexec.lircrc auslösen.

    Funktioniert alles top.


    irsend funktioniert in dieser Konfiguration nicht (z. B. irsend SEND_START EPSON KEY_RESTART; sleep 3; irsend SEND_STOP EPSON KEY_RESTART):
    hardware does not support sending

    Error running command: Input/output error


    Durch diesen Eintrag in der /boot/config.txt: dtoverlay=pwm-ir-tx

    Kann ich allerdings parallel per ir-ctl senden. Z. B.:

    ir-ctl -d /dev/lirc1 -S necx:0x835584 -S necx:0x835584 -S necx:0x835584 -S necx:0x835584 --gap=125

    IR-Signale werden erfolgreich gesendet.


    ABER: Obwohl mit diesen Scancodes die Fernsteuerung eigentlich erkannt wurde (ir-keytable etc.), kann mein Endgerät mit den gesendeten IR-Signalen per ir-ctl nicht wirklich etwas anfangen. Ganz selten funktioniert es, allerdings viel zu selten (vielleicht 1 von 20 Versuchen und dabei muss ich noch teilweise am gap herumschrauben).


    2a. Die Voraussetzung für erfolgreiches senden ist diese hier (nach reboot):

    Mit folgender Konfiguration in der /boot/config.txt

    ...

    # Uncomment this to enable infrared communication.

    dtoverlay=gpio-ir,gpio_pin=17

    dtoverlay=gpio-ir-tx,gpio_pin=18

    #dtoverlay=gpio-ir-tx,gpio_pin=27

    #dtoverlay=pwm-ir-tx

    ...


    Dann funktioniert allerdings das erfolgreiche empfangen mit irw / Shell-Commands über irexec.lircrc nicht mehr.


    2b. Die Voraussetzung für erfolgreiches empfangen abwechselnd mit senden ohne reboot:

    Booten mit /boot/confi.txt von 1.:

    ...

    # Uncomment this to enable infrared communication.

    dtoverlay=gpio-ir,gpio_pin=17

    #dtoverlay=gpio-ir-tx,gpio_pin=18

    #dtoverlay=gpio-ir-tx,gpio_pin=27

    dtoverlay=pwm-ir-tx

    ...


    Jetzt kann ich erfolgreich empfangen.

    In /etc/lirc/lirc_options.conf wird nun die Zeile:


    device = /dev/lirc0

    geändert in
    device = /dev/lirc1


    Dann noch ein:

    sudo systemctl restart lircd.service


    Voila, jetzt kann ich wieder erfolgreich mit irsend senden.

    Will ich allerdings wieder empfangen muss ich das ganze wieder auf 0 ändern und einen erneuten lircd restart hinlegen.


    Dieses hin- und her ist mir zu aufwändig bzw. zu instabil für einen schnellen Betrieb. Wie kann ich es wirklich parallel realisieren?!?

    Ich habe in einigen Beiträgen erfahren, dass es mit Bullseye und LIRC wirklich viele Probleme gibt.
    Hier sprechen einige davon, einfach auf Kernel-Lösungen umzusteigen:
    https://debianforum.de/forum/viewtopic.php?t=174168

    https://www.mess.org/2020/01/2…tools-to-rc-core-tooling/

    Das wäre an sich die Lösung. ir-ctl funktioniert bei mir jedoch nicht zuverlässig (siehe oben).

    Ich habe es auch mit der Aufnahme von Rohdaten von der Fernsteuerung probiert. Leider ohne Erfolg.

    irsend scheint hier eine solidere wenn auch veraltete Lösung zu sein?!?

    Ich hoffe das ist alles soweit verständlich und freue mich riesig über eure Ideen/Feedback!

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

  • Hi,


    richtig mit dem gleichzeitig das ist immer relativ. Ich habe das Thema mal auf unkompliziert geändert. Das trifft es aber ggf. auch noch nicht so richtig.

    Und ja verstehe natürlich die Frage: Um was geht es wirklich?

    Ich habe drei Steckdosen, die per lernbarem IR-Signal ferngesteuert geschaltet werden können.

    D. h. ich kann die Steckdosen einzeln ansprechen mit irgendeinem im Prinzip frei wählbaren irsend Befehl.

    Ich möchte nun die Steckdosen auf Basis von Wetterdaten mit einem Python-Programm vom Raspi aus schalten (PV-Eigenverbrauchsoptimierung).


    Dann habe ich die IR-Fernsteuerung. Mit dieser möchte ich jedoch im Zweifelsfall einzeln die Steckdosen wieder ein- oder ausschalten - also das Programm aktivieren/deaktivieren oder ggf. auf eine andere Zeit ändern (ich bin ja frei darin was die IR-Fernbedienung bewirkt. Wichtig ist dabei, dass ich nicht direkt die Steckdose mit der Fernbedienung schalte, weil sonst das Programm nicht mitbekommt, dass ich etwas geändert habe. Die Steckdosen schalten mit dem gleichen IR-Code ein und aus.

    Mir irsend funktionert das wunderbar auch wenn ich mehrmals den Befehl sende (wie hier beschrieben).

    Daher möchte ich gerne "gleichzeitig" und unkompliziert ohne Umwege senden und empfangen können. Und das kann das Teil ja auch im Prinzip ir-ctl ist der Beweis.

    Kann mir irgendjemand erklären warum irsend einwandfrei funktioniert, aber ir-ctl nicht funktioniert, selbst wenn ich IR-Rohsignale aufzeichne / wieder abspiele? Wie könnte man irsend mir lirc1 zum laufen bringen während lirc0 für den Empfang weiter funktioniert?
    Wie könnte ich ir-ctl zum funktionieren bringen?

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

    Franky

  • Hui, danke, du bist ja ganz schön schnell im Antworten.


    Ein abwechselndes Senden und Empfangen ist ok für mich. Es muss nicht zeitgleich erfolgen.

    Aber dies durch umbenennen von /dev/lirc0 in /dev/lirc1 zu realisieren sehe ich nicht als praktikable Lösung an.


    Vor allem wenn das senden ja mit ir-ctl grundsätzlich funktioniert.

    Mein Eindruck ist, ggf. hast du mich an einer Stelle Mißverstanden:

    ir-ctl habe ich nicht gleichzeitig während eines Empfangsvorgangs genutzt.

    Aber die Empfangsbereitschaft war da.

    Oder meinst du, dass in dem Moment wenn die Empfangsbereitschaft da ist, grundsätzlich hardwaremäßig ein Senden Probleme macht, auch wenn nichts empfangen wird?


    Ich möchte grundsätzlich bei dieser Hardware bleiben, kein weiteres Geld ausgeben weil sie ja einwandfrei funktioniert! Wenn ich jetzt Steckdosen habe die mit 5V Relais geschaltet werden wäre es auch kein Problem, ich habe aber ja schon die anderen und finde das eigentlich ganz schick.
    Das ganze wird auch mehr im Unterricht für Lernzwecke: Python Lernen mit sinnvollem Einsatz - als dass es jetzt einem professionellen Einsatz standhalten soll.


    Vielleicht nun die grundsätzliche Frage an dich:
    Kennst du dich mit dem Unterschied aus wie

    irsend vs. ir-ctl funktionieren?


    Worin besteht der Unterschied?


    Könnte ggf. dieser Eintrag in der /boot/config.txt

    dtoverlay=pwm-ir-tx

    Dazu führen, dass das senden nicht mehr richtig funktioniert, falsche Sendefrequenz im Vergleich zu derjenigen die irsend verwendet o.ä.?


    Meine Idee war schon, ich wechsle für den Empfang einfach auf ir-ctl, das scheint ja zu funkionieren, sonst hätte ich meine IR-Fernsteuerung nicht erkannt. Allerdings ist es da wiederrum nicht so easy Befehle an den Empfang zu koppeln, bräuchte ich triggerhappy etc. Steige ich leider noch nicht richtig durch...

  • 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 ?

    Franky

  • Ok, vielen Dank. Sehr informativ. So langsam komme ich auf den Trichter.


    Ich habe nun tatsächlich mal den Empfang deaktiviert:

    Mit folgender Konfiguration in der /boot/config.txt

    ...

    # Uncomment this to enable infrared communication.

    #dtoverlay=gpio-ir,gpio_pin=17

    #dtoverlay=gpio-ir-tx,gpio_pin=18

    #dtoverlay=gpio-ir-tx,gpio_pin=27

    dtoverlay=pwm-ir-tx

    ...


    Und siehe da: Die Befehle mit ir-ctl funktionieren einwandfrei genauso gut wie mit irsend.

    Das heißt ich verstehe, mit der laufenden Empfangsbereitschaft für IR-Signale ist mein Raspi schon so beschäftigt bzw. fokussiert, dass er einen gleichzeitigen Versand von sauberen IR-Signalen nicht mehr auf die Kette kriegt.

    Das macht dann alles durchaus Sinn.


    Und ja, wir wollen natürlich nicht nur auf schönes Wetter warten sondern auf Basis der Wetterprognose am Tag den optimalen Slot bestimmen in welchem bspw. der Ebike-Akku geladen wird, so dass er möglichst solar geladen wird. Das ist das eigentliche Thema für die Schüler sich hier mit Python auszutoben. Das ganze dann noch mit ein paar Kamerabildern und Auswertung mit imagemagick abgeglichen ob das Wetter wirklich so wurde wie prognostiziert. Die GPIO Schnittstelle / IR Steuerung ist im Grunde nur Beiwerk und macht es etwas runder, weil eine komfortable Bedienung ohne Tastatur möglich ist und die Tasten schön frei programmierbar sind. Per IR-Fernbedienung soll dann der Automatismus überschrieben werden können, falls z. B. der Akku doch sofort geladen werden soll :)


    Also smart Home nicht im Sinne von: Wie Verbrauche ich mehr, weil jetzt bei einem Gewitter automatisch meine Lichter angehen, sondern Smart Energy Home im Sinne von wie optimiere ich meinen Eigenverbrauch von PV oder Wind oder sonst etwas erneuerbarem, weil ich dann meine Verbraucher einschalte, wenn potentiell eine Erzeugung da ist :)


    Nun so wie es aussieht werde ich doch den Empfangsmodus immer wieder unterbrechem müssen wenn ich IR-Signale senden möchte.


    Gibt es hier eine schönere Möglichkeit als bei einem bestimmtem IR-Empfangssignal per Kommando in

    irexec.lircrc so etwas hier zu fabrizieren:


    sudo sed /lirc0/lirc1/g /etc/lirc/lirc_options.conf; sudo systemctl restart lircd.service; irsend ...; sudo sed /lirc1/lirc0/g /etc/lirc/lirc_options.conf; sudo systemctl restart lircd.service;

    Ich erreiche im Grunde mein Ziel, aber so richtig schick finde ich es noch nicht?!?


    Vielleicht noch der Grund weshalb ich auf einen Zero gegangen bin: Für mich der derzeit günstigste Rechner auf dem ein Debian läuft. D. h. das ist für Schüler hinsichtlich der Architektur interessant, dies weil sie viele Dinge die sie lernen, prinzipiell auch auf jedem normalen Webserver oder Unix/Linux-System so anwenden können. Wenn ich das richtig verstanden habe ist das mit dem Pico anders. Ansonsten überzeugt mich auch der geringe Stromverbrauch von ca. 1,5W. Mehr will ich für solche Spielereien garnicht verbrauchen :).

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

    Franky

  • 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

  • Franky07 ich kann dir sehr gut folgen und danke dir für die umfangreichen und schnellen Rückmeldungen!!!


    Optische Rückmeldungen waren übrigens immer vollsständig ausgeschlossen. Das war also nicht das Problem.


    Die Kombination mit dem Pico wäre für eine professionellere Umsetzung definitiv sehr cool und es gäbe dann auch noch mehr zu lernen. Ich glaube jedoch auf dieses Level werden wir es innerhalb der vorgesehenen Zeit mit den Schülern nicht schaffen. Auch ich selbst habe begrenzte Zeit zum vorbereiten. Aber ich werde erläutern, warum es nun so ist wie es ist, und wie man sich eigentlich noch intensiver reinfuchsen müsste um dem ganzen mehr flow zu verpassen und es professioneller umzusetzen.


    Martin28 vielen Dank auch für diese Tips. Die Infos von deinen Links Teil1/2 hatte ich bereits vorher aufgestöbert und damit herumprobiert, bin aber auf keinen wirklich grünen Zweig gekommen.

    Der Ansatz der in github beschrieben ist war mir neu. Er weist jedoch im letzten Beitrag genau auf das Problem hin, was Franky07 erläutert (https://github.com/dotnet/iot/…31#issuecomment-898347886). D. h. senden und empfangen gleichzeitig wird mit einem Raspi ohne Zusatz nicht reibungsfrei und flüssig funktionieren.
    Hier wurde es dann mit einem zusätzlichen Arduino gelöst was mir allerdings im Vergleich zum Einsatz eines Pico wie Kanonen auf Spatzen erscheint. Aber gut, wer weiß was das Arduino sonst noch für Aufgaben hatte...


    Vielen Dank euch. Hiermit schließe ich das Thema.