FRSKY FrSky TARANIS - FrSky neuster Geniestreich - 16 Kanaele, 2,4Ghz, openTX, 8 Sprachen

Wowbagger

Erfahrener Benutzer
Das ist ja erst das Anpassen der realen Servolaufrichtung. Aber laut helle soll man in den Mischern immer so arbeiten: Positiver Mischwert=>Ruder nach oben/rechts. Also immer gleiche Mischermathematik, egal wie das Servo läuft/eingebaut ist. Wenn dann das Servo falsch rum läuft, dann wie in Deinem Screenshot die Richtung invertieren, klar.
 

helle

Erfahrener Benutzer
Hy,

je nach Komplexität ist das egal wo man invertiert, aber am tut sich leichter es gleich am Knüppelsignal zu machen.

Damit das "System" passt muss/soll der Höhen-Knüppel beim ziehen positive Werte abgeben.
Der Knüppel gibt aber beim ziehen negative Werte ab!

Deshalb in den Inputs den Höhenruder-Knüppel invertieren (-100%) dann stimmt alles in der nachfolgenden Mischer-Logik und ist wieder Positiv

Früher (vor Taranis) gab es keine Inputsverrechnung, da nahm man eben einen freien Kanal zum Höhenruder-Knüppel Inputs invertieren (Th9x und 9XR haben keine Inputsverrechnung!)
und rechnete dann mit dem CHx-INV weiter.

Das ist also mehr ein "einheitliches systematisches Vorgehen" und ich kann alles mischen und simulieren ohne auf die reale Servorichtungen im Modell achten zu müssen.

Helle
 
Zuletzt bearbeitet:

Wowbagger

Erfahrener Benutzer
Damit das "System" passt muss/soll der Höhen-Knüppel beim ziehen positive Werte abgeben.
Genau an der Stelle finde ich das System inkonsequent. Denn ich würde sagen:
Knüppel oder Ruder hoch/rechts = positiver Wert.
Dann ist alles völlig konsistent (siehe auch linkes Querruder)

Wenn ich für den Höhenknüppel die Ausnahme mache (nach hinten ziehen=positiv), dann habe ich keine durchgängige Regel mehr, sondern eben eine Ausnahme. :)
Gas-Knüppel ist ja auch nach hinten ist negativ.

Logisch, das ist alles eher philosophisch, aber mir fiel das besonders auf, weil Du ja zu Recht in der Anleitung sehr oft schreibst: positiver Wert=Ruder oben/rechts.

Deshalb in den Inputs den Höhenruder-Knüppel invertieren (-100%) dann stimmt alles in der nachfolgenden Mischer-Logik und ist wieder Positiv
Also ist es korrekt, dass man nun schon in den Inputs invertieren kann und der entsprechende Teil in der Anleitung einfach noch für eine alte Version?

Das ist also mehr ein "einheitliches systematisches Vorgehen" und ich kann alles mischen und simulieren ohne auf die reale Servorichtungen im Modell achten zu müssen.
Ja, das verstehe ich. Nur eben, welchen Vorteil es haben soll, nur für den Höhenruderknüppel eine Ausnahme zu machen, verstehe ich nicht.

BTW, sobald ich in Companion den Input für den Höhenruderknüppel aufrufe, "zerstöre" ich mir die Konfiguration. Ich tippe da auf ein Umlautproblem. Es steht dort:
[I2]H?h Gewichtung(100%) Quelle(Höh)
Wenn ich den Input aufrufe, ist auch alles in Ordnung, unter Quelle steht das Popup auch auf Höh. Sobald ich auf OK gehe sieht die Zeile so aus:
[I2]H?h Gewichtung(100%) Quelle(----)
Auch in anderen Inputs kann ich die Quelle Höh zwar im Popup auswählen, beim Speichern wird das aber nicht übernommen und auf ---- geändert.
Companion 2.0.8 unter OS X 10.8.5
 

helle

Erfahrener Benutzer
Hy

du must auf die Mischer blicken.
Dort hast du Eingangs- und Ausgangsinale zu verrechnen.

Ein Mischer-Beispiel

HöhenKnüppel Inputs invertiert (also -100%)


