CC1101 FSK Sendeprobleme (nur 15 Nachrichten?!)

[devzero84]

Hallo,

Version V 3.5.0-dev+20201221 SIGNALduino cc1101 (chip CC1101) - compiled at May 8 2021 18:53:43

ich experimentiere gerade mit der Bresser 5in1 (FSK!) Wetterstation bzw. mache eine eigene Implementierung (also kein FHEM), die mit dem SIGNALduino interagiert. Um das Protokoll zu validieren habe ich bestimmte Daten selbst ausgesendet. Das Display, rtl_433 und auch ein anderer SIGNALduino als Empfaenger bekommen die Daten.

Grundsaetzlich funktioniert es; eine gueltige Nachricht gesendet wird sowohl im rtl_433 als auch auf dem Display korrekt dargestellt.

Ich sende folgendes (alle 12s wie der original Aussensensor): SN;R=1;D=E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000;<0x0A als line end>

rtl_433 (das Display der Wetterstation ebenso) stellt das wie folgt dar - Werte sind so erwartet:

---

time : 2021-06-08 13:04:13 model : Bresser-5in1 id : 168 Battery : 1 Temperature: 75.6 C Humidity : 98 Wind Gust : 98.7 m/s Wind Speed: 24.3 m/s Direction : 0.0 Rain : 1.0 mm Integrity : CHECKSUM

Kurioser Weise klappt das - reproduzierbar und mehrfach ausprobiert - nur mit insgesamt 15 Nachrichten. Danach antwortet der SIGNALduino zwar weiterehin auf das Sendekommando mit dem String (also kein Fehlerstring) aber es geht offenbar nichts mehr in die Luft. Der Spectrumanalyzer von URH (auch mit RTL-SDR Stick) zeigt dann keinen Ausschlag mehr.

Ich habe mich durch den Code auf dem FSK branch gewuehlt, finde aber keine Stelle wo das limitiert werden wuerde (hatte die 1% Regel fuer 868 MHz im Kopf).

Wenns hilft, koennte ich noch SPI zum CC1101 mitsniffen. Hat jemand eine Idee bzw. kann das nachstellen? Diese Nachricht von oben und ein RTL-SDR Stick mit rtl_433 reicht zum Nachstellen, die Wetterstation muss also nicht physisch existent sein.

Viele Gruesse, devzero

[HomeAutoUser]

Ich werde versuchen es nachzustellen mit meiner Hardware.

[HomeAutoUser]

@devzero84 mit dem ESP8266 konnte ich dein Verhalten nicht nachstellen. Ich habe nun direkt aus FHEM mehrfach deine Nachricht SN;R=1;D=E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000; gesendet nachdem ich den Empfänger auf Bresser-5in1 einstellte.

time      : 2021-06-08 19:36:07
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:20
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:26
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:33
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:41
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:50
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:36:57
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:03
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:10
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:17
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:22
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:30
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:39
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:45
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:51
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:37:56
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:38:01
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:38:09
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:38:15
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-08 19:38:23
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM

Welche Hardware nutzt du genau? Mache doch mal deinen Test mit einem Zeitabstand von 24 Sekunden ....

[elektron-bbs]

Ich konnte es auch nicht nachvollziehen. Ich habe einen Arduino Nano mit dieser Firmware V 3.5.0-dev+20201207 SIGNALduino cc1101 (chip CC110 unknown) - compiled at Dec 18 2020 22:34:07 alle 30 Sekunden über einen Zeitraum von etwa 2 Stunden das Signal senden lassen. Der MSGCNT beim Empfänger zeigte danach 120 an.

[devzero84]

Hallo zusammen,

danke fuers ausprobieren. Ich habe das Problem nach wie vor. Es scheint aber weg zu sein, wenn ich sekuendlich sende (habe dafuer die Antenne abgemacht um hoffentlich die Nachbarn nicht zu stoeren) - oder es auessert sich einfach viel spaeter. Langzeittests fehlen hier noch.

Als Hardware kommt ein Arduino Uno (also auch 328P wie der Nano) zum Einsatz mit einem CC1101 Modul.

Ich habe nun mal aus den Sourcen gebaut (mit -DDEBUG) und angefangen die cc1101::sendFIFO() zu untersuchen. Hierbei ist mir aufgefallen, dass hier jedesmal TXFIFO_UNDERFLOW signalisiert wird, was die Funktion aber erstmal nicht stoert. Habe den Code mal testweise um das SFTX Command Strobe ergaenzt (Datenblatt S.67), dies aendert aber nichts. Nach einiger Zeit (ca. die 15 Telegramme) geht der CC1101 scheinbar in den SLEEP. Ab hier kommen dann keine Pakete mehr. Hier kommt er nicht mehr raus. Jedenfalls komme ich durch folgenden Debugcode zu dem Ergebnis, evtl. verrenne ich mich hier aber. Waere gut, wenn ein CC1101 Experte sich das mal anschauen und bewerten koennte.

Als diff:

 void cc1101::sendFIFO(char *startpos, char *endpos) {
     cc1101_Select();                                // select CC1101
     sendSPI(CC1101_TXFIFO | CC1101_WRITE_BURST);    // send register address
@@ -684,8 +683,23 @@ void cc1101::sendFIFO(char *startpos, char *endpos) {
     cc1101_Deselect();    //Wait for sending to finish (CC1101 will go to RX state automatically

     for(uint8_t i=0; i< 200;++i) {
-      if( readReg(CC1101_MARCSTATE_REV00, CC1101_STATUS) != MarcStateTx)
+      uint8_t marcState = readReg(CC1101_MARCSTATE_REV00, CC1101_STATUS);
+      DBG_PRINTLN(marcState);
+      if( marcState != MarcStateTx)   // Datenblatt S.93
+      {
+        if (marcState == 22)  // 22 TXFIFO_UNDERFLOW
+        {
+          //cc1101::cmdStrobe(CC1101_SFTX);
+        }
         break;            //neither in RX nor TX, probably some error
+      }
       delay(1);
     }
+
+    int8_t txbytes = readReg(0x3A /* TXBYTES */, CC1101_STATUS);  // Datenblatt S.94
+    if (txbytes & 0x80)
+    {
+        DBG_PRINTLN("TXFIFO_UNDERFLOW");
+    }
+    DBG_PRINTLN(txbytes&0x7F); // Anzahl Bytes im TX FIFO
 }

Komplett:

void cc1101::sendFIFO(char *startpos, char *endpos) {
    cc1101_Select();                                // select CC1101
    sendSPI(CC1101_TXFIFO | CC1101_WRITE_BURST);    // send register address

    uint8_t val;
    for (char *i = startpos; i < endpos; i+=2) {
      val = hex2int(i[0]) * 16;
      val+= hex2int(i[1]);
      /* DBG_PRINTLN(val); // only to debug */
      sendSPI(val);    // send value
    }

    cc1101_Deselect();    //Wait for sending to finish (CC1101 will go to RX state automatically

    for(uint8_t i=0; i< 200;++i) {
      uint8_t marcState = readReg(CC1101_MARCSTATE_REV00, CC1101_STATUS);
      DBG_PRINTLN(marcState);
      if( marcState != MarcStateTx)   // Datenblatt S.93
      {
        if (marcState == 22)  // 22 TXFIFO_UNDERFLOW
        {
          //cc1101::cmdStrobe(CC1101_SFTX);
        }
        break;            //neither in RX nor TX, probably some error
      }
      delay(1);
    }

    int8_t txbytes = readReg(0x3A /* TXBYTES */, CC1101_STATUS);  // Datenblatt S.94
    if (txbytes & 0x80)
    {
        DBG_PRINTLN("TXFIFO_UNDERFLOW");
    }
    DBG_PRINTLN(txbytes&0x7F); // Anzahl Bytes im TX FIFO
}

Hier der dazugehoerige Debugoutput beim Senden:

send cmd detected 2
Adding xFSK message
rearrange beginptr
SN;Adding repeats: 1
R=1;locating data start:E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000; end:;
msg 1/1 part 0/0 repeats 1
19
19
19
19
19
19
19
19
19
19
19
19
19
19
22
TXFIFO_UNDERFLOW
0
SN;D=E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000;

Hier klappt es noch, 19 => TX, 22 => TXFIFO_UNDERFLOW Die 0 nach der Ausgabe TXFIFO_UNDERFLOW und dem SN String ist die Laenge im Buffer.

Etwas spaeter dann (2-3 Minuten, ca. 15 Frames), ab wo es nicht mehr funktioniert (faengt sich auch nicht mehr):

send cmd detected 2
Adding xFSK message
rearrange beginptr
SN;Adding repeats: 1
R=1;locating data start:E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000; end:;
msg 1/1 part 0/0 repeats 1
19
19
19
19
19
19
19
19
19
0
7
SN;D=E3577F24FCBCEDA9F867EFFFFF1CA880DB034312560798100000;

0 => SLEEP und nun 7 Bytes (die Laenge ist auch schonmal kuerzer oder laenger) im FIFO

Ich habe aktuell keine richtige Idee, was das Problem sein koennte ausser vielleicht ein defektes CC1101 Modul, auch wenn Empfang mittlerweile ganz wunderbar funktioniert (musste aber einen Offset von 20 kHz zur Frequenz addieren, damit es das stabil tut - laeuft vielleicht der Quarz zu stark abweichend von 26 MHz?) Ein anderes Modul muss ich aber erst fertig machen. Werde ich als naechstes testen.

Danke und Gruesse

[devzero84]

Ich habe es mit einem anderen Modul probiert mit dem selben Ergebnis. Was mir nicht ganz klar ist, warum der CC1101 fuer die Bresser5in1 auf Infinite package length und nicht auf fixed packet length konfiguriert ist. Die Nachrichten haben immer 26 Byte Nutzdaten + Praeambel und den beiden Syncbits - gibts dafuer einen Grund?

Vgl. Register PKTCTRL0 Bits 1:0 (auf 10 gesetzt, infinite package length mode, S. 74) und PKTLEN (auf 0xFF gesetzt)

Ich habe versuch das zu aendern auf 00 (Fixed package length mode) und mit 26 (dezimal) in PKTLEN, hat aber bisher auch nicht zum Ergebnis gefuehrt.

[elektron-bbs]

Da wir es nicht nachvollziehen können, was das Problem verursacht, würde ich gerne erst mal bei der Hardware anfangen zu suchen. Beschreib doch bitte mal genau, was verwendet wird: Arduino, CC1101-Modul, Verdrahtung (Steckbrett/Leiterplatte), Levelshifter/Spannungsteiler (welche Widerstandswerte), Netzteil u.s.w. Hilfreich wären vielleicht auch Bilder.

Ich verlinke das auch gleich noch in https://github.com/RFD-FHEM/SIGNALDuino/issues/206#issuecomment-857549449, da es sich dort u.U. um das gleiche Problem dreht.

[devzero84]

Pegelwandlung erfolgt aktuell ueber je einen N Kanal FET mit 3,3V am Gate, 3,3V ueber 10K an Source und 5V ueber 10K an Drain. Ich weiss, prosa ist immer doof - ich skizzier das spaeter noch und reiche auch Bilder nach (die Module sind fertig gekauft, aber ich habe mir die Schaltung schon angesehen).

Ansonsten gehen jeweils ca 20 cm lange Dupontwires vom Uno zum Modul weg. Grundsaetzlich koennte hier natuerlich SPI gestoert werden (laeuft ja mit 4 MHz), schliesse ich aber fast aus, weil ich noch einen LogicAnalazyer ueber nochmal 20 cm dran habe und da alles so aussieht, wie ich es warte - und auch beim Empfang keine Probleme auftreten.

Dennoch habe ich mir noch nicht die Signale hinterm Pegelwandler mitm Oszi angesehen, werde ich aber wohl erst am Wochenende mal machen. Kann meinen Homeofficetisch nicht noch weiter mit Geraeten zustellen :) Habe auch noch andere "nackte" CC1101 Module von einem anderen Haendler (also andere Charge), da muss ich aber erst Draehte anloeten.

