CUl FW 1% / listen before talk

Begonnen von Stephan, 26 Dezember 2013, 05:31:07

Vorheriges Thema - Nächstes Thema

Stephan

Würde mir jemand bitte erklären, warum man sich beim CUL mit der 1% Regel rumschlägt, anstelle  "listen before talk" zu nutzen?
Hat das nur aufwandsgründe in bezug auf die programmierung oder steckt da was technisches dahinter?

Weil, im grunde finde ich die 1% Regel schon sehr lästig, wenn man an 10 Thermostate Profile schickt und es mehrere Stunden dauert, bis das ganze durch ist. Stundenlang not enough credit....

Ist mal wieder typisch, da wird so ne regel vorgeschrieben ohne rücksicht darauf, ob ich in berlin wohne oder ich hier 1 Kilomter zum nächsten Nachbarn habe.

Und seien wir mal ehrlich, zwei CUL mit je eigener 1% Regel nehmen das Band auch nicht weniger in Anspruch als einer mit einer 2% Regel. Ich persönlich halte "listen before talk" für die eleganteste lösung, nix los im Band, los gehts...
Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig

ZitatWürde mir jemand bitte erklären, warum man sich beim CUL mit der 1% Regel rumschlägt, anstelle  "listen before talk" zu nutzen?

Weil beim Implementieren mir diese Moeglichkeit nicht bekannt war. LBT ist nicht allgemein besser, da es mit anderen Problemen (Sende-Erkennung, Delay) zu kaempfen hat. In culfw wird er fuer die RFR Uebertragung verwendet.

Zitatin berlin wohne oder ich hier 1 Kilomter zum nächsten Nachbarn habe.
Dieses Problem wird mit Begrenzung der Sendestaerke geloest. Der 1% Regel ermoeglicht, dass alle Geraete in einer Wohnung funktionieren, da dauer-Sender (wie Audio-Uebertagung) in diesem Band nicht erlaubt sind.

Stephan

Das war nicht als Vorwurf gedacht. Mich interessiert das bloß weil es so unendlich lästig (annoying) ist. Das nervt im Betrieb tierisch. Irgendwie haben sich alle Werte aller meiner (Max) Thermostaten verabschiedet und ich bin jetzt seit zwei tragen dran, die Werte zu restaurieren.
Not Enough crédit ohne Ende.
Begrenzung der  Sendeleistung wäre aber nur dann wirklich effektiv, wenn es sich um die Strahlungsleistung handeln würde. Dadurch, das sich da jeder die ihm passende Antenne auf den Sender nagelte wird die  Reichweiten Begrenzung effektiv schon sehr ausgehebelt.
Wenn ich mir da eine Hornparabol mit 40 dB Gewinn  draufsetze dann habe ich auch 5 Kilometer Reichweite. Das kann ja in einer dicht besiedelten Gegend sich nicht Zielführung sein.
Bin drauf und dran, einen zweiten cul einzusetzen, da ist am Ende dann auch fraglich, was das im Endeffekt für die Bandnutzung bringt im Gegensatz zu einem cul, der doppelt so viel sendet.
Abgesehen von der Frage, ob das auch überhaupt zulässig wäre, das hinge wohl von der Frage ab, wie man Sende Anlage definiert.

Gruss
Stephan
   

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig

Und ich wollte mich damit auch nicht entschuldigen sondern erklaeren. Ich will auch nicht bestreiten, dass in manchen Situationen LBT fuer FS20/FHT praktisch ist, bin nur sicher, dass man dann andere Probleme bekommt.

Wenn ich es richtig verstanden habe: groessere/speziellere Antennen  (ohne Verstaerker) helfen nicht _generell_, sondern erlauben die Signale aus einer bestimmten Richtung besser zu empfangen, auf Kosten der anderen Richtungen. Klar kann man Nachbarn abhoeren, aber es geht hier eher um das unabsichtliche Stoeren.


Stephan

Ja, habe ich auch so verstanden.

Zu Antennen kann ich vielleicht als Nachrichtentechniker mit Fachgebiet Übertragungs- und Funktechnik was sagen.

Gute Antennen helfen schon generell, weil schlechte Antennen schlecht sind.::-)

Es steht einem am Ausgang eines Senders eine bestimmte Energie zur Verfügung. Diese will man aus verschiedenen Gründen auch nicht einfach so nach oben schrauben (im Gegensatz zu den früher von Unkundigen gerne betriebenen "Nachbrennern" /"Verstärker-Mikes" bei CB-Funk Geräten, etc). Zum einen kostet das Geld, zum anderen hangelt man sich damit eine Menge anderer Probleme ein. Zum Beispiel reduziere ich die Wiederverwendbarkeit meiner Frequenz, meines Bandes. Des weiteren hilft mir eine höhere Sendeleistung überhaupt nicht beim (eigenen) Empfang.

Aus dem grunde setzt man Antennen ein, die keinen idealen Omni-(Kugel)Strahler darstellen. Also Antennen, die bevorzugt in eine bestimmte Richtung abstrahlen. Dadurch wird die insgesamt verfügbare Sendeleistung auf einen räumlich kleineren Bereich konzentriert und die Strahlungsleistung nimmt zu. Dies kann trotz grundsätzlich nicht unbedingt sehr hoher Sendeleistung sogar dazu führen, dass zum Beispiel Vögel tot vor einem Radargerät runterfallen, weil dort mit so grossen Antennengewinnen gearbeitet wird, dass sehr hohe Strahlungsleistungen zustande kommen.

Jetzt kommen zwei schöne Effekte zum tragen. Zum einen wirkt der Antennengewinn nicht nur beim Senden, sondern auch beim Empfangen, das ist schon mal toll und wenn man sowohl bei Sender als auch Empfänger zwei schöne abgestimmte Antennen hat, dann  wundert man sich schon, was mit wie wenig Leistung geht.
Der zweite Effekt ist die Bedämpfung der Nebenkeulen, also der Bereiche, aus denen man nicht empfangen/senden möchte. Beides führt zu einer Verstärkung des Nutzsignals und zu einer Bedämpfung aller übrigen Signale, somit zu einem stark erhöhten Signal-Rausch Verhältniss und das will man ja gerade haben. Also grundsätzlich: Tolle Sache.

In Bezug auf das 868 Mhz Band muss man sich dann aber schon  fragen, ob die Verwendung von Antennen mit Gewinn (und das haben quasi alle, wenn sie kein Omni-Strahler sind), nicht schon grenzwertig ist. Es ist einfach so, dass man damit seine eigenen Signale eben auch weiter zum Nachbarn trägt. Ob das regulatorisch gewollt ist? Wo ist die Grenze? Bei 3db oder bei 40db? Bei WLAN ist die maximale Strahlungsleistung definiert.

Dann zum Beispiel die Verwendung eines CUL o.ä. als Repeater. Da sendet ja der originäre Sender munter mit 1%, der Repeater also auch und der Repeater vom Repeater ggf auch noch. Den oder die Repeater als eigenständige Sendeanlage zu bezeichnen könnte argumentativ weit hergeholt sein, da er eigenständig keinerlei Funktion ausübt. Da wird dann also munter ein mehrfaches des "erlaubten" verbraten.

Ich will damit sagen, ich finde die Implementierung wie sie ist schon sehr sehr stringent im einen Bereich, im anderen Bereich dagegen in der Tendenz lässig.
Nicht dass ich was dagegen hätte, Vorschriften einzuhalten, aber als ehemaliger Bediensteter eines Organs der Exekutive in diesem Bereich habe ich meinen damaligen Ermessenspielraum dort, wo er gegeben war, schon praxisorientiert eingesetzt.

Die Umsetzung der Vorschrift in ihrer Gesamtheit wirkt auf mich als Anwender so, dass es Bereiche gibt, in denen diese Umsetzung an die Grenze von Unbenutzbarkeit führt und das ist ja gerade vom Regulierer auch nicht gewollt. Das ganze soll benutzbar sein, und zwar für alle. Und eben nicht nur für andere, sondern auch für mich.

Und einfach zwei CULs einzusetzen und damit 2% zu verbraten, dürfte dann ebenfalls nicht zulässig sein, da sie Teil einer Sendeanlage sind. Denn im Extremfall schaffe ich mir 100 CUL an, reisse damit alle Timeslots an mich und jeder Nachbar schaut in die Röhre. Das das nicht zulässig sein soll im Rahmen der Regulierung leuchtet wohl ein.
Also müsste man wenn man konsequent ist, den Einsatz mehrerer CULS abfangen und die Timeslots reduzieren. Wird aber auch nicht gemacht (was ich aus Praxisgründen ja auch nachvollziehen kann). Aber wenn man es da schon nicht so richtig konsequent macht (mehrere eigenständige CULS / Einsatz von Repeatern), vielleicht gibt es ja eine Möglichkeit, durch eine sagen wir an die Praxis angepasste Interpretation eine höhere Nutzbarkeit zu erzielen?

Ich habe ja neben dem CUL auch einen CUBE. Wenn ich am CUL 10 Thermostate komplett einrichte, dauert das Ewigkeiten! Eine halben oder ganzen Tag, das spielt jetzt keine Rolle, aber wirklich lang. Und in der Zwischnezeit geht nichts.
Was mich beim CUBE dann wundert, ist, dass die gleiche Prozedur damit dann am Ende in Minuten abgefrüstückt ist. Nicht in einer oder zwei, aber in doich recht kurzer Zeit. Also entweder ignorieren die EQ3 Leute die Vorgaben vollständig (was sie aber nicht am Vertrieb hindert) oder die haben eine anwenderfreundlichere Implementierung gefunden. Schade, dass der CUBE in der Praxis unbenutzbar ist.

