Taranis Lua Telemetry Script für OpentX ab 2.2.0 / 2.2.1 : Änderungen, Erweiterungen ...

09:11 ,Sa 30. Sep 2017,

Alles klar, Danke....
Werde ich heute Nachmittag mal ausprobieren

14:44 ,Sa 30. Sep 2017,

Ich habe erst einmal in den Sensoren den Wert für die "Dist" eingerichtet :
Man lernt soch nie aus

DANKE

Für alle Anderen (auch wenn von mir noch nicht getestet):
"Dist" wird nicht automatisch als Sensor angelegt.
Dies kann man jedoch ohne Probleme selber machen mit folgenden Einstellungen (Vorrausetzung ist natürlich das GPS)

Edit: Einstellungen korregiert

@Fandi
Du müsstest bei Dir "Entf" in "Dist" umbenennen

Nachdem wir schon einmal beim Thema Distanz sind, ist die Höhe auch nicht weit weg.
Da wir keine Baro-Daten haben, leben wir halt mit den GPS Höhen-Daten.
"Dummerweise" wird uns hier die Höhe über NN ( Normal Null) angezeigt.
Um das Ganze etwas lesbarer zu machen, habe ich den Code ein wenig geändert und noch ein Bildchen gebastelt:
Funktionsweise ist nun folgende:

* Solange am Häuschen oben kein Haken ist, wird die Höhe ab NN angezeigt.
* Das Höhensysmbol zeigt die NN rechts neben den Pfeilen mit an
* Wird das erste Mal nach dem Start von dem Script
________a) der GPS-Home-Fix signalisiert (die vordere 2 von Tmp2) UND
________b) sind genügend Satellieten verfügbar
__wird der Hacken am Häuschen gesetzt und die aktuelle Höhe wird als Starthöhe gewertet und
__ das NN ist aus dem Höhensymbol verschwunden
* Diese Höhe wird der weiteren Höhe immer als Offset abgezogen.
--> wer nun am Hang fliegt bekommt auch Minus Werte angezeigt, wenn er tiefer fliegt als seine Starthöhe.

Als Beispiel:

6 Sat gefunden, Höhe vom GPS = 200m , jedoch noch keine Bestätigung vom FC, das der Homepunkt gesetzt ist

4 Sat gefunden, Höhe vom GPS = 200m , Bestätigung vom FC, das der Homepunkt gesetzt ist, jedoch zu wenig Satelliten

6 Sat gefunden, Höhe vom GPS = 200m , Bestätigung vom FC, das der Homepunkt gesetzt ist, genügend Satelliten; die Höhe von 200m wird abgezogen : angezeigt wird 0m (als Flughöhe) und das Icon hat sich geändert (kein NN mehr dabei)

Im Flug : GPS gibt 250m über NN an, das Display zeigt 50m an

Hangflug: das Modell ist fliegt unter dem Startpunkt (HöhenMeter in Minus Bereich)

Was wurde geändert?

eine globale Variabel HomeAlt angelegt

Code: Alles auswählen

-- Leave as is!
...
...
local HomeAlt

diese wird in der Funktion init entsprechend mit 0 initialisiert ( hier könnte es ectl an der Küste Probleme geben??? )

Code: Alles auswählen

-- ###################### INIT ##########################
local function init()

	-- Calculate xOffset depending on how many single column widgets there are
	numSingleCols = 0
	numMultiCols = 0
	HomeAlt = 0

hier wird die Starthöhe gesetzt (sofern sie 0 ist)

Code: Alles auswählen

-----------------------------------------
 -- Home Point;    MULTI Row Col Widget --
 -----------------------------------------
 local function hpWidget(xCoord, yCoord)
--   if myQualSat < 3 then
	 if myQualSat < 2 then								-- bei CF und BF bekommen wir lt Beschreibung von CF nur 0,1 und 2; 2 = Home Fix
      lcd.drawPixmap(xCoord + 1, yCoord + 3, "/SCRIPTS/TELEMETRY/OLIME/home1.bmp")
      lcd.drawText(xCoord + 19, yCoord + 5, "?", MIDSIZE + BLINK)
   elseif myNumSat > 5 then
      lcd.drawPixmap(xCoord + 1, yCoord + 3, "/SCRIPTS/TELEMETRY/OLIME/home.bmp")
      lcd.drawPixmap(xCoord + 19, yCoord + 3, "/SCRIPTS/TELEMETRY/OLIME/check.bmp")

		if HomeAlt == 0 then							-- // wenn der Haken beim Häuschen gesetzt wird, sollte die Abflughöhe über Null stimmen
			HomeAlt = getValueOrDefault("GAlt")
		end

in der Funktion Hoehe wurden folgende Aenderungen gemacht

Code: Alles auswählen

local function heightWidget(xCoord, yCoord)

   --local height = getValueOrDefault("GAl")
   local height = getValueOrDefault("GAlt")
   
   if simModeOn == 1 then
      height = theight
   end
 
   flight_height = height - HomeAlt
		if  HomeAlt > 0 then
			lcd.drawPixmap(xCoord + 1, yCoord + 2, "/SCRIPTS/TELEMETRY/OLIME/hgt.bmp")
		else 
			lcd.drawPixmap(xCoord + 1, yCoord + 2, "/SCRIPTS/TELEMETRY/OLIME/hgtNN.bmp")
		end
	
   -- lcd.drawNumber(xCoord + 18, yCoord + 7, height, LEFT)                -- 213 Height
   lcd.drawNumber(xCoord + 18, yCoord + 7, flight_height, LEFT)

Die benötigten Files hängen unten an (nur Simuliert, noch nicht in der Funke getestet)

15:07 ,Sa 30. Sep 2017,

Ich habe gerade gesehen, das die Distanz auch auf GPS HöhenMeter von NN aufsetzt.
Hier müßte ich noch die Starthöhe abziehen.Dadurch wird es im Flug eine gewisse Unschärfe geben, da ich ja nur vom Endprodukt die Starthöhenmeter wieder abziehen kann. Ich werde draussen mal testen, ob die Distanz wirklich die Distanz zum Startpunkt ist und nicht nur die Höhenmeter (dann wäre Selber berechnen angesagt)

15:22 ,Sa 30. Sep 2017,

Ich habe gerade mal meinen Kopter programmiert,
und werde versuchen einen LOG zu erstellen der möglichst viele Dinge enthält....
Wird zwar nur ein Flug auf dem Balkon werden, es regnet aus Eimern, aber mal sehen....
Die Höhe ließe sich ja auch noch aus den GPS Daten berechnen,
Hier mal ein paar Informationen dazu:
http://www.luftknipser.de/blog/test-tec ... verwenden/

Edit:
und hier der LOG,
die GPS Werte sind nicht richtig, dafür war der Empfang zu schlecht.
Als Flugmode sollten Angle, Horizon, alt_hold,pos_hold und RTH drin sein.
Baro und Kompass sind an Board

15:57 ,Sa 30. Sep 2017,

Danke,
der Link ist Gold wert

http://www.luftknipser.de/blog/test-tec ... -verwenden

Dadurch konnte ich oben die Distanz auf 2D zurücksetzen und nun stimmt es mit der typischen GPS Toleranz

Die Timer muss ich mir im Script noch einmal anschauen .... irgendwie zeigen Sie mir je nach Flugmode andere Werte an ...
Norden ist noch Süden ... schauen wir mal ob eine Mag Änderung von CW180 den gewünschten Erfolg bringt....

Ansonsten schaut das Script schon gut aus.
Vielleicht sollte man die Höhenmeter per Taste zurücksetzen können? Oder vom GPS nehmen? Nur zu welchem Zeitpunkt? Und wann wieder zurücksetzen?

16:16 ,Sa 30. Sep 2017,

das größte Problem bei GPS Höhe ist, das die eigentlich ziemlich ungenau ist,
und sich erst nach ein paar Sekunden gut einstellt.
Bei meinem LOG stimmt die z.B. nie gut.
Ok, das wundert mich nun auch nicht wirklich, da auf dem überdachten Balkon.

