Hallo, ich möchte gerne Bewegungsmelder der Firma B.E.G Brück fernsteuern. Viele der Melder haben eingebaute Infrarot Empfänger. Als Zubehör gibt es dazu entsprechende Fernbedienungen und eine Smartphone App, zu der ein Sender für den Klinkenanschluss erworben werden muss. Schöner wäre allerdings die Verwendung der in viele Smartphones eingebauten Infrarot Diode. Der Sender für den Klinkenanschluss enthält einen Akku, der vor der Benutzung geladen werden muss. Nun habe ich mir die App heruntergeladen und die Signale am Klinkenanschluss aufgezeichnet (siehe Anhang). Ich gehe mal davon aus, dass das Signal in dem Sender aufbereitet wird und anschließend mit der derzeit unbekannten Frequenz moduliert und verstärkt wird. Die Pulse in daten.png zeigen die Daten, die bei konstantem Druck auf die Taste gesendet werden. Der erste Teil ist bei kurzem Druck auf die Taste nicht vorhanden. Das Bild puls.png zeigt einen Puls, der irgendwie vermutlich zu einer 1 bei der Modulation gewandelt wird. Die Daten stammen von der App zu dieser Fernbedienung (https://www.luxomat.com/en/pdf/en/datasheet/92105.pdf). Kann jemand etwas mit diesem Daten anfangen, und mir Tipps geben, wie sie zu filtern und zu modulieren sind, um das Klinkensignal an eine Infrarotdiode weiterzugeben? Hat vielleicht jemand eine solche Fernbedienung und weiß etwas über das verwendete Protokoll?
Hans schrieb: > Kann jemand etwas mit diesem Daten anfangen, und mir Tipps geben, wie > sie zu filtern und zu modulieren sind, um das Klinkensignal an eine > Infrarotdiode weiterzugeben? Es sieht so aus, als würde da schon ein moduliertes Signal herauskommen, das man lediglich begrenzen/digitalisieren muss. Dazu könnte ein nicht ganz langsamer Schmitt-Trigger oder Komparator dienen. Hans schrieb: > puls.png Schönes Bild, aber du hast vergessen, den Zeitmasstab mit zu knipsen. So weiss man nichts über die Modulationsfrequenz. Das wäre der Abstand der Nulldurchgänge. Wenn der Abstand z.B. 13µs wäre, hätten wir etwa 38 kHz Modulationsfrequenz.
Matthias S. schrieb: > Schönes Bild, aber du hast vergessen, den Zeitmasstab mit zu knipsen. Ja stimmt. Das war schon doppelt ein guter Hinweis, die Aufnahmerate war nämlich in der ersten Aufzeichnung viel zu gering, um nur ansatzweise etwas sinnvolles zu erkennen bei einem modulierten Signal. Matthias S. schrieb: > Wenn der Abstand z.B. 13µs wäre, hätten wir etwa 38 kHz > Modulationsfrequenz. Ich habe jetzt nochmal eine Aufnahme erstellt, diesmal mit eine Rate von 384000 Hz. Jetzt ist das Signal auch schön rund. Der im Screenshot markierte Bereich ist laut Audacity 10 Samples lang, womit sich eine Dauer von 26µs ergibt. Nach meiner Rechnung wären das dann 38kHz. Im nächsten Schritt würde es wohl Sinn machen eine Filterschaltung aufzubauen. Wenn ich das richtig deute, dann sollten die negativen Halbwellen einer 0 und die positiven einer 1 entsprechen. Am Logic Analyzer sollte sich somit bereits ein brauchbares Signal ergeben. Alternativ könnte ich das Signal natürlich auch digital aus der Aufnahme filtern und zum Test direkt an einen Mikrocontroller geben. Da ich die Schaltung ohnehin nicht am Klinkenstecker betreiben möchte, gefällt mir diese Lösung momentan sogar besser.
Angehängte Dateien:
-
signal.png
10 KB
Hans schrieb: > Der im Screenshot > markierte Bereich Mist, Anhang vergessen
Hans schrieb: > Der im Screenshot > markierte Bereich ist laut Audacity 10 Samples lang, womit sich eine > Dauer von 26µs ergibt. Nach meiner Rechnung wären das dann 38kHz. Nur ein unbedeutender Rundungsfehler :-P Die Frequenz bezieht sich auf eine volle Periode des Signals, ist also nur halb so hoch. Deswegen hatte ich oben ja geschrieben, das bei 13µs zwischen 2 Nulldurchgängen 38kHz rauskommen. Da herkömmliche Audioausgänge nicht bis 38kHz kommen, mussten sie was tieferes nehmen. Sind also etwa 19kHz.
:
Bearbeitet durch User
Das erklärt, warum ich mit meinem schnellen Aufbau mit OPV und Logic Analyzer nur die halbe Frequenz messen konnte. Ich hatte mich auch schon ein bisschen gewundert, dass das Signal eine so hohe Frequenz haben sollte.
Hans schrieb: > ich möchte gerne Bewegungsmelder der Firma B.E.G Brück fernsteuern. > Viele der Melder haben eingebaute Infrarot Empfänger. Als Zubehör gibt > es dazu entsprechende Fernbedienungen und eine Smartphone App, zu der > ein Sender für den Klinkenanschluss erworben werden muss. Schöner wäre > allerdings die Verwendung der in viele Smartphones eingebauten Infrarot > Diode. Alternativ könnte man die IR-Signale mit IRMP aufzeichnen. Mit etwas Glück ist das verwendete Protokoll bereits unter den 50 bekannten Protokollen. Dann braucht man nur noch die Remote IRMP-App, die mittlerweile auch direkt über IR senden kann: Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" Damit ist es möglich, nicht nur übers WLAN IRMP-codierte Frames an IRMP-Satelliten im Netz zu schicken, sondern auch den IR-Transmitter im Handy direkt zu verwenden. Das Handy lässt sich dann als Universal-Fernbedienung benutzen. Hier definiert man ein paar Tasten, hinterlegt Protokollnummer und Kommando und schon kann man per Handy die Bewegungsmelder fernsteuern. Sollte das verwendete Protokoll nicht bekannt sein, kann man mit IRMP auch die Daten im Rohformat aufnehmen und auf der seriellen Schnittstelle ausgeben. Dann schickst Du mir die Scans und ich baue das Protokoll in IRMP ein.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Hier definiert man ein paar Tasten, hinterlegt Protokollnummer und > Kommando und schon kann man per Handy die Bewegungsmelder fernsteuern. Das macht ja auch schon die App, die der TE benutzt. Das o.a. Signal kommt aus dem Kopfhörerausgang des Telefones. Für IRMP müsste man nämlich auch noch einen Empfänger für 19kHz Modulationsfrequenz bauen, das ist gar nicht so einfach - gibts ja nicht fertig. @TE: Bau doch mal mit deinem OPV eine Komparatorschaltung (oder einen Verstärker, der in die Begrenzung geht), die du so dimensionierst, das am Ausgang des OPV ein Rechtecksignal rauskommt. (Kannst du bei Audacity einfach mal auf den zweiten Kanal legen und testen). Wenn du die Schaltung soweit hast, das der Ausgang praktisch eine Rechteckversion des Eingangssignales ist, legst du das Signal auf eine IR LED mit entsprechendem Vorwiderstand und sendest an die Bewegungsmelder.
:
Bearbeitet durch User
Wenn ich mir die "daten.png"-Grafik im ersten Posting so anschaue, würde ich ja vermuten, dass da 32 Bit übertragen werden, und man das für den Anfang ungefähr so dekodieren könnte: Kurze Ruhephase/kurzer Abstand zwischen zwei Pulsen = 0-Bit Lange Ruhephase/langer Abstand zwischen zwei Pulsen = 1-Bit ...oder genau anders herum. Das dargestellte Signal würde ich daher als folgende Bit-Folge interpretieren: 00000000 11111111 00010000 11101111 oder (invertiert) 11111111 00000000 11101111 00010000 Wenn man das ganze als vier Bytes interpretiert, dann fällt weiterhin auf, dass (zumindest in diesem Beispiel) das zweite Byte exakt dem Wert des ersten Bytes entspricht, aber mit invertierten Bits; genauso verhält es sich beim dritten und vierten Byte. Sofern das nicht nur ein erstaunlicher Zufall ist, würde ich daher vermuten, dass da letztlich 16 Bits an Informationen übertragen werden. Vielleicht kannst Du ja einfach mal eine etwas längere Audio-Aufnahme machen und dann möglichst viele verschiedene/alle vorhandenen Tasten drücken, dann könnte man das Protokoll besser analyisieren.
Joachim S. schrieb: > Wenn ich mir die "daten.png"-Grafik im ersten Posting so anschaue, würde > ich ja vermuten, dass da 32 Bit übertragen werden, Das sehe ich genauso. Joachim S. schrieb: > Wenn man das ganze als vier Bytes interpretiert, dann fällt weiterhin > auf, dass (zumindest in diesem Beispiel) das zweite Byte exakt dem Wert > des ersten Bytes entspricht, aber mit invertierten Bits; genauso verhält > es sich beim dritten und vierten Byte. Jepp. Das könnte das weit verbreite NEC-Protokoll sein: https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC Um das zu verifizieren, müsste der TO einfach mal die Längen der Pulse/Pausen vermessen. Mit der Remote IRMP-App ginge es dann ohne Adapter am Klinkenstecker, also direkt mit einer eingebauten IR-LED. Allerdings habe ich nicht im Kopf, welchen Modulationsbereich die Android-IR-Transmitter so unterstützen, also ob sie überhaupt bis 19kHz herunterkommen. Das kann man aber mit getCarrierFrequencies() aus der ConsumerIrManager-Klasse herausfinden.
Frank M. schrieb: > Das könnte das weit verbreite NEC-Protokoll sein: > > https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC Stimmt, das passt perfekt. Das oben dargestellte Signal dürfte demnach dekodiert "Adresse 0x00/Befehl 0x08" bedeuten.
:
Bearbeitet durch User
Joachim S. schrieb: > Das oben dargestellte Signal dürfte demnach dekodiert "Adresse > 0x00/Befehl 0x08" bedeuten. Oder in der Extended-NEC-Variante, welche die Standard-Adresse auf 16 Bit aufbohrt und damit die Negierung der zweiten Adresshälfte obsolet macht: Adresse 0x00FF, Befehl 0x08. Diese Werte würde jedenfalls IRMP ausspucken.
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.