Vorsicht bei "Telemetrie verloren" mit Horus

arti

Well-known member
- Nach kurzer Zeit, bestimmt die Arbeit am Clonschutz den Fortschritt und die Richtung meines Produktes.
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.

"Data whitening" wurde eingeführt, um den Synchronisationsverlust zu verhindern. Dieses "data whitening" hat FrSky aber nicht fehlerfrei für alle Kombinationen hinbekommen und es wurde mit V.2.1.0 wieder zurückgenommen. Und schwupps, haben wir wieder Lockouts.
Fairerweise muss man aber sagen, dass genau einer weltweit mit einer betroffenen Kombination kompetent testet.
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.
 
Erhaltene "Gefällt mir": Steve1

arti

Well-known member
Fairerweise muss man aber sagen, dass genau einer weltweit mit einer betroffenen Kombination kompetent testet.
Ich habe eine betroffene Kombination. Eine Xlite Pro, welche Frequenzmäßig wo anders liegt wie die Sender älterer Generation. Jetzt wo die ISRM ACCST V2 raus ist sollte man sich das genauestens anschauen.

Leider habe ich nicht die Zeit mich nebenberuflich darum zu kümmern das FrSky seine Kernkompetenz richtig umsetzt.

Mein Tipp, wäre es Leuten die genügend Zeit mitbringen und willig sind bei der Thematik zu helfen auch das Equipment bereit zustellen.
Bei @nihonski scheint es ja gut funktioniert zu haben. Hätte er von EngelMT kein Material bekommen wären wir heute nicht wo wir sind. Nach diesem Schema sollte auch weiter verfahren werden, auch in der Public Beta Phase von V2.1
 

arti

Well-known member
Genau, da gehts um den Synchronisation des hardwarenahen Datenflusses. Verliert man hier mal ein Bit wird das allerhöchstens zu fehlerhaften Frames führen, wofür dann der CRC gerade stehen muss. Warum FrSky das aus den Datenpaketen wieder raus genommen hat bleibt die gute Frage. Wenn die Hardware Version davon vom CC2500 aktiviert wurde könnte es bereits ausreichen.

Zum Thema testing. Ich kann mit meiner betroffenen Xlite Pro aktuell nur testen indem ich tatsächlich fliegen gehe. Da wird einfach nicht die nötige Zeit zusammen kommen. Das ist etwa 1-2h airtime pro Woche, nicht mehr
 
"as lots of zero bytes means the receiver cannot recover the data clock" habe ich als einen Verlust der Synchronisation interpretiert, der dann zu einer Neusynchronisation (=Lockout) führt. Das würde auch die Beobachtung erklären, dass die Lockouts bei betroffenen Kombinationen auch mit 2.1.0 noch auftreten.

Für die Ogottogotts: Natürlich nur bei den ganz wenigen, wirklich betroffenen Kombinationen.
 

FJH

Erfahrener Benutzer
Hier aktuelles Statement von Engel zur ACCST Firmware:
FrSky is still working on a final Firmware version for the XM+, SXR and GRX-6/GRX-8. It seems, as it will be not so easy to get a well working Firmware for it.
 
Interessanter Hinweis.
Obwohl es wenig Daten zu betroffenen Kombinationen gibt, scheint es wirklich diese Empfänger in Verbindung mit neueren Sendern zu betreffen. Was auffällt, bei allen könnte es an der Prozessorlast liegen, der XM+ hat fast keinen ;) und die anderen müssen noch Zusatzjobs machen.
 
So, ich habe mal meinen X9D+SE-2019 Sender mit der ISRM2.1.0A SW geflasht.
Das Binden an einen X6R Empfänger mit 2.1.0 SW im ACCST D16mode ging ohne Probleme (8ch mode)
- Es gibt keinen FL Telemetrie Sensor im ACCST D16 mode (OTX 2.3.5)
- Die FL Bits sind gefiltert im ACCST D16 mode

ISRM2.1.0-X6R2.1.0_8chmode.jpg
 
Zuletzt bearbeitet:
Kann man für das ACCST D16, das als Zugabe bei ACCESS dabei ist, den LF Sensor und ungefilterte LF erwarten? Ich denke nicht. Diese Features bleiben vermutlich ACCESS vorbehehalten - wenn das Autotuning eingeführt wurde. Damit kann man dann die Frames auch wieder zeigen.
 
Nein, habe ich auch nicht wirklich erwartet. Hätte sein können, dass die gefilterten FL Bits gezeigt werden, aber wenn dann in ACCESS wirklich die ungefilterten gezeigt werden, fällt das auf.
Habe versucht einen RX6R mit ACCESS zu binden, aber das geht nicht mit OTX2.3.5.
Dazu muss man erst wieder auf OTX 2.3.7 updaten.
Langsam mache ich nichts anderes mehr ...:confused:
 
Ja, ich hab's auch gerade gelesen ;)

Hoffentlich geht er jetzt nicht die verlorenen Frames suchen. Seine Warnschwelle macht nur zu Testzwecken Sinn.
 
Hallo zusammen,
Ich lese hier eigentlich nur mit, da ich von dem was Ihr hier besprecht max. die Hälfte verstehe.
Habe aber jetzt aus gegebenem Anlass eine Verständnisfrage.
Ihr sprecht hier von alter und neuer Hardware. Sprich Empfänger und HF-module die evtl. Probleme mit unterschiedlichen Frequenzen haben und dadurch evtl. Logouts etc. verursachen. Bezieht sich das "alt" auf ältere Hardwaregenerationen oder tatsächlich auf gleiche Bauteile älterer oder neuerer Proktion?
Ich Frage, da bei meiner X9D+ von 2014 reparaturbedingt das Backboard inkl.
HF-teil getauscht wurde. Da ich bis jetzt keine Probleme hatte, habe ich ein bisschen bedenken mir jetzt welche einzufangen.

Gruß Andreas
 
Hi zusammen,

mir geht´s ähnlich...,für mich stellt sich jetzt die Frage...?

Hatte mit meiner X9E mit HF Firmware V1 und Empfängern nie ein Problem bemerkt oder festgestellt.

Lohnt es sich nun auf Sender und allen Empfängern die HF Firmware V2.1xx aufzuspielen?
Ist diese HF V2 FW wirklich sicherer? :???:

Grüße Meinhard
 
RCLogger

FPV1

Banggood

Banggood

Oben