FDS
User
... eine Machbarkeitsstudie mit Folgen.
Alles begann irgendwann im Sommer 2021, als ich coronabedingt wieder öfter auf dem Modellflugplatz meines Vereins in der Nähe von Berlin war – sonst konnte man ja nicht viel machen. Ich schaute dort meinen Vereinskollegen Axel und Randolph begeistert beim GPS-Triangle Fliegen zu und beim Anblick der schönen DNAracer in der Luft war mein erster Impuls:
Zum Hintergrund: Ich fliege seit über 20 Jahren F3F-Wettbewerbe, überwiegend in Dänemark und überwiegend mit eher bescheidenem Erfolg. Schon in den 2000ern haben mein Kumpel Bernd und ich regelmäßig gebrainstormed, wie man mit Hilfe von Lasern, Kameras oder sonst was eine Anlage zur Erkennung der Wendemarken entwickeln könnte, damit wir vielleicht endlich begreifen, wie man eine Wende einleitet BEVOR es piept. Dann kam Barney's piCAMTracker und die Sache war erstmal vom Tisch. Nicht dass wir uns jemals einen Tracker gebaut hätten, also haben wir die Wenden weiterhin beim Piep eingeleitet.
Zurück zum Triangle: Dem ersten Impuls habe ich widerstanden. Zum zweiten Impuls: Ich wollte das mal probieren und habe mir von Axel einen SM GPS Logger der ersten Generation ausgeliehen und auf meinen E-Radical getaped, den inzwischen ausgemusterten und deshalb kostenlosen Sky-Navigator auf dem Handy installiert, das Handy mittels Saugnapf-Halterung auf das Display meiner Jeti DC16 geklebt (Autsch!) und los ging es. Und ich hatte Spaß und konnte Dreiecke fliegen.
Um so richtig ins Triangle einzusteigen hat es aber dann doch nicht gereicht. Und am Hang habe ich es dann mangels Hang in Berlin auch nicht probiert. Den Sensor also irgendwann zurückgegeben und das wars dann erstmal.
Mein cooles Triangle-Setup:
Ich bin eigentlich Pilot alter Schule (brauche keine Telemetrie!) - aber irgendwie hatte das schon ganz gut funktioniert. Es hat mir dann doch keine Ruhe gelassen, also habe ich in einen 'SM GPS Logger 3' investiert um das GPS doch mal am Hang zu probieren. Wenn es nicht klappt – wovon ich damals eigentlich ausgegangen bin – kann man das Ding ja noch als Vario benutzen oder an einer Halskette tragen.
Also habe ich den Logger in einem geeigneten Rumpf untergebracht und im Sender einen Entfernungsalarm programmiert – auf 55m statt 50m - man will schließlich auch ein bisschen vor der Hangkante fliegen. Und dann ab nach Laucha, was für uns Berliner so etwas wie ein Haushang ist.
Abwurf – Flug und .... es piept. Nicht so ganz genau da, wo die Wendelinie hin gehört aber immerhin. Wenn ich im richtigen Abstand vor der Kante in der richtigen Höhe und nicht zu schnell geflogen bin kam richtig ein F3F Feeling auf. Natürlich kann man bei dieser Technik die 50m auch direkt nach vorne oder nach oben oder auch nach hinten fliegen, dann piept es genauso. Aber es machte Mut. Ich habe festgestellt, dass die Position beim Piep zwar nicht so richtig stimmte, aber sie war halbwegs deterministisch. Beim schnellen Fliegen kam der Piep immer zu spät, beim Fliegen weiter vor der Kante immer zu früh. Damit kann man arbeiten.
Mein Hangflugkumpel Frank hatte das ganze interessiert verfolgt und wollte nun auch einen Sensor. Nach kurzer Recherche schlug er den 'HEPF GPS Sensor' vor. Mit der zugehörigen Software sollte es möglich sein, Flugzonen zu definieren. Die Idee war also eine rechteckige Flugzone vor dem Hang zu nutzen. Ich habe mir das dann angeschaut und nicht schlecht gestaunt, dass die Software samt Kartenanzeige und Flugzonendefinition auf dem Jeti Sender betrieben werden sollte.
LUA als Programmiersprache kannte ich bis dahin nicht, hatte aber schon davon gehört, dass es so etwas wie LUA-Scripte auf Jeti Sendern gibt. Ich hatte das aber nie wirklich ernst genommen. Für mich - der in den 80er Jahren Informatik studiert hat - ist alles außer C++ sowieso nur Spielerei
. Ich dachte also das sind irgendwelche Makros, mit denen man ein paar vorgegebene Befehle abspielen kann.
Aber wenn man sich anschaut was die Sensorsoftware damit macht lohnt es sich vielleicht da mal genauer drauf zu schauen. Sehr schnell waren im Netz zahlreiche LUA-Apps gefunden und ich war begeistert, wie mächtig das ist. Es hat mich nicht wirklich technisch überrascht, vielmehr hatte ich nicht damit gerechnet, dass ein Hersteller von Fernsteuerungen so einen Interpreter wirklich in seine Firmware integriert.
Alle Achtung Jeti!
GPS-Sensor im Freestyler-Rumpf:
Nun hatte ich Bock! Dass man so eine Flugzone vor dem Hang auch recht schnell mit Hilfe der Trigonometrie berechnen kann hatte ich mir schon überlegt, allerdings müsste man sich noch mit Entfernungs- und Winkelbestimmung anhand von GPS-Positionen beschäftigen. Aber eins nach dem anderen.
Erstmal ein 'Hello World' in LUA, dann mal ein Konfigurationsmenü registrieren, einen Sensor auslesen, die Basics halt. Beispiele gab es ja im Netz genug. Und die Doku zur Jeti-API lesen - und schon wieder staunte ich: Die Jeti GPS-API liefert Positionen, Entfernungen und Winkel, also alles, was ich für die trigonometrische Berechnung benötigte. Hammer – nun hatte ich richtig Bock!
Ca. eine Woche saß ich vorm Rechner – mit kurzen Schlafpausen – und programmierte den kompletten F3F-Ablauf, Countdown, Streckenzähler, Stoppuhr – und die rechteckige Flugzone vor dem Hang. Ich rannte zur Verwunderung meiner Nachbarn mit einem Rumpf und einem Sender durch den Garten und es war nur ein gelegentliches Piepen zu vernehmen. Aber ja, prinzipiell machte der cosinus was von ihm erwartet wurde (nachdem ich begriffen hatte, dass man den Winkel erst ins Bogenmaß umrechnen sollte).
Um dann auch noch einen Einflug hinzubekommen habe ich begonnen mit Offsets zu arbeiten. Die Strecke wurde also auf 50m pro Seite definiert und dann beim Ausflug um einen konstanten Wert verkürzt um der Latenz entgegen zu wirken, beim Einflug entsprechend verlängert. Fertig war der erste Prototyp, Yeah!
Und es funktionierte – zumindest in einem gewissen Geschwindigkeitsbereich. Man konnte jetzt auch weit vor dem Hang fliegen und es piepte einigermaßen korrekt an der Linie. Es erwies sich allerdings als schwierig, die Offsets so einzustellen, dass die A-Base beim Ausflug und beim Einflug an der selben Stelle erkannt wird. Außerdem war zu beobachten, dass sich mit zunehmender Geschwindigkeit doch die Base deutlich verschiebt, die Latenz forderte ihren Tribut.
Da kann man doch was machen! In der nächsten Version waren die Offsets abhängig von der Geschwindigkeit, die ich ja auch direkt vom Sensor beziehen konnte. Die Faktoren, mit denen die Geschwindigkeit die Offsets für Einflug und Ausflug beeinflusst habe ich auf Potis gelegt. Nun konnte ich im Flug das System so justieren, dass – zumindest bei meinem Sender- und Telemetriesetup – die Wendemarken recht gut von beiden Seiten erkannt werden, und das auch bei unterschiedlichen Geschwindigkeiten. Fertig war der zweite Prototyp. Supi!
Erste Versuche:
Es sprach sich auch so langsam rum, dass ich da am Basteln war. Und so kam es, dass ich dann im März 2022 gemeinsam mit Katja und Frank - meinen Betatestern der ersten Stunde - das Projekt schon mal im Chat des F3F-Aktivenforums vorgestellt habe, damals unter dem aussagekräftigen Arbeitstitel 'GPS-Wenden-Signal-Gedöns'.
Das Interesse war groß, die Freude wurde allerdings dadurch getrübt, dass einige der Teilnehmer doch eher Graupner-Piloten waren.
Dann ging es an die wunderschönen Hänge nach Dänemark. Dort wird ja nicht nur geflogen, sondern auch zugeschaut. Und dann fällt es schon auf, wenn es an den Wendemarken piept und ab und zu eine Zeitansage zu hören ist - und nirgends am Hang eine Kamera oder sonstige Anlage steht. Und das nicht nur bei mir, auch Katja und Frank flogen piepsend durch die Gegend. Und so mußten wir dann Rede und Antwort stehen, und die Verbreitung des F3F-Tool Prototyps nahm seinen Lauf – bei Piloten aus Deutschland, Dänemark, Norwegen, Island ... Dabei war das Ganze bis dahin für mich nicht viel mehr als eine Machbarkeitsstudie – zugegeben mit dem Ergebnis 'prinzipiell machbar'. Keine vernünftige Doku, kein Update-Konzept, so gut wie kein Fehlerhandling – ein Albtraum für einen Informatiker.
Aber gut, es lohnt sich ja. Also machte ich das einzig Richtige, das, was einem im Job nie vergönnt ist, weil die Zeit fehlt oder das Geld fehlt oder die Zeit und das Geld fehlt. Ich warf den Prototyp weg!
Und ich schrieb es komplett neu, diesmal mit Struktur. Barney hatte mir noch Tips gegeben, wie man in LUA objektorientiert arbeiten kann, das klang doch gut. Und jetzt mit einstellbarer A-Base, besserem Fehlerhandling, und besserer Konfigurationsoberfläche.
Da auch schon die Idee aufgekommen war das Tool im F3B-Training einzusetzen baute ich noch einen Modus dafür ein, bei dem man nicht extra in die Mitte der Strecke laufen muss als wäre es ein Hang. Ich hatte kurz erwogen, den Namen auf 'F3X-Tool' zu ändern, wollte aber erstmal sehen ob das für F3B überhaupt taugt. Also bleibt es vorerst ein F3F-Tool mit F3B-Modus.
Nun muss man wissen, dass es auf den 'alten' Jeti-Sendern – die mit dem Schwarz/Weiß Display – eine strikte Begrenzung des Arbeitsspeichers gibt. Ich hatte mir für die Entwicklung sowieso schon eine DS-24 gegönnt, die ich seit dem versuche aus den eingehenden Spenden einiger Nutzer (Danke!) zu refinanzieren. Trotzdem habe ich immer versucht, den Speicherverbrauch so klein zu halten, dass es auf meiner alten DS-16 noch läuft. Aber die neue F3F-Tool Version sprengte nun total den Rahmen. Schade! Ich habe ja kein Problem damit, wenn man wegen meines Tools von Graupner auf Jeti umsteigt. Aber wenn alte DS-16 oder DS-14 Anlagen, die ja eigentlich für die Ewigkeit gebaut sind, meinetwegen ausgemustert werden finde ich das doof.
Die neuen aufgeräumten Konfigurationsmenüs:
Inzwischen hatte sich bereits ein Netzwerk von F3F-Tool Nutzern gebildet, über welches ich Kontakt mit Dave aus den USA bekam. Dave ist ein sehr erfahrener LUA-Entwickler mit zahlreichen coolen Apps im Angebot und er arbeitete damals an einem ähnlichen GPS-Ansatz für F3B/F3G. Wir standen also vor den selben Herausforderungen, auch in Bezug auf die Speicherbegrenzung der alten Sender. Wir tauschten uns in seitenlangen Emails aus, und Dave brachte die Idee ein, Code aus- und wieder einzulagern. Das gab es schon bei Windows 3.1 in den 90ern, aber toll dass man das auch mit LUA machen kann.
Dass ich das Programm diesmal strukturiert hatte zahlte sich aus. Denn so konnte ich relativ schnell ganze Objekte aus dem Speicher werfen, wie z.B. die gesamten Konfigurations-Forms, die ja im Flug eher wenig benötigt werden. Und während der Konfiguration kann man dann die Fluglogik auslagern, tolle Sache. Letzten Endes doch viel Fummelei aber es gelang mir, den Speicherverbrauch permanent unter die kritische Größe zu drücken. Und somit gibt es das Tool auch weiterhin für alle Jeti Sender. Cool!
https://github.com/frank-sc/F3F-Tool-V1
Im Wesentlichen war das – etwas verkürzt - die ganze Story. Ich leite jetzt ab und zu die Wende wirklich schon vor dem Piep ein (bin allerdings dann machmal auch schon vor dem Piep rum). Und ich denke, die Geschichte ist noch nicht zu Ende da geht noch was – spätestens mit der nächsten Sensorgeneration.
Wir sehen uns am Hang
Frank
FAQ:
Geht das auch für Graupner oder Futaba oder andere Sender?
Nein, leider stellen Graupner und Futaba keinen LUA Interpreter zur Verfügung, sind also nicht in dieser Form programmierbar. Auch andere Sender sind mir nicht bekannt, außer OpenTX-Systeme.
Läuft das dann auch auf OpenTX?
Nein, leider auch nicht direkt. Man müsste die komplette Verwendung der Jeti-API ersetzen, das betrifft Konfigurationsmenüs, Displayansteuerung, GPS-Berechnungen, Sensorzugriffe ... eigentlich ein schönes Projekt ...
Ist das denn auch genau?
Nein, nicht so ganz. Aber irgendwie doch auch schon. Das aufkommende F3F-Feeling ist schon gut. Muss jeder selbst entscheiden, ob die Genauigkeit ihm ausreicht.
Das Consumer-GPS ist einfach prinzipiell nicht genau genug und die Übertragung über die Telemetrie auch nicht optimal. Die guten Triangle Systeme nutzen ja eine eigene Funkstrecke für die GPS-Übertragung. Das ist allerdings recht teuer und passt in keinen F3F-Rumpf.
Wie fliegt das denn ohne Motor?
Das hat mit GPS nix zu tun, bitte woanders fragen!
Alles begann irgendwann im Sommer 2021, als ich coronabedingt wieder öfter auf dem Modellflugplatz meines Vereins in der Nähe von Berlin war – sonst konnte man ja nicht viel machen. Ich schaute dort meinen Vereinskollegen Axel und Randolph begeistert beim GPS-Triangle Fliegen zu und beim Anblick der schönen DNAracer in der Luft war mein erster Impuls:
"Will auch haben"
und mein zweiter Impuls:"Das müsste doch irgendwie auch beim F3F funktionieren".
Zum Hintergrund: Ich fliege seit über 20 Jahren F3F-Wettbewerbe, überwiegend in Dänemark und überwiegend mit eher bescheidenem Erfolg. Schon in den 2000ern haben mein Kumpel Bernd und ich regelmäßig gebrainstormed, wie man mit Hilfe von Lasern, Kameras oder sonst was eine Anlage zur Erkennung der Wendemarken entwickeln könnte, damit wir vielleicht endlich begreifen, wie man eine Wende einleitet BEVOR es piept. Dann kam Barney's piCAMTracker und die Sache war erstmal vom Tisch. Nicht dass wir uns jemals einen Tracker gebaut hätten, also haben wir die Wenden weiterhin beim Piep eingeleitet.
Zurück zum Triangle: Dem ersten Impuls habe ich widerstanden. Zum zweiten Impuls: Ich wollte das mal probieren und habe mir von Axel einen SM GPS Logger der ersten Generation ausgeliehen und auf meinen E-Radical getaped, den inzwischen ausgemusterten und deshalb kostenlosen Sky-Navigator auf dem Handy installiert, das Handy mittels Saugnapf-Halterung auf das Display meiner Jeti DC16 geklebt (Autsch!) und los ging es. Und ich hatte Spaß und konnte Dreiecke fliegen.
Um so richtig ins Triangle einzusteigen hat es aber dann doch nicht gereicht. Und am Hang habe ich es dann mangels Hang in Berlin auch nicht probiert. Den Sensor also irgendwann zurückgegeben und das wars dann erstmal.
Mein cooles Triangle-Setup:
Ich bin eigentlich Pilot alter Schule (brauche keine Telemetrie!) - aber irgendwie hatte das schon ganz gut funktioniert. Es hat mir dann doch keine Ruhe gelassen, also habe ich in einen 'SM GPS Logger 3' investiert um das GPS doch mal am Hang zu probieren. Wenn es nicht klappt – wovon ich damals eigentlich ausgegangen bin – kann man das Ding ja noch als Vario benutzen oder an einer Halskette tragen.
Also habe ich den Logger in einem geeigneten Rumpf untergebracht und im Sender einen Entfernungsalarm programmiert – auf 55m statt 50m - man will schließlich auch ein bisschen vor der Hangkante fliegen. Und dann ab nach Laucha, was für uns Berliner so etwas wie ein Haushang ist.
Abwurf – Flug und .... es piept. Nicht so ganz genau da, wo die Wendelinie hin gehört aber immerhin. Wenn ich im richtigen Abstand vor der Kante in der richtigen Höhe und nicht zu schnell geflogen bin kam richtig ein F3F Feeling auf. Natürlich kann man bei dieser Technik die 50m auch direkt nach vorne oder nach oben oder auch nach hinten fliegen, dann piept es genauso. Aber es machte Mut. Ich habe festgestellt, dass die Position beim Piep zwar nicht so richtig stimmte, aber sie war halbwegs deterministisch. Beim schnellen Fliegen kam der Piep immer zu spät, beim Fliegen weiter vor der Kante immer zu früh. Damit kann man arbeiten.
Mein Hangflugkumpel Frank hatte das ganze interessiert verfolgt und wollte nun auch einen Sensor. Nach kurzer Recherche schlug er den 'HEPF GPS Sensor' vor. Mit der zugehörigen Software sollte es möglich sein, Flugzonen zu definieren. Die Idee war also eine rechteckige Flugzone vor dem Hang zu nutzen. Ich habe mir das dann angeschaut und nicht schlecht gestaunt, dass die Software samt Kartenanzeige und Flugzonendefinition auf dem Jeti Sender betrieben werden sollte.
LUA als Programmiersprache kannte ich bis dahin nicht, hatte aber schon davon gehört, dass es so etwas wie LUA-Scripte auf Jeti Sendern gibt. Ich hatte das aber nie wirklich ernst genommen. Für mich - der in den 80er Jahren Informatik studiert hat - ist alles außer C++ sowieso nur Spielerei
. Ich dachte also das sind irgendwelche Makros, mit denen man ein paar vorgegebene Befehle abspielen kann.Aber wenn man sich anschaut was die Sensorsoftware damit macht lohnt es sich vielleicht da mal genauer drauf zu schauen. Sehr schnell waren im Netz zahlreiche LUA-Apps gefunden und ich war begeistert, wie mächtig das ist. Es hat mich nicht wirklich technisch überrascht, vielmehr hatte ich nicht damit gerechnet, dass ein Hersteller von Fernsteuerungen so einen Interpreter wirklich in seine Firmware integriert.
Alle Achtung Jeti!
GPS-Sensor im Freestyler-Rumpf:
Nun hatte ich Bock! Dass man so eine Flugzone vor dem Hang auch recht schnell mit Hilfe der Trigonometrie berechnen kann hatte ich mir schon überlegt, allerdings müsste man sich noch mit Entfernungs- und Winkelbestimmung anhand von GPS-Positionen beschäftigen. Aber eins nach dem anderen.
Erstmal ein 'Hello World' in LUA, dann mal ein Konfigurationsmenü registrieren, einen Sensor auslesen, die Basics halt. Beispiele gab es ja im Netz genug. Und die Doku zur Jeti-API lesen - und schon wieder staunte ich: Die Jeti GPS-API liefert Positionen, Entfernungen und Winkel, also alles, was ich für die trigonometrische Berechnung benötigte. Hammer – nun hatte ich richtig Bock!
Ca. eine Woche saß ich vorm Rechner – mit kurzen Schlafpausen – und programmierte den kompletten F3F-Ablauf, Countdown, Streckenzähler, Stoppuhr – und die rechteckige Flugzone vor dem Hang. Ich rannte zur Verwunderung meiner Nachbarn mit einem Rumpf und einem Sender durch den Garten und es war nur ein gelegentliches Piepen zu vernehmen. Aber ja, prinzipiell machte der cosinus was von ihm erwartet wurde (nachdem ich begriffen hatte, dass man den Winkel erst ins Bogenmaß umrechnen sollte).
Um dann auch noch einen Einflug hinzubekommen habe ich begonnen mit Offsets zu arbeiten. Die Strecke wurde also auf 50m pro Seite definiert und dann beim Ausflug um einen konstanten Wert verkürzt um der Latenz entgegen zu wirken, beim Einflug entsprechend verlängert. Fertig war der erste Prototyp, Yeah!
Und es funktionierte – zumindest in einem gewissen Geschwindigkeitsbereich. Man konnte jetzt auch weit vor dem Hang fliegen und es piepte einigermaßen korrekt an der Linie. Es erwies sich allerdings als schwierig, die Offsets so einzustellen, dass die A-Base beim Ausflug und beim Einflug an der selben Stelle erkannt wird. Außerdem war zu beobachten, dass sich mit zunehmender Geschwindigkeit doch die Base deutlich verschiebt, die Latenz forderte ihren Tribut.
Da kann man doch was machen! In der nächsten Version waren die Offsets abhängig von der Geschwindigkeit, die ich ja auch direkt vom Sensor beziehen konnte. Die Faktoren, mit denen die Geschwindigkeit die Offsets für Einflug und Ausflug beeinflusst habe ich auf Potis gelegt. Nun konnte ich im Flug das System so justieren, dass – zumindest bei meinem Sender- und Telemetriesetup – die Wendemarken recht gut von beiden Seiten erkannt werden, und das auch bei unterschiedlichen Geschwindigkeiten. Fertig war der zweite Prototyp. Supi!
Erste Versuche:
Es sprach sich auch so langsam rum, dass ich da am Basteln war. Und so kam es, dass ich dann im März 2022 gemeinsam mit Katja und Frank - meinen Betatestern der ersten Stunde - das Projekt schon mal im Chat des F3F-Aktivenforums vorgestellt habe, damals unter dem aussagekräftigen Arbeitstitel 'GPS-Wenden-Signal-Gedöns'.
Das Interesse war groß, die Freude wurde allerdings dadurch getrübt, dass einige der Teilnehmer doch eher Graupner-Piloten waren.
Dann ging es an die wunderschönen Hänge nach Dänemark. Dort wird ja nicht nur geflogen, sondern auch zugeschaut. Und dann fällt es schon auf, wenn es an den Wendemarken piept und ab und zu eine Zeitansage zu hören ist - und nirgends am Hang eine Kamera oder sonstige Anlage steht. Und das nicht nur bei mir, auch Katja und Frank flogen piepsend durch die Gegend. Und so mußten wir dann Rede und Antwort stehen, und die Verbreitung des F3F-Tool Prototyps nahm seinen Lauf – bei Piloten aus Deutschland, Dänemark, Norwegen, Island ... Dabei war das Ganze bis dahin für mich nicht viel mehr als eine Machbarkeitsstudie – zugegeben mit dem Ergebnis 'prinzipiell machbar'. Keine vernünftige Doku, kein Update-Konzept, so gut wie kein Fehlerhandling – ein Albtraum für einen Informatiker.
Aber gut, es lohnt sich ja. Also machte ich das einzig Richtige, das, was einem im Job nie vergönnt ist, weil die Zeit fehlt oder das Geld fehlt oder die Zeit und das Geld fehlt. Ich warf den Prototyp weg!
Und ich schrieb es komplett neu, diesmal mit Struktur. Barney hatte mir noch Tips gegeben, wie man in LUA objektorientiert arbeiten kann, das klang doch gut. Und jetzt mit einstellbarer A-Base, besserem Fehlerhandling, und besserer Konfigurationsoberfläche.
Da auch schon die Idee aufgekommen war das Tool im F3B-Training einzusetzen baute ich noch einen Modus dafür ein, bei dem man nicht extra in die Mitte der Strecke laufen muss als wäre es ein Hang. Ich hatte kurz erwogen, den Namen auf 'F3X-Tool' zu ändern, wollte aber erstmal sehen ob das für F3B überhaupt taugt. Also bleibt es vorerst ein F3F-Tool mit F3B-Modus.
Nun muss man wissen, dass es auf den 'alten' Jeti-Sendern – die mit dem Schwarz/Weiß Display – eine strikte Begrenzung des Arbeitsspeichers gibt. Ich hatte mir für die Entwicklung sowieso schon eine DS-24 gegönnt, die ich seit dem versuche aus den eingehenden Spenden einiger Nutzer (Danke!) zu refinanzieren. Trotzdem habe ich immer versucht, den Speicherverbrauch so klein zu halten, dass es auf meiner alten DS-16 noch läuft. Aber die neue F3F-Tool Version sprengte nun total den Rahmen. Schade! Ich habe ja kein Problem damit, wenn man wegen meines Tools von Graupner auf Jeti umsteigt. Aber wenn alte DS-16 oder DS-14 Anlagen, die ja eigentlich für die Ewigkeit gebaut sind, meinetwegen ausgemustert werden finde ich das doof.
Die neuen aufgeräumten Konfigurationsmenüs:
Inzwischen hatte sich bereits ein Netzwerk von F3F-Tool Nutzern gebildet, über welches ich Kontakt mit Dave aus den USA bekam. Dave ist ein sehr erfahrener LUA-Entwickler mit zahlreichen coolen Apps im Angebot und er arbeitete damals an einem ähnlichen GPS-Ansatz für F3B/F3G. Wir standen also vor den selben Herausforderungen, auch in Bezug auf die Speicherbegrenzung der alten Sender. Wir tauschten uns in seitenlangen Emails aus, und Dave brachte die Idee ein, Code aus- und wieder einzulagern. Das gab es schon bei Windows 3.1 in den 90ern, aber toll dass man das auch mit LUA machen kann.
Dass ich das Programm diesmal strukturiert hatte zahlte sich aus. Denn so konnte ich relativ schnell ganze Objekte aus dem Speicher werfen, wie z.B. die gesamten Konfigurations-Forms, die ja im Flug eher wenig benötigt werden. Und während der Konfiguration kann man dann die Fluglogik auslagern, tolle Sache. Letzten Endes doch viel Fummelei aber es gelang mir, den Speicherverbrauch permanent unter die kritische Größe zu drücken. Und somit gibt es das Tool auch weiterhin für alle Jeti Sender. Cool!
Pünktlich zu Ostern 2023 war die Version 1.4 dann fertig zum Test. Die Ergebnisse:- F3F geht ganz gut
- Auch im F3B-Distance Training erfreuen sich Piloten daran
- Beim Speed Training ist die Begeisterung noch verhalten, da gibt es noch Potential
https://github.com/frank-sc/F3F-Tool-V1
Im Wesentlichen war das – etwas verkürzt - die ganze Story. Ich leite jetzt ab und zu die Wende wirklich schon vor dem Piep ein (bin allerdings dann machmal auch schon vor dem Piep rum). Und ich denke, die Geschichte ist noch nicht zu Ende da geht noch was – spätestens mit der nächsten Sensorgeneration.
Wir sehen uns am Hang
Frank
FAQ:
Geht das auch für Graupner oder Futaba oder andere Sender?
Nein, leider stellen Graupner und Futaba keinen LUA Interpreter zur Verfügung, sind also nicht in dieser Form programmierbar. Auch andere Sender sind mir nicht bekannt, außer OpenTX-Systeme.
Läuft das dann auch auf OpenTX?
Nein, leider auch nicht direkt. Man müsste die komplette Verwendung der Jeti-API ersetzen, das betrifft Konfigurationsmenüs, Displayansteuerung, GPS-Berechnungen, Sensorzugriffe ... eigentlich ein schönes Projekt ...
Ist das denn auch genau?
Nein, nicht so ganz. Aber irgendwie doch auch schon. Das aufkommende F3F-Feeling ist schon gut. Muss jeder selbst entscheiden, ob die Genauigkeit ihm ausreicht.
Das Consumer-GPS ist einfach prinzipiell nicht genau genug und die Übertragung über die Telemetrie auch nicht optimal. Die guten Triangle Systeme nutzen ja eine eigene Funkstrecke für die GPS-Übertragung. Das ist allerdings recht teuer und passt in keinen F3F-Rumpf.
Wie fliegt das denn ohne Motor?
Das hat mit GPS nix zu tun, bitte woanders fragen!
Quatschen wir in Haho drüber. Vielleicht bei einem isotonischen Hefegetränk
