Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle

[papa]

Ich denke, das Problem ist unabhängig vom Dimmer.

Fassen wir nochmal zusammen:

• Es tritt auch nur bei Geräten auf, die ständig empfangsbereit sind.
• Ein Sendevorgang belebt das Gerät wieder.
• BURST-Geräte scheinen nicht betroffen zu sein.
• ??? Schlechte Empfangsumgebungen scheinen das Problem zu verstärken ???

Tritt das eigentlich auch bei dem Si4431 & RFM69 Varianten auf ?

Meine Vermutung ist immer noch, dass irgendein Paket das CC1101 aus der Bahn wirft und wir das nur durch den Reset wieder ans laufen kriegen.

[Matsch]

[*] ??? Schlechte Empfangsumgebungen scheinen das Problem zu verstärken ???[/list]

Nach meinen Beobachtungen: NEIN.
Mit allem anderen gehe ich konform.

Ich kann keinen Unterschied in der Ausfallhäufigkeit sehen im Zusammenhang mit der Entfernung (immer das gleiche Gerät!). Mein CS liegt aber auch meist bei 0...2% und DC ist auch niedrig (6...15%).

[jp112sdl]

Nach meinen Beobachtungen: NEIN.
Mit allem anderen gehe ich konform.

Ich kann keinen Unterschied in der Ausfallhäufigkeit sehen im Zusammenhang mit der Entfernung (immer das gleiche Gerät!). Mein CS liegt aber auch meist bei 0...2% und DC ist auch niedrig (6...15%).

Hier auch so

Meine Vermutung ist immer noch, dass irgendein Paket das CC1101 aus der Bahn wirft und wir das nur durch den Reset wieder ans laufen kriegen.

Müsste man mal schauen, wie bzw. mit welchen Registerwerten eQ-3 bei seinen Geräten das CC1101 im Idle-Modus hinterlässt.

[Horbi]

Und schon wieder was gefunden, ist echt blöd das wir den Fehler nicht nachstellen können.

RXFIFO_OVERFLOW Issue —Radio stays in RX state instead of entering RXFIFO_OVERFLOW state
https://www.ti.com/lit/er/swrz020e/swrz ... 151390.pdf

Das was wir eingestellt haben ist:
1 (01) Variable packet length mode. Packet length configured by the first byte after sync word

Im Workaround steht dann folgendes:

In applications where the packets are short enough to fit in the RX FIFO and one wants
to wait for the whole packet to be received before starting to read the RX FIFO, for
variable packet length mode (PKTCTRL0.LENGTH_CONFIG=1) the PKTLEN register
should be set to 61 to make sure the whole packet including status bytes are 64 bytes or
less (length byte (61) + 61 payload bytes + 2 status bytes = 64 bytes) or PKTLEN ≤ 62

Ich begrenze die Paketlänge jetzt mal in der Radio-CC1101.h und teste...
CC1101_PKTLEN, 0x3D, // 0xFF

[Matsch]

Ich begrenze die Paketlänge jetzt mal in der Radio-CC1101.h und teste...

dito


PS:
Ich habe 3 Steckdosen umgeflasht. Einen negativen Effekt durch die verkürzte Paketlänge konnte ich bisher nicht beobachten. Bisher ist in meinem Stresstest (toggeln aller 5 min) nach 12 h (also knapp 150 Schaltvorgänge) noch kein solcher Ausfall wieder aufgetreten.
Aber noch ist nicht aller Tage Abend.

[Matsch]

Es sieht nicht so aus, als würde das irgendwas bringen. Schon wieder die bekannten Ausfälle auf 2 von 3 Geräten - innerhalb von 14 h.

Wie reagiert die Firmware eigentlich auf Overflow-Signalisierung?

Nachtrag: Nach 15 h ist zeigt sich auch beim dritten Gerät wieder die bekannte Macke ...

[Horbi]

Es sieht nicht so aus, als würde das irgendwas bringen. Schon wieder die bekannten Ausfälle auf 2 von 3 Geräten - innerhalb von 14 h.

Wie reagiert die Firmware eigentlich auf Overflow-Signalisierung?

Nachtrag: Nach 15 h ist zeigt sich auch beim dritten Gerät wieder die bekannte Macke ...

Sehr schade, hatte gehofft das wir dem Fehler näher kommen.

Auf Overflow Signalisierung wird gar nicht reagiert.
Basierend auf GDO0 Änderung wird ein Interrupt ausgelöst der ein READ flag setzt.
Die Funktion read wird per loop ständig durchlaufen und prüft ob das READ flag gesetzt ist.
Wenn ja, wird der RX Buffer kopiert und im cc1101 zurück gesetzt.
Zum Kopieren des Buffers wird die Länge gelesen, ist die zu groß, wird nichts gelesen, sondern direkt geleert.

Ich habe ja eine ganze Weile das Overflow Flag ausgelesen - hatte bei mir aber keinen Treffer.
Kannst ja bei Dir mal das Chip Status Byte beobachten, vielleicht gibts bei Dir wirklich eine Overflow Signalisierung auf die wir reagieren können.

