SIGNALDuino - Analyse unbekannter Funkprotokolle

Begonnen von plin, 26 Februar 2018, 17:42:45

Vorheriges Thema - Nächstes Thema

habeIchVergessen

sieht so aus, als ob rot die 4000ms high sind. gelb 15000ms high und dazwischen die 400ms low/high Wechsel.
hat jemand eine Erklärung für die vertauschte Polarität?

plin

Die Eckwerte finden sich aber wieder:

Ausgangsbasis
P0=-32001;P1=15860;P2=-398;P3=412;P4=3998;P5=822;P6=-800;D=0123232323232323232323232425636363252563636363252525252525636325636363636325632563252525636363636363636363632563636363252563256363256363636363636363256325;

Die lange Sync-Lücke spiegelt sich in P0=-32001 wider (grün-grün).
Die P1=15860 habe ich noch nicht gefunden.
Die LowHigh-Pärchen 23232323232323232323232 sind als Pärchen jeweils ca. 1.200 ms lang. Knapp 12 Pärchen a 1.200 ms = ca. 14.400 ms (zwischen grün und gelb).
Dann folgt P4=3998 (rot-rot, aber alle positiv).
Danach die Code-Sequenz mit 64 Pärchen a 1.200 ms = ca. 76.800 ms


FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

P.S. Wenn ich die Fernbedienung bei 868.325 MHz/58 kHz mitschneide kriege ich

MU;P0=-406;P1=798;P2=412;P3=-800;P4=-15504;P5=-4004;D=01010101010231023102323102323102310231023102310232310101010102310101023102323102310102310101010101010102310232420202020202020202020202523231023232310231010101010101023102310232310232310231023102310231023231010101010231010102310232310231010231010101010101;CP=2;R=74;O;

Die bisher benutzten Code-Sequenzen stammen alle von Messungen bei 868.000 MHz/650 kHz bzw. 868.275 MHz/58/kHz. Die neue Messung passt besser zu dem was der Oszi anzeigt.

Vielleicht muss ich für die beiden wackligen Motoren noch mal eine Messreihe bei 868.275 MHz/58/kHz mitschneiden, um das Codes abzuleiten.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen

was machen die Motoren, wenn das invertierte Signal auf der höheren Frequenz gesendet wird?

plin

Zitat von: habeIchVergessen am 22 März 2018, 21:39:33
was machen die Motoren, wenn das invertierte Signal auf der höheren Frequenz gesendet wird?
Mein defekter hat auf die erste Sequenz nicht reagiert. Ich denke ich muss erst wieder die strukturell sauberen Signale ermitteln. Bei den bisher bekannten hatte ich eine erste Filterung nach 01 [23,23,..] 4 [sequenz] durchgeführt. Die Ergebnismenge habe ich dann durch meinen Hex-Decoder geschickt und die validen mit den bekannten Motoren/Fernbedienungen/Richtungen extrahiert. Bei den 868.325er-Sequenzen ist das Ergebnis null, muss also wieder nach Gemeinsamkeiten schauen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen

nach dem bekannten Muster bearbeitet

MU;P0=-406;P1=798;P2=412;P3=-800;P4=-15504;P5=-4004;D=

01010101010231023102323102323102310231023102310232310101010102310101023102323102310102310101010101010102310232420202020202020202020202523231023232310231010101010101023102310232310232310231023102310231023231010101010231010102310232310231010231010101010101;CP=2;R=74;O;


01010101010231023102323102323102310231023102310232310101010102310101023102323102310102310101010101010102310232 20202020202020202020202P23231023232310231010101010101023102310232310232310231023102310231023231010101010231010102310232310231010231010101010101

                                            01010101010231023102323102323102310231023102310232310101010102310101023102323102310102310101010101010102310232
20202020202020202020202P23231023232310231010101010101023102310232310232310231023102310231023231010101010231010102310232310231010231010101010101

SsSsSsSsSsSsSsSsSsSsSsSPSlSlLsSlSlSlLsSlLsLsLsLsLsLsLsSlLsSlLsSlSlLsSlSlLsSlLsSlLsSlLsSlLsSlSlLsLsLsLsLsSlLsLsLsSlLsSlSlLsSlLsLsSlLsLsLsLsLsLsLsLsSlLsSlS
                         0 0 1 0 0 0 1 0 1 1 1 1 1 1 1 0 1 0 1 0 0 1 0 0 1 0 1 0 1 0 1 0 1 0 0 1 1 1 1 1 0 1 1 1 0 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 0 1 0
                         22FE A4AA 9F74 B7FA

plin

Ok, ich der mir morgen noch mal mein decode-Script anschauen um ,,gute" Seuenzen zu finden. Vielleicht muss ich auch mein recode-Script nutzen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen

vorher hatten wir sL => 0 und lS => 1
durch das invertieren Sl => 0 und Ls => 1

plin

Mal ein (vermeintlicher) Sprung nach vorne: ein freundliches Forumsmitglied aus Köln dem mein persönliches Adventure Game gefällt hat mir einen DVB-T-Stick geliehen und ich war in der Lage mit SDR# eine Spektrumanalyse durchzuführen (Gegenleistung: Ich werde einen Wiki-Artikel zur Vorgehensweise verfassen - ist schon in Arbeit).

Nur leider passen die Erkenntnisse nicht zu den bisherigen 868.300 MHz, ca. 25 kHz Hub. Wer lügt? Der CC1101 oder der R820T?

FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

KölnSolar

Naja, 868,23/868,28 liegen ja nicht sooo weit weg  ;) Vermutlich kleine Fehlinterpretation unsererseits  :-[ Erklärt aber immer noch nicht warum Senden ASK/868.00 funktioniert. ???

Gestern war mein Pen nur zu langsam. Aber sehe das sonst auch so. Konntest Du die Pulslängen mit dem Oszi oder jetzt mit dem Stick konkretisieren ?

Evtl. durch Probieren(verändern der Pulslängen am S'duino) das gleiche Ergebnis wie beim Oszi-mit-FB erzeugen ? Nicht sehr wissenschaftlich, aber der Zweck heiligt die Mittel.



RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

plin

Zitat von: KölnSolar am 23 März 2018, 21:13:32
Naja, 868,23/868,28 liegen ja nicht sooo weit weg  ;)
Für den Nachrichtentechniker ist das ziemlich weit weg. Der Quartz im Empfänger hat 6,7 MHz, mal 128 + 10,7 MHz Zwischenfreuenz ergibt die 868.300. Dazu noch der Hub => 868.325 MhHz? Die rudimentären Messungen des CC101 erscheinen mir da plausibler als das was SDR# zeigt. Meiner ist noch aus China unterwegs, dann hätten wir einen Vergleichswert. Ich bin mir auch nicht sicher, dass ich SDR# so korrekt konfiguriert habe, dass ich mich auf die angezeigten Werte verlassen kann.

Aktuell versuche ich die bei 868.325 MHz/58 kHz ermittelten Codes zu filtern und brauchbare rauszuziehen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

#131
Der heutige Test mit dem S'duino zeigte:
- das Signal ist relativ schwach im Vergleich zu dem der Fernbedienung (siehe Screenschots)
- die Richtcharakteristik der Wendelantenne spielt auch eine Rolle (Wendelachse parallel zur SDR-Antenne->ok, im 90 Grad-Winkel verdreht->NOK, Achse auch Antenne gerichtet->auch nicht viel)

Die Richtcharakteristik hatte ich als Ursache für einige sich verweigernden Motoren schon im Verdacht. So wie die Rolläden im EG angeordnet sind wird das eine Herausforderung (wobei ich aktuell die S'duino-Antenne senkrecht ausgerichtet habe und die Rollladen-Antennen alle horizontal ausgerichtet sind und es meistens funktioniert!??).
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

#132
Zitat von: KölnSolar am 23 März 2018, 21:13:32
Konntest Du die Pulslängen mit dem Oszi oder jetzt mit dem Stick konkretisieren ?
Wie kann ich mit SDR# die Empfangenen Puls-Sequenzen anzeigen lassen?

Zitat von: KölnSolar am 23 März 2018, 21:13:32
Evtl. durch Probieren(verändern der Pulslängen am S'duino) das gleiche Ergebnis wie beim Oszi-mit-FB erzeugen ? Nicht sehr wissenschaftlich, aber der Zweck heiligt die Mittel.
Das Oszillogram synchronisiert auf Basis der langen Lücke. Es wäre also sinnvoll die nicht einmalig als Präambel zu senden sondern im Wiederholungsblock. Die eigentliche Code-Sequenz wird aber (wie die ersten Analysen zeigten) mehr als einmal in einem Gesamtblock gesendet. Da fehlt mir die Information zur Anzahl Wiederholungen. Wenn ich die kenne kann ich eine Sequenz aus <präambel><code><code><code>.... zusammenbauen und dann schauen was der Oszi sagt.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

KölnSolar

ZitatWie kann ich mit SDR# die Empfangenen Puls-Sequenzen anzeigen lassen?
Keine Erfahrung  :-[ Aber in Anleitungen sieht es so aus, dass das 2. Diagramm das anzeigt(zeitlich von unten nach oben). Wenn man das dann passend zoomen kann...

ZitatDer heutige Test mit dem S'duino zeigte:
Ist da nicht auch ein Ausschlag auf 868.2x zu erkennen? Würde endlich auflösen, warum die gesendeten Befehle überhaupt funktionieren.

Zitatdas Signal ist relativ schwach
Wie ist patable eingestellt ? Für 868.00 müssen sicherlich die Werte angepasst werden.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

plin

Der Ausschlag bei 868.2 MHz im Spektrogram ist immer da, auch wenn der S'duino nicht sendet.
patable steht auf +10 dBm
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB