ZWCUL & STACKABLE_CC

[Telekatz]

CCCOUNT muss nicht geändert werden. Die Anzahl der Transceiver wird anhand des Targets über HAS_MULTI_CC definiert.

[A.Harrenberg]

Hallo Rudi, hallo Telekatz,

ich habe mir jetzt mal einige Übertragungen mit dem LogicAnalyser angesehen und auch die Laufzeiten grob mit dem HAL_GetTick() ermittelt.
Ich bin etwas verwirrt über die meiner Meinung nach langen Laufzeiten...

Beispiel vom HW-LogicAnalyser (von einem verworfenem Paket, Länge 191):

Zeitdifferenz zwischen GDO2 (RX_FIFO_THR=8 erreicht) bis SPI Übertragung startet: 1,8 ms. -> Finde ich sehr lange. (Wenn ich mich nicht verrechne dann dauert 1Byte über ZWave mit 100kBaud 10 µs. Das würde bedeutet das in der Zeit bereits 180 weitere Zeichen angekommen sein müssten.)
-> Habe mich vertan, es sind kBit und nicht kBaud -> 1,8ms reichen für ca. 22 weitere Byte

Das Auslesen der ersten 8 Byte per SPI dauer dann 280 µs. Die Frequenz der SPI SCKL liegt hier nur bei ca. 280 kHz. Sowohl der Maple als auch der CC1100 dürften hier wesentlich schnellere Datenraten hergeben... (CC1100 bis ca. 6Mhz, beim Maple müsste es einen Mode 4 mit 4,5 MHz geben...) Auch hier könnte man mMn schneller sein, wobei ich allerdings noch nicht gefunden habe wo/wie man die SPI Geschwindigkeit konfiguriert, die Default Geschwindigkeit ist anscheinend in STM32/hal_spi.c über " hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;" definiert. Hier könnten man mMn auf "_16" gehen...

Da die Paketlänge mit 191 über dem max-Wert liegt sollte das Paket verworfen werden und es wird rf_zwave_init() aufgerufen, es folgt jedoch erst einmal eine Pause von 1,3 ms die ich mir nicht erklären kann.

Der Reset und die Initialisierung der CC1100-Register dauert dann noch mal 1,9 ms. Danach folgt eine Pause von 4ms die aber auch im Code so vorgesehen ist. Das nachfolgende zccRX() dauert dann noch mal 875 µs.

D.h. vom Zeitpunkt das die 8 bytes im FIFO-Buffer sind (GDO2 Signal) bis zum Abschluss der Neu-Initialisierung dauert es in diesem Fall 10ms. (Laut meiner Rechnung reicht das für 1000 weitere Bytes die während dieser Zeit übertragen werden können...) -> auch hier, es sind kBit nicht kBaud -> 10ms reichen für ca. 125 weitere Bytes

Eine Auswertung der Ticks aus dem Logfile ergibt ähnliche Ergebnisse.

Für den Fall das die Länge mal in Ordnung sein sollte ergben sich aber teilweise erhebliche längere Laufzeiten bis zu 38 ms, da wundert es mich dann nicht das keine ACK (die in der Regel 1-3 ms nach der Übertragung ankommen) empfangen werden...


Beispiel vom HW-LogicAnalyser (von einem gültigen Paket, Länge 63):

Zeitdifferenz zwischen GDO2 und start der SPI Übertragung: 1,7 ms
Auslesen Fifo_buffer: 285 µs
Pause bis mit dem weiteren Auslesen gestartet wird 1 ms
Zeitdauer Auslesen der restlichen 55 Bytes: 2,2 ms
Pause bis mit zxxRX() weitergemacht wird 3,8 ms
Dauer zxxRX() 930 µs

Gesamtdauer von GDO2 Bit gesetzt bis CC1100 wieder emfpangsbereit: 10ms

