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.
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.
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.
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.
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.
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.