Bis zum WE werde ich mir aber mal ein Minimalbeispiel from scratch coden, was dauersendet (im 12s Raster) - die Registersettings uebernehme ich erstmal und mache die restlichen Dinge nach Datenblatt - dann vergleiche ich das Ergebnis mal. Evtl. ergibt sich hieraus auch ein Fix oder zumindestens die Ursache wird erkannt.

Ansonsten stelle ich alles online, Script welches die Daten sendet, Firmware mit Debugcode (als Diff und HEX) und detaillierte HW Infos. Mich macht das TXFIFO_UNDERFLOW jedenfalls arg stutzig. Ich moechte jetzt nicht nur, dass es funktioniert, sondern auch das Problem verstehen :)

Ich melde mich dann spaetestens am WE wieder.

Merci und viele Gruesse

[devzero84]

Hallo,

habe den Fehler gefunden. https://github.com/RFD-FHEM/SIGNALDuino/pull/210

Ich beschreibe noch genauer, wie ich das gefunden habe und warum das auch die Probleme von vorgestern erklaert (mit der 0 die ich als SLEEP gedeutet habe beim Read vom MARCSTATE Register) . Das MISO etwas laenger high ist, kann vielleicht am CC1101 liegen. Das erklaert aber auch, warum es nicht sofort auftritt sondern erst nach ein paar Telegrammen. Die aktuelle Implementierung ist aber auf jeden Fall so falsch. Die statische Variable wird genau einmal auf 255 initialisiert und dann immer nur dekrementiert - einmal 0, immer 0.

