Reply to thread

Message

<blockquote data-quote="Herr R aus B" data-source="post: 219379" data-attributes="member: 62807">Great - that releases me from the suspicion to be some nerd <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink&nbsp; &nbsp; ;)" loading="lazy" data-shortname=";)" /> I did some testing - the problem is reproducable and obviously not related to your driver. Although I attached two logs - one before and one after killing the process. And there is no diffeence between these logs. That leads me to the assumption, that this 32 bit application closes correctly but is not properly handled by the 64 bit runtime. Anyway - maybe it's also a bug in the configuration utility. But as there's no official support for 64 bit systems yet...Complete misunderstanding. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /> What I meant was, that I have a windows service in mind, that offers several interfaces (plain pure common and boaring sockets or more sophisticated SOAP based web services to be state of the art). These interfaces would be:<ul>
<li data-xf-list-type="ul">configuring automatic fan control (on tcp port X, should be configurable)</li>
<li data-xf-list-type="ul">reading temperature values and setting fan speeds (on tcp port Y, should be configurable)</li>
<li data-xf-list-type="ul">setting display contents (on tcp port Z, should be configurable)</li>
<li data-xf-list-type="ul">reading remote codes (probably using the IRTrans protocol on port 21000)</li>
</ul>My question was meant like as in would you be interested to write a display driver, that accesses this service instead of accessing the VFD itself. This could also incorporate configuring automatic fan control etc - each as seperate plugins as the service offers several interfaces on different ports. The other benefit would be, that i could provide a VFD simulator this way. This is simply a little bit service oriented way of doing it - just a proposal, though <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />This was not meant to be a complaint at all! I just wanted to be helpful <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> Right - i didn't say, that I can reproduce this behaviour. All this, what I posted happens during the MHC shows its (very colorful) splash screen. The first part must be searching for the device, as MHC says it was scanning all the COM ports. Seems just to be the cheap way of shouting to all directions and wait for some answer <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /> Then there is one line, I thought it was part of the &quot;where is my COM port&quot; search:A5 38 ¥8According to your source code this sets the display's brightness to 100% (whith 25% = 0x3B, 50% = 0x3A, 75% = 0x39, 100% = 0x38). This then always is followd by initilizing the fans according to the AFC settings in the MHC software. Then the display is set to whatever startup message is configured. The most interesting thing is this 41 byte block at the end if the initialization. My guess is, that it sets a bunch of paramters which are - of coruse! - nit documented. I wrote to Zalman, to VL System and I also contacted that guy <a href="https://forum.team-mediaportal.com/member.php?u=29291" target="_blank">dero</a> here from the german section of the forum, because he did some testing and wrote some controlling software for this VFD. But I didn't get any response so far. And I doubt, that Zalman or VL System will let private persons peek into their deep secrets <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown&nbsp; &nbsp; :(" loading="lazy" data-shortname=":(" /> I also tried to find out, whether some linux folks already analyzed this VFD - so far no results, but I am sure there will be something sooner or later.Anyway - these 41 bytes are rather interesting, as such blocks occur here and there with slightly different content. So far I would just try to emulate exactly what I sniffed and to release you from all this impossible testing I thought, it might be a good idea to have the opportunity to specify all this hex code stuff in some configuration file - that would help me to do some testing here using your driver.I did so and I am amazed! Works perfectly - at least it switches off the fans and there is wonderful silence <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" />&nbsp; Now of course it would be great if the driver would be able to set fan speeds (see my above attachments). At the moment, I think, that reading the temperatures is done sending the VFD a 0xAF and get two bytes in return, where the first byte seems to be the second sensor and the second byte the first sensor. At least that is, how the MHC software treats the values.Again - that was not meant as a complaint! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> In that earlier post I attached a file showing what MHC writes tp the COM port before sending windows to standby:00 00 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ...AE AE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ®®undocumented stuff...A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43&nbsp;&nbsp; ¡.§M.Play Home C65 6E 74 65 72 20 20 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; enter&nbsp; .A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64&nbsp;&nbsp; ¢.§&nbsp; &nbsp; &nbsp; &nbsp; Stand62 79 20 4D 6F 64 65 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; by Mode.setting the display text...AC 47 47&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ¬GGsetting the fans to 40%A4 7E&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ¤~A4 76&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ¤v01&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .11&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .1E&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .1F&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .01&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .0C&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .1D&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .0B&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .AE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ®undocumented stuff...A5 3B&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; ¥;setting the display's brightness to 25%This matches what I can watch during the process of sending the PC to standby. After this sequence is completed, windows goes to standby and can be woke up using the PwrOff button. And exactly this doesn't work with your driver. That means, pressing the PwrOff button sends the PC to standby, but then you can't wake it up using the remote - no matter what button you press. Hitting the keyboard, moving the mouse or pressing the case's PwrOn/Off button shortly wakes windows up again. My guess would be, that one of the following conditions are true:<ul>
<li data-xf-list-type="ul">The MHC software somehow listens to what happens on the COM port and wakes up windows, when PwrOff button on the remote is pressed</li>
<li data-xf-list-type="ul">The above undocumented byte sequence between setting the display's text and dimming the display to 25% tells the VFD to listen for certain keystrokes and then wake up windows by emulating a short press of the case's PwrOn/Off button - this makes sense, as the VFD is connected between the case's PwrOn/Off button and the motherboard</li>
</ul>I tend to think it's the latter, because what application should listen to the COM port when windows is asleep? Especcially after the COM port log also shows, that the MHC software releases the COM port after sending the above sequence:015813: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_PURGE: Purge requests&nbsp; Purge mask=TXABORT: Read requests, RXABORT: Receive buffer015814: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_PURGE: Purge requests015815: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask&nbsp; WaitMask=None015817: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask015818: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_PURGE: Purge requests&nbsp; Purge mask=TXCLEAR: Write requests, RXCLEAR: Write buffer015819: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0IOCTL_SERIAL_PURGE: Purge requests015820: Close Request (DOWN), 30.12.2007 17:01:29.437 +0.0Buffer size: 0x0 bytes015821: Close Request (UP), 30.12.2007 17:01:29.546 +0.109Buffer size: 0x0 bytesStatus: 0x00000000You probably couldn't find any, as this was described in the german section by this dero (see above). Aren't you reading the german posts??? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /> (Kidding!) Anyway, the driver still doesn't react on permanently pressed buttons. What i wrote in that PDF file was insufficent I think, because I thought each key stroke results in two bytes. Somehow, this remote itself is a little bit crappy, because using it over the MHC software, it produces duplicated key strokes. Seem as if the buttons on the remote itself are rather cheap... Anyway - as far as I watched it und that is congruent with what I found, the remote is supposed to work like this:1D -&gt; DOWN was pressed once1D 7E 7E 7E 7E 7E 7E 7E -&gt; DOWN was hold and should result in 8 DOWNs (7 repeats)But it could also be like this:1D 7E -&gt; DOWN was pressed once1D 7E 7E 7E 7E 7E 7E 7E -&gt; DOWN was hold and should result in 7 DOWNs (6 repeats)The latter version seems to be rather illogical. I dunno how you treated the information so far. The result is, that no matter how long a hold a remote button pressed, I get exactly one key stroke. That is, if I need 4 DOWNs I have to hit the Down button 4 times. Anyway - your driver treats the remote signals better than the HMC software as you obviously filter out some of these unwanted duplications produced by this (rather crappy) remote...Maybe a good solution would be to remeber the last valid remote code and ignore 2 or 3 directly following 0x7E. Then if there are additional 0x7E send the last valid remote code instead. That should result in a behaviour like having a short gap between one button stroke and repeated button strokes... Just a proposal. The problem would be to define what are valid remote codes - maybe thos, defined in the XML file...You are very welcome - as I stated before, I am not complaining but just trying to support your work as much as I can! And I like the new version - especially the fact, that one can disable the remote. This MPlay remote really is a pain in the a****.&nbsp; The remote sensor wouldn't accept most of the remote codes sent ba a generic and programmable remote that controls all my other equipment wothout any problems. Even worse, some of the remote codes of the MPlay remote interfere woth my other devices. Terrifying! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite4" alt=":mad:" title="Mad&nbsp; &nbsp; :mad:" loading="lazy" data-shortname=":mad:" /> Now with your driver I have the chance to ignore this MHC stuff and the MPlay remote and maybe succeed with using an old Terratec Cynergy USB IR receiver. Maybe that one is able to talk to my generic remote...Works brilliantly so far! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /> There still is that german umlaut issue. This definately is no problem with the VFD, as it cn display them perfectly (see attached picture). This is, what MHC sends to the display:A1 00 A7 20 20 20 20 20 41 75 74 6F 20 55 73 65&nbsp;&nbsp; ¡.§&nbsp; &nbsp;&nbsp; Auto Use72 20 20 20 20 20 20 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; r&nbsp; &nbsp; &nbsp; .A2 00 A7 20 20 20 20 20 49 6E 64 69 63 61 74 6F&nbsp;&nbsp; ¢.§&nbsp; &nbsp;&nbsp; Indicato72 20 20 20 20 20 20 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; r&nbsp; &nbsp; &nbsp; .A1 00 A7 D6 20 F6 20 DC 20 FC 20 C4 20 E4 20 DF&nbsp;&nbsp; ¡.§Ö ö Ü ü Ä ä ß20 20 20 20 20 20 20 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .A2 00 A7 20 20 20 20 20 20 20 20 20 20 20 20 20&nbsp;&nbsp; ¢.§&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; 20 20 20 20 20 20 20 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .Now as you can see in screenshot of MP with german language defined for the skin, MP displays the umlauts perfectly, but then sends these question marks to the VFD. Here is a log of what your driver writes to the COM port:00 A7&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; .§4D 65 69 6E 65 20 46 69 6C 6D 65 20 20 20 20 20&nbsp;&nbsp; Meine Filme&nbsp; &nbsp;&nbsp; 20 20 20 20&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; 00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .00&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; .A2&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ¢00 A7&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; .§3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 20 20&nbsp;&nbsp; ? ? ? ? ? ? ?&nbsp;&nbsp; 20 20 20 20&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; Could that maybe be an issue with windows code pages, unicode or whatever transformation within MP?Once again: I really appreciate your work and please don't take my rather long comments as complaints or nagging or whatever. I am really trying to provide you with as much information as I can as I know that this blind coding you are doing at the moment is rather annoying.Greetings,AxelPS: Just to give you more information - <a href="http://www.vlsys.co.kr/English/oem_mr300.php" target="_blank">this here</a> is the device we are talking about <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /></blockquote>

