FSK mit dem SIGNALDuino

hofy · 31 Mai 2021, 21:40:45

Ok, dann bleibe ich mal auf meiner Firmware.

Das mit dem Test ist nicht ganz so einfach, da ich noch nicht weiss wie ich mit dem SIGNALduino vom Haus weglaufen soll ...
Welchen Wertebereich hat denn das Register 0x13 und in welchen Schritten sollte es hochgehen?

Dann sehe ich noch das du Register 0x23 bis 0x26 setzt.
Was ist denn hier die Bedeutung und hält du die für relevant?
Die setzten wir aktuell garnicht und diese weichen auch vom Default ab.

Ralf9 · 31 Mai 2021, 22:07:19

Wenn das Senden auch durch Wände und Decken zuverlässig funktioniert, dann müsste Register 0x13 zu passen. Per Default werden 4 preamble Byte gesendet.

Die 0x23 bis 0x26 sind bei den meisten FSK Protokollen gleich , ich hab sie, glaube ich, vom cul übernommen, ist wahrscheinlich nicht relevant ( Frequency Synthesizer Calibration)

hofy · 01 Juni 2021, 22:01:36

Ok.

Dann glaube ich haben wir erstmal eine Konfiguration die recht gut funktioniert.
Ich würde dann erstmal nichts weiter testen.

Ich denke wir werden in dem anderen Thread noch daran arbeiten GFSK stabil zu bekommen,
damit man dauerhaft auf 0x1213 (GFSK) umschalten kann.

Mit den aktuellen Firmwares 3.5.x scheint nur 0x1203 (2FSK stabil zu funktionieren. Auch wenn es wahrscheinlich nicht ideal für den Rolladen ist ud auch nicht von meinem RTL433 SDR empfangen werden kann.

Ralf9 · 01 Juni 2021, 22:23:07

hier sieht man, daß der Defaultwert (4 preamble Byte gesendet) von Register 0x13 passt

Code Auswählen


remote_shutter-küche_2x-down_433_92MHz-1MSps-1MHz
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 3459 samples]    [Pause: 3,46 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 48986 samples]   [Pause: 48,99 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 3258 samples]    [Pause: 3,26 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 967860 samples]  [Pause: 967,86 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 3454 samples]    [Pause: 3,45 ms]
aaaaaaaad391d391083122fd298a018a8e30cd [Pause: 48883 samples]   [Pause: 48,88 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 3264 samples]    [Pause: 3,26 ms]
aaaaaaaad391d391083122fd29ea01026602a6 [Pause: 1654809 samples] [Pause: 1,65 s]

Wenn Du das Rojaflex auf dem produktiv System verwenden willst, ist es wahrscheinlich besser wenn Du vorerst auf der aktuellen Firmware 3.5.x bleibst und FSK verwendest.
FSK ist zwar nicht ideal aber es funktioniert auch, wahrscheinlich mit geringerer Reichweite, es müsste auch ausreichend sein um das Rojaflex Modul fertig zu entwickeln.
Du kannst dann immer noch auf GFSK wechseln, wenn es eine Firmware 3.5.x gibt bei der auch GFSK funktioniert und mindestens über eine Woche stabil läuft.
Meine Firmware läuft sehr stabil, ich habe damit eine uptime von deutlich über 100 Tagen.

roelleke · 04 Juni 2021, 12:55:20

Hallo,
ich melde mich wieder wegen meines Bresser 5 in 1 Sensor, bei dem der Signalduino ja immer einen 'Checksum Error pos=0' ausgibt. siehe: https://forum.fhem.de/index.php/topic,106594.msg1157364.html#msg1157364
Mein rtl433 Stick ist heute angekommen. Nachdem ich die rtl433 Software installiert und gestartet habe, wurde mein Bresser 5 in 1 Sensor, der sich komischerweise als 6 in 1 Sensor meldet, sofort fehlerfrei empfangen, sie Bild im Anhang. Es sieht für mich nun danach aus als ob in der Signalduino Software noch etwas nicht richtig berechnet wird.
Kann ich hier noch mehr liefern?

