Hi
I upgraded my PC, everything works fine. The wheel is detected in Windows, it beeps happy and the blue light is on. Starting TrueDrive (I tried 2021.1 and 2021.4.4, it just doesn’t respond. I get the TrueDrive screen, but it isn’t responding.
I did get the suggested windows redistributable thing suggested here https://granitedevices.com/wiki/Simucube_2_True_Drive_releases …
Anything I’m missing here?
We have had this report recently, and I fixed an obvious crash that was unexpectedly caused by the compiler switch we did for this release when there were a few more profiles than what we have on our testing system.
Please make a shortcut to the True Drive.exe and add word
log
into the end of the shortcut’s target field (in the properties).
Then a log.txt will be generated. Paste the content of that file to here or send it via email, and I will have a look. There might indeed be another bug…
Hi Mika, this is the file (it isn’t large)
12:08:00.809: with logging
12:08:00.872: Opened style file
12:08:00.872: Warning: QObject::connect: No such signal TelemetryConsent::TelemetryConsent::consentChanged(TelemetryConsent::Consent c)
12:08:01.026: Warning: QMetaObject::connectSlotsByName: No matching signal for on_wirelessbutton_clicked()
12:08:01.026: Warning: QMetaObject::connectSlotsByName: No matching signal for on_exportButtonMenu_clicked_one()
12:08:01.026: Warning: QMetaObject::connectSlotsByName: No matching signal for on_exportButtonMenu_clicked()
12:08:01.026: Warning: QObject::connect: No such signal MW2::activeProfileChanged(int index, profDataNew *profile)
12:08:01.026: Warning: QObject::connect: (sender name: ‘MW2’)
12:08:01.026: Warning: QObject::connect: (receiver name: ‘MW2’)
12:08:01.039: wheel image: attempting to load: “wheels/wheelimage.png”
12:08:01.054: “C:/Simucube 2 True Drive 2021.4_4/simucubeprofiles.ini”
12:08:01.054: “C:/Simucube 2 True Drive 2021.4_4/profiles_autobackup.ini”
12:08:01.054: “C:/Simucube 2 True Drive 2021.4_4/profiles_autobackup.ini”
12:08:01.070: loadIncludedFirmwareVersion: included 1.1.13
12:08:02.043: EULA previously accepted.
12:08:02.249: Disconnected state
12:08:02.249: unable to open device, pid: 3423
12:08:02.249: Connected to SC2 Pro
12:08:02.249: reconnected
Thanks. It appears to hang on the first packet send to to the device. I wonder what is blocking it…
I connected it to a front USB 2 port and it got further. Updated the firmware and it works. But not in the rear USB3 port I used before.
But it is detected in this rear USB3 port, I can even steer the wheel and see the axis in DIVIEW.
Just TrueDrive doesn’t load in this case.
Also it is connected via the same cable and hub as it was for over a year on my previous PC, so that never was a problem. I have no USB2 ports on the motherboard anymore, as these are dissapearing with time…
EDIT: it was also connected to a USB3 port on the old system, not USB2
It also works when directly connected to a front or rear USB3 port.
But not via the USB3 hub where it had been working fine, connected to a USB3 port on my old system.
Again, windows detects it, DIVIEW sees the steering axis, but TrueDrive won’t start.
Sounds like some type of migration issue where windows moves the previously detected devices from port to port. It might be good idea to turn off Simucube, go to device manager, and delete all hidden game controller devices + related USB composite device that could be related to Simucube.
But thanks for reporting this. Something unexpected for sure!
Also, such an issue where windows was blocking packet transmission (but not reception) to the device was in the few very first released Simucube 2 firmware versions, and it was related to USB enumeration going wrong in Windows due to a firmware bug. This likely is not that issue again…
So this is weird. Connected via the hub, so TrueDrive won’t start…
Sims also don’t start. AMS and RF2 just a black screen ‘not responding’.
Then I unplug the USB out of the SimuCube and they start loading.
So this hub and Simucube that worked perfectly fine on my last mainboard, now do this! Odd.
Yeah, so its the same thing, all packet transmission from any app in Windows to the device are being blocked due to the enumeration issue. The code in 2021.4 version is exactly the same proven code that was working in 2020.10 and versions before that.
It is a Windows issue.
It works on a different rear USB port as well… The problematic ones are specifically labelled as USB 3.2…