Empasa Markise, Bits ermitteln. Siehe Screenshot.

Christian U. OP #6361036
Lesenswert?
• ▲
▼ 
Hallo Gemeinde,

ich habe eine Empasa Sonnenmarkise, und würde die gerne in meiner 
Haussteuerung einbinden, falls mal die Fernbedienung verloren geht.

Die "Markise Rein" Taste habe ich per RTL/SDR Stick aufgezeichnet, und 
in Audacity vor mir liegen. Da es meine Erste Analyse ist, bitte ich um 
Hilfe, ob mir jemand die Bit Reihenfolge aus dem Screenshot erkennen 
kann. Bin mir nicht sicher, ob das "Manchester" like aussieht ?!

Die Fernbedienung ist eine Dooya DC174A.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
wendelsberg Gast #6361130
Lesenswert?
• ▲
▼ 
Ueblicherweise arbeiten die Fernsteuerungen von sowas mit 
Verschluesselung.
Du solltest also erst einmal herausfinden, ob mehrere Betaetigungen 
immer dasselbe Telegramm senden, (was ich fuer unwahrscheinlich halte).

wendelsberg
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nichtverzweifelter Gast #6361190
Lesenswert?
• ▲
▼ 
Taktrate jeder steigenden Flanke konstant ( daraus Takt rückgewinnbar).
Nach jeder steigenden Flanke eindeutig ein kurzer oder langer Highstate, 
daraus Bit null oder eins ableitbar. Also längencodiert, nicht 
phasenwechselkodiert.
Ein schöner, klassischer Code.
Name desselben suchst Dir selber, die entscheidenden Parameter hast Du 
ja jetzt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Christian U. OP #6361294
Lesenswert?
• ▲
▼ 
rtl_433 zeigt mir folgendes an ( pro Knopfdruck auf der Fernbedienung )


1
*** signal_start = 1086186, signal_end = 1154532, signal_len = 68346, pulses_found = 123

2
Iteration 1. t: 653    min: 117 (120)    max: 1189 (3)    delta 1522

3
Iteration 2. t: 653    min: 117 (120)    max: 1189 (3)    delta 0

4
Pulse coding: Short pulse length 117 - Long pulse length 1189

5


6
Short distance: 95, long distance: 194, packet distance: 5889

7


8
p_limit: 653

9
bitbuffer:: Number of rows: 3 

10
[00] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

11
[01] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

12
[02] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

13


14


15
*** signal_start = 1228940, signal_end = 1297199, signal_len = 68259, pulses_found = 123

16
Iteration 1. t: 655    min: 121 (120)    max: 1190 (3)    delta 1768

17
Iteration 2. t: 655    min: 121 (120)    max: 1190 (3)    delta 0

18
Pulse coding: Short pulse length 121 - Long pulse length 1190

19


20
Short distance: 96, long distance: 195, packet distance: 5978

21


22
p_limit: 655

23
bitbuffer:: Number of rows: 3 

24
[00] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

25
[01] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

26
[02] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Christian U. OP #6362502
Lesenswert?
• ▲
▼ 
Hallo Dieter,

danke for Deine ausführliche Erklärung und die Zeit die Du in Anspruch 
genommen hast! Mir ist noch nicht ganz klar, wie ich jetzt die Bits 
interpretieren muss. Da muss ich wohl einfach mehrere Varianten testen, 
und mit dem CUL senden.

10110010 11100010 11110011 01001110 11100001

Oder

01001101 00011101 00001100 01001110 00011110

Vielen Dank nochmal...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Günter Lenz Gast #6362542
Lesenswert?
• ▲
▼ 
von Christian U. schrieb:
>Niemand eine Idee ?

Ganz einfach, du addierst einfach alle Zeiten wo
die Kurve über der Nulllinie ist und subtrahierst
davon alle Zeiten wo die Kurve unter der Nulllinie ist.
Wenn dann 0 rauskommt, ist es Manchestercode.
Das ist ja das Ziel von Manchestercode, es soll
kein Gleichspannungsanteil geben.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter Gast #6362549
Lesenswert?
• ▲
▼ 
Christian U. schrieb:
>
> Mir ist noch nicht ganz klar, wie ich jetzt die Bits interpretieren muss.

Ich weiss nicht ob es bei dem System eine Device-ID gibt um verschiedene 
Sender zu unterscheiden. Falls ja ist diese Device-ID vielleicht 
irgendwo aufgedruckt. Wenn die Device-ID direkt in den Daten stehen 
sollte könnte man so die Bedeutung der Bits "1" und "0" herausfinden.

Viele "wenn" und "vielleicht", aber das wäre ein Weg um die Bits zu 
interpretieren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nichtverzweifelter Gast #6362795
Lesenswert?
• ▲
▼ 
Na, jetzt hast Du es ja raus. Deine ursprüngliche Unterteilung in Bits 
auf die eineinhalbfache Länge umgestellt, richtig. Ob "lang" logisch 1 
oder 0 bedeutet ist reine Definitionssache, gibt halt invertierte Bits.

Jetzt guckst Du noch, mit welcher Wiederholrate ein komplettes Telegramm 
wiederholt wird und ob die Fernbedienung als allererstes einen 
"Einpegelton" für die automatische Verstärkungsregelung (AGC) des 
Empfängers liefert, oder nicht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter Gast #6362835
Lesenswert?
• ▲
▼ 
Christian U. schrieb:
>
> tatsächlich. Die Ersten 4 Bytes (32 Bits) sind IMMER gleich.
>
> Das Letzte Byte (8 Bits) beinhaltet wohl den eigentlichen Schaltvorgang.

Wenn man nach Dooya Fernbedienungen/Sensoren sucht und deren Einbindung 
in SmartHome Systeme sieht man öfters einen ähnlichen Aufbau der Daten: 
40 Bit, die ersten 32 Bit ändern sich nicht. Allerdings ist die 
Modulation unterschiedlich zu dem Signal Deiner Fernbedienung. Ein 
Beispiel gibt es hier für einen Sensor und rtl_433:

https://github.com/merbanan/rtl_433/issues/1337

Ich würde erwarten dass es irgendeine Device-ID gibt um zu verhindern 
dass ein Sender bei allen anderen Markisen funktioniert. Oder kann man 
Sender anlernen durch irgendeine "Pairing" Prozedur?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Christian U. OP #6362866
Lesenswert?
• ▲
▼ 
Hallo nochmal,

vorerst möchte ich mich nochmal bei allen bedanken. Da es meine 'Erste' 
Analyse in dem Bereich ist, nochmal Entschuldigung für meine Fragen. 
Irgendwie hat ja jeder mal angefangen...


@Nichtverzweifelter
Beitrag "Re: Empasa Markise, Bits ermitteln. Siehe Screenshot."

Ein Telegramm besteht aus 3 Gruppen a 5 Bytes (40 Bits), welches 2 x 
Hintereinander exakt gleich gesendet wird. Ich bereite das mal auf, und 
sende dies gleich im Anschluß. Diesmal auch ohne Audacity bearbeitet, 
also so, wie ich es aufgezeichnet habe. In meinem Screenshot habe ich 
nämlich die Verzerrung angepasst, um die Kurven besser dargestellt zu 
bekommen.

Meinst du mit Einpegelton ein Präambel ? Da muss ich mich erst noch 
einlesen. Kann/Muss dieser nicht im 1.sten Byte stecken. Die ersten 4 
Bytes sind ja immer gleich...


@Dieter
Beitrag "Re: Empasa Markise, Bits ermitteln. Siehe Screenshot."
Danke für den Link. Da muss ich mich gleich mal einlesen...


@Möbel
Beitrag "Re: Empasa Markise, Bits ermitteln. Siehe Screenshot."
Mache ich gleich. Bereit das noch kurz in Audacity auf...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Christian U. OP #6362917
Lesenswert?
• ▲
▼ 
Hallo Nochmal,

Anbei das Komplette Telegramm eines Tastendruckes "Markise Raus".

Puh, garnicht so einfach das alles auf einem Screenshot zu bekommen. 
Sorry, aber ich hab mir Mühe gegeben...

Liege ich richtig ?:

- Die Erste Dreiergruppe ist in sich identisch. (Alle 5 Bytes, 40 Bits 
sind gleich)
- Die Zweite Dreiergruppe  ist in sich identisch. (Alle 5 Bytes, 40 Bits 
sind gleich)

- Die Zweite Dreiergruppe ist zu Bytes 1,2,3,4 identisch mit der Ersten 
Gruppe. (grün, gelb, blau, violett)

- Die Zweite Gruppe unterscheidet sich mit 4 Bits im 5.ten Byte von der 
Ersten Gruppe (rot zu blau).

Mhh, die Ersten 4 Bits von links im 5 Byte (kurz, kurz, kurz, lang). 
0001 oder 1110. Kann das der Gerätecode sein ? Findet die eigentliche 
Schaltung in den letzten 4 Bits des 5 Bytes statt ?

Man ist das alles kompliziert...
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nichtverzweifelter Gast #6363116
Lesenswert?
• ▲
▼ 
Es gibt IR-Systeme, die fortwährend senden, solange die Taste gedrückt 
ist, das Loslassen der bisher gedrückt gehaltenen Taste aber extra 
übertragen. Mit einem anderen Code.

Daher Telegramme vergleichen.
Deine bisherigen zeigen, dass die Info "Welche Taste ist gedrückt?" im 
letzten Byte steckt.

Allgemein wird die Reichweite eines IR-Fernbedienungssystems begrenzt 
von: Rauschen, das Signal (Leuchtdichte) ist zu schwach, zu weit weg. 
Anderes Extrem: Das Signal ist viel, viel, viel zu stark und übersteuert 
den Empfänger. Gleichzeitig kämpft das System mit dem Gleichlichtanteil, 
der überall vorhandenen Wärmestrahlung.
Weil das Empfängersystem über eine Verstärkungsregelung verfügen muss, 
die diese Unterschiede ausgleicht, normiert, bevor dann die eigentliche 
Einteilung in "high" und "low" stattfindet, sendet man gerne einen 
Pegelton, eine Präambel oder wiederholt das Telegramm komplett, auch 
wenn Du die Taste "noch so kurz betätigst". Man gibt dem analogteil des 
Empfangssystems Zeit, sich "automatisch richtig auszusteuern".
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter Gast #6363171
Lesenswert?
• ▲
▼ 
Die Auswertung der Signale wird einfacher mit rtl_433 anstelle das per 
Hand zu machen. Da die Modulation nun bekannt ist braucht man rtl_433 
nur die entsprechenden Modulations-Parameter mitteilen. In dem Link, den 
ich weiter oben geschickt habe, wird das auch so gemacht (nach 
"m=OOK_PWM" suchen, die weiteren Parameter müssen noch angepasst 
werden).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Christian U. OP #6363260
Lesenswert?
• ▲
▼ 
Hallo Dieter,

hat sauber funktioniert. Danke @Dieter.

1
## 1. Gruppe;

2


3
Detected OOK package  2020-08-07 09:08:41

4
Analyzing pulses...

5
Total count:  123,  width: 193.45 ms    (48362 S)

6
Pulse width distribution:

7
 [ 0] count:    3,  width: 4808 us [4804;4816]  (1202 S)

8
 [ 1] count:   72,  width:  372 us [364;380]  (  93 S)

9
 [ 2] count:   48,  width:  732 us [728;744]  ( 183 S)

10
Gap width distribution:

11
 [ 0] count:    3,  width: 1488 us [1484;1496]  ( 372 S)

12
 [ 1] count:   72,  width:  696 us [692;708]  ( 174 S)

13
 [ 2] count:   45,  width:  336 us [328;344]  (  84 S)

14
 [ 3] count:    2,  width: 23500 us [23500;23504]  (5875 S)

15
Pulse period distribution:

16
 [ 0] count:    3,  width: 6296 us [6296;6300]  (1574 S)

17
 [ 1] count:  117,  width: 1068 us [1060;1084]  ( 267 S)

18
 [ 2] count:    2,  width: 24240 us [24240;24240]  (6060 S)

19
Level estimates [high, low]:  15884,      2

20
RSSI: -0.1 dB SNR: 39.0 dB Noise: -39.1 dB

21
Frequency offsets [F1, F2]:   -2148,      0  (-8.2 kHz, +0.0 kHz)

22
Guessing modulation: Pulse Width Modulation with sync/delimiter

23
Attempting demodulation... short_width: 372, long_width: 732, reset_limit: 23508, sync_width: 4808

24
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=372,l=732,r=23508,g=0,t=0,y=4808'

25
pulse_demod_pwm(): Analyzer Device

26
bitbuffer:: Number of rows: 3 

27
[00] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 

28
[01] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 

29
[02] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 

30


31


32
## 2.te Gruppe;

33
Detected OOK package  2020-08-07 09:08:41

34
Analyzing pulses...

35
Total count:  123,  width: 193.09 ms    (48272 S)

36
Pulse width distribution:

37
 [ 0] count:    3,  width: 4808 us [4796;4824]  (1202 S)

38
 [ 1] count:   66,  width:  368 us [364;380]  (  92 S)

39
 [ 2] count:   54,  width:  732 us [728;744]  ( 183 S)

40
Gap width distribution:

41
 [ 0] count:    3,  width: 1488 us [1484;1492]  ( 372 S)

42
 [ 1] count:   63,  width:  696 us [692;712]  ( 174 S)

