Kopp Free Control und NanoCUL

[Feuerdrache]

Moin,
die Einbelegung bei mir ist genau so wie in Gummibärs blog http://blog.gummibaer-tech.de/cul-stick-868433-im-selbstbau/.

Die Pinbelegung die Du da siehst bezieht sich auf die bestückte Seite.

Soweit ich das auf Deinem Bild nachvollziehen kann ist alles richtig verkabelt.

Hast Du evt hardware für einen zweiten nanoCUL rumliegen? oder eine DVBT stick den man als Sur verwenden kann. Dann könnte man eine Fehleranalyse auf der Funkseite versuchen.

Gruß FD

[stoffel]

Zweiten CUL hab ich noch nicht, hab mir jetzt noch einen bestellt... dauert etwas...
Ich vermute, mein aktueller CUL ist defekt....

[Feuerdrache]

Moin,
kann ich gar nicht glauben das der cc1101 kaputt ist.
Bin mal gespannt was Du noch so berichtest.

Falls Du die Funkseite auch angucken willst:
Ich hab mir am Anfang mal ein DVB-T Stick http://www.amazon.de/Fernsehen-Funktion-Bearbeitung-Software-Fernbedienung/dp/B00NOP0P6W/ref=cm_cr_pr_product_top?ie=UTF8 besorgt, mit dem man Signale analysieren kann und ungefähr danach http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/ gearbeitet.
Damit konnte ich ganz gut nachvollziehen, wie und ob meine Kopp Fernbedienung arbeitet. Damit habe ich aus rausgefunden, das meine 20 Jahre alten Funksteckdosen eine Variante von dem Intertechno Protokoll sprechen und es hinbekommen die auch noch einzubinden.

Gruß FD

[stoffel]

So, zweiter CC1101 ist da,
habe ihn wie den anderen zuvor angeschlossen...
Leider ohne Erfolg, gleiches Verhalten wie der erste CC1101... kein Empfang...
an der HW scheint's also doch nicht zu liegen...

Kann es sein, daß FHEM noch eine "Initialisierung" macht, die mir bei der Terminalemulation fehlt?
 

Gruß
Stef

[Feuerdrache]

Nein, hab meine Stick auch einfach mit der nanoCulFw bespielt, Terminalemulation gestartet und krS eingegeben.

Da muss doch noch was mit der Verkabelung nicht stimmen. Oder mit dem Arduino.

Dein Arduino läuft mit 16MHz und Du verbindest dich mit 38400 Baud?

Gruß FD

[stoffel]

Ja, meine Arduino läuft mit 16 MHZ, (Zeile ist im board.h nicht auskommentiert)
allerdings im makefile steht diese Zeile drin: F_CPU = 8000000
aber ich glaube das ist richtig so...

hab' ja jetzt zwei Arduinos und zwei CC1101... beide zeigen das gleiche Verhalten,
hatte auch die Kabel in verdacht, aber auch mit neuen Kabeln das Gleiche.
Hab ich die Pins wirkliche richtig belegt?
Wenn ich von der Bestückungsseite auf den CC1101 schaue (Antenne zeigt nach rechts)
dann ist oben links PIN1 (mit dem Quadrat)? Ist doch richtig so?
Meine Arduinos haben den CH340G USB Chip, die funktionieren in einer anderen Anwendung(RFID Reader) problemlos.

Habe mir jetzt mal die SW angeschaut...in kopp-fc.c
was hat das zu bedeuten:

 *    some hints:
 *   ===========
 *   - it seems, that the Firware sends the information to the display/serial interface (e.g. via DS_P() command) after this routine
 *     was left. That means, that nothing will displayed, when e.g, watchdog timer overruns.
 *     For debugging issues this is the hell :-(   
 *   - found out, that this routine makes some courious stuff if e.g. strtol() works on wrong number base (10/16/autodetect)
         
mir ist ja aufgefallen, das beim Senden (z.B.: kt30F96E0110000J) die Ausgabe im Terminal abbricht, also nicht alles ausgegeben wird.
Ich habe alles unter Windows7 laufen.

Gruß
Stef

[Feuerdrache]

Das mit dem abbrechen der Meldung finde ich komisch, klingt für mich so als wenn noch eine andere Software versucht den Port zu nutzen, zumindest kenne ich das Verhalten, wenn FHEM auf meinem Pi noch läuft, während ich mit dem Terminal auf den Stick zugreifen will.

Pin Anschluss sah auf Deinen Bild gut aus, allerdings würde mich auf Foto von der Bestückungsseite interessieren das es verschiedene cc1101 Module gibt und die nicht unbedingt die gleiche in Belegung haben.

Zu der Software kann ich nichts sagen, aber Raspii evt.

Gruß FD


Gesendet von meinem iPhone mit Tapatalk

[stoffel]

So, habe nochmal ein Bild von der Bestückungsseite her gemacht...( habe die Pins "beschriftet", so wie ich sie "verkabelt" habe)

ich habe jetzt auch im board.h testweise diese Zeile geändert:
#define TTY_BUFSIZE             512//128
danach bekomme ich beim Senden von "kt30F96E0110000J" die komplette Ausgabe....
jedoch meldet sich der CUL dann mit "V1.66 nanaoCUL433 obwohl die Zeile
//#define HAS_CC1100_433
auskommentiert ist.

aber Empfang geht immer noch nicht... es scheint evtl. doch an der Verkabelung zu liegen...
die Ports/Pins werden doch auch in der board.h definiert...
wie sieht denn deine board.h aus...
muss GDO2 mit D2 oder D4 verbunden werden?


Gruß
Stef

[RaspII]

Hi,
ist schon etwa ein Jahr her, dass die die Kopp FW geschrieben habe.
Damals sind mir einige Kuriositäten aufgefallen, die habe ich im Source Code dokumentiert, dass soll aber nichts bedeuten.

Wichtig war damals, dass man die culfw zum "RESET" treiben kann, wenn sich eine Unterroutine zu lange in einer Schleife befindet. Genau das ist mir passiert, weil ich in meiner Routine "lange Tastendrücke" simuliere (siehe Timeout beim kr.... Commando).
Final möchte ich die "langen Tastendrücke" aber nicht mehr in der culfw lösen.

Ich hab mir mal angeschaut was Du sendest:

Code: [Auswählen]

kt 30 F96E 01 10000 JDu gibst hier ein Timeout von 10sec an.
Das sollte eigentlich nichts ausmachen, da das Timeout immer nur bei Tastencode + 0x80 (langer Tastendruck) aktiv wird, trotzdem: schicke mal 5 Nullen anstelle der 10000.

Bzgl. Baudrate: ich benutzte immer 38400, funktioniert problemlos.
Bei meinen Tests (umschalten zwischen Terminal und FHEM) hatte ich mal ein ähnliches Problem wie Du (mein CUL hatte nur unvollständig oder kompletten Schrott geantwortet ).
Ich habe dann den RASPII runtergefahren und sowohl RASPII wie auch CUL von der Versorgungsspannung getrennt. Danach das System wieder hochgefahren.
Danach hat alles wieder ganz normal funktioniert. Ich habe nie rausbekommen was die Ursache war.

Wichtig:
neben dem KOPP Prototokoll darf dem nanoCUL kein weiteres Protokoll zugewiesen werden.
Gruß
RaspII

[RaspII]

Hab mir jetzt nochmal die FW angeschaut. Die Meldung sollte eigentlich wie folg lauten:

Next Character (int) after parameter (should be line end character)

Jetzt könnte folgendes passiert sein:
Die Textausgabe könnte zu lange daueren, d.h. dazu führen, dass der Watchdog der culfw aktiv wird und einen Reset auslöst.

Das würde aber bedeuten, der Watchdog Deines nanoCULs hat einen kürzeren Zyklus wie beim Standard CUL.
@Feuerdrache: hast Du das auch mal bei Dir ausprobiert (ein RAW Commando mit J am Ende senden)
@stoffel: was passiert eigentlich wenn Du folgendes Kommando schickst:

Code: [Auswählen]

kt30F96E0100000NKannst Du diesen Befehl dann einem Kopp Aktuator anlernen?

[stoffel]

Hallo RaspII, Hallo Feuerdrache,
bin jetzt schon mal einen Schritt weiter....habe ja jetzt zwei ArduinoNano + CUL-Module... beide geflasht und an zwei Rechner angeschlossen.
auf beiden Rechnern "HTerm" gestartet und verbunden.
auf der einen Seite gebe ich folgendes ein:

kt30F96E0100000N

auf dem anderen Rechner kommt folgendes:

kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000

das sieht doch schon mal gut aus, es scheinen also beide CULs zu funktionieren!
ob das stimmt/richtig ist, was da ankommt, kann ich nicht sagen...
müßte nicht genau der Sendestring mehrmals ankommen?

Und  damit kann ich auch keinen Aktuator anlernen,
habe hier eine Funksteckdose ( meine UP-Aktoren sind alle UP-verbaut, da komm ich nicht so leicht ran).
und eine 5*8 FunkFernbedienung(811402), diese möchte ich "nachbilden".
mit der Fernbedienung kann ich anlernen, da schaltet die Steckdose,

mit dem o.a. Befehl

kt30F96E0100000N

geht's leider nicht, da reagiert die Steckdose gar nicht.

Große Frage, warum nicht?

[RaspII]

Hi,
hm, so richtig gut sieht das nicht aus.

Code: [Auswählen]

kr000000000000000000Hab ich noch nie gesehen, dürfte nicht kommen (könnte aber auch ein SW Fehler sein, ich schau da nochmal rein).

Wenn Du aber nichts beim Tastendruck auf die Fernbedienung empfängst funktioniert was Grundlegendes nicht.
Ich habe in einem anderen Thread gelesen, dass jemand zwar 2 CC1101 Module miteinander koppeln konnte, nicht aber mit FS20 Komponenten kommunizieren konnte. Am Ende hat sich dann herausgestellt, dass die CC1101 Module die Frequenz nicht halten (also beide auf der falschen Frequenz gesendet/empfangen haben).

Aber zumindest scheint klar zu sein, dass Du alles richtig miteinander verbunden hast.

Die Sendebotschaft und der Empfangsstring sind tatsächlich unterschiedlich aufgebaut, ich hatte eigentlich nie vor mit Roh Daten zu arbeiten (würde ich beim nächsten mal anders machen).

Mich stimmt das ganze jetzt zuversichtlich, ich gehe davon aus, dass die neuen Module funktionieren (mit diesen Modulen hatte noch nie jemand Fehler gemeldet, mit den blauen gibt es zumindest bei 868Mhz viele Anwender die Probleme melden).
Mein Vorschlag: Abwarten bis ich die Module getestet habe, ich befürchte ansonsten ist die Zeit umsonst investiert.
Wenn ich mal Zeit habe messe ich nach ob der Quarz am CC1101 Modul auf der richtigen Frequenz läuft.

[Feuerdrache]

Hab gestern bei Aliexpress gestöbert, und festgestellt, das bei vielen "blauen" Modulen  in der Beschreibung steht das sie nicht bis 868MHz gehen. Daher ich denke ich, das es nicht nur die Antennenbeschaltung der Module ist, die bestimmt, ob sie bei 868 MHz gut funktionieren...

Na mal sehen.

Gruß FD

[stoffel]

So, bin ein gewaltiges Stück weiter....
die "blauen" senden nicht auf der eingestellten Frequenz....

Dank Feuerdrache (ich habe keine Kosten und Mühen gescheut) habe ich mir einen DVB-T Stick besorgt(siehe Link oben)
den Stick ans Laufen zu bekommen ist ein anderes Thema (ich könnte k... )
damit habe ich die Differenz zwischen Kopp FB und dem CUL sichtbar machen können.. Hurra!!!!
Habe dann in der Kopp_fc.c die Frequenzwerte angepasst:

Code: [Auswählen]

0x21, // 0D  FREQ2    *1E    21  21  FREQ[23..0] = f(carrier)/f(XOSC)*2^16  ->
0x66, // 0E  FREQ1    *C4    65  65  s.o.
0x78, // 0F  FREQ0    *EC    e8  6A  s.o.

neu kompiliert und geflasht.... und siehe da...
ich kann die Steckdose anlernen, und bekomme auch bei "krS" un ddrücken der FB folgende Ausgabe:

kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000

hier komischerweise nur 8x jede Zeile???

Mit der Software scheint wirklich etwas nicht zu stimmen,
bei mehreren FB Tasten drücken kommt hin und wider auch mal ein

40 Checksum Error

siehe screenshot unten... vor der Frequenzanpassung war der rote Block(CUL) weiter links... bei ca. 868,171Mhz
durch die Anpassung ist er nun im gleichen Bereich wir der schwarze Block (Kopp FB) bei 868,229MHz
rechnerisch eingestellt ist aber jetzt 886,407Mhz


hoffe das hilft euch auch weiter...
 


Gruß
Stef

[Feuerdrache]

Hi, coole Arbeit.
Gruß FD


Gesendet von meinem iPhone mit Tapatalk