SIGNALDuino - Analyse unbekannter Funkprotokolle

[plin]

Unter Section 26 kannst du nachlesen wie man die Temperatur als analoge Spannung an einen IO Pin ausgeben kann. Über ein Register geht es nicht.

Da ich aktuell mit dem SIGNALduino arbeite und dieser die Temperatur nicht ausliest fällt diese Option dann weg.

Nur nebenbei, die Bandbreite wird nicht mit +/- angegeben sondern ist der gesamtbetrag, d.h. +/-50kHz sind 100kHz Bandbreite und die +/-23kHz sind eigentlich  46kHz (Vermutlich 50kHz eingestellt)

jow, war wohl unkonzentriert und hätte Frequenzhub schreiben sollen. Laut Datenblatt ist der +/--Ansatz bei der Modulation aber korrekt: "The 868 MHz 50Ω-Output testboard shows an FSK-deviation of +/- 27 kHz, typically.",

Ein Drift um 660kHz ist wohl nur ein Tippfehler.

tja, da war der Wunsch wohl Vater des Gedankens ...

<OT> Wie sendet man breitbandiger ? Es wird doch nur mit einer konkreten Frequenz gesendet und ggfs. breitbandiger empfangen  Link für Dummies ? <OT>

Aber natürlich kann ich breitbandiger als OOK senden: FSK  . Aber nicht mit dem SIGNALdunio. Dann müsste die culFW ran aber die ist nicht so flexibel ausgelegt wie die des S'duino. Außerdem fehlt mir immer noch die Bestätigung für 868.300 MHz mit +/- 23 kHz Hub. Der SDR-Stick-Mitschnitt zeigt ja deutlich abweichende Frequenzen.

Wenn der CC1101, TDK5110 und TDA5210 nur geringe Frequenzabweichungen haben, bedeutet das, dass mein SDR-Stick derjenige ist der daneben liegt. Vielleicht suche ich mir mal einen richtigen Sender als Vergleichsquelle.

[plin]

Die Empfehlung des Tages: Universal Radio Hacker (urh). Das einzige Tool was bisher in der Lage war ad-hoc das Signal aufzuzeichnen, FSK zu dekodieren und mir das anzuzeigen was ich wissen will.
Die Screenshots bestätigen das was ich bisher ermittelt habe.

Aber: Auf Grund der ersten verwertbaren Codes und des im FHEM-Log angezeigten Overflow-Flags glaubte ich, dass die Code-Sequenz innerhalb eines Blocks mehrfach gesendet wird bevor es wieder mit der 15ms Pause weiter geht (Edit: Die Sequenz könnte länger sein als bisher gedacht, siehe nächsten Post). Die Analyse zeigt, dass die komplette Sequenz
- 15 ms Pause
- 10 ms Preamble
- 4 ms Pause
- 78 ms Code
wiederholt wird.

Damit kann ich jetzt im Prinzip saubere Steuersequenzen erzeugen (ich hoffe, dass meine Motoren das auch so sehen).

Eine komplette FSK-Sequenz für Motor 7 Stop sieht damit z.B. so aus:

Code Auswählen Erweitern

0000000000000000000000000000000000000001010101010101010101010100000000001101001101101001001001101001001001001101001001101001001001101001001001101101001101001101001101001101001001101101101101101001101101101001101001001101001101101001101101101101101101101101101101001
bzw. bei erneutem betätigen des Buttons

Code Auswählen Erweitern

0000000000000000000000000000000000000001010101010101010101010100000000001101101001101101101101101001101001101101001001101001001001001101101101001001101001101101101001001101001001101101101101101001101101101001101001001101001101101001101101101101101101101101101101001

Die Hex-Ergebnisse von 4 Tastendrücken mit Pause dazwischen (jeweils ein CR bei neuer Pause eingefügt):

Code Auswählen Erweitern


