FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

Es gibt ja eine völlig konfuse Geschichte in diesem Zusammenhang.
- FrSky unterdrückt die ersten 3 LF Bits im SBus seit dem "CRC"-Bug
- unser aller HF-Experte brachte daraufhin den Hütchenspielertrick ins Gespräch
- nach Protesten sendet FrSky jetzt bei ACCESS den ehrlichen LFR% Wert
- schönt im SBus aber immer noch
Das Verrückte ist, dass jeder Simpel die wahren Informationen sehen kann und nur die Leute, die einen Lost Frame Sensor bauen können, sehen bei ACCESS die gefälschten LQ Daten vom SBus? Das macht null Sinn. Ich suche schon länger nach einer Erklärung für diesen Nonsens.

Gestern hatte ich ein langes Gespräch mit einem cleveren FrSky Neuling der Alles ganz genau von mir wissen will (danke dafür, Jörg). Er hat dann irgendwann zum USM Folgendes vorgeschlagen: Man könnte doch einfach, wenn ein Vollausschlag (kann USM sein, muss aber nicht) festgestellt wird, abwarten, ob das nächste und das übernächste Frame mit der gleichen Information ankommen und erst dann den Vollausschlag weitergeben. Oder ob die Frames verloren gehen und man annuliert den Vollausschlag.

Da kam mir natürlich der Gedanke, ist es vielleicht genau das, was FrSky tatsächlich macht? Vielleicht reparieren sie den USM durch diese Hintertür? Und nehmen die gesteigerte Latenz in Kauf? Das kann man leicht durch eine Latenzmessung überprüfen, aber darauf habe ich gerade keine Lust. Die Hütchenspielerstory bekäme dann auch einen gewissen Sinn. Andererseits würde es bedeuten, dass FrSky nicht weiß, wo der USM herkommt und der Lockout weiter auftreten kann. Wofür es ja auch erste Anzeichen gibt.

Bei Langeweile kann man ja mal darüber nachdenken

 

[FJH]

Dachte verstanden zu haben, dass allein die verbesserte CRC-Prüfung schon dafür sorgt, dass ein USM nicht mehr als valid durchkommt.

 

[Carbonator]

Klar, das ist auch durchaus möglich. Aber hast du eine sinnstiftende Erklärung für den oben beschriebenen Unsinn? Soll ja nur ein bisschen Brainstorming sein - es gibt so Vieles, was absolut noch nicht zusammenpasst. Und das mag ich gar nicht

 

[heikop]

Dachte verstanden zu haben, dass allein die verbesserte CRC-Prüfung schon dafür sorgt, dass ein USM nicht mehr als valid durchkommt.

Das wäre zu einfach und würde auch nicht in die heutige Zeit passen, macht doch viel mehr Spass
täglich mit einer neuen Verschwörungstheorie die Menschheit auf Trab zu halten.
(Ja, dies ist auch eine)

 

[Sigimann]

Carbo. deine Theorie ergibt keinen Sinn. FrSly wertet den S-Bus ja nicht aus, sondern generiert die Daten im S-Bus. Was die auch immer Auswerten wollen, machen die bereit vor der Generierung des S-Bus uund nicht aus dem S-Bus. Auch FrSky S-Bus Servos oder Konverter ignorieren das LF, die bleiben einfach stehen, wenn nichts neues kommt.

Sigi

 

[Sigimann]

Aber es gibt einen Anderen Grund, für die LF Manipulation. Grund ist die neue verschärfte CRC - Prüfung.
Hier haben sich die Verhältnisse umgedreht. Vorher kamen immer wieder falscher Datensätze durch die CRC Prüfung. Niemand weis wie viele wirklich falsch waren, denn auch ein falscher Datensatz kann nur Daten im zulässigen Bereich enthalten und ausser Servoknurren gab es keinen weiteren Schaden im System an. Nur Vereinzelt gab es unzulässige Wertebreiche, die dann einen DATA-Overflow auslösten. Game Over für jedes System. Und nur die konnten wir sehen.

Das neue CRC System mit der Verschärften CRC Prüfung hat jetzt den Umgedrehten Effekt. Es werden Zahlreiche gültige Frames als ungültig aussortiert, jetzt knurrt noch nicht einmal ein Servo.
Dumm nur, dass Carbonator Allerhop einen LF-Sensor hat, der würde ein Häufung von LF jetzt als eine Verschlechterung der Funkstrecke interpretieren, obwohl die Funkstrecke TipTop ist denn nur die CRC Prüfung ist ein bischen streng, da passen wir doch den S-Bus an (fast) alle freuen sich.

Sigi

 

[FJH]

Das neue CRC System mit der Verschärften CRC Prüfung hat jetzt den Umgedrehten Effekt. Es werden Zahlreiche gültige Frames als ungültig aussortiert, jetzt knurrt noch nicht einmal ein Servo.

Wie soll das bitte sein, das ist erst recht eine total abenteuerliche These. Wenn das so wäre, dann wäre das erst recht eine fehlerhafte CRC-Prüfung. Und die verbessert man auch nicht durch eine Manipulation des FL-Bit im SBus. Heute ist doch der 1. Juni, oder vertue ich mich im Datum ......

 

[Carbonator]

OK, war nur ein Veruch mit dem Brainstorm und der Schwarmintelligenz
Aber vielleicht kommt ja doch noch jemand mit einer Idee, warum die SBus und die LFR% Information unterschiedlich ist.

 

[GerdS]

Carbos Text müsste so lauten, damit ein Schuh draus wird:
"Das neue CRC System mit der Verschärften CRC Prüfung hat jetzt den Umgedrehten Effekt. Es werden zahlreiche fehlerhafte aber mit dem alten CRC-Verfahren noch als gültig durchgewinkte Frames jetzt als ungültig erkannt und aussortiert, jetzt knurrt noch nicht einmal ein Servo. "

Gruß Gerd

 

[Carbonator]

Das ist nicht mein Text

Es glaubt doch hoffentlich niemand, dass so viele korrupte Frames durch die alte CRC Prüfung gingen, dass man dies bei einem Vergleich alt gegen neu bemerken kann?

 

[GerdS]

Wenn Du zuvor ein Servoknurren hattest das jetzt weg ist, doch.

Gruß Gerd

 

[QuadCrash]

Carbo kann bei den neuen v2 Sachen eh nicht mitreden, lt. eigener Aussage bleibt er ja bei v1 ... . Oder hat er jetzt still & heimlich ein Update gemacht?

 

[FJH]

Zur Zeit melden sich bei mir Clubkollegen und fluchen über FrSky, der eine mit einer X9E, der andere mit einer X12S. Beide beklagen mit der v2 Firmware Verlust an Reichweite (dauernde RSSI-Warnungen bis hin zu kritisch in Höhen von nur 200m bis 400m) beim Einsatz in ihren Seglern und das mit verschiedenen Empfängern, also nicht nur G-RX8.

 

[Carbonator]

Carbo kann bei den neuen v2 Sachen eh nicht mitreden, lt. eigener Aussage bleibt er ja bei v1 ... . Oder hat er jetzt still & heimlich ein Update gemacht?

Dann will ich dich mal auf's Laufende bringen
Meine Aussage war, dass ich keine Firmware teste, die betrügt. Aber FrSky hatte bei den RX8R ursprünglich vergessen zu betrügen, deswegen habe ich mir erlaubt, meinen ACCESS Sender mal auf ACCST V2 umzustellen, um einen Vergleich ACCESS<->ACCST zu machen. Dabei habe ich dann festgestellt, dass ACCST V2 auf dem RX8R überhaupt keine Lost Frame Bits mehr setzt. Die anderen Tester haben zwar ihre Logs veröffentlicht, aber diese Tatsache noch nicht einmal bemerkt Also Test gleich wieder beendet. Aber immerhin hat FrSky jetzt das Bug-Label gesetzt.

Mir wäre es wirklich recht, wenn auch mal jemand anders Tests mit Hand und Fuß macht. Die meisten Pappnasen labern entweder nur oder machen einen Schreibtischtest und geben dann die Firmware großspurig frei, nicht ohne selbstverständlich die großartige Reichweite zu erwähnen Natürlich immer ohne Logfile.

Ich sehe aber immer noch nicht ein, dass ich als User Aufwand betreiben soll, weil der Hersteller die Linkqualität bewusst verschleiert. Leider checkt die überwiegende Mehrheit gar nicht, um was es geht und lässt sich weiter ver@rschen

Edit: Noch was: Die Tatsache, dass bei ACCESS der RSSI 10dB niedriger liegt, als bei ACCST verdanken wir den gleichen Pappnasen. Das sind nämlich die, die nicht verstehen wollen, dass RSSI kein Prozentwert ist.
Kann man so bescheuert sein:
ACCST - RSSI Scaling on R-XSR, RX6R, G-RX8, incorrect · Issue #18 · FrSkyRC/Firmware-Test
ACCESS - RSSI SCALING · Issue #29 · FrSkyRC/Firmware-Test
Dafür dann nach einem 3 Minuten Flug mit seiner Schaumwaffel, den er auch noch im falschen Thread gepostet hat, als Rentner so einen Spruch loslassen:
"My sole LQ sensor is hardwired in another configuration at present - I will be making more when it gets to the top of my jobs list."

Merke: Diese Pappnasen gibt es auf allen Kontinenten

 

[Sigimann]

Das neue CRC System mit der Verschärften CRC Prüfung hat jetzt den Umgedrehten Effekt. Es werden Zahlreiche gültige Frames als ungültig aussortiert, jetzt knurrt noch nicht einmal ein Servo.

Wie soll das bitte sein, das ist erst recht eine total abenteuerliche These. Wenn das so wäre, dann wäre das erst recht eine fehlerhafte CRC-Prüfung. Und die verbessert man auch nicht durch eine Manipulation des FL-Bit im SBus. Heute ist doch der 1. Juni, oder vertue ich mich im Datum ......

Das war Brainstormen was FrSky so antreibt, aber je länger ich drüber Nachdenke, ich glaube immer mehr, die arbeiten wirklich so.

Sigi

 

[headwind]

Das neue CRC System mit der Verschärften CRC Prüfung hat jetzt den Umgedrehten Effekt. Es werden Zahlreiche gültige Frames als ungültig aussortiert, jetzt knurrt noch nicht einmal ein Servo.



Das war Brainstormen was FrSky so antreibt, aber je länger ich drüber Nachdenke, ich glaube immer mehr, die arbeiten wirklich so.

Sigi

Gedankengang scheint mir logisch schlüssig - es hat eben alles seinen Preis.

Bis auf weiteres fliegt Frsky bei mir zwecks Telemetrie mit - und als Redundanz zu CF.

Ich frag mich allerdings zuweilen schon, ob von Frsky nicht zuviel erwartet wird. Hat jemand schon einmal Jeti-Graupner-Futaba genauer angeschaut ? Ich frag mich, was da rauskommen würde.

Hat jemand Interesse, sich an der Entwicklung eines Loggers, der auf SD-Karte aufzeichnet zu beteiligen ?
Als Idee - Teensy 3.6, bis zu vier SBUS-streams werden aufgezeichnet. Sind nicht gerade Winterabende - deshalb möchte ich es nicht alleine machen. Knackpunkt ist für mich die Aufzeichnung auf SD-Karte, bzw. die inkonsistente Latenz der SD-Karte. Den Rest hätte ich mehr oder weniger.

grüsse hw

 

[QuadCrash]

@Carbonator : ich hab es wohl gelesen ... . Ich guck nächste Tage mal, wie sich ACCST und ACCESS mit v2 verhalten. Aktuell hab ich grad 'nen Flieger mit Jeti Assist-RX fertiggestellt und muss noch den OpenXSensor dafür umflashen/einbauen/testen. Danach ist dann FrSky wieder dran ...

 

[ReinhardZ]

Gedankengang scheint mir logisch schlüssig - es hat eben alles seinen Preis.

Bis auf weiteres fliegt Frsky bei mir zwecks Telemetrie mit - und als Redundanz zu CF.

Ich frag mich allerdings zuweilen schon, ob von Frsky nicht zuviel erwartet wird. Hat jemand schon einmal Jeti-Graupner-Futaba genauer angeschaut ? Ich frag mich, was da rauskommen würde.

Hat jemand Interesse, sich an der Entwicklung eines Loggers, der auf SD-Karte aufzeichnet zu beteiligen ?
Als Idee - Teensy 3.6, bis zu vier SBUS-streams werden aufgezeichnet. Sind nicht gerade Winterabende - deshalb möchte ich es nicht alleine machen. Knackpunkt ist für mich die Aufzeichnung auf SD-Karte, bzw. die inkonsistente Latenz der SD-Karte. Den Rest hätte ich mehr oder weniger.

grüsse hw

Hallo HW,
Ich habe mich auch mal mit dem Thema SBus Log auf SD-Karte beschäftigt und dazu einen Arduino Pro Mini mit externem Micro SD Adapter benutzt. Bei der Arduino SD library und SdFat library sind ja einige Beispielprogramme dabei, die man als Basis benutzen kann. Ich habe die Daten vom SBus über die serielle Schnittstelle des Arduino aufgenommen (mit HW Inverter) und dann im CSV Format auf die SD-Karte geschrieben. Das geht im Prinzip, allerdings gibt es regelmäßig falsche Daten im Log. Das liegt wohl an der zu großen max. Latenz der SD-Karte. Mit dem 'bench' Beispielprogramm der SdFat library kann man ja die Latenz Zeiten der SD Karte messen. Ich habe eine max. Latenz von ca. 100ms gemessen. Für diese Zeit müssten die seriellen Daten vom SBus zwischengespeichert werden. Dazu muss man den RxBuffer für die serielle Schnittstelle entsprechend vergrößern (die ser. Daten laufen da Interruptgesteuert ein). Der kritische Fall ist ein Empfänger mit ACCESS SW. Da kommen die SBus Daten im 7ms Takt. Innerhalb von 100ms laufen also etwa 100/7 = 14,3 SBus Frames auf. Bei 25Bytes/frame ergibt das 358 Bytes. Mit einem RxBuffer von 512 Bytes sollte man auf der sicheren Seite liegen. Ob das funktioniert, habe ich aber noch nicht ausprobiert.

 

[Carbonator]

Mir ist nicht ganz klar, wo der mögliche Erkenntnisgewinn liegen soll. Es gibt eigentlich nur eine offene Frage zum SBus, das sind die etwa minütlich auftretenden Phasen, in denen Werte nicht bei jedem Frame geändert werden. Die sogenannten Reißzähne oder invertierte Pommesgabel im Log mit dem @ReinhardZ BBLQ Sketch.

Ich fände es interessanter, den BBLQ auf den Teensy zu portieren und dessen Daten dann auf SD zu loggen. Damit bekämen wir eine exakte Analyse jedes Frames ohne Telemetrie- und Sensor-Einschränkungen.

Und mal noch eine ganz naive Frage: Auf einem Flightcontroller gibt es die komplette Hardware, die wir für so einen Logger bräuchten, vom SBus Interface bis zum SD-Card Slot. Könnte man das entsprechende Programm auch auf einen FC portieren? Der wäre sogar noch preiswerter als ein Teensy allein.
Und die SBus und SD-Card Routinen sind bei BF oder iNav auch schon vorhanden. Man müsste eigentlich nur das Meiste weglassen

 

[ReinhardZ]

Ein SBus Log auf SD Karte entspringt dem Wunsch auch andere Systeme außer FrSky zu untersuchen, die SBus Daten ausgeben (z.B. Futaba). Offensichtlich unterstützt auch das FrOS kein Telemetry Log.
Der 'Fang' Effekt (Reißzähne) ist eigentlich klar. Das kommt vom XJT-Modul. Ich hab das schonmal mit meinem SBus PC Logger untersucht.

Ob man die SBus Daten oder die daraus berechneten LQBB-Daten auf die SD-Karte schreibt, ist eigentlich egal. Das zentrale Problem ist, dass die SD Karte zu langsam ist und mit den gängigen Librarys (SdFat) nicht schnell genug beschrieben werden kann ohne größere Verrenkungen anzustellen. Der Teensy ist zwar schneller als der Arduino Pro Mini, aber der Engpass ist die SD-Karte, nicht der Arduino. Ein Vorteil des Teensy ist allerdings, dass er mehr RAM hat. Das könnte für größere Empfangspuffer wichtig sein.

Einen Flightcontroller mit SD Karte kann man sicher auch einsetzten. Dazu muss man dann aber die Entwicklungsumgebung haben, um die Controller zu programmieren. Eventuell geht das auch mit der Arduino Umgebung. Damit kann man zumindest den STM32 programmieren. Mag sein, dass Betaflight und INAV alles bereitstellen, aber den Code zu durchforsten und umzuarbeiten ist auch 'ne Menge Arbeit. Dazu habe ich zumindest keine Lust. Es war mal ganz interessant, die SD-Karte an den Arduino anzubinden, aber nachdem das Loggen nicht so ohne weiteres zuverlässig funktioniert, ist mir erstmal die Lust vergangen