Edit: Ich glaube Du kannst Dir das Auslesen des Overflow Flags sparen. Für den GDO0 ist folgendes eingestellt:

Asserts when sync word has been sent / received, and de-asserts at the end of the packet. In RX, the pin will also deassert when a packet is discarded due to address or maximum length filtering or when the radio enters RXFIFO_OVERFLOW state. In TX the pin will de-assert if the TX FIFO underflows.

Fallende Flanke löst den Interrupt aus, das READ flag wird gesetzt.
Beim nächsten Poll wird der Buffer gelesen. Wegen des RXFIFO_OVERFLOW state wird die Länge auf 0 gesetzt und damit ist read auch schon beendet.

Wir brauchen eine neue Idee

[Horbi]

Mir lässt das ganze keine Ruhe, deshalb eine neue Theorie
Was wäre wenn im Funkmodul was schief geht und wir aus irgendeiner do while loop nicht mehr rauskommen?

In der Funktion sndData wäre so ein Beispiel. Der cc1101 wird in idle versetzt und der TX buffer wird gelöscht.
Als nächstes wird versucht in den TX mode zu schalten, dabei wird ein Timeout von 200 x 100us gegeben und runtergezählt.

Ist der Chip während dieser Zeit nicht im TX mode, wird ein Chipreset ausgelöst und danach per loop in den RX mode geschaltet.
In der loop zum RX mode gibt es aber kein Timeout mehr, d.h. wenn der Softreset nicht arbeitet und der Chip auf SRX nicht reagiert, bleibt der Arduino in der loop hängen.

Code: Alles auswählen

  uint8_t sndData(uint8_t *buf, uint8_t size, uint8_t burst) {
    // Going from RX to TX does not work if there was a reception less than 0.5
    // sec ago. Due to CCA? Using IDLE helps to shorten this period(?)
    spi.strobe(CC1101_SIDLE);  // go to idle mode
    spi.strobe(CC1101_SFTX );  // flush TX buffer

    uint8_t i=200;
    do {
      spi.strobe(CC1101_STX);
      _delay_us(100);
      if( --i == 0 ) {
        // can not enter TX state - reset fifo
        spi.strobe(CC1101_SIDLE );
        spi.strobe(CC1101_SFTX  );
        spi.strobe(CC1101_SNOP );
        // back to RX mode
        do { spi.strobe(CC1101_SRX);
        } while (spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_RX);
        return false;
      }
    }
    while(spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_TX);

Bisher sind wir von einem Empfangsproblem ausgegangen, aber jedes Paket wird ja auch quittiert.
Falls jemand testen möchte, hier die Änderung in der Radio-cc1101.h

Code: Alles auswählen

  uint8_t sndData(uint8_t *buf, uint8_t size, uint8_t burst) {
    // Going from RX to TX does not work if there was a reception less than 0.5
    // sec ago. Due to CCA? Using IDLE helps to shorten this period(?)
    spi.strobe(CC1101_SIDLE);  // go to idle mode
    spi.strobe(CC1101_SFTX );  // flush TX buffer

    uint8_t i=200;
    do {
      spi.strobe(CC1101_STX);
      _delay_us(100);
      if( --i == 0 ) {
        // can not enter TX state - reset fifo
        spi.strobe(CC1101_SIDLE );
        spi.strobe(CC1101_SFTX  );
        spi.strobe(CC1101_SNOP );
        // back to RX mode
        waitRXmode(1);
        /*do { spi.strobe(CC1101_SRX);
        } while (spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_RX);*/
        return false;
      }
    }
    while(spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_TX);

    _delay_ms(10);
    if (burst) {         // BURST-bit set?
      _delay_ms(350);    // according to ELV, devices get activated every 300ms, so send burst for 360ms
    }

    spi.writeReg(CC1101_TXFIFO, size);
    spi.writeBurst(CC1101_TXFIFO | WRITE_BURST, buf, size);           // write in TX FIFO

    waitRXmode();
    /*for (uint8_t i = 0; i < 200; i++) {  // after sending out all bytes the chip should go automatically in RX mode
      if( spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) == MARCSTATE_RX)
        break;                                    //now in RX mode, good
      _delay_us(100);
    }*/
    return true;
  }

  void waitRXmode(uint8_t strobeSRX = 0) {
    uint8_t i = 200;
    do {
      if (strobeSRX) spi.strobe(CC1101_SRX);
      _delay_us(100);
      if (--i == 0) DPRINT(F("return to RX error"));
    } while (spi.readReg(CC1101_MARCSTATE, CC1101_STATUS) != MARCSTATE_RX);
  }

[papa]

Dann würde aber ein Tastendruck auch nciht mehr funktionieren.

[Horbi]

Dann würde aber ein Tastendruck auch nciht mehr funktionieren.

Eventuell ja doch, was wenn der SRX etwas Zeit braucht um gesetzt zu werden und die Abfrage und damit das erneute Setzen zu schnell kommt.
Dann würde der Pin-Interrupt immerhin etwas Zeit verschaffen.
Ist aber alles Spekulation, mit der Änderung in der Radio-cc1101.h sehen wir jetzt zumindest eine Debug Message