Der Test wurde mit dem
@ReinhardZ Sketch gemacht. Der 5100 wertet die Lost Frames im SBus aus.
Code:
* 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