LBT Firmware für Taranis
- Themenstarter hugo1
- Beginndatum
- Status
Hallo,
vielleicht müsste man mal klarstellen, was die Anforderungen durch die EN 300328 an Funksysteme sind. Wir reden hier vom Standard. Das ist das Thema.
Diese Anforderungen sind früher in der R&TTE-Directive und mittlerweile in der Radio Equipment Directive verankert und gelten für ALLE! Funksysteme, die diesen Direktiven unterliegen.
Diese sind sowohl in der R&TTE-D als auch in der RED im Artikel 3 als "Essential Requirements" festgelegt. Die aktuelle Version dieser Anforderungen im Artikel 3 der RED kann hier nachgelesen werden:
http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:JOL_2014_153_R_0002&from=EN
Kurz gefasst sind das:
Sicherheit von Personen und Haustieren sowie der Schutz von Eigentum
Elektromagnetische Verträglichkeit
Effektive und Effiziente Nutzung des Radio-Spektrums und die Vermeidung schädlicher Störungen
und eine längere Liste spezifischer Anforderungen.
Die Performance einzelner Produkte ist NICHT! Gegenstand der Normierung. Das ist die Aufgabe produktspezifischer Normen und der Hersteller, dieses im Rahmen der RED zu leisten.
Die spezifischen Anforderungen an die Spektrumzugriffsmethoden unterscheiden sich naturgemäss nach den Betriebsparametern der verschiedenen Systeme. Alle müssen aber die Essential Requirements erfüllen.
Natürlich sind die Sicherheitanforderungen des Betriebes and einen BT-Headset und eine R/C-Anlage unterschiedlich. Das ist aber nicht das Thema des ETSI-Standards. Es gibt nebenbei noch Fernsteuerungen ausserhalb des Modellbaus und Systeme der Systemüberwachung und Systemsteuerung. Und dort sind die Anforderungen noch deutlich härter als im Modellbereich und bewegen sich in einem Bereich, in dem es kabelgebunden schon unlustig wird (> 99.x% Verfügbarkeit).
Von daher brauche ich nicht verschiedene Systeme wahllos in einen Topf zu schmeissen. Sie sind schon alle im Topf des Artikel 3.
Ansonsten ist die Lektüre der Artikel 4 und 5 empfehlenswert, da sich hier einige Fallstricke für den R/C-Bereich auftun.
Besonders der Artikel 4, dessen Erwähnung des Inhaltes ja hier auch schon mal zu massiven Anfeindungen geführt hat.
Bei der Registrierungspflicht gemäss Artikel 5 ist der R/C-Bereich mit von der Partie. Das dürfte so sicher sein, wie das Amen in der Kirche.
vielleicht müsste man mal klarstellen, was die Anforderungen durch die EN 300328 an Funksysteme sind. Wir reden hier vom Standard. Das ist das Thema.
Diese Anforderungen sind früher in der R&TTE-Directive und mittlerweile in der Radio Equipment Directive verankert und gelten für ALLE! Funksysteme, die diesen Direktiven unterliegen.
Diese sind sowohl in der R&TTE-D als auch in der RED im Artikel 3 als "Essential Requirements" festgelegt. Die aktuelle Version dieser Anforderungen im Artikel 3 der RED kann hier nachgelesen werden:
http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:JOL_2014_153_R_0002&from=EN
Kurz gefasst sind das:
Sicherheit von Personen und Haustieren sowie der Schutz von Eigentum
Elektromagnetische Verträglichkeit
Effektive und Effiziente Nutzung des Radio-Spektrums und die Vermeidung schädlicher Störungen
und eine längere Liste spezifischer Anforderungen.
Die Performance einzelner Produkte ist NICHT! Gegenstand der Normierung. Das ist die Aufgabe produktspezifischer Normen und der Hersteller, dieses im Rahmen der RED zu leisten.
Die spezifischen Anforderungen an die Spektrumzugriffsmethoden unterscheiden sich naturgemäss nach den Betriebsparametern der verschiedenen Systeme. Alle müssen aber die Essential Requirements erfüllen.
Natürlich sind die Sicherheitanforderungen des Betriebes and einen BT-Headset und eine R/C-Anlage unterschiedlich. Das ist aber nicht das Thema des ETSI-Standards. Es gibt nebenbei noch Fernsteuerungen ausserhalb des Modellbaus und Systeme der Systemüberwachung und Systemsteuerung. Und dort sind die Anforderungen noch deutlich härter als im Modellbereich und bewegen sich in einem Bereich, in dem es kabelgebunden schon unlustig wird (> 99.x% Verfügbarkeit).
Von daher brauche ich nicht verschiedene Systeme wahllos in einen Topf zu schmeissen. Sie sind schon alle im Topf des Artikel 3.
Ansonsten ist die Lektüre der Artikel 4 und 5 empfehlenswert, da sich hier einige Fallstricke für den R/C-Bereich auftun.
Besonders der Artikel 4, dessen Erwähnung des Inhaltes ja hier auch schon mal zu massiven Anfeindungen geführt hat.
Bei der Registrierungspflicht gemäss Artikel 5 ist der R/C-Bereich mit von der Partie. Das dürfte so sicher sein, wie das Amen in der Kirche.
Hi,
mal ganz klar: Ich habe selbst FrSky und finde es reichlich doof mit den verschiedenen Firmwares hantieren zu müssen. Auch mein Wunsch ist dass bei der RC-Übertragung "alles so wie immer" ist!
Ich befürchte aber das haben weder wir noch Frank unter Kontrolle und deshalb müssen wir es leider so annehmen - klar dürfen wir jammern (finde ich!), nur ändert es halt nix mehr.
Ich befürchte aber dass du in der Sache "Niedrigere Frequenznutzungsintensität = unsicherere Übertragung" nicht korrekt argumentierst:
Die Argumentation hier verstehe ich ungefähr so: "Pakete kommen manchmal an, manchmal nicht. Wenn ich also viele Pakete senden darf dann habe ich eine höhere Wahrscheinlichkeit dass ein heiles Paket ankommt". Dem möchte ich mein (zugegebenermaßen) Laienwissen entgegen halten:
Das gilt vielleicht so lange wie du in deinem Frequenzband alleine bist. De facto bist du das aber bei 2.4Ghz praktisch nie: Selbst wenn du allein in der Landschaft stehst dann sendet z.B. immer noch das WLan deines Handys, das Bluetooth und eventuell noch das deines Autos.
Sobald du andere Nutzer drauf hast gibt es einen Grund warum Pakete nicht heile beim Empfänger ankommen: Jemand anderes sendet zur gleichen Zeit (Kollision).
Meines Verständnis nach prüft LBT vor dem Senden ob ein Kanal frei ist. Ist er belegt dann meidet es diesen Kanal beim Senden. Damit können also viele Teilnehmer ganz viel senden ohne dass Pakete Kollisionen zum Opfer fallen. Das ist ein Win:Win für alle Teilnehmer auf dem Band und damit auch für deine RC-Anlage!
Zum Thema 10% MU (durchschnittliche Nutzung): Diese Option gilt nicht nur für deine RC-Anlage sondern auch für die anderen Teilnehmer die dir vielleicht deine Datenpakete per Kollision verstümmeln. Daraus ergibt sich für deine Anlage ein größerer Schutz, da du weniger schnell zugemüllt wirst. Und damit kann durchaus die Wahrscheinlichkeit, dass ein intaktes Paket beim Empfänger ankommt steigen und das obwohl du selbst weniger senden darfst! Immer daran denken: Sendet jeder wann er möchte und ohne Rücksicht auf andere (ALOHA-Prinzip), so ist ein Band bereits bei 18% seiner theoretisch Kapazität voll und nicht weiter nutzbar. Also muss man in dem Fall mit der Kapazität stark haushalten.
Übrigens muss bei 10% MU auch die Latenz nicht schlecht sein: Die RC-Anlagen übertragen ja nur wenige Daten und damit sehr kurze Pakete -> sehr kurze Sendedauer. Ich vermute dass man trotz 10% MU noch sehr viele Pakete pro Sekunde los wird.
mal ganz klar: Ich habe selbst FrSky und finde es reichlich doof mit den verschiedenen Firmwares hantieren zu müssen. Auch mein Wunsch ist dass bei der RC-Übertragung "alles so wie immer" ist!
Ich befürchte aber das haben weder wir noch Frank unter Kontrolle und deshalb müssen wir es leider so annehmen - klar dürfen wir jammern (finde ich!), nur ändert es halt nix mehr.
Ich befürchte aber dass du in der Sache "Niedrigere Frequenznutzungsintensität = unsicherere Übertragung" nicht korrekt argumentierst:
Die Argumentation hier verstehe ich ungefähr so: "Pakete kommen manchmal an, manchmal nicht. Wenn ich also viele Pakete senden darf dann habe ich eine höhere Wahrscheinlichkeit dass ein heiles Paket ankommt". Dem möchte ich mein (zugegebenermaßen) Laienwissen entgegen halten:
Das gilt vielleicht so lange wie du in deinem Frequenzband alleine bist. De facto bist du das aber bei 2.4Ghz praktisch nie: Selbst wenn du allein in der Landschaft stehst dann sendet z.B. immer noch das WLan deines Handys, das Bluetooth und eventuell noch das deines Autos.
Sobald du andere Nutzer drauf hast gibt es einen Grund warum Pakete nicht heile beim Empfänger ankommen: Jemand anderes sendet zur gleichen Zeit (Kollision).
Meines Verständnis nach prüft LBT vor dem Senden ob ein Kanal frei ist. Ist er belegt dann meidet es diesen Kanal beim Senden. Damit können also viele Teilnehmer ganz viel senden ohne dass Pakete Kollisionen zum Opfer fallen. Das ist ein Win:Win für alle Teilnehmer auf dem Band und damit auch für deine RC-Anlage!
Zum Thema 10% MU (durchschnittliche Nutzung): Diese Option gilt nicht nur für deine RC-Anlage sondern auch für die anderen Teilnehmer die dir vielleicht deine Datenpakete per Kollision verstümmeln. Daraus ergibt sich für deine Anlage ein größerer Schutz, da du weniger schnell zugemüllt wirst. Und damit kann durchaus die Wahrscheinlichkeit, dass ein intaktes Paket beim Empfänger ankommt steigen und das obwohl du selbst weniger senden darfst! Immer daran denken: Sendet jeder wann er möchte und ohne Rücksicht auf andere (ALOHA-Prinzip), so ist ein Band bereits bei 18% seiner theoretisch Kapazität voll und nicht weiter nutzbar. Also muss man in dem Fall mit der Kapazität stark haushalten.
Übrigens muss bei 10% MU auch die Latenz nicht schlecht sein: Die RC-Anlagen übertragen ja nur wenige Daten und damit sehr kurze Pakete -> sehr kurze Sendedauer. Ich vermute dass man trotz 10% MU noch sehr viele Pakete pro Sekunde los wird.
LBT bietet weitergehende Möglichkeiten:
Die Einfachversion von LBT ist die, das ein System auf eine Frequenz springt, die Frequenz auf Belegung prüft und falls belegt das Senden einfach bleiben lässt. Das ist sozusagen LBT-Light.
Dann gibt des die Möglichkeit, das im Falle der Belegung in einem sog. "nichtadaptiven" Mode gesendet wird. Hier gibt es zahlreiche Möglichkeiten, die zu erläutern aber abendfüllend wäre.
Und dann gibt es die Möglichkeit, im Rahmen der auf der Frequenz zur Verfügung stehenden Zeit zu warten, bis die Frequenz frei wird und dann zu senden. Das Warten geht natürlich nicht beliebig lange, da ein FHSS nach Ablauf seiner geplanten Verweilzeit auf der Frequenz springen muss, um nicht die Synchronisation mit der Gegenstelle zu verlieren.
Typische Zeiten auf einer Frequenz sind 0.5 - 2 ms Sendezeit und so ca. 5 - 20 ms Verweilzeit. Die meisste Zeit dreht das System also Däumchen.
Wenn innerhalb dieser Verweilzeit die Frequenz rechtzeitig frei wird, kann der aktuelle Slot durchaus noch genutzt werden, auch wenn er anfangs belegt war.
Der Standard sieht dieses Vorgehen übrigens explizit vor und regelt wie dabei zu verfahren ist. Das Prozedere muss dabei bei allen einheitlich sein, damit es gerecht funktioniert.
Damit kann die ansonsten verschwendete Zeit innerhalb der Verweilzeit auf einer Frequenz noch sinnvoll genutzt werden. bei stark belegtem Band kann damit der Datendurchsatz deutlich besser erhalten und die Kollisionswahrscheinlichkeit reduziert werden.
Wenn nix los, ist wird LBT eh nicht aktiv.
Das hat bisher nur kaum einer gemerkt, weil alle nach dem Part mit "LBT-Light" aufgehört haben, zu lesen.
Die Einfachversion von LBT ist die, das ein System auf eine Frequenz springt, die Frequenz auf Belegung prüft und falls belegt das Senden einfach bleiben lässt. Das ist sozusagen LBT-Light.
Dann gibt des die Möglichkeit, das im Falle der Belegung in einem sog. "nichtadaptiven" Mode gesendet wird. Hier gibt es zahlreiche Möglichkeiten, die zu erläutern aber abendfüllend wäre.
Und dann gibt es die Möglichkeit, im Rahmen der auf der Frequenz zur Verfügung stehenden Zeit zu warten, bis die Frequenz frei wird und dann zu senden. Das Warten geht natürlich nicht beliebig lange, da ein FHSS nach Ablauf seiner geplanten Verweilzeit auf der Frequenz springen muss, um nicht die Synchronisation mit der Gegenstelle zu verlieren.
Typische Zeiten auf einer Frequenz sind 0.5 - 2 ms Sendezeit und so ca. 5 - 20 ms Verweilzeit. Die meisste Zeit dreht das System also Däumchen.
Wenn innerhalb dieser Verweilzeit die Frequenz rechtzeitig frei wird, kann der aktuelle Slot durchaus noch genutzt werden, auch wenn er anfangs belegt war.
Der Standard sieht dieses Vorgehen übrigens explizit vor und regelt wie dabei zu verfahren ist. Das Prozedere muss dabei bei allen einheitlich sein, damit es gerecht funktioniert.
Damit kann die ansonsten verschwendete Zeit innerhalb der Verweilzeit auf einer Frequenz noch sinnvoll genutzt werden. bei stark belegtem Band kann damit der Datendurchsatz deutlich besser erhalten und die Kollisionswahrscheinlichkeit reduziert werden.
Wenn nix los, ist wird LBT eh nicht aktiv.
Das hat bisher nur kaum einer gemerkt, weil alle nach dem Part mit "LBT-Light" aufgehört haben, zu lesen.
Noch eine Anmerkung zum MU-Faktor.
Auch bei 10% MU ist ein Duty-cycle von 100% möglich. Allerdings ist bei 100% die Leistung auf 10 mW beschränkt. Unter 10 mW entfallen alle Timing-Limits.
Der MU-Faktor ist, vereinfacht gesagt, das Produkt aus Leistung und Duty-Cycle. Mit diesen beiden Parametern kann man dann jonglieren.
Wenn ich also z.B. ein System mit 15% Duty-Cycle habe, gehe ich halt etwas in der Leistung runter und alle sind glücklich.
Auch bei 10% MU ist ein Duty-cycle von 100% möglich. Allerdings ist bei 100% die Leistung auf 10 mW beschränkt. Unter 10 mW entfallen alle Timing-Limits.
Der MU-Faktor ist, vereinfacht gesagt, das Produkt aus Leistung und Duty-Cycle. Mit diesen beiden Parametern kann man dann jonglieren.
Wenn ich also z.B. ein System mit 15% Duty-Cycle habe, gehe ich halt etwas in der Leistung runter und alle sind glücklich.
Zuletzt bearbeitet:
Hallo Jungs,
Jetzt wurde soviel diskutiert... Hat es denn jetzt schon jemand getestet, ist doch eh Mistwetter, also ideal zum experimentieren.
Wenn ich es richtig verstanden habe, ist die Sendeleistung etwas niedrieger, siehe Frsky-rc.com Forumsbeitrag mit den Oszi-Bildern.
Grüsse, Gruni
PS: ich würde es selber gerne Testen, aber die Taranis liegt etwa 600km weg im Keller, ich darf arbeiten...
Jetzt wurde soviel diskutiert... Hat es denn jetzt schon jemand getestet, ist doch eh Mistwetter, also ideal zum experimentieren.
Wenn ich es richtig verstanden habe, ist die Sendeleistung etwas niedrieger, siehe Frsky-rc.com Forumsbeitrag mit den Oszi-Bildern.
Grüsse, Gruni
PS: ich würde es selber gerne Testen, aber die Taranis liegt etwa 600km weg im Keller, ich darf arbeiten...
Nachdem auf die Eingangsfrage bisher keine Antwort gekommen ist, habe ich die Software testweise selbst installiert. Funktioniert bei mir einwandfrei. Fliege um diese Jahreszeit allerdings nur einen Schaumflieger. Subjektiv hat sich entweder der MU-Faktor oder die Sendeleistung erhöht, da die HF-Einstrahlung in den Lautsprecher viel lauter geworden ist. Ist natürlich nur eine Vermutung, da ich über keine Messmittel verfüge, um dies zu bestätigen.
Nur gebe ich zu bedenken, dass, wenn man den Diagrammen auf der Frsky-Seite Glauben schenken kann, die EU-Firmware in der Leistung deutlich gegenüber der Nicht-EU-Version eingeschränkt war. Nehme an, dass da keine 100 mW abgestrahlt wurden. Wäre möglich, dass sich die Leistung in der LBT-Version wieder an die der Nicht-EU-Version angepasst hat. Darüber kann man allerdings nur mutmaßen.
Toller Hinweis, das die auf der Frsky Seite sein soll haste nochmal erwähnt
Sollte aber auch dazu sagen, ich bin in dem Frsky Forum nicht regestriert, kann die deswegen evtl nicht sehen, und finde die deswegen nicht
Ich komme an der blöden Spam-Bot Frage nicht vorbei
What is our company website domain name?:
Was zum Teufel wollen die wisen, frsky-rc ist es nciht, frsky-rc.com ist es nicht, was für einen Domain namen meinen die
Sollte aber auch dazu sagen, ich bin in dem Frsky Forum nicht regestriert, kann die deswegen evtl nicht sehen, und finde die deswegen nicht
Ich komme an der blöden Spam-Bot Frage nicht vorbei
What is our company website domain name?:
Was zum Teufel wollen die wisen, frsky-rc ist es nciht, frsky-rc.com ist es nicht, was für einen Domain namen meinen die
Adresse ist www.frsky-rc.com. Das www gehört dazu.
Die LBT Firmware liegt nun offiziell im Downloadbereich. Ich gehe davon aus das dies nun keine Beta mehr ist.
Nachdem ich gestern erstmalig einen (wie zu erwarten entäuschenden) Reichweitentest mit meiner neuen X9E mit der orginalen 1.8.1 gemacht habe kommt heute mal die LBT Firmware drauf.
Mal sehen ob die an die Reichweite der 1.7.1 ran kommt...
Nachdem ich gestern erstmalig einen (wie zu erwarten entäuschenden) Reichweitentest mit meiner neuen X9E mit der orginalen 1.8.1 gemacht habe kommt heute mal die LBT Firmware drauf.
Mal sehen ob die an die Reichweite der 1.7.1 ran kommt...
Hallo,
hier mal der Direktlink:
EU LBT Firmware
Im Word-Dokument steht folgendes:
--------------------
Note: LBT firmware is not compatible with previous EU firmware. FrSky highly suggest you to upgrade your radios, modules, receivers with old EU firmware to their corresponding LBT firmware.
----------
Google Übersetzer sagt:
Hinweis: LBT-Firmware ist nicht mit früheren EU-Firmware kompatibel. FrSky sehr empfehlen Ihnen, Ihre Funkgeräte, Module, Empfänger mit alten EU-Firmware auf ihren entsprechenden LBT Firmware zu aktualisieren.
--------------------
Ist damit gemeint, dass man die bisherige EU v1.8.1 Firmware durch die EU LBT ersetzen sollte?
Wann ja, warum? Sicherer? Leistungsfähiger? ...?
Wie sieht es mit der Konformitätserklärung für die EU LBT aus?
Gruß
meute
hier mal der Direktlink:
EU LBT Firmware
Im Word-Dokument steht folgendes:
--------------------
Note: LBT firmware is not compatible with previous EU firmware. FrSky highly suggest you to upgrade your radios, modules, receivers with old EU firmware to their corresponding LBT firmware.
----------
Google Übersetzer sagt:
Hinweis: LBT-Firmware ist nicht mit früheren EU-Firmware kompatibel. FrSky sehr empfehlen Ihnen, Ihre Funkgeräte, Module, Empfänger mit alten EU-Firmware auf ihren entsprechenden LBT Firmware zu aktualisieren.
--------------------
Ist damit gemeint, dass man die bisherige EU v1.8.1 Firmware durch die EU LBT ersetzen sollte?
Wann ja, warum? Sicherer? Leistungsfähiger? ...?
Wie sieht es mit der Konformitätserklärung für die EU LBT aus?
Gruß
meute
- Status
