SimuCUBE Open Source Firmware: Beta version 0.4.1 BUG Reports

one other thing i noticed. sometimes the friction and inertia values update/change by themselves.

for example, set friction and inertia to 1.2% each, let them auto-apply but don’t save them.
leave the GUI open and go into iRacing and drive some laps. exit iRacing then bring the FFB GUI to the front.
the friction and inertia values are now 1.18% each. not the 1.2% i originally set.

i didn’t save the values and reload them, i just set them, then went into iRacing for some laps.

The code that checks these parameters has been revised a bit for the next beta, so lets wait for that before investigating this further.

This happened to me also, only by restarting the simucube got it to
work again properly.

One thing I noticed and might have been fixed for the next version already, but there is no max or min width / height for the configuration tool window. Meaning you can size then window over the settings or make it larger than it needs the space.

Yep, its not a bug, its just a feature that needs to be set at some point.

UI will be tabbed so that status and profile will be visible in the main tab and other buttons and actions in another. No need to waste time trying to fine tune it before doing it all over again…

tonight i sat down, opened the GUI and found it wasn’t connected.


i pressed the e-stop, nothing. released e-stop, nothing.

i then took your suggestion and pressed the Enable Ioni USB configuration button and loaded Granity. I was able to connect and see my settings. I then disconnected from Granity and pressed the Disable Ioni USB button, then the GUI showed it was connected and everything worked normally after that.

i don’t remember doing anything odd or different last the last time i used it. just quit iRacing (worked great in-game!), closed the GUI, left the simcube turned on and the e-stop released.

That is really strange. Lets wait for next beta before doing any fixes, as I don’t think it should be possible to send any commands to the firmware successfully and at the same time being disconnected somehow.

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?

Miguel

Thanks for the report. I already went over the code once, so please report that again for the next closed beta, if it happens with that too.

1 Like

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.

What would be the CPR value for that?

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

No button reading implemented yet, sorry.

Do you know exactly off hand. I thought I saw 4096 but I could be wrong. Dave supplied it so I did not question it.

4194304 encoder count per revolution in the UI

No problem. Thanks for clarifying

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.

Close enough to your reported values, then…

Mika, can I lower the 22bit value in Granity to something lower for the time being?