Im normalen Ablauf, würde ich das dann zurücksetzen wenn der Kopter gearmt wird, da es eh erst dann wichtig ist.
Bei INAV dauert es eh ein wenig bis man armen kann, da erst 6 Sat und ein 3D Fix nötig sind.
Die Höhe sollte dann schon gut sein.

Mir ist aufgefallen, das bei meinen LOG die Höhe immer auf 0 steht, der Alt Sensor aber Daten von bis 2m liefert,
muß mir da das Script mal ansehen.

19:11 ,Sa 30. Sep 2017,

So ... bis auf Schönheitsfehler ( GPS Toleranz bei der Höhe ) und Sachen, welche man verbessern kann - läuft das Script wie es soll

Den Timer habe ich auf Vers 2.2. angpaßt.
Für unsere Long Range Flieger zeigt er auch nun Stunden an -> die Sekunden werden dann nicht mehr angezeigt, es blinkt allerdings dann schon nach den Minuten der Doppelpunkt ( leider ist dieser beim Screenshoot immo nicht zu sehen.

Der Timer ist der Gas-Timer : Also welcher nur läuft, wenn Throttle größer 0 ist.

Hier wieder die Änderungen : ( alles bis auf die erste Zeile neu )

Code: Alles auswählen

local function timerWidget(xCoord, yCoord)

  lcd.drawPixmap(xCoord + 1, yCoord + 3, "/SCRIPTS/TELEMETRY/OLIME/timer_1.bmp")
  --lcd.drawTimer(xCoord + 18, yCoord + 8, getValueOrDefault(197), 0) 
  
  local localtimer = model.getTimer(0)
			if (localtimer.value < 3600) then
				lcd.drawTimer(xCoord + 18, yCoord + 8, localtimer.value, 0)
			else
					lcd.drawTimer(xCoord + 18, yCoord + 8, localtimer.value / 60 , 0)
					lcd.drawText(lcd.getLastPos()+0,50,":",0+BLINK)
			end
 end

und sich erst nach ein paar Sekunden gut einstellt.

Das ist der Grund für meine Frage oben : Den Startpunkt mauell wieder auf 0 zurücksetzen ? und wie am dümmsten? Im Moment muss dafür die Funke fein säuberlich ausgeschalten oder das Modell gewechselt werden .... Also verbesserungswürdig.

Achja: ist der Schalter für das Loggen eigentlich von Interesse ? Das ist das einzige, was ich mir bisher noch nicht angeschaut habe

20:17 ,Sa 30. Sep 2017,

Hi

Danke für Deine / Eure Mühen !!!

Vielleicht solltet ihr den noch „Unbefleckten“ ganz kurz mitteilen, wie sie das Script in den Simulator der Taranis bekommen und wie und wo auf die Funke. Ich behaupte mal, dass das sehr viele nicht wissen

Many Greetz
Baumi

Gesendet von iPhone7 mit Tapatalk Pro

20:33 ,Sa 30. Sep 2017,

DeWe hat geschrieben:Achja: ist der Schalter für das Loggen eigentlich von Interesse ? Das ist das einzige, was ich mir bisher noch nicht angeschaut habe

Da hatte ich schon mal an anderer Stelle was zu geschrieben,
ich wollte das einfach automatisch haben, und logge in Abhängigkeit von RSSI>1

http://kopterforum.at/fernsteuerungen-f ... t3467.html

Vielleicht ist das ja auch was für Dich.

------

was ich bei dem Script gerne noch hätte:
die automatische Akku Anzahl Erkennung,
die des Open-Pilot läuft zuverlässig.
2 meiner Kopter fliege ich mit 3S oder mit 4S

20:38 ,Sa 30. Sep 2017,

Baumi hat geschrieben:Vielleicht solltet ihr den noch „Unbefleckten“ ganz kurz mitteilen, wie sie das Script in den Simulator der Taranis bekommen und wie und wo auf die Funke. Ich behaupte mal, dass das sehr viele nicht wissen

Hast recht,
macht sicherlich Sinn das in einem eigenen Beitrag zu schreiben.
Gilt dann ja nicht nur für dieses Script.
Ich werde es einfach mal anfangen.

21:20 ,Sa 30. Sep 2017,

Fandi hat geschrieben:
DeWe hat geschrieben:Achja: ist der Schalter für das Loggen eigentlich von Interesse ? Das ist das einzige, was ich mir bisher noch nicht angeschaut habe
Da hatte ich schon mal an anderer Stelle was zu geschrieben,
ich wollte das einfach automatisch haben, und logge in Abhängigkeit von RSSI>1

http://kopterforum.at/fernsteuerungen-f ... t3467.html

Vielleicht ist das ja auch was für Dich.

------

was ich bei dem Script gerne noch hätte:
die automatische Akku Anzahl Erkennung,
die des Open-Pilot läuft zuverlässig.
2 meiner Kopter fliege ich mit 3S oder mit 4S

Du meinst, wenn ein RSSI vorhanden ist?
Dann kann man es auch gleich mitlaufen lassen... so lange ist die Funke ja nicht an, ohne dass das Modell aus ist. Die meiste Zeit verbringt man eh mit dem eingeschalten Modell auf der Erde, um ein sauberes GPS Signal zu bekommen.... ausserdem : nur einschalten? Wenn auch ausschalten, wäre bei Funkabriss der Log unterbrochen... auch nicht so das gelbe vom Ei.

Meine Frage war auch noch : Wie man am dümmsten den Startpunkt Offset für die Höhe rücksetzen sollte, wenn man will... Alles was auch im Flug passieren kann macht kein Sinn. Aus-/Einschalten bzw Modellwechsel an der Funke auch nicht. Schalter ginge, aber es müsste auch einfacher gehen.
Immo wird das Ganze beim Armen gesetzt... oder passt das euch soweit?

Lipo Erkennung kann ich aus dem anderen Script übernehmen und anpassen, das sollte nicht das Ding sein.

Was mir noch vorschwebt : Einen Pfeil der in Richtung Kopter zeigt für den Fall der Springerde : Diese Richtung xyz Meterzu Fuß. Die Distanz haben wir ja schon, fehlt ja "nur" noch die Marschrichtung... nur noch

21:46 ,Sa 30. Sep 2017,

Genau, wenn RSSI vorhanden ist, wird geloggt.
Wenn der Kontakt abreißt, gibt es auch nichts zu loggen, die Aufzeichnung stoppt dann automatisch.
Hierbei ist es egal, ob man nun das Modell ausschaltet, oder der Kontakt abreißt.
Sobald die Verbindung wieder da ist wird weiter geloggt.
Ich habe es eher so gemacht, um den Datenmüll klein zu halten,
es ist aber tatsächlich nicht so viel.

Die Höhenmessung mit dem Armen zu setzen macht wohl am meisten Sinn,
toll wäre halt auch die Auswertung der Baro Messung, wenn es die den gibt.
Die ist meist genauer.

So einem Pfeil wird praktisch nicht möglich sein, da man bei der Modellsuche ja den Standort verlässt,
um das auszuwerten bräuchte die Funke ein eigenen GPS.
Was sicher gehen müßte ist ein Pfeil der anzeigt ob das Modell zu einen kommt, bzw. weg fliegt.
So was hat jedes OSD, dazu muß die "Marschrichtung" relativ zum Homepoint ja bekannt sein

21:55 ,Sa 30. Sep 2017,

Ich sag mal so rum:
Startgps Daten speichern und dann via Winkel Berechnung zu den aktuellen GPS Daten die Richtung bestimmen.
Wenn das Modell einbombt : Die Richtung anpeilen und auf den Weg machen. Da die Distanz auch bekannt ist entsprechend die Laugmeter schätzen... Sollte zumindest einen genaueren Anhalt geben, als aus den Gedächtnis den gemeinten Weg absuchen... Gut man könnte auch die letzten GPS Daten aus dem Telemetry Screen (Page 13 von 14) abfragen und den Routenplaner von Google in Anspruch nehmen... Nur wenn kein Netz vorhanden ist.....???

Für einen Pfeil, wenn das Modell weg oder zu einem fliegt, muss ja die gleiche Berechnung zugrunde gelegt werden. Es ist nur eine andere Darstellung und die letzte Position muss auch noch gespeichert werden, da es egal ist, in welcher Lage sich das Modell entfernt oder näher kommt.

21:58 ,Sa 30. Sep 2017,

DeWe hat geschrieben:Was mir noch vorschwebt : Einen Pfeil der in Richtung Kopter zeigt für den Fall der Springerde : Diese Richtung xyz Meterzu Fuß. Die Distanz haben wir ja schon, fehlt ja "nur" noch die Marschrichtung... nur noch

Dazu träume ich noch von einer Mini App für das Smartphone,
im Falle eines Falles, die letzten Koordinaten abtippen.
Loslaufen und die App zeigt einen Pfeil in die richtige Richtung plus die Entfernung.
Das Smarthphone hat da für alles nötige, GPS und Kompass
Gibt es so was schon? Kennt sich jemand mit so was aus?

Dazu kann man sich in einem anderen Telemetrie Bild die GPS Position auch anzeigen lassen.

DeWe hat geschrieben: Gut man könnte auch die letzten GPS Daten aus dem Telemetry Screen (Page 13 von 14) abfragen und den Routenplaner von Google in Anspruch nehmen... Nur wenn kein Netz vorhanden ist.....???

Ich sehe, Du hast ähnliche Gedanken, deswegen die Mini App,
die sollte stand allone laufen, ohne Google Maps.
Die GPS Daten sollten einfach ein zu tippen sein.
Je einfacher desto besser.

So ein Pfeil der einen anzeigt ob der Kopter zu einem hinfliegt oder eben nicht,
macht dann Sinn, wenn der Sichtkontakt verloren wurde.
Ohne RTH Funktion sicher eine tolle Hilfe

22:13 ,Sa 30. Sep 2017,

Google Map = Routenplaner :
Als Ziel dann entsprechend z. B.
48.10N 14.38E
als Ziel eingeben. Die Karte kann man sich ja vorher bei Bedarf auch offline laden (Gültigkeit ca 1 Monat, wenn man nicht per Tastendruck verlängert)

Btw:
Die billigste Möglichkeit für den Pfeil für näher kommen oder wegfliegen (nur diese Aussage) kann man aufgrund der sich verringerten 2D Distanz treffen

,. Dumm nur wenn man von ganz rechts oder links parallel zu sich Richtung Mitte fliegt

Bis zur Mitte wird die Distanz kürzer

22:26 ,Sa 30. Sep 2017,

Um Google Maps offline zu nutzen muß man sich irgendwie vorbereiten,
mit 100% Wahrscheinlichkeit fehlt genau das, wenn man es mal braucht.

Das mit der 2D Distanz gilt nur bedingt, da sich das Modell erst mal auch nähert,
wenn es sich im großen Winkel auf einen zu bewegt.
Obwohl man eine Gerade fliegt, und die Distanz erst einmal immer weniger wird, steigt die dann auf einmal wieder an.
Wenn man sein Modell dann noch nicht im Blick hat, steigt dann langsam der Puls.

22:41 ,Sa 30. Sep 2017,

Bei Google Map in die Einstellungen : Offline Karten... Dort großzügig den Bereich auswählen (lieber eine größere Flach als zu klein) und dann downloaden.... Das File ist nicht so groß... Bevor die Karte verfällt, kommt eine Popup Meldung zur Verlängerung

18:16 ,So 1. Okt 2017,

Ich habe noch ein Script gefunden,
welches so einen Richtungspfeil eingebaut hat.
In der Simulation schon ganz gut, ich müßte es mal fliegen, um zu sehen was es kann.
https://github.com/iNavFlight/LuaTelemetry

18:58 ,So 1. Okt 2017,

Bin schon dabei ein anderes Script anzupassen und einzuphasen :
Ist etwas komplizierter, da hier der Pilot in der Mitte steht, die Pfeilspitze das Heading anzeigt und dies "räumlich" noch angezeigt wird.
Fand ich persönlich schöner

Gefunden habe ich es hier:
https://github.com/Clooney82/MavLink_Fr ... Y/main.lua

und so schaut es immo auf dem Simulator aus:

Derzeit bin ich daran, das es flexibel sich in die Menüstruktur einfügen läßt .... dann dürfte es auch mittig stehen und die mittlere Trennlinie weg sein ( hoffentlich)

21:23 ,So 1. Okt 2017,

Ich muß echt sagen, das Du das gut hin bekommst.
Vielleicht hast Du später mal Lust das ein wenig zu erklären.
Mittlerweile verstehe ich da nur noch Bahnhof, bzw. wenn ich gerade ungefähr verstanden habe, was Du gemacht hast,
legst Du schon wieder nach....

22:09 ,So 1. Okt 2017,

In der Mitte von dem "Fadenkreuz" ist dein Standort, wo der Kopter gearmt wird.
An der Stelle werden die Koordinaten und das Heading gespeichert. Also wohin die Nase schaut.
Aufgrund der reinkommenden Koordinaten und dem Heading wird dann der Pfeil um die Mitte rechts, links, davor oder dahinter gezeichnet in Abhängigkeit der vorher gespeicherten Koordinaten (vom Armen). Das Heading beeinflusst die Pfeilspitze, fliegst du auf dich zu, zeigt die Pfeilspitze auf die Mitte...
So sollte es funktionieren, wenn es mal läuft.
Im Moment kann ich es schon dynamisch verschieben (so wie andere Widgets auch. Ich mu nur noch eine Mittellinie entfernen bzw nicht zeichnen lassen, da das Widgets eine doppelte Größe einnimmt und noch ein wenig zwecks der Schönheit nach links schieben.
Dann sollte ich mal um mein Heading kümmern... sonst kann ich es nicht vor Veröffentlichung testen.
Ein wenig Code Bereinigung muss ich dann auch noch durchführen, so dass nicht unnötige Variablen global mitlaufen und überflüssiger Code (als Gedächtnisstütze und Test) enthalten sind.

16:11 ,Mo 2. Okt 2017,

Ich habe gerade festgestellt, das sich bei mir im Sensor Tmp1 beim Armen die Zahl in 5 ändert und nicht auf 4. ( Betaflight 3.1.6 )
Kann das jemand bestätigen? und wenn nein: Welche Version ?

18:07 ,Mo 2. Okt 2017,

Hi,

gerade bei INAV 1.7.3 nachgeschaut:
Disarm: 10011
Arm: 10015

Gruß
Stefan

22:54 ,Mo 2. Okt 2017,

Danke.... habe im Script nun auch die 5 ausgewertet;
muss jetzt noch einen Rechen/logikfehler suchen: der Pfeil fliegt mir aus dem Quadrat raus

... Jedoch nur wenn der Kopter gearmt wird und der Offset berechnet wird. Ansonsten schaut es für den ersten Wurf schon gut aus... (OK von einigen Scripterrors auf der Funke abgesehen)

09:54 ,Mi 4. Okt 2017,

Weiß jemand wie das mit dem Byte für das Armen funktioniert?
Genauer gefragt:
wie verhält sich das Ganze, wenn ich arme und das Bit auf 5 gesetzt ist und ich habe einen Verbindungsverlust und kurz danach kommt die Verbindung wieder zustande? Oder der Kopter geht aufgrund von Funkverlust in den FS.
Bleibt das das Byte auf 5 oder wechselt dies?
Hintergrund ist, das den Homepunkt jedesmal beim Armen neu setzen möchte.. Da das GPS mit den Hohenangabe etc. doch recht schwankt bis es mal stabil ansteht.
Im Moment muss ich das Modell wechseln und wieder zurück oder die Funke ein und ausschalten um den Wert neu zu setzen ( Hardcore zur Sicherheit

)

KOPTERFORUM . AT

Taranis Lua Telemetry Script für OpentX ab 2.2.0 / 2.2.1 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Re: Taranis Lua Telemetry Script für OpentX 2.2.0 : Änderungen, Erweiterungen ...

Letzte Beiträge: