FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[helle]

FrSky updaten ACCST D16-V1 auf ACCST D16-V2

Das neu Frsky ACCST Protokoll wurd an vielen Ecken verbessert.

CRC-Software und im CC2500 Hardware aktiviert
Fehlerkorrektur und Plausibilität verbessert
Codierung verbessert, 0000001111111 Problem
LBT auf 100/27mW verbessert (MU10% auf belegtem Kanal).
Frequenzfeinabgleich ?
Datenaustausch beim Bindungsablauf
Alter D8 FCC Mode wurde nicht angefasst, geht weiterhin

d.h. viele Dinge die in ACCESS schon drinnen sind wurden in ACCST übernommen.

Das wird Pascval Langer, Entwickler von MPM 4in1, noch anpassen müssen,
bis auf dem 4in1 FrSky mit neuem Protokoll ACCST D16-V2 wieder läuft.
Er ist dabei, denke 1 Woche.
------------------------
Für updates der internen und externen HF-Module sollte man openTx >V2.3.5 verwenden
Dann kann man auch das interne HF-Modul der X10 X12 ohne Umweg über FROS direkt neu flashen.

---

 

[Sigimann]

Muss ich die alte X9D und X9E auf OpenTx >V2.3.5 flaschen?.

FrSky updaten ACCST D16-V1 auf ACCST D16-V2

------------------------
Für updates der internen und externen HF-Module sollte man openTx >V2.3.5 verwenden
Dann kann man auch das interne HF-Modul der X10 X12 ohne Umweg über FROS direkt neu flashen.

---

Am liebsten würde ich gar nichts neu flashen, keine Probleme bisher. Aber es wird ja jetzt als "Sicherheitsupdate" verbreitet und damit zum Muss.

Muss ich die alte X9D und X9E auf OpenTx >V2.3.5 flaschen?.

Würde gerne die fertige 2.18 weiter verwenden, da kenne ich mich auch in dem "dünnen" Handbuch schon ziemlich gut aus.

Sigi

 

[nihonski]

Heute früh lese ich diesen Beitrag. Hier in Deutsch (google translate):
"Ich glaube nicht, dass sie die Daten als solche verschlüsselt haben. Ich glaube, ein Teil des Problems (Servostörungen) war auf Frequenzverschiebungen einiger Sender zurückzuführen. In diesem Fall kann der Empfänger Probleme haben, die Daten zu dekodieren, da sie mit der falschen Rate vorliegen, insbesondere wenn eine lange Zeichenfolge von 0 oder 1 vorliegt, da die Taktwiederherstellung nicht auf diese Daten zugreifen kann. FrSky ändert die Daten, um das Auftreten solcher Zeichenfolgen zu vermeiden."

Wenn es stimmt, und Mike B. ist kein Nasenbohrer, dann erklärt es sehr viele Beobachtungen. Dann ist auch der gefundene Fix von FrSky, nämlich die langen gleichen Zeichenketten zu vermeiden, zielführend. So kann eine leichte Frequenzverschiebung nicht mehr zu den Lockouts führen. Wenn man FrSky jetzt noch dazu bringen könnte, bei den Lost Frames nicht mehr zu schwindeln, wären doch alle glücklich.

@QuadCrash Lass die Info vielleicht besser hier im Forum. Die 5 Leute im Händlerforum, die es verstehen, finden es auch so. Und es macht die Ogottogotts nicht weiter unsicher

Es ist richtig, daß die Daten nicht verschlüsselt, aber jetzt anders kodiert werden, um sicherer dekodiert zu werden. Das wirkt sich besonders beim Auftreten des sogenannten Fresnel-Effektes auf. (Plötzliche Phasensprünge des HF-Signals) Man erinnere sich, daß Piloten die Servoausschläge eher im Nahbereich, in der Fresnelzone beobachtet haben, nicht in größerer Entfernung.
Daß es durch die geringe Frequenzverschiebung der Abstimmung zu Datenfehlern wegen verschobener Baudrate kam, ist kaum anzunehmen, das wäre viel zu wenig, da würde sich der Dopplereffekt bei schnellen Modellen eher auswirken. Das wäre auch bei jeder Entfernung gleich. Da liegt Mike nicht ganz richtig, ist aber natürlich einen sachlichen Gedanken wert.

