ZWave @ culfw

[rudolfkoenig]

Bist Du sicher, dass das neigborupdate ist?

Na wie wir sie nennen, ist mir egal, ich habe halt die im Kommentar gespeicherten Nachrichten bei einem neighborUpdate haufenweise gesehen. Und sonst keine Nachrichten mit einer anderen Klasse.

Ich wuesste auch gerne, wer meinem Sensor gesagt hat, dass er 2-mal um die Ecke routen soll, bzw. wie ich das wiederum korrigiere. Gehe ich richtig in der Annahme, dass im ZWDongle ausser der neighborList keine anderen Daten da sind? Wie sucht er die optimale Routing-Strecke aus?

Evtl. ähnliches über MULTILEVEL SWITCH (Level Change).

Stimmt, ist leider begrenzt auf 2 Stunden. Ich muss mal damit rumspielen, bin gespannt was ein Zwischenstecker aus dim-Kommandos macht.

[krikan]

Ich wuesste auch gerne, wer meinem Sensor gesagt hat, dass er 2-mal um die Ecke routen soll, bzw. wie ich das wiederum korrigiere.

Das begreife ich eben auch nicht. Bei mir gehen die Routen fast immer über die Sirene, obwohl der direkte Weg viel kürzer wäre. Sirene ist 100k wie Controller während restliche Router und Enddevice 40k. Korrektur ?? Auch x-Mal neigborUpdate führen zu keiner Änderung.

Gehe ich richtig in der Annahme, dass im ZWDongle ausser der neighborList keine anderen Daten da sind? Wie sucht er die optimale Routing-Strecke aus?

Zu der Annahme tendiere ich mittlerweile auch, aber keine Idee wie das optimale Routing läuft. Habe dazu noch nirgendwo etwas Erhellendes gefunden.

Im Endeffekt: Auch keine richtige Ahnung mangels vernünftiger Doku (AEOTEC Updater spricht bei Class 01 auch über ein unbekanntes Dokument SDS10264-2 ...)

[rudolfkoenig]

Habe culfw/ZWCUL angepasst, damit 100k besser funktioniert: ich kann jetzt auch auf 100k mehrere "set as6 versionClassRequest" (also 16 get Abfragen direkt hintereinander) ohne Probleme absetzen. 40k funktioniert auch noch. Ich habe bwidth bei 40k auf 325k gesetzt, und wir senden "nur" 12 preambel bytes, wie in ZAD12837-1 bzw. ITU-G.9959 beschrieben. Bei 100k muessten wir 40 preambel bytes senden, das CC1101 kan aber nur maximal 24, scheint trotzdem zu funktionieren. Modulation habe ich bei 100k auf GFSK gesetzt.

Die KFOB kann ich auf 100k jetzt empfangen, die zwave.me Fernbedienung ist weiterhin komisch (nur die erste Taste ist mit dem CUL empfangbar).

Weiterhin wird der Checksum ab sofort im culfw immer geprueft: sowohl bei 40k als auch bei 100k, und auch im monitor mode.

Mein Problem ist 9.6k (zu aktivieren mit zm9/zr9): da kann ich nicht empfangen, senden habe ich gar nicht probiert. Ist deswegen ein Problem, weil Inclusion/Exclusion auf 9.6k laeuft, hatte naemlich weder auf 40k noch auf 100k irgendetwas gesehen, weder beim Goodway, noch beim ZWave.
Falls jemand (Andreas?) meine CC1101-Parameter fuer 9.6k pruefen koennte, waere ich dankbar.

Wenn ich auf dem as6 den Knopf druecke, dann kann ich auf dem ZWCUL nichts empfangen, der zme Dongle meldet ZW_APPLICATION_UPDATE (das ist doch ein NIF?), ich vermute, der as6 sendet das auf 9.6k. Der Dongle mit "set zme sendNIF 1" sendet auf 40k und "gleichzeitig" auf 100k, vermutlich auch auf 9.6k, das sehe ich aber nicht.

[rudolfkoenig]

Habe bWidth bei 40k auf 101k zurueckgesetzt, da der Empfang mit 325 merkbar schlechter geworden ist.
Weiterhin kann man ab sofort mit CwAADD Register AA in der CC1101 mit DD direkt beschreiben: beim Experimentieren mit den Registern muss man nicht staendig neu Flashen.

[A.Harrenberg]

Hi Rudi,

Habe culfw/ZWCUL angepasst, damit 100k besser funktioniert
[...]
Die KFOB kann ich auf 100k jetzt empfangen

was hast Du denn angepasst?

Mein Problem ist 9.6k (zu aktivieren mit zm9/zr9): da kann ich nicht empfangen, senden habe ich gar nicht probiert. Ist deswegen ein Problem, weil Inclusion/Exclusion auf 9.6k laeuft, hatte naemlich weder auf 40k noch auf 100k irgendetwas gesehen, weder beim Goodway, noch beim ZWave.
Falls jemand (Andreas?) meine CC1101-Parameter fuer 9.6k pruefen koennte, waere ich dankbar.

