Meine Probleme mit FUTABA FASSTest

8 lange Jahre bin ich mit Futaba und dem FASST System unterwegs. 8 lange Jahre die überzeugt haben und ein starkes Sicherheitsgefühl hinterlassen haben. Nicht ohne Grund hat sich Futaba mit dem FASST System einen guten Ruf erarbeitet und Modellpiloten weltweit dazu überzeugt einen Umstieg vom alten 35MHz System in die neue 2,4GHz Welt zu wagen. Ich war dabei, anfangs mit einer Futaba FX-30, später auch mit einer kleinen FF-7 als Zweit- und Schülersender. Jahre ohne Funk Probleme, ohne Aussetzer, Failsafe, Abstürze, Störungen, Kanal-Doppelbelegungen oder Probleme. Doch plötzlich hat sich etwas verändert…. Ich möchte dies hier dokumentieren und meine Beobachtungen erklären.

Das Problem kommt mit Futaba FASSTest ins Haus

Im Frühjahr 2013 kaufte ich mir eine FX-32 und gab meine FX-30 weg. Die neuen Funktionen und die eingeführte Telemetrie animierten mich dazu. Doch ich hatte es nicht eilig alle möglichen Modellflugzeuge umzurüsten, und so dauerte es einige Zeit ehe die neue Technik wirklich eingesetzt wurde.
Als erstes kam in meinen 4 Meter Discus Segler ein R8007SB Empfänger mit einem Vario Sensor. Da ich diesen nur mit Schlepper in die Luft bekomme war der Einsatz der neuen Technik nur recht selten. Es gab ein paar Momente in denen etwas nicht so war wie es sollte, heute muss ich sagen war ich durch die jahrelange Verlässlichkeit von FASST abgelenkt und zog es nicht in Betracht das hier ein Problem sein könnte. Erst im Jahr 2016 wurde das ganze konkreter.
Nach dem was ich bis jetzt analysiert habe wurde die Problematik sichtbar durch zwei Fakten:

  1. Mit einem R7018SB Empfänger für ein  Jet Modell beginnt auch bei mit die intensive Nutzung der neueren FASSTest Technik
  2. Mit einem Firmware Upgrade für die FX-32 (1.4) wird auch am FASST Protokoll eine Änderung durchgeführt

Somit ändert sich im Frühjahr 2016 einiges und die Geschichte beginnt.

Empfangsprobleme kommen auf den Tisch

moto-g4-plus-kamera-beispiel-bild-6Der erste Hinweis auf ein Problem mit dem FASSTest System kommt am Tag des Erstfluges unserer J10 auf den Tisch. Im zweiten Flug! Nach einem ganz simplen Platz Überflug geht die Turbine plötzlich in den Leerlauf (Failsafe Position), die Maschine fliegt gerade weiter (Hold). Nach 5-6 Sekunden aber reagiert die Maschine wieder und wir fliegen normal weiter.  Nach diesem Zwischenfall waren wir uns damals nicht sicher was das für ein Problem war, hier kamen auch andere Fakten noch hinzu, zum Beispiel das mein Sohn zu diesem Zeitpunkt die Kontrolle mit dem Schülersender über das Modell hatte. Zudem das Wetter und Wind, wir waren nicht sicher ob wir den „Leerlauf“ korrekt gehört haben. Und während der Phase habe ich vom Schüler auf meinen Lehrersender zurück geschaltet. Zu dem Zeitpunkt lief kein Telemetrie Log der etwas hätte beweisen können.
Nach Kontrolle damals konnten wir nichts finden, für mich galt das Argument einer Antennen Abschattung. Die Antennen waren nicht optimal verlegt und das korrigierte ich. Was blieb war ein komisches Gefühl. Bei weiteren Flügen gab es keine nennenswerten Probleme die klar auf der Hand lagen. Später aber auf einem Flugtag hatte ich wieder die Einbildung das es zu einem deutlich merkbaren Failsafe gekommen sei. Das Gefühl verschlechterte sich. Ich veränderte abermals die Anordnung der Antennen, begann mich aber auch mit dem Log der Telemetrie zu beschäftigen. Ich setzte eine entsprechend große SD Karte in der FX32 ein und aktivierte die Log Funktion mit dem Timer. Somit hatte ich seitdem jeweils Aufzeichnungen der Telemetrie, die ja auch die Empfangsstärke beinhalten. In den ersten Logs die ich kontrollierte fand ich erst mal nichts ungewöhnliches und keine konkreten Hinweise.

Kapitel 2 – Jetzt auch FASST

vampire-staffelIm August 2016 änderte sich die Situation schlagartig. Sommerfest im Verein. Unzählige Modellpiloten auf dem Flugplatz. Es war nicht der erste Flug an diesem Tag für den Impeller Jet, aber es sollte der letzte werden. Aus heiterem Himmel hatte ich plötzlich Probleme mit dem Futaba FASST System in dem Flieger (R617FS) und konnte nicht fliegen da die Servos nur ruckartig auf Befehle reagierten. Da das Problem kurz darauf aber auch wieder verschwunden war startete ich trotzdem. Ich weis, sowas tut man nicht! Die Strafe kam prompt: nach ca. 2 Minuten Flug kam das Problem zurück und erst kurzen Aussetzern folgte ein kompletter Ausfall der Steuerung der mich den Flieger kostete.
Bei Untersuchung nach dem Crash entnahmen wir die wichtigen Komponenten und bauten gleich vor Ort das RC System wieder auf. Symptom: Die Empfänger LED am R617FS blinkte wie wild grün und rot, blieb manchmal für mehrer Sekunden auf rot. Teilweise war dann das Problem wieder einmal ganz verschwunden, dann wieder da. Bereits hier fällt auf das die Problematik mehr oder weniger groß ist je nachdem ob ich mein Smartphone in der Nähe habe  oder nicht.
An diesem Tag wurde ich auf eine falsche Fährte gelockt durch die folgende Tatsache: Ich argumentierte mit einem defekten BEC System an diesem Flugzeug, da bei einem weiterem Test mit einem 4 Zellen NC Akku direkt am Empfänger das Problem nicht auftrat.
So ist das wenn man einem System über die Jahre blind vertraut hat, man kommt nicht auf die Idee daran zu zweifeln. Obwohl spätestens jetzt total klar war das hier ein Problem existiert mit dem Fernsteuersystem, suchte ich immer noch an einer anderen Stelle.

Der große Blackout

Im September entging ich nur kurz einer Katastrophe. Die J10 steht vollgetankt und mit 2 Liter Smokeöl versehen am Start. Ich schiebe den Hebel nach vorn und starte. Die endlose Power treibt den Flieger fast senkrecht in die Luft. Auf großer Höhe drossele ich die Turbine und gehe in den horizontalen Flug. Blackout. Turbine auf Leerlauf. Keine Kontrolle mehr. Die Maschine dreht nach rechts ab und fällt langsam, wird immer langsamer. Endlose Zeit vergeht. Die Maschine rollt weiter geht fast senkrecht nach unten. Plötzlich tourt die Turbine wieder auf, die Kontrolle ist wieder da. Ich schreie „Störung“ über den Platz und fliege zum Gegenanflug. Auf den kurzen Weg dorthin fühlbar mehrere Aussetzer, die Maschine steuert sich träge und merkwürdig. Gegenanflug, träge. Queranflug, Kurve, alles normal, Anflug, sicher aufsetzen, aber viel zu hektisch und zu schnell. Gerettet…..

Analyse

Das Vertrauen ist weg. Es ist sicher: Vorerst bleibt alles am Boden. Ich recherchiere im Netz nach Erklärungen, Hintergründen, lese viel. Und beginne verschiedene Tests um mir das Problem zu erklären.  Befasse mich mit der Telemetrie und den LOGs und komme somit zum Nachweis meines Blackout:

13-sec-failsafe-fasstestGanze 13 Sekunden hat der Failsafe gedauert. 13 Sekunden Ewigkeit, Hilflosigkeit ohne Kontrolle. Die Maschine war währenddessen nicht weit weg, vielleicht 120 – 150 Meter.  Ich bin kein Fachmann und kann nicht wie ein Entwickler solcher Systeme mit Fachwissen um mich werfen. Diese Statistik erkläre ich mir aber simpel. Der erste Datenwert in der Telemetrie ist die Zeit seid Beginn der Übertragung in Millisekunden, zu dem der Log Eintrag empfangen wird. Berechnet man die Differenz zwischen diesen Zeitstempeln erkennt man wenn zwischen Übertragungen längere Pausen vorkommen. Der erste große Peak hier dauerte über 13000ms . Mein Failsafe über 13 Sekunden! Schaut man sich die Log Werte für die Empfangsstärke an, die mit den Werten 0-3 dargestellt werden, so findet man diesen Ausfall nicht. Erst mit der dahinterliegenden Zeitbasis wird der Ausfall wirklich sichtbar! Die danach folgenden Peaks sind die Aussetzer von 2-3 Sekunden die ich im Gegenanflug registriert habe.
Eine simple Grafik, für mich der Beweis!

Reproduktion

Im weiteren Verlauf habe ich mich weiter eingelesen in die aktuelle Technik rund um die Protokolle FASST, FASSTest, Firmwareupdates, Telemetrie und anderes. Es wurde mir klar das „mein System“ sich stören lässt. Von anderen Sendern? Von WLAN, Richtfunk? Zum Zeitpunkt meines Vampire Absturzes flogen 5 weitere Modelle und andere Anlagen waren sicher ebenfalls in Betrieb. Zum Zeitpunkt des Blackout meiner J10 war ich alleine unterwegs. Aber unser Flugplatz hat ein WLAN Netzwerk für die Webcam und einen WLAN Hotspot. Sollte es möglich sein das sich mein FASST System so simpel stören lässt? Das war über Jahre undenkbar.

Proof of Concept: R617FS – FASST

Ich bin schockiert. Nachdem ich anfangs nicht klar zu einem Status gekommen bin mit dem ich die Aussetzer mit dem R617 Empfänger nachvollziehen konnte war es nach Recherche und Überlegung viel zu einfach.

Es reichte aus in meinem Wohnzimmer Sender und Empfänger zu positionieren. Um das Problem sichtbar zu machen musste ich dann meinem WLAN nur dazu bringen aktiv zu werden und viel Daten zu übertragen, hier eine Videodatei vom Notebook auf meine NAS.

Solange die Übertragung lief blinkte der Empfänger rot und hatte Aussetzer bis zu mehreren Sekunden. Wichtig: Ein zweiter parallel aktivierter Empfänger blinkte in absolut identischer Weise. Somit war jetzt klar das das Problem nicht der Empfänger sein kann, sondern vom Sender produziert wird.
Ein weiterer Test wurde hinzugezogen: Ich brachte meine alte FF-7 Anlage zur selben Position mit in Betrieb und war erstaunt. Diese Kombination aus FF-7 und R617FS lies sich nicht beeindrucken und funktioniert störungsfrei! Das Bild beider Systeme nebeneinander: Links: FX-32 / Rechts: FF7.

Ist meine FX-32 defekt? Meine FX-32 ist nicht defekt, den Beweis liefere ich am Ende dieses Artikels. Bisher kannte ich zwei Probleme: Aussetzer mit meinem neuen FASSTest Empfänger und Aussetzer mit einem über die Jahre verlässlichen FASST System. Mit meinem Sender! Es folgte der zweite Proof:

Proof of Concept: R7018SB

Das folgende Video zeigt das selbe Verhalten in der Kombination FX-32 und FASSTest R7018SB. Wichtig: Es ist weder mein Sender, noch mein Empfänger, noch mein Wohnort. Diesen Test führte ein anderer User für mich nach Vorgabe aus und nach Erklärung meiner Rahmenbedingungen war es auch hier brutal einfach möglich durch die reine Übertragung von Daten über das WLAN im Haus die Kommunikation von FASSTest zu stören. Daten übertragen vom Smartphone, die Link LED beginnt rot zu blinken:

Die Ursache

Die folgende Erkenntnis setzte sich mühsam in mehreren Iterationen zusammen. Ich habe kein teures Equipment um Messreihen aufzubauen, ich habe dies aus den durchgeführten Tests zusammengereimt und daraus ergeben sich logische Fakten. Das Problem schleust sich ins Futaba System ein mit Einführung der Norm EN300-328 Version 1.8.1 . Wer möchte kann sich ein paar Details dazu im Futaba Forum ansehen. Hier seht ihr auch welche Sender ab welcher Firmware Version dieser Norm folgen: Futaba Forum ETSI V1.81

Das primäre Problem ist meiner Meinung nach darin begründet das der Sender erst sendet wenn er vorher in seine Frequenz hineingehört hat und feststellt das dort nichts anderes ist. Bei FASST nennt man diese Anpassung LBT (listen before transmit). Bei der FX-32 kommt dieses Protokoll ab Firmware 1.4 zum Einsatz mit dem FASST Protokoll. Bei den anderen Empfängern mit FASSTest ist es fester Bestandteil der Produkte, die Firmware hat keinen Einfluss.

