Fiery

You can enter symbols only when they are ANSI characters. AIDA64 doesn't support Unicode characters or Unicode strings.

The reference benchmarks list that you can find in AIDA64 only includes such systems that we have got in our R&D labs. Those systems are under our strict control to make sure the reference performance scores obtained on them are always dependable.

I'm glad you've managed to make it work

It is usually caused by a storage controller driver. Updating the driver sometimes helps, but not in all cases. If you want to disable RAID scanning, close AIDA64, go to AIDA64 installation folder, find AIDA64.INI file, and open it in Notepad. Then find the following two lines ... LowLevelRAIDEnum=1 LowLevelRAIDSMART=1 ... and alter them to: LowLevelRAIDEnum=0 LowLevelRAIDSMART=0 In case you cannot find an AIDA64.INI file, then create one, and write the following 3 lines into it: [Generic] LowLevelRAIDEnum=0 LowLevelRAIDSMART=0 Regards, Fiery

It looks great!

LCDsysinfo displays -- both the original version and the newer GOverlay -- is cheap for a reason. It is a very limited device that doesn't support direct bitmap image transfer/display via USB connection, and so it cannot be supported by AIDA64. Yes, it is possible to put AIDA64 measurements to LCDsysinfo displays, but only by using LCDsysinfo's own software solution that is a lot more constrained than AIDA64's own LCD module. What makes more sophisticated displays more expensive is the underlying microcontroller that drives the display and makes it possible to transfer bitmap images over USB. Without that, the communication protocol could only support basic commands like "Display a letter A at X=2,Y=1 position" or so. You can display fancy text that way, but not full-blown graphics. Make sure to check every screen shots and other material that you can find about LCDsysinfo online, including the screen shots for their companion software that you use to configure the display. Also check this review: http://www.techspot.com/review/704-lcdsysinfo-for-goverlay/ There's a slim chance that LCDsysinfo would still fulfill your needs, and I don't mean to bash those devices at all. I just wanna make sure you don't fall into the trap of a low price tag BTW, we do have one piece of most of the USB-connected LCD devices out there in our R&D lab, including all those mentioned in this topic. So we do have a first-hand experience on the capabilities and constraints of all the LCD devices that AIDA64 supports.

I don't know about the cheapest option for your specific requirements, but you've got the following options: - AlphaCool 200x64: may be difficult to source - Crystalfontz CFA835: $86 - Matrix Orbital GX Typhoon: $99.95 - picoLCD 256x64 Sideshow: $54.95 or $59.95 Maybe there's more, but those are the most well-known 5.25-inch form factor options that all work well with AIDA64. Note that even though Matrix Orbital GLK would technically work with AIDA64, it has a very slow update rate in gfx mode, so I wouldn't recommend that option at all. Matrix Orbital GX is a far better solution: it's got a very quick gfx update rate that works great with AIDA64.

Please note that we will revamp the active memory channels enumeration in the next AIDA64 beta build (due in a few days from now), to avoid showing confusing information on the Cache & Memory Benchmark panel.

Battery charge rate is only support by Android 5+ systems. It doesn't depend on the SoC model, but only on the Android version. Regards, Fiery

Thank you. The issue is already fixed in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta Regards, Fiery

In case your display offers a standard DSub VGA connection, and you can connect it to your computer as a secondary monitor, then you could extend Windows Desktop to it, and use SensorPanel instead of the LCD module of AIDA64 to display various sensor readings.

Thank you for the feedback

I'm sorry, I've mixed up 3430 and 3431 The right one is the 3430 build.

The change we've introduced in Beta Build 3430 affects misc temperature ("Temperature #n") values. Previously, misc temperature values may overlap across sensor devices. So e.g. in your case, your motherboard sensor can measure 3 misc temperature values that AIDA64 calls Temperature #1 to #3 (it is labelled as "T_Sensor1" to "T_Sensor3" by Asus), but your Aquaero device can also measure a series of misc temperatures that AIDA64 called Temperature #1 .. #44. On previous builds Temperature #1 to #3 coming from Aquaero overlapped with Temperature #1 to #3 measured by your motherboard sensor, hence you lost 3 readings, the ones for the motherboard. Now AIDA64 handles those readings in a sequential manner, so all temperatures are kept and they will never overlap. This unfortunately has a side-effect on such mixed sensor configurations like yours, so it may require adjustments for LCD and SensorPanel layouts. We've delayed making this necessary change for that reason, but lately we've received many inquiries about overlapping readings, so it was now hard to avoid making that step. As for the missing temperatures, they should be there now. If they're not, then please copy-paste or attach an ISA Sensor Dump and an Embedded Controller Dump, and we'll check what's going on. Please make sure to use AIDA64 Build 3431 where we've fixed some issues over the 3430 build.