Kleine Statistik aus dem Logfile:
335 erkannte Pakete, davon:
112 wegen falscher Länge verworfen, min: 9 ms, max: 10ms, Durchschnitt: 10ms
102 wegen unpassender Länge während des Auslesens verworen, min: 10ms, max: 27ms, Durchschnitt 10ms
121 mit korrekter Chechsumme erkannt, min: 9ms, max: 38ms, Durchschnitt: 17ms

@Rudi: Kannst Du Dich erinnern mit welcher Geschwindigkeit das SPI bei CUL läuft? Ich kann da leider nicht mit dem HW-LogicAnalyser dran...

@Telekatz: Gibt es Interruptroutinen beim MapleCUL? Denke nicht, oder etwa doch?

Gruß,
Andreas.

[Telekatz]

Der Timer Interrupt für TIM1 wird periodisch aufgerufen (clock_TimerElapsedCallback in clock.c). Außerdem läuft die USB und UART Übertragung Interruptgesteuert ab.

Du solltest aber beachten, dass deine Debugausgaben auch Verzögerungen verursachen. Diese Ausgabe läuft nicht mit Interrupts und es geht erst weiter, wenn alle Bytes übertragen sind.
Um das zu minimieren solltest du direkt in den entsprechenden UART Empfangspuffer schreiben. Dann läuft das nicht erst über UART und wird in der main loop dann direkt über USB gesendet.

dbgu.c:

Code Auswählen Erweitern

#include "ringbuffer.h"
extern rb_t UART_Rx_Buffer[];

int fputc(int ch, FILE *f) {
  //HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF);
  //SWO_PrintChar((uint8_t)ch,0);
  rb_put(&UART_Rx_Buffer[0], ch);
  return ch;
}

[rudolfkoenig]

@Rudi: Kannst Du Dich erinnern mit welcher Geschwindigkeit das SPI bei CUL läuft?

Die SPI Geschwindigkeit wird vom Master bestimmt.
Wir setzen SPSR nicht, wir modifizieren es nur im spi.c per

Code Auswählen Erweitern

SPSR |= _BV(SPI2X);
das entspricht laut Atmel Doku f_osc/2 -> auf dem CUL sollte der Atmel Chip mit 4MHz senden.

Laut CC1101 Doku haengt die andere Richtung vom extern zugefuehrten SCLK ab, und sollte fuer Burst unter 6.5MHz bleiben. Wenn ich board.h richtig interpretiere, dann kommt SCLK vom Atmel (PB1), weiss gerade nicht, wie/wo man PB1 mit einem Taktgeber verheiratet. Gehe aber auch von etwas im Bereich von 1-4 MHz aus.

[A.Harrenberg]

Hi Telekatz,

Der Timer Interrupt für TIM1 wird periodisch aufgerufen (clock_TimerElapsedCallback in clock.c). Außerdem läuft die USB und UART Übertragung Interruptgesteuert ab.

Sowas hatte ich befürchtet das USB auch per Interrupt läuft. Dann muss ich mal schauen ob ich mir da auch eine kurze Debug-Message reinschreibe.

Du solltest aber beachten, dass deine Debugausgaben auch Verzögerungen verursachen. Diese Ausgabe läuft nicht mit Interrupts und es geht erst weiter, wenn alle Bytes übertragen sind.
Um das zu minimieren solltest du direkt in den entsprechenden UART Empfangspuffer schreiben. Dann läuft das nicht erst über UART und wird in der main loop dann direkt über USB gesendet.

Ja, ich hatte testweise meinen gesamten Debugcode mal auskommentiert, dann geht das ganze ungefähr 1 bis 1,5 ms schneller, was ich auch schon erheblich finde.
Ich glaube ich werde mir da nicht so sehr die Mühe machen den Debug-Code noch zu optimieren, die Zeit bleibt da bei was anderem liegen, ich fürchte ja das es die DH2() Funktion bzw. die serielle Übertragung über die USB-Schnittstelle.