Ralf9 · 04 Juni 2021, 13:17:38

Der bresser_6in1 hat ein anderes Protokoll
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_6in1.c

wie der bresser_5in1
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_5in1.c

ich schaus mir heute abend an.
Ich kann von sduino noch mehr MN-Nachrichten gebrauchen

roelleke · 04 Juni 2021, 18:24:57

Hallo,
schön das du dir das noch einmal anscheuen möchtest. Gut das es dieses RTL_433 gibt. Ich hatte eigentlich eine Wetterstation mit einem 5i in 1 Sensor gekauft und so dachte ich dass ich auch so einen habe. Ich habe die MN Nachrichten vom Mai angehängt. ich hoffe das reicht so aus.

Ralf9 · 04 Juni 2021, 19:37:33

Irgendwas passt noch nicht, es müsste normalerweise ungefähr so aussehen:

Code Auswählen

5e aa 18 80 02 c3 18 fa 8f fb 27 68 11 84 81 ff f0 72 00 [Temp 11.8 C  Hum 81%]
ae d1 18 80 02 c3 18 fa 8d fb 26 78 ff ff ff fe 02 db f0
f8 2e 18 80 02 c3 18 fc c6 fd 26 38 11 84 81 ff f0 68 00 [Temp 11.8 C  Hum 81%]
c4 7d 18 80 02 c3 18 fc 78 fd 29 28 ff ff ff fe 03 97 f0
28 1e 18 80 02 c3 18 fb b7 fc 26 58 ff ff ff fe 02 c3 f0
21 e8 18 80 02 c3 18 fb 9c fc 33 08 11 84 81 ff f0 b7 f8 [Temp 11.8 C  Hum 81%]
83 ae 18 80 02 c3 18 fc 78 fc 29 28 ff ff ff fe 03 98 00
5c e4 18 80 02 c3 18 fb ba fc 26 98 11 84 81 ff f0 16 00 [Temp 11.8 C  Hum 81%]
d0 bd 18 80 02 c3 18 f9 ad fa 26 48 ff ff ff fe 02 ff f0

Die ersten beiden Byte ist die CRC16 Prüfsumme und die nächsten 4 Byte müssten immer gleich sein.

Bitte ändere mal das cc1101 reg 0x07 auf 40

Code Auswählen

set sduino cc1101_reg 0740
anschauen kannst Du die cc1101 Register mit

Code Auswählen

get sduino ccreg 99

Wenn dies noch nicht ausreicht, kannst Du auch mal die Frequenz auf 868.3 ändern.

Evtl passt auch die Datarate noch nicht ganz.

Es müsste ca alle 12 - 24 sek eine MN-Nachricht empfangen werden

ZitatThere are at least two different message types:
- 24 seconds interval for temperatur, hum, uv and rain (alternating messages)
- 12 seconds interval for wind data (every message)

Gruß Ralf

roelleke · 04 Juni 2021, 20:06:52

Danke für die Hinweise.
Ich habe das Register 07 von 00 auf 40 geändert. Dann kommt gar keine MN Nachricht mehr rein.
Eine Änderung der Frequenz ergibt keine Änderung.
Die Register sehen jetzt so aus:

Code Auswählen


ccregAll: 

ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 6A
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 ED 2E 15 11 41 00 59 7F 3E 88 31 0B

Gruß
Dieter

Ralf9 · 04 Juni 2021, 20:18:35

Du kannst auch mal beim register 0x03 die Werte 5, 4 oder 3 versuchen, dies ist der Fifo threshold (5 = 24, 4 = 20, 3=16)

@beaune hat festgestellt, daß die Datenrate recht genau passen muss

beaune · 05 Juni 2021, 14:34:23

