CUL: Unterschied zwischen den Versionen
Yfhem (Diskussion | Beiträge) K (Updated forum link.) |
(Umformatiert, typos) |
||
(78 dazwischenliegende Versionen von 20 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist | Ein '''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer [[CUL Ausstattung|Antenne]]. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen. | ||
Im | == CUL HW == | ||
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module ([[CUN]]O), Module zum direkten Aufstecken auch einen Raspberry Pi ([[COC]]), und auf Arduino basierende Lösungen ([[SIGNALduino]]). | |||
== Einführung == | |||
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe [[CUNO]] (RF+OneWire/LAN-Übergang), [[COC]] (RF+OneWire/Rasberrybus-Übergang), CSM usw. | |||
Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") werden die amplitudenmodulierten 1 kHz breiten Signale per [[#FW|culfw]] direkt dekodiert und dann per USB weitergegeben. | |||
Das CUL kann mittels des '''[[CUL (Modul)|CUL Moduls]]''' (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden. | |||
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe {{Link2Forum|Topic=68145|LinkText=Link}} | |||
Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}. | |||
Frequenz und Bandbreite können | Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist. | ||
Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt. | |||
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen. | |||
Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden. | |||
== Definition in FHEM == | |||
Das CUL wird definiert mit | |||
<code>define <name> CUL <device> <FHTID> </code> | |||
als z.b.: | |||
<code>define myCUL CUL /dev/ttyUSB0 0000</code> | |||
Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet. | |||
Was <device> ist hängt von der Art des CUL ab: | |||
=== Geräte, die an USB angeschlossen sind (CUL/CUN) === | |||
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden: | |||
modprobe usbserial vendor=0x03eb product=0x204b | |||
In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0. | |||
Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400. | |||
Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS. | |||
=== Geräte, die mit dem Netzwerk verbunden sind (CUN(O)) === | |||
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323 | |||
Weiteres in der commandref [https://fhem.de/commandref.html#CUL] | |||
== Hinweise zum Betrieb mit FHEM == | == Hinweise zum Betrieb mit FHEM == | ||
'''Anmerkung:'''Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per | '''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. | ||
* Ist Empfang eingeschaltet ? | * Ist Empfang eingeschaltet ? | ||
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13) | *: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13) | ||
* Auslesen der | * Auslesen der culfw Version: | ||
*: <code>get myCUL raw V</code> | *: <code>get myCUL raw V</code> | ||
* LED | * LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1) | ||
*: <code>set myCUL raw l00</code> | *: <code>set myCUL raw l00</code> | ||
* LED soll | * LED einschalten | ||
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen | |||
* LED soll blinken (einmal in der Sekunde) | |||
*: <code>set myCUL raw l02</code> | *: <code>set myCUL raw l02</code> | ||
* Reboot / Reset des CUL: | * Reboot / Reset des CUL: | ||
*: <code> | *: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware) | ||
* Freie CUL Sendezeit ([[1% Regel]]): | * Freie CUL Sendezeit ([[1% Regel]]): | ||
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms | *: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots | ||
* Freie Kapazität des FHT Buffers | * Freie Kapazität des FHT Buffers | ||
*: <code> get myCUL raw T03</code> | *: <code> get myCUL raw T03</code> Ergebnis Bytes in HEX. Leer = 4a | ||
* Inhalt des FHT Buffers | * Inhalt des FHT Buffers | ||
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes | *: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer | ||
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]] | |||
*: <code> get myCUL raw T01</code> | |||
* Eingestellte Frequenz, Bandbreite etc. Ausgeben | * Eingestellte Frequenz, Bandbreite etc. Ausgeben | ||
*: <code> get myCUL ccconf</code>. <br>Rückgabe z. B.: <br><code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code> | *: <code> get myCUL ccconf</code>. <br>Rückgabe z. B.: <br><code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code> | ||
* eingestelle Bandbreite erhöhen (z. | * eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn): | ||
*:<code>set myCUL bWidth 464</code> | *:<code>set myCUL bWidth 464</code> | ||
* Einstellen der Sendestärke: | * Einstellen der Sendestärke: | ||
Zeile 44: | Zeile 85: | ||
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen | Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen | ||
-10/-5/0/5/10 Sendeleistung in | -10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. | ||
Werte x00-x04 sind '''mit''' Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]]. | Werte x00-x04 sind '''mit''' Ramping (''sanfter'' Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]], da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl). | ||
'''Hinweis:''' Beim CUL im | '''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}). | ||
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit : | Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit : | ||
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt | * <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt | ||
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet | * <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet | ||
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet | * <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet | ||
* <code>set CUL1 raw X80</code> RSSI / | * <code>set CUL1 raw X80</code> RSSI / Signalstärke jeder Flanke wird gemeldet | ||
* <code>set CUL1 raw X21</code> normal Modus | * <code>set CUL1 raw X21</code> normal Modus | ||
Achtung: Auf | Achtung: Auf Groß- und Kleinschreibung des "x,X" achten! | ||
Die kompletten Kommandos mit Erklärung für CUL | Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden. | ||
== Versionen == | == Versionen == | ||
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden. | Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden. | ||
* CUL V1 - AT90USB162 Prozessor, 0, | * CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt. | ||
* CUL V2 - AT90USB162 Prozessor, 0, | * CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt. | ||
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 | * CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig. | ||
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 | * CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus. | ||
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig. | |||
== Firmware {{Anker|FW}} == | |||
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der | |||
* [http://culfw.de CUL Firmware Homepage] | |||
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden. | |||
Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der | |||
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw] | |||
Hier kann man sich z.B. mit | |||
<syntaxhighlight lang="bash"> | |||
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw | |||
</syntaxhighlight> | |||
die aktuelle Version laden. | |||
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen: | |||
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann. | |||
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen. | |||
Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend). | |||
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen. | |||
== Sendefrequenz == | == Sendefrequenz == | ||
Das CUL gibt es in Ausführungen für 868 und 433 MHz. | Das CUL gibt es in Ausführungen für 868 und 433 MHz. | ||
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im SlowRF Mode auch durch direkte Befehle aus | Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge. | ||
Es ist | |||
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt. | |||
Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno. | |||
== Antenne == | |||
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar. | |||
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus. | |||
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik. | |||
* '''Anpassung''' Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen. | |||
* '''Abstrahlung''' Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten. | |||
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne. | |||
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene. | |||
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter. | |||
Weitere Informationen sind im {{Link2Forum|Topic=93021|LinkText=Antennenthread}} des Forums zu finden. | |||
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn"). | |||
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird. | |||
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser. | |||
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind. | |||
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne. | |||
== Antennenlänge == | |||
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss. | |||
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar: | |||
868,35 MHz (z.B. HM, FS20, FHT …) | |||
1/4 Lambda = 8,63 Zentimeter | |||
1/2 Lambda = 17,26 Zentimeter | |||
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung) | |||
433,92 MHz (z.B. Intertechno …) | |||
1/4 Lambda = 17,27 Zentimeter | |||
1/2 Lambda = 34,54 Zentimeter | |||
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.: | |||
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz | |||
17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz | |||
34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz | |||
== Bekannte Probleme == | == Bekannte Probleme == | ||
Im Gegensatz zu den original FHZ Zentralen ist das CUL recht | |||
=== RF-Tuning === | |||
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit. | |||
Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen: | Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen: | ||
* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden. | * Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden. | ||
*: <code>set | *: <code>set CUL freq 868.350</code> | ||
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ( | * Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren. | ||
*: <code>set | *: <code>set CUL sens 8</code> | ||
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten. | * Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten. | ||
= Links = | *: <code>set CUL bWidth 464</code> | ||
== Selbstbau-/Bastelprojekte == | |||
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte: | |||
* [[Selbstbau CUL]] | |||
* [[FHEMduino]] | |||
* [[SIGNALduino]] | |||
* [[MapleCUN]] mit STM32 Mikrocontroller | |||
== Links == | |||
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de] | * Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de] | ||
* [ | * Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im FHEM Forum ergänzt/ersetzt | ||
* CUL commandref [https://fhem.de/commandref.html#CUL] | |||
* | |||
[[Kategorie: | [[Kategorie:Interfaces]] | ||
[[Kategorie:CUL]] | [[Kategorie:CUL|!]] | ||
[[Kategorie:433MHz]] | |||
[[Kategorie:868MHz]] |
Aktuelle Version vom 6. Dezember 2023, 17:05 Uhr
Ein CUL (CC1101 USB Lite) ist eine Radiofrequenz/USB-Schnittstelle bestehend aus einem USB-Dongle mit externer Antenne. Im USB-Stecker kann ein 8 bit Atmel Prozessor die im ISM/SRD-Band empfangenen RF-Daten onboard vorverarbeiten. Je nach aufgespielter Firmware kann das CUL verschiedene 868MHz Protokolle empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS Protokollfamilien. Durch eine kurzzeitige Umschaltung auf 433 MHz sind weitere Protokolle zugänglich, z. B. Intertechno, viele Baumarkt-Funksteckdosen.
CUL HW
Im Zusammenhang mit diesem Artikel ist vor allem vom "echten" CUL die Rede, als dem USB Hardware-Dongle des Hersteller Busware. Es gibt aber diverse andere Hardware-Schnittstellen, die sich ebenfalls wie ein CUL verhalten, z.b. Netzwerkattached Module (CUNO), Module zum direkten Aufstecken auch einen Raspberry Pi (COC), und auf Arduino basierende Lösungen (SIGNALduino).
Einführung
Die Firmware (culfw) ist quelloffen. Sie wird auch von verwandten Schnittstellen verwendet, siehe CUNO (RF+OneWire/LAN-Übergang), COC (RF+OneWire/Rasberrybus-Übergang), CSM usw.
Im Umfeld von FS20/FHT/EM/S300/HMS ("rfmode - SlowRF") werden die amplitudenmodulierten 1 kHz breiten Signale per culfw direkt dekodiert und dann per USB weitergegeben.
Das CUL kann mittels des CUL Moduls (00_CUL.pm) von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.
Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem HMLAN Konfigurator betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim Flashen der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich. Es ist jedoch nicht angeraten, den CUL bei HM-Geräten zu verwenden, siehe Link
Ebenso gibt es ein Modul zur Ansteuerung der MAX! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich nicht angeraten.
Ferner ist der Einsatz eines CUL als RFR CUL für den SlowRF Mode (jedoch nicht für den HomeMatic Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.
Alle diese Modi sind in der Original-culfw enthalten und werden z.B. durch die Wahl des rfmode eingestellt.
Obwohl die nominale Betriebsfrequenz der FHT- und FS20-Komponenten 868,35 MHz beträgt, ist bei aktuellen CUL-Firmwareversionen zum Betrieb mit FHEM die Frequenz 868,30 MHz vorgesehen. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, obwohl diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten SlowRF Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.
Frequenz und Bandbreite können daher im SlowRF Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.
Definition in FHEM
Das CUL wird definiert mit
define <name> CUL <device> <FHTID>
als z.b.:
define myCUL CUL /dev/ttyUSB0 0000
Da FHT zur Heizungssterung kaum noch eine Rolle spielen dürfte ist die Vergabe der FHT-ID 0000 sinnvoll, da das CUL dann nicht auf FHT Communication achtet.
Was <device> ist hängt von der Art des CUL ab:
Geräte, die an USB angeschlossen sind (CUL/CUN)
<device> gibt die serielle Schnittstelle an, mit der der CUL kommuniziert. Der Name der seriellen Schnittstelle hängt von der gewählten Distribution und USB-Treiber ab, unter Linux ist dies das Kernel Modul cdc_acm und üblicherweise wird die Schnittstelle /dev/ttyACM0 genannt. Wenn die Linux Distribution über kein Kernel Modul cdc_acm verfügt, dann kann die Schnittstelle über usbserial mit dem folgenden Befehl erzeugt werden: modprobe usbserial vendor=0x03eb product=0x204b In diesem Fall ist diese Schnittstelle dann wahrscheinlich /dev/ttyUSB0.
Wenn der Name der Schnittstelle ein @ enthält, kann nachfolgend die verwendete Baudrate angegeben werden, z.B.: /dev/ttyACM0@38400.
Wenn die Baudrate mit "directio" angegeben wird (z.B.: /dev/ttyACM0@directio), wird das Perl Modul Device::SerialPort nicht benötigt und FHEM öffnet die Schnittstelle mit einfachem Dateizugriff. Dies sollte dann funktionieren, wenn das Betriebssystem vernünftige Standardwerte für die serielle Schnittstelle verwendet, wie z.B. einige Linux Distributionen oder macOS.
Geräte, die mit dem Netzwerk verbunden sind (CUN(O))
<device> gibt die Hostadresse:Port des Gerätes an, z.B. 192.168.0.244:2323
Weiteres in der commandref [1]
Hinweise zum Betrieb mit FHEM
Anmerkung: Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); myCUL ist dabei nur ein Platzhalter und durch den Namen Ihres CUL zu ersetzen.
- Ist Empfang eingeschaltet ?
get myCUL raw C35
(13 = ja, z. b.: C35 = 0D / 13)
- Auslesen der culfw Version:
get myCUL raw V
- LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
set myCUL raw l00
- LED einschalten
set myCUL raw l01
Blinkt bei Senden oder Empfangen von Paketen
- LED soll blinken (einmal in der Sekunde)
set myCUL raw l02
- Reboot / Reset des CUL:
set myCUL raw B00
Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
- Freie CUL Sendezeit (1% Regel):
get myCUL raw X
2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auchget myCUL credit10ms
ergibt Sendezeit in 10ms Slots
- Freie Kapazität des FHT Buffers
get myCUL raw T03
Ergebnis Bytes in HEX. Leer = 4a
- Inhalt des FHT Buffers
get myCUL raw T02
(CUL V2 Buffer ist 74 Bytes groß, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
- Eingestellte FHT-ID
get myCUL raw T01
- Eingestellte Frequenz, Bandbreite etc. Ausgeben
get myCUL ccconf
.
Rückgabe z. B.:myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB
- eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
set myCUL bWidth 464
- Einstellen der Sendestärke:
set myCUL raw x09
Einstellen der Sendeleistung.
Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen -10/-5/0/5/10 Sendeleistung in dB. Default ist x08 = +5dB. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.
Werte x00-x04 sind mit Ramping (sanfter Flankenanstieg anstatt Rechteck) und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. RFR CUL, da die CULs Rampingsignale nicht verstehen (FS20 / FHT und ähnliche Empfänger aber sehr wohl).
Hinweis: Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter nicht verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung (Quelle).
Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
set CUL1 raw X61
Communication wird im Detail angezeigtset CUL1 raw X25
auch checksum Fehler / unerkannte Protokolle werden gemeldetset CUL1 raw X2F
alle empfangenen Flanken werden gemeldetset CUL1 raw X80
RSSI / Signalstärke jeder Flanke wird gemeldetset CUL1 raw X21
normal Modus
Achtung: Auf Groß- und Kleinschreibung des "x,X" achten!
Die kompletten Kommandos mit Erklärung für CUL sind in der commandref zu finden.
Versionen
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.
- CUL V1 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
- CUL V2 - AT90USB162 Prozessor, 0,5 kB RAM, 16 kB Flashmemory, 0,5 kB EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für SlowRF Geräte und zugleich HomeMatic Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi zeitgleich betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
- CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kB EEPROM). Voll einsatzfähig.
- CUL V4 - ATMega32U2 Prozessor, 1 kB RAM, 32 kB Flashmemory, 1 kB EEPROM. Voll einsatzfähig. Genaugenommen ein "Sparmodell" des V3, um Lieferengpässe des ATMega32U4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.
Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.
Firmware
Die für den CUL und verwandte Hardware wie CUN und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
Dort kann die jeweils aktuelle Version nachgesehen und heruntergeladen werden. Alte Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
Hier kann man sich z.B. mit
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
die aktuelle Version laden.
Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
- Alternative culfw for cul devices auf GitHub und im Forum mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe Forum) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem MAX Cube betrieben werden kann.
- Timestamp Firmware mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.
Alternativ zu den [a]culfw-Firmwares gibt es SIGNALduino (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).
Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weglassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.
Sendefrequenz
Das CUL gibt es in Ausführungen für 868 und 433 MHz. Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im SlowRF Mode auch durch direkte Befehle aus FHEM (im HomeMatic Mode derzeit nicht unterstützt). Der bauliche Unterschied der 868 und 433 MHz CULs ist ein auf das Frequenzband richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.
Es ist durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt. Besser ist aber die Nutzung eines dedizierten 433 MHz CUL für Intertechno.
Antenne
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar. Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.
Bei einer Antenne sind zwei Dinge auseinanderzuhalten: Einmal die Anpassung sowie die Abstrahlungscharakteristik.
- Anpassung Eine Antenne ist typischerweise für eine bestimmte Frequenz konstruiert. Wenn die Konstruktionsfrequenz nicht mit der Frequenz übereinstimmt, auf der die Antenne senden und empfangen soll, ist die Anpassung schlecht. Dies führt zu Verlusten bei der Übertragung. Typische Kennwerte für eine Anpassung sind das Stehwellenverhältnis (SWR) sowie die Impedanz. Beide Größen können per Messgerät bestimmt werden, inzwischen gibt es für 150 Euro entsprechende Geräte. Wer eine Antenne selbst konstruiert, sollte ein solches Gerät zumindest ausborgen, um seine Antenne zu bestimmen.
- Abstrahlung Es gibt mehrere Arten von Antennen, die sich in der Art der Strahlung unterscheiden. Richtantennen versuchen Signale nur in eine bestimmte Richtung zu versenden, Dipole versuchen in die gesamte Umgebung zu senden bzw zu empfangen. Während es bei Anpassung nur die Kategorien "gut" und "schlecht" gibt, ist bei der Abstrahlung eher auf "zweckmäßig" und "unzweckmäßig" zu achten.
Grundsätzlich hängen Abstrahlung und Antennengewinn zusammen. Die Energie, die eine (perfekt angepasste) Antenne strahlt, wird durch die Antennenkonstruktion weder verdoppelt oder halbiert, sondern nur gebündelt. Während ein Dipol in alle Richtungen abstrahlt, bündelt eine Richtantenne dieselbe Energie in eine bestimmte Richtung. Insofern muss man bei der Antennenkonstruktion überlegen, woher die Signale kommen bzw wohin sie gehen sollen. Jeder Antennengewinn geht einher mit einer Einschränkung bei der Sende/Empfangsrichtung, es sei denn, man verbessert die Anpassung der Antenne.
Leider kann man auch bei gekauften Antennen nicht davon ausgehen, dass sie korrekt angepasst sind. Es gibt Berichte im Forum, wonach es insbesondere bei 433 MHz-Antennen eher ein Glücksspiel ist, ob man eine vernünftig angepasste Antenne bekommt. Daher kann es durchaus sein, dass eine Eigenbauantenne wesentlich bessere Werte liefert als eine käuflich erworbene.
Eine zentrale Größe bei der Anpassung ist die Länge der Antenne. Wenn man einen Dipol verwendet, muss diese zweckmäßigerweise so groß sein wie ein Viertel der Wellenlänge ("Lambda/4"). Die sind bei 868 MHz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Anpassung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.
Weitere Informationen sind im Antennenthread des Forums zu finden.
Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar "Lambda" lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn"). Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Besonders wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht empfangen wird.
Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr dB" und speziell "länger" ist also nicht automatisch besser.
Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.
Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.
Antennenlänge
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch ein Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur ein Kompromiss.
Exakt berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 MHz (z.B. HM, FS20, FHT …) 1/4 Lambda = 8,63 Zentimeter 1/2 Lambda = 17,26 Zentimeter 1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)
433,92 MHz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter 1/2 Lambda = 34,54 Zentimeter
Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:
8,6 Zentimeter als 1/4 Lambda für 868,35 MHz 17,2 Zentimeter als 1/2 Lambda für 868,35 MHz und zugleich 1/4 Lambda für 433,92 MHz 34,5 Zentimeter als Lambda für 868,35 MHz und zugleich 1/2 Lambda für 433,92 MHz
Bekannte Probleme
RF-Tuning
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern (z. B. der FHT Raumregler) zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.
Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:
- Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
set CUL freq 868.350
- Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte (siehe Diskussion hier). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
set CUL sens 8
- Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
set CUL bWidth 464
Selbstbau-/Bastelprojekte
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
- Selbstbau CUL
- FHEMduino
- SIGNALduino
- MapleCUN mit STM32 Mikrocontroller
Links
- Hersteller / Bezugsquelle für CUL: busware.de
- Google groups CUL fans, mittlerweile durch das Board cul-fans im FHEM Forum ergänzt/ersetzt
- CUL commandref [2]