Wh40 - rain drop sensor about rffhem HOT 11 CLOSED

@elektron-bbs
@HomeAutoUser

Ich bräuchte ein wenig Hilfe mit den Registern. Eventuell passt Syncword oder Länge nicht ganz. Ich vermute es ist aber nur eine Kleinigkeit

from rffhem.

Empfängst du denn von dem Sensor irgend etwas?
Syncword und Datenrate sollten eigentlich passen. Die Paketlänge ist erstmal nebensächlich, im Quellcode werden 9 Byte verwendet.

Bist du sicher, das der Sensor auf 868 MHz sendet? Das Teil gibt es ja auch wie den WH31 für 433, 868 und 915 MHz.

Ansonsten vielleicht mal die Bandbreite auf max stellen, evtl. liegt ja der Sensor oder der CC1101 etwas daneben.

from rffhem.

Im Moment empfange ich nichts und wusele mich durch die cc1101 Register durch.

Ich blicke da nicht ganz durch, aber meiner Meinung nach, stehen die Register auf einer fixen Paketlänge:

0x06: PKTLEN hat den Wert 0x04 => 14 Byte
0x08 PKTCTRL0 hat den Wertr 0x00 => Fixed packet length mode. Length configured in PKTLEN register
0x03 FIFOTHR hat den Wert 0x43 => 16 Bytes in RX_FIFO

Demnach würden nur 14 Byte Lange Nachrichten akzeptiert werden. Was länger ist, sollte verworfen werden und der FIFO melded das Erreichen des Schwellwertes sobald 16 Bytes in ihm stecken.

Kannst Du bei dir ein cc1101_reg 1200 absetzen? Wenn nein, dann habe ich einen Bug gefunden....

from rffhem.

Register setzen geht:

ccreg: 

Configuration register detail:
------------------------------
add.  name       def.   cur.
0x12  MDMCFG2  - 0x30 - 0x00

Demnach würden nur 14 Byte Lange Nachrichten akzeptiert werden. Was länger ist, sollte verworfen werden und der FIFO melded das Erreichen des Schwellwertes sobald 16 Bytes in ihm stecken.

Nicht ganz. Sobald die feste Paketlänge erreicht ist, wird an GDO0 signalisiert, das die eingestellte Anzahl Bytes empfangen wurde. Dann holen wir den Puffer ab.
Ich habe das vorhin zufällig durchprobiert, als ich die Register für den WH31 geändert habe.
Gesendet habe ich 0x3024826E174FAA00000000000000000000000000
empfangen habe ich 0x3024826E174FAA
Also genau die Bytes, die wir für den Sensor benötigen. Der Rest danach interessiert uns nicht. Wahrscheinlich sind das dann auch irgendwelche zufällig eingetrudelte Bits, wie hier in den Nachrichten aus dem Quellcode:

30c3820a5edfbc0756a7ae00000000
3044921a395ab30745045f00000000
30c381d55c2acf0835442c
3035c22f3c0fa10752299f
3035c22e3cfb8c0752299f
30c9a21e400c050734c6b1
302bb2143d94f2085378e6
30c9a21f40f8f20734c6b1
304492133e0e650745045f
304492153d075f0745045f
30c381d65b90350835442c
300282603A91DF6C000200000BB8

from rffhem.

Ich habe mal das cc1101 Modul gewechselt. Empfange jetzt

2023.04.02 20:08:22.770 5: signalESP: dispatch P112#40013E3490220121

from rffhem.

Das sieht doch schon gut aus. Für den WH40 brauchen wir aber 9 Byte. Du hast wahrscheinlich Packet Length auf 8 eingestellt.

from rffhem.

Ja stimmt. Ich habe den Schwellwert auf 8 gestellt. der hat aber 14 Byte, auch wenn wir die Bedeutung letzten 5 nicht ablesen können.

from rffhem.

Ich empfange: sduinoESP: Read, msg: �MN;D=40011CDF8F0000976220A6802801;R=61;
Der Aufkleber auf dem Gerät sagt ID: 11CDF

from rffhem.

Na, das passt doch. Laut Quellcode haben die als ID allerdings nur 4 Nibble verwendet:

    YY 00 IIII FF RRRR XX AA 00 02 ?? 00 00

- Y is a fixed Type Code of 0x40
- I is a device ID
- F is perhaps flags, but only seen fixed 0x10 so far
- R is the rain bucket tip count, 0.1mm increments
- X is CRC-8, poly 0x31, init 0x00
- A is SUM-8

Das wäre dann die Nachricht: 40011CDF8F00009762 20A6802801
Ob die letzten 5 Byte eher Zufallszahlen sind, kannst du nur beobachten.

from rffhem.

Ich werde das gleich mal als Protokoll 126 definieren. Aber wie ich den Regenwert prüfe ob er stimmt weiss ich noch nicht

from rffhem.

Ich denke doch, das die 0,1 mm aus dem Quellcode passen:

"rain_mm", "Total Rain", DATA_FORMAT, "%.1f mm", DATA_DOUBLE, rain_raw * 0.1,

Das kannst du dann nur mit örtlichen Wetterstationen vergleichen.
Oder du berechnest die Fläche der Öffnung und tröpfelst dann z.B. mit einer Spritze Wasser rein, bis die Wippe kippt.

from rffhem.