Block 1
00000000055555500369b6da69b49a4936d269b69349b6da6da6934da6db6db6d2
0000000002aaaaa801b4db6d34da4d249b6934db49a4db6d36d349a6d36db6db69
000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48
000000000555555001b4db6d34da4d249b6934db49a4db6d36d349a6d36db6db69
000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48
000000000aaaaaa006d36d34da4d249b6934db49a4db6d36d349a6d36db6db69
000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48
000000000aaaaaa00369b6da69b49a4936d269b69349b6da6da6934da6db6db6d2
000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48
000000000aaaaaa006d36db4d36934926da4d36d26936db4db4d269b4db6db6da4

Block 2
00000000005555550034da49a49349a49a49b4d34d349b6da6da6934da6db6db6d2
000000000155555400d36926924d26926926d34d34d26db69b69a4d369b6db6db48
000000000aaaaaa0069b49349269349349369a69a6936db4db4d269b4db6db6da4
0000000005555550034da49a49349a49a49b4d34d349b6da6da6934da6db6db6d2
0000000002aaaaa801a6d24d249a4d24d24da69a69a4db6d36d349a6d36db6db69
0000000000aaaaaa0069b49349269349349369a69a6936db4db4d269b4db6db6da4
0000000005555550034da49a49349a49a49b4d34d349b6da6da6934da6db6db6d2
0000000002aaaaa801a6d24d249a4d24d24da69a69a4db6d36d349a6d36db6db69
000000000155555400d36926924d26926926d34d34d26db69b69a4d369b6db6db48

Block 3
0000000005555550036d269348d249349349249269a4db6d36d349a6d36db6db69
0000000000aaaaaa0036d269349a4926926924924d349b6da6da6934da6db6db6d2
0000000002aaaaa801b69349a4d249349349249269a4db6d36d349a6d36db6db69
000000000155555400db49a4d269249a49a4924934d26db69b69a4d369b6db6db48
0000000005555550036d269349a4926926924924d349b6da6da6934da6db6db6d2
000000000155555400db49a4d269249a49a4924934d26db69b69a4d369b6db6db48
0000000005555550036d269349a4926926924924d349b6da6da6934da6db6db6d2
000000000155555400db49a4d269249a49a4924934d26db69b69a4d369b6db6db48
0000000005555550036d269349a4926926924924d349b6da6da6934da6db6db6d2
000000000155555400db49a4d269249a49a4924934d26db69b69a4d369b6db6db48
000000000aaaaaa006da4d26934924d24d249249a6936db4db4d269b4db6db6da4
0000000002aaaaa801b69349a4d2493424d249249a6936db4db4d269b4db6db6da4

Block 4
000000000055555500269269b6db6db6d36db6924db49b6da6da6934da6db6db6d2
00000000015556a80134934db6db6db69b6db4926da4db6d36d349a6d36db6db69
0000000000aaaaaa004d24d36db6db6da6db6d249b6936db4db4d269b4db6db6da4
00000000055555500269269b6db6db6d36db6924db49b6da6da6934da6db6db6d2
0000000001555554009a49a6db6db6db4db6da4936d26db69b69a4d369b6db6db48
000000000aaaaaa004d24d36db6db6da6db6d249b6936db4db4d269b4db6db6da4
0000000002aaaaa80134934db6db6db69b6db4926da4db6d36d349a6d36db6db69
0000000000555554004d24d36db6db6da6db6d249b6936db4db4d269b4db6db6da4
00000000055555500269269b6db6db6d36db6924db49b6da6da6934da6db6db6d2
0000000002aaaaa80134934db6db6db69b6db4926da4db6d36d349a6d36db6db69


[plin]

Erste Erkenntis nach Betrachtung der Bitfolgen: Die scheint doch länger zu sein als ich bisher dachte (und nutzte). Zumindest sieht urh das so.
Die Unterschiede in den Hex-Sequenzen (z.B. 00000000015555540 vs. 000000000aaaaaa00) entstehen durchr einzelne Bitverschiebungen).

[tux75at]

Bandbreite, Modulierung etc haben nicht viel miteinander zu tun, ausser dass es bei diesen Begriffen um Nachrichtentechnik und Funksignale geht.

Bandbreite: Ist der Betrag der Differenz von Höchster und Niedrigster Frequenz, die für die Übertragung verwendet wird. Im Fall von OOK ist es mehr als nur die Frequenz die verwendet wird. Man kann kein Signal mit einer einzigen Frequenz senden, man sendet immer mit einem Frquenzband.  Im Fall von OOK sind es ebenfalls einige Kiloherz wie im Falle von FSK. Bei FSK werden die Daten anders Moduliert als bei OOK.

OOK: On Off Keying - Hier wird oft nicht nur off als 0 und on als 1 sondern eine On-Off sequenz für 0 und 1 verwendet. z.b. kurz an lang aus ist 0 und lang an und kurz aus ist 1, oder kurz an lang aus ist 0 und lang an und lang aus ist 1. Hierbei ist sehr viel möglich, jedenfalls sind die On und Off Zeiten für die Dekodierung wichtig. Das Signal hat hier eine Bandbreite von einigen KHz
FSK: Frequency Shift Keying - Hier wird das Signal um eine Mittenfrequenz gesendet. Der "Frequenzhub"  kann hier unterschiedlich angegeben werden, zum einen als Betrag der differenz oder auch durch die Betragsdifferenz zur Mittenfrequenz diese hat dann aber meinst +/- davor stehen. Die Bandbreite ist dann aber auch nicht nur 50kHz bie +/-25kHz Frequenz hub, sondern etwas mehr, da der Frequenzhub zur Mittenfrequenz wieder zur Mittenfrequenz des Signals liegt, das Signal selbst aber wie bei OOK einige kHz Bandbreite benötigt (e.g. 5kHz), da von der Mitte des Signals einmal bei + sowie einmal bei - jeweils die hälfte der Bandbreite rausragt hätte die FSK Modulierung eine Tatsächliche Bandbreite von 55kHz.
Die "FSK-deviation" entspricht dem "Frequenzhub" ist aber nicht die Bandbreite, in deinem Beispiel mit +/-27kHz sind das 54kHz + Signalbandbreite also eher bei 60 kHz

Deutlich Abweichende Frequenzen im SDR zeigen einen systematischen Fehler.
1. Muss man das Signal klar im SDR dargestellt haben und die FSK bzw OOK kodierung sehen (OOK falls zu schnell sieht man nur nach Aufzeichnung und Analyse mit entsprechendem tool)
Die Bilder die ich bis jetzt gesehen habe, sind nicht gerade optimal aufgenommen, zuviel rauschen und eher ein raten ob hier tatsächlich etwas gesendet wird, da völlig übersteuert.
2. Muss man das Original und das immitierte Signal nebeneinander mit dem gleichen Tool darstellen. Falls eine Abweichung im Betrag der Frequenz vorhanden ist, und diese bei beiden auftritt, dann hat SDR einen Offset und der kann ignoriert werden. Ist jedoch eine Unterschiedliche Frequenz zu sehen zwichen Original und Immiatat, dann muss das Immitat korrigiert werdne.
3. Modulation mit tool überprüfen, SDR kann sehr gut Aufzeichen aber die Modulation nicht immer richtig darstellen. Hierbei wieder Original und Immitat direkt vergleichen.

-> diese Vorgehensweise fehlt mir hier, es wird zwar etwas gezeigt, aber nicht beide Signale, eine Abweichung zum Original zeigt meist den Fehler.


Die Darstellung mit Pause/Preamble/Pause/Signal in der Loop wird korrekt sein und wird Aufgrund von möglichen Übertragungsfehlern bei Fernbedienungen immer so gemacht (Es gibt keinen Rückkanal)

Code Auswählen Erweitern

000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48
000000000aaaaaa00369b6da69b49a4936d269b69349b6da6da6934da6db6db6d2

Hier sind Fehler in der Dekodierung vorhanden, ich nehme an, das hat ein Plugin oder ähnliches Dekodiert.

Code Auswählen Erweitern


Falsch:
000000000155555400da6db69a6d26924db49a6da4d26db69b69a4d369b6db6db48


Code Auswählen Erweitern


Richtig:
000000000aaaaaa00369b6da69b49a4936d269b69349b6da6da6934da6db6db6d2

(Das hat plin eben selbst auch bemerkt)

Der Grund ist folgender:

Code Auswählen Erweitern


Pause: 000000000 (Hier wird nichts gesehendet)
Präambel: aaaaaa (Ist meist AA oder 55, ein gleichmässiges toggeln findet man fast überall)
Pause: 00
Code: 369b6da69b49a4936d269b69349b6da6da6934da6db6db6d2


Die Frage ist nur:
Präambel 55 oder AA, dies kann man Aus der Signalform meist sehr gut rauslesen, die Darstellung  in den Screenshots ist aber nicht optimal, ich kann hierbei nicht viel erkennen, ausser dass etwas wiederholt wird.

Eventuell werf ich meinen SDR nochmal an und versuche meine Messung zu wiederholen (Leider ist mir meine Virtuelle Maschine in der ich das gemacht habe gestorben). Mehr dazu Sonntag oder Montag, je nachdem wie ich dazukomme.

[plin]

Code Auswählen Erweitern

[quote author=tux75at link=topic=85006.msg788371#msg788371 date=1522413537]
-> diese Vorgehensweise fehlt mir hier, es wird zwar etwas gezeigt, aber nicht beide Signale, eine Abweichung zum Original zeigt meist den Fehler.

ja klar, mein bisheriges Ziel war es überhaupt mal in der Lage zu sein das Signal der Fernbedienung korrekt aufzuzeichnen und zu analysieren. Die Verwendung des SIGNALduino im OOK-Modus ist für mich eher ein Glückstreffer. Bevor ich da an das FSK-Protokoll rangehe will ich erst mal verstehen was ich senden muss. Die technischen Daten der Komponenten suggerieren halt andere Frequenzen als das was die RTL-SDR nutzenden Tools darstellen.

Wenn ich einen definitven Stand in puncto Original-Komponenten, Frequenzen und Code-Sequenzen habe kann ich mit der Delta-Betrachtung "Was sendet mein S'duino" loslegen.

Apropos Tools: Ist urh die richtige Wahl oder gibt es etwas besseres?

[plin]

Kleine schöpferische Pause, Denkfehler gefunden und gefixt. urh erwartet eine feste Taktung des übertragenen Signals. Folglich muss ich die von S'duino gemessenen Pulslängen (400/800 ms) berücksichtigen und die binären urh-Sequenzen umkodieren:

• 100 (short high, long low) -> Sl => 0
• 110 (long high, short low) -> Ls => 1

Das Ergebnis passt dann wieder zu den bekannten Codes wie z.B. D590E5C 9 F74B7F E
Und die Nibbles 1-8 bleiben bei einem Tastendruck stabil, ändern sich beim nächsten aber wieder.

Interessante neue Erkennntnis: Die Steuersequenz endet hier nicht, sondern es folgt noch ein letztes high bit (400ms high).

Es gilt also nach wie vor mein Leitspruch "aufgeben gilt nicht".

Somit wären korrekte Sequenzen:

Code Auswählen Erweitern

set mySIGNALduino raw SR;;R=8;;P1=15932;;P2=-409;;P3=420;;P4=4014;;P5=-786;;P6=809;;D=1232323232323232323232324532626532626532626262626262626535353532626532653535353532626262653265353535353532653535326532626532653532653535353535353535326262;;

SC ist nicht mehr erforderlich.

[tux75at]

Also das tool "urh" kenn ich nicht, hast du dazu einen link?

Ich verwende gqrx und dann Audacity, wobei ich damals irgendwas noch gemacht habe. Zur zeit hab ich keine Fernbedienung in der nähe und die Wettersensoren sind zu weit weg für eine Analyse, da ist alles zu verrauscht.
Ich hänge einen screenshot an, das Signal scheint ein OOK Signal zu sein, im Waterfall sieht man es inzwischen schon weit unten, kommt sehr regelmäßig (jede Minute) und ist eigentlich schon gegen die Regelung für short range devices (die maximalzahl an Paketen ist zu hoch evtl auch zu lang, aber solang es nichts stört merkt es keiner)
Man Sieht aber sogar Pausen im Signal was auf OOK hinweist und eine eindeutige linie. ich glaub ich hab nichts mit FSK zur hand, und nur eine OOK Fernbedienung, werde aber morgen/übermorgen sofern ich zeit habe noch weiter bilder machen. und versuchen eine kurze anleitung zu erstellen.

[plin]

Hier ist der Link: https://github.com/jopohl/urh. Ist sogar dokumentiert: https://github.com/jopohl/urh/raw/master/data/userguide.pdf

Der Vorteil: urh ist (fast) intuitiv nutzbar und man kommt mit einem einzigen Tool aus. Man kann damit sogar die Bitfolgen analysieren.

[plin]

Der Tag hat gut angefangen. Gestern Abend habe ich in FHEM alle Steuersequenzen auf die neuen Erkenntnisse umgestellt und heute Morgen sind alle relevanten Rolläden nach einem einzigen set-Command hochgefahren (selbst Motor 3). Und das bei max. 10 Wiederholungen.

[plin]

Zum Vergleich jetzt auch die Interpretation des OOK-Signals durch urh als FSK-Signal. Die Strukturen sind identisch.

Dann noch mal die Spektogramme aus Sicht von gqrx. Die Frequenzen sind wie bereits vormals erwähnt verschoben. Die Fernbedienung sendet bei 868.300 MHz +/-23 kHz (hier 868.256). Der S'duino steht auf 868.00 MHz (hier 867.956).

[plin]

Ein paar Tage weiter: ein paar Tests mit dem S'duino, Vergleich mit der Fernbedienung, ein Versuch mit dem S'duino auf 868.323 MHz zu senden (keine Reaktion der Motoren), testweise die Sendefrequenz auf 868.003 MHz erhöht, schien auch Motor 3 auf die Sprünge zu helfen, aber: Up-Commands wurde teilweise als Stop interpretiert ...

Bisher habe ich immer noch nicht die Oberwelle des OOK-Signals gefunden die die FSK-empfangenden Motoren steuert.

Ich denke jetzt über einen Wechsel von OOK zu FSK nach. Mein RF12B funktioniert/sendet, ich habe genug Arduino nanos, ich weiß welche Signalsequenzen ich senden muss, es könnte also losgehen.

Was soll's werden? Sendefrequenz 868,300 MHZ, Frequenzbub +/- 23 kHz, Bitfolge im Bereich 2.500 Baud.

Die Frage ist nur: Mit welchem Ansatz komme ich am schnellsten ins Ziel?

- Arduino nano mit RF12B
- Arduino mit CC1101
- TDK51110 kaufen und den Sender der Fernbedienung nachbauen

Irgendwelche Tipps/Empfehlungen?

[habeIchVergessen]

für einen RFM12 würde ich keine Software schreiben. besser den Nachfolger RFM69CW wählen. wird im JeeLink v3c/LaCross-Gateway verwendet.

[sash.sc]

Wie wäre es auf nen sduino {esp8266} einen cc1101 und ein rfm69cw zu kombinieren?

Gesendet von meinem...... was auch immer

[plin]

Wie wäre es auf nen sduino {esp8266} einen cc1101 und ein rfm69cw zu kombinieren?

Wo ist der Vorteil des rfm69cw? Ich denke der cc1101 kann auch 2-FSK (das ist das was ich senden muss)?

[KölnSolar]

Und wenn Du den CUL nimmst ? Register des CC1101 lassen sich über FHEM-set ändern. Sequenz, Pulsweiten fest verdrahten. z.B. als IT device und Code in der Clib/intertechno.c Funktionsaufruf: it_send
Grüße Markus