Ich werde testweise mal den Teiler für die SPI Kommunikation runtersetzen. Weißt Du zufällig wie man das per Befehl umkonfigurieren kann? Ich würde das ansonsten in STM32/hal_spi.c ändern und sehen ob das greift.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Die SPI Geschwindigkeit wird vom Master bestimmt.
Wir setzen SPSR nicht, wir modifizieren es nur im spi.c per

Code Auswählen Erweitern

SPSR |= _BV(SPI2X);
das entspricht laut Atmel Doku f_osc/2 -> auf dem CUL sollte der Atmel Chip mit 4MHz senden.

ich hatte jetzt auch etwas im Bereich von >1 Mhz erwartet, mit der Tendenz zu 4 Mhz...

Laut CC1101 Doku haengt die andere Richtung vom extern zugefuehrten SCLK ab, und sollte fuer Burst unter 6.5MHz bleiben. Wenn ich board.h richtig interpretiere, dann kommt SCLK vom Atmel (PB1), weiss gerade nicht, wie/wo man PB1 mit einem Taktgeber verheiratet. Gehe aber auch von etwas im Bereich von 1-4 MHz aus.

Die Geschwindigkeit hängt ja immer an SCLK, und das taktet laut meinem LogicAnalyser nur mit 280 Khz, was auch zu dem voreingestellten Frequenzteiler im Code passt. Ich werde das einfach mal auf die 4.5 MHz stellen und schauen was passiert.

Gruß,
Andreas.

[A.Harrenberg]

Hallo zusammen,

ich habe jetzt mal allen Debugcode entfernt und den Frequenzteiler für SPI auf _16 -> 4.5 MHz gestellt.

Code Auswählen Erweitern

a-culfw\trunk\culfw\STM32\hal_spi.c:

  //~ hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;

Im LogicAnalyser sieht das Signal für SCLK jetzt nicht mehr soo sauber/gleichmäßig aus, das schwankt da auch schon mal bis 5.3 MHz bei einzelnen Flanken, das sollte aber kein Problem sein solange das unter 6.5 MHz bleibt ...

Die Datenpakete die ich bisher beobachtet haben sind jetzt im Schnitt zwischen 1,5 und 2 ms abgearbeitet, inklusive der ca. 0,8 ms für das zccRX(). Das längste was ich jetzt bisher gesehen habe ist 3,4 ms.

Die Statistik für 100k sieht jetzt auch schon VIEL besser aus:
229 100k Datenpakete: ZWCUL hat 228 erkannt, und nur eine Nachricht "verpasst", MapleCul (auf 100k) hat 223 erkannt, 5 Nachrichten und ein ACK verpasst.

Das sieht schon mal sehr gut aus, ein Datenverlust von < 3% beim Maple, allerdings gegen sehr gute < 0.5% beim CUL.

Ich hatte jetzt noch mal mit Debug-Code probiert und hatte dann teilweise wieder eine fast 4ms lange Pause, das ist dann wahrscheinlich der CDC-Task der dann läuft...

Da der GDO0 Pin per Default als Ausgang geschaltet ist und nur über die Bedatung als 3-state geschaltet wird habe ich den Pin am Maple als Input definiert damit es während des Reset keine Probleme gibt.

Code Auswählen Erweitern

a-culfw\trunk\culfw\clib\rf_zwave.c:

void
rf_zwave_init(void)
{

#ifdef USE_HAL
//~ hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
  hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_IN_CS_IN);
#else
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
#endif

Ich werde morgen mal versuchen 40k (und noch mal 9k6) zu testen, ob das jetzt auch besser aussieht.

Gruß,
Andreas.

Edit: Ich habe mal das fw-file angehängt.

[A.Harrenberg]

Hallo Rudi,

und schon gibt es wieder die ersten Probleme...
der zwc = CUL steht eigentlich auf 100k und hatte auch brav die 100k Pakete empfangen. Jetzt ist mir gerade aurgefallen das er die 40k Pakete empfängt, diese aber mit 100k dekodiert will (2byte CS)
Neustart von FHEM hatte nichts genutzt, gleiches Ergebnis, erst ein "set zwc reopen" hat den wieder auf 100k gesetzt.

