Ja das ist leider richtig.
Meine Aussage war in die Richtung gedacht, dass dieser Aspekt von der Community stark diskutiert wird und das eigentlich zu fixende Problem dabei in den Hintergrund rückt. FrSky hat diese Marschrichtung schon lange eingeschlagen und wird sich höchstwahrscheinlich nicht durch diese Diskussion umstimmen lassen auch wenn ich es mir auch anders wünschen würde. Also warum Energie darauf verbraten wenn man die kritischen Probleme diskutieren könnte?
Lockouts sind für mich das absolute K.O. Kriterium zur weiteren Nutzung von FrSky Produkten, nicht Kopierschutz.
Synchronisationsverlust von Was? Also von welcher Ebene der Übertragung? Die eigentliche Bit-weise Übertragung oder der ACCST OTA Frames?
Data Whitening hilft nur die Kodierung von aufeinanderfolgenden Bits besser trennen zu können.
Diese Arbeit übernimmt ausschließlich das zugrundeliegende Übertragungsprotokoll des HF Chip (CC2500). Der Chip bietet auch eine eingebaute Data Whitening Funktion, die FrSky Firmware kann dieses Feature auch nur an oder aus machen.
Hat der HF Chip lang genug zugehört liefert er dann nur noch die kompletten OTA Frames des FrSky Protokolls. Enthält dieser Frame fehlerhafte Bits, dann sollte der CRC greifen und ein Frameloss wird gemeldet. Wird ein fehlerhafter Frame vom CRC durchgelassen, welcher noch zusätzlich protokollkritische Informationen enthält, könnte es dazu kommen dass das ACCST Protokoll die Synchronisation zwischen Empfänger und Sender verliert. Die Folge ist, wir haben einen Lockout.
Data Whitening reduziert Fehler auf der HF Protokollebene, dann hat der höher liegende CRC einfach weniger fehlerhafte Frames die er erkennen muss. Mit dem Synchronisationsverlust auf ACCST Protokollebene, was ich mit einem Lockout gleichsetze, hat es zunächst nichts zu tun.
Meine Aussage war in die Richtung gedacht, dass dieser Aspekt von der Community stark diskutiert wird und das eigentlich zu fixende Problem dabei in den Hintergrund rückt. FrSky hat diese Marschrichtung schon lange eingeschlagen und wird sich höchstwahrscheinlich nicht durch diese Diskussion umstimmen lassen auch wenn ich es mir auch anders wünschen würde. Also warum Energie darauf verbraten wenn man die kritischen Probleme diskutieren könnte?
Lockouts sind für mich das absolute K.O. Kriterium zur weiteren Nutzung von FrSky Produkten, nicht Kopierschutz.
Synchronisationsverlust von Was? Also von welcher Ebene der Übertragung? Die eigentliche Bit-weise Übertragung oder der ACCST OTA Frames?
Data Whitening hilft nur die Kodierung von aufeinanderfolgenden Bits besser trennen zu können.
Diese Arbeit übernimmt ausschließlich das zugrundeliegende Übertragungsprotokoll des HF Chip (CC2500). Der Chip bietet auch eine eingebaute Data Whitening Funktion, die FrSky Firmware kann dieses Feature auch nur an oder aus machen.
Hat der HF Chip lang genug zugehört liefert er dann nur noch die kompletten OTA Frames des FrSky Protokolls. Enthält dieser Frame fehlerhafte Bits, dann sollte der CRC greifen und ein Frameloss wird gemeldet. Wird ein fehlerhafter Frame vom CRC durchgelassen, welcher noch zusätzlich protokollkritische Informationen enthält, könnte es dazu kommen dass das ACCST Protokoll die Synchronisation zwischen Empfänger und Sender verliert. Die Folge ist, wir haben einen Lockout.
Data Whitening reduziert Fehler auf der HF Protokollebene, dann hat der höher liegende CRC einfach weniger fehlerhafte Frames die er erkennen muss. Mit dem Synchronisationsverlust auf ACCST Protokollebene, was ich mit einem Lockout gleichsetze, hat es zunächst nichts zu tun.
