Fiery

USB devices have a lot of information encoded in their firmware, including vendor ID, product ID, manufacturer string, product string, serial number, etc. Since they're all stored in the firmware, they can all be set to any value by a simple firmware reprogramming. Making a USB-connected chip look like another chip (in the USB device information block) is quite easy unfortunately. Regards, Fiery

Have you read the customer review on that page? Also, it would be very important to check how many I2C devices can that dongle handle, and what electrical connections do you have to apply to connect those devices. Also, it would be important to check where the proposed sensor devices would get their power from. Because, unlike with USB, the I2C bus doesn't provide any power to connected devices. So the whole thing, including the hardware and software design could quickly become quite complicated. IMHO you may be better off with a ready-made solution, such a device complex that has everything already developed, and you just have to plug the pieces together. AFAIK Yoctopuce provides such solutions, but I'm not sure whether they provide all kinds of sensors that you would need for your project, like humidity and such.

Such devices typically use I2C connection. With most PCs it's not possible to connect your own I2C devices. That's because most PCs do not feature an I2C bus that would be available for the user to connect his own I2C devices. But, in case you find a solution to connect your I2C devices to your PC in any ways, please let us know the exact solution and provide us with an API or other documentation on how to talk to your I2C devices. We can implement virtually any kind of sensor devices in AIDA64, as long as the communication protocol is well documented, and reading out sensor information doesn't take ages. A couple of potential candidates on connecting I2C devices to your PC via USB port: http://www.harbaum.org/till/i2c_tiny_usb/index.shtml http://www.robot-electronics.co.uk/htm/usb_i2c_tech.htm http://mmdolze.users.sourceforge.net/use-a-lcd-with-twi.html http://www.sprut.de/electronic/pic/projekte/usb4all/usb4all_en.html But, you have to be careful with those: you have to verify how many devices you want to connect to the I2C bus, and whether a specific I2C --> USB converter could support that many devices. Or, you can see whether there're any ready-made solutions offered by the following companies: http://yoctopuce.com http://phidgets.com Yoctopuce has very interesting devices that could measure all sorts of things. AIDA64 already supports their OLED displays, as well as Phidgets LCDs -- but not those companies' sensor devices at this time. Another solution might be building your own USB-connected interface board, based on a Microchip or Atmel microcontroller, and hook up your I2C devices to that board. That solution would provide the most flexibility, but may also be the most expensive solution as well. And then there's using a Raspberry Pi as a slave device connected to your PC via USB port, etc. etc. It all depends on how serious are you about this project, and what exactly would you like to achieve.

The requested feature will be implemented in the next AIDA64 beta update It will be rolled out later this week. Regards, Fiery

I meant the 2 scenarios listed as "1)" and "2)" above. It's unlikely, but it could happen. You can try downloading some big files while running the AIDA64 stress test, maybe it will cause an issue...

I think the confusion about thermal testing is that AIDA64 offers more flexibility for stress testing, and sometimes users cannot find the optimal combination. Usually the FPU subtest alone could put the most thermal stress on modern processors. And if you enable more subtests (like CPU, Cache, etc), the thermal stress will not be that great. So it's best if you decide what do you want to use the AIDA64 System Stability Test for: 1) You want to find potential computing errors or other stability issues. In which case you should have a combination of subtests enabled, e.g. you can enable them all. 2) You want to see how well your cooling solution works by putting the most thermal load on your system. In which case you should have only the FPU subtest enabled. Additionally, if you have a discrete video adapter (one or more video cards), you can enable the GPU test as well. If your system can stand 8 hours with both test #1 and test #2, then I'd consider it quite stable

It doesn't do any harm if you run the disk test while using your computer. The disk stress test simply performs file reading operations, so nothing low-level and nothing critical is being performed.

The disk test uses separate processing threads, so you can use it along with the other subtests if you want. You can also issue that test after the other ones. Based on your description of the issue, I too don't think it's disk related. It sounds more like a PSU, motherboard or memory related problem. Regards, Fiery

The requested feature will be implemented in the next AIDA64 beta update It will be rolled out later this week.

Thank you for the feedback. We're constantly working on the already implemented LCD protocols, while in the same time keep adding new ones. So the whole LCD module evolves rapidly, and hopefully soon it will cater for everyone

I'm glad it worked out

