FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Die relevanten Fakten sind:
X7S und Xlite, also "neue" Sender
R-XSR und XM+ zeigten in BF schlechte Linkqualität, was verlorene Frames bedeutet
3 R-XSR zeigen mit der neuen Firmware gute LQ in BF, also keine Framelosses mehr
Er hofft, dass FrSky keinen Trick in die Firmware eingebaut hat und einfach nur das letzte "gute" Frame wiederholt
Die XM+ zeigen schlechte Linkqualität und die LED stottert, wie bei den R-XSR vor dem Update
Edit: Relevant aus dem gesamten Thread ist die Info, dass der Fehler mit LBT und FCC gleichermaßen auftritt
X7S und Xlite, also "neue" Sender
R-XSR und XM+ zeigten in BF schlechte Linkqualität, was verlorene Frames bedeutet
3 R-XSR zeigen mit der neuen Firmware gute LQ in BF, also keine Framelosses mehr
Er hofft, dass FrSky keinen Trick in die Firmware eingebaut hat und einfach nur das letzte "gute" Frame wiederholt
Die XM+ zeigen schlechte Linkqualität und die LED stottert, wie bei den R-XSR vor dem Update
Edit: Relevant aus dem gesamten Thread ist die Info, dass der Fehler mit LBT und FCC gleichermaßen auftritt
Zuletzt bearbeitet:
OK, das hatte ich interpretiert aber war mir nicht sicher.
Danke euch beiden!
Es stand ja auch das die Telemetrie beim R-xsr abgeschaltet war weil es die OSD Verbindung auf 5,..GHZ. gestört hat. Meines Wissens sollte das ja eigentlich ausgeschlossen sein.
Gruß Michael
P.S. ich Frage mich was FrSky geritten hat sich eine eigene Verschlüsselung einfallen zu lassen, abhängig von den Chipherstellern ist Frsky doch sowieso!
Fragen über Fragen.........
Danke euch beiden!
Es stand ja auch das die Telemetrie beim R-xsr abgeschaltet war weil es die OSD Verbindung auf 5,..GHZ. gestört hat. Meines Wissens sollte das ja eigentlich ausgeschlossen sein.
Gruß Michael
P.S. ich Frage mich was FrSky geritten hat sich eine eigene Verschlüsselung einfallen zu lassen, abhängig von den Chipherstellern ist Frsky doch sowieso!
Fragen über Fragen.........
Zuletzt bearbeitet:
Wenn man zwischen den Zeilen lesen kann, schimmert so langsam durch, dass der Engel-Bug mit problematischen Sendemodulen verstärkt auftritt. Meine Behauptung ist ja, dass er mit einwandfreien Sendemodulen überhaupt nicht auftritt, aber das ist natürlich subjektiv. Objektiv kann ich nur sagen, dass er mit meinen Sendemodulen überhaupt nicht auftritt.
Jetzt müsste ein helles Forenmitglied mal nachfragen, wie es eigentlich mit den problematischen Sendemodulen weitergeht, wenn die Auswirkungen mit einer neuen Firmware kaschiert werden? Merkt man dann nur noch bei Totalausfall, dass etwas im Busch war?
Jetzt müsste ein helles Forenmitglied mal nachfragen, wie es eigentlich mit den problematischen Sendemodulen weitergeht, wenn die Auswirkungen mit einer neuen Firmware kaschiert werden? Merkt man dann nur noch bei Totalausfall, dass etwas im Busch war?
Unten Kopie aus dem FrSky Forum, Info-Bereich.
Die Darstellung ist allgemeinverständlich gehalten, das heißt aber nicht, daß im Detail nicht klar wäre, was genau passiert.
Was passiert in der Praxis?
A.) Sollte der Fehler auftreten (typisch 2-4 fehlerhafte Frames), so äußert es sich meistens in einem kurzen „Servo-Zucken“ ohne dass eine merkliche Servobewegung entsteht. 2 Frames dauern 18ms, das ist zu kurz für einen merklichen Servoausschlag. Das ist kaum sichtbar, nur hörbar. Meistens betrifft es nur einen der 16 Servo-Kanäle, selten zwei.
B.) In seltenen Fällen unter A ) ist nicht nur ein Servo-Wert fehlerhaft, sondern es kommt zu einer kurzen Störung im Ablauf des Empfängerprogramms. Wahrscheinlich deshalb, weil außer oder zusätzlich zu einem Servowert auch irgendwelche programm-relevante Kontrollbits fehlerhaft übertragen wurden. Dies dauerte bei allen Tests bisher immer 0.9 Sekunden, bis sich der Empfänger „fängt“ und wieder neu auf den Sender synchronisiert. Innerhalb dieser 0.9 Sekunden sind dann alle Servowerte auf den letzten Stand eingefroren.
Leider ist es dann so, dass meistens auch ein fehlerhafter Servowert für 0.9s auf irgendeinem der 16 Servokanäle eingefroren anliegt. Ist an diesem Kanal ein Servo angeschlossen so kommt es zu einem deutlichen, unkontrollierten Servoausschlag. 0,9s reichen auch für langsame Servos aus, um voll zu positionieren. Ist in diesem Fall einer der 16 Servokanäle fehlerhaft, welcher nicht verwendet wird, so ist das Modell zwar für 0.9s nicht steuerbar, aber ein Servoausschlag ist nicht festzustellen.
Das gleiche gilt, wenn nur Kontrollbits aber keine Servowerte fehlerhaft sind.
Im Vergleich zu dem kurzen „Servo-Zucken“ tritt dieser Fall wesentlich seltener auf und betraf bisher nur wenige Piloten im EU (LBT) Bereich. Der statistische Unterschied zwischen A.) und B.) gründet einfach darauf, dass wesentlich mehr Servodaten als Kontrollbits vom Sender zum Empfänger übertragen werden.
Die Hauptursache ist die sogenannte „Fehlererkennung/Verschlüsselung“ in der Firmware. Diese wurde von FrSky selbst entwickelt um von den Chipherstellern unabhängig zu bleiben. Denn diese stellen auch eine Fehlererkennung/Verschlüsselung bereit. Diese selbst entwickelte Fehlererkennung/Verschlüsselung muss über Jahre gut funktioniert haben. Sonst hätte FrSky nicht diesen bis dato den guten Ruf als sicheres und zuverlässiges RC-System erlangt.
In der letzten Zeit ändern sich aber zunehmend die Betriebsbedingungen durch eine deutlich höhere Auslastung des 2,4 GHz Bandes. Es besteht ein direkter, statistischer Zusammenhang zwischen Störungen und der Qualität der Funkstrecke auf dem 2.4GHz Band und der Wahrscheinlichkeit, mit welcher unser Fehler auftreten kann.
Zudem sind moderne Empfänger-Chips empfindlicher und erlauben deshalb eine größere Reichweite. Sie sind deshalb aber auch empfindlicher gegenüber kleinsten Frequenzabweichungen. Deshalb sind auch Empfänger wie der GRX-8 öfter betroffen als ältere Typen. Wenn die Streuung von Bauteilen (gibt es in der Elektronik durchaus) nun zu einem etwas unsauberen Frequenzabgleich führt und dazu noch viele Störungen im Umfeld sind, dann gibt es eine deutlich höhere Wahrscheinlichkeit dass das Problem auftritt.
Die Darstellung ist allgemeinverständlich gehalten, das heißt aber nicht, daß im Detail nicht klar wäre, was genau passiert.
Was passiert in der Praxis?
A.) Sollte der Fehler auftreten (typisch 2-4 fehlerhafte Frames), so äußert es sich meistens in einem kurzen „Servo-Zucken“ ohne dass eine merkliche Servobewegung entsteht. 2 Frames dauern 18ms, das ist zu kurz für einen merklichen Servoausschlag. Das ist kaum sichtbar, nur hörbar. Meistens betrifft es nur einen der 16 Servo-Kanäle, selten zwei.
B.) In seltenen Fällen unter A ) ist nicht nur ein Servo-Wert fehlerhaft, sondern es kommt zu einer kurzen Störung im Ablauf des Empfängerprogramms. Wahrscheinlich deshalb, weil außer oder zusätzlich zu einem Servowert auch irgendwelche programm-relevante Kontrollbits fehlerhaft übertragen wurden. Dies dauerte bei allen Tests bisher immer 0.9 Sekunden, bis sich der Empfänger „fängt“ und wieder neu auf den Sender synchronisiert. Innerhalb dieser 0.9 Sekunden sind dann alle Servowerte auf den letzten Stand eingefroren.
Leider ist es dann so, dass meistens auch ein fehlerhafter Servowert für 0.9s auf irgendeinem der 16 Servokanäle eingefroren anliegt. Ist an diesem Kanal ein Servo angeschlossen so kommt es zu einem deutlichen, unkontrollierten Servoausschlag. 0,9s reichen auch für langsame Servos aus, um voll zu positionieren. Ist in diesem Fall einer der 16 Servokanäle fehlerhaft, welcher nicht verwendet wird, so ist das Modell zwar für 0.9s nicht steuerbar, aber ein Servoausschlag ist nicht festzustellen.
Das gleiche gilt, wenn nur Kontrollbits aber keine Servowerte fehlerhaft sind.
Im Vergleich zu dem kurzen „Servo-Zucken“ tritt dieser Fall wesentlich seltener auf und betraf bisher nur wenige Piloten im EU (LBT) Bereich. Der statistische Unterschied zwischen A.) und B.) gründet einfach darauf, dass wesentlich mehr Servodaten als Kontrollbits vom Sender zum Empfänger übertragen werden.
Die Hauptursache ist die sogenannte „Fehlererkennung/Verschlüsselung“ in der Firmware. Diese wurde von FrSky selbst entwickelt um von den Chipherstellern unabhängig zu bleiben. Denn diese stellen auch eine Fehlererkennung/Verschlüsselung bereit. Diese selbst entwickelte Fehlererkennung/Verschlüsselung muss über Jahre gut funktioniert haben. Sonst hätte FrSky nicht diesen bis dato den guten Ruf als sicheres und zuverlässiges RC-System erlangt.
In der letzten Zeit ändern sich aber zunehmend die Betriebsbedingungen durch eine deutlich höhere Auslastung des 2,4 GHz Bandes. Es besteht ein direkter, statistischer Zusammenhang zwischen Störungen und der Qualität der Funkstrecke auf dem 2.4GHz Band und der Wahrscheinlichkeit, mit welcher unser Fehler auftreten kann.
Zudem sind moderne Empfänger-Chips empfindlicher und erlauben deshalb eine größere Reichweite. Sie sind deshalb aber auch empfindlicher gegenüber kleinsten Frequenzabweichungen. Deshalb sind auch Empfänger wie der GRX-8 öfter betroffen als ältere Typen. Wenn die Streuung von Bauteilen (gibt es in der Elektronik durchaus) nun zu einem etwas unsauberen Frequenzabgleich führt und dazu noch viele Störungen im Umfeld sind, dann gibt es eine deutlich höhere Wahrscheinlichkeit dass das Problem auftritt.
Ich denke, wir sind uns einig, dass man die eigentliche Ursache beseitigen sollte und nicht die Symptome. Die Tatsache, dass die Fehler nur bei bestimmter Hardware, dort aber gehäuft auftreten, mit anderer Hardware überhaupt nicht, wird m.E. zu wenig berücksichtigt.
Ich kommentiere eigentlich nur noch gemütlich zurückgelehnt das Geschehen. Der Stein ist ja schon im Rollen.
Ich wies die 3-5 Openminded, die hier mitlesen, lediglich auf einen neuen Aspekt aus dem Hauptquartier hin, der bisher so noch nicht zu hören war
Ach ja, meine eigentlich Frage ↑ ist noch nicht beantwortet ....
Ich kommentiere eigentlich nur noch gemütlich zurückgelehnt das Geschehen. Der Stein ist ja schon im Rollen.
Ich wies die 3-5 Openminded, die hier mitlesen, lediglich auf einen neuen Aspekt aus dem Hauptquartier hin, der bisher so noch nicht zu hören war
Ach ja, meine eigentlich Frage ↑ ist noch nicht beantwortet ....
Zuletzt bearbeitet:
Vor allem passiert ein solcher Servoausschlag auch nicht bei jedem "falschen Wert" der Servoansteuerung, die meiner Erinnerung nach eine Auflösung von 2048 Schritten hat, es muss also also schon ein Fehlwert im entsprechenden Bereich hin zur Servo-Endstellung sein.
Wie bitte?? Die „Fehlererkennung/Verschlüsselung“ in der Firmware "hat über Jahre gut funktioniert" und dieselbe tut das jetzt auf einmal nicht mehr, weil sich zunehmend die Betriebsbedingungen durch eine deutlich höhere Auslastung des 2,4 GHz Bandes ändern?? Sorry, das ist abenteuerlich, um nicht unhöfliche Worte hier zu schreiben. Entweder hat die „Fehlererkennung/Verschlüsselung“ in der Firmware funktioniert und dann funktioniert dieselbe auch noch heute und das auch bei einer höheren Auslastung des Frequenzbandes. Oder aber sie hat eine Schwachstelle und dann hat sie diese schon seit Einführung des D16-Protokolls.
Wie bitte?? Die „Fehlererkennung/Verschlüsselung“ in der Firmware "hat über Jahre gut funktioniert" und dieselbe tut das jetzt auf einmal nicht mehr, weil sich zunehmend die Betriebsbedingungen durch eine deutlich höhere Auslastung des 2,4 GHz Bandes ändern?? Sorry, das ist abenteuerlich, um nicht unhöfliche Worte hier zu schreiben. Entweder hat die „Fehlererkennung/Verschlüsselung“ in der Firmware funktioniert und dann funktioniert dieselbe auch noch heute und das auch bei einer höheren Auslastung des Frequenzbandes. Oder aber sie hat eine Schwachstelle und dann hat sie diese schon seit Einführung des D16-Protokolls.
Ich hab das schon mal geschrieben:
Frsky verwendet crc16 als Datensicherung (2 bytes). Das ist keine Verschlüsselung.
Da gibt's nur 65536 Kombinationen.
D.h. Kommen falsche Daten an, können die auch als korrekt erkannt werden, da es ja viel, viel, viel mehr Kombinationen gibt.
Einzelne falsche frames die als korrekt zum Servo gelassen werden, merkt man höchstens als brummen.
Ist das Umfeld verseucht, kommen mehr und mehr ungültige frames durch, aber sicher nicht direkt hintereinander.
Dies kann auch durch ein driften des sende Moduls entstehen.
Ich glaube der Empfänger zählt die defekten frames und setzt diesen Zähler nicht korrekt zurück und kommt dann durcheinander.
Mike
Frsky verwendet crc16 als Datensicherung (2 bytes). Das ist keine Verschlüsselung.
Da gibt's nur 65536 Kombinationen.
D.h. Kommen falsche Daten an, können die auch als korrekt erkannt werden, da es ja viel, viel, viel mehr Kombinationen gibt.
Einzelne falsche frames die als korrekt zum Servo gelassen werden, merkt man höchstens als brummen.
Ist das Umfeld verseucht, kommen mehr und mehr ungültige frames durch, aber sicher nicht direkt hintereinander.
Dies kann auch durch ein driften des sende Moduls entstehen.
Ich glaube der Empfänger zählt die defekten frames und setzt diesen Zähler nicht korrekt zurück und kommt dann durcheinander.
Mike
Jetzt habe ich doch Bedenken bekommen. Wenn man hoch greift und annimmt, dass jede Sekunde ein kritisches Frame aus 111 auftritt und es nur 65536 Kombinationen zur Fehlerkorrektur gibt, dann hat man alle 18 Stunden für 1/111s einen falschen Servowert anliegen. Und da gibt es tatsächlich Modellflieger, die das noch nicht bemerkt haben wollen?
Es ist auch keine Fehlerkorrektur.
Falsche frames werden einfach verworfen.
Aber wie geschrieben, wenn z.b. Jeder 20 kaputte frame durch kommt merkt das kein Servo und keine FC, da die ja einen Filter haben, der glitches raus filtert.
Wegen den crc16 Sachen mache ich mir wenig Gedanken.
Eher deswegen, weil der Empfänger wohl offensichtlich durch zuviele falsche frames wohl rebootet, reseted oder sich neu syncen muss und dadurch für knapp ne Sekunde die falschen Signale ausgeben werden.
Dies ist meiner Meinung nach einfach schlecht programmiert worden.
Falsche frames werden einfach verworfen.
Aber wie geschrieben, wenn z.b. Jeder 20 kaputte frame durch kommt merkt das kein Servo und keine FC, da die ja einen Filter haben, der glitches raus filtert.
Wegen den crc16 Sachen mache ich mir wenig Gedanken.
Eher deswegen, weil der Empfänger wohl offensichtlich durch zuviele falsche frames wohl rebootet, reseted oder sich neu syncen muss und dadurch für knapp ne Sekunde die falschen Signale ausgeben werden.
Dies ist meiner Meinung nach einfach schlecht programmiert worden.
Das war natürlich ironisch gemeint. Die eigentliche Frage ist, warum soll das System jahrelang perfekt funktioniert haben und dann treten plötzlich firmwarebedingte Fehler auf? Verbessert man in so einem Fall die Fehlerkorrektur? Macht keinen Sinn. Man muss schauen, was vorgelagert passiert ist. Die Fehlerkorrektur ist beim funktionierenden System gut genug. Bei einem driftenden System kommt es zu den Aussetzern. Also muss man sich um das Wegdriften kümmern. Zumindest in meiner Welt ist das so ....
So seh ich es auch, es hat bisher auch ausgereicht.
Und das es im Grenzbereich / Reichweitengrenze / laboraufbau auch aussetzt ist ja klar.
Und wenn sende module driften sollte man eher danach schauen.
Denn dann tritt so ein Fehler auch im Nahbereich auf.
Aber es sind ja genug "Spezialisten" an der Fehlerbehebung dran.
P.s.
Ich bin schon seit 25 Jahren Entwickler für Hardware und Firmware auf mikrontrollern von 8bit bis 32bit CPUs.
Und das es im Grenzbereich / Reichweitengrenze / laboraufbau auch aussetzt ist ja klar.
Und wenn sende module driften sollte man eher danach schauen.
Denn dann tritt so ein Fehler auch im Nahbereich auf.
Aber es sind ja genug "Spezialisten" an der Fehlerbehebung dran.
P.s.
Ich bin schon seit 25 Jahren Entwickler für Hardware und Firmware auf mikrontrollern von 8bit bis 32bit CPUs.
Weil es sonst zu langweilig und leicht wird....
Dann möchte ich noch einmal in den Raum werfen, das ein backward update des XJT von 170317 LBT auf die 151223 LBT Probleme bei meiner X9D+ und dem G-RX8 das Problem auch behebt.
IAus diesem Grund vermute ich den Fehler mehr in der HF Firmware oder (Hardware? denke ich eher nicht), vermutlich wurde durch eine Änderung 21.05.2017 in der Firmware 170317 der Fehler ausgelöst.
Dann möchte ich noch einmal in den Raum werfen, das ein backward update des XJT von 170317 LBT auf die 151223 LBT Probleme bei meiner X9D+ und dem G-RX8 das Problem auch behebt.
IAus diesem Grund vermute ich den Fehler mehr in der HF Firmware oder (Hardware? denke ich eher nicht), vermutlich wurde durch eine Änderung 21.05.2017 in der Firmware 170317 der Fehler ausgelöst.
Weiter möchte ich noch sagen.... die Firmware 170317 habe ich seit ca. 1,5-2 Jahren im fast täglichen Einsatz und das ganze ohne abstürze!
Vielleicht wäre es möglich den ein oder anderen vermutlichen Strömungsabriss beim langsamen Kurbeln auf die beschriebenen Fehler zu schieben, aber ich weis es nicht, wirklich gesehen habe ich beim fliegen noch nie etwas, meist aber auch recht weit weg wo die Sicht sowieso schon schlecht wird.
Bemerkt habe ich das Problem nur durch Zufall beim programmieren eines Modells als es lange eingeschaltet auf dem Tisch lag, erst habe ich gedacht ich hätte mich geirrt als ich ein oder mehrere Servos ihre typischen Laufgeräusche hörte. danach war ich aber aufmerksam und sensibel und konnte nach einiger Zeit sehen das die Klappen sich bewegten.
Dann fing das suchen an, natürlich habe ich erst mal allem möglichem kram die schuld gegeben, an den Sender oder Empfänger habe ich nicht mal gedacht.
Erst als ich alles durch hatte was man tauschen konnte und das Problem weiter bestand, fing ich an Firmware zu Flashen, aber nur die RX Firmware den hier gab es ja schon genug Fehler.
Dem Sender hatte ich immer noch nicht im Verdacht weil ich flog ja schon die ganze Zeit damit, nur die G-RX 8 waren im Ersteinsatz.
Nach Wochen vergeblichem suchen Flashen und eigentlich hatte ich schon fast aufgegeben, weil keiner das Problem kannte geschweige denn bestätigen konnte.
An einem Sonnigen Tag war ich wieder beim fliegen, hatte mein meist, fast täglich geflogenen Segler vor mir eingeschaltet auf der Wiese liegen wie immer... leider war Thermik trotz super Wetter nicht wirklich zu finden also warten und den Himmel nach den gefiederten Kollegen absuchend... und im nächsten Moment hörte ich ein Servo laufen und sah im Augenwinkel wie wenigstens ein Ruder sich ordentlich bewegte.
Ab dem Tag war klar der GR-X8 ist nicht alleine betroffen den in dem Flieger steckt ein S8R mit deaktiviertem Stabi ab jetzt war Schluss mit Thermik suchen, jetzt wurde verzweifelt weiter gesucht... dann kam ich auf die Idee mal das HF auf die Vorgängerversion 151223 zu flashen und siehe da egal ob GR-X8 oder S8R nix zuckt keine Failsafe mehr, so bin ich dann bis ende der Season weiter geflogen, hatte aber immer ein wachsames Auge auf meine eingeschaltet rum liegenden Flieger... ist wohl ein "vorteil" wenn man sie eingeschaltet lässt um solche Sachen zu bemerken.
Mein Grund für das eingeschaltet lassen ist aber einfach der das wenn ich der Meinung bin jetzt ist der richtige Moment den Flieger zu werfen dann möchte ich nicht erst Akkus anstecken warten bis Vario und GPS Stabil sind... obendrein bin ich faul auch der Stromverbrauch ist lächerlich selbst nach vielen Stunden Leerlauf und fliegen also hat sich das so eingebürgert.
Übrigens...
Sehr interessant finde ich wie viele Flugzeuge in der letzten Zeit wegen genau "diesem" Problem abgestürzt sind vor ein paar Wochen kannte es fast noch niemand.
Vielleicht wäre es möglich den ein oder anderen vermutlichen Strömungsabriss beim langsamen Kurbeln auf die beschriebenen Fehler zu schieben, aber ich weis es nicht, wirklich gesehen habe ich beim fliegen noch nie etwas, meist aber auch recht weit weg wo die Sicht sowieso schon schlecht wird.
Bemerkt habe ich das Problem nur durch Zufall beim programmieren eines Modells als es lange eingeschaltet auf dem Tisch lag, erst habe ich gedacht ich hätte mich geirrt als ich ein oder mehrere Servos ihre typischen Laufgeräusche hörte. danach war ich aber aufmerksam und sensibel und konnte nach einiger Zeit sehen das die Klappen sich bewegten.
Dann fing das suchen an, natürlich habe ich erst mal allem möglichem kram die schuld gegeben, an den Sender oder Empfänger habe ich nicht mal gedacht.
Erst als ich alles durch hatte was man tauschen konnte und das Problem weiter bestand, fing ich an Firmware zu Flashen, aber nur die RX Firmware den hier gab es ja schon genug Fehler.
Dem Sender hatte ich immer noch nicht im Verdacht weil ich flog ja schon die ganze Zeit damit, nur die G-RX 8 waren im Ersteinsatz.
Nach Wochen vergeblichem suchen Flashen und eigentlich hatte ich schon fast aufgegeben, weil keiner das Problem kannte geschweige denn bestätigen konnte.
An einem Sonnigen Tag war ich wieder beim fliegen, hatte mein meist, fast täglich geflogenen Segler vor mir eingeschaltet auf der Wiese liegen wie immer... leider war Thermik trotz super Wetter nicht wirklich zu finden also warten und den Himmel nach den gefiederten Kollegen absuchend... und im nächsten Moment hörte ich ein Servo laufen und sah im Augenwinkel wie wenigstens ein Ruder sich ordentlich bewegte.
Ab dem Tag war klar der GR-X8 ist nicht alleine betroffen den in dem Flieger steckt ein S8R mit deaktiviertem Stabi
ab jetzt war Schluss mit Thermik suchen, jetzt wurde verzweifelt weiter gesucht... dann kam ich auf die Idee mal das HF auf die Vorgängerversion 151223 zu flashen und siehe da egal ob GR-X8 oder S8R nix zuckt keine Failsafe mehr, so bin ich dann bis ende der Season weiter geflogen, hatte aber immer ein wachsames Auge auf meine eingeschaltet rum liegenden Flieger... ist wohl ein "vorteil" wenn man sie eingeschaltet lässt um solche Sachen zu bemerken.Mein Grund für das eingeschaltet lassen ist aber einfach der das wenn ich der Meinung bin jetzt ist der richtige Moment den Flieger zu werfen dann möchte ich nicht erst Akkus anstecken warten bis Vario und GPS Stabil sind... obendrein bin ich faul
auch der Stromverbrauch ist lächerlich selbst nach vielen Stunden Leerlauf und fliegen also hat sich das so eingebürgert.Übrigens...
Sehr interessant finde ich wie viele Flugzeuge in der letzten Zeit wegen genau "diesem" Problem abgestürzt sind
vor ein paar Wochen kannte es fast noch niemand.
Mario, nichts gegen deine Beobachtung, aber du bist so ziemlich der Einzige, der diese Beobachtung gemacht hat. Nicht falsch verstehen, im Einzelfall sicher richtig, aber insgesamt ohne statistische Bewandtnis. Die meisten fliegen problemlos mit 170317 und es sind kaum X9D/E bekannt, die das Lockout Problem oder den Ausschlag zeigen.
zeigen.
