FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

Heute habe ich mal dem R8 von Jumper mit der neuesten midelic Firmware dieselbe Aufgabe gestellt. Nach 50.000 Lost Frames hatte dieser keinen einzigen Lockout. Das Lustige ist, dass sich midelic von Anfang an sicher war, dass seine Firmware keine Lockouts produziert. Ich bin mal gespannt, ob er eine Erklärung rausrückt.

 

[nihonski]

Hast du als Sender das MPM?

 

[Carbonator]

Nein, diese Tests mache ich mit der Ur-X9D mit FCC und WiFi Einfluss.

 

[nihonski]

Sieht sehr stabil aus, gefällt mir im Prinzip.
Mit dem R8 konnte ich auch keine Servo-Ausreißer feststellen, allerdings habe ich nicht lange genug getestet. Anbei zwei Logs des bekannten Datenfehlers mit X9D+, FCC
(pdf in logicdata ändern)

 

[nihonski]

Die Frage ist, was du mit dem 5100 als Lockout feststellst.
Kann es auch ein Problem mit der X8R Telemtrie sein?

 

[Norbert]

Mike Blandford behauptet auch, die Problematik (syncVerlust) ist auch ohne Änderung der Übertragungssoftware mölich ist.

RC Groups - View Single Post - FrSky D16 firmware for D8 receivers

 

[nihonski]

Es sieht ganz so aus, daß die Datenfehler durch unzureichende CRC entstehen (meist nur 2-4 Frames lang)
und die Synch.-verluste (Lockouts) durch unzureichendes Data-Whitening enstehen (ca. 0,9s lang).
Kommt beides zusammen, liegen für 0,9s falsche Servowerte an.
Mike sagt er kann die Snych.-verluste durch Date-Whitening vermeiden ohne an der CRC etwas zu ändern.
Das spricht für die Theorie.
Aber sollen wir deshalb auf die erweiterte CRC verzichten und kurze Datenfehler in Kauf nehmen?
Mike hat die CRC Problematik nicht bestritten.

Übrigens wird das Data-Whitening fälschlicherweise als Hack- oder Kopierschutz ausgelegt, nicht die CRC.

 

[Carbonator]

Der Test wurde mit dem @ReinhardZ Sketch gemacht. Der 5100 wertet die Lost Frames im SBus aus.

*   5100: Good frames % of last 100 frames (Tadango method)
*   5101: Frame Loss Counter  , absolute 32Bit value (FrSky)
*   5102: Frame Loss Counter 2, absolute 32Bit value (@bionicbone method)
*   5103: Good frames % of last 100 frames (@bionicbone method)
*   5104: Test waveform from Channel 8

Der 5101 Counter läuft im Arduino auch ohne Telemetrie weiter, so kann man die fehlenden Frames immer rekonstruieren. 5102 bis 5104 werten das Dreiecksignal auf Kanal 8 aus, dabei gibt es kleine Aussetzer, weil die OpenTX Timer für slow/delay mit 10ms Auflösung laufen, die Frames aber alle 9ms gebildet werden.

Aber sollen wir deshalb auf die erweiterte CRC verzichten und kurze Datenfehler in Kauf nehmen?
Mike hat die CRC Problematik nicht bestritten.

Übrigens wird das Data-Whitening fälschlicherweise als Hack- oder Kopierschutz ausgelegt, nicht die CRC.

Niemand beschwert sich über die erweiterte CRC-Prüfung. Oder das Data-Whitening.
Bedenken gibt es wegen
- der geschönten Lost Frames, da fehlt immer noch eine nachvollziehbare Begründung
- wegen der hohen Zahl von Lost Frames bei bestimmten Kombinationen, funktioniert das jetzt?
- der Komplexität der Änderungen, hätte man sich nicht besser nur auf die Fehler konzenriert?
- der Möglichkeit, dass doch ein Kopierschutz vorrangiges Ziel war (sonst wäre der längst geknackt)
- der Tatsache, dass FrSky das komplette Programm als fehlerhaft bezeichnet und seinen Ruf ruiniert, obwohl vielleicht 98% der User nie ein Problem hatten. Das spricht wiederum dafür, dass man so eine Maßnahme nur ergreift, um Konkurrenz auszuschließen, sonst grenzt das an Suizid.
- der Tatsache, dass um eine vergleichbare Sicherheit wie V1 zu gewährleisten, eigentlich jahrelang getestet werden müsste

 

[Carbonator]

Midelics Antwort ist sehr interessant:

In my early tests of the new D16 firmware found some issues.There were 2 major problems .I had some problem with the channel offset basically about the decision when to jump(hop) to the next channel.I had received frame errors.
Frsky has this check on each frame received which may lead to jumping to wrong channel if the frame is corrupted.I fixed the problem at that time choosing one frame and use the channel offset from that particular frame ,for all the subsequent frames.This way we eliminate false positives. Mike fixed now this problem in its code for D8R/D4R.
Second problem is Frsky don't not do any tuning of TX with RX It relies only on the accurate parts selection of the Xtal and the passive electronic components.In my opinion that is not enough.My code does tuning tx with rx at binding time on base frequency,

Meine Übersetzung:

In meinen frühen Tests der neuen D16-Firmware wurden einige Probleme festgestellt. Es gab zwei Hauptprobleme. Ich hatte ein Problem mit dem Kanalversatz, hauptsächlich im Hinblick auf die Entscheidung, wann zum nächsten Kanal gesprungen werden soll. Ich hatte Rahmenfehler erhalten.

Frsky macht diese Prüfung für jeden empfangenen Frame, was dazu führen kann, dass bei einer Beschädigung des Frames zum falschen Kanal gesprungen wird. Ich habe das Problem zu diesem Zeitpunkt behoben, indem ich einen Frame ausgewählt und den Kanalversatz von diesem bestimmten Frame für alle nachfolgenden Frames verwendet habe. So eliminieren wir falsche Ergebnisse. Mike hat dieses Problem jetzt in seinem Code für D8R / D4R behoben.

Das zweite Problem ist, dass Frsky Sender und Empfänger nicht abstimmt. Es hängt nur von der genauen Teileauswahl des Quartzes und der passiven elektronischen Komponenten ab. Meiner Meinung nach reicht das nicht aus. Mein Code stimmt den Empfänger beim Binden auf die Grundfrequenz des Senders ab.

 

[nihonski]

Was Midelic bezüglich der Hopping-Sequenz etwas misverständlich formuliert, hatte Mike auch festgestellt und FrSKy mitgeteilt. Sollte mit V2 behoben sein, ist allerdings schwer zu messen. Man muß dazu auf der SPI Schnittstelle gezielt falsche Daten einschleusen um das zu erkennen.
Ich meine darüber hatten wir hier schon gesprochen bzw. wurde Mike`s original Text gepostet.

Daß Midelic Auto-Tuning macht ist sehr interessant.

 

[Michael Faupel]

Heute habe ich mal dem R8 von Jumper mit der neuesten midelic Firmware dieselbe Aufgabe gestellt. Nach 50.000 Lost Frames hatte dieser keinen einzigen Lockout. Das Lustige ist, dass sich midelic von Anfang an sicher war, dass seine Firmware keine Lockouts produziert. Ich bin mal gespannt, ob er eine Erklärung rausrückt.
Anhang anzeigen 180312

Kann man denn auf einen Jumper R8 einfach die neue Software von midelic aufspielen wie bei den Frsky Empfängern und wenn ja, wo bekommt man die Software her?

Gruß Michael

 

[Bussard]

Da ist der gesamte Blog, hier die gekürzte, deutsche Fassung.
Man braucht einen Programmer und etwas Zeit. aber dann geht es schnell und lohnt sich.

 

[Norbert]

Es sieht ganz so aus, daß die Datenfehler durch unzureichende CRC entstehen (meist nur 2-4 Frames lang)
und die Synch.-verluste (Lockouts) durch unzureichendes Data-Whitening enstehen (ca. 0,9s lang).
Kommt beides zusammen, liegen für 0,9s falsche Servowerte an.
Mike sagt er kann die Snych.-verluste durch Date-Whitening vermeiden ohne an der CRC etwas zu ändern.

OK, wie auch immer. ABER: Selbst wenn ich die CRC Prüfung weglasse und nur Data-Whitening mache, brauche ich doch neue Übertragungssoftware, die mit ACCST V1 nicht kompatibel ist - oder sehe ich das falsch?

Norbert

 

[nihonski]

Hallo Norbert,
ja, auch bei erweitertem Data-Whitening muß TX und RX FW angepaßt werden.

Mike Blandford hat zwei mögliche Problem-Ursachen angesprochen.
1) Data-Whitening
2) Verarbeitung der Hopping Informationen im Empfänger.

Zu 2)
Einfach gesagt, FrSky überprüft im RX zu jedem Frame die Hopping Informationen, welche mit jedem Frame übergeben werden. Der Fehler dabei ist, daß diese Info nicht zum Quercheck, sondern als "neuer" Wert zur Verrechnung benützt wird (FW bug oder Denkfehler des Programmierers.) Ist diese Info falsch (auf Grund von CRC Fehler) dann springt der RX auf eine falsche Hopping Frequenz, die Synch ist verloren.
Midelics FW und Mike Blandfords FW machen das anders. Sie überprüfen nach dem Einschalten die Hopping-Info mehrerer Frames und "frieren" diesen Wert dann ein ohne daran etwas zu ändern.
Genau dieser Fehler ließe sich nur in der RX FW beheben (ohne TX). Die Grund-Ursache ist allerdings wiederum CRC.
Ob es durch Behebung diesen Fehlers nie mehr zu Synch.-verlusten, sondern nur zu den kurzen Datenfehlern kommt, kann ich nicht sicher sagen.

Mike hat beide, mögliche Probleme 1) 2) nicht im Fehlerfall gemessen, sondern simuliert. Er hat in den SPI Datenstrom künstliche Fehler einfließen lassen und gleichzeitig den CRC-check manipuliert sodaß der Frame als "valid" durchging. Das war zur Analyse sehr wertvoll.
Damit kann ich aber nicht sicher sagen, daß es außer 1) oder 2) keine anderen CRC Fehler gibt, welche zu Snychr.-verlusten führen können. Der CRC-Fehler kann an jeder beliebigen Stelle innerhalb eines Frames auftreten.

 

[Michael Faupel]

Da ist der gesamte Blog, hier die gekürzte, deutsche Fassung.
Man braucht einen Programmer und etwas Zeit. aber dann geht es schnell und lohnt sich.

Hallo Norbert,
ja, auch bei erweitertem Data-Whitening muß TX und RX FW angepaßt werden.

Mike Blandford hat zwei mögliche Probleme angesprochen.
1) Data-Whitening
2) Verarbeitung der Hopping Informationen im Empfänger.

Zu 2)
Einfach gesagt, FrSky überprüft im RX zu jedem Frame die Hopping Informationen, welche mit jedem Frame übergeben werden. Der Fehler dabei ist, daß diese Info nicht zum Quercheck, sondern als "neuer" Wert zur Verrechnung benützt wird (FW bug oder Denkfehler des Programmierers.) Ist diese Info falsch (auf Grund von CRC Fehler) dann springt der RX auf eine falsche Hopping Frequenz, die Synch ist verloren.
Midelics FW und Mike Blandfords FW machen das anders. Sie überprüfen nach dem Einschalten die Hopping-Info mehrerer Frames und "frieren" diesen Wert ein ohne daran etwas zu ändern.
Genau dieser Fehler ließe sich nur in der RX FW beheben (ohne TX). Die Grund-Ursache ist allerdings wiederum CRC.
Ob es durch Behebung diesen Fehlers nie mehr zu Synch.-verlusten, sondern nur zu den kurzen Datenfehlern kommt, kann ich nicht sicher sagen.

Mike hat beide, mögliche Probleme 1) 2) nicht im Fehlerfall gemessen, sondern simuliert, er hat in den SPI Datenstrom künstliche Fehler einfließen lassen. Das war zur Analyse sehr wertvoll.
Damit kann ich aber nicht sicher sagen, daß es außer 1) oder 2) keine anderen CRC Fehler gibt, welche zu Snychr.-verlusten führen können. Der CRC-Fehler kann an jeder beliebigen Stelle innerhalb eines Frames auftreten.

Sorry,

wenn ich mich als nahezu Unwissender dieser Technik wieder zu Wort melden..

Kann man denn die beiden FW von midelic oder Mike Blandford nicht einfach für alle Frsky Empfänger verwenden, also die feste Hoppingsequenz übernehmen damit Folgefehler minimiert werden.
Wenn hiefür keine einfache Antwort möglich ist würde bestimmt interessieren in wieweit die FW Entwicklungen dieser Experten überhaupt Einfluss auf weitere Frsky Software hat.

Es kann doch irgendwie nicht sein das einzelne fähige Personen, die zum Teil weltweit verstreut sind, eine höhere Entwicklungskompetenz besitzen als ein großer Massenhersteller!
Ebenfalls wird ja langsam vollkommen unverständlich das FRSky offenbar gute Entwicklungsempfehlungen führender Köpfe ignoriert!

Gruß Michael

 

[Carbonator]

Es kann doch irgendwie nicht sein das einzelne fähige Personen, die zum Teil weltweit verstreut sind, eine höhere Entwicklungskompetenz besitzen als ein großer Massenhersteller!
Ebenfalls wird ja langsam vollkommen unverständlich das FRSky offenbar gute Entwicklungsempfehlungen führender Köpfe ignoriert!

Denk dir das Ganze mal vor dem Hintergrund durch, dass FrSky diese Aktion nutzen will, um die Konkurrenz, bzw. die Cloner vor die Tür zu stellen. Dann wird Vieles klar werden. Die sind nicht doof bei FrSky, sie denken oft nur nicht zu Ende.

Man kann sich darüber streiten, ob so ein Vorgehen legitim ist, immerhin machen sie damit der Mehrzahl ihrer Kunden Angst und zerstören das über Jahre aufgebaute Vertrauen in den Link. Aber sie dürfen natürlich ihr geistiges Eigentum schützen. Die Frage ist, wie weit man dabei gehen sollte. Und natürlich, ob bei den betroffenen Kombinationen wirklich alles in Ordnung gebracht wird mit dem Update. Das Schönen der Lost Frame Information ist in dem Zuammenhang verdächtig. Aber warten wir ab .....

 

[Michael Faupel]

Denk dir das Ganze mal vor dem Hintergrund durch, dass FrSky diese Aktion nutzen will, um die Konkurrenz, bzw. die Cloner vor die Tür zu stellen. Dann wird Vieles klar werden. Die sind nicht doof bei FrSky, sie denken oft nur nicht zu Ende.

Man kann sich darüber streiten, ob so ein Vorgehen legitim ist, immerhin machen sie damit der Mehrzahl ihrer Kunden Angst und zerstören das über Jahre aufgebaute Vertrauen in den Link. Aber sie dürfen natürlich ihr geistiges Eigentum schützen. Die Frage ist, weit man dabei gehen sollte. Und natürlich, ob bei den betroffenen Kombinationen wirklich alles in Ordnung gebracht wird mit dem Update. Das Schönen der Lost Frame Information ist in dem Zuammenhang verdächtig. Aber warten wir ab .....

Die können von mir aus Kopierschutzmechanismen einbauen soviel sie wollen solange die Übertragungsstrecke dabei sicherer wird bzw nicht auf der Strecke bleibt.
Hier sind soviel gute Vorschläge gekommen irgendwann sollte Frsky da mal einlenken sonst ist der Zug abgefahren, Jumper und Co stehen doch am Start.
Wenn das "Original" super funktioniert wer sollte bei den günstigen Preisen dann denn noch was anderes kaufen?
Das wird doch nur gemacht weil die anderen besser sind, zB Jumper T16 mit abstimmbarer und programmierbarer Mittenfrequenz, das würde doch garnicht ziehen wenn sich TX und RX auf eine gemeinsame Mitte "einigen" würden, um nur ein Beispiel zu nennen! Dazu festgelegte Hoppingsequenzen a,la midelic und Mike Blandford, möglichst über mehr Kanäle wie es zB Powerbox mit der Core macht.

 

[FJH]

Jumper und Co sind noch Meilen-weit von einer Vergleichbarkeit mit FrSky entfernt. Nur, die Masse der Poster in den Foren (wie in RCG), die sich mit grossmäuligen Sprüchen von FrSky abwenden wollen, denken nicht zu Ende. Gab ja auch hier schon einen, der bestätigte, dass für ihn und seine Kumpels FrSky gestorben sei. Nur auf sein FrSky Equipment wollte er dann doch nicht verzichten. Würde FrSky morgen dicht machen, dann würde das grosse Heulen losgehen. Mit nur einem MPM-Sender und zwei eigenen Empfängern (von denen einer nur eigen entwickelt und der andere Raub-geklont ist) und sonst garnichts kommt keiner weit. Schau dir mal zum Vergleich an, was FrSky mittlerweile alles an Komponenten im Programm hat. Mag mir nicht vorstellen, dass das plötzlich nicht mehr zu haben sein wird.

 

[Michael Faupel]

Jumper und Co sind noch Meilen-weit von einer Vergleichbarkeit mit FrSky entfernt. Nur, die Masse der Poster in den Foren (wie in RCG), die sich mit grossmäuligen Sprüchen von FrSky abwenden wollen, denken nicht zu Ende. Gab ja auch hier schon einen, der bestätigte, dass für ihn und seine Kumpels FrSky gestorben sei. Nur auf sein FrSky Equipment wollte er dann doch nicht verzichten. Würde FrSky morgen dicht machen, dann würde das grosse Heulen losgehen. Mit nur einem MPM-Sender und zwei eigenen Empfängern (von denen einer nur eigen entwickelt und der andere Raub-geklont ist) und sonst garnichts kommt keiner weit. Schau dir mal zum Vergleich an, was FrSky mittlerweile alles an Komponenten im Programm hat. Mag mir nicht vorstellen, dass das plötzlich nicht mehr zu haben sein wird.

Das stimmt schon, nur muß es auch sicher funktionieren.
Man muß sich drauf verlassen können. Mit einem Grummeln im Magen ist das kein gutes Omen..

Wir warten weiter ab, die Hoffnung stirbt zuletzt!

Gruß Michael

 

[Carbonator]

Mag mir nicht vorstellen, dass das plötzlich nicht mehr zu haben sein wird.

Deswegen arbeiten wir daran, dass FrSky wieder zur Vernunft kommt und diese Spielchen bleiben lässt.