Fiery

There are a few issues with that I'm afraid First, it's simply not possible to take a value from the AIDA64 main information pages tree and use it somewhere else. You cannot use a "pagegroup/pagename/section/field" formula, because the information bits are not indexed in any ways. AIDA64 provides those information for users to check out, and sometimes to write them to a HTML (or TXT) report file, but that's it. It's not meant to be post-processed, or processed on-the-fly by AIDA64 itself either. So every value you would like to add to the already huge number of hardware monitor items (over 1000 right now) would have to be added manually, by assigning the value to be detected or measured one by one. The other issue is that the hardware monitoring module of AIDA64 was designed for the single purpose of monitoring constantly changing (dynamically changing) values like utilization, clocks, temperatures, fan speeds, voltages, power draw and such. It's not meant to monitor such values that would most likely never change, like CPU model, total memory size, video adapter model, ForceWare clock rules, etc. It would be quite an overhead and for the most part pointless to detect such properties 1 or 2 times a second, over and over again. Of course any of the listed values may indeed change, but most likely not while keeping AIDA64 up and running. You can change your CPU and video adapter, or add more system memory, but you would have to shut your computer down and then boot it up again. You can adjust ForceWare clock rules anytime, but IMHO it's much more important to know the actual (current) clocks rather than the profile that ForceWare maintains about clocking. And I know, we've already made an exception with BIOS Version That is also one value that most likely never change while AIDA64 is running. We may add a few more of such values that we reckon would make sense to be monitored, and ones that other users may find interesting. But I'd personally feel best if we kept the number of such values at minimum. You can always use a fixed (static) label to display such information on your SensorPanel and LCD anyway -- although if you keep changing your CPU or video adapter frequently, it may be difficult to maintain those labels, I admit

It is shown as Max Turbo Boost Multipliers on the Motherboard / CPUID page in AIDA64. Regards, Fiery

Try to reinstall OpenAL, it should fix it. If not, then you can disable the OpenAL page in AIDA64 / main menu / File / Preferences / Layout. The VINR0 and Aux readings are bogus values. As you can see, none of them makes any sense That's why AIDA64 will not display them.

We've fixed the issue in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3244gtm3rsb2cxzip

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps.

I do understand your desire to see the fraction of degrees there, but somehow I still cannot imagine what would be the actual, practical use of it. Why is it so important to know the difference between 35.0 Celsius and 35.4 Celsius for example? Why does 0.1 or 0.4 Celsius make a difference? I of course understand the need to know the difference between 1.0 Volts and 1.1 Volts, but I cannot see myself in a position not being content with a 35, 36, 37 Celsius scale If your water is cool, it is cool anywhere between 30 and 31 Celsius. If your system is overheating, it will be hot anywhere between 80 and 81 Celsius, it doesn't matter to know whether it is 80.2 Celsius or 80.6 Celsius -- it's still very hot. The other problem -- besides the amount of work we would have to put in it -- with showing the temperature decimal digits is that most sensor devices are simply not capable of measuring temperatures at such accuracy. So for most of the temperature readouts we would have to show "39.0 Celsius" or "61.0 Celsius", and from a mathematical pont of view, that would be incorrect, since the measurement accuracy doesn't actually tell us the ".0" part. And overcomplicating the whole thing by showing "39 Celsius" for such values where accuracy is zero decimal digits, and showing "39.2 Celsius" where accuracy is one decimal digit would just make things even more complicated. And quite frankly, I cannot see the actual benefit of all that... BTW, it's no coincidence that the overwhelming majority of sensor devices will not measure temperatures with a fraction of Celsius accuracy. Aquaero/Aquaduct devices are designed for the hardest of the hardcore users, but IMHO even their engineers wouldn't be able to tell me with a straight face that there's an actual technical benefit of the extreme accuracy of their temperature diodes. It's a great thing when they want to show off the technical complexity and engineering accomplishment of their products of course, but that's more of a marketing trick

The problem is, you didn't specify a filename extension for /R. So AIDA64 will try to override the file extension to .INI, and it replaces the ".ivanov_2014-11-28" (which it thinks is the filename extension) with ".ini". You can avoid that by specifying the filename extension, e.g.: AIDA64.exe /r $hostname_$ipaddr_$username_$date.ini /ini /langen

Please note that DMI information -- especially the sections your screen shot shows -- is in many cases incorrect or inaccurate. Your notebook features an Embedded Controller chip, and not a very old LM78 sensor chip As for fan control, your system doesn't have to know any RPM values or RPM capabilities for your fan(s). Fans are controlled by changing duty cycle percentage, so the motherboard sets the fan to e.g. 0% to stop it (when the system is cool), or at e.g. 40% under light load, and 100% under heavy load. If you could ask Razer about whether it is possible to measure fan RPM on your particular notebook, and they can provide us the necessary programming information, we would be happy to implement it in AIDA64.

Frequently Asked Questions about the RemoteSensor LCD feature: Q: Does it work on Amazon, Android, BlackBerry OS, Chrome OS, Firefox OS, iOS, MeeGo, Windows Phone, or Windows RT mobile devices? A: Yes, on all of them. Basically any device would work that has got a modern web browser. In case your web browser doesn't display the LCD layout properly, then try to find another, preferably more modern web browser. E.g. on Android v2.3 devices the built-in Android Browser fails to work, but Firefox will work fine. Q: Does it work with Internet Explorer? A: Yes, but only with IE 9.0 and later versions. Q: Is it possible to use it over the internet? A: It is designed to be used in a WiFi network, but it is also possible to use it over the internet. You have to take care of opening the relevant TCP/IP port on your router or firewall though, and if necessary, configure port forwarding too. It is not recommended to use it via a cellular data network (e.g. GPRS, EDGE, 3G, or LTE) connection though, due to the frequent network traffic. Q: Does RemoteSensor support multiple pages? A: RemoteSensor supports only one physical page, but you can use a larger page size than your actual mobile device display resolution, and use swipe scrolling to change between virtual pages. The way it works: let's say you've got a 980x1440 pixel resolution, as reported by the web browser of your mobile device. You configure 980x2880 as Preview Resolution in AIDA64, and you will basically have two pages on top of each other. You can use 980x5760 resolution to have 4 pages, etc.

The collision may or may not happen, since AI Suite background service does have a poll rate. If it is polling the sensors when AIDA64 launches, a collision would occur. If it is between two polls, AIDA64 will launch fine. And since AIDA64 is a process (application), but AI Suite background service is a NT service, there's no way to set their start order. Unless of course you delay AIDA64 launch by 30 or 60 seconds after the user logon.

Thank you for the feedback. As for SPD, both your memory modules have a working SPD chip. Otherwise, the module would not appear on the Motherboard / SPD page in AIDA64 Your TwinMOS module however has the SPD manufacturer ID field and part number fields both set to zero, so it's basically not filled. It doesn't cause an actual issue, it prevents the proper identification of memory module model name.

Please note that AI Suite II, even when you don't use it (when you don't have any of its windows open), it is still using its background service to monitor and poll the motherboard sensors. Even after uninstalling AI Suite, it tends to leave its background service behind and active. Most likely the background service collides with AIDA64 low-level detection module. Note that AIDA64 detects and then caches a lot of hardware information at its startup, and it's crucial that no other software would collide with it when it starts up. Most other diagnostics, monitoring, overclocking and tweaking software (like AMD OverDrive, CoreTemp, CPU-Z, GPU-Z, HWiNFO, HWMonitor, MSI Afterburner, Rivatuner, SIV, SpeedFan) are synchronized with AIDA64 and each other, but Asus refuses to implement the necessary and standardized synchronization technique. If they would, such collisions would never occur with other software...

Strike7 API has quite a few weird issues. Sometimes implementing a workaround fixes it, but the major problem lies in the SDK that Mad Catz designed. Please report the issue to them, and we'll also ping them to find out how can we work together to fix this issue, and also the touch-related other problems. Thanks, Fiery

Hard to diagnose such issues remotely My best guess would be that the low-level hardware detection module of AIDA64 collides with another diagnostics, overclocking, tweaking, or monitoring software. Or, a wild guess: maybe your security software kills the AIDA64 process due to it making some "funny" things like talking directly to the hardware.

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3242kwn2zf6gyqzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. That should fix the fan RPM calculation issues. Note that the sensor chip of your motherboard is only capable of measuring no more than 3 fans. Hence, the 4th fan (NB fan) is not measured, but only powered.

We've added graphs and gauges to both the Logitech Arx and RemoteSensor LCD module in the latest beta release of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta Note that the new gauges featured in these modules are called arc gauges. They do not have the same look & feel as the classic AIDA64 gauges (featured in the SensorPanel), but they offer much more flexibility.

It looks great We've added graphs and gauges to both the Logitech Arx and Web Server LCD module in the latest beta release of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta Note that the new gauges featured in these modules are called arc gauges. They do not have the same look & feel as the classic AIDA64 gauges (featured in the SensorPanel), but they offer much more flexibility.

I've just sent you a private message about this Regards, Fiery

Our contact at Logitech says that they will look into it.

Most notebooks can only control fan speeds, based on temperature readouts, but monitoring the current fan speed RPM is not supported. Are you sure your notebook is capable of measuring its fan speed(s)?

Thank you. I've sent you a private message about this.

Thank you. That indeed looks quite odd. What update frequency did you select for the OSD Panel? When the OSD Panel gets "confused", do the date and time items (at the bottom) drop out?

We've recently revamped the OSD Panel and SensorPanel window positioning scheme, so make sure to upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3237vy9hqdrx7czip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps. BTW, in the Registry you can set SensorPanelPosX and SensorPanelPosY to change the position of the SensorPanel.

We haven't got any programming information on those devices. We've sent a request to Aquacomputer, hopefully they would help us out. I'll post updates on this issue into this topic.

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Aquaero Dump. Copy-paste the full results into this topic. Thanks, Fiery