FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Michael Faupel]

Wenn ich das so lese was du von dir gibst .. ich könnte mir vorstellen ... oder hören-sagen Info ..
Schreib doch einfach das du Null Ahnung hast, jedoch trotzdem hier deinen Mi.. dazu geben willst.
Edit: ich korrigiere mich
- weiter so, sehr fundiert

Im Zusammenhang hast du das aber gelesen? Prima!
Von HF- Technik habe ich keine Ahnung, das stimmt!
Es ändert aber nichts an der Art wie ich Dinge betrachte. Welche Erfahrungen ich selber gemacht habe bzw wo ich mich auf glaubwürdige Aussagen beziehen kann mache ich durch entsprechende Hinweise kenntlich!
Ich kann jedenfalls auch über Jeti reden weil ich es seit 11 Jahren einsetze, also persönlich kenne!
Und solange ich mein Gegenüber nicht persönlich kenne bin ich mit Urteilen auch eher zurückhaltend.

Sehr windig hier...

Gruß Michael

 

[arti]

Der Test ist bedeutungslos

Das sehe ich anders. Der Test zeigt genau das wovon hier die ganze Zeit gesprochen wird. Zusätzlich zeigt er wie man mit sehr einfachen Mitteln einen falschen Output des Empfänger direkt sichtbar macht. Jeder kann das nachstellen und selber ausprobieren wie sich seine Sender/Empfänger Kombo verhält.
Ob eine Funkverbindung getestet wird oder 4 auf einmal macht in meinen Augen auch keinen signifikanten Unterschied. Schließlich bist du so gut wie nie alleine auf dem 2,4GHz Band unterwegs, egal ob Wlan, Bluetooth oder die Sender der Kollegen auf dem Flugfeld. Die Funkstrecke muss damit umgehen können, sonst riskiere ich ja jedesmal mein Modell wenn ich in die Luft gehe.

 

[Carbonator]

Ich vermute so langsam, dass viele die Grundlagen überhaupt nicht verstehen. Wer legt denn zwei fremde aktive Sender in sein Modell?

 

[Michael Faupel]

Ich vermute so langsam, dass viele die Grundlagen überhaupt nicht verstehen. Wer legt denn zwei fremde aktive Sender in sein Modell?

Ich halte das auch nicht für richtig. Direkt nebeneinander betrieben kommt es sehr leicht zu Interferenzen.

 

[arti]

Wer legt denn zwei fremde aktive Sender in sein Modell?

Du störst dich wirklich daran dass da mehrere Empfänger dabei waren? Anders gefragt, wäre der Test unauffällig ausgegangen wenn nur ein einziger FrSky Empfänger da aufgestellt worden wäre? Wie sieht es aus mit einem Redundanzsetup mit 2 Empfängern, vielleicht sogar mit 2 tatsächlich verschiedenen HF Strecken? Wie sieht es aus wenn ein Bluetoothmodul mit im Modell untergebracht ist?

Ich gebe dir völlig Recht das man etwas an der Methodik arbeiten müsste um belastbare Aussagen treffen zu können. Aber der simple Ansatz selbst ist doch nicht verkehrt. Stellen wir uns mal vor es wären keine Auffälligkeiten eingetreten, dann wäre man einen Schritt näher den Systemen wieder blind vertrauen zu können.

 

[fsjunk]

bei der von ihm vermuteten Fehlerhäufigkeit könnte er den Test ja nur mit FrSky Tx/Rx wiederholen.

 

[Sigimann]

Auffällig sind doch die hohen Störpegel im 40 Minuten Takt. Das kann nicht aus den getesteten Sendern kommen und deutet auf zyklische Fremdstörer hin.
Zwischen den Störspitzen kann man dann den Einfluss der Sender untereinander sehen, nicht auffällig, die könnte man so betreiben.

Sigi

 

[Carbonator]

Wenn mehrere Komponenten parallel laufen, ergibt das auch ein zeitliches Muster der Störungen, je nachdem, wie die Systeme hoppen. Man müsste mit einem einzigen System mal gegenchecken, ob es tatsächlich Störungen auf dem Platz gibt, oder ob es ein selbstgemachter Effekt ist. Was soll denn nur alle 40 Minuten senden? Ich habe keine Idee, was das sein soll.

 

[Leo1962]

Vor allem wenn die Sender wie im Normalen Leben mindesten 1- 2m voneiander Stehen

