Link Quality Sensor von Tadango

Schön, dass du einigermaßen auf der Sachebene angekommen ist. In der postfaktichen Zeit, die du ja auch bedauerst, ist das schon mal ein wesentlicher Schritt. Ironie findet sich übrigens weder bei Trump noch bei der AFD, von daher ist auch dieser Vergleich leider völlig unpassend. Da bin ich genau der Falsche.
"Wer JETI fliegt, spürt eh nix mehr. Aber jetzt mal im Ernst. Glaubt FrSky wirklich, dass man den SBus aus 4 Frames zusammensetzen kann und das dann auch noch der Latenz zugute kommt? "
OK, ich hab die Smileys weggelassen, wenn man aber liest "Aber jetzt mal im Ernst" dann darf man darauf schließen, dass vorher Spaß war.
"Dann hat das Engel Team losgelegt und plötzlich waren alle FrSky Anlagen betroffen. Für mich ist die Frage, ob FrSky das Spiel durchschaut und im Windschatten ihre Interessen durchzubringen versucht. Also Rumbasteln an der Frequenzabweichung, Schönung des Lost Frame Verhaltens und Ausschluss der Konkurrenz. Oder ob sie wirklich auf das Arroganzteam hereingefallen sind und selbst an die Geschichtchen glauben vom SBus Hütchenspielertrick - aber das ist doch eigentlich lächerlich, oder? "
Jetzt positionier dich bitte, das muss nicht richtig sein, es geht um deine Meinung:
- Sind alle FrSky Kombinationen von Anfang an von diesem Problem betroffen (im realen Flugbetrieb)?
- Schönt FrSky die Lost Frames um eine bessere Link Qualität vorzutäuschen?
- Wurde das AFC Fenster der Empfänger verändert?
- Wurde das Kopieren bzw. Klonen des Protokolls erschwert (FrSky darf das, sollte es aber öffentlich machen)
- Kann man ein SBus Frame sinnvoll aus einem Ringbuffer zusammensetzen?
- Wie wirkt sich das auf die Latenz aus?
" Übrigens bin ich sicher, dass sich JETI User den SBus Ringbuffer für 80€ nachkaufen würden "
- (scherzhaft) Wieviel Prozent der JETI User würden ein SBus-Ringbuffer-Performance-Update kaufen?

Das muss ich jetzt noch loswerden: Exakt dein Wutpost ist heute das Mittel der postfaktischen Populisten. Verschwörungstheorien kann man nur mit Fakten begegnen. Idealerweise mit Fakten, die man selbst nachvollziehen kann. Lass uns daran arbeiten.
 
Das sind zwei unterschiedliche Dinge, Meinung und Fakten. Ich frage seine Meinung ab, weil er sich nicht positioniert. Ich weise sogar explizit darauf hin, dass es nicht richtig sein muss.

Und du demonstrierst mal wieder völliges Unverständnis. Du bist nicht in der Lage oder willens, dich auf eine andere Sichtweise einzulassen. Das ist schade. vor allem, weil es sich um relativ einfache Sachverhalte handelt. Sowohl hier, wie auch beim SBus Hütchenspiel. Udo hat den SBus Quatsch ja irgendwann eingesehen, der andere Kollege äußert sich scheinbar gar nicht mehr?
 

FJH

Erfahrener Benutzer
Ich schlage vor, dass wir jetzt einfach mal abwarten, was uns als v2-Update von FrSky angeboten wird, bis jetzt weiss das ja offensichtlich noch keiner. Und damit bleibt auch erst mal alles offen, sowohl LF-Bit im SBus als auch ein mögliches Auto-tuning und (zumindest bei mir) noch die Hoffnung auf einen LQ-Sensor. Da sollte und wird ganz sicher dann wieder genau hingeschaut werden. Es geht doch hier letztlich niemandem um Rechthaberei sondern um die Sache und da schliesse ich ausdrücklich keinen aus. Und man kann in manchen Punkten ja durchaus unterschiedlicher Meinung sein, sei es aufgrund unterschiedlicher Bewertung oder auch aufgrund eines unterschiedlichen Wissenstandes. Für alle sollte zumindest in diesem Forum ein Platz sein, sich frei äussern zu dürfen. Also lasst uns doch alle mal eine Pause einlegen und schauen, was als nächstes Update kommt.
 
Reine Projektbetrachtung, nicht technisch:

Das Auto-Tuning müßte jetzt flächendeckend rein kommen, da TX und RX FW angepaßt werden muß.
Ich denke eher nicht bei ACCST, für ACCESS könnte es zeitlich noch klappen, wenn FrSky das will.

Ein LQ Sensor für den downlink oder uplink kann "case by case" immer nachgeliefert werden.
FW Zusatz ohne Kompatibilitätskonflikt.
 
Zuletzt bearbeitet:

FJH

Erfahrener Benutzer
Ich weiss, dass bei FrSky ein Auto-tuning zumindest ernsthaft betrachtet wird. Ob man es dann allerdings auch umsetzt, muss abgewartet werden.

Und bzgl. LQS zusätzlich zum RSSI habe ich FrSky auf folgendes hingewiesen:

1) Wenn LQS, dann sollte die bis dato angewandtle Mischkalkulation des RSSI bereinigt werden und ein sauberer RSSI ausgegeben werden. Letzterer wird dann nicht mehr vergleichbar mit "altem" RSSI sein. Es sollten dann jeweils für den LQS als auch für den dann neuen RSSI speziische Alarmwerte agegeben werden, die in OTx dann entsprechend vorgeblendet werden.

2) Wenn man sich bei FrSky entschliesst, den LQS mit dem bereinigten RSSI dem neuen ACCESS vorzubehalten, dann erzeugt man damit eine sehr unschöne Situation. Die User müssen sich dann bei ACCST und ACCESS mit nicht vergleichbaren RSSI-Werten (Alarme, FS) herumschlagen. Technisch zwar machbar, kann mir aber nicht vorstellen, dass man sich das traut. Der bereinigte RSSI hätte zudem für FrSky bei ACCESS noch den Vorteil, dass es ein Ausweg wäre aus der aktuellen Schieflage der ACCESS-RSSI-Mischkalkulation/Skalierung. Die haben sie nämlich bislang nicht vergleichbar mit ACCST hingekriegt. Stattdessen hat FrSky empfohlen, für ACCESS die Alarmwerte runterzusetzen, unschön und verwirrend für den User.

Leider habe ich meinen FrSky-Kontakt nur über das Marketing, nicht (mehr) über die Technik. Warten wir es also ab.
 
Zuletzt bearbeitet:
Heute mal den neuen Sensor am Boden getestet...
Empfänger im Garten an einen Baum gehängt und mit dem Sender ins Haus gegangen.

Immer alles gleich, bis auf den Ort des Bindens. Ich weiß jetzt nicht, was ich davon halten soll?
Es war windig, der Empfänger pendelte hin und her, war dafür aber perfekt gekühlt.
Der Empfänger ist aus einer Bestellung von September 2019 mit unveränderter Firmware.

Taranis X9D+SE mit R-XSR LBT:
X9D+SE_mit_r-xsr_lbt.jpg
Links mit bereits im Haus gebundenem Empfänger, rechts neu gebunden im Garten, nach zwischenzeitlichem Test mit X-Lite Pro.

X-Lite im Garten gebunden:
X-Lite_pro_mit_r-xsr_lbt.jpg
X-Lite im Haus neu gebunden:
X-Lite_pro_mit_r-xsr_lbt_2.jpg
X-Lite beide Logs:
X-Lite_beide.jpg
X-Lite nochmal unverändert nur länger: (zweimal kam Warnung zur Empfangsstärke)
X-Lite_pro_mit_r-xsr_lbt_3.jpg
Im Garten nochmals neu gebunden:
X-Lite_pro_mit_r-xsr_lbt_4.jpg
X-Lite komplett:
X-Lite_pro_mit_r-xsr_lbt_5.jpg


:???: scheint reproduzierbar zu sein...

Vorgehen und Ort immer genau gleich, auch der Sender lag jeweils immer genau gleich auf dem Tisch.
 

Anhänge

