Le problème est qu’après, à l’aveugle, qui saurait faire la différence entre plusieurs bases sur le marché toutes bien réglées ? …
Quelqu’un qui a un DD2 ce serait ridicule de changer à mon sens, un autre direct drive ne va pas réinventer la roue même si il chante …
La grosse evo du dd a été la « simplification » vu les SC1 le bazar que c’était et maintenant un SC2. Y’a pas photo !
Pas sur !
La HD, c'est bien quand même !... (pour le son ou la video, personne ne reviendrait en arrière)
Cela dit, aujourd'hui, on ne peut pas apprécier (ni objectivement, ni subjectivement) la difference avec une base plus lente car il faut que les jeux se mettent a jour (le 1er sera i-racing)
Possible. À voir.
Pour le moment c’est un peu trop marketing j’ai l’impression …
Certes, il y a du marketing !
Mais personnellement, ce n'est pas ce qui m'intéresse et malheureusement, concernant les données de performances objectives, les marques ne nous donnent pas grand chose ! 
Je ne dis pas que le couple ne compte pas mais c'est très insuffisant pour avoir une idée de la performance de l'asservissement !
Et pour le nombre de bits de l'encodeur il y a confusion volontaire entre résolution (du capteur) et précision (générale)
Oui mais il a y tellement d’autres facteurs donc tu as parlé.
Et le plus gros reste les jeux … Quels jeux utiliseront à 100% son potentiel ?
jmr31 je ne me souviens plus si tu as créé un topic sur le slew rate, je pose ce qu’a écrit Mika le gourou du simucube sur le forum officiel :
Équipe de Granite Devices
7h
Le taux de rotation du couple est le taux de changement du signal de couple. S'il y a un limiteur, alors le logiciel limite le taux de changement à celui des paramètres. Le résultat est une sensation beaucoup plus lisse et caoutchouteuse sur la roue. Cependant, tout changement réel de sensation ne se produit que lorsque la limite de taux de glissement a été fixée à 1,5 Nm/ms ou moins - tout taux de glissement plus rapide que cela ne sont pas vraiment utiles dans le simracing.
Le "slew rate" (ou pente) défini l'augmentation (ou la diminution) d'une grandeur (tension, courant, couple) en une milliseconde (ou us...)
En sim racing on parle de la pente du couple mais la pente du couple est aussi la pente du courant
La pente du courant est déjà limitée par l'inductance du moteur (qui peut être énorme) car une inductance s'oppose aux variations de courant (l'inductance crée une tension à ses bornes pour maintenir le courant le plus "constant possible"... plus l'inductance est grosse => moins le courant varie vite => moins le couple varie vite => le slew rate est bas
voir le post #2 sur la page ci-dessous :
Pourquoi une inductance crée une tension qui s'oppose au variation de courant
Pour contrer cet effet, on peut augmenter la tension : les CSL DD sont en 24V mais les Simucube sont en 36V et certains moteur Mige utilisé en sim-racing sont en 48V !
Apres, il y a aussi la vitesse de la commande qui peut ralentir... cela dit la limitation ci-dessus ne sera jamais dépassée !
===================================
Sinon, ce qui m'étonne dans ce message est le gars qui dit qu'une variation de 1,5 Nm/ms (ou moins) est suffisante en Sim racing
Déjà, je trouve que ça n'a pas trop de sens puisque une base qui aurait 1.5 Nm de couple atteindrait ce couple en 1ms alors qu'un DD2 réglé à 15 Nm mettrait 10 ms pour atteindre sa valeur max...
Supposons qu'on tape un mur, pas sur que 10 ms soit assez rapide pour rendre l'impact réaliste...
Mais le slew rate est un limite pour les grands signaux !
Cad pour les petites variations, on peut aussi être limité par la vitesse de la commande (même si le slew rate est suffisant)
voir le post #3 sur la page ci-dessous :
Tu m’as perdue là 
J’ai bien compris que c’est un réglage qui limite la réactivité du moteur , dans notre cas nos volants, je l’utilise de plus en plus dans assetto corsa, car suivant les voitures utilisées, le volant (moteur) est à mon goût beaucoup trop réactif, ce qui me retransmet des effets de vibrations que je trouve désagréables et pas réaliste pour une voiture, surtout lors des appuis, freinage ou virages.
Pour imager, cela me donne l’impression que les roues avant, sont dévissés et tremblent, si tu vois ce que je veux décrire.
En réduisant se réglage , je n’ai plus cette mauvaise sensation, je trouve un véhicule avec une physique plus lourde et j’ai de meilleures sensations lorsque la roue monte un vibreur , c’est moins on/off , je trouve donc ce réglage génial, de plus cela permet de réduire considérablement le damping et la friction,l’inconvénient en ce qui concerne assetto, c’est qu’il y’a tellement de voitures, qu’il faudrait quasiment un réglage par voiture .
Je comprends, un filtrage des signaux de fréquences élevés (filtrés par le slew rate ou bien par autre chose...) te donne un meilleur ressenti
Mais ce n'est pas ce filtrage qui est en cause mais la qualité des données envoyés par le logiciel.
Dans l'idéal, tu pourrais avoir une bande passante infinie !! (avec un slew rate infini !) et un ressenti qui doit juste (si les informations de FFB étaient juste..)
Avoir la capacité d'accélérer à l'infini ou d'atteindre une vitesse infinie ne veut pas dire qu'il y aura plus d'informations haute fréquence si le FFB est juste.
C'est un peu comme si on roulait avec une voiture très rapide sans accélérer (la capacité a accélérer ou à aller vite est "un plus"... mais ce n'est pas une obligation !)
Alors comment limiter cette quantité de données ?
Est-ce que la fréquence pourrait la limiter ?
Par exemple descendre en dessous des 1000 hrz ? Actuellement je suis à 4700 hrz , mais avec le réglage "standard " de 2200hrz c’est pareil.
Il y’a également un réglage que personne ne touche , même pas simucube, c’est une fréquence associée à un facteur Q , j’ai déjà essayé, sans succès car il faut toucher ces deux paramètres et je n’y comprends rien
D’ailleurs je dis des bêtises ce n’est pas mentionné comme une fréquence mais des db associé au facteur Q.
Alors comment limiter cette quantité de données ?
Est-ce que la fréquence pourrait la limiter ?
normalement avec les filtres proposé d'origine :
un peu d'inertie pour le poids
un peu de damping pour lisser
Apres... une base peu performante peu lisser aussi ! (lol !) Mais ce n'est pas l'Idéal
L'Idéal est une base HD Haute Fidélité, sans limite de vitesse / fréquence / précision capable de restituer dans leur intégralité toutes les informations que soft envoi.
Et c'est au logiciel d'envoyer de bonnes informations (et aussi de les supprimer / filtrer celles que tu ne souhaites pas, comme avec la musique, baisser les aigus si tu n'aimes pas l'aigue... mais laisser la possibilités à ceux qui veulent toutes les infos de les avoir ! (après tu semble dire que l'aigue d'Assetto corsa n'est pas très bon ! mais ça c'est un autre problème et ce serait dommage de limiter les perf de la base parce que le FFB d'Asseto est granuleus ou autre...)
Mais le slew rate est un limite pour les grands signaux !
Cad pour les petites variations, on peut aussi être limité par la vitesse de la commande (même si le slew rate est suffisant)
voir le post #3 sur la page ci-dessous :
https://forums.futura-sciences.com/electronique/8…e-passante.html
Pour expliquer ces mes 2 lignes ci-dessus qui sont très importantes à comprendre j'ai fait un petit dessin
1) le slew rate est une limite pour les grands signaux seulement !
- La courbe 1 est un signal sinus de grande amplitude qui ne peut pas être restitué (sans forte distorsion) puisqu'il dépasse le slew rate (ou la pente maxi, cad la droite rouge en pointillé)
- Donc ce sinus de grande amplitude 1 sera restitué comme la courbe 2 (cad le triangle rouge et noir de moindre amplitude => toute la surface en fine hachure gris clair ne peut pas être restitué par la base !)
- PAR CONTRE la courbe 3 de même fréquence MAIS de petite amplitude sera rendu sans distorsion !
- Et aussi en bleu, la courbe 4 sera aussi restituée sans distorsion (pourtant sa fréquence est plus élevé!!)
2) on peut aussi être limité par la vitesse de la commande (même si le slew rate est suffisant)
Le slew rate, comme le couple et une des données intéressantes mais hélas très insuffisante pour caractériser la performance dune base !...
D'ailleurs vous voyez sur le dessin que le slew rate ne caractérise même pas la réponse en fréquence (sauf pour les grands signaux ou il limite la réponse)
Sur ses derniers DD, Fanatec s'est doté de DSP plus rapide (il traite les datas à 16 KHz) pour améliorer la réponse en fréquence (le théorème de Shannon nous dit qu'il faut une échantillonnage au moins 2x plus rapide que le signal le plus haut).
Bien sur, aucune base ne pourra répondre à 8Hhz (vu la masse en mouvement, c'est impossible !!) MAIS on peut espérer une meilleure définition de ces bases quand les jeux enverront des FFB "haute définition"
Aujourd'hui c'est loin d'être le cas !! 
Suivant les jeux, les FFB ne sont pas assez définis/précis/lisse (un peu comme les premiers lecteurs CD qui avait qqfois un aigue qui étais décrits par certain comme "dur" ou "métallique")
Tu constates un "grain" qui te dérange avec ton Simucube et paradoxalement une base moins performante filtrerait ce grain qui te dérange (en fait on peut retourner le problème MAIS pour moi, il faut le prendre dans le bons sens)
C'est comme si tu avais une TV 4K de 65 pouces et que tu utilisais un fichier source en basse résolution et très compressée... (par contre ce même fichier sur un écran de tel passe très bien)
Te concernant la solution (pour le moment avec les jeux actuels) passe par des filtres "passe-bas" qui vont lisser
voilà une autre illustration pour comprendre la limite du slew rate
- ligne du haut 2 signaux à restituer (carré à gauche et sinusoïdal à droite)
- ligne du bas : en bleu, les signaux réellement restitués (et en gris tel qu'il devraient être restitués !)
Notez que le signal carré ne correspond pas a une réalité physique car il n'a pas de temps de monté ! (ou temps de monté nul) par contre on l'utilise pour caractériser un système et à partir de sa réponse transitoire (équivalente à la réponse en fréquence en sinus en utilisant une transformation mathématique)
Merci pour ton implication, même si je suis complètement dépassé Sur certains points cela est intéressant,
Pourquoi sur la ligne du bas (output) le graphique de droite, ne peut pas être restitué comme il devrait l’être ? A cause de nos moteurs qui ne serait pas suffisamment puissant ?
Tu dis que fanatec utilise maintenant un DSP de 16 kHz, saurais-tu à quoi cela correspond sur simucube ? Le filtre de bande passante peut-être ?
Pourquoi sur la ligne du bas (output) le graphique de droite, ne peut pas être restitué comme il devrait l’être ? A cause de nos moteurs qui ne serait pas suffisamment puissant ?
Que ce soit sur le graphique de droite ou de gauche ou sur mon dessin, ce n'est pas une question de puissance de moteur mais une capacité du moteur a accélérer.
Si tu observes bien les 3 graphiques, le problème est identique car les 3 signaux (carré ou grand sinus) dépassent tous la pente de la rampe de monté maxi => donc la sortie suit cette rampe (parce que la base ne peut pas aller au-delà)
Un moteur de F1 accélère instantanément sans inertie (pour le démontrer, Renault faisait chanter la Marseillaise à son moteur) par contre un moteur de camion/bateau qui serait 2x plus puissant ne pourrait pas accélérer aussi vite (donc "puissance" ET "slew-rate/vitesse" sont des choses différentes)
Si je prends l'exemple d'une base comme un DD2 (sans parler de la commande mais seulement du moteur) il y a plusieurs aspect qui limitent :
Mécaniquement : la masse ou la plus grande inertie du rotor extérieur
Electriquement : l'inductance du rotor extérieur (peut-être plus grande) qui limite la monté du courant donc du couple (voir mon post no #47 => plus l'inductance est grande est plus elle s'oppose a la variation du courant...)
Electroniquement : la vitesse de la commande, on ne peut pas aller plus vite que le DSP (CPU dédié a cette appli) d'après le théorème de Shannon il faut au minimum minimum 2 points/échantillons par période (c'est la raison pour laquelle un CD est échantillonné à 44 KHz pour avoir au moins 2 échantillons à 20KHz)
C'est complexe !... MAIS d'un autre coté le couple supérieur peut compenser la masse car l'accélération est le résultat d'une force appliquée sur une masse
Tu dis que fanatec utilise maintenant un DSP de 16 kHz, saurais-tu à quoi cela correspond sur simucube ? Le filtre de bande passante peut-être ?
D'après ce que j'ai compris de la com minimaliste de Fanatec, 16 KHz correspondent à la vitesse de traitement des échantillons (cad que le temps de traitement de la boucle logicielle de l'asservissement lui permet de prendre en compte 16.000 échantillons par seconde)
Evidement, ce n'est pas la vitesse du DSP (= Digital Signal Processeur = CPU = uP dédié au traitement du signal) car le DSP tourne bcp plus vite !! et Fanatec se garde de donner des infos a ce sujet ! (16 KHz est la vitesse de prise en compte des datas par le logiciel)
Pour simucube, c'est aussi opaque ! mais on sait que leur logiciel est capable de prendre en compte des FFB jusqu'à 2200 Hz (je crois...)
Cela dit, le FFB de i-racing est à 60 Hz (et qu'ACC affiche 400 Hz... mais à voir !...)
Concernant ACC c’est bien marqué 400 hrz sur la pâte du jeu .
Pour simucube c’est bien plus de 2200hrz il est affiché sur la page du logiciel 4700 et illimité, entre 2200 et 4700 il y’a 2 ou 3 réglages intermédiaires.
Je regarderai quand j’aurais un peu plus de temps , simucube enfin granit devis avait détaillé sur un schéma, l’électronique du moteur, peut-être y verra-t-on plus d’informations.
Oui j'avais lu un 2200 pour Simucube... mais maintenant que tu le dis j'ai un souvenir de 4700 (qui doit être le maximum car illimité c'est faux, il y a tjrs une limite d'échantillonnage)
Pour ACC, c'est marqué 400 Hz en effet, mais le FFB d'ACC a t'il vraiment cette finesse car résolution n'égale pas précision ! loin de là !!!
En fait, 2 grandeurs caractérisent la précision d'un signal numerique, par ex pour l'audio
1) la fréquence d'échantillonnage en Hz
2) la résolution des échantillons en nombre de bits
Pour le format CD audio, c'est une base de 16 bits pour la dynamique (ou la hauteur en niveau) et de 44.1 Khz pour le nombre d'échantillon (ou la "largeur" dans le temps)
Pour le format HD audio, il y a le 24 bits de résolution et 96KHz pour l'échantillonnage (et il y a plus haut...)
On parle surtout de résolution pour la précision en niveau... je peux aussi parler de résolution temporelle (cad fréquence d'échantillonnage)
Bref ! le format HD (très précis en terme de "résolution") peut "porter" un signal audio très distordu et imprécis
Donc, résolution ne signifie pas précision !... c'est ce que je voulais sous entendre avec le FFB d'ACC en 400 Hz...