Es gibt noch ein paar weitere Unschoenheiten im CC1101 Code, die ich lokal schon geandert habe. Reiche ich ggf. spaeter als weiteren Pullrequest nach.

Viele Gruesse

[HomeAutoUser]

Hallo @devzero84 ich habe nun nachstellen können (alle 4 Sekunden senden) wie und wann dein Absturz nach deinen vermeitlichen 15 Nachrichten zustande kommen kann. Es wird bestimmt unabhängig mit deinem PR Vorschlag oder weiteren Feststellungen zusammenhängen.

@elektron-bbs wie sind deine Erkenntnisse?

Ich konnte verifizieren, das die Stelle https://github.com/RFD-FHEM/SIGNALDuino/blob/00089bb67fe52c0af4ef22ec06a9cca9e9a31baf/src/signalduino.h#L99-L101 uns diesen Crash bringt. Dort werden die SPI Pin´s mit angegriffen. Wenn ich die Schleife nur von i=2;i<10 laufen lasse, so klappt es.

Orginalvariante https://github.com/RFD-FHEM/SIGNALDuino/blob/00089bb67fe52c0af4ef22ec06a9cca9e9a31baf/src/signalduino.h#L99 bringt Fehler:

START
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:03:46
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:04:30
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM

SCHLUSS crash

Wenn ich nun die Schleife auf

  for (uint8_t i=2;i<10;i++) { // all SPI PIN´s locked out, if SPI PIN set to pinAsInputPullUp -> crashed ???
    pinAsInputPullUp(i);
  }

ändere, so rennt es durchweg ...

START
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:09:42
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:19:46
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
.....

Das Ganze auch reproduziert wenn Schleife (uint8_t i=2;i<13;i++) orginal ist.

START
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:24:26
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:25:14
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM

SCHLUSS crash

Änderung, Schleife (uint8_t i=2;i<10;i++)

START
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:34:18
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2021-06-10 18:51:18
model     : Bresser-5in1 id        : 168
Battery   : 1            Temperature: 75.6 C       Humidity  : 98            Wind Gust : 98.7 m/s
Wind Speed: 24.3 m/s     Direction : 0.0           Rain      : 1.0 mm        Integrity : CHECKSUM
.....

läuft immer noch

[sidey79]

Das Initialisieren der Pins habe ich eingebaut damit die einen definierten Stand haben.

Das passiert doch nur beim initialisieren und später nicht mehr. Seltsam, werden dir SPI Pins nicht später auch in den passenden Zustand gebracht?

[devzero84]

@HomeAutoUser Hast Du mal meinen PR ausprobiert? Wie gesagt, das ist definitiv kaputt. Wenn das 255 mal passiert, kehrt die readReg() funktion immer mit false zurueck. Da die 255 nicht nach 1 oder 2 Messages erreicht sind, geht es halt ein paar Mal. Bei mir so meist 15 mal. Der SPI Takt spielt sicher auch noch eine Reihe. Auf dem ATmega328 wird der mit fosc/4, also 4 MHz betrieben.

Das ist auch das, was ich in meinem Fehlerreport von vorgestern gesehen habe (was ich irrtuemlich als SLEEP weil 0 angenommen habe) -> readReg() auf das MARCSTATE Register: wait_Miso_rf() kehrt, weil der MISO PIN noch High ist, mit false zurueck, was dann als 0 interpretiert wird. Ich hatte testweise das read entfernt und ein NOOP Strobe eingefuegt und die Statusantwort ausgewertet. Hier noch eine Variable hochgezaehlt und auf die Konsole geschrieben. Ich hab dann gesehen, dass die Zahl teilweise doppelt so hoch war, als wie ich das NOOP Strobe auf dem Logikanalyzer sehen konnte - so kam ich darauf, dass irgendwie der SPI Bus nicht richtig funktioniert und dann ist mir das static im wait_Miso_rf() define fast direkt ins Auge gesprungen.

Ich war jetzt - allein mit der PR Aenderung, 3 Stunden ohne Probleme im 12 Sekundenintervall Dauersenden.

Was die Pullups betrifft - ich glaube das tut dem ATmega nicht weh, auf dem ESP kann das natuerlich anders sein. Jedenfalls koennte aber auch sein, dass dies Zeit kostet, die Dir dann am Ende im kaputten wait_Miso_rf() um die Ohren fliegt. Probier das bitte mal aus. Hast Du einen LA? Ich werde spaeter mal zwei Screenshots machen - von dem Fehler und vom Normalfall, wo es tut.

[devzero84]

Beides Bilder vom Senden eines Datenpakets (das vom Fehlerzustand hab ich jetzt mal weggelassen, weil ich es nicht habe und erst wieder umflashen muesste) - man sieht, dass nach dem Senden das MARCSTATE Register gelesen wird (Adresse 0xF5 mit 0x00 als readcmd) - geantwortet mit 0x20 0x13 - 0x20 ist der Inhalt des Statusregisters was immer uebertragen wird (hier wuerde ich kuenftig also eher den NOOP Strobe nehmen und das auswerten, spart SPI Traffic). Der Wert 0x13 sagt aus, dass der CC1101 noch im TX ist. Das passiert ein paar mal - irgendwann ist er ungleich 0x13 und verlaesst die cc1101::sendFIFO(). Und zwar genau dann, wenn hier das Statusbyte 0x70 (TXFIFO_UNDERFLOW) ist und 0x16 (Inhalt von MARCSTATE) sagt ebenfalls TXFIFO_UNDERFLOW (was normal ist, da hier aktuell nicht mit fester Laenge gearbeitet [PKTCTRL0 und PKTLEN] wird). Jedoch wird im enableReceive() bzw. im cc1101:setReceive() direkt der Buffer geflusht (SRX Strobe im underflowfall).

Achtung: Das geht so nicht, wenn man auf feste Laenge umstellt. Habe ich probiert und funktioniert ganz wunderbar ohne underflow, jedoch darf dann das SRX im enableReceive nicht einfach so gemacht werden (laut DB nur im Idle oder Underflowfall - das bezeichnte ich vorhin als unschoen und das werde ich spaeter noch pull-requesten). Im aktuellen Fall spielt das aber keine Rolle, da wir entweder den Underflowfall haben nach dem send oder anfangs aus Idle reinkommen.

Wenn nun aber hier schon nur EIN SPI Paket verloren geht, ist die Uebertragung kaputt. Das erklaert auch, warum man zwar keine validen Daten mehr empfangen hat, aber oftmals im Spektrum noch was sah (nicht immer). Man darf nicht vergessen, dass sich das nicht mehr fangen konnte sobald einmal mehr (also nach 255) auf ein low MISO gewartet werden muss.

    for(uint8_t i=0; i< 200;++i) {
      if( readReg(CC1101_MARCSTATE_REV00, CC1101_STATUS) != MarcStateTx)
        break;            //neither in RX nor TX, probably some error
      delay(1);
    }

[elektron-bbs]

Bei mir ähnlich: Ich hatte zuerst die originale Firmware noch drauf, keine 20 Sendungen im 4-Sekundentakt und es erfolgte kein Senden mehr, Arduino über FHEM nicht mehr ansprechbar, erst close und darauf reset erweckten ihn wieder zum Leben.

Ich habe dann den Code dahingehend geändert:

  for (uint8_t i=4;i<10;i++) { // pullup on for unused pins
    pinAsInputPullUp(i);
  }

Er sendet jetzt seit knapp 3 Stunden im 4-Sekundentakt ohne Auffälligkeiten. Bei GPIO 2 und 3 müssen die Pullups auch nicht eingeschaltet werden, da sie sowieso als PIN_RECEIVE und PIN_SEND später richtig initialisiert werden.

