FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

@FJH Du bist schon eine coole Socke Hier streitest du mit mir und international stimmst du mir indirekt zu.

Wir bräuchten viel mehr Menschen mit soviel @rsch in der Hose und persönlicher Ausgewogenheit. @QuadCrash habe ich übrigens auch in Verdacht, so einer zu sein

Danke dafür!

 

[wezskindiver]

Na gut dann fange ich mal an!!

Ich lese nun schon seit geraumer Zeit hier interessiert mit und bewundere die teilweise doch sehr detaillierten Messungen und den Aufwand, den einige hier treiben.

Zuerst vielleicht die dumme Frage, in der Überschrift wird die Horus erwähnt, in wie weit ist davon auch meine X9D+ betroffen, laut den Engel Forum betrifft der Fehler alle Sender Modelle

Aus meine Sicht wird der Thread immer technischer und geht immer mehr in die Tiefe mit Timing Fragen, Lost frames usw, gut ich bin ET Ing, da kann ich mir schon vieles erklären, aber ob der unbedarfte Laie hier noch mitkommt ...

Zum Update, das gehen die Meinungen weit auseinander, selbst im Engel Forum wird darüber kontrovers diskutiert, als ehemaliger IT-ler kenne ich auch " Verschlimm-Besserungen ", selbst Firmen wie MicroSoft und andere bleiben davon nicht verschont. Und aus dieser Erfahrung favorisiere ich eigentlich ..never change a runnig system .., anderseits habe ich auf meinem PC auch W10 mit allen Updates und nicht mehr W98.

Als Umsteiger von Futaba bin ich doch jetzt etwas verunsichert, ob das der richtige Schritt war, klar die Taranis ist ein toller Sender zu akzeptablen Preisen, wenn ich sehe, was Futaba für Preise bei Telemetrie hat und die Möglichkeiten, die OpenTX bietet, wirklich toll, aber ich muss auch das Gefühl der Sicherheit haben, wenn ich meinen Flieger in die Luft bringe und nach all den Beiträgen hier und in anderen Foren geht mir die doch etwas verloren.

Und wenn ich dann lese, das nach dem sogenannten Sicherheits Update diverse Sender nicht mehr richtig funktionieren, Empfänger nicht mehr gebunden werden können und das die Reichweite nicht mehr da ist ( das Engel Forum ist voll von solchen Berichten ). Ich werde jedenfalls diesen Thread, aber auch die bei Engel oder die bei RCG weiterhin aufmerksam verfolgen, werde aber in Hinsicht eines Updates die Füsse still halten und abwarten.
Allerdings möchte ich den Haupt Akteuren der Beiträge hier ausdrücklich für ihre Mühe danken, sonst hätte vielleicht FrSky auch nie etwas unternommen, Jungs macht weiter so, denkt aber auch an die Nicht-Techniker, die vielleicht auch verstehen wollen, worum es geht
Ansonsten alle ein schönes WE, heute Nachmittag soll bei uns das Wetter besser werden, dann gehe ich wieder raus zu fliegen

LG
Klaus

 

[QuadCrash]

Die entscheidende Frage ist: Warum wurde dies eingeführt? Hier wird es interessant.

Ich vermute mal etwas ganz simples, hier hat halt niemand über die nachfolgenden Konsequenzen, also bspw. Probleme bei Betaflight, nachgedacht. Und, die Leute, die getestet haben, sind allesamt "manuelle" Flieger, sprich mit FC & Co. kennt sich da niemand aus.

@QuadCrash habe ich übrigens auch in Verdacht, so einer zu sein

Danke für das Lob, ich bin aber nur einfacher Anwender, der sich nur auf SBUS und andere Protokolle bei der Fliegerei verlässt und daher vielleicht hier & da etwas mehr Einblick hat.

 

[Michael Faupel]

Nach den Zugriffszahlen wird dieser Thread oft gelesen, aber es kommen leider wenig Beiträge. Ich möchte ausdrücklich ermuntern, Fragen zu stellen. Wenn jemand Angst hat, sich bloßzustellen, gerne auch per PN. Wobei es keine dummen Fragen gibt. Nur dumme Erklärungen.

Da im Händlerforum gerade wieder Nebelkerzen kombiniert mit wahnsinnig kompetent aussehenden Messungen geworfen werden, hier mal ein paar Bemerkungen zur PWM Ausgabe am Empfänger:

1. Fall 8-Kanal Empfänger mit 18ms PWM Framezeit (Standard), Sender sendet nur 8 Kanäle (9ms Anzeige)
- "über die Luft" Frame 1-8 kommt an
- ist gültig aber die 18ms sind noch nicht um
- "über die Luft" Frame 1-8 kommt an
- ist es ebenfalls gültig wird dieses Frame ausgewertet und die PWM Pulse ausgegeben
- ist es ungültig, wird das vorherige ausgeben
2. Fall 8-Kanal Empfänger mit 18ms PWM Framezeit (Standard), Sender sendet 16 Kanäle (18ms Anzeige)
- "über die Luft" Frame 1-8 kommt an
- ist es gültig wird es an 1-8 ausgegeben
- ist es ungültig, wird das vorherige an 1-8 ausgeben
- "über die Luft" Frame 9-16 kommt an
- das wird nicht gebraucht -> an der Stelle sollte man erkennen, wozu die Kanalzahl im Sender wichtig ist
3. Fall 8-Kanal Empfänger mit 9ms PWM Framezeit (HSModus) Sender sendet 8 Kanäle
- "über die Luft" Frame 1-8 kommt an
- ist es gültig, wird es ausgegeben
- ist es ungültig, wird das vorherige nochmal ausgegeben
4. Fall 8 Kanal Empfänger mit 9ms PWM Framezeit (HSModus) Sender sendet 16 Kanäle
- bitte selbst ausfüllen

Alles eigentlich ganz simpel und "furchtbar" logisch. Auf Wunsch mache ich gerne weitere Beispiele. So eine Übertragung ist übrigens auch für professionelle Zwecke geeignet.

Hallo Carbo,

Ist also so das für 1-8 und 9-16 je nach Bindung zwei verschiedene Frames zuständig sind und somit sicherheitsrelevante Doppelruder auf eine Framegruppe gelegt werden sollten!

Habe diese Frage auch im Frsky Forum gestellt, finde das aber auch für andere User wichtig.

Gruß Michael

 

[QuadCrash]

Und wenn ich dann lese, das nach dem sogenannten Sicherheits Update diverse Sender nicht mehr richtig funktionieren, Empfänger nicht mehr gebunden werden können und das die Reichweite nicht mehr da ist ( das Engel Forum ist voll von solchen Berichten ).

Mal grundsätzlich zu Foren-Diskussionen, egal zu welchem Thema: Probleme werden immer deutlich mehr diskutiert, als wenn alles perfekt läuft. Das muss man nur entsprechend gewichten.

 

[FJH]

@FJH Hier streitest du mit mir und international stimmst du mir indirekt zu.

Den gelinkten Punkt habe ich aber auch hier doch nie bestritten. Du könntest als Ergänzung noch deine Kurven dazu liefern, sowas ist einleuchtender als eine nur verbale Beschreibung. Habe das auch mal angedacht, es dann aber gelassen. Das solltest du besser selber tun, kann mir vorstellen, dass dazu dann auch Fragen kommen.

 

[Gruni]

Wie gesagt, mein Traum ist immer noch ein MPM welches Jeti, M-Link, Hott komplett in das OTX einbinden könnte.
Dann würde sich die ganze fakerei in nullkommanix auflösen.
Die OTX-Hardware könnte weiter verwendet werden, die angegebenen Hersteller bieten SBus, also könnten, bis auf Kleinzeug die FCs in den Coptern weiter genutzt werden.
Dann kann/muss FrSky nur noch in die "richtige", nämlich Sourceopen-Richtung agieren und es gäbe nur noch Gewinner.

Vielleicht etabliert sich dann sogar mal ein universell kompatibles Protokoll, quasi wie in "guten" alten 35/40MHz Zeiten.

Grüsse Gruni

 

[Carbonator]

Den gelinkten Punkt habe ich aber auch hier doch nie bestritten. Du könntest als Ergänzung noch deine Kurven dazu liefern, sowas ist einleuchtender als eine nur verbale Beschreibung. Habe das auch mal angedacht, es dann aber gelassen. Das solltest du besser selber tun, kann mir vorstellen, dass dazu dann auch Fragen kommen.

Verlink doch auf den openrc Thread. Der ist jetzt einigermaßen ausgewogen, seit ich den polnischen Premierendealer geoutet habe janekx ist übrigens sein tchechischer Kollege. Wenn jemand RCJohn identifiziert, spendiere ich einen LostFrame Sensor Dort habe ich ein paar Infos zusammengetragen. Ich habe keine große Lust mit mpfj01 zu diskutieren, ich versuche schon 5 Jahre erfolglos, ihm und Webb den RSSI zu erklären.

 

[Carbonator]

Ist also so das für 1-8 und 9-16 je nach Bindung zwei verschiedene Frames zuständig sind und somit sicherheitsrelevante Doppelruder auf eine Framegruppe gelegt werden sollten!

Technisch gesehen auf jeden Fall. Wie oft sich das wirklich in der Praxis auswirkt, weiß ich nicht. Aber es schadet definitiv nicht.

 

[Carbonator]

Als Umsteiger von Futaba bin ich doch jetzt etwas verunsichert, ob das der richtige Schritt war, klar die Taranis ist ein toller Sender zu akzeptablen Preisen, wenn ich sehe, was Futaba für Preise bei Telemetrie hat und die Möglichkeiten, die OpenTX bietet, wirklich toll, aber ich muss auch das Gefühl der Sicherheit haben, wenn ich meinen Flieger in die Luft bringe und nach all den Beiträgen hier und in anderen Foren geht mir die doch etwas verloren.

OpenTX mit FrSky ist für technisch Begeisterte immer noch eine gute Wahl. Mit der X9D+ hast du nach meiner Erfahrung nicht viel zu befürchten. Der Fehler tritt ja generell nur äußerst selten auf. FrSky nutzt die Sache hauptsächlich, um die Konkurrenz auszubooten. Erreicht damit aber auch große Verunsicherung bei den eigenen Leuten.
Vorschlag: Bestell dir einen Arduino nano, einen 2N7000 Transistor und einen 10k Widerstand, dann baust du dir einen LostFrame Sensor und machst 10 Flüge. Dann weißt du, ob du betroffen bist oder nicht.

 

[FJH]

Die beiden sind jedenfalls immer sehr engagiert und mpf01 durchweg FrSky positiv eingestellt. Habe also mal den Link ergänzt, mal schauen, ob jemand dem nachgeht.

 

[FJH]

@wezskindiver .... und fliege mit FCC ....

 

[quax2011]

Hallo zusammen, ich bin ja offenbar einer (aber ich denke nicht der einzige ) der Horus (X12S) Nutzer die zumindest von der Framelost Problematik betroffenen ist. Ich will hier aber noch mal ganz deutlich sagen dass ich im Flugverhalten (ausschließlich E angetriebene Flächenmodelle) bisher nichts bemerkt habe bezüglich unerklärlichen Ausschlägen. Auch hier Betonung auf "nichts bemerkt" habe. Dazu kommt noch dass ich bei keinem meiner Modelle Failsave programmiert hab. Einen Verbindungsverlust von 0,9 sek. würde ich deshalb wahrscheinlich nicht bemerken. Gleichwohl hatte ich in den Logs zweimal - mit dem Frameloss Sensor gemessen - Einbrüche bis unter 10% gültige Frames. An der Stelle auch nochmal mein Dank an Bernd mit dem ich in engem Kontakt stehe. Im Moment werde ich weiter Informationen sammeln mit der alten Firmware und dann ein Modell und den Sender umstellen und weiter Daten sammel. Ob ich dann bei der neuen Firmware bleibe oder zurückgehe werde ich danach entscheiden. Das ganze kann allerdings noch ein paar Wochen dauern
Jürgen

 

[nihonski]

Ein konstruktiver Beitrag wäre, unbenützte SBUS bits als zusätzlichen Status zu verwenden.
Korrekt wäre, daß jeder Frame seinen eigen Status hätte.
Leicht einzuführen und rückwärtskompatibel.

 

[Carbonator]

Das ist nicht nötig. Ein Frame kommt over the air und er ist entweder gültig oder nicht. Entweder wird er ausgegeben (PWM und SBus) oder der vorherige Frame wird ausgegeben (PWM und SBus). Ein SBus Frame wird doch nicht ungültig, wenn ein LostFrame auftritt. Der letzte over the air Frame wird halt nicht in den SBus Frame eingebaut, sondern es bleiben die vorherigen Kanalwerte gültig - was soll denn auch sonst passieren? Willst du die vor-vorherigen einbauen?

Du überkomplizierst die Sache. Schildere doch bitte mal genau einen Ablauf, bei dem deine Theorie Sinn macht. Oder gib mir eine bestimmte over the air Framereihenfolge vor (gültig/ungültig), dann schreiben wir beide auf, was unserer Meinung nach passiert.

 

[wezskindiver]

@wezskindiver .... und fliege mit FCC ....

Tja würde ich gern, aber zu spät, ist halt schon LBT drauf und lässt sich " angeblich oder doch nicht " nicht mehr umflashen

 

[wezskindiver]

Mal grundsätzlich zu Foren-Diskussionen, egal zu welchem Thema: Probleme werden immer deutlich mehr diskutiert, als wenn alles perfekt läuft. Das muss man nur entsprechend gewichten.

klar hast Recht, kaum einer schreibt ... bei mir ist alles toll ... usw, aber die Menge der Beiträge über Problem verunsichert und nicht bei allen liegt das Problem " zwischen den Ohren "
das mit dem Lost Frame Tracker werde ich mal machen, so eine Arduino Board habe ich sogar noch rumliegen

 

[Carbonator]

Tja würde ich gern, aber zu spät, ist halt schon LBT drauf und lässt sich " angeblich oder doch nicht " nicht mehr umflashen

Es ist noch nicht sicher, warum LBT stärker betroffen ist, aber LBT funktioniert grundsätzlich. Mach dir keinen Stress wegen LBT. Wenn du keine Lockouts siehst, dann kannst du absolut beruhigt fliegen, auch mit LBT. LBT ist nur kritischer in Verbindung mit Lockouts und die gibt es, nach meiner Überzeugung, nur mit den neueren Sendern ab QX7 in wenigen Fällen, nicht in allen!

 

[arti]

Mit der X9D+ hast du nach meiner Erfahrung nicht viel zu befürchten. Der Fehler tritt ja generell nur äußerst selten auf.

Ich weiß du vertrittst diese Ansicht weil du selber keine Auffälligkeiten an deiner Hardware feststellen konntest. Das ändert aber nichts daran dass bei D16 V1 die Möglichkeit für Servoausschläge und Lockouts besteht. Eine Empfehlung die neue D16 V2 Firmware zu ignorieren halte ich für sehr fragwürdig. Nur weil die Wahrscheinlichkeit dass man selber davon betroffen ist niedrig zu sein scheint heißt es noch lange nicht dass es sicher ist.

Ja, ich hatte auch hunderte Flüge ohne Auffälligkeiten mit der X9D+. Aber ich werde garantiert nicht einen 700er Heli mit FrSky Hardware fliegen solange die Möglichkeit besteht, dass ich eine unkontrollierbare Kreissäge vor mir in der Luft habe. Das ist schon nicht mehr nur unverantwortlich sondern schon grob fahrlässig.

 

[Carbonator]

@arti Deinen Standpunkt kann ich nachvollziehen. Ich garantiere auch niemandem, dass bei seiner Anlage niemals ein Fehler auftritt. Ich arbeite mit meinen eigenen Erfahrungen und Messmethoden. Wie du siehst, habe ich "nach meiner Überzeugung" dazugeschrieben.

Hast du die V2.0.1 schon intensiv getestet? Kannst du Freigabe erteilen? Wenn ja, für welche Kombinationen?