FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

Carbonator

Carbonator

Allerhopp ;)
#681
#681
Wenn man etwas ausschließen kann, ist man auch schon einen Schritt weiter. Mit der Frequenzdrift bei den neuen Sendertypen und der engeren Bandbreite bei den neuen Empfängern könnte man ziemlich alle Beobachtungen erklären. Norbert kann den Fehler mit dem MPM hervorrufen, ich bin fast sicher, dass er das durch Verstimmen des Senders macht, vielleicht kommt ja noch eine Aussage von ihm.
 
GerdS

GerdS

Erfahrener Benutzer
#682
#682
Dass ich Fehler produziere wenn ich den Sender verstimme, das ist ja klar. Aber da die Mittenfrequenz ja nicht permanent willkürlich hin und her pendelt, sondern von einem Anfangswert beim Einschalten langsam aufgrund z.B. der Bauteilerwärmung oder des Betriebsspannungsverlaufs weg wandert, müsste das Auftreten der Fehler weitaus reproduzierbarer sein, wenn das die Ursache wäre. Ich habe den Fehler jedoch schon kurz nach dem Einschalten als auch erst nach 30 Minuten Senderlaufzeit erlebt. Und konnte danach noch lange ohne erneuten Fehler weiterfliegen.
Das Einzige was man durch Verstimmen testen kann, ist das Verhalten an der Reichweitengrenze auf dem Labortisch, ob die komplette Failsafe-Behandlung in jeder Stufe korrekt arbeitet. Alternativ geht das natürlich auch mit einem HF-Dämpfungsglied zwischen Sender und Empfänger.

Gruß Gerd
 
Carbonator

Carbonator

Allerhopp ;)
#683
#683
Norbert hat das Sendemodul gewechselt und der sporadisch auftretende Fehler war weg. Es ging nur darum, das auszuprobieren. Wenn das nicht klappt, auch gut, war nur eine Frage ;)
 
Norbert

Norbert

Erfahrener Benutzer
#684
#684
Hallo,

nicht nur durch verstimmen. War bei Ewald und haben mit verschiedenen Sendern getestet.
Das übliche Szenarie, WLAN-Router beim Übertragen eines Filmes, einen Störsender und der Empfänger und Sender am definiertem Platz.
Auswertung der PPM Impulse und SBus durch programmieren MicroController, der bei Fehler den Salea anstößt und mit 0,5 sec PreTrigger für 3 sec ausnimmt. Auswertung/Darstellung mit Salea Software.
Dabei das Verhalten eines X6R und eines G-RX8 bei auf jeweilige Mitte getrimmten Senders untersucht, bzw bei 25 Schritt Verstimmung.
Beim X6R keine Fehler innerhalb 10 min bei Verstimmung feststellbar, beim G-RX8 innerhalb 10 min mehrere Fehler bei Verstimmung, bei Mittenabstimmung 1x bei Bewegung.

Auffällig war
1) dass beim G-RX8 der S-Bus einen Kanalwert von Hex 00 ausgegeben hat ( den gibt es lt Definition gar nicht ), das S-Bus Flag aber auf ok stand und einige Frames später auf fehlerhaft ging, obwohl die Kanalwerte ok waren.
2) der Fangbereich bei Synchronisationsverlust bei externen Störungen wesentlich kleiner wurde wie in ungestörter Umgebung - und zwar drastisch. Es hält und flackert massiv relativ lang, wenn er aber abreist muss man mehr als die Hälfte der Verstimmung zurückgehen, bis er wieder fängt.

Norbert
 
Carbonator

Carbonator

Allerhopp ;)
#685
#685
Norbert hat gesagt.:
Auffällig war
1) dass beim G-RX8 der S-Bus einen Kanalwert von Hex 00 ausgegeben hat ( den gibt es lt Definition gar nicht ), das S-Bus Flag aber auf ok stand und einige Frames später auf fehlerhaft ging, obwohl die Kanalwerte ok waren.
Zum Vergrößern anklicken....
Danke für die Zusatzinformationen (y)
Ich bin kein Freund von Verschwörungstheorien, trotzdem die Frage: war das mit der neuesten Firmware? Es lönnte ein Hinweis darauf sein, wie FrSky die Lost Frames verringert.
 
M

matkovits

Neuer Benutzer
#686
#686
Ein herzliches Hallo in die Runde.

Ich lese jetzt schon geraume Zeit in mehreren Foren mit, und muss mich nun als "Neuer Teilnehmer" an der Debatte auch mal melden.
Vorerst sei mitgeteilt, dass ich im engel-Forum bereits 2018 gepostet habe, dass es bei meiner Horus X12 beim Landeanflug eines Großmodells einen unerklärlichen und plötzlichen negativen Servoausschlag am Höhenruder gegeben hat. Das hat mich fast das Modell gekostet, aber es war zu reparieren. Soweit so gut. (oder auch nicht)
Seitdem gab es immer wieder mal undefinierte Servoausschläge.
Seit dem Vorfall habe ich meine großen Vögel (Verbrenner und Jets) gegroundet und fliege nur mehr mit kleineren E-Schaumwaffelfliegern herum. Da ich ja seit damals weis, dass es zu plötzlichen Servoausschlägen kommen kann, passe ich besser auf..... deshalb.... schnellere Reaktionszeit und daher keine Verluste von Modellen. Die Wartezeit auf eine Lösung geht mir aber jetzt schön langsam auf die Nerven.........
Bisher habe ich bei allen Debatten über die Hochfrequenztechnik aber folgendes vermisst, oder ich habe es überlesen.....
Vorausschicken möchte ich, dass ich keine Ahnung von Hochfrequenztechnik habe und dieses Wissen auch in meinen 40 Jahren Modellflug bisher noch nicht wirklich vermisst habe.
Ich habe jetzt folgendes ausprobiert. Meine Horus X12 mit LBT-Software an einen X8R Empfänger gebunden und meine neu angekaufte zweite FS eine Taranis X9D+ mit FCC Software geflasht an einen anderen X8R gebunden. Dieses am Basteltisch. Dann die beiden grünen Empfänger-LED beobachtet. Beim Empfänger der an die Horus X12 (LBT) gebunden ist flackert die LED ziemlich deutlich. Beim Empfänger der an die Taranis (FCC) gebunden ist leuchtet die grüne LED permanent, ohne zu flackern. Das bedeutet für mich, dass die LBT-Übertragungstechnik irgendeinen Fehler enthält. Ergänzend noch, dass beim Test in meinem Bastelkeller w-lan Netze (meines und die Netze der Nachbarn) und mein Smartphone anwesend waren.
Vielleicht sollte die LBT-Technik mal überdacht werden.....
Ich habe dazu ein Video auf youtube hochgeladen.
lg an alle die dies lesen......
 
Zuletzt bearbeitet:
Carbonator

Carbonator

Allerhopp ;)
#687
#687
Hallo,

die Beobachtung ist korrekt und zeigt das Prinzip von LBT. Wenn der Kanal besetzt ist, wird auf die Aussendung des Paketes verzichtet und zum nächsten Kanal gesprungen. Wenn zwei FCC Sender gleichzeitig senden, kommt im schlimmsten Fall gar kein Paket durch, weil sich die Sender gegenseitig stören. Man kann am Stammtisch wunderbar darüber streiten, aber in der Praxis funktionieren beide Verfahren. Beim Modellflug ist man in der Regel weit genug weg von festen 2,4GHz Quellen, so dass einem nur die anderen Modellflieger gelegentlich in die Quere kommen (bei FCC und LBT). Bei 111 Paketen in der Sekunde ist es unbedenklich, wenn sogar der überwiegende Teil der Pakete verloren geht, klingt schlimm, merkt aber kein Mensch. Wenn man es genau wissen will, baut man einen Lost Frame Sensor und misst die verlorenen Pakete.

(Für die Ogottogotts: Am Servoausgang der Empfänger kommen bei 18ms Framerate sowieso nur die Hälfte der Pakete an, also nicht aufregen ;))

Am Stammtisch hilft das alles aber nicht, wenn die Experten loslegen, um es gleich zu sagen ;)
 
Zuletzt bearbeitet:
weixelgeist

weixelgeist

Erfahrener Benutzer
#688
#688
Für die Horus X10S gibt es eine neue Firmware mit Datum 11.12.19
Beschreibung:
1. Fix some bugs about menu setup
– when the menu is first entered it appears like a switch can be assigned to settings # 1 in FLAP SET page.
– logic Switch “NOT” operation displays extraneous data.
– DR/Expo under flight mode 6.
– data not saved in Swash page
– could not control sound by Pots.
– data not saved when log space is 100ms in teleSetup page
2. Change Non-LBT to LBT mode for internal module in FLEX firmware.

Ich weiß nicht was soll es bedeuten????
 
Norbert

Norbert

Erfahrener Benutzer
#689
#689
matkovits hat gesagt.:
Ich habe jetzt folgendes ausprobiert. Meine Horus X12 mit LBT-Software an einen X8R Empfänger gebunden und meine neu angekaufte zweite FS eine Taranis X9D+ mit FCC Software geflasht an einen anderen X8R gebunden. Dieses am Basteltisch. Dann die beiden grünen Empfänger-LED beobachtet. Beim Empfänger der an die Horus X12 (LBT) gebunden ist flackert die LED ziemlich deutlich. Beim Empfänger der an die Taranis (FCC) gebunden ist leuchtet die grüne LED permanent, ohne zu flackern..
Zum Vergrößern anklicken....
Binde zur Gegenprobe die Empfänger auf den jeweilig anderen Sender, Fw muss natürlich passen geflashed sei. Aber sehr wahrscheinlich wird das Verhalten mit LBT mitwandern.

Übrigens wurde zum Thema LBT ein Vorschlag an FrSky gemacht: Bei Kanalbelegung den Frame nicht ausfallen lassen, sondern mit 25 mW senden, das ist denke ich zulässig.

Durch die wesentlich häufigeren Frameverluste bei LBT kommt es auch häufiger zu Fehlern, die sich auswirken.
 
Carbonator

Carbonator

Allerhopp ;)
#695
#695
Carbonator

Carbonator

Allerhopp ;)
#696
#696
Mike Daley plaudert hier ein bisschen über die aktuelle FrSky Strategie. Der Arbeitstitel ist scheinbar
"rare unwanted servo movement issue" Klingt süß, oder :) Dabei wollen sie auch noch die niedrigere ACCESS Reichweite miterschlagen. In meinem Test war die etwa halb so groß wie mit ACCST, demnach war mit einem vernünftig abstrahlendem Sender in der Praxis überhaupt kein Problem zu erwarten.
RT1_1_3.png
Mal sehen, wie sie das machen wollen, zurück auf 16 Kanäle, oder die "statischen" Kanäle weniger oft übertragen? Und wer wohl den ganzen Kram unter realistischen Bedingungen testen wird?
Zum Glück habe ich null Druck, bei meinen Seglern irgendetwas zu ändern :)
 
Zuletzt bearbeitet:
F

FJH

Erfahrener Benutzer
#697
#697
Zuletzt bearbeitet:
Carbonator

Carbonator

Allerhopp ;)
#698
#698
@FJH Da hast du mich erwischt ;) Aber da ich nur zwei Flüge mit ACCESS gemacht habe und die Reichweite wirklich unkritisch ist, wollte ich da nicht tiefer einsteigen. Wer sicher und weit fliegen will, bleibt sowieso bei ACCST :)
 
Carbonator

Carbonator

Allerhopp ;)
#700
#700
ACCST ist das over-the-air Protokoll und das funktioniert schon jahrelang ohne Probleme. Das Thema ging mit den neuen Sendern los. Problematisch sind scheinbar (edit: natürlich nur einige/wenige) QX7, Xlite und die Horus Sender. Vermutlich driftet die Sendefrequenz. Wenn du an einen Sender mit Spectrum Analyser kommst (SA mit MPM geht auch mit OTX2.3.3) kannst du ja mal nachsehen, wo die Frequenz beim Binden liegt.

Es ist aber noch nicht sicher, ob der SA die erforderliche Auflösung hat. Es wäre gut, ein paar Zahlen von problematischen Sendern zu bekommen, ich hab leider ;) keinen.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten