SD_WS_125 - Receive stopped after some times

[HomeAutoUser]

Problem wurde schon in anderem Faden angesprochen. Nun war es wieder soweit bei mir und ich habe versucht mit dem Handy mehr Infos zu erhalten (weil nicht daheim) -> Receiver blieb wieder stehen.

• Ping erfolgt noch
• state: opened
• nach einem Reset oder Versionsabfrage geht es wieder

Zustände Register beim Nicht-Empfang:

0x32 FREQEST - 0хEB
0x35 MARCSTATE - 0x0D
0x38 PKTSTATUS - 0xD0
0x3A TXBYTES - 0x00
0x3B RXBYTES - 0x00

Letzte RAWMSG

MN;D=30BAA2683190B56C0F0200;R=254;A=5;
RSSI -75

---

Fakten

• sporadischer Ausfall des uC bei einer Benutzung von 6 Sensoren auf einmal
• Ausfall scheint bei keinen DCF Paketen zu sein
• Ausfallzeitpunkte (normale Empfänge, keine DCF Zeit Übertragung)
  • 2026-01-06_00:27:50
• wenn der "Still-Zustand" existiert verbose 5 eingeschalten (keine Sensoren definitiv)

2026.01.20 17:18:35 3: sduino_868: Attr, setting Verbose to: 5
2026.01.20 17:18:36 1: RMDIR: ./restoreDir/save/2026-01-10
2026.01.20 17:18:38 4: sduino_868: KeepAlive, ok, retry = 0
2026.01.20 17:19:38 4: sduino_868: KeepAlive, not ok, retry = 1 -> get ping
2026.01.20 17:19:38 5: sduino_868: AddSendQueue, sduino_868: P (1)
2026.01.20 17:19:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:19:38 4: sduino_868: SendFromQueue, called
2026.01.20 17:19:38 5: sduino_868: SimpleWrite, P
2026.01.20 17:19:38 4: sduino_868: Read, msg: OK
2026.01.20 17:19:38 5: sduino_868: Parse, noMsg: OK
2026.01.20 17:19:38 5: sduino_868: Read, msg: regexp=^OK$ cmd=ping msg=OK
2026.01.20 17:19:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:19:38 4: sduino_868: HandleWriteQueue, nothing to send, stopping timer
2026.01.20 17:20:38 4: sduino_868: KeepAlive, ok, retry = 0
2026.01.20 17:21:38 4: sduino_868: KeepAlive, not ok, retry = 1 -> get ping
2026.01.20 17:21:38 5: sduino_868: AddSendQueue, sduino_868: P (1)
2026.01.20 17:21:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:21:38 4: sduino_868: SendFromQueue, called
2026.01.20 17:21:38 5: sduino_868: SimpleWrite, P
2026.01.20 17:21:38 4: sduino_868: Read, msg: OK
2026.01.20 17:21:38 5: sduino_868: Parse, noMsg: OK
2026.01.20 17:21:38 5: sduino_868: Read, msg: regexp=^OK$ cmd=ping msg=OK
2026.01.20 17:21:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:21:38 4: sduino_868: HandleWriteQueue, nothing to send, stopping timer
2026.01.20 17:22:38 4: sduino_868: KeepAlive, ok, retry = 0
2026.01.20 17:23:38 4: sduino_868: KeepAlive, not ok, retry = 1 -> get ping
2026.01.20 17:23:38 5: sduino_868: AddSendQueue, sduino_868: P (1)
2026.01.20 17:23:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:23:38 4: sduino_868: SendFromQueue, called
2026.01.20 17:23:38 5: sduino_868: SimpleWrite, P
2026.01.20 17:23:38 4: sduino_868: Read, msg: OK
2026.01.20 17:23:38 5: sduino_868: Parse, noMsg: OK
2026.01.20 17:23:38 5: sduino_868: Read, msg: regexp=^OK$ cmd=ping msg=OK
2026.01.20 17:23:38 4: sduino_868: HandleWriteQueue, called
2026.01.20 17:23:38 4: sduino_868: HandleWriteQueue, nothing to send, stopping timer

• wenn der "Still-Zustand" existiert ccreg 99 durchgeführt