Irgendeine Idee woher das jetzt kommen könnte? Es betrifft wie gesagt den CUL und nicht den Maple...

Gruß,
Andreas.

Code Auswählen Erweitern

2017.04.16 21:58:55.616 5: zwc e015dfed S:40 F:51 f:0 SN:b L:14 T:01 P:600d07003105012200 C:f1bb
2017.04.16 21:58:55.616 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.617 5: z40k e015dfed S:40 F:51 f:0 SN:b L:14 T:01 P:600d07003105012200f1 C:bb
2017.04.16 21:58:55.617 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.621 4: ZWDongle_Read ZWDongle_0: rcvd 0004004009600d04003105030125 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.623 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:09600d04003105030125 CB:00
2017.04.16 21:58:55.626 5: z40k e015dfed S:01 F:13 f:0 SN:b L:0a T:40 P: C:6b
2017.04.16 21:58:55.628 5:    F: ack speedModified
2017.04.16 21:58:55.629 1: ERROR: Unknown packet ze015dfed01130b0a406b
2017.04.16 21:58:55.642 5: z40k e015dfed S:40 F:51 f:0 SN:c L:16 T:01 P:600d08003105084400002718 C:10
2017.04.16 21:58:55.642 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.646 4: ZWDongle_Read ZWDongle_0: rcvd 000400400a600d07003105012200f1 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.648 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0a600d07003105012200f1 CB:00
2017.04.16 21:58:55.649 5: zwc e015dfed S:40 F:51 f:0 SN:c L:16 T:01 P:600d080031050844000027 C:1810
2017.04.16 21:58:55.649 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.653 1: ERROR: Unknown packet ze015dfed01130c0a406c
2017.04.16 21:58:55.653 5: z40k e015dfed S:01 F:13 f:0 SN:c L:0a T:40 P: C:6c
2017.04.16 21:58:55.653 5:    F: ack speedModified
2017.04.16 21:58:55.668 5: z40k e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d0900310501420992 C:b9
2017.04.16 21:58:55.668 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.674 4: ZWDongle_Read ZWDongle_0: rcvd 000400400c600d08003105084400002718 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.676 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0c600d08003105084400002718 CB:00
2017.04.16 21:58:55.677 5: zwc e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d09003105014209 C:92b9
2017.04.16 21:58:55.677 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.681 1: ERROR: Unknown packet ze015dfed01130d0a406d
2017.04.16 21:58:55.714 4: ZWDongle_Read ZWDongle_0: rcvd 000400400a600d0900310501420992 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.16 21:58:55.716 4: CMD:APPLICATION_COMMAND_HANDLER ID:40 ARG:0a600d0900310501420992 CB:00
2017.04.16 21:58:55.728 5: z40k e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d0900310501420992 C:b9
2017.04.16 21:58:55.728 5:    F: singleCast speedModified ackReq
2017.04.16 21:58:55.728 5: zwc e015dfed S:40 F:51 f:0 SN:d L:14 T:01 P:600d09003105014209 C:92b9
2017.04.16 21:58:55.728 5:    F: singleCast speedModified ackReq


[rudolfkoenig]

Jetzt ist mir gerade aurgefallen das er die 40k Pakete empfängt, diese aber mit 100k dekodiert will

Entweder ist zwave_drate umgekippt (unwahrscheinlich), die Initialisierung ist schiefgegangen (eher unwahrscheinlich), oder das CC1101 empfaengt die Daten trotz "falscher" Datenrate (eher wahrscheinlich).

_Wenn_ diese Hypothese stimmt, taucht die Frage auf, ob wir diese Daten akzeptieren sollten: ich bin unentschlossen. Empfaengt man 40k einigermassen zuverlaessig mit der 100k Eingestellung?

[A.Harrenberg]

Hi Rudi,

