433 MHz SDR Signal dekodieren

Ich schiebe das mal in die HF-Ecke, da sollte solche eine Frage besser 
aufgehoben sein.

Mit rtl-sdr kannst du ja IQ-Daten aufzeichnen. Vielleicht kannst du die 
hier mal als Dateianhang posten.

Danke fürs Verschieben.

Ich habe eine WAV-Datei (welche 29MB groß ist) in meine Cloud geladen:

https://smuehl.de/nextcloud/s/z2gez5R9fTwGodN

Hilft das weiter?

IQ-Daten wären besser als WAV, weil man dann nicht nur die Amplituden-, 
sondern auch die Phaseninformation hat. Ist ja noch nicht wirklich 
sicher, dass es eine (reine) Amplitudenmodulation ist.

https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr

Etwa ab der Hälfte wird das erklärt.

Müsste sich prinzipiell auch aus dem GNU Radio Companion heraus 
abspeichern lassen, falls du den nimmst, aber da bin ich nicht so sehr 
bewandert. Habe das damit bislang auch erst einmal ausprobiert – und bin 
leider beim Decodieren bzw. Reproduzieren meiner offensichtlich 
FSK-modulierten Daten auch nicht so sehr viel weiter gekommen als du 
hier.

Du kannst die Daten auch ruhig hier hochladen als Anhang, aber eventuell 
auf das Wesentliche dabei konzentrieren.

Jörg W. schrieb:
> IQ-Daten wären besser als WAV, weil man dann nicht nur die Amplituden-,
> sondern auch die Phaseninformation hat. Ist ja noch nicht wirklich
> sicher, dass es eine (reine) Amplitudenmodulation ist.


Ich nutze den Universal Radio Hacker über die Windowsplattform. Im 
Anhang befindet sich die I/Q-Datei (lt. URH - Manual). Ich hoffe du 
kannst die Datei öffnen. Swoeit ich dass verstehe, bist du auch am 
Dekodieren hängengeblieben. D.h. es sollte schonmal nicht am Programm an 
sich liegen.

GEKU schrieb:
> Der im Anhang gezeigte Bereich wäre interessant. Der Zoom sollte
> so groß  sein, dass man gerade die einzelnen Linien sieht.

hier noch einmal 2 Bilder. Daraus geht hervor, dass es keine 
Regelmäßigkeit gibt. Das ist, was mich so verwirrt.

> Codierung mit drei Niveaus?
>
> RZ-Codierung siehe:
>
> https://www.elektroniktutor.de/internet/codes.html

Ich verstehe, was du meinst, müsste es wie gesagt nicht eine 
Regelmäßigkeit geben? Oder sollte ich die spitzen Flanken als Rauschen 
interpretieren?

> Wenn man den den Binärcode ist der halbe Weg erreicht.
> Dann muss das Protokoll erforscht werden. Wenn's verschlüsselt ist sind
> die Chancen sehr gering. Dann kann man nur die Codesequenzen speichern
> und auf gut Glück abspielen. Wenn eine Rollcodierung verwendet wird,
> dann ist auch diese Möglichkeit verbaut. Siehe
> https://de.wikipedia.org/wiki/Rollingcode

Meinst du wirklich, dass Intertechno sich die Mühe macht, den Code 
rollend zu gestalten? Es ist doch nur eine billo-home-Variante. Laut 
FHEM (RaspPi-Home-Automation Software sollten die OBI-Varianten einen 32 
BIT-Code aufweisen. 
https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung). Das Signal ist 
aber endlos lang. Was von dem Signal ist Müll

https://github.com/RFD-FHEM/RFFHEM/issues/41
"Sender:ITLS-16, Empfänger ITLR-300.
Der Sender sendet auf jeden Fall auch ein ITv3 Signal, das kann man auch 
entsprechend auswerten."

unpraktischerweise gibt es einen TV-Sender der ITV3 heißt, also besser 
nach "itv3 protocol" suchen:

https://wiki.fhem.de/wiki/SIGNALduino
"Die Geräte werden automatisch erkannt ...
Intertechno Funkschalter"

https://youtu.be/LbCDpbWrdlQ?t=53

Die Idee Audacity als Speicheroszilloskop zu benutzen ist gut. Der 
Soundkarte fehlt allerdings eine DC-Kopplung, deshalb schwankt der DC 
Pegel, wie man im Video sieht. Für meine SPI-Bus-Aufzeichnung neulich 
wäre das allerdings zu langsam gewesen.

Ist der SIGNALduino nicht für die Untersuchung geeignet? Angeblich kennt 
er das Protokoll schon.

Hallo Leute,
zunächst bedanke ich mich für euer detailreiches und schnelles Feedback. 
Ich habe mich jetzt versucht mit all euren Tipps in das Thema 
einzuarbeiten - tiefer und tiefer.

Ich hole zunächst zur verwendeten Hard- und Software ein wenig aus. Zum 
Anfang habe ich mir die Billo-Empfängervariante von Aukru [1] für meinen 
Raspberry geholt und wollte diesen ins FHEM und über die 
433Utils/RPi_utils einbinden. Empfohlen wurde mir den Sender neben dem 
intertechno-Protocol auch das Kaku-Protokoll einfach auszuprobieren. 
Dabei hatte ich wenig Erfolg. Beim transcieven ist außer 
nichtinterpretierbarem Datenmüll nichts rausgekommen. Also bin ich der 
Empfehlung der Community gefolgt und habe mir einen RTL2832U-Dongle 
gekauft, welcher breitere Frequenzbänder abdeckt, da ich vermutet habe, 
dass die Aukru-Varianten mit den dazugehörigen Protokollen an Ihre 
Grenzen geraten. Diese habe ich nun über SDR-Sharp ausgelesen und mit 
Audacity versucht zu interpretieren (also nicht über die Soundkarte, 
sondern über den SDR-TCP-Dongle). Signale wurden zwar beim Drücken der 
Fernbedienung empfangen, aber waren für mich ebenso nicht 
interpretierbar, weswegen ich den „Universal Radio Hacker“ mit der 
gleichen Hardware nutze, da dort viele Voreinstellungen (Filter, 
Bit-Länge, Center, Noise) treffen kann. Das sind die von mir im ersten 
Post hochgeladenen Ergebnisse.
Ich weiß, ich könnte die Steckdosen neu anlernen, dann vergessen diese 
aber meine Hardwarefernbedienung. Ich möchte, dass mein Reciever am 
Raspberry mitbekommt, dass ich per Hardwaretaste den DIMMER schalte. Aus 
diesem Grund möchte ich unbedingt die 26-Bit ID meiner 
ITLS-16-Fernbedienung (leider ist Sie geklebt und ich komme nicht an den 
Chipsatz heran) herausbekommen.
Laut FHEM hat es anscheinend jmd. über das neue Protokoll ITv3 
hinbekommen, weswegen ich nicht von den von euch spekulierten 
Rollingcodes ausgehe.
26-Bit ID des steuernden Geräts (Fernbedienung)   2-Bit Kommando   4-Bit 
Kanal-ID (Tastenpaar)

Jetzt ist meine Motivation das gleiche zu machen, was der schlaue Kopf 
herausgefunden hat – die Fernbedienung EINFACH(!^^) auszulesen. Gibt es 
vlt. einen grundlegenden Fehler, welchen ich beim Sniffen eingehe (Gain, 
Frequenz, Bit-Länge / Pulslänge, Center, Noise…)? Wie komme ich vom 
Signal zum reproduzierbaren o.g. ITv3-Protokoll?

[1] Hallo Leute,
zunächst bedanke ich mich für euer detailreiches und schnelles Feedback. 
Ich habe mich jetzt versucht mit all euren Tipps in das Thema 
einzuarbeiten - tiefer und tiefer.

Ich hole zunächst zur verwendeten Hard- und Software ein wenig aus. Zum 
Anfang habe ich mir die Billo-Empfängervariante von Aukru für meinen 
Raspberry geholt und wollte diesen ins FHEM und über die 
433Utils/RPi_utils einbinden. Empfohlen wurde mir den Sender neben dem 
intertechno-Protocol auch das Kaku-Protokoll einfach auszuprobieren. 
Dabei hatte ich wenig Erfolg. Beim transcieven ist außer 
nichtinterpretierbarem Datenmüll nichts rausgekommen. Also bin ich der 
Empfehlung der Community gefolgt und habe mir einen RTL2832U-Dongle 
gekauft, welcher breitere Frequenzbänder abdeckt, da ich vermutet habe, 
dass die Aukru-Varianten mit den dazugehörigen Protokollen an Ihre 
Grenzen geraten. Diese habe ich nun über SDR-Sharp ausgelesen und mit 
Audacity versucht zu interpretieren (also nicht über die Soundkarte, 
sondern über den SDR-TCP-Dongle). Signale wurden zwar beim Drücken der 
Fernbedienung empfangen, aber waren für mich ebenso nicht 
interpretierbar, weswegen ich den „Universal Radio Hacker“ mit der 
gleichen Hardware nutze, da dort viele Voreinstellungen (Filter, 
Bit-Länge, Center, Noise) treffen kann. Das sind die von mir im ersten 
Post hochgeladenen Ergebnisse.
Ich weiß, ich könnte die Steckdosen neu anlernen, dann vergessen diese 
aber meine Hardwarefernbedienung. Ich möchte, dass mein Reciever am 
Raspberry mitbekommt, dass ich per Hardwaretaste den DIMMER schalte. Aus 
diesem Grund möchte ich unbedingt die 26-Bit ID meiner 
ITLS-16-Fernbedienung (leider ist Sie geklebt und ich komme nicht an den 
Chipsatz heran) herausbekommen.
Laut FHEM hat es anscheinend jmd. über das neue Protokoll ITv3 
hinbekommen, weswegen ich nicht von den von euch spekulierten 
Rollingcodes ausgehe.
26-Bit ID des steuernden Geräts (Fernbedienung)   2-Bit Kommando   4-Bit 
Kanal-ID (Tastenpaar)

Jetzt ist meine Motivation das gleiche zu machen, was der schlaue Kopf 
herausgefunden hat – die Fernbedienung EINFACH(!^^) auszulesen. Gibt es 
vlt. einen grundlegenden Fehler, welchen ich beim Sniffen eingehe (Gain, 
Frequenz, Bit-Länge / Pulslänge, Center, Noise…)? Wie komme ich vom 
Signal zum reproduzierbaren o.g. ITv3-Protokoll?

Hallo Leute,
zunächst bedanke ich mich für euer detailreiches und schnelles Feedback. 
Ich habe mich jetzt versucht mit all euren Tipps in das Thema 
einzuarbeiten - tiefer und tiefer.

Ich hole zunächst zur verwendeten Hard- und Software ein wenig aus. Zum 
Anfang habe ich mir die Billo-Empfängervariante von Aukru für meinen 
Raspberry geholt und wollte diesen ins FHEM und über die 
433Utils/RPi_utils [2] einbinden. Empfohlen wurde mir den Sender neben 
dem intertechno-Protocol auch das Kaku-Protokoll einfach auszuprobieren. 
Dabei hatte ich wenig Erfolg. Beim transcieven ist außer 
nichtinterpretierbarem Datenmüll nichts rausgekommen. Also bin ich der 
Empfehlung der Community [3] gefolgt und habe mir einen RTL2832U-Dongle 
[4] gekauft, welcher breitere Frequenzbänder abdeckt, da ich vermutet 
habe, dass die Aukru-Varianten mit den dazugehörigen Protokollen an Ihre 
Grenzen geraten. Diese habe ich nun über SDR-Sharp ausgelesen und mit 
Audacity versucht zu interpretieren (also nicht über die Soundkarte, 
sondern über den SDR-TCP-Dongle). Signale wurden zwar beim Drücken der 
Fernbedienung empfangen, aber waren für mich ebenso nicht 
interpretierbar, weswegen ich den „Universal Radio Hacker“ [5] mit der 
gleichen Hardware nutze, da dort viele Voreinstellungen (Filter, 
Bit-Länge, Center, Noise) treffen kann. Das sind die von mir im ersten 
Post hochgeladenen Ergebnisse.
Ich weiß, ich könnte die Steckdosen neu anlernen, dann vergessen diese 
aber meine Hardwarefernbedienung. Ich möchte, dass mein Reciever am 
Raspberry mitbekommt, dass ich per Hardwaretaste den DIMMER schalte. Aus 
diesem Grund möchte ich unbedingt die 26-Bit ID meiner 
ITLS-16-Fernbedienung [6](leider ist Sie geklebt und ich komme nicht an 
den Chipsatz heran) herausbekommen.
Laut FHEM [7] hat es anscheinend jmd. über das neue Protokoll ITv3 
hinbekommen, weswegen ich nicht von den von euch spekulierten 
Rollingcodes ausgehe.

26-Bit ID des steuernden Geräts (Fernbedienung) + 2-Bit Kommando + 4-Bit 
Kanal-ID (Tastenpaar)

Jetzt ist meine Motivation das gleiche zu machen, was der schlaue Kopf 
herausgefunden hat – die Fernbedienung EINFACH(!^^) auszulesen. Gibt es 
vlt. einen grundlegenden Fehler, welchen ich beim Sniffen eingehe (Gain, 
Frequenz, Bit-Länge / Pulslänge, Center, Noise…)? Wie komme ich vom 
Signal zum reproduzierbaren o.g. ITv3-Protokoll?

[1]
https://www.amazon.de/Aukru-Superregeneration-Transmitter-Modul-receiver-module/dp/B00OLI93IC/ref=asc_df_B00OLI93IC/?tag=googshopde-21&linkCode=df0&hvadid=309008177512&hvpos=1o3&hvnetw=g&hvrand=15034857729375519174&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041576&hvtargid=pla-587318345194&psc=1&th=1&psc=1&tag=&ref=&adgrpid=65257070361&hvpone=&hvptwo=&hvadid=309008177512&hvpos=1o3&hvnetw=g&hvrand=15034857729375519174&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041576&hvtargid=pla-587318345194
[2] https://github.com/ninjablocks/433Utils/tree/master/RPi_utils
[3] https://www.youtube.com/watch?v=LE1CvGWqSsw&t=270s
[4] 
https://www.amazon.de/Tragbarer-Mini-Digitaler-TV-Stock-Unterst%C3%BCtzung-SDR-Stimmer-Empf%C3%A4nger/dp/B013Q94CT6/ref=asc_df_B013Q94CT6/?tag=googshopde-21&linkCode=df0&hvadid=231942130490&hvpos=1o1&hvnetw=g&hvrand=5142072953929196758&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041576&hvtargid=pla-422395741591&psc=1&th=1&psc=1
[5] https://www.rtl-sdr.com/tag/universal-radio-hacker/
[6] 
https://www.amazon.de/Intertechno-Smart-FUNK-UNIVERSALDIMMER-ITDM-250-Gl%C3%BChbirnen/product-reviews/B00HZL2QCC
[7] 
https://www.amazon.de/Intertechno-Smart-FUNK-UNIVERSALDIMMER-ITDM-250-Gl%C3%BChbirnen/product-reviews/B00HZL2QCC

Kann geschlossen werden.

Es lag nicht am Sender an sich - zumindest nicht direkt. Snifft man das 
Signal, sollte man sehr darauf achten, wann man das Signal aussendet. 
Die Länge des Signals ist etwa 40 Millisekunden. Alles aufgenommene 
herum ist Müll.

Achtet auf den Ausschlag nach oben. Das brauchbare Signal hat einen 
kleineren Gain (db), als das Rauschen, weswegen das "wahre Signal" 
untergeht.

Hier das ausgelesene Signal und ein aufbauender "Send-Thread": 
Beitrag "433 MHz Sender - klare Flanken"