ZWave @ culfw

A.Harrenberg · 29 Dezember 2015, 17:55:26

Hi Rudi,

Zitat von: A.Harrenberg am 29 Dezember 2015, 11:45:18
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.

ITU Dokument von 2015:
S. 46 -> 8bit CS für Datenrate R1, R2
S. 47 -> 16bit CRC für Datenrate R3

Ich hatte das EOF im Kopf, und das wird NUR bei R1 gesendet (hat dann aber nichts mehr mit dem Protokoll zu tun).

Also alles in Ordnung ,-)

Gruß,
Andreas.

A.Harrenberg · 29 Dezember 2015, 22:50:22

Hi,

also mal ein "kurzer" Stand zu dem was ich bzgl. Mehrfrequenzmöglichkeit rausgebkommen habe:

9.6kBaud -> 19.2 kBit/s -> mind. 10 Preambeln -> mind. 80 bit -> mind. 8.3 ms
40kBaud -> 40 kBit/s -> mind. 10 Preambeln -> mind. 80 bit -> mind. 2 ms
100kBaud -> 100 kBit/s -> mind. 40 Preambeln -> mind. 320 bit -> mind. 3.2 ms
CC1101 kann nur 24 Preambeln senden -> max. 192 bit -> max. 1.92 ms

D.h. ein "Scannen" aller drei Datenraten darf maximal 1.5 ms dauern damit es überhaupt funktionieren kann.

Ein Umschalten "Idle to RX with calibration" benötigt bereits ~800 us "Transition time", das wäre schon mal deutlich zu lange, damit würde ja das reine Umschalten für drei Datenraten bereits mehr als die verfügbare Zeit dauern...
Es gibt aber anscheinend wohl die Möglichkeit diese Kalibrierwerte auszulesen und dann z.B. im CUL abzulegen und beim Umschalten keine Kalibrierung durchzuführen sondern diese Werte vorher zurückzuschreiben. Dann kommt man in die Größenordnung von ~ 150 us. Schon besser...

Die Frage wäre dann noch wie man die Preambel erkennen kann... Der CC hat da einiges zu bieten, allerdings verstehe ich leider auch nicht alles davon, bzw. kann nicht sagen ob sich das sinnvoll verwenden lassen würde. Die Preambel besteht aus 010101... bzw. 101010... Folgen, je nach Datenrate, jedenfalls immer schön abwechselnd.

Im CC gibt es einen Zähler den man aktivieren kann, dieser erhöht bei jedem Wechsel der Bits den Zähler um 1 und verringert ihn um 8 falls zwei gleiche Bits hintereinander kommen. Erreicht der Wert eine Schwelle, kann diese zur "Freigabe" der Erkennung des Syncwortes genutzt werden. Diesen Zähler könnte man nun evtl. auch nutzen, aber zum einen scheint sich der nur beim Wechsel von Idle->RX und am Paketende zu resetten, zum anderen dauert es in 9.6 Modus zu lange... Wenn man von den 10 Preambeln wenigstens 2 als "Freigabe" nutzen möchte, müsste man im 9.6 Modus ja bereits ~1.6ms warten -> zu langsam...

Empfangsstärke RSSI, hierzu finden sich in der DN505 (Design Note 505) Angaben zu den Zeiten nach denen man ersten Wert erwarten darf, der sich dann allerdings auch noch weiter ändern kann falls der Empfänger sich in der Verstärkung noch anpasst. Die Werte sind abhänging von Datenrate und Bandbreite, die Beispielwerte zeigen aber schon mal die Größenordnung:

Mindestzeit für 1 Update bei 1 kBaud ~280 us, falls der AGC eingeregelt ist ~140 us
Mindestzeit für 1 Update bei 38 kBaud ~160 us, falls der AGC eingeregelt ist ~ 80 us
Mindestzeit für 1 Update bei 250 kBaud ~ 40 us, falls der AGC eingeregelt ist ~ 8 us

D.h. auch hier wird es eng, falls sich der Wert erst nach 2-3 Updates eingependelt haben sollte.

Also Gedankenspiel:
150 us : Ändern der Frequenz/Datenrate auf 9.6K mit vorher gespeicherten Kalibrierwerten
400 us : Stabilisierung RSSI für 9.6k
150 us : Ändern der Frequenz/Datenrate auf 40K mit vorher gespeicherten Kalibrierwerten
300 us : Stabilisierung RSSI für 40k
150 us : Ändern der Frequenz/Datenrate auf 100K mit vorher gespeicherten Kalibrierwerten
100 us : Stabilisierung RSSI für 10k

1250 us = 1.25 ms gesamtzeit für einen Durchlauf, dazu kommen natürlich noch die Programmlaufzeiten, das sollten aber nur wenige us sein, oder verschätze ich mich hier?
Evtl. wird das umschalten aber auch "schneller" da nur zwischen zwei Frequenzen umgeschaltet wird. Die Änderung der Datenrate/Bandbreite dürfte aber dennoch EInfluß auf die RSSI Werte haben.

Soweit zur Theorie... Aber wer könnte dass in die Praxis umsetzen? Momentan sehe ich mich weder zeitlich noch fachlich dazu in der Lage...

Gruß,
Andreas.

rudolfkoenig · 30 Dezember 2015, 15:01:56

Dann hier mal ein "einfaches" Problem: Senden@9600 funktioniert nicht. Ich habe es mit G-FSK und 2-FSK versucht. Im ITU Dokument steht was vom EOF bei R1, was als "manchester code violations" besteht. Wie sendet man sowas? Ich habe versucht ein Byte (0x00) mehr zu senden, und beim Senden dieses Bytes die Codierung von Manchester auf NRZ zu stellen. Ohne Erfolg. Seufz.

Uebrigens bei der Inclusion wird (wenn ich es richtig sehe) "nur" mit Hilfe von 0103 nodeId und homeId gesetzt. Und bei der Exclusion werden mit dem gleichen Befehl die beiden Werte auf 0 gesetzt. Waehrend beider Vorgaenge sendet der Controller alle 2 Sekunden 010801, keine Ahnung, wozu. Alles auf 9600.

krikan · 30 Dezember 2015, 15:15:36

Zitat von: rudolfkoenig am 30 Dezember 2015, 15:01:56
Uebrigens bei der Inclusion wird (wenn ich es richtig sehe) "nur" mit Hilfe von 0103 nodeId und homeId gesetzt. Und bei der Exclusion werden mit dem gleichen Befehl die beiden Werte auf 0 gesetzt. Waehrend beider Vorgaenge sendet der Controller alle 2 Sekunden 010801, keine Ahnung, wozu. Alles auf 9600.

Laut meinem derzeitigen Lieblingstool (Aeotec Updater):
01= ZWAVE_CMD_CLASS (Z-wave protocol Command Class)
Befehl 03 = ASSIGN_ID
Befehl 08 = TRANSFER_PRESENTATION (

?)

Beim Rest auf Andreas hoffen...

A.Harrenberg · 30 Dezember 2015, 15:26:15

Hi Rudi,

Zitat von: rudolfkoenig am 30 Dezember 2015, 15:01:56
Dann hier mal ein "einfaches" Problem: Senden@9600 funktioniert nicht. Ich habe es mit G-FSK und 2-FSK versucht. Im ITU Dokument steht was vom EOF bei R1, was als "manchester code violations" besteht. Wie sendet man sowas? Ich habe versucht ein Byte (0x00) mehr zu senden, und beim Senden dieses Bytes die Codierung von Manchester auf NRZ zu stellen. Ohne Erfolg. Seufz.

oh, das ist aber wirklich ein "einfaches" Problem...
Wie hast Du denn beim Senden des Bytes Manchester ausgeschaltet? Du schreibst doch nur Bytes in den FIFO und "weisst" gar nicht genau wann das Byte dran ist... Außerdem bin ich nicht wirklich sicher ob sich das theoretisch überhaupt während einer Übertragung umschalten lässt...
Ich schau noch mal in die Doku von dem CC rein, aber so aus dem Gedächtnis ist mir da jetzt nichts bewusst was der CC automatisch anhängen könnte (außer einer CS).
Ich überlege gerade ob es möglich wäre die Daten selbst auf Manchester zu codieren und dann mit NRZ zu senden, dann sollte auch die "violation" möglich sein.

Tja, scheint doch mehr ein "echtes" Problem zu sein...

Gruß,
Andreas.

rudolfkoenig · 30 Dezember 2015, 15:58:28

ZitatLaut meinem derzeitigen Lieblingstool (Aeotec Updater):

