FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Glaube ich nicht, das war ja Authentigate 
FrSky hatte doch Sender ausgeliefert, bei denen das Modul über einen firmwaregesteuerten Schalter geschaltet wurde und wenn es kein von FrSky freigegebenes Modul war, konnte man es überhaupt nicht in Betrieb nehmen. Xlite vielleicht? Da hatten sogar FrSky Module nicht mehr funktioniert, wenn ich recht erinnere.
FrSky hatte doch Sender ausgeliefert, bei denen das Modul über einen firmwaregesteuerten Schalter geschaltet wurde und wenn es kein von FrSky freigegebenes Modul war, konnte man es überhaupt nicht in Betrieb nehmen. Xlite vielleicht? Da hatten sogar FrSky Module nicht mehr funktioniert, wenn ich recht erinnere.
Ich habe es mal so verstanden, das ein Verweis auf eine der im Empfänger gespeicherten Sprungtabellen mitgeschickt wird. Der im Normal aber immer derselbe ist. So hätte man aber die Möglichkeit, die Sprungtabelle zu wechseln. Wenn sich da ein Fehler einschleicht, dann kommt es zum Synchronisationsverlust. Wenn diese Möglichkeit nicht genutzt wird, dann ist sie ein Sicherheitsrisiko. Aber das ist nur Hörensagen ....
RC Groups - View Single Post - Important Firmware Update ACCST D16 2.0.0 - ACCESS also affected
Ich denke es ist nicht gesichert, daß FrSky mit jedem Frame die Sprungtabelle beeinflußt, das kann Mike auch nicht direkt bestätigen. Aber ein Glitch in den Hoppingdaten, führt dazu, daß der Empfänger glaubt er wäre nicht synchron und er startet den Synch.- Modus.
Ich denke es ist nicht gesichert, daß FrSky mit jedem Frame die Sprungtabelle beeinflußt, das kann Mike auch nicht direkt bestätigen. Aber ein Glitch in den Hoppingdaten, führt dazu, daß der Empfänger glaubt er wäre nicht synchron und er startet den Synch.- Modus.
Ja, gerade eben gelesen. Klingt erst mal vernünftig. Aber dann wäre die Wahrscheinlichkeit, dass Kanalwert und das Kanalhopping gleichzeitig betroffen sind, äußerst gering.
Aber das passt wiederum zu @quax2011, der ungefähr in jedem 3. oder 4. Flug einen Lockout misst, aber noch nie einen ungesteuerten Servoausschlag hatte. Den Lockout bemerkt man in der Regel nicht. Das heißt, dann würde es viel mehr Lockouts geben, die man messen kann aber nicht merkt, als Servoausschläge, die man definitiv bemerkt.
Ich hatte mit meinen alten Sendern übrgens noch nie einen Lockout und ich habe viele Flüge mit LostFrame Sensor gemacht.
Passt die Frequenzabweichung bei dem bisher einzigen gemessenen Problemsender in die Theorie? Nebenbei: heute konnte ich eine QX7 messen, die lag exakt im Soll.
Aber das passt wiederum zu @quax2011, der ungefähr in jedem 3. oder 4. Flug einen Lockout misst, aber noch nie einen ungesteuerten Servoausschlag hatte. Den Lockout bemerkt man in der Regel nicht. Das heißt, dann würde es viel mehr Lockouts geben, die man messen kann aber nicht merkt, als Servoausschläge, die man definitiv bemerkt.
Ich hatte mit meinen alten Sendern übrgens noch nie einen Lockout und ich habe viele Flüge mit LostFrame Sensor gemacht.
Passt die Frequenzabweichung bei dem bisher einzigen gemessenen Problemsender in die Theorie? Nebenbei: heute konnte ich eine QX7 messen, die lag exakt im Soll.
OK, was steht genau drin in den Hopping Daten? Ein Link auf eine Sprungtabelle? Der nächste Sprung kann es ja nicht sein, das gäbe bei jedem verlorenen Frame Chaos.
Es geht ja auch gar nicht darum, ob FrSky beeinflussen will, es geht darum, ob ein falsch übertragener Wert beeinflussen kann. Und das scheint definitiv der Fall zu sein.
Es geht ja auch gar nicht darum, ob FrSky beeinflussen will, es geht darum, ob ein falsch übertragener Wert beeinflussen kann. Und das scheint definitiv der Fall zu sein.
Was genau in den Hopping Daten der Frames drin steht, ist im Detail nicht wichtig.
Die Spezialisten wissen hier zwar mehr, aber es gibt Verpflichtungen Firmeninterne Details zu respektieren.
Entscheidend ist wie die Hopping Daten verarbeitet werden und wie es sich auswirkt und das ist Sache der FW, wo niemand Einblick hat. Wir können nur auf zugänglichen Schnittstellen messen, welche Daten ausgetauscht werden und daraus Rückschlüsse ziehen.
Aus meiner Sicht, werden die übertragenen Hopping Daten im Empfänger überprüft, ob sie mit der Empfänger-internen Hoppingtabelle übereinstimmen. Wenn nicht wird der Modus zur Wiederherstellung der Synchronisation eingeleitet und das dauert normal 0,9s.
Eine Veränderung des Hopping-Musters, ausgehend vom Empfänger, kann ich mir nicht vorstellen.
Dazu müßte eine Rückmeldung an den Sender erfolgen und sichergestellt werden, daß dieser das erkannt hat und der wiederum ein Acknowledge Signal an den Empfänger geben, damit dieser weiß, die neue Tabelle ist bestätigt und wird aktiv. Man bedenke hierbei, daß der Sender als Master der Synchronisation zu sehen ist und der Empfänger der Slave.
Eine Änderung der Hopping Tabelle ohne Handshake halte ich für fahrlässig, damit wäre die Funkverbindung nicht so stabil wie wir sie kennen.
Anbei der Ablauf eines Frames mit Signalen im Sender, ein Handshake wäre am CTX Signal erkennbar, es müßte mehrmals zwischen Senden und Empfangen hin- und herschalten.
Die Spezialisten wissen hier zwar mehr, aber es gibt Verpflichtungen Firmeninterne Details zu respektieren.
Entscheidend ist wie die Hopping Daten verarbeitet werden und wie es sich auswirkt und das ist Sache der FW, wo niemand Einblick hat. Wir können nur auf zugänglichen Schnittstellen messen, welche Daten ausgetauscht werden und daraus Rückschlüsse ziehen.
Aus meiner Sicht, werden die übertragenen Hopping Daten im Empfänger überprüft, ob sie mit der Empfänger-internen Hoppingtabelle übereinstimmen. Wenn nicht wird der Modus zur Wiederherstellung der Synchronisation eingeleitet und das dauert normal 0,9s.
Eine Veränderung des Hopping-Musters, ausgehend vom Empfänger, kann ich mir nicht vorstellen.
Dazu müßte eine Rückmeldung an den Sender erfolgen und sichergestellt werden, daß dieser das erkannt hat und der wiederum ein Acknowledge Signal an den Empfänger geben, damit dieser weiß, die neue Tabelle ist bestätigt und wird aktiv. Man bedenke hierbei, daß der Sender als Master der Synchronisation zu sehen ist und der Empfänger der Slave.
Eine Änderung der Hopping Tabelle ohne Handshake halte ich für fahrlässig, damit wäre die Funkverbindung nicht so stabil wie wir sie kennen.
Anbei der Ablauf eines Frames mit Signalen im Sender, ein Handshake wäre am CTX Signal erkennbar, es müßte mehrmals zwischen Senden und Empfangen hin- und herschalten.
Anhänge
Zuletzt bearbeitet:
Ah, das macht Sinn.
- Frame verloren, dann hoppt der Empfänger auf die nächste Frequenz der internen Tabelle
- Frame OK, dann vergleicht der Empfänger, ob es die nächste Frequenz die gleiche ist, wie er sie sowieso anspringen würde
- Frame angeblich OK, aber andere Frequenz im Frame, dann wird die weiße Fahne geschwenkt und neu synchronisiert
Die nächste Frage: Kommt es zu wesentlich mehr Lockouts als ungewollten Servobewegungen, weil im letzteren Fall zwei Fehler zusammen auftreten müssen? Lockouts hatte ja @quax2011 schon genügend, aber noch keinen Breakdance.
- Frame verloren, dann hoppt der Empfänger auf die nächste Frequenz der internen Tabelle
- Frame OK, dann vergleicht der Empfänger, ob es die nächste Frequenz die gleiche ist, wie er sie sowieso anspringen würde
- Frame angeblich OK, aber andere Frequenz im Frame, dann wird die weiße Fahne geschwenkt und neu synchronisiert
Die nächste Frage: Kommt es zu wesentlich mehr Lockouts als ungewollten Servobewegungen, weil im letzteren Fall zwei Fehler zusammen auftreten müssen? Lockouts hatte ja @quax2011 schon genügend, aber noch keinen Breakdance.
Ich würde die Auswirkung des Problems in 4 Kategorien darstellen, wie auch Mike.
Mit der höchsten Häufigkeit zuerst.
1. Servodatenfehler unbemerkt, da kein Servo am betroffenen Kanal angeschlossen und zu kurz.
2. Servodatenfehler unbemerkt, da Servo angeschlossen, aber zu kurz, nur 2-4 Frames.
3. Lockout mit Neu-Synchronisation, alle Servos auf Hold, oft unbemerkt, oft verwechselt mit FailSafe.
4. Lockout mit Neu-Synchronisation + Servodatenfehler, das Servo läuft für 0,9s auf einen falsche Position.
Der relative Unterschied der Häufigkeit zwischen 1. und 4. beträgt ca. 1 : 30, gemessen mit etlichen Messreihen. Das scheint plausibel, denn die Verteilung von Servodaten und Kontrolldaten in einem Frame bewegt sich in einem ähnlichem Verhältnis.
Mit der höchsten Häufigkeit zuerst.
1. Servodatenfehler unbemerkt, da kein Servo am betroffenen Kanal angeschlossen und zu kurz.
2. Servodatenfehler unbemerkt, da Servo angeschlossen, aber zu kurz, nur 2-4 Frames.
3. Lockout mit Neu-Synchronisation, alle Servos auf Hold, oft unbemerkt, oft verwechselt mit FailSafe.
4. Lockout mit Neu-Synchronisation + Servodatenfehler, das Servo läuft für 0,9s auf einen falsche Position.
Der relative Unterschied der Häufigkeit zwischen 1. und 4. beträgt ca. 1 : 30, gemessen mit etlichen Messreihen. Das scheint plausibel, denn die Verteilung von Servodaten und Kontrolldaten in einem Frame bewegt sich in einem ähnlichem Verhältnis.
Gute Frage Vielleicht haben sie nur das nachgebaut, was zur Funktion notwendig ist. Und das was zu Lockouts führt, nicht Ich kenne keinen dokumentierten Lockout mit dem MPM und schon gar keinen Breakdance. Aber dass es das nicht gibt, kann ich natürlich nicht sicher sagen.
Plausibel für die statistische Verteilung der einzelnen Fehler vielleicht, aber wie wahrscheinlich ist es, dass die beiden Fehler zusammen auftreten? Jetzt brauchen wir einen Stochastiker
Vielleicht haben sie nur das nachgebaut, was zur Funktion notwendig ist. Und das was zu Lockouts führt, nicht Ich kenne keinen dokumentierten Lockout mit dem MPM und schon gar keinen Breakdance. Aber dass es das nicht gibt, kann ich natürlich nicht sicher sagen.Plausibel für die statistische Verteilung der einzelnen Fehler vielleicht, aber wie wahrscheinlich ist es, dass die beiden Fehler zusammen auftreten? Jetzt brauchen wir einen Stochastiker
Gute Frage Vielleicht haben sie nur das nachgebaut, was zur Funktion notwendig ist.
Vielleicht haben sie nur das nachgebaut, was zur Funktion notwendig ist.
Wie das im einzelnen funktioniert => Pascal direkt fragen. Ich benutze nur das MPM.
Das macht doch so keinen Sinn. Wenn der Empfänger ein für ihn gültigen Frame identifiziert hat, muss er beim Empfang dieses Frames auf der richtigen Frequenz gelegen haben. Warum will man das Anzweifeln und neu synchronisieren? Da geht doch jeder normal denkende Mensch auf den nächsten geplanten Hoppingkanal.
Andersrum wird ein Schuh draus. Wenn der Empfänger keine gültigen Frames mehr empfängt weil der Sender gerade mal durch LBT blockiert wird, dann könnte man auf die Idee kommen neu zu synchronisieren. Aber wenn man weiss, dass man mit LBT arbeitet, macht man genau das nicht.
Genau an dieser Stelle macht dann ein zweiter (doppel) Empfänger auf der Platine mal richtig sinn. Der eine synchronisiert mal neu, während der andere die geplante Hoppingtabelle abarbeitet. So ein Empfänger dürfte beim Preis eher unauffällig sein ...
Sigi
Andersrum wird ein Schuh draus. Wenn der Empfänger keine gültigen Frames mehr empfängt weil der Sender gerade mal durch LBT blockiert wird, dann könnte man auf die Idee kommen neu zu synchronisieren. Aber wenn man weiss, dass man mit LBT arbeitet, macht man genau das nicht.
Genau an dieser Stelle macht dann ein zweiter (doppel) Empfänger auf der Platine mal richtig sinn. Der eine synchronisiert mal neu, während der andere die geplante Hoppingtabelle abarbeitet. So ein Empfänger dürfte beim Preis eher unauffällig sein ...
Sigi
