FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

Norbert

Erfahrener Benutzer
Soweit ich den/die threads überblicke geht es sehr speziell um das Problem undefinierter Ausschläge auf einem, manchmal mehreren Kanälen in Situationen ungünstiger Empfangsverhältnisse, tw auch im Failsafe Zustand, der eben im Eintrittsfall die "Telemetry lost" Meldung triggert.
Wie bereits mehrfach geschrieben, treten die Probleme mehr im Nahfeld auf. Zum Teil unter 50 mtr Abstand und 5 mtr Höhe. Mein letzter Ausfall " Doppelausfall" war in 10 oder 20 mtr Luftlinie. Davor 2 Tage ohne Probleme, danach wieder 2 Tage ohne Probleme am Moosberg mit ungefähr 10 anderen in der Luft???

Das einzig vielleicht interessant war, dass ich zuvor und danach mit externer Antenne geflogen bin. Hatte die externe Antenne abgebaut, weil ich den Sender dieses mal im Rucksack hochtrug, um sie nicht zu beschädigen. Keine Reichweitenprobleme, nur "Landeprobleme". Die externe Antenne war vorher natürlich abgeschaltet. Nach dem Vorfall sicherheitshalber wieder montiert.

UND DOCH: Kontollverlust von 1 sec kann tötlich sein: Da es 17:00 war ( Kaffeezeit bei uns ) wollte ich meinen XPlorer landen. Da ich 50 mtr hoch war habe ich ihn im 50° Winkel angestochen um 1 Looping und eine Rolle zu machen und dann zu landen. Bei 20 mtr wollte ich ziehen - nada. Gottseidank kurz vor dem Boden konnte ich wieder ziehen - voll. Da er für den Windenstart gebaut ist, hielt er es klaglos aus.

Da ich immer mitlogge sind jede Menge Daten da - aber man sieht bei den ungesteuerten Ausschlägen nichts - nur die Korrekturreaktion und bei den Aussetzern gerade Striche im Log.

Muss den Log von gestern Abend noch kontrollieren, da stotterte der Varioton und die Höheansage beim Steigen hing 2x für ~3 - 4 Sekunden beim gleichen Wert um dann auf den korrekten Wert zu springen.

Ich merke Aussetzer sofort, da ich ständig die relative Höhe, Abstand, Richtung und Vario mitlaufen habe. Beim Kreisen korrigiere ich laufend die Schräglage mit Quer und Längsachse mit Höhe, sodaß ich Kontrollverlust < 1 sec bemerke. Nur beim stationären Geradeausflug würde ich nur das hängen der Telemtriewerte bemerken.

"Elektrostatische Entladungen wie von Tadango vermutet kann ich ausschliessen, " sehe ich nicht so, da es schon genügt über den Teppichboden zu laufen und die Antennenspitze zu berühren. Glaube aber nicht, dass das unser Fehler ist, da dann eher der Empfänger "taub" wird und nicht für kurze Augenblicke "spinnt".

Der ratlose Norbert
 

Hans J

Neuer Benutzer
"Elektrostatische Entladungen wie von Tadango vermutet kann ich ausschliessen, " sehe ich nicht so, da es schon genügt über den Teppichboden zu laufen und die Antennenspitze zu berühren.
Norbert, hast recht, hätte präziser schreiben müssen: Elektrostatische Aufladungen kann ich in meinem Fall ausschliessen, da ich die Empfänger und die Antennen im letzten halben Jahr nicht angerührt habe. (Sind im tief unten im Modell eingebaut, da muß ich vorher einiges ausbauen ....)
 
Erhaltene "Gefällt mir": Norbert

zerokewl

Neuer Benutzer
Da ich leider nicht über die Zeit und Kompetenzen verfüge etwas zu bauen:

Im frsky-forum und auch hier kommt ja immerwieder die Theorie, dass der Sender die falschen Signale im Modulschacht ausgibt und auch an den Empfänger so übermittelt (kein Falesafe). Um den Fehler eindeutig nachzuweisen müssten wir doch einfach mit einem passenden Arduino + SD Karte im Modulschacht und im Modell die Servobewegungen (z.b. über SBUS) mitloggen?

Wäre so ein Logger schwierig umzusetzen? Ich habe die Hardware schon liegen, welche ich auch weitergeben würde, aber zu wenig Know-How.
 
Zuletzt bearbeitet:

strgaltdel

Erfahrener Benutzer
Im frsky-forum und auch hier kommt ja immerwieder die Theorie, dass der Sender die falschen Signale im Modulschacht ausgibt
Die Theorie wurde aber deutlich abgeschwächt.
Der Betroffene mit dem externen Modul, weswegen der aktuelle thread geöffnet wurde, schrieb ein paar Tage später;

"Hallo und guten Morgen,
seit Gestern stellt sich mein Problem anders dar und die Horus scheint nicht für alles verantwortlich zu sein.
Gestern wieder eingefrorene Ruder in der Kombination Graupner MX-22 mit Jeti Modul. "
 
Der Fehler riecht so streng nach HF-Modul/-Firmware, dass ich da keine Zeit ivestieren würde. Klar kann man PXX oder PPM capturen und analysieren, aber da wird nix bei rauskommen, da bin ich sehr sicher.

Meine aktuelle Hypothese ist, dass irgendetwas im Empfangsbereich passiert, was die Firmware nicht abfängt. Entweder falsche Prüfsumme oder ein Fehler in der Hopping-Tabelle oder ähnliches. Es scheint dann den Kanal 1 kurz zu verändern, dann hängt sich der Empfänger für 1 Sekunde weg. Danach wird neu synchronisiert und es läuft, bis zum nächsten Ereignis. Riecht vielleicht ein bisschen nach einem overflow.
 

strgaltdel

Erfahrener Benutzer
Meine aktuelle Hypothese ist, dass irgendetwas im Empfangsbereich passiert, was die Firmware nicht abfängt.
Ist auch meine stärkste Vermutung.
Verminderte Emfangsgüte & LBT & ggf "Aussenstörer", der zusätzliche Framelosses produziert, generieren eine Situation, die nicht ganz korrekt durch die FW abgefangen wird.
Lass' eine Komponente weg, und das Problem schlägt nicht durch....
 

GerdS

Erfahrener Benutzer
Gestern nach längerer Zeit auch mal wieder bei mir: Meldung RXLOSS mit Failsafe auf meinem CineBee 75 HD Whoop mit R-XSR-Empfänger und Sender X-Lite (LBT) in ca. 15m Entfernung.
Zum Glück hielten ihn meine aktuellen Failsafe-Einstellungen stabil in der Luft bis meine Steuerbefehle wieder durch kamen...

Gruß Gerd
 

strgaltdel

Erfahrener Benutzer
Hi,

falls jemand Zeit hat und Lust verspuert einen SBUS Monitor auf seinem Rechner ans Laufen zu bringen,
ich habe am Wochenende leider zu viele Baustellen, werde mich erst im Laufe der naechsten Woche drum kuemmern:

sbusmonitor.jpg

notwendig sind meinem Verstaendnis nach
- Java
- eine "Processing" Umgebung / workframe
- das script
- ein FTDI Adapter
- ein Inverter um SBUS am FTDI ans Laufen zu bekommen
(je nach FTDI Adapter kann wohl per tool auch via SW invertiert werden)

Damit wuerden sich schnell Zucker und Failsaves darstellen lassen.
Wenn es ans Laufen zu bringen ist wuerde ich versuchen "Schleppzeiger" fuer die Servoausschlaege zu integrieren und eine Frameloss Zaehlung unterzubringen.

das script und seine Beschreibung:
Real-Time Graphical Representation | S.BUS Protocol - ROBOTmaker

die Processing Umgebung
Download \ Processing.org

... funktioniert wohl ein wenig wie Arduino IDE, nur eben am Rechner und auf Basis Java

Ich hab's kurz versucht, ohne Erfolg
evtl liegt es daran, dass die aktuelle Processing Version nicht mehr kompatibel ist
im Moment muss ich mich leider anderweitig beschaeftigen

:???:
Revidiere:
kaum nimmt man einen anderen Rechner, schon funktionierts scheinbar
zumindestens erhalte ich den Eroeffnungsscreen mit der Meldung no data,
nun mal schauen ob ich noch genug Teile fuer den Inverter hierhabe
 
Zuletzt bearbeitet:

FJH

Erfahrener Benutzer
Aktuell berichtet einer auf RCG über kurze Verbindungsabbrüche mit kurzzeitigem Failsafe sowohl im Flug wie auch am Boden. Betrifft diesmal nicht FrSky sondern anderes 2,4 GHz System (Assan). Nach seinen Ermittlungen zur Ursache, wurden die Störungen durch aktives WiFi seines Smartphones verursacht. Nach Abschalten des WiFi gab es keine Empfangsstörungen mehr. Also entweder WiFi beim Smartphone ausschalten oder gleich das Smartphone wärend des Fliegens nicht am Mann tragen, sondern beiseite legen. Die in der Nähe stehenden Kollegen sollten dabei tunlichst das gleiche tun.
 

GerdS

Erfahrener Benutzer
Im deutschen Frsky-Forum hat Fa. Engel von Frsky bestätigt bekommen, dass es unter bestimmten Umständen durch ein kombiniertes Hardware/Softwareproblem zu diesen Kanalzuckern und Failsafe kommen kann, häufiger bei den LBT- und selten bei FCC-Verisonen. Es wird an einem Fix gearbeitet.

Hier könnt Ihr mal den Fall live mit anschauen. Mein CineWhoop kippt unvermittelt nach rechts ab, gleichzeitig erscheint die RXLOSS-Meldung und Betaflight fängt ihn dank angepasstem Failsafe-Handling wieder ab. Gesteuert mit X-Lite, Empfänger ist ein R-XSR.

Gruß Gerd

Dropbox - RXLOSS.mp4 - Simplify your life
 

fsjunk

Neuer Benutzer
Ich hatte im April einen Absturz mit meinem E-Segler (Schaumwaffel Phoenix 2000).
Gleich nach Handstart mit laufendem Motor stieg er nicht mehr weiter und hat auch nicht mehr reagiert.
ist schon länger her. Aber bei einem neuen Versuch am Wochenende hatte ich Aussetzer am HR-Servo: das Minuskabel war an der Lötstelle lose.

Also war das damals kein FrSky-Problem.
 
Laut Engel Forum sind die Probleme mit XJT und X8R und G-RX8 gelöst. Ich frage mich nur, wer überhaupt und wenn ja, wieviele jemals in dieser Kombination Probleme haben oder hatten.

Die überwiegende Anzahl der Problemfälle ist mit iXJT unterwegs :rolleyes:

Mal sehen, was da noch an Überraschungen kommt ;)
 
Im Engel Forum wurden Details genannt. Es sollen sich trotz Fehlerkorrektur falsche Kanalwerte im SBus Signal bzw. am PWM Ausgang einstellen können. Sehr selten, aber bei allen D16 Anlagen und zwar von Anfang an.

Das mag der Fall sein. Aber ich habe es nie bemerkt oder gemessen. Und ich habe wirklich viel Zeit damit verbracht, das FrSky Protokoll und die Geräte zu verstehen. Zumindest den Teil, der für die Praxis wichtig ist.

Ich bin sehr sicher, dass der Fehler, um den es hier geht, ein völlig anderer ist:

- eine falsche Kanalinformation für 1/111s bekommt man überhaupt nicht mit
- der beschriebene Fehler führt nicht zu einer "telemetry lost" Meldung
- auch nicht zu einer "RX loss" Meldung
- und auch nicht zu einem 1 Sekunden Lockout
- viele Fehler traten im Nahbereich bei Null Frameloss auf

Schließlich waren auch nur wenige Kombinationen betroffen. Und da vor allem iXJT. Dieser letzte Punkt wird überhaupt nicht beachtet. Es sollen alle ACCST Sender betroffen sein.

Da waren die Kollegen leider auf der falschen Spur unterwegs. Ich hoffe, dass bei einer eventuellen Korrektur dieses "Fehlers" keine neuen Fehler in das D16 Protokoll eingebaut werden.
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten