Forum Flightgear France

Une communauté prend son envol

Vous n'êtes pas identifié(e).

Annonce

Futur nouvel inscrit, tu dois au préalable lire l'intégralité des 10 articles des règles, s'il te plaît. Tout nouveau compte qui ne respecte pas les règles sera supprimé par l'administration.

#1 8/02/2020 22:57:11

GR
Membre
Inscription : 28/01/2019
Messages : 209

T16000M : retour d’un problème matériel

Bonsoir,

Il n’est pas trop tard pour vous souhaiter une bonne et heureuse année 2020 et vous remercier encore pour votre disponibilité et réactivité dans le cas de problème pas forcément toujours liés à FG.

Je reviens donc vers vous pour un problème du même type que celui qui m’a pris la tête le printemps dernier : mon nouveau joystick T16OOOM présente quasiment le même défaut que mon ancien Saitek X52 : blocage de l’axe Rz à mi-course vers la droite et débattement d’un seul côté ce qui rend évidemment tout pilotage impossible avec FG (comme d’ailleurs avec tout autre simulateur). Ma question est donc de savoir si une réparation est possible.

Mon ancien Saitek a duré 13 ans avant d’être inutilisable et le T16000M moins d’un an. Je ne pense pas avoir manipulé ce dernier opus de manière différente. La conclusion s’impose donc. Quels sont vos conseils avant d’acquérir un nouveau joystick. Pour le moment j’ai remis en service le SideWinder de Microsoft qui a au moins 15 ans et qui fonctionne encore à merveille !!

Bien cordialement.
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#2 10/02/2020 12:00:20

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

Bonjour GR,

J'ai eu ce genre d'ennui avec le mien. Au bout de 2 ans, alors que cet axe ne me servait que pour balayer la vue latérale (palonnier aux pieds extérieur).  Thrustmaster T.16000M et Ubuntu.
Moins franc que toi en général, mais parfois aussi extrême que toi quand même. Bruiteux au centre même parfois sans le manipuler, interaction parfois quand on manipule d'autres axes, mauvaise initialisation au démarrage (ce qui fait que c'est aléatoire).

J'ai retrouvé : tu avais pratiquement ma réponse dans Problème à venir sur le T16000M ?

Je suis maintenant à peu près certain que c'est un problème de potentiomètre Z, usé très ponctuellement au centre. Si c'est vraiment de l'usure, un coup de bombe ne fera évidemment rien. Trouver un potentiomètre de rechange n'est pas évident. De plus, (au moins souvenir du T.Flight Stick X) c'est un peu galère à démonter et beaucoup à remonter.

Ceci me confirme le côté quincaillerie de m..., conception et fabrication amateur de Thrustmaster. Se voit encore plus quand on ouvre.
Sur mon T.Flight Stick X (qui m'a quand même duré 8 ans, au prix de quelques réparations personnelles accessibles), j'ai eu plusieurs fois des ennuis avec la manette de gaz. Un concepteur au mental limité a eu l'idée géniale de faire tourner le potentiomètre entier (donc les fils.. mad) au lieu de faire tourner l'axe comme tout le monde. Donc les fils se cassaient.

Dommage, les axes X et Y à effet Hall du T16000M sont vraiment super.

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.

Rappel : la garantie légale en Europe est de deux ans. Tu as peut-être plus de chance que moi. Bien que ce ne soit pas forcément un placement d'avenir... hmm


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#3 10/02/2020 20:03:55

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Bonsoir,

Merci pour cette piqure de rappel. J'avais oublié mes débuts catastrophiques avec le T16000M. Il s'agissait quasiment du même problème. En plus cette fois il y a eu une incidence notable du mouvement d'autres axes et juste après le chargement, tout étant au repos, le moindre mouvement, juste un effleurement, du stick faisait se déclencher un bruitage au départ autour du zéro en ensuite autour d'une position excentrée droite.

Le problème est qu'aujourd'hui il n'y a plus de problème sur l'axe Rz sans aucune action de ma part (pas de soufflante, ni évidemment d'essai de démontage (j'ai vu une vidéo sur un tel démontage et effectivement cela ne donne pas envie d'essayer). Il reste un problème sur le TWCS (pas de réponse du throttle) mais FG n'est pas concerné.

Je vais peut être essayer de contacter Thrustmaster mais le mieux qu'ils pourraient me proposer est un remplacement ce qui risque de ne rien régler du tout à moyen terme. L'autre solution est de faire une recherche sur un autre matériel mais alors on change de gamme de prix : on passe de quelques dizaines d'euros à quelques centaines.

Si cela se reproduit comme c'est fort probable il me reste toujours le Sidewinder !!
Bien cordialement.


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#4 10/02/2020 20:27:04

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

GR a écrit :

En plus cette fois il y a eu une incidence notable du mouvement d'autres axes et juste après le chargement, tout étant au repos, le moindre mouvement, juste un effleurement, du stick faisait se déclencher un bruitage au départ autour du zéro (...)

J'ai eu exactement ça.
Et même, le simple fait d'approcher la main sans toucher !! Comme un effet d’électricité statique. Je pense que, le circuit électrique se trouvant "ouvert" par absence de contact au centre, la tension devient très sensible au captage de parasites externes par effet antenne.
Même effet en démontant le fond (ici, c'est facile) et en touchant le paquet de fils maintenus en vrac au ruban adhésif.

Malheureusement, comme tu dis, les autres JS à capteurs effet Hall sont nettement plus chers.


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#5 10/02/2020 21:02:06

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Bonsoir,
La présentation du nouveau X52 n'est pas très claire concernant un effet Hall sur les 3 axes : c'est sùr sur deux mais j'ai un doute sur le Rz ? L'avantage est qu'il reste abordable (entre 150 et 200 euros suivant les sites). Le prix est même comparable à l"ensemble T16000M + TWCS.
A suivre donc
Bien cordialement


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#6 11/02/2020 0:09:13

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

Je suis persuadé que l'axe Z n'est pas à effet Hall. C'est rare et ils s'en vanteraient. Ou je n'ai pas vu le "nouveau".

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.


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#7 11/02/2020 10:40:20

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Bonjour,

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.


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#8 19/02/2020 18:15:05

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Bonjour,

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.


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#9 19/02/2020 18:43:49

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

Bonjour,

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 :

dany93 a écrit :

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... tongue . 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 :

dany93 a écrit :

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).


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#10 19/02/2020 19:46:51

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Re,

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


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#11 19/02/2020 20:23:31

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

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.

Dissymétrie naturelle d'un monomoteur à hélice ?


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#12 20/02/2020 12:23:13

GR
Membre
Inscription : 28/01/2019
Messages : 209

Re : T16000M : retour d’un problème matériel

Bonjour,

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


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#13 20/02/2020 13:25:46

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 199

Re : T16000M : retour d’un problème matériel

Bonjour,

GR a écrit :

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). Mais c'est sans doute 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, malgré sauvegarde.
Peut-être en ligne de commande ? Mais ce n'est pas moi qui te le dirai.

Il y a aussi jscal (à installer contenu dans "joystick") mais je ne peux pas t'en dire plus.
L'intérêt est que ces compensations se font en amont, valables quel que soit le simulateur.

Le plus simple à essayer, pour FG, 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>

Au prix sans doute d'une très légère perte de course maxi (= l'offset) à une extrémité.

Attention : D'après le Wiki, l'offset s'entend à l'entrée (avant application de factor et power). Voir Property-scale.
Si tu lis -0.00783 pour le rudder avec <squared type="bool">true, il faudrait alors essayer <offset>0,0885. Regarder et compenser le décalage en Input. Mais les explications du wiki sont tout sauf claires et cohérentes et, aux essais, j'ai l'impression du contraire pour l'ordre de calcul du <power> et de l'<offset>... L'offset semble être appliqué juste après l'élévation de input au carré, avant le factor. Ma valeur ci-dessus de 0.00783 serait alors la bonne.
On aurait

[(inputproperty^power) + offset] * factor  = result

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)

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.


FG 2019.2.0, OSG 3.4.2, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

Pied de page des forums