Try to double-click on the GPU temperature item, and select the actual GPU temperature from the list of temperatures. It may be called "GPU Diode". Note that "GPU" temperature and "GPU Diode" temperature are different readings, so if your old video card supported "GPU" but the new one supports "GPU Diode", then you have to reconfigure the relevant SensorPanel items.

Thank you for the links. We'll definitely have to do a lot of measurements to find out where does our DRAM:BCLK ratio detection code have issues.

That is yet again due to the enermously slow SPD bank switching mechanism of DDR4 modules. We'll do our best to come up with a fixed AIDA64 beta in a few days from now. Sadly, we cannot do that without an actual test hardware on hand, since we have to tweak and optimize the DDR4 SPD bank switching code to make sure it becomes quick enough to let you use AIDA64 without any slowdowns.

Thank you, we'll fix the voltages in the next AIDA64 beta. Rampage V Extreme and X99-Deluxe brought many changes to the sensor layer, so it takes a bit of time for us to figure out the layout

Even though it looks like if it was frozen, AIDA64 doesn't actually lockup there, but just slows down due to the SPD bank switching being very slow on DDR4 modules. You have to wait cca. 10 seconds to let it go through, to let it scan all DIMM slots for any possible DDR4 modules installed, and then things will get back to normal. That scanning will only take place once per an AIDA64 session, but if you close AIDA64 and start it again, sadly it will have to do it again. We'll of course fix that as soon as our DDR4 platform arrives.

Thank you

It doesn't a make a difference whether you overclock your system or not. A stable system should be able to perform any subtests in any combinations, without an error.

You can use the AIDA64 System Stability Test subtests in any combination you wish Regards, Fiery

If it's a DDR4 system, then the long initialization is unfortunately normal at this time. It is caused by the new SPD bank switching mechanism specific to DDR4 modules. The bank switching unfortunately takes a lot more time than we've anticipated, usually 5 to 10 seconds at least, but maybe in your case it's even longer. We'll implement a workaround to put that delay down to less than a second as soon as our DDR4 system arrives. I'll post a message into this topic once a fixed AIDA64 build is available for download.

A minute to load AIDA64 is definitely unusual. In what circumstances does it take a minute to load AIDA64? What kind of computer do you have and what Windows version are you running? At which stage (e.g. "Scanning SMART Devices") does AIDA64 send a lot of time?

Thank you for the feedback. We've double-checked it, and the register AIDA64 currently uses to read CPU temperature seems to be the right one. You can verify that by checking CPU temperature in AI Suite. If you decide to install AI Suite for the test, then please create a new ISA Sensor Dump before and after installing AI Suite. There's a slim chance AI Suite may reconfigure the sensor chip about temperature measurement. As for the Cache & Memory Benchmark, what exactly happens? Is it just slow to complete, or an error message pops up? Please note that on DDR4 systems certain parts of AIDA64 may slow down for cca. 5 to 10 seconds, and it may look as if those modules locked up. But it's just a slowdown, and as soon as that "penalty" elapses, everything gets back to normal. The slowdown is due to the SPD bank switching mechanism of DDR4 modules. The bank switching sadly takes a lot more time than we've anticipated, which causes the 5 to 10 seconds slowdown when reading SPD memory module information. We'll work on that as soon as our X99 test platform arrives.

AMD keeps updating the hardware DirectX version of their GCN-class GPUs, even for the old(er) ones. It's not easy to keep up with that Soon every GCN GPUs will officially support DirectX 12, not just 11.2. Anyway, we'll update GCN GPUs to indicate support for DirectX 11.2 now. Thanks, Fiery

1) On Aquaero 4 you have to select the USB-LCD screen. On Aquaero 5 & 6 you have to change one of the screens to USB-LCD. 2) Yes, we can read the information block from the Aquaero, but its layout is quite complex, so we need a bit more time to process it and "wire" it to the existing sensor module of AIDA64.

We've just rolled out a new AIDA64 beta that supports Adafruit, Dangerous Prototypes HD44780, LPT (Parallel Port Connected) HD44780, Odroid-Show, picoLCD 20x4, Pyramid, Roccat Valo, USB2LCD+, Wallbraun LUI LCDs: http://forums.aida64.com/topic/2498-new-lcd-device-support-usb2lcd/