FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

arti

Well-known member
Hallo zusammen,
Ich lese hier eigentlich nur mit, da ich von dem was Ihr hier besprecht max. die Hälfte verstehe.
Habe aber jetzt aus gegebenem Anlass eine Verständnisfrage.
Ihr sprecht hier von alter und neuer Hardware. Sprich Empfänger und HF-module die evtl. Probleme mit unterschiedlichen Frequenzen haben und dadurch evtl. Logouts etc. verursachen. Bezieht sich das "alt" auf ältere Hardwaregenerationen oder tatsächlich auf gleiche Bauteile älterer oder neuerer Proktion?
Ich Frage, da bei meiner X9D+ von 2014 reparaturbedingt das Backboard inkl.
HF-teil getauscht wurde. Da ich bis jetzt keine Probleme hatte, habe ich ein bisschen bedenken mir jetzt welche einzufangen.

Gruß Andreas
Ich hab eine "alte" X9D+ eine neuere X12S und eine ganz neue Xlite Pro.
Wegen der Xlite Pro sind mir 2 700er Helis wegen je einem Lockout gecrasht.

Den größten Unterschied zwischen alt und neu sollten tatsächlich die verwendeten HF Chips machen. In den XJT Sendemodulen (auch iXJT) wurde der CC2500 verwendet. Die ACCESS Hardware verwendet den CC2650. Die direkte Peripherie dieser beiden Chipvarianten ist unterschiedlich und damit kann die resultierende HF-Frequenz sich zwischen den beiden Generationen leicht voneinander unterscheiden.
Zusätzlich können fertigungsbedingte Toleranzen der verwendeten Komponenten auch zu besagten Frequenzabweichungen führen. Das schien bei den ganz alten Chargen kein Problem gewesen zu sein. Mit neueren Sendern wie der X12S, und dem darin verbauten neuen iXJT Modul sind dann die ersten Probleme aufgetaucht. Nur war da die Wahrscheinlichkeit davon betroffen zu sein noch zu niedrig und Probleme waren eben Einzelfälle.

Ich selber fliege nur noch mit der X9D+ mit der neuen V2 Firmware und ausschließlich Kleinvieh, welches mir und meinem Geldbeutel nicht wehtut wenn es runterkommt. Nach 150 Flügen würde ich mich jetzt auch größere Helis damit fliegen.

Dank dem Release der neuen V2.1 FW für die Xlite Pro kann ich jetzt auch diese testen. In einer ganz trivialen Trockenübung mit viel Frameloss kann ich bei Empfängern, gebunden an die Xlite Pro ACCST D16 V1, etwa einmal alle 20 Minuten einen Failsafe provozieren. Mit der neuen ACCST D16 V2.1 kriege ich nach 180 Minuten Beobachtungszeit unter ähnlichen Bedingungen keinen einzigen Failsafe hin. Mit meiner X9D+ habe ich das auch mit V1 und V2 probiert. Selbes Ergebnis, unter V1 gehen die Empfänger hin und wieder in einen Failsafe. Unter V2 krieg ich mit meinem Testaufbau in der zehnfachen Beobachtungszeit keinen einzigen Failsafe provoziert.
 

arti

Well-known member
Ist diese HF V2 FW wirklich sicherer?
Ja das ist sie, zumindest bezüglich dem bekannten alten Bug.

Im alten Protokoll existiert ein kritischer Fehler welcher zu einem Synchronisationsverlust zwischen Empfänger und Sender auf der ACCST Protokollebene führen kann. Die Wahrscheinlichkeit mit der dieser Fehler auftritt ist nach meinem Verständnis direkt proportional mit dem Anzahl der verlorenen Frames in der HF Übertragung zwischen Sender und Empfänger. Die LED am Empfänger gibt übrigens darüber eine Auskunft.
Besitzt du ein Setup wo nicht viel Frameloss auftritt, dann wird der besagte Fehler bei dir sehr sehr selten auftreten.

Ziel von V2 ist es den Bug zu beseitigen oder zumindest die Auftrittswahrscheinlichkeit noch einmal deutlich zu reduzieren. Ein Setup das mit V1 Probleme hatte könnte dann mit V2 genau so selten ausfallen wie ein unauffälliges V1 Setup.

Weil es noch nicht viele verlässlichen Zahlen zu der ganzen Thematik gibt bleibt jetzt nichts anderes übrig als nach seinem Bauchgefühl zu gehen. Mit der Zeit wird es dann genügend Erfahrungen geben und eine klare Aussage ob V2 ohne weitere Probleme daher kommt.
 
Ganz kurz gesagt, wenn die grüne Empfänger LED stabil leuchtet, muss man sich keine Gedanken machen. Wenn sie deutlich flackert, hat man möglicherweise ein betroffenes System.
 
Ich habe jetzt mal einen RX6R Empfänger mit ACCESS 2.1.0A SW an die Taranis X9D+2019 gebunden und den neuen FLR% Wert geloggt. Der Wert zeigt auf jeden Fall mehr an, als die gefilterten FL-Bits vom SBus, wird aber wohl nur alle 700ms upgedated.

1585762022299.png

Wenn man statt FLR% den Wert FLR100 = 100-FLR% darstellt, kann man besser vergleichen:
1585762200998.png

Anbei noch die Logdatei (.txt am Ende löschen)
 

Anhänge

Hallo Arti, Hallo Carbonator.
Danke für Eure Antworten. Was ich daraus mitgenommen habe ist: Ausprobieren und die LED beobachten. Und xjt ist xjt, mögliche Abweichungen kommen Max.von Bauteiltoleranzen.
Also warte ich bis der Sender wieder da ist und glotze dann auf die LED.
In guter Hoffnung 😉
Andreas
 
Und nach wie vor fliegt die Mehrheit der FrSky Nutzer mit der alten Firmware ohne Probleme und wird vermutlich auch nicht auf die V2.1 flashen. Hier im Forum und auch im Nachbarforum kann man aber schnell den Eindruck gewinnen, dass man FrSky eigentlich gar nicht benutzen kann. Komischerweise sah das bis Spätsommer letzten Jahres anders aus. Da wurde über die sichere Übertragungstechnik von Frsky gejubelt.
Meinte der Herr Engel heute.

Dieses Forum kann er nicht meinen, denn ich habe von Anfang an immer wieder darauf hingewiesen, dass nur wenige Kombinationen von dem Fehler betroffen sind.

Irgendwo kamen dann ein paar *zensiert* auf die Idee, Störsender zu aktivieren und haben so nachgewiesen, dass alle FrSky Empfänger problematisch sind. Dass ich dies für kompletten Unsinn halte, ist hier ebenfalls mehrfach nachzulesen. Hier ein Beispiel.

Vielleicht wäre ein klein wenig Selbstkritik angebracht, anstatt über die bösen User zu schimpfen? Die quatschen doch nur nach, was die hochgelobten "Experten" festgestellt haben.
 
Andrew hat interessante Erlebnisse mit der G-RX8 2.1.0E Firmware gehabt. Schön unterlegt mit vielen Telemetrie Daten. Ein Fest für Leute, die sich im Log lesen üben wollen.

Ein einzelner Tester ist natürlich eine denkbar schlechte Basis für Schlussfolgerungen. Wo sind eigentlich die ganzen User, die vom plötzlichen Servoausschlag betroffen waren?
 

Gruni

Erfahrener Benutzer
Das frag ich mich auch.
Ich war gestern das erste mal wieder fliegen dieses Jahr. Fläche.
Whoops und Hawks gehen den ganzen Winter.
Mit FCC kein einziger Hänger.
Also ich weis nix oder ich merk nix oder beides.😂😂😂

Nen schönen zweiten Ostertag, Gruni
 
Zum Malen nach Zahlen hier noch der relevante Ausschnitt aus dem Logfile. Man sieht eindeutig, dass die Pilotenreaktion in dem Moment erfolgt, als die Telemetrie einfriert. Eindeutig ein plötzlicher Servoausschlag.
 

Anhänge

Welchen Sender hatte der Kollege?
Die 2.1E soll ja ( mittlerweile) einwandfrei laufen. Das sieht irgendwie nach dem Einzelfall aus und ist für mich jetzt nicht unbedingt serienrelevant.

Schönen Ostermontag

Gruß Michael
 
Welchen Sender hatte der Kollege?
Die 2.1E soll ja ( mittlerweile) einwandfrei laufen. Das sieht irgendwie nach dem Einzelfall aus und ist für mich jetzt nicht unbedingt serienrelevant.
Eine QX7. Man sollte es vielleicht besser so ausdrücken: die 2.1.0E hat jetzt wieder die Funktionalität der V1 Firmware. Jetzt können Betroffene anfangen zu testen, ob die Lockouts und USM tatsächlich beseitigt sind. Bei dem Einzigen, der kompetent testet, ist dies nicht der Fall.
 

Sigimann

Erfahrener Benutzer
Welchen Sender hatte der Kollege?
Die 2.1E soll ja ( mittlerweile) einwandfrei laufen. Das sieht irgendwie nach dem Einzelfall aus und ist für mich jetzt nicht unbedingt serienrelevant.

Schönen Ostermontag

Gruß Michael
jetzt kommt ein bewiesener Fehler
Also die "plötzlichen Servoausschläge" wahren immer Einzelfälle. Tausende von Fliegern haben gar nichts bemerkt und die betroffenen hatten den Ausschlag auch nur sehr sehr selten. Selbst nach richtiger Erkenntnis der Dinge habt man den Fehler nur in wenigen Einzelfällen auch Nachweisen können.
Und FrSky hat aufgrund der wenigen Fehler ihre gesamt Software für Schrott erklärt.

Und für die neue Software gibt es ein "paar" Tests die keinen 'Fehler zeigen und jetzt zeigt jemand diesen Fehler mit LOG Datei. Und da redest du von einem Einzelfehler?
Die ganze neue Software muss sich doch erst bewähren, Versprochen sind nicht weniger "Plötzliche Servosudschläge" sondern gar keine.

Also weitertesten bis die Version "F" kommt. Nach E kommt F, ich war noch bei Version C
 
Zuletzt bearbeitet:

Sigimann

Erfahrener Benutzer
Nachtrag:

Ich war etwas schnell. Nach Sichtung der Orginalbeiträge bin ich nicht sicher ob es tatsächlich ein "Plötzlicher Servoausschlag" im Sinne des bekannten Fehlrs war.

Vielleicht kann carbo das noch etwas erklären,

Sigi
 
Beim "plötzlichen Servoausschlag USM" kommt zuerst der Ausschlag, direkt gefolgt von einem Lockout. Im Logfile sieht man das schön. Andrew steuert schon dagegen, als der Lockout in der Telemetrie gerade beginnt.

Hätte die Failsafeinstellung "Flaps down" den Loop verursacht (ist eh unwahrscheinlich - aber nicht ausgeschlossen, wenn kein Tiefenruder konfiguriert ist), hätte man zuerst die Sekunde ohne Kontrolle gesehen und dann die Pilotenreaktion.
 
Ja, wenn die Stecker richtig verlötet sind geht das sicher, aber wenn da ein Wackelkontakt/schlechte Verbindung an dem SBus Stecker ist, würde das vieles erklären.

Hatte Andrew nicht seine Flächenservos auch über SBus angeschlossen?
 
FPV1

Banggood

Oben Unten