S'il dit vrai (et vos observation vont dans ce sens), cela va complètement dans le sens d'une des hypothèses que j'avais avancées :
En ouvrant par le fond, un paquet de fils, plus ou moins rangés serrés par un ruban collant, apparaît. Le fait de toucher ou même d'approcher certains de ces fils peut provoquer des perturbations fortes du signal quand l'anomalie est (aléatoirement) présente. Comme s'il y avait parasitage par influence mutuelle, ou sensibilité à des champs électrostatiques extérieurs...
Je confirme : quand il est en défaut, il suffit d'approcher la main du manche pour voir évoluer le signal RZ (torsion).
Le fait qu'un potentiomètre puisse se charger comma ça est curieux et anormal. Jamais vu ça (en tous cas, pas pour un circuit de potentiomètre). Circuit trop bien isolé de la masse ? Ampli à trop haute impédance ? Défaut de conception, en tous cas.
J'espère que le T16000M est moins galère à démonter et remonter que le T.Flight Stick X. C'est possible, car un des croches-pieds avec le T.Flight était un bouton eu haut et derrière, qui se démantibulait avec son circuit au démontage et qui faisait casser les soudures. Il n'y pas ce bouton sur le T16000M. Une autre difficulté était la remise en place correcte du ressort en torsion. Il vaut mieux observer avant si possible, pendant qu'il est en place.
Démontage du T16000M (toucher le potard ? peut-être au mieux un contournement temporaire mais pas une solution).
Potentiomètre(s) CTS, d'après ce forum, linéaire, voir 100 kOhm, en accord proche pour les dimensions (mais la cause me semble résider ailleurs...).
]]>http://www.jeuxvideo.com/forums/42-3000 … 16000m.htm
Cela a marché pour moi juste avant le renvoi et je viens donc d'en recommander un.
Bien cordialement.
GR
Il n'est pas sûr que ce soit un problème matériel ou d’incompatibilité.
Comme dans cette discussion. Petite difficulté avec les JS branchés les uns dans les autres, il faut trouver les axes et configurer correctement les numéros dans le fichier FG xml de configuration.
Le côté pas sympa est que le demandeur du Gladiator (MikeSky) n'a pas donné suite, pas de retour sur son éventuelle résolution du problème.
D'ailleurs, son palonnier fonctionne s'il est branché à part, sur son propre port USB.
Et tous les axes fonctionnent vus par le contrôleur de JS (celui de Windows, je suppose).
Ces deux liens sont très intéressants bien qu'un peu inquiétants. Je crains alors de tomber sur un autre genre de problème. Il faut toutefois que je me décide car après encore des échanges avec Thrustmaster qui m'a dit que cela n'était pas réparable et qui m'a renvoyé vers le vendeur (amazon en l'occurence). Ce dernier a accepté le remboursement et je viens de retourner le matériel. Donc pas de vol possible sauf avec le Sidewinder qui est quand même bien défaillant ce qui est normal vu son grand age (15 ans).
Il est vrai que sur le net il est surtout question de la version pro du joystick MKV mais cette version est bien plus chère, la version standard qui m'interesse étant à moins de 100 USD (pour le moment).
Bien cordialement et merci encore pour ce retour.
GR
Du côté du forum US en recherche rapide, je ne trouve que peu de choses et mal adaptées.
Joystick Gladiator MKII cause FG crash (sur Mac OS)
VKB Gladiator MKII with t-rudders (Windows 10, avec palonnier séparé)
Il faudrait peut-être chercher mieux, j'ai en souvenir une discussion plus générale sur le retour d'information avec les JS, mais je n'ai pas retrouvé facilement.
[EDIT] J'ai trouvé. Your joystick(s) and how well they work with FlightGear. Mais... non pour Gladiator . [/EDIT]
Effectivement, le Gladiator Mk.II est donné pour X, Y, Z sans contacts. Capteurs magneto-resistifs (différemment des autres JS à effet Hall).
]]>PS les modifications proposées par Dany93 ont très bien marché pour le SideWinder mais l'ergonomie du couple (T16000M, Sidewinder) ne me convient pas.
]]>J'ai modifié le "setting" dans l'arbre des propriétés et ai mis 0
Je ne suis pas sûr d'avoir bien compris. Si tu modifies la valeur rudder par controls/flight/rudder , 0 , "set", tu cherches à régler une valeur qui est en fait normalement imposée par le joystick. Au premier mouvement du JS, ta valeur sera écrasée. C'est le dernier qui a raison.
Si tu modifies des valeurs dans l'arbre des propriétés, c'est :
- soit non pris en compte, si ces valeurs sont imposées par ailleurs (ici, rudder par le JS)
- soit seulement pour la session en cours (exemple : une valeur de trim).
Un décalage de -0.00783 est vraiment faible, cela ne devrait pas être très gênant. Même pour le c172p qui a bien d'autres raisons de tirer d'un côté ou de l'autre (plutôt à gauche). Chez moi, cela ne fait même pas tourner l'UFO. Mais c'est probablement compensable.
jstest-gtk ("Calibration") devrait permettre en principe de compenser ce décalage, mais je ne sais pas comment. Par la calibration automatique ? De plus, lors de mes essais avec un JS déficient, j'ai trouvé qu'il était buggé et qu'il ne conservait pas les réglages que j'avais entrés d'un boot à l'autre, malgré sauvegarde.
Peut-être en ligne de commande ? Mais ce n'est pas moi qui te le dirai.
jscal semble meilleur (à installer contenu dans "joystick") mais je ne peux pas t'en dire plus. Il me semble le mieux adapté à ton anomalie (lire "Calibration"). Voir aussi jscal, jstest.
Aussi http://fr.flightgear.tuxfamily.org/wiki … flightgear ("Calibration").
L'intérêt est que ces compensations se font en amont, sur le JS. L'offset serait logiquement fait en amont sur l'output du JS par rapport à sa position physique, donc sur l'input pour FG, ce qui laisserait plus d'espoir (?? à essayer...) pour conserver la symétrie de l'output sur la course. De plus, la correction ainsi faite en amont serait valable quel que soit le fichier de configuration du JS.
Différemment, l'offset FG est fait sur l'output FG, après élévation de l'input au carré. L'input n'étant pas à zéro au repos, cette compensation par FG ne corrige pas le défaut à la racine, elle ne peut pas corriger une dissymétrie du signal sur la course totale du JS.
Un autre avantage est que ces calibrations du JS sont valables quel que soit le simulateur.
Le plus simple à essayer, bien qu'imparfait, est dans ton fichier de configuration du rudder, ajouter une valeur d'offset :
<desc>Rudder</desc>
<binding>
<command>property-scale</command>
<property>/controls/flight/rudder</property>
<factor>1.0</factor>
<offset>0.00783</offset>
<power type="double">2.0</power>
</binding>
Mais cela ne compense pas l'effet d'une perte de course maxi à une extrémité.
Cependant, je ne suis même pas sûr que jscal corrige cette dissymétrie.
Attention : D'après le Wiki Property-scale dans sa rédaction antérieure (à mon avis, c'est une erreur), l'offset s'entend avant application de factor et power.
((property+offset)*factor)^power=result
(j'ai corrigé ce point dans le Wiki car je pense fortement que c'était une erreur)
On aurait (d'après mes observations), et ceci est confirmé par rominet dans Calibrating a joystick on linux
[(property^power) + offset] * factor = result
Tu lis -0.00783 pour le rudder avec <squared type="bool">true. Si je comprends bien, l'offset en input (avant élévation au carré) est donc de l'ordre de -0.0885 pour ton JS.
Pour contrôler l'effet, il te faudra peut-être manipuler le JS après démarrage du simulateur.
Pour les essais, tu peux contrôler l'effet d'une post-modification dans ton fichier JS par Debug > Reload Input (sans relancer le simulateur)
Personnellement, j'ai configuré le "hat" et deux de mes boutons JS pour régler aileron trim, elevator trim, rudder trim. C'est de la triche avec certains avions pour aileron et rudder trims mais en simulation, avec nos JS à ressorts, c'est plus confortable. Surtout pour aileron trim, car je ne me sers presque jamais du rudder trim (sauf ponctuellement pour le P51D quand il était en cours de réglage).
]]>Au neutre mon sidewinder n'indique pas 0 pour le rudder mais -0.00783. J'ai modifié le "setting" dans l'arbre des propriétés et ai mis 0 mais cela n'a pas été pris en compte au cours de cette session ; il y a toujours -0.00783 au bas du panneau joystick (ce qui peut être normal) mais surtout le comportement n'a pas changé. En fait cela n'est vraiment gênant que pour des appareils du type c172 et l'est beaucoup moins pour le citationX ce qui est également normal.
Peut être (surement) y a t'il autre chose à faire pour annuler ce décalage initial du sidewinder ?
Bien cordialement
GR
Certes quelques ajustements sont encore à faire notamment pour ne pas trop dévier le nouvel axe "rudder" étant au neutre
Si ton rudder SideWinder donne la valeur 0 au neutre, il ne devrait pas y avoir de différence.
]]>Effectivement ta solution sur laquelle je n'avais pas rebondi, car ne pensant pas pouvoir utiliser à nouveau d'aussi vieux matériels, est excellente. J'ai branché mon vieux sidewinder qui est bien reconnu par FG et n'est gardé que la manette des gaz et l'axe aileron que j'ai alors affecté au rudder et cela marche très bien sans que j'ai eu besoin de créer un nouveau fichier de configuration. Certes quelques ajustements sont encore à faire notamment pour ne pas trop dévier le nouvel axe "rudder" étant au neutre.
Bien cordialement
1- Freins différentiels :
, (virgule) = Apply left brakes
. (point) = Apply right brakes
Keyboard shortcuts
Sauf si l'avion est configuré pour désactiver ces touches.
2- Tu n'as pas réagi à cette suggestion :
Maintenant, pour toi, il y aurait peut-être moyen de faire commander ton axe Z (palonnier) par un autre JS et d’utiliser ton T16000M pour le reste. Pour profiter des axes X et Y à effet Hall.
Dans tes joysticks au rencart, tu dois bien en avoir un avec un axe qui permettrait d'aller de droite à gauche, non ? (il suffit qu'il aille de -1 à +1).
On fait un fichier de configuration de 10 à 15 lignes contenant son nom et le bon numéro d'axe, et c'est tout.
L'inconvénient est que ça t’occupe les deux mains dans les phases critiques, pour les gaz il reste les dents... . Et il faut de la place.
Pour le roulage, tu peux aussi utiliser la souris en mode pilotage pour commander le palonnier (clic gauche maintenu), mais ce n'est pas vraiment pratique car elle est censée servir aussi à autre chose.
3- Autre solution, plus chère mais avec laquelle tu gagnerais en qualité de pilotage :
Et pour le même ordre de prix, un palonnier ? Tu utiliserais ton T16000M pour les axes X et Y, en désactivant le Z.
C'est la solution que j'utilise depuis longtemps (pour des raisons de réalisme à l'origine, j'ai même acquis un palonnier avant d'avoir un joystick).
]]>Je reviens sur ce sujet car après une bonne semaine avec un axe Rz redevenu normal (pourquoi ?) le problème est revenu à l'identique. Je peux bloquer cet axe sur le neutre et désactiver l'axe rudder du joystick et ai ensuite envisagé d'utiliser les freins différentiels pour le taxi. Cette méthode marche sous XP (mais ce n'est pas terrible). Je n'ai pas trouvé un équivalent sous FG tout au moins dans le panneau standard. Je suis sûr qu'il y a des solutions à essayer avant d'envisager sérieusement le choix d'un nouveau matériel, choix que je sens difficile compte tenu des réponses précédentes et de mes investigations sur le net.
Bien cordialement.
Effectivement même dans les HOTAS, Warthog et consorts entre 250 et 400 euros soit il est précisé que seuls les axes x et y sont concernés par le mécanisme sans contact, auquel cas il n'y a pas d'ambiguité, soit il est dit axes sans contact (d'où mon intérrogation). Dans la catégorie des modèles professionnels il y en a pas mal avec les 3 axes sans contact mais 1) les prix ne sont pas indiqués et 2) surtout je n'en ai pas trouvé à vocation simulateur de vol. Je sais qu'il en existe pour les simulateurs réels utilisés pour la formation mais alors il est probable qu'ils ne seraient pas reconnus par la famille (FG, FSX, XP, ...) si tant est qu'ils soient disponibles sur le marché.
Bien cordialement.
Et pour le même ordre de prix, un palonnier ? Tu utiliserais ton T16000M pour les axes X et Y, en désactivant le Z.
]]>