Bitte nicht als unfreundliches Gemecker falsch verstehen, aber so eine schöne Technik und dann an den Grenzen der Unbenutzbarkeit mit so hohem Frustpotenzial, das müsste doch irgendwie fluffiger sein, snappier, wie auch immer.

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig

Ich will ja nicht behaupten, dass culfw die ideale Loesung anbietet, nur dass _ich_ als Programmierer zufrieden war, und habe aufgehoert weiter zu optimieren. Es wird auch niemand daran gehindert, LBT fuer FS20/FHT in culfw und dann in FHEM zu implementieren, ich waere bereit Patches einzuspielen, wenn notwendig. Ich glaube aber nicht daran, dass Dir das wirklich helfen wird, s.u.

Unterschied FHT vs. MAX ist einfach zu erklaeren: FHT sendet auf 1kHz Datenrate, und benoetigt pro uebertragenen "Nutzbyte" 1 Funktelegramm mit 5 Byte + Ack. Einen Wochenprogramm hochzuladen bedeutet ca 30 "Nutzbytes". Wenn ein Telegramm verloren geht (z.Bsp. weil jemand zwischenfunkt), dann geht das Ganze von vorne los, ca 2 Minuten spaeter. Jeder der ein Wochenprogramm an einem FHT uebertraegt, ist mutig, jemand, der sowas an 10 FHTs machen will, muss sehr viel Glueck haben.

MAX und HomeMatic verwenden beide 10kHz Datenrate, und uebertragen mehrere Nutzbytes pro Telegramm, d.h. beide Protokolle sind grob 50-mal effizienter als FHT.

Stephan

Dann muss FHT ja unbenutzbar sein, denn ich habe nur MAX Komponenten und würde sagen, 9 Stück davon und 5 Fensterkontakte sind an der Grenze der Benutzbarkeit.

Leider bin ich zu blöd, um eine Firmware zu schreiben, könnte mich aber mit einem Antennendiagramm revanchieren, wenn jemand vielleicht eine Türklinke oder eine Konservendose an seinem cul betreiben möchte. Ich stell mal die Frage in den Raum ... hat jemand eine 2% Firmware? Falls man das hier nicht diskutieren darf gerne auch per PN ☺

Gruss
Stephan
   
Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig

ELV hat viel Erfahrung mit kaputten Protokollen, und vielleicht wollten sie bei MAX die Tradition wenigstens teilweise aufrechterhalten :)

Firmware schreiben musst du nicht, es reicht culfw kompilieren und flashen zu koennen.
Siehe culfw/clib/rf_send.h: #define MAX_CREDIT 900, bzw. http://culfw.de/commandref.html#flashing

Stephan

DANKE! DANKE! DANKE!

Endlich kann ich mal ein Wochenprofil absetzen ohne zu warten!  ;)

Hat mich zwar einige Mühen gekosted, aber man lernt ja auch dabei.

Virtualbox installiert
Ubuntu installiert
firmware geändert, komp9liert
rüber auf den PI
rawkommando b01 gesendet, da taster am cul defekt...
per hand am pi den cul geflashed

und läuft..:-)))))

Was mich hier an diesem Punkt aber noch mal interessiert:

Wieso steht da in diesem Wert 900 und "using 25% of irgendwas" und nicht 3600?
100% der 1% dürfte man doch schon nutzen, oder?

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig


Stephan

Ja, das hab ich schon verstanden. Warum nur 900 statt 3600?

Gruss
Stephan
   

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

rudolfkoenig

Willkuerlich. Ich fand die Begrenzung auf Viertelstunde besser, weil konservativer.
Lieber hoechstens 9 Sekunden ununterbrochen senden, als 36

Stephan

Ach so, ok. Verstehe ich.
Das ist also der Wert, bis zu dem Guthaben aufkumuliert wird. 900 bedeutet also maximal Guthaben von 1 Prozent aus einer Viertelstunde, 3600 maximal Guthaben von 1 Prozent aus einer Stunde.


Gruss
Stephan
   

Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

atietzel

Hallo Stephan,

ich habe dazu mal eine Frage: wo hast du gelesen, dass im Kanal 2 (868.6MHz - 868.7MHz) die 1% Duty Cycle Regel nicht gilt, wenn man CSMA implementiert?

Gruß
Alexander

Stephan

Findet man überall im Internet, dass die Voraussetzungen für den genehmigungsfreien Betrieb (u.a.) sind, dass man entweder die 1% Regel befolgt oder Listen before talk unterstützt.
Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05