FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[RayX]

Da hast du durchaus recht, so wie ich oben schon geschrieben habe, kam ich mir die erste Zeit auch sehr alleine vor.
Ändert aber nichts an der Tatsache, das mein Problem der ungewollten Servo Ausschläge und Failsafes mit dem zurück flashen der XJT Firmware verschwunden ist.
Ich kann nach wie vor die 170317 flashen und alle Probleme sind weder da, mit dem GR-X8 sehr gut zu finden, hier habe ich zwischenzeitlich 4 verschiedene GR-X8 getestet mit allen das gleiche.

Schön wären ein paar ideen wie das zustande kommt / kommen kann.


Zu dem verseuchte 2,4GHZ Band möchte ich auch noch meine Senf dazu abgeben, spaßeshalber habe ich mein Handy mit voll ausgelasteter W-lan und Bluetooth Verbindung zu einem DJI Osmo der sein Video Bild und Ton über diese Funkstrecke überträgt auf den RX gelegt der sich am Range test mod befand.
Einen Ausfall oder Servo Bewegungen konnte ich so nicht provozieren, das flacker der Led wurde heftig aber sonst nichts, der normale W-Lan kram war aber auch im Haus aktive, der Sender war so weit weg das der RSSI ca 45 angezeigt hat.
Man sieht schon Auswirkungen an hand der LED aber eine Erklärung ist das für mich nicht.
Sonst wäre ja die 151223 W-Lan "Störung" resistent

 

[Carbonator]

Gute Frage, keine Ahnung was da passiert. Es scheint so zu sein, dass die neuen Empfänger schmalbandiger sind als die älteren, der G-RX8 sicher, aber vermutlich gehört der S6R auch dazu. Eine gewagte Theorie könnte sein, dass dein HF-Modul ebenfalls ein wenig driftet und das Update der XJT Firmware diesen Effekt aus einem normalerweise unkritischen Grund erst sichtbar macht, aber das ist zugegebenermßen sehr nahe bei "ich habe keine Ahnung".

Hast du mal die neue G-RX8 Firmware mit der 170317 probiert? Kannst du mal mit einem MPM den Empfängeroffset und den Bereich testen, bei dem die grüne LED zu zucken beginnt? Mit alter und neuer G-RX8 Firmware. Dann mal im Vergleich mit einem X-S/4/6/8/-R.

Leider ist noch kein einfacher Weg bekannt, die Senderdrift zu messen, das wäre eigentlich das erste, was man tun sollte. Hast du eventuell ein externes XJT zum vergleichen, tritt damit der Effekt auch auf?

 

[RayX]

Die 170317 habe ich sicher getestet ist ja für das XJT, du meinst bestimmt die 191115 für den GR-X8 ?
Nein, die habe ich nicht mehr getestet, ich bin zurzeit Winter Modus (hinterm Ofen sitzen.. Konstruieren, sonstigen Unsinn ausdenken und bauen), die letzte getestete war eine vorab Test firmware mein nächster versuch wird vermutlich Frskys grosser Firmware Fix sein.

Ein MPM oder externes XJT habe ich nicht.

 

[GerdS]

Um das mal klar zu stellen, CRC-Checks können keinen Fehler korrigieren sondern nur (hoffentlich) erkennen. Wird vom Empfänger ein defekter Frame aufgrund eines ungültigen CRCs erkannt, dann wird der komplette Frame verworfen und stattdessen der vorherige gute Frame weiter verwendet, so lange, bis wieder ein korrekter neuer Frame empfangen wird oder nach einer bestimmten Anzahl fehlerhafter oder ausbleibender Frames die Failsafe-Behandlung ausgeführt wird.

So wie ich den Fall sehe, liegt es nicht an der CRC-Prüfung und defekten Frames. Denn mehrere Dinge sind auffällig und sprechen für eine andere Ursache.
1. Zumindest bei meinem XM+ wird immer derselbe Kanal gestört und zwar immer in Richtung 2ms Impulszeit. Übertragungs-Bitfehler in Frames sind aber immer zufällig und das wäre schon ein regelrechtes Wunder, wenn immer dieselben 2 Bytes des immer gleichen Kanals im Frame in gleicher Weise gestört wären.

