Jump to content


Recommended Posts

What we've just rolled out with AIDA64 v4.60 is only the first wave of new LCD and VFD devices. If you consider interface, protocol, controller and all other variables, there are literally hundreds of different LCD/VFD devices out there. We're already working on a number of new devices (Acer Idea 500, AX206-based firmware-hacked DPF, ct-Mausekino, Cwlinux, Futaba MDM166A, picoLCD, SoundGraph iMon UltraBay LCD, Sure Electronics, Trefon, Yoctopuce, etc) that will be added during the next few weeks, and then a lot more is coming. We're collecting ideas on which displays to support next, so feel free to let us know what display you've got, or what display you want to see being supported by AIDA64.  Make sure to state display manufacturer, display model, interface (USB, serial, parallel, I2C, etc), and if possible, show us the device you've got by posting a link to the product page or a hardware review.


If your unsupported LCD/VFD uses USB connection, please post a USB dump of it: right-click on the bottom status bar of AIDA64 v4.60 --> System Debug --> USB Dump. Copy-paste the full results into this topic.




Link to comment
Share on other sites

Hello Fiery


Is direct support of the display linked below possible? If a USB dump or other info is needed I will purchase this disaply in order to provide the necessary info if support may be possible.






Edit: Below is sample code for controlling the LCD.



Custom Usage:
The LCD can be customly controlled by using
USB control packets using default control
endpoint (no bulk or interrupt endpoint). Therefore, using the below library, user can create
their own applications to control the LCD in Linux and Windows environment.
Controlling the LCD using Python in Linux
Please visit Github for library
using Python by Dan Gardner
Controlling the LCD using C# library.

* LCDDrive.Startup();
* Load LIBUSB Driver. If device is detected, nothing will return. If no device, will display error message.
* Need to be called in when the application start.
* LCDDrive.turn_off_dimLCD_during_idle();
* By default, LCD will turn to idle mode(dim
the LCD) if no command is send to LCD within 10secs.
* Running this function will disable this feature
* LCDDrive.turn_on_dimLCD_during_idle();
* Enable back the above feature
* LCDDrive.ChangeLCDBrightness(int value)
* Change the brightness of LCD immediately (v
alue must be >0 and <255) 0=shutoff 255=brightness (Does
not save to device) for example: LCDDrive.Change
LCDBrightness(255): Set to brightness immediately.
* LCDDrive.SaveBrightnessvaluetodevice(int off_value, int on_value)
* Save the brightness value of LCD to device. off_value and on_value must be >0 and <255
* for example: LCDDrive.SaveBrightnessvaluetodevice(0, 255): Set the device to turn off the LCD during idle
and turn to max brightness when working.
* LCDDrive.Clear_lines(bool line1, bool line2, bool line3, bool line4, bool line5, bool line6, int colour)
* Clear the lines of the LCD. Because Clear line ta
kes time, sleep the thread for sometime before issuing next
* set line1-line6 to true to clear the lines, otherwise set to false to retain the line
* Color Value (integer value) This can
be a 16bit colour value in RRRRRGGGGGGGBBBBB Format
* or use the present value in ColourValue_16bit enum
* for example: LCDDrive.Clear_lines(true, true
, true, true, true, false, (int)ColorValue_16bit.Purple);
* This will clear the top5 line and retain the last line, the line will be cleared to Purple colour.
* LCDDrive.Display_icon_on_grid(int position, int icon_number)


Link to comment
Share on other sites

We've already got both the original LCDsysinfo and the newer LCDsysinfo for GOverlay. Problem with those devices is that they're one of the few rare LCD/VFD displays that do not support direct addressing. When I use the term "direct addressing", I mean that you cannot draw individual pixels on the 320x240 display, and you also cannot put a simple full-screen bitmap (or a smaller bitmap) on the display. So with those displays you cannot use the regular LCD module of AIDA64, since that is designed to work in a way that:

1) AIDA64 first collects the items you've defined using the LCD preview (AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / LCD Items)

2) It then renders all items individually in the memory, in a bitmap back-buffer, in an order that you've defined in #1

3) And finally, it sends the bitmap from the memory buffer straight to the LCD device, using the LCD's own API, which is usually a pre-defined set of USB or HID commands.

And when a display doesn't support displaying a bitmap, that whole thing simply cannot work.

Now, there are a number of displays that use either a cost-effective hardware solution (like LCDsysinfo displays), or designed in a way that it must support low-speed connections like RS232, Parallel or I2C (like Matrix Orbital and 4D Systems displays). With such displays you cannot display a bitmap, but you can use various commands to draw things on the LCD, like line, rectangle, filled rectangle, circle, ellipse, and write text. While it may sound quite convenient to use such commands to achieve the same layout that you can design with AIDA64 LCD preview, due to the fundamental differences between those protocols (LCDsysinfo, Matrix Orbital GTT, 4D Systems), it takes a lot of time to develop an alternative rendering technique, specific to a particular display model. We're planning to work on LCDsysinfo for GOverlay and 4D Systems, but first we want to finish up the already half-done Matrix Orbital GTT rendering path. We may not get to fully supporting the original LCDsysinfo though, since it is quite a basic protocol, with certain capabilities that are closer to the alphanumeric displays than to the graphical displays.

If you're looking for a 320x240 small colour LCD with USB connection, that also supports direct addressing (and so is directly and fully supported by AIDA64 LCD module), I suggest you to check out the AX206-based firmware-hacked DPF (Digital Picture Frame) LCDs, like the one made by Pearl. You can purchase them, with their firmware already hacked on eBay, just search for:

lcd4linux Pearl


lcd4linux LCD

More information on AX206 DPF hacking:







The next AIDA64 beta (due in 1 or 2 days from now) will implement full support for such AX206-based hacked DPF LCDs. The only trick is that they do not come with a Windows driver, so you either have to patch an existing LibUsb0-based Windows driver, or ping me in private message and I'll send you the driver that we've made for our Pearl AX206 DPF. The driver will work with any other AX206-based firmware-hacked DPF device.

The mentioned very next AIDA64 beta will also support the following new LCD and VFD devices BTW:

- Acer Idea 500 VFD

- ct-Mausekino LCD

- Cwlinux LCD

- picoLCD

- SoundGraph iMon LCD (iMon UltraBay)

- Sure Electronics LCDs

- Trefon LCDs

Link to comment
Share on other sites

Hi Fiery


Thank for all the detailed info. AX206 displays seem hard to locate here in the States. As the GOverlay display cost very little money I'll probably pick one up to use for now. I'll keep looking for a AX206 display or possibly when you have the Matrix Orbital GTT coding done pick up one of them. Do you anticipate AIDA64 working with all the differnt size GTT displays?

Link to comment
Share on other sites

I'm not sure why the AX206 display would have to sold locally in the States for you to purchase it. You can order one from overseas, and pay a little customs tax, and use it happily with AIDA64 :) GOverlay may cost little money, but its capabilities are also heavily limited. You can get one, but when it comes to what you can achieve with the AIDA64 LCD module, an AX206 display would simply blow it away. The GOverlay display should really have a much more advanced firmware, at least as sophisticated as the one for the Matrix Orbital GTT. You can't even use a background image on the GOverlay, not to mention many other important visual elements.

As with the GTT, AIDA64 will support all display sizes, as long as they are in the GTT Rev2 family. So GTT35A, GTT43A, GTT50A and GTT70A will all be fully supported. The old GTT480272A and the discontinued GTT57M are not validated by us, but they may still work properly. However, please note that the GTT protocol doesn't support a few features that AIDA64 would want to use for rendering, e.g. it doesn't support bold or italic font styles at all. Also, when you use a lot of dynamically changing elements, especially graphs and gauges, rendering may take several seconds on those non-directly addressable devices (GTT, 4D Systems, LCDsysinfo). So while those displays look great and feel like a proper external display, their use is not so convenient and could be very limited. It's always best to use a directly addressable display, for them the only issue could be the slow update rate -- but usually it's in the acceptable range of between 100 and 500 milliseconds.

BTW, in the not so far future we'll also implement support for Samsung SPF digital photo frames as well. Maybe those things will be easier for you to find locally.

Link to comment
Share on other sites



My serch skills must really suck. I find nothing on any of the ebay sites. Using Google I find some at Pearl and DX.com but they all show as out of stock. I'm using a couple of old 4x20 serial CrystalFontz displays now so will hold off until you have GTT support implemented. Thanks agian

Link to comment
Share on other sites

Here's the eBay item for a Pearl AX206 already firmware-hacked LCD:


We've ordered one from him a few weeks ago.

BTW, what kind of Crystalfontz displays do you use, and with which software? Do you have multiple displays connected to a single computer? I'm just asking, because we'll soon implement support for Crystalfontz LCDs as well ;)

Link to comment
Share on other sites

This is weird. Even searching for that display from the page you linked to shows no results. Doesn't make sense when I'm at the page where the display is listed.


Both displays are the Crystalfontz 634 serial version. They are probably 8 - 10 years old. I forget I had them till going through a bunch of stuff not long ago. I have one display per computer (Win8.1) connected with a FTDI based USB to serial cable. I'm using CrystalControl2 and accessing the AIDA64 data using WMI.

Link to comment
Share on other sites

Maybe those listings do not appear for you because the seller limited the geological availability of the items? I never sold stuff on eBay, so I'm not sure if it's possible to do that. Anyway, if you want to buy one, I can try reaching out to the seller to ask what's the procedure of selling it to you.

As for Crystalfontz, your displays will soon be fully supported. CFA533, CFA631, CFA632, CFA633, CFA634 and CFA635 displays with a USB connector (or FTDI RS232 --> USB converter) will be supported first by AIDA64, and then CFA735 and CFA835 will come in the next round. Later on we may add support for RS232 (serial) Crystalfontz and Matrix Orbital devices as well.

Link to comment
Share on other sites

Thanks for the offer. I think I'll hold off getting anything until you have support for the Gtt displays or possibly the Samsungs as they appear to be easy to obtain.

We've just rolled out a new AIDA64 beta that supports Samsung SPF Digital Photo Frames, Futaba MDM166A and Yoctopuce LCDs:


Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
  • 2 weeks later...

What are the chances of implementing support for tablets? How incredibly awesome would it be to be able to stand my nice 10" tablet up next to my monitor and have AIDA64 stats for my PC displayed? Compared to a 2.5" little LCD screen? Pfft..


Basically just an AIDA64 app that receives data from my PC AIDA64 software and allows me to do some of the things I can do with the SensorPanel currently in AIDA64 on my PC. Could even start out simple and have preset 'modules' to display in the app, then if successful start allowing more and more customization. Or alternatively treat it like you do the LCD panels above and just have a 'receiver' app that then displays on the tablet like you do on LCD panels.


I'd have zero hesitation in paying an extra couple bucks for an AIDA64 android app that could do that, even if it required me to have my tablet plugged into a USB port like the LCD panels above.

Link to comment
Share on other sites

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:


Link to comment
Share on other sites

What about going at it a different way? Instead of sending a pre-rendered bitmap to be displayed, simply send plain text data and let the actual app do the rendering based upon the data received? Use the processing power of the tablet/phone instead of making AIDA64 on the PC do all the work. I can't imagine it would be too difficult to design a fairly simple (to start with) app that gave users let's say a square grid of X 'slots'. They get to pick which style is displayed in each box (e.g. graph, bar, text, gauge) and then what data to display on that box.


Extremely oversimplifying it of course, but AIDA64 sends a short stream of text to the app where each packet's header is the box followed by the data itself.. Example value of "163" - could represent data destination is box 1, data is 63. The app receives it, knows it goes to box one, knows the user has specified box one is a graph and that it displays CPU utilization %. So the screen displays a pretty little graph and enters a 63% data point. All done with 3 characters of data for a single monitor in the app.. Easy peasy!


Obviously there would be some limitations to make things easier and the full power of AIDA64 may not initially be present, but it's an extremely exciting path. I have yet to find anyone else doing it and bet lots of people would like it. Heck, could even be used as a (slower to update perhaps) remote system monitor. Lots of possibilities.. :)

Link to comment
Share on other sites

What about going at it a different way? Instead of sending a pre-rendered bitmap to be displayed, simply send plain text data and let the actual app do the rendering based upon the data received? Use the processing power of the tablet/phone instead of making AIDA64 on the PC do all the work.

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.

I can't imagine it would be too difficult to design a fairly simple (to start with) app that gave users let's say a square grid of X 'slots'. They get to pick which style is displayed in each box (e.g. graph, bar, text, gauge) and then what data to display on that box.

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.


Obviously there would be some limitations to make things easier and the full power of AIDA64 may not initially be present, but it's an extremely exciting path. I have yet to find anyone else doing it and bet lots of people would like it. Heck, could even be used as a (slower to update perhaps) remote system monitor. Lots of possibilities.. :)

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.

Link to comment
Share on other sites

What if you send those bitmaps to the smartphone and than use this app to view them??


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.

Link to comment
Share on other sites

  • 3 weeks later...

You said earlier you would support LCDSysInfo for GOverlay at some point... Do you have an ETA on that or it's just a distant possibility ?


thank you ...

Problem is: the USB protocol for LCDsysinfo was only published for the original LCDsysinfo device, but not for the more advanced GOverlay device. We've contacted the company behind the GOverlay both in email and through eB*y to request specifications, API description, SDK or any other material to let us connect to the device in AIDA64, but we've got absolutely no response from them. It's quite tough to work this way, and I cannot promise anything at this time about GOverlay.

Link to comment
Share on other sites

Problem is: the USB protocol for LCDsysinfo was only published for the original LCDsysinfo device, but not for the more advanced GOverlay device. We've contacted the company behind the GOverlay both in email and through eB*y to request specifications, API description, SDK or any other material to let us connect to the device in AIDA64, but we've got absolutely no response from them. It's quite tough to work this way, and I cannot promise anything at this time about GOverlay.


thank you for the quick response !

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By WanaGo
      I hope this hasn't already been covered, not found this exact question though already asked.
      4D Systems makes a bunch of LCD products which mainly have UART interfaces. They are not primary display interfaces, so don't take an HDMI input etc from your PC, they can be programmed to handle serial data and display it in various ways. You design the GUI yourself in their IDE and then you feed it the data you want in the known format, and make it do what you like with that data.
      What I am trying to find out is if there is a way to use AIDA64 to collect the data from the PC, such as CPU temperature etc, and send the data out the UART to the display. I don't want all the graphics from AIDA64, all I want is the data for the sensors.
      I have used AIDA64 for a while, going to a external HDMI monitor and displaying data on that, and it works, but now and then I get issues where windows decides the little monitor is the primary, or the mouse goes in there and gets stuck, and all sorts of other weird things. I also dont want it loading my GPU at all, I just want it off that whole system entirely.
      Is there a way to have AIDA64 export in a stream the selected Sensor data, to the serial UART? These 4D displays can handle BAUD's into the MBaud rates, so not 9600 or 115200 type levels.
      If there is, can you please point me in the right direction.
      If there is a way to get this data, I can create a demo project use a 4D Systems display, and post that up here for other people to use as a base. I have used 4D displays for years in various applications at work and around the house, we build full systems at work using their products, and it just seems the perfect application for PC Chassis builds, rather than using HDMI type solutions off the GPU. Let the display do the GUI 'heavy lifting' itself with its GPU and just feed it the data it is looking for from AIDA64.
      Any tips would be appreciated
    • By Bas101
      Is it possible to use 2 (or more) LCDs display different data?  Example: #1 for essential CPU etc while a #2 would have cooling info like fans, liquid temps etc.  If so... what are some recommendations?  Keep hearing Beada (which could work).  Alternatively, is there a larger compatible LCD?  Ideallly bar style but 17-18 wide.
      TY in advance for any guidance!!
    • By Rich83
      hi all, newbie here! this is my first post so i hope it has landed in the correct place..  be gentle!

      i have installed the 'simple' version of a64, is it possible to run multiple instances of the sensor panel? i have the sensor panel running in a 5 inch screen located inside my case but have a room change planned which will put the case high on a shelf out of my eye sight so i would like a second display for stats placed under my main monitor. i plan to use a larger screen say a 10.1 'ultrawide (if thats the correct term) as i like the extra real-estate. what are my options?
      on a similar topic, is it possible to create an 'unpublished' senor panel before removing the currently used panel? or would i have to save the current panel to file or something then start a new panel?
      also can anyone point me to gauge resources, ie pre made gauges? or an easy to understand tutorial for how to diy them? total novice here, but can follow an idiots guide!

      i have included the final evolution of my first attempt using the provided gauges etc, it took me ages to get rid of the green dials.. i finally gave up trying to figure it out in a64 so i just changed the hue on the 5inch monitor lol. really hoping to learn the skills to create something like i have seen on here.. some really nice work on the share your panel thread, some of those must have taken ages!!! impressive. 
      any advice greatly received, but remember your talking to an a64 absolute novice!!
      Thanks folks. 

  • Create New...