Was die Lost Frames anbelangt, so ist es nach wie vor so, daß die grüne LED jeden Frame-loss anzeigt.
Der SBUS wird aber von 2 Frames zusammengesetzt. Wenn nun ein Frame gut ist, aber der andere nicht, soll ich dann den "ganzen" SBUS als fehlerhaft markieren? Bisher war das so.
FrSKY hat sich entschieden in diesem Fall den schlechten Frame durch den vorhergehenden guten zu ersetzen.
Bei LBT fallen ständig Frames aus und die Steuerung gibt die Daten des letzten Frames an die Servos weiter (Hold). Darüber hat sich noch nie jemand beschwert, ist aber die gleiche Angelegenheit.
Durch die neue Methode sind die SBUS Daten eher mit den Servoausgängen synchron als vorher.
Carbos 5100 Chart zeigt lediglich, wie stark sich diese Änderung auswirkt. Das Delta von vorher zu nachher zeigt, wieviele SBUS unnötigerweise verworfen wurden, obwohl die Hälfte der Daten auf dem neuesten Stand waren. Die Reaktionszeit des SBUS ist dadurch verbessert.
Mit Schummelei hat das nichts zu tun.
Also was soll dieses ständige Geplänkel gegen FrSky.
Für Zwangsneurosen gibt es andere Foren.

 

[helle]

sie haben einfach die Technik, Verfahren, Kodiuerung und Sicherung einer 2,4GHZ HF-Übertagung nicht verstanden.

 

["M"]

Hi,
@Sigi,
werde auch auf der X9E die OTX 2.1.9 erstmal weiterfliegen.
Anleitung zum Flash HF Modul Helle Handbuch S.505.

- Ordner anlegen z.b. Updates
- Richtige HF FW reinkopieren
- Datei auswählen
- Flash internes XJT Modul

Gruß Meinhard

 

[FJH]

Was die Lost Frames anbelangt, so ist es nach wie vor so, daß die grüne LED jeden Frame-loss anzeigt.
Der SBUS wird aber von 2 Frames zusammengesetzt. Wenn nun ein Frame gut ist, aber der andere nicht, soll ich dann den "ganzen" SBUS als fehlerhaft markieren? Bisher war das so.
FrSKY hat sich entschieden in diesem Fall den schlechten Frame durch den vorhergehenden guten zu ersetzen.
Bei LBT fallen ständig Frames aus und die Steuerung gibt die Daten des letzten Frames an die Servos weiter (Hold). Darüber hat sich noch nie jemand beschwert, ist aber die gleiche Angelegenheit.
Durch die neue Methode sind die SBUS Daten eher mit den Servoausgängen synchron als vorher.
Carbos 5100 Chart zeigt lediglich, wie stark sich diese Änderung auswirkt. Das Delta von vorher zu nachher zeigt, wieviele SBUS unnötigerweise verworfen wurden, obwohl die Hälfte der Daten auf dem neuesten Stand waren.

Die Frage dabei ist nur, wie alt darf denn der letzte gültige Frame sein wenn es mehrere lost Frames hintereinander sind? Und wenn diese Framekorrektur dann die Grundlage wird für einen Signal Quality Sensor (den soll es ja laut Andrea beim ACCESS Update geben) dann ist das ganz einfach Beschiss, sowas wäre praktisch unbrauchbar und sollte man sich dann auch ganz sparen.

 

[Carbonator]

Bei LBT fallen ständig Frames aus und die Steuerung gibt die Daten des letzten Frames an die Servos weiter (Hold). Darüber hat sich noch nie jemand beschwert, ist aber die gleiche Angelegenheit.
Durch die neue Methode sind die SBUS Daten eher mit den Servoausgängen synchron als vorher.
Carbos 5100 Chart zeigt lediglich, wie stark sich diese Änderung auswirkt. Das Delta von vorher zu nachher zeigt, wieviele SBUS unnötigerweise verworfen wurden, obwohl die Hälfte der Daten auf dem neuesten Stand waren. Die Reaktionszeit des SBUS ist dadurch verbessert.
Mit Schummelei hat das nichts zu tun.
Also was soll dieses ständige Geplänkel gegen FrSky.
Für Zwangsneurosen gibt es andere Foren.

Ich versuch es dir zu erklären. Es ist völlig normal, dass Frames ungültig sind. Es ist absolut OK, das wird auch schon die ganze Zeit so gemacht, das letzte Frame zu wiederholen. Da sind sich alle einig. Wie das LostFrameBit im SBus Stream ausgewertet wird, ist Sache des angeschlossenen Gerätes. Der Programmierer kann entscheiden, wie er damit umgeht. Das Bit macht nicht automatisch das Frame ungültig. Das Frame ist ungültig! FrSky bleibt meines Erachtens gar nichts anderes übrig, als wieder zu einem ehrlichen LostFrameBit zurückzukehren.

Carbos 5100 Chart zeigt lediglich, wie stark sich diese Änderung auswirkt. Das Delta von vorher zu nachher zeigt, wieviele SBUS unnötigerweise verworfen wurden, obwohl die Hälfte der Daten auf dem neuesten Stand waren.

Denk mal über diese Aussage nach, wenn nur 8 Kanäle gesendet, also jeder Frame aktuell sein muss ....

@FJH Du bst einer der Wenigen, der das überhaupt versteht. Die Betaflight Jungs gehören auch dazu.

 

[Michael Faupel]

Ich versuch es dir zu erklären. Es ist völlig normal.......

@FJH Du bst einer der Wenigen, der das überhaupt versteht. Die Betaflight Jungs gehören auch dazu.

Was sollen denn so Normalos wie ich dazu sagen, bedeutet das Alles jetzt "Gut oder Böse"?

Das ist doch die alles entscheidende Frage!

Kann man dem System jetzt vertrauen oder nicht?

Ich hatte das im Frsky Forum schon geschrieben, meine X9E mit S6R verhält sich nach dem Update wie beim vor kurzem eingespielten FCC Protokoll. Ich habe jetzt eher noch mehr "Telemetrie verloren" Meldungen im Nahbereich mit FailSafe holds als vorher. Das so von machen "festgestellte" Ausbleiben dieser Meldungen kann ich leider nicht bestätigen!

Gruß Michael

 

[Sigimann]

Was die Lost Frames anbelangt, so ist es nach wie vor so, daß die grüne LED jeden Frame-loss anzeigt.
Der SBUS wird aber von 2 Frames zusammengesetzt. Wenn nun ein Frame gut ist, aber der andere nicht, soll ich dann den "ganzen" SBUS als fehlerhaft markieren? Bisher war das so.
FrSKY hat sich entschieden in diesem Fall den schlechten Frame durch den vorhergehenden guten zu ersetzen.

Für Zwangsneurosen gibt es andere Foren.

Ewald
Wenn es ein LostFrame gibt, muss dies auf dem S-Bus als Flag erscheinen, alles andere ist falsch.
Und LBT verursacht doch nur LostFrames, wenn viel betrieb auf dem Band ist. Und genau dafür will man doch den LostFramezähler haben, und genau das macht der Zähler von Tadango.

Wenn FrSky jetzt auch beginnt eine heile Welt vorzugaukeln, dann bekomme ich auch noch eine Neurose und gehe mit Sperckdrum ins Bett.

Sigi

 

[Carbonator]

Was sollen denn so Normalos wie ich dazu sagen, bedeutet das Alles jetzt "Gut oder Böse"?

Das ist doch die alles entscheidende Frage!

Kann man dem System jetzt vertrauen oder nicht?

Meine subjektive Sicht:

Vermutlich hat FrSky das Problem der Frequenzdrift und der Lockouts gelöst. Also macht es Sinn, wenn man einen "gefährdeten" Sender hat, also alles was nach X9D/E kam, upzudaten.

X9D/E User hatten bisher keine Probleme, die können abwarten, wie die Praxiserprobung der Firmware läuft.

Die Manipulation des LostFrameBit ist sehr unschön, weil man so zum Beispiel in Betaflight noch perfekte Linkqualität angezeigt bekommt, obwohl schon die Hälfte der Frames fehlt. So etwas ist unseriös.

Man müsste jetzt noch ein paar Performancetests machen, Reichweite, Latenz, aber da habe ich wenig Lust zu.

 

[Sigimann]

Hi,
@Sigi,
werde auch auf der X9E die OTX 2.1.9 erstmal weiterfliegen.
Anleitung zum Flash HF Modul Helle Handbuch S.505.

- Ordner anlegen z.b. Updates
- Richtige HF FW reinkopieren
- Datei auswählen
- Flash internes XJT Modul

Gruß Meinhard

Die Frage ist: Funktionieren die neuen Updates mit den alten OTX es,
oder nur noch mit den OpenTx >V2.3.5.

Sigi

 

[RayX]

@Carbonator hast du deinen Log ein Paar Posts weiter oben mal auf RCG eingestellt ?
Ich denke da gehört er hin und hat den größten Einfluss auf Frsky

 

[FJH]

Die Frage ist: Funktionieren die neuen Updates mit den alten OTX es,
oder nur noch mit den OpenTx >V2.3.5.

Sigi

Sollten OTx versionsunabhängig funktionieren.

 

[Carbonator]

@Carbonator hast du deinen Log ein Paar Posts weiter oben mal auf RCG eingestellt ?
Ich denke da gehört er hin und hat den größten Einfluss auf Frsky

Lass mal lieber. Da sind auch so viele Ogottogotts unterwegs. Bei openrc passt das schon. Da lesen die maßgeblichen Leute mit. Ich wüsste nur zu gerne, wer "RCJohn" ist, der hat sich extra angemeldet, um rumzustänkern. Ich bin sicher, den kenne ich, vermutlich bin ich ihm auch schon mal auf die Füße getreten

 

[FJH]

@Carbonator hast du deinen Log ein Paar Posts weiter oben mal auf RCG eingestellt ?
Ich denke da gehört er hin und hat den größten Einfluss auf Frsky

Da werden die meisten sich garkeine Gedanken zu dem merkwürdigen Lost-Frame-Kurvenverlauf machen, sondern alles als Superlösung ansehen.

 

[nihonski]

Das ganz ist keine Schummelei, sondern eine Reaktion von FrSky auf Kundenwunsch aus der Ecke der Profi Drohnen.

Bevor ihr hier pragmatische Oberflächlichkeiten klopft, müßt Ihr Euch erst mal genau mit den Timings der Übertragung befassen, welche Daten wann genau an den Servoausgängen herauskommen, wann am SBUS und dann überlegt genau, welche Art der Datenkennzeichnung realistischer ist.
Wir reden hier um Timings und Verfahren innerhalb der Latency.
Es geht nicht darum irgendwelche alte Daten als neu vorzugaukeln.

Was den LQ Sensor anbelangt, bin ich gespannt was FrSky dazu hernimmt.
Wenns sie es richtig machen, dann bestimmt nicht einen integrierten FL Counter, wie es jeder Arduino tut, bestenfalls zusätzlich, sondern direkt die LQ-Daten welche der HF-Chip an jedes Paketende anhängt und diese dann direkt als virtueller Sensor überträgt.

Übrigens, die Telemetrie Übertragung des Arduino Frameloss Zählers erfolgt alle 400ms.
Ein Frame dauert 9ms, die Latency ist im Bereich von ca. 30ms (3 Frames).
Was sagt euch das?

 

[Carbonator]

Das ganz ist keine Schummelei, sondern eine Reaktion von FrSky auf Kundenwunsch aus der Ecke der Profi Drohnen.

Welche Profis wollen denn nicht wissen, ob das aktuelle Frame gültig ist? Hallo

 

[nihonski]

Andersherum, welcher Profiflieger will unnötige Verzögerung wenn gültige Daten verworfen werden?

 

[FJH]

Das ganz ist keine Schummelei, sondern eine Reaktion von FrSky auf Kundenwunsch aus der Ecke der Profi Drohnen.

Bevor ihr hier pragmatische Oberflächlichkeiten klopft, müßt Ihr Euch erst mal genau mit den Timings der Übertragung befassen, welche Daten wann genau an den Servoausgängen herauskommen, wann am SBUS und dann überlegt genau, welche Art der Datenkennzeichnung realistischer ist.
Wir reden hier um Timings und Verfahren innerhalb der Latency.
Es geht nicht darum irgendwelche alte Daten als neu vorzugaukeln..

Meine Frage nach dem maximalen zulässigen Alter des letzten guten Frames als Ersatz für einen ungültigen hat nichts mit Oberflächlichkeit zu tun und das weisst du auch. Bei ca. 111 Frames pro Sekunde kann ab einer gewissen Anzahl ungültiger Frames in Folge es durchaus steuerungstechnisch kritisch werden. Dies umso mehr, je schneller das Teil fliegt oder je näher es sich in Bodennähe oder an Hindernissen (Racekopter) befindet. 50% Framelosses sind für alle völlig unproblematisch, solange jeder 2. Frame gut/schlecht ist. Also nochmal, wird diese Framekorrektur nur angewandt, wenn der direkt vorangehende empfangene Frame gut war und es sich dabei nicht schon um einen als gut ersetzten Frame handelt oder wird das auch bis zum x-ten Mal hintereinander gemacht bis irgendein Zähler dann dazu stop sagt? Die erste Option wäre ja okay, die zweite allerdings bedenklich.

Was den LQ Sensor anbelangt, bin ich gespannt was FrSky dazu hernimmt. Wenns sie es richtig machen, dann bestimmt nicht einen integrierten FL Counter, wie es jeder Arduino tut, bestenfalls zusätzlich, sondern direkt die LQ-Daten welche der HF-Chip an jedes Paketende anhängt.

Das wäre allerdings wünschenswert, also warten wir's mal ab.

 

[nihonski]

Hallo FJH,
bei den FW-tests hatte ich festgestellt, daß bis maximal zum 3. Frame zurück ersetzt wird.
Das entspricht der durchschnittlichen Latenzzeit.
In der Praxis sind einfache Framelosses mit Abstand am häufigsten und genau das führt zu Verzögerungen auf dem SBUS mit der bisherigen FW.