2. Danach schlägt bei meinem Flight Controller die Failsafe-Behandlung zu, also bleiben entweder weitere Steuersignale aus (am Servostecker oder bei mir am SBUS) oder es wird am SBUS (bei mir) ein Fehlerbit gesetzt. Ich vermute Ersteres.

Nur so wird ein Schuh daraus, weshalb der falsche Kanalimpuls überhaupt mehr als ein kurzes kaum sichtbares Servozucken verursacht und das passt dann auch zur knapp 1s andauernden Unsteuerbarkeit.

Gruß Gerd

 

[Leo1962]

Bei einem driftenden System kommt es zu den Aussetzern. Also muss man sich um das Wegdriften kümmern. Zumindest in meiner Welt ist das so ....

in der realen welt da ist dei Lösug ganz einfach wegen des wegdriftens Drogen weglassen

 

[Michael Faupel]

in der realen welt da ist dei Lösug ganz einfach wegen des wegdriftens Drogen weglassen

Das scheint mir angesichts der vielen Fehlgriffe der Frsky Software Abteilung immer noch die sinnvollste Hilfestellung zu sein.

Gruß Michael

 

[weixelgeist]

Da habe ich mal eine Frage dazu, die ich auch im Engel Forum gestellt habe :
Ist es besser, die 2.3.3 RC1 zu verwenden oder sind die 2.3.3 nightlies sicherer?
Oder anders gefragt: sind die nightlies eine Weiterentwicklung der RC1, in denen eventuelle Fehler der RC1 schon ausgebessert sind?

 

[Carbonator]

Die 170317 habe ich sicher getestet ist ja für das XJT, du meinst bestimmt die 191115 für den GR-X8 ?

Mich hätte interessiert, ob dein 191115 G-RX8 mit der 170317 ohne Zuckeln funktioniert.
@weixelgeist Die täglichen Nächtlichen können problematisch sein, im Extremfall funktionieren sie gar nicht. Deswegen teste ich immer alle Funktionen am Boden, wenn es da funktioniert, fliege ich auch
Das Thema hier kann aber nur von FrSky firmwareseitig, oder wie manche behaupten , hardwareseitig gelöst werden. Die OpenTX Version spielt dabei keine Rolle.

 

[fsjunk]

Frsky verwendet crc16 als Datensicherung (2 bytes). Das ist keine Verschlüsselung.
Da gibt's nur 65536 Kombinationen.

Im Engelforum hat sich jemand den CRC-Code für FrSky im DIY-Modul angeschaut. Das Lookup Table enthält nur 16 Werte statt der eigentlich verwendeten 256. Dadurch sei die Fehlererkennung wesentlich unzuverlässiger.

 

[Norbert]

Vorsicht:
1) 2 Byte sind die rund 65.000 Kombinationen
2) Ob man die Werte aus dem DIY Modul heranziehen darf weiss ich nicht, da es nicht zwangsläufig dem FrSky Modul entspricht, das eventuell mehr als die 256 aus der Lookup Tabelle des DIY verwendet
3) Siehe 2) - aber wenn das auch bei FrSky so wäre, dass nur 16 aus 65.000 möglichen verwendet, dann wundert mich gar nichts mehr und ist die Fehlerhäufigkeit absolut plausibel

 

[Carbonator]

@Norbert Eigentlich müsste es doch gerade dich wundern, dass mit Hardwaretausch dein Problem behoben war, einmal zeitweise, dann komplett ...
Das Killerargument ist ganz einfach, dass das System in den überwiegenden Fällen perfekt funktioniert. Und mit dem MPM hatte noch niemand vergleichbare Probleme. Ich könnte mir vorstellen, dass eine Frequenzanpassung wie im MPM auch die Lösung für die FrSky Sender wäre. Mit einer entsprechenden Argumentation ".... der anspruchsvolle Modellflieger u.s.w..) könnte man das auch den Ogottogotts verkaufen.

 

[quax2011]

Heißt das daß man dann mit einem Multiprotokollmodul im Modulschacht z.B der Horus garantiert auf der sicheren Seite ist. Und, kann man das MPM direkt vom Sender ansprechen will sagen ohne Drehschalter oder so und zuletzt welches MPM soll ich dann kaufen?

 

[Carbonator]

Das MPM ist eher die Lösung für die Cowboys Es funktioniert zwar, ich würde mich aber damit nicht auf einen Modellflugplatz trauen. Zumindest solange nicht, bis ein Hersteller/Händler das MPM zertifiziert hat. Ich würde auch keine Panik schieben, das schlimmste, was dir mit deiner X12 passieren kann ist ein 1s Lockout mit Servoausschlag. Das trainiert das Reaktionsvermögen und die Resilienz Und du benutzt ja auch keine "neuen" Empfänger, so weit ich weiß.

 

[Leo1962]

Verschwöhrugs Teoretiker würden jezt sagen der Chef Programierer hat sich mit Frsky dermassen zersstritten das er heimlich den programmier Code geändert hatte befor er weg wahr. Heimlich die Fehler eingebaut! So nach dem Motto seht irr ohne mich geht es ja gar nicht mehr.

Währe ja nicht der erste der so oder ähnlich handelt.


Jetzt wäre noch zu klären wie lange er sich schon mit Frsky über worfen hat

 

[quax2011]

Jep, du sagst es. Bleiben wir bei dem was funktioniert. Und wenn die Teile von BG kommen bau ich den LQS und sehr dann weiter

 

[Norbert]

Genau das ist Teil des Programms, das ich bereits am Sa mit Ewald vereinbart habe.
Klar sind die sich verändernden Quarzfrequenzen ( Ja so ein Sender hat auch heute noch ein Quarz drin ) eins der Probleme ( aber auch im Empfänger ) - das ist aber alles kein Geheimnis. Habe ich längs geschrieben.
Heute Abend geht unter anderem darum, inwie weit man mit verdrehter Mittenfrequent diese Aussetzer provozieren kann und ob es mit opt. Einstellung verschwunden ist.

 

[Carbonator]

Ganz ohne Ironie: Ich bin begeistert und sehr gespannt auf die Ergebnisse!

 

[Sigimann]

In den ersten Horus-Monaten gab es doch Probleme mit "seltenem" FailSave.
Immerhin hat es Monate gedauert bis man es so fest machen konnte, daß FrSky überhaupt darauf reagierte. Passt doch immer noch auf den heutigen Fehler.
Dann gab es innerhalb von wenigen Tagen ein Update, dass Problem wurde allgemein als Gelöst bewertet. Ist wohl nur dünn drüber Programmiert worden mit Symtome abfragen und Fehler korrigieren.

Der Auslöser für die langen Holts von ca 1 sec wird ja sicher ein SystemReset sein. als Auslöser bietet sich ja ein Speicherüberlauf (Fehlerzähler) oder sogar ein StakOverflow an. Da passt dann beides, Fehler aus Frequenzverschiebung oder LBT aufsummieren.
Und beider Fehler sind ja als Tief verborgene Leiche sehr beliebt in der Programmierung.

Ich hab damals meine Horus abbestellt und war jetzt dabei die X10 zu kaufen ....
Aber da wird nix, fliege weiter mit der alten X9D (vor 2015) und mit Fremdmodul in der X9E.

Frsky kannste knicken, das wird nichts mehr.

Sigi

 

[Gruni]

Hallo Sigi, Leo,....
nana, gebt den Jungs/Mädels ne Chance. Ich denke nicht, dass da böse Absicht hintersteckt.

Immerhin wollen Sie(Frsky) ja auch noch Empfänger, Regler, etc verkaufen.
Früher zu FTZ-Zeiten durften wir ja noch nicht einmal Taster/Schalter/Ladeanschlüsse in den Sender einbauen, die Steckersysteme waren ganz bestimmt nicht standardisiert, das war viel mehr Abschottungspolitik.

Und "Fehler"-Behebung war so gut wie garnicht, Ich weiss nicht, wie oft ich meine Luna zum Service geschickt habe, dauernd wurde die kleine Ankoppelspule am Antennenfusspunkt gewechselt.
Der Reichweitenfehler war aber wohl eher was anderes.

Das Internet, oder besser Foren wie dieses und deren engagierte Teilnehmer regeln da heutzutage viel eher was.
Der Druck auf die Firmen ist viel grösser als früher.

Nur mal so nebenbei und oT.

Grüsse Gruni

 

[Norbert]

Hier meine Zusammenfassung der Test von gestern:

Es wurden bewusst keine Horus, sondern Jumper T16 und Taranis zum Testen als Sender verwendet.
Die Mittenfrequenz und Leistung der T16 bei 0 Verstimmung liegt identisch mit dem Mittel aus mehreren FrSky Sendern, ebenso die Leistung. Die Hoppingsequenz unterscheidet sich.

1) Das Testobjekt war ein G-RX8 im Einzeltest. Man sah deutlich, dass die Fangbreite des Empfängers in einer Störumgebung wesentlich kleiner wie in einer ungestörten Umgebung ist.
Als erstes wurde die +/- Einstellung relativ zum Empfänger ermittelt und die Mittenfrequenz eingestellt. Verdreht man die relative Mittenfrequenz zum Maximalwert um den halben Betrag erhöht sich die Fehlerrate deutlich gegenüber der Idealeinstellung.
Für ein weiteres Phänomen konnte ein Ansatz gefunden werden. Die Fehler in der Realität treten ja immer nur im Nahbereich bei guten RSSI Werten auf, wofür ich bisher keine zwingende Erklärung hatte. Beim Test mit der Idealeinstellung warteten wir knapp 15 min ohne Fehler und sahen hinten im Raum nach etwas anderem. Als wir entschieden den Test abzubrechen kam ein Fehler. Dieses Verhalten hat Ewald schon oft beobachtet, dass er lange auf einen Fehler wartet, es nichts tut und in dem Moment, wenn er geht oder kommt der Fehler auftritt. Vermutlich ausgelöst durch Reflektionen und dadurch entstehende Phasenverschiebungen und Auslöschungen.

2) Test mit RB-10: Rx in 1 = G-RX8 / Rx in 2 = X8R
Fehler am S.Bus Ausgang des RB-10 erkennbar, aber relativ sinnlose Konstellationen von Kanalwerten und den Fehlerbytes ( Frame ungültig / Frame gut ) bzw Failsave. Als Ursache konnte der G-RX8 ermittelt werden, der sinnlose Fehlerflags ( gut oder fehlerhaft ) auf dem S-Bus setzt. Dh bei korrekten Werten der Kanäle kommen Framelost, bei ungültigen Kanalwerten frame ok oder das ganze um mehrere Frames verschoben.
Das muss noch näher untersucht werden.

Diese Test liefen bereits vor meiner Anwesenheit mit Taranis über mehrere Stunden - dann mit Jumper ( 3h) .

Fazit: Für mich ist klar, dass die Fehler nicht Sendertyp abhängig sind, sondern die Abstimmung der Sende/Empfangsfrequenz eine eminente Rolle spielt. Dass die Empfänger aufgrund der mangelhaften CRC-Prüfung und eines eventuellen anderen Fehlers dann aussteigen ist eine andere Geschichte.

Möglicherweise kam die ganze Problematik jetzt so hoch, weil die Horussender im Mittel stärker verstimmt waren, bzw stärker davon liefen und die G-RX8 ( eventuell die gesamte neue Chip-Generation ) anders in der Frequenz eingestellt wurden. Hinzu kommt, dass die neue Chip-Generation (G-RX8) einen kleineren Fangbereich hat und wenn die Synchronisation verloren geht schwerer wieder einrastet.
Ob hiervon alle neuen Empfänger der neuen Generation betroffen sind, kann ich nicht sagen, da wir nur mit G-RX8 testeten - die Vermutung liegt aber nahe.

Das ganze korreliert sehr gut mit den Erfahrungen in der Praxis und bestätigt meine Erfahrungen. Lediglich die Einbindung des RB-10 und seine Fehlervermeidung muss noch näher untersucht werden. Ein interessanter Aspekt mit RB-10 und 2x X8R ist, dass die Umschaltung zwischen den beiden Empfängern quasi verzugslos erfolgt. Das entspricht nicht meiner Erfahrung mit G-RX8 an Rx in1 und X6R an Rx in 2. Da dauerte es erkennbar, bis umgeschaten wurde, das werde ich noch einmal testen.
Ansonsten vielen Dank an Ewald, für den freundlichen Empfang und die Unterstützung und die Wochen an Zeit, die er aufgewendet hat um den Fehler zu fixen und reproduzierbar nachzuweisen.

Norbert