Vorsicht bei "Telemetrie verloren" mit Horus

QuadCrash

Erfahrener Benutzer
halt nur "mein Traum" um die Fehleranalyse zu vereinfachen
Schöne Träume ... ;). Ich glaub einfacher wäre es, wenn die Betroffenen Sender (OS und HF-Firmware) und RX auf den aktuellen Stand bringen würden, Log einschalten und dann dann weiter testen. So wie es sich aktuell darstellt, sind einfach zu viele unterschiedliche Konfigurationen in Benutzung.
 

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:
RCLogger

FPV1

Banggood

Banggood

Oben