Seitdem ich meine DC 24II nutze, habe ich Probleme mit der erstmals in der Jeti DC 24II werksseitig eingebauten Bluetooth - Audio-Lösung. Nun hab ich endlich eine Lösung für das Problem gefunden.
Was ist das Problem.
Beim Betrieb des Bluetooth-Audio Moduls in Zusammenhang mit einem BT Headset gab es regelmäßig Beeinflussungen des Telemetriedaten-Rückkanals. Dies äußerte sich einerseits durch einen mäßigen Q-Wert, also die Bilanzierung der Anzahl der gesendeten verglichen mit den empfangenen Datenpaketen. Dies machte sich konkret beim Einsatz eines Lua-Skriptes bemerkbar indem immer wieder "Höhe Null Meter" angesagt wurde, weil schlicht keine Telemetriedaten zur Verfügung standen.
Dies kann man in dem Diagramm hier gut erkennen:
Ab etwa Minute 22 wurde die interne BT-Lösung genutzt. Davor war ein extern an den Kopfhörerausgang angeschlossenes. externes BT-Audiomodul in Verwendung, das neben dem Sender im Zwischenraum des Acrylpults positioniert war, um auszuschließen, dass BT generell den Rückkanal stört, wie ja immer wieder behauptet wird. Etwa bei Minute 26 ist auch eine Datenlücke bei der Höhe zu sehen, die immer wieder beim Steigflug auftritt und den Höhenalarm verzögert oder gar nicht aufruft.
Durch die Verwendung eines externen BT-Audiomoduls ist also klar, dass Bluetooth nicht generell den RC-Rückkanal stört. Man muss beide Systeme eben so positionieren, wie deren Verwendung ist.
So wird das RC-Signal bzw. der Rückkanal eben vor dem Sender benötigt, weil dort die Modelle sind, die zu steuern sind. Das BT-Audiosignal wird aber hinter dem Sender benötigt, weil hier eben der Pilot steht und die Informationen abhören möchte.
Daher war ein Anfangsverdacht gegeben, dass die BT bzw. WiFi Antenne in der DC24 II hier so ungünstig positioniert ist, dass sie eben die RC-Funkstrecken geringfügig aber dennoch signifikant beeinflusst.
Die Problemlösung
Die angesprochene Antenne für Bluetooth und Wifi ist bei der DC24 II unterhalb des Display beheimatet. Der Bereich ist durch die senkrechten Linien erkennbar, die vermutlich auf die Tasten hinweisen sollen, die als sogenannte Softkeys dienen zur Bedienung der Benutzeroberfläche.
Und hier liegt vermutlich auch das Probleme. Die Antenne ist ein Rundstrahler und so kann aucgh ein Teil der Sendeleistung an die vorne in den "Hörnern" befindlichen RC-Antennen gelangen. Da der Zugang zu der BT/WiFi-Antenne aber recht kompliziert ist und einiges an Demontagearbeiten bedeutet, war mir dies für Versuche zu kritisch und kompliziert.
Deshalb habe ich die Original-Antenne versuchsweise vom ESP32 Modul abgeklemmt und isoliert.
Die Antenne selber wurde außerhalb des Senders am Acrylpult angebracht und so positioniert, dass eine direkte Beeinflussung der RC-Antennen ausgeschlossen werden kann da keinerlei "Sichtverbindung" zu den Antennen besteht. Dankenswerterweise ist der U.FL-Antennenstecker so winzig, dass das Antennenkabel durch eine der für die Senderbefestigung vorgesehenen und mit Gewindestiften verschlossenen M4 Gewinde auf der Senderrückseite durchgeführt werden konnte.
Mit dieser Anordnung wurden verschiedene Modelle geflogen sowohl mit als auch ohne Headset.
Das Ergebnis ist hier zu sehen:
Es ist nicht mehr zu erkennen wann mit aktivem BT-Audio geflogen wurde und wann nicht. In diesem Fall wurde das Headset nach 10 Minuten abgeschaltet.
Mit dieser Modifikation ist für mich das Problem erst einmal gelöst.
Ich empfinde es aber als wenig professionell, dass dieses Problem nicht bereits bei der Entwicklung des Senders untersucht und gelöst wurde. Durch geringfügige Modifikation der Originalantenne (etwas niedriger einbauen und mit dünnen Folien nach oben hin abschirmen) hätte hier bereits werksseitig Abhilfe geschaffen werden können. Da wir aktuell mitten in der Flugsaison sind, werde ich erst in der Wintersaison weitere Versuche mit einer Modifikation der Originalantenne unternehmen und ggf. weiter berichten.