Thank you, we'll add the missing information in the next AIDA64 beta update due next week. Regards, Fiery

That's actually a much more complicated issue than the 2 lines of "if ... then" sequence you've mentioned. AIDA64 always tries to handle things automatically, so that the user wouldn't have to worry about every single bits of configuration. When you start AIDA64 without previously altering the Preferences settings, it will automatically tick (enable) a pre-defined list of sensor icons. Since those are a pre-defined list, the items on the list may or may not be supported by the current system. For example, it will enable CPU Fan, System Fan, Chipset Fan, Chassis Fan, etc. And since it's not possible to know which items do exist on the current system, AIDA64 automatically will hide the ones that provide an invalid reading, like 0 RPM, negative RPM or excessively high (unrealistic) RPM like 60000 RPM. That logic assures that only the actually valid items from the pre-defined list would appear automatically on the System Tray as sensor icons. And when I say "it will automatically tick" a certain list of sensor icons, it means it sets their SHOW property to 1 (enabled). It is the same property that you can alter by ticking the checkbox next to a sensor icon in the Preferences. So there's no separate property for "automatically ticked" and "ticked by the user". On a typical system the enabled list of sensor icons is much longer than the ones that actually get shown on the System Tray. You can open the AIDA64.INI file, and in there you can see that a lot of sensor icons (incl. many fan readouts) are enabled automatically, but they are not shown on your system simply because those fan headers do not exist or they provide a 0 RPM reading. Of course as soon as any of them start to provide a meaningful readout, the sensor icon will immediately appear on the System Tray -- and will not disappear until you restart AIDA64. Another problem with the behavior about stopped fans and invalid readings is that some users prefer to have the sensor icon (or OSD Panel, LCD, etc) items hidden in such cases, while others would still want to watch them show the invalid reading. And in many cases it's not easy to decide what an invalid reading actually is The hardware monitoring module of AIDA64 is very sophisticated, but your example shows that no matter how much we try to improve it, it still cannot satisfy every single specific and unique needs And when I say unique, I really mean that. The sensor icons module works the way it does now for many years, and noone complained about the 0 RPM fans issue before. And quite frankly, I have to disagree with you on the "critical" issue of stopped fans. While it is a critical issue, I don't think a user would quickly and easily notice that a fan stopped by looking at tiny 16x16 pixel System Tray icons. Unless of course you only use just one sensor icon, and you constantly watch the System Tray area for icon text changes I don't think in practice anyone would rely on the tiny sensor icons for critical system readouts. Typically, you would configure the Alerting facilty of AIDA64 to warn you about fan issues or overheating situations.

That's what I meant when I mentioned the difference between fan duty cycle (%) and fan RPM readout. Fan RPMs are shown in the AIDA64 System Stability Test, but fan duty cycles are not. So if your second GPU only provides a fan duty cycle, then it's normal that it will not appear in the System Stability Test Statistics.

Thank you. I think the issue is caused by an overflow in the AIDA64 sensor module. Somehow your D5 devices carry the same HID device ID and product string as MPS, and so AIDA64 tries to handle them as MPS. And since you've got five AquaComputer devices in total (incl. the Aquaero), the 4 slots that AIDA64 provides for AquaComputer devices overflow I've sent you a private message about this.

Thank you. There's something very fishy going on there. Please clarify: do you have a single Aquaero 5/6 device connected via USB, and you've got 4 MPS devices all connected via USB?

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta If it doesn't help, then please post two Aquaero dumps (with a few seconds gap between them) to let us check what's going on on your devices

Such issue could be because Haswell-EP processors feature 2 memory controllers, each with 4 memory channels (total of 8 memory channels per socket). And there're many configurations where 4 memory channels are assigned to a socket, but not by utilizing all memory channels of the 1st IMC, but 2 channels for IMC0 and 2 channels for IMC1. And on the Cache & Memory Benchmark panel AIDA64 will show the utilized memory channels count for the very first IMC it can find in the system. You can go to the Motherboard / Chipset page to see all the IMCs you've got in the system, and check the actual memory channel utilization for all of them. Regards, Fiery

"MSI 2" seems like an incorrect (maybe truncated?) motherboard model. We can check it out, as well as the sensor issue, if you could post an ISA Sensor Dump of your system. Right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic. Thanks, Fiery

AIDA64 overrides its own CPU affinity setting to make sure it can enumerate all available processors and can measure various properties of all logical processors in the system. Regards, Fiery

PCH Diode temperature measurement requires the BIOS (UEFI) to properly initialize the thermal device of the PCH. I suppose on the Z97-GD65 motherboard the BIOS fails to initialize the thermal device, and so AIDA64 cannot use the device to measure the PCH Diode temperature. Regards, Fiery

Thank you, we've got the SDK, and ordered a X-52 Pro unit for development. In this topic I'll let you know about our progress on implementing support for it.