What is going on with the encoder resolution of DD wheelbases?
Zhenghao Lai
Member
I've recently purchased a DD1 wheelbase and have always been mocked by my friends saying that simucube products are a bit better on the FFB side. I wouldn't comment on this as I buy Fanatec products simply because of their eco system.
However this constant input of idea makes me start researching. General comments from every Youtube review is that FFB of simucube is a bit more detailed. What might cause that? Other than software issues, the only thing I get from the internet is that it might be affected by encoder resolution (this might be wrong but it's what I get from the research)
So I investigated the encoder resolution of both products. Simucube has stated the resolution of 22bit on their website (more than 4million counts per revolution). However, Fanatec does not state this value very clearly.
I've found this thread of Fanatec's software update, where it's stated that the resolution has unlocked from 8bit to 16bit (around 65000 counts per revolution). It's explicitly explained by the Fanatec staff that the increased resolution makes the FFB more detailed. Thus, it might be true that the 'slightly more detailed' FFB from simucube is a result of their high-res encoder (4,000,000cpr compared to 65,000cpr).
However, from Boosted Media's teardown video of a DD2, it's clear that the wheelbase has an MHL200 encoder chip. This is a 12bit encoder (only 4096 counts per revolution!), you can get the datasheet of the chip from the internet.
https://www.youtube.com/watch?v=MDiQ9zmqOss
Now here comes the problem, how do Fanatec manage to get 65536cpr (16bit) from a 4096cpr (12bit) encoder???
I hope that there's somehow a hidden encoder in the motor itself that Boosted Media's teardown did not cover, rather than Fanatec just scaling up their low-res signal of positional data.
Comments
Having both a SC2 sport and a DD2 in can asure you the SC2 is indeed a bit more detailed and smoother than the DD2 regarding FFB but (and there is always one) for most of the users this won't be very noticeable, especially after a few laps running on a wheelbase. I only notice it when i jump back an forth between the two wheelbases (and i'm not talking about the cogging)
There are a few things to consider however, Simecube is working with an inrunner instead of an outrunner motor which feels a lot smoother on rotation without or with minimal load and when you ask most users what they mean by "smoother" rotation this is what they mean. Because of the outrunner the DD1/2 has some cogging but that's just a characteristic of the motor type (the CSL DD will rotate a bit smoother also).
Now i'm not sure how Simecube measures the position etc and if they do it with an optical sensor for example but i think there is a bigger picture then "just the encoder chip".
Would be nice however if someone from Fanatec could be a bit more specific on this topic.
Besides that, that something is better on paper won't mean it's experienced as better by people also. I did a lot of DJ gear reviews in the past and the Technics SL1200MK2 was a legendary turntable, somewhere around 2006 HanPin (a big manufacturer in China) came up with an OEM turntable that had an optical sensor to read out the rotation speed and it was waaaaaaaaay smoother, accurate and didn't have the overshoot on corrections like the SL1200 had and a lot of people still preferred the SL1200 even though the new one was cheaper and performing better ;)
Thanks for your reply, Reind.
I think it's nice to be clear that simucube is using a very typical optical absolute encoder. (That is a later beam hitting a patterned disk and the sensor senses any obstruction for signalling).
Fanatec is using a hall effect sensor and letting it float around a magnetic strip around the outer parameter of the rotor.
I can;t comment on the accuracy on those, but generally speaking, the optical one is better. Also, simucube's encoder is like 8 to 9 times more expensive than Fanatec's chip.
Actually, the mean issue is that, although their encoder is physically capable of reporting 4096 positions each rotation, Fanatec stated in their thread that it's now sampling at 65536 positions each rotation. It's like having a 540p monitor and claiming that it's capable of streaming 8K video. To be clear, the encoder does determine the physical resolution of the servo motor. So imaging that as screen resolution is an accurate representation.
How do they even do that? Displaying 8K content on a 540p (or even worse consider the 4096 vs 65536 positions per rev) monitor?
To be very apparent, I'm not really criticising their servo motor's resolution (although it's 4000 vs 4million cpr)
What I'm talking about is, that why are they claiming to sample 16bit data from a 12bit sensor? (this is explained in my previous comment)
I hope there's some misunderstanding, it's good if Fanatec's technical support can explain this. Otherwise, I tend to think that Fanatec did a false claim on their data.
As a DD1 to simucube 2 pro user I too can confirm the simucube is a bit more detailed but its very slight and I think actually it's more down to the speed of the motors.
Fanatec actually stated they opted for a outrunner motor for the DD bases for increased torque output at the cost of speed... the simucube bases are quite obviously faster but managed to get the power aswell, the pro matching the DD2 for 25nm torque.
Fanatec is actually pretty vague on the details they give on the specs and it's very likely because the spec sheet wouldn't look great next to competitors, the encoder resolution is lower, the slew rate (motor speed) is almost certainly lower etc so its clear granite devices went balls to the wall on hardware and fanatec... didn't.
How useful this all is - is up for debate, because I can honestly tell you between the DD1 and simucube 2 pro I can't pick up the resolution difference in rotation, literally blowing air onto the wheel causes movement on screen, so even though technically the simucube is far superior, I dont think a human can tell the difference, in a factory setting requiring robots to be super accurate the simucube 2 motor would be top dog.
I can tell you the simagic alpha uses an 18bit encoder aswell according to its user manual, the VRS direct force pro also uses a 22bit encoder so technically superior to the DD bases.
I can't explain how they increased the resolution if indeed the encoder is 12bit but I was always under the impression it was always a 16bit encoder it was just software restricted.
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. :)