|
Anzeige
|
Funkfernbedienung dekodierenHi Ich möchte mit einer Funkfernbedienung mehrere Empfänger, die jeweils noch mehrere Ausgänge haben, steuern. Ich dachte an diese FB https://www.pollin.de/p/pc-funkfernbedienung-x10-721815. und einen 433MHz-Empfänger. Gibt es für diese FB irgendwo Unterlagen, wie das Sendesignal aufgebaut ist, damit ich es dekodieren kann? Oder alternativ: Kann man eine IR-FB nehmen, einen 433MHz-Sender statt der Sende-Led anschließen und am 433MHz-Emfänger einfach den passenden IR-Dekoder anschließen? Das IRMP Projekt kann auch X10 RF dekodieren: https://www.mikrocontroller.net/articles/IRMP
Gast
#7465259
Nein, die ist zusätzlich noch ein Träger von gegen 40kHz verwendet, zu viel für die RF-TX/RX.
Der 38kHz-Träger wird dann ja nicht gebraucht. Wenn der stört, könnte man ihn ja rausfiltern.
Gast
#7465288
Könnte man. Wie J. S. (jojos) schon schrieb: Exakt diese Funkfernbedienung wird von IRMP unterstützt, inkl. Scroll-Taste. Ich hatte mir damals diese FB bei Pollin gekauft und auch die SW dafür angepasst.
Nützt mir leider nichts, der Signalaufbau ist dort nicht beschrieben und compilieren/µCs programmieren kann ich nicht.
Wie wolltest Du das "Sendesignal" denn dann dekodieren?
OK, verständlicher Wunsch.
OK, günstiger geht's kaum.
Kommt drauf an. Die Trägerfrequenz ist natürlich wichtig, entscheidet aber nicht allein über die Tauglichkeit. Es kommt auch auf die vom Empfänger unterstützten Modulationsarten an. X11 ist AM. Nicht jedes der verbreiteten 433MHz-Receiver-Module kann damit etwas anfangen.
Warum willst du es unbedingt "decodieren"? Eigentlich reicht doch für deine Anwendung eine reine "Mustererkennung". Sprich: es genügt völlig, z.B. zu erkennen: "jetzt wurde auf meiner FB Prog+ gedrückt". Es ist überhaupt nicht nötig, die Kodierung und Bedeutung der einzelnen Bits der Nachricht zu verstehen. Das ergibt erst einen Sinn, wenn die Intention ist: ich will einem X11-Receiver etwas senden, was er versteht, aber die verfügbare FB nicht zu produzieren vermag. Also irgendwie nicht gerade dein Anwendungsfall...
RP Pico und PicoMite.
Ich muß doch wissen, welcher High/Low-Salat aus dem Emfänger welcher FB-Taste entspricht. Dazu muß ich den Salat dekodieren, oder wie soll ich die Muster sonst erkennen?
Nunja, wenn du nicht verstehst, wie allereinfachste Mustererkennung funktioniert, dann ist dir wohl nicht wirklich zu helfen. Fakt ist jedenfalls: man muß rein garnichts über Inhalt/Aufbau/Bedeutung des Musters wissen, um es erkennen zu kennen. Die Bedeutung gibt man ihm in der Lernphase, indem man einfach sagt: das gerade empfangene Muster ist das, was beim Drücken der Prog+-Taste der FB entsteht. Und auch nur (noch einfacher): wenn dieses gerade emfangene Muster zukünftig nochmal siehst: Mache dies und jenes. Schließlich braucht die Anwendung letztlich nichtmal zu wissen, welcher Taste der FB das entspricht. Die muss nur wissen: wenn dieses Muster reinkomt, machst du jenes und fertig isses.
Stimmt, ich habe keine Ahnung, wie ein Programm zur Mustererkennung funktioniert. Aber ich muß ja wissen, wo das FB-Wort anfängt und wo es endet, und damit ist der Anfang der Dekodierung schon gemacht...
Klar. Das passiert einfach, indem du in der Lernphase sagst: ab jetzt kommt was, was den relevanten Teil beinhaltet und: jetzt ist Schluß mit dem relevanten Zeug. Du mußt dann nur noch diese zwei Anweisungen an die lernende Software zeitlich hinreichend genau mit dem Tastendruck auf der FB in Einklang bringen. Etwas forgeschrittenere Software zur Musterkennung braucht nichtmal diese Hilfe, zumindest für diese einfache Anwendung. Die braucht nur einen Schwellwert für den Informationsgehalt. Dann kann sie sogar alleine rausfinden, was eines der interessierenden Muster sein könnte, wo es anfängt ud wo es endet. Aber dieser (höhere) Aufwand ist nur zum komfortablen Lernen erforderlich. Nicht für die Endanwendung.
Und wie schreibe ich mir so eine Lernsoftware? Zwischen Druck und Loslassen der Taste kann die FB schon einge zig FB-Worte ausgesendet haben. Wie finde ich in den ganzen Wiederholungen den relevanten Teil? Meine Vorstellung einer solchen Mustererkennung beschränkt sich auf: Ein komplettes FB-Wort abspeichern (Anfang bis Ende). Der Emfänger lauscht, bis er den Anfang eines solchen FB-Wortes erkennt, und vergleicht dann das empfangene FB-Wort mit dem abgespeicherten. Aber dazu muß ich erstmal den Anfang und ein Taktraster des FB-Wortes kennen. Ich fürchte, diese Methode führt nicht weiter. Ich werde dann mal probieren, an eine IR-FB einen Sender zu hängen und feststellen, ob die IR-Signale aus dem Empfänger rauskommen. IR-Signale dekodieren ist in PicoMite bereits eingebaut. Guck dir mal Informationen im Zusammenhang mit https://de.wikipedia.org/wiki/Manchester-Code an.
Warum? Wenn dein Taster gedrückt wird ("steigende Flanke") sendet er das eine Signale, wenn er wieder losgelassen wird, ein anderes. Oder Du sendest nur während des Tastendrucks.
Riichtig. Wobei eigentlich nur der Anfang und das kontant sein müssen. Die Daten dazwischen können variabel sein.
Jepp.
Jepp.
Leute, die Dinge bewerten, von denen sie keine Ahnung haben...
Wer's einfach haben will, kauft eine fertige Lösung (und muss dann natürlich auch die Kosten für die Entwicklung etc. mitbezahlen).
Du schaust dir an wie lirc das gemacht hat und machst es genau so, oder du verwendest die lirc-Software. Noch besser, du verwendest eine vorhandene X10 Konfiguration für lirc https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/atiusb/atiusb.lircd.conf (in der Datei nach X10 suchen). Gab sogar mal Rechner (Notebooks) mit internem X10 Empfänger - hauptsächlich zur Fernbedienung der mitgelieferten TV-Karte gedacht. lirc erkennt eine Menge dieser Empfänger, die meist über USB angeschlossen sind.
Sage ich doch, ich habe keine Ahnung, deshalb führt es mich nicht weiter.
Da finde ich nichts fertiges mit mehr als 4 Schaltmöglichkeiten. Kodier-ICs aus Funksteckdosen-FBs wären zwar flexibel genug, aber die dazugehörigen Dekodier-ICs haben dann nur einen Ausgang. Und einen IC pro Schaltmöglichkeit ist zu aufwändig.
oder beauftragt jemanden mit der Entwicklung.
Das soll aber ohne PC/Notebook und USB funktionieren. Einfach: FB sendet Signal, Empfänger stellt fest: Mein Ausgang 8 ist gemeint und schaltet diesen...
Gast
#7466228
https://www.aliexpress.com/w/wholesale-8-channel-remote-control.html
Was hast du als Empfänger genommen? Diese 433MHz Module wie RFM01? Der Artikel zu IRMP geht darauf leider gar nicht ein. Dito der Thread dazu. Und eine Beschreibung des Protokolls sehe ich da auch nicht.
Die gerade sind ziemlich ungeeignet. Die können nämlich von Hause aus kein AM. Man kann sie nur mit einem Trick (unter Umgehung des eigentlich vorgesehenen Empfangsmechanismus) dazu überreden, AM zu empfangen.
Das ist ja auch einfach. Aber wenn du dich gegen Mikrocontroller sperrst, wird das so nix.
Am Anfang das: https://www.makershop.de/module/funk/433-sender-empfaenger/ Die sind aber wenig zu gebrauchen, weil der Empfänger ein einfaches Pendelaudion ist. Das ist daher besser: https://www.makershop.de/module/funk/rxb6-433mhz-superheterodyne/ Es muss aber kein RXB6-Modul sein, RXB5 funktioniert genauso gut, jedenfalls konnte ich keinen Unterschied entdecken. Irgendwo im Netz findet man da auch Vergleichstests.
Ja, ich hatte damals wenig Zeit, um das noch zu dokumentieren. Änderungen im Artikel dazu: Version 3.2.0:
Version 3.2.2:
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" (EDIT: Mist, der Link verweist nicht auf den konkreten Beitrag von damals, er findet sich auf Seite 12 vom 22.06.2020 11:31 Uhr)
Im Source ist das Protokoll beschrieben - irmpprotocols.h:
Wie man aus den Timing-Werten erkennt, ist es kein Manchesterprotokoll (wie sich hier jemand aus den Fingern gesaugt hat), sondern eine Pulse Distance Kodierung, siehe hierzu auch https://www.mikrocontroller.net/articles/IRMP#Pulse_Distance, wo das erklärt wird. Daraus kann ich ja mal Gelegenheit das entsprechende Kästchen für den IRMP-Artikel unter IRMP: Die IR-Protokolle im Detail generieren, falls es kein anderer macht. P.S. Falls sich jetzt hier jemand erschreckt, weil da oben Float-Werte stehen: Diese werden at-Compile-Time in Integer-Werte umgerechnet, so dass auch ein ATTiny45 damit arbeiten kann.
Danach brauchst Du nur noch einkommende Frames mit Deinen gespeicherten Daten vergleichen. Das Verfahren funktioniert, ohne das Protokoll zu "verstehen", versagt aber in bestimmten Konstellationen, wo Muster kontextabhängig sind. Beispiel: NEC-Protokoll: Es gibt einen sog. Wiederholungsframe aus ein paar Bits, mit dem der letzte Frame (viele Bits) wiederholt werden soll. Sinnvoll ist dieser beispielsweise bei längerem Druck auf die Lautstärke-Taste. Ohne den Kontext "gemeint ist der letzte Frame davor" zu kennen, disqualifiziert sich dieses simple Verfahren damit automatisch. Es würde nur erkennen, was mal mit dem Wiederholungsframe aufgezeichnet wurde: Zum Beispiel einen TV-Kanal-Wechsel. Da kann man dann eine beliebige Taste länger auf der FB drücken: Das Programm würde dann den TV-Kanal immer um 1 inkrementieren, statt zum Beispiel die Lautstärke runterzuregeln. Fies sind da manchmal auch Toggle-Bits, die für ein- und dasselbe Kommando durchaus verschieden sein können, um Sequenzfolgen zu kennzeichnen. IRMP geht einen anderen Weg: Es versucht, die Protokolle zu "verstehen" und kann daher kontextabhängig dekodieren. IRMP weiß, was ein Wiederholungsframe ist und wie dieser zu verstehen und umzusetzen ist. IRMP speichert keine Einsen und Nullen, sondern erlernte Muster, die vom Speicherbedarf wesentlich kleiner sind (ungefähr 1:50). Mit diesen Mustern werden dann die Daten verglichen, inkl. Checksum-Tests und anderer Plausibilitätsprüfungen. Hier wird im Detail beschrieben, wie die Erkennung arbeitet: IRMP: Protokoll-Erkennung Immerhin kann IRMP mittlerweile 60 Protokolle dekodieren - die meisten davon gleichzeitig.
Der Signalaufbau steht im IRMP-Source - mittlerweile auch in diesem Thread, siehe 2 Beiträge höher. Die Timings sind beschrieben. Ebenso wie sich daraus die Bits zusammensetzen und wie die Bits insgesamt den Frame bilden. Genauso sind die Checksum-Bits beschrieben, um einen Plausibilitätstest zu integrieren.
Dann kannst Du das vergessen. Außer Du findest einen, der entweder IRMP auf die von Dir gewünschte Zielhardware umsetzt oder aus den von mir dokumentierten Werten ein Programm für Dich schreibt.
Da fehlt einem DU (= Dummuser, eine Stufe über einem DAU) wie mir, der rechte Zugang. Verstehe ich den Source-Ausschnitt oben soweit richtig? Startbit ist 2850µs H und 1710µs L, 0-Bit ist 570µs H und 570µs L, 1-Bit ist 570µs H und 1710µs L, FB-Wort-(=Frame?)Ende wird durch ein 4456µs L gekennzeichnet und danach wird alles wiederholt? Den Rest verstehe ich nicht mehr... Aber damit könnte ich vielleicht schon was anfangen, wenn jeder FB-Tastendruck immer nur jeweils das gleiche FB-Wort sendet. Oder besteht ein Tastendruck aus mehreren FB-Wörtern?
Umgekehrt: Pulse (Mark) sind Low, Pausen (Space) sind High. Also Startbit: 2850µs L und 1710µs H
Ja, nur L und H vertauscht, siehe oben.
Die Pausen zwischen den Frames sind 4456µs (High-Pegel). Um ein Frame-Ende zu erkennen, reicht aber bereits eine Pausenzeit von etwas mehr als 1710µs, z.B. 2000µs. Das ist dann das Stop-Bit. Ein Frame besteht aus 20 Bits - siehe Kommentar aus obigem Beitrag:
Wenn Du es schaffst, diese 20 Bits zu erkennen, zu speichern und weitere reinkommende Frames mit den bereits abgespeicherten Werten zu vergleichen, bist Du fertig. Die 2 Toggle-Bits solltest Du dabei ignorieren.
Ja, das sieht passender aus als RFM01. Schließlich versucht dieses Modul ja, eine Datenverbindung nach einem eigenen Protokoll aufzubauen. Mit RXB5 bzw. RXB6 kann ich nun googlen.
Die Channel bits entsprechen den 16 Funkkanälen der FB? Wie stellt man den Kanal eigendlich ein? "wenn die Led dauernd leuchtet, mit der FB-Tastatur (1-16) den Kanal wählen" Wie macht man das bei den Tasten 1-0? Oder sind andere Tasten gemeint? Jedenfalls reagiert die Led nicht mit mehrfachen Blinken, das der Kanalzahl entspricht. (ich habe nur die dürftige Pollin-Anleitung)
Ja. 4 Bits bilden 16 Möglichkmeiten.
Wenn ich das richtig in Erinnerung habe, drückst Du 01 bis 16 - also nacheinander immer 2 Tasten. Abschließen mit SELECT. Kann aber auch sein, dass man einfach nur 1...16 gefolgt von SELECT drücken muss. Das ist 3 Jahre her, wo ich die Kanäle mal durchgecheckt habe. Mal eine Verständnisfrage: Wenn auf der FB keine Taste gedrückt ist, geht ein Low in den Sender. Macht der Emfänger daraus dann ein "High"? Oder richtiger: Low in den Sender -> sendet nicht -> Empfänger gibt High-Gebrösel aus, High in den Sender -> sendet -> Empfänger gibt Low aus? Ich habe die FB direkt, ohne Sender/Empfänger dazwischen, mit dem Pico verbunden und bin über die Signalpolaritäten etwas verwirrt.
Das kommt auf den jeweiligen Sender bzw. Empfänger an. Frank schreibt jedenfalls für seinen (!) Empfänger:
Den Sender wird er gar nicht probiert haben. Warum auch? Aber so schwer ist das ja nun auch wieder nicht, den inaktiven Pegel festzustellen.
Prinzipiell ja, aber ich habe die Erfahrung gemacht, dass sowohl Infrarot-TSOP-Empfänger als auch die oben genannten RXBx-Funkempfänger bei Inaktivität immer ein High-Signal ausgeben. Wenn dann tatsächlich ein Signal empfangen wird, ist dieses dann Low. Von daher passt das schon, was ich oben geschrieben habe:
Das ist Unsinn. Du musst am Empfänger messen, nicht am Sender. Du weisst doch gar nicht, wie die Elektronik des Sender einen Puls umsetzt. Relevant ist das jedenfalls nicht für Deine spätere Anwendung.
Bei Funk ist das nicht so trivial wie bei bei Infrarot. Der Funkempfänger schraubt die Empfindlichkeit hoch, wenn nichts empfangen wird. Daher empfängt man dann ein Rauschen, also zufällige Einsen und Nullen. Erst wenn der Sender sendet, dreht der Empfänger seine Empfindlichkeit zurück und man bekommt dann längere Puls- und auch Pausenzeiten zu sehen. Die Kunst besteht natürlich darin, Rauschen und eindeutige Signale zu unterscheiden. IRMP kann das, weil die Statemachine erstmal darauf wartet, bis ein bekanntes Start-Bit empfangen wird. Bis dahin verwirft es den Datensalat. Der TO hat offenbar den Anspruch, all das, was längst in IRMP vorhanden ist, nochmal selbst zu durchleben und zu bewältigen. Kann man machen, aber ich prophezeie da noch einen langen, steinigen Weg, bis er soweit ist. Einfacher wäre die Adaption von IRMP, das auch für Arduino fix und fertig als Lib verfügbar ist und von Jojo erstklassig gepflegt wird: https://github.com/IRMP-org/IRMP
Erstmal muß ich die Frames richtig erkennen erkennen und einlesen können, da kann ich keine unsichere Verbindung über Sender/Empänger gebrauchen. Wenn die Drahtverbindung einwandfrei funktioniert, kann ich mich um die Funkverbindung kümmern.
Das ist einer von diesen Sendern, hauptsächlich bestehend aus einem Transistor und einem rundem 433MHz-Quartz an der Basis. Der wird Träger senden oder schweigen, mehr nicht.
Bleibt mir ja nichts anderes übrig, da ich mit den vorhandenen Sourcen nichts anfangen kann.
Doch, genau diese brauchst Du. Sonst schreibst Du ein Programm, das zwar den Sender versteht, aber kein Programm, das mit dem Output des Empfängers zurechtkommt.
Wieso nicht? IRMP gibts als Arduino-Lib und der Aufruf der Funktion irmp_get_data() ist ein Einzeiler. Genau für Anwender, die selbst nur rudimentär bzw. kaum programmieren können, ist IRMP gedacht. Wie man IRMP anwendet, ist ausführlich beschrieben. Da gibts auch Beispiele auf github mit vielen bunten Bildchen: https://github.com/IRMP-org/IRMP. Für Leute, die nicht des Lesens mächtig sind, gibts sogar Youtube-Filmchen. Einfach mal auf den Link klicken und runterscrollen. Das ist auf jeden Fall einfacher, als das Rad neu zu erfinden. Siehs mal so: Mit IRMP steigst Du in ein Auto und fährst los. Du möchtest das Autobauen aber neu erfinden. Kann man natürlich machen, wenn man nichts anderes zu tun hat.
Gegenbeispiel: Den Führerschein bekomme ich nicht geregelt, da fahre ich dann lieber mit dem Pedelec um überhaupt voranzukommen... Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
