Hier gibt es mal wieder einen klaren lockout-Fall. Ohne Engel-Bug 
Jetzt bin ich mal auf den verwendeten Sender gespannt ....
Jetzt bin ich mal auf den verwendeten Sender gespannt ....
FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Hier gibt es mal wieder einen klaren lockout-Fall. Ohne Engel-Bug Jetzt bin ich mal auf den verwendeten Sender gespannt ....
Jetzt bin ich mal auf den verwendeten Sender gespannt ....
Ohne Engel Bug= kein zusätzliches, plötzlicher Servoausschläge??
Gruß Michael
Ja, passt. Lockout bedeutet, dass für einen wahrnehmbaren Zeitraum keine Steuerinformationen ankommen. Failsafe ist ein Lockout >1s.
Der Engel-Bug ist die Hypothese, dass seit Anbeginn der FrSky Firmware ungesteuerte Ausschläge auftreten. Meine Namenwahl soll klarstellen, dass nur der Gläubige diese Erfahrung machen kann.
Der Engel-Bug ist die Hypothese, dass seit Anbeginn der FrSky Firmware ungesteuerte Ausschläge auftreten. Meine Namenwahl soll klarstellen, dass nur der Gläubige diese Erfahrung machen kann.
Zuletzt bearbeitet:
.Bei einem Falesafe "hold" sollte man ja von dem Fehler eigentlich nichts mitkriegen. So wie ich das verstanden habe kommt es aber nicht zum Falesafe.
Für den Laien ist das schwer verständlich weil uns die Grundlagen fehlen.
Sowie verstanden ist der "Lockout" also der andere Fehler von dem du gesprochen hast.
1.Fehler.. Der RX gibt für sehr kurze Zeit einen Servoimpuls raus, zB Roll, Höhe oder Gas= plötzliche Servobew.="Engel Bug"
2.Fehler.. Am RX kommt für kurze Zeit nichts mehr an = Lockout
--Beide Fehler immer ohne das ein Nachweis über das logging erfolgen könnte.
--Beides auch ohne das der RX den Hauch einer Chance hatte in den Failsafe zu gehen!
In dieser sehr ungünstigen "Konstellation" wäre das aber auch ein Firmware-Supergau!
Sorry wenn ich so frage aber einen kompletten für mich verständlichen Zusammenhang hab ich noch nicht verinnerlicht!
Vielen Dank schonmal
Gruß Michael
Für den Laien ist das schwer verständlich weil uns die Grundlagen fehlen.
Sowie verstanden ist der "Lockout" also der andere Fehler von dem du gesprochen hast.
1.Fehler.. Der RX gibt für sehr kurze Zeit einen Servoimpuls raus, zB Roll, Höhe oder Gas= plötzliche Servobew.="Engel Bug"
2.Fehler.. Am RX kommt für kurze Zeit nichts mehr an = Lockout
--Beide Fehler immer ohne das ein Nachweis über das logging erfolgen könnte.
--Beides auch ohne das der RX den Hauch einer Chance hatte in den Failsafe zu gehen!
In dieser sehr ungünstigen "Konstellation" wäre das aber auch ein Firmware-Supergau!
Sorry wenn ich so frage aber einen kompletten für mich verständlichen Zusammenhang hab ich noch nicht verinnerlicht!
Vielen Dank schonmal
Gruß Michael
Servus,
ich bin froh diesen Thread gefunden zu haben, denn ich bin auch betroffen. Als Helipilot gibt es aber einen kleinen Unterschied zu den hier erwähnten Vorfällen, bei einem Funkausfall im Sekundenbereich ist der Heli definitiv hin wenn man 3D fliegt...
Am 25.10.19 und am 10.11.19 hatte ich jeweils einen Crash, einmal mit einem 700er 3Blatt Forza und einem 700er Voodoo. In den Logs des FBLs (Flybarless oder Flightcontroller für die nicht-Heli-Menschen) ist ersichtlich dass für den Zeitraum von 1-2s jeweils nichts sinnvolles auf dem SBUS vom Empfänger kam, danach war wieder Signal vorhanden. In den OpenTX logs vom Sender sieht man dass es keine neuen Werte aller Telemetriedaten gab in diesem Zeitraum, also kein Link vorhanden war, der letzte RSSI Wert war jeweils 63 und 65.
Vor diesen beiden Crashes hatte ich in einem anderen Heli (630 Goblin) auch etwa einen Aussetzer alle 50 Flüge. Dort ist aber ein anderes FBL verbaut welches sich im Failsafefall etwas anders verhält, zusätzlich hatte ich damals immer Glück weil es nie mitten in 3D Figuren nah am Boden auftrat. Ich habe dort 4-5 Aussetzer in 250 Flügen erlebt mit den Empfänger/Sendercombos R-XSR+X9D, RX8R+X9D, RX8R+X12S mit verschiedenster Firmware. Irgendwann habe ich nicht mehr die Funkanlage in Verdacht gehabt weil ich da ja genügend Komponenten durchgetauscht hatte und andere Helis keine Symptome gezeigt hatten. Der Rest meiner Flotte hat aber deutlich weniger Flüge gesehen da ich gut 20 Modelle habe.
Im Oktober diesen Jahres bin ich auf eine Xlite Pro umgestiegen. Nach anfänglicher Eingewöhnungsphase mit 5" Coptern und kleinen Helis (380 Devil & Oxy3) von etwa 30 Flügen habe ich angefangen die 700er auch mit der Xlite Pro zu fliegen. Der Forza mit einem RX8R hatte 20 Flüge mit einer X9D oder X12S mitgemacht. Dann kamen 5 Flüge mit der Xlite Pro als beim letzten Flug nach 1 Minute in etwa 5 Meter Höhe bei einem einfachen Flip die Kontrolle ausfiel. Der Voodoo mit einem XSR hatte über 90 Flüge mit X9D und X12S gesehen und dann nach etwa 10 Flügen mit der Xlite Pro kam der Crash mit einem RSSI von 63. Das wirklich doofe ist dass es nach 6 Minuten Flugzeit passiert ist, kurz bevor ich sowieso landen müsste
Probleme mit der Verkabelung oder Antennenausrichtung kann ich ausschließen, spätestens bei einem 700er sollte man wissen worauf zu achten ist. Die Funkanlage habe ich auch nicht direkt im Verdacht gehabt da ich mit dem FrSky System über 600 geloggte Flüge habe über den Zeitraum der letzten 2 Jahre verteilt über viele Helis ab 450er Größe. Kleinvieh und Copter habe ich nicht mit geloggt.
Nach dem ersten Crash dachte ich an EMV Probleme weil der Forza sich locker 200A peaks an 12S gönnt und ich noch nie Probleme bei Helis mit kleineren Antrieben hatte. Nach dem Voodoo crash war die Funkanlage in Verdacht. Aktuell baue ich alle Helis >600 auf RX8R Pro & XM+ um. Jetzt nachdem hier tatsächlich ein Problem außerhalb meiner Reichweite aufgetreten sein könnte, kann ich nur hoffen dass es von FrSky beseitgt wird. Am besten noch vor der nächsten Saison, denn die Xlite Pro geb ich nicht mehr her
Grüße,
Arti
ich bin froh diesen Thread gefunden zu haben, denn ich bin auch betroffen. Als Helipilot gibt es aber einen kleinen Unterschied zu den hier erwähnten Vorfällen, bei einem Funkausfall im Sekundenbereich ist der Heli definitiv hin wenn man 3D fliegt...
Am 25.10.19 und am 10.11.19 hatte ich jeweils einen Crash, einmal mit einem 700er 3Blatt Forza und einem 700er Voodoo. In den Logs des FBLs (Flybarless oder Flightcontroller für die nicht-Heli-Menschen) ist ersichtlich dass für den Zeitraum von 1-2s jeweils nichts sinnvolles auf dem SBUS vom Empfänger kam, danach war wieder Signal vorhanden. In den OpenTX logs vom Sender sieht man dass es keine neuen Werte aller Telemetriedaten gab in diesem Zeitraum, also kein Link vorhanden war, der letzte RSSI Wert war jeweils 63 und 65.
Vor diesen beiden Crashes hatte ich in einem anderen Heli (630 Goblin) auch etwa einen Aussetzer alle 50 Flüge. Dort ist aber ein anderes FBL verbaut welches sich im Failsafefall etwas anders verhält, zusätzlich hatte ich damals immer Glück weil es nie mitten in 3D Figuren nah am Boden auftrat. Ich habe dort 4-5 Aussetzer in 250 Flügen erlebt mit den Empfänger/Sendercombos R-XSR+X9D, RX8R+X9D, RX8R+X12S mit verschiedenster Firmware. Irgendwann habe ich nicht mehr die Funkanlage in Verdacht gehabt weil ich da ja genügend Komponenten durchgetauscht hatte und andere Helis keine Symptome gezeigt hatten. Der Rest meiner Flotte hat aber deutlich weniger Flüge gesehen da ich gut 20 Modelle habe.
Im Oktober diesen Jahres bin ich auf eine Xlite Pro umgestiegen. Nach anfänglicher Eingewöhnungsphase mit 5" Coptern und kleinen Helis (380 Devil & Oxy3) von etwa 30 Flügen habe ich angefangen die 700er auch mit der Xlite Pro zu fliegen. Der Forza mit einem RX8R hatte 20 Flüge mit einer X9D oder X12S mitgemacht. Dann kamen 5 Flüge mit der Xlite Pro als beim letzten Flug nach 1 Minute in etwa 5 Meter Höhe bei einem einfachen Flip die Kontrolle ausfiel. Der Voodoo mit einem XSR hatte über 90 Flüge mit X9D und X12S gesehen und dann nach etwa 10 Flügen mit der Xlite Pro kam der Crash mit einem RSSI von 63. Das wirklich doofe ist dass es nach 6 Minuten Flugzeit passiert ist, kurz bevor ich sowieso landen müsste
Probleme mit der Verkabelung oder Antennenausrichtung kann ich ausschließen, spätestens bei einem 700er sollte man wissen worauf zu achten ist. Die Funkanlage habe ich auch nicht direkt im Verdacht gehabt da ich mit dem FrSky System über 600 geloggte Flüge habe über den Zeitraum der letzten 2 Jahre verteilt über viele Helis ab 450er Größe. Kleinvieh und Copter habe ich nicht mit geloggt.
Nach dem ersten Crash dachte ich an EMV Probleme weil der Forza sich locker 200A peaks an 12S gönnt und ich noch nie Probleme bei Helis mit kleineren Antrieben hatte. Nach dem Voodoo crash war die Funkanlage in Verdacht. Aktuell baue ich alle Helis >600 auf RX8R Pro & XM+ um. Jetzt nachdem hier tatsächlich ein Problem außerhalb meiner Reichweite aufgetreten sein könnte, kann ich nur hoffen dass es von FrSky beseitgt wird. Am besten noch vor der nächsten Saison, denn die Xlite Pro geb ich nicht mehr her
Grüße,
Arti
Mir ist irgendwann aufgefallen, dass es eine Häufung von Fehlerbeschreibungen gab. Besonders bei Benutzung von Horus Sendern. Der Fehler äußert sich auf mehrere Arten:
- das Modell ist kurze Zeit nicht steuerbar, das merkt man nur in bestimmten Situationen, wie z.B. Abfangen im Landeanflug, Pylonwende u.s.w..
- der Sender gibt eine "Telemetrie verloren" Meldung aus, was bedeutet, dass 1s lang keine Telemetrie empfangen wurde. Kritisch deswegen, weil Hin- und Rückkanal mit derselben Leistung und den gleichen Antennen arbeiten. Es gibt eine große Wahrscheinlichkeit, dass auch der Hinkanal nicht funktioniert hat
- im Log sieht man einen "eingefrorenen" RSSI. Was sehr untypisch ist, wiel ganz selten 2 aufeinanderfolgende RSSI Werte identisch sind. Der Log muss dazu mindestens auf 0,2s stehen, sonst funktioniert das natürlich nicht. Auch die anderen Werte sind während des Lockout "eingefroren"
- es gibt in Zusammenhang mit dem Lockout ab und zu ungesteuerte Ausschläge, das wird in der Regel immer bemerkt
Leider hat sich Ewald vor allem auf den letzten Punkt gestürzt und hat es geschafft, mit viel Aufwand bei allen FrSky Empfängern Ausschläge zu produzieren. Das war aber leider nur ein mögliches Symptom des eigentlichen Fehlers.
Ich sehe eine gute Chance, dass FrSky die Wirkung des Fehlers mit der neuen R-XSR und G-RX8 Firmware entschärft hat. Der eigentliche "Fehler" ist aber vermutlich eine Frequenzdrift des RF-Moduls der neueren Sender. Kein alter Sender ist von dieser Drift betroffen. Ich kenne nur eine einzige Ausnahme, das ist die X9D+ von Mario. Und leider war genau dieser Sender im engeren Testfeld, wenn ich das richtig verstanden habe.
Wichtig wäre es, die eigentliche Ursache anzugehen, nämlich die Frequenzdrift bei den neuen Sendern (Vermutung, kann man aber leicht messen).
Wenn sich FrSky demnächst mit der unnötigen Engel-Bug-Firmware unkompatibel zu sich selbst macht, wird es richtig spannend. Ich würde sehr gut über die möglichen Folgen nachdenken.
Artis Beitrag habe ich gerade kurz überflogen, scheint aber zu passen
- das Modell ist kurze Zeit nicht steuerbar, das merkt man nur in bestimmten Situationen, wie z.B. Abfangen im Landeanflug, Pylonwende u.s.w..
- der Sender gibt eine "Telemetrie verloren" Meldung aus, was bedeutet, dass 1s lang keine Telemetrie empfangen wurde. Kritisch deswegen, weil Hin- und Rückkanal mit derselben Leistung und den gleichen Antennen arbeiten. Es gibt eine große Wahrscheinlichkeit, dass auch der Hinkanal nicht funktioniert hat
- im Log sieht man einen "eingefrorenen" RSSI. Was sehr untypisch ist, wiel ganz selten 2 aufeinanderfolgende RSSI Werte identisch sind. Der Log muss dazu mindestens auf 0,2s stehen, sonst funktioniert das natürlich nicht. Auch die anderen Werte sind während des Lockout "eingefroren"
- es gibt in Zusammenhang mit dem Lockout ab und zu ungesteuerte Ausschläge, das wird in der Regel immer bemerkt
Leider hat sich Ewald vor allem auf den letzten Punkt gestürzt und hat es geschafft, mit viel Aufwand bei allen FrSky Empfängern Ausschläge zu produzieren. Das war aber leider nur ein mögliches Symptom des eigentlichen Fehlers.
Ich sehe eine gute Chance, dass FrSky die Wirkung des Fehlers mit der neuen R-XSR und G-RX8 Firmware entschärft hat. Der eigentliche "Fehler" ist aber vermutlich eine Frequenzdrift des RF-Moduls der neueren Sender. Kein alter Sender ist von dieser Drift betroffen. Ich kenne nur eine einzige Ausnahme, das ist die X9D+ von Mario. Und leider war genau dieser Sender im engeren Testfeld, wenn ich das richtig verstanden habe.
Wichtig wäre es, die eigentliche Ursache anzugehen, nämlich die Frequenzdrift bei den neuen Sendern (Vermutung, kann man aber leicht messen).
Wenn sich FrSky demnächst mit der unnötigen Engel-Bug-Firmware unkompatibel zu sich selbst macht, wird es richtig spannend. Ich würde sehr gut über die möglichen Folgen nachdenken.
Artis Beitrag habe ich gerade kurz überflogen, scheint aber zu passen
Ich vermute, dass es im Falle des Lockouts sogar zu einem Reboot des empfängers kommt, getriggert entweder durch einen Watchdog oder einen Software-Fehler.
Und von meinen beiden betroffenen Empfängern, einem XM+ und R-XSR weiß ich, dass die beiden Fehler, also plötzliche Kanal-Vollaussteuerung und Lockout unmittelbar zusammenhängen.
Wie ich seit gestern weiß, basiert der XM+ auf einem 8051-Prozessor, der R-XSR auf einem STM32-Prozessor. Der XM+ produziert diese Kanal-Vollaussteuerung gefolgt vom Lockout, der R-XSR nur den Lockout alleine, den allerdings wesentlich häufiger als der XM+. Vielleicht gleicht sich die Häufigkeit ja durch die neue Firmware an den XM+ an.
Jetzt wäre schon mal interessant zu wissen, ob alle von Kanal-Vollausschlägen betroffenen Empfänger ebenfalls auf dem 8051 basieren, oder ob es auch Fälle mit Empfängern mit STM32 gibt.
Denken wir mal weiter: Wann nimmt ein Servo einen Kanalwert an und führt ihn aus? Ein einzelner Ausreißer im Datenstrom würde schlimmstenfalls zu einem kurzen Zucken führen, aber niemals zu einem anhaltenden Vollausschlag. Meine Theorie lautet daher, dass ein Frame aufgrund des im Engel-Forum diskutierten CRC-Fehlers falsch dekodiert und als Kanalwert sowohl per SBUS als auch Servopin ausgegeben wird und gleichzeitig zum Aufhängen oder Absturz der Empfängerfirmware führt, wodurch der Prozessor neu bootet und den Lockout produziert. In dieser Zeit werden weder auf dem SBUS noch auf den Servopins Daten ausgegeben, was der Betaflight-FC in meinen Whoops korrekterweise als RXLOSS erkennt.
Da die Firmware für 8051 und STM32 ja unterschiedlich sein muss, kann sich auch das Verhalten unterscheiden, sprich beim 8051 wird der falsche Kanalwert noch ausgegeben, beim STM32 nicht.
Gruß Gerd
Und von meinen beiden betroffenen Empfängern, einem XM+ und R-XSR weiß ich, dass die beiden Fehler, also plötzliche Kanal-Vollaussteuerung und Lockout unmittelbar zusammenhängen.
Wie ich seit gestern weiß, basiert der XM+ auf einem 8051-Prozessor, der R-XSR auf einem STM32-Prozessor. Der XM+ produziert diese Kanal-Vollaussteuerung gefolgt vom Lockout, der R-XSR nur den Lockout alleine, den allerdings wesentlich häufiger als der XM+. Vielleicht gleicht sich die Häufigkeit ja durch die neue Firmware an den XM+ an.
Jetzt wäre schon mal interessant zu wissen, ob alle von Kanal-Vollausschlägen betroffenen Empfänger ebenfalls auf dem 8051 basieren, oder ob es auch Fälle mit Empfängern mit STM32 gibt.
Denken wir mal weiter: Wann nimmt ein Servo einen Kanalwert an und führt ihn aus? Ein einzelner Ausreißer im Datenstrom würde schlimmstenfalls zu einem kurzen Zucken führen, aber niemals zu einem anhaltenden Vollausschlag. Meine Theorie lautet daher, dass ein Frame aufgrund des im Engel-Forum diskutierten CRC-Fehlers falsch dekodiert und als Kanalwert sowohl per SBUS als auch Servopin ausgegeben wird und gleichzeitig zum Aufhängen oder Absturz der Empfängerfirmware führt, wodurch der Prozessor neu bootet und den Lockout produziert. In dieser Zeit werden weder auf dem SBUS noch auf den Servopins Daten ausgegeben, was der Betaflight-FC in meinen Whoops korrekterweise als RXLOSS erkennt.
Da die Firmware für 8051 und STM32 ja unterschiedlich sein muss, kann sich auch das Verhalten unterscheiden, sprich beim 8051 wird der falsche Kanalwert noch ausgegeben, beim STM32 nicht.
Gruß Gerd
Könnte so sein, aber ich glaube, dass die Wahrscheinlichkeit für die andere Priorität höher ist: Das Problem startet immer mit einem Lockout und bei manchen Empfängern oder in bestimmten Situationen bewirkt es auch eine Kanalwertänderung die während des Lockout gehalten wird. Damit könnte man alle Beobachtungen erklären, vor allem auch die Lockouts ohne Kanalwertänderung. Und auch warum nur bestimmte Sender betroffen sind.
Carbo - welcher "Glaubens"gemeinschaft gehörst du an? Glauben heisst nicht wissen, und es wird nicht dadurch richtiger, wenn du mantramäßig immer wieder das gleiche erzählst.
Die Ausschläge bzw Holds sind Auswirkung der gleichen Ursache, die sich aber unterschiedlich auswirken kann. Wie ich bereits sagte, hat Engel eine unglückliche Themenüberschrift gewählt. Die Untersuchung ging aber in alle Richtungen, und auf meine Bitte hin hat Ewald einen Test eingeführt, der auch die Holds nachweist. Aber das weisst du alles - ignorierst es aber.
Daher nochmals zur Klarstellung: Im gleichen Testszenario treten auf:
Oben genannte Faktoren führten führten zu einem hohen Frameverlust - das zu einem erhöhten Ausflippen des Empfänger führte.
Das erklärt auch warum manche keine Probleme hatten, manche nur mit bestimmten Sender/Empfänger Kombinationen.
Was damit für mich NICHT schlüssig erklärt werden kann ist, warum die Probleme überwiegend im Nahbereich ( <200 mtr ) auftreten.
Norbert
Die Ausschläge bzw Holds sind Auswirkung der gleichen Ursache, die sich aber unterschiedlich auswirken kann. Wie ich bereits sagte, hat Engel eine unglückliche Themenüberschrift gewählt. Die Untersuchung ging aber in alle Richtungen, und auf meine Bitte hin hat Ewald einen Test eingeführt, der auch die Holds nachweist. Aber das weisst du alles - ignorierst es aber.
Daher nochmals zur Klarstellung: Im gleichen Testszenario treten auf:
- kurze Holds und Ausschläge über wenige Frames ( 3-5 ) - das merkt niemand, da sie nur 30 - 50 msec dauern
- Die relevanten Holds und Ausschläge über 100 Frames ( 900msec) - die man sehr wohl merkt - interessanterweise immer exakt 900 msec - das ist wohl die Zeit, bis Empfänger und Sender wieder synchron laufen, nachdem sie sich verloren hatten
- Der Fehler tritt parallel am SBus und an den Servoausgängen auf
- Der Fehler konnte meist an 1 Kanal, einige male an 2 Kanälen, aber nie mehr nachgewiesen werden
- längere Fehler als die oben beschriebenen 900 msec konnten nicht nachgewiesen werden
Oben genannte Faktoren führten führten zu einem hohen Frameverlust - das zu einem erhöhten Ausflippen des Empfänger führte.
Das erklärt auch warum manche keine Probleme hatten, manche nur mit bestimmten Sender/Empfänger Kombinationen.
Was damit für mich NICHT schlüssig erklärt werden kann ist, warum die Probleme überwiegend im Nahbereich ( <200 mtr ) auftreten.
Norbert
Hallo Norbert, fachlich kann ich da nicht mitdiskutieren, habe zudem auch selber keinen solchen Effekt bisher erlebt. Ich frage mich aber, sind da wirklich nur RXSR und GRX8 betroffen und keine anderen Empfänger? Und wenn nicht, warum sind die nicht betroffen? Der GRX6 dürfte nicht viel unterschiedlich sein wie auch der GRX8 und was ist mit dem RX6R und RX4R?? Alle getestet und für okay befunden?
Ich finde das Ganze wird, zumindest für den Laien immer undurchsichtiger und man hat den Eindruck das eine dauerhafte Lösung für einen sicheren Betrieb mit Frsky- Systemen überhaupt nicht in Sicht ist.
Man ließt ja auch als Laie immer mit aber egal in welchem Bereich von FrSky man unterwegs ist, nichts als Frust ......
Gibt es denn nicht auch mal wieder Positives zu berichten, das vermisse ich überall wo Frsky im Spiel ist, von Jumper T16 mal abgesehen.
Das kann aber doch nicht sein oder liege ich daneben?
Gruß Michael
Man ließt ja auch als Laie immer mit aber egal in welchem Bereich von FrSky man unterwegs ist, nichts als Frust ......
Gibt es denn nicht auch mal wieder Positives zu berichten, das vermisse ich überall wo Frsky im Spiel ist, von Jumper T16 mal abgesehen.
Das kann aber doch nicht sein oder liege ich daneben?
Gruß Michael
Ich fliege seit 2013 mit FrSky (X9D und X9E) und hatte noch nie irgendein Phänomen mit ACCST auf 2,4GHz. Ich logge jeden Flug und habe sicher über hundert Testflüge in den Failsafe gemacht, um das System auch im Grenzbereich zu testen. Ich würde meine hochwertigen Modelle mit nichts anderem fliegen.
Also nicht hysterisch machen lassen.
Also nicht hysterisch machen lassen.
Michael, du liegst damit nicht wirklich daneben. FrSky hat sich seit der Ankündigung von ACCESS selber durch unglückliche Aktionen und Entscheidungen sebst geschadet und seine bis dahin weitgehend zufriedene Kunden langsam aber sicher frustiert (und tut das noch immer). Ich denke mal, dass im FrSky Management einer Entscheidungen trifft und der Betreffende schleunigst ausgetauscht werden sollte, bevor FrSky noch seinen ganzen Kredit bei seinen Usern verspielt.
Ich bin nach wie vor FrSky ( nein OTx ) Fan - und die Hardware ist gut - wenn die Macken beseitigt sind.
Ich war wirklich begeistert, als die ersten Info´s zu ACCESS kamen, jedoch als die ersten Abstrichen kamen, nur die neuesten Empfänger updatebar sind, die Funktionalität zT nicht gegeben ist, aufgerüstete Sender nicht mit ACCESS 900MHz Modulen zusammenspielen, das unsägliche Drama mit dem internen ACCESS Aufrüstmodul, werde ich ACCESS erst mal links liegen lassen und ACCST ordentlich zum laufen bringen. Nachdem jetzt klar ist wo es hängt, sollte das nicht so schwer sein.
Ich habe mich auch gefragt, warum es bei FrSky jetzt so klemmt. ALso ich erfahren habe, daß FrSky jetzt ein Aktienunternehmen ist und der Chefentwickler weggegangen ist und die Jumper entwickelt hat - wundert mich nichts mehr.
Norbert
Ich war wirklich begeistert, als die ersten Info´s zu ACCESS kamen, jedoch als die ersten Abstrichen kamen, nur die neuesten Empfänger updatebar sind, die Funktionalität zT nicht gegeben ist, aufgerüstete Sender nicht mit ACCESS 900MHz Modulen zusammenspielen, das unsägliche Drama mit dem internen ACCESS Aufrüstmodul, werde ich ACCESS erst mal links liegen lassen und ACCST ordentlich zum laufen bringen. Nachdem jetzt klar ist wo es hängt, sollte das nicht so schwer sein.
Ich habe mich auch gefragt, warum es bei FrSky jetzt so klemmt. ALso ich erfahren habe, daß FrSky jetzt ein Aktienunternehmen ist und der Chefentwickler weggegangen ist und die Jumper entwickelt hat - wundert mich nichts mehr.
Norbert
Ich habe nur einen X-Lite-Sender und da passiert es auch im Nahbereich zwischen 6 und 150m.
Inzwischen habe ich einige Flüge mit dem upgedateten R-XSR hinter mir und bisher ist der Lockout nicht wieder aufgetreten. Soll aber noch nichts heißen, nur um diese Jahreszeit wird es zunehmend schwierig, genug Flugstunden anzusammeln und der Fehler kam ja immer sporadisch ohne Vorwarnung.
Gruß Gerd
Inzwischen habe ich einige Flüge mit dem upgedateten R-XSR hinter mir und bisher ist der Lockout nicht wieder aufgetreten. Soll aber noch nichts heißen, nur um diese Jahreszeit wird es zunehmend schwierig, genug Flugstunden anzusammeln und der Fehler kam ja immer sporadisch ohne Vorwarnung.
Gruß Gerd
Interessant.........
Jedenfalls habe ich den Eindruck das sich die Philosophie der Firma geändert hat..
Die Sicherheit der HF-Strecke muß gewährleistet sein, alles andere ist für mich zweitrangig. Selbst Telemetrie ist für mich von geringerer Bedeutung als der sichere Flugbetrieb, klar logisch aber dieser Kompromiss ist ja heute garnicht erforderlich!
Jedenfalls habe ich den Eindruck das sich die Philosophie der Firma geändert hat..
Die Sicherheit der HF-Strecke muß gewährleistet sein, alles andere ist für mich zweitrangig. Selbst Telemetrie ist für mich von geringerer Bedeutung als der sichere Flugbetrieb, klar logisch aber dieser Kompromiss ist ja heute garnicht erforderlich!
Ihr habt doch problematische iXJT Module im Zugriff. Hat mal jemand gemessen, wie weit die weggedriftet sind? Mit der neuen Firmware von FrSky werden die zwar noch gefangen, aber interessieren würde es mich schon. Dass das Problem generell nur bei neuen Sendern auftritt, ist euch doch aufgefalen, oder?
