Yes, this was a direct bolt on replacement for the small Mige I reviewed in the recent SRG OSW review. This Mige has two opposing holes that are tapped for M3 threads. This pair of holes are closer together than the holes that the SinCos is using. And they fit the BISS-C mounting bracket perfectly. Now, some older Mige motors may not have these extra holes. If that is the case, Tomo includes a machined adapter bracket that bolts to the SinCos holes. This adapter has two tapped holes with screws in them, that will fit the BISS-C’s mounting bracket.
I will have review video out on Tomo’s conversion kit this weekend. As usual, it will show all this in detail. Along with the settings I used in Granity to get it up and running. This is a very easy kit to install.
Yes sounds like you probably have a revised Mige Servo as the older units only have one pair of mounting holes and a longer encoder shaft which fails the direct replacement ability.
The only thing is, Barry said he updated the Mige he used for his SRG OSW review which had the Sincos.
Which, if I’m not mistaken fits the old shaft style.
Anyway, we’ll soon see the upgrade process in the upcoming review. I’m curious about the shaft fitment as well.
Yes the SinCOS fit the old style shaft because the sinCOS has a deeper Void for the encoder shaft from the Servo than does the BiSS which is part of why Mige had to make mods to the servo itself… The other issue is the Mounting hole locations being narrower on the BiSS which is what Barry mentioned was on the one he has so it was an already Mige Modded Servo… It sounds like there will be a crossover and some SinCOS and all newer 10K Servos (as the 10K’s will use the old mounting) will be able to accept the BiSS directly though in reality I am not sure that the upgrade from the SinCOS to the BiSS will be worth the upgrade cost. However it will be the new standard upper end encoder so it is what it is there.
Unfortunately I was not able to get the last of the sincos encoders floating around so I’ll have to wait to see if there is a biss retrofit solution with the older mige… let’s see what tomo comes up with…if it just needs to be spaced out a bit it should be an easy fix…
Fortunately we have access to all of the Mige M10010 motors from the early 5000ppr versions, we have measured the shafts to see exactly what is compatible with the new BISS-C encoder it seems that one adapter plate will cover all previous versions.
We will be manufacturing the adapter plates as of next week, if anybody would like to manufacture one for themselves the drawing and STEP files are available here: BISS-C Adapter Plate Drawing and STEP File
So it’s a single-turn absolute 22 bit, Binary code, Clockwise counting, 5 volts, BISS, the smaller diameter of a holder, 0.3 meters. 62.5kHz update rate with 10 Mbit rate on <12 meter 24AWG UTP cable.
Inside it is using sin-cos encoder + digital converter with 9 bit subdivision resolution and 2048 P/R, so it’s >1M resolution (last 2 bits could be noise). Original sin-cos on IONI was around 5 bit sibdivision resolution, so it’s 4 bits less noise.
But accuracy is +/- 45 arcseconds which would make it 14400/turn. Not very good, to be honest. If we want to exceed DirectInput resolution at 450deg bumpstop - it has to be < +/- 12 arcseconds.
If we will use Rongde DVC48.3V9D-G0.3M1S-8192BM - that should be higher accuracy even it’s sin-cos - +2 clean bits. And with proper sin-cos to BISS converter - should be even better.
Another option is to take Rongde RDE94T30-20-1-SBG and make shaft (from 30 straight to 9mm tapper) and holder adapter. That would be 1M resolution (instead of 4M, but 7.5 arcsecond accuracy instead of 45). 4M from Rongde requires 60mm shaft encoders.
Reality is that we need as high CPR as possible to have filters work correctly (because ioni speed/acceleration calculations are too simple) but we need <12 arcsecond accuracy to get position data. No encoder that are widely used now can achieve that. And this biss-c from Yunghe is not real 22 bit - they just don’t have any encoders better than 45 arcsecond.
I will get one to test how acceleration graph looks with it on low-speed vibrations (or anyone willing to test and post?).
But with any effect based sim it should work better (iracing/ac should be placebo only if no filters in use). On top of that should be no noise anymore, lower drift and higher accuracy, no phasing issue. Could use much lighter ordinary UTP CAT5 cable.
Unfortunately, IONI doesn’t check CRC, so glitches still might come through. But it should be catching tracking error then.
Hey @Mash, how are you deriving the absolute accuracy of these encoders? I have a Henglsgter Ad58 on my AKM, what kind of accuracy am I looking at there?
Some of them actually posting it in datasheets. Especially if it’s absolute encoder. And I measured noise on Simucube + Rongde 2048 SinCos. In your case, it’s clearly stated - Absolute accuracy ±35 arcseconds. Somewhat better than 45 of Yunghe. I don’t think you can have better than that with 2048 plates sincos under the hood. If your one is 22 bit - you should see a lot of position noise at least significant bits. They state repeatability of 7", so it would be last 5 bits noise, that they filter out. 13 bit version is guarantee to be accurate with all data, but for our application 22bits is better to calculate effects and filters.
What is your exact model number @smilen ? If you got 22bit BISS + sincos encoder - you really should not connect it in a sincos mode.
I’m not sure where you’re going with this, but I guess you’re fully aware that this is more than enough to position the wheels and drive around the track? I think that the most critical point in time when you could possibly need the precision is around corners and, let’s think about the actual situation when you’re in the corner, when you’re driving through the corner fast. The force feedback from the simulator is turning the wheel always more or less, “kicking” your hands, and you, as a person, cannot hope to position the wheel precisely like precision grade robot could turn the wheel, e.g. robot is driving the simulator with micro_second reflexes + ability to counter_steer like a human through corners. No, you’re not positioning the wheel precisely but you’re driving it through the corner and correcting the car as/when needed.
As a smaller note to this thing, as I am aware, majority of people drive with 900 degrees bump stop to bump stop? Therefore the previous is < +/- 24 arcseconds. Also, as we’re simulating a real race car, how many arcseconds there are is play in a real car ?
Rongde was… well, let say this, that there was business related issues, major issue being their ability maintain acceptable lead times. Long lead times lead to situation where there is every now and then nothing to deliver, motors are not available from the motor supplier. The SinCos also had one feature “lacking”, that it is not absolute.
It is a positive upgrade that the SimuCUBE could right after the power up pick up the wheel position correctly as from our perspective it seemed that when some new people buy the product, some of them are more or less confused if the wheel is not “straight” and many of them don’t read the manuals either . So to correct this, absolute it needs to be, not that it is absolutely needed for everyone, but it is nice feature to majority. Adds a bit to the ease of use.
Doesn’t seem to be made for motors, at least not for this size as the smallest size is for 30mm shaft.
Okay. I think that I was talking about this with you something like ~½ year ago where you mentioned all sorts of fancy things that to my knowledge requires rather powerful computer which is turn means that this is impossible on embedded system.
If widely used encoders would achieve or exceed this level of precision, how would you expect it to change the experience and to what degree the change would be from current level of force feedback?
Would people drive faster or enjoy more? How critical it is if there is difference between the steering wheel that you hold and the virtual steering wheel at the simulator side if you cannot hope to see the difference with your own eyes as in stand still situation and (also) the position differences that you can see during driving are caused by delays from USB communication and/or Windows OS as it is not real time system, I mean, if you can see the difference (which you can from time to time, then those are USB, firmware and windows related or display related, not encoder related precision errors)?
Interesting idea, there could even be commercial possibilities with this outside the simulator field.
Tommi, I’m not concerned at all about static wheel position precision. What I’m concerned about are effects that implemented as filters/direct effects in Simucube and effects that implemented inside iracing/AC. They all need speed and acceleration calculations. And most of the time you get feedback while barely moving a wheel - your positional changes are tiny. In such condition your wheel speed and acceleration calculations becoming extremely poor. Accuracy is basically linearity and if you report with large mistakes - you add very significant error in further calculations inside the sim.
Now you can fix your Simucube effects by doing simple arithmetical filtering based on a knowledge of possible system state range. That, I’m quite sure can be done on current MCU. But, I’m not really pushing it, because most people play on direct osw iracing/AC and there it would be useless. What would not be useless is fast and precise reporting back to sim actual position.
And I have only stated that beyond 12 arcseconds accuracy and 21 bit repeatability further improvement of encoders would stop making sense. Certainly for 900deg you’re limited to 24.
About rs485-422, I’m looking for existing h/w platform. Unfortunately most converters have low speed MCU and deal with 0.1mbit only. And I’m not ready to invest time and money to develop new h/w. But maybe it’s easy for your team - adm485 already has both interfaces. At the same time - I have no idea about tamagawa accuracy and whether it will have it beyond Yunghe. It’s worth talking with them before wasting a time.
But it has to be better - it doesn’t keep sincos inside. It doesn’t deal with light signal phases. So its mechanically binary. And based on the fact that 23 bit consumes more than twice power vs 17 bit - I assume that they just added few times more led and diodes to read same perforated wheel at shifted positions. So it has to have full resolution unless they extrapolate something. So based on what I know - it’s a simplest (Mige built their motors with tamagawa in mind from the beginning) and cheapest option to surpass possible encoder definition. Just need a fast converter of tformat to biss data.
Resolute would require adapter on the shaft, but it has large tolerance for play. I have no idea how much it costs, but it’s ideal combination of accuracy, speed and resolution in a still compact package.
?
. So to correct this, absolute it needs to be, not that it is absolutely needed for everyone, but it is nice feature to majority. Adds a bit to the ease of use.