Auf den ersten Blick würde ich sagen, dass du in dem RSSI Bereich bist, wo die Lost Frames bereits RSSI bedingt ansteigen.
Der Log zeigt sehr übersichtlich den Zusammenhang zwischen RSSI und Lost Frames.
Im Garten nochmals neu gebunden:
Zeigt anfangs dieselben Oszillationen im RSSI wie ich sie mal von Andrew gepostet habe, schon seltsam. Oder ist das nur der Wind?

Du solltest mal versuchen, den RSSI bei 60 zu halten, und dann die Lost Frames zu vergleichen. Wieviel WiFi Störungen hast du dort? Die Störungen haben großen Einfluss auf die Lost Frames. Eigentlich müsste man den Test außerhalb der Zivilisation wiederholen.

Wenn deine Beobachtung aber darauf hinausläuft, dass der RSSI je nach Bindeort unterschiedlich ist, dann habe ich keine Erklärung.
 
wenn ich das FrSky Verfahren richtig verstanden habe, werden beim Binden die Hopping Frequenzen festgelegt. Das sind 47 Frequenzen aus 250 möglichen. Beim erneuten Binden sind das dann andere Frequenzen. Wenn es WLAN Störungen gibt, könnte man einmal Glück haben mit den 47 Frequenzen und einmal eine schlechtere Kombi erwischen. Dann sind die Framelosses vielleicht nicht vom Ort des Bindens, sondern von der gewählten Hopping Sequenz abhängig.
 
Mal als Vergeich meine gute alte X9D (LBT) mit einem X4R im Haus. Man sieht hier schön, wie um die 45dB die Losses beginnen. Das halte ich für das normale und erwartbare Verhalten. Deswegen besser beim Test immer darüber bleiben, sonst wird es unübersichtlich. Rechts sieht man, dass die 100% nicht mehr erreicht werden.
X9D+X4Rinhouse.jpg
Beim X4R hat FrSky noch die LQ Funktion drinnen, man sieht, wie der RSSI nach unten rauscht, wenn der LQ einbricht. Das hat nichts mehr mit dem normalen RSSI Bereich zu tun. Die Empfehlung, die Warnung herabzusetzen, wird sich trotzdem weiter hartnäckig halten ;)

@ReinhardZ Ich glaube, dass bei gleicher Receiver Nummer und Sender ID immer die gleiche Hopping Tabelle verwendet wird. Sonst könnte man nicht mehrere Empfänger binden.
 
Also die Receiver Nummer ändern und gucken, ob's besser wird :)
Mach den Ogottogotts keine Angst ;) Das ist das völlig normale Verhalten und absolut unkritisch. Wir suchen doch nach einem Grund, warum manche Kombinationen sich anders verhalten. Und dazu muss man identische Voraussetzungen schaffen. Die WiFi Störungen bewirken ja nur, dass eine Handvoll Frames ausfallen, dann ist man wieder bei 100%. Das merkt kein Mensch. Auch 50% Frameverlust bemerkt man nicht beim Steuern.

Wenn aber eine Kombination nie die 100% erreicht, auch nicht kurzfristig (Edit: so dass wenigstens ab und zu eine kurze gerade Linie zu sehen ist), trotz RSSI >60, dann ist vermutlich etwas grundsätzlich faul. Diese Kombinationen suchen wir. Das hier ist so ein Kandidat mit Lockout (lag am S8R):
Skymule_frames.jpg
 
Zuletzt bearbeitet:
Seltsam... naja nochmal versucht, war es eben andersrum.

Im Haus gebunden:

Bildschirmfoto zu 2020-02-19 16-47-28.jpg
Draußen neu gebunden:
Bildschirmfoto zu 2020-02-19 16-47-47.jpg

Diesmal den Empfänger und seine Antennen auf einem Karton fixiert, Antennen frei nach oben und nicht ins Haus gegangen mit dem Sender. Der Empfänger und der Sender lagen genau gleich, nur neu gebunden.
Der RSSI ist deutlich unterschiedlich,das verstehe ich nicht :???:
 
Dann bist du vielleicht an etwas dran (y)

Kannst du mir mal die Log-Datei schicken?
 
RCLogger

FPV1

Banggood

Banggood

Oben