Vorsicht bei "Telemetrie verloren" mit Horus

@quax2011 @quax2011 besteht trotz hochnotpeinlicher Befragung darauf, dass er keine Fehlausschläge hatte.
Ich denke diese Frage kann ich beantworten.
Wenn ich mich recht entsinne hat Quax seine Failsafe Einstellungen auf Hold, anders als bei mir, ich habe recht große Wege für die Wölbklappen als Failsafe Programmiert deswegen bewegt sich bei Quax dort auch kein Ruder wenn ich die Einstellungen auf Hold setzte ist das bei mir genauso. (ich nenne das mal Fehler 1 damit es keine Verwechslung gibt )

Die Failsafe Einstellungen haben aber keinen Einfluss auf die ungewollten Servo Bewegungen (das ist Fehler 2 ) diese kommen egal was eingestellt ist nur eben sind das zumindest bei mir nur kurze und kleine Bewegungen ca +- 5mm der Ruder im Vergleich mit meinen Failsafe Einstellungen wo das Ruder sich heftig bewegt.
 
Ich denke diese Frage kann ich beantworten.
Wenn ich mich recht entsinne hat Quax seine Failsafe Einstellungen auf Hold, anders als bei mir, ich habe recht große Wege für die Wölbklappen als Failsafe Programmiert deswegen bewegt sich bei Quax dort auch kein Ruder wenn ich die Einstellungen auf Hold setzte ist das bei mir genauso. (ich nenne das mal Fehler 1 damit es keine Verwechslung gibt )

Die Failsafe Einstellungen haben aber keinen Einfluss auf die ungewollten Servo Bewegungen (das ist Fehler 2 ) diese kommen egal was eingestellt ist nur eben sind das zumindest bei mir nur kurze und kleine Bewegungen ca +- 5mm der Ruder im Vergleich mit meinen Failsafe Einstellungen wo das Ruder sich heftig bewegt.
Nach der aktuellen Beschreibung von Mike Blandford gibt es 0,9s Lockouts, die gelegentlich zusammen mit ungesteuerten Servoausschlägen auftreten. @quax2011 hatte noch nie diesen 0,9s Vollausschlag, um den es hier geht. Lass mal die "kleinen" Servobewegungen außen vor, die sind zwar nicht OK, aber das sind nicht die Vollausschläge, die Mike mit servo "hard over" error bezeichnet. Schwer zu sagen, was bei dir passiert, aber bitte nicht falsch verstehen, du bist zur Zeit eher ein "Einzelschicksal", das nicht in die aktuelle Fehlerbeschreibung passt. Vielleicht passt es ja, wenn wir irgendwann erfahren, was tatsächlich abgeht. Zur Zeit sind noch zu viele Fragen offen. Du merkst ja, dass auf klar formulierte, einfache Fragen keine Antworten aus dem "inneren Kreis" kommen.
 
Das sieht nach einem Troll aus. Ein einziger Post, kein Ort, keine Nennung des Clubs. Am besten gar nicht beachten, wenn keine weiteren Details kommen.
 

QuadCrash

Erfahrener Benutzer
In der 170317 wurde erst die Übertragung von S-Port Daten aktiviert von daher geht kein Weg an dieser Firmware vorbei, das steht zwar nicht auf der Frsky Seite, ist aber auch nichts neues.
Ist mir bekannt. Ich könnte mir aber vorstellen, dass FrSky die 170317 Firmware nicht unbedingt ausgiebig mit den älteren X9D(+) Serien getestet hat. Ist natürlich nur 'ne Vermutung wie vieles hier, könnte aber zutreffen.

Nehmen wir mal an, dass wäre so, dann müsste die 170317 Firmware 'ne Macke haben. Die ist aber wiederum nicht für neuere Sender, demnach wäre das mit der X9D+ ein anderes Problem, als mit neueren Sendern.

In unserer eigenen Softwareentwicklung würde ich jetzt einfach in den Entwicklungsbaum gucken und schauen, was Modul y von x "geerbt" hat. Leider lässt FrSky uns nicht ... vielleicht setzen sie auch kein VCS ein ;).
 

GerdS

Erfahrener Benutzer
Das sieht nach einem Troll aus. Ein einziger Post, kein Ort, keine Nennung des Clubs. Am besten gar nicht beachten, wenn keine weiteren Details kommen.
Weshalb sollte das ein Troll sein? Nach meinen Erlebnissen mit XM+ gehe ich davon aus, dass durchaus auch noch andere Empfänger unter ähnlichen Ausfällen leiden können.
Fakt ist für mich, FrSky hat auf die Schnelle noch vor dem chinesischen Neujahrsfest Bananensoftware veröffentlicht, die jetzt beim Kunden reifen soll. Der XM+ beweist eindeutig, dass sie ihre aktuell zum Download angebotene Software, sowohl 2.0.1 als auch 2.0.2 nicht wirklich zuvor getestet haben. Vertrauen erweckt man auf diese Weise nicht gerade, aber man verspielt es dafür umso mehr.
 
- Telemetry is a total mess. You are no longer able to discover the internal sensors of the receivers (Rx Battery, RSSI, etc).
Ich habe sogar schon Logs mit V2 veröffentlicht, sowohl LBT wie FCC und da funktionierte alles. Es gibt sicher Telemetrieprobleme, zum Beispiel deines, aber der Post ist unglaubwürdig.
 

GerdS

Erfahrener Benutzer
Ich habe kein Telemetrieproblem. Ok, der im OSD angezeigte RSSI schwankt als wäre der XM+ besoffen, aber auf die Funktion bzw. Flugsicherheit hat das wie schon mal gesagt keinen Einfluss. Und mit Telemetrie hat der auch nichts zu tun, da lokal im XM+ erzeugt und über SBUS Kanal 16 ausgegeben. Die Lockouts dagegen sehr wohl...

Gruß Gerd
 
Weshalb sollte das ein Troll sein? Nach meinen Erlebnissen mit XM+ gehe ich davon aus, dass durchaus auch noch andere Empfänger unter ähnlichen Ausfällen leiden können.
Fakt ist für mich, FrSky hat auf die Schnelle noch vor dem chinesischen Neujahrsfest Bananensoftware veröffentlicht, die jetzt beim Kunden reifen soll. Der XM+ beweist eindeutig, dass sie ihre aktuell zum Download angebotene Software, sowohl 2.0.1 als auch 2.0.2 nicht wirklich zuvor getestet haben. Vertrauen erweckt man auf diese Weise nicht gerade, aber man verspielt es dafür umso mehr.
Gibt es denn verschiedene Updateversionen?
Ich hatte eine Zip-Datei von der Frskyseite geladen in der einmal FCC und noch die LBT- Version gewesen ist.
Habe auch nur eine neue dort finden können.
Wo bekommt man eine mögliche 2.0.2?
Gruß Michael
 
Zuletzt bearbeitet:

quax2011

Erfahrener Benutzer
@ rayX. Ich hab überhaupt kein Failsave eingestellt. Bin nicht sicher ob das bedeutet dass die Einstellungen auf hold gehen. Ich denke da kommt halt für 0,9 sec nix anderes im Empfänger an. Könnte also einem Hold entsprechen. Und zu dem Vollausschlag: Ich hab das Mal in großer Höhe "manuell" auf Quer, Höhe und Seite versucht. Das merkt man eindeutig wenn eines der Ruder voll reinhaut.
 
Zuletzt bearbeitet:
@ rayX. Ich hab überhaupt kein Failsave eingestellt. Bin nicht sicher ob das bedeutet dass die Einstellungen auf hold gehen. Ich denke da kommt halt für 0,9 sec nix anderes im Empfänger an. Könnte also einem Hold entsprechen. Und zu dem Vollausschlag: Ich hab das Mal in großer Höhe "manuell" auf Quer, Höhe und Seite versucht. Das merkt man eindeutig wenn eines der Ruder voll reinhaut.
Das du nichts eingestellt hast ist unwahrscheinlich, denn dann kommt jedes mal bei Sender einschalten... Warnung Failsafe nicht eingestellt.
Du kannst ja mal testweise auf allen Ruder 50 oder 100% einstellen aber Vorsicht wenn meine Vermutung stimmt kann es dann mal wackeln...
 
Das du nichts eingestellt hast ist unwahrscheinlich, denn dann kommt jedes mal bei Sender einschalten... Warnung Failsafe nicht eingestellt.
Du kannst ja mal testweise auf allen Ruder 50 oder 100% einstellen aber Vorsicht wenn meine Vermutung stimmt kann es dann mal wackeln...
Der Lockout ist in den meisten Fällen ein bisschen zu kurz, um Failsafe auszulösen. Die Servos sind deswegen beim Lockout immer auf Hold. Der Lockout ist auch meistens zu kurz um "Telemetrie verloren" auszulösen.

Wer selbst kompilieren kann, könnte den Trigger für "Telemetrie verloren" auf 0,7s Ausfall umstellen. So bekommt man den Lockout, um den es hier geht, auf jeden Fall mit, auch ohne LostFrame-Sensor.
 
Zuletzt bearbeitet:
Als ich das letzte Mal auf der FrSky-Seite beim XM+ nachgeschaut habe, hatten sie die 2.0.1 wieder heraus genommen und durch die 2.0.2 ersetzt, also gibt es derzeit nur noch diese zum Download. Aber wie gesagt, besser Finger weg und auf 2.0.3 warten.

Gruß Gerd
Ok, Danke Gerd!

Ich dachte ursprünglich das es auch um das Sendemodul geht, das HF Update.
 
Zuletzt bearbeitet:
RCLogger

FPV1

Banggood

Banggood

Oben