SIGNALDuino - Analyse unbekannter Funkprotokolle

[tux75at]

Das wasserfalldiagram, ich nehme an in der Mitte ist zu Beginn am interessantesten. Dort wird das Spektrum permanent nach unten geschoben. Blau schwach bis rot oder weiß stark. Die Limits in dB kann man sicher einstellen und das hast du scheinbar gemacht. Vorher war es uebersteuert und dann eher schon zu dunkel, aber ich erkenne auch nichts in dem Diagramm(die Bilder sind am Handy evtl zu schwach aufgelöst ). Wenn das Signal in der Mitte permanent da ist, dann musst du etwas ähnliches suchen, das beim betätigen kommt und dann wieder weg ist. Auf das Signal musst du dich konzentrieren und am besten aufnehmen. Für Linux (evtl auch Windows) gibt es Programme mit denen du den zeitlichen Verlauf ansehen kannst. Wichtig ist die samplerate bei der Aufzeichnung. Hat bei mir super geklappt für einen garagentoröffner.

Gesendet von meinem E5823 mit Tapatalk

[plin]

Aktueller Stand: gefrustet. Seit dem Wochenende versuche ich mit den diversesten Tools eine FSK-Demodulation hinzukriegen, um das Raster von Sync/Codes auszulesen und die Wiederholungsraten zu ermitteln.

Windows
- SDR# - Wie geht's weiter?
- sigmira - couldn't open rtl-sdr, die mitgelieferten Treiber mag mein Win10 aber nicht

Linux
- rtl_fm/multimon-ng - braucht genau abgestimmte Parameter zwischen den beiden Tools
- gqrx - Zeichnet etwas auf, aber wie kann ich daraus FSK auslesen, Audacity wäre ein Ansatz
- rtl_rfm - gibt nur im Debug-Mode output aus
- gnuradio-companion - nicht intuitiv nutzbar

Nächste Idee: Vom TDA5210 die Signale abgreifen und mit einem Arudino oder Wemos D1 aufzeichen. Aber womit? Hat jemand einen passenden Sketch?

Anregungen sind wie immer willkommen 

[habeIchVergessen]

SIGNALduino gibt es auch für RXBx Hardware. die benutzt stumpf ein GPIO-Pin für den Empfang.

[plin]

SIGNALduino gibt es auch für RXBx Hardware. die benutzt stumpf ein GPIO-Pin für den Empfang.

Genau daran einen GPIO-PIN des Arduino zu versorgen (ggf. mit Spannungsteiler, Stromversorgung aus Powerpack wg. galvanischer Entkopplung) habe ich gedacht. Mir fhelt nur der passende Sketch. Ich brauche den jeweiligen Signalpegel =/1 und den Timestamp.

[habeIchVergessen]

schau mal im FHEM-Verzeichnis nach FHEM/firmware/SIGNALduino_nano328.hex
GPIO2 sollte recv-Pin sein

[plin]

Ein GPIO-Pin des Raspi wäre auch eine Möglichkeit. Den könnte ich über den gpio-Command auslesen. Der TDA5210 scheint lt. Oszi aber nur 0,4 Volt zu liefern, da muss also noch ein Transistor ran.

[KölnSolar]

SIGNALduino gibt es auch für RXBx Hardware. die benutzt stumpf ein GPIO-Pin für den Empfang.

Das versteh ich jetzt gar nicht. Wie soll ein anderer Funkempfänger als CC1101 die FSK-Signale besser/richtiger empfangen 

Nächste Idee: Vom TDA5210 die Signale abgreifen und mit einem Arudino oder Wemos D1 aufzeichen. Aber womit? Hat jemand einen passenden Sketch?

Das versteh ich schon eher. Aber einen Sketch kenne ich auch nicht.
Aber: Ich hab zwar kein Oszi und auch keine Ahnung von den Dingern, aber ich hätte jetzt schon erwartet, dass man die Pulsweiten am Oszi ablesen/auswerten kann 

Ich hab mal mit der Soundkarte am Mikrofoneingang die FB bei 433MHz und OOK analysiert. Das hat eigentlich recht gut geklappt, weil das Signal aufgezeichnet wird und man danach analysieren kann. Allerdings war das natürlich viel einfacher, weil ich nur an/aus erkennen musste. Ob das bei FSK genauso klappt ? Und wie ich es genau gemacht hatte, weiß ich leider auch nicht mehr. Stand irgendwo hier im Forum. Und zu 95% bin ich mir sicher, dass ich Audacity dafür benutzt hatte.
Vielleicht hilfts 

[plin]

Aber: Ich hab zwar kein Oszi und auch keine Ahnung von den Dingern, aber ich hätte jetzt schon erwartet, dass man die Pulsweiten am Oszi ablesen/auswerten kann 

Man kann die Pulsweiten auf dem Oszi erkennen. Aber das ist nicht mein Problem (ich denke die vom S'duino ermittelten Pulsweiten sind schon rechtepassend).
Das Signal setzt sich aus
1. Pause von ca. 16 ms (P1=16.000)
2. Preamble von low/high-Folgen (23232323 mit P2=-398;P3=412)
3. Pause von 4 ms (P4=4.000)
4. 64 Bits Signalcode (1-n Mal gesendet)
zusammen.

Die allerersten Analysen haben gezeigt, dass der Signalcode mehrfach gesendet wird. Ich kenne aber nicht die Anzahl der Wiederholungen.  Aktuell wiederhole ich den Block 3+4 n-fach und habe damit relativ gute Ergebnsse erzielt, aber 2 Motoren arbeiten immer noch nicht zuverlässig.  Der eine reagiert gerne bei 50 Wiederholhen (a 90 ms = 4,5 Sekunden, halte ich für ziemlich lang). Das Oszi hat keine Lupenfunktion mit der ich beliebig nach rechts fahren kann, um Wiederholungen zu erkennen. Deshalb der alternative Weg.

Edit: Die Analog-Input-Schleife am ArduinoNano ist zu langsam und ich kann keine Reaktio auf's senden beobachten.

[KölnSolar]

Der eine reagiert gerne bei 50 Wiederholhen (a 90 ms = 4,5 Sekunden, halte ich für ziemlich lang).

Find ich auch. Viel zu lang. Dürften eher max. 5 sein. Das Verhalten erklär ich mir eher dadurch, dass das Signal nicht sauber genug ist und irgendwann klappt es halt.(wundert mich dann nur, wie das mit der Präambel dann noch zeitlich passt).

Die Wiederholungen könntest Du evtl. per nanoCUl ermitteln. Dort hast Du die Möglichkeit empfangene Daten mit steigender und fallender Flanke anzusehen. Auf den ersten Blick arg kryptisch. Um die Anzahl der Pulse zu zählen aber wahrscheinlich gar nicht so verkehrt. Zumal ich gerade gesehen habe, dass nach einer Pause von 4ms ein neuer Datensatz erkannt wird. Das würde ja zu Schritt 3 gut passen.

[plin]

Ich habe heute Abend noch mal Sequenzen bei 868.275 MHz/58 kHz/ sens 8dBm mitgeschnitten. Mal schauen wie die diese Nacht funktionieren. Ich komme bei denen mit R=8 aus.

[plin]

neue Theorie wieso Motor 3 Morgens/Abends nicht reagiert, wohl aber wenn ich diverse Codes durchgetestet habe: Temperatur Drift

Das Data Sheet des CC1101 sagt: "The module central frequency will change as the operating temperature change, use it under suggest temperature, the module can work well."
Ein anderes Dokument sagt: "The frequency error or drift is due to crystal inaccuracies. This requirement is therefore a test of  the  crystal  used  and  not  covered  in  this 
application  note. "

Die Frequenz im kalten Zustand gefällt den Motoren 1, 4, 5 und meistens 6. Motor drei benötigt eine leicht andere Freuqenz (man erinnere sich: die FB/Motoren arbeiten eigentlich mit FSK auf ca. 868.300MHz/25 kHZ Hub, der S'duino kann sie mit 868.000MHz/OOK ansteuern).

Also brauche ich jetzt einen kalten S'duino, die bei 868.275MHz gefundenen Code-Sequenzen und einen leichten Frequenz-Hub beim Senden auf ca. 868.000MHz.

[tux75at]

neue Theorie wieso Motor 3 Morgens/Abends nicht reagiert, wohl aber wenn ich diverse Codes durchgetestet habe: Temperatur Drift

Das Data Sheet des CC1101 sagt: "The module central frequency will change as the operating temperature change, use it under suggest temperature, the module can work well."
Ein anderes Dokument sagt: "The frequency error or drift is due to crystal inaccuracies. This requirement is therefore a test of  the  crystal  used  and  not  covered  in  this 
application  note. "

Die Frequenz im kalten Zustand gefällt den Motoren 1, 4, 5 und meistens 6. Motor drei benötigt eine leicht andere Freuqenz (man erinnere sich: die FB/Motoren arbeiten eigentlich mit FSK auf ca. 868.300MHz/25 kHZ Hub, der S'duino kann sie mit 868.000MHz/OOK ansteuern).

Also brauche ich jetzt einen kalten S'duino, die bei 868.275MHz gefundenen Code-Sequenzen und einen leichten Frequenz-Hub beim Senden auf ca. 868.000MHz.

Kannst du etwas breitbandiger senden? Der temperaturdrift kann am besten über ein breitbandigeres Signal korrigiert werden. Bei OOK geht es um Signal ja/nein im empfangsmodul. Das Signal wird vorher bandbegrenzt. Wenn ich breitbandiger sende, dann müssten alle etwas empfangen.

Gesendet von meinem E5823 mit Tapatalk

[plin]

"etwas breitbandiger senden" ist gut gemeint. Ich sende nominell auf 868.000 MHz OOK. Der TDA5210 sollte aufgrund des 6.7 MHz Quartzes auf 868.300 MHz FSK empfangen, lt. Datenblatt +/- 50 kHz. Die RIO-Fernbedienung sendet lt SDR-Stick mit einer Bandbreite von +/- 23 kHZ. Erste Analysen mit 2 S'duinos haben gezeigt, dass der zweite bei ca. 868.325 MHz eine Oberwelle des ersten empfängt (siehe https://forum.fhem.de/index.php/topic,85006.msg782882.html#msg782882). Würde also zu vorgenannten Eckdaten des TDA5210 passen.

Ich habe jetzt zwei Testreihen mit meinen beiden S'duinos und dem SDR-Stick hinter mir. Mit gqrx habe ich die empfangene Frequenz so präzise wie möglich auf den Peak eingestellt. Zwei identische Sequenzen a 22 Commands mit je 20 Wiederholungen des Codes (=ca. 2 Sekunden senden, gefolgt von 8 Sekunden Pause) führen zu folgender Erkennntis:
- Test-S'duino: Start 867.955,400 MHz - Ende 867.956,060 MHz -> wandert 660 kHz aufwärts
- Prod-S'duino: Start 867.953,000 MHz - Ende 867.952,670 MHz -> wandert 330 kHz abwärts
Die scheinen also unterschiedlich auf den Betrieb zu reagieren.

Die Erwärmung und damit abweichende Frequenz erklärt dann auch folgende subjektive Beobachtungen:

• Die Qualität der Steuerung hängt von dem im ROLLO-Modul angegebenen async_delay ab. Ist aktuell auf 30 Sekunden eingestellt. Das gibt dem CC1101 wohl Zeit wieder etwas abzukühlen, denn kürzere Abstände führen zu schlechteren Ergebnissen.
• Motor 3 reagiert zunächst nicht auf neu mitgeschnittene, als formal brauchbar befundene Code-Sequenzen. Probiere ich die der Reihge nach durch, spricht er irgendwann an.
• Gefundene gute Sequenzen fünktionieren Morgens/Abends auf einmal nicht mehr. Wenn ich auf Dauerbrenner gehe (30-50 Wiederholungen) reagiert der Motor besser.

Wie geht's weiter? Lt. Datenblatt hat der CC1101 einen "Integrated analog temperature sensor". Vielleicht kann man über ein Register die Temperatur auslesen und die Sendefrequenz dann entsprechend anpassen.

[tux75at]

Du hast dir die Antwort fast selbst gegeben "Integrated ANALOG temperature sensor".
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.

Temperatur Drift:
Es gibt einen Drift, aber der ist, solang der CC1101 kalibiert ist nicht nennenswert, ausser du hast dramatische Temperaturänderungen oder VCC Änderungen. (Sec. 22.1)
Falls die Selbstkalibrierung nie gemacht wurde, gibt es natürlich stärkere Abweichungen und eventuell auch heftigere Drifts.

The calibration can be initiated automatically
or manually. The synthesizer can be
automatically calibrated each time the
synthesizer is turned on, or each time the
synthesizer is turned off automatically. This is
configured with the MCSM0.FS_AUTOCAL
register setting. In manual mode, the
calibration is initiated when the SCAL
command strobe is activated in the IDLE
mode.

Schau mal nach was in dem Register steht, bzw reingeschrieben wird.

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)

Die Abweichungen bei deinen Tests sind zum Glück keine kHz sondern nur Hz, ansonsten würde garnichts gehen. Drift muss weitaus kleiner sein als die Bandbreite ansonsten gibt es massive Probleme. Ein Drift um 660kHz ist wohl nur ein Tippfehler.


Interessant wäre ein Bild des Spektrums wenn dein Signal nicht geht und der direkte Vergleich mit der funktionierenden Original FB. Wenn der Drift soviel ausmacht, dann müssten die Signale nebeneinander liegen, bzw kaum überlappen und genau in diese Richtung musst du nachjustieren. Aber bitte die Bilder zur gleichen Zeit erstellen, da der Temperaturdrift bei beiden Geräten vorkommt und ein Vergleich mit anderen Temperaturen dann nichts mehr aussagt.

[KölnSolar]

Tests sind zum Glück keine kHz sondern nur Hz,

Sehe ich auch so, und dass die das ganze ins Wanken bringen sollen  OK, wir reden nach wie vor von einem OOK-Sender u. einem FSK-Empfänger. Dass das überhaupt klappt...

MCSM0.FS_AUTOCAL=01b=When going from IDLE to RX or TX (or FSTXON)

Problematik also bei Dauerfeuer(so sehe ich 2sek permanentes Senden). Heißt aber doch nur, dass Du mit der Freq. je nach S'duino etwas runter oder rauf müsstest

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