Kanal Mischer für das Höhenruder
1. Zeile Gewichtung +60% normale Höhnenruderfunktion, positive Mischer-Werte, positives Ruder
2. Zeile Gewichtung -15% Gaskorrektur, wenn ich Gas geben zieht er nach oben weg, ich muss nach unten korrigieren
3. Zeile Gewichtung +20% Landklappenkorrektur, wenn ich die Landeklappen setzte muss ich Höhen geben

Somit ist alles im Mischer korrekt verrechnet.

-------------

Das "ö" Sonderzeichen kann nicht dargestellt weden,
da kommm dann ein "?" oder ein "_"

Es gibt in openTX fertigen Auswahltext, dort ist das "Höh" schon fest hinterlegt.
Ich weiß das verwirrt mal als "Höh" mal als "H?h" dargestellt.

Ein "---" habe ich aber noch nicht gesehen.

Helle
 
Zuletzt bearbeitet:

Wowbagger

Erfahrener Benutzer
Du missverstehst mich. Dein Beispiel und die Verrechnung im Mischer sind völlig klar und logisch: positiver Mischerwert=positives Ruder (hoch/rechts)

Mein "Problem" sitzt an der anderen Stelle.
Du definierst: Beim Ziehen (nach hinten) muss der Höhenknüppel positive Werte abgeben. Da ist der Knackpunkt. Warum muss oder soll er da von den anderen Knüppeln abweichen? Alle Knüppel liefern: positive Knüppelbewegung (hoch/rechts)=positiver Eingangswert. Also völlig analog. Nimmt man das, hat man zwei feste goldene Regeln, die konsistent sind:
- positiver Knüppel (hoch/rechts)=positiver Wert
- positives Ruder (hoch/rechts)=positiver Wert
Man braucht dann keine zusätzliche Ausnahme für den Höhenruderknüppel ("runter ziehen" soll positive Werte liefern).

Ich weiß, das ist alles ein philosophisches Problem. Aber für mich vereinfacht sich die Programmierung dann schon (weniger Regeln/Ausnahmen).

Die Frage ist eben: Warum soll der Höhenknüppel beim Ziehen positive Werte liefern (beim Input, nicht als Mischerausgang!), anders als alle anderen Knüppel.

Das "ö" Sonderzeichen kann nicht dargestellt weden,
da kommm dann ein "?" oder ein "_"

Es gibt aber auch fertigen Auswahltext, dort ist das "Höh" schon fest hinterlegt.
Auch hier missverstehst Du mich. Das das ? ein ö mit Umlautproblem ist, ist klar. Komischerweise wird aber eben bei der Quelle wirklich das ö geschrieben (s.o.). Sobald man aber den Inputdialog verlässt und Höh als Quelle im Popup ausgewählt hat, wird das nicht übernommen. D.h. beim Speichern der Werte eines Inputs ist ein Fehler. Vermutlich auch umlautbedingt.
 

helle

Erfahrener Benutzer
Hy,
das companion-Problem werde ich heute Abend mal testen,
ist mir bisher nicht ausgefallen.
-----------------

Mein Ansatz sind nicht die Eingangssignale selbst, sondern die Mischerverrechnung.

Die Mischerverrechnung soll immer korrekt sein.

Mein Obiges Beispiel (Höhe -100% invers, minus*minus= plus) führt bei max Signalen zu
+60 -15 +20= +65% pos. Mischerwert = pos. Ruderwert

wenn ich die Höhe nur im Mischer invertiere kommt das raus
-60% -15% +20% = -55% , das wird jetzt echt falsch berechnet!

ich muss dann alles drehen damit es wieder passt.
-60% +15% -20% = -65% , jetzt habe ich ein negatives Mischerergebnis
jetzt hilft nur noch im Servo zu invertieren dann kommt +65% als Ruderwert raus

Bitte mal simulieren

Helle


Helle
 
Zuletzt bearbeitet:

flying_pit

Geht nicht..gibt´s nicht!
moin, ich verstehe eure Diskussion nicht ganz.... :) , alle meine früheren Sender liefern wenn ich Höhenruder ziehe positive Werte, das Ruder geht hoch..wäre ja auch fatal wenn das andersrum wäre..damals...grins....Helle sagt nun, bei der Taranis wird aber beim Höhe ziehen ein negativer Wert vom Knüppel geliefert, warum auch immer, hab meine Taranis grad nicht zur Hand da auf Arbeit..:), aber ich glaub da mal Helle. Also sollte, aus Kompatibilitätsgründen..die Taranis beim ziehen am Höhe-Knüppel, so wie bei allen anderen Sendern auch, positiv liefern....right!? UND DAS kannst DU ja gleich am Knüppel ändern..wie beschrieben, also nun liefert der Höhe-Knüppel der Taranis, positives Signal und alles ist gut!
das mit dem GAS ist schon korrekt, denn GAS hinten also im negativen, bedeutet nunmal leerlauf..(also bei vielen.bei mir isses umgedreht, aber aus anderen Gründen)..und höhe ist nunmal schon immer ..ziehen..hoch...positiv.... da sehe ich keine Ausnahme sondern Standart.

Natürlich könnte man auch das Kabel am poti vom Höhe Knüppel umfriemeln , dann hättest DU auch standartmäßig HÖHE ziehen, positiv....aber wer macht sich denn die Arbeit??? Wozu haben wir denn nun so ein offenes System!?

Frsky macht das mit den GAS/Höhe Knüppel bestimmt wegen der MODE Umstellung. Also GAS rechts oder links. verstehst!?
:eek:
 
Zuletzt bearbeitet:

Wowbagger

Erfahrener Benutzer
Die Mischerverrechnung soll immer korrekt sein.
Genau. Und das ist sowohl bei Deiner als auch meiner Methode so. Der Unterschied ist einzig und allein: Liefert der Höhenruderknüppel entsprechende Werte wie alle anderen oder soll er beim Ziehen positive Werte liefern. Das und nur das ist der Knackpunkt.

Zu Deinen Beispielen. Mit "max. Signale" meinst Du "alle Eingangswerte +100%", d.h.
- bei Dir= voll Höhenruder ziehen, voll Gas, voll Landeklappe.
- bei mir= voll Tiefenruder drücken, voll Gas, voll Landeklappe.
Das dann bei den Formeln unterschiedliche Sachen raus kommen, ist klar und sogar richtig.

Zur Demonstration:
- Deine Gewichtungen (Höhe -100% invers): +60% -15% +20%
- Meine Gewichtungen: -60% -15% +20%

"max. Signale" bei Dir=voll Höhenruder ziehen, voll Gas, voll Landeklappe
- ergibt bei Dir (Höhenknüppel liefert positiv beim Ziehen): (60%*100%) + (-15%*100%) + (20%*100%) = +65%
- ergibt bei mir (Höhenknüppel liefert negativ beim Ziehen): (-60%*-100%) + (-15%*100%) + (20%*100%) = +65%
Funktioniert also identisch.

"max. Signale" bei mir=voll Tiefenruder drücken, voll Gas, voll Landeklappe
- ergibt bei Dir (Höhenknüppel liefert positiv beim Ziehen): (60%*-100%) + (-15%*100%) + (20%*100%) = -55%
- ergibt bei mir (Höhenknüppel liefert negativ beim Ziehen): (-60%*100%) + (-15%*100%) + (20%*100%) = -55%
Funktioniert also identisch.

Es ist wirklich die reine Definition: Bei welcher Bewegung des Höhenknüppels liefert er positive Werte.

ich muss dann alles drehen damit es wieder passt.
-60% +15% -20% = -65% , jetzt habe ich ein negatives Mischerergebnis
jetzt hilft nur noch im Servo zu invertieren dann kommt +65% als Ruderwert raus
Das ist natürlich unsinnig, da hast Du Recht. Die anderen Werte dürfen nicht geändert werden, denn positiver Mischerwert=Ruder nach oben.

Ich kann mir schon vorstellen, woher dieser Wunsch nach "Knüppel ziehen=positiver Inputwert" kommt. Wenn es so ist, dann ist das allereinfachste Modell in den Mischern:
CH1 (Quer rechts)= 100%*Querinput
CH2 (Höhe)= 100%*Höheinput
CH3 (Seite)= 100%*Seiteinput
CH4 (Motor)= 100%*Motorinput
Also im Endeffekt der Wunsch, dass ein reines Durchreichen der Inputs positive Ruderbewegungen erzielen soll.
 

Wowbagger

Erfahrener Benutzer
alle meine früheren Sender liefern wenn ich Höhenruder ziehe positive Werte, das Ruder geht hoch..
Das kann schon sein, das habe ich nie gemessen. :)
Aber wegen einer möglichen Modeumstellung müssten die eigentlich auf beiden Knüppeln identische Werte liefern. Falls dann dort trotzdem positive Werte beim Ziehen auftauchen, dann haben die intern wieder mal versteckte Berechnungen dafür.
Da es dort ja keine so simple und vernünftige Mischermathematik wie bei der Taranis gab, habe ich mich nie um die Werte gekümmert. Knüppel ziehen-> Ruder läuft richtig, gut, Ruder läuft falsch, dann Servo invertieren.

wäre ja auch fatal wenn das andersrum wäre..damals...grins
Nö, eigentlich nicht, denn auch da musste man wie bei der Taranis, die reale Servolaufrichtung entsprechend Servo und Einbaurichtung etc. anpassen. Wer natürlich einbaut und keinen Rudercheck macht und nur auf positive Werte vertraut... :)

Helle sagt nun, bei der Taranis wird aber beim Höhe ziehen ein negativer Wert vom Knüppel geliefert, warum auch immer, hab meine Taranis grad nicht zur Hand da auf Arbeit..:), aber ich glaub da mal Helle.
Ja, das ist so. Bei der Taranis gilt für alle Knüppel: hoch/rechts=positive Werte

Also sollte, aus Kompatibilitätsgründen..die Taranis beim ziehen am Höhe-Knüppel, so wie bei allen anderen Sendern auch, positiv liefern....right!?
Nein, genau das ist der Knackpunkt. Warum soll man den Vorteil der Taranis (simple Berechnungen, alles konsistent) aus "Kompatibilitätsgründen" mit einer Ausnahme versehen? Ich übernehme doch eh keine Mischerdefinition von einer anderen Anlage.

und höhe ist nunmal schon immer ..ziehen..hoch...positiv.... da sehe ich keine Ausnahme sondern Standart.
Jein. Beim Höhenknüppel haben wir historisch bedingt aus dem manntragenden Bereich den Fall:
- Knüppel runter=ziehen=Ruder hoch
- Knüppel hoch=drücken=Ruder runter
Daher ist "schon immer" Knüppel hoch=Ruder runter und daher gewünscht Knüppel hoch soll negative Wirkung sein.
BTW kenne ich einen Piloten der Höhenknüppel genau anders herum fliegt. Er hat sich als Jugendlicher das Fliegen alleine beigebracht und damals gedacht: Knüppel hoch=Flugzeug hoch, Knüppel runter=Flugzeug runter. Du siehst, das ist nur eine Frage der Definition bzw. Historie.

Einfach finde ich:
Knüppel hoch/rechts oder Ruder hoch/rechts=positiv

"Komplizierter" finde ich:
Knüppel hoch/rechts oder Ruder hoch/rechts=positiv
mit Ausnahme Höhenknüppel runter=positiv
 

flying_pit

Geht nicht..gibt´s nicht!
grins..ich glaub das entwickelt sich hier zu einer reinen Diffinitionsfrage!

Nochmal, beim Fernsteuersender kann ich GAS links oder rechts kaufen, je nach Steuergewohnheit! Und GAS ziehen ist nunmal standartmäßig negativ weil Leerlauf (ich fliege GAS ziehen positiv beim HUBI weil ich es so vom manntragenden gewohnt bin, ziehen..GAS+PITCH..positiv) aber das tut hier nix zur Sache.

Wenn ich nun die MODE umstelle, hab ich ein Dilemma , was mach ich wenn ein Kunde GAS rechts hat? dann hat er halt rechts beim ziehen am knüppel, negativen Wert weil GAS hinten = Leerlauf. dann ist Links das Höhenruder, wieder das gleiche Problem, wenn ich Höhe ziehe kriege ich negative Werte (da ja auch links GAS sein könnte) verstehst Du??? Früher haben wir dann einfach die Servolaufrichtung umgekehrt..das jedoch wollen wir hier ja am Anfang gerade nicht tun!!
Da aber beim ziehen das Ruder nach oben gehen soll....brauch ich positiven knüppel!!! Und nun ist es egal ob GAS links oder rechts, also MODE 1 oder 2 geflogen wird, ich muss/sollte das Höhenrudersignal am Knüppel auf positiv stellen damit nachfolgend alles weiterhin..easy geht! Und das muss/sollte ich dann bei Höhe links oder rechts gleichermaßen tun.

