Fiery

Apparently the ACPI BIOS provides a stuck temperature on your particular notebook, most likely due to a BIOS bug. Just ignore that value and focus on the other CPU readings that do change dynamically. Regards, Fiery

We've specified the changelog properly when we've updated the app from v1.45 to v1.46, but for some reason the Play Store fails to display the up-to-date changelog. I guess it's due to a bug in either the Google Play Developer Console or the Play Store. Anyway, here're the changes in v1.46: - Improved support for Galaxy S8, Galaxy S8+ - Window resizing support for Samsung DeX - Fixed: core architecture detection for Snapdragon 435 (MSM8940)

Before pushing Win + D, was the SensorPanel basically placed over the Taskbar?

We cannot push the price down, so a cut-down version would cost the same as the full version (Extreme) right now. It would mean that we would have to raise the price of the current edition by 25 or 33%, _if_ we decide to go down that path.

Thank you for your feedback and your kind words

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Sensor Profiling Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Thanks, Fiery

We haven't yet found a way to detect those states. We'll also need to find out how to integrate them in the existing AIDA64 hardware monitoring module framework, since that one doesn't support yes/no states properly yet. Please give us a bit more time on this

Time should be easy, but with the date, how would you define the minimum and maximum states?

We're not planning to enable animations simply because it would consume a lot of system resources to update the SensorPanel more frequently than 10 times a second -- which is the 100 milliseconds update rate that is available as the maximum update rate right now. A fluid animation would require 30 or even 60 updates per second.

Do you have DPI scaling enabled on any of your displays? What is the native resolution of your displays?

Thank you for the feedback

Thank you. We suspect that your system may be using a special SMBus mux that effectively hides SPD memory modules from 3rd party application. Only Dell knows how to switch the mux in order to let Windows software like AIDA64 to read the SPD data and to measure DIMM TS temperature readings If you have a good contact at Dell, he might be able to provide you with the technical guidelines on how to handle the mux. Although according to our past experiences, manufacturers tend to keep such information as a secret Regards, Fiery

I've just sent you a private message about this issue

Do you mean that AIDA64 should be able to monitor the 9 temperature sensors managed by iCX? If yes, then we'll need to look into that. Do you know if EVGA's own monitoring software is already capable of monitoring those 9 temperature sensors?

Close AIDA64, start Registry Editor (REGEDIT.EXE), and navigate to: HKEY_CURRENT_USER\Software\FinalWire\AIDA64 Remove the following entries: PrefWindowPosX PrefWindowPosY Then close Registry Editor, and start AIDA64

Here's the above mentioned AIDA64 beta update to implement support for LSI Nytro Warpdrives: https://www.aida64.com/downloads/latesta64xebeta Thank you for your help!

Here's the above mentioned AIDA64 beta update to fix the Asetek LC protocol timeout issue: https://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

Maybe you've minunderstood my posts, so let me clarify. If you choose the POS VFD module, it won't work with your LCD, since it is designed for POS VFD displays. If you select the Pertelian module, it won't work, because it was designed for the original Pertelian X2040 LCD device, using FTD2xx USB bridge chip. You on the other hand seem to have a 3rd party, custom-made LCD device that uses a PL2303 USB bridge chip. It is not a Pertelian device, it just uses the Pertelian command protocol. The current Pertelian module of AIDA64 will not work with your device simply because it expects to have a FTD2xx USB bridge chip, and it doesn't support RS232 protocol directly. So you cannot select the COM port to use, but it will default to using the FTD2xx API instead. However, in order to make AIDA64 compatible with your device, we've implemented support for RS232-connected Pertelian-compatible LCD devices in the latest beta version of AIDA64 Extreme available at: https://www.aida64.com/downloads/latesta64xebeta If you go to the previously mentioned Pertelian page of the Preferences, you will see that now you can select the COM port as well as the LCD type (resolution). Let me know how it works with your device.

In order to clarify the nature of the issue: you are using AIDA64 Business, and you go to main menu / Remote / Remote Control, you enter the IP address along with the port number of your choosing, press OK? Is it the place where you would need AIDA64 to handle the port address selection in a smarter fashion?

We used to have plans for Steam, but we've shelved that since as it turned out, Steam limits the way we release maintenance updates quite a bit. So let's just say the way we manage updates to AIDA64 is not compatible with Steam right now. It would be possible to make a special "AIDA64 for Steam" edition, but it would have to have a different roadmap, a different way of managing updates, and we're not convinced the number of users who would only purchase an AIDA64 license on Steam (and refuse to purchase it in our own AIDA64 Online Store) is high enough to justify the additional work and efforts it would require.

If you have a Pertelian device, do not use the POS VFD module: even if it says "Init OK", it won't work. Use the Pertelian module.

You can enable it on the AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / Pertelian page.

Pertelian X2040 LCD is already supported. But, it's not supported as part of the POS VFD LCD module, but it has a separate, dedicated module named Pertelian

It's normal, and it's because the Computer / Sensor page and the hardware monitoring module of AIDA64 (that consists of the Sensor Icons, OSD Panel, Desktop Gadget, SensorPanel, External LCD, Logging, External Applications features) use separate sensor measurement threads. It means that they can indeed measure different values at any given time. And in many modern processors the temperature measurement diode is very sensitive to the actual CPU load, and can fluctuate several degrees Celsius depending on how demanding a task is currently executed. And the 2 different measurement threads I've explained above do not use the same code, and so they put a different amount of load on the CPU.

Thank you for your ideas. We're not planning to enable animations simply because it would consume a lot of system resources to update the SensorPanel more frequently than 10 times a second -- which is the 100 milliseconds update rate that is available as the maximum update rate right now. A fluid animation would require 30 or even 60 updates per second. The custom gauge configuration is already too quirky and complicated, and we're not planning to make it even more complex by doubling the number of states. As for the update frequency, that's again, would require too much system resources. And on most computers polling all the sensor devices take more than 100 milliseconds anyway, so you would never be able to reach the desired 30 FPS update rate with the SensorPanel anyway