IONI drive is in torque controller mode in the SimuCUBE application case, as all the games output torque data. Positional mode would be interesting advancement, but no support from games and DirectInput is a problem. The IONI torque controller is black box to me, and I’m not sure how much details we would be willing to give even if I had access to that firmware.
SimuCUBE gives only torque commands via SimpleMotion fastupdatecycle() command. The same command also reads back the differential encoder position. Any other commands, for example reading currents etc, would drop the update rate to much lower as those would need to use normal parameter write commands in the bus. My guess is that the torque command rate would drop to about 100 Hz.
SimuCUBE firmware uses the encoder position information directly to calculate velocity and acceleration. These are only required to be used when the game has set FFB effects that require these, such as Inertia, Friction and Damping. In that case, the difference that these effects make to the resulting torque command to be set to IONI goes through a low pass filter. I just implemented these effects for 0.8.11/0.8.12 release as a new feature, and the LPF is in for this from the start.
Noise is not measured in ppm. Think about it - momentarily you have clean signal of 300K count, but in terms of accuracy you barely have 20K CPR. While with cheaper 40K CPR you have twice higher accuracy. So I wouldn’t say that signal of SinCos is good. Yes, it has higher resolution and for the smoothness feeling it’s important. But signal is by far not good. It would be way better if SinCos was 8K ppr + 64x analog signal.
Drift can’t pass beyond CPR digit, so it’s not an issue.
Resolution is ability to resolve real signal. I demonstrated that 2M has more resolution than 0.5M. You can filter out noise from 0.5M as much as you want, but you will not get 2M resolution. So if position calculation is well filtered and approximated from physics (from known acceleration out of currents and previous speed) and drift is slow enough - we should get proper 2M counts that can be trusted as incremental data over short period of time.
I am still not sure how exactly position is used beyond reporting back to DirectInput.
For the reasons above I don’t think drift is an issue.
I’m confident that drift will not pass over CPR tick, so it’s limited to 1/8000 of the turn. I think with proper study we will find that in reality it constrained even more.
Anyway, even without currents - you can filter position by just knowing facts that there are limits on acceleration change as well as limits on velocity change from that plus just absolute limits on velocity and acceleration and so you can forecast next position and range. So you can use forecasted position range to filter out values from the bunch of positions you get. But knowing a torque helps process acceleration direction change better, so certainly it would be further clarified. But it doesn’t worth frequency lost, for sure.
Velocity from 2 points position is very poor even at 2M at movements that are quite sensible. You certainly use more than 2 points, so I guess if you have enough values to process through LPF it’s probably good enough. You know better.
Yes, its conceivable, although wheel would have to spin faster than 32678 counts in 1/2500 s. This would make it faster than around 39 rev/s assuming 2.1M CPR. Given that there might be some occasional trips where 1/2500 s rate can’t be maintained, we could assume that it would maintain half-rate, so around 19.5 rev/s. Thats still crazy fast. If one doubles up the CPR from here, it would make it around 10 rev/s, or there abouts. Still quite fast, but could be plausible if there are sudden jolts etc.
I’m almost sure that I’ve lost center during FFB on/off during opening menu or something like that.
So it’s most likely was a hiccup way longer than 1/2500s.
My RPM limit is 1000, so I doubt it would let it spin 39rps.
Yes, you measure something else such as volts or counts, but the result can be represented in ppm, but if this is not the favorite unit of measure, other unit can also be used.
Where this 300k counts is derived from and then as a reference to the previous, there is this other unit 20K CPR and 40K CPR that is for full turn? Can you elaborate your findings a bit more?
Hmm… would you point to the make and model of this encoder, preferably with price information also?
Such an encoder that has drift such that has no boundaries, is not useful for motor control.
In order to predict position in a system where there are 2 actors producing force to the system (the simulator hardware and the man), it is quite challenging to simulate and know the position from that. So if I understood your idea correctly, it sounds quite futuristic that one would measure output current, use it to simulate force and by knowing the inertia (when the human hands are on the wheel + how tightly the person holds the wheel and as addition to previous we need to know the total amount of friction of the the system), derive the acceleration from the known information on embedded hardware in realtime in order to generate second reference value for position when the feedback rate is set to 2 million counts per revolution. Probably takes about a quite some time with a very powerful computer without any real time requirements. It is quite doubtful that there would be commercial possibilities already on the previous calculation requirements, but since the only force causing acceleration to the wheel is not the current through the coils of the motor we also need to count in to the equation this the man who turns the wheel, how do we predict the man’s decision making and amount of force -> acceleration -> speed -> in order to produce anywhere near prediction of position when we do have real time requirements also to take into consideration?
You’re overthinking it. It’s a simple math where you store some array of previously calculated values for velocity, and acceleration. Torque of motor should just give you correction of where acceleration should go. All this just to calculate bracket of reasonable values, so that values out of it can be filtered for the next step. I’m not talking about some complicated Kalman predictions.
So the filter should be some adaptive filter? Why is a low pass filter not enough? As the main torque value always comes from the game and the change to it by the damping/friction/inertia filters is usually very small.
To be honest, I don’t know if it’s worth it because I don’t have enough knowledge of all processes happening inside. Somehow people feel the difference of SinCos. Or do they? Placebo is a real thing.
If all that is happening is rounding position down to 26K of DirectInput resolution and a game returns target torque - there should be no difference of 40K or SinCos. What I can see is the difference in resolution of movements that I can clearly feel on 2M vs 0.5M. But is it used anywhere at all?
My understanding is the only time when you use some positional math (other then lpf and rounding down) is during the implementation of static filters and effects. Am I missing something or key sims are not really using effects much and it’s just for arcades (or some lazy implementation of standing tire friction, like AC)? If so - better encoder data won’t worth much value for effects.
I don’t really understand point of those “filters” - for me they look pretty much as a static overhead effects just to simulate friction in the steering column, damping of power amplifier and some tires resistance which doesn’t even change with speed or angle. Sim supposedly also simulates that stuff, so if it’s doing it right - those filters should be zero and don’t mess with “real” stuff.
Reconstruction filter could use position to predict torque change from the input. Again, it’s some kind of temporary limitation, probably - iRacing could just up their calculation rate, it’s 2017 already and direct drive wheels are too popular among their customers who pay on a regular basis. AC already did it and just small smoothing fixes the whole story.
Maybe torque interpolation based on predictions would make sense to do for low-frequency titles and that would need better positional accuracy. But it’s not easy task similar to frame rates increase for the video. It has to learn a history of what was happening as a result of response, predict, correct and so on. Should be doable, but not easy. And, again, iRacing can do real calcs instead and make it useless. 60hz is a joke, clearly.
So, Mika, I don’t really know. I’m not up to the task if LPF is enough or not. You, certainly, know better.
What you think about whole this hi-res thing?
2 remarkably less servo audible noise. And no noise coming thru the steering wheel. Unless you move the wheel very very slowly and concentrate.
Agreed any other benefit is hard to discern from placebo, so far.
I do plan on going back to the 10K encoder once I’ve driven on the Sincos for quite a while and have been acclimatise to it. I think it should be easier to notice any loss in quality than any gain.
Id also be interested in hearing @bsohn opinion on the subject, in addition to @Mika
Has anyone that ordered a Heidenhain SinCos encoder in the last two weeks at Sim-Tronix received it already or did you at least get a delivery note or any other piece of communication except for the order message? I‘m waiting for any info regarding my order since two weeks and evan after sending an additional email I didn‘t get any reply
This is very true, if no filtering is being set in either IONI or by the game via DirectInput, which is implemented in SimuCUBE firmware.
Yes, all the hardcore sims (iracing, asetto corsa, automobilista, etc…) use just that,and very little other types of effects.
Yes, but those can be used, and indeed are often used, to make changes to how the wheel feels, in addition to making the oscillations not so severe.
It appears that they can’t, as their physics engine is so hard-coded. This has been stated very recently by their programmer Dave Tucker.
This is indeed why we implemented the reconstruction filter - its just not realistic to feel all the square wave notches at 60 Hz.
The high-res thing indeed has not much effect if the user or the game does not use effects, but there is very clear difference (I’ve felt it too) when I wanted to try more dampened feel. They are not placebo effects, the filter is much more stable and smooth when it gets better (more accurate) positional data which is used to calculate velocity and acceleration.
Hello I have installed today the sincos encoder, all went well, the encoder is present in granity and in simucube program with the right values, but when I turn the wheel, the picture in the simucube program does not move and the wheel is not recognised in the sims, please help
