FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

GerdS

Erfahrener Benutzer
Der FC ist doch nicht auf den RSSI-Wert angewiesen, den zeigt er nur im OSD an.
Es sind zwei Probleme, die vermutlich dieselbe Ursache haben. Und der fluktuierende RSSI ist nur ein Indiz dafür, dass etwas nicht stimmt, aber nicht für den Flug relevant.
Der Failsafe bzw. Lockout dagegen schon.

Gruß Gerd
 
Was und wie wird mit dem FC ausgewertet und auf dem OSD angezeigt?
Was muß passieren (z.B. 10 FLs) daß der FC über das OSD lockout meldet?
Welche Inputs werden wie ausgewertet?
Ich würde das gerne etwas "greifbarer" verstehen.
 

GerdS

Erfahrener Benutzer
Ich bin kein Experte für das SBUS-Protokoll, jedoch so viel kann ich glaube ich sagen:
- RSSI ist nur eine Option und wird ausschließlich zur Anzeige im OSD verwendet
- RXLOSS wird ausgelöst beim Ausbleiben von Input per SBUS über einen einstellbaren Zeitraum, z.B. 1s
- und RXLOSS wird auch ausgelöst, wenn die "Frame lost" und/oder Failsafe-Flags auf dem SBUS über einen Zeitraum von z.B. 1s gelesen werden

Gruß Gerd
 
Was macht der FC z.B. wenn die SBUS Daten schneller kommen als er verarbeiten kann?
Wir haben heute andere Timing-Verhältnisse als bei der Einführung des SBUS durch Futaba.
Die SBUS Pakete (3ms) kommen alle 9ms mit 6ms Pause dazwischen.
Was sagt die Spezifikation des FC? Und sind wir sicher, daß die FW des FC diese immer einhält.
Eine konsequente Fehlersuche beinhaltet alle Komponenten.

Einfache Frage mal, welche Impulsfrequenz liefern die Servoausgänge des FC.
Synchron zum SBUS oder einen eigenen Takt?
Wenn am FC lockout gemeldet wird, gibt es einen Ausgang, einen Pin, welcher ein Signal ausgibt?
Was nützt mir im Flug eine Anzeige auf dem OSD.
 
Zuletzt bearbeitet:
Ich glaube, diese Diskussion bringt so nicht viel. Die FC sind um Größenordnungen schneller als die SBus Frames. Die Racecoptermotoren können aktuell bis zu 1200 mal pro Sekunde unterschiedlich angesteuert werden. Die 111 oder 140 Hz des SBus sind Schnecke dagegen.

Wie LostFrame und Failsafe im SBus behandelt werden, ist Sache der FC Firmware, betaflight, iNav u.s.w.. Wenn die Entwickler der Meinung sind, dass bei einem extrem schnellen Quad 30 fehlende Frames ein Risiko darstellen, dann lösen sie nach diesen 30 eben RXLoss aus. Das ist ein Sicherheitsaspekt. Wenn ein GPS an Bord ist, kann man das Quad gerade richten, steigen und dann autonom landen lassen. Wenn nicht, Motoren aus und "landen".

Wichtig ist, dass die LostFrame Information wahr ist und keine Scheinsicherheit liefert. Ein Quad, das mit 200km/h in 1,5m Höhe unterwegs ist, ist etwas völlig anderes als ein Thermiksegler. Hier geht es um Sicherheit, bitte darüber nachdenken.

Was nützt mir im Flug eine Anzeige auf dem OSD.
Bei Betaflight zeigt der "LQ" genau die LostFrame Information an. Der Pilot kann damit frühzeitig erkennen, wenn Verbindungsprobleme auftreten. Man müsste im Code nachsehen, wie die angezeigten Stufen mit den LostFrames zusammenhängen.
 
Zuletzt bearbeitet:
Erhaltene "Gefällt mir": GerdS
Pascal Langer hat hier ein paar interessante Informationen veröffentlicht.
Übersetzung:
Ich erhalte viele Anfragen, ob FrSkyX V2 von Multi unterstützt wird, und teile daher einige Neuigkeiten mit.

Während FrSky das sporadische Problem der Servos durch Aktivieren der Hardware-CRC behebt, hat es seinem Protokoll 6 Anti-Kopier- / Klon-Schutzfunktionen hinzugefügt:
- 3 auf den Bindungspaketen: 1 schwach, 2 stark
- 2 auf den normalen Paketen: 2 Medium
- 1 zu den Telemetriepaketen des Empfängers: Ich habe es mir noch nicht angesehen, kann es also nicht bewerten.
Wie Sie aus der obigen Liste ersehen können, ist noch einiges zu tun.

