Jump to content
AIDA64 Discussion Forum
Roy

Simple send to an serial port

Recommended Posts

Hi,

it would be nice if there was the possibility to send sensor values unformatted as a number or percentage, via a serial port.

Similar to the LCD displays, only without formatting, or pure numbers with separators.
Together with a small GUI.

Background is the simple evaluation of the data with a microcontroller and display in different ways.
I imagine not only LCD or OLED, but rather seven segment display, nixi tubes or an analog pointer display.

That would create a lot of possibilities.

Share this post


Link to post
Share on other sites
2 hours ago, Roy said:

Hi,

it would be nice if there was the possibility to send sensor values unformatted as a number or percentage, via a serial port.

Similar to the LCD displays, only without formatting, or pure numbers with separators.
Together with a small GUI.

Background is the simple evaluation of the data with a microcontroller and display in different ways.
I imagine not only LCD or OLED, but rather seven segment display, nixi tubes or an analog pointer display.

That would create a lot of possibilities.

We would prefer to add such new projects as a new, dedicated LCD device to the AIDA64 LCD module.  If you have a project in development, let us know, and we'll take care of supporting the device using a dedicated codepath.

Share this post


Link to post
Share on other sites

A concrete project does not exist yet.
The idea is to build a steampunk case and it always looks good when old analog gauges or segment displays are used.
Driving the individual parts is no problem with an Arduino. But passing on the data to the microcontroller seems to be more difficult.
During my research on the net I found a lot of demands, but only a few solutions.
However, these solutions always consist of small self-written programs, which use either the shared memory of AIDA64 or the OpenHardwareMonitor library or their web interface.
Without this monster of MS Visual Studio and knowledge in C # or Python you can not get on with it.
I think for such an issue would be the modding scene and also the hobbyists who might want to control their heating inversely proportional to the CPU load, grateful.
For the output formatting I would like a variable solution in which you simply put together a string. Just like the individual display parts on the LCD's.
Then the selection of the Com Port, a baud rate and interval to it and done.

Share this post


Link to post
Share on other sites
On ‎1‎/‎31‎/‎2019 at 2:00 PM, Roy said:

A concrete project does not exist yet.
The idea is to build a steampunk case and it always looks good when old analog gauges or segment displays are used.
Driving the individual parts is no problem with an Arduino. But passing on the data to the microcontroller seems to be more difficult.
During my research on the net I found a lot of demands, but only a few solutions.
However, these solutions always consist of small self-written programs, which use either the shared memory of AIDA64 or the OpenHardwareMonitor library or their web interface.
Without this monster of MS Visual Studio and knowledge in C # or Python you can not get on with it.
I think for such an issue would be the modding scene and also the hobbyists who might want to control their heating inversely proportional to the CPU load, grateful.
For the output formatting I would like a variable solution in which you simply put together a string. Just like the individual display parts on the LCD's.
Then the selection of the Com Port, a baud rate and interval to it and done.

The problem with pushing a long string to the COM port would be the amount of data going through a rather narrow pipe (e.g. 9600 bps).  Hence I don't think it would be optimal to simply push the raw data (like the full content of the shared memory) as a long string to the COM port.  Unless of course your serial connection is a relatively high performance one, like 115000 bps.

Share this post


Link to post
Share on other sites

I do not see this as such a big problem, because if you can put together the data you need, similar to the LCD's and only relavantes further, the string should not be too long.

For what I imagined, that would be:
- CPU load
- CPU temperature
- GPU load
- GPU temperature
- RAM occupancy

The string could look like this:
25;55;30;45;3545;
or:
CL25,CT55,GL30,GT45,R3545;

So only the most necessary joined together with separators.
That makes 36 characters in the constelation, that is 360 bits.
Maximum update at 9600 baud: 26 / s.
But that's not all that much, since such ads are rather crude and sluggish.
Apart from that, even the small Arduino Uno creates the 115000 baud.

Share this post


Link to post
Share on other sites
8 hours ago, Roy said:

I do not see this as such a big problem, because if you can put together the data you need, similar to the LCD's and only relavantes further, the string should not be too long.

For what I imagined, that would be:
- CPU load
- CPU temperature
- GPU load
- GPU temperature
- RAM occupancy

The string could look like this:
25;55;30;45;3545;
or:
CL25,CT55,GL30,GT45,R3545;

So only the most necessary joined together with separators.
That makes 36 characters in the constelation, that is 360 bits.
Maximum update at 9600 baud: 26 / s.
But that's not all that much, since such ads are rather crude and sluggish.
Apart from that, even the small Arduino Uno creates the 115000 baud.

