CUl FW 1% / listen before talk

[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...

[rudolfkoenig]

Wü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.

in 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
   

[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.

[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
   

[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?

[rudolfkoenig]

Tipp:
25% = 1/4
4*900 = 3600

[Stephan]

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

Gruss
Stephan
   

[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
   

[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.

[atietzel]

Ok, danke. Ich habe es gerade verstanden! Ich war immer davon ausgegangen, dass "wir" im Bereich 868.6MHz bis 868.7MHz senden. Das ist aber gar nicht der Fall sondern 868,35 MHz und dann stimmt es natürlich nach ETSI-300-220-1 gilt für die Frequenz, auf der CUL und Konsorten senden und empfangen 1% or LBT + ATA. Und das steht auch im fhemwiki richtig.

Und damit ist mir nun auch klar, dass wir nicht im Alarm-Kanal des 868MHz-Bandes senden (würde eigentlich auch gar nicht passen)...
So wird man schlauer!
Und die Links für weitere Interessierte wären:
http://www.fhemwiki.de/wiki/1%25_Regel
http://www.radiometrix.com/files/additional/pdf/regulatory/en_30022001v020201c.pdf

[mfeske]

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

Hallo Stephan,

kannst Du mir vielleicht auf die Sprünge helfen ? Ich habe die Firmware runtergeladen und die Datei modifiziert. Wie hast Du den kompiliert? Ich hab schon Ubuntu am laufen. Wie hast Du den am PI geflasht, das würde mir den Umweg über den Laptop immer ersparen.

Gruß
Micha

[HaraldP]

Da hier schon öfter nachgefragt: hier die geänderten und übersetzten Dateien mit max. Credits von 3600.
Harald

[Joern78]

Wo kann ich eigentlich überprüfen ob 900 oder 3600 in der Firmware aktiv ist ? Ich habe die rf_send.h angepasst, kompiliert und neu geflasht.

[rudolfkoenig]

fhem> get CUL credit10ms
CUL credit10ms => 861

[Joern78]

Vielen Dank. Hat geklappt mit der Änderung

[stobor]

Da hier schon öfter nachgefragt: hier die geänderten und übersetzten Dateien mit max. Credits von 3600.
Harald

Wurde in dieser Firmware-Version nur das Zeitfenster, auf das sich die 1% beziehen von 15 auf 60min erweitert, oder kann man generell länger senden?

So wie ich das jetzt aus diesem Beitrag verstehe, läuft das in der "normalen" Firmware so:
Innerhalb von 15min darf ich 1% der Zeit senden (= max. 9sec. innerhalb von 15min), richtig?

In der von Dir (HaraldP) angebotenen Version hast Du in der rf_send.h define MAX_CREDIT 3600 eingetragen, was dann innerhalb von 1h 1% Sendezeit (= max. 36sec. innerhalb von 1h) ermöglicht. Man könnte also die 36sec schon in den ersten 15min verbrauchen, kann dann aber die restlichen 45min nichts mehr senden, richtig?

Kann man auch generell die 1% erweitern?

[HaraldP]

Ja, wenn x Credits vorhanden sind, kann man x Sek. senden. Dann sind sie aufgebraucht. Pro Sekunde Nichtsenden werden die vorhandenen Credits um eins erhöht, bis 900 bzw. 3600 erreicht sind. Der Wert von 900 wird also nach einer 1/4 Std. erreicht, 3600 entsprechend nach 1Std.
Im Prinzip kann man pro Std. 4 mal 9s oder einmal 36s senden. Es kommt also auf das Gleiche hinaus. Mit MAX_CREDIT 3600 hat man mehr Reserve nach einer Sendepause - und nach meiner Meinung kommt man der Intention der Verordnung der Bundestnetzagentur näher. Dort ist explizit die 1% Regel auf eine Stunde bezogen.
Warum man den Angstfaktor 1/4 noch nicht aufgegeben hat, ist mir schleierhaft. Mit max. 3600 Credits komme ich mit meinem MAX! System gut über die Runden, mit 900 nicht.
Harald