Ist ab sofort auch mein Lieblingstool

ZitatWie hast Du denn beim Senden des Bytes Manchester ausgeschaltet?

FIFOTHR auf 1, PKTLEN eins mehr als noetig, Daten wie bisher schreiben, danach Bit pollen bis 0, dann Manchaster aus, und 0 senden. Ist eingecheckt. Alernative ist noch SlowRF. Wuerg.

A.Harrenberg · 30 Dezember 2015, 16:06:42

Hi,

das Kodieren auf Manchester und senden mit NRZ dürfte auch nicht funktionieren, da dann ja Preambel und Sync im falschen Format gesendet werden...

Ich bin aber extrem skeptisch was das umschalten der Modulation innerhalb des sendens angeht.
Könntest Du das testweise mal (ohne zusätliches byte) für 40K machen und sehen ob dann das Senden nicht mehr geht? Dann wäre es zumindest ein Hinweis das die Umschaltung funktioniert.

Da Manchester aber auf einer "clock" beruht dürfte das extrem empfindlich sein was das Timing beim Umschalten angeht.

Was macht den SlowRF (anders)? Und wieso "würg"?
Gruß,
Andreas.

rudolfkoenig · 30 Dezember 2015, 16:09:17

Mit Slowrf darf man die Flanken einzeln mit dem Atmel setzen. So laeuft FS20 & co.

A.Harrenberg · 30 Dezember 2015, 18:17:59

Hi Rudi,

Zitat von: rudolfkoenig am 30 Dezember 2015, 16:09:17
Mit Slowrf darf man die Flanken einzeln mit dem Atmel setzen. So laeuft FS20 & co.

ist wohl eher "muss" als "darf"...

Mein erneuter kurzer Blick in das Manual vom CC hat leider nichts neues erbracht. Der CC kann höchstens eine 16bit CRC beim Senden anhängen, eine Art EOF gibt es da nicht.
So langsam geht das aber schon ganz schön ins "Eingemachte" von dem CC. Als nächstes kann man sich dann wahrscheinlich mal mit der Statemachine von dem Ding befassen...

Noch mal zu dem Senden von 0x00 ohne Manchester, es soll ja ein Pattern ohne Transitions erzeugt werden, dazu ist mMn nötig das man das letzte Bit der Übertragung 8 mal wiederholt, also entweder 0x00 oder 0xff, je nach letztem Bit.

Was das Timing des Umschaltens angeht schaue ich noch mal ob es Angaben über den Zeitversatz zwischen FIFO und Senden angeht. Ich meine nämlich da etwas gelesen zu haben das beim Empfangen da ein Versatz von bis zu 9 Bytes auftritt, wobei ich da momentan nicht wüsste woher diese große Verzögerung kommen soll und wo da noch ein interner FIFO wäre...

Gruß,
Andreas.

A.Harrenberg · 30 Dezember 2015, 18:35:21

Hi,

also der "Versatz" (Latenz) den ich meinte gilt anscheinend nur für den "synchronous serial mode", der wird aber nicht genutzt, sondern FIFO. Und der Versatz wäre auch nur 9 BIT (nicht Byte) beim Empfangen und 8 bit beim Senden.

Gruß,
Andreas.

A.Harrenberg · 05 Januar 2016, 21:48:26

Hi Rudi,

ein paar Punkte:

- Bist Du mit 9.6k eigentlich schon was weiter gekommen? Meine Geräte senden auch bei "nicht erreichbarkeit" (ausgesteckter Steckdosensschalter) nicht auf 9.6k, ich sehe nur was während der Inklusion.

- Ich hab' jetzt auch ein ZWay zum gegentesten hier, ist aber nur eingeschränkt tauglich... ,-(

- Das DanaLock wird von ZWay als FLIRS erkannt, was auch Sinn macht. Darüber hatte ich mir bisher keine Gedanken gemacht. Momentan ist das Ding an ZWay angelernt, brauchts Du da evtl. mal einen NIF von dem Gerät? Dann könnte ich bei Gelegenheit noch mal in FHEM anlernen (oder mit CUL sniffen?)

Gruß,
Andreas.

rudolfkoenig · 06 Januar 2016, 07:36:40

FLIRS waere bei mir low Prio (habe keine Geraete, und es ist kompliziert), Senden@9.6k dagegen hoch, sonst kann ein CUL kein vollwaertiger Dongle Ersatz sein. Da die Ideen, die ich habe (Senden in SlowRF implementieren oder Paketmodus per Logic-Analyzer debuggen) aufwendig sind, ruht die Sache erstmal. Falls jemand helfen moechte...

A.Harrenberg · 06 Januar 2016, 07:57:08

Hi Rudi,

bin mir gar nicht sicher ob FLIRS wirklich besondere Behandlung benötigt, mein Verständnis ist das so ein Ding oft genug aufwacht um einen Beam zu erkennen. Ich werde jedenfalls bei Gelegenheit mal NIF und Inklusion mitschneiden.

Was das 9.6k angeht kann ich demnächst auch mal wieder ein wenig experimentieren. Eine Idee wäre noch beim Senden Preambel/Sync und Manchester auszuschalten, die Manchestercodierung dann in SW zu machen, und das ganze dann inklusive der Preambel, dem Sync, der Payload und der "Code violation" dann "normal" in 19.2 zu senden. Wobei die "Code violation" dann natürlich nicht mit der Manchestercodierung gemacht werden darf.

Ich bin mir aber nicht sicher ob Preambel/Sync auch mit Manchester codiert werden, oder ob die für alle codierungen gleich sind, gehe aber davon aus.

Man bräuchte mal einen Empfänger an dem man das de-modulierte Signal mit einem Scope oder Logic-Analyzer auslesen kann...

Gruß,
Andreas.

rudolfkoenig · 06 Januar 2016, 08:07:17

Zitatbin mir gar nicht sicher ob FLIRS wirklich besondere Behandlung benötigt

Ich schon, oder ich habe FLIRS nicht verstanden. Da muss man doch lange Beams senden, entweder ununterbrochen oder in Intervallen.Ich will dich aber nicht abhalten.

Zitat
Man bräuchte mal einen Empfänger an dem man das de-modulierte Signal mit einem Scope oder Logic-Analyzer auslesen kann...

Sehe ich auch so. Gibts nicht sowas fuer DVB-T Sitcks? Will keine Unsummen fuer diesen Fall ausgeben. Was Vergleichbares fuer Arme ist culfw mit X18 bzw. culfw/tools/timer.c . Bin nicht sicher, ob es mit 19200 zurechkommt, selbst mit 9600 hat es nie wirklich gut funktioniert.

A.Harrenberg · 06 Januar 2016, 09:02:38

Hi Rudi,

Zitat von: rudolfkoenig am 06 Januar 2016, 08:07:17
Ich schon, oder ich habe FLIRS nicht verstanden. Da muss man doch lange Beams senden, entweder ununterbrochen oder in Intervallen.Ich will dich aber nicht abhalten.

ich wollte das ja nicht implementieren, mir ging es erst mal darum das FLIRS als Eigenschaft in NIF erkannt wird. Soweit ich das bisher gesehen habe steht da eigentlich immer nur "Listening".

Zitat von: rudolfkoenig am 06 Januar 2016, 08:07:17
Sehe ich auch so. Gibts nicht sowas fuer DVB-T Sitcks? Will keine Unsummen fuer diesen Fall ausgeben. Was Vergleichbares fuer Arme ist culfw mit X18 bzw. culfw/tools/timer.c . Bin nicht sicher, ob es mit 19200 zurechkommt, selbst mit 9600 hat es nie wirklich gut funktioniert.

Ganz so einfach wird das wahrscheinlich nicht sein, da man ja die Frequenzwechsel mitbekommen will...
Erster Schritt aus meiner Sicht ist mal den Empfang auf 19.2 ohne Manchester, Preambel, Sync, RSSI-Schwelle umstellen und dann mal schauen ob da ein Datenpaket drin zu erkennen ist. Dann mal extern Manchester decodieren und schauen ob das wirklich ein Datenpaket war.

Wenn das funktioniert, dann müsste es umgekehrt auch mit dem Senden funktionieren.

Siehst Du denn mit Deinen Geräte Kommunikation auf 9.6k wenn Du z.B. ein Gerät aussteckst/abschirmst oder sonstwie unerreichbar machst? Meine Geräte scheinen alle nur bis auf 40k runter zu gehen und dann aufzuhören, ich habe aber auch alles nur neuere Geräte...

Gruß,
Andreas.