Lässt sich das neue Futaba System so leicht aus dem Tritt bringen? Verweigert es einfach zu senden weil es meint dort wäre noch etwas anderes im Weg. Genau dies habe ich mir hier bewiesen. Ich mag es nicht glauben, aber die Fakten lassen kein anderes Resultat zu.

Fazit

Es fehlt noch ein abschließender Test. Ich habe meine FX-32 als einer der ersten Kunden in Deutschland bekommen, noch mit Firmware 1.0. Auch wenn der Finger erhoben wird das man gegen Strafe zu unterlassen hat die Firmware unter 1.4 downzugraden, das ist mir egal. Ich habe die Version 1.3 auf meine Anlage geflasht und meine Tests durchgeführt. Mit der Firmware ohne LBT war es nicht möglich das FASST System wie vorher zu beeindrucken. Doch für FASSTest ist das nicht möglich. Der oben gezeigte Test mit R7018SB wurde mit einer FX-32 und Firmware 1.2 durchgeführt. Will man eine stabile Übertragung haben so bleibt nur eine Firmware kleiner 1.4 zu benutzen und auch die neueren Empfänger in den FASST Multi Modus umzuschalten.
Das Vertrauen ist zerstört. Über Jahre hat sich so eine starke Vertrauensbasis auf FASST aufgebaut das ich Anfangs es überhaupt nicht für möglich hielt das ich hier ein Problem habe. Ungewolltes Ausklinken beim Seglerschlepp (Failsafe programmiert) zeigen mir jetzt ein anderes Bild, es war gar nicht die Kupplung? Viele andere Hinweise auf diese Problematik stehen nun in einem anderen Licht. Ich war geblendet von der jahrelangen Problemlosigkeit. Eventuell geht sogar ein weiterer Modell Verlust in diesem Jahr auf das Konto FASST LBT.
Ich bin jetzt mutig, FASST hat über die Jahre bewiesen wie perfekt es funktioniert, mit der alten Firmware und den Systemen auf FASST Protokoll kann ich kurzzeitig leben. Doch es macht keinesfalls glücklich.
Wieso fällt das Problem nicht häufiger auf, wieso gibt es keine weiteren Berichte dazu? Es gibt vereinzelte Hinweise darauf, auch auf das flackern der LED bei FASST. Doch wieviele Anwender haben wirklich ihre Firmware gegen die neuere ausgetauscht. Wie viele nutzen wirklich intensiv FASSTest? Wann kommt die Konstellation zueinander die die Störungen hervor ruft. Welcher Modellflugplatz besitzt ein eigenes WLAN?
Wer ist daran Schuld? Futaba? Auch wenn sich das Problem hier bei Futaba zeigt, so sind für alle neuen Systeme, ganz gleich ob Hott, Jeti, Spektrum, Multiplex, ab dem 1.1.2015 die selben Voraussetzungen vorgeschrieben. Sie müssen konform mit der neuen Norm senden. Kann das Problem auch andere Hersteller betreffen die der neuen Norm entsprechend ihre Protokolle entwickeln. Oder hat ausgerechnet Futaba, der Vorreiter der 2,4GHz Systeme, einen simplen Bug in seinen Produkten?

Sind die Test repräsentativ? Sicher nicht, Experten schreien jetzt sicher nach einem „Labor“. Nun aber ich gebe zu bedenken, die Tests liefen nicht unter realen Bedingungen auf dem Modellflugplatz bei denen das Modell mehrere 100 Meter weit weg sein kann, noch waren weitere Modellflieger anwesend. Speziell bei meinen Tests war das Umfeld viel optimaler. Es war nur mein WLAN anwesend, Sender und Empfänger waren nur wenige Meter entfernt im selben Raum. Wo würde man ehr Probleme erwarten?

An dieser Stelle enden meine Ausführungen denn ich bin zu wenig Entwickler, Spezialist, Funktechniker oder Elektroniker um das fachlich erklären zu können. Ich habe nur meine Beobachtungen und Tests und die dabei gesammelten Fakten hier wiedergegeben. Ich verzichte bewusst darauf diesen Beitrag in einem Forum zu veröffentlichen wo er nicht unter meiner Kontrolle bleibt und dann von Moderatoren oder Futaba Befürwortern tot gelegt wird.

Wer mit diskutieren möchte kann dies im Forum von jet-hangar.de tun.

 

 

 

3 Comments

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.