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?

On modern computers it's not at all dangerous. Modern CPUs and GPUs both feature thermal protection circuitry, so once they start to overheat, they either throttle themselves down or turn off. We generally recommend running the AIDA64 Stability Test for at least a few hours. You should watch the temperatures and the throttling graph (on Intel processors) as well. AIDA64 Stability Test works on notebooks and servers as well.

AIDA64 Business implements a Logging facility that can be used for such purposes. Go to AIDA64 / main menu / File / Preferences / Hardware Monitoring / Logging to enable and configure that feature. Regards, Fiery

The link between Fraps and AIDA64 shouldn't cause an issue, so in case there's a serious issue while using them together, I think it must be a bug in either one of those software. If you never experience such issues when you only use one of them, then it's a tough one Then the only thing I can think of is some sort of Direct3D hooking vs. AIDA64 mixup, which may be caused by the underlying video driver. Quite hard to diagnose such issues though, since all those ideas I came up with in this paragraph are just hunches, not based on any evidence or actual experience on our test systems.

Yes, I've read those datasheets. Quite frankly, we could add almost any sensors to AIDA64 as long as you figure out how to connect them to your PC. We haven't implemented support for IOWarrior56 or Phidgets sensors simply because so far no AIDA64 user has shown any interest in them. We however have already added IOWarrior24-based ct-Mausekino LCD and Phidget LCD support in AIDA64, so we know how to handle those devices. It's just not for measuring anything, but for displaying the measured values. If you come to a decision on what stuff and how you would build it, let me know. The only thing required for us to start working on the implementation in AIDA64 is the device to be connected to PC via a standard interface (USB preferred), and the possibility for us to buy the same components from an online store. BTW, when it comes to the Phidget sensor device you've linked above, have you checked what device would you connect that thing into? I suppose either one of the following devices would work: http://www.phidgets.com/products.php?product_id=1018 http://www.phidgets.com/products.php?product_id=1011 We've already got the 8-8-8 device with the integrated LCD ( http://www.phidgets.com/products.php?category=15&product_id=1203_2 ), and it's an impressive piece of kit. Although, we haven't yet connected any sensors to it

You can already do that using Fraps When you install and enable Fraps, a new item will appear among other LCD items, called Fraps (in the System group).

Yes, that's correct. But I'm afraid this part of the year is very busy, with all the new hardware launches, so we need a bit more time to understand and process the layout of the Aquaero readings. Both the old Aquaero 4 and the newer models are very "German", in a good way It's very technical, very well structured, very complex, and capable of doing a lot of things. It's not easy to find a common ground with that and the existing sensor module of AIDA64. It's also time consuming to see what we can do with a standalone Aquaero module, and find out what readings may come from external modules and additional (optional) modules. AIDA64 already supports a few fan controller and temperature measurement devices, but none of them is even half as complicated as the Aquaero devices.

You only have to have the FPU subtest enable for that. In case you've got a discrete video adapter (video card) in your system, then enable the GPU subtest as well. If you've got an integrated video adapter, then do not enable the GPU subtest.

Thank you for the feedback

Idle temperature isn't that important. The only thing really matters is temperatures under heavy load.

Those temperatures look absolutely fine to me.

We've implemented support for parallel port connected Samsung KS0108 controller based LCDs in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta

We've fixed the Haswell-E DRAM:BCLK ratio detection and all other DDR4 related issues in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3143zrvflpc9mdzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works