Ich hab hier nochmal alles zusammengestellt, wie es bei mir für die 5-in-1 genau konfiguriert ist.

Hardwaremäßig setze ich einen Maple(Doppel)-CUL ein.

Softwareausstattung:
version: V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A4 B0*) - compiled at Feb 6 2021 00:26:38
versionmodul: v3.4.6-dev_ralf_24.04.
versionprotoL: v3.4.6-dev_ralf_24.04.

get sduino ccconf liefert:

Code Auswählen

ccconf: freq:868.315MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8232.12Baud)

Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz

get sduino ccreg 99 liefert:

Code Auswählen

ccregAll: 

ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 90
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 EC 0E 3D 11 41 00 59 7F 3E 88 31 0B 

cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2   - 0x01 (0D) [29]
0x01 IOCFG1   - 0x2E
0x02 IOCFG0   - 0x46 (2D) [3F]
0x03 FIFOTHR  - 0x06 (07)
0x04 SYNC1    - 0x2D (D3)
0x05 SYNC0    - 0xD4 (91)
0x06 PKTLEN   - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]
0x09 ADDR     - 0x00
0x0A CHANNR   - 0x00
0x0B FSCTRL1  - 0x06 [0F]
0x0C FSCTRL0  - 0x00
0x0D FREQ2    - 0x21 (10) [1E]
0x0E FREQ1    - 0x65 (B0) [C4]
0x0F FREQ0    - 0x90 (71) [EC]
0x10 MDMCFG4  - 0x88 (57) [8C]
0x11 MDMCFG3  - 0x4C (C4) [22]
0x12 MDMCFG2  - 0x02 (30)
0x13 MDMCFG1  - 0x22 (23)
0x14 MDMCFG0  - 0xF8 (B9)
0x15 DEVIATN  - 0x51 (00) [47]
0x16 MCSM2    - 0x07
0x17 MCSM1    - 0x00 [30]
0x18 MCSM0    - 0x18 [04]
0x19 FOCCFG   - 0x16 (14) [36]
0x1A BSCFG    - 0x6C
0x1B AGCCTRL2 - 0x43 (07) [03]
0x1C AGCCTRL1 - 0x68 (00) [40]
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1  - 0x87
0x1F WOREVT0  - 0x6B
0x20 WORCTRL  - 0xF8
0x21 FREND1   - 0x56
0x22 FREND0   - 0x11 [16]
0x23 FSCAL3   - 0xEC (E9) [A9]
0x24 FSCAL2   - 0x0E (2A) [0A]
0x25 FSCAL1   - 0x3D (00) [20]
0x26 FSCAL0   - 0x11 (1F) [0D]
0x27 RCCTRL1  - 0x41
0x28 RCCTRL0  - 0x00
0x29 FSTEST   - 0x59
0x2A PTEST    - 0x7F
0x2B AGCTEST  - 0x3E
0x2C TEST2    - 0x88
0x2D TEST1    - 0x31
0x2E TEST0    - 0x0B

Der Empfang geht nur mit ccmode=4

Code Auswählen

get sduino raw CSccmode=4

rtl_433 als Service auf dem Raspberry einrichten, auf dem auch fhem läuft.
Mit diesen Parametern (bei der Frequenz ggf. etwas experimentieren): ExecStart=/usr/local/bin/rtl_433 -f 868315000 -R 119 -M level -F mqtt://localhost:1883,devices=rtl_433
In fhem einen MQTT2 Server definieren und autocreate einstellen.

roelleke · 05 Juni 2021, 16:19:04

Hallo,
danke für eure Hinweise. Ich habe jetzt alles ausprobiert, aber der Checksum Error bleibt.
Ich verwende einen NanoCul mit folgenden Software versionen:
version

V 3.3.4-dev200914 SIGNALduino cc1101 (b0) - compiled at Sep 17 2020 23:37:47
versionmodul: v3.4.6-dev_ralf_01.05.
versionprotoL: v3.4.6-dev_ralf_30.04.

get sduino ccconf liefert:

Code Auswählen

ccconf: freq:868.315MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:8232.12Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz

get sduino ccreg 99 liefert:

Code Auswählen

ccreg 00: 01 2E 46 06 2D D4 FF 00 02 00 00 06 00 21 65 90
ccreg 10: 88 4C 02 22 F8 51 07 00 18 16 6C 43 68 91 87 6B
ccreg 20: F8 56 11 ED 2E 15 11 41 00 59 7F 3E 88 31 0B 

cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2   - 0x01 (0D) [29]
0x01 IOCFG1   - 0x2E
0x02 IOCFG0   - 0x46 (2D) [3F]
0x03 FIFOTHR  - 0x06 (07)
0x04 SYNC1    - 0x2D (D3)
0x05 SYNC0    - 0xD4 (91)
0x06 PKTLEN   - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x00 (04)
0x08 PKTCTRL0 - 0x02 (32) [45]

Der Mode 4 ist eingestellt:

Code Auswählen

ccconfFSK: N=7 ccmode=4 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:57.129kHz

Der Unterschied liegt wohl nur in der Software des NanoCul, aber da scheint es keine neuere Version zugeben bzw. mir wird keine im Signalduino Modul angeboten. Läuft die 4.1.2 vielleicht auch auf dem nanoCul?

@baune: Danke für den Hinweis mit dem SDR Stick, das funktioniert so weit ganz gut. Ich denke ich werde das erst mal so machen, bis es vielleicht auch mit dem Signalduino funktioniert.

Viele Grüße
Dieter

Ralf9 · 05 Juni 2021, 16:47:05

Mit der V 3.3.4 sollte es eigentlich auch funktionieren dort gibts auch den ccmode=4

Der Checksum Error wird nur weggehen, wenn Nachrichten vom Bresser 5in1 wie ihn beaune hat, empfangen werden.
Bei Deinem Bresser wird die Checksum anders berechnet, dies kann ich erst ins Signalduino Modul einbauen, wenn ich passende MN-Nachrichten habe.

Ob die MN-Nachrichten passen, kannst Du nur erkennen indem Du die empfangenen MN-Nachrichten anschaust.
Sie müssen ungefähr so aussehen.
Das dritte bis sechste Byte sollten immer gleich sein

Zitat von: Ralf9 am 04 Juni 2021, 19:37:33
Code Auswählen Erweitern
5e aa 18 80 02 c3 18 fa 8f fb 27 68 11 84 81 ff f0 72 00 [Temp 11.8 C Hum 81%] ae d1 18 80 02 c3 18 fa 8d fb 26 78 ff ff ff fe 02 db f0 f8 2e 18 80 02 c3 18 fc c6 fd 26 38 11 84 81 ff f0 68 00 [Temp 11.8 C Hum 81%] c4 7d 18 80 02 c3 18 fc 78 fd 29 28 ff ff ff fe 03 97 f0 28 1e 18 80 02 c3 18 fb b7 fc 26 58 ff ff ff fe 02 c3 f0 21 e8 18 80 02 c3 18 fb 9c fc 33 08 11 84 81 ff f0 b7 f8 [Temp 11.8 C Hum 81%] 83 ae 18 80 02 c3 18 fc 78 fc 29 28 ff ff ff fe 03 98 00 5c e4 18 80 02 c3 18 fb ba fc 26 98 11 84 81 ff f0 16 00 [Temp 11.8 C Hum 81%] d0 bd 18 80 02 c3 18 f9 ad fa 26 48 ff ff ff fe 02 ff f0
Die ersten beiden Byte ist die CRC16 Prüfsumme und die nächsten 4 Byte müssten immer gleich sein.

beaune · 06 Juni 2021, 11:17:01

Mir hat das Thema keine Ruhe gelassen und ich hab nochmal recherchiert.

Eine Sache sollten wir vielleicht mal als allererstes klären: Verwendet die Wetterstation von @roelleke jetzt das 5-in-1 oder das 6-in-1-Protokoll? Das läßt sich mit Hilfe von rtl_433 relativ leicht rausfinden, indem man den Parameter -R bemüht. Mit diesem Funktionsaufruf sollten nur dann noch Telegramme empfangen werden, wenn es sich um das in fhem bereits impleentierte 5-in-1-Protokoll handelt:

Code Auswählen

rtl_433 -f 868272000 -R 119
Es scheint aber auch sehr ähnliche Geräte zu geben, die das 6-in-1-Protokoll verwenden. Da gibt es einige interessante Hinweise in diesem Chat:https://github.com/merbanan/rtl_433/issues/1214, speziell https://github.com/merbanan/rtl_433/issues/1214#issuecomment-751349385. Es würde sich also lohnen, mal zu probieren, ob mit diesem Funktionsaufruf etwas empfangen wird:

Code Auswählen

rtl_433 -f 868272000 -R 172

So hätten wir dann zumindest über das Protokoll Klarheit. Da der Empfang mit fhem bislang nicht funktioniert hat gehe ich davon aus, dass mit -R 119 auch nichts empfangen wird, wohl aber mit -R 172. Wenn das so wäre, könnte man sich auf die Unterschiede stürzen.

Da hätten wir zum Einen den Quellcode des rtl_433: https://github.com/merbanan/rtl_433/blob/master/src/devices/bresser_6in1.c. Wir wissen ja, dass die Datarate kritisch ist, und diese offenbar aus der short_width abzuleiten ist, die hier mit 124µs angegeben ist. Genau über diese 124 waren wir beim 5-in-1 auch schon mal gestolpert: https://forum.fhem.de/index.php/topic,106594.msg1152200.html#msg1152200. Darin hatte @elektron-bbs mal eine Tabelle erstellt und darin die unterschiedlichen Datarates ausgerechnet, die sich für 122 oder 124 ergeben: https://forum.fhem.de/index.php?action=dlattach;topic=106594.0;attach=151036. Genau das könnte jetzt der entscheidende Unterschied für den fhem-Empfang werden. Ich würde daher jetzt nal folgendes ausprobieren:

Zitatset sduino cc1101_dataRate 8064

Wenn dann Nachichten kommen, die dem von @Ralf9 zuvor dargestellten Schema entsprechen, kommen wir entscheidend weiter. Ansonsten ruhig mal einfach ein paar Werte für die Datarate ausprobieren. Irgendwo in diesem Bereich wird es liegen; die Erkenntnis beim 5-in-1 war auch eher ein Zufallstreffer.

Ralf9 · 06 Juni 2021, 11:23:54

hier steht
https://github.com/merbanan/rtl_433/blob/7480c9c9f986859fdf0f661562f05509cc30a383/src/devices/bresser_6in1.c

Code Auswählen

- 1910 084d 18 : RebeckaJohansson, VENTUS W835
- 2030 088d 10 : mvdgrift, Wi-Fi Colour Weather Station with 5in1 Sensor, Art.No.: 7002580, ff 01 in the UV field is (obviously) invalid.
- 1970 0d57 18 : danrhjones, bresser 5-in-1 model 7002580, no UV
- 18b0 0301 18 : konserninjohtaja 6-in-1 outdoor sensor
- 18c0 0f10 18 : rege245 BRESSER-PC-Weather-station-with-6-in-1-outdoor-sensor
- 1880 02c3 18 : f4gqk 6-in-1
- 18b0 0887 18 : npkap

Es gibt demnach auch ein "bresser 5-in-1 model 7002580, no UV"
An den Byte 3-6 lässt sich demnach der Typ erkennen.

@beaune
hat Dein Bresser UV?

Nachtrag:
1/121 ergibt 8264
1/122 ergibt 8196
1/123 ergibt 8130
1/124 ergibt 8064