FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[arti]

Einen ungesteuerten Fehlimpuls hatte ich so gesehen noch nicht zu verzeichnen. Die Servos werden beim Heli ja über die Regelkreise im FBL angesteuert. Der Empfänger gibt ja nur Drehraten für das FBL vor und einzelne Frames merkt man bei dieser Art von Tiefpass bestimmt nicht.
Mein Problem waren die hier erwähnten Lockouts. Selbst bei den einfachsten 3D Manövern mit dem Heli bist du ruck zuck im Acker wenn du 1s lang keine Kontrolle mehr hast.
Deswegen wäre die Redundanz eine schöne Option die FrSky einem anbietet. Vorausgesetzt der Master leitet das Slavesignal weiter auch wenn er aussteigt.

 

[Norbert]

Ein Abfangen/Verhindern des kurzen ungesteuerten Fehl-Impulses eines Servos kann m.E. weder durch eine RB noch durch eine Master/Slave-Empfängerschaltung realisiert werden. Damit das funktionieren sollte, müsste ja die RB oder der Master-Empfänger erkennen, dass der veranlasste Impuls ein Fehler ist und entsprechend unterdrückt bzw. durch korrekten Datenframe ersetzt gesteuert werden. Würde mich also sehr wundern, wenn dem so wäre. Failsafe verhindern können/sollten dagegen beide Varianten.

Übrigens alle FrSky RBs arbeiten nach demselben Prinzip. Umschaltkriterium für SBus-Signal von Empfänger 1 nach Empfänger 2 ist einzig eine Failsafe-Auslösung bei Empfänger 1. Das von der RB zu verwertende SBus-Signal kommt also komplett entweder von RX1 oder nach Failsafe von RX1 dann von RX2.

Tja, genau darum geht es. Der RB-10 wartet nicht erst einen Failsave ab, dazu schaltet er zu schnell um ( ~0,3 sec ) schaltet aber auch nicht bei jedem falschen Frame um, wie auch schon behauptet. Daher der Test.
Wenn er erst beim Failsave umschaltet ist sowieso alles zu spät. Denn kurz danach ist alles ja wieder ok.

Aber das wird sich die nächsten Tages ja zeigen, ob der RB-10 fasche Signale, egal ob freeze oder Ausschlag verhindern kann.

Norbert

 

[FJH]

Meine Info zum Umschaltkriterium stammt von FrSky selber, Stand 22. Okt 2019.

Hier meine Frage ;

May I kindly ask you for clarification with your technicans about what are the RB10 criteria for switching from one Rx to other Rx.

Und hier die Antwort darauf:

Yes, all FrSky RBs work base on the same theory.
If the RX1 enter the failsafe/ frozen, the signal will switch to the RX2, and the RX1 does not send the constant signal to RB at this moment.

Ergänzung : Habe zum Umschaltkriterium nochmal in alten Forenbeiträgen recherchiert und muss sagen, dass man aus einigen Beiträgen und verschiedenen Tests durchaus einen Framevergleich beider Quellen ableiten kann und darauf basierend einen Ersatz des ungültigen Frames durch einen gültigen des anderen Empfängers. Wenn dem dann so ist, dann hat mein Kontakt bei FrSky möglicherweise nicht den letzten Stand mitbekommen. Leider gibt es dazu kein (mir bekanntes) offizielles Statement seitens FrSky.

 

[nihonski]

Wie Carbonator schon sagte, bringt ein Redundanzempfänger keine zuverlässige Sicherheit, da er im Fehlerfall den Slave-Empfänger blockiert.

Im Fall RB10/20 oder anderen SBUS Brücken:
Im CRC-Fehlerfall erlauben die SBUS Flags keine zuverlässigen Rückschlüsse, ob fehlerhafte Daten vorliegen oder nicht. Aber diese Flags braucht eine SBUS-Brücke um zu entscheiden, welcher Empfänger-Zweig echte Daten liefert. Die Flags scheinen mit einer höheren Wahrscheinlichkeit richtig zu liegen als daneben, aber das ist alles. Der Aufwand rentiert sich nicht, nur um die Wahrscheinlichkeit unseres CRC-Fehlers zu verringern, nachweislich kann ich sie damit nicht 100% verhindern. Natürlich, wenn man eine SBUS-Brücke aus anderen Gründen schon drin hat, kann man das so lassen.

Anbei ein XM+ Log:
Trace5: SBUS Roh-Daten direkt am Empfänger
Trace6: Error Trigger, in diesem Fall 4mal => 4 Frames sind fehlerhaft
Trace7: SBUS Daten dekodiert, in diesem Fall ist Servo Kanal 13 fehlerhaft (Werte 6, 2 anstatt 3, 224)

Das Vorletzte Byte der SBUS-Rohdaten (Trace5) enthält die Flags FL und FS:
0x0C => FL und FS ist gesetzt
0x04 => FL ist gesetzt
0x00 => Daten fehlerfrei
Wie man beim 4. Error-Trigger (Trace6) erkennt, ist Kanal 13 (Trace7, Wert 2, 6) fehlerhaft, obwohl die SBUS Flags null sind, 0x00 (Trace 5, vorletztes Byte).
Wenn also wie in diesem Beispiel die SBUS-Brücke die SBUS Daten des XM+ übernimmt, weil gerade der andere Empfänger einen Frameloss hat, dann würde das Servo am Kanal 13 falsche Werte erhalten.
In diesem Fall nur kurz, aber wenn,s dumm geht 0,9s lang.

 

[nihonski]

Als noch unklar war, ob und wie schnell Frsky darauf reagiert, hatte ich mir mögliche work-arounds überlegt.
Aus meiner Sicht geht es nur mit selbst-programmierten SBUS-Brücken:

1) Brücke für 3 Empfänger, 3 Eingänge. Entscheidung nach dem Mehrheitsprinzip.
Es wäre extrem unwahrscheinlich, daß der Fehler bei 2 oder 3 Empfängern gleichzeitig auftritt.

2) Brücke für 1 oder 2 Empfänger, das SBUS Signal wird auf extreme Sprünge analysiert.
Man sieht an den Logs, daß der Fehler immer einen extremen Sprung macht, ohne Zwischen-Werte.
So schnell kann niemand steuern. Wenn ein plötzlicher Sprung eines Servo-Wertes in einem Empfängerzweig erkannt wird, dann liegt hier eher der Fehler vor, als im anderen Zweig mit geringerer Veränderung.

Da wir dieses Jahr noch die offizielle FW erhalten sollen, erspar ich mir den Aufwand, obwohl die Umsetzung von 2) schon einen gewissen Reiz hätte, auch ohne den CRC-Fehler.
Quasi eine Erkennung von nicht-plausiblen Steuerbefehlen. Natürlich nur für die Sticks, nicht für Schaltkanäle.

 

[Carbonator]

Jetzt warten wir mal ab, wie FrSky diese Geschichte den Usern verkaufen will. Mit "improve the performance" kommen sie diesmal definitiv nicht durch. Da muss schon ein bisschen Prosa dazukommen. Vorzugsweise mit der Rechtsabteilung abgestimmt Und dann bin ich mal auf die Reaktion der Cracks bei RCG gespannt.

 

[arti]

Sorry für die Frage falls das bereits klar ist, aber zeigt der Empfänger keinen Failsafe/Frameloss wenn es einen Lockout gibt und hält einfach die letzten Werte? Vielleicht noch in Verbindung mit Falschausschlägen?
Dann wäre hier Redundanz natürlich komplett Sinnfrei als Lösungssansatz, außer mit einer externen SBUS Brücke wie Ewald sie beschreibt.
Bei beiden Crashes hat das (baugleiche) FBL nämlich keinen Failsafe geloggt. Bis jetzt dachte ich es liegt an dem internen Failsafehandling des FBLs. Es wurden nur die letzten Werte für 1s+ gehalten. Beim ersten Crash ging noch der Pitchkanal auf komplett negativ. Beim zweiten Crash gab es keine Fehlausschläge auf den 4 Steuerachsen+Throttle, dafür wurde im Nachgang ein Failsafe im FBL geloggt. Da lag der Heli aber schon im Rapsfeld und hatte womöglich wirklich schlechten Empfang.

Ein 700er Heli verwandelt sich mit diesem Problem in eine unkontrollierbare fliegende Kreissäge. Sowas will man nicht in seiner Nähe haben. Ein Wechsel von FrSky weg ist für mich trotzdem keine Option. Also stell ich zurück zur alten X9D mit FCC.

 

[Carbonator]

Mein zweiter Empfänger, der XM+, der auch neben dem Lockout den falschen Kanalwert produziert, der wartet noch auf sein Update.

Nicht nur deiner Wenn du BF mal auf LQ Anzeige upgedatet hättest, wie vorgeschlagen, wären wir vielleicht schon ein Stück weiter.

 

[GerdS]

Du kennst doch den Spruch, "never change a running system". Ich werde den Teufel tun und auf BF4.x updaten. Der Vogel fliegt und BF rettet ihn derweil vor dem Crash aufgrund von Lockout und falschen Kanalwerten.

Gruß Gerd

 

[RayX]

Sorry für die Frage falls das bereits klar ist, aber zeigt der Empfänger keinen Failsafe/Frameloss wenn es einen Lockout gibt und hält einfach die letzten Werte? Vielleicht noch in Verbindung mit Falschausschlägen?
Dann wäre hier Redundanz natürlich komplett Sinnfrei als Lösungssansatz, außer mit einer externen SBUS Brücke wie Ewald sie beschreibt.
Bei beiden Crashes hat das (baugleiche) FBL nämlich keinen Failsafe geloggt. Bis jetzt dachte ich es liegt an dem internen Failsafehandling des FBLs. Es wurden nur die letzten Werte für 1s+ gehalten. Beim ersten Crash ging noch der Pitchkanal auf komplett negativ. Beim zweiten Crash gab es keine Fehlausschläge auf den 4 Steuerachsen+Throttle, dafür wurde im Nachgang ein Failsafe im FBL geloggt. Da lag der Heli aber schon im Rapsfeld und hatte womöglich wirklich schlechten Empfang.

Ein 700er Heli verwandelt sich mit diesem Problem in eine unkontrollierbare fliegende Kreissäge. Sowas will man nicht in seiner Nähe haben. Ein Wechsel von FrSky weg ist für mich trotzdem keine Option. Also stell ich zurück zur alten X9D mit FCC.

Die x9d mit FCC ist aber von dem Problem nicht ausgeschlossen, es passiert nur seltener. Eigene Erfahrung

 

[Carbonator]

Deine ist eine der ganz wenigen die betroffen sind, das hatte ich ja schon erwähnt. Da aber genau deine im engeren Kreis um Ewald gelandet ist, hat das vermutlich dazu geführt, dass man den Fokus auf alle Sender erweitert hat.

Wenn man die Auflistung bei Engel anschaut, spricht dies eine deutliche Sprache. Ebenso die Tatsache, dass der Bug bis 2017 überhaupt nicht aufgetaucht ist. Bei arti war die X9D offensichtlich auch unproblematisch, genau wie bei tausenden anderen X9D/E Usern.

Meine Hypothese ist, dass das Problem ursächlich durch Frequenzdrift des Senders hervorgerufen wird. Wer 2,5GHz messen/zählen kann und die Probleme hat, sollte einfach mal die Bindefrequenz messen.

 

[Michael Faupel]

Die x9d mit FCC ist aber von dem Problem nicht ausgeschlossen, es passiert nur seltener. Eigene Erfahrung

Alleine das zu wissen macht doch einen gewissenhaften Betrieb mit dem Frsky System nicht möglich. Bei einfachen Seglern und Styropormodellen mach das noch vertretbar sein, bei Motormodelle, evtl sogar Großmodellen und Hubschraubern verbietet es sich doch ein solches System einzusetzen; Selten ist einfach zu oft wen man weiß das Fehler vorkommen . Da sind einfach nur die sichersten RC Systeme gerade gut genug.

Stellt euch doch mal vor das Modell kommt außer Kontrolle und fliegt einem Menschen an den Kopf, in eine Windschutzscheibe eines fahrenden Autos oder sonst was ......

Das ist das was ich gestern beschrieben habe ,es kommt bestimmt auch bei den anderen Sendern und RX Kombinationen vor.

Carbo, du vertrittst ja die Meinung das es bei den anderen Sendern und Co praktisch nicht vorkommt....Man, man, man.....das kann man doch nicht mehr "leugnen"!
Ich meine explizit nicht defekte Anlagen sondern Ausfälle aufgrund unzureichender Software und Sicherheitsmechanismen sowie ungenügenden Schaltungsaufbau!

Gruß Michael

 

[Carbonator]

Carbo, du vertrittst ja die Meinung das es bei den anderen Sendern und Co praktisch nicht vorkommt....Man, man, man.....das kann man doch nicht mehr "leugnen"!
Ich meine explizit nicht defekte Anlagen sondern Ausfälle aufgrund unzureichender Software und Sicherheitsmechanismen sowie ungenügenden Schaltungsaufbau!

Sorry, aber das ist Bullshit. Ich bin 100% sicher, dass meine Sender seit mehreren Jahren ohne einen einzigen Glitch funktioniert haben. Jedes technische Gerät kann natürlich ausfallen oder sich verändern, altern, jede Firmware hat Fehler. Damit verdiene ich sogar meine Brötchen. Es gibt aber definitiv kein statistisch signifikantes Problem mit den "alten" Sendern. Das heißt logischerweise nicht, dass "alte" Sender nie Probleme machen können.

Der Bug ist mit den neuen Sendern bzw. - Achtung schwierige Formulierung - mit der Alterung der neuen Sender bzw. Sendemodule aufgetaucht, da bin ich ziemlich sicher.

Edit: Eventuell könnte er mit einer manuellen Nachstimmung der Sendefrequenz wie beim Multimodul ganz elegant und technisch sauber beseitigt werden. Aber erklär sowas mal den Ogottogotts, die gerade massig Likes verteilen, weil ein geschlossener Bereich im Engel-Forum ohne jeglichen Inhalt geschaffen wurde

 

[nihonski]

Wer sicherheitsrelevante Updates wissentlich ignoriert, ist ein gefundenes Fressen für die Versicherungsanwälte, wenn es darauf ankommt.

 

[Carbonator]

Ist es nicht Sache des Herstellers/Händlers in so einem sicherheitsrelevanten Fall einen für den Kunden kostenlosen Rückruf durchzuführen? Uffbasse ....

 

[bendh]

das mit der Frequenz könnte auch mein Bindeproblem erklären:
https://frsky-forum.de/thread/2637-rx6r-problem-beim-binden/
Waren 3 QX7 und nur beim alten hat es funktioniert.
Nachdem der Empfänger umgetauscht wurde, in einen aus einer neuen Lieferung, geht es mit allen 3en.

 

[nihonski]

Der Hersteller ist zunächst einmal weit weg. Zuerst geht es um den Geschädigten, wer den Schaden verursacht hat, und wer am längeren Hebel sitzt. Ist nur ein Hinweis auf die Praxis, keine Rechtsprechung.

 

[RayX]

Ebenso die Tatsache, dass der Bug bis 2017 überhaupt nicht aufgetaucht ist.

Das hängt vermutlich mit der neuesten LBT XJT Firmware zusammen, die kam glaube ich Anfang 2018 raus., denn mit zurü ck flashen auf die Vorgänger Version ist bei meiner X9d das / die Probleme wieder verschwunden, hatte ich aber auch schon mal erwähnt.

 

[FJH]

Das hängt vermutlich mit der neuesten LBT XJT Firmware zusammen, die kam glaube ich Anfang 2018 raus., denn mit zurü ck flashen auf die Vorgänger Version ist bei meiner X9d das / die Probleme wieder verschwunden, hatte ich aber auch schon mal erwähnt.

Die letzte und damit aktuelle Firmware für das XJT-Modul ist die Version 170317 und die ist auch erforderlich, wenn man gewisse Funktionen in OTx nutzen will oder sogar braucht.

 

[nihonski]

Hallo Ray, das entspricht nicht meinen Tests verschiedener FWs.
Es gab einen Hinweis, daß ein Update nur für ein bestimmtes Fertigungslos gedacht war.
Vielleicht würde das deine Erfahrung erklären.