2.4 hat übrigen Probleme mit Unterwasser Empfang wenn die Sender also bei Regen unter Karton lagen könnte dass durchaus auch einen Einfluss haben und vermehrte stöhrugen ergeben.
wäre also interessant ob das gleiche ergebnis raus komt mit offen liegenden Sendern und dem gleichen Test.

Ich war vor kurzen mit einem Nuri auf wirklich nasser Wiesse am Fligen das teil tropfte die offen Paddel Antenne bekamen anscheinend auch wasser ab und der Nuri hat angefangen zu flattern hab das Fliegen abgebrochen und gedacht so jetzt hast du das Problem auch nur viel stärker mit einem nicht upgedateten x4s Empfänger. Ging dan zuhause auf Ursachen Forschung mit neu binden usw. Als alles wider richig Trocken war, war der Spuck wider vorbei.
Ich hab danach die blanken Paddels Mit Tesa verklebt so das knien Wasser mehr dran kommt. Seither keine Probleme mehr.

 

[Carbonator]

Pascal Langer (MPM) hat interessanterweise gleich die richtige Frage gestellt, als er auf den "Engel Bug" aufmerksam gemacht wurde:

Really, the CRC16 they are using is fully standard... Are they not just trying to stop clones RX and TX from working?

"Wirklich, der CRC16, den sie verwenden, ist kompletter Standard ... Versuchen sie damit nicht nur, die Clon RX und TX auszuhebeln?"

Die weitere Diskussion zu dem Thema ist dann auch sehr interessant. Ich bin echt mal gespannt, ob FrSky den Humbug wirklich durchzieht und sich zum eigenen Protokoll inkompatibel macht und behauptet, das Protokoll war schon jahrelang problematisch, obwohl jeder, der seine fünf Sinne zusammenhat, weiß, dass das Protokoll funktioniert hat.

I'm still puzzled and I think it's a good way to make incompatible all the RX clones on the market (most of them can't be updated) and TX clones (if we don't manage to reverse the change) hidden behind a "security" problem so that no one can complain why they do it.

In der russischen Außenpolitik hat sich der Begriff der "nützlichen Idioten" etabliert. Vielleicht sind die Chinesen ja ähnlich unterwegs

 

[QuadCrash]

Dort steht aber auch (von Mike Blandford) ...

If you check in the multi code, you will see the RF chip CRC is disabled currently for the 'X' protocol.

... sprich Pascal hat das auch nicht aktiviert.

Ich gehe davon aus, dass das so kommt: Klick!

 

[Carbonator]

Ich verstehe es so, dass die Funktion von Mike B. vorübergehend für das MPM deaktiviert wurde. Und Pascal hat da gar nicht genau hingeschaut.
Es kann durchaus so kommen, wie du vermutest, aber ob das der richtige Weg ist, bezweifle ich. Wie groß ist die Wahrscheinlicheit von fehlerfreien neuen Firmwares, die
- die Konkurrenz ausschließen
- die Frequenzdrift der neuen Sender kaschieren
- ACCESS (hat bereits einige Baustellen) und ACCST abdecken?
Dazu kommt das Gejammer Tausender User, die jetzt schon von den vielen Updates die Nase voll haben und jetzt einwandfrei funktionierende Systeme in eine ungewisse Zukunft transformieren sollen.

IBM hat mal gegen die IBM PC Kompatiblen etwas Ähnliches probiert, aber das ist massiv in die Hose gegangen. Wenn FrSky dicht macht, plädiere ich dafür, dass die Anhänger von OpenTX nach einem neuen Hersteller suchen, der besser zu dem Spirit von OpenTX passt.

 

[QuadCrash]

Es kann durchaus so kommen, wie du vermutest, aber ob das der richtige Weg ist, bezweifle ich.

Ob es der richtige Weg ist bezweifle ich zwar auch, aber FrSky wird sich die Gelegenheit nicht entgehen lassen.

Dazu kommt das Gejammer Tausender User, die jetzt schon von den vielen Updates die Nase voll haben und jetzt einwandfrei funktionierende Systeme in eine ungewisse Zukunft transformieren sollen.

Sehe ich eher nicht so, weil niemand muss updaten ... Und wer das tut, aus welchen Gründen auch immer, wird halt TX und RX aktualisieren müssen.

 

[Carbonator]

Sehe ich eher nicht so, weil niemand muss updaten ... Und wer das tut, aus welchen Gründen auch immer, wird halt TX und RX aktualisieren müssen.