43
 [ 2] count:   54,  width:  336 us [332;348]  (  84 S)

44
 [ 3] count:    2,  width: 23868 us [23868;23868]  (5967 S)

45
Pulse period distribution:

46
 [ 0] count:    3,  width: 6296 us [6288;6312]  (1574 S)

47
 [ 1] count:  117,  width: 1068 us [1060;1084]  ( 267 S)

48
 [ 2] count:    2,  width: 24236 us [24236;24240]  (6059 S)

49
Level estimates [high, low]:  15904,      1

50
RSSI: -0.1 dB SNR: 42.0 dB Noise: -42.1 dB

51
Frequency offsets [F1, F2]:   -1881,      0  (-7.2 kHz, +0.0 kHz)

52
Guessing modulation: Pulse Width Modulation with sync/delimiter

53
Attempting demodulation... short_width: 368, long_width: 732, reset_limit: 23872, sync_width: 4808

54
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=368,l=732,r=23872,g=0,t=0,y=4808'

55
pulse_demod_pwm(): Analyzer Device

56
bitbuffer:: Number of rows: 3 

57
[00] {40} b2 e2 f3 4e e1 : 10110010 11100010 11110011 01001110 11100001 

58
[01] {40} b2 e2 f3 4e e1 : 10110010 11100010 11110011 01001110 11100001 

59
[02] {40} b2 e2 f3 4e e1 : 10110010 11100010 11110011 01001110 11100001



Somit wird folgendes Ergebnis ermittelt, und deckt sich mit meinem 
Letzten Screenshot:

10110010 11100010 11110011 01001110 11101110
10110010 11100010 11110011 01001110 11101110
10110010 11100010 11110011 01001110 11101110

PAUSE

10110010 11100010 11110011 01001110 11100001
10110010 11100010 11110011 01001110 11100001
10110010 11100010 11110011 01001110 11100001

Nun meine abschließende Frage:
Ich würde die Bits jetzt per Signalduino, oder besser einem Arduino mit 
Funk Sender senden wollen.

Muss ich den Delay noch ermitteln, zwischen den Bytes, und der 
Wiederholungsgruppe ?

Als Beispiel würde ich jetzt wie folgt vorgehen:

1
/*

2
  Based on the SendDemo example from the RC Switch library

3
  https://github.com/sui77/rc-switch/

4
*/

5


6
#include <RCSwitch.h>

7
RCSwitch mySwitch = RCSwitch();

8


9
void setup() {

10
  Serial.begin(9600);

11
  

12
  // Transmitter is connected to Arduino Pin #10  

13
  mySwitch.enableTransmit(10);

14


15
  // Optional set pulse length.

16
  mySwitch.setPulseLength(REPLACE_WITH_YOUR_PULSE_LENGTH);

17
  

18
  // Optional set protocol (default is 1, will work for most outlets)

19
  mySwitch.setProtocol(REPLACE_WITH_YOUR_PROTOCOL);

20
  

21
  // Optional set number of transmission repetitions.

22
  // mySwitch.setRepeatTransmit(15);

23
}

24


25
void loop() {

26
  // Binary code - Group 1

27
  mySwitch.send("1011001011100010111100110100111011101110");

28
  // DELAY ??

29
  mySwitch.send("1011001011100010111100110100111011101110");

30
  // DELAY ??

31
  mySwitch.send("1011001011100010111100110100111011101110");

32


33
  // DELAY ??

34
  

35
  // Binary code - Group 2

36
  mySwitch.send("1011001011100010111100110100111011100001");

37
  // DELAY ??

38
  mySwitch.send("1011001011100010111100110100111011100001");

39
  // DELAY ??

40
  mySwitch.send("1011001011100010111100110100111011100001");

41
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nichtverzweifelter Gast #6364590
Lesenswert?
• ▲
▼ 
Wieso " einen ..mit Funk Sender"? Infrarot !!!

Mit ziemlicher Sicherheit "geträgert". D.h. In Wirklichkeit ist das 
Wechsellicht, der IR-Empfänger ist nur so nett (ist heute Standard), Dir 
die Modulation des empfangenen Trägers auszugeben, nicht den Träger 
selbst.

Oft im Bereich 38kHz.

Die "PAUSE" zwischen den beiden Telegrammen, nun ja, wahrscheinlich. Das 
Originaltelegramm scheint keine Stopp-Bits zu enthalten. Also macht er 
es über den zeitlichen Abstand der Telegramme. Kannst Du ja bei Deiner 
Software austesten.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren