Doesn’t reduce torque output but if the wheel starts moving crazy fast in velocity it will trigger a fault…
This may NOT work with all wrecks (if you are holding onto the wheel) but if set low enough it will stop it from ripping out of your hand… Problem is if you set it too low you may find that YOU can fault it with a quick oversteer correction.
So I have ordered the HEIDENHAIN ERN 480 Sin-Cos encoder for my Small mige. This encoder has 3600 lines. This gives a final maximum resolution of 3.7million CPR as the seller says. (3600x4(Quadrature)x256(interpolation))
No, you are ok. But you have to set interpolation one step lower, and that will be officially supported resolution. So no dramas!
edit: Although IONI officially supports 15M resolution, according to documentation, the limitation to ~2M comes on SimpleMotion V2 protocol and update rate to SimuCUBE.
IONI offers 16x, 64x and 256x interpolation - so selecting 64X will be ideal, as you will still have just over 900k CPR resolution then, which will be more than adequate for this application. Compare that to the 40k max the 10K incremental guys are using today, and it’s 23x higher resolution - not bad at all
I know you would Mika, as I said elsewhere, in the end most of us would not be able to tell the difference between 500.000 CPR to 4.000.000.
What ever the result is, we are so excited about the beta to be published soon.
I am running the number 1 sim hardware forum subject in Turkey and people are awaiting madly to hear what I will be saying about the results of high end encoder + Simucube Firmware combination.
Let’s not bother you with these things
Keep up the good work.
Hi Ben/George,
I have mentioned this to someone over in iRacing too just a few minutes ago, coincidently, and will ask Mika to ask Tero about it. Should be easy to code into the IONI FW.
@Racing: Not yet available to download as public beta, we are still testing a few new features in the coming week or so before it will go public.
Mika is just busy implementing Profile Management, which proofed to be a bugbear to implement, as it disrupted a lot of the existing code - but he is making very good progress - so not to much longer…
Most probably we will not implement that either as it would require making the change to Ioni firmware, Granity, and at the same time most likely the sincos settings would become incompatible for current users after this change. All this for no perceivable improvement and just extra work.
Successful debugging session today with profile management. I’ll have to take my words back; debugging Qt is not so easy.
Now the management dropdown works, and values can be changed, and they show for each profile… New profiles can successfully be added too. Tomorrow, I hopefully also fix naming of the profiles and debug things a bit more. Need to implement “this is current default profile” indicator. Getting close!
You can use the full resolution, the caveat being that if the servo moves faster than the Simple Motion Bus can detect the change in position there may be instances where you will loose your Wheel Centerpoint location which will offset the wheel… Other than that all will work OK… So far in my testing the only time I experienced this and only once was after a wreck which essentially totaled the car and would have put me out of a race… I wasn’t the one testing at the time but it was on my rig… I believe that there are a couple other instances with very hard curb strikes by others that triggered the issue… This could be a Rare or Common occurrence how much so we do not know but it seems to occur only under extreme circumstances such as a wreck… Basically though if you never want it to NEVER occur you have to run the Points below the Maximum Support for this application at approx 2mil by setting an encoder resolution/interpretation below that number of points. So you haven’t totally over purchased and you can use the full resolution just be aware that the issue of misreading the position relative center could occur at any time if running higher.