Vorsicht bei "Telemetrie verloren" mit Horus

FJH

Erfahrener Benutzer
Ich sehe auch das grösste Problem damit wäre die offizelle CE Zertifizierung hier und die FAA in USA. Beides kostet eine schöne Stange Geld. Frage ist dann wer macht das? Und dann weiter, wenn einmal zugelassen, dann ist so ohne neue Prüfung nix mehr mit Verändern oder Anpassen des Codes, das würde dann neue Zulassung bedeuten. Also einmal Code zertifiziert und Ende, nix mit weiterentwickeln so wie es bei OTx läuft.
 

FJH

Erfahrener Benutzer
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?
Mike Blandfort antwortete auf die Frage mit dem Verweis darauf, dass die Datenraten der Übertragung nach "altem" ACCST unterschiedlich sind, bei FCC sind es seiner Angabe nach ca. 70.000 bits/sec und bei LBT sind es ca. 100.000 bits/sec => RC Groups - View Single Post - Important Firmware Update ACCST D16 2.0.0 - ACCESS also affected

Damit sind wir wieder bei der alten Erkenntnis, dass höhere Datenraten in der Signalübertragung das Fehlerrisiko der Übertragung erhöhen.
 
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+.

In der 170317 wurde erst die Übertragung von S-Port Daten aktiviert von daher geht kein Weg an dieser Firmware vorbei, das steht zwar nicht auf der Frsky Seite, ist aber auch nichts neues.
 

FJH

Erfahrener Benutzer
Das erfährt man noch irgendwann. Von Ewald gibt es aber einen Hinweis, der auf Konkurrenzausschluss hinauslaufen könnte. Sympathischer wäre natürlich, wenn FrSky nur Bugs mit der V2 Firmware beseitigt hätte, aber glaubt das wirklich irgendjemand? Ich definitiv nicht ;)
Hier gibt's auch noch eine Anmerkung von Mike Blandford als Antwort auf eine Anmerkung von 3djc zu vermuteter Verschlüsselung der Daten:

I don't think they have encrypted the data as such. I believe part of the problem (servo glitches) was due to some transmitters frequency drifting. When this happens, the receiver can have trouble decoding the data, as it is at the wrong rate, particularly if there is a long string of 0s or 1s as the clock recovery cannot lock on to these. FrSky are modifying the data to avoid such strings occurring.

=> RC Groups - View Single Post - Jumper T16 2.4G 16CH OpenTX Multi-protocol Radio
 
Allmählich akzeptiert jeder die Fakten und erkennt die tatsächliche Situation.
Alles ist längst bekannt, hätte man sich die wesentlichen Beiträge, auch im FrSky-Forum, genau angeschaut.
Wie kommt es dazu?
Verschwörungstheorien sind in der Masse einfach beliebter und bequemer, Sachlichkeit ist anstrengend.

Was zu den bekannten Fakten noch zu sagen wäre ist, daß das Data-Whitening (vermeiden von kritischen Bitfolgen) nicht mit der im CC2500 integrierten HW umgesetzt wird, sondern per FW.
Das ist kein Problem, die Prozessorleistung wird dadurch kaum beansprucht.
Grund ist wohl die Kompatibilität mit HF-Chips anderen Typs und daß man sich die Unabhängigkeit davor bewahren will. Genauso wie beim CRC Verfahren, welches zuvor ebenfalls selbstgestrickt war, und nicht das im HF-CHip integrierte zur Anwendung kam.

Ein selbst-definiertes Data-Whitening kann man als Verschlüsselung zur Behinderung der Clones auslegen, oder als Verbesserung der Datenübertragung. Das ist Ansichtssache und wie man die Welt gerne sehen möchte.
Ich bin mir sicher, FrSky hätte nie diesen Aufwand betrieben nur um der Konkurrenz eins auszuwischen, aber wenn das als Nebeneffekt dabei heraus kommt, wären sie ja blöd, wenn sie es nicht täten.

FrSky hat eine ganze Latte neuer Produkte in der Pipeline, mit dem neuen Übertragungsverfahren ACCESS.
Eine entsprechende Auslegung der neuen Produkte, nur um die Clones zu blockieren, hätte aus wirtschaflticher Sicht bei ACCESS vollkommen ausgereicht.
 
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?
Wenn Du Dir den Text auf der FrSky Seite ansiehst, dann ist das eigentlich offiziell Warnung genug.
frsky.JPG
Solange nicht alle potentiell betroffenen Produkte mit einem zuverlässigen Update versehen sind, werden die Händler wegen der geringen Fehlereintrittswahrscheinlichkeit keinesfalls ihre Umsätze auf´s Spiel setzen und selber eine offizielle Warnung herausgeben. Das können die sich einfach auch nicht leisten. Es ist ja schon mal Super, wie der Engel sich in der Sache einsetzt. Wenn das Thema letztlich gelöst ist, dann kommt da bestimmt auch was offizielles. Das müssen sie ja auch machen, wenn sie dann das Equipment nur noch mit der neuen Firmware ausliefern.
 
