FRSKY Vorsicht bei "Telemetrie verloren" mit Horus
- Themenstarter Carbonator
- Beginndatum
Du meinst, ich poste als Thomas W.? Leider falsch, aber der Post könnte wirklich von mir sein. Es gibt schon noch ein paar Leute, die Ahnung haben 
Aber leider noch viel mehr Leute, die überhaupt keine Ahnung haben, wenn man die Likes zu dem Beitrag sieht, um den es Thomas W. ging.
Aber leider noch viel mehr Leute, die überhaupt keine Ahnung haben, wenn man die Likes zu dem Beitrag sieht, um den es Thomas W. ging.
Auch mir graut es bei der Vielfalt an Meinungen ohne erkennbaren Sachverstand ... mache sollten lieber ihren WebAdmin Job machen oder Motorrad fahren
Das sehe ich nicht ganz so negativ, jeder erzählt mal Blödsinn. Ich finde es nur bedenklich, wenn man Blödsinn nicht mehr als Blödsinn bezeichnen darf. Und sich dann vielfach ge-like-ter Blödsinn als "Erkenntnis" etabliert.
Dass unsere Modellflugplätze in der Pampa mit 2,4GHz verseucht sein sollen, ist zum Beispiel so ein Blödsinn. Aber so wird wenigstens aus dem neuen Schbeggdrumm-Änneleiser ein sinnvolles Fiedscher
Dass unsere Modellflugplätze in der Pampa mit 2,4GHz verseucht sein sollen, ist zum Beispiel so ein Blödsinn. Aber so wird wenigstens aus dem neuen Schbeggdrumm-Änneleiser ein sinnvolles Fiedscher
Hmm,
ich habe mir auch mal Gedanken gemacht. Die Daten werden ja mit vom Sendemodul mit CRC16 gesichert.
D.h. es gibt nur verschiedene 65536 Sicherungswerte. Da es aber sehr viel mehr Kombinationen der Datenbytes an sich gibt, können Übertragungsfehler (z.b. ein bit oder mehrere zerstört) nicht zuverlässig erkannt werden. Denn die Berechnung des CRC16 im Empfänger kann ja die selbe checksumme auch bei falschen Daten ergeben. Also es können Daten als korrekt erkannt werden obwohl sie falsch sind. Zwar nur gaaaanz, gaaanz selten, aber es kann auftreten.
Aber nur dann wenn die Erkennung des HF Baustein auf unterer Ebene noch gültige Pakete erkennt. Dieser
hat auch eine Datensicherung drin.
Oder der Empfänger hat ein Problem (Software) wenn die Daten mittendrin kurz aufhören und er dies nicht erkennt und CRC Berechnung wiederum korrekte Daten ergibt.
Da nun Ewald ja die HF Strecke stört, tritt dieser Fehler viel öfter auf. Dazu noch das LBT bei dem u.U. Datenpakete für längere Zeit fehlen und failsafe ausgelöst wird (ist aber meiner Meinung nach ein extra Problem).
Ist aber nur Spekulation von mir.
Habe kürzlich mal einen SBUS Decoder gebaut, der mir das Lostframe bit detektiert.
Das kam bei mir im Keller ziemlich oft. Habs aber nicht weiter analysiert.
P.s.
bin beruflich Embedded Entwickler und hab selber schon solche Probleme gehabt.
ich habe mir auch mal Gedanken gemacht. Die Daten werden ja mit vom Sendemodul mit CRC16 gesichert.
D.h. es gibt nur verschiedene 65536 Sicherungswerte. Da es aber sehr viel mehr Kombinationen der Datenbytes an sich gibt, können Übertragungsfehler (z.b. ein bit oder mehrere zerstört) nicht zuverlässig erkannt werden. Denn die Berechnung des CRC16 im Empfänger kann ja die selbe checksumme auch bei falschen Daten ergeben. Also es können Daten als korrekt erkannt werden obwohl sie falsch sind. Zwar nur gaaaanz, gaaanz selten, aber es kann auftreten.
Aber nur dann wenn die Erkennung des HF Baustein auf unterer Ebene noch gültige Pakete erkennt. Dieser
hat auch eine Datensicherung drin.
Oder der Empfänger hat ein Problem (Software) wenn die Daten mittendrin kurz aufhören und er dies nicht erkennt und CRC Berechnung wiederum korrekte Daten ergibt.
Da nun Ewald ja die HF Strecke stört, tritt dieser Fehler viel öfter auf. Dazu noch das LBT bei dem u.U. Datenpakete für längere Zeit fehlen und failsafe ausgelöst wird (ist aber meiner Meinung nach ein extra Problem).
Ist aber nur Spekulation von mir.
Habe kürzlich mal einen SBUS Decoder gebaut, der mir das Lostframe bit detektiert.
Das kam bei mir im Keller ziemlich oft. Habs aber nicht weiter analysiert.
P.s.
bin beruflich Embedded Entwickler und hab selber schon solche Probleme gehabt.
Diese Erkenntnis bezweifelt ja niemand. Es stellen sich aber drei Fragen. Welche Auswirkungen hat ein "falsches" Frame in der Praxis? Lag der simulierte Zustand, also viele fehlende Frames und Störquellen bei den dokumentierten Fehlern überhaupt vor? Warum hat man den Fehler jahrelang nicht bemerkt, wenn er doch die komplette CC2500 Hardware betrifft?
Die erste Frage kann sich jeder selbst beantworten. Wir wissen, dass im Normalfall 111 Frames/s ankommen, wir kennen die Stellgeschwindigkeit der Servos.
Bei der zweiten Frage ist die Antwort ganz klar nein. Die Fehler traten auch in naher Umgebung bei hoher Feldstärke und geringer Störstrahlung auf.
Frage 3: Der Fehler tritt in der Praxis nicht auf, weil der Bereich, in dem sich Lost Frames häufen, außerhalb der Sichtweite liegt. Und wenn ein Frame tatsächlich mal falsche Daten enthalten sollte, merkt man das nicht. Bei den vielen tausend Nutzern, die FrSky in der Anfangszeit kritisch beäugt haben (wie ich auch), wäre so ein Fehler definitiv aufgefallen.
Wer sich Sorgen über Lost Frames macht, sollte den Sensor nachbauen und sich selbst ein Bild machen. Ich verstehe ja, dass man in der Begeisterung, einen Fehlausschlag unter bestimmten Bedingungen nachweisen zu können, euphorisch wird, aber man sollte danach gedanklich zwei Schritte zurücktreten und die Erkenntnis mit der Praxis abgleichen. Wenn das dann aber zu dem Schluss führt, dass auf unseren Plätzen in der Pampa eine 2,4 GHz Verseuchung existieren muss, sonst würde ja der Fehler nicht auftreten, läuft etwas massiv schief.
Mit dem Lost Frame Sensor und dem Spectrum Analyzer kann man sich selbst ein Bild machen. Es gibt keinen Grund hysterisch zu werden. Vielleicht führt ja die LBT Firmware Geschichte von Xedos9er in die richtige Richtung.
Edit, ganz vergessen: Das eigentliche Problem ist doch der Lockout und die CRC-Sache eignet sich kaum, den Lockout zu erklären.
Die erste Frage kann sich jeder selbst beantworten. Wir wissen, dass im Normalfall 111 Frames/s ankommen, wir kennen die Stellgeschwindigkeit der Servos.
Bei der zweiten Frage ist die Antwort ganz klar nein. Die Fehler traten auch in naher Umgebung bei hoher Feldstärke und geringer Störstrahlung auf.
Frage 3: Der Fehler tritt in der Praxis nicht auf, weil der Bereich, in dem sich Lost Frames häufen, außerhalb der Sichtweite liegt. Und wenn ein Frame tatsächlich mal falsche Daten enthalten sollte, merkt man das nicht. Bei den vielen tausend Nutzern, die FrSky in der Anfangszeit kritisch beäugt haben (wie ich auch), wäre so ein Fehler definitiv aufgefallen.
Wer sich Sorgen über Lost Frames macht, sollte den Sensor nachbauen und sich selbst ein Bild machen. Ich verstehe ja, dass man in der Begeisterung, einen Fehlausschlag unter bestimmten Bedingungen nachweisen zu können, euphorisch wird, aber man sollte danach gedanklich zwei Schritte zurücktreten und die Erkenntnis mit der Praxis abgleichen. Wenn das dann aber zu dem Schluss führt, dass auf unseren Plätzen in der Pampa eine 2,4 GHz Verseuchung existieren muss, sonst würde ja der Fehler nicht auftreten, läuft etwas massiv schief.
Mit dem Lost Frame Sensor und dem Spectrum Analyzer kann man sich selbst ein Bild machen. Es gibt keinen Grund hysterisch zu werden. Vielleicht führt ja die LBT Firmware Geschichte von Xedos9er in die richtige Richtung.
Edit, ganz vergessen: Das eigentliche Problem ist doch der Lockout und die CRC-Sache eignet sich kaum, den Lockout zu erklären.
Zuletzt bearbeitet:
Da stimme ich voll zu. Einzelne defekte Frames können unsere Servos gar nicht abbilden.
Im Nahbereich können gar nicht so viele Frames zerstört sein, dass sich das auswirkt.
Ich glaube eher, es werden irgendwelche (Fehler) Zähler im Empfänger nicht richtig zurückgesetzt bzw.
laufen über und er resetet sich bzw. initalisert ein Teil der Software.
Irgendwas in der Richtung. Wie teilweise das Einschaltzucken beim Einschalten des Empfängers.
Ich glaube es sind halt 2 Fehler drin. Das zucken im Nahbereich und die Microausschläge am Ende der Reichweite.
Daher meine ich auch, dass das ganze HF verseuchte Flugplatz Gesülze für die Katz ist.
Nachtrag:
Ich hatte so einen Ausschlag im Nahbereich auch schon (qx7 / LBT und S6R) Landeanflug und dabei keine Knüppel bewegt, also den Flieger alleine reinkommen lassen. (Failsafe auf Hold)
Im Nahbereich können gar nicht so viele Frames zerstört sein, dass sich das auswirkt.
Ich glaube eher, es werden irgendwelche (Fehler) Zähler im Empfänger nicht richtig zurückgesetzt bzw.
laufen über und er resetet sich bzw. initalisert ein Teil der Software.
Irgendwas in der Richtung. Wie teilweise das Einschaltzucken beim Einschalten des Empfängers.
Ich glaube es sind halt 2 Fehler drin. Das zucken im Nahbereich und die Microausschläge am Ende der Reichweite.
Daher meine ich auch, dass das ganze HF verseuchte Flugplatz Gesülze für die Katz ist.
Nachtrag:
Ich hatte so einen Ausschlag im Nahbereich auch schon (qx7 / LBT und S6R) Landeanflug und dabei keine Knüppel bewegt, also den Flieger alleine reinkommen lassen. (Failsafe auf Hold)
Ich glaube der Geschichte bisher auch nicht. Mein letzter Lockout war in einer Entfernung von ca. 6m Luftlinie zum Sender, grad mal um die Hausecke.
Und einzelne defekte Frames erklären auch nicht, weshalb es im Anschluss zum falschen Kanalwert zum Lockout kommt, oder weshalb der XM+ einen falschen Kanalwert vor dem Lockout ausgibt, der R-XSR jedoch nicht, aber insgesamt deutlich mehr Lockouts zeigt als der XM+.
Gruß Gerd
Und einzelne defekte Frames erklären auch nicht, weshalb es im Anschluss zum falschen Kanalwert zum Lockout kommt, oder weshalb der XM+ einen falschen Kanalwert vor dem Lockout ausgibt, der R-XSR jedoch nicht, aber insgesamt deutlich mehr Lockouts zeigt als der XM+.
Gruß Gerd
Die daily soap geht weiter
Aber um jetzt diese Wendung zu verstehen, brauche ich Hilfe. Laut Premium Händler hat FrSky die erste ACCST Firmware mit Fix des unmerklichen Servoausschlags gebracht. Aber interessanterweise für das R9 System, das einen völlig anderen Chipsatz von einem ganz anderen Hersteller verwendet (SX1279 von Semtex)
Aber um jetzt diese Wendung zu verstehen, brauche ich Hilfe. Laut Premium Händler hat FrSky die erste ACCST Firmware mit Fix des unmerklichen Servoausschlags gebracht. Aber interessanterweise für das R9 System, das einen völlig anderen Chipsatz von einem ganz anderen Hersteller verwendet (SX1279 von Semtex)
Es gibt schon Testsoftware für fast alle Sender/Empfänger, die laufen sehr sehr gut
Für ACCST D8, D16 und teils auch schon für ACCESS
also für (DJT), XJT, IXJT, ISRM
Die R9 Testsoftware kam vorgestern dazu.
Der "Fehler" ist wohl schon uralt (>10 Jahre) und noch aus DJT-Zeiten im FCC begraben.
Tritt pratische dort nie auf, bzw ganz selten sind da 1-2 Framelost drauf zurückzuführen.
und das hat bis dato keiner bemerkt.
Erst mit LBT kann es sein das es neben 1-2 Framelost auch mal länger anstehen kann,
noch viel seltener sogar zu 900ms-1s Aussetzer kommen kann.
Ich vermute mal durch verschieden Generationen Compilern von C nach C++ hat
er sich irgendwann eingeschlichen und keiner hats gemerkt.
....Deklationsproblem, Überlauf, Wertebereich....
Da tut also was.
Für ACCST D8, D16 und teils auch schon für ACCESS
also für (DJT), XJT, IXJT, ISRM
Die R9 Testsoftware kam vorgestern dazu.
Der "Fehler" ist wohl schon uralt (>10 Jahre) und noch aus DJT-Zeiten im FCC begraben.
Tritt pratische dort nie auf, bzw ganz selten sind da 1-2 Framelost drauf zurückzuführen.
und das hat bis dato keiner bemerkt.
Erst mit LBT kann es sein das es neben 1-2 Framelost auch mal länger anstehen kann,
noch viel seltener sogar zu 900ms-1s Aussetzer kommen kann.
Ich vermute mal durch verschieden Generationen Compilern von C nach C++ hat
er sich irgendwann eingeschlichen und keiner hats gemerkt.
....Deklationsproblem, Überlauf, Wertebereich....
Da tut also was.
Zuletzt bearbeitet:
OK, das würde dann bedeuten, dass der Fehler 10 Jahre lang nicht bemerkt wurde. Lass ich mal so im Raum stehen. Damit man mit LBT den Fehler bemerkt, müssten direkt nach dem fehlerhaften Frame viele Frames ausfallen, damit der fehlerhafte Kanalwert gehalten wird, bzw. es zu dem beobachteten Lockout kommen. Kann man natürlich nicht ausschließen. Die Wahrscheinlichkeit können Leute die die Lost Frames mit LBT im Flug mal aufgezeichnet haben, relativ gut einschätzen. Ich mach die Tage mal wieder einen Messflug mit LBT, das hatte ich, glaube ich, noch nie veröffentlicht.
Dass es immer nur dieselben Kollegen mit einer bestimmten Hardwarekombination trifft, hat aber noch niemand erklärt, oder übersehe ich etwas?
Dass es immer nur dieselben Kollegen mit einer bestimmten Hardwarekombination trifft, hat aber noch niemand erklärt, oder übersehe ich etwas?
