Do you have an unsupported LCD or VFD?

[Fiery]

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.

 

Regards,

Fiery

[Praz]

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.

 

http://coldtearselectronics.wikispaces.com/LCDsysinfo+For+GOverlay+-+Powerful+Info+Gadget+for+gamers

 

Thanks

 

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
https://github.com/dang
ardner/pylcdsysinfo
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
command
* 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)

 

[Fiery]

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

or

lcd4linux LCD

More information on AX206 DPF hacking:

http://picframe.spritesserver.nl/wiki/index.php/DPF_with_AppoTech_AX206

http://bastel.dyndns.info/~dockstar/lcd/

http://sourceforge.net/projects/dpf-ax/

http://www.zebradem.com/wiki/index.php?title=Lcd4linux

http://www.oli82.de/blog/?p=600

http://openschemes.com/2011/08/23/our-turn-with-the-ax206-digital-photo-frames/

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

[Fiery]

Here's the new AIDA64beta that I've mentioned in my previous post:

http://www.aida64.com/downloads/aida64extremebuild3104t4gjsw2khpzip

[Praz]

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?

[Fiery]

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.

[Praz]

Hello

 

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
 

[Fiery]

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

http://www.ebay.com/itm/lcd4linux-6-1-cm-2-4-Display-DPF-Coolstream-Dreambox-Enigma-Pearl-Linux-HD-/251599797594?pt=DE_Foto_Camcorder_Digitale_Bilderrahmen&hash=item3a94843d5a

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

[Praz]

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.

[Fiery]

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.

[Praz]

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.

[Fiery]

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:

http://forums.aida64.com/topic/2424-new-lcd-device-support-samsung-spf-digital-photo-frames/

[Fiery]

We've just rolled out a new AIDA64 beta that supports BWCT, Crystalfontz and POS VFD displays:

http://forums.aida64.com/topic/2433-new-lcd-device-support-crystalfontz/

[Fiery]

We've just rolled out a new AIDA64 beta that supports LCDInfo and Aquaero 4 displays:

http://forums.aida64.com/topic/2449-new-lcd-device-support-lcdinfo-usb13700-and-usbd480/

[Fiery]

We've just rolled out a new AIDA64 beta that supports Aquaero 5 and Aquaero 6 displays, as well as Matrix Orbital RS232 LCDs:

http://forums.aida64.com/topic/2458-new-lcd-device-support-aquaero/

[Fiery]

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/

[mack624]

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.

[Fiery]

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/

[mack624]

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..

[Fiery]

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.

[mortillo]

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

https://play.google.com/store/apps/details?id=be.wyseur.photo&hl=it

[Fiery]

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

https://play.google.com/store/apps/details?id=be.wyseur.photo&hl=it

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.

[ermethic]

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 ...

[Fiery]

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.

[ermethic]

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 !