Entweder ist zwave_drate umgekippt (unwahrscheinlich), die Initialisierung ist schiefgegangen (eher unwahrscheinlich), oder das CC1101 empfaengt die Daten trotz "falscher" Datenrate (eher wahrscheinlich).

_Wenn_ diese Hypothese stimmt, taucht die Frage auf, ob wir diese Daten akzeptieren sollten: ich bin unentschlossen. Empfaengt man 40k einigermassen zuverlaessig mit der 100k Eingestellung?

sorry, aber die Empfangstheorie kann ich nicht bestätigen. Der cc1100 der auf 40k eingestellt war hat dabei NICHTS empfangen. Selbst wenn die anderen Parameter (Bandbreite, Frequenz) ähnlich sind, die Datenrate unterscheidet sich um den Faktor 2,5, da sollte nichts empfangen werden können.

Ich gehe jetzt eher von einem SW Problem aus. Heute morgen war der Maple cc1100 der auf 40k eingestellt war "stumm"... Erst ein "reopen" hat da wieder Werte ergeben. Interessanterweise traf dies auch auf den CUL mit 100k zu, der Maple 100k lief aber noch.

Mir fällt aber auch auf das nach einem Reset / oder Anschließen des Maple dieser irgendwie nicht immer richtig/vollständig in FHEM initialisiert wird. Manchmal erhalte ich ein "reappeared" und die Zeile mit den möglichen Kommandos vom CUL, aber es werden KEINE Initialisierungswerte von FHEM gesendet (also z.B. die Datenrate eingestellt).

Mir scheint das hier auf beiden Seiten der Software noch was nicht ganz rund läuft. Das Logfile ist 8MB groß, da drin werde ich ohne eine konkreten Verdacht wohl nichts finden. Ich schau aber trotzdem mal ob da ein disappeared/reappeared auftaucht.

Ansonsten muss ich mal schauen das ich mal die Register vom cc1100 dumpe wenn das noch mal passiert, dann wissen wir wenigsten in welchem Mode das Ding zuletzt war.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

Die Statistik für 100k sieht jetzt auch schon VIEL besser aus:
229 100k Datenpakete: ZWCUL hat 228 erkannt, und nur eine Nachricht "verpasst", MapleCul (auf 100k) hat 223 erkannt, 5 Nachrichten und ein ACK verpasst.

Das sieht schon mal sehr gut aus, ein Datenverlust von < 3% beim Maple, allerdings gegen sehr gute < 0.5% beim CUL.

hier jetzt auch mal die Statistik mit 40k, sieht ähnlich gut aus:
1586 Datenpakete: ZWCUL hat 1579 erkannt, 5 Nachrichten und 2 ACKs nicht, der MapleCUL hat 1557 Nachrichten erkannt, 17 Nachrichten und 12 ACKs nicht.

Das macht wieder <0.5% Datenverlust beim CUL und <2% beim MapleCUL.

Die Frage ist, lohnt es sich diese 2-3% Datenverlust weiter zu analysieren? Mein erster Ansatzpunkt wäre noch mal die Interrupts zu analysieren ob die hier zu Datenverlusten führen könnten.
Empfangsprobleme sollte bei Abständen <1m keine Auftreten, hochfrequente Störungen am Maple könnte ich mir aber durchaus vorstellen, da sind immerhin 4 Transceiver plus der WZ5100 dran...

Gruß,
Andreas.

[rudolfkoenig]

Die Frage ist, lohnt es sich diese 2-3% Datenverlust weiter zu analysieren?

Du musst nicht uebertreiben, es sind nur 1.83% => Ich wuerde es nicht.
Was mich interessieren wuerde: wieviel erkennt ein ZWDongle im Vergleich?

[A.Harrenberg]

Hallo Rudi,

ich habe da noch mal ein paar Fragen zum ZWave-Code...