add.  name       def.   cur.
0x00  IOCFG2   - 0x0D - 0x01
0x01  IOCFG1   - 0x2E - 0x2E
0x02  IOCFG0   - 0x2D - 0x2E
0x03  FIFOTHR  - 0x47 - 0x43
0x04  SYNC1    - 0xD3 - 0x2D
0x05  SYNC0    - 0x91 - 0xD4
0x06  PKTLEN   - 0x3D - 0x0E
0x07  PKTCTRL1 - 0x04 - 0x80
0x08  PKTCTRL0 - 0x32 - 0x00
0x09  ADDR     - 0x00 - 0x00
0x0A  CHANNR   - 0x00 - 0x00
0x0B  FSCTRL1  - 0x06 - 0x06
0x0C  FSCTRL0  - 0x00 - 0x00
0x0D  FREQ2    - 0x10 - 0x21
0x0E  FREQ1    - 0xB0 - 0x66
0x0F  FREQ0    - 0x71 - 0x1A
0x10  MDMCFG4  - 0x57 - 0xA9
0x11  MDMCFG3  - 0xC4 - 0x5C
0x12  MDMCFG2  - 0x30 - 0x02
0x13  MDMCFG1  - 0x23 - 0x22
0x14  MDMCFG0  - 0xB9 - 0xF8
0x15  DEVIATN  - 0x00 - 0x43
0x16  MCSM2    - 0x07 - 0x07
0x17  MCSM1    - 0x00 - 0x00
0x18  MCSM0    - 0x18 - 0x18
0x19  FOCCFG   - 0x14 - 0x16
0x1A  BSCFG    - 0x6C - 0x6C
0x1B  AGCCTRL2 - 0x07 - 0x43
0x1C  AGCCTRL1 - 0x00 - 0x68
0x1D  AGCCTRL0 - 0x91 - 0x91
0x1E  WOREVT1  - 0x87 - 0x87
0x1F  WOREVT0  - 0x6B - 0x6B
0x20  WORCTRL  - 0xF8 - 0xF8
0x21  FREND1   - 0xB6 - 0xB6
0x22  FREND0   - 0x11 - 0x11
0x23  FSCAL3   - 0xE9 - 0xEF
0x24  FSCAL2   - 0x2A - 0x2D
0x25  FSCAL1   - 0x00 - 0x3F <----- https://github.com/RFD-FHEM/SIGNALDuino/issues/380#issuecomment-3729405057
0x26  FSCAL0   - 0x1F - 0x1F
0x27  RCCTRL1  - 0x41 - 0x41
0x28  RCCTRL0  - 0x00 - 0x00
0x29  FSTEST   - N/A  - 0x59
0x2A  PTEST    - N/A  - 0x7F
0x2B  AGCTEST  - N/A  - 0x3E
0x2C  TEST2    - N/A  - 0x88
0x2D  TEST1    - N/A  - 0x31
0x2E  TEST0    - N/A  - 0x0B

• wenn der "Still-Zustand" existiert ccreg 31/32/33/34/35/36/37/38/39/3a/3b/3c/3d durchgeführt

0x31  VERSION        - 0x14 Chip CC1101
0x32  FREQEST        - 0xF2
0x33  LQI            - 0x80
0x34  RSSI           - 0xD2
0x35  MARCSTATE      - 0x0D
0x36  WORTIME1       - 0x00
0x37  WORTIME0       - 0x00
0x38  PKTSTATUS      - 0x90
0x39  VCO_VC_DAC     - 0xFF
0x3A  TXBYTES        - 0x00
0x3B  RXBYTES        - 0x00
0x3C  RCCTRL1_STATUS - 0x00
0x3D  RCCTRL0_STATUS - 0x00

• FREQAFC bei einer Arbeitsfrquenz von 868.370MHz

sduino_868_FREQAFC | -2
sduino_868_FREQAFC | 0
sduino_868_FREQAFC | 8

• ccconf: Freq: 868.370 MHz, Bandwidth: 135 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud, Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 34.91 kHz

• bei einem Zeitlichen uC reset von 120 Minuten tritt der Fehler nicht auf

Vorgehensweise(n) um den Empfang wieder zu starten

• set reset uC

!!! nach erfolgtem RESET ausgelesen !!!
0x25  FSCAL1   - 0x00 - 0x19

• ...

[elektron-bbs]

Die Register sehen eigentlich gut aus:

0x32 FREQEST   - 0хEB = -24 = -38,0859375 kHz - hier ähnlich, wackelt 0xE0, 0xE1 ...
0x35 MARCSTATE - 0x0D = RX
0x38 PKTSTATUS - 0xD0 - hier auch so
0x3A TXBYTES   - 0x00 - Number of bytes in TX FIFO = OK
0x3B RXBYTES   - 0x00 - Number of bytes in RX FIFO = OK

Ich hatte mir bei der Analyse der DNT_000005 etwas abweichende Werte notiert:

Deviation: ca. 70 kHz
Datenrate:
 10 Bit   584 µS =               17,12 kHz
 20 Bit  1110 µS =               18,01 kHz
 30 Bit  1690 µS =               17,75 kHz
352 Bit 10100 µS = 28,7 µS/Bit = 17,42 kHz
-------------------------------------------
                   Durchschnitt: 17,575 kHz

Zur Zeit werden die entsprechenden Register so eingestellt:

Datenrate: 17.2577, Bandbreite: 135.416667, Deviation: 34.912109
add.  name       def.   cur.
0x10  MDMCFG4  - 0x57 - 0xA9
0x11  MDMCFG3  - 0xC4 - 0x5C
0x15  DEVIATN  - 0x00 - 0x43

Probiere mal bitte folgende Einstellungen:

Datenrate: 17.5552, Bandbreite: 162.500000, Deviation: 69.824219
add.  name       def.   cur.
0x10  MDMCFG4  - 0x57 - 0x99
0x11  MDMCFG3  - 0xC4 - 0x62
0x15  DEVIATN  - 0x00 - 0x53

[sidey79]

Hmm, ich müsste mal einen Signaldino aufsetzen und dann debuggen... Aber ich weiss noch nicht wie ich das mit dem debuggen anstelle

[elektron-bbs]

Es muss ja irgend etwas sein, was der CC1101 bzw. die Firmware selbst anpasst. Wenn die AFC ausgeschaltet ist, fällt mir eigentlich nur noch die "bit synchronization" ein, die sich evtl. auf andere Signale einstellt.

[HomeAutoUser]

@elektron-bbs
Ich habe soeben die Register mal geändert und ein ccconf gemacht. Der Empfang geht wieder, aber es werden immer falsche Chk-Summen gebildet.

2025.08.25 21:21:55 3: sduino_868: SD_WS_125 Parse msg 30F8E36B1CCD09B607C180 - ERROR CRC8 73 shoud be 0
2025.08.25 21:21:55 3: sduino_868: SD_WS_125 Parse msg 30F8C32B1CCD09B6078080 - ERROR CRC8 203 shoud be 0
2025.08.25 21:22:03 3: sduino_868: SD_WS_125 Parse msg 30BAF37717D0E13607C180 - ERROR CRC8 237 shoud be 0
2025.08.25 21:22:03 3: sduino_868: SD_WS_125 Parse msg 30BAA33317D0E136078080 - ERROR CRC8 238 shoud be 0
2025.08.25 21:22:08 3: sduino_868: SD_WS_125 Parse msg 3097DB709B09213607C180 - ERROR CRC8 115 shoud be 0
2025.08.25 21:22:08 3: sduino_868: SD_WS_125 Parse msg 3097D3309B092136078080 - ERROR CRC8 157 shoud be 0
2025.08.25 21:22:11 3: sduino_868: SD_WS_125 Parse msg 3050DB671C8450B607C180 - ERROR CRC8 166 shoud be 0
2025.08.25 21:22:11 3: sduino_868: SD_WS_125 Parse msg 305091271C8450B6078080 - ERROR CRC8 175 shoud be 0
2025.08.25 21:22:12 3: sduino_868: SD_WS_125 Parse msg 3056837022C89F3607C080 - ERROR CRC8 50 shoud be 0
2025.08.25 21:22:12 3: sduino_868: SD_WS_125 Parse msg 3056813022C89F3607C080 - ERROR CRC8 199 shoud be 0
2025.08.25 21:22:37 3: sduino_868: SD_WS_125 Parse msg 30FABB7B1AE79B3607C180 - ERROR CRC8 185 shoud be 0
2025.08.25 21:22:37 3: sduino_868: SD_WS_125 Parse msg 30FAB12B1AE79B36078080 - ERROR CRC8 244 shoud be 0
2025.08.25 21:23:00 3: sduino_868: SD_WS_125 Parse msg 30F8E36B1CCD09B607C180 - ERROR CRC8 73 shoud be 0
2025.08.25 21:23:00 3: sduino_868: SD_WS_125 Parse msg 30F8C32B1CCD09B6078080 - ERROR CRC8 203 shoud be 0
2025.08.25 21:23:06 3: sduino_868: SD_WS_125 Parse msg 30BAA33317D0E13607C080 - ERROR CRC8 238 shoud be 0
2025.08.25 21:23:13 3: sduino_868: SD_WS_125 Parse msg 30509B671C8450B607C180 - ERROR CRC8 70 shoud be 0
2025.08.25 21:23:13 3: sduino_868: SD_WS_125 Parse msg 305091271C8450B6078080 - ERROR CRC8 175 shoud be 0
2025.08.25 21:23:13 3: sduino_868: SD_WS_125 Parse msg 3056837022C89F36078180 - ERROR CRC8 50 shoud be 0
2025.08.25 21:23:13 3: sduino_868: SD_WS_125 Parse msg 3056813022C89F36078080 - ERROR CRC8 199 shoud be 0
2025.08.25 21:23:14 3: sduino_868: SD_WS_125 Parse msg 3097D3709B092136078180 - ERROR CRC8 111 shoud be 0
2025.08.25 21:23:14 3: sduino_868: SD_WS_125 Parse msg 3097D3309B092136078080 - ERROR CRC8 157 shoud be 0

Aktuelle Config

cc1101_config
Freq: 868.370 MHz, Bandwidth: 162 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.56 kBaud
2025-08-25 21:21:53
cc1101_config_ext
Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 69.82 kHz

Nachdem ich die Register auf rfmode Fine_Offset_WH31_868 wechselte, klappte der Empfang mit richtigen Chk-Summen auch.

Jetzige Config

cc1101_config
Freq: 868.350 MHz, Bandwidth: 135 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud
2025-08-25 21:29:40
cc1101_config_ext
Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 34.91 kHz
2025-08-25 21:29:40

[elektron-bbs]

Dann liege ich wahrscheinlich falsch. Ich habe mich auch schon gewundert, wiese so unterschiedliche Bitraten herauskommen, je nach Anzahl der Bytes. Der SDR-Stick bzw. die Software ist vielleicht auch nicht so genau.

[HomeAutoUser]

Hallo @sidey79, @elektron-bbs
-> auf diesem Wege noch ein gesundes neues Jahr 2026

Ich versuche mal ein paar Erkenntnisse hier zu sammeln, da das Problem immer noch besteht.
Nach langer Testreihe, habe ich den Verdacht, das vielleicht ein Timer in der uC das Ganze erscheinen lässt.
Sobald ich in den Tests mit allen 6 Sensoren immer nach 60 Minuten den uC zurücksetze mit einem RESET läuft es beständig.
(Leider nerven dann die LOG-Einträge und dies ist ein WORKAROUND der schlechten Sorte)

Nun habe ich den Abstand auf 120Minuten genommen und beobachte.

@elektron-bbs, du hattest Einblick in sämtliche Timer, kommt dir da vielleicht etwas bekannt vor der ein Timer in den sinn wo du das Ganze mit den RSSI Fehler untersucht hattest?

Liebe Grüße

[elektron-bbs]

Hallo @sidey79, @elektron-bbs -> auf diesem Wege noch ein gesundes neues Jahr 2026

Das wünsche ich euch und allen anderen auch.

Ich versuche mal ein paar Erkenntnisse hier zu sammeln, da das Problem immer noch besteht. Nach langer Testreihe, habe ich den Verdacht, das vielleicht ein Timer in der uC das Ganze erscheinen lässt. Sobald ich in den Tests mit allen 6 Sensoren immer nach 60 Minuten den uC zurücksetze mit einem RESET läuft es beständig. (Leider nerven dann die LOG-Einträge und dies ist ein WORKAROUND der schlechten Sorte)

Nun habe ich den Abstand auf 120Minuten genommen und beobachte.

@elektron-bbs, du hattest Einblick in sämtliche Timer, kommt dir da vielleicht etwas bekannt vor der ein Timer in den sinn wo du das Ganze mit den RSSI Fehler untersucht hattest?

An einem Timer in der Firmware kann es nicht liegen. Da gibt es nur einen, der maximal alle 32 mS den FiFo bei ASK/OOK zurück setzt und die Uptime aktualisiert.
Es muss etwas spezielles bei diesem Protokoll/Einstellungen sein. Bei mir läuft ein SIGNALduino mit Bresser_5_in_1 über mehrere Monate stabil.
Hast du denn mal, wenn der Empfang aussetzt, den SIGNALduino auf verbose 4 gesetzt? Kommt dann noch irgendein Empfang rüber? Ich habe den Verdacht, das es mit Lacrosse Mode 1 zusammenhängt. Das ist die gleiche Datenrate und fast gleiche Frequenz, allerdings unterschiedliche Länge der Nachrichten.

[HomeAutoUser]

An einem Timer in der Firmware kann es nicht liegen. Da gibt es nur einen, der maximal alle 32 mS den FiFo bei ASK/OOK zurück setzt und die Uptime aktualisiert. Es muss etwas spezielles bei diesem Protokoll/Einstellungen sein. Bei mir läuft ein SIGNALduino mit Bresser_5_in_1 über mehrere Monate stabil. Hast du denn mal, wenn der Empfang aussetzt, den SIGNALduino auf verbose 4 gesetzt? Kommt dann noch irgendein Empfang rüber? Ich habe den Verdacht, das es mit Lacrosse Mode 1 zusammenhängt. Das ist die gleiche Datenrate und fast gleiche Frequenz, allerdings unterschiedliche Länge der Nachrichten.

Da die Suche schon seit Langem gehen und die Zeit fehlte, so habe ich bei all den Versuchen nie genau dokumentiert, was ich bei einem Ausfall alles machte. Dazu wollte ich nun den Faden hier nutzen mit viel Selbstdisziplien. Ganz dunkel erinnere ich mich an das Verbose 4 aber da möchte ich meine Hand nicht ins Feuer legen.

Alles was wir nun sammeln und getestet haben, halte ich hier #380 (comment) fest

[sidey79]

Ich wünsche euch auch ein gesundes und erfolgreiches neues Jahr 2026.

Bezüglich dieses Problemes bin ich auch etwas ratlos.

Der uC selbst bleibt nicht hängen, weil er ja weiterhin seine Arbeit verrichtet.

Wenn das Problem vor liegt, dann ist die Kommunikation mit dem cc1101 gestört. In dem Moment müsste man ja mal alle Register usw. bekommen aber ich wüsste nicht, wie man die abfragen kann.

Vielleicht ist einfach nur die SPI Kommunikation gestört? Also ich hatte das Problem mit einem esp32. Seit dem periodischen neu Initialisieren fällt es nicht mehr auf.

[sidey79]

Der Wert 0xD0 entspricht binär 1101 0000. Die Zählweise der Bits im TI Datenblatt (Seite 72 für PKTSTATUS) ist von 7 (MSB) bis 0 (LSB).

Die Aufschlüsselung für 1101 0000:

Bit	Name	Wert	Bedeutung
7	CRC_OK	1	Das vorherige Paket wurde korrekt empfangen (CRC Check ok).
6	CS	1	Carrier Sense. RSSI ist über dem Schwellwert.
5	PQT_REACHED	0	Präambel-Qualität nicht erreicht.
4	CCA	1	Clear Channel Assessment. Der Kanal gilt als "frei".
3	SFD	0	Sync Word nicht gefunden (Kein Paket-Start erkannt).
2	GDO2	0	(Status des Pins)
1	-	0	(Reserved)
0	GDO0	0	(Status des Pins)

Zusammengefasst:

CS = 1: Der Chip sagt: "Hier ist ein Signal (oder Rauschen), das lauter ist als mein Schwellwert."
CCA = 1: Der Chip sagt: "Der Kanal ist frei, du darfst senden."

Vermutlich hat der AFC den Empfänger abwandern lassen, ich teste mal mit einem periodischen SIDLE Befehl um neu zu kalibrieren.