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.
To my knowledge - there would be zero difference. BISS could be potentially 30 usec slower due to the buffering of sample and calculation of value from inputs.
But then Simucube is going to collect a lot of samples of position and average it. That would introduce (if it’s 1000Hz, I don’t remember how much) 500 usec delay.
And then it will send position data to sim. In case of iracing that would be 15`000 usec delay.
After that it will probably waste another 100`000 usec to make a meaningful response to the motor.
So I don’t know exact numbers, but sensor latency is not your actual problem.
Edit: Now I know where is this “latency” comes from. Barry explained that he doesn’t mean literally encoder delay, but rather earlier understanding of what’s going on. Which could be explained by higher factual resolution vs Rongde sincos.
Anyone with new encoder willing to do the test as I did before?
Go to Granity Testing tab.
TSP1 set to smallest value you can feel. For me it was 50 = 0.04A.
TSP2 = -TSP1
TSD1, TSD2 = 0.02
TSR = 20000
Capture signals selection: Position Achieved, Velocity Achieved
Continuously repeating capture = ON
Click Start Capture button
Click TSE = ON
Don’t hold a wheel. If you don’t see at the right side chart proper wave - increase TSP1 and TSP2. If you can see wheel moving by your eyes - decrease them. If you can’t feel it by your hands - increase them. So the purpose is to find smallest movements you can feel.
After that click “save to file” button above the chart and post file here.
Post picture like this. This is crappy sincos velocity calculation. If you have better encoder - that thing will improve.
Another test - disable test stimulus and just check noise of the position achieved. Send picture. This is how drift looks if you collect data slow on sincos.
I saw your post in the review and was have these questions:
So, the Ioni FW is capable of 22bit resolution, but the SimuCube’s FW is not. Do you know exactly which filters the Ioni’s FW can run at 22bit? This information may be helpful in tuning the wheel to ones preference if we know which filters are running at the higher speeds. Or if it is just an improvement in ADC and signal noise causing the difference, should we consider that all filters are running smoother across the board because of it? Or, is all of this speculation, and we will have to wait until someone can actually test this encoder to get real data to look at?
Every IONI filter runs at full CPR that is configured into IONI. Because SimuCUBE firmware reads the encoder value by using 16-bit differential value (changes of max/min +32767/-32768) every 400 us (2500 Hz), using higher than 21 bits might result in overflowing that differential value, and could then cause loss-of-center for the steering. This would happen if wheel was rotating very fast.
This used to happen a lot in early beta testing, but we have no recent reports. Also, we didn’t have time to implement the reading of full encoder counter value into Simplemotion API’s fastUpdateCycle() command, which SimuCUBE and IONI use to communicate with each other, so that it could be read as such by the SimuCUBE firmware. So we set the limit at 21 bits at the time, so that people would not try to find expensive encoders that would not immediately work correctly.
It might be possible for us to implement new versions of the FastUpdateCycle() command in to the SimpleMotion API - there are already commits that implement this in Github, so work has started. However, we do not have a solid ETA about when we might be able to implement these functionalities into IONI firmware.
I think I said it wrong - to my knowledge Simucube was not throwing out least significant bits, but it has a limit of 32768 distance points per 400 usec. So it was determined that going beyond 21 bit could in theory overflow distance buffer and make unexpected results. Whether guys made safety truncation - I don’t know. It’s also in theory solvable by extending API with 24 bit distance increment since ioni itself is fine with 30 bit.
If I’m not wrong - non directx effects are part of ioni config. So it would be all in the left block. Anyone from the team should correct me if I’m wrong. If I’m right - iracing and ac would benefit from it.
Oh, that means I’m wrong - I thought DX effects are calculated in Simucube itself. Good to know. Thanks.
@Mika - do you see how to potentially increase velocity calculation precision at small increments? If you look at both graphs above you can clearly see that it could have been better. And, btw, velocity is hitting a quantisation floor with calculations and makes it worse than it could be. Human senses of small movements of objects in hands are incredible high resolution - I’m sure there are something perceivable can be fixed in this area.
?
. 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.