Daher gibt es derzeit keine Antwort auf die Frage, ob sie unterstützt wird oder nicht. Die einzig gültige Antwort ist, dass wir daran arbeiten und die Zeit es zeigen wird.
Es spricht also vieles dafür, dass - Achtung @Norbert - die CRC Jungs nur als nützliche Idioten vorgeschoben wurden, um die Hardwareprobleme mit den "neuen" Sendern und die Kopierschutzgeschichte elegant zu verpacken. Bei der Gelegenheit hat FrSky dann auch gleich noch die LostFrames gefälscht, um eine einwandfreie Übertragungsqualität zu suggerieren. Und ich war mal FrSky Fan :rolleyes:
 
"As you can understand from the list above, there is quite some work which needs to be done"
Ist der Pascal genervt, belustigt oder ist das der sportliche Ehrgeiz?
Da gibt es noch einige Überraschungen.
 
Wenn man bedenkt, daß Pascal alleine alles, bis auf die Telemetrie, innerhalb von 3 Tagen geknackt hat, spricht das für seine Expertise, aber nicht unbedingt für einen guten Kopierschutz.
Den Clones ein paar Steine in den Weg zu legen, nimmt man natürlich gerne mit, aber das eigentliche Ziel war es nicht. Neben der CRC Sache, hat man eine verbesserte Daten-Kodierung eingeführt. Diese Verfahren sind längst bekannt z.B. bei HDDs, zur Vermeidung von mehreren gleichen Bitwerten hintereinander.
(siehe Manchester Code)
Da wo es darauf ankommt, bei den xxx.frk Flash-Dateien, hat bisher noch niemand die Kodierung des Hex-codes entschlüsselt. Außer Jumper, der ehemalige FrSky-Entwickler, der hat den Code einfach mitgehen lassen.
 
Nach dem bisherigen Verfahren, ist der SBUS (bestehend aus 2 Frames) komplett blockiert, wenn jeder zweite Frame ein Loss ist.
Nach dem neuen Verfahren wird ein gültiger Frame aus den letzten drei Frames zusammengesetzt, wenn ein Frame nicht gültig war. Also bis drei Frames zurück, darüber hinaus nicht.
Das ist eine wesentliche Verbesserung der SBUS Latency.
Es erfordert natürlich etwas Hirschmalz das zu verstehen.
Kann jeder hier nachvollziehen.
(Die Dateierweiterung PDF umändern in LOGICDATA und mit Saleae SW öffnen).
 

Anhänge

Nach dem bisherigen Verfahren, ist der SBUS (bestehend aus 2 Frames) komplett blockiert, wenn jeder zweite Frame ein Loss ist.
Ich kann doch aber nicht jeden Frame als gültig bezeichnen, wenn die Häfte verloren geht. Was ist daran so schwer zu verstehen? Ich habe 50% Frameverlust und 100% Signalqualität ?????

Das kann man wegen mir für die PWM Ausgänge machen, aber nicht für SBus/FPort. Dort verlässt man sich darauf, dass nicht manipuliert wird.
 
Zuletzt bearbeitet:
Racecopter mit 8 Kanälen, das ist der Standard für latenzkritische Anwendungen. Das bedeutet, jedes Frame kann neue Informationen in den 8 Kanälen haben. Wenn ein Frame ungültig ist, dann ist diese Information weg. Da kann der liebe Ewald noch so lange schwadronieren, sorry. Das kann man nicht hinbasteln und wenn man das trotzdem tut und als gültig bezeichnet, ist das gelogen.
 

Norbert

Erfahrener Benutzer
Achtung @Norbert - die CRC Jungs nur als nützliche Idioten vorgeschoben wurden, um die Hardwareprobleme mit den "neuen" Sendern und die Kopierschutzgeschichte elegant zu verpacken. Bei der Gelegenheit hat FrSky dann auch gleich noch die LostFrames gefälscht, um eine einwandfreie Übertragungsqualität zu suggerieren.
Ja - es gibt nützliche Idioten - und unnütze.
Es gibt logisch denkende und vorgehende Menschen und welche, die vermuteten und verdrehte Dinge als Tatsachen darstellen.
Und dann gibt es noch die die vorsätzlich falsche Dinge verbreiten.
Und dann gibt es noch die, die das alles glauben, weil sie es glauben wollen oder nicht besser wissen.

Was soll ich sagen - so langsam fehlen mir die Worte und die Motivation mich zu äussern.
Da haben Leute über 100derte von Stunden Fakten zusammengetragen, sich Messaufbauten ausgedacht, um den Fehler zu fixen. Dann analysiert welches Problem haben wir denn eigentlich und versucht daraus eine Lösung abzuleiten. Selbst die Sache, warum der Fehler nur im Nahbereich auftritt ist geklärt.

