FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

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.

Das fällt mir sehr schwer, so den Loop und den anschließenden Lockout zu erklären. Aber die Lötstellen sind ja schnell kontrolliert, wenn jemand das für die wahrscheinliche Ursache hält.

 

[ReinhardZ]

Ja, bin gespannt was Andrew rausfindet ...

 

[Sigimann]

Wenn es ein Wackelkontakt am SBus oder Servostecker ist, dann kommt es zu unkontrollierten Servoausschlägen, aber die Funkstrecke ist nicht betroffen, die weis nichts was die Servos machen.
Dann gibt es keinen Lockout.

Das Schluss von Carbo ist eindeutig. Der Pilot reagiert bereits zu beginn des Lockouts mit einer heftigen Steuerreaktion, also schlägt das Servo vor dem Lockout out und bleibt dann stehen bis der "Lockout" vorbei ist. Eine FailSave Reaktion des Servos kommt frühstens nach 1100 ms ohne gültigen Steuerbefehl.

Für mich Eindeutig, dass die "Plötzlichen Servoausschläge" noch da sind, und sind sie hier, dann sind sie überall noch Drinn.

Sigi

 

[Michael Faupel]

Für mich Eindeutig, dass die "Plötzlichen Servoausschläge" noch da sind, und sind sie hier, dann sind sie überall noch Drinn.

Sigi[/QUOTE]

Ich würde jetzt nicht so eilig "verurteilen".

Warten wir,s wirklich ab.

Jedenfalls fliege ich jetzt schon wieder größere und schnellere Modelle mit dem System und habe ein gutes Gefühl dabei.
Meine Kurzzeit-Erfahrungen beschränken sich allerdings auf die X9E mit X6R und X8R, also eine Kombi die ja nach Carbo,s Erfahrung auch vorher eher unkritisch war.
Der G8 war mir in der Vergangenheit allerdings auch suspekt.

Gruß Michael

 

[Sigimann]

Für mich Eindeutig, dass die "Plötzlichen Servoausschläge" noch da sind, und sind sie hier, dann sind sie überall noch Drinn.

Sigi

Ich würde jetzt nicht so eilig "verurteilen".

Warten wir,s wirklich ab.

Meine Kurzzeit-Erfahrungen beschränken sich allerdings auf die X9E mit X6R und X8R, also eine Kombi die ja nach Carbo,s Erfahrung auch vorher eher unkritisch war.



Gruß Michael[/QUOTE]

Das ist auch meine Kombi, alles was ich von FrSky hab, alles X6R und X8R,(halt, noch die alte X9D).
Fliege seit Jahren mit dem LQ-Sensor von Tandango. Motormodelle mit E und V-Motor.
Lockout hatte ich nie, Bei LQ-Werte kleiner 60% (ist meine Warnschwelle) fand mal ich eine gebrochenen Antenenansch

Sigi

 

[ReinhardZ]

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.

Ich habe mir nochmal den 5102 Wert im Log angesehen. Der zählt ja die FL-Bits nach der Bionicbone Methode. Da bei Failsafe kein update der Kanaldaten erfolgt, ergibt sich keine Differenz bei den aufeinanderfolgenden Samples der Dreieckfunktion (5104) und die BB-Bits sind immer 0. Deshalb habe ich im LQBB Code folgende Zeilen drin

// wave channel is on hold during failsafe, FL-Bit is set during failsafe
  if (failsafe) {
    LostFrameCtr_V2++;
    lastFrameLosses_V2[lastFrameLossesIndex] += 1;
  }

Damit werden die FL-Bits während failsafe simuliert. Die Variable LostFrameCtr_V2 ergibt den 5102 Wert.
In dem Log von Andrew sieht man nun, dass der 5102 Wert am Ende des Telemetrie freeze von 14577 auf 14587 springt. D.h. für mich, dass während 10 SBus frames ein gesetztes Failsafe Bit erkannt wurde.
Die 100 FL-Bits, die vorangehen müssten, kann man in der V2 SW ja nicht auf dem SBus sehen. Ich frage mich, ob FrSky eventuell neue Kriterien zum Setzen des FS-Bit in der V2 SW definiert hat.

 

[Carbonator]

Damit werden die FL-Bits während failsafe simuliert. Die Variable LostFrameCtr_V2 ergibt den 5102 Wert.
In dem Log von Andrew sieht man nun, dass der 5102 Wert am Ende des Telemetrie freeze von 14577 auf 14587 springt. D.h. für mich, dass während 10 SBus frames ein gesetztes Failsafe Bit erkannt wurde.

Mag sein, ich denke eher, dass das Failsafe Bit gar nicht gesetzt wurde und die 10 LF echte LF sind. Dass nur für 1/10s Failsafe anlag ist nicht schlüssig, aber auch nicht auszuschließen - Glaubenssache.

Die 100 FL-Bits, die vorangehen müssten, kann man in der V2 SW ja nicht auf dem SBus sehen. Ich frage mich, ob FrSky eventuell neue Kriterien zum Setzen des FS-Bit in der V2 SW definiert hat.

Ich denke, dass man mindestens 97 LF Bit bei V2 bei Failsafe noch sieht, denn es werden ja nur die ersten 3 unterschlagen. Der 5101, der die SBus LF Bit zählt, kommt auf 160 (+3), was Sinn macht. Wir haben ja keine 100% Auflösung, das sieht man schön am 5100 Sensor, der von Null, die aber nicht übertragen wurde, in Dreizehnerschritten hochzählt, bis er wieder bei 100% landet (ein Wert war wohl noch nicht berechnet, als gesendet wurde).

Vermutlich ist die Failsafe Bedingung unverändert. Das kann man ja leicht ausprobieren, wenn man die Empfängernummer ändert und die Zeit vom Ausgehen der grünen LED bis Failsafe misst. Meine TX bleiben in Quarantäne und müssen 2m Abstand von V2 halten

 

[weixelgeist]

Jetzt habe ich eine Frage, ich weiß nicht, ob das hierher zu diesem Thema gehört.
Man kann ja im OpenTX auf der Modell Setup Seite die Anzahl der Kanäle auswählen, die übertragen werden. Wenn ich da z.B. 10Ch auswähle, dann werden auch am SBus nur 10 Kanäle übertragen.

Hat das Einfluss auf die Übertragungs-Geschwindigkeit bzw. auf die Qualität der Funkstrecke?

 

[stock]

Jetzt habe ich eine Frage, ich weiß nicht, ob das hierher zu diesem Thema gehört.

Eigentlich nicht

Man kann ja im OpenTX auf der Modell Setup Seite die Anzahl der Kanäle auswählen, die übertragen werden. Wenn ich da z.B. 10Ch auswähle, dann werden auch am SBus nur 10 Kanäle übertragen.

Hat das Einfluss auf die Übertragungs-Geschwindigkeit bzw. auf die Qualität der Funkstrecke?

Jein.
Qualität -> Nein
Übertragungsgeschwindigkeit wird nur unterschieden ob bis inkl. 8 Kanäle übertragen werden, oder eben bis 16 Kanäle.

Heißt es gibt keinen Unterschied in deinem Fall, ob du 10 oder 16 Kanäle überträgst.

 

[helle]

übertragen wird in 8er Gruppen
9ms pro 8 Kanal Gruppe

Der SBus hat immer 16 Kanäle

 

[Carbonator]

Der SBus hat grundsätzlich Platz für 16 Kanäle. Wieviele Kanäle tatsächlich übertragen werden, entscheidet der User.
Überträgt er nämlich nur bis zu 8 Kanäle, werden diese alle 9ms aktualisiert, überträgt er mehr als 8, werden die einzelnen Kanäle nur alle 18ms aktualisiert.

 

[Carbonator]

Heute hat ein Kollege nur durch eine schnelle Reaktion sein Modell gerettet. X9D+, LBT, RX8Rpro, V1 Firmware. Ich war überzeugt, dass es ihn nicht erwischen würde, weil sein Lost Frame Sensor kaum Verluste angezeigt hat. Also eine Kombination, die ich als unkritisch bezeichnet habe (ich bin heilfroh, dass nichts passiert ist).

Trotzdem kam es plötzlich zu einem Vollausschlag auf Tiefe, verbunden mit dem bekannten Lockout. Vorher und nachher war das Lost Frame Verhalten vorbildlich. Irgendwie erschreckend, das so zu sehen. Andererseits natürlich sehr gut, weil es einer der ganz wenigen dokumentierten Fälle von USM mit Lost Frame Sensor ist. Es waren keine Störungen oder schwache Empfangssituationen vorhanden, der Ausschlag kam aus heiterem Himmel.





Edit: Empfängertyp nachgetragen.

 

[FJH]

Freut mich für den Kollegen. Nicht missverstehen, nicht weil LO passiert ist, sondern weil er sein Modell noch hat abfangen können. Also dann doch wechseln auf ACCST v2 ??

 

[Carbonator]

Mir persönlich fällt es sehr schwer nach 7 völlig problemlosen Jahren. Und ich bin ja bei weitem nicht der Einzige, der nie ein Problem hatte. Ich sehe es erstmal sportlich und fliege mit V1 und Sensor weiter. Aber ich werde es niemandem mehr empfehlen

Im VollCFK Segler sieht es mit den Frames übrigens schlechter aus, als beim Kollegen.

 

[FJH]

Du willst damit aber nicht dein eigenes LO-Erlebnis abwarten, oder ?

 

[Carbonator]

Ich hatte nie Lockouts, warum soll ich jetzt welche bekommen? Ich glaube nicht an solche Zufälle. Ich habe nur noch nicht verstanden, was da genau passiert. Außerdem haut es mich nicht gleich vom Himmel, wenn es wirklich passiert.
Wer zum Beispiel hatte mit V1 Lockouts und kann bestätigen, dass sie mit V2 nicht mehr auftreten? Natürlich ohne dass in der Zwischenzeit das Sendemodul getauscht wurde - was ein Kollege glatt vergessen hatte zu erwähnen

 

[FJH]

Ich hatte auch selber noch keine Lockouts (jedenfalls keine bemerkt), und auch ich fliege schon seit Urzeiten seit erste Taranis X9d auf den Markt kam (in Belgien gekauft). Werde aber trotzdem nicht mehr mit der v1 ACCST fliegen. Habe natürlich auch keinen Tadango Sensor zum Mitfliegen . Nur der hilft ja offensichtlich auch nicht im Fall des Falles. Aber muss natürlich jeder für sich entscheiden.

 

[Carbonator]

Das ist ja das Seltsame. Überleg mal, wie misstrauisch wir anfangs gegenüber ACCST waren. Und wie genau damals hingeschaut wurde. Der Link war aber immer bocksteif. Und ich teste ja auch schon ein paar Jahre mit dem Sensor. Ein Lockout hätte mich alarmiert. Der Lockout oben kam ohne Ansage. Bei externen Störungen hätten doch die Frames vorher mal wackeln müssen - da war aber nichts. Schaun wir mal, wie es weitergeht ...

 

[arti]

Moment mal, es wurde doch ein Fehler in ACCST V1 nachgewiesen? Warum denkst du dass man da einfach immun dagegen sein soll? Selbst wenn du Jahre ohne Probleme damit unterwegs warst kann es morgen ausfallen. Schließlich gibt es einen kritischen Bug im Protokoll.

Ich fliege übrigens wieder mit meiner Xlite Pro mit ACCST V2.1 auch Helis in 700er Größe. Genau der Sender womit ich letzten Herbst 2 700er Helis gecrasht habe.
Bisher habe ich in Summe etwa die doppelte Flugzeit mit diesem Sender runter wie im Herbst, alles ohne jegliche Auffälligkeiten.

 

[Carbonator]

Wieviele Stunden etwa?