FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[RayX]

Bei mir weckt es den Eindruck, das sie es sehr gut verstehen aber mehr Wert auf ihre neuen Access Produkte legen um den schnellen Dollar zu machen.
In meinem Issue hat @Adelaxie gesagt:

So the diagram is showing the old firmware(v2.0.1) behavior? Maybe I missed it, where can I find the diagram with firmware that we are testing here?

Da ich in der Tread Überschrift und im Eröffnung post klar und Deutlich meine Verwendete Hardware und die Firmware angegeben habe... stellt sich Frksy einfach dumm und springt auf die die sagen "alles funktioniert"(Warum gibt es hier keine Smily mit... ich steck mir den Finger in den Hals... der gehört hier hin wo jetzt der Text in klammern steht ) und nur weil sie den neuen Access Schrott gekauft haben und nix damit anfangen können und ganz dringend fliegen müssen bei sage und schreibe 0,5 Grad Außentemperatur und Corona.
Aber ich lasse mich so einfach nicht abschütteln, ich hätte gerne einen zweiten Shitstorm , bin am aufbereiten der Daten, diesmal etwas deutlicher.

 

[FJH]

Ich glaube schon, dass sich viele Quadcopter-User bei FrSky beschwert haben, und zwar über ausgelöste Failsafes bei meist völlig unkritischem RSSI. Ich glaube nicht, dass eine FL-Bit Änderung von den Usern gefordert wurde, sondern dass diese Änderung auf einer FrSky eigenen "Analyse" beschlossen wurde. Mit dem Gedanken also, wir berichten über weniger FLs, dann passieren auch keine FS mehr.

Dann gibt's noch den Post von @mpjf01:
I would have thought that the firmware producers for the flight controllers "making the wrong failsafe judgement when they receive a FL" would be the appropriate party to modify their firmware rather than transferring the "error" to the FRSKY firmware.
However now that it has been done, reverting it back could cause issues for all the FC users who would appear to now rely on it. Some communication with the FC firmware people might help if so.

Der Kollege sieht das Problem der Failsafes bei der Firmware der FCs. Auch befürchtet er, dass ein Zurückdrehen des FL-Bits auf alten Stand (was wir ja alle fordern) den armen FC-Fliegern neue Probleme schaffen. Mann-o-Mann, der Kollege hat vielleicht Phantasien, da kann man nur abdrehen ...

 

[RayX]

der Kollege ist speziell

 

[ReinhardZ]

Ich denke, wir haben eine gute Chance, dass die FL Bit Filterung zurückgenommen wird.
Wenn erstmal die (gefilterte) FL Anzeige für die ISRM Module implementiert ist, gibt es viele User, die dann entsprechende Logs anfertigen können. Wenn man dann nochmal die wahren Zusammenhänge aufzeigt mit LQBB Logs, wird es eine breitere Unterstützung geben.

 

[FJH]

@Reinhard, du und andere Kollegen messen ja ohne Ende und posten das auch auf RCG, mein Respekt davor. Die Messungen und deren Darstellung ist aber für die meisten der Leser weitgehend"unverständlich". Darum müsstet ihr, und das vermisse ich leider doch, viel klarer schreiben, was die Konsequenzen sind, bzw was die Forderungen an FrSky sind. Offenbar bin ich ja ziemlich Einzelkämpfer bei der Forderung, auch für die ACCST-Firmware den LQ-Sensor zu bekommen. Aber genau der würde dann ja allen den Zugang zur LQ der unterschiedlichsten Empfänger und Sender/Empfänger-Kombis geben.

Neben der FL-Problematik, die ja jetzt sehr ausfühlich getestet und dokumentiert wurde und immer noch wird, gibt es immer noch die grundsätzliche Frequenzshift-Problematik, die leider etwas aus dem Fokus gerückt ist. Die wiederholt vorgeschlagene Lösung eines auto-Frequenztunings des Empfängers beim Binden wurde meines Wissens nach bei der aktuellen 2.1.0 ACCST Firmware nicht implementiert. Das behält sich FrSky für ACCESS Firmware vor. Einzig gemacht bei der ACCST Firmware wurde eine Vergrösserung des AFC-Fensters.

Für die alte v1 ACCST-Firmware wurden hier etliche Messungen zu der Frequenzverschiebung gemacht. Es wäre gut, wenn soche Messungen auch jetzt zur v2.1.0 Firmware gemacht würden. Damit liesse sich dann deutlich machen, bei welchen Empfängern nach wie vor diese Frequenzverschiebung viel zu nahe am Rand des AFC-Fensters liegt, was ja gleichbedeutend ist mit erhöhtem LF-Risiko. Nicht gut also und letztlich nur durch auto-Frequenztuning beim Binden Leider bin ich selber zu doof für solche Messungen.

 

[RayX]

@FJH nö... du bist kein Einzelkämpfer, ich hatte es in meinem Issue gefordert auch für ACCST, es waren aber auch noch andere dabei die es gefordert hatten ich meine @QuadCrash war auch dabei.

Was die Aufbereitung angeht, da hast du recht, aber ich bin dabei denke in der nächsten Stunde habe ich es fertig.
Viel zu Flashen und zu messen...


Edit:
Messungen zur Frequenzverschiebung kann ich nicht mit dienen, habe nichts da womit ich Frequenzen Messen kann.
Evt. kann da jemand anders aushelfen.

 

[RayX]

vermutlich habe ich gerade den Fang meines Lebens im Log aufgezeichnet....
denke ich zumindest oder vielleicht doch nicht?

Der G-RX8 mit der V2.10 5100 habt hat den Failsafe komplett verpennt erst nach dem Failsafe sieht man das er reagiert der 5103 hingegen hat es hübsch angezeigt, so wie gewünscht.
Vielen Dank Reinhard für diesen abgewandelten Tadango Sketch!!

 

[Carbonator]

Neben der FL-Problematik, die ja jetzt sehr ausfühlich getestet und dokumentiert wurde und immer noch wird, gibt es immer noch die grundsätzliche Frequenzshift-Problematik, die leider etwas aus dem Fokus gerückt ist.

Ich teste einfach mit V1 weiter. Da sieht man exakt, was passiert und muss sich keinen Kopf wegen der manipulierten Frames machen. Es wäre halt gut, wenn noch ein paar Kollegen, die den Verdacht haben, dass sie von Lockouts bzw. USM betroffen waren, mittesten würden. Ein Blick auf die Empfänger-LED reicht zur Diagnose. Wenn diese flackert, wenn keine sonstigen 2,4GHz Quellen in der Nähe sind, dann sollte man den LQ testen. Dann kann man durch Quertausch den Verursacher feststellen.

 

[ReinhardZ]

Der G-RX8 mit der V2.10 5100 habt hat den Failsafe komplett verpennt erst nach dem Failsafe sieht man das er reagiert der 5103 hingegen hat es hübsch angezeigt, so wie gewünscht.
Vielen Dank Reinhard für diesen abgewandelten Tadango Sketch!!

Wenn du den 5104 Wert im Log anzeigst (das Dreiecksignal von Kanal 8) kann man gut erkennen, wo der Empfang aussetzt.

 

[RayX]

@Reinhard den 5104 hatte ich jetzt zwecks Übersicht weggelassen und mich auf RSSI, 5100 und 5103 beschränkt.Die Logs kommen jetzt gleich, dann darf gerne Kritik geübt und Änderungs Wünsche vorgeschlagen werden.

 

[RayX]

Test abgeschlossen, alles funktioniert super, egal was es ist. (Ironie)

Kapitulation
Blödes Wort

 

[Carbonator]

Hier meine Ergebnisse von heute Morgen und das was ich auf Github einstellen möchte :

Denk aber dran, dass so gut wie niemand einen LQ Sensor hat. Und in deinem V2 Beispiel ist die Telemetrie einfach eingefroren durch den Failsafe. Ich weiß nicht, ob das im GitHub zielführend ist.

 

[ReinhardZ]

Man sollte wohl eher von Lost Frame Rate statt von Link Quality sprechen. Wenn mit der 2.1.0 SW nur nach 4 lost frames ein FL Bit gesetzt wird, ist klar, dass der 5100 Wert höher ist, als der 5103 Wert.
Man sieht aber hier auch schön im 1.Versuch, dass man dem 5103 Wert (beim X8R) trauen kann, da er sehr gut mit dem 5100 Wert übereinstimmt.

 

[RayX]

Test abgeschlossen
Kapitulation
Blödes Wort

 

[RayX]

@ReinhardZ @Carbonator da habt ihr wohl recht.
Leider habe ich nicht vorher daran gedacht es Frame Lost zu nennen.
Ich habe keine Lust mehr alles noch mal zu machen, den Text im Screenshot kann ich nicht ändern... Sche....
Mir hängt die Testerei langsam zum Hals raus, mein Arsc.... ist Platt Gessen und wie Finger Wund getippt (bin Handwerker kein Schreiberling) und das Hirn raucht... vermutlich raucht es aus Zorn über Frsky´s verhalten, auch wenn ich es sogar verstehen kann.
Nichts desto trotz habe ich heute Morgen auch schon mal über PowerBox CORE nachgedacht, als ich Adelaxie Mail gelesen habe.

 

[ReinhardZ]

Das zweite Beispiel mit dem G-RX8 ist interessant.
Aber wie @Carbonator schon sagt, kann das natürlich auch ein Telemetrie Problem sein und kein Failsafe.
Ist da eine Ansage gekommen?
Der G-RX8 ist in der Übersicht auf github ja noch mit Telemetrie Problem aufgeführt.

 

[RayX]

Das zweite Beispiel mit dem G-RX8 ist interessant.
Aber wie @Carbonator schon sagt, kann das natürlich auch ein Telemetrie Problem sein und kein Failsafe.
Ist da eine Ansage gekommen?
Der G-RX8 ist in der Übersicht auf github ja noch mit Telemetrie Problem aufgeführt.

Ich starte meine Tests im Im Full Power Mod gehe dann mit Sender an meinen Schreibtisch und lege den Sender immer gleich ausgerichtet an die gleiche Stelle, anschließend schalte ich den Range Mod ein, hier fällt der RSSI auf ca 40-45 ist, anschließend schirme ich die Antenne der X9D+ mit den Händen soweit ab das der RSSI auf etwas unter 35-40 fällt und halte diese Position einen Moment (wenn man zu schnell ist dann sieht man im Log es nicht so gut ) nach dieser Zeit schirme ich die Antenne mit den Händen Komplett ab RSSI fällt dabei recht schnell auf 0, die Ansage Telemetrie Verloren kommt recht zeitgleich mit dem Failsafe was ich an Hand eines Angeschlossen Servos höre . mit 100% Sicherheit kann ich nicht sagen ob Telemetrie verloren oder Failsafe als erstes kommt oder beides gleichzeitig.
Dafür ist der Test zu Primitive

 

[QuadCrash]

Im Frsky-Forum schreibt jemand, dass der G-RX8 mit v2.1 bei ihm gut funktioniert (Flug durchgeführt). Und einen Beitrag weiter bestätigt @Wolfgang Fleischer das auch mit einem Trockentest.

Für mich stellt sich hier auch die Frage, ob die zusätzlichen Sensoren immer perfekt funktionieren. Ein kleiner Programmier-/Denkfehler reicht ja bekanntlich schon ... Nur so als Hinweis, ich glaub schon, dass @ReinhardZ weiß, was er da macht .

Für @Carbonator : persönlich würde ich nix mehr mit v1 testmäßig machen. Lieber auf v2.1 konzentrieren und hier FrSky mit Bugmeldungen, sofern vorhanden, zuschütten ...

 

[RayX]

Wenn gut Funktionieren gleich Telemetrie Peaks sind ?
dann ist ja alles gut!
Lost Frame ist ne andere Geschichte, die alle RX betreffen.

Egal, ich gebe mich geschlagen und Lösche die Post oben und lasse gut sein.

 

[Carbonator]

Für @Carbonator : persönlich würde ich nix mehr mit v1 testmäßig machen. Lieber auf v2.1 konzentrieren und hier FrSky mit Bugmeldungen, sofern vorhanden, zuschütten ...

Ich bin ja immer noch an dem Ursprungsbug dran, um den es in diesem Thread geht. Da macht es für mich wenig Sinn, auf Bugs zu testen, die FrSky nachträglich eingebaut hat. Es geht jetzt darum, den Fehler einzugrenzen und da stören die V2 Änderungen nur. Einen Mehrwert hat V2 für mich nirgendwo.

Quax' problematischer S8R fliegt bei mir tadellos mit FCC, jetzt fliege ich ihn hier mit LBT, dann teste ich ihn in Hockenheim (externe Störungen?) - alles mit meiner X9D und dann irgendwann mit Quax' X12, wenn die Beschränkungen rum sind. So sollte der Verursacher der Lockouts zu ermitteln sein.