FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

in deinem PXX, SBus CHx SA Bild must du schon auch Framefehler erzeugen dass du da was siehst
Ohne Fehler kein Versatz ablesbar.

Und auch die 2 SBus Blöcke Block 1 Ch1-8 mit Bock Ch9-16 vergleichen

Das ging aber aus deiner Ausgangsaussage nicht hervor:

Das SBus Verfahren hat Ewald erklärt und vermessen, da ist auch nichts geheimnisvolles dabei,
außer dass die Servoausgabe nicht Framesynchron ist, das war es noch nie,

Ich wüsste jetzt auch nicht, wie durch ein verlorenes Frame die Synchronisation verloren gehen soll, schließlich ist der Sender der Taktgeber und der kriegt das gar nicht mit. Ich kann mir nur vorstellen, dass in Ewalds Störfeuer alles außer Tritt gerät und eine Neusynchronisation provoziert wird. Aber im modellflugtypischen Umfeld bringt man das nicht hin. Bei Gelegenheit schaue ich es mir mal an.

 

[Carbonator]

Heute nacht wurde durchgearbeitet (ich natürlich nicht ). Mike Blandford hat eine sehr diplomatische Zusammenfassung des Problems veröffentlicht, die vermutlich der Bezugspunkt für weitere Diskussionen werden wird.
Ich versuch mich an der Übersetzung:

Der Hauptgrund für dieses Update ist die aktuelle Methode zum Überprüfen, ob gültige Frames empfangen wurden. Möglicherweise wird ein falsches Frame als gültig erkannt. Ein falsches Frame kann durch einen Sende- / Empfangsfehler verursacht werden, der beispielsweise auf Interferenzen zurückzuführen ist. Wenn die Übertragung alle 9 ms zu einem anderen Kanal springt und nur für einen Teil der 9 ms aktiv ist, ist die Wahrscheinlichkeit eines beschädigten Frames recht gering, jedoch nicht Null. Dann gibt es nur eine weitere kleine Chance, dass das beschädigte Frame als gültig erkannt wird. Dies ist also ein seltenes Ereignis, das jedoch auftreten kann.
Jedes Frame enthält sowohl Servopositionsinformationen als auch Daten, um anzuzeigen, zu welchem Kanal zu hüpfen ist.
Ein beschädigtes Frame kann daher entweder falsche Servodaten ausgeben, die Sprungsequenz stören oder beides.
Ein falscher Servoausgangsfehler allein würde einen Servostörimpuls verursachen, der jedoch innerhalb von 18 ms behoben wird.
Ein falscher Sprungdatenfehler allein führt dazu, dass der Rx die Synchronisation mit dem Tx verliert, was zu einer Sperrung von 0,9 Sekunden führt, bis der Rx entscheidet, dass er die Synchronisation wiederherstellen muss.
Beide Fehler zusammen verursachen falsche Servopositionen und die 0,9 Sekunden blockieren, was zu einem "Hard Over" -Fehler des Servos führt. Da in einem Frame nur 8 Kanäle gesendet werden, sind entweder die Kanäle 1-8 oder die Kanäle 9-16 betroffen. Wenn 9-16, dann bleibt es beim Lockout ohne zusätzliche Servobewegung.
Der Stresstest zur Reproduktion des Fehlers wurde durchgeführt, um zu zeigen, dass dies geschieht. Die Bedingungen für das tatsächliche Auftreten des Fehlers sind lediglich Störungen, die dazu führen, dass ein einzelnes Paket fälschlicherweise akzeptiert wird.

Damit ist jetzt zumindest der Lockout halboffiziell, über den sonst nicht gern geredet wird. Spannend wird die internationale Diskussion, wenn die Verschlüsselung der Datenübertragung klar wird. Das SBus Thema werde ich nicht nach außen tragen, bzw. bei openrc lassen, das wird sonst zuviel für die eingeschworenen FrSky Fans. Ich war ja auch mal einer und wenn FrSky die Kurve kriegt ......

 

[Michael Faupel]

