Hi,
ich versuche gerade, das Protokoll der 30.3180.IT-Sensoren von TFA
Dostmann zu reverse engineeren. Ist eine kleine Wetterstation mit bis zu
8 Funksensoren. Im Gegensatz zu anderen bereits mit dem RFM12b
"erschlagenen" Sensoren aus der IT+-Reihe ist über die wohl noch nichts
bekannt. Leider sind die HF-Chips alle direkt auf die Platine gebondet,
sonst wäre es auch einfacher ;) Basisfrequenz ist jedenfalls die übliche
868.300MHz.
Ich habe es geschafft, das FSK mit einem SA mit 30kHz RBW auf 868.25MHz
zu demodulieren (hab sonst nix da...). Das Ergebnis sieht man oben in
gelb. Damit ergibts sich die Bitrate schon mal bequem als ca.
38.8kbit/s. Die anderen Sensoren haben AFAIK 17 bzw. 9kbit/s. Zunächst
gibts eine Menge Pulse zur Eintaktung (ca. 4ms, also >150Bits), dann
kommt 0100 1011 1101 0100. Der Cursor 2-1 zeigt auf die ersten 8 Bits.
Das entpricht invertiert und pro Byte revertiert dem üblichen
RFM12-Syncpattern 2d d4. Ich habs dann auf Papier weiter dekodiert, es
folgen die 16Bit-ID des Senders (steht auch hinten drauf), Temperatur,
Feuchtigkeit und noch ein paar Bytes, das letzte vermutlich CRC oder
sowas. Mit dem Sync-Pattern sind es insgesamt 11 Bytes.
Sieht dann mit der ID 3bae, 26.1Grad und 40% Feuchtigkeit so aus:
Das Problem ist, dass das dem RFM12b ums Verrecken nicht beizubringen
ist. Wie man an DATA (=cyan, DCLK lila) sieht, ignoriert er alle kurzen
1-Impulse schon im ersten Sync-Pattern. Ich habe viel mit AFC, drssi&Co
rumgespielt, es wird einfach nix.
Da stellen sich mir mehrere Fragen:
- Das Eintaktungsschema sieht auf 868.350 genauso aus. Ich vermute mal
dass es kein 01-Wechsel in FSK ist, sondern nur auf f0 gesendet wird.
Dem SI4420-DB nach wäre das dann eher unpassend und könnte die
Synchronisationsprobleme erklären... Oder gäbe es noch eine andere
Erklärung für das Aussehen nach der Demodulation für Arme via SA?
- Im DB wird nicht genau erklärt, welche Bitreihenfolge empfangen wird.
Das beim Senden sieht so aus, als wäre das MSB des Datenworts auch das
erste, das gesendet wird. Passt mit der Revertierung oben eigentlich
auch nicht zusammen.
- Beim Senden kann man die Modulation invertieren, was macht eigentlich
der Empfänger damit? Wird da auch das invertierte Sync-Pattern
korreliert? Steht auch nicht im DB...
Oder andersrum: Kennt jemand ein Funkmodul/Chip, der obiges Protokoll
empfangen könnte, wenn möglich nicht RTL-SDR ;)
Nachtrag: Der RF-Chip auf dem Sensor nutzt einen 16MHz-Quarz, damit
fallen Si4420/30 schon mal raus...
Sagen wir mal so... ich ahne, welcher TX/RX in der Sensoren verbaut sind
(das Layout samt Quarz passt exakt zu einem Demo-Layout), allerdings
gibt es keine Infos dazu.
Abgreifen der SPI-Signale in der Station wäre zwar eine Möglichkeit, die
Daten rauszubekommen. Das geht dann aber wohl auch nur bis 8 Sensoren,
weil der RX ausserhalb der Lernphase immer passend eingeschaltet wird.
Ziel ist also schon, einen unabhängigen Empfänger zu nutzen. Dazu muss
ich aber noch mehr Eigenschaften rausbekommen. Ich weiss immer noch
nicht, wie die vielen Sync-Bits real aussehen, muss da wohl echt mal mit
einem SDR ran.
Ist aber eben nur ein Nebenprojekt ;)
Hallo Georg,
ich hatte das mal vor einem Jahr mit einem RTL-SDR versucht und anhand
dessen einige Aufnahmen gemacht und das Signal"dekodiert". Allerdings
bin ich nur einfacher Softmatiker und verstehe weder das RTL-SDR noch
irgendetwas von dem Senden/Empfangen der Daten. Helfen Dir dazu RTL-SDR
Sceenshots/Aufnahmen weiterzukommen? Ich kann dazu gerne meine
weitergeben. Ich bin sehr daran interessiert diese Sensoren mittels
einer kleinen Software/Hardware real-time abfragen/auswerten zu können.
lg
Berni
Uiuiui, ist das schon lang her ;)
Aber falls es noch jemanden interessiert: Ich habe das Protokoll jetzt
"durch", es wird mit einem SDR-Stick eingelesen und dekodiert. Der RFM12
(und vermutlich viele andere dieser Module) kann es prinzipiell nicht
dekodieren. Es ist zwar FSK als Modulation, die Sensoren kodieren die
Bits aber mit NRZS statt NRZ. D.h. eine 0 sorgt für einen Wechsel der
Frequenz, eine 1 nicht. Damit geht beim RFM12 natürlich schon die
Synchronisation daneben.
Als Basis wird die libsdr-rtl genommen, es läuft damit "out-of-the-box"
unter Linux und Mac, auf Windows bekommt man es sicher auch hin.
Zur Empfindlichkeitssteigerung wird mit 4xDownsampling gearbeitet, damit
ist es mit R820T-Sticks gefühlt deutlich empfindlicher als die originale
TFA-Basisstation. Kostet dafür etwas CPU, aber selbst der Raspi3 schafft
das mit nur 60% auf einem Kern. Und dauernd laufen muss es ja ohnehin
nicht.
Vorteil: Im Gegensatz zum System mit der TFA-Basisstation und maximal 8
Funksensoren kann man beliebig viele Sensoren betreiben. Die Basis kann
man aber auch natürlich weiternutzen.
Ich stricks noch etwas schöner, dann gibts hier einen Link auf github
(vermutlich nächste Woche).
Hallo Georg,
ich habe mich die letzten paar Abende zufällig ebenfalls mit dem Sensor
und einem RFM69CW als Empfänger gespielt, aber natürlich keine
brauchbaren Ergebnisse zusammengebracht und bin natürlich gespannt auf
deine Erkenntnisse! :)
Falls das Auslesen mit einem SDR-Stick funktioniert wäre ich da sehr
glücklich darüber, da ich 6 von diesen Teilen herumstehen habe!
gr schrieb:> Falls das Auslesen mit einem SDR-Stick funktioniert wäre ich da sehr> glücklich darüber, da ich 6 von diesen Teilen herumstehen habe!
Dem schließe ich mich an. Ich habe hier zar nur zwei 30.3156.WD und
einen R820T-Stick sowie div. Rechner, auf denen (u.a.) Linuxe laufen,
finde diese Variante aber interessanter als das Herumgebastel mit einem
RFM12, und würde mir die SDR-Toolchain angewandt auf einen der
TFA-Sensoren deswegen gerne mal anschauen.
Ich glaube eher nicht, dass andere Sensoren mit dem Code gehen. Gerade
wenn sie mit dem RFM12/69/JeeLink-Stick laufen, sind sie ja wieder NRZ
und nicht NRZS wie die KlimalogPro-Sensoren. Ich habe den Code jetzt
auch recht stark auf die Anwendung optimiert, damit der Raspi3 auch
damit zurechtkommt. Allerdings kann ich ja auch nochmal ein paar andere
Sender kaufen und in den Code einbauen. So ein DVB-T-Stick ist mit 12EUR
ja auch billiger als ein (Original)JeeLink.
Inzwischen habe ich hier 16 Sensoren am laufen, da brummts ganz schön im
Äther ;)
Mein Kollege baut auch noch was zum Eintragen der Daten in eine MySQL-DB
und ein einfaches Webinterface zur Ausgabe der Kurven dazu, quasi ein
Ersatz für die TFA-PC-Software. Wobei es im Gegensatz dazu natürlich
keinen Zwischenspeicher in der Basisstation gibt, falls der PC mal aus
ist. Aber wer macht den sowas...
FHEM/etc-Integration habe ich jetzt nicht, sollte aber kein grösseres
Problem sein, mein Tool kann für jedes empfangene Telegramm ein Programm
aufrufen, dass sich dann um den Rest kümmert.
Die RF-HW der Sensoren ist übrigens ein Chip von Axsem (jetzt ON), Typ
hab ich vergessen. Vor der Übernahme gab es auf deren Seite jedenfalls
ein Layout-Beispiel, dass dem in den Sensoren nahezu 1:1 entsprochen
hat. Alle anderen Chips (TI, NRF, Atmel, etc.) haben nicht gepasst.
Ich möchte das Thema gerne nochmal hochholen. Habe wie andere auch
versucht, das Signal von Klimalogg Sensoren mit einem RFM69 zu
empfangen. Dazu habe ich den RFM auf die Trägerfrequenz, Bitrate und
Deviation eingestellt und Continuous Modus ohne Bit Synchronizer
gewählt. Es ging also erst mal darum, das rohe Signal hinter dem FSK
Demodulator per Oszi zu begutachten.
Das hat auch funktioniert, ich konnte das gesamte Signal mehr oder
weniger sauber einfangen - allerdings nur bei einem Abstand von Sensor
zu RFM von < 1m. Außerdem fiel auf, dass schon die Pulse der Präambel
einen ziemlich Jitter haben. Es scheint also, dass der Empfang mit einem
RFM tatsächlich nicht möglich ist. Die Frage wäre warum, was ist das
Besondere an dem Signal? Ob es NRZ oder NRZS ist, spielt auf dieser
Ebene doch IMHO noch ger keine Rolle. Kann mir jemand auf die Sprünge
helfen?
Hallo Jochen
Ich wäre ebenfalls daran interessiert, die 30.3180.IT-Sensoren mit einem
RFM69 zu empfangen. Und ich teile deine Meinung, dass der Empfang von
NRZS-Signalen im Continuous Mode möglich sein sollte.
Daher habe ich meinen RFM69HW zunächst mal mit einem Raspberry Pi in
Betrieb genommen und versucht, im Continuous Mode den empfangenen
Datenstrom an DIO2 (Data) am Oszi anzuzeigen.
Leider ohne Erfolg. Ohne setzen eines RSSI-Thresholds werden ständig
irgendwelche "Daten" empfangen. Ich denke, es handelt sich dabei um
Rauschen (die RSSI-Werte liegen dabei laut RFM69 bei ca. -73dBm). Wenn
ich denn RSSI-Schwellwert (RegRssiThres) höher setze (z.B. -50 dBm)
empfange ich nichts; auch dann nicht, wenn ein Sender direkt neben dem
RFM69 liegt.
Meine Einstellungen:
* Sequencer: off
* DataMode: Continuous without bit synchronizer
* Modulation Type: FSK
* Bitrate: 38.4 kb/s
* Frequency deviation: verschiedene Werte getestet: 5 kHz, 15 kHz 30 kHz
* Carrier Frequency: 868.25 MHz
* LnaZin (LNA input impedance): 50 Ohm
* LnaGainSelect: highest gain -48 dB (habe aber auch andere Werte
versucht)
* RxBwMant: 24; RxBwExp: 2 => RxBw=83.3 kHz
* DccFreq: 2 (default => 4% of RxBw)
@Jochen: Wie ist es dir gelungen Signale zu messen? Hast du inzwischen
Fortschritte bei dem Vorhaben gemacht?
Die Frequency Deviation sollte bei 15 kHz liegen, richtig?
Thread beobachten
Seitenaufteilung abschalten