Probleme mit RXLOSS

Status
Nicht offen für weitere Antworten.

GerdS

Erfahrener Benutzer
#1
Hallo,
Ich fliege noch nicht allzulange meine Kopter mit FrSky und hatte jetzt schon mehrfach PRobleme mit Failsafe bzw. RXLOSS im OSD meiner Betaflight FCs.

Als Sender verwende ich den X-Lite.

Heute mein Erlebnis mit dem BetaFpv 85X HD Cinewhoop und einem XM+-Empfänger (LBT), mit den Antennen entlang der hinteren Propellerschützer verlegt, also eigentlich ideal.
Vor dem Vorkommnis war ich sogar gut dreimal so weit weg, immer mit RSSI > 50, auf die Entfernung von vielleicht 100-150m auf freiem Feld hätte ich daher im Leben nicht mit Failsafe gerechnet. RXLOSS hatte ich mit diesem Kopter erst zweimal, das erste in der Wohnung im unmittelbaren Nahbereich (da kennt man das ja) und ein zweites Mal hinter einer Hecke in ca. 30m Entfernung, wobei ich nach dem Touch Down gleich wieder starten konnte.

Hier der interessierende Ausschnitt aus dem aufgezeichneten Fatshark-Video.

Auch mit meinem zweiten Whoop, dem CineBee 75 HD mit R-XSR-Empfänger (LBT) hatte ich innerhalb der Wohnung schon einen RXLOSS im Nebenzimmer, auch nicht nachvollziehbar.

Vor dem Umstieg auf FrSky hatte ich in den älteren Whoops DSMX-Empfänger drin und solche Probleme kannten diese nicht.

Hat jemand eine Idee was da los ist?

Gruß Gerd
 
#2
Könnte das der gleiche Effekt sein, wie hier beschrieben? Es ist ein Ausfall der Steuerung von etwa 1,2 Sekunden. Ich vermute, dass er nur beim iXJT der X10 und der X-Lite auftritt. Mit einem "normalen" Modell bemerkt man ihn im Flug oft gar nicht und hört nur "Telemetrie verloren". Passiert es im Landeanflug, oder in einer Pylon-Spitzkehre fällt es natürlich auf. Ebenso bei deinem Copter, der sofort bei RXLOSS abschaltet.

Mach doch mal Telemetrie-Logs mit 0,2s, dann sieht man später an den Flatlines, ob es sich tatsächlich um diesen 1,2s Effekt handelt. Es gibt noch zu wenig zuverlässige Daten, um sicher zu sein und FrSky zu informieren.

Wenn du einen Arduino hast, kann ich dir einen Sketch schicken, der einen PWM-Kanal auswertet und per Telemetrie zurückschickt. Den kann man dann mal ein paar Stunden laufen lassen und sieht dann, wie häufig der Ausfall auftritt.
 

GerdS

Erfahrener Benutzer
#3
Ja, das klingt sehr ähnlich. Der XM+ hat ja keine Telemetrie, da macht ein Log also keinen Sinn.
Ich mache gerade einen statischen Test. Ich habe einen Failsafe-Buzzer an einem Servoausgang eines S8R angeschlossen und Failsafe so programmiert dass er piept. Das läuft jetzt schon ca. eine Stunde, aber bisher leider noch kein Failsafe...

Gruß Gerd
 
#4
Die Frage ist, ob man die 0,2s, die dann tatsächlich Failsafe-Status haben, auf diese Art überhaupt mitbekommt. Mit einem Telemetrieempfänger, einem Servotestsignal als "Heartbeat" auf einem PWM-Ausgang und Rückmeldung des PWM-Signals über die Telemetrie wäre man auf der sicheren Seite.
 

GerdS

Erfahrener Benutzer
#6
Die Frage ist, ob man die 0,2s, die dann tatsächlich Failsafe-Status haben, auf diese Art überhaupt mitbekommt. Mit einem Telemetrieempfänger, einem Servotestsignal als "Heartbeat" auf einem PWM-Ausgang und Rückmeldung des PWM-Signals über die Telemetrie wäre man auf der sicheren Seite.
Das habe ich eben über zwei Stunden lang statisch ausprobiert.
An meinem S8R Empfänger war auf dem Throttle-Kanal ein Beepermodul eingesteckt und Failsafe entsprechend programmiert. Zudem habe ich RSSI am Sender mit 0,1s Intervall aufgezeichnet. Ergebnis: nichts...

Gruß Gerd
 
#8
Das habe ich eben über zwei Stunden lang statisch ausprobiert.
An meinem S8R Empfänger war auf dem Throttle-Kanal ein Beepermodul eingesteckt und Failsafe entsprechend programmiert. Zudem habe ich RSSI am Sender mit 0,1s Intervall aufgezeichnet. Ergebnis: nichts...
Hier hat ein Kollege (ist das Mario?) denselben Effekt reproduzierbar festgenagelt. Es scheint demnach kein iXJT Problem zu sein, sondern ein Problem von LBT in Verbindung mit den neuen Empfängerchipsets. Das könnte erklären, warum es bei dir mit dem S8R nicht aufgetreten ist.
Dieses Setup kann ich nachstellen, mal sehen, ob es bei mir auch auftritt.
 
#10
:) Der war gut :)

Crossfire heißt der Segler und das Crossfire-Modul geht auch nicht mit dem G-RX8. Spätestens an der Stelle darf man stutzig werden.
 
#12
Da ist imho noch eine unbekannte Variable mit im Spiel, der LBT Test läuft bei mir bis jetzt ohne Failsafe. Könnte eventuell die UID aus dem Sendemodul sein, die auch am Erstellen der Hopping-Tabelle beteiligt ist.
 

FJH

Erfahrener Benutzer
#13
Aber er hat doch mit IDs von 3 bis 10 getestet und immer dasselbe Ergebnis. Und jetzt mit FCC ebenso. Damit dürfte Firmware als Ursache so ziemlich raus sein.
 
#14
Ich hab dir gerade auf RCG geantwortet ;) Ich stochere doch nur im Nebel herum, auf der Suche nach dem Missing Link. Die UID gehört zum Sendemodul und macht es unverwechselbar. Norbert hatte auch dieses Failsafe-Problem und nach Wechsel des Sendemoduls war alles OK.
Der Kollege in RCG (spricht übrigens deutsch) hat drei G-RX8, von denen nur einer keine Failsafes produziert und das mit zwei grundverschiedenen Sendern. Die Sender könnten zufällig zwei problematische UIDs haben, oder er hat zufällig zwei defekte G-RX8. Genau wie der Threadersteller zwei betroffene Empfänger hat ....
Ich suche halt nach einer gemeinsamen Ursache für alle Beobachtungen.
 

FJH

Erfahrener Benutzer
#15
Das wäre aber ja ein Riesenzufall, wenn die HF-Module (einmal XJT und einmal iXJT) beider Sender eine problematische Kennung haben. Aber im Lotto macht ja auch immer einer den Hauptgewinn, man selber zwar nicht, aber einen trifft's fast immer.
 
#16
Die UID wird in der Firmware zur Berechnung der Hopping Tabelle eingesetzt. Da kann es schon mal Überläufe bei bestimmten Kombinationen geben (aber alles nur geraten). Von der Anzahl der Meldungen her ist die Wahrscheinlichkeit größer als ein Lottogewinn ;) Und die Meisten bemerken einen 1s Failsafe überhaupt nicht. Vielleicht testen jetzt noch ein paar mehr weltweit, es wäre schon gut, den Fehler einzukreisen.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten