CUL HM empfängt nicht oder sendet Empfangsdaten nicht an den Rechner

Begonnen von noansi, 04 Mai 2014, 16:51:04

Vorheriges Thema - Nächstes Thema

tpm88

Zitat von: rudolfkoenig am 27 Mai 2014, 08:38:51
Sicher, ich haette nur gerne noch feedback von einem weiteren Benutzer mit viel HM Hardware.

Hallo Ansgar, Rudi,

ich lese das Thema schon eine Weile mit Interesse mit - ich beobachte ähnliche Phänomene bei meinem CULv3 an einer FB7390. Gelegentlich meldet der ActionDetector alle meine vier RT-DN HM Thermostate als dead - nach einiger Zeit (wenige Stunden) funktionieren sie plötzlich wieder.


2014-05-17_16:56:51 ActionDetector alive:4 dead:0 unkn:0 off:0
2014-05-20_03:37:23 ActionDetector status_dg_Thermostat: dead
2014-05-20_03:37:23 ActionDetector status_az_Thermostat: dead
2014-05-20_03:37:23 ActionDetector status_wz_Thermostat: dead
2014-05-20_03:37:23 ActionDetector status_bd_Thermostat: dead
2014-05-20_03:37:23 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-20_04:27:24 ActionDetector status_dg_Thermostat: alive
2014-05-20_04:27:24 ActionDetector status_az_Thermostat: alive
2014-05-20_04:27:24 ActionDetector status_wz_Thermostat: alive
2014-05-20_04:27:24 ActionDetector status_bd_Thermostat: alive
2014-05-20_04:27:24 ActionDetector alive:4 dead:0 unkn:0 off:0
2014-05-20_19:57:32 ActionDetector status_dg_Thermostat: dead
2014-05-20_19:57:32 ActionDetector status_az_Thermostat: dead
2014-05-20_19:57:32 ActionDetector status_wz_Thermostat: dead
2014-05-20_19:57:32 ActionDetector status_bd_Thermostat: dead
2014-05-20_19:57:32 ActionDetector alive:0 dead:4 unkn:0 off:0
2014-05-21_06:47:47 ActionDetector status_dg_Thermostat: alive
2014-05-21_06:47:47 ActionDetector status_az_Thermostat: alive
2014-05-21_06:47:47 ActionDetector status_bd_Thermostat: alive
2014-05-21_06:47:47 ActionDetector alive:3 dead:1 unkn:0 off:0
2014-05-21_06:57:47 ActionDetector status_wz_Thermostat: alive
2014-05-21_06:57:47 ActionDetector alive:4 dead:0 unkn:0 off:0


Dazu zeitlich passend habe ich einen Sendefehler am 21.05. um 05:30 Uhr - hier wird die Heizungspumpe via HM aktiviert:

2014-05-21_05:30:00 ke_Pumpe set_on-for-timer 5400
2014-05-21_05:30:15 ke_Pumpe ResndFail
2014-05-21_05:30:15 ke_Pumpe MISSING ACK


Bin gerne bereit, hier ggf. mit einer geänderten CUL FW zu testen.

Gruss
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

noansi

Hallo Rudolf, hallo Tobias,


ok, dann hier die Codeänderungen. Ich möchte es noch beta nennen, da sicherlich noch optimierbar. Für TX, also Senderichtung habe ich es auch gleich eingebaut. Vielleicht kann Martin das Timingtechnisch nochmal für den Normalfall, also ohne PLL Lock Problem, mal gegen checken.


Mit

attr CUL_0 verbose 2

für den CUL (CUL_0 ggf. anpassen) werden die eingebauten Meldungen ins Log geschrieben.

Ausgegeben werden:
PLLERR , wenn der Registerzustand aus meinen Logs im RX State erkannt wird und aufgrund dessen rf_asksin_init aufgerufen wird (die harte Methode, da damit auch SRES ausgeführt wird).
PLLNOLOCK , wenn der CUL ohne PLL Lock erwischt wird. Dann wird die Kalibrierung versucht.
PLLLOCKFAIL , wenn mehrere Versuche des Kalibrierens nicht zu einem erfolgreichen PLL Lock führen.


@Rudolf: Danke für den Speicherhinweis! Wäre schön, wenn Du das Speichertechnisch für CUL_V2 mal checken könntest. Die Ausgaben zu size verstehe ich noch nicht ganz und möchte nicht fehlinterpretieren.

@Tobias: Danke für Deine Problemnachricht. Zur Fritz!Box 7390 darf ich aus eigener Erfahrung sagen, dass die USB Stromversorgung da auch eine Rolle spielen kann (siehe auch Rudolfs und Jens Tipps und Hinweise zur Stromversorgung), zumindest mit USB-Sticks (CUL war noch nie daran angeschlossen) hatte ich da Probleme, die sich mit einem dickeren Netzteil beheben ließen. Das original Netzteil hatte das auch anfangs mit gemacht aber ist dann nach ca. 1 Jahr Betrieb etwas eingebrochen. Wenn Du also mehr als nur den CUL daran hängen hast, dann kann die Stromversorgung auch Problemursache sein.
Wenn Du nicht gerade einen CUL_V2 (und damit eventuell zu wenig Programmspeicherplatz) hasst, dann würde ich mich freuen, von Deinen Erfahrungen mit der Firmwareänderung zu lesen. Bitte auch den verbose Modus für den CUL auf 2 setzen, damit es im Log auch sichtbar wird.


Hier der diff zu rf_asksin.c:

--- rf_asksin.c 2014-03-13 21:49:42.000000000 +0100
+++ clib/rf_asksin.c 2014-05-27 23:03:27.896030622 +0200
@@ -58,6 +58,10 @@
#endif

static void rf_asksin_reset_rx(void);
+static void rf_asksin_toRX(void);
+static void rf_asksin_toTX(void);
+static uint8_t asksin_checkPLL(void);  // noansi: returns 0 on success
+

void
rf_asksin_init(void)
@@ -90,24 +94,26 @@
     }
   }
#endif

+
   ccStrobe( CC1100_SCAL );

   my_delay_ms(4);

   // enable RX, but don't enable the interrupt
-  do {
-    ccStrobe(CC1100_SRX);
-  } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+ // noansi: check PLL is in Lock in RX
+ rf_asksin_toRX();
}

+
static void
rf_asksin_reset_rx(void)
{
+  ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
   ccStrobe( CC1100_SFRX  );
-  ccStrobe( CC1100_SIDLE );
-  ccStrobe( CC1100_SNOP  );
-  ccStrobe( CC1100_SRX   );
+  //ccStrobe( CC1100_SIDLE );
+  //ccStrobe( CC1100_SNOP  );
+  //ccStrobe( CC1100_SRX   );
+ rf_asksin_toRX(); // noansi: try to set RX with calibration
}

void
@@ -143,9 +149,7 @@

     CC1100_DEASSERT;

-    do {
-      ccStrobe(CC1100_SRX);
-    } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+    rf_asksin_toRX();

     last_enc = msg[1];
     msg[1] = (~msg[1]) ^ 0x89;
@@ -178,14 +182,33 @@
   }

   switch(cc1100_readReg( CC1100_MARCSTATE )) {
+    case MARCSTATE_RX:
+ // noansi: try init, if stuck in RX State with no PLL Lock as seen in extended read timeout logging
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l == 0x3f) { // noansi: no PLL Lock as described in CC1101 errata
+ l = cc1100_readReg( CC1100_FSCAL3 );
+ if (l == 0xaf) { // noansi: saw this too, if no data is received any more for a long period of time (up to 2 hours)
+ DS_P(PSTR("PLLERR\r\n"));
+ rf_asksin_init(); // noansi: try init to recover
+ return;
+ }
+ }
+ break;
     case MARCSTATE_RXFIFO_OVERFLOW:
+      ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
       ccStrobe( CC1100_SFRX  );
     case MARCSTATE_IDLE:
-      ccStrobe( CC1100_SIDLE );
-      ccStrobe( CC1100_SNOP  );
-      ccStrobe( CC1100_SRX   );
+      //ccStrobe( CC1100_SIDLE );
+      //ccStrobe( CC1100_SNOP  );
+      //ccStrobe( CC1100_SRX   );
+ rf_asksin_toRX(); // noansi: try to set RX with calibration
       break;
   }
+
+ if (asksin_checkPLL()) // noansi: check PLL is in Lock
+ {
+ rf_asksin_toRX(); // noansi: try to set RX with calibration
+ }
}

void
@@ -218,10 +241,8 @@
   
   msg[l] = msg[l] ^ ctl;

-  // enable TX, wait for CCA
-  do {
-    ccStrobe(CC1100_STX);
-  } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_TX);
+ // noansi: set TX with check/try PLL is in Lock in TX
+ rf_asksin_toTX();

   if (ctl & (1 << 4)) { // BURST-bit set?
     // According to ELV, devices get activated every 300ms, so send burst for 360ms
@@ -252,14 +273,118 @@
   }
   
   if(asksin_on) {
-    do {
-      ccStrobe(CC1100_SRX);
-    } while (cc1100_readReg(CC1100_MARCSTATE) != MARCSTATE_RX);
+ // noansi: set RX with check/try PLL is in Lock in RX
+ rf_asksin_toRX();
   } else {
     set_txrestore();
   }
}