Heute nacht wurde durchgearbeitet (ich natürlich nicht ). Mike Blandford hat eine sehr diplomatische Zusammenfassung des Problems veröffentlicht, die vermutlich der Bezugspunkt für weitere Diskussionen werden wird.
Ich versuch mich an der Übersetzung:


Damit ist jetzt zumindest der Lockout halboffiziell, über den sonst nicht gern geredet wird. Spannend wird die internationale Diskussion, wenn die Verschlüsselung der Datenübertragung klar wird. Das SBus Thema werde ich nicht nach außen tragen, bzw. bei openrc lassen, das wird sonst zuviel für die eingeschworenen FrSky Fans. Ich war ja auch mal einer und wenn FrSky die Kurve kriegt ......

Traurig ist das aber schon, denn wenn ich diese Aussagen richtig interpretiere ! liegt das Grundproblem offensichtlich wirklich an Bauteilerolleranzen bzw an fehlenden Sicherheitsmechanismen die soetwas verhindern. Das scheint "der Preis" des günstigen Systems zu sein.
Wie gesagt, das habe ich daraus interpretiert! Korrigiert mich bitte wenn das falsch ist.

Ebenfalls scheint der Fehler nicht behoben sondern nur kaschiert worden zu sein!
Damit wäre deine Kritik an der "löst frame Schönrechnerei aber auch berechtigt.

Hmm.....sehr bedenklich..

 

[Carbonator]

Traurig ist das aber schon, denn wenn ich diese Aussagen richtig interpretiere ! liegt das Grundproblem offensichtlich wirklich an Bauteilerolleranzen bzw an fehlenden Sicherheitsmechanismen die soetwas verhindern. Das scheint "der Preis" des günstigen Systems zu sein.
Wie gesagt, das habe ich daraus interpretiert! Korrigiert mich bitte wenn das falsch ist.

Ebenfalls scheint der Fehler nicht behoben sondern nur kaschiert worden zu sein!
Damit wäre deine Kritik an der "löst frame Schönrechnerei aber auch berechtigt.

Hmm.....sehr bedenklich..

Nein, das ist so nicht korrekt. Das Protokoll ist sehr sicher, es kam nur in ganz wenigen Fällen zu einer Situation, in der es zu einem Lockout und in noch weniger Fällen zu einem Lockout mit Servoausschlag kam. Die Bauteile sind überall dieselben, von den 30€ Sendern (vielleicht) mal abgesehen. Die Firmware ist das Entscheidende.

Es gibt noch ein paar Unklarheiten, aber jetzt sind die richtigen Leute am Ball, von denen man auch eine mehr oder wenig offene Aussage bekommen wird. Es ist z.B. nicht ganz klar, warum Häufungen bei LBT und bestimmten Sendern auftreten und andere Sender (meine ) gar keine Symptome zeigen.

Eine interessante Aussage kam gerade von midelic. Nämlich, dass eventuell mit der neuen Produktlinie etwas an der Firmware geändert wurde. Da fällt mir natürlich sofort Mario ein. Aber es muss noch einen weiteren Faktor geben, sonst hätte nicht nur Mario mit dem Update seiner X9D+ die Probleme bekommen. Es sind immer noch so gut wie keine X9D mit dem Problem bekannt.

 

[Norbert]

@ Michael WIe du es zusammenfasst ist "Quatsch" - Entschuldigung.
Ja es liegt an Bauteil"toleranzen" - genau an einem . nämlich dem Sender- - bzw dem Empfängerquarz.
Insbesondere das Senderquarz scheint zu laufen. Ich habe den Zusammenhang bereits vor Monaten hier dargestellt, daher in Kürze: Alterung / Themeraturabhängigkeit / mech. Stress.
Es gibt bessere Quarzegeneratoren, die temperaturkompensiert sind, mechanisch stabilisiert, präziser gefertigt.
Die werden meines Wissens von keinem Hersteller eingesetzt. Beim Sender preislich vertretbar, beim Empfänger eher nicht. die von FrSky verwendeten Quarze werden bei der Herstellung im Empfänger angestimmt.

Am "Sicherheitsmechanismus" wurde etwas geändert, das ist der Knackpunkt. Durch davonlaufende Senderquarze und die neuen Empfänger ( R-XRS , G-RX8 usw ), die kleinere Fangbereiche haben und zudem anders abgestimmt wurden, kochte das Problem hoch.
Jetzt wird durch eine andere Übertragung der digitalen Werte versucht Übertragungsfehler zu vermeiden ( Verschlüsselung ), zusätzlich die Richtigkeit der Übertragung besser zu überprüfen ( CRC ) um falsche Sprungwerte zu vermeiden ( 0,9 sec Aussetzer - bei mir der häufigste Fehler ), bzw Servoausschläge, die offensichtlicher waren.

 

[Carbonator]

Gibt es zu den Frequenzabweichungen Messungen? Welche Sender sind betroffen? Welche Abweichung kann noch per Firmware aufgefangen werden, ab wann wird es kritisch? Warum ist LBT ungleich stärker betroffen, warum die "alten" Sender fast nicht?

Vielleicht kommen wir doch noch auf den Grund der ganzen Geschichte, wenn diese Fragen geklärt sind.

 

[quax2011]

Persönlich halte ich es auch für grob Fahrlässig mit dem alten Protokoll weiterzufliegen, da von FrSky entsprechende Warnungen veröffentlich wurden.

Hi, dazu eine Bemerkung von mir: Wo wurden entsprechende Warnungen veröffentlicht? Hier im Forum ! Liest das jeder? Auf der FrSky -Seite ! Wer liest da ? Auf der Engel-Seite ! Warum kommt von dort kein Hinweis an die Käufer die dort ihre Sender gekauft haben? Also von veröffentlichten Warnungen kann hier nur bedingt die Rede sein. Und solange ich nicht sicher bin mit einem Update nicht vom Regen in die Traufe zu kommen warte ich erstmal ab.
@helle at all: Oder kann jemand das Update vorbehaltlos empfehlen?
Von daher finde ich mein Verhalten bei Leibe nicht unverantwortlich zumal ich mit der Anlage seit 2016 fliege und noch keinen ungewollten Servoausschlag und erst Recht keinen Absturz hatte.

Gruß Jürgen

 

[Michael Faupel]

Durch den Mist mit den Telemetrieproblemen bin ich momentan noch nicht bereit meine besseren Modelle mit Frsky auszurüsten, dafür fehlt zur Zeit noch das Vertrauen. Man hat irgendwie immer noch im Hinterkopf das ja noch andere Dinge Probleme bereiten könnten.
Wenn Ruhe eingekehrt ist und die Updates so normal ablaufen wie man sich das vorstellt werde ich den Diabolo 700 und eine Jak 55 damit ausrüsten, darin sind nur hochwertige Komponenten verbaut und erlauben aus meiner Sicht eine bessere Beurteilung der Zuverlässigkeit ds Systems.

Gruß Michael

 

[arti]

Traurig ist das aber schon, denn wenn ich diese Aussagen richtig interpretiere ! liegt das Grundproblem offensichtlich wirklich an Bauteilerolleranzen bzw an fehlenden Sicherheitsmechanismen die soetwas verhindern. Das scheint "der Preis" des günstigen Systems zu sein.
Wie gesagt, das habe ich daraus interpretiert! Korrigiert mich bitte wenn das falsch ist.

Ich sehe das ehrlich gesagt anders. Es handelt sich um ausschließlich um eine ungünstige Implementierung des Übertragungsprotokolls. Ich sehe da insgesamt 3 Punkte: 1. der HF Frequenzableich, 2. die HF Übertragung, 3. die Fehlererkennung nach der Übertragung

1. Ein ganz wichtiger Punkt ist das Hardwaretoleranzen nicht ausreichend abgefangen werden. Sollte sich die RF Referenz des HF Chips (26MHz beim CC2500) fertigungsbedingt zwischen verschiedenen Empfängern/Sendern generationsübergreifend (XJT/IXJT/ISRM) ändern, dann kann ich die Frequenzen z.b. beim Bindenn abgleichen und die Unterschiede vorhalten. Das ist eine reine Frage der Implementierung des HF Links. Der HF Chip kann alle Frequenzen im 2.4GHz Band erzeugen, ich muss ihm nur sagen welche ich denn genau brauche. Ich hoffe der Frequenzabgleich wurde in dem D16 V2 Update eingeführt/ausgeweitet.

