Hi 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?
Peter N. schrieb: > 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? Nein, die ist zusätzlich noch ein Träger von gegen 40kHz verwendet, zu viel für die RF-TX/RX.
H. H. schrieb: > Nein, die ist zusätzlich noch ein Träger von gegen 40kHz verwendet, Der 38kHz-Träger wird dann ja nicht gebraucht. Wenn der stört, könnte man ihn ja rausfiltern.
Peter N. schrieb: > H. H. schrieb: >> Nein, die ist zusätzlich noch ein Träger von gegen 40kHz verwendet, > > Der 38kHz-Träger wird dann ja nicht gebraucht. Wenn der stört, könnte > man ihn ja rausfiltern. 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.
Frank M. schrieb: > Exakt diese Funkfernbedienung wird von IRMP unterstützt, inkl. Nützt mir leider nichts, der Signalaufbau ist dort nicht beschrieben und compilieren/µCs programmieren kann ich nicht.
Peter N. schrieb: > Frank M. schrieb: >> Exakt diese Funkfernbedienung wird von IRMP unterstützt, inkl. > > 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? Peter N. schrieb: > Gibt es für diese FB irgendwo Unterlagen, wie das Sendesignal aufgebaut > ist, damit ich es dekodieren kann?
Peter N. schrieb: > Ich möchte mit einer Funkfernbedienung mehrere Empfänger, die jeweils > noch mehrere Ausgänge haben, steuern. OK, verständlicher Wunsch. > Ich dachte an diese FB > https://www.pollin.de/p/pc-funkfernbedienung-x10-721815. OK, günstiger geht's kaum. > und einen 433MHz-Empfänger. 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. > Gibt es für diese FB irgendwo Unterlagen, wie das Sendesignal aufgebaut > ist, damit ich es dekodieren kann? 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...
Joachim S. schrieb: > Wie wolltest Du das "Sendesignal" denn dann dekodieren? RP Pico und PicoMite. C-hater schrieb: > 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. 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?
Peter N. schrieb: > 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.
C-hater schrieb: > Nunja, wenn du nicht verstehst, wie allereinfachste Mustererkennung > funktioniert, dann ist dir wohl nicht wirklich zu helfen. 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...
Peter N. schrieb: > Aber ich muß ja wissen, wo das FB-Wort anfängt und wo es endet 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.
C-hater schrieb: > 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. 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. Peter N. schrieb: > 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? 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. > Meine Vorstellung einer solchen Mustererkennung beschränkt sich auf: > Ein komplettes FB-Wort abspeichern (Anfang bis Ende). Riichtig. Wobei eigentlich nur der Anfang und das kontant sein müssen. Die Daten dazwischen können variabel sein. > Der Emfänger lauscht, bis er den Anfang eines solchen FB-Wortes erkennt, > und vergleicht dann das empfangene FB-Wort mit dem abgespeicherten. Jepp. > Aber dazu muß ich erstmal den Anfang und ein Taktraster des FB-Wortes > kennen. Jepp. > Ich fürchte, diese Methode führt nicht weiter. Leute, die Dinge bewerten, von denen sie keine Ahnung haben... > 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. Wer's einfach haben will, kauft eine fertige Lösung (und muss dann natürlich auch die Kosten für die Entwicklung etc. mitbezahlen).
Peter N. schrieb: > Und wie schreibe ich mir so eine Lernsoftware? 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).
:
Bearbeitet durch User
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.
Rahul D. schrieb: >> Ich fürchte, diese Methode führt nicht weiter. > Leute, die Dinge bewerten, von denen sie keine Ahnung haben... Sage ich doch, ich habe keine Ahnung, deshalb führt es mich nicht weiter. Rahul D. schrieb: > Wer's einfach haben will, kauft eine fertige Lösung 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.
:
Bearbeitet durch User
Peter N. schrieb: > Rahul D. schrieb: >> Wer's einfach haben will, kauft eine fertige Lösung > > Da finde ich nichts fertiges mit mehr als 4 Schaltmöglichkeiten. oder beauftragt jemanden mit der Entwicklung.
Matthias S. schrieb: > 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. 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...
Peter N. schrieb: > Da finde ich nichts fertiges mit mehr als 4 Schaltmöglichkeiten. https://www.aliexpress.com/w/wholesale-8-channel-remote-control.html
Frank M. 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. 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.
:
Bearbeitet durch User
Axel S. schrieb: > Diese 433MHz Module wie RFM01? 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.
Peter N. schrieb: > Einfach: FB sendet Signal, Empfänger stellt fest: Mein Ausgang 8 ist > gemeint und schaltet diesen... Das ist ja auch einfach. Aber wenn du dich gegen Mikrocontroller sperrst, wird das so nix.
Axel S. schrieb: > Was hast du als Empfänger genommen? Diese 433MHz Module wie RFM01? 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. > Der Artikel zu IRMP geht darauf leider gar nicht ein. Ja, ich hatte damals wenig Zeit, um das noch zu dokumentieren. Änderungen im Artikel dazu: Version 3.2.0: - 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF) - 22.06.2020: Neues RF-Protokoll: RF_GEN24 - 22.06.2020: Neues RF-Protokoll: RF_X10 Version 3.2.2: - 09.07.2020: Zusätzliche Erkennung der Funkkanäle beim RF_X10 Protokoll - 09.07.2020: Verbesserung der Erkennung von RF-Frames durch neue Stop-Bit-Behandlung. - 09.07.2020: Verbesserte Detektion von RF_GEN24-Protokollen > Dito der Thread dazu. 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) > Und eine Beschreibung des Protokolls sehe ich da auch nicht. Im Source ist das Protokoll beschrieben - irmpprotocols.h:
1 | /*-----------------------------------------------------------------------------------------------
|
2 | * RF X10 remote control (MEDION, Pollin 721815)
|
3 | *
|
4 | * Frame:
|
5 | * 1 toggle bit + 7 checksum bits + 1 toggle bit + 7 command bits + 4 channel bits
|
6 | *
|
7 | * Rule:
|
8 | * checksum = (command + 0x0055 + (channel << 4)) & 0x7F
|
9 | *
|
10 | * Here we store checksum in address, command incl. 4 channel bits in command
|
11 | *
|
12 | * In irmp_get_data():
|
13 | * irmp_command = command << 4
|
14 | * irmp_address = channel + 1
|
15 | *------------------------------------------------------------------------------------------------
|
16 | */
|
17 | #define RF_X10_START_BIT_PULSE_TIME 2850.0e-6 // 2850 usec pulse
|
18 | #define RF_X10_START_BIT_PAUSE_TIME 1710.0e-6 // 1710 usec pulse
|
19 | #define RF_X10_0_PULSE_TIME 570.0e-6 // 570 usec pulse
|
20 | #define RF_X10_0_PAUSE_TIME 570.0e-6 // 570 usec pause
|
21 | #define RF_X10_1_PULSE_TIME 570.0e-6 // 570 usec pulse
|
22 | #define RF_X10_1_PAUSE_TIME 1710.0e-6 // 1710 usec pause
|
23 | |
24 | #define RF_X10_FRAME_REPEAT_PAUSE_TIME 4456.0e-6 // frame repeat after 4460 usec
|
25 | #define RF_X10_ADDRESS_OFFSET 1 // skip 1st toggle bit
|
26 | #define RF_X10_ADDRESS_LEN 7 // store 7 command bits in address
|
27 | #define RF_X10_COMMAND_OFFSET 9 // skip 1st toggle bit + 7 command bits + 2nd toggle bit
|
28 | #define RF_X10_COMMAND_LEN 11 // read 7 alternative command bits plus 4 0-bits
|
29 | #define RF_X10_COMPLETE_DATA_LEN 20 // complete length
|
30 | #define RF_X10_STOP_BIT 1 // has stop bit
|
31 | #define RF_X10_LSB 0 // MSB...LSB
|
32 | #define RF_X10_FLAGS 0 // flags
|
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.
:
Bearbeitet durch Moderator
Peter N. schrieb: > Und wie schreibe ich mir so eine Lernsoftware? - Erkennung für Start-Bit im Frame schreiben - Erkennung für Stop-Bit im Frame schreiben - Einsen und Nullen für verschiedene Tasten per Timer aufnehmen. - Folgen der Einsen und Nullen geeignet abspeichern 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.
:
Bearbeitet durch Moderator
Peter N. schrieb: > Nützt mir leider nichts, der Signalaufbau ist dort nicht beschrieben 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. > und compilieren/µCs programmieren kann ich nicht. 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.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Der Signalaufbau steht im IRMP-Source - mittlerweile auch in diesem > Thread, siehe 2 Beiträge höher. Die Timings sind beschrieben. 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?
Peter N. schrieb: > Verstehe ich den Source-Ausschnitt oben soweit richtig? > Startbit ist 2850µs H und 1710µs L, Umgekehrt: Pulse (Mark) sind Low, Pausen (Space) sind High. Also Startbit: 2850µs L und 1710µs H > 0-Bit ist 570µs H und 570µs L, > 1-Bit ist 570µs H und 1710µs L, Ja, nur L und H vertauscht, siehe oben. > FB-Wort-(=Frame?)Ende wird durch ein 4456µs L gekennzeichnet > und danach wird alles wiederholt? 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:
1 | 1 toggle bit + 7 checksum bits + 1 toggle bit + 7 command bits + 4 channel bits |
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.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Axel S. schrieb: >> Was hast du als Empfänger genommen? Diese 433MHz Module wie RFM01? > > 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 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.
Frank M. schrieb: > Ein Frame besteht aus 20 Bits - siehe Kommentar aus obigem Beitrag:1 > toggle bit + 7 checksum bits + 1 toggle bit + 7 command bits + 4 channel > bits 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)
Peter N. schrieb: > Die Channel bits entsprechen den 16 Funkkanälen der FB? Ja. 4 Bits bilden 16 Möglichkmeiten. > Wie macht man das bei den Tasten 1-0? 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.
:
Bearbeitet durch Moderator
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.
Peter N. schrieb: > Mal eine Verständnisfrage: > > Low in den Sender -> sendet nicht -> Empfänger gibt High-Gebrösel aus, > High in den Sender -> sendet -> Empfänger gibt Low aus? Das kommt auf den jeweiligen Sender bzw. Empfänger an. Frank schreibt jedenfalls für seinen (!) Empfänger: Frank M. schrieb: > Pulse (Mark) sind Low, Pausen (Space) sind High. Den Sender wird er gar nicht probiert haben. Warum auch? Aber so schwer ist das ja nun auch wieder nicht, den inaktiven Pegel festzustellen.
Axel S. schrieb: > Das kommt auf den jeweiligen Sender bzw. Empfänger an. 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: - Puls (Mark) = Low - Pause (Space) = High
:
Bearbeitet durch Moderator
Peter N. schrieb: > Ich habe die FB direkt, ohne Sender/Empfänger dazwischen, mit dem Pico > verbunden und bin über die Signalpolaritäten etwas verwirrt. 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.
:
Bearbeitet durch Moderator
Axel S. schrieb: > Aber so schwer ist das ja nun auch wieder nicht, den inaktiven Pegel > festzustellen. 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
:
Bearbeitet durch Moderator
Frank M. schrieb: > Das ist Unsinn. Du musst am Empfänger messen, nicht am Sender. 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. Frank M. schrieb: > Du weisst doch gar nicht, wie die Elektronik des Sender einen Puls > umsetzt. 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. Frank M. schrieb: > Der TO hat offenbar den Anspruch, all das, was längst in IRMP vorhanden > ist, nochmal selbst zu durchleben und zu bewältigen. Bleibt mir ja nichts anderes übrig, da ich mit den vorhandenen Sourcen nichts anfangen kann.
Peter N. schrieb: > Erstmal muß ich die Frames richtig erkennen erkennen und einlesen > können, da kann ich keine unsichere Verbindung über Sender/Empänger > gebrauchen. 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. > Bleibt mir ja nichts anderes übrig, da ich mit den vorhandenen Sourcen > nichts anfangen kann. 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.
:
Bearbeitet durch Moderator
Frank M. schrieb: > steigst Du in ein Auto und fährst los. Gegenbeispiel: Den Führerschein bekomme ich nicht geregelt, da fahre ich dann lieber mit dem Pedelec um überhaupt voranzukommen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.