Firstly many thanks to you and the team for an awesome product!
I upgraded recently from MMos to the Simucube firmware and have been having the same issue where the PC doesn’t boot when the device is switched on. I followed the steps you suggested to test this, and can confirm that the PC booted successfully when the Simucube was switched to firmware upgrade mode. After power cycling the Simucube to return in to its normal state, the PC again would no longer boot with it switched on.
Basically I have the same issue described by Elliot:
I’ve tried both USB 2 and 3 slots with the same results. In case it’s of any use, other hardware is as follows:
Asus Maximus Hero vi mobo
I7 4700k CPU
Logitech G25 shifter via Bodnar adapter
Fanatec V3 pedals
Fanatec BMW rim with Bodnar “Formula Rim” USB mod
Small Mige with 10,000 encoder
IONI Pro HC
Incidentally since I’m here, here are some other thoughts since installing Simucube
Assetto Corsa feels great, better than MMos!
rF2 has been a struggle so far to get it feeling smooth, but I’ll need to do some more tweaking before I reach a conclusion
Automobilista again feels great - much better than MMos.
Just bought ETS2 in the xmas sale, and am looking forward to having some kind of FFB as currently there’s nothing whatsoever. It seems the upcoming firmware fixes this?
Anyway hope this helps and let me know if you need any more testing…
Can you test again with the following procedure: Put the SimuCUBE into the IONI USB Configuration mode, and then restart the computer. In that mode, it won’t send any USB HID reports to PC, but of course the USB interface is the same. This would help in pinpointing if it is indeed the descriptor OR the USB report sending OR both that makes this happen.
OK, so the PC boots fine with the SimuCube switched on, but in IONI Config mode.
Just to confirm, after switching it back to normal operation mode again, the PC failed to boot until the SimuCube was switched off.
So this issue is likely just because SimuCUBE is sending the USB reports as fast as it can to PC. Maybe these bioses get overwhelmed by this, and are not successful in trying to figure out if the device is a keyboard, mouse or something else.
Based on the recent round of your test, I have figured out how to handle RESET and SUSPEND callbacks from the USB stack, and disabled report sending if state is suspended. This change will be included in the next version, to be released this week.
Now that I know what could solve the issue (disabling usb report sending when a suspend or reset request comes from a pc), I was thinking about just manually pausing the report sending for, for example, 30 seconds at those events.
How would people react if wheel started to update only after a while of being connected? I would make it so that updates would start right away when Configuration Tool requests any status reports.
Yep, nice one Mika. I should be installing the new F/W tomorrow (WOOT!) so I’ll let you know if it changes any of this behaviour…
Otherwise your last suggestion sounds fine.
Can you think of anything in my hardware setup that might be causing this? The Bodnar adapter for the G25 shifter used to do the same thing in fact, then Leo recommended me a different version of the firmware which sorted it out. Also, installing a PCI-e USB card and using that instead was another way of fixing it.
A fix for this would be nice, but tbh it’s not a massive inconvenience, and it doesn’t seem to be a very widespread issue? Plus I’m kind of in the habit now anyway of booting up the PC before I switch the wheel on