Fiery

No problem, I suppose you've upgraded to the latest AIDA64 beta that already implements support for GeForce GTX 970 and GTX 980 Regards, Fiery

CPU-Z may report CPU VID as Vcore. Please compare AIDA64 readings against HWiNFO64 or Asus AI Suite instead

1) What is the file size of the Strike7API.dll file you've copied into AIDA64 installation folder? 2) Have you tried it with the latest AIDA64 beta update as well? http://www.aida64.com/downloads/latesta64xebeta

1) We'll fix the fan labels in the next AIDA64 beta update. 2) AIDA64 reports the actual Vcore, while CPU-Z reports the CPU VID. 3) CPU temperature and CPU Package temperature may or may not match. It's due to the difference in measurement methodology, you don't have to adjust any of those values. 4) Unidentified temperature readings can only be added if your motherboard also shows those values in the UEFI Setup or Gigabyte's own monitoring software. Otherwise, those values could well be just bogus readings, invalid values, or unconnected sensor chip wires. Regards, Fiery

We'll check that And keep posting any issues or ideas. I cannot promise you that we can fix every issues, or that we can implement everything you come up with, but we will do our best to improve AIDA64

It should be able to show that information, unless the video adapter is in deep sleep mode. In your case I suppose the secondary video adapter (nVIDIA) only wakes up when AIDA64 starts up, and then goes back to sleep, and wakes up again only when you start a graphics-intensive application like a 3D game. Try to start AIDA64, and go immediately to the Display / GPU page, and check if the clocks are reported for the nVIDIA GPU. And then watch if it goes to sleep, and the clocks disappear or turn to zero. If the clocks stop showing a meaningful value, it means your nVIDIA video adapters went to sleep (to save battery power).

Try to enable the option Wake GPUs up at AIDA64 startup in AIDA64 / main menu / File / Preferences / Stability. Restart AIDA64 after altering that option. It should help to monitor both GPUs properly. Regards, Fiery

It's not quite that easy I'm afraid. You could sync a photo to your phone, but that means writing 2 or 4 MegaBytes of data two times a second to the flash memory of your mobile device. It would quite quickly exhaust the flash memory write cycles and render your device useless, so you have to avoid that. The data -- whether it is a bitmap or a bunch of descriptors about the image -- has to stay in memory, and that's why any existing apps wouldn't work.

Yes, unfortunately Asus still refuses to implement the industry standard synchronization mutexes in their software. That would assure AI Suite works seamlessly together with 3rd party monitoring applications like CoreTemp, CPU-Z, GPU-Z, HWiNFO, HWMonitor, SIV, SpeedFan, and of course AIDA64. As for FPS monitoring, I'm afraid it's too complex for us to consider at this time, so it's not on our roadmap.

We definitely has something like that on our roadmap. Check the following forum topic for a little insight: http://forums.aida64.com/topic/2415-do-you-have-an-unsupported-lcd-or-vfd/ Regards, Fiery

Thank you for the feedback

Yes, the GPU temperature diode is located integrated into the graphics processor of your video card. You can check it out on the Display / GPU page of AIDA64. AIDA64 cannot measure FPS, but you can use Fraps to do that, and you can import Fraps data into AIDA64. Regards, Fiery

Only the Memory Latench benchmark is an exception. In every other benchmarks the higher the result, the better the score. Regards, Fiery

We've implemented support for Till Harbaum's GLCD2USB protocol in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta Special thanks go to Till Harbaum, for providing us with a trio of microcontrollers to let us build our own GLCD2USB devices. BTW, parallel port connected SED1520 and T6963C, IkaLogic, and SpikenzieLabs MPTH LCDs are also supported now by the latest AIDA64 beta.

We've implemented support for parallel port connected Epson SED1520 controller based LCDs and for parallel port connected Toshiba T6963C controller based LCDs in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta BTW, GLCD2USB, IkaLogic, and SpikenzieLabs MPTH LCDs are also supported now by the latest AIDA64 beta.

Thank you for the feedback

We've added the requested separate lines for Device Resources entry in the latest revision of the language modules. You can find it at the bottom of the language modules in the following new AIDA64 beta package: http://www.aida64.com/downloads/aida64extremebuild3149w7bx5cfygmzip Thanks, Fiery

Thank you for the feedback. We've further tweaked the DDR4 diagnostics module of AIDA64. Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3149w7bx5cfygmzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it is any better than the previous try

Thank you for the feedback. We've further tweaked the DDR4 diagnostics module of AIDA64. Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3149w7bx5cfygmzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it is any better than the previous try

Don't be too afraid of the programming of Arduino and such boards. Many of them offer a BASIC-like simple, easy-to-read and easy-to-follow language, or even shell scripting to drive the board. There are many tutorials available online, that start from the classic "Hello World!" example And there's always a passionate community who can help you out if you get stuck. You can find a lot of information at the mentioned sites like Phidgets, Yoctopuce and such, and also at: http://www.parallax.com http://www.adafruit.com http://arduino.cc http://www.robotshop.com http://beagleboard.org http://www.bananapi.org Truth be told, the Banana Pi may just be overkill for your purposes I just included it to have you an idea on how extreme can you go with such hobby projects

That is exactly what I've explained above For low bandwidth LCDs (like Matrix Orbital GTT) that's the way to go already, but as I've said above, such solutions have serious drawbacks and limitations if you cannot alter the protocol. With a mobile device protocol, designed and developed by us, we wouldn't have such constraints fortunately, but we'd still have a lot of issues to solve before developing the actual Android or iOS app that does the rendering. For example, how to connect your PC and your mobile device through the internet, how to send the data in a reliable and secure fashion (https + additional data encryption and compression), how to support both landscape and portrait modes seamlessly, how to handle multiple mobile devices and multiple PCs, how to handle the screen resolution issues, etc. That could be an option, but we've already seen a LCD that does sort of similar stuff (LCDsysinfo), and quite frankly, it is very limited and tough to use. To take the existing, very sophisticated SensorPanel facility and simplify it down to the bare minimum may sound okay as a start, but it would offer you so much less than the current SensorPanel that you would immediately start to build up your "appetite" and just demand more So IMHO the only logical solution is to clone the feature set of SensorPanel and do the same rendering process on a mobile device, using the low bandwidth approach to save network bandwidth. I agree, there's a lot of potential in our envisioned remote monitoring feature for AIDA64 I'm confident that we'll get there, it's just a matter of time. It takes a lot more resources and efforts to make this happen than many other existing features of AIDA64 combined.

That's actually a subject we've been thinking about for months now. We've already done quite a bit of research, and here're the challenges with the proposed solution. First of all, an insight on how AIDA64 works about LCDs and SensorPanel. Both modules use the same rendering engine that takes a specific output size (X pixels by Y pixels), a bitmap type (monochrome, 16-bit hi-color, 32-bit true-color, etc), and a number of items that you've put on your LCD or SensorPanel, and renders the output as a single bitmap image (frame). It's a very flexible solution for users, since they can design their layout with a per-pixel precision, and can dynamically put any items anywhere on the LCD or SensorPanel. For us it's also very easy now to plug new LCD protocols into the existing LCD module, since the rendering engine can take virtually any display resolutions, display types and bit depths, and handles everything automatically. Once the bitmap is rendered, AIDA64 sends the bitmap to the LCD via USB, RS232 (serial) or LPT (parallel) port, or simply displays it on the SensorPanel window. That's where the problem rises about alternative screens like phones or tablets If you could have a mobile device connected to a USB port, and AIDA64 could submit the rendered bitmap with at least 1 or 2 FPS update rate, then things would be quite simple. Unfortunately iOS devices simply don't support such a thing, so you cannot send any bitmap frames through the USB connection to your device. You can sync your photos via USB, and it might technically be possible to use that interface to submit bitmaps to your iOS device, but it may not be the best idea to keep writing a big image file to your flash storage one or two times a second -- it may quickly ruin the lifespan of the flash storage and eventually kill your device Android seems a bit easier in that regard, since according to our research it supports network connection via USB cable, so it should be possible to send bitmaps or other data over the USB cable and process them in a native Android app. But, even if we did that, several other issues may still remain. One of the issues comes from the fact that nowadays -- as funny as it may sound -- many phones and tablets feature a similar or higher resolution screen than your PC screen. And since we've got a per-pixel accurate LCD designer (preview screen) in AIDA64 Preferences, you may find it very difficult to design the LCD layout when the mobile device's screen resolution is similar or higher than your PC screen's resolution. Of course it may be possible to add some odd workarounds there, like downscale the preview by 2x or 4x to fit on the PC screen properly, but then it would raise a lot of confusion for less experienced users. Like you would move a certain item on the preview by one pixel to the right, and it doesn't move due to the downscaling And the other, even more disturbing issue is that very soon both the mobile and the desktop PC world will become almost completely wireless. So even if we made an AIDA64 Android LCD app that you could use with your PC through a USB cable, many users would instantly demand a wireless solution -- and I wouldn't blame them It would be a lot more fun to watch your sensor readings without having to hassle with cables, and you could even perform the monitoring remotely, from anywhere, if the AIDA64 LCD module would send data over the internet, as opposed to your home WiFi LAN. And then the problem comes about using the internet or WiFi connection: if you take a 1 or 2 FPS update rate, and take a 32-bit true-color fullHD (1920x1080) or 2048x1536 resolution bitmap, the required network bandwidth to do the screen updates would quickly become so enermous (24+ MegaBytes/sec) that no wireless network connection could reliably and constantly push through. Not to mention the looming age of 4K where things will get even worse. In the past few months we've worked on implementing over 50 different LCD protocols in AIDA64, including very fast ones that take full advantage of the USB 2.0 bandwidth, and also ones that are designed to work with low bandwidth connections like RS232 or I2C. With such low bandwidth LCDs, even if you use a wired connection, it's simply not possible to push the rendered bitmap from the PC to the LCD in less than 3 or 10 or in some cases 40 (!) seconds. Manufacturers of such LCDs get around that problem by implementing such a protocol that allows you to copy small bitmap elements and TrueType font files to the onboard memory of the LCD, and issue certain commands that would allow you to build your LCD design a bit like how you design your SensorPanel or LCD layout in AIDA64. So you specify the (X,Y) position of your label, you select the font type, font size, font colour, you send the text you want the label to display, and the LCD's processor renders the image for you. It really works a lot like how AIDA64 renders the SensorPanel and LCD bitmaps, which is of course good news. The bad news is that all those low-speed connection protocols work differently, and do not feature many of the tricks and features that AIDA64's own rendering engine implements, so it takes a lot of time and efforts to implement such a protocol as an alternative rendering path for AIDA64. We've been working on one of such protocols (Matrix Orbital GTT) for months already, and we still cannot get an acceptable result, especially when we use a lot of LCD items. It's really tough to work with LCDs if you cannot push the rendered bitmap straight to the LCD. And that's where mobile devices have a similarity: they can also be considered low bandwidth devices in wireless mode, since ideally an AIDA64 frame update should consume very little network bandwidth, so you could monitor your PC from low-speed WiFi networks or cellular networks. So we would have to come up with an alternative rendering engine for both Android and iOS devices, since we cannot use the existing bitmap rendering engine. The new engine should support any mobile screen resolution, even in the LCD designer (preview), even when the mobile device has twice the resolution of your PC screen. It should also support both portrait and landscape screen modes, and consume the least network bandwidth possible, while still maintaining all the features you got used to with the SensorPanel. As you can see, it's quite a challenge, but we'll get there. Of course, it would all be a lot easier if you could somehow use your existing mobile device's screen as a simple USB monitor, via DisplayLink or a proprietary interface. If your mobile device's screen could appear as a secondary monitor in Windows, you could simply use the existing SensorPanel without any modifications Maybe an idea for Google for Android 5.0? ;) Anyway, sorry for the long post. I just wanted to let you know all the difficulties and impacts of the feature you envisioned. I also wanted to post all of this, because hopefully it will start a conversation and brainstorming where others could also chime in and post their point of view on this matter. PS: If you're looking for a large true-color LCD device that can be used with AIDA64 even today, then I'd recommend you to get a Samsung SPF: http://forums.aida64.com/topic/2424-new-lcd-device-support-samsung-spf-digital-photo-frames/

FYI, currently AIDA64 can only measure the following type of sensor values: - temperature - fan speed (can also be used to measure pump RPM) - voltage - electrical current - power - misc, also called as "system": clocks, CPU load, memory utilization, FPS, etc So as you can see, humidity is not there yet. But we can add it, if we could find a sensor device that can be polled by AIDA64. As for calculations and applying certain formula on the measured values, well, that's not really possible with AIDA64 right now, if you mean combining multiple measured values in a formula. However, if you want to do some calculation on a single measured value, then using the Correction feature may be the way to go. With Correction you can use a ratio and an offset on a certain measured value, but you cannot do "a+b" where "a" is a measured value and "b" is a different measured value. I'm not trying to overcomplicate your hardware project, or convince you to spend more $$ on this, but there's a chance you would be better off by starting with an Arduino, Raspberry Pi or similar board. With that you can hook up many different shields or sensors, and write a firmware or application that does all the measurements and calculations you want, and then push a single value (the result) through the USB port to the PC host. You could also not only measure values but control fans, pumps and other devices with such a solution. Of course this solution may seem overkill and overly complicated at the first glance, but it would also offer you the maximum flexibility in the long run. The more generic and versatile you go, the better your chances are for future expansion. If you keep things less complicated, you may find yourself in a situation in the not so far future where you have to start all over again, due to exhausting the possibilities of the simple hardware solution.

Does the service user have proper rights to read the AIDA64.INI configuration file as well? Have you tried to enable the Registry export feature? (AIDA64 / main menu / File / Preferences / Hardware Monitoring / External Applications) It would be useful to know whether that works with your configuration or not.

Is your video card overclocked or in any other ways tuned?