IR-Decoder - universell

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

    • Soooo, hab mal den Code überarbeitet und dabei stehe ich jetzt vor einem Scheidepunkt: Wenn es Performance laufen soll und Speicher-sparend implementiert, dann gibt es da Konfliktpotenzial. Und zwar in der Form, dass ich z.B. zur Laufzeit die Toleranzen berechne - damit spare ich Anfangs ein bisschen Flash, muss später aber viel Rechnen und auch dass kostet Flash (trotz funktionaler Zusammenfassung) und natürlich Laufzeit....

      Jetzt wollte ich nicht weitermachen, ohne den Gedanken mal genauer zu Beleuchten.

      Anregungen? Ideen willkommen!
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • @Mitch64, also ich hab nochmal über Deine Argumentation nachgedacht (Post #12) und mich dann gefragt, warum meine Variante keine Konstanten verwendet?

      In einem anderen Thread ging es quasi genau um das Thema „Konstanten“ - auch wenn die Überschrift etwas anderes vermuten lässt: LINK
      Verstehst Du was ich meine?
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Also ich bin jetzt etwas verwirrt, was du mir eigentlich mitteilen willst.

      Zum einen weil du ganz am Anfang (Post 1) schreibst, du willst einen IR-Decoder bauen. Später (meine ich) schreibst du, dass du eine IR-Fernbedienung nachbilden willst. Das wäre dann aber ein Encoder (der kodiert).

      Zum anderen ist mir gerade nicht klar, wo dein Speicher nicht reicht. Ist dein SRAM zu klein oder dein Flash?

      Und zum dritten, weiß ich nicht, ob dein aktueller code irgendwo hier einzusehen ist.

      Ich kann mich aber erinnern, dass es auch mal um die Statemachine ging und ich dir gesagt habe, dass du das Programm belassen solltest. Was willst du denn genau erreichen?
      Kaum macht man es richtig - und schon geht's!
    • Mitch64 schrieb:

      Also ich bin jetzt etwas verwirrt, was du mir eigentlich mitteilen willst.
      Die Antwort stand im Post davor:

      monkye schrieb:

      @Mitch64, also ich hab nochmal über Deine Argumentation nachgedacht (Post #12) und mich dann gefragt, warum meine Variante keine Konstanten verwendet?

      Dann fängst Du ganz am Anfang an und wechselst zum Encoder: Nein, das habe ich nie geschrieben.


      Mitch64 schrieb:

      Zum anderen ist mir gerade nicht klar, wo dein Speicher nicht reicht. Ist dein SRAM zu klein oder dein Flash?
      Beides, denn der Empfang von Signalen soll im Hitergrund erfolgen und zur Steuerung oder Verarbeitung derselben in einem anderen Anwendungskontext dienen (Beispiele: LED-Deko-Streifen, ferngesteuert mit der TV-Fernbedienung oder Einschalten eines Relais, welches per 433MHz-Baumarkt-Fernbedienung geschalten wird - deshalb ja UNIVERSELL)


      Und jetzt zurück zum Ausgangspunkt:

      Mitch64 schrieb:

      Ich kann mich aber erinnern, dass es auch mal um die Statemachine ging und ich dir gesagt habe, dass du das Programm belassen solltest. Was willst du denn genau erreichen?

      Mir ging es um Deine Darlegung, dass ich keine "State Machine" verwende, weil dazu Konstanten notwendig sind. In dem von mir angegeben Link haben andere Forenmitglieder mir genau das erklärt - das z.B. "12" eine Konstante ist. Und so war es in der 1. Version ja auch umgesetzt.

      OK, Haken dran (für mich).
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.

      Beitrag von monkye ()

      Dieser Beitrag wurde von Michael aus folgendem Grund gelöscht: Doppelpost ().
    • Neue Version - nicht unbedingt optimaler, aber strukturierter...

      Yamaha RAV28 - IR Remote Control _ Dekodiert.PNG

      Liest sich wie folgt für 1.Zeile:

      P1 = Protokoll 1
      22-46 = Impuls 22 Ticks - Pause 46 Ticks
      13-21 = Impulsbreite von 13 - 21 Ticks ======> deshalb ist der Messwert 22 außerhalb des Bereichs, FEHLER --> Bit = 2
      32_1 = 32 Datenbits - 1 Stopp-Bit
      0112 = erkanntes Bitmuster --> das 4. Bit ist ungültig

      Um Speicherplatz im Flash zu sparen habe ich die Abtastrate von 8 Mikrosekunden auf 32 Mikrosekunden hochgenommen (Prescaler von 64 auf 256), damit muss weniger gerechnet werden - weil ich die Toleranzgrenzen speichere UND die sind nur 1 Byte groß anstatt 1 Word.

      Damit das gängige Intertechno auch geht habe ich einen Kompromiss vorgesehen: Anstatt 4 Bit-Phasen auszuwerten werden jetzt die erkannten Bits einfach gespeichert. Bei der Auswertung muss die Umsetzung dann erfolgen, weil ja 2 Sende-Bits ein Datenbit ergeben:
      00 = 0
      11 = 1
      01 = F
      10 = E

      Inzwischen gibt es ja mehrere Protokollvarianten, welche auch mit den Zuständen 0, 1, F, E hantieren.

      In der Datei "IR-SlowRF-Def-Protocol.inc" sind die Definitionen als Tabelle hinterlegt und auch absichtlich vertikal gespeichert, weil sich die Parameter leichter lesen lassen.

      Ja, und die Zeiten habe ich einmal gegen eine Excel geworfen und die Werte abgeschrieben....

      Protokolle_Umrechnung Zeiten in Ticks.PNG
      Dateien
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • So, noch mal ein paar Fehler entsorgt...

      Was sich vorerst als ungeeignet erwiesen hat: Der Pin-Change-Interrupt für Funksignale, denn bei den "billigen" Teilen a la MX-05V o.ä. kommt jede Menge Müll herein, der zu einer sehr hohen Last beim MC führt.Datenmüll via 433MHz Receiver.PNG

      Hier teste ich erstmal andere Receiver und dann denke ich nochmal über die Zeitbasis nach...
      Dateien
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.