I just did had the exact same behavior.
Not sure if I can replicate it, but what I did was:
Configured the wheel with the configuration tool
rebooted the PC without powering off the wheel
started the configuration tool and it showed “Disconnected”
powered off and on the wheel and it was “Operational” again
update:
could not replicate it
update 2
now, I could recreate the problem, by doing the above.
So it might not happen every time.
Additional info, if this happens the SimuCUBE Gamecontroller property page does also not show any movement.
I will try to replicate this on the bench.
I have always been in the habit after any changes to the drive ( Argon, Ioni or Simcube) to restart the control. This seems to eliminate some weird behaviors.
I finally managed to get around to installing the beta firmware. I made sure to take notes of all the common bugs and work arounds that have been posted so far. After 2 hours of messing around with the settings I had no issues whatsoever so great work you guys.
My only issue is that in Granity I had set the center frequency to 1.5hz per my old settings. Under the GUI however it shows the center frequency is now disabled. If you use a value of 2.0hz then it works just fine and its not disabled. So it looks like any values under 2 will show as disabled in the GUI. So i take it any values under 2 will not work and could that possibly be changed in future updates?
Using BiSS encoder and driving DW12 at Mid-Ohio I noticed it yesterday and was able to replicate it several times today as well.
There is a large bump coming out of the last corner after pit entrance the jolts the steering. It is throwing off the steering by approximately 6 degrees. I can visually see the change as my real wheel loses alignment with the on screen wheel.
After this happens I cannot re-centre using the UI centre wheel reset button. This when I am sitting in the pits.
I can reset the centre while in pits anytime until I get the off centre glitch over that same bump.
If I exit the UI and start Granity I and see in the testing page that my wheel is in the correct point when centred in Granity so that it is not the hardware that is moving.
Running AKM53K with Davy Watts supplied Hengstler 22bit BiSS encoder.
edit: Further testing a few minutes ago. After resetting centre in UI and powering down PC and wheel, upon reboot and starting UI, the UI shows the previously zeroed settings off by 14 degrees. Granity testing window shows wheel centre to still be true to original settings. I was able to get it to do this both times that I had the loss of centre.
I was also able to get it to go off centre with a quick wheel correction. This time when checking it was off by about -4.12 degrees. When I used the UI reset centre it defaults in the UI to -5.61 degrees.
Other than that the BiSS is even smoother and more precise than the previously used 10k encoder…as Beeno has already mentioned.
just to confirm: buttons should not work as of now, should they?
on one of my rims I have the paddles connected as buttons to the simucube, but they are not registered
Four million… hmm. At the office, I’ve tested up to 2 million and something.
It is possible to loose the track of position just like that, if the firmware does not give torque commands fast enough. Encoder is being read back from Ioni with the same command as the torque is given. For the beta, it was at 10 kHz, and for the next version, we have settled upon 2.5 kHz to have a stable base to build time-dependant effects.
Its difficult to say if there is some strange problem looming here…
Adding that every 0.0001s the encoder position is read into an unsigned 16 bit value (0-65535) which is then on the firmware wrapped to 32bit counter. This is a limitation of the software API that we use to communicate with Ioni.
Reliability of this is dependendent on the 16bit value never going around between updates. 65535/4194304 * 360 = 5.62.
You can just decrease the bit accuracy in Granity, it just drops one bit of accuracy, so its ~2M. You will have to run the wizard again too. I think it won’t make any difference to feel at this high levels of CPR.
Sorry, not 100% sure what to change the current 22bit setting to? 21bit?
Or just experiment reducing until the error goes away I would guess or around 2 million in the UI.
We have also other fixes in mind, for example, Ioni could give “saturated” values for the 16 bit value so that when we read it, it will have never overflowed. But things like that are not on the top of the list for fixes. Can’t we agree that 2 million CPR is enough?
It will be also valuable to know if it happens for you with 2M CPR, or whether you would need to go as low as 1M CPR. But, as we all know, even that is quite high compared to typical 20000.
Hello Mika,
Will be testing it tonight when I get home.
Really I thought that the 10K 40000 PPR was more than great. But you can actually feel the difference on the high resolution BiSS encoder.
Almost impossible to find absolute centre when I was setting my index mark as close to zero in Granity testing window. 6000ppr is about as close as I could get.