+static void
+rf_asksin_toRX(void)
+{
+ uint8_t n;
+ uint8_t t;
+
+ // noansi: set RX with check/try PLL is in Lock in RX
+ n = 5; // noansi: Try to set several times before giving up
+ do {
+ // enable RX
+ t = 255;
+ do {
+ ccStrobe(CC1100_SRX);
+ if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_RX) break;
+ my_delay_us(5);
+ } while (--t);
+
+ //if (!t) DS_P(PSTR("PLLNORX\r\n"));
+
+ if (!asksin_checkPLL()) return;
+ } while (--n);
+
+ //if (!n) DS_P(PSTR("PLLRXFAIL\r\n"));
+}
+
+static void
+rf_asksin_toTX(void)
+{
+ uint8_t n;
+ uint8_t t;
+
+ // noansi: set TX with check/try PLL is in Lock in TX
+ n = 5; // noansi: Try to set several times before giving up
+ do {
+ // enable TX, wait for CCA
+ t = 255;
+ do {
+ ccStrobe(CC1100_STX);
+ if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_TX) break;
+ my_delay_us(5);
+ } while (--t);
+
+ //if (!t) DS_P(PSTR("PLLNOTX\r\n"));
+
+ if (!asksin_checkPLL()) return;
+ } while (--n);
+
+ //if (!n) DS_P(PSTR("PLLTXFAIL\r\n"));
+}
+
+static uint8_t
+asksin_checkPLL(void)  // noansi: returns 0 on success
+{
+ uint8_t n;
+ uint8_t l;
+
+ // noansi: check PLL Lock and try to calibrate. Possibly restoring a saved calibration could be faster...
+ n = 5; // noansi: Try to recover several times before giving up
+ do
+ {
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata
+
+ // noansi: try to recover as no PLL Lock as described in CC1101 doc and errata
+      ccStrobe( CC1100_SIDLE );
+ DS_P(PSTR("PLLNOLOCK\r\n"));
+ // noansi: wait idle state, is it needed here?
+ l = 255;
+ do
+ {
+ if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_IDLE) break;
+ my_delay_us(1);
+ }
+ while (--l);
+
+ ccStrobe( CC1100_SCAL ); // noansi: Try Calibration
+
+ //if (!l) DS_P(PSTR("PLLNOIDLE\r\n"));
+
+ //my_delay_ms(1); // noansi: maybe waiting gives a better calibration instead of polling the state (noise)
+
+ // noansi: wait idle state -> calibration finished
+ l = 255;
+ do
+ {
+ if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_IDLE) break;
+ my_delay_us(10);
+ }
+ while (--l);
+
+ //if (!l) DS_P(PSTR("PLLNOCALIDLE\r\n"));
+ }
+ while (--n);
+
+ //rf_asksin_init(); // noansi: Try Init ... no could flood stack recursively...
+
+ l = cc1100_readReg( CC1100_FSCAL1 );
+ if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata
+
+ DS_P(PSTR("PLLLOCKFAIL\r\n"));
+
+ return 1; // noansi: error, no PLL Lock
+}
+
+
void
asksin_func(char *in)
{



Für die, die die komplette geänderte rf_asksin.c ansehen möchten:

#include "board.h"
#ifdef HAS_ASKSIN
#include <string.h>
#include <avr/pgmspace.h>
#include "cc1100.h"
#include "delay.h"
#include "rf_receive.h"
#include "display.h"

#include "rf_asksin.h"

uint8_t asksin_on = 0;

const uint8_t PROGMEM ASKSIN_CFG[] = {
     0x00, 0x07,
     0x02, 0x2e,
     0x03, 0x0d,
     0x04, 0xE9,
     0x05, 0xCA,
     0x07, 0x0C,
     0x0B, 0x06,
     0x0D, 0x21,
     0x0E, 0x65,
     0x0F, 0x6A,
     0x10, 0xC8,
     0x11, 0x93,
     0x12, 0x03,
     0x15, 0x34,
     0x17, 0x33, // go into RX after TX, CCA; EQ3 uses 0x03
     0x18, 0x18,
     0x19, 0x16,
     0x1B, 0x43,
     0x21, 0x56,
     0x25, 0x00,
     0x26, 0x11,
     0x29, 0x59,
     0x2c, 0x81,
     0x2D, 0x35,
     0x3e, 0xc3
};

#ifdef HAS_ASKSIN_FUP
const uint8_t PROGMEM ASKSIN_UPDATE_CFG[] = {
     0x0B, 0x08,
     0x10, 0x5B,
     0x11, 0xF8,
     0x15, 0x47,
     0x19, 0x1D,
     0x1A, 0x1C,
     0x1B, 0xC7,
     0x1C, 0x00,
     0x1D, 0xB2,
     0x21, 0xB6,
     0x23, 0xEA,
};

static unsigned char asksin_update_mode = 0;
#endif

static void rf_asksin_reset_rx(void);
static void rf_asksin_toRX(void);
static void rf_asksin_toTX(void);
static uint8_t asksin_checkPLL(void);  // noansi: returns 0 on success


void
rf_asksin_init(void)
{

  EIMSK &= ~_BV(CC1100_INT);                 // disable INT - we'll poll...
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );   // CS as output

  CC1100_DEASSERT;                           // Toggle chip select signal
  my_delay_us(30);
  CC1100_ASSERT;
  my_delay_us(30);
  CC1100_DEASSERT;
  my_delay_us(45);

  ccStrobe( CC1100_SRES );                   // Send SRES command
  my_delay_us(100);

  // load configuration
  for (uint8_t i = 0; i < sizeof(ASKSIN_CFG); i += 2) {
    cc1100_writeReg( pgm_read_byte(&ASKSIN_CFG[i]),
                     pgm_read_byte(&ASKSIN_CFG[i+1]) );
  }

#ifdef HAS_ASKSIN_FUP
  if (asksin_update_mode) {
    for (uint8_t i = 0; i < sizeof(ASKSIN_UPDATE_CFG); i += 2) {
      cc1100_writeReg( pgm_read_byte(&ASKSIN_UPDATE_CFG[i]),
                       pgm_read_byte(&ASKSIN_UPDATE_CFG[i+1]) );
    }
  }
#endif

  ccStrobe( CC1100_SCAL );

  my_delay_ms(4);

  // enable RX, but don't enable the interrupt
// noansi: check PLL is in Lock in RX
rf_asksin_toRX();
}


static void
rf_asksin_reset_rx(void)
{
  ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
  ccStrobe( CC1100_SFRX  );
  //ccStrobe( CC1100_SIDLE );
  //ccStrobe( CC1100_SNOP  );
  //ccStrobe( CC1100_SRX   );
rf_asksin_toRX(); // noansi: try to set RX with calibration
}

