zwei unerklärliche Abstürze
- Themenstarter ronk
- Beginndatum
- Status
Moin,
es kann natürlich sein, dass ein Hardwareproblem die Ursache für die Failsafes ist. Was mich an dieser Hypothese stört, ist, dass die Ausfälle exakt gleich lange gedauert haben. Bei einem Hardwaredefekt wäre das ein sehr großer Zufall. Alle Telemetriewerte, Versorgung etc., sehen ansonsten perfekt aus.
Mal angenommen, diese 1s "Aussetzer" kommen bei allen IXJT Modulen (in großen Intervallen) vor, warum merkt es sonst niemand? Die Aussetzer sind gerade lange genug, um eben Failsafe zu triggern. Kann es sein, dass der Brain nicht schnell genug aus der Failsafe-Prozedur herauskommt, während andere Controller sofort wieder "online" sind? Nach den Logs könnte der Brain Mitverursacher sein.
Wenn der Aussetzer so kurz ist, dann versagt auch der Failsafetest mit der Schraube auf dem Rotorblatt, weil das Servo gar nicht genug Zeit hat, um die Failsafeposition anzufahren.
Wie könnte man das überprüfen?
- die Empfänger LED beobachten, aber das ist eher ätzend
- einen LostFramesCounter loggen -die Telemetrie ist zwar auch kurz off, aber den Aussetzer würde man sehen, weil der Durchschnitt über 1s gebildet wird - so ein Teil könnte ich dir leihen
- eventuell kann man mit dem Brain + PC loggen
Die Firmware + Brain Hypothese ist gewagt, ich weiß. Ansonsten bleibt noch das Bluetooth Modul, welches die Funkverbindung bei bestimmten Hopping-Konstellationen abgegrätscht haben könnte. Auch dies sollte reproduzierbar sein. War das Modul bei allen Crashs aktiv?
es kann natürlich sein, dass ein Hardwareproblem die Ursache für die Failsafes ist. Was mich an dieser Hypothese stört, ist, dass die Ausfälle exakt gleich lange gedauert haben. Bei einem Hardwaredefekt wäre das ein sehr großer Zufall. Alle Telemetriewerte, Versorgung etc., sehen ansonsten perfekt aus.
Mal angenommen, diese 1s "Aussetzer" kommen bei allen IXJT Modulen (in großen Intervallen) vor, warum merkt es sonst niemand? Die Aussetzer sind gerade lange genug, um eben Failsafe zu triggern. Kann es sein, dass der Brain nicht schnell genug aus der Failsafe-Prozedur herauskommt, während andere Controller sofort wieder "online" sind? Nach den Logs könnte der Brain Mitverursacher sein.
Wenn der Aussetzer so kurz ist, dann versagt auch der Failsafetest mit der Schraube auf dem Rotorblatt, weil das Servo gar nicht genug Zeit hat, um die Failsafeposition anzufahren.
Wie könnte man das überprüfen?
- die Empfänger LED beobachten, aber das ist eher ätzend
- einen LostFramesCounter loggen -die Telemetrie ist zwar auch kurz off, aber den Aussetzer würde man sehen, weil der Durchschnitt über 1s gebildet wird - so ein Teil könnte ich dir leihen
- eventuell kann man mit dem Brain + PC loggen
Die Firmware + Brain Hypothese ist gewagt, ich weiß. Ansonsten bleibt noch das Bluetooth Modul, welches die Funkverbindung bei bestimmten Hopping-Konstellationen abgegrätscht haben könnte. Auch dies sollte reproduzierbar sein. War das Modul bei allen Crashs aktiv?
Hy ronk,
schönes Bild, aber:
Bau doch mal die Antennen in Richtung Kufen ein, frei nach unten, eine links, eine rechts
und kein scharfes abknicken, das sind Koaxialkabel!
Schließlich müssen sich die Sender und Empfängeantennen "sehen" können
Der Heli ist oben, der Sender ist unten
Alles aus Metall oder Kohle schirmt ab!
Je nächer die Antennen am Metall desto schlimmer!
Testweise getrennte Stromversorgungen von Antrieb und Empfänger+Brain
Testweise 4700uF/16V und 5A-10A Shottky-Diode als Stütze für Empfänger + Brain
um BEC und Antieb zu entkoppeln
Empfängerspannung loggen
Akku Einzelzellen loggen
Akku Strom loggen
BEC Strom loggen
Wer den sporadischen Fehler nicht kennt muss systematisch messen und testen, vermuten hilft nicht.
schönes Bild, aber:
Bau doch mal die Antennen in Richtung Kufen ein, frei nach unten, eine links, eine rechts
und kein scharfes abknicken, das sind Koaxialkabel!
Schließlich müssen sich die Sender und Empfängeantennen "sehen" können
Der Heli ist oben, der Sender ist unten
Alles aus Metall oder Kohle schirmt ab!
Je nächer die Antennen am Metall desto schlimmer!
Testweise getrennte Stromversorgungen von Antrieb und Empfänger+Brain
Testweise 4700uF/16V und 5A-10A Shottky-Diode als Stütze für Empfänger + Brain
um BEC und Antieb zu entkoppeln
Empfängerspannung loggen
Akku Einzelzellen loggen
Akku Strom loggen
BEC Strom loggen
Wer den sporadischen Fehler nicht kennt muss systematisch messen und testen, vermuten hilft nicht.
Anhänge
Zuletzt bearbeitet:
Da kann ich ehrlich gesagt, nicht mehr folgen.
Er hat doch gemessen. Im Flug, während der Failsafes, bessere Daten kann man doch gar nicht bekommen. Man sieht eindeutig an den Telemetriedaten, dass RSSI, RxBt, Strom, usw. im grünen Bereich sind. Trotzdem friert die Verbindung für 1 s ein. Warum jetzt drei Schritte zurückgehen, anstatt sich Gedanken über den klar zu sehenden Ausfall zu machen, die verschiedenen Hypothesen abzuarbeiten, um so die Ursache herauszufinden?
Die Antennen sind perfekt verlegt, RSSI ist perfekt, Stromversorgung ist perfekt, einen Usererror kann man sehr wahrscheinlich ausschließen.... Das sind hervorragende Voraussetzungen, um einem vermutlich außergewöhnlichen Fehler zu detektieren.
Er hat doch gemessen. Im Flug, während der Failsafes, bessere Daten kann man doch gar nicht bekommen. Man sieht eindeutig an den Telemetriedaten, dass RSSI, RxBt, Strom, usw. im grünen Bereich sind. Trotzdem friert die Verbindung für 1 s ein. Warum jetzt drei Schritte zurückgehen, anstatt sich Gedanken über den klar zu sehenden Ausfall zu machen, die verschiedenen Hypothesen abzuarbeiten, um so die Ursache herauszufinden?
Die Antennen sind perfekt verlegt, RSSI ist perfekt, Stromversorgung ist perfekt, einen Usererror kann man sehr wahrscheinlich ausschließen.... Das sind hervorragende Voraussetzungen, um einem vermutlich außergewöhnlichen Fehler zu detektieren.
Hallo zusammen,
vielen Dank für eure Antworten. Das Brain braucht schon ein paar Sekunden zum Initialisieren. Aber ich denke nicht, daß das im Flug überhaupt funktioniert, beim Initialisieren möchte das Teil still stehen. Wird es bewegt, initialisiert es nicht. Nach allen Abstürzen war das Brain in voller Bereitschaft, alles funktionierte, so wie es sollte, deutet darauf hin, daß das Brain die ganze Zeit durchgelaufen ist.
Das BT-Modul war immer aktiv, das hängt da dran und fliegt immer mit. Wäre eine Möglichkeit, es mal ohne BT-Modul zu testen...
Die Antennenverlegung: Es geht etwas eng zu im TDR. So, wie die Antennen sind, ist es im Handbuch als die beste Lösung beschrieben. Wenn ich die Antennen nach unten verlege, sind sie wieder oft durch die ziemlich großen Carbon-Kufenplatten abgeschattet, nicht ideal... Scharfes Abknicken: Das Bild täuscht etwas, da ist kein scharfer Knick drin, gebogen ist das Kabel aber. Ich versuche mal, die Empfängerantennen noch etwas weiter aus den Röhrchen raus zu schieben, die abisolierten Enden sind doch noch etwas im Bogen...
Aber ehrlich, ist der Empfänger so sehr empfindlich auf solche Kleinigkeiten? Die Qualität der Verbindung (RSSI) im Log ist doch okay, oder? Stromversorgung passt, Reichweitentest bei 30m um 45... Wie schon geschrieben, vorher mit dem Futaba-Zeugs war das alles kein Thema. Eingebaut, fliegen, nicht mehr dran denken... Bin ich wirklich der Einzige mit diesem Fehler? Fliegt sonst niemand nen Heli?
PS: beim letzten Failsafe war der Heli im Rückenflug, beste Sicht auf die Antennen. BEC und ESC sind getrennt.
vielen Dank für eure Antworten. Das Brain braucht schon ein paar Sekunden zum Initialisieren. Aber ich denke nicht, daß das im Flug überhaupt funktioniert, beim Initialisieren möchte das Teil still stehen. Wird es bewegt, initialisiert es nicht. Nach allen Abstürzen war das Brain in voller Bereitschaft, alles funktionierte, so wie es sollte, deutet darauf hin, daß das Brain die ganze Zeit durchgelaufen ist.
Das BT-Modul war immer aktiv, das hängt da dran und fliegt immer mit. Wäre eine Möglichkeit, es mal ohne BT-Modul zu testen...
Die Antennenverlegung: Es geht etwas eng zu im TDR. So, wie die Antennen sind, ist es im Handbuch als die beste Lösung beschrieben. Wenn ich die Antennen nach unten verlege, sind sie wieder oft durch die ziemlich großen Carbon-Kufenplatten abgeschattet, nicht ideal... Scharfes Abknicken: Das Bild täuscht etwas, da ist kein scharfer Knick drin, gebogen ist das Kabel aber. Ich versuche mal, die Empfängerantennen noch etwas weiter aus den Röhrchen raus zu schieben, die abisolierten Enden sind doch noch etwas im Bogen...
Aber ehrlich, ist der Empfänger so sehr empfindlich auf solche Kleinigkeiten? Die Qualität der Verbindung (RSSI) im Log ist doch okay, oder? Stromversorgung passt, Reichweitentest bei 30m um 45... Wie schon geschrieben, vorher mit dem Futaba-Zeugs war das alles kein Thema. Eingebaut, fliegen, nicht mehr dran denken... Bin ich wirklich der Einzige mit diesem Fehler? Fliegt sonst niemand nen Heli?
PS: beim letzten Failsafe war der Heli im Rückenflug, beste Sicht auf die Antennen. BEC und ESC sind getrennt.
Meine Vermutung zum Brain war nicht, dass es komplett aussteigt, sondern dass es nach der Failsafe Meldung über den SBus zu lange die eigenen Failsafe Maßnahmen durchführt, anstatt sofort wieder in den Normalbetrieb zurückzukehren, wenn der Failsafe vom Rx aufgehoben wird. Das könntest du testen, indem du den TX im Rangemode in seine Alukiste sperrst (--> Failsafe), dann die Kiste öffnest und schaust, wie lange das Brain braucht, um den Failsafe wieder aufzuheben. Der RX hebt den Failsafe unvermittelt auf. Der eigentliche Fehler ist natürlich, dass überhaupt ein Failsafe für 1s gemeldet wird (bzw. die Verbindung 1s einfriert).
Ist in deinem anderen, funktionierenden Heli ein Brain und/oder Bluetooth verbaut?
Ist in deinem anderen, funktionierenden Heli ein Brain und/oder Bluetooth verbaut?
okay, jetzt hab ich verstanden. Ich habe keine Ahnung, ob das Brain überhaupt irgendwelche Maßnahmen trifft, wenn die Funkverbindung abreißt. Aber du hast recht, das gilt es rauszufinden. Ich habe noch zwei Helis mit Brain und X4RSB. Ein 450er Chinaclown, ohne BT (funktioniert problemlos) und einen Goblin 570, der hat ein BT-Modul dran (funktioniert bis jetzt auch problemlos). Alle Helis sind über SBUS mit dem Brain verbunden.
Danke Blade Breaker, stimmt, hilft erstmal nicht, trotzdem schön zu hören, dass ich nicht der einzige Helipilot hier bin. Tja, meine anderen Helis fliegen ja auch. Kann es auch Zufall sein, daß es aller paar Wochen nur immer den TDR trifft?
Danke Blade Breaker, stimmt, hilft erstmal nicht, trotzdem schön zu hören, dass ich nicht der einzige Helipilot hier bin. Tja, meine anderen Helis fliegen ja auch. Kann es auch Zufall sein, daß es aller paar Wochen nur immer den TDR trifft?
D
Hi,
hab zwar keinen blassen schimmer von Helis...
aber schon mal über einen Kabelbruch defekten Stecker oder eine Kalte gebrochene Lötstelle nachgedacht ?
Wenn alle anderen Modelle bei Dir funktionieren kannst du die Horus schon mal ausschließen, also muss ja was an dem Modell anders oder defekt sein, so wie du schreibst hast du ja mehrere gleiche Setups, im schlimmsten fall Teil für Teil Tauschen und den defekt im Ausschlussverfahren suchen...
hab zwar keinen blassen schimmer von Helis...
aber schon mal über einen Kabelbruch defekten Stecker oder eine Kalte gebrochene Lötstelle nachgedacht ?
Wenn alle anderen Modelle bei Dir funktionieren kannst du die Horus schon mal ausschließen, also muss ja was an dem Modell anders oder defekt sein, so wie du schreibst hast du ja mehrere gleiche Setups, im schlimmsten fall Teil für Teil Tauschen und den defekt im Ausschlussverfahren suchen...
Nachdem die Funkverbindung für etwas mehr als 1s weg war (schwarzes Rechteck = Failsafe)), wurde der Motor abgeschaltet. Dann dauert es noch 6 Sekunden, bis die Höhe (30m) abgebaut war. Der Rotor hatte wohl noch genug Drehzahl, um die Fluglage zu korrigieren. Die Steuerbewegungen sieht man ebenfalls in der Telemetrie. Wieso lief aber der Motor nicht schneller hoch? Die Rotordrehzahl nimmt ja wegen der gespeicherten Rotationsenergie nur sehr langsam ab, das heißt, der Motor musste beim Wiederhochlaufen nur sich selbst beschleunigen. Ist das der programmierte Sanftanlauf, den man im Diagramm (rotes Rechteck) sieht? Wäre es nicht besser, nach einem Failsafe, sofort wieder die Solldrehzahl anzufahren, ohne Sanftanlauf? Der Heli wäre so locker zu fangen gewesen.
Keine Ahnung, ob man das umsetzen kann, aber es wäre doch für den Failsafe Fall, wie in diesem Beispiel, unbedingt sinnvoll.
Keine Ahnung, ob man das umsetzen kann, aber es wäre doch für den Failsafe Fall, wie in diesem Beispiel, unbedingt sinnvoll.
Hi Zusammen,
ich habe div. Helis mit verschiedenen Empfängern (X6R, X8R, XM+, XSR) und Stabis (Mini VStabi, VStabi, Beast, Turnigy Cyclone) im Einsatz und hatte bisher noch nie so ein Problem.
Allerdings hatte ich einen X6R der ab Werk nicht richtig funktionierte, also auch Funkaussetzer.
Tausch doch einfach mal den Empfänger gegen einen X8R.
VG
Bebo
ich habe div. Helis mit verschiedenen Empfängern (X6R, X8R, XM+, XSR) und Stabis (Mini VStabi, VStabi, Beast, Turnigy Cyclone) im Einsatz und hatte bisher noch nie so ein Problem.
Allerdings hatte ich einen X6R der ab Werk nicht richtig funktionierte, also auch Funkaussetzer.
Tausch doch einfach mal den Empfänger gegen einen X8R.
VG
Bebo
Hallo,
jetzt hänge ich mich auch mal dazwischen.
Wie meistens trifft Helles Ansicht auch meine. Ich fliege viele Helis, darunter 3 Stück 700.
1) Ich hatte mit einem ähnlichen Antennensetup Feldstärke Warnungen, da die Antennen komplett verdeckt werden. Ich habe jetzt die Antennen in Röhrchen am linken und rechten Fahrwerksfuß 1cm vor dem Lande Alurohr endend.
2) BEC: Ich verwende Mikado FBL Regler. Ich hatte einen 20A BEC, der gemesssen 24A Dauerstrom brachte. Dann auf der Werkbank den VStabi Regler im nicht eingebauten Zustand schnell geschüttelt und gedreht, dass alles Servos Samba tanzten. Das VStabi ist ausgestiegen und nach 2 sec war es wieder da. Mit Scope gemessen, BEC brach auf 3,7V ein - FBL black out.
Ursache: die heutigen schnellen und kräftigen Servos ziehen kurzzeitig ( msec Bereich ) unglaubliche Ströme , die das ungepufferte BEC zusammenbrechen lassen. LÖSUNG: Puffern - entweder mit dicken low ESR Kondensatoren ( dürfen gerne 10.000uF/10V sein ) oder besser zusätzlich Pufferkondensatoren, ich glaube GrennCap heissen die, 3 x 25F (kein Schreibfehler ) 2,7V. die werden in Reihe geschalten und haben dann ~8F und 8V. Damit laufen meine Servos ohne Spannungsversorgung noch gut 10 sec. Die habe ich gnadenlos in die Leitung des BEC´s zum VStabi gehängt. Dauert zwar ~ 1-2 sec nach einstecken des Akuus bis es läuft, dann aber superstabile Spannungsversorgung. Habe auch mit Ennelop usw rumgemacht - vergiss es, die brechen ein.
Siehe dir dazu auch http://www.vstabi.info/de/node/1316 an, dort wird umfassend das Thema Stromversorgung abgehandelt.
Norbert
jetzt hänge ich mich auch mal dazwischen.
Wie meistens trifft Helles Ansicht auch meine. Ich fliege viele Helis, darunter 3 Stück 700.
1) Ich hatte mit einem ähnlichen Antennensetup Feldstärke Warnungen, da die Antennen komplett verdeckt werden. Ich habe jetzt die Antennen in Röhrchen am linken und rechten Fahrwerksfuß 1cm vor dem Lande Alurohr endend.
2) BEC: Ich verwende Mikado FBL Regler. Ich hatte einen 20A BEC, der gemesssen 24A Dauerstrom brachte. Dann auf der Werkbank den VStabi Regler im nicht eingebauten Zustand schnell geschüttelt und gedreht, dass alles Servos Samba tanzten. Das VStabi ist ausgestiegen und nach 2 sec war es wieder da. Mit Scope gemessen, BEC brach auf 3,7V ein - FBL black out.
Ursache: die heutigen schnellen und kräftigen Servos ziehen kurzzeitig ( msec Bereich ) unglaubliche Ströme , die das ungepufferte BEC zusammenbrechen lassen. LÖSUNG: Puffern - entweder mit dicken low ESR Kondensatoren ( dürfen gerne 10.000uF/10V sein ) oder besser zusätzlich Pufferkondensatoren, ich glaube GrennCap heissen die, 3 x 25F (kein Schreibfehler ) 2,7V. die werden in Reihe geschalten und haben dann ~8F und 8V. Damit laufen meine Servos ohne Spannungsversorgung noch gut 10 sec. Die habe ich gnadenlos in die Leitung des BEC´s zum VStabi gehängt. Dauert zwar ~ 1-2 sec nach einstecken des Akuus bis es läuft, dann aber superstabile Spannungsversorgung. Habe auch mit Ennelop usw rumgemacht - vergiss es, die brechen ein.
Siehe dir dazu auch http://www.vstabi.info/de/node/1316 an, dort wird umfassend das Thema Stromversorgung abgehandelt.
Norbert
Hy Norbert,
gute Idee Norbert GoldCap bzw GreenCap Kondensatoren zu verwenden,
die speichern wirklich und können sehr sehr hohe Ströme abgeben.
2Stk 1F/5V in Reihe reichen auch schon für 1-2s und sind nicht groß
3Stk 25F/2,7V in Reihe bauen recht groß und sind teuer
Wenn man die tatsächlihcen Ströme und Spannungen messen will die vom BEC an den Empfänger gehen, mit schütteln, so wie du es gemacht hast
ist das mit den normalen Telemetriestromsensoren nicht möglich, die sind zu langsam und zeigen eine Mittelwert an.
Auch die Spannung wird nicht richtig angezeigt, da auch zu langsam.
Auch eine gute Stromzange ist zu langsman.
Da hilft nur ein Messaufbau mit 0,1Ohm Shunt in der Plusleitung und Oszi oder Hall-Stromsensor für die Stormmmessung
und/oder schnelles Digitalmultimter oder Speicheroszi in Stellung Hold Min.
3+1 DigitalServos, High Tech, im Heli, da fließen für wenigen ms 50A und mehr beim "Schütteltest"
und die mussen auch über den Empfänger und FBL verteilt werden können.
In Ruhe fießen keine 3A 0,5A pro Servo da merkt man nichts.
Messen und Testen hilft!
Bitte auch da nochmal intensiv nachschauen
http://www.vstabi.info/de/node/1316
-->Stützakkus bringen nichts da zu hochohmig bei sehr hohen Strömen!
-->Nur Große Kondensatoren helfen!
-->Große Kondensatoren helfen gegen / puffer Rückströme von div.Servos
Ich hab das mal zusammengefasst
gute Idee Norbert GoldCap bzw GreenCap Kondensatoren zu verwenden,
die speichern wirklich und können sehr sehr hohe Ströme abgeben.
2Stk 1F/5V in Reihe reichen auch schon für 1-2s und sind nicht groß
3Stk 25F/2,7V in Reihe bauen recht groß und sind teuer
Wenn man die tatsächlihcen Ströme und Spannungen messen will die vom BEC an den Empfänger gehen, mit schütteln, so wie du es gemacht hast
ist das mit den normalen Telemetriestromsensoren nicht möglich, die sind zu langsam und zeigen eine Mittelwert an.
Auch die Spannung wird nicht richtig angezeigt, da auch zu langsam.
Auch eine gute Stromzange ist zu langsman.
Da hilft nur ein Messaufbau mit 0,1Ohm Shunt in der Plusleitung und Oszi oder Hall-Stromsensor für die Stormmmessung
und/oder schnelles Digitalmultimter oder Speicheroszi in Stellung Hold Min.
3+1 DigitalServos, High Tech, im Heli, da fließen für wenigen ms 50A und mehr beim "Schütteltest"
und die mussen auch über den Empfänger und FBL verteilt werden können.
In Ruhe fießen keine 3A 0,5A pro Servo da merkt man nichts.
Messen und Testen hilft!
Bitte auch da nochmal intensiv nachschauen
http://www.vstabi.info/de/node/1316
-->Stützakkus bringen nichts da zu hochohmig bei sehr hohen Strömen!
-->Nur Große Kondensatoren helfen!
-->Große Kondensatoren helfen gegen / puffer Rückströme von div.Servos
Ich hab das mal zusammengefasst
Anhänge
Zuletzt bearbeitet:
Die Stromversorgung ist bocksteif. Es gibt hier mehrere tausend Messwerte von RxBT und keinen einzigen, der auch nur den leisesten Verdacht auf eine Instabilität zulässt. Eine "weiche" Stromversorgung würde man in jedem Fall in der Telemetrie sehen, selbst kürzeste Einbrücke wären bei dieser Datenmenge zu sehen.
Die Fehlerkette wurde zwar von einem kurzen Verbindungsabbruch ausgelöst, die eigentliche Absturzursache war aber der Sanftanlauf des Motors. Der Motor muss nach einem Failsafe sofort wieder da sein. Entweder den Sanftanlauf über OpenTX programmieren und den Regler auf Sofortanlauf umstellen. Oder es gibt noch eine andere, elegantere Möglichkeit. Das Thema ist ja sicher nicht neu für die Heliflieger. Dann würde ich relativ sorglos sogar wieder fliegen - aber das ist meine persönliche Bewertung.
Der Verbindungsabbruch sieht im Log exakt so aus, wie die Horus Failsafes vom letzten Jahr.
Hypothese 1: Die Firmware hat immer noch ein Problem beim Kanalhopping, das aber nur noch selten und kurz auftritt und in den meisten Fällen unbemerkt bleibt. FrSky hatte damals richtig Stress und ich schließe es zumindest nicht aus.
Hypothese 2: Im Zusammenspiel von Bluetooth und ACCST kommt es in seltenen Fällen zu einem kurzen Lockout, wenn sich das Frequenzhopping ungünstig überschneidet. Ich fliege auch Modelle mit Bluetooth an Bord und habe da schon immer leichte Bedenken. Bei meinem Flugstil muss ein Failsafe aber schon sehr lange dauern, damit ich ihn überhaupt bemerke. Meine Segler fliegen am Besten ohne mich
Hypothese 3: Hardwareproblem im/am RX --> A....karte gezogen, aber shit happens. Wie wahrscheinlich ist es aber, dass die Lockouts exakt gleich lang sind? Klar, ausschließen kann man es nicht.
Systematische Fehlerursache ist immer der Umgang mit Wahrscheinlichkeiten. Wenn ich Daten habe, die ohne menschliches Zutun ermittelt und gespeichert wurden, traue ich denen erstmal. Im Zweifelsfall muss ich die Datenermittlung verifizieren. Wenn man befürchtet (ich tu´s nicht), dass kurze Spannungseinbrüche von RxBT nie registriert werden, könnte man z.B. eine Wechselspannung mit veränderlicher Frequenz überlagern und prüfen, ab welcher Frequenz RxBT die Änderungen nicht mehr wahrnimmt.
Sicher gibt es noch weitere Hypothesen, aber ich würde immer zuerst schauen, ob sie sich mit den, zum Glück vorhandenen, Daten vereinbaren lassen.
Fehlersuche ist immer sehr spannend, ich hoffe, diese hier führt zu einem Resultat.
Der Verbindungsabbruch sieht im Log exakt so aus, wie die Horus Failsafes vom letzten Jahr.
Hypothese 1: Die Firmware hat immer noch ein Problem beim Kanalhopping, das aber nur noch selten und kurz auftritt und in den meisten Fällen unbemerkt bleibt. FrSky hatte damals richtig Stress und ich schließe es zumindest nicht aus.
Hypothese 2: Im Zusammenspiel von Bluetooth und ACCST kommt es in seltenen Fällen zu einem kurzen Lockout, wenn sich das Frequenzhopping ungünstig überschneidet. Ich fliege auch Modelle mit Bluetooth an Bord und habe da schon immer leichte Bedenken. Bei meinem Flugstil muss ein Failsafe aber schon sehr lange dauern, damit ich ihn überhaupt bemerke. Meine Segler fliegen am Besten ohne mich
Hypothese 3: Hardwareproblem im/am RX --> A....karte gezogen, aber shit happens. Wie wahrscheinlich ist es aber, dass die Lockouts exakt gleich lang sind? Klar, ausschließen kann man es nicht.
Systematische Fehlerursache ist immer der Umgang mit Wahrscheinlichkeiten. Wenn ich Daten habe, die ohne menschliches Zutun ermittelt und gespeichert wurden, traue ich denen erstmal. Im Zweifelsfall muss ich die Datenermittlung verifizieren. Wenn man befürchtet (ich tu´s nicht), dass kurze Spannungseinbrüche von RxBT nie registriert werden, könnte man z.B. eine Wechselspannung mit veränderlicher Frequenz überlagern und prüfen, ab welcher Frequenz RxBT die Änderungen nicht mehr wahrnimmt.
Sicher gibt es noch weitere Hypothesen, aber ich würde immer zuerst schauen, ob sie sich mit den, zum Glück vorhandenen, Daten vereinbaren lassen.
Fehlersuche ist immer sehr spannend, ich hoffe, diese hier führt zu einem Resultat.
Zuletzt bearbeitet:
Carbo zu deiner Hypothese 1
Es ist ja auch nie bekannt geweorden, wie FrSky den Bug gelöst hat. Auf jeden fall sehr schnell und unter Zeitdruck.
Hier werden oft "Notlösungen" gefunden, die nicht die Wahre Ursache beseitigen.
Zum Beispiel werden relevanten Werte vor der Verarbeitung noch mal auf "zulässigen Bereich " geprüft. und bei überschreitung die Weiterverarbeitung blockiert Jetzt kommt es in der nachfolgenden Verarbeitung nicht mehr zu DATAoverflow und Zeitschleifen.
Damit kann mann schnell Fehler übertünchen ohne die Wahre Ursache zu beseitigen. Wird geren gemacht, wenn man so Richtig unter Druck ist.
Das war so die Situation von FrSky.
Ich finde es gut, dass du da so gründlich ans Werk geht. Ich habe mich damals ja von meiner Horusbestellung getrennt und mit dem Ardu Lostzähler meine X9e und x9d getestet. Ich denke, das ist das Richtige Werkzeug, wenn man Fehlern aus dem Sender nachspürt.
Zur Info; meine teste mit zweitem Sender aun Bord
Ein BT Sender im Hubi sollte unkritisch sein. Ich bin Testweise mit einem zweiten System (ACT) im Flieger geflogen. Der ACT Empfänger sendet dabei mit zwei unabhängigen HF Teilen und zwei Antennen mit voller zulässiger Leistung (100 mW nach alter Eu) die Telemetrie Hierbei sehe ich keine Verschlechterung der LostFrams am X8 Empfänger. Auch der ACT Empfänger ist völlig Unbeeindruckt von der Telemetrie des X8. Und der ACT steht dabei auf "Failsave nach 50 ms. (von 30 - 300 ms einstellbar)
Sigi
Es ist ja auch nie bekannt geweorden, wie FrSky den Bug gelöst hat. Auf jeden fall sehr schnell und unter Zeitdruck.
Hier werden oft "Notlösungen" gefunden, die nicht die Wahre Ursache beseitigen.
Zum Beispiel werden relevanten Werte vor der Verarbeitung noch mal auf "zulässigen Bereich " geprüft. und bei überschreitung die Weiterverarbeitung blockiert Jetzt kommt es in der nachfolgenden Verarbeitung nicht mehr zu DATAoverflow und Zeitschleifen.
Damit kann mann schnell Fehler übertünchen ohne die Wahre Ursache zu beseitigen. Wird geren gemacht, wenn man so Richtig unter Druck ist.
Das war so die Situation von FrSky.
Ich finde es gut, dass du da so gründlich ans Werk geht. Ich habe mich damals ja von meiner Horusbestellung getrennt und mit dem Ardu Lostzähler meine X9e und x9d getestet. Ich denke, das ist das Richtige Werkzeug, wenn man Fehlern aus dem Sender nachspürt.
Zur Info; meine teste mit zweitem Sender aun Bord
Ein BT Sender im Hubi sollte unkritisch sein. Ich bin Testweise mit einem zweiten System (ACT) im Flieger geflogen. Der ACT Empfänger sendet dabei mit zwei unabhängigen HF Teilen und zwei Antennen mit voller zulässiger Leistung (100 mW nach alter Eu) die Telemetrie Hierbei sehe ich keine Verschlechterung der LostFrams am X8 Empfänger. Auch der ACT Empfänger ist völlig Unbeeindruckt von der Telemetrie des X8. Und der ACT steht dabei auf "Failsave nach 50 ms. (von 30 - 300 ms einstellbar)
Sigi
Zuletzt bearbeitet:
- Status