Hmm, ich habe jetzt heute abend schon so einige Variationen durchprobiert, komme aber auch an keine Nachrichten...

Laut dem Dokument von Fouladi/Ghanoun ist bei 9.6 GFSK aktiv...
Mich wundert weiterhin der Kommentar in diesem Dokument das ALLE Bits im 40k-Frame negiert sind. Die Preambel/Sync Werte für 40k/100k sind ja ggü. den Werten in der ITU auch invertiert.

Habe sowohl mal mit GFSK als auch mit den normalen Werten für die Preambel/Synce rumprobiert und nichts empfangen können.
An den übrigen Parametern habe ich jetzt erst mal nichts auffälliges gesehen, die scheinen soweit in Ordnung zu sein.

Muss mal sehen ob ich morgen noch mal Zeit dafür finde. Der "Cw"-Befehl hilft da beim ausprobieren schon mal weiter ,-)

Gruß,
Andreas.

[rudolfkoenig]

was hast Du denn angepasst?

Die GFSK Modulierung. Und ich habe die Drahtantenne auf dem CUL (zu kurz/duenn/schlecht aufgeloetet) ausgetauscht.

Laut dem Dokument von Fouladi/Ghanoun ist bei 9.6 GFSK aktiv...

Ich sehe im Dokument FSK. Ich habe die beiden vor eine Woche angeschrieben, ohne Antwort bisher.
Falls demnaechst kein Wunder passiert, dann versuche ich das Senden@9.6k mit SlowRF zu protokollieren.

[A.Harrenberg]

Hi Rudi,

Die GFSK Modulierung. Und ich habe die Drahtantenne auf dem CUL (zu kurz/duenn/schlecht aufgeloetet) ausgetauscht.

Das war doch schon GFSK oder habe ich mich da so vertan?

Zu kurze Antenne? Ich habe meine nicht nachgemessen, da sich mein Testequipment momentan aber im Umkreis von 1m um die Dongles und den CUL befindet ist Empfangsleistung bei mir kein Problem...

Ich sehe im Dokument FSK. Ich habe die beiden vor eine Woche angeschrieben, ohne Antwort bisher.
Falls demnaechst kein Wunder passiert, dann versuche ich das Senden@9.6k mit SlowRF zu protokollieren.

Im Text unter der Tabelle steht das sie Unterschiede zu den offiziellen Angaben festgestellt haben, unter anderem steht da dann GSFK für 9.6 kBaud und das ALLE Bits für 40k invertiert sein sollen...

Hattest Du nicht schon mal die Register von denen geschickt bekommen oder habe ich da was falsch abgespeichert?

Gruß,
Andreas.

[rudolfkoenig]

Alle bisherigen Drahtantennen von busware hatten eine mAn ungenaue Laenge, und ich meine mit 1.5mm² Draht bessere Ergebnisse zu haben als mit einem Duennen. Aber das wird off-topic.

ALLE Bits für 40k invertiert sein sollen

Danke, das muss man verinnerlichen: _beide_ SYNC Parameter muessen invertiert sein. Jetzt funktioniert auch 9.6k, jedenfalls Empfang, Senden habe ich noch nicht getestet. Habe die Aenderungen  eingecheckt. Die beiden haben mir nur die Parameter fuer 40k gegeben. So schaut der NIF der as6 aus:

Code Auswählen Erweitern

2015.12.29 10:42:48.866 5: xxxxxxxx S:36 F:01 f:0 SN:a L:22 T:00 P:fefe2c63feeffea1dad9cc8fd8cd7e7aa68d79858c10a57d C:e9
2015.12.29 10:42:48.866 5:    F: singleCast

Der Raetsel meiner zwave.me Fernbedienung wandelt sich: sie schickt auf 9600 an irgendwelche komische Adresse mit "falschen" checkSum merkwuerdige Daten. Der Sequence-Number aendert sich im aufeinanderfolgenden Paketen auch nicht. T: im ACK kann ich auch nicht erklaeren, immerhin kommt das mit "richtigen" checkSum.

Code Auswählen Erweitern

2015.12.29 11:09:01.734 5: xxxxxxxx S:16 F:41 f:0 SN:1 L:11 T:fe P:9ff2fffddffeff C:92
2015.12.29 11:09:01.734 5:    F: singleCast ackReq
2015.12.29 11:09:01.754 5: xxxxxxxx S:01 F:03 f:0 SN:1 L:0a T:e9 P: C:85
2015.12.29 11:09:01.754 5:    F: ack
Der Goodway meldet diese Daten als "07600d0002200100" also MULTI_CHANNEL CMD_ENCAP (600d), EndPoint 02, basicSet:00 (200100). Nein, Verschluesselung ist nicht aktiviert. Ergebnis: vorher hatte ich ein Problem (ich empfange nichts), jetzt 5 Fragen: Wie rechnet man den Checksum (92 ist nach bisheriger Methode falsch), wer ist der Addressat (fe?), wieso aendert sich SN nicht (bleibt 1), wie dekodiert man die Daten, wieso geht der Ack an e9.

