FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Andrew hat heute seinen 2.1 Lockout Flug veröffentlicht. Leider ist er vielleicht weltweit der Einzige, der mit einem betroffenen System systematisch testet.
Er spricht zwar nur von möglichen Lockouts, aber wenn man die Telemetrie anschaut, sind es Lockouts. Reinhards Sensor im zweiten Bild zeigt auch vier mal den Einbruch auf Null, der FrSky Fake LQ nur einmal, zweimal fast genau und einmal nur knapp 60% (roter Pfeil). Fairerweise muss man sagen, dass der 5103 Sensor systembedingt teilweise mehr Verluste anzeigt, als real vorlagen.
Die gute Nachricht ist, dass auch mit gefälschten Lost Frames die kritischen Situationen durchkommen. Aber man sieht nicht mehr den Fakt, dass niemals 100% erreicht werden, was für mich ein sicheres Zeichen für ein "gefährdetes" System ist (nach den bisherigen Erfahrungen).
Die schlechte Nachricht ist, dass die Lockouts mit 2.1 vermutlich nicht beseitigt sind.
Ich hab zusätzlich noch die Lockout-Details angehängt, falls jemand tiefer einsteigen will.
Er spricht zwar nur von möglichen Lockouts, aber wenn man die Telemetrie anschaut, sind es Lockouts. Reinhards Sensor im zweiten Bild zeigt auch vier mal den Einbruch auf Null, der FrSky Fake LQ nur einmal, zweimal fast genau und einmal nur knapp 60% (roter Pfeil). Fairerweise muss man sagen, dass der 5103 Sensor systembedingt teilweise mehr Verluste anzeigt, als real vorlagen.
Die gute Nachricht ist, dass auch mit gefälschten Lost Frames die kritischen Situationen durchkommen. Aber man sieht nicht mehr den Fakt, dass niemals 100% erreicht werden, was für mich ein sicheres Zeichen für ein "gefährdetes" System ist (nach den bisherigen Erfahrungen).
Die schlechte Nachricht ist, dass die Lockouts mit 2.1 vermutlich nicht beseitigt sind.
Ich hab zusätzlich noch die Lockout-Details angehängt, falls jemand tiefer einsteigen will.
Anhänge
Zuletzt bearbeitet:
Dass mit dem 5103 Wert keine 100% erreicht werden, liegt an dem G-RX8 Empfänger, der ein etwas unsauberes Signal auf den SBus Kanälen hat (PPM Ausgänge habe ich nicht geprüft). Dieses unsaubere Signal führt mit der @Bionicbone Methode zu einem LQ Abfall von mindestens 10%. Dieser Effekt tritt besonders im 8 Kanal Modus des G-RX8 auf.
Ja, man kann leider nur vermuten. Das zeigt nochmal, wie irre es ist, das LF Bit zu manipulieren. Leider verstehen weniger als 0,01% der User die Hintergründe, sonst hätte man FrSky leicht zur Umkehr zwingen können. Der Shitstorm hat nur die getroffen, die auf die Manipulation hingewiesen haben.
Aber zurück zum Thema: Ich bin relativ sicher, dass ein System, das mit V1 regelmäßig 100% LQ zeigt, nicht von dem Problem betroffen ist. Positive und negative Beispiele habe ich hier schon öfter gezeigt.
Aber zurück zum Thema: Ich bin relativ sicher, dass ein System, das mit V1 regelmäßig 100% LQ zeigt, nicht von dem Problem betroffen ist. Positive und negative Beispiele habe ich hier schon öfter gezeigt.
Hier die Erklärung in kursiv von FrSky zum FL-Bit im SBus-Stream :
Some flight control products will make the wrong failsafe judgment when they receive an FL. This is not the case. We received many emails from regular users suggesting that we modify the FL output feature.
FrSky sagt also, dass die Änderung gemacht wurde, weil viele Benutzer in Mails über Probleme/Failsafes bei ihren FCs, verursacht durch das FL-Bit, sich bei FrSky beschwert haben.
For now, we've decided not to change 2.1.0 because everything is stable and another round will cause a delay.
We will have to start extensive testing and release of ISRM as soon as possible so that we can revisit this matter.
Es wird also jetzt bei der jetzt 2.1.0 Version erst mal nichts geändert. Erst mal soll es mit Tests mit ISRM Sender weitergehen, danach will man sich nochmal die FL-Sache ansehen.
I hope you will continue to pay attention to the upcoming ISRM testing procedures this week and the in-time FL values will be displayed on the radio menu as a standalone sensor with the ISRM firmware update which is coming.
Für ISRM-Sender sollen mit der 2.1er Firmware die FLs im Sender angezeigt werden. Das werden dann wohl vermutlich die manipulierten FLs sein. Hier ist dann messen mit den externen QL Sensor angesagt.
FrSky Erklärung hier zu finden => ACCST V2.x.x pre-release firmware - Rx Lost Frame SBUS Indicator · Issue #2 · FrSkyRC/Firmware-Test
Some flight control products will make the wrong failsafe judgment when they receive an FL. This is not the case. We received many emails from regular users suggesting that we modify the FL output feature.
FrSky sagt also, dass die Änderung gemacht wurde, weil viele Benutzer in Mails über Probleme/Failsafes bei ihren FCs, verursacht durch das FL-Bit, sich bei FrSky beschwert haben.
For now, we've decided not to change 2.1.0 because everything is stable and another round will cause a delay.
We will have to start extensive testing and release of ISRM as soon as possible so that we can revisit this matter.
Es wird also jetzt bei der jetzt 2.1.0 Version erst mal nichts geändert. Erst mal soll es mit Tests mit ISRM Sender weitergehen, danach will man sich nochmal die FL-Sache ansehen.
I hope you will continue to pay attention to the upcoming ISRM testing procedures this week and the in-time FL values will be displayed on the radio menu as a standalone sensor with the ISRM firmware update which is coming.
Für ISRM-Sender sollen mit der 2.1er Firmware die FLs im Sender angezeigt werden. Das werden dann wohl vermutlich die manipulierten FLs sein. Hier ist dann messen mit den externen QL Sensor angesagt.
FrSky Erklärung hier zu finden => ACCST V2.x.x pre-release firmware - Rx Lost Frame SBUS Indicator · Issue #2 · FrSkyRC/Firmware-Test