Nach dem Einlesen der ersten 8 Zeichen aus dem Buffer wird die Länge geprüft und das Paket verworfen wenn die Länge ungültig ist. Hierzu wird rf_zwave_init() aufgerufen was den CC resettet, die Register neu setzt und dann per zccRX() wieder auf "Empfang" geht.

Code Auswählen Erweitern


  uint8_t len=msg[7], off=8;
  if(len < 9 || len > MAX_ZWAVE_MSG) {
    rf_zwave_init();
    //DC('l'); DNL();
    return;
  }

Ist der Reset hier wirklich nötig? Würde es nicht reichen in SIDLE zu schalten, den Buffer zu flushen und wieder auf Empfang zu schalten? Zum einen könnte das schneller sein, zum anderen stört mich der Reset gerade beim Experimentieren, da dann meine Änderungen in den Registern dauernd wieder überschrieben werden. Spricht was dagegen hier ohne Reset zu arbeiten?

Nachdem dann die (erwartete) Länge bekannt ist, folgt das Einlesen der restlichen Daten. Hierzu gibt es eine eine Schleife mit einem Delay, was in etwa für 1 Byte ausreicht. Warum gibt es dieses Delay für nur ein Byte? Wäre es nicht sinnvoller länger zu warten um dann mehr Bytes in einem Rutsch auslesen zu können? Im Analyser kann ich sehen das dort teilweise nur Häppchen von zwei Bytes ausgelesen werden und es dadurch mehrere Durchgänge braucht bis die Nachricht  eingelesen ist. Geschwindigkeitsmäßig dürfte das aber relativ egal sein...

Code Auswählen Erweitern


  cc1100_writeReg(CC1100_PKTLEN, len );

  // 1 byte @ dataRate + 10% margin
  uint16_t delay = (zwave_drate[CC_INSTANCE] == DRATE_100k ? 90 :
                   (zwave_drate[CC_INSTANCE] == DRATE_40k ? 220 : 920));
  for(uint8_t mwait=MAX_ZWAVE_MSG-8; mwait > 0; mwait--) {
    my_delay_us(delay);
    uint8_t flen = cc1100_readReg( CC1100_RXBYTES );
    if(flen == 0)
      continue;
    if(off+flen > len) {
      //DC('L'); DNL();
      rf_zwave_init();
      return;
    }

    CC1100_ASSERT;
    cc1100_sendbyte( CC1100_READ_BURST | CC1100_RXFIFO );
    for(uint8_t i=0; i<flen; i++) {
      uint8_t d = cc1100_sendbyte( 0 );
      if(zwave_drate[CC_INSTANCE] != DRATE_9600)
        d ^= 0xff;
      msg[off++] = d;
    }
    CC1100_DEASSERT;
    if(off >= len)
      break;
  }

In dem Teil gibt es dann wieder eine Prüfung auf die Länge indem der aktuelle Offset und die aktuelle Länge des Buffers mit der überträgenen Länge verglichen wird. Auch hier wird wieder rettet... Ich verstehe aber nicht so ganz was hier passiert. Bei meinen Debug-Versuchen habe ich gesehen das diese Prüfung relativ häufig für den Abbruch der Übertragung verantwortlich war. Ich verstehe nur nicht wie da mehr Zeichen im Buffer sein können wenn vorher die PKTLEN doch eingestellt wurde. Nach dem Erreichen der PKTLEN sollte der CC doch aufhören zu empfangen??

Kannst Du DIch noch daran erinnern wie diese kaputten Nachrichten dann aussehen? Ich habe mir das noch nicht genauer angesehen, würde aber dann doch erwarten das da dann Müll hinten dran hängt den man ignorieren kann, oder?