2. Es gibt gute und weniger gute Möglichkeiten binäre Signale über einen verrauschten Kanal zu übertragen. Data Whitening ist das Stichwort. Dabei wird versucht möglichst zufällige Bitfolgen zu erzeugen und lange Sequenzen von 1 oder 0 zu vermeiden. Das macht die Übertragung robuster. So wie ich verstanden habe war das eins der Updates bei D16 V2

3. Egal wie gut man man den HF Link implementiert, es werden trotzdem immer wieder fehlerhafte Daten übertragen. Jetzt gilt es diese zu erkennen und zu korrigieren oder zu verwerfen. Mit einem gängigen CRC Verfahren kann man fehlerhafte Daten rausfischen. Je mehr Datenbits man dem CRC einräumt, desto seltener rutschen Fehler durch.

Erst wenn fehlerhafte Daten durch den CRC als "gut" klassifiziert werden, dann können die übertragenen Daten wie Servowerte, oder noch schlimmer der nächste Hoppingkanal (wenn dieser mit übertragen wird), falsch sein. Der Empfänger führt dann lediglich diese falsch verstandene Anweisung aus.

Alle diese Punkte sind eine reine Implementierungsfrage der Firmware von Sender und Empfänger. Mit unbegrenzten Mitteln kann man das alles lösen. Aber auch mit realistischen Mitteln kann FrSky viel erreichen. So wie ich das bisher verstanden habe war das D16 V2 Update ja genau auf diese Punkte ausgerichtet.

 

[helle]

Übertragung Sender an Empfänger

Sendezeit: 1ms LBT, dann ca 4ms Senden, 4ms Telemetrieempfang, daher die 9ms
mit 100000bit/s (altes D8-Protokoll hatte 70000bit/s)

1. Frame Ch1-Ch8 als kodierte Daten+ weitere Daten, 9ms
2. Frame Ch9-Ch16 als kodierte Daten+ weitere Daten, 18ms

3. Frame Ch1-Ch8 als kodierte Daten+ weitere Daten, 27ms
4. Frame Ch9-Ch16 als kodierte Daten+ weitere Daten, 36ms

Auswertung jedes Frames, CRC32 + weitere Fehlerkorrektur, Frame als gültig erkannt.
und wird in einen 4Frame Ringspeicher gespeichert
z.B. https://www.nxp.com/docs/en/application-note/AN5070.pdf

SBus:
Frame X(ch1-ch8)+ Frame X+1(ch9-ch16) ergibt zusammen einen gültigen 16 Kanal SBus-Frame,
der erscheint alle 9ms an SBus Pin, LED ist/bleibt Grün. (Zeitversatz zum Empfangsrame >9ms)

Wenn jetzt ein neuer Frame als ungültig erkannt wird,
nimmt man den vorherigen gültige Frame um einen 16 Kanal SBus-Frame zu erzeugen.
der erscheint am SBus Pin, LED ist/bleibt Grün,
Dieser SBus Frame ist aber zusammengesetzt aus einem aktuellen gültigen Frame
und einem vorher gültgen Frame.

Mehr kannste nicht erwarten.

Mehrstufige Fehlerkorrektur,
mit overhead an Daten bei der Übertragung für die Fehlerkorrektur im Frame selbst.
Zusammensetzung zu einem gültgen S-Bus Frame falls ein Frame nicht korrigiert werden kann und als ungültig gekennzeichnet wrid.
Aber zumindet eine kompletter gültiger SBus Frame (und damit Servowerte) wird erzeugt.

------------------------
Wäre mal gespannt wenn Ewald die gleichen Tests mit Jeti, Futaba, Spektrum und Graupenr machen würde
und genauso "grauslige" Entdeckungen" macht, was zu erwarten ist.
------------------------

Die kochen alle mit Wasser, das Zeug darf nichts kosten, verwenden alle die gleiche Bauteile.
Wir sind im RC-Bereich, das ist keine eigensichere Echtzeitübertragung und nicht wie in der industriellen sicheren Datenübertragung wie z.B. bei Kranfernsteuerungen.

Es wird erst besser wenn man im RC-Bereich auch aktuelle HFHardware für Industrie 4.0 verwenden würde.
zB. mit A86RF215 Pozessoren
Aber da sind wir noch weit entfernt.
Die neue CC26xx Reihe der HF-Prozessoren ist ein erste Schritt dahin.
Die aktuell verbauten CC2500 HF-Prozessoren sind auch schon >15 Jahre am Markt.

-------------------
Zu LBT und FCC
Das Dümmste was man mit LBT und bei belegtem Knal machen kann ist dort nicht zu senden,
anstatt dort zumindest mit den mögliche 27mW zu senden also auf diesem Kanal mit MU10% zu senden.
Dann hat man zumindest die Chance dass auf diesem Kanal auch was zum Empfänger durchkommt.
------------------

 

[Carbonator]

Erst wenn fehlerhafte Daten durch den CRC als "gut" klassifiziert werden, dann können die übertragenen Daten wie Servowerte, oder noch schlimmer der nächste Hoppingkanal (wenn dieser mit übertragen wird), falsch sein. Der Empfänger führt dann lediglich diese falsch verstandene Anweisung aus.

Midelic schreibt, dass FrSky mit jedem Frame auch noch einen Verweis auf eine Hopping-Tabelle mitschickt, um die Hopping Tabelle auch nach der ersten Initialisierung noch wechseln zu können. Wenn diese Info verfälscht durch die CRC Kontrolle läuft, arbeitet der Empfänger mit der falschen Hopping Tabelle und braucht 0,9s, um neu zu synchronisieren. Klingt erstmal logisch für mich, aber überprüfen kann ich es nicht.

 

[arti]

Midelic schreibt, dass FrSky mit jedem Frame auch noch einen Verweis auf eine Hopping-Tabelle mitschickt, um die Hopping Tabelle auch nach der ersten Initialisierung noch wechseln zu können. Wenn diese Info verfälscht durch die CRC Kontrolle läuft, arbeitet der Empfänger mit der falschen Hopping Tabelle und braucht 0,9s, um neu zu synchronisieren. Klingt erstmal logisch für mich, aber überprüfen kann ich es nicht.

Genau so wird da überhaupt ein Schuh draus.
Bisher kam nichts als Erklärung zurück warum denn exakt 100 Frames hintereinander verloren gehen können. Nach eben diesen 100 ungültigen Frames kommt es zu einem erneuten Verbindungsversuch, das war irgendwie gegeben. Aber wieso es denn überhaupt dazu kommt das 100 Frames fehlen. Wenn der Empfänger immer an falscher Stelle zuhört, dann kann er natürlich nichts hören.

Jetzt bleibt noch die letzte Frage, warum LBT und nicht FCC? Dort gibt es auch eine Hoppingtabelle. Ist diese vielleicht nicht dynamisch aktualisierbar?

 

[Michael Faupel]

Übertragung Sender an Empfänger

Sendezeit: 1ms LBT, dann ca 4ms Senden, 4ms Telemetrieempfang, daher die 9ms
mit 100000bit/s (altes D8-Protokoll hatte 70000bit/s)

1. Frame Ch1-Ch8 als kodierte Daten+ weitere Daten, 9ms
2. Frame Ch9-Ch16 als kodierte Daten+ weitere Daten, 18ms

3. Frame Ch1-Ch8 als kodierte Daten+ weitere Daten, 27ms
4. Frame Ch9-Ch16 als kodierte Daten+ weitere Daten, 36ms

Auswertung jedes Frames, Fehlerkorrektur, Frame als gültig erkannt.
und wird in einen 4Frame Ringspeicher gespeichert
z.B. https://www.nxp.com/docs/en/application-note/AN5070.pdf

