SIGNALDuino - Analyse unbekannter Funkprotokolle

[plin]

Ich bin über diese Seite gestolpert https://homematic-forum.de/forum/viewtopic.php?t=11087 und habe mir jetzt einen DVB-T-Stick bestellt.

(Ich habe nämlich auch noch Velux-Rolläden die nur SOMFY/Tahoma verstehen. Das wäre die nächste noch größere/kompliziertere Nummer ...)

[KölnSolar]

Hi plin,
ich glaube Du bist gedanklich etwas auf dem Holzweg. Du machst Dir Gedanken über ein Modulationsverfahren, das FSK wäre. Der S'duino kann aber meines Wissens nur ASK/OOK. Wenn ich damit richtig liege, kommst Du so also nicht weiter.

Ich hab jetzt nicht jeden Post detailliert gelesen, aber es scheint ja manchmal zu funktionieren, was bedeuten würde, dass es sich eher um eine ASK/OOK-Modulation handelt. Vermutlich würde sonst auch gar nichts vom S'duino erkannt werden. ASK/OOK hat aber keinen "Frequenzhub". Es ist charakterisiert durch die Trägerfrequenz und die wird einfach nur ein- oder ausgeschaltet. Außer Trägerfrequenz und Sendestärke lässt sich dann auch eigentlich nichts einstellen. Beim Empfang dann bwidth u. sense, womit die "Empfindlichkeit" eingestellt wird, dem cc1101 also mitgegeben wird, nur in engen Grenzen zu empfangen und Fehlsignale auszuschließen oder eben möglichst viel zu empfangen, was dann aber "Funkschrott" sein kann.

Da Du vermutlich kein Oszi hast, könntest Du mit dieser oder dieser  Methode versuchen, das Modulationsverfahren zu bestimmen. Als nanoCUL geflashed so analysieren.
Grüße Markus
Edit: Du warst etwas schneller mit Deinem Post 

[plin]

Da Du vermutlich kein Oszi hast, könntest Du mit dieser oder dieser  Methode versuchen, das Modulationsverfahren zu bestimmen. Als nanoCUL geflashed so analysieren.

Zufälligerweise haben ich meinen Oszi aus Studienzeiten noch im Schrank stehen ...

Wie wäre der Ansatz?

VG Peter

[habeIchVergessen]

patable haben noch nicht betrachtet. auf welchem Wert steht das bei dir?

[plin]

patable haben noch nicht betrachtet. auf welchem Wert steht das bei dir?

Auf 10 dB (Rollade 6 war vom Obergeschoss aus nicht zu erreichen (schräg durch die Betondecke durch, deshalb der Ansatz viel-hilft-viel))

[plin]

ich glaube Du bist gedanklich etwas auf dem Holzweg. Du machst Dir Gedanken über ein Modulationsverfahren, das FSK wäre. Der S'duino kann aber meines Wissens nur ASK/OOK. Wenn ich damit richtig liege, kommst Du so also nicht weiter.

Danke für den Hinweis, der hilft in der Tat.

Hast Du eine Idee für folgendes Verhalten:

• Bei 868.275MHz/58kHz habe ich die beste Empfangsqualität, die mitgeschnittenen Codes nähern sich den von uns vermuteten theoretischen Werten -400/400/4000/-800/800.
• Wenn ich mit 868.275MHz sende reagiert kein einziger Motor auf diese Codes.
• Wenn ich mit 868.00MHz sende reagieren 3 der 6 nahezu jedes Mal, 2 manchmal aber nicht zuverlässig, der 6. ist problematisch.

VG Peter

[KölnSolar]

Du bist ja echt fleißig  So schnell kann ich nicht denken und antworten 

Zu Deinem letzten Post:
find ich seltsam, aber das muss nichts heißen  Da müsst ich noch mal in den Tiefen des cc1101 gucken. Wenn ich es richtig im Kopf habe, ist es mit einfacher Frequenzänderung nicht getan. Hab wie blöde gesucht, wo mir Telekatz das mal vor Augen geführt hatte. Ich hab aber nix mehr gefunden  Ich versuch mich mal wieder an der cc1101-Doku......

Wie wäre der Ansatz?

Hab dann noch einmal länger drüber nachgedacht und mir die diversen Threads zu Audacity angeguckt und versucht meine grauen Zellen zu aktivieren, in denen steht, wie ich das mal vor Jahren probiert hatte.  Und für eine Einschätzung meiner Antworten: Ich bin weder firm in Elektronik, noch in Funk. Hab mich aber recht gut in ASK/OOK eingearbeitet.

Ganz vorne angefangen, hast Du sicherlich schon im Inet gesucht, ob sich da etwas zu Hersteller, Protokoll... finden lässt.
Danach würde ich mich auf die FB fokussieren. Ich würde sie mal öffnen, um festzustellen, welcher Sendechip verbaut ist. Evtl. lässt sich dann schon per Suchmaschine das Modulationsverfahren ermitteln.

Oder den Sendepin mit was auch immer abgreifen und aufzeichnen. Bei ASK/OOK ist das mit Soundkarte/Audacity machbar, da die Trägerfrequenz weniger interessiert, sondern nur die Pulslängen von Interesse sind. Das hab ich damals erfolgreich hinbekommen.
Mit einem Oszi(ich hab keins) sollte man auch den Frequenzgang ermitteln können. Das kann ich aber nur theoretisch spekulieren.

Das lässt sich natürlich auch auf der Empfängerseite(cc1101) ausführen. Aber dort hat man dann den cc1101 schon entsprechend eingestellt. Man gewinnt vermutlich kaum neue Erkenntnisse gegenüber der S'duino-Auswertung, außer dass man das Signal nun visualisiert hat und die "kryptische" Darstellung des S'duino bestätigen kann.

[plin]

Ganz vorne angefangen, hast Du sicherlich schon im Inet gesucht, ob sich da etwas zu Hersteller, Protokoll... finden lässt.

tja, das ist die RIO-Serie eines kleinen Bonner Herstellers. Nachdem der Motorenlieferant Pleite gegangen ist haben sie auf eine andere Produktlinie gewschwenkt.  Ich habe sogar per Mail angefragt, ob die mir Informationen zukommen lassen können, die Anfrage lief aber ins Leere.

Danach würde ich mich auf die FB fokussieren. Ich würde sie mal öffnen, um festzustellen, welcher Sendechip verbaut ist. Evtl. lässt sich dann schon per Suchmaschine das Modulationsverfahren ermitteln.

Gute Idee, hätte fast von mir sein können  . Und siehe da: ich lese K110 83 oder K110 B3 und das führt mich über http://www.domoticaforum.eu/viewtopic.php?f=7&t=127&start=45 zu https://www.digchip.com/datasheets/parts/datasheet/216/TDK5110-pdf.php.

Ab sofort müssen wir uns also mit der Idee auseinander setzen einen ASK/OOK-Transceiver für das Senden von ASK/FSK zu nutzen.

JeeLink wäre dann wohl der richtige Ansatz?

[KölnSolar]

Ab sofort müssen wir uns also mit der Idee auseinander setzen einen ASK/OOK-Transceiver für das Senden von ASK/FSK zu nutzen.

JeeLink wäre dann wohl der richtige Ansatz?

Nicht unbedingt. der cc1101 kann ja auch ASK/FSK. Und der CUL hat auch ein paar FSK-Protokolle implementiert(ich glaub HM, MAX....)

Interessant find ich, dass lt. Datenblatt scheinbar für FSK u. ASK unterschiedliche Pins genutzt werden. Kannst Du über die Pins evtl. weiter auf das Modulationsverfahren schließen ?

[plin]

Die Oberseite sieht so aus

Pin 6 (ASKDATA) und Pin 7 (FSKDATA) werden demnach genutzt.

[plin]

mmh, sollte ich dann einen der beiden SIGNALduinos mal auf nanoCUL umflashen?

[KölnSolar]

Pin 6 (ASKDATA) und Pin 7 (FSKDATA) werden demnach genutzt.

Dann wohl figure 3.6, 3.7 oder 3.9  Und die Pins 1, 6 u. 7 mal am Oszi betrachten 

mmh, sollte ich dann einen der beiden SIGNALduinos mal auf nanoCUL umflashen?

