mikrocontroller.net

Forum: HF, Funk und Felder 433 MHz SDR Signal dekodieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: sascham (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir ein Intertechno-Sender (ITLS-16) und Empfänger-Modul 
(ITLR-300)zum Schalten von Steckdosenleuchten aus dem OBI-Baumarkt 
besorgt. Diese habe ich aneinander hardwaretechnisch angelernt. Für mein 
Smart-Home-Projekt möchte ich die Schaltsignale auffangen und per 
Rasp-Sender beliebig versenden.

Über meinen RaspPi und bestehende Rasp-rtl_433-Bibliotheken habe ich 
leider kein vernünftiges Signal sniffen bzw. interpretieren können.

Nun habe mir ein DVB-T Stick (rtl2832) gekauft, um die Signale 
auszulesen. Leider kann ich die Signale nicht eindeutig interpretieren. 
Kann mir da jmd. helfen, ob ich falsch recorde oder die falsche 
Modulationsart nutze?

Ich bin wie folgt vorgegangen:

1. Das Spektrum legt bei 433,875 MHz (Bild 1)
2. Ich habe 3 Signale aufgenommen, um regelmäßigkeiten zu erkennen (Bild 
2)
3. Herangezoomt ergibt das alles für mich ein ziemliches Wirrwarr (Bild 
3)

Habe ich eine falsche Modulationsart ausgewählt oder Lese ich einen 
Parameter falsch ein?


Vielen Dank

Sascha

: Verschoben durch Moderator
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha M. (sascham)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Sascha M. (sascham)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GEKU (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der im Anhang gezeigte Bereich wäre interessant. Der Zoom sollte so groß 
sein, dass man gerade die einzelnen Linien sieht.

Codierung mit drei Niveaus?

RZ-Codierung siehe:

https://www.elektroniktutor.de/internet/codes.html

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

Autor: Sascha M. (sascham)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: GEKU (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sascha M. schrieb:
> 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.

Die Mühe kostet nur einmal Geld bei der Entwicklung der Software und 
haben keinen Einfluss auf die Produktion. Aber der Ruf würde dauerhaft 
ruiniert werden, wenn der Schalter von Fremden gehackt und geschaltet 
werden könnte.

Wenn Scrambler und Whitening im Spiel ist, erkennt man nur mehr 
Rauschen.

Whitening siehe 3.11 Packet Mode MRF89XA

Scrambler siehe 
https://de.wikipedia.org/wiki/Scrambler_(Telekommunikation)

Die beide letzten Anhänge sind zu stark gezoomt und daher nicht 
aussagekräftig.
Interessant der gesamte Ausschnitt gezoomt im Anhang 2

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sascha M. schrieb:
> Es ist doch nur eine billo-home-Variante.

Der Paketmode des MRF89XA macht es im Chip!

Übrigens welcher Chip ist in dem Gerät verbaut?

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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"

: Bearbeitet durch User
Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Sender:ITLS-16, Empfänger ITLR-300

Ich meinte nicht den Gerätetyp , sondern den Chipsatz vom Sender.
Auch ein gutes Foto vom geöffneten Gerät reicht.
Wenn man Glück hat, dann ist der Chip des Sendemoduls nicht 
neutralisiert.

Wenn es keine Onechip Lösung ist (HF Teil + MC) könnte man das Signal 
dazwischen abgreifen. HilfT bei der Analyse des HF Signals.

Autor: Als Gast hier (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich habe eine Empfehlung für dich, bevor du tief in das Thema 
einsteigst...

Prüfe zunächst, ob der Code, den dein Sender abschickt auch wirklich 
reproduzierbar ist, oder ob jede Sendung inhaltlich anders ist.
Wenn sie nicht reproduzierbar ist, besteht als einzige reale Chance nur, 
den Sender an sich zu nutzen und diesen direkt per Tastenansteuerung 
einzubinden.
Rollingcode geht noch, aber sobald echte Verschlüsselung im Spiel ist, 
legst du dir schlicht die Karten!

Viel Erfolg dir! Und, wenn du eine Lösung hast, her damit! ;-)

Autor: Als Gast hier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Die Daten vom Sender bekommst du leicht auf zwei Arten sauber 
gelesen:

1) für 2,50 Euro oder günstiger ein 433er Empfängermodul und ein Arduino 
uno,

2) für wenig Geld mit einem Salaea-Logicanalyser direkt per Wire den 
Sender anzapfen

Autor: Georg M. (g_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Sascha M. (sascham)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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] Youtube-Video "#44 Hacking and Cloning a Garage Door Opener using SDR Radio"
[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

: Bearbeitet durch User
Autor: Als Gast hier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.