Kopp Free Control und NanoCUL

Begonnen von stoffel, 20 Januar 2016, 10:12:35

Vorheriges Thema - Nächstes Thema

Kanumouse

Hallo RaspII,

ich habe eine CUL-Stick von Busware, insofern glaube ich nicht, dass ich von dem Problem betroffen bin.
Die Fotos habe ich als Anhang beigefügt.

Gruß

RaspII

Hallo nochmal,

Ich befürchte ich hatte da was falsch verstanden.
Die Kopp init Textdatei aus folgendem Beitrag war gar nicht von Dir?
https://forum.fhem.de/index.php/topic,47846.msg922919.html#msg922919

Dann muss das auch nicht funktionieren
Ich schicke dir meine Adresse per Privater Nachricht
RaspII

Kanumouse

Hallo RaspII,

die Kopp Init Textdatei war nicht von mir.
Ich werde dir einen Handsender und einen Empfänger zusenden.
der Empfänger ist auf die Tasten 3 und 4 des Handsenders angelernt.

Es wäre toll, wenn das zum Schluß alles klappen würde.
Die Zeit ist sekundär.

Gruß

RaspII

Hallo,
den ersten Schritt um die Botschaften zu empfangen habe ich mit Deinem Sender jetzt hinbekommen.
Läuft noch nicht 100%ig stabil, ich möchte aber gerne testen ob Frequenzen etc. auch mit einem zweiten Sender klappen.

Kannst Du bitte mal Testen ob Du ebenfalls Blöcke empfangen kannst und mir das Ergebnis zusenden?

Du musst dazu zwingend die Firmware, am besten via Terminal mit
krS2
in den Empfangsmode bekommen. In allen anderen Modis kommt vermutich nur Quatsch

Falls es klappt sende mir bitte für jeden Tastendruck (kurze und lange Drücke sollten unterschiedliche Botschaften generieren) das Ergebnis.

Anbei die erste Version.
RaspII

Kanumouse

Hallo,

ich habe die erste Version deiner Firmware getestet.

Im Ergebnis sind aus meiner Sicht schon Muster zu erkennen, aber in der Unterscheidung zwischen langem und kurzen Tastendruck scheinen mir die Blöcke nicht logisch.
Beim Empfang hat man den Eindruck, dass der eher zufällig ist, da es manchmal funktioniert und manchmal nicht, aber immerhin überhaupt erst einmal Empfang.
Manchmal empfängt man die Blöcke auch völlig abweichend von der folgenden Grundstruktur.

Empfangene Blöcke:
Kurzer Tastendruck
Taste 4 - B616CB6CAD800000
Taste 3 - B412CB6D05800000
Taste 2 - B402CB6C25800000
Taste 1 - B606CB6DA5800000

Langer Tastendruck

Taste 4 - B602CB6C04800000
Taste 3 - B416CB6DAC800000
Taste 2 - B402CB6C24800000
Taste 1 – B616CB6DAC800000

Gruß

RaspII

#230
Hi,
das sieht schonmal richtig gut aus und bestätigt auch meine Befürchtungen.

Ein Erfolg ist, dass überhaupt was kommt, d.h. die ersten beiden Bytes 0x09 und 0x64 werden ab und zu empfangen, sonst würde kein Sync ausgelöst und auch nichts ausgegeben.

Das Problem mit den Unterschiedlichen Ausgaben ist, dass ich die Baudrate nicht richtig treffe.
Und das war auch meine Vermutung. Da die Botschaftn per Software und nicht per Hardware erzeugt werden gibt es hier vermutlich Toleranzen, die nicht "Standard" sind (wenn man das überhaupt sagen kann).
Empfängt man die einzelnen Bits per Software macht das nichts, man kann die Zeiten ausmessen und so die Toleranz eleminieren.
Nutzt man wie ich das Fifo (Quasi im Sync Mode) muss man die Toleran der Hardware einhalten.

Die Tolereranz zu Deinem Sender ist bei mir ca. 2-3 %, das ist schon recht viel ohne Korrektur
Ich bin jetzt fast soweit, dass ich auch korrekte Botschaften (mit dieser Toleranz) senden kann, dann kann ich auch raustesten in welchem Rahmen der Empfänger tolerant ist.

Die Frage ist was Du damit vor hast.
Wenn Du aus FHEM raus nur senden möchtest könnte das schon reichen, wenn Du auch empfangen möchtest braucht sollte man die Bits ebenfalls per Software empfangen und den Fehler herausmessen.
Dann sollte die Basis aber nicht meine Standard Kopp Software sein, sondern eher ein Signalduino. Damit wäre es dann sogar möglich mehrere unterschiedlichen Protokolle (mit ASK/OOK Modulation) parallel zu fahren.

Ich frag dann bei den Signalduino Kollegen nach, ob es dort Ideen gibt.
Jetzt mach ich mich noch an die Senderoutine, vielleicht klappt das heute Abend ja schon.

Nachtrag:
Schade, dass Du noch keinen DBV-T Stick hast. Sonst könnten wir uns die Unterschiede der Sender ansehen. 
RaspII

RaspII

Hallo,
ich bin jetzt einen riesen Schritt weiter.
In meiner Software habe ich noch einen Fehler gefunden. Ich kann jetzt senden und die "Dose" schaltet zuverlässig.

Ich habe zwar auch noch Fehler drin die ich heute nicht mehr finde, aber einem Test sollte das nicht stören.

Der erste Schritt wäre:
den Empfang nochmal zu testen, ob Du mit der aktuellen Version Ergebnisse bekommst die reproduzierbar sind.
Du benötigst jetzt zum Aktivieren des V1 Modes einen anderen Befehl:
krT2

Danach (nur falls der Empfang dann zuverlässig klappt) sollten bei jedem Tastendruck reproduzierbare Botschaften kommen.
Bei mir ist das für Taste 3:
Bytes in Fifo: 0B  Received Data: 92DB2596D96DB2D8000000
Bytes in Fifo: 0B  Received Data: 92DB2596D96DB2D8000000
Bytes in Fifo: 0B  Received Data: 92DB2596D96DB2D8000000

und Taste 4:
Bytes in Fifo: 0B  Received Data: 92DB2596D96D92D8000000
Bytes in Fifo: 0B  Received Data: 92DB2596D96D92D8000000
Bytes in Fifo: 0B  Received Data: 92DB2596D96D92D8000000


Wenn ich dann jeweils via CUL für Taste 3:
ku92db2596d96db2d805000J

Und Taste 4:
ku92db2596d96db2d805000J

via Terminal eingebe, kann ich ebenfalls zuverlässig schalten

Probiers mal aus und sag Bescheid
RaspII

RaspII

Hallo Kanumouse,
ich habe die Firmware jetzt soweit fertiggestellt.
Mit Deinen Komponenten kann ich jetzt zuverlässig kommunizieren.

D.h. wir müssen jetzt nur noch einen Mode finden, bei dem alle Deine Sender verstanden werden (und alle Deine Kompenenten den CUL verstehen), d.h. ggf. an der Datenrate ändern.

Hier mein aktueller Stand, die Vorgehensweise für Dich wäre immer noch wie im letzten Kommentar beschrieben.
Dann los gehts !

RaspII

Kanumouse

Hi RaspII,

hatte gestern Abend deine Version 002 ausprobiert.
Der CUL empfing die Blöcke unzuverlässig. Eine nachvollziehbare Logik konnte ich nicht erkennnen.

Jetzt eben habe ich deine Version 003 getestet.
Gleiches Verhalten - Empfang unzuverlässig bzw. gar nicht.
Den Test habe ich auch mit zwei verschiedenen Wandtastern, die ich noch im Einsatz habe, wiederholt - das gleiche Ergebnis.
Der Vollständigkeit halber habe ich dir einen Auszug aus dem CuxD-Terminal beigefügt.

11:14:18 [ttyACM0] *** connect(9600:8N1) CUL868
11:14:18 [ttyACM0] <-- V
11:14:18 [ttyACM0] --> V 1.67 CUL868
11:14:18 [ttyACM0] <-- X21
11:14:26 [ttyACM0] <-T krT2
11:14:26 [ttyACM0] --> krS-ReceiveStart
11:15:11 [ttyACM0] --> Bytes in Fifo: 08  Received Data: B4024B6C96C00000
11:15:38 [ttyACM0] --> Bytes in Fifo: 08  Received Data: B6024B6C96C00000
11:15:40 [ttyACM0] --> Bytes in Fifo: 08  Received Data: B6024B6C96C00000
11:18:09 [ttyACM0] <-T krE
11:18:09 [ttyACM0] --> krE-ReceiveEnd
11:18:43 [ttyACM0] <-T krT2
11:18:43 [ttyACM0] --> krS-ReceiveStart
11:19:43 [ttyACM0] <-T krE
11:19:43 [ttyACM0] --> krE-ReceiveEnd

Mache ich da irgend etwas falsch?

Gruß

RaspII

Hallo Kanumouse,
so schlecht sieht das gar nicht mal aus.
Wenn man die Botschaften um 3 Bit nach links schiebt, sehen die letzten Bytes wie bei mir aus.
Zumindest sieht es besser aus wie beim letzten mal, d.h. die Baudrate habe ich in die richtige Richtung geschoben.
(jetzt wird es aber langsam kritisch, viel weiter komme ich nicht ohne dass Dein anderen Sender aus dem Fokus kommt).
Aber der Protokollanalyser sagt mir eigentlich das gleiche, ich liege noch nicht beim sollt.

Das zweite Problem dürfte das Sync-Byte sein. Ich synce gerade auf 0x09 und 0x64, 0x09 scheint die Blocklänge zu sein.
Wenn Das wirklich die Blocklänge ist und Dein sender nur ein anderes 2tes Byte schickt, finden wir vielleicht eine Lösung.

Ich mache mal eine V004.
Wenn Du die nächsten ein bis zwei Stunden Zeit hättest, könnten wir ein paar Tests fahren und sind dann heute evt. sogar schon erfolgreich.
Ich hänge die neue Version später an diesen Kommentar dran




RaspII

Kanumouse


RaspII

#236
So,
ich synce jetzt auf 0x00 0x09, d.h. falls 0x09 die Blocklänge ist, müsste auch bei Dir was halbwegs sinnvolles kommen.
Die Baudrate habe ich auch nochmal um ein inkrement angepasst.

Das Problem ist, dass wir jetzt eigentlich nur noch ein "echtes" Sync Byte haben, d.h. es können sich jetzt leichter falsche Botschaften einschleichen (bei OOK Modulation ist kein Signal = 0 also immer das erste Sync Byte)  :(
Bin mal gespannt was bei Dir jetzt ankommen.

Nachtrag:
bei mir ist das Problem schon sichtbar, ich empfange jetzt sporadisch falsche Syncs/Botschaften. Das ist aber noch kein Problem, die kann man später rausfiltern, weil extrem selten 2x die selben Botschaften empfangen werden.
RaspII

Kanumouse

Hallo RasPII,

mit der Version 004 empfange ich jetzt bei jedem Tastendruck 2 Blöcke.
Ich habe die Tasten in folgender Reihenfolge betätigt: 1, 2, 3, 4

13:06:24 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C96B25B25B2D6DB
13:06:25 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C96B25B25B2DADB
13:06:35 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C96B25B25B2DE5B
13:06:35 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C965B5B25B2DB5B
13:06:45 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C96B25B25B2F6CB
13:06:45 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C94B25B25B296CB
13:06:50 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C84125B25B2924B
13:06:50 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C96125B25B2DA4B
13:06:51 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 6C94B25B25B2B64B
13:06:55 [ttyACM0] --> Bytes in Fifo: 08  Received Data: 8178000000000000

Es werden aber jetzt auch Blöcke empfangen ohne das ich eine Taste betätige (z.B. der letzte Bock oben).

Gruß

RaspII

#238
Super, jetzt sieht das schon aus wie bei mir   ;D

Das Du jetzt auch Blöcke empfangst ohne Tastendruck liegt wie gesagt am schlechteren Sync, das muss ich später per Software abfangen.
Der nächste Schritt ist jetzt, dass wir bei Dir die richtige Baudrate erwischen.

Hast Du immer die selbe Taste gedrückt?
RaspII

Kanumouse

Nein, nacheinander 1, 2, 3, 4.