SimuCUBE Open Source Firmware Development Update Thread

Mika · 23 January 2018 20:51

It is more like the connection is not being established, sometimes not even on startup, and usually not when trying to reconnect after being connected via Granity.

Mika · 24 January 2018 18:42

At work today, I think I partially found the issue. But at work, old Qt is uninstalled and Qt 5.10 is still downloading so can’t do real end-to-end testing easily via the Configuration Tool.

Release before the weekend is likely.

Mika · 24 January 2018 19:44

Testing at home, however, revealed great success.

Mika · 24 January 2018 21:31

anyone up for pre-release testing?

Ippai · 24 January 2018 23:06

Desktop spring effect doesn’t work it just turns the wheel to the left bumpstop. If you untick it it can take up to 30 second for it to disable.

Mika · 24 January 2018 23:09

Thanks for being a good tester.

It does work on my rig.

Mika · 24 January 2018 23:10

Does the SimuCUBE Configurator Tool tell any different status as it does that?

Mika · 24 January 2018 23:11

And you did also do the firmware update wizard?

Ippai · 24 January 2018 23:13

Tried it a few times now. Turned of SimuCUBE and re ran config tool. Makes no difference. No bus errors. Installed FW on the HARDWARE tab with the update button

EDIT correction the right bumpstop

Mika · 24 January 2018 23:13

Ok, I will investigate this tomorrow.

Ippai · 24 January 2018 23:23

@Mika Re flashed and turn SimuCUBE off by the power after flashing, turned back on launched config tool. Ticked center spring now it works but doesn’t centre exactly to the centre postion (12 oclock) but returns to 1130 clock position

Mika · 24 January 2018 23:25

Try with increased force and/or more narrow steering angle limit.

I made it quite gentle to begin with, to avoid any oscillation issues.

Ippai · 24 January 2018 23:29

It never returns exactly even at 80 and gets worse at 100%. At lower strengths it returns to all sorts of positions.

Tested at 1040degrees.

Edit Yeah Small Mige Sincos. and yeah its not something I would use either. Just testing

Mika · 24 January 2018 23:31

Strange. Small Mige?

I think not many people will want to use this feature, and the target is to center somewhere near the center, not exact.

Mika · 25 January 2018 08:25

no showstoppers during the night. Therefore…

Mika · 25 January 2018 08:36

v0.9.1 has been released. I would appreciate testing of the fixes and also all the new features since 0.8.11/0.8.12 release.

phillip.vanrensburg · 25 January 2018 10:32

Cheers Mika,
I just got home, and we have a long weekend here in AU. I shall do some testing tomorrow again

Stephane_Charrier · 25 January 2018 12:48

Hello,

I tested again this morning on RaceRoom, and the FFB always disappears after a time always equal to around: 1 minute and 5 seconds.

I tested more categories and circuits and also other settings, it’s always the same: total loss of the FFB.

Mika · 25 January 2018 12:59

Interesting. That is definitively a RaceRoom bug!

In DirectInput, there is an unsigned 16-bit integer for effect duration. Duration is specified in milliseconds.
Maximum duration is 65535 milliseconds = 65.535 seconds = 1 minute and 5.535 seconds.
Infinite duration is 0.

I very much appreciate your precise measurement!

I will add, as a workaround, code that Infinite duration is 0 OR 65535 milliseconds.

Mika · 25 January 2018 13:13

OR its a bug in the FFB interface code, hah. According to Microsoft documentation, Infinite is -1 instead of 0. Either way, this will be corrected I will have to find out what Raceroom actually outputs to this.

… actually, we do know, as you measured it to be 65535