SimuCUBE Open Source Firmware Development Update Thread

Hi all, i’ve a similar problem, in Assetto Corsa i lost FF and the steering wheel discennects withou any apparent reason. The first public firmware release did not cause any problems. With 0.8.4 i have e disconnect ad reconnect problem, i lost the steering wheel for one second, with 0.8.2 i lost the steering wheel and i must exit form the game and turn off the steering wheel. with 0.8.2 i see about 250 smbus error.

SimuCUBE based OSW kit
Servo Motor: MiGE 130ST-M10010 20Nm 10000ppr (40000cpr)
PSU: Mean Well 480W (Noiseless) 20-30Nm
Servo drive: Ioni Pro HC (25A)

Based on my find about fault behavior on the weekend, it appears that any other fault (overspeed, over voltage, etc…) will also trigger smbus reset, and increment of that counter.

This will be fixed sometime.

Can you trigger a fault by using Granity testing tab?

ok , that happened to me one single time, but previously to that AC freezes before exiting, same with Z1 dashboard.

i had to go to task manager and kill Assetto Corsa.

next start AC again and the simuCUBE have effects but the car have not direction and go straigth .

simucube configuaration tool says operating mode disconected.

a quick off / on did not solve it, the simucube did not phase, off , wait for 10 or 20 seconds then on , simucube did phase and all was ok again.

i change desktop resolution to 5760x1080 instead of 5800x1080.

since that AC closes fine and i do not have any error nevermore in any game.

Regards,

Yes, i can trigger a fault. I test to simulate a Over speed fault, i reduced FEV and tested. When i exit from granity i had to restart motor.

Restart motor by actuating e-stop which will clear faults, or actually restarting the whole SimuCUBE?

I restart Simucube but the counter has not increased.

The counter is always reset at SimuCUBE power-on. Good news that it has not increased.

I’ve started a thread to be more specific for trying to find the causes of different types of recurring problems.

If we create a profile with less overall strength it will also affect bumpstop strength. Is there a way around this without having to change bumpstop maximum strength manually every time when switching profiles?

1 Like

Hi Dave,

The overall strength is now set via adjusting the motor current. This is to negate the need for the confusing two-slider strategy (signal scaling and motor amperage setting).

As no consumer wheels have that type of setting, we wanted to remove the need for that. Eventual target remains to remove access to Granity altogether for average users. Whether this is done with the input signal scaling (like it was in 0.7.x series and earlier) or by scaling the motor amperage (as 0.8.0) remains to be seen, but the result of the 0.7.x vs 0.8.0 poll seems to indicate pretty conclusively that if there should be one slider, the motor amperage slider is the one to have.

The result, however, is that also the bumpstops are of course affected. There is no way around that for now, until I revisit the bumpstop code. Boosting it to be proportional to the motor current setting is one option. There is also the bumpstop damping effect that could be redone to utilize the general damping that has since been implemented to SimuCUBE firmware.

1 Like

I have to add, that we feel that every slider that can be used to “do the same thing” as another slider, should just be removed to reduce confusion.

Depending on how much you reduced the FEV you might not be getting the error that mika is wanting as if the FEV is too low the servo will fault WHILE phasing and it probably won’t do what mika is attempting to have done… Set the FEV so it shows about 1-2 rev per sec in granity if you were not already at around this point. You will then be able to go into iRacing or another game and get the wheel to fault by turning the wheel fast. you can then reset it by the e-stop to regain function and not have to restart the SimuCUBE which will clear the fault.

Update: getting really close to next release. Solved motor fault reason parsing with Tero. It was totally something I overlooked. Also found out that effect loop was running at 1.25 kHz - and had been, for quite many releases. Upped the rate back up to 2.5 kHz :slight_smile:

7 Likes

Might have to take that word back, as upping the rate back unforeseen consequences elsewhere in the code.

Maybe it has a quick fix :smiley: :wink:

1 Like

I can just choose to leave it at 1.25 kHz for now, as nobody seems to have noticed.

Could just put it back to 1.25k for the time being and release. :slight_smile:

Finally doing the rFactor 2 test just now.

1 Like

Please do move it back up to 2.5 kHz.
But maybe not now if it will delay the new firmware by a lot, but for the next release.

And could you tell us until what FW version it was 2.5 khz.
was it before or after the scaling method was changed? or way before that, or even public beta ?
maybe i never tested a version with 2.5kHz :stuck_out_tongue:

It appears that I made the change on July 20th already. I must find out what caused me to do that change and whether it can be reversed. I don’t believe changes in the effects can be really felt between 1250 Hz and 2500 Hz - please do take notice that these are not related to the torque bandwidth, that is a different thing.