eigentlich ganz einfach oder!?
 
Zuletzt bearbeitet:

DerCamperHB

Erfahrener Benutzer
Früher (vor Taranis) gab es keine Inputsverrechnung, da nahm man eben einen freien Kanal zum Höhenruder-Knüppel Inputs invertieren (Th9x und 9XR haben keine Inputsverrechnung!) und rechnete dann mit dem CHx-INV weiter.
Das haste aber ganz falsch in Erinnerung Den Blödsinnigen Inputverarbeitung auf der Input Seite haben die nicht, braucht auch keiner, die Invertierung über Negativen Prozentwert hatte schon die Ur-Thus Version gehabt
 

Wowbagger

Erfahrener Benutzer
Wenn ich nun die MODE umstelle, hab ich ein Dilemma , was mach ich wenn ein Kunde GAS rechts hat? dann hat er halt rechts beim ziehen am knüppel, negativen Wert weil GAS hinten = Leerlauf. dann ist Links das Höhenruder, wieder das gleiche Problem, wenn ich Höhe ziehe kriege ich negative Werte (da ja auch links GAS sein könnte) verstehst Du???
Eben, genau das schreibe ich ja. Weil es konsistent ist, ist Knüppel hinten negativ, Knüppel vorne positiv. Genau das!

Da aber beim ziehen das Ruder nach oben gehen soll....brauch ich positiven knüppel!!!
Nein, Du brauchst dann positiven Mischerwert=positives Ruder!
Eben, da man diese Richtung (historisch aus dem Kanntragenden übernommen) so haben will, muss der Wert intern mit -100% verrechnet werden. Genau das!

Falls die alten Sender da immer positive Werte liefern, dann haben die da versteckt Berechnungen drin. (Diese versteckten Berechnungen in den alten Anlagen machen ja oft Probleme, siehe helles Handbuch)
 

Wowbagger

Erfahrener Benutzer
Zum Companion:

neues leeres Modell angelegt:
Bildschirmfoto 2014-08-25 um 16.48.53.png

Höhenknüppelinput aufgerufen:
Bildschirmfoto 2014-08-25 um 16.49.10.png

OK geklickt:
Bildschirmfoto 2014-08-25 um 16.49.24.png

Sobald ich einen Input bearbeite, kann dieser kein Höh mehr enthalten, da das nicht übernommen wird.
Falls es bei Dir funktioniert:
Ich nutze Companion 2.0.8 auf OS X 10.8.5 und Du glaube ich Linux, oder?
 

flying_pit

Geht nicht..gibt´s nicht!
Hy,

je nach Komplexität ist das egal wo man invertiert, aber am tut sich leichter es gleich am Knüppelsignal zu machen.

Damit das "System" passt muss/soll der Höhen-Knüppel beim ziehen positive Werte abgeben.
Der Knüppel gibt aber beim ziehen negative Werte ab!

Deshalb in den Inputs den Höhenruder-Knüppel invertieren (-100%) dann stimmt alles in der nachfolgenden Mischer-Logik und ist wieder Positiv

Helle
genau das meine ich...so wäre der einfachste weg.

Prio hat GAS, Höhe hat sich unterzuordnen, bei diesem Sender! Umgedreht wäre es wenn Frsky die Knüppel Aggregate so gebaut hätte das beide Knüppel beim ziehen positive werte leifern, standartmäßig. Dann hätten wir jetzt die Diskussion nicht mit Höhe sondern mit GAS. Höhe wäre Prio, GAS müsste sich unterordnen. Genauso war es früher mit den alten Sendern, GAS musste ich anpassen, stand in (fast) jeder Betriebsanleitung! :eek:
 

DerCamperHB

Erfahrener Benutzer
Helle du hast den gleichen Fehler wie ich mit 2.04 Sobald Höh aufgerufen wird, verliert der Input 4 seinen Namen, bei mir "Gas" bei dir "Sei" und bekommt "Input4" als Namen Wird der Name dann per Hand geändert, wird aus Höh dann Höhgas, und aus Input4 gas, also der Name wird Doppelteingetragen
 
FPV1

Banggood

Oben Unten