FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Kann sein, wird bestimmt noch spannend werden ...
Es wurden zwar überwiegend Probleme mit der Horus gemeldet, alle anderen Sender waren aber auch beteiligt. Vermutlich kann man das nicht an einem Modell festmachen. Es wurde auch berichtet, dass nach dem Austausch des HF-Moduls alles ok war und es später wieder zu Problemen kam.
Das ist einfach typisch für Foren. Egal zu welchem Themenbereich ein Forum exisitiert.
Es wurden zwar überwiegend Probleme mit der Horus gemeldet, alle anderen Sender waren aber auch beteiligt. Vermutlich kann man das nicht an einem Modell festmachen. Es wurde auch berichtet, dass nach dem Austausch des HF-Moduls alles ok war und es später wieder zu Problemen kam.
Das ist einfach typisch für Foren. Egal zu welchem Themenbereich ein Forum exisitiert.
Ich hatte schon mal geschrieben, daß man einen eventuellen, zusätzlichen, Horus-spezifischen Fehler erst vernünftig isolieren kann, wenn die zwei bekannten updates (AFC + CRC) drin sind.
Wenn überhaupt, so hat dieser Horus-Fehler ganz ähnliche Symptome.
Oder hat hier jemand konkret andere Erfahrung?
Wenn überhaupt, so hat dieser Horus-Fehler ganz ähnliche Symptome.
Oder hat hier jemand konkret andere Erfahrung?
Ob der Fehler beim R-XSR wirklich weg ist, wird sich erst mit der Zeit erweisen. Bei den derzeitigen Temperaturen und Wetterbedingungen halten sich die Flugstunden in engen Grenzen.
Und @Carbonator, der Horus-Sender ist nur einer von vielen betroffenen Typen. Auch mein X-Lite fällt darunter.
Mein zweiter Empfänger, der XM+, der auch neben dem Lockout den falschen Kanalwert produziert, der wartet noch auf sein Update.
Ich gehe davon aus dass mein R-XSR nach dem Update immer noch Lockouts zeigen wird, im gleichen Rahmen wie der XM+ und nicht mehr an die zehnmal häufiger, so wie bisher.
Das verbleibende Kanalwert- und Lockout-Problem hat aus meiner Sicht dieselbe Ursache. Möglicherweise entscheidet die Prozessorarchitektur des Empfängers darüber, ob vor dem Lockout ein falscher Kanalwert produziert wird oder nicht. Wohlgemerkt, der XM+ basiert auf einem 8051-Prozessor, der R-XSR auf einem STM32-Prozessor, entsprechend unterscheidet sich auch die Firmware der Signalverarbeitung.
Gruß Gerd
Und @Carbonator, der Horus-Sender ist nur einer von vielen betroffenen Typen. Auch mein X-Lite fällt darunter.
Mein zweiter Empfänger, der XM+, der auch neben dem Lockout den falschen Kanalwert produziert, der wartet noch auf sein Update.
Ich gehe davon aus dass mein R-XSR nach dem Update immer noch Lockouts zeigen wird, im gleichen Rahmen wie der XM+ und nicht mehr an die zehnmal häufiger, so wie bisher.
Das verbleibende Kanalwert- und Lockout-Problem hat aus meiner Sicht dieselbe Ursache. Möglicherweise entscheidet die Prozessorarchitektur des Empfängers darüber, ob vor dem Lockout ein falscher Kanalwert produziert wird oder nicht. Wohlgemerkt, der XM+ basiert auf einem 8051-Prozessor, der R-XSR auf einem STM32-Prozessor, entsprechend unterscheidet sich auch die Firmware der Signalverarbeitung.
Gruß Gerd
Die Vernunft sollte einem doch sagen, dass man erstmal die kleine Lösung probiert, also die Sender untersucht, die das Problem hervorrufen und die auf Vordermann bringt. Und dann erst eine weltweite Aktion startet die die ganze Marke FrSky in Verruf bringt. Wenn ich Horus schreibe, meine ich die betroffenen Sender. Klar kann auch mal eine X9D oder E abweichen und Probleme verursachen. Aber es scheinen doch weit überwiegend nur neuere Sender betroffen.
Lasst uns das Thema erstmal beenden, der Zug ist eh schon abgefahren .... Jetzt wird es Zeit für das Popcorn
Einen hab ich noch
Lasst uns das Thema erstmal beenden, der Zug ist eh schon abgefahren .... Jetzt wird es Zeit für das Popcorn
Einen hab ich noch
Zuletzt bearbeitet:
Die Vernunft sollte einem doch sagen, dass man erstmal die kleine Lösung probiert, also die Sender untersucht, die das Problem hervorrufen und die auf Vordermann bringt. Und dann erst eine weltweite Aktion startet die die ganze Marke FrSky in Verruf bringt. Wenn ich Horus schreibe, meine ich die betroffenen Sender. Klar kann auch mal eine X9D oder E abweichen und Probleme verursachen. Aber es scheinen doch weit überwiegend nur neuere Sender betroffen.
Lasst uns das Thema erstmal beenden, der Zug ist eh schon abgefahren .... Jetzt wird es Zeit für das Popcorn
Einen hab ich noch
Lasst uns das Thema erstmal beenden, der Zug ist eh schon abgefahren .... Jetzt wird es Zeit für das Popcorn
Einen hab ich noch
Es sprechen doch nur Leute über das Problem wenn man sich 100% IG sicher ist das das oder die aufgetretenen Probleme nicht an irgendwelchen anderen äußeren Einflüssen gelegen haben. Ich kenne einige Leute, mich eingeschlossen,die mit ihren Modellen runtergefallen sind und/oder oft in der Luft nicht nachvollziehbare Steuerreaktionen hatten, diese aber nicht auf Defekte Rc-Komponenten schieben wollen weil eben andere Fehler nicht auszuschließen sind .
Genau dies meine ich auch mit "komisches Gefühl" den genau diese Dinge waren mir zB vorher fremd!
Ich bin davon überzeugt dass es genau aus diesem Grund eine sehr hohe Zahl an Problemfälle-Dunkelziffer gibt, besonders vor dem Hintergrund das ja meistens sehr viele schöne Flüge gemacht wurden.
Wenn ich meinen Kunstflugheli Diabolo mit FrSky geflogen wäre dann hätte ich die aufgetreten Fehler nahezu sicher dem RC System zuordnen können, der fliegt auch bei Wind extrem stabil und reproduzierbar aber das war mir seit Frsky-Benutzung im Frühjahr viel zu gefährlich!
Die Fehlerhäufigkeit konzentriert sich auf Horus Sender aber andere Sender werden auch oft genug in dem Zusammenhang genannt.
Carbo, warum so aggressiv?
Nur weil sich nicht jeder deiner Meinung anschließt, die nicht einmal untermauert ist?
Andere, die klare Beweise haben werden, werden ignoriert oder das Wort im Mund verdreht.
Bis du wirklich der Ansicht das ein starkes Behauptung besser ist ein Beweis?
Eigentlich bin ich es leid mir ständig die Finger wund zu schreiben, um Dinge für andere gerade zu rücken.
Wie kommst du auf die Idee, nur Horus wäre betroffen? Ich stehe im Kontakt mit Taranis, X_lite, X-Lite pro, Horus X10 und Horus X12 Nutzern, die alle das gleiche Problem haben.
Ich kann von mir nur zum wohl 10.Mal sagen, daß das Problem mit dem HF-Teil wandert.
Aber worüber regst du dich eigentlich auf???
Über FrSky - das verstehe ich - das ist wirklich diletantisch, was die seit Monaten abziehen.
Aber sonst? Wen greifst du warum an - nur weil du es nicht glaubst oder ein Gefühl hast oder du kein Problem mit deiner Anlage hast und darum alles falsch ist?
Ich hatte auch 1,5 Jahre kein Problem und jetzt seit einem 1/2 JAhr kein Problem, trotzdem waren die Probleme temporär vorhanden.
Ich persönlich bin heilfroh, dass jemand eine Möglichkeit fand, das Problem nachzustellen ( ist uns beiden nicht gelungen ) und auch die Ursache ermittelte.
Für mich ist das alles logisch und technisch nachvollziehbar. Ich habe die realen Messdaten überprüft und mit einfacherem, kostengünstigen Material die Angaben nachgestellt und bestätigen können.
Norbert
Nur weil sich nicht jeder deiner Meinung anschließt, die nicht einmal untermauert ist?
Andere, die klare Beweise haben werden, werden ignoriert oder das Wort im Mund verdreht.
Bis du wirklich der Ansicht das ein starkes Behauptung besser ist ein Beweis?
Eigentlich bin ich es leid mir ständig die Finger wund zu schreiben, um Dinge für andere gerade zu rücken.
Wie kommst du auf die Idee, nur Horus wäre betroffen? Ich stehe im Kontakt mit Taranis, X_lite, X-Lite pro, Horus X10 und Horus X12 Nutzern, die alle das gleiche Problem haben.
Ich kann von mir nur zum wohl 10.Mal sagen, daß das Problem mit dem HF-Teil wandert.
Aber worüber regst du dich eigentlich auf???
Über FrSky - das verstehe ich - das ist wirklich diletantisch, was die seit Monaten abziehen.
Aber sonst? Wen greifst du warum an - nur weil du es nicht glaubst oder ein Gefühl hast oder du kein Problem mit deiner Anlage hast und darum alles falsch ist?
Ich hatte auch 1,5 Jahre kein Problem und jetzt seit einem 1/2 JAhr kein Problem, trotzdem waren die Probleme temporär vorhanden.
Ich persönlich bin heilfroh, dass jemand eine Möglichkeit fand, das Problem nachzustellen ( ist uns beiden nicht gelungen ) und auch die Ursache ermittelte.
Für mich ist das alles logisch und technisch nachvollziehbar. Ich habe die realen Messdaten überprüft und mit einfacherem, kostengünstigen Material die Angaben nachgestellt und bestätigen können.
Norbert
Hallo,
ich selbst fliege nur X9D+ und ältere X-Empfänger. Nie ein Problem.
Aber, im Hobby-Keller, ohne störende Geräusche, wobei ich die Anlage relativ häufig für andere Untersuchung in Betrieb habe, bemerkte ich seit 2014 alle paar Tage mal dieses kurze Servo-Knacken, also ob es ganz kurz mit vollem Strom anläuft, aber nicht wirklich positioniert. Mit allen Kanal-Mischern MAX0%, und Failsafe 0% ist das bei einwandfreier Anlage vom Prinzip her technisch unmöglich.
Ich wusste da ist was., aber hatte keine Idee wo anzufangen.
Nachdem ich dieses Jahr immer wieder, vor allem von Norbert, über diese Servoausschläge gelesen hatte, zwang mich mein Ehrgeiz dem nachzugehen, auch wenn ich überhaupt nicht betroffen war.
Firma Engel hat mir dazu freundlicher Weise verschiedene HW ausgeliehen.
Ich programmierte mir einen STM32 und scanne damit den SBUS und die Servo-Ausgänge eines Empfängers auf Werte/Impulse die nicht sein dürften. Im Falle des Falles liefert der STM32 ein Trigger-Signal, womit ein LA losläuft und SBUS und PWMs aufzeichnet, 1s dem Trigger, voraus.
Die erste Aufzeichnung war für mich das Deja-Vu der seltsamen Servo-Knack-Geräusche über all die Jahre zuvor.
Wer die Saleae SW installiert hat kann sich den Log anschauen (X6R, CH3.pdf ändern in X6R, CH3.logicdata). Trace 0-5 sind die X6R Servo-Ausgänge, Trace 6 ist das Trigger-Signal, Trace 7 ist der decodierte SBUS als serielles Signal in byte-Paaren. Servo 3 hat für 2 Frames abrupten Aussschlag von 1,50 auf 1,83ms.
Die Häufigkeit dieser kurzen Fehler steht direkt im Zusammenhang mit Störquellen/anderen Teilenehmern im 2,4GHz Band. Ein WLAN im Videostreaming in unmittelbarer Nähe macht schon einen großen Unterschied.
Neben den kurzen Fehlern kommt es in, dazu verglichen, seltenen Fällen zu einem eingefrorenen Zustand über 0.9s. Es gibt keine fließenden Übergang, entweder kurz oder selten 0.9s. Siehe Log X6R, CH2, 1s. Ich vermute die Ursache in fehlerhaften Kontrollbits, nicht nur in Servowerten.
Die Ursachen dazu sind mittlerweile hinreichend beschrieben und sind durch die Art der Lösung direkt bestätigt. Obwohl ich außer den kurzen, "nicht spürbaren" Datenfehlern nie ein Problem hatte, fliege ich nicht mehr mit diesem Bug und dem potentiellen Risiko. Das kann jeder machen wie er will.
Gruß
Ewald
ich selbst fliege nur X9D+ und ältere X-Empfänger. Nie ein Problem.
Aber, im Hobby-Keller, ohne störende Geräusche, wobei ich die Anlage relativ häufig für andere Untersuchung in Betrieb habe, bemerkte ich seit 2014 alle paar Tage mal dieses kurze Servo-Knacken, also ob es ganz kurz mit vollem Strom anläuft, aber nicht wirklich positioniert. Mit allen Kanal-Mischern MAX0%, und Failsafe 0% ist das bei einwandfreier Anlage vom Prinzip her technisch unmöglich.
Ich wusste da ist was., aber hatte keine Idee wo anzufangen.
Nachdem ich dieses Jahr immer wieder, vor allem von Norbert, über diese Servoausschläge gelesen hatte, zwang mich mein Ehrgeiz dem nachzugehen, auch wenn ich überhaupt nicht betroffen war.
Firma Engel hat mir dazu freundlicher Weise verschiedene HW ausgeliehen.
Ich programmierte mir einen STM32 und scanne damit den SBUS und die Servo-Ausgänge eines Empfängers auf Werte/Impulse die nicht sein dürften. Im Falle des Falles liefert der STM32 ein Trigger-Signal, womit ein LA losläuft und SBUS und PWMs aufzeichnet, 1s dem Trigger, voraus.
Die erste Aufzeichnung war für mich das Deja-Vu der seltsamen Servo-Knack-Geräusche über all die Jahre zuvor.
Wer die Saleae SW installiert hat kann sich den Log anschauen (X6R, CH3.pdf ändern in X6R, CH3.logicdata). Trace 0-5 sind die X6R Servo-Ausgänge, Trace 6 ist das Trigger-Signal, Trace 7 ist der decodierte SBUS als serielles Signal in byte-Paaren. Servo 3 hat für 2 Frames abrupten Aussschlag von 1,50 auf 1,83ms.
Die Häufigkeit dieser kurzen Fehler steht direkt im Zusammenhang mit Störquellen/anderen Teilenehmern im 2,4GHz Band. Ein WLAN im Videostreaming in unmittelbarer Nähe macht schon einen großen Unterschied.
Neben den kurzen Fehlern kommt es in, dazu verglichen, seltenen Fällen zu einem eingefrorenen Zustand über 0.9s. Es gibt keine fließenden Übergang, entweder kurz oder selten 0.9s. Siehe Log X6R, CH2, 1s. Ich vermute die Ursache in fehlerhaften Kontrollbits, nicht nur in Servowerten.
Die Ursachen dazu sind mittlerweile hinreichend beschrieben und sind durch die Art der Lösung direkt bestätigt. Obwohl ich außer den kurzen, "nicht spürbaren" Datenfehlern nie ein Problem hatte, fliege ich nicht mehr mit diesem Bug und dem potentiellen Risiko. Das kann jeder machen wie er will.
Gruß
Ewald
Zuletzt bearbeitet:
Nachtrag zu Log X6R, CH3.
Die zwei Trigger Impulse weisen darauf hin, daß neben Servo 3 auch Servo 8 einen falschen Wert hat, welcher aber nicht als PWM herausgeführt ist.
Genausogut wie Servo-Werte können natürlich auch auch irgendwelche Kontrollbits fehlerhaft sein, und den Empfänger komplett aus dem Tritt, sprich aus der Synchronisation werfen. Ein watchdog timeout findet nicht statt, ich vermute aber daß der Empfänger auf Grund eines nicht definierten Zustandes einen soft-reset macht.
Die zwei Trigger Impulse weisen darauf hin, daß neben Servo 3 auch Servo 8 einen falschen Wert hat, welcher aber nicht als PWM herausgeführt ist.
Genausogut wie Servo-Werte können natürlich auch auch irgendwelche Kontrollbits fehlerhaft sein, und den Empfänger komplett aus dem Tritt, sprich aus der Synchronisation werfen. Ein watchdog timeout findet nicht statt, ich vermute aber daß der Empfänger auf Grund eines nicht definierten Zustandes einen soft-reset macht.
Zuletzt bearbeitet:
Aufgrund des angesprochenen Problems mit dem FrSky Equipment wollte ich mit recht einfachen Mitteln das Risiko minimieren. Wozu gibt es denn die Redunanzempfänger. Mit einem zusätzlichen XM+ zum RX8R könnte ich mich sicherer fühlen, wenn ich wüsste dass ein zeitgleicher Lockout beider Empfänger sehr viel unwahrscheinlicher wäre als bei einem einzelnen Empfänger.
Hat hier einer eine Idee ob dem so wäre?
Ansonsten würde ich den XM+ über ein externes Multiprotokollmodul betreiben und den RX8R über das interne Sendemodul. Bei zwei komplett separaten HF Links müssten die Ausfallrisiken ja unabhängig von einander sein und ließen sich so einfach miteinander multiplizieren.
Hat hier einer eine Idee ob dem so wäre?
Ansonsten würde ich den XM+ über ein externes Multiprotokollmodul betreiben und den RX8R über das interne Sendemodul. Bei zwei komplett separaten HF Links müssten die Ausfallrisiken ja unabhängig von einander sein und ließen sich so einfach miteinander multiplizieren.
Mit einer RB sollte die Redundanz funktionieren. Ohne aber eher nicht, denn wenn sich der Master-Empfänger weghängt, kommen die Signale vom redundanten Empfänger höchstwahrscheinlich auch nicht mehr durch.
Die RB würde in dem Fall auf den zweiten Empfänger umschalten.
Aber wenn du bisher keine Probleme hattest, würde ich auch nicht rumstressen. Selbst wenn dich der Ausschlag mal trifft, muss es schön ziemlich blöd kommen, damit es kracht. Dann weißt du aber genau, dass etwas faul ist und kannst etwas unternehmen.
Die RB würde in dem Fall auf den zweiten Empfänger umschalten.
Aber wenn du bisher keine Probleme hattest, würde ich auch nicht rumstressen. Selbst wenn dich der Ausschlag
mal trifft, muss es schön ziemlich blöd kommen, damit es kracht. Dann weißt du aber genau, dass etwas faul ist und kannst etwas unternehmen.Seht euch die Daten mit Hilfe der Salea Software an, vielleicht versteht ihr dann besser. Danke an Ewald, dass du sie zur Verfügung stellst. Das Verhalten des SBus an Index 23, das Frame loss/fail save oder alles ok anzeigt ist etwas seltsam, daher bin ich nicht sicher, ob der RB-10 hilft. Zumal ich nicht weiss, wann RB-10 umschaltet.
Die Option auf RB umzusteigen habe ich leider nicht. Ein 700er Heli bietet zwar Platz, aber soviel dann nun auch wieder nicht.
Ich hatte bisher Probleme, die zwei Crashes wegen Empfänger Failsafe haben mich mehr gekostet als meine X9D, X12s und die Xlite Pro zusammen. Da ich aber keine Alternativen zu OpenTx sehe und mir der Formfaktor der Xlite extrem zusagt werde ich bei FrSky bleiben müssen.
Aber bis die Probleme über die Firmware gelöst werden muss ich ja irgendwie in die Luft gehen können. Deshalb die Frage ob man sich da nicht etwas zusammenstricken könnte über Redundanz mit einem zweiten Sendemodul.
@Norbert Über genau so einen Test würde ich mich sehr freuen. Ansonsten riskiere ich direkt den nächsten Heli
Ich hatte bisher Probleme, die zwei Crashes wegen Empfänger Failsafe haben mich mehr gekostet als meine X9D, X12s und die Xlite Pro zusammen. Da ich aber keine Alternativen zu OpenTx sehe und mir der Formfaktor der Xlite extrem zusagt werde ich bei FrSky bleiben müssen.
Aber bis die Probleme über die Firmware gelöst werden muss ich ja irgendwie in die Luft gehen können. Deshalb die Frage ob man sich da nicht etwas zusammenstricken könnte über Redundanz mit einem zweiten Sendemodul.
@Norbert Über genau so einen Test würde ich mich sehr freuen. Ansonsten riskiere ich direkt den nächsten Heli
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.
Ü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.
Zuletzt bearbeitet:
