Empasa Markise, Bits ermitteln. Siehe Screenshot.

[Christian U. (gan_dalf)]

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.

[wendelsberg (Gast)]

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

[Christian U. (gan_dalf)]

Hallo Wendelsberg,

433Mhz. 5xRecorded, immer das selbe Ergebnis, und exakt die gleiche 
Kurven. Daher kann ich eine Verschlüsselung ausschließen.

Kannst du mir weiterhelfen, bei der Decodierung aus dem Screenshot ?

[wendelsberg (Gast)]

Christian U. schrieb:
> Kannst du mir weiterhelfen, bei der Decodierung aus dem Screenshot ?

Nein.
Aber AM scheint das schonmal nicht zu sein.

wendelsberg

[Christian U. (gan_dalf)]

Aufzeichnung wurde im "AM" Modus gemacht. Wie kommst du drauf, das das 
kein AM ist ?

[Nichtverzweifelter (Gast)]

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.

[Christian U. (gan_dalf)]

Hallo Nichtverzfeifelter,

(Ich bin am Verzweifeln :) ).

Ich weiß nicht, ob meine Analyse richtig ist. Kann da jemand rüber 
schauen ? Siehe Screenshot.

[Christian U. (gan_dalf)]

Hallo Nochmal,

bin ich mit PWM auf der richtigen Spur ?

[Christian U. (gan_dalf)]

rtl_433 zeigt mir folgendes an ( pro Knopfdruck auf der Fernbedienung )

*** signal_start = 1086186, signal_end = 1154532, signal_len = 68346, pulses_found = 123
Iteration 1. t: 653    min: 117 (120)    max: 1189 (3)    delta 1522
Iteration 2. t: 653    min: 117 (120)    max: 1189 (3)    delta 0
Pulse coding: Short pulse length 117 - Long pulse length 1189

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

p_limit: 653
bitbuffer:: Number of rows: 3 
[00] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0
[01] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0
[02] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0


*** signal_start = 1228940, signal_end = 1297199, signal_len = 68259, pulses_found = 123
Iteration 1. t: 655    min: 121 (120)    max: 1190 (3)    delta 1768
Iteration 2. t: 655    min: 121 (120)    max: 1190 (3)    delta 0
Pulse coding: Short pulse length 121 - Long pulse length 1190

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

p_limit: 655
bitbuffer:: Number of rows: 3 
[00] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0
[01] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0
[02] {41} 80 00 00 00 00 00 : 10000000 00000000 00000000 00000000 00000000 0

[Christian U. (gan_dalf)]

Niemand eine Idee ?

[funky (Gast)]

Christian U. schrieb:
> Niemand eine Idee ?

Einfach machen!

Oder meinst du du findest ein fertiges .hex File für dein µC, das aus 
dem Format deiner Wahl diesen Bitstrom für dein  RF-IC erzeugt?

Vielleicht hilft IRMP/IRSND weiter?

[Dieter (Gast)]

Was spricht gegen die eigentlich offensichtliche Interpretation (siehe 
Bild)?

"Rot" trennt die Bytes, "Grün" die Bits. Also insgesamt 40 Bits (5 
Bytes), eventuell sind das dann 32 Bit Device-ID und 8 Bit Befehl.

[Christian U. (gan_dalf)]

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

[Günter Lenz (Gast)]

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.

[Dieter (Gast)]

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.

[Christian U. (gan_dalf)]

@Günther,

Danke für den Tipp. Das sollte ich gleich rausbekommen...

@Dieter,

Ich 'grabbe' heute mal die Taste "Markise raus" Taste. Wenn die ersten 
32-Bits gleich bleiben, wäre Deine Vermutung richtig. Bin mal 
gespannt...

[Christian U. (gan_dalf)]

Hallo Dieter,

tatsächlich. Die Ersten 4 Bytes (32 Bits) sind IMMER gleich.

Das Letzte Byte (8 Bits) beinhaltet wohl den eigentlichen Schaltvorgang.

Im Neuen Screenshot habe ich die LED Beleuchtung der Markise 
eingeschaltet...

[Nichtverzweifelter (Gast)]

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.

[Dieter (Gast)]

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?

[Möbel (Gast)]

Christian U. schrieb:

> Im Neuen Screenshot habe ich die LED Beleuchtung der Markise
> eingeschaltet...

Poste doch der Einfachheit halber alle Telegramme.

[Christian U. (gan_dalf)]

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

[Christian U. (gan_dalf)]

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

[Nichtverzweifelter (Gast)]

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