SBus:
Frame X (ch1-ch8)+ Frame X+1(ch9-ch16) ergibt zusammen einen gültigen 16 Kanal SBus-Frame,
der erscheint alle 9ms an SBus Pin, LED ist/bleibt Grün. (Zeitversatz zum Empfangsrame >9ms)

Wenn jetzt ein neuer Frame als ungültig erkannt wird,
nimmt man den vorherigen gültige Frame um einen 16 Kanal SBus-Frame zu erzeugen.
der erscheint am SBus Pin, LED ist/bleibt Grün,
Dieser SBus Frame ist aber zusammengesetzt aus einem aktuellen gültigen Frame
und einem vorher gültgen Frame.

Mehr kannste nicht erwarten.

Mehrstufige Fehlerkorrektur,
mit overhead an Daten bei der Übertragung für die Fehlerkorrektur im Frame selbst.
Zusammensetzung zu einem gültgen S-Bus Frame falls ein Frame nicht korrigiert werden kann und als ungültig gekennzeichnet wrid.
Aber zumindet eine kompletter gültiger SBus Frame (und damit Servowerte) wird erzeugt.

------------------------
Wäre mal gespannt wenn Ewald die gleichen Tests mit Jeti, Futaba, Spektrum und Graupenr machen würde
und genauso "grauslige" Entdeckungen" macht, was zu erwarten ist.
------------------------

Die kochen alle mit Wasser, das Zeug darf nichts kosten, verwenden alle die gleiche Bauteile.
Wir sind im RC-Bereich, das ist keine eigensichere Echtzeitübertragung und nicht wie in der industriellen sicheren Datenübertragung wie z.B. bei Kranfernsteuerungen.

Es wird erst besser wenn man im RC-Bereich auch aktuelle Hf-Hardware für Industrie 4.0 verwenden würde.
zB. mit A86RF215 Pozessoren

Die aktuell verbauten CC2500 HF-Prozessoren sind auch schon >15 Jahre am Markt.
Aber da sind wir noch weit entfernt.
Die CC26xx Reihe der HF-Prozessoren ist ein erste Schritt dahin.

Wäre mal gespannt wenn Ewald die gleichen Tests mit Jeti, Futaba, Spektrum und Graupenr machen würde
und genauso "grauslige" Entdeckungen" macht, was zu erwarten ist.
------------------------
Das würde mich zumindest für Jeti brennend interessieren und ich würde meine DC 16 mit verschiedenen aktuellen Empfängern gerne für 3 Monate zur Verfügung stellen!

Gruß Michael

 

[RayX]

@ Michael WIe du es zusammenfasst ist "Quatsch" - Entschuldigung.
Ja es liegt an Bauteil"toleranzen" - genau an einem . nämlich dem Sender- - bzw dem Empfängerquarz.
Insbesondere das Senderquarz scheint zu laufen. Ich habe den Zusammenhang bereits vor Monaten hier dargestellt, daher in Kürze: Alterung / Themeraturabhängigkeit / mech. Stress.
Es gibt bessere Quarzegeneratoren, die temperaturkompensiert sind, mechanisch stabilisiert, präziser gefertigt.
Die werden meines Wissens von keinem Hersteller eingesetzt. Beim Sender preislich vertretbar, beim Empfänger eher nicht. die von FrSky verwendeten Quarze werden bei der Herstellung im Empfänger angestimmt.

Am "Sicherheitsmechanismus" wurde etwas geändert, das ist der Knackpunkt. Durch davonlaufende Senderquarze und die neuen Empfänger ( R-XRS , G-RX8 usw ), die kleinere Fangbereiche haben und zudem anders abgestimmt wurden, kochte das Problem hoch.
Jetzt wird durch eine andere Übertragung der digitalen Werte versucht Übertragungsfehler zu vermeiden ( Verschlüsselung ), zusätzlich die Richtigkeit der Übertragung besser zu überprüfen ( CRC ) um falsche Sprungwerte zu vermeiden ( 0,9 sec Aussetzer - bei mir der häufigste Fehler ), bzw Servoausschläge, die offensichtlicher waren.