Glaube nicht, dass das was bringt. Andererseits: Versuch macht kluch 

Edit: Hab das Datenblatt noch nicht ganz durchschaut  Aber: Es ist ja von 13,56 und divider 64 zu lesen. Auf dem Bild meine ich 13,5672 lesen zu können. Multipliziert mit 64 ergäbe das eine typische(z.B. FS20) 868,30MHz-Frequenz. Und die 2. Frequenz(sofern FSK) +/- 150 kHz des loop filters ? Würde evtl. erklären, dass bei bwidth > 58kHz kein Empfang, da aus ASK-Sicht kein low mehr für die Demodulation empfangen wird ? Und ebenso, warum beim senden von ASK mit der selben Frequenz nichts an den Rolladenmotoren passiert.

Hab mal den CUL in die verschiedenen rfmodes gesetzt:

HomeMatic, MAX  => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Kopp_FC             => freq:868.300MHz bWidth:162KHz rAmpl:42dB sens:8dB
WMBus geht bei mir nicht, weil ich eine spezielle firmware habe.

Soweit meine Spinnereien.

Richtig interessant fand ich dann diese Passage aus dem Internet

Code Auswählen Erweitern

Für den wm-bus ist bei kürzeren Reichweiten das SRD-Frequenzband(short range devices) mit 868MHz und einer Daten-Übertragungsrate von 32,768kbps mit Manchester-Codierung spezifiziert. Dabei
werden die beiden Modi S und T unterschieden. Der Modus S wird hauptsächlich bei Messgeräten eingesetzt, die mit einem lokalen Datensammler zusammen arbeiten (Stationary Devices). Diese funken ihre Daten
nur einige Male am Tag zum Datensammler. Der T-Modus dagegen ist für Geräte gedacht, die häufig senden (frequent transmission mode), d.h. alle n Sekunden oder n Minuten, wobei der Empfänger auch ein mobiles Gerät
sein kann, welches die Daten im walk-by oder drive-by Modus entgegennimmt,. Schließlich wird noch zwischen dem S1 und S2 sowie dem T1 und T2 Modus unterschieden. Hierbei sind S1 und T1 diejenigen Modi in denen das
Gerät nur sendet (unidirektionale Kommunikation). Bei S2 und T2 sendet das Gerät zwar regelmäßig Telegramme, aber der Empfänger kann das Gerät in soweit fernsteuern, dass er z.b. weitere Daten anfordert. Dafür muss das
Gerät dann aber auch einen Empfänger haben, so dass es die Befehle des (mobilen) Datensammlers auch entgegennehmen kann (bidirektionale Kommunikation). Verfolgt man den Signal Pfad von der Antenne her weiter,
dann erkennt man ein Antennen- Anpass-Netzwerk aus Chip-Induktivitäten und Kapazitäten, welches von einem IC in einem TSSOP-16 Gehäuse getrieben wird. Der Ausgang, welcher das Anpass-Netzwerk treibt, ist Pin 14 an
diesem IC. Nun gibt es nicht allzu viele integrierte Schaltungen im sub-ghz Bereich, die entweder senden (Transmitter) oder senden und empfangen (Transceiver). Daher fällt es nicht allzu schwer, den IC als ein Transmitter IC für
den sub-ghz Bereich der Firma Infineon mit der Bezeichnung TDK5110 zu identifizieren. Dass der TDK5110 Tranceiver auf der Platine verbaut wurde, lässt sich auch leicht daran verifizieren, dass der Versorgungsanschluss auf Pin 3 und
der Power Down Anschluss auf Pin 1 liegt. Außerdem ist ein passendes Quarz für die Phasenregelschleife (PLL) mit der Frequenz von 6.78MHz auf der Platine vorhanden. Studiert man das Datenblatt des Sende-ICs TDK5110 von
Infineon, dann kann man ihm entnehmen, dass die Sendeausgangsleistung mit typisch 10mW (10dBm) und mit maximal 15.8mW (12dBm) an 50ohm spezifiziert ist. Um Strom zu sparen wird der Sender über den Power Down Pin
deaktiviert und nur dann aktiviert, wenn auch gesendet werden soll. Dies steuert ein diskreter Transistor oberhalb des IC. Für die physikalische Übertragungsschicht des wm-bus (physical layer nach dem Standard EN )
welche die Funkübertragung regelt, wird eine Frequenzmodulation mit 50kHz Frequenzumtastung benutzt (Frequency-Shift-Keying, FSK). Dazu enthält der Sende-IC einen integrierten Schalter, mit dem eine Last-Kapazität am Quarz
der PLL umgeschaltet wird. Dadurch ändert sich die Schwingfrequenz des Quarzes geringfügig. Da die PLL die Sendefrequenz über einen festen Faktor aus der Quarzfrequenz synthetisiert, folgt diese den Änderungen der umgetasteten
Quarz-Schwingfrequenz und erzeugt so eine FSK-Modulation. Das Datensignal für den FSK-Umtastschalter wird vom Prozessor am Pin 7 angeliefert. Gleichzeitig kann am Pin 6 den Sende-Endverstärker (Power Amplifier) an- und
abgeschaltet werden und so auch eine Amplitudenumtastung erreicht werden (zweiwertige Amplitudenmodulation). Da diese Eingänge offen zugänglich sind, wäre es kein großer Aufwand das Signal des Transistors, das den Chip vom
Prozessor her steuert mit einer zugefügten Elektronik zu überschreiben und zwischen den normal vorgesehenen Sendezeiten über die Modulationseingänge andere Informationen einzuspeisen und zu übertragen.

Das klingt für mich alles danach, dass Du tatsächlich mit dem WMBus-Protokoll eines nanoCUL Erfolg haben könntest. Also doch flashen 

Edit2: Und Du wirst Dir die culfw selber kompilieren und vorher "define HAS_MBUS" in der board.h aktivieren müssen. Ggfs. andere Protokolle deaktivieren, weil der Speicherplatz im nanoCUL nicht ausreicht.

[habeIchVergessen]

bei 868.275 und BW 58 kHz sowie 868.000 und BW 650 kHz funktioniert der Empfang (sens .
Senden geht wohl nur bei 868.000 pa 10.

würde eher gegen WMBus sprechen.

[plin]

bei 868.275 und BW 58 kHz sowie 868.000 und BW 650 kHz funktioniert der Empfang (sens .
Senden geht wohl nur bei 868.000 pa 10.

würde eher gegen WMBus sprechen.

Mein Bauchgefühl:
<spekulation>
FSK sendet auf zwei Frequenzen, eine für High, eine für Low. Wenn wir die High-Frequenz treffen, spricht der Empfänger an und erkennt "high". Fehlt die Low-Frequenz stört in das nicht, weil er "kein high" als "low" interpretiert (Entscheidung des Entwicklers). Deshalb lässt sich unser Empfänger auch mit OOK (einem halben FSK) ansteuern, aber halt nicht so präzise.
</spekulation>

Nach so vielen Tests kommt es jetzt auf einen (evtl. vergeblichen Test) mit dem nanoCUL auich nicht mehr an. Ist halt ein wenig wie ein Adventure Spiel, wir haben zwar vieles eingesammelt aber die Tür zum nächsten Raum geht noch nicht auf.

[plin]

ok, ich bin jetzt so weit:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CMDS       ABbCEeFfGhiKklMmRTtUVWXxZz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1122
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         16
   FHTID      1122
   NAME       nanoCUL
   NR         79
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-03-11 09:30:31   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-03-11 09:29:11   cmds             A B b C E e F f G h i K k l M m R T t U V W X x Z z
     2018-03-11 09:29:11   state           Initialized
Attributes:
   room       nanoCUL
   verbose    5

Log:

Code Auswählen Erweitern

2018.03.11 09:29:07 3: Opening nanoCUL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2018.03.11 09:29:07 3: Setting nanoCUL serial parameters to 38400,8,N,1
2018.03.11 09:29:11 3: nanoCUL: Possible commands: ABbCEeFfGhiKklMmRTtUVWXxZz
2018.03.11 09:29:11 3: nanoCUL device opened

Wie geht es jetzt weiter? Kann ich die bekannten raw-Commands senden oder müssen wir die umrechnen?