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
Angehängte Dateien:
-
1_Spectrum.JPG
110 KB -
3x_gedrueckt.JPG
100 KB -
3_Zoom.JPG
100 KB
:
Verschoben durch Moderator
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.
Angehängte Dateien:
-
Codierung.png
14 KB -
codierung2.png
9,5 KB
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
Angehängte Dateien:
-
Steile_Flanke.JPG
36 KB -
andere_Flanken.JPG
44 KB
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
Angehängte Dateien:
-
Codierung.png
14 KB
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
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?
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
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.
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! ;-)
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
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
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
:
Bearbeitet durch User
nimm den hier... https://www.amazon.de/WINGONEER-Superheterodyne-Wireless-Receiver-Arduino/dp/B06XHJMC82/ref=cm_cr_arp_d_product_top?ie=UTF8
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"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.