home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Herr R aus B" data-source="post: 219905" data-attributes="member: 62807"><p>Actually (and unfortunately) it's getting worse. So this time I produced quite a bunch of logs for you. That's why it took a little bit longer - but as I can see, you must be asleep now - no wonder, it should be 5am over there ;-)</p><p></p><p>Here is what I could watch:</p><p></p><p>There definately are no 0x3F. I sniffed the traffic between the version 010108b with that 1 2 3 4 5 6 7 8 9 & hold 9 test. That's the same what I did then. And the COM port log doesn't show any 0x3F. Unfortunately i didn't save the MP log this time, but I think, there would be no difference. See the files <strong><em>V.010108b.*.txt</em></strong>.</p><p></p><p>I repeated all the tests just having MHC running instead of MP. See the files <strong><em>MHC.1 2 3 4 5 6 7 8 9 hold test.*.txt</em></strong>.</p><p></p><p>Then I installed the new version 010108c and the first thing I found out is, that this version of the driver obviously doesn't read anything from the COM port. I simply don't get any reading recordings in the COM port logs... See the files</p><ul> <li data-xf-list-type="ul"><strong><em>V.010108c.start stop MP.complete traffic.txt</em></strong> (COM port log)</li> <li data-xf-list-type="ul"><strong><em>V.010108c.start stop MP.log</em></strong> (MP log)</li> </ul><p>The MP log states that you are reading (and ignoring) data, but the COM port log for the same time doesn't show any read requests... Confusing...</p><p></p><p>I then tested the standby thing. As I have no remote with the new driver version I put windows to standby using the MP menu. The result is, that you still switch off the VFD as in nothing is displayed and the red indicator LED is off. See the log files </p><ul> <li data-xf-list-type="ul"><strong><em>V.010108c.sending to standby and waking up manually.txt</em></strong> (COM port log)</li> <li data-xf-list-type="ul"><strong><em>V.010108c.sending to standby and waking up manually.log</em></strong> (MP log)</li> </ul><p>Doing the same running MHC instead of your driver shows a dimmed standby message in the display and leaves the indicator LED lit. So, what I did then is again logging all kinda things having MHC started instead of your driver as logged in the following files</p><ul> <li data-xf-list-type="ul"><strong><em>MHC.putting windows to standby using MP and waking it up again with remote.txt</em></strong></li> <li data-xf-list-type="ul"><strong><em>MHC.putting windows to standby using remote and waking it up again with remote.txt</em></strong></li> <li data-xf-list-type="ul"><strong><em>MHC.putting windows to standby using windows shutdown menu and waking it up again with remote.txt</em></strong></li> </ul><p>Using MPlay's remote control to snet windows to standby causes some problems as the VFD is not reinitialized after wake up. But that seems to happen here and then is still not reproducable for me. The point is, that the wake up pressing the PwrOff button on the remote always works. At least this should help you maybe finding out the proper sequence. I found the following sequence interesting, which is sent by MHC immediately after I sent windows to standby using the windows shut down menu:</p><p></p><p><span style="font-family: 'Courier New'"><strong>00 00 00 ...</strong></span></p><p><span style="font-family: 'Courier New'"><strong>AE AE ®®</strong></span></p><p></p><p>Maybe "you are about being shut down"? I wonder whether these 0x00 0x000x00 are some general reset. Could also be the 0xAE 0xAE...</p><p></p><p><strong><span style="font-family: 'Courier New'">A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43 ¡.§M.Play Home C</span></strong></p><p><strong><span style="font-family: 'Courier New'">65 6E 74 65 72 20 20 00 enter .</span></strong></p><p><strong><span style="font-family: 'Courier New'">A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64 ¢.§ Stand</span></strong></p><p><strong><span style="font-family: 'Courier New'">62 79 20 4D 6F 64 65 00 by Mode.</span></strong></p><p></p><p>Setting the display and this also can be watched on the display - of course...</p><p></p><p><span style="font-family: 'Courier New'"><strong>AC 47 47 ¬GG</strong></span></p><p></p><p>Setting the fans to 40%...</p><p></p><p><strong><span style="font-family: 'Courier New'">A4 7E ¤~</span></strong></p><p><strong><span style="font-family: 'Courier New'">A4 76 ¤v</span></strong></p><p><strong><span style="font-family: 'Courier New'">02 .</span></strong></p><p><strong><span style="font-family: 'Courier New'">0D .</span></strong></p><p><strong><span style="font-family: 'Courier New'">02 .</span></strong></p><p><strong><span style="font-family: 'Courier New'">1F .</span></strong></p><p><strong><span style="font-family: 'Courier New'">04 .</span></strong></p><p><strong><span style="font-family: 'Courier New'">01 .</span></strong></p><p><strong><span style="font-family: 'Courier New'">0A .</span></strong></p><p><strong><span style="font-family: 'Courier New'">0B .</span></strong></p><p><strong><span style="font-family: 'Courier New'">AE ®</span></strong></p><p></p><p>Hm.... ? 0xAE again.... And what is this A4? In <a href="https://forum.team-mediaportal.com/showpost.php?p=219437&postcount=71" target="_blank">this article</a> you assumed, the following eight bytes after 0xA4 0x76 could be time setting information. They represent in decimal: 02 <span style="color: Blue">13 02 </span>31 04 01 <span style="color: Blue">10 </span>11. Well according to the COM port logs it all happened at 13:02:10 and these numbers are there (marked blue), but not following each other directly... and where is the date then? there is another 02, which would fit the day and there is also a 01, which could be january. But where then is 2008 which would be 0x07D8. Maybe if the 0x1F (31) is an offset to a base year and the 0x04 could be the day of week (should be wednesday then), but then the week would start either on saturday (0x00) oder sunday (0x01), where the latter even mitght be valid - and who knows what koreans think about what day is the first day in the week - in Germany its monday, in Java (language) it's sunday... But then, what about the 0x0B before the 0xAE? How did you get the idea, that this could be time/date information? I am confused <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" /></p><p></p><p><strong><span style="font-family: 'Courier New'">A5 3B ¥;</span></strong></p><p></p><p>Dimming the display... What follows then is closing the COM port and there were no read requests during this sequence.</p><p></p><p>And here are the log files - I wish I could be more helpful...</p></blockquote><p></p>
[QUOTE="Herr R aus B, post: 219905, member: 62807"] Actually (and unfortunately) it's getting worse. So this time I produced quite a bunch of logs for you. That's why it took a little bit longer - but as I can see, you must be asleep now - no wonder, it should be 5am over there ;-) Here is what I could watch: There definately are no 0x3F. I sniffed the traffic between the version 010108b with that 1 2 3 4 5 6 7 8 9 & hold 9 test. That's the same what I did then. And the COM port log doesn't show any 0x3F. Unfortunately i didn't save the MP log this time, but I think, there would be no difference. See the files [B][I]V.010108b.*.txt[/I][/B]. I repeated all the tests just having MHC running instead of MP. See the files [B][I]MHC.1 2 3 4 5 6 7 8 9 hold test.*.txt[/I][/B]. Then I installed the new version 010108c and the first thing I found out is, that this version of the driver obviously doesn't read anything from the COM port. I simply don't get any reading recordings in the COM port logs... See the files [LIST] [*][B][I]V.010108c.start stop MP.complete traffic.txt[/I][/B] (COM port log) [*][B][I]V.010108c.start stop MP.log[/I][/B] (MP log) [/LIST] The MP log states that you are reading (and ignoring) data, but the COM port log for the same time doesn't show any read requests... Confusing... I then tested the standby thing. As I have no remote with the new driver version I put windows to standby using the MP menu. The result is, that you still switch off the VFD as in nothing is displayed and the red indicator LED is off. See the log files [LIST] [*][B][I]V.010108c.sending to standby and waking up manually.txt[/I][/B] (COM port log) [*][B][I]V.010108c.sending to standby and waking up manually.log[/I][/B] (MP log) [/LIST] Doing the same running MHC instead of your driver shows a dimmed standby message in the display and leaves the indicator LED lit. So, what I did then is again logging all kinda things having MHC started instead of your driver as logged in the following files [LIST] [*][B][I]MHC.putting windows to standby using MP and waking it up again with remote.txt[/I][/B] [*][B][I]MHC.putting windows to standby using remote and waking it up again with remote.txt[/I][/B] [*][B][I]MHC.putting windows to standby using windows shutdown menu and waking it up again with remote.txt[/I][/B] [/LIST] Using MPlay's remote control to snet windows to standby causes some problems as the VFD is not reinitialized after wake up. But that seems to happen here and then is still not reproducable for me. The point is, that the wake up pressing the PwrOff button on the remote always works. At least this should help you maybe finding out the proper sequence. I found the following sequence interesting, which is sent by MHC immediately after I sent windows to standby using the windows shut down menu: [FONT="Courier New"][B]00 00 00 ... AE AE ®®[/B][/FONT] Maybe "you are about being shut down"? I wonder whether these 0x00 0x000x00 are some general reset. Could also be the 0xAE 0xAE... [B][FONT="Courier New"]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.[/FONT][/B] Setting the display and this also can be watched on the display - of course... [FONT="Courier New"][B]AC 47 47 ¬GG[/B][/FONT] Setting the fans to 40%... [B][FONT="Courier New"]A4 7E ¤~ A4 76 ¤v 02 . 0D . 02 . 1F . 04 . 01 . 0A . 0B . AE ®[/FONT][/B] Hm.... ? 0xAE again.... And what is this A4? In [URL="https://forum.team-mediaportal.com/showpost.php?p=219437&postcount=71"]this article[/URL] you assumed, the following eight bytes after 0xA4 0x76 could be time setting information. They represent in decimal: 02 [COLOR="Blue"]13 02 [/COLOR]31 04 01 [COLOR="Blue"]10 [/COLOR]11. Well according to the COM port logs it all happened at 13:02:10 and these numbers are there (marked blue), but not following each other directly... and where is the date then? there is another 02, which would fit the day and there is also a 01, which could be january. But where then is 2008 which would be 0x07D8. Maybe if the 0x1F (31) is an offset to a base year and the 0x04 could be the day of week (should be wednesday then), but then the week would start either on saturday (0x00) oder sunday (0x01), where the latter even mitght be valid - and who knows what koreans think about what day is the first day in the week - in Germany its monday, in Java (language) it's sunday... But then, what about the 0x0B before the 0xAE? How did you get the idea, that this could be time/date information? I am confused :D [B][FONT="Courier New"]A5 3B ¥;[/FONT][/B] Dimming the display... What follows then is closing the COM port and there were no read requests during this sequence. And here are the log files - I wish I could be more helpful... [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Input / Output interfaces
Mini Display
Zalman HD135 VFD (VlSys Mplay)
Contact us
RSS
Top
Bottom