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.
 
RCLogger

FPV1

Banggood

Banggood

Oben