Fiery

It can only be supported if the digital photo frame can accept bitmap image (bitmap frame) transfers via its USB connection. AFAIK only Samsung SPF displays and AX206 hacked picture frames support that.

We've checked, and unfortunately we haven't found any classic ways of obtaining those values from the video card iCX must use a custom communication protocol, but we have no idea how it works and how to handle it.

Not really. The AXi firmware seems quite bad quality anyway (for example: the USB protocol is quite unreliable, so a lot of workarounds have to be implemented in a 3rd party software just to read the raw sensor values out of the PSU), so I'm sure Corsair did their best to get around all the issues. The remaining issues are not major ones, so I'm pretty sure they wouldn't want to deal with them.

When you configure a 1 sec update rate, then the actual CPU utilization value will reflect the average CPU utilization over a 1 second period.

We've done test runs and research about those values, but they didn't look good. The input power simply was inaccurate. And the output power and efficiency are calculated values, using such formulas that vary over different PSU SKUs. It's simply not scientific enough for us to deal with

I don't think 500 millisec would be an issue, but 100 millisec may cause stuttering or frame drops while gaming. Try it, and you will see whether you can notice any difference (you will probably not )

Yes, but the update rate doesn't include the sensors polling time that can take anything between 50 to 500 milliseconds, in rare cases even more. But still, even if we're talking exactly 100 milliseconds update rate or 10 FPS, it's way inferior to what is considered "fluid" these days...

1) Yes, the whole circle represents the 24 hours of a day, so on 6:00am it will show 25% "progress", and at 4:00pm it will show 66% "progress". 2) I don't think we'd want to go down that path.

There's no high temperature in that log. There was also no high CPU workload during that logging session. The maximum CPU utilization was below 30%. If you leave your computer idle, and wouldn't put any considerable load on the CPU, you won't be able to find out what causes overheating.

I appreciate your kind words. We'll keep pushing the development of AIDA64 in order to deliver more quality releases in the future too. As for socket temp... well... I'm not quite sure how to label these things We generally recommend watching all CPU related temperatures, and use the highest one as your reference. With Ryzen "X" (XFR-capable) processors cooling is crucial, so it's worth experimenting with various system loads, and watch and log all the temperatures during a certain workload to find out whether the current cooling solution can and should be improved.

When you have 1 second update rate configured, the actual update rate will be somewhat higher. It's because AIDA64 waits 1 second between updates, but one update may take 50 to 500 milliseconds, depending on how many slow interface hardware (sensors mostly) you've got in your system. So the actual update rate will be between 1050 and 1500 milliseconds. If you want to get to exactly 1 second update rate, you need to experiment lowering the update rate from 1000 milliseconds to 900, 800, 700, etc, until you reach the exactly 1 second update rate. As for gaming, I think it may be caused by the Game Mode feature of Win10 Creators Update. It may allocate far less CPU cycles to background tasks -- like AIDA64 sensors polling -- than before. You can overcome that issue by turning Game Mode off, and/or by increasing the priority level of the AIDA64 main process (AIDA64.EXE) using Task Manager. The latter is not very convenient, but it's worth checking out. BTW, we've checked your support ticket, but it only included an AIDA64 report snippet, without actual comment or problem description. We can't really do anything about such tickets But we can definitely investigate this issue here, on the forums, I'm here to help you out.

Let's see first whether the OSD Panel is the culprit. Maybe there's an item on your panel that operates outside the sensor module and causes the slowdown. Please let me know what happens after you turn the OSD feature off. If it solves it, and once you turn it back on, the issue comes back, then we need to dig down deeper and check out the 4 items you have on your OSD. We'll then try to replicate the issue on our own Xeon E5 v3 based test system.

We've enabled graph and gauge configuration for the Time item in the following new AIDA64 beta build: https://www.aida64.com/downloads/latesta64xebeta The resolution for the time value is 1 second, so for the gauge you may want to specify a minimum of 0 and maximum of 86399 to have a full day scale.

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

It's a bit difficult to implement it, but we'll give it a try. Please give us a week or two to work it out.

The problem with the single value is that to my understanding the throttling cause is not reported as an "either", but as a bit field combo, so there's a possible state of power limit + voltage limit in the same time, or even power limit + temperature limit + voltage limit. So reporting that would either need discreet values -- which would blow up the number of sensor items considerably --, or would require us to report the values as a string (text form). The latter solution would however make it impossible for you to put indicator LEDs on your panel...

In order to find out which component is overheating during the stress test, enable the Logging facility in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Logging. And BTW, that 216 Celsius reading is clearly a bogus value. No component in your computer would be able to operate at over 100-120 Celsius

SensorPanel doesn't support that kind of a placement, I'm afraid.

With a less than 10 FPS update rate it wouldn't look all that great IMHO.

We're not currently working on this feature idea. Maybe sometime in the future...

Thank you. It's quite odd, since I can see no issues about the sensor module there. Maybe it's something else, another part of AIDA64 that drives your CPU core to the maximum. Do you have any hardware monitoring modules (like OSD Panel, SensorPanel, LCD, Logging, Desktop Gadget, Sensor Icons) enabled?

We follow AMD's requests and recommendations on the -20C temperature offset for the CPU Diode (Tctl) temperature reading on Ryzen 7 1800X, 1700X and 1600X parts. Ryzen processors feature only a single thermal diode, and I assume it's located outside the CCX'es, in the uncore part of the CPU. The temperature reading labelled simply as "CPU" is measured by the motherboard sensor chip.

I'm afraid we don't have plans to enable such deep customization of sensor readouts. However, you can use the Correction feature (AIDA64 / main menu / File / Preferences / Hardware Monitoring / Correction) to scale the RPM values down to a 0 to 100 range, in order to convert the RPM readings into percentage values.

Apparently the ACPI BIOS provides a stuck temperature on your particular notebook, most likely due to a BIOS bug. Just ignore that value and focus on the other CPU readings that do change dynamically. Regards, Fiery

We've specified the changelog properly when we've updated the app from v1.45 to v1.46, but for some reason the Play Store fails to display the up-to-date changelog. I guess it's due to a bug in either the Google Play Developer Console or the Play Store. Anyway, here're the changes in v1.46: - Improved support for Galaxy S8, Galaxy S8+ - Window resizing support for Samsung DeX - Fixed: core architecture detection for Snapdragon 435 (MSM8940)