Search results

We don't have information about these series protocol. Maybe @jonnyGURU can help?

It's OK if it's large, it dumps a lot of internal data. But the file you posted doesn't seem to capture the sleep -> resume sequence. You need to have Debug Mode active while that sequence and when the erratic data is shown.

Can you capture that situation in HWiNFO Debug File and post it here? I need to check raw data to see how to filter them out.

This looks like a bug in NPU drivers. Try to re-install them.

That's temperature of the Voltage Regulator on mainboard. 90 C is quite high but not dangerous.

Press Del key over the sensor item or entire heading.

Such selection isn't supported via CLI. You'd need to manually disable monitoring of sensors and then start monitoring via CLI.

HWiNFO reports the value set in memory controller per specification - ACT to ACT (different bank group in DDR4) minimum delay. The others probably mean the tRDRD_dg.

Thank you!

Probably one of the GPU memory rails.

Try to disable monitoring of the MSI EC sensor.

Will be fixed in the next (Beta) build.

As I said, the targeting doesn't work properly for some titles because their workload isn't properly reflected via D3D interface. Note, that to use a custom PID, you need to also disable the "Automatic targeting" option, otherwise it will override your setting.

Update: I have identified a potential issue that could be causing this problem. It will be fixed in the next (Beta) build. But please note that since the currently running version performs the update process, it will require 2 updates for the fix to come into force.

Thanks, that would explain a lot of things. Could you please enable Debug Mode in HWiNFO and repeat the automatic update procedure while TRCC is running? Then please provide the HWiNFO64.DBG file that was created. That should tell me what's going on internally to diagnose the problem.

Automatic targeting uses process with highest GPU load. Unfortunately for some titles this doesn't work properly as they don't reflect the load via DX interface. The other requests are currently not supported.

AFAIK RTSS injects its own output into DX, perhaps that causes issues in combination with PresentMon. I'd suggest to report this to respective RTSS forum.

I see you used a wrong PID - the correct one is 13588 but you entered 13558.

No. There's no standard that would specify how to interpret serial-port data from such custom devices. Each solution requires dedicated support.

Connect some USB device into the respective USB controller which should keep it active, or prevent it from powering off in Device Manager.