[elektron-bbs]

Was die Pullups betrifft - ich glaube das tut dem ATmega nicht weh, auf dem ESP kann das natuerlich anders sein. Jedenfalls

Ungenutzte Pins sollten IMMER in einen definierten Zustand versetzt werden.

[devzero84]

Ich weiss, aber der ATmega hat definierte Werte nach einem Reset - und wenn man die Funktion auf SPI stellt, sind dem evtl. eingestellte Weakpullups fuer den PORTB - jedenfalls fuer die SPI Pins - eigentlich egal. Hier kann es aber sein, dass sich der ESP32 (den Du ja glaube ich benutzt) anders verhaelt - nur darauf wollte ich hinaus. Ich habe den ESP32 zwar auch schon mit esp-idf (also ohne Arduino) programmiert, aber nie sonderlich low-level, sondern mit FreeRTOS Funktionen, daher kenne ich den nicht so gut. Die ATmegas schon.

Andere offene Inputs (die nicht ausgewertet oder irrtuemlich auf ein pinchange Interrupt konfiguriert sind) koennten im allgemeinen aber sogar floaten (auch wenn es nicht empfehlenswert ist), denn das kann EMV Probleme machen. Als Ausgang ist es ohnehin egal, also wenn sie offen sind. Generell stimme ich Dir aber zu, dass die Zustaende immer definiert sein sollten. Das habe ich nie bestritten.

[sidey79]

Er sendet jetzt seit knapp 3 Stunden im 4-Sekundentakt ohne Auffälligkeiten. Bei GPIO 2 und 3 müssen die Pullups auch nicht eingeschaltet werden, da sie sowieso als PIN_RECEIVE und PIN_SEND später richtig initialisiert werden.

Das hängt doch vom verwendeten Board und Reciver ab, welche Pins später noch initialisiert werden. Im Setup war daher mein Ansatz für alle Pins einen definierten Zustand zu erreichen unabhängig davon ob später mit dem Pin noch was passiert oder nicht.

In cc1101::setup werden die PINs definiert, da fehlt dann vermutlich einer? https://github.com/RFD-FHEM/SIGNALDuino/blob/00089bb67fe52c0af4ef22ec06a9cca9e9a31baf/src/cc1101.cpp#L313-L326

[elektron-bbs]

Das Aktivieren der Pullups erfolgt aber in der signalduino.h und da werden anschließend noch

pinAsInput(PIN_RECEIVE);
pinAsOutput(PIN_SEND);

gesetzt.

Ob in der cc1101.cpp überhaupt noch eine Initialisierung der SPI-Pins erforderlich ist, kann ich jetzt auf Anhieb nicht beurteilen.

[HomeAutoUser]

Wir müssen aufpassen, das wir die Themen nicht durcheinander wirbeln. ;-) Scheinbar besitzen wir 3 Fixes bzw. Fehlerhafte Punkte.

[devzero84]

@sidey79 hat jedenfalls Recht, mein Fix fixt zwar das Problem, dass es immer 0 sein kann, aber ich habe mir hier auch vertan. Da es niemals mehr 0 wird, also tendentiell - wenn sich alles aufhaengt und MISO High bleibt, fuer immer da stehen bleibt).

Gerne wuerde ich die miso_wait defines wegschmeissen und sauber in eine Funktion mit Rueckgabewert packen - ist das Konsens?

quasi sowas bool waitForMisoLow() { ...return true wenn OK, false wenn timeout zugeschlagen hat

Dann muesste man aber da jeweils ein if drum machen in readReg und Co, also if (!waitForMisoLow()) { return; }

Man kann das aber auch in das define reinvergewaltigen, mit einem do/while drumrum um den Scope zu haben, dann gehts ohne static und ohne redefinition error.

[devzero84]

Ich sehe gerade, es gibt ja schon eine cc1101::waitToMiso()

Eigentlich sollte man aus den zwei defines und dieser Funktion eine fuer alles machen - d.h. den Wert als Parameter.

[devzero84]

Aus meiner Sicht hat sich dies mit Mergen des Fixes erledigt. Soll ich das hier schliessen, oder hat jemand noch Anmerkungen?