Ok gehen wir mal von deiner festgestellten Frequenz Abweichung aus und zwei Fehlern ungewollte Servo Ausschläge und dem Failsafe.

Jetzt stellt sich mir die Frage wie kann ein zurück flashen des XJT der X9D+ von 170317 mit dem beide Fehler ganz ohne Stresstest reproduzierbar sind auf 151223 beide Fehler beheben ?

 

[helle]

Wird Zeit dass man ein offende RC HF-Protokoll macht,
quasi ein open Tx-Rx mit aktuellsten HF-Prozessoren z.B. wie das Projekt tinySDR mit A86RF215

TinySDR
[PDF] TinySDR: Low-Power SDR Platform for Over-the-Air Programmable IoT Testbeds | Semantic Scholar
https://arxiv.org/pdf/1907.02063.pdf
---

 

[QuadCrash]

Jetzt stellt sich mir die Frage wie kann ein zurück flashen des XJT der X9D+ von 170317 mit dem beide Fehler ganz ohne Stresstest reproduzierbar sind auf 151223 beide Fehler beheben ?

Von wann, welches Produktionsdatum, ist denn die besagte X9D+?

Lt. Firmware-Seite hat FrSky das RF-Board der Taranis seit Nov. 2016 optimiert und dafür ist die 170317 vorgesehen. Wenn nun eine ältere Taranis die 170317 Firmware bekommt, obwohl das lt. Beschreibung nicht notwendig ist, könnte es sein, dass mit 151223 alles i.O. ist, aber mit 170317 halt Fehler auftreten. Letzteres wäre dann ein Anwenderfehler, weil die Beschreibung zu den Updates hier eigentlich eindeutig ist.

M.E. ist dieses Problem aber getrennt vom Hauptproblem zu sehen. Daher vermutlich auch die wenigen Meldungen zu Problemen mit der X9D+.

 

[FJH]

Ich sehe das ehrlich gesagt anders. Es handelt sich um ausschließlich um eine ungünstige Implementierung des Übertragungsprotokolls. Ich sehe da insgesamt 3 Punkte: 1. der HF Frequenzableich, 2. die HF Übertragung, 3. die Fehlererkennung nach der Übertragung
.
.
.
2. Es gibt gute und weniger gute Möglichkeiten binäre Signale über einen verrauschten Kanal zu übertragen. Data Whitening ist das Stichwort. Dabei wird versucht möglichst zufällige Bitfolgen zu erzeugen und lange Sequenzen von 1 oder 0 zu vermeiden. Das macht die Übertragung robuster. So wie ich verstanden habe war das eins der Updates bei D16 V2

Kann es sein, dass FrSky genau dieses Verfahren jetzt anwendet und dass dies dann als Kopierschutz misverstanden wird?

 

[QuadCrash]

Pascal hat das Thema Verschlüsselung publik gemacht. Es wird das wohl nicht so leichtfertig sagen.

 

[Carbonator]

Jetzt bleibt noch die letzte Frage, warum LBT und nicht FCC? Dort gibt es auch eine Hoppingtabelle. Ist diese vielleicht nicht dynamisch aktualisierbar?

Es gibt auch zuverlässige Berichte von FCC mit Lockouts. Eine Info habe ich noch von Mike Blandford auf diese Frage bekommen: FCC arbeitet mit 70000bit/s OTA, LBT mit 100000bit/s. Aber wie ich das genau interpretieren soll, ist mir unklar. Der FCC Link ist durch den niedrigeren Datendurchsatz eventuell robuster gegen Störungen, mehr fällt mir nicht ein, aber vielleicht reicht das ja schon?

 

[FJH]

Pascal hat das Thema Verschlüsselung publik gemacht. Es wird das wohl nicht so leichtfertig sagen.

Hab mich gerade korrigiert weil schlecht ausgedrückt. Verschlüsselung wäre ja auch für mich das von @arti beschriebene Verfahren, das allerdings nicht dem Kopierschutz dient, sondern die Übertragungssicherheit verbessern soll. Also nochmal : Kopierschutz ein Missverständnis/Fehlinterpretation??