Fanatec est-il menacé par la qualité des FFB SimuCube, Moza, Simagic, Asetek, VRS ?
C’est une question qui revient souvent mais au-delà du couple en Nm, on ne trouve pas d’éléments factuels qui permettent de savoir si une base surpasse les autres en termes de qualité de retour de force.
Les comparaisons de bases se font souvent sur :
- le couple (permettant d’éviter le clipping)
- et la résolution de l'encodeur position...
Depuis quelque temps on parle beaucoup de la “précision du codeur position” MAIS en fait, le terme employé devrait être la “résolution” de l’encodeur (ce qui est très différent de la précision de l’asservissement !)
Mais bien évidemment si la résolution est de 8 bits, la précision sera faible !
Dans le cas contraire, ce n’est pas parce qu’on travaille sur 24 bits que le résultat sera meilleur ! par exemple : un format audio 16 bits porté transcodé en HiRes 24 bit (comme le fait une plateforme de musique en ligne) restera toujours très inférieur à un signal 24 bit issu du master audio (on parle quelquefois de bit “significatif” : une chaîne peut avoir une résolution très élevé mais si les 3 ou 4 bit de poid faibles sont noyés dans le bruit de fond il ne sont plus significatifs)
Plusieurs marques mettent en avant un encodeur rotatif ultra précis 22 bit par tour !
Cela correspond à 2 puissance 22 positions / par tour (cad 4194304 positions codées pour 1tour)
Cela donne une résolution angulaire de 360° / 4194304 = 0,000085° !!!
Pour avoir une idée de ce que cet angle représente, voilà en rouge un angle de 1° => il faut diviser cet angle en 11650 part égale pour avoir une idée de ce que représente une précision de 0.000085° !! 
Du coté de chez Fanatec, la référence du codeur est MHL200 annoncé pour 12 bit (soit 4096 positions) ce peut paraître peu ! MAIS il s’agit de 4096 positions pour un petit déplacement angulaire de 4 mm de circonférence la roue de la roue codeuse... voir le lien ci-dessous :
https://forum.fanatec.com/disc…solution-of-dd-wheelbases
Sorry for the long bump, but I did some research and wanted to correct some misinformation on this thread. I've read the datasheet for the MHL200. https://www.ichaus.de/upload/pdf/MHL200_datasheet_D1en.pdf
The MHL200 hall sensor chip reads a magnetic strip with alternating north/south/north/south polarities with a period of 4 mm, which means from the center of one north to another north is 4 mm. This counts as one period. The Podium DD wheels have a magnetic strip with this alternating north/south pattern near the outer edge of the motor assembly.
The 12 bits of resolution cited is 12 bits for EACH magnetic period that the sensor can detect, which is 4 mm of travel. It is NOT 12 bits for the full circle. The datasheet of the chip boasts "resolution better than 1 µm." If you do the math, 4 mm / 2^12 bits = 0.977 µm. So there are 12 bits, or 4096 counts, of resolution for every 4 mm of rotation. So how many CPR there are obviously depends on the diameter of one rotation - the bigger the circle, the more CPR.
The magnetic strip read by the sensor on the Podium wheels obviously has a circumference much larger than 4 mm. Obviously the firmware of the wheel base will keep track and count the number of times the sensor has gone through its 4 mm, 12-bit range to derive the actual position of the wheel in degrees.
The actual CPR of the Podium wheels should be calculated with this formula: (2*π*r) / 0.977 µm, which r being the radius of the magnetic strip.
The width of the Podium wheel base is 171mm. As the sensor is on the outer radius of the motor assembly, if we assume r of the magnetic strip is 75 mm (just pulling a random sensible number here), we get 2*π*75 mm = 471 mm diameter. 471 mm / 0.977 µm = over 482,000 CPR, 100 times better than the original poster's assumption and more importantly much better than the 16-bit resolution reported to Windows, which should be actually a downsample. The actual number is probably not too far off but surely it's bigger than 2^16. I'm guessing it's at least 2^18.
Given that 1 µm is 50 times less than a width of a hair, I don't think the precision of the sensor is a huge bottleneck for the Podium wheels. I'd be more worried about manufacturing tolerances on these parts than the resolution of this sensor.
It says on the CSL DD's page that it uses the same sensor, but I don't know how the motor works and not sure what a good approximation of r would be compared to the DD1/DD2.
This is all I'm doing while waiting for my pre-order to ship 
Would be cool if someone from Fanatec weighed in here.
Also how the heck do I change my username on here? I am not Fabio Lopes.
Si on prends en compte ce déplacement angulaire, on retombe sur une précision d'environ 16 bits par tour, soit 655365 positions ou une résolution angulaire de 360° / 65536 = 0,005°
Pour avoir une idée de ce que représente 0.005°, il faut diviser l'angle ci-dessus en rouge en 200 parts égales ! je pense que c'est bien suffisant ! 
(d'ailleurs je ne pense pas que l'asservissement puisse atteindre cette énorme précision mais au moins il ne sera pas limité par la résolution du capteur !)
La résolution du capteur est une chose, la précision de l'asservissement en est une autre qui est bien plus complexe !
Par exemple, il y a un point essentiel qui est la capacité d'accélération du moteur :
- Du point de vue mécanique c'est la masse à mouvoir divisé le couple
- MAIS du point de vue électrique, le couple n'est pas immédiat car le couple correspond au courant absorbé.
Dans une bobine le courant maximum n'est pas immédiat => lorsqu’on alimente une inductance avec une tension donnée le courant augmente de manière linéaire avec une pente qui est proportionnelle à la tension et inversement proportionnelle à la valeur de cette inductance.
Voilà pourquoi Asetek annonce qu'il faut 3 ms a sa base pour atteindre les 27 Nm (car la pente est de 9 Nm par ms)
Cette donnée est très importante ! elle est beaucoup plus significative que la résolution de l'encodeur qui ne veut pratiquement rien dire à partir de précisions supérieures au centième de degré !
Ce point pourrait être pénalisant pour le CSL DD car son alimentation ne fait que 24V... cela dit, si la valeur de l'inductance est faible, le courant montre plus vite mais d’un autre côté, réduire le bobinage réduit aussi le couple ! (car le champ magnétique dépend du courant ET de l'inductance)
En fait, pour accélérer, il faut que la tension soit haute et que le moteur soit petit avec de petit bobinages mais ces 2 derniers points réduisent le couple et s’il n’y a pas de couple il n’y a pas d'accélération non plus !
D'autre part, d’un point de vue moins électrique et plus mécanique, la capacité d'accélération est liée à la masse car l'inertie dépend de la taille du moteur.
La masse en mouvement dépend aussi de sa topologie, par exemple : rotor interne ou externe :
- moins d’inertie avec un rotor interne comme pour le CLS DD (mais moins de couple)
- plus d’inertie avec un rotor externe comme pour le DD1 et le DD2 (mais plus de couple)
Donc, il y a un compromis à faire entre le couple et la masse (ci-dessous les 2 types : rotor interne ou externe)
Il y a aussi l’influence de l’électronique de pilotage du moteur qui est énorme sur les grandeurs souvent contradictoires dans boucle de régulation : Précision vs Vitesse vs Stabilité (c'est un compromis car il est impossible de gagner sur tout les tableaux en même temps ! 
par exemple : augmenter la vitesse réduit souvent la marge de stabilité ! c'est vrai dans beaucoup de domaines et en logiciel de Sim racing cela peut traduire par ajouter du "Damper" amorti et améliore la stabilité MAIS trop de "damper" réduit la précision et la vitesse.
Ces paramètres peuvent être modifiés / dégradés par logiciel (Fanalab ou …). Je dis dégradé car avec du logiciel, on peut facilement ralentir un système MAIS on ne sait pas le faire aller plus vite que ce qu'il peut aller !!
Il y a aussi la vitesse de rafraichissement du logiciel : SimuCube est capable de rafraichir jusqu'à 2200 fois par seconde tandis que Fanatec rafraichi 1000 fois par seconde son asservissement... MAIS le jeu est loin de calculer aussi vite les corrections de FFB (si le logiciel tourne à 100 Hz ça doit être très bien !... alors évidement, il est préférable que la base assure un asservissement plus rapide que les mouvements calculés par le jeu sinon on perd des infos ! mais 1000 Hz devrait suffire...)
Malheureusement, la plupart des informations sont très incomplètes , il est donc difficile de comparer les bases ! Et les informations fournies sont plutôt du "marketing" comme par exemple, la résolution de l'encodeur, qu’il soit de 16 ou de 22 bits… je ne pense pas que ce qui soit l'élément déterminant au regard de la sommes des paramètres à prendre en compte et de la précision totale de la boucle d'asservissement qui doit être autour du dixième de degré près (je ne suis pas certain qu'on puisse atteindre le centième de degré !... alors un encodeur à 0,000085°.... 
)
Ceux qui se sont intéressés au DIY ont déjà dû se poser ces questions… s'ils ont des éléments de réponse pour faire avancer le sujet, ils sont les bienvenus.
, je pense que pour la plupart des acheteurs de ses DD ,on y fait pas vraiment attention, ce qui compte c'est le ressenti en piste, à lire les avis sur notre forum et voir quelques tests , il n'y a pas une base qui en surpasse une autre, le faite que fanatec est vendu autant de produits , c'est l'offre qu'ils proposent, contrairement à simucube qui ne propose que le moteur.
)
)
, nos spécialistes de l'époque pourront sûrement préciser, mais on n'a jamais vraiment tourné avec une précision de 2500PPR sur nos RFRWheel 
, c'est mon avis).