Allmählich akzeptiert jeder die Fakten und erkennt die tatsächliche Situation.
Alles ist längst bekannt, hätte man sich die wesentlichen Beiträge, auch im FrSky-Forum, genau angeschaut.
Wie kommt es dazu?
Verschwörungstheorien sind in der Masse einfach beliebter und bequemer, Sachlichkeit ist anstrengend.
Sehr gut, ich bin auch ein großer Feind von Verschwörungstheorien und ein großer Freund der Wahrheit. Dann sei doch so gut und beschreibe die durchgeführten Maßnahmen in Stichworten. Mike Blandford macht es ja vor, wie man das allgemeinverständlich tun kann. Bitte folgende Punkte ergänzen:

- Welche verschiedenen Schutzmaßnahmen hat FrSky eingesetzt
- Warum wird das Lost Frame Bit jetzt erst nach 3 verlorenen Frames gesetzt
- Mit einem nachvollziehbaren Beispiel bitte, warum das Sinn machen soll
- Warum ist LBT so viel stärker betroffen als FCC
- Warum sind X9D und X9E fast nicht betroffen
- Wieso war z.B. bei Norbert der Fehler nach Tausch des Sendemoduls beseitigt
 
Zuletzt bearbeitet:
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?
Neben der Bitrate unterscheiden sich FCC und LBT im Modulationsverfahren.
FCC, GFSK, 70.000b/s
LBT, 2FSK, 100.000b/s
Grundsätzlich wird die Reicheite/Empfindlichkeit des Empfängers geringer, je höher die Bitrate ist.
Deshalb gab es bei der Zwischenlösung EU-MU mit mehr als 200.000b/s die Probleme.
Ob sich der relativ geringe Unterschied der Reichweite von 70.000 zu 100.000 durch 2FSK kompensieren läßt, kann ich nicht sagen.
Bei 2FSK habe ich einen deutlicheren, schnelleren Frequenzhub und verweile länger auf einem der zwei "Höcker", siehe Spektrum. Das wirkt sich negativ auf die Nebenwellenabstrahlung aus, aber ich kann besser zwischen 0 und 1 unterscheiden.
Die schnellere Übertragungsrate bei LBT war notwendig, um innerhalb der gegebenen 9ms Platz zu schaffen für LBT.
 
Zuletzt bearbeitet:
Das vermeiden kritischer Bitfolgen betrifft doch die Kommunikation zwischen Prozessor und CC2500. Also müssen doch beide Seiten die Prozedur verstehen. Die HW im CC2500 kann das sowieso schlecht alleine machen.
Nein, das Vermeiden kritischer Bitfolgen ist nur auf der HF-Strecke relevant.
Um es mal bildlich auszudrücken, ich fliege durch die Fresnelzone, vom Sender kommen lauter 1-en, plötzlich ein Phasensprung im Signal und ich sehe nicht mehr, waren es jetzt 6 oder 7 einsen.
Häufige wechsel zwischen 0 und 1 können mich nicht so leicht aus dem Konzept bringen.
Schließlich ist so ein Empfänger aus nur ein Mensch, oder ein Carbo.
 
Zuletzt bearbeitet:
Das ist aber immer noch keine Erklärung zu der höheren Empfindlichkeit für Lockouts. Ist es denkbar, dass das 2FSK Verfahren empfindlicher auf Frequenztoleranz ist? Es gibt ja immer noch die zwei Hypothesen

- CRC Fehler bei der Hopping Tabelle führen zum Lockout
- Frequenzabweichung und ungeschickte Bitfolge führen zum Verlust der Synchronisation=Lockout

Mike Blandford spricht für das Erste, @Norbert massiv und nachvollziehbar für das Zweite. Kann am Ende beides zum Lockout führen? Oder weiß man es gar nicht so ganz genau?

Und dann ist ja noch das andere Thema im Raum. Welchen Mist jubelt uns FrSky mit diesem Update unter?
- zusätzlicher Code für eine für die Sicherheit unnötige Verschlüsselung?
- eine gefälschte FrameLoss Information?

Fragen, die auf eine Antwort warten.

Nein, das Vermeiden kritischer Bitfolgen ist nur auf der HF-Strecke relevant.
Ja, die Frage von mir war Blödsinn, ich hatte sie auch schon vor deiner Antwort wieder rauseditiert.
 
So wie ich das verstanden habe ist die Hopping Tabelle pro Sendermodul konstant. Es gibt 3 verschiedene Hopping Tabellen, die je nach Seriennummer des Sendermodules ausgewählt werden.
Wahrscheinlich ist hier bei einigen alten X9D der Fehler passiert mit der neuen Firmware was zu miesen Verbindungen und schlechtem RSSI führt.
Eine dynamische Hopping-Tabelle macht nicht besonders viel Sinn.
 
[
So wie ich das verstanden habe ist die Hopping Tabelle pro Sendermodul konstant. Es gibt 3 verschiedene Hopping Tabellen, die je nach Seriennummer des Sendermodules ausgewählt werden.
Wahrscheinlich ist hier bei einigen alten X9D der Fehler passiert mit der neuen Firmware was zu miesen Verbindungen und schlechtem RSSI führt.
Eine dynamische Hopping-Tabelle macht nicht besonders viel Sinn.
Eine dynamische Hopping Tabelle wäre das DAA Verfahren (detect and avoid).
Das ist aber in der Conf. Erklärung nicht so deklariert, FrSky mach LBT.
Außerdem bräuchte man dazu aber eine wesentlich aufwendigere HW, wie z.B. Weatronic.

Ich denke das ist nur ein zusätzliche Sicherheitsmaßnahme.
In jedem Frame sagt der Sender dem Empfänger, an welcher Stelle er in der Hopping Tabelle steht, als zusätzlichen Sicherheitsabgleich.
Es gibt aber keine Absprache zwischen TX und RX, die Tabelle zu verändern.
Das wäre fatal wenn diese Info mitten im Betrieb verloren ginge.
 
Eine dynamische Hopping-Tabelle macht nicht besonders viel Sinn.
Es gibt aber keine Absprache zwischen TX und RX, die Tabelle zu verändern.
Das wäre fatal wenn diese Info mitten im Betrieb verloren ginge.
OK, dann lag Midelic wohl daneben. Es wäre tatsächlich auch ein Sicherheitsrisiko. Dann fassen wir doch einfach die zwei Lockout Hypothesen zusammen:

Eine Frequenzabweichung im Sender verursacht zusammen mit einer kritischen Bitfolge "über die Luft" den Verlust der Synchronisation. Das Verhindern der kritischen Bitfolge verhindert den Synchronisationsverlust.

Besser? Zu meinen Beobachtungen würde es jedenfalls passen.
 
Zuletzt bearbeitet:
Eine Frequenzabweichung im Sender verursacht zusammen mit einer kritischen Bitfolge "über die Luft" den Verlust der Synchronisation. Das Verhindern der kritischen Bitfolge verhindert den Synchronisationsverlust.
Ja. Einen reinen Bit- oder Byte-Synchronisationsverlust würde aber niemand bemerken, dann fällt halt ein Frame aus. Die Snychronisation startet bei jedem Frame von neuem mit der Preamble des Datenpaketes.

Carbo will nachweisen, daß ein Frame-Synchronisationsverlust mit der CRC Sache nichts zu tun hat.
Wenn dem so wäre dürfte es bei den 0.9s Lockouts keine Datenfehler geben. Sie sind aber da.

Wenn man tiefer einsteigen will sollte man zuerst einmal genau den Lockout definieren, was damit gemeint ist. Was bedeutet das genau, was irgendwelchen Anzeigen der Elektronik dritter Parteien darstellen?
 
Ich will nichts nachweisen, ich möchte die Wahrheit wissen.
Carbo will nachweisen, daß ein Frame-Synchronisationsverlust mit der CRC Sache nichts zu tun hat.
Wenn dem so wäre dürfte es bei den 0.9s Lockouts keine Datenfehler geben. Sie sind aber da.
@quax2011 ist der erste, der mit einem kritischen Sender (X12) mit Lostframe Sensor fliegt und er hat bereits zwei Lockouts nachgewiesen. Der Arduino arbeitet unabhängig, ermittelt einen gleitenden Durchschnitt der erfolgreich übertragenen Frames und schickt den Wert über den SBus. Simple Sache, leicht nachzubauen und keine Raketentechnik und Open Source. @quax2011 besteht trotz hochnotpeinlicher Befragung darauf, dass er keine Fehlausschläge hatte. Diese Lockouts gehen auch zeitweise mit einer "Telemetrie verloren" Meldung in unverdächtiger Entfernung einher, daher der Threadtitel.

Mir geht es vor Allem auch darum, zu klären, warum meine Sender nicht betroffen sind. Ich habe hunderte bestens dokumentierte Messflüge mit openXsensor gemacht und hatte nicht einen einzigen Zucker. Andere Kollegen, die jahrelang schon auf FrSky schwören, Mike Shellim zum Beispiel, sind auch aus allen Wolken gefallen, als sie erfahren haben, dass ihre Systeme ungesteuerte Ausschläge zeigen sollen. Alles alte Sender wohlgemerkt. Es gibt eine Menge Nichtnasenbohrer, die die "alle sind betroffen" Story nicht abkaufen wollen. Denen muss jemand mal die Hintergründe und die Fehlerwahrscheinlichkeit bei üblicher Nutzung erklären.

So wie bei @quax2011 klar ist, dass etwas faul ist, ist bei anderen klar, dass alles in Ordnung ist. Ich denke, dass die Leute, die eine Menge Geld bei FrSky gelassen haben, einen Anspruch auf die Wahrheit haben.
 
RCLogger

FPV1

Banggood

Banggood

Oben