Dann gibt es einen der sagt, ich habe das Problem noch nie gehabt, also gibt es das auch nicht. Der jedem und allen unterstellt nur etwas vorzugaukeln, zu manipulieren und betrügen, ohne je etwas nachweisen zu können.

Dabei übersieht er, dass eine Verschachtelung von Daten nicht zwangsläufig nur ein Kopierschutz sein muss, sondern der Datensicherheit dienen kann.
Aussetzer im Nahbereich durch Reflektionen => bei mehreren Nullen oder Einsen, da dann die Synchronisation aus dem Tritt kommen kann.

Sorry, ich habe keine Lust mehr mich hierzu zu äußern, da es sinnlos ist. Entweder ist man Zwangsneurotiker, intellektuell nicht in der Lage den Sachverhalt nachzuvollziehen oder man gönnt anderen nicht was die gefunden haben.

Ausserdem ist es das gute Recht von FrSky sich zu schützen, oder versperrst du dein Haus nicht, wenn du in Urlaub fährst, um deine geschaffenen Werte zu schützen? Ob es was nützt weiss ich nicht - eher nicht denke ich. Aber der Versuch ist nicht verwerflich.

Ich verstehe FrSky auch nicht, ziehe aber keinerlei Vorteile von FrSky oder Engel, aber versuche die Sachlage sachlich richtig darzustellen.

Mir tut Engel leid und FrSky demontiert sich gerade selbst und verspielt jegliches Vertrauen - mal sehen, ob sie es in einem Jahr noch gibt. Das Desaster ging letztes Jahr so richtig los mit ungehaltenen Versprechen bei ACCESS, wo sie bis heute nicht richtig weiter kommen. Und dann komme noch ich mit meinen Vorhaltungen, dass es Verbindungsabbrüche gibt :mad:

So jetzt habe ich mir den Frust von der Seele geschrieben und mache mir was leckeres zum Abendessen.
 
Zuletzt bearbeitet:

arti

Well-known member
Racecopter mit 8 Kanälen, das ist der Standard für latenzkritische Anwendungen. Das bedeutet, jedes Frame kann neue Informationen in den 8 Kanälen haben. Wenn ein Frame ungültig ist, dann ist diese Information weg.
Hab ich das jetzt falsch verstanden? Im D16 8 Kanalmodus dürfte sich nichts geändert haben im Vergleich zur bisherigen Firmware.

Ein SBUS Frame wird aus Informationen von 2 HF Frames zusammengesetzt. Der Grund dafür ist dass ein HF Frame nur die Hälfte aller Kanäle vom SBUS überträgt, daher sind auch 2 HF Frames nötig um einen SBUS Frame zu bauen.
Wie ich jetzt sinnvoll mit einem SBUS Frame umgehe wenn ein einzelner HF Frame verloren geht, aber nicht beide, darüber kann man diskutieren. Prinzipiell schadet es nicht etwas mehr Hirnschmalz reinzustecken und nicht einfach beide HF Frames zu verwerfen wenn einer mal verloren gehen sollte. Je nachdem was die Randbedingungen der Anwendung sind kann man auch auf unterschiedliche Lösungen angewiesen sein.

Aber, wenn ich D16 mit nur 8 Kanälen betreibe, dann werden nur 8 Kanäle vom SBUS populiert. Jeder HF Frame überträgt diese 8 Kanäle, oder? Dann ist man wieder soweit das für einen SBUS Frame nur ein HF Frame notwendig ist. Dann braucht und kann man doch garnichts mehr ersetzen bei einem verlorenen HF Frame, dann muss er einem verlorenen SBUS Frame entsprechen. Hat das jemand schon ausprobiert?

Übrigens, die Lösung mit den max 3 SBUS Frames rückwirkend ersetzen bewirkt ziemlich schnell 100% Link Quality. Gehen wir mal von 98% guten HF Frames aus, also im Mittel 1 verlorener HF Frame von 50. Um einen einzigen SBUS Frame zu verlieren müssen entweder beide aufeinanderfolgende HF Frames ungültig sein (ist das so? oder werden hier einfach beide ersetzt) oder man hat bei 6 HF Frames 3 ungültige und noch dazu exakt jeder zweite. Die Wahrscheinlichkeiten für beide Fälle sind sehr klein, weswegen man eher länger warten muss um auch nur ein einziges Frameloss Bit am SBUS Port zu sehen.
 
FPV1

Banggood

Oben Unten