FrSky, Taranis, LBT, ETSI-Norm 1.8.1

Hallo,

hat jemand einen Gesamtüberblick über den Stand und die Realisierung von LBT bzw. der ETSI-Norm 1.8.1 bezogen auf FrSky und Taranis?

Wird es eine Hardwareadaption geben, oder erfolgt die Umstellung via Software?
Wird es neue Empfänger geben, oder kann man diese umprogrammieren?

Danke
Stefan

PS: Ich kenne den allgemeinen Thread dazu. Ich halte es aber für sinnvoll, die Systeme einzeln zu diskutieren.
 
Danke,

weiß jemand, wie das Update durchgeführt wird? Via der Open-TX Software oder betrifft das einen anderen Layer?
Ich hatte immer gedacht, dass Open-TX quasi das Betriebssystem ist aber die Funkhardware eine eigene Firmware hat.

Werden die Empfänger auch geupdatet?
Geht das überhaupt bei allen Typen?

Stefan
 

Walter24

User gesperrt
Hy,

ja das opentX ist das Betriebssystem des Senders und hat erst mal gar nichts mit dem internen 2,4GHz HF Modul zu tun.

Das interne Hf Modul (entspricht exakt einem XJT-Modul) hat seinen eingen Prozessor der den 2,4GHZ HF-Cip eigenständig steuert.

Man kann diesen Prozessor extern komplett updaten, das ging und geht schon immer,
man kann ihm aber auch nur per opentX ein paar Steuerbefehle senden.
Das macht man ja jetzt auch schon wenn man unter openTX auswählt Europa / Amerika.
Damit wird eine andere Hoppingsequenz antiviert, die bestimmte (Amerika)-Frequenzbereiche nicht anspringt.

Walter
 
Aha, und welche "Tool-Chain" braucht man dafür? Geht das mit Companion?

Wer wird diese ganze Thematik für die Community etwas mundgerechter aufbereiten?
Gibt es da schon was?

Stefan
 
Wenn ich das richtig verstanden habe, dann wird einfach der Sendezeit auf <= 10% verringert um damit die Norm zu erfüllen?! Sprich LBT wird einfach ignoriert und dafür einfach viel weniger gesendet?

Klärt mich doch bitte auf was dieser mysteriöse MU Faktor ist.

Lg
 

Walter24

User gesperrt
Hy,

gemeint ist der MU-Faktor <10%, dann braucht man kein LBT machen

DC = Duty Cylce
P = Power
MU= (P/100mW) * DC

-------------------------------------

Frühe FHSS also Hopping Systeme hüpften nur auf 1-2 bzw 15-16 Kanälen im 2,4GHz Band mit Bandbreiten von 1MHz

Bei 1Mhz Bandbreite standen ca. 80Kanäle zur Verfügung
und diese Frequenzen waren bei diesen ersten Hoppingvorgang auch noch relativ lange belegt.
Das Band war damit sehr schnell "zu" und die Hoppingsequenzen selber waren starr
Das sieht man schön am Spektrumanalzer.

Aktuelle FHSS Systeme (Hott, AFHSS, best. Futaba-Typen, Hitec, usw.) verwenden sehr schmalbandige Filter
mit Bandbreiten 500kHz, 375kHz, 250Khz
d.h. dort stehen nun zwischen 160 und 320 Hoppingfrequenzen zur Verfügung
Davon werden Sprung-Sequenzen mit 30-60 Frequenzen ausgewählt, angesprungen und diese werden auch noch variiert.

Durch schnelle HF-Chips und Prozessoren, und die paar Byte die ein RC-Sender pro Burst überträgt kann die Frequenz sehr schnell wieder freigegeben werden ohne sofort eine neue Frequenz belegen zu müssen.
d.h. der Sender kann damit warten, was alle aktuelle FHSS-Systeme auch jetzt schon tun.

Der eine wartet etwas länger und kommt damit auf eine MU von 7%
der andere wartet etwas weniger und kommt damit auf eine MU von 12% bis 15%
(das hängt auch davon ab wie schnell sie mit neuen Daten versorgt werden)

Wir reden hier von ca 10-15us Unterschied

Jeder moderne RC RX/TX-Chip kann heute LBT oder mind 3-5 anderes Verfahren
Jeder aktuelle Sender der ein RSSI-Signal darstellt ist schon in "Listen"-Modus, das ist also nichts neues.


Konkret:
Der eine FHSS-Hopper muss nichts mehr tun, nur neu zertifizieren
Der andere FHSS-Hopper muss etwas tun und neu zertifizieren

----------------------------------------------------------
By the Way:
Auch der LBT ist nicht besser drann, denn auch er muss warten und "listen" für
min 20us bevor er sagt, ja da ist frei ich muss sofort senden, für max 60us


Im sehr ungünstigen Fall:
"listen, nicht frei", also hoppen,
"listen auch nicht frei", also nochmal hoppen
"listen wieder nicht frei", .......
irgendwann muss er aber senden.

LBT ist damit für Prozesse in der Industrie nicht echtzeitfähig.
Darum bastelt man schon an der nächsten "Reform der Reform" der 1.8.1
Die gibt es dann in 5-7 Jahren und bis die durch ist, ist sie schon wieder technisch überholt.

Industrie 4.0 läst grüßen, siehe div Fachbeiträge der Industrie, z.B. Phönix Testlab


-------------------------------------------------------------
Schnelle RC-Systeme übertragen in 9 -16ms die Daten für 16-32 Kanäle

Normales PPM für 8 Kanäle braucht 22,5ms

Walter
 

Walter24

User gesperrt
Hy,

ne, stimmt schon.

20us listen dann 60us senden pro Hoppingfrequenz

Man kann auch, wenn gerade auf Fx gesendet wird, schon in die nächste Hoppingfrequenz Fy schon mal reinhören
wenn der Sendechip mit Hardware-Umfeld das können.

Walter
 
Hallo,

danke für die interessanten Infos.

so, wieder zurück zur Taranis bzw. der praktischen Umsetzung. Hat das Update schon jemand gemacht? Wo gibt es Infos dazu?

Stefan
 

ingo_s

User
@Walter
Laut ETSI EN 300 328 V1.8.2 Abschnitt 4.3.1.7.2.2 Requirements & Limits sind es 60ms.

Bei Spektrum mit DSSS dauert eine einzelne Teil-Übertragung der Kanäle schon ca. 1,5ms.

Gruß Ingo
 
Ich möchte Euch ungern bremsen, aber ich habe diesen Thread für praktische Belange zur neuen Norm bezogen auf Taranis bzw. FrSky gestartet. Allgemeine Dinge zum Verfahren werden meines Wissens nach in dem Parallelthread diskutiert.

Danke
Stefan
 

Walter24

User gesperrt
hy,

ja hast ja recht zurück zur Taranis
--------------------------------


Es sind 60us pro Hopping-Frequenz

Die 60ms sind ein Beispel in der 1.8.1 für eine 400ms Sequenz

Taraniss überträgt 16 kanäle in 9ms

Ein normales PPM-Signal hat 22,5ms für 8 Kanäle

----------------------------

Walter
 

Julez

User
Was mich interessieren würde wäre, wie die Kompatibilität von Empfängern wäre. Da werden die neuen ja auch wahrscheinlich upgedated sein müssen, verträgt sich dass dann noch mit der alten Modulsoftware?
 

DD8ED

Vereinsmitglied
Öhm ja
Hy,

ne, stimmt schon.

20us listen dann 60us senden pro Hoppingfrequenz

Man kann auch, wenn gerade auf Fx gesendet wird, schon in die nächste Hoppingfrequenz Fy schon mal reinhören
wenn der Sendechip mit Hardware-Umfeld das können.

Walter
Also die maximale Sendezeit am Stück ist schon 60 ms. Mit 60 us kommst du nicht weit. Das sind nur ein paar Bits.
Und für den Empfänger der hören kann während ein Sender auf der gleichen oder unmittelbar benachbarten Antenne sendet und dann noch im gleichen Band wirst du einen SEHR grossen Flieger brauchen. Das ist dann ein Empfänger im Format Schrankwand und nebenbei noch stocktaub. Mit der im R/C-Bereich üblichen Technik ist das nicht drin.
 
Puh, wie groß ist der Duty Cycle? Also Vergleichen würde ich das nicht. LBT wird garantiert öfter senden als bei einem so kleinem Duty Cycle (P/100mW = 1 nehm ich an). MU ist also gleich DC...
 
Ansicht hell / dunkel umschalten
Oben Unten