[Dieter (Gast)]

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

[Christian U. (gan_dalf)]

Hallo Dieter,

hat sauber funktioniert. Danke @Dieter.

## 1. Gruppe;

Detected OOK package  2020-08-07 09:08:41
Analyzing pulses...
Total count:  123,  width: 193.45 ms    (48362 S)
Pulse width distribution:
 [ 0] count:    3,  width: 4808 us [4804;4816]  (1202 S)
 [ 1] count:   72,  width:  372 us [364;380]  (  93 S)
 [ 2] count:   48,  width:  732 us [728;744]  ( 183 S)
Gap width distribution:
 [ 0] count:    3,  width: 1488 us [1484;1496]  ( 372 S)
 [ 1] count:   72,  width:  696 us [692;708]  ( 174 S)
 [ 2] count:   45,  width:  336 us [328;344]  (  84 S)
 [ 3] count:    2,  width: 23500 us [23500;23504]  (5875 S)
Pulse period distribution:
 [ 0] count:    3,  width: 6296 us [6296;6300]  (1574 S)
 [ 1] count:  117,  width: 1068 us [1060;1084]  ( 267 S)
 [ 2] count:    2,  width: 24240 us [24240;24240]  (6060 S)
Level estimates [high, low]:  15884,      2
RSSI: -0.1 dB SNR: 39.0 dB Noise: -39.1 dB
Frequency offsets [F1, F2]:   -2148,      0  (-8.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 372, long_width: 732, reset_limit: 23508, sync_width: 4808
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=372,l=732,r=23508,g=0,t=0,y=4808'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 3 
[00] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 
[01] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 
[02] {40} b2 e2 f3 4e ee : 10110010 11100010 11110011 01001110 11101110 


## 2.te Gruppe;
Detected OOK package  2020-08-07 09:08:41
Analyzing pulses...
Total count:  123,  width: 193.09 ms    (48272 S)
Pulse width distribution:
 [ 0] count:    3,  width: 4808 us [4796;4824]  (1202 S)
 [ 1] count:   66,  width:  368 us [364;380]  (  92 S)
 [ 2] count:   54,  width:  732 us [728;744]  ( 183 S)
Gap width distribution:
 [ 0] count:    3,  width: 1488 us [1484;1492]  ( 372 S)
 [ 1] count:   63,  width:  696 us [692;712]  ( 174 S)
 [ 2] count:   54,  width:  336 us [332;348]  (  84 S)
 [ 3] count:    2,  width: 23868 us [23868;23868]  (5967 S)
Pulse period distribution:
 [ 0] count:    3,  width: 6296 us [6288;6312]  (1574 S)
 [ 1] count:  117,  width: 1068 us [1060;1084]  ( 267 S)
 [ 2] count:    2,  width: 24236 us [24236;24240]  (6059 S)
Level estimates [high, low]:  15904,      1
RSSI: -0.1 dB SNR: 42.0 dB Noise: -42.1 dB
Frequency offsets [F1, F2]:   -1881,      0  (-7.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 368, long_width: 732, reset_limit: 23872, sync_width: 4808
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=368,l=732,r=23872,g=0,t=0,y=4808'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 3 
[00] {40} b2 e2 f3 4e e1 : 10110010 11100010 11110011 01001110 11100001 
[01] {40} b2 e2 f3 4e e1 : 10110010 11100010 11110011 01001110 11100001 
[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:

/*
  Based on the SendDemo example from the RC Switch library
  https://github.com/sui77/rc-switch/
*/

#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();

void setup() {
  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // Optional set pulse length.
  mySwitch.setPulseLength(REPLACE_WITH_YOUR_PULSE_LENGTH);
  
  // Optional set protocol (default is 1, will work for most outlets)
  mySwitch.setProtocol(REPLACE_WITH_YOUR_PROTOCOL);
  
  // Optional set number of transmission repetitions.
  // mySwitch.setRepeatTransmit(15);
}

void loop() {
  // Binary code - Group 1
  mySwitch.send("1011001011100010111100110100111011101110");
  // DELAY ??
  mySwitch.send("1011001011100010111100110100111011101110");
  // DELAY ??
  mySwitch.send("1011001011100010111100110100111011101110");

  // DELAY ??
  
  // Binary code - Group 2
  mySwitch.send("1011001011100010111100110100111011100001");
  // DELAY ??
  mySwitch.send("1011001011100010111100110100111011100001");
  // DELAY ??
  mySwitch.send("1011001011100010111100110100111011100001");
}

[Nichtverzweifelter (Gast)]

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.