Du vergisst, dass wir ein "Riesen-Sicherheitsproblem" haben und genau die jammernden Ogottogotts unbedingt die "sicherheitsrelevanten" Updates einzuspielen versuchen - mit allen bekannten Folgen

Am besten läuft es für die, die einfach nur fliegen

 

[bendh]

Am besten läuft es für die, die einfach nur fliegen

aber nur wenn sie die Störung nicht haben und solange neu gekaufte Empfänger auf die alte Firmware flashbar sind.

 

[Carbonator]

Leider haben wir immer noch keine Methode, die betroffenen Sender exakt zu identifizieren. Einen Kollegen habe ich gebeten, seine G-RX8 (alte Firmware) in Verbindung mit seiner Horus auf Flackern der grünen LED zu kontrollieren. Da flackert nichts, also ist auch das Risiko bei ihm gering. Ein "Telemetrie verloren" hat er ebenfalls noch nie gehört. Der G-RX8 mit der 2018er Firmware scheint aktuell die beste Testmethode zu sein.

Wenn es flackert (ohne Störungen durch WLAN oder andere 2,4GHz Quellen) --> Uffbasse

 

[QuadCrash]

Nun, es gibt ein Problem und wenn das durch die Updates behoben wird, kräht kein Hahn mehr danach, dass man dafür TX und RX updaten muss.

Leute, die kein Problem haben, werden eh nichts machen. Die "Update-Blase" existiert nur in den Foren und nur ein Bruchteil der FrSky-User wird daher updaten. Und von dem Bruchteil wird nur ein weiterer Bruchteil jedes Update unter die Lupe nehmen.

Für FrSky kann es doch gar nicht besser laufen. Sie aktualisieren mit gewissem Aufwand den kompletten Firmware-Bestand und zeigen dadurch, dass sie auch Probleme ernst nehmen, die nur bei wenigen Usern vorkommen. Das dabei Fremd-Hardware ggfs. wertlos wird, ist halt so, aber nicht deren Problem ...

Deine Flacker-Theorie ist übrigens auch nur eine Theorie. Je nach Firmware-Stand flackerts eh unterschiedlich und daran kann man nix festmachen. Ich denk, dass Ewald da 'nen besseren Einblick hat. Was FrSky dann daraus macht ist wiederum 'ne andere Sache.

 

[Norbert]

So - jetzt haben wir mal eine Aussage von außerhalb unseres Kreises.

"Wow, it's so unsual to disable the hardware CRC check from the RF component that I haven't even checked! That looks like a design flow to me. " ==>>
Wow, es ist so ungewöhnlich, die Hardware-CRC-Prüfung für die HF-Komponente zu deaktivieren, dass ich sie noch nicht einmal überprüft habe! Das sieht für mich nach einem ??Entwicklungsablauf?? aus.

Ich weiss nicht, was er mit DesignFlow wirklich meint - aber anyway- Da ist wohl was im Argen?

Sie sind mit der Nase draufgestoßen und offenbar ist es auch kein grosses Problem, es auf der Senderseite nachzuvollziehen. Bei den Empfängern sieht es wohl anders aus. Was mich persönlich nicht interessiert.

Wie ich bereits mehrfach sagte, alles für mich völlig nachvollziehbar und logisch. Ich denke das Hauptproblem sind die neue Rx Generation, da diese einen engeren Fangbereich haben der unter starker HF-Belastung nochmals deutlich enger wird und damit bei verstimmten Sendern aus dem Bereich heraus kommt und damit die Fehleranzahl massiv erhöht, bis es zum Crash ( nichtsynchronisation ) kommt.

So ist mein derzeitiger Stand des Irrtums.

Norbert

PS: Ihr seit dazwischen gekommen. Die Flacker Theorie ist durchaus berechtigt. Jedes Flackern zeigt einen verlorenen Frame an. Mit einem einfachen Spektrumanalyser für 35 € kann man die Mittenfrequenz des Senders messen.

 

[masterblaster]

Er meint wohl "Design Flaw" = Designfehler.

 

[Carbonator]

Mike Blandford schreibt übrigens:

If you check in the multi code, you will see the RF chip CRC is disabled currently for the 'X' protocol.

The problem has been happening, particularly in Germany with LBT. Someone has been able to reproduce the problem on the bench.

"Das Problem ist vor allem in Deutschland mit LBT aufgetreten. Jemand konnte das Problem auf der Werkbank reproduzieren."

Also auch hier der Hinweis auf eine einzige Quelle.