FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

GerdS

Erfahrener Benutzer
Dass es immer nur dieselben Kollegen mit einer bestimmten Hardwarekombination trifft, hat aber noch niemand erklärt, oder übersehe ich etwas?
Es trifft viel mehr, wie ich heute wieder feststellen durfte, nur die stochern wegen der Ursache noch im Nebel und suchen den Grund für den Absturz überall, nur natürlich nicht in der Software ihrer Sender und Empfänger. Ein Flächenflieger hat 3 Modelle verloren und nach Sichtung seiner Bordvideos ist die Ursache ebenfalls ziemlich sicher unserem Problem hier zuzuordnen...

Gruß Gerd
 
Das wäre aber extremes Pech, wenn man durch den kurzen Lockout 3 Flächenflieger verliert. Dass Copter sofort runterfallen, ist normal, bei Fläche muss es einen extrem tief, bzw. im Landeanflug erwischen. Man darf nicht vergessen, dass es auch noch eine Menge anderer Ursachen geben kann.

Je mehr konkrete Daten zusammenkommen, desto eher kann man Wahrscheinlichkeiten definieren.
 

RayX

Ein niemand
Es funktioniert auch mit G-RX8, zumindest bei mir, Firmware auf dem RX ist egal ob alt oder neu.

Das XJT ist bei mir der Schlüssel,

Mit 170317 Sporadische Servobewegungen und Failsafe.
Mit 151223 ist von den Problemen nichts mehr zu sehen, auch bei sehr langen tests nicht.
 
Hammer. War das mit LBT? Es scheint ohne (bis jetzt) erkennbares System einfach bestimmte Kombinationen von Hard- und Firmware zu betreffen. Den G-RX8 habe ich schon stundenlang mit 170317 laufen lassen, ohne auch nur einen Mucks zu bemerken.
 

RayX

Ein niemand
Mit LBT häufig.
Mit FCC seltener, aber vorhanden, hier habe ich allerdings nicht die ältere Firmware getestet.
Ich war froh überhaut eine Lösung gefunden zu haben bis das Update von Frsky verfügbar ist.
 
Mit LBT häufig.
Mit FCC seltener, aber vorhanden, hier habe ich allerdings nicht die ältere Firmware getestet.
Ich war froh überhaut eine Lösung gefunden zu haben bis das Update von Frsky verfügbar ist.
Die Engel-Kommission hat ja einen Fehler festgemacht, der nicht von der Firmware- und Hardware-Version abhängt und nur bei sehr schwachem Signal und hohem Störpegel frameweise auftritt. Von daher vermute ich, dass ein dahingehendes Update das Lockout Problem nicht lösen wird. Und es deswegen Sinn macht, weiter nach Abhängigkeiten zu suchen.

Beschreib doch mal deine Testbedingungen, Stromversorgung RX, Abstand Sender-Empfänger, Rangetest- oder Normalmodus, Fehlerhäufigkeit u.s.w..
 
Die Engel-Kommission hat ja einen Fehler festgemacht, der nicht von der Firmware- und Hardware-Version abhängt und nur bei sehr schwachem Signal und hohem Störpegel frameweise auftritt. Von daher vermute ich, dass ein dahingehendes Update das Lockout Problem nicht lösen wird.
Ich war der selben Meinung, konnte mich aber vom gegenteil überzeugen.
 
Ich sage es eindeutig so:

Wenn eine meiner FrSky Kombinationen seit 2013 einen Lockout-Fehler gehabt hätte, hätte ich es definitiv bemerkt. Ob eines der Millionen/Milliarden Frames für 1/100s eine falsche Kanalinformation beinhaltet, konnte und kann ich, genau wie jeder andere, nicht bemerken.

Es gibt aber bei bestimmten Kombinationen Lockouts und nur diese Lockouts sind problematisch. Ein falscher Kanalwert alleine ist vollkommen unproblematisch, außer man konstruiert eine sehr unwahrscheinliche Situation mit falschem Kanalwert und vielen anschließenden Lost Frames.

Im Übrigen gilt: bei schlechtem HF-Wetter hilft immer noch der Alu-Hut am besten :)
 
Da gibt es unterschiedliche Ansichten. Meiner Meinung nach zeigt sich das Problem in sehr wenigen Fällen als kurzer Verbindungsverlust, der manchmal mit einem ungesteuerten Ausschlag verbunden ist. Die andere Interpretation ist, dass alle FrSky Systeme ungesteuerte Ausschäge zeigen können, die sehr selten mit einem Verbindungsverlust zusammen auftreten.
 
Bei meinem System X9D+ mit G-RX8 sind es Sporadische Servo Bewegungen ohne Failsave und ab und zu auch sehr kurze Failsave mit den dementsprechenden Ruderbewegungen so wie voreingestellt.
 
Bist du sicher, dass während der Servobewegungen kein Verbindungsverlust vorliegt? Nur wenn der Verbindungsverlust länger als ~1s dauert, wird nämlich Failsafe getriggert.
 

GerdS

Erfahrener Benutzer
Bei meinem Whoop mit XM+ ist es dieses Jahr dreimal passiert, jedesmal Vollausschlag auf Kanal 1 (ca. 2ms Pulsweite) gefolgt von 0,5-1s Lockout, angezeigt durch die RXLOSS-Meldung im OSD. Beim anderen Whoop mit R-XSR mindestens ein Dutzend Mal kurzes Lockout mit RXLOSS-Meldung, was ich ohne die Meldung oft nicht mal bemerkt hätte, weil ich Failsafe in Betaflight so eingestellt habe dass er nicht gleich vom Himmel fällt. Jeweils in Entfernungen zwischen 6 und um die 100m...

Gruß Gerd
 
FPV1

Banggood

Oben Unten