void
rf_asksin_task(void)
{
  uint8_t msg[MAX_ASKSIN_MSG];
  uint8_t this_enc, last_enc;
  uint8_t rssi;
  uint8_t l;

  if(!asksin_on)
    return;

  // see if a CRC OK pkt has been arrived
  if (bit_is_set( CC1100_IN_PORT, CC1100_IN_PIN )) {
    msg[0] = cc1100_readReg( CC1100_RXFIFO ) & 0x7f; // read len

    if (msg[0] >= MAX_ASKSIN_MSG) {
      // Something went horribly wrong, out of sync?
      rf_asksin_reset_rx();
      return;
    }

    CC1100_ASSERT;
    cc1100_sendbyte( CC1100_READ_BURST | CC1100_RXFIFO );
   
    for (uint8_t i=0; i<msg[0]; i++) {
         msg[i+1] = cc1100_sendbyte( 0 );
    }
   
    rssi = cc1100_sendbyte( 0 );
    /* LQI = */ cc1100_sendbyte( 0 );

    CC1100_DEASSERT;

    rf_asksin_toRX();

    last_enc = msg[1];
    msg[1] = (~msg[1]) ^ 0x89;
   
    for (l = 2; l < msg[0]; l++) {
         this_enc = msg[l];
         msg[l] = (last_enc + 0xdc) ^ msg[l];
         last_enc = this_enc;
    }
   
    msg[l] = msg[l] ^ msg[2];
   
    if (tx_report & REP_BINTIME) {
     
      DC('a');
      for (uint8_t i=0; i<=msg[0]; i++)
      DC( msg[i] );
         
    } else {
      DC('A');
     
      for (uint8_t i=0; i<=msg[0]; i++)
        DH2( msg[i] );
     
      if (tx_report & REP_RSSI)
        DH2(rssi);
     
      DNL();
    }
  }

  switch(cc1100_readReg( CC1100_MARCSTATE )) {
    case MARCSTATE_RX:
// noansi: try init, if stuck in RX State with no PLL Lock as seen in extended read timeout logging
l = cc1100_readReg( CC1100_FSCAL1 );
if (l == 0x3f) { // noansi: no PLL Lock as described in CC1101 errata
l = cc1100_readReg( CC1100_FSCAL3 );
if (l == 0xaf) { // noansi: saw this too, if no data is received any more for a long period of time (up to 2 hours)
DS_P(PSTR("PLLERR\r\n"));
rf_asksin_init(); // noansi: try init to recover
return;
}
}
break;
    case MARCSTATE_RXFIFO_OVERFLOW:
      ccStrobe( CC1100_SIDLE ); // noansi: if stuck in RX after RX OVERFLOW as described in CC1101 errata -> do SFRX only in IDLE as CC1101 doc
      ccStrobe( CC1100_SFRX  );
    case MARCSTATE_IDLE:
      //ccStrobe( CC1100_SIDLE );
      //ccStrobe( CC1100_SNOP  );
      //ccStrobe( CC1100_SRX   );
rf_asksin_toRX(); // noansi: try to set RX with calibration
      break;
  }

if (asksin_checkPLL()) // noansi: check PLL is in Lock
{
rf_asksin_toRX(); // noansi: try to set RX with calibration
}
}

void
asksin_send(char *in)
{
  uint8_t msg[MAX_ASKSIN_MSG];
  uint8_t ctl;
  uint8_t l;

  uint8_t hblen = fromhex(in+1, msg, MAX_ASKSIN_MSG-1);

  if ((hblen-1) != msg[0]) {
//  DS_P(PSTR("LENERR\r\n"));
    return;
  }

  // in AskSin mode already?
  if(!asksin_on) {
    rf_asksin_init();
    my_delay_ms(3);             // 3ms: Found by trial and error
  }

  ctl = msg[2];

  // "crypt"
  msg[1] = (~msg[1]) ^ 0x89;

  for (l = 2; l < msg[0]; l++)
    msg[l] = (msg[l-1] + 0xdc) ^ msg[l];
 
  msg[l] = msg[l] ^ ctl;

// noansi: set TX with check/try PLL is in Lock in TX
rf_asksin_toTX();

  if (ctl & (1 << 4)) { // BURST-bit set?
    // According to ELV, devices get activated every 300ms, so send burst for 360ms
    for(l = 0; l < 3; l++)
      my_delay_ms(120); // arg is uint_8, so loop
  } else {
  my_delay_ms(10);
  }

  // send
  CC1100_ASSERT;
  cc1100_sendbyte(CC1100_WRITE_BURST | CC1100_TXFIFO);

  for(uint8_t i = 0; i < hblen; i++) {
    cc1100_sendbyte(msg[i]);
  }

  CC1100_DEASSERT;

  // wait for TX to finish
  while(cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_TX)
    ;

  if (cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_TXFIFO_UNDERFLOW) {
      ccStrobe( CC1100_SFTX  );
      ccStrobe( CC1100_SIDLE );
      ccStrobe( CC1100_SNOP  );
  }
 
  if(asksin_on) {
// noansi: set RX with check/try PLL is in Lock in RX
rf_asksin_toRX();
  } else {
    set_txrestore();
  }
}

static void
rf_asksin_toRX(void)
{
uint8_t n;
uint8_t t;

// noansi: set RX with check/try PLL is in Lock in RX
n = 5; // noansi: Try to set several times before giving up
do {
// enable RX
t = 255;
do {
ccStrobe(CC1100_SRX);
if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_RX) break;
my_delay_us(5);
} while (--t);

//if (!t) DS_P(PSTR("PLLNORX\r\n"));

if (!asksin_checkPLL()) return;
} while (--n);

//if (!n) DS_P(PSTR("PLLRXFAIL\r\n"));
}

static void
rf_asksin_toTX(void)
{
uint8_t n;
uint8_t t;

// noansi: set TX with check/try PLL is in Lock in TX
n = 5; // noansi: Try to set several times before giving up
do {
// enable TX, wait for CCA
t = 255;
do {
ccStrobe(CC1100_STX);
if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_TX) break;
my_delay_us(5);
} while (--t);

//if (!t) DS_P(PSTR("PLLNOTX\r\n"));

if (!asksin_checkPLL()) return;
} while (--n);

//if (!n) DS_P(PSTR("PLLTXFAIL\r\n"));
}

static uint8_t
asksin_checkPLL(void)  // noansi: returns 0 on success
{
uint8_t n;
uint8_t l;

// noansi: check PLL Lock and try to calibrate. Possibly restoring a saved calibration could be faster...
n = 5; // noansi: Try to recover several times before giving up
do
{
l = cc1100_readReg( CC1100_FSCAL1 );
if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata

// noansi: try to recover as no PLL Lock as described in CC1101 doc and errata
      ccStrobe( CC1100_SIDLE );
DS_P(PSTR("PLLNOLOCK\r\n"));
// noansi: wait idle state, is it needed here?
l = 255;
do
{
if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_IDLE) break;
my_delay_us(1);
}
while (--l);

ccStrobe( CC1100_SCAL ); // noansi: Try Calibration

//if (!l) DS_P(PSTR("PLLNOIDLE\r\n"));

//my_delay_ms(1); // noansi: maybe waiting gives a better calibration instead of polling the state (noise)

// noansi: wait idle state -> calibration finished
l = 255;
do
{
if (cc1100_readReg(CC1100_MARCSTATE) == MARCSTATE_IDLE) break;
my_delay_us(10);
}
while (--l);

//if (!l) DS_P(PSTR("PLLNOCALIDLE\r\n"));
}
while (--n);

//rf_asksin_init(); // noansi: Try Init ... no could flood stack recursively...

l = cc1100_readReg( CC1100_FSCAL1 );
if (l != 0x3f) return 0; // noansi: PLL in Lock as described in CC1101 doc and errata

DS_P(PSTR("PLLLOCKFAIL\r\n"));

return 1; // noansi: error, no PLL Lock
}


void
asksin_func(char *in)
{
#ifndef HAS_ASKSIN_FUP
  if(in[1] == 'r') {                // Reception on
#else
  if((in[1] == 'r') || (in[1] == 'R')) {                // Reception on
    if (in[1] == 'R') {
      asksin_update_mode = 1;
    } else {
      asksin_update_mode = 0;
    }
#endif
    rf_asksin_init();
    asksin_on = 1;

  } else if(in[1] == 's') {         // Send
    asksin_send(in+1);

  } else {                          // Off
    asksin_on = 0;

  }
}

#endif



Erfahrungsberichte und Verbesserungsvorschläge werden gerne entgegen genommen.


Gruß, Ansgar.

rudolfkoenig

ZitatWäre schön, wenn Du das Speichertechnisch für CUL_V2 mal checken könntest.

Size:
   text       data        bss        dec        hex    filename
  11404         16        313      11733       2dd5    CUL_V2_HM.elf

11404+16 = 11420 < 12288 (12k)

-> Flash reicht, und Moeglichkeiten zum optimieren der Groesse gibt es auch noch reichlich.

martinp876

Zum Thema Timing:
ein HM device ist timingseitig einer CUL aus 2 Gründen überlegen:
1) es sendet selbständig ACK => das wird man nicht in eine CUL einbauen können/wollen
2) es sendet einen Timestamp mit jeder empfangenen Message aus der Luft

Punkt 2) wäre der eingentliche Bringer, eine CUL voran zu bringen. Man müsste einen Timer  mit msec auflösung laufen lassen und diesen Zeitstempel zusammen mit der Nachricht an die Zentrale senden. Dort kann dann mit hinreichender Genauigkeit die Verzögerung zwischen RF-receiver und FHEM-verarbeitung ausgerechnet werden. So mache ich dies auch mit HMLAN.

Schön wäre auch ein keep-alive - also ein Ping. Das regelmässige senden und die Antwort (mit zeitstempel) addiert einen Level an Genauigkeit. Erfahrungsgemäß sind die Quarze sehr schlecht (ich vermute, HMLAN hat gar keinen Quarz - zumindest ist das Timing nicht davon abgeleitet - zu schlecht). Das Delay alle 30sec zu prüfen ist daher sehr hilfreich.

Gruss Martin

tpm88

Zitat von: noansi am 27 Mai 2014, 23:11:27

@Tobias: Danke für Deine Problemnachricht. Zur Fritz!Box 7390 darf ich aus eigener Erfahrung sagen, dass die USB Stromversorgung da auch eine Rolle spielen kann (siehe auch Rudolfs und Jens Tipps und Hinweise zur Stromversorgung), zumindest mit USB-Sticks (CUL war noch nie daran angeschlossen) hatte ich da Probleme, die sich mit einem dickeren Netzteil beheben ließen. Das original Netzteil hatte das auch anfangs mit gemacht aber ist dann nach ca. 1 Jahr Betrieb etwas eingebrochen. Wenn Du also mehr als nur den CUL daran hängen hast, dann kann die Stromversorgung auch Problemursache sein.
Wenn Du nicht gerade einen CUL_V2 (und damit eventuell zu wenig Programmspeicherplatz) hasst, dann würde ich mich freuen, von Deinen Erfahrungen mit der Firmwareänderung zu lesen. Bitte auch den verbose Modus für den CUL auf 2 setzen, damit es im Log auch sichtbar wird.


Hi Ansgar,
Stromversorgung kann ich ausschliessen, denn es hängt zwar noch mehr dran an der 7390 - allerdings an einem aktiven Hub. Den CUL habe ich direkt an den zweiten USB-Port der FB7390 angeschlossen. Die FB7390 selbst wird von einem 12V 4A stabilisierten Labornetzteil gespeist. Da sollte nichts einbrechen...

Ich habe einen CUL_V3, mit dem Platz also auch keine Probleme. Könntest Du mir bitte die modifizierte Firmware als hex File schicken?
Dann teste ich gerne...

Gruss
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

noansi

Hallo Martin, hallo Rudolf,

@Rudolf: Danke für den check. Jetzt ist mir die size Ausgabe klar, was den Programmspeicher angeht. Und schön, dass noch was geht.

@Martin: Ich dachte zwar eigentlich an einen Check, ob mit den Änderungen Timingprobleme zu befürchten sind.
Aber macht nix, einen ms Timer habe ich jetzt mal mit dem auf dem CUL noch freien Timer 3 am laufen und er spuckt mir nach jedem Empfangstelegramm noch eine Zeile mit TS<Zeitstempel><NL> aus. Der Zeitstempel ist ein 32bit ms Zähler, der dezimal ausgegeben wird. Natürlich läuft der Zähler auch mal über und beim CUL Neustart wird er auf 0 gesetzt.
Wie hättest Du denn gerne den Zeitstempel ausgegeben/angehangen/Hex ???? Welches Komando für das ECHO und wie das Echo-Antwortformat???

Zu dumm, das Timer 3 bei CUR auch im Quelltext steht. Ganz so easy allgemein wird es also nicht.

Gruß, Ansgar.

rudolfkoenig

Das CUR stammt noch vor der HM@culfw Zeit, und es hat HM nie wirklich unterstuetzt, es sei denn, man verwendet das CUR als teuren CUL. Es gibt mWn insg. 3 Exemplare davon, du brauchst also keine Ruecksicht zu nehmen. Man muss nur "HAS_ASKSIN" aus Devices/CUR/board.h entfernen.

Der Zeitstempel muss an die A Nachricht angehaengt werden, damit in CUL.pm keine Sonderbehandlung noetig ist.

tpm88

Zitat von: rudolfkoenig am 27 Mai 2014, 08:38:51
Sicher, ich haette nur gerne noch feedback von einem weiteren Benutzer mit viel HM Hardware.

So - ich habe jetzt auch die von noansi modifizierte Firmware auf meinem CUL. Der Loglevel ist auf verbose 2 gesetzt.

Da bei mir die Aussetzer, die ich über den ActionDetector bemerkt habe, nur alle paar Tage auftraten, heisst es jetzt abzuwarten.

Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

noansi

Hallo Martin, hallo Rudolf,


zum Zeitstempel bei Asksin wäre mein Vorschlag:

- per default aus, da derzeit nicht bei allen CULs einbaubar

- Aktivierbar mit AT und de-aktivierbar mit At

- wird als T<Empfangs Zeitstempel in Hex> an die Nachricht angehangen, also AllnnffttssssssddddddppTtttttttt\r\n
   Der Zeitstempel wird nach dem Einlesen aus dem cc1101 FIFO und erneutem Aktivieren des Empfangs genommen.
   Da ohnehin nur gepollt wird, ob was angekommen ist, wird das ausreichend genau sein, denke ich.

- Ping mit Ap antwortet mit ATtttttttt\r\n


@Martin: Wenn es auch 16 Bit tun, dann nur Ttttt. Was brauchst Du?

@Rudolf: was ist mit dem RSSI? Da müsstest Du wohl noch eine Kleinigkeit ändern. Hab ich noch was übersehen?

Wenn Ihr damit einverstanden seid, dann ist es quasi in der Firmware für CUL_V3 fertig und läuft bei mir im Test.


Gruß, Ansgar.

rudolfkoenig

Wenn RSSI weiterhin hinten drangehaengt wird, dann nicht.

tpm88

Hallo Ansgar,

verändern deine Anpassungen an der Firmware irgendwie das Timing? Mir sind eben einige Fehler, Resends aufgefallen im HMinfo aufgefallen, die erst seit Einspielen der modifizierten CUL Firmware auftreten:


protoEvents done:
    name                :State           |CmdPend           |Snd               |LastRcv       |Resnd             #CmdDel            |ResndFail         |Nack       
    az_Thermostat       : done           | -                |1:05-30 03:50:59  |05-30 21:49:54| -                # -                | -                | -         
    az_podP6026         : done           | -                |2:05-30 21:17:33  |05-30 21:17:33|3:05-30 21:17:33  # -                | -                | -         
    bd_Thermostat       : done           | -                |1:05-30 03:40:36  |05-30 21:50:44| -                # -                | -                | -         
    dg_Thermostat       : done           | -                |1:05-30 04:09:13  |05-30 21:50:53| -                # -                | -                | -         
    ke_Pumpe            : done_Errors:1  | -                |1:05-30 05:30:00  | -            |3:05-30 05:30:12  #1                 |1:05-30 05:30:17  | -         
    ke_Switch4          : done           | -                |1:05-30 15:32:44  |05-30 15:32:47|1:05-30 15:32:47  # -                | -                | -         
    ku_Switch1          : done           | -                |2:05-30 20:36:55  |05-30 20:36:55| -                # -                | -                | -         
    te_Markise          : done           | -                |12:05-30 21:05:49 |05-30 21:05:49|4:05-30 21:05:48  # -                | -                | -         
    wz_Thermostat       : done           | -                |1:05-30 01:58:07  |05-30 21:51:33| -                # -                | -                | -         
    wz_vT               : done           | -                |596:05-30 21:49:55| -            | -                #4                 | -                | -         
================================================================================================================
    sum                 1                |0                 |618               |40            |11                #5                 |1                 |0   


Da das mein Produktionssystem ist, habe ich seit einiger Zeit keine Updates eingespielt. Brauchen deine Modifikationen eine aktuelles CUL oder CUL_HM Modul ?


# $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $
# $Id: 00_CUL.pm 5269 2014-03-20 21:22:59Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 5262 2014-03-20 19:02:12Z martinp876 $


Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

noansi

Hallo Tobias,

Danke für Dein erstes Feedback.

Meine fhem.pl Basis hat die Version 5663 vom 26.4.14
00_CUL.pm Basis 5487 vom 8.4.14
10_CUL.pm Basis 5679 vom 27.4.14
Am Timing habe ich da nichts geändert, sondern nur für den Problemfall meine Timeout Behandlung eingebaut. Die machen aber im ms Bereich sicher keinen Unterschied.

Meine Änderungen betreffen im Timing in der Firmware die Umschaltung von Senden nach Empfang und umgekehrt, da jedes mal noch das CC1100_FSCAL1 ausgelesen und geprüft wird.
Edit: Die Prüfung erfolgt auch nach jedem Poll auf ein neues Paket, also bei jedem Taskdurchlauf.
Wenn ich am SPI Timing nichts übersehen habe, dann sind das aber nur Verzögerungen im niedrigen xx µs Bereich. Von daher erwarte ich da keine massiven Probleme, da Martin ja im ms Bereich unterwegs ist, was das Timing angeht. Aber ich kann mich da auch täuschen.
Das war eigentlich auch die Frage an Martin, ob er damit Probleme erwartet.

Edit: Hast Du mal ins Hauplog geschaut, ob da irgendwelche von den PLL Meldungen auftauchen? Wenn neu kalibriert werden muss, dann ist das mit mehr Zeitaufwand im knappen ms Bereich verbunden (so es beim ersten mal klappt, sonst bis zu mehreren ms).

Wie sah es denn mit der bisherigen Firmware bei den Resends aus?

Meine Erfahrung beim Senden bisher, und die habe ich bisher nur manuell ausgelöst, waren mit relativ häufigen Resends verbunden, auch vor meinen Änderungen an der Firmware. Verbesserungen bezüglich Empfangslage (RSSI) haben dabei zu Verbesserungen geführt.

Gruß, Ansgar.

tpm88

Hallo Ansgar,

Zitat von: noansi am 31 Mai 2014, 08:27:04
Edit: Hast Du mal ins Hauplog geschaut, ob da irgendwelche von den PLL Meldungen auftauchen? Wenn neu kalibriert werden muss, dann ist das mit mehr Zeitaufwand im knappen ms Bereich verbunden (so es beim ersten mal klappt, sonst bis zu mehreren ms).
Nein - ich sehe keinerlei PLL Meldungen, seit ich die 1.59 Firmware eingespielt habe.

Zitat
Wie sah es denn mit der bisherigen Firmware bei den Resends aus?
Es gab in der Vergangenheit schon mal den einen oder anderen Resend - vom Gefühl her vielleicht 1x pro Woche. Problem mit der 1.59 ist, dass praktisch jedes Kommando einen Resend und noch schlimmer häufig sogar einen Resend Failed ausgelöst hat.

2014-05-30_22:31:37 az_podP6026 ResndFail
2014-05-30_22:31:37 az_podP6026 MISSING ACK
...
2014-05-31_07:02:46 ku_Switch1 ResndFail
2014-05-31_07:02:46 ku_Switch1 MISSING ACK
...
2014-06-01_07:30:18 ke_Pumpe ResndFail
2014-06-01_07:30:18 ke_Pumpe MISSING ACK
...
2014-06-01_17:48:16 ku_Switch1 ResndFail
2014-06-01_17:48:16 ku_Switch1 MISSING ACK
...
protoEvents done:
    name                :State           |CmdPend           |Snd               |LastRcv       |Resnd             #CmdDel            |ResndFail       
    az_Thermostat       : done           | -                |34:06-01 01:21:38 |06-01 17:49:29|2:05-30 22:48:03  # -                | -               
    az_podP6026         : done           | -                |8:06-01 17:47:29  |06-01 17:47:29|1:06-01 17:47:13  # -                | -               
    bd_Thermostat       : done           | -                |2:06-01 01:11:17  |06-01 17:49:50| -                # -                | -               
    dg_Thermostat       : done           | -                |2:06-01 01:39:55  |06-01 17:48:19| -                # -                | -               
    ke_Pumpe            : done           | -                |12:06-01 17:47:38 |06-01 17:47:38|8:06-01 17:47:37  #1                 |1:06-01 07:30:18
    ke_Switch4          : done           | -                |8:05-31 07:10:02  |05-31 07:20:12|5:05-31 07:10:07  #3                 |1:05-30 22:41:10
    ku_Switch1          : done_Errors:1  | -                |2:06-01 17:48:08  | -            |2:06-01 17:48:12  #2                 |2:06-01 17:48:16
    te_Markise          : done           | -                |5:06-01 17:48:53  |06-01 17:48:53|4:06-01 17:48:53  # -                | -               
    wz_Thermostat       : done           | -                |2:05-31 23:28:47  |06-01 17:48:45| -                # -                | -               
    wz_vT               : done           | -                |1025:06-01 17:49:58| -            | -                # -                | -             
================================================================================================================
    sum                 1                |0                 |1100              |47            |22                #6                 |4               


Zitat
Meine Erfahrung beim Senden bisher, und die habe ich bisher nur manuell ausgelöst, waren mit relativ häufigen Resends verbunden, auch vor meinen Änderungen an der Firmware. Verbesserungen bezüglich Empfangslage (RSSI) haben dabei zu Verbesserungen geführt.
Die obigen Resends und Resend Failed betreffen mehrere Devices in verschiedenen Räumen. Ich hatte in der Vergangenheit eigentlich nur mit einem Device relativ schlechte RSSI Werte gehabt.

Zum Vergleich - eben habe ich wieder die Original 1.58 FW eingespielt und anschliessend auf jedes meiner HM Devices einen statusRequest und getConfig ausgelöst:

Kein einziger Resend, kein einziger Fehler, selbst bei den häufig etwas problematischen getConfig bei den RT-DN Thermostaten...


protoEvents done:
    name                :State           |CmdPend           |Snd               |LastRcv       |Resnd             #CmdDel            |ResndFail       
    az_Thermostat       : done           | -                |29:06-01 18:14:10 |06-01 19:00:22| -                # -                | -               
    az_podP6026         : done           | -                |7:06-01 19:00:32  |06-01 19:00:32| -                # -                | -               
    bd_Thermostat       : done           | -                |29:06-01 18:20:45 |06-01 19:01:10| -                # -                | -               
    dg_Thermostat       : done           | -                |29:06-01 18:23:33 |06-01 18:59:25| -                # -                | -               
    ke_Pumpe            : done           | -                |7:06-01 19:00:44  |06-01 19:00:44| -                # -                | -               
    ke_Switch4          : done           | -                |11:06-01 18:03:32 |06-01 18:03:32| -                # -                | -               
    ku_Switch1          : done           | -                |9:06-01 19:00:51  |06-01 19:00:51| -                # -                | -               
    te_Markise          : done           | -                |9:06-01 18:03:56  |06-01 18:03:56| -                # -                | -               
    wz_Thermostat       : done           | -                |29:06-01 18:59:40 |06-01 19:00:05| -                # -                | -               
    wz_vT               : done           | -                |24:06-01 18:59:59 | -            | -                # -                | -               
================================================================================================================
    sum                 0                |0                 |183               |54            |0                 #0                 |0               


Zumindest mit einer FB7390 macht die v1.59 bei mir erhebliche Probleme beim Senden.

Gruss
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

noansi

Hallo Tobias,


danke für Dein Feedback.


Ok, jetzt wäre etwas Protokollinfo zum Timing nicht verkehrt.
Hat dazu jemand Infos?

Kommen Acks und Antworten so schnell, dass die kleine Zusatzverzögerung diese Auswirkungen erklären kann?

Dann könnte ich nur in den Sendepausen mal prüfen, ob der PLL nicht mehr im Lock Zusand ist und müsste es beim Umschalten sein lassen, respektive so schnell wie möglich umschalten?


Gruß, Ansgar.

noansi

Hallo Rudolf und alle Mitleser,


ich habe nun 2 CULs am laufen und das nun auch an einem aktiven USB-Hub.

Das vorläufige Testergebnis nach über 4 Tagen Test zeigt bisher nur bei dem ersten CUL das Problem mit dem fehlenden PLL Lock.
Der neue CUL hat als Unterschied zum ersten noch den Metall-Schirm. Da ich aber in der Nähe keine großen erkennbaren Störsender/-quellen habe, denk ich nicht, dass das den Unterschied ausmacht.

Vielleicht habe ich auf dem CUL eine "Montags" cc1101 drauf oder eine Lötstelle ist nicht ganz sauber oder ein Pufferkondensator etwas schwach... und einen Software Workaround gefunden.

Sollte der Zweite sich doch nochmal mit dem beschriebenen Problem melden, werde ich berichten.

Unterschiedlich sind auf jeden Fall die Register Werte bei den FCAL Registern:

Zitat
CUL_0 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AE2A16114100597F3E81350B00
CUL_1 raw => 072E2E0DE9CAFF0C450000060021656AC8930322F834073318166C434091876BF85610AC2B16114100597F3E81350B00


@Rudolf: Danke nochmal für die Hardwareanregungen und Deine Geduld!


Gruß, Ansgar.