Well, no, we wouldn't go for such a constrained (non-flexible) solution.  The user should be able to pick the sensor values he would like to have sent to the COM port, including the labels and measurement units.  And that's what makes the string long.  But if you say 115000 bps is available, then even long strings shouldn't make things too slow.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Wampo
      Hey Aida Team,
      i have some issues with this Adafruit LCD wich is recomended. On the two Pictures you can see what aida should do and what can i see on the Display. The First line is completely erased and the screen is flickering. The Adafruit Backpack is set to 20x4 LCD. When the Display is updating you can see the right setting for a millisecond.
      But if i change the LCD Setting in AIDA to 16x2, and leave the Backpack in 20x4 mode,  the Screen isn flickering and the first line is there. I think you got a little problem with the 20x4 Driver. I have Searched for the code but i cant find it, to edit it if i found the failure. 
       
      Please give me response for this BUG. I have extra ordert this overpriced 50€ LCD for it. 
      Greetings Daniel from Germany


      VID_20181129_160917.mp4
    • By Fiery
      We've added support for RoboPeak RPUSBDisp color graphical USB-connected LCD display.

      You can enable the LCD device from AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / RoboPeak. Currently there is no Windows driver made specifically for RoboPeak displays.  But there's a workaround: you can use the AlphaCool LCD driver (Version 2.1).  The driver installation has to be forced due to the USB device ID mismatch (between AlphaCool and RoboPeak displays).
      The driver installation works as:
      Open Device Manager --> Other devices --> double-click on rp-usbdisp --> Update Driver button --> Browse my computer for driver software --> Let me pick from a list of available drivers on my computer --> Show All Devices --> Next button --> Have Disk button --> Browse button --> select acusbdisplay.inf file from the AlphaCool LCD driver folder --> Next button --> press Yes button on the Update Driver Warning message box.

      You can order a RoboPeak display from DFRobot at:
      https://www.dfrobot.com/product-1062.html#.UqfXHfSnoqX
      You can find the new AIDA64 beta update at:
      https://www.aida64.com/downloads/latesta64xebeta
      Please let us know if you find any difficulties enabling or using this new feature. Also let us know if you've got another kind of LCD device that is currently unsupported by AIDA64.
      Regards,
      Fiery
    • By Fiery
      We've added support for several Matrix Orbital USB character based and monochrome graphical LCD displays, including LK, MX, PK, VK, GLK, GLT, GX Typhoon, and their drive-bay and external variants as well.
      You can enable the LCD device from AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD. The only thing needed to enable this feature is having the appropriate Matrix Orbital USB LCD drivers installed, and the LCD to be connected to a USB port. You can verify if your device is supported by AIDA64 by finding the device on the Devices / USB Devices page in AIDA64, and checking its Device ID. It should be one of the following IDs:
      0403-FA01
      0403-FA02
      0403-FA03
      0403-FA04
      0403-FA05
      1B3D-011F
      1B3D-0120
      1B3D-0121
      1B3D-0123
      1B3D-0125
      1B3D-0127
      1B3D-012C
      1B3D-0134
      1B3D-013E
      1B3D-013F
      1B3D-0140
      1B3D-0141
      1B3D-0155
      1B3D-0156
      1B3D-0157
      1B3D-0158
      1B3D-015E
      1B3D-0161
      1B3D-016A
      1B3D-016B
      1B3D-016C
      1B3D-0176
      1B3D-017B
      1B3D-01F0
      1B3D-01F1

      Due to their interface bottleneck BGK, EGLK, GLK and GLT displays perform display updates quite slowly, so visual discrepancies may be experienced when using the GLK (graphics) protocol on these displays. It is possible to use the LK (character based) protocol on GLK displays as well, which will work much faster. In order to switch between the GLK and LK protocols, you need to first disable the GLK protocol (in AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD), and then enable the LK protocol on the same page. Ignore the error, and restart AIDA64 to apply the switch.
      You can find the new AIDA64 beta update at:
      http://www.aida64.com/downloads/latesta64xebeta
      Please let us know if you find any difficulties enabling or using this new feature. Also let us know if you've got another kind of LCD device that is currently unsupported by AIDA64. BTW, Abacom, AlphaCool, Digital Devices, LCD2USB, Mad Catz Venom, and SDC Megtron LCDs are also supported now by the latest AIDA64 beta.
      Regards,
      Fiery
    • By Fiery
      We've added support for the built-in 160x32 pixel monochrome LCD screen of EVGA Z10 gaming keyboard.  You can enable the LCD device from AIDA64 / main menu / File / Preferences / Hardware Monitoring / LCD / EVGA.
      [/
      Currently AIDA64 communicates with the LCD directly, using USB HID interface.  It collides with EVGA's own software (EVGA Unleash), so it's recommended to close that software before enabling EVGA Z10 support in AIDA64.  EVGA will soon develop a proper SDK/API for their keyboard, much like the LCD API of Logitech gaming keyboards, so that multiple software can put information on the LCD the same time, without collisions.
      You can find the new AIDA64 beta update at:
      https://www.aida64.com/downloads/latesta64xebeta
      Please let us know if you find any difficulties enabling or using this new feature. Also let us know if you've got another kind of LCD device that is currently unsupported by AIDA64.
      Regards,
      Fiery
    • By Novius
      Hello. 
      Is it possible to see from the AIDA file what type of LCD is connected? For example to tell if its an OLED or IPS panel. 
×