RainPoint 433 Sensor decodieren?

[Stefan S. (kami)]

Hallo,

ich habe hier einen 433Mhz RainPoint Bodenfeuchte und Temperatursensor. 
Leider habe ich im Inet noch keine Decodierung zu den Signalen gefunden. 
Ich taste mich gerade zum erstmal selber daran. Der Sensor hat 3 Kanäle 
und liefert Tempwerte von -10 -> 50 °C und Feucht von 0-100%.
Laut Datenblatt RF433,92 Mhz ASK

Ich habe mal mit dem Wasserfall Diagramm die Nachrichten aufgenommen.

Wenn ich das Bild richtig deute ist das ein PWM Signal. Er steht auf 
Kanal 2 und sendet mehrfach immer diese NAchricht. Er liegt im Raum 
keine Feuchtigkeit vorhanden und Temperatur bei circa 23°C.

Kann mir jemand weiterhelfen, wie ich das decodiere?

Danke Gruß kami

[Georg A. (georga)]

Schau mal ob rtl433 damit was anfangen kann:

https://github.com/merbanan/rtl_433

Da steht jetzt zwar nix von Rainpoint, aber vermutlich ist das im 
Original was anderes (wie zB. TFA meistens was von LaCrosse ist).

[Stefan S. (kami)]

Hi,

danke das habe ich schon probiert. Leider ist der Sensor darin nicht 
gelistet. Hat jemand eine Ahnung wie man das Decodiert? Kann auch gerne 
mehr Daten liefern.

Gruß kami

[Georg A. (georga)]

Naja, rumprobieren und kniffeln... Man könnte mal so anfangen:

__ oder -- = 0
-_ oder _- = 1

Oder auch invertiert ;)

Gern gibts am Anfang neben einigen 1en auch eine Sync-Sequenz ala 2d d4, 
am Ende ist eigentlich immer eine CRC. Wenn du die Daten anderweitig 
auslesen kannst, lohnt es sich, mal die Werte gezielt zu ändern (+-0.1, 
etc.). Die Temperatur ist aber oft mit Offset und Faktor versehen, die 
man erstmal rausfinden muss. Die Luftfeuchtigkeit ist meistens "roh", da 
sieht man besser, ob es passt. Da es eigentlich nie "trailing bits" 
gibt, kann man von hinten her versuchen, die Bytegrenzen festzulegen.

[Wolfgang (Gast)]

Stefan S. schrieb:
> Wenn ich das Bild richtig deute ist das ein PWM Signal

Bestimmt nicht.
PWM ist ein Analogsignal (zeitkontinuierlich), bei dem die Pulslänge 
jedes Einzelpulses den Wert enthält. Du siehst ein Digitalsignal (kurze 
und lange Pulse), bei dem irgendwie Bits übertragen werden.

Dein Bild zeigt auch kein Wasserfalldiagramm. Bei einem 
Wasserfalldiagramm werden viele Datentelegramme gegen die Zeit 
dargestellt.
Dein Bild zeigt ein einzelnes Datentelegramm.
Erwärme den Sensor gleichmäßig und zeichne mit einem Logikanalysator 
auf, wie sich dabei das Telegramm verändert. Damit bekommst du den 
ersten Anhaltspunkt für die Kodierung.

[Wolfgang (Gast)]

Georg A. schrieb:
> Gern gibts am Anfang neben einigen 1en auch eine Sync-Sequenz ala 2d d4

Erstmal kommt eine Sequenz mit schnellen Wechseln, damit sich der 
Empfänger einpegeln kann (vermutlich die Anfangsfolge mit den 15 kurzen 
Pulsen). Der erste lange Low-Pegel ist die Markierung fürs 
Synchronisieren. Erst danach können irgendwelche Bits sinnvoll 
zugeordnet werden.

[Kai B. (kaib)]

Die Daten sind wohl Manchester codiert. Sieht zumindest ähnlich wie bei 
Sensoren von Oregon Scientific aus welche auch ihre Daten als Manchester 
Code übertragen.
Ich habe das hin und wieder schon von Hand gemacht in dem ich in Gimp 
über die Daten ein Gitter gezogen habe und dann anhand des 
Taktes(Gitter) die 1/0 Bits aus gelesen.

Hilfreich zum Decodieren ist es wenn man ein paar verschiedene 
Datensätze und die passenden Messwerte kennt. da lassen sich die Daten 
dann untereinander Darstellen was es einfacher macht herauszufinden 
welche Bits sich Ändern und welchem Wert diese entsprechen könnten.

Manche Sensoren übertragen dann Quasi Klartext als BCD Code(manchmal 
auch in umgekehrter Reihenfolge wie z.B: bei den Oregon Sensoren) oder 
als Bit Wert 1110 1010 = 234 = 23,4°C

[Georg A. (georga)]

Wolfgang schrieb:
> Georg A. schrieb:
>> Gern gibts am Anfang neben einigen 1en auch eine Sync-Sequenz ala 2d d4
>
> Erstmal kommt eine Sequenz mit schnellen Wechseln, damit sich der
> Empfänger einpegeln kann (vermutlich die Anfangsfolge mit den 15 kurzen
> Pulsen). Der erste lange Low-Pegel ist die Markierung fürs
> Synchronisieren. Erst danach können irgendwelche Bits sinnvoll
> zugeordnet werden.

Der erste Low-Pegel ist nicht die Markierung, er gehört dazu (kleiner 
Unterschied). Beim Empfänger landen die dekodierten Bits ja in einem 
Schieberegister (meistens sogar von rechts nach links wie sie auch 
gesendet wurden) und wenn das dann einen magischen Sync-Wert aufweist, 
ist die Justierung auf Bytegrenzen gelungen.