[QUOTE="Herr R aus B, post: 219379, member: 62807"] Great - that releases me from the suspicion to be some nerd ;) I did some testing - the problem is reproducable and obviously not related to your driver. Although I attached two logs - one before and one after killing the process. And there is no diffeence between these logs. That leads me to the assumption, that this 32 bit application closes correctly but is not properly handled by the 64 bit runtime. Anyway - maybe it's also a bug in the configuration utility. But as there's no official support for 64 bit systems yet... Complete misunderstanding. :D What I meant was, that I have a windows service in mind, that offers several interfaces (plain pure common and boaring sockets or more sophisticated SOAP based web services to be state of the art). These interfaces would be: [LIST] [*]configuring automatic fan control (on tcp port X, should be configurable) [*]reading temperature values and setting fan speeds (on tcp port Y, should be configurable) [*]setting display contents (on tcp port Z, should be configurable) [*]reading remote codes (probably using the IRTrans protocol on port 21000) [/LIST] My question was meant like as in would you be interested to write a display driver, that accesses this service instead of accessing the VFD itself. This could also incorporate configuring automatic fan control etc - each as seperate plugins as the service offers several interfaces on different ports. The other benefit would be, that i could provide a VFD simulator this way. This is simply a little bit service oriented way of doing it - just a proposal, though :D This was not meant to be a complaint at all! I just wanted to be helpful :) Right - i didn't say, that I can reproduce this behaviour. All this, what I posted happens during the MHC shows its (very colorful) splash screen. The first part must be searching for the device, as MHC says it was scanning all the COM ports. Seems just to be the cheap way of shouting to all directions and wait for some answer :D Then there is one line, I thought it was part of the "where is my COM port" search: [FONT="Courier New"][SIZE="2"][B]A5 38 ¥8[/B][/SIZE][/FONT] According to your source code this sets the display's brightness to 100% (whith 25% = 0x3B, 50% = 0x3A, 75% = 0x39, 100% = 0x38). This then always is followd by initilizing the fans according to the AFC settings in the MHC software. Then the display is set to whatever startup message is configured. The most interesting thing is this 41 byte block at the end if the initialization. My guess is, that it sets a bunch of paramters which are - of coruse! - nit documented. I wrote to Zalman, to VL System and I also contacted that guy [URL="https://forum.team-mediaportal.com/member.php?u=29291"]dero[/URL] here from the german section of the forum, because he did some testing and wrote some controlling software for this VFD. But I didn't get any response so far. And I doubt, that Zalman or VL System will let private persons peek into their deep secrets :( I also tried to find out, whether some linux folks already analyzed this VFD - so far no results, but I am sure there will be something sooner or later. Anyway - these 41 bytes are rather interesting, as such blocks occur here and there with slightly different content. So far I would just try to emulate exactly what I sniffed and to release you from all this impossible testing I thought, it might be a good idea to have the opportunity to specify all this hex code stuff in some configuration file - that would help me to do some testing here using your driver. I did so and I am amazed! Works perfectly - at least it switches off the fans and there is wonderful silence :D Now of course it would be great if the driver would be able to set fan speeds (see my above attachments). At the moment, I think, that reading the temperatures is done sending the VFD a 0xAF and get two bytes in return, where the first byte seems to be the second sensor and the second byte the first sensor. At least that is, how the MHC software treats the values. Again - that was not meant as a complaint! :) In that earlier post I attached a file showing what MHC writes tp the COM port before sending windows to standby: [FONT="Courier New"][SIZE="2"][B]00 00 00 ... AE AE ®® [/B][/SIZE][/FONT] undocumented stuff... [FONT="Courier New"][SIZE="2"][B]A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43 ¡.§M.Play Home C 65 6E 74 65 72 20 20 00 enter . A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64 ¢.§ Stand 62 79 20 4D 6F 64 65 00 by Mode.[/B][/SIZE][/FONT] setting the display text... [FONT="Courier New"][SIZE="2"][B]AC 47 47 ¬GG[/B][/SIZE][/FONT] setting the fans to 40% [FONT="Courier New"][SIZE="2"][B]A4 7E ¤~ A4 76 ¤v 01 . 11 . 1E . 1F . 01 . 0C . 1D . 0B . AE ®[/B][/SIZE][/FONT] undocumented stuff... [FONT="Courier New"][SIZE="2"][B]A5 3B ¥;[/B][/SIZE][/FONT] setting the display's brightness to 25% This matches what I can watch during the process of sending the PC to standby. After this sequence is completed, windows goes to standby and can be woke up using the PwrOff button. And exactly this doesn't work with your driver. That means, pressing the PwrOff button sends the PC to standby, but then you can't wake it up using the remote - no matter what button you press. Hitting the keyboard, moving the mouse or pressing the case's PwrOn/Off button shortly wakes windows up again. My guess would be, that one of the following conditions are true: [LIST] [*]The MHC software somehow listens to what happens on the COM port and wakes up windows, when PwrOff button on the remote is pressed [*]The above undocumented byte sequence between setting the display's text and dimming the display to 25% tells the VFD to listen for certain keystrokes and then wake up windows by emulating a short press of the case's PwrOn/Off button - this makes sense, as the VFD is connected between the case's PwrOn/Off button and the motherboard [/LIST] I tend to think it's the latter, because what application should listen to the COM port when windows is asleep? Especcially after the COM port log also shows, that the MHC software releases the COM port after sending the above sequence: [FONT="Courier New"][SIZE="1"][B] 015813: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_PURGE: Purge requests Purge mask=TXABORT: Read requests, RXABORT: Receive buffer 015814: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_PURGE: Purge requests 015815: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask WaitMask=None 015817: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask 015818: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_PURGE: Purge requests Purge mask=TXCLEAR: Write requests, RXCLEAR: Write buffer 015819: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0 IOCTL_SERIAL_PURGE: Purge requests 015820: Close Request (DOWN), 30.12.2007 17:01:29.437 +0.0 Buffer size: 0x0 bytes 015821: Close Request (UP), 30.12.2007 17:01:29.546 +0.109 Buffer size: 0x0 bytes Status: 0x00000000 [/B][/SIZE][/FONT] You probably couldn't find any, as this was described in the german section by this dero (see above). Aren't you reading the german posts??? :D (Kidding!) Anyway, the driver still doesn't react on permanently pressed buttons. What i wrote in that PDF file was insufficent I think, because I thought each key stroke results in two bytes. Somehow, this remote itself is a little bit crappy, because using it over the MHC software, it produces duplicated key strokes. Seem as if the buttons on the remote itself are rather cheap... Anyway - as far as I watched it und that is congruent with what I found, the remote is supposed to work like this: [FONT="Courier New"][B][SIZE="2"]1D -> DOWN was pressed once 1D 7E 7E 7E 7E 7E 7E 7E -> DOWN was hold and should result in 8 DOWNs (7 repeats) [/SIZE][/B][/FONT] But it could also be like this: [FONT="Courier New"][SIZE="2"][B]1D 7E -> DOWN was pressed once 1D 7E 7E 7E 7E 7E 7E 7E -> DOWN was hold and should result in 7 DOWNs (6 repeats)[/B][/SIZE][/FONT] The latter version seems to be rather illogical. I dunno how you treated the information so far. The result is, that no matter how long a hold a remote button pressed, I get exactly one key stroke. That is, if I need 4 DOWNs I have to hit the Down button 4 times. Anyway - your driver treats the remote signals better than the HMC software as you obviously filter out some of these unwanted duplications produced by this (rather crappy) remote... Maybe a good solution would be to remeber the last valid remote code and ignore 2 or 3 directly following 0x7E. Then if there are additional 0x7E send the last valid remote code instead. That should result in a behaviour like having a short gap between one button stroke and repeated button strokes... Just a proposal. The problem would be to define what are valid remote codes - maybe thos, defined in the XML file... You are very welcome - as I stated before, I am not complaining but just trying to support your work as much as I can! And I like the new version - especially the fact, that one can disable the remote. This MPlay remote really is a pain in the a****. The remote sensor wouldn't accept most of the remote codes sent ba a generic and programmable remote that controls all my other equipment wothout any problems. Even worse, some of the remote codes of the MPlay remote interfere woth my other devices. Terrifying! :mad: Now with your driver I have the chance to ignore this MHC stuff and the MPlay remote and maybe succeed with using an old Terratec Cynergy USB IR receiver. Maybe that one is able to talk to my generic remote... Works brilliantly so far! :thx: There still is that german umlaut issue. This definately is no problem with the VFD, as it cn display them perfectly (see attached picture). This is, what MHC sends to the display: [FONT="Courier New"][SIZE="2"][B]A1 00 A7 20 20 20 20 20 41 75 74 6F 20 55 73 65 ¡.§ Auto Use 72 20 20 20 20 20 20 00 r . A2 00 A7 20 20 20 20 20 49 6E 64 69 63 61 74 6F ¢.§ Indicato 72 20 20 20 20 20 20 00 r . A1 00 A7 D6 20 F6 20 DC 20 FC 20 C4 20 E4 20 DF ¡.§Ö ö Ü ü Ä ä ß 20 20 20 20 20 20 20 00 . A2 00 A7 20 20 20 20 20 20 20 20 20 20 20 20 20 ¢.§ 20 20 20 20 20 20 20 00[/B][/SIZE][/FONT] . Now as you can see in screenshot of MP with german language defined for the skin, MP displays the umlauts perfectly, but then sends these question marks to the VFD. Here is a log of what your driver writes to the COM port: [FONT="Courier New"][SIZE="2"][B]00 A7 .§ 4D 65 69 6E 65 20 46 69 6C 6D 65 20 20 20 20 20 Meine Filme 20 20 20 20 00 . 00 . A2 ¢ 00 A7 .§ 3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 20 20 ? ? ? ? ? ? ? 20 20 20 20 [/B][/SIZE][/FONT] Could that maybe be an issue with windows code pages, unicode or whatever transformation within MP? Once again: I really appreciate your work and please don't take my rather long comments as complaints or nagging or whatever. I am really trying to provide you with as much information as I can as I know that this blind coding you are doing at the moment is rather annoying. Greetings, Axel PS: Just to give you more information - [URL="http://www.vlsys.co.kr/English/oem_mr300.php"]this here[/URL] is the device we are talking about :) [/QUOTE]

Verification