IR- Fernbedienungen und BASCOM

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Hallo Christian,
      wie gesagt, mit Libs kenne ich mich nicht aus, da kann ich dir nicht helfen.
      Und ein Windows Programm kann ich schon gar nicht erstellen.
      Meine Vorstellung ist eher, alles mit Bascom Befehlen zu machen.
      Die Zweiteilung für die Erkennung des Protokolls und dem Einbinden in ein Programm ist ok, das würde ich auch so machen. Und ja, durch die bedingte Compilierung kann man erreichen, dass nur die notwendigen Codes im Programm enthalten sind.
      Wenn sich sonst niemand meldet, dann werde ich es erst mal für mich weitermachen und dann evtl. hier einstellen, wenn das Programm leicht woanders einzubinden ist.
      Es gibt halt mehrere Wege, wie man die Codes einlesen und analysieren kann. Z.B. per Timer regelmäßig (recht oft) einen Pin abfragen, einen ext Int oder PCInt verwenden, oder auch den ICP Eingang. Dies ist jeweils sehr unterschiedlich in vorhandene Programme integrierbar. Ich würde bei mir wahrscheinlich die PCInt Variante nehmen, da sie wenig Last für den Controller ist und ich es mir leisten kann, wenn das Programm für ein paar hundert Takte den Ablauf unterbricht. Dies passt aber vielleicht bei anderen nicht so gut.
    • Hallo,

      ich beschäftige mich nun auch schon einige Zeit mit dem Thema und bin sowohl auf "IRMP" als auch die AN#157 bei MCSELEC gestossen.
      Ich möchte gerne einen universellen Empfänger in meine Attiny und Atmega-Projekte integrieren.
      Auch eine Library würde ich mir persönlich wohl eher kaufen wollen (wie I2C), wenn es einfach funktioniert.

      Da die meisten FB´s wohl NEC (-kompatibel) sind, würde ich vermutlich auf AN#157 aufbauen und , und, und ....

      Was wäre für mich "schön":
      - möglichst jeden Pin benutzen können, nicht unbedingt ein INT0/1 ==> also wenn dann den richtigen yC nehmen und ein PCINT
      - die Schaltung sollte "Batteriekompatibel" sein, also am besten direkt mit dem PCINT aufwecken, detektieren und ein nicht-einschlaf-flag setzen; dann in der Hauptroutine alles machen, was man will und wieder schlafen ...

      Ich möchte nochmal betonen, dass ich das hier nicht als Bestellung einer Lösung sehe, ich habe den Thread bisher so verstanden, dass abgefragt wird, was denn so die Rahmenparameter sind für eine möglichst universelle "IRMP-like" Implementierung.

      Ich bin zwar schon knapp 5 Jahre bei Bascom, verwende aber nicht einen Grossteil der Zeit für dieses Hobby. Die Programmierung und Hardware dazu (ich baue meist drahtbasiert auf Lochstreifen) ist für mich immer Mittel zum Zweck und eine Freude, wenn ich in wenigen Tagen zum Ziel komme.

      Bin gespannt, wie es hier weiterläuft - das ist das absolut aktuellste, was ich im grossen Netzt zum Thema Bascom und IR Dekoder so gefunden habe

      Der_Papa

      PS: ich bin schon mittleren Alters, also ich suche hier keinen, der mir meine Schul-/Studienarbeit programmiert ;)
    • Ein universeller Empfänger macht doch an sich keinen sinn, im normalfall hat man eine Fernbedienung mit einem Protokoll, warum also den Prozessor und das Programm mit dem rest vollstopfen den man eh nicht braucht....ausser bei einem Tester der mir das gesendete Protokoll und den code angibt.
      Dann kann man ja in Bascom die entsprechende sup (oder Lib wenn die jemand gebaut hat) einbinden.
      Alle Protokolle jetzt in eine .Lib zwingen seh ich aufgrund der mannigfaltigen konfigurationen pro protokoll nicht als vorteil, schon ein Protokoll verwirrt genug.
      Als Programmbeispiel mit sleep währe ein Sender viel geeigneter, der muss doch Strom sparen da er auf Batterie läuft. Dedizierte Sender chips gibts ja fast nicht mehr. Und zum gesammtkonzept sollte unbedingt ein eigener Sender gehören auch wenn den die wenigsten bauen wollen.
      Ein Open-source gehäuse währ doch dann der zweite schritt.
      FBs mit variabler Tastenmenge, man Bohrt von hinten die menge Löcher für Tasten durch die man braucht, schneidet die Gummimatte passend zu...voila eine voll anwender angepasste FB.

      Tobias
    • Schraubbaer schrieb:

      Ein Open-source gehäuse währ doch dann der zweite schritt.
      FBs mit variabler Tastenmenge...
      wie @ceperiga schon gesagt hat geht es um Fernbedienungen die man in der "Wühlkiste" liegen hat die aber zum großteil kein RC5 senden und zum wegwerfen zu schade sind.
      Es soll ja am Ende auch nicht der gesamte Umfang der Protokolle in das Programm rein sondern nur der Teil den man braucht und dafür sind LIBs nun mal da.
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • Hallo,
      Ich habe schon einige Versuche gemacht, IR Protokolle zu empfangen und auch wieder zu senden.
      Dazu habe ich mir zunächst mal die vorhandenen Programme angesehen.

      Für einen reinen universellen Empfänger ist der Code von for_ro recht gut geeignet.
      Er ist noch nicht so gut portierbar, also auf andere Controller mit anderen Taktfrequenzen.
      Aber das habe ich schon hinbekommen, indem ich einige Konstanten verwende, die abhängig von der Frequenz gesetzt werden.
      Wichtiger ist aber, dass der Code zunächst einmal die Zeiten aller Pegel eines Telegramms in ein Array schreibt.
      Dafür alleine sind schon 200 Bytes vorgesehen. Ok für ein reines Auswertungsprogramm zum Feststellen des Codes.
      Das will sich aber wahrscheinlich keiner in seinem Programm leisten, dessen Funktion ja in der Regel etwas anderes ist und die IR Befehle nur eine Art der Eingabe sind.
      Außerdem wird dann noch ein Timer und ein externer Interrupt benutzt, wodurch die Freiheit des Input Pins schon recht eingeschränkt ist.

      In dem Code bei MCS (AN157) wird der ext. INT0 und ein der Timer0 exklusiv verwendet und es wird nur der NEC Code erkannt.
      Dafür werden aber keine Laufzeiten in einem Array abgespeichert.

      Wenn man sich dagegen die GETRC5() Funktion von Bascom ansieht, dann erkennt man, dass die das im Normal-Modus rein in Software macht.
      Es kann jeder Pin verwendet werden. Allerdings mit einem entscheidenden Nachteil: Der ganze Spaß dauert >100ms, was häufig zu einem Problem führen kann.
      Besonders wenn Interrupts abgeschaltet werden, damit die Funktion die Zeiten richtig erkennen kann.
      Zusätzlich gibt es noch den Background-Modus, wo der ICP Pin eines 16 Bit Timers exklusiv genutzt wird.
      Der Timer ist dann nur noch sehr eingeschränkt für andere Dinge verwendbar.

      Meine aktuelle Idee ist, die Auswertung „on-the-fly“ zu machen, wie das so schön auf neu-Deutsch heißt.
      Analysieren der Werte und abspeichern des jeweils erkannten Bits direkt nach dem Einlesen.
      Das entweder durch abtasten mittels sehr häufigem Timerinterrupt (10 KHz), durch PCInt oder durch ICP, wobei die Pin Einschränkung dabei immer größer wird.

      Ich habe mal ein Excel File mit den Protokolldaten erstellt, wie sie im IRMP Projekt verfügbar sind.
      Da sieht man zunächst einmal, das der erste Impuls (meistens das sogenannte Startbit) nicht eindeutig ist.
      Bei genauerem Hinsehen erkennt man aber, dass für einen bestimmten ersten Impuls die Zeitwerte (Spalten G-N) fast immer konstant sind.
      Das heißt, wenn man die Länge des ersten Impulses hat, kann man die erforderlichen Längen der anderen Impulse und Pausen festlegen.
      Allerdings ist das genaue Protokoll noch nicht klar. Wenn man sich die NEC ähnlichen Protokolle mit Startwert 9000 ansieht, dann werden je nach Protokoll 16-42 Bit übertragen.
      Und selbst da gibt es mehrere gleiche, also z.B. 32 Bit. Daher ist die Bedeutung der Bits nicht unbedingt klar.
      Aber wenn man weiß, welchen Code man erwartet, wäre das ok.
      Ein Problem sind die sehr kurzen Impulse von einigen Protokollen. Wenn ich mit 10KHz abtaste, dann habe ich bei 158µs Puls nur einen oder zwei High- bzw Low-Werte.
      D.h., man müsste schon auf einen einzelnen Impuls reagieren, was wohl nicht sehr störsicher ist. Daher würde ich die Protokolle mit weniger als 300µs Puls/Pause eher nicht abtasten.

      Beim Senden sehe ich das Hauptproblem in den Wiederholungen. Wenn ich meine Sony FB nehme, wird ein SIRCS Code mit unterschiedlicher Anzahl Bits je Taste gesendet.
      Wenn ich die Taste ultrakurz drücke, kommen zwei identische Wiederholungen hinterher. Drücke ich so, wie man normalerweise die Taste drückt, sind es manchmal nur 2, aber aus bis zu 10 Wiederholungen. Was dein Empfänger daraus macht, hängt dann von dessen Programm ab. Und das kannst du ja meistens nicht beeinflussen.
      Da muss man also mit verschiedenen Möglichkeiten spielen.
      Also noch einiges zum Forschen, Probieren, Entwickeln.

      IR_Protokoll_Daten.zip
    • Hallo zusammen,
      ich habe hier mal eine .inc Datei mit der Scan-Sub eingefügt.
      Über Konstanten können die einzelnen Protokolle alle zusammen oder einzeln eingeschaltet werden.
      Im Moment wird alles gescannt. Außerdem werden unbekannte Protokolle in einem Array abgespeichert und zum Schluss ausgegeben.
      In der .bas Datei ist dann ein Beispiel, wie die Daten ausgelesen werden können.
      Es ist noch nicht so sehr viel kommentiert, ich wollte erst einmal hören, wie das so ankommt und ob es verwendbar ist.
      Im Beispiel wird der Timer0 verwendet. Es kann auch jeder andere Timer verwendet werden, der CTC hat. Ansonsten müsste der Timer Reload Wert in der ISR gesetzt werden.
      universeller_ir_receiver.inc
      Universeller_IR_Empfaenger_on_the_fly.bas