Sagt Dir eigentlich FOC (Frequency Offset Compensation) und FSC (Frequency Synthesizer Calibration) etwas? Ich suche ja immer noch nach einer Möglichkeit die Frequenzen (und die Modulationen) schneller schalten zu können um mit einem Transceiver mehrere Datenraten abdecken zu können. Ich habe zu Testzwecken mal den GDO0 Pin so programmiert das er entweder auf CCA (Clear Channel Assessment), das SyncWort oder CarrierSense reagiert. Diese Signale toggeln ohne Übertragung alle ein wenig, kommen aber teilweise 4ms früher als das FIFO_RX Signal (für 8 Bytes) und sind bei einer Übertragung anscheinend stabil. Ich muss mir die Timings da auch mal für die anderen Geschwindigkeiten anschauen und noch mal rechnen wie schnell man sein müsste. An meine letzten Rechnungen kann ich mich schon nicht mehr erinnern...

Mit der (a-)synchronen Ausgabe über die GDO-Pins hast Du wahrscheinlich auch noch nicht gearbeitet, oder?

Gruß,
Andreas.

[rudolfkoenig]

Ist der Reset hier wirklich nötig?

Noetig ist zu viel gesagt: ist einfach, und im Zweifel initialisert alles neu. Ich war unsicher am Anfang, und habe ein bisschen "defensiv" Programmiert. Wie lange dauert ein reset? Du kannst natuerlich mit SIDLE experimentieren, falls es zu besseren Ergebnissen fuehrt, dann uebernehme ich es.

Warum gibt es dieses Delay für nur ein Byte?

Was soll ich sonst in der Zeit tun? Delay ist eine Endlosschleife, ob die innere Schleife kuerzer ist oder nicht, ist doch egal.

Ich verstehe nur nicht wie da mehr Zeichen im Buffer sein können wenn vorher die PKTLEN doch eingestellt wurde.

Ich bin jetzt zu faul zum Nachschauen , aber ich meine diese Laenge gehoert zum ZWave Protokoll, und wird nicht vom CC1101 ueberprueft. Und irgendwer muss es ja tun.

Sagt Dir eigentlich FOC (Frequency Offset Compensation) und FSC (Frequency Synthesizer Calibration) etwas?

Ja, aber vermutlich weniger als Dir Ich meine das CC1101 besteht auf relativ haeufige Kalibrierung (ein Nebeneffekt vom Reset). Einer meiner Theorien, warum der ZWDongle im Nachbar-Thema nach eine Weile nix mehr empfaengt: es hat sich nicht kalibriert. Senden kann (je nach Einstellung) dagegen helfen. Oder (wieder mit passenden Parameter) nach SIDLE wechseln.

Mit der (a-)synchronen Ausgabe über die GDO-Pins hast Du wahrscheinlich auch noch nicht gearbeitet, oder?

Weiss nicht genau, was du meinst, wenn das die Flanken sind: SlowRF arbeitet damit, und das geht wg. Interrupt-Ungenauigkeit geschaetzt bis 2-4kBaud Datenrate gut. Hatten schon mehrere die Idee, die Interrupt-Zeiten bis FHEM zu schicken, und die Daten da zu dekodieren, mW ohne Erfolg.

[A.Harrenberg]

Hi Rudi,

Du musst nicht uebertreiben, es sind nur 1.83% => Ich wuerde es nicht.
Was mich interessieren wuerde: wieviel erkennt ein ZWDongle im Vergleich?

puh, das ist schwierger zu filtern, und die Testnachrichten habe ich vom ZWDongle aus losgeschickt, da muss ich dann ein wenig zählen...

So, 793 Nachrichten (inklusive der ACK) sind beim ZWDongle angekommen, 4 davon fehlen beim CUL (3 Nachrichten, 1 ACK), beim MapleCUL sind es 17 (8 Nachrichten, 9 ACKs).
Ich habe keine Nachricht gefunden die beim CUL oder MapleCUL angekommen ist und nicht beim ZWDongle. Es gibt auch keine Nachrichte die keiner der beiden CUL nicht bekommen hat.

Das war jetzt nur die Richtung DanaLock -> ZWDongle, die Verlustrate ist in der gleichen Größenordung wie in beide Richtungen, d.h. es gibt da keinen signifikanten Unterschied ob das Device oder beide gesendet haben.

Gruß,
Andreas.