FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
LBT, als Teil der ETSI 1.8.1, ist wie vieles in der deutschen/europäischen Gesetzgebung, es dient hauptsächlich zum Selbstzweck der Ämter und zur Marktregulierung gegenüber Nicht-EU Produkten.
Einerseits komplex und einschränkend, anderseits läßt es so viele Freiräume und Hintertürchen offen, daß man sich mit all den verschiedenen Umsetzungen mehr denn je behindert.
Würden sich alle Hersteller auf jeweils ein Verfahren bei FHH und DSS einigen, dann würde es etwas bringen, aber da ist man weit weg davon.
Einerseits komplex und einschränkend, anderseits läßt es so viele Freiräume und Hintertürchen offen, daß man sich mit all den verschiedenen Umsetzungen mehr denn je behindert.
Würden sich alle Hersteller auf jeweils ein Verfahren bei FHH und DSS einigen, dann würde es etwas bringen, aber da ist man weit weg davon.
Nein , sind mir keine bekannt. Hier aber mal ein Zitat unseres "Interessenvertreters" in den betreffenden EU-Gremien: Im 2.4 GHz-Band steht ein Bereich von 83,5 MHz zur Verfügung, für dessen Kapazität es eine physikalische Obergrenze gibt. Ein Weg zur besseren Nutzung des Bandes ist übrigens LBT, das im vergleich zu Non-LBT die NUTZBARE Kapazität des Bandes ungefähr verdreifacht.
Hier wird einmal ganz klar gesagt, worum es bei LBT eigentlich geht, nämlich um die deutlich verbesserte Nutzung der verfügbaren Bandbreite durch noch mehr gleichzeitige Nutzer.
Und was die Theorie betrifft, da hat ja jeder Empfänger ein Zeitfenster, in dem mindestens ein verwertbarer Datensatz ankommen muss, ansonsten löst FS aus. Ist man praktisch auf weiter Flur alleine und ohne andere Bandnutzer - fein. Nun lass aber mal ein paar Dinge unglücklicherweise zusammenkommen. Die gleichzeitige Bandnutzung durch andere Sender oder auch sonstige "Teilnehmer", wie zB WLan, wird das verzögerte Senden des nächsten Datenpakets ganz im Sinne von LBT zur Folge haben. Je intensiver/höher die Bandnutzung durch andere Teilnehmer ist, desto öfter wird LBT das Senden des nächsten Datenpakets bremsen. Vielleicht sind dabei auch sogar meherer Hoppingfreuqenzen hintereinander "blockiert". Demgegenüber wird FCC ungebremst seine Datenpakete rausschicken, auch wenn es dabei zu einem Clash kommen sollte, wobei letzteres nicht zwangsläufig bedeutet, dass das gesendete Datenpaket unbrauchbar beim Empfänger ankommt.
Befindet sich dein Flieger auf einem Durchflug mit lokal ungünstiger Empfangslage, die eh schon ggf. Datenverluste begünstigt, dann kann Senden (FCC) oder Nicht-Senden (LBT) des nächsten Datenpakets durchaus den Unterschied machen zwischen Kontrolle behalten oder ab in den FS. Die "ungünstige Empfangslage" kann durchaus auch ein relativ niedriger Landeanflug sein bei entsprechenden Wetter-/Bodenbedingungen.
Zugegeben für den "normalen" Alltag und die Platzrunde wird es in der Regel keinen Unterschied machen. In kritischer Empfangslage bin ich jedoch bei FCC besser aufgehoben. Mag gerne jeder anders sehen.
Hier wird einmal ganz klar gesagt, worum es bei LBT eigentlich geht, nämlich um die deutlich verbesserte Nutzung der verfügbaren Bandbreite durch noch mehr gleichzeitige Nutzer.
Und was die Theorie betrifft, da hat ja jeder Empfänger ein Zeitfenster, in dem mindestens ein verwertbarer Datensatz ankommen muss, ansonsten löst FS aus. Ist man praktisch auf weiter Flur alleine und ohne andere Bandnutzer - fein. Nun lass aber mal ein paar Dinge unglücklicherweise zusammenkommen. Die gleichzeitige Bandnutzung durch andere Sender oder auch sonstige "Teilnehmer", wie zB WLan, wird das verzögerte Senden des nächsten Datenpakets ganz im Sinne von LBT zur Folge haben. Je intensiver/höher die Bandnutzung durch andere Teilnehmer ist, desto öfter wird LBT das Senden des nächsten Datenpakets bremsen. Vielleicht sind dabei auch sogar meherer Hoppingfreuqenzen hintereinander "blockiert". Demgegenüber wird FCC ungebremst seine Datenpakete rausschicken, auch wenn es dabei zu einem Clash kommen sollte, wobei letzteres nicht zwangsläufig bedeutet, dass das gesendete Datenpaket unbrauchbar beim Empfänger ankommt.
Befindet sich dein Flieger auf einem Durchflug mit lokal ungünstiger Empfangslage, die eh schon ggf. Datenverluste begünstigt, dann kann Senden (FCC) oder Nicht-Senden (LBT) des nächsten Datenpakets durchaus den Unterschied machen zwischen Kontrolle behalten oder ab in den FS. Die "ungünstige Empfangslage" kann durchaus auch ein relativ niedriger Landeanflug sein bei entsprechenden Wetter-/Bodenbedingungen.
Zugegeben für den "normalen" Alltag und die Platzrunde wird es in der Regel keinen Unterschied machen. In kritischer Empfangslage bin ich jedoch bei FCC besser aufgehoben. Mag gerne jeder anders sehen.
Wenn das so implementiert ist, wurden halt die Möglichkeiten im LBT-Betrieb nicht ausgenutzt. Anstatt verzögern, prüfen und noch weiter verzögern kann ja auch mit weniger Leistung trotzdem gesendet werden. Manche Hersteller nutzen die Möglichkeiten, manche nicht und andere kennen sie vielleicht noch nicht mal.
Der LBT-Betrieb selber ist da unmisverständlich :
"'Unavailable' channels may be removed from or may remain in the hopping sequence, but in any case:
there shall be no transmissions on 'unavailable' channels"
und
" ..... this requirement does not apply for equipment with a maximum declared RF Output power level of less
than 10 dBm e.i.r.p. or for equipment when operating in a mode where the RF Output power is less than 10 dBm e.i.r.p."
Um demnach auch bei besetztem Kanal senden zu dürfen, muss dafür die Sendeleistung auf 10 mW zurückgenommen werden. Na super ...
"'Unavailable' channels may be removed from or may remain in the hopping sequence, but in any case:
there shall be no transmissions on 'unavailable' channels"
und
" ..... this requirement does not apply for equipment with a maximum declared RF Output power level of less
than 10 dBm e.i.r.p. or for equipment when operating in a mode where the RF Output power is less than 10 dBm e.i.r.p."
Um demnach auch bei besetztem Kanal senden zu dürfen, muss dafür die Sendeleistung auf 10 mW zurückgenommen werden. Na super ...
Beispiel für eine HF-Schleuder? Eine scheinbar harmlose Bluetooth-Maus. Sobald sie jedoch mit einem Notebook verbunden ist, legt Sie im Umkreis von 5m jegliches WLAN lahm. Als Maus funktioniert sie dennoch. Das Teil stammte vom Ramschtisch eines Elektronikmarktes, welcher weiß ich nicht mehr. Aber immerhin regulär in D verkauft, mit CE usw.
Eine Maus wird zwar kaum auf dem Flugplatz zum Einsatz kommen (wobei Kollegen durchaus auch mal ein Heli-FBL nachjustieren), aber anderer Elektronikschrott schon.
Eine Maus wird zwar kaum auf dem Flugplatz zum Einsatz kommen (wobei Kollegen durchaus auch mal ein Heli-FBL nachjustieren), aber anderer Elektronikschrott schon.
Ja MU10 geht auch, aber genau damit hat FrSky in der EU ihr Desaster bereits gehabt und als Folge davon dann doch letztlich LBT-Firmware gebracht. Und bezüglich Pausierens zwischen dem Senden von Datenpaketen und damit Sendeverzögerung dürfte MU10 genauso im Nachteil sein gegenüber FCC.
Und mehrere HF-Teile wegen LBT in der EU für die paar User?? Der Rest der Welt mit FCC braucht das nicht.
Und mehrere HF-Teile wegen LBT in der EU für die paar User?? Der Rest der Welt mit FCC braucht das nicht.
das läut so.
LBT-Variante
Hopping-Frequenz frei, dann mit 100mW senden
Hopping-Frequenz belegt, dann auf MU10 umschalten und dort mit 25...27mW senden (je nach Dwellzeit).
Damit wird eigentlich reines LBT ausgehebelt und doch auf der belegter Hopping-Frequenz gesendet.
Das ist also ein kastriertes FCC, nicht mehr und nicht weniger,
in der Hoffnung dass am Empfänger noch was ankommt.
Diese Schlupfloch wurde eingeführt als man merkte dass reines LBT in der realen HF-Umgebung
Ärger macht, nicht wirklich was bringt und die Echtzeitfähigkeit von FCC verloren geht.
Alles andere ist nur LBT- Lobhudelein der ETSI-Fraktion
LBT-Variante
Hopping-Frequenz frei, dann mit 100mW senden
Hopping-Frequenz belegt, dann auf MU10 umschalten und dort mit 25...27mW senden (je nach Dwellzeit).
Damit wird eigentlich reines LBT ausgehebelt und doch auf der belegter Hopping-Frequenz gesendet.
Das ist also ein kastriertes FCC, nicht mehr und nicht weniger,
in der Hoffnung dass am Empfänger noch was ankommt.
Diese Schlupfloch wurde eingeführt als man merkte dass reines LBT in der realen HF-Umgebung
Ärger macht, nicht wirklich was bringt und die Echtzeitfähigkeit von FCC verloren geht.
Alles andere ist nur LBT- Lobhudelein der ETSI-Fraktion
Zuletzt bearbeitet:
Ein wesentliches Merkmal des TDMA Mobilfunks ist, daß alle Teilnehmer sich an festen time-slots synchronisieren und sich an ein genau definiertes Protokoll halten und damit eine bestmögliche Effizienz der Netzauslastung erreichen.
Wie kann jemand behaupten, daß man mit LBT eine Verdreifachung der Kapazität erreicht, und die gleiche Person in der ETSI 1.8.1 keinerlei feste Synchronisation der Teilnehmer definiert, und dazu noch verschiedene Übertragungsprinzipien wie Frequenzhopping und Spread Spectrum ohne klare Definition in einem Sumpf zuläßt. Ein Widerspruch in sich.
Man betrachte es mal von so her: Wenn ich das ganz Band mit Teilnehmern soll voll ist, daß (unter FCC) nur noch 33% an gültigen Daten durchkommen, dann würde man, so heißt es, mit LBT wieder 100% erreichen (das 3-fache). haha
Anbei ein einfacher Test meinerseits, schon eine Weile her, ging damals an FrSky als noch FCC, MU und LBT im Boot waren. Bei hoher Auslastung ist LBT klar im Nachteil.
Die ETSI ist eine Denksportaufgabe für Labyrinth Freaks mit der Herausforderung, wie komme ich möglichst intelligent durch ohne anzuecken, eine Verbotsliste ohne Lösungskompetenz.
Wenn die Industrie eine Fabrik mit etlichen WLAN Teilnehmern vernetzt, dann geht das mit garantierter Echtzeit ohne jeglichen Crash, wenn sich alle Teilnehmer an ein gemeinsames Protokoll halten. Das geht mit state-of-the-art Intelligenz unter FCC, dazu braucht man kein LBT.
Wie kann jemand behaupten, daß man mit LBT eine Verdreifachung der Kapazität erreicht, und die gleiche Person in der ETSI 1.8.1 keinerlei feste Synchronisation der Teilnehmer definiert, und dazu noch verschiedene Übertragungsprinzipien wie Frequenzhopping und Spread Spectrum ohne klare Definition in einem Sumpf zuläßt. Ein Widerspruch in sich.
Man betrachte es mal von so her: Wenn ich das ganz Band mit Teilnehmern soll voll ist, daß (unter FCC) nur noch 33% an gültigen Daten durchkommen, dann würde man, so heißt es, mit LBT wieder 100% erreichen (das 3-fache). haha
Anbei ein einfacher Test meinerseits, schon eine Weile her, ging damals an FrSky als noch FCC, MU und LBT im Boot waren. Bei hoher Auslastung ist LBT klar im Nachteil.
Die ETSI ist eine Denksportaufgabe für Labyrinth Freaks mit der Herausforderung, wie komme ich möglichst intelligent durch ohne anzuecken, eine Verbotsliste ohne Lösungskompetenz.
Wenn die Industrie eine Fabrik mit etlichen WLAN Teilnehmern vernetzt, dann geht das mit garantierter Echtzeit ohne jeglichen Crash, wenn sich alle Teilnehmer an ein gemeinsames Protokoll halten. Das geht mit state-of-the-art Intelligenz unter FCC, dazu braucht man kein LBT.
Schöner Test. Genau sowas braucht es. Ich gehe stark davon aus dass im Zuge der aktuellen Problematik du genau so den Frameloss angeschaut hast um den Fehler überhaupt sichtbar zu machen.
Jeder RC Hersteller wird weiterhin sein eigenes Süppchen kochen was die Protokolle angeht. Den Fall den du beschreibst in der Telekommunikation, wo ein gemeinsames festes Protokoll für die Zeitslots verwendet wird, werden wir im RC Bereich nie haben. Dafür ist der Bedarf der Bandbreite im 2.4GHz Band noch nicht hoch genug. Jegliche Vorschriften, inkl LBT, sind ja nur ein Versuch eine Marschrichtung vorzugeben. Nur solange nicht auch eine verbindliche und explizite Implementierung dieser Richtung mitgeliefert wird bleibt es das Labyrinth von dem du sprichst, wo jeder RC Hersteller einfach möglichst gut durchkommen will.
Jeder RC Hersteller wird weiterhin sein eigenes Süppchen kochen was die Protokolle angeht. Den Fall den du beschreibst in der Telekommunikation, wo ein gemeinsames festes Protokoll für die Zeitslots verwendet wird, werden wir im RC Bereich nie haben. Dafür ist der Bedarf der Bandbreite im 2.4GHz Band noch nicht hoch genug. Jegliche Vorschriften, inkl LBT, sind ja nur ein Versuch eine Marschrichtung vorzugeben. Nur solange nicht auch eine verbindliche und explizite Implementierung dieser Richtung mitgeliefert wird bleibt es das Labyrinth von dem du sprichst, wo jeder RC Hersteller einfach möglichst gut durchkommen will.
Nach dem ich jetzt zurück und wieder vor gelesen habe (auch in anderen) Foren bleiben bei mir noch ungeklärte Fragen.
Oder: die bisherige Fehlerlogik ist zum CRC-Fehler ist falsch.
Der „Uhrfehler“ soll eine fehlerhafte/unzureichende CRC-Implementierung sein, die sehr selten einen fehlerhaften Datensatz nicht erkennt und es so zu unkontrollierten Servoausschlägen kommt.
Eine 100% tige CRC Prüfsicherheit wird in der Regel jedoch gar nicht angestrebt, es werden immer „schnelle“ Verfahren mit „nur“ hoher Erkennwahrscheinlichkeit eingesetzt. Mit der auftretenden Fehlerrate konnte man ja auch bisher sehr gut leben.
Daraus folgt: Der CRC-Check Fehler ist kein keinen Fehler.
Erst (nur) in Verbindung mit LBT und hoher Funkauslastung steigt dann die Rate der fehlerhaften Frames und damit die Anzahl CRC-Fehler und es kommt zu dem beschriebenen Problem.
Aber wenn ich LBT anwende, dann bekomme ich weniger fehlerhafte Frames und nicht mehr, denn ich Sende nicht. Da kommt beim Empfänger dann kein verstümmeltes Signal an, sonder gar keins, nichts von meinem Sender. Damit kann der Empfänger aber umgehen, weil das jetzt zum Protokoll gehört. Erst wenn statt gar nicht mit Mu10 Sende, erhöhe ich die Anzahl der verstümmelten Signale. Den Schwachsinn macht FrSky ja nicht.
Sigi
Oder: die bisherige Fehlerlogik ist zum CRC-Fehler ist falsch.
Der „Uhrfehler“ soll eine fehlerhafte/unzureichende CRC-Implementierung sein, die sehr selten einen fehlerhaften Datensatz nicht erkennt und es so zu unkontrollierten Servoausschlägen kommt.
Eine 100% tige CRC Prüfsicherheit wird in der Regel jedoch gar nicht angestrebt, es werden immer „schnelle“ Verfahren mit „nur“ hoher Erkennwahrscheinlichkeit eingesetzt. Mit der auftretenden Fehlerrate konnte man ja auch bisher sehr gut leben.
Daraus folgt: Der CRC-Check Fehler ist kein keinen Fehler.
Erst (nur) in Verbindung mit LBT und hoher Funkauslastung steigt dann die Rate der fehlerhaften Frames und damit die Anzahl CRC-Fehler und es kommt zu dem beschriebenen Problem.
Aber wenn ich LBT anwende, dann bekomme ich weniger fehlerhafte Frames und nicht mehr, denn ich Sende nicht. Da kommt beim Empfänger dann kein verstümmeltes Signal an, sonder gar keins, nichts von meinem Sender. Damit kann der Empfänger aber umgehen, weil das jetzt zum Protokoll gehört. Erst wenn statt gar nicht mit Mu10 Sende, erhöhe ich die Anzahl der verstümmelten Signale. Den Schwachsinn macht FrSky ja nicht.
Sigi
Aber ein neuer Gedanke mit Frage an die Fehlerkundigen
Wenn "verstümmelten" Datensätze gar nicht auf der Funkstrecke entstehen.
Wenn bereits im Sender ein fehlerhafter Datensatz mit CRC Codiert wird ...
dann wird der Empfänger diesen Datensatz immer als korrekt behandeln und an die Servos weitergeben.
Nur das würde auch erklären warum fast immer nur Kanal 1 oder 2 betroffen sind (Engel Forum).
Konnte man das messen, das der Sender immer korrekte Frames sendet?
Sigi
Nachtrag: Das würde so ziemlich alles erklären ...
Warum nur neue Sender, a
auch bei bester Funklage, in der Pampa mit wenigen Sendern,
auch im Keller auf dem Tisch, bei bester Betonabschirmung von hoch liegenden Richtstrecken.
oder
Wenn "verstümmelten" Datensätze gar nicht auf der Funkstrecke entstehen.
Wenn bereits im Sender ein fehlerhafter Datensatz mit CRC Codiert wird ...
dann wird der Empfänger diesen Datensatz immer als korrekt behandeln und an die Servos weitergeben.
Nur das würde auch erklären warum fast immer nur Kanal 1 oder 2 betroffen sind (Engel Forum).
Konnte man das messen, das der Sender immer korrekte Frames sendet?
Sigi
Nachtrag: Das würde so ziemlich alles erklären ...
Warum nur neue Sender, a
auch bei bester Funklage, in der Pampa mit wenigen Sendern,
auch im Keller auf dem Tisch, bei bester Betonabschirmung von hoch liegenden Richtstrecken.
oder
Wenn man nicht wie Ewald zwei 1W Videosender in das Modell packt oder Router und Störsender, dann können eine ganze Menge Flugmodelle störungsfrei mit LBT parallel betrieben werden. Diese Zahl kann man ganz gut abschätzen und in keinem der bekannten Lockout-Fälle waren auch nur ansatzweise so viele Modelle in der Luft.
Realistische Lost Frame Werte kann man nur in realistischen Szenarien bekommen, diese Tests wurde m.W. noch gar nicht durchgeführt. Ich habe aber, ehrlich gesagt, auch keine Lust zu fliegen, wenn viele Dutzend Modelle in der Luft sind.
Das LBT Prinzip ist definitiv nicht schuld an den Lockouts. Der Auslöser der Lockouts ist für mich ziemlich sicher eine zu hohe Frequenzverschiebung Sender/Empfänger. Die vielen ausfallenden Frames lösen dann vermutlich durch nicht sauber programmierte (LBT-) Firmware den Lockout selbst aus. Beide Probleme muss FrSky angehen.
Realistische Lost Frame Werte kann man nur in realistischen Szenarien bekommen, diese Tests wurde m.W. noch gar nicht durchgeführt. Ich habe aber, ehrlich gesagt, auch keine Lust zu fliegen, wenn viele Dutzend Modelle in der Luft sind.
Das LBT Prinzip ist definitiv nicht schuld an den Lockouts. Der Auslöser der Lockouts ist für mich ziemlich sicher eine zu hohe Frequenzverschiebung Sender/Empfänger. Die vielen ausfallenden Frames lösen dann vermutlich durch nicht sauber programmierte (LBT-) Firmware den Lockout selbst aus. Beide Probleme muss FrSky angehen.
Ogottogott 
Bei solchen FUD Aussagen rollen sich mir die Zehennägel auf. Bekommen wir trotzdem noch eine konkrete Einschätzung, wieviel Flugmodelle geichzeitig mit LBT ohne merkliche Einschränkungen betrieben werden können?
Bei solchen FUD Aussagen rollen sich mir die Zehennägel auf. Bekommen wir trotzdem noch eine konkrete Einschätzung, wieviel Flugmodelle geichzeitig mit LBT ohne merkliche Einschränkungen betrieben werden können?
und hier => RC-Network - Adaptive Funksysteme - ein Nachtrag
