Kopp Free Control und NanoCUL

[stoffel]

Hallo RaspII,
habe eigentlich nur im aktuellen "trunk" 549  die  Datei kopp-fc.c  angepasst. (Frequenzanpassung für die blauen CC1101)

Viel Spaß am WE 
Gruß
Stef

[RaspII]

Ok,
und ich hab mir gestern abend den nanoCUL gekillt
Mal sehen ob ich das kurzfristig hinbekomme.



Gesendet von meinem SM-G900F mit Tapatalk

[RaspII]

Sodele, ein paar Neuigkeiten habe ich.
der nanoCUL ist immer noch defekt  ,kommt davon wenn man schnell schnell macht (hudelt).

Dafür konnte ich jetzt endlich den ProMicro wiederbeleben (nachdem ich den Bootloader vom Nano draufgeflasht habe, konnte man ihn wieder ansprechen, keine Ahnung warum der falsche Bootloader funktionierte, der richtige aber nicht). Nachdem der falsche Bootloader lief musste ich noch den richtigen Bootloader flashen, danach ein leeres Arduino Projekt laden, danach liefs wieder.

Ich hab die kopp-fc.c von stoffel (mit angepasster Frequenz) genommen und siehe da, ich kann das Kopp Protokoll empfangen und senden,
d.h. die Frequenz Abweichungen sind zumindest stabil.
Das Modul versteht den Kopp Sender, der Kopp Dimmer versteht das Modul.
Allerdings: jämmerliche Reichweite und viel zu breites Spektrum.
Aber zumindest läuft mein System, die Verdrahtung hatte gestimmt. Danke an alle, der Tipp bzgl. SDR war Gold wert (man sieht sofort wo das Problem liegt).

Stoffel, Dich muss ich entäuschen, bei mir gibt es keine Checksummenfehler, alles läuft wie erwartet (bis auf die ebenfalls erwarteten Reichweiteprobleme).
Sobald mein nanoCUL wieder läuft (Ersatzteile sind bestellt), schau ich nochmal nach Dein Fehler bei mir reproduzierbar ist.
Allerdings muss man solche Effekte fast erwarten, wenn man einen 5V CUL mit einem 3,3V CC1101 Modul koppelt (der CC1101 muss höhere Ströme/Stromspitzen ertragen, das liegt ausserhalb der Spec).

Jetzt noch ein Hinweis:
In meinem System mit Pro Micro ist / bleibt wohl der Arduino Boot Mechanismus aktiv (2x Reset drücken um in den Boot Mode zu kommen).
Ob der CUL Bootmechanismus zusätzlich aktiv ist, kann ich nicht bewerten, da bei mir der HWB Schalter nicht verbaubar ist (Signal ist fest auf Masse beim Pro Micro).

Das ich die letzten Tage nicht weitergekommen bin lag daran, dass die culfw inzwischen wohl so groß geworden ist, dass diese nicht mehr gemeinsam mit dem Arduino Bootloader auf den m32u4 passt.
Ich hatte deshalb beim Programmieren immer verify Error bekommen und die culfw ist danach abgestürzt. Nachdem ich jetzt ein paar Module aus dem Makefile entfernt habe läuft das alles.

Wie geht es jetzt weiter:

• Nachdem der nanoCUL m.E. kein richtig tauglicher Proband ist, auch der Pro Micro basierte CUL passt nicht so richtig, da man nicht an alle Signale kommt (HWB Schalter) suche ich nach einer Lösung mit 3,3Volt/8 Mhz 32u4 (am besten eine Breakout Version bei der alle Pins auf Pfostenstecker gelegt sind).
  Bisher habe ich nur Module teurer 20€ gefunden, falls jemand einen günstigeren Tipp hat, nur her damit.
  Bis dahin überlebe ich mit dem ProMicro und nutze solange halt den Arduino Bootloader (scheint ja halbwegs stabil zu laufen)
• Dann warte ich noch ab wie sich die bestellten 868 Module verhalten, läuft das alles positiv beschreibe ich die Lösung hier bzw. in einem neuen Blog

Habe noch meine Schaltung angehängt

RaspII

[RaspII]

Hi,
heute ist mein neues CC1101 Modul (Briefmarke, echte 868Mhz) gekommen.
Habs angeschlossen, die Frequenzeinstellungen für das Kopp Protokoll in der culfw wieder auf den Originalwert gesetzt.
Kaum zu glauben, alles lief auf Anhieb.

Anbei noch meine Schaltung
RaspII

[RaspII]

Hallo zusammen,
ich hab noch etwas mit dem blauen 433 Mhz Modul geforscht.
Dazu hab ich es bei 433 Mhz in Betrieb genommen, meine 433 Mhz Funksteckdosen kann ich damit auch steuern.
Allerding sehe ich auch hier eine Frequenzabweichung von ca. 120khz, d.h. etwa die hälfte der Abweichung die wir bei 868 Mhz sehen (Soll Frequenz ist 433.920Mhz). Der Handsender (Bild Mitte) sendet auf der korrekten Frequenz)

Ich vermute mal das ist der Quarz, mal schaun ob ich das auch noch messtechnisch klären kann (mal sehen was der China Oszi taugt)
Klar ist nur, dass ich keine weiteren "blauen" Module mehr kaufen werde.

Bei meinen Untersuchungen habe ich auch rausbekommen, das der Port / Pin:

Code Auswählen Erweitern


#define MARK433_PORT            PORTB
#define MARK433_PIN             PINB
#define MARK433_BIT             6

den CUL auf 433Mhz Betrieb umschaltet, sobald er auf Masse gelegt wird (zumindest meldet sich der CUL dann als 433 Mhz Modul)

Code Auswählen Erweitern


pi@raspberrypi2 /opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Mär  9 00:22 usb-busware.de_CUL433-if00 -> ../../ttyACM1


Ich melde mich wieder sobald ich Neuigkeiten habe.

Nachtrag zum Bild:
Die Frequenzangabe 433,862Mhz gehört zum gelben Cursor, also zur "zu niedrigen Frequenz"
Gruß
RaspII

[stoffel]

Hallo mal wieder,
so... mein "echtes" 868Mhz Modul ist jetzt angekommen....
und ich habe mir einen Arduino pro Mini besorgt... der läuft mit 3.3V (wie das Modul)
... habe den Arduino mit der original FW geflasht (also keine Frequenzverschiebung) und...
es funktioniert wie zuvor....
kurze Tastendrücke auf die Kopp FB kommen einwandfrei an...
bei einen langen Druck auf eine Taste habe ich wieder den Effekt, daß ich mehrere Zeilen bekomme + Checksum Error

kr0788109501CC0F0260    <-- kurzer Tastendruck auf Taste 1

kr0788109681CC0F02E3    <-- langer Tastendruck auf Taste 1
E4 Checksum Error
kr07881097F7CC0F0294
kr07881098F7CC0F029B
B2 Checksum Error

@Raspi
konntest du schon etwas rausfinden, warum hier mehrere Zeilen und die Checksum Fehler kommen?

habe einen ESP8266 an den Arduino angeschlossen, mit dem habe ich einen kleinen WebServer erstellt,
somit kann ich über einen Webbrowser mit dem CUL "kommunizieren" (brauche also kein USB...hat der Pro Mini nicht)
....das funktioniert bisher einwandfrei...


Grüße
Stef

[RaspII]

Hi,
den Checksumme Fehler kann ich nicht  nachstellen (gibt es bei mir nicht)
Wenn wir hier weiterkommen wollen brauch ich ein Systems zum Debuggen.
Kannst Du mir bitte vorab deinen verdrahtungsplan (cc1101 -pro mini, am besten von Hand erstellen) und Deine board.h zusenden?

Gesendet von meinem SM-G900F mit Tapatalk

[stoffel]

Bild auf die Schnelle erstellt... (Verdrahtung ist analog zu FHEM SelbstbauCul)
siehe auch http://www.fhemwiki.de/wiki/Selbstbau_CUL

[RaspII]

Ach ja,
ich hatte Dir noch nicht alle Fragen beantwortet:
Bei einem kurzen Tastendruck wird nur eine Botschaft vom CUL zu FHEM geschickt.

