FSK mit dem SIGNALDuino

[hofy]

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]

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]

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]

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

Code: [Auswählen]

remote_shutter-kü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]

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]

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]

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]

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 f0Die 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 0740anschauen 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

There 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]

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]

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]

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

Wenn das alles so eingestellt ist, müßte es klappen.

Der Vollständigkeit halber möchte ich hier noch erwähnen, dass man auch mit dem SDR-Stick eine Integration in fhem machen kann, nur so als Rückfallstrategie wenn alle Stricke reißen. Der SDR braucht zwar mehr Strom, das rtl_433 mehr Rechenleistung, und der Empfang ist gefühlt auch nicht ganz so gut, aber es läuft auch ziemlich stabil, und ist auch konfigurationsmäßig nicht sehr schwierig:

• 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.

Der Rest geht dann automatisch, fhem legt ein MQTT-Device für die Wetterstation an und ermittelt auch die Readings selbständig. Je nachdem, was man loggen/visualisieren will, ist noch Handarbeit gefragt, aber das ist dann mit fhem Boardmitteln ohne weiteres möglich. Da ist ein für die Verwendung mit dem statistic Modul optimiertes fhem-Device natürlich schon etwas einfacher zu handhaben, als ein universelles MQTT Device, das z.B. die Besonderheiten bei der Auswertung der Regenmenge (Zählerüberlauf) nicht kennen kann, geht aber alles. Aber das Ziel dieses Threads ist natürlich ein anderes 

Viel Erfolg, bei welcher Lösung auch immer!

[roelleke]

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]

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

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 f0Die ersten beiden Byte ist die CRC16 Prüfsumme und die nächsten 4 Byte müssten immer gleich sein.

[beaune]

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 119Es 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:

set 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]

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