Hat jemand was Aufhellendes?

[A.Harrenberg]

Hi Rudi,

hmm, ich habe gestern selbstverständlich mit den umgedrehten Syncparametern (aa/55 und f0/0f) probiert, sogar in allen 4 möglichen Kombinationen und kein einziges Nachrichtenpaket empfangen. Aber schön wenn es bei Dir jetzt geht.

Zu dem Rest kann ich jetzt auch nicht viel sagen (bin ja eigentlich auch auf der Arbeit...), nur ein paar wilde Ideen...

Mir fällt auf das Antwort an e9 geht, das wäre aber oberhalb der maximalen Node-Anzahl (ebenso wie das fe), könnte das evtl. eine besondere Form eines Broadcasts sein?

Thema Checsum: Ich habe sowas im Hinterkopf das im ITU was gestanden hätte das bei 9.6 keine CS gebildet wird??? Jedenfalls war da eine Besonderheit.

Gruß,
Andreas.

[rudolfkoenig]

kein einziges Nachrichtenpaket empfangen.

Ich gehe davon aus, dass Du "^ 0xff" beim Emfang nicht deaktiviert hast.
Apropos... Ich leider auch nur die Haelfte. Und schon erklaert sich der Raetsel der "komischen" zwave.me Pakete. Die Fernbedienung sendet ganz normal auf 9600, alle bits/bytes sind verstaendlich und im Klartext.

Danke fuer die psychologische Beratung

[A.Harrenberg]

Hi Rudi,

Ich gehe davon aus, dass Du "^ 0xff" beim Emfang nicht deaktiviert hast.

nein, hatte ich nicht, ich hatte nach so etwas gesucht, aber nicht gefunden... ,-(

Schön wenn es jetzt funktioniert und die Pakete jetzt auch "verständlicher" sind ,-)

Mahlzeit,
Andreas.

[krikan]

Klasse, dass jetzt alle Datenraten funktionieren.

Könnt ihr mir bitte Nachhilfe geben bzw. mein Verständnis kontrollieren:
9.6, 40k und 100k sind in einem Z-Wave-Netz immer gleichzeitig aktiv. Damit braucht man zum vollständigen Sniffen des Funkverkehrs im Netz 3 Culs gleichzeitig.
Ein Cul kann dynamisch zwischen den Datenraten umgeschaltet werden. Dadurch wäre beim Senden für verschiedene Datenraten ein Cul genug; es würden nur nicht alle Telegramme empfangen, wenn die gerade am Cul eingestellt Datenrate nicht passt.
Z-Wave-Sticks können hingegen alle 3 Datenraten gleichzeitig senden/empfangen.

Danke und Gruß, Christian

[A.Harrenberg]

Hi Christian,

ja, so ist auch mein Verständnis. Mir ist nur nicht klar wie die ZWave-Dongles das mit den unterschiedlichen Datenraten machen. Aufgrund der verschiedenen Frequenz für 100kBaud gehe ich davon aus das in so einem ZWave-Chip mehrere Empfänger parallel arbeiten. Keine Ahnung ob es solche CC-Chps mit mehreren unabhängig programmierbaren Empfängern gibt. Die müssten dann aber auch unabhängige Emfangsbuffer haben...

Oder man muss mal ausrechnen wie schnell so ein Chip die Frequenz und die Datenrate "umschaltet", wie lange er braucht um eine Preamble zu erkennen und wie viele Preamblen in dieser zeit "vorbei" rauschen. Vielleicht würde das zeitlich ja sogar ausreichen...

Gruß,
Andreas.

[rudolfkoenig]

@Christian: Alles richtig, soweit ich es verstanden habe.
Mein Ziel ist das ZWDongle mit ZWCUL zu ersetzen. Dabei wuerde ich fuer die Inklusion auf 9600 schalten, und danach alle Geraete auf 40k oder 100k "zwingen". Bin noch nicht sicher, dass das so klappen wird. Wenn Andreas den gleichzeitigen Empfang hinkriegen wuerde, dann waere alles viel einfacher. Ich bin aber extrem skeptisch.

[A.Harrenberg]

Hi,

ich glaube auch nicht wirklich das man mit dem "einfachen" CC1100 einen gleichzeitigen Empfang sicherstellen kann. Ich muss mal rechnen wie lange so eine komplette Preambel in den verschiedenen Datenraten dauert, und dann mal in den Datenblättern zum CC wühlen was da zum Thema Umschaltzeiten steht.

Das kann ja nur funktionieren wenn man in der kürzesten Zeit der drei Datenraten alle drei Modi umschalten kann UND auch noch die Preambel sicher erkennen kann. Dazu müsste es dann aber auch ein Ausgangssignal oder Register geben das aktiv wird sobal diese Preambel erkannt wird, daran kann ich mich jetzt auch Anhieb nicht erinnern.

Ansonsten müssen wir uns nach "besserer" Hardware umsehen, wie gesagt, keine Ahnung ob es Chips aus dieser Reihe gibt die das in HW können.

Gruß,
Andreas.