Bei einem langen Tastendruck kommt beim Drücken der Taste die erste Botschaft

Code Auswählen Erweitern


kr0788109681CC0F02E3
beim Loslassen der Taste wird vom Sender 2x die "Fertig/Ende" Botschaft gesendet

Code Auswählen Erweitern


kr07881097F7CC0F0294
kr07881098F7CC0F029B


Das wäre alles soweit ok, das sieht man am fortlaufenden Blockzähler (96, 97, 98) bei diesen 3 Blöcken.
Am Blockzähler des kurzen Tastendrucks (95) kann man sehen, dass diese Taste unmittelbar zuvor gedrückt wurde.
Nur dass beim langen Tastendruck immer mal wieder ein Checksummenfehler kommt darf nicht sein.

Du musst wissen, dass jeder der angezeigten Blöcke vom Sender tatsächlich 13x gesendet wird (mit identischem Blockzähler).
Da das aber jeweils der selbe Befehl ist, gibt meine culfw dies jeweils nur 1x zu FHEM weiter. D.h. immer nur wenn sich der Blockzähler verändert hat geht eine neue Botschaft zu FHEM. D.h. beim langen Tastendruck geht jeweils eine der 13 Übertragungen schief. Das habe ich bei mir nie gesehen.

Dann nutzt Du ja auch meine neue Software die die "Nullbotschaften" unterdrückt (die es aber wohl immer noch gibt).
Auch das hab ich bei mir noch nie gesehen.

Hattest Du eigentlich schonmal den CSn Pin mit 10kOhm zusätzlich an die 3,3V verbunden?
Ich denke nicht wirklich, dass das was bringt, allerdings ist das der einzige Unterschied den ich in Deiner Verdrahtung im (Vergleich zu meiner) finden kann.
Der einzige weitere Unterschied ist, dass der ProMini einen Atmega 328 als µC hat (soweit ich weiss) und mein ProMicro ein 32U4 wie der original CUL.
(Dein Quarz hat 8 Mhz?, nehme ich an)

Ich könnte Dir noch eine modifizierte kopp_fc.c Datei zusenden, die auch den fehlerhaften Block ausgibt.
Viel wird das aber nicht bringen (man sieht nur wo im Block der Fehler auftritt).

Für eine richtige Fehlersuche müsste ich Deine HW bei mir haben oder zumindest den Fehler auf meiner HW (allerdings ein ProMicro) nachstellen können.

[stoffel]

Hallo Raspi,
Du bist aber früh unterwegs...
Vielen Dank für die ausführliche Beschreibung....
Fange die Fehler(?) jetzt in meiner Auswertesoftware ab...
Den 10k Widerstand hatte ich drin, bringt aber nix...kein Unterschied....

Ja der Arduino pro mini hat 8MHz.
Gruß
Stef

[RaspII]

Hi,
ich hab jetzt eine kopp-fc.c als "Debug Version gebaut"
Hier erfolgt keine Frequenzkorrektur, müsste also inzwischen für Dich passen.

Ich gebe hier alles an die Konsole aus, was Empfangen wird, und zwar

• Jede empfangene Botschaft mit korrektem Sync Pattern wird weitergereicht
• egal ob Checksummen Fehler oder nicht

Für den Betrieb mit FHEM taugt das ganze nicht, die Aktoren würden dort ca. 13x schalten/toggeln
Zur Fehlersuche könnte es uns ein Stück weiterbringen.

Ich hab es jetzt bei mir geschafft auch die "falschen" "Nullbotschaften" zu empfangen.
Man kann das Hinbekommen wenn z.B. GDO0 und GDO2 vertauscht sind
GDO2 muss in der board.h mit CC1100_xyz verknüpft werden

Code Auswählen Erweitern


define CC1100_IN_DDR      DDRC // hier muss jeweils der mit GDO2 verbunden Pin spezifiziert sein
define CC1100_IN_PORT     PINC
define CC1100_IN_PIN      PC6
define CC1100_IN_IN       PINC


Compiliere mal Deine Version mit der angehängten kopp.c und schick mir mal eine Log mit Terminalprogramm zu.
Vorher natürlich "krS" eingeben und dann am besten wieder die Tasten drücken wie Du es oben schon mal gemacht hast.

[stoffel]

Hallo RaspII,
habe deine Version eingebaut:
so sieht der log aus bei einem kurzen Tastendruck und anschließend einem langen

Code Auswählen Erweitern


kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227   

kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
67 Checksum Error
kr078810A381CC0F0267
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
8F Checksum Error
kr078810A5F7CC0F028F



meine board.h sieht so aus:

* CC1101 GDO2 Rx Interrupt */
#define CC1100_IN_DDR     DDRD
#define CC1100_IN_PORT        PIND
#define CC1100_IN_PIN           PD2
#define CC1100_IN_IN             PIND

nehme ich dein Einstellungen von oben, empfängt das Modul nichts...
ich versteh' das nicht? wann ist es PD2 und wann PC2 respektive PC3 bzw PC2?
und bei dir steht PC6 ?


Gruß
Stef

[RaspII]

Hi,
bzgl. GDO2: nein, bei Dir ist alles ok.
Ich hatte bei mir zum Test mal die Pins vertauscht und ich nutze ein Micro CUL mit anderer Pinbelegung. Deine board.h passt zum Schaltplan, alles ok.
Da bei Dir keine Nullbotschaften kommen scheint erst mal alles korrekt zu sein.

Was bei Dir auffällt ist, dass die Botschaften nur 8x kommen (bei meinen Sendern wird immer 13x gesendet).

Folgende Ideen habe ich noch:
a) Dein Sender ist älterer Bauart und hat Bugs (??)
b) Deine Batteri im Sender ist schwach
c) Dein Sender ist defekt (hast Du einen zweiten zum testen?)
d) Die Frequenzeinstellungen für das Kopp Protokoll wurden verändert
    -> werden in Deiner fhem.cfg irgend welche Frequenzen angepasst?
    -> Verwendest Du noch andere Protokolle parallel.

Was passiert eigentlich wenn Du via FHEM/nanoCUL Daten sendest. Funktioniert das alles problemlos?
Falls ja, könnte ich einfach die Ausgabe des Checksummenfehlers unterdrücken und danach sollte auch bei Deinem System alles funktionieren.

Falls Du einen zweiten CUL/nanoCUL hast, kannst Du auch mal mit diesem Daten senden und prüfen ob Checksummenfehler geworfen werden.

Gruß
RaspII

[stoffel]

Hallo RaspII,

Was bei Dir auffällt ist, dass die Botschaften nur 8x kommen (bei meinen Sendern wird immer 13x gesendet).

ja das stimmt, habe in den alten Logs nachgeschaut, hatte früher auch 13x, jetzt nur 8x

zu a: Sender ist schon älter, ca. 5-6 Jahre?
zu b: habe die Batterien getauscht, jedoch keine Änderung
zu c:  funktioniert mit den Aktoren ganz normal, .... habe auch leider keinen zweiten Sender...
zu d:  ich setze noch kein FHEM ein, wie oben erwähnt, habe ich noch eine "HomeAutomation-Eigenentwicklung",die bekommt/sendet die Daten des CUL über USB(COM-Port) bzw. jetzt über ESP8266 (http-Web server)

wenn ich mit dem nanoCUL sende, funktionieren die Aktoren (soweit sie überhaupt noch funktionieren, -> defekte Kondensatoren) einwandfrei, jedoch nicht mit der Reichweite, die ich mit der FB habe.

Unterdrücken des Checksum Fehler wäre gut....

Gruß
Stef

[RaspII]

ok,
dann mache ich Dir heute Abend mal eine Version ohne Fehlermeldung bei Checksummenproblemen.
Ich werde das Modul so dann auch offiziell einstellen.

Bzgl. Frequenzeinstellungen:
konfiguriert Du am nanoCUL noch irgend etwas von Hand bzw. oder verlässt Du Dich auf kopp-fc?
(nur die Ausgangsamplitude darf manuell verändert werden, damit kannst Du auch testen ob bzgl. Reichweite noch was zu machen ist)

Gesendet von meinem SM-G900F mit Tapatalk