Je dirais que c'est normal, tu relâches tu as le surge vers l'avant
DIY - tensionneur de harnais 2 DOF avec PTMover/simHub
-
-
ok merci étrange quand même seulement sur ams2
-
normalement tu as un filtre pour ne prendre que les valeurs d'accélérations négatives donc ça doit être dans le plugin du jeu qui envoie des g négatifs à l'accélération...
-
tu dois pouvoir vérifier en jeu en visualisant avec FlyPT en même temps : ça permettrait de savoir si c'est corrigeable et à quel niveau
-
pour mettre un (ou plusieurs) ventilo sur une arduino, il te faut une monster shield, qui sert aussi bien à des BS de type moteur vibration manette console que des ventilos....
surtout prévoir l'alim dédiée à la monster shield qui vas bien derrière
-
merci pour vos réponses je vais tester ce soir ams2 en même temps que flypt pour glaner plus d'infos, concernant le ventilo c'était pour refroidir l'éléctronique que j'ai placé dans un boitier du coup j'en ai bricolé un sur une prise usb cela semble faire le taf
-
bon moi je commence a venir a bout de moi meme lol
je me fais le montage de Wotever https://www.simhubdash.com/diy-belt-tensionner/
j'ai suivi tous son guide (et pas mal d'aide également de teddyman durant mes choix achats montage etc..)
je passe le coup du Arduino ou j'ai galéré a transférer le code (il a fallut que je mette un ancien driver ch340 pour réussir sans message d'erreur)
la je suis dans la phase test et évidement...fume c'est de la bonne
tout fonctionne dans dans la procédure expliquée sur le calibrage
j'ai mien la calibration ok, mais une fois simhub lancé j'ai que dalle (derniere version 9.1.13, une maj en ce moment 9.1.14)
et dans le logs systeme de simhub je vois ca :
si quelqu'un a une idée...
-
Faut verifier les cablages, court circuits, soudures, cable usb , hub usb , cette erreur c'est quand la puce usb/série déraille ou un défaut matériel / usb
Attention aussi aux fausses puces CH340 ... depuis avril il y a un driver fourni par microsoft qui les met KO, et les symptômes ressemblent à ce que vous avez : https://github.com/SHWotever/SimH…s-driver-issues -
merci j'explore de ce coté, deja pour televerser le code ca été un bordel...
-
effectivement tu as raison, deja pour le televersement du code j'avais du remettre un driver ancien...
comme j'utilise un autre ordi pour cela, je ne l'avais pas fait sur le simulateur
en testant avec ancien driver...ca fonctionne impeccable !!!
pour info j'ai commandé mon arduino ici : https://www.amazon.fr/dp/B01MS7DUEM?…ct_details&th=1
-
Allez une bonne arduino , tes fesses bien plaquées dans le baquet, le harnais serré juste comme il faut, une petite monoplace style Lotus Exos F125 (sans parler pure F1) et tu vas avoir une 1/2 molle et pas par le coup du foulard
par contre je risque d'avoir le meme souci avec la MAJ de simhub et ce message "fake chip" comme je suis en phase de finition sur mon adaptation du tensionneur de notre ami Whotever d'un baquet fixe vers mon 2DOF simukit.
me reste le câblage à refaire propre afin que rien ne traine lorsque tout sera en mouvement et je pourrai avoir le combo harnais/siège mobile...
-
Attention aussi aux fausses puces CH340 ... depuis avril il y a un driver fourni par microsoft qui les met KO, et les symptômes ressemblent à ce que vous avez : https://github.com/SHWotever/SimH…s-driver-issues
Je viens de finir les miens et j'ai eu des problèmes sur mes PC de jeux.
Lorsque que je faisait la mise au point dans mon labo, j'utilisais utiliser un vieux PC (avec un vieux Windows) tout allait bien.
MAIS sur le PC de jeux recent, certains Arduino ne veulent pas se télécharger !... d'autres présentent une connexion USB instable dans SimJub (il se déconnecte puis se reconnecte périodiquement).
En remplacant, par un Leonardo (je crois...) tout va bien !
Je crois qu'il faudrait utiliser des Leonardo car avec le Leonardo c'est le uP qui gère la liaison USB => plus de CH340 fake !
-
Allez une bonne arduino
Mes Arduino etaient des AZ-Delivery
Je ne les crois pas plus mauvaises que les originales !... ( mais si depuis qq mois Windows bloque les CH340 non officiels )
Je pense qu'on doit pouvoir contourner leur limitation en utilisant des Pro micro ou des Leonado...
-
Mes Arduino etaient des AZ-Delivery
moi aussi et dans simhub en "fake chip", j'ai commandé une nouvelle nano sur le site officielle arduino...a suivre
-
je suis d'accord ! ( j'ai fait le même constat avec mes AZ-D)
Ce que je voulais dire c'est que on devrait arrêter d'utiliser des UNO (ou des Nano) pour ne plus etre embêté avec la gestion de cette liaison USB par un circuit annexe.
Si on utilise des Leonardo (ou pro micro)
Il n'y a plus de CH340 et c'est nickel ! car c'est le micro-P qui gère directement l'USB (au lieu d'avoir une puce annexe qui nous crée que des problemes !... )
-
les UNO ou nano originaux n'ont pas ce problème, seuls les clones ont des puces CH340 chinoises...
-
visiblement oui
pour info si Wotever passe ici
je suis sous w11 (22h2)
je me suis servi de sa fonction dans simhub de passer en ancien driver (et qui bloque le maj aussi du driver (d'ailleurs si on veut debloquer il y a quoi a faire ?)
donc avant j'etais ainsi
suite a l'installation du old drivers je suis bien en 3.5.2019.1 (pratique je le faisais manuellement avant lol)
maintenant je teste avec la mise sous tension des moteurs puis connection de l'arduino
et la le port com4 du arduino disparait et je passe sun un periph usb non reconnu
c'etait juste pour faire mon petit Retex (retour d'experience), j'ai commandé une arduino sur le site officiel
juste une chose j'aimerais annuler le blocage de la maj du drivers, il y a une manip a faire ?
-
juste une chose j'aimerais annuler le blocage de la maj du drivers, il y a une manip a faire ?
C'est décrit ici https://github.com/SHWotever/Fake…xer/#revert-fix
Pour les leonardo/pro micro effectivement ils prennent en charge l'usb et en ce sens elles sont mille fois plus "fiables",mais ca implique aussi qu'elle est occupée à prendre en charge toute la stack USB. Pour envoyer les pulsations assez vite aux drivers malheureusement cette petite différence est sensible, la librairie que j'utilise va chercher les derniers hz specifiquement sur l'atmega328p (uno, nano v3) pour atteindre une bonne vitesse -
C'est décrit ici https://github.com/SHWotever/Fake…xer/#revert-fix
oui j'ai vu mais je comprends pas la manip a faire...
faut relancer le meme .exe soit FakeCH340DriverFixer.exe ??? et il va automatiquement faire l'inverse ?
-
les UNO ou nano originaux n'ont pas ce problème, seuls les clones ont des puces CH340 chinoises...
Je sais bien RacingMat Mais autant utiliser des ProMicro ou des Léonardo qui sont moins chers (et a la limite mieux pour d'autres raisons... sauf la connectique)
Avec le Leonardo, l'USB est pris en charge par le microP (il n'y a plus ce circuit interface CH340 => plus de problème )
-