FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Ich will ja nicht nur kritisieren, sondern auch konstruktiv etwas beitragen.
Meiner Meinung nach handelt es sich bei den Fehlern um einen Empfänger Reboot. Das erklärt den RXLoss, "telemetry lost" und den 1 Sekunden Lockout, in dem keine Steuerbefehle funktionieren. Die eigentliche Ursache ist, dass der Empfänger "abgeschossen" wird, die große Frage ist, warum. Die "alte" Serie zeigt das Problem gar nicht, es trat auf mit dem Erscheinen des iXJT und vermehrt mit den "schnellen" Empfängern wie G-RX8.
Wenn das letzte Frame vor dem Lockout verstümmelt wird, kann das zu dem Ausschlag führen, wenn ein Digitalservo im Spiel ist, das den letzen PWM Impuls hält.
Die Aufgabe für FrSky wäre es, mögliche Ursachen für einen Empfängerausstieg abzuklopfen. Und möglichst zu beseitigen oder zumindest vor einem Reboot in der Firmware abzufangen.
Es könnte sich ganz simpel um einen overflow handeln, oder eine falsche Adresse bei einem Schreibvorgang, der dann zum Neustart führt. Ein Fehler in der Firmware ist für mich am wahrscheinlichsten.
Eventuell führen auch elektrische Störungen zu dem Reboot, wie das mit den fehlerhaften Zündanlagen und den leistungsfähigen Impellermodellen der Fall war. Wobei dummerweise da nur der Prozessor neu bootete, aber der CC2500 nicht neu initialisiert wurde. Was FrSky dann mit einem Firmwareupdate geändert hat. Bei einem Segler ist diese Ursache natürlich sehr unwahrscheinlich.
Meiner Meinung nach handelt es sich bei den Fehlern um einen Empfänger Reboot. Das erklärt den RXLoss, "telemetry lost" und den 1 Sekunden Lockout, in dem keine Steuerbefehle funktionieren. Die eigentliche Ursache ist, dass der Empfänger "abgeschossen" wird, die große Frage ist, warum. Die "alte" Serie zeigt das Problem gar nicht, es trat auf mit dem Erscheinen des iXJT und vermehrt mit den "schnellen" Empfängern wie G-RX8.
Wenn das letzte Frame vor dem Lockout verstümmelt wird, kann das zu dem Ausschlag führen, wenn ein Digitalservo im Spiel ist, das den letzen PWM Impuls hält.
Die Aufgabe für FrSky wäre es, mögliche Ursachen für einen Empfängerausstieg abzuklopfen. Und möglichst zu beseitigen oder zumindest vor einem Reboot in der Firmware abzufangen.
Es könnte sich ganz simpel um einen overflow handeln, oder eine falsche Adresse bei einem Schreibvorgang, der dann zum Neustart führt. Ein Fehler in der Firmware ist für mich am wahrscheinlichsten.
Eventuell führen auch elektrische Störungen zu dem Reboot, wie das mit den fehlerhaften Zündanlagen und den leistungsfähigen Impellermodellen der Fall war. Wobei dummerweise da nur der Prozessor neu bootete, aber der CC2500 nicht neu initialisiert wurde. Was FrSky dann mit einem Firmwareupdate geändert hat. Bei einem Segler ist diese Ursache natürlich sehr unwahrscheinlich.
... die Frage ist zu unpräzise
rnd 90% der incidents dürften in die Kategorie 1-2 Frames Verweildauer fallen.
Ich habe dann mal eine Ardu so programmiert, dass er ein KST 135 Servo 1 oder 2 Frames aus Neutralposi auf diese "1538" ansteuert
Bei einem frame hat das Servo gar nicht genügend Zeit auf die Posi zu fahren und zuckt mit ggf 10..15% Ausschlag
2Frames reichen geschätzt aus um ein schnelles Servo kurz in die Region 40% anzufahren.
Bei Flächenfliegern kommt jetzt das Trägheitsmoment und die Abhängigkeit der Reaktion zu aktuellen Strömungsgeschwindigkeit in die Betrachtung hinzu.
Imho wird das kein Pilot als Störung bemerken, da bereits Luftturbulenzen mehr Bewegung verursachen. zumal ab einer gewissen Entfernung diese minimale "Korrekturbewegung" nicht mehr visuell erkennbar ist.
Wenn der Fall vorliegt, dass du, weshalb auch immer, eine FL rate von 50% vorliegen hast, ist die Wahrscheinlichkeit höher, dass sich das Problem auch mal über 0,2..0,3 Sekunden fortpflanzt
(Vererbung auf die Framelosses, da kommt schon eine schöne Anzahl FLs hintereinander zustande)
Das dürfte durch eine "Korrekturbewegung" bemerkbar sein, Frage ist, ob man das tatsächlich als Störung abtut, wenn man die Ursache nicht kennt.
In logs oder Flags taucht das Problem nicht auf & kann darüber nicht detektiert werden.
rnd 90% der incidents dürften in die Kategorie 1-2 Frames Verweildauer fallen.
Ich habe dann mal eine Ardu so programmiert, dass er ein KST 135 Servo 1 oder 2 Frames aus Neutralposi auf diese "1538" ansteuert
Bei einem frame hat das Servo gar nicht genügend Zeit auf die Posi zu fahren und zuckt mit ggf 10..15% Ausschlag
2Frames reichen geschätzt aus um ein schnelles Servo kurz in die Region 40% anzufahren.
Bei Flächenfliegern kommt jetzt das Trägheitsmoment und die Abhängigkeit der Reaktion zu aktuellen Strömungsgeschwindigkeit in die Betrachtung hinzu.
Imho wird das kein Pilot als Störung bemerken, da bereits Luftturbulenzen mehr Bewegung verursachen. zumal ab einer gewissen Entfernung diese minimale "Korrekturbewegung" nicht mehr visuell erkennbar ist.
Wenn der Fall vorliegt, dass du, weshalb auch immer, eine FL rate von 50% vorliegen hast, ist die Wahrscheinlichkeit höher, dass sich das Problem auch mal über 0,2..0,3 Sekunden fortpflanzt
(Vererbung auf die Framelosses, da kommt schon eine schöne Anzahl FLs hintereinander zustande)
Das dürfte durch eine "Korrekturbewegung" bemerkbar sein, Frage ist, ob man das tatsächlich als Störung abtut, wenn man die Ursache nicht kennt.
In logs oder Flags taucht das Problem nicht auf & kann darüber nicht detektiert werden.
Hi,
zu der Hypothese:
"Wenn das letzte Frame vor dem Lockout verstümmelt wird"
da gibt es in dem HF Chip integrierte Erkennungsmethodiken, so etwas wird als frameloss erkannt, der letzte plausible frame wird dann ausgegeben.
"Unsere" Fehler treten auch bei konstant fehlerfreien Datenstrom auf, wenn man lange genug warten möchte.
Wir haben natuerlich auch untersucht, inwieweit SBUS und PWM Ausgänge "auseinanderlaufen" können,
ohne wirklichen Befund.
eigentlich gilt:
Müll auf SBUS = identischer Müll auf Servoausgängen.
"Die Aufgabe für FrSky wäre es, mögliche Ursachen für einen Empfängerausstieg abzuklopfen. "
Ich kann dir im Prinzip Futter dazu geben, weil mit mit einigen neuen RXen die Ansteuerung des PWM Signals verändert wurde.
das führte auch kurz zur Theorie, dass ein Anlaufen mehrerer Servos zeitgleich "evtuell und unter bestimmten Situationen" einen Brownout verursachen könnte.
Wurde messtechnisch versucht nachzuvollziehen und ist nicht gelungen.
Ausserdem passt es nicht dazu, dass auch Sat Rxe betroffen sind.
Ist jedenfalls aus jetziger Sicht "Verschwörungstheorie", da müsste der Rx auch wissen wann wir mal nicht messen und zuschlagen (-;
zu der Hypothese:
"Wenn das letzte Frame vor dem Lockout verstümmelt wird"
da gibt es in dem HF Chip integrierte Erkennungsmethodiken, so etwas wird als frameloss erkannt, der letzte plausible frame wird dann ausgegeben.
"Unsere" Fehler treten auch bei konstant fehlerfreien Datenstrom auf, wenn man lange genug warten möchte.
Wir haben natuerlich auch untersucht, inwieweit SBUS und PWM Ausgänge "auseinanderlaufen" können,
ohne wirklichen Befund.
eigentlich gilt:
Müll auf SBUS = identischer Müll auf Servoausgängen.
"Die Aufgabe für FrSky wäre es, mögliche Ursachen für einen Empfängerausstieg abzuklopfen. "
Ich kann dir im Prinzip Futter dazu geben, weil mit mit einigen neuen RXen die Ansteuerung des PWM Signals verändert wurde.
das führte auch kurz zur Theorie, dass ein Anlaufen mehrerer Servos zeitgleich "evtuell und unter bestimmten Situationen" einen Brownout verursachen könnte.
Wurde messtechnisch versucht nachzuvollziehen und ist nicht gelungen.
Ausserdem passt es nicht dazu, dass auch Sat Rxe betroffen sind.
Ist jedenfalls aus jetziger Sicht "Verschwörungstheorie", da müsste der Rx auch wissen wann wir mal nicht messen und zuschlagen (-;
Noch was:
"es trat auf mit dem Erscheinen des iXJT und vermehrt mit den "schnellen" Empfängern wie G-RX8. "
Ich würde das anders formulieren:
Mit der X12s wurde das iXJT eingeführt.
Leider ist die interne Antennenpositionierung in der X12s der einer z.B. X9e unterlegen, wordurch Framelosses häufiger auftreten können und sich die Eintrittswahrscheinlichkeit erhöht.
Eine extrene Antenne hilft, damit könnte man ggf auf das Niveau einer X9d kommen.
"es trat auf mit dem Erscheinen des iXJT und vermehrt mit den "schnellen" Empfängern wie G-RX8. "
Ich würde das anders formulieren:
Mit der X12s wurde das iXJT eingeführt.
Leider ist die interne Antennenpositionierung in der X12s der einer z.B. X9e unterlegen, wordurch Framelosses häufiger auftreten können und sich die Eintrittswahrscheinlichkeit erhöht.
Eine extrene Antenne hilft, damit könnte man ggf auf das Niveau einer X9d kommen.
Ich denke, dass beim "Abschiessen" eines RX auch ganz simpel mal ein PWM Impuls abgeschnitten werden kann, da macht auch keine Fehlerkorrektur mehr etwas dran ....
Da der Fehler auch 15m vor dem Sender auftrat, ist jede Diskussion über Antennen etc. müssig imo.
Lass uns entspannt abwarten, wie es weitergeht. Die Argumente sind ausgetauscht
Da der Fehler auch 15m vor dem Sender auftrat, ist jede Diskussion über Antennen etc. müssig imo.
Lass uns entspannt abwarten, wie es weitergeht. Die Argumente sind ausgetauscht
Dieser ca 1s-Ausschlag sieht dann nach Re-Synchronisationsproblemen aus,
wenn obiger Fehler gehäuft auftrat.
Den solange braucht der RX bis er sich im ungüstigsten Fall wieder zum Sender aufsynchronisiert hat.
Das ist aber kein Empfänger-Reboot.
Bei FCC ist der Fehler genauso verhanden, fällt aber nicht auf, im Gegensatz zum LBT-Verfahren.
Kann man das so formulieren: "....Nur dank LBT trat der Fehler sichtbar auf...."
da LBT systembedingt viel mehr FL erzeugt als FCC.
wenn obiger Fehler gehäuft auftrat.
Den solange braucht der RX bis er sich im ungüstigsten Fall wieder zum Sender aufsynchronisiert hat.
Das ist aber kein Empfänger-Reboot.
Bei FCC ist der Fehler genauso verhanden, fällt aber nicht auf, im Gegensatz zum LBT-Verfahren.
Kann man das so formulieren: "....Nur dank LBT trat der Fehler sichtbar auf...."
da LBT systembedingt viel mehr FL erzeugt als FCC.
Zuletzt bearbeitet:
Der erratische Ausschlag löst nix aus,
darauf gab es nie irgendwelche Hinweise.
in einer blöden Situation ist er Bestandteil des letzten frames vor einer "loss" Situation.
Wenn in der "loss" Phase ein resync notwendig wird, dauert es halt
(... was dank lbt ja nicht wirklich schneller geht (-; )
Leider hatte sich Mike B. dazu auf Anfrage nicht weiter geäussert.
So wie ich Ewald verstehe gibt es noch Möglichkeiten den HF chip noch etwas zu "tunen" / optimieren.
Inwieweit sich dem FrSky annimmt ist noch offen.
Der G-Rx ist da sowieso ein Sensibelchen.
Ohne Belastbare logs vorweisen zu können, weil nur Gefühl:
Bei Tests, wo ich zwei G Rxe parallel im Grenzbereich laufen lies, war sowohl das Failsafe Verhalten als auch der Resync bei dem mit dem, letztem Update"Robuster" im Sinne Resync funzt schneller / Failsafe kommt nicht so häufig.
Wenn's "nur" am rogue value liegen würde, hätte das eine Version vorher auch schon sein müssen.
Es ist nicht unwahrscheinlich, dass Frsky in dem Zug da auch noch was macht/gemacht hat.
darauf gab es nie irgendwelche Hinweise.
in einer blöden Situation ist er Bestandteil des letzten frames vor einer "loss" Situation.
Wenn in der "loss" Phase ein resync notwendig wird, dauert es halt
(... was dank lbt ja nicht wirklich schneller geht (-; )
Leider hatte sich Mike B. dazu auf Anfrage nicht weiter geäussert.
So wie ich Ewald verstehe gibt es noch Möglichkeiten den HF chip noch etwas zu "tunen" / optimieren.
Inwieweit sich dem FrSky annimmt ist noch offen.
Der G-Rx ist da sowieso ein Sensibelchen.
Ohne Belastbare logs vorweisen zu können, weil nur Gefühl:
Bei Tests, wo ich zwei G Rxe parallel im Grenzbereich laufen lies, war sowohl das Failsafe Verhalten als auch der Resync bei dem mit dem, letztem Update"Robuster" im Sinne Resync funzt schneller / Failsafe kommt nicht so häufig.
Wenn's "nur" am rogue value liegen würde, hätte das eine Version vorher auch schon sein müssen.
Es ist nicht unwahrscheinlich, dass Frsky in dem Zug da auch noch was macht/gemacht hat.
Ich hoffe dass sich Engel mit seiner Umbenennung von
"Horus X10 und X12 verliert Verbindung bzw macht ungewollte Ausschläge" auf "Plötzliche Servoausschläge"
nicht selbst ins Knie geschossen hat und nicht nach dem Hauptproblem gesucht wurde.
Heute morgen habe ich bereits Ewald angeschrieben und wir haben vereinbart uns zu treffen, um über diesen Punkt zu sprechen.
Ich gebe Carbo im vollen Umfang recht, wenige fehlerhafte Frames merkt kein Mensch. Ich spreche von Holds über ca. 1 sec bzw Ausschlägen so, dass mein Segler durch Tiefenruder von waagerecht auf senkrecht nach unten, bzw durch Quer von Waagerecht um 120° drehte.
Dieses Video
aus dem Beitrag https://frsky-forum.de/thread/3146-plötzliche-servoausschläge/?postID=38161#post38161 entspricht zeitlich dem Ausschlagproblem.
Ich werde nachher noch versuchen Ewald telefonisch zu erreichen, um näheres zu klären.
Norbert
"Horus X10 und X12 verliert Verbindung bzw macht ungewollte Ausschläge" auf "Plötzliche Servoausschläge"
nicht selbst ins Knie geschossen hat und nicht nach dem Hauptproblem gesucht wurde.
Heute morgen habe ich bereits Ewald angeschrieben und wir haben vereinbart uns zu treffen, um über diesen Punkt zu sprechen.
Ich gebe Carbo im vollen Umfang recht, wenige fehlerhafte Frames merkt kein Mensch. Ich spreche von Holds über ca. 1 sec bzw Ausschlägen so, dass mein Segler durch Tiefenruder von waagerecht auf senkrecht nach unten, bzw durch Quer von Waagerecht um 120° drehte.
Dieses Video
Ich werde nachher noch versuchen Ewald telefonisch zu erreichen, um näheres zu klären.
Norbert
"Warum "Prügel bezogen", wo du recht hast,hast du recht. "
... hatte für die Aktion meine betagte X9e wieder rausgekramt.
Anfangs mit X12s (iXJT) und X9e(XJT) parallel in identischer Anordnung Vergleichmessungen gemacht.
Wenn ich die durchschnittliche Framelossrate über einen längeren Zeitraum betrachtet habe kamen mir
Hab' die X9e daraufhin nochmal saubergemacht & gestreichelt .....
... hatte für die Aktion meine betagte X9e wieder rausgekramt.
Anfangs mit X12s (iXJT) und X9e(XJT) parallel in identischer Anordnung Vergleichmessungen gemacht.
Wenn ich die durchschnittliche Framelossrate über einen längeren Zeitraum betrachtet habe kamen mir
Hab' die X9e daraufhin nochmal saubergemacht & gestreichelt .....
Dann gebe ich auch nochmal meinen Senf dazu.
Plötzliche Ausschläge (immer Kanal 1 = Roll und nach rechts) gefolgt von RXLOSS, also Lockout oder Failsafe sehe ich auf einem Kopter, der mit XM+ fliegt. Seit meiner speziellen Failsafe-Behandlung führt das jedoch nicht mehr unweigerlich zum Crash.
Ein solcher Fall hier nochmals im Video: Dropbox - RXLOSS.mp4 - Simplify your life
Mein zweiter Kopter mit R-XSR zeigte so weit ich weiß bisher keine plötzlichen Ausschläge, sondern nur RXLOSS bzw. Failsafe oder Lockout. Da ich meist sanft cruise, fällt mir der Fehler hier vom Flugverhalten fast nicht auf, nur sehe ich eben ab und zu RXLOSS im OSD und er nimmt Steuerbefehle verzögert an. Bei beiden jeweils mit direkter Sichtverbindung und unter 100m Distanz. Auch hier habe ich die Failsafe-Behandlung entsprechend angepasst, damit er mir nicht gleich die Motoren abstellt, wie das beim ersten Vorkommnis noch passiert ist.
Vorkommen tut das geschätzt einmal pro 50 Flüge.
Gruß Gerd
Plötzliche Ausschläge (immer Kanal 1 = Roll und nach rechts) gefolgt von RXLOSS, also Lockout oder Failsafe sehe ich auf einem Kopter, der mit XM+ fliegt. Seit meiner speziellen Failsafe-Behandlung führt das jedoch nicht mehr unweigerlich zum Crash.
Ein solcher Fall hier nochmals im Video: Dropbox - RXLOSS.mp4 - Simplify your life
Mein zweiter Kopter mit R-XSR zeigte so weit ich weiß bisher keine plötzlichen Ausschläge, sondern nur RXLOSS bzw. Failsafe oder Lockout. Da ich meist sanft cruise, fällt mir der Fehler hier vom Flugverhalten fast nicht auf, nur sehe ich eben ab und zu RXLOSS im OSD und er nimmt Steuerbefehle verzögert an. Bei beiden jeweils mit direkter Sichtverbindung und unter 100m Distanz. Auch hier habe ich die Failsafe-Behandlung entsprechend angepasst, damit er mir nicht gleich die Motoren abstellt, wie das beim ersten Vorkommnis noch passiert ist.
Vorkommen tut das geschätzt einmal pro 50 Flüge.
Gruß Gerd
OK
unternehmen wir noch mal einen moeglichen Erklaerungsversuch
das ganze hypothetisch,
aus der Ferne ist eine Diagnose immer schwierig.
Fernab der erratischen Ausschlags Untersuchung:
Vorab:
unabhaengig von der ganzen "Thematik" hatte ich den XM+ mal als Sat Rx fuer redundancy boxen angedacht
Beim Reichweitentest fiel er bei mir durchs raster, weil ein XSR deutlich mehr RW hatte
Spaeter habe ich mal R-XSR gegen diverse andere antreten lassen, das Teil stach z.B. bewaehrte X8r bei der RW aus.
Auf dieser Basis sollte Imho ein R Xsr einem XM+ bei der Empfangsguete ueberlegen sein.
Das wuerde sich dann mit deiner Erfahrung decken, dass der RXSR weniger anfaellig ist.
FS & Lockouts auf beiden Systemen deutet eher auf den Sender als Ursache / missing link hin.
Vorausgesetzt Antennenverlegung, Kabelei etc sind Rx seitig sauber.
Wenn du die Anlage in freier Umgebung rund 3m vom Sender betreibst, hast du dann noch "sauberen" Empfang, oder flackern da schon die Empfangsleds deutlich?
etl beim xm+ mehr?
unternehmen wir noch mal einen moeglichen Erklaerungsversuch
das ganze hypothetisch,
aus der Ferne ist eine Diagnose immer schwierig.
Fernab der erratischen Ausschlags Untersuchung:
Vorab:
unabhaengig von der ganzen "Thematik" hatte ich den XM+ mal als Sat Rx fuer redundancy boxen angedacht
Beim Reichweitentest fiel er bei mir durchs raster, weil ein XSR deutlich mehr RW hatte
Spaeter habe ich mal R-XSR gegen diverse andere antreten lassen, das Teil stach z.B. bewaehrte X8r bei der RW aus.
Auf dieser Basis sollte Imho ein R Xsr einem XM+ bei der Empfangsguete ueberlegen sein.
Das wuerde sich dann mit deiner Erfahrung decken, dass der RXSR weniger anfaellig ist.
FS & Lockouts auf beiden Systemen deutet eher auf den Sender als Ursache / missing link hin.
Vorausgesetzt Antennenverlegung, Kabelei etc sind Rx seitig sauber.
Wenn du die Anlage in freier Umgebung rund 3m vom Sender betreibst, hast du dann noch "sauberen" Empfang, oder flackern da schon die Empfangsleds deutlich?
etl beim xm+ mehr?
Die Empfänger sind in den Minis gut vergraben, da sieht man die LEDs kaum noch.
Aber apropos Reichweite, da schenken sich beide bei mir nichts, beide schaffen ein Mehrfaches der Entfernung, in der das Problem üblicherweise auftritt. Mit dem einen Kopter (R-XSR) ist mir das beim ersten Vorfall sogar innerhalb vom Haus passiert, als ich den Kopter mal in's Nachbarzimmer geflogen habe. Damals fiel er dann aus 1,5m auf den Steinboden, weil bei Failsafe noch "Motor aus" programmiert war...
Ich schaue mal morgen, ob ich an den LEDs etwas sehen kann.
Gruß Gerd
Aber apropos Reichweite, da schenken sich beide bei mir nichts, beide schaffen ein Mehrfaches der Entfernung, in der das Problem üblicherweise auftritt. Mit dem einen Kopter (R-XSR) ist mir das beim ersten Vorfall sogar innerhalb vom Haus passiert, als ich den Kopter mal in's Nachbarzimmer geflogen habe. Damals fiel er dann aus 1,5m auf den Steinboden, weil bei Failsafe noch "Motor aus" programmiert war...
Ich schaue mal morgen, ob ich an den LEDs etwas sehen kann.
Gruß Gerd
Korrekt. Der XM+ hat genau dieselbe Empfindlichkeit wie der R-XSR. Und eine CPU aus der neuen TI-Serie.
Udo, mein Vorschlag wäre, gedanklich mal zwei Schritte zurückzugehen, die gut dokumentierten repräsentativen Fälle von Gerd und Norbert FrSky zu erklären und FrSky überprüfen zu lassen, welche Routinen möglicherweise zu einem "Abschiessen" des Prozessors führen können. In beiden Fällen waren neue Sendemodule am Werkeln.
Und lasst bitte das XJT in Ruhe, das funktioniert perfekt
Udo, mein Vorschlag wäre, gedanklich mal zwei Schritte zurückzugehen, die gut dokumentierten repräsentativen Fälle von Gerd und Norbert FrSky zu erklären und FrSky überprüfen zu lassen, welche Routinen möglicherweise zu einem "Abschiessen" des Prozessors führen können. In beiden Fällen waren neue Sendemodule am Werkeln.
Und lasst bitte das XJT in Ruhe, das funktioniert perfekt
Bernd,
wir können uns darauf einigen, dass es Failsafes / loss of control Situationen in Situationen gibt, die man nicht vermuten würden (irgendwo im Nahbereich)
Ich habe gerade jemand anderem gerade dazu meine persönliche Meinung geschrieben, in etwas so:
Bei 15 derartigen Berichten würde es vermutlich mindestens 4 verschiedene Ursachen geben.
Ich sehe noch keinen Anhaltspunkt, dass dies bei FrSky häufiger als bei anderen Mitbewerbern auftritt.
mögliche Ursachen
a)
Aus der Erfahrung von 40 Jahren Modellflug ist ein Grossteil an Kontrollverlusten hausgemacht (Kabel/Stecker/Stromversorgung, Kontaktkorrosion..), wo intermittierende Probleme auch gerne im Nahbereich auftreten.
b)
Nach den ganzen "Messorgien" habe ich meine Meinung ueber potentielle Aussenstörung (Handy Wlan, allgemeine 2.4 GHZ Nutzung etc...) geändert im Sinne von "Kann doch tatsächlich eine Rolle spielen"
Da hätte ich ich vorher abgewunken, solche Dinge sind leider kaum nachzuweisen
c..)
Und dann bleiben noch die Möglichkeiten die auf FrSky Seite liegen.
Einen anderen sporadischen FW Bug, egal ob auf Tx oder Rx Seite, der FS einfach so auslöst würde ich mit extrem geringer Wahrscheinlichkeit bewerten, da er bei den ganzen Messungen, die etliche Personen gemacht haben, imho mal hätte mitgeloggt / "gesehen" werden müssen.
Von deiner Vermutung, dass reboots unter bestimmten Umständen auftreten können, bin ich auch nicht überzeugt.
(mal von den bekannten Ursachen abgesehen, natürlich gibt es brownouts etc...)
es fällt mir daher schwer, andere um Abhilfe zu überreden von etwas, woran ich selbst nicht glaube.
Mein Vorschlag:
Der "Draht" nach FrSky ist für die Thematik noch "warm".
Jemand weist mit nachvollziehbaren Mitteln die Existenz von sporadischen, unerklärbaren reboots nach und ich/wir kümmern uns ums weitere.
Grüsse
udo
wir können uns darauf einigen, dass es Failsafes / loss of control Situationen in Situationen gibt, die man nicht vermuten würden (irgendwo im Nahbereich)
Ich habe gerade jemand anderem gerade dazu meine persönliche Meinung geschrieben, in etwas so:
Bei 15 derartigen Berichten würde es vermutlich mindestens 4 verschiedene Ursachen geben.
Ich sehe noch keinen Anhaltspunkt, dass dies bei FrSky häufiger als bei anderen Mitbewerbern auftritt.
mögliche Ursachen
a)
Aus der Erfahrung von 40 Jahren Modellflug ist ein Grossteil an Kontrollverlusten hausgemacht (Kabel/Stecker/Stromversorgung, Kontaktkorrosion..), wo intermittierende Probleme auch gerne im Nahbereich auftreten.
b)
Nach den ganzen "Messorgien" habe ich meine Meinung ueber potentielle Aussenstörung (Handy Wlan, allgemeine 2.4 GHZ Nutzung etc...) geändert im Sinne von "Kann doch tatsächlich eine Rolle spielen"
Da hätte ich ich vorher abgewunken, solche Dinge sind leider kaum nachzuweisen
c..)
Und dann bleiben noch die Möglichkeiten die auf FrSky Seite liegen.
Einen anderen sporadischen FW Bug, egal ob auf Tx oder Rx Seite, der FS einfach so auslöst würde ich mit extrem geringer Wahrscheinlichkeit bewerten, da er bei den ganzen Messungen, die etliche Personen gemacht haben, imho mal hätte mitgeloggt / "gesehen" werden müssen.
Von deiner Vermutung, dass reboots unter bestimmten Umständen auftreten können, bin ich auch nicht überzeugt.
(mal von den bekannten Ursachen abgesehen, natürlich gibt es brownouts etc...)
es fällt mir daher schwer, andere um Abhilfe zu überreden von etwas, woran ich selbst nicht glaube.
Mein Vorschlag:
Der "Draht" nach FrSky ist für die Thematik noch "warm".
Jemand weist mit nachvollziehbaren Mitteln die Existenz von sporadischen, unerklärbaren reboots nach und ich/wir kümmern uns ums weitere.
Grüsse
udo
