Germany
Which was? I am always also interested in causes
You're welcome! Hop it fits your needs! The remote was still being ignored - but as you said this could happen, I'm gonna downgrade again
Zalman HD135 VFD (VlSys Mplay) (1 Viewer)
- Thread starter -Manfred-
- Start date
You're welcome! Hop it fits your needs! The remote was still being ignored - but as you said this could happen, I'm gonna downgrade again
What stuff??? The character definitions?? I posted that I had figured it out.... One of your logs showed MHC displaying the clock.... once you posted a picture showing the clock, I was able to deduce that the 64 bytes of data in the 0xAD command was custom character data.... I then manually decoded the data into character maps, and correlated that into the data being sent by MHC for the clock display... and managed to get results that match the picture.
anyway, there is this logo definition now
What logo?
I could be wrong... but I don't think so... Please explain why you think I'm wrong.
hmm... should work... but, things don't always work the way you (me in this case) want them to.
At least I got you pointed in the right direction... 8-}
Yes... I noticed this too... but the remote mapping dialog in the the remote control plugin (external to the ExternalDisplay plugin) and I haven't had a chance to look into that problem yet.
Anyway... Let's see what comes around from you next
Could you provide the mediaportal.log that I requested... I'm waiting on more data... Thanks.
Regards,
CybrMage
Which was? I am always also interested in causes
It was because I had assumed (from indications in the previous logs) that the data would come in bursts of 1, 2 or 3 bytes... and coded specific routines to take care the these cases on log the data... but I forgot to clear the data buffer after handling a 3 byte burst... so the next time the WhenDataReceived() routine was called, there was 4 bytes of data... then 6 bytes, etc... and the data handling routines were never executed with more than 3 bytes in the buffer... (Yes, I know... STUPID mistake... I'm only human...)
You're welcome! Hop it fits your needs! The remote was still being ignored - but as you said this could happen, I'm gonna downgrade again
I'm looking at the log now... Thanks again... hopefully, I'll get this received data processing routine figured out this time.
Regards,
CybrMage
What stuff??? The character definitions?? I posted that I had figured it out.... One of your logs showed MHC displaying the clock.... once you posted a picture showing the clock, I was able to deduce that the 64 bytes of data in the 0xAD command was custom character data.... I then manually decoded the data into character maps, and correlated that into the data being sent by MHC for the clock display... and managed to get results that match the picture.
anyway, there is this logo definition now
What logo?
I could be wrong... but I don't think so... Please explain why you think I'm wrong.
I think you didn't see this article I just posted approximately one hour before you posted your explaination about the custom characters . After 3 hours analyzing and documenting I ended up defining a custom character set to display the MP logo... And I found out, that the custom character definitions are being transferred to the VFD in a rather strange order which is 8 1 2 3 4 5 6 7 (or 7 0 1 2 3 4 5 6 from the data scientist's viewpoint). Addressing them later on as 0x01 through 0x08 gives the proper results though... If you like have a look at the logs in the article...
Somehow our articles are that long, that we run out of synch
Btw - of course I am not using google translation to write down all this here
Or is my english that bad? Darn... You know.... I completely missed it... Neither of your posts was there when I started writing the info... When I finally posted it, I saw your second post ( #77) and didn't bother scrolling up to notic #76...
My appologies!!!
Yes... it is strange... but the reason is simple... 0x00 is used as an End-Of-Line character... (could it be that the extra 0x00's that are being sent to the display are actually a bug in the MHC data collection routine... It determines what commands it wants to send to the display and adds a 0x00 terminator?? no data = terminator only???).
Because the 0x00 is used as a termination, it can't be used as a character...
I didn't have enough data from your logs to determine for sure that the 0x00 was the termination or that 0x08 was used in a display string... so I arbitrarily picked 0x00... bad choice 8-{... you are absolutely correct!
At least we both managed to determine the character encoding correctly 8-}
Somehow our articles are that long, that we run out of synch
That's the way things go sometimes.... The timezone difference (8 hours) doesn't help any either... Something we'll have to deal with (unless you are planning on moving to a reasonable timezone 8-} )
Besides... I'd rather get a little out of sync, and get good information (and confirmation of said information) than be in sync with very little info or feedback...
No... your english is very good.... I just couldn't resist the retort!! 8-}Btw - of course I am not using google translation to write down all this here
Here is another test version...
I rewrote the serial data handling rotine (again)... This time I added filtering of invalid data (why are we geting 0x3F all of a sudden???) and two rudimentary state machines ( the first to make sure we don't send a request for temperature data before we receive the data from the previous request and the second to try and properly detect a remote button that is being held down).
I also changed the initialization routine to send the same data (all those 0xAA's) as the MHC program....
And, I also discovered that I was not correctly closing the serial port on shutdown... hopefully this fix will let the display restart the machine from shutdown/hibernate/sleep (fingers crossed)!! 8-}
I also changed the shutdown routine to set the fan speed for both fans to 40%... Better to have a little noise from the fan than the expense of replacing a machine that has overheated.!!!..
Please make sure you have the options "Use fan control" turned on, and at least one of the fans set to "automatic" when you test this one (The temperature requests are only sent to the display if automatic fan control is needed).
Regards,
CybrMage
It's OK - I was just so happy that I finally did something useful for this µ-project ;-) Obviously we were writing at the same time, and as a matter of fact all this documenting takes a remarkable amount of time. But: We seem to set up a complete and understandable documentation.
Right - If one doesn't know the buffer length. But my experience with communicating with such devices (I once had a long fight with a power switch card) is, that they work with fixed buffer lengths.
That's the point!
So? What's a reasonable timezone? I like my +0100
+1 is much more than -7! I won! Yeeeeehah! Honestly I'd love to move to canada, as I am somewhat northbound so to say. I speak danish, travelled all of scandinavia (finnland included) - the only country missing is greenland. I didn't want to spend some 300 € for a eight hour heli trip to greenland when I was in island. And canada and alaska amaze me. Canada would be better though, as I lived and worked in Atlanta and really wouldn't cope with these US folks generally... I mean I also was up in Seattle, which is different, very different, but in the end, the states wouldn't make me happy. But maybe I once make it to canada again. As I told you - I had a great time in tToronto and Ontario - and that's just such a small spot of your country. But the other thing is, that I am 43 already and finding a reasonable job with 43 might also be a problem in Canada - in germany it definately is and we are not talking the states. You seem to be from the east coast - where?
I saw them myself peeking in the log and thought it was still this misinterpretation or wrong display of hex values - I'm gonna sniff th communication between your driver and the COM port before updating...
I am all excited about the new driver
Right in general - in my case (either my htpc case or the fact that I am using your driver - arghl...) there are working additional fans controlled by the motherboard. So it would be even more comfortable to be able to set an additional standby speed.
Unfortunately testing has to wait a little bit, because at the moment again I have some recordings running - yes, I am still using this software
And if wouldn't freeze my screen from time to time, I would even more like it... But I think the screen freezing problem while returning from any fullscreen mode seems to be a known problem...I'll keep you updated and informed within the next 30 - 45 minutes...
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 V.010108b.*.txt.
I repeated all the tests just having MHC running instead of MP. See the files MHC.1 2 3 4 5 6 7 8 9 hold test.*.txt.
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
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
00 00 00 ...
AE AE ®®
Maybe "you are about being shut down"? I wonder whether these 0x00 0x000x00 are some general reset. Could also be the 0xAE 0xAE...
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.
Setting the display and this also can be watched on the display - of course...
AC 47 47 ¬GG
Setting the fans to 40%...
A4 7E ¤~
A4 76 ¤v
02 .
0D .
02 .
1F .
04 .
01 .
0A .
0B .
AE ®
Hm.... ? 0xAE again.... And what is this A4? In this article you assumed, the following eight bytes after 0xA4 0x76 could be time setting information. They represent in decimal: 02 13 02 31 04 01 10 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
A5 3B ¥;
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...
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 V.010108b.*.txt.
I repeated all the tests just having MHC running instead of MP. See the files MHC.1 2 3 4 5 6 7 8 9 hold test.*.txt.
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
- V.010108c.start stop MP.complete traffic.txt (COM port log)
- V.010108c.start stop MP.log (MP log)
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
- V.010108c.sending to standby and waking up manually.txt (COM port log)
- V.010108c.sending to standby and waking up manually.log (MP log)
- MHC.putting windows to standby using MP and waking it up again with remote.txt
- MHC.putting windows to standby using remote and waking it up again with remote.txt
- MHC.putting windows to standby using windows shutdown menu and waking it up again with remote.txt
00 00 00 ...
AE AE ®®
Maybe "you are about being shut down"? I wonder whether these 0x00 0x000x00 are some general reset. Could also be the 0xAE 0xAE...
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.
Setting the display and this also can be watched on the display - of course...
AC 47 47 ¬GG
Setting the fans to 40%...
A4 7E ¤~
A4 76 ¤v
02 .
0D .
02 .
1F .
04 .
01 .
0A .
0B .
AE ®
Hm.... ? 0xAE again.... And what is this A4? In this article you assumed, the following eight bytes after 0xA4 0x76 could be time setting information. They represent in decimal: 02 13 02 31 04 01 10 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
A5 3B ¥;
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...
Wel... It seems that, for me, the new year is getting off to a bad start...
Although I did learn a few things...
1) NEVER do coding on new years day!!!
2) NEVER do coding after a "party"!!
3) When coding a state machine... TURN IT ON!!! 8-}
Opps... Sorry... mea culpa...
What I am trying to do is "marshal" the information that the display sends to the driver... From the last set of MHC logs, it appears the the display sends an identity string to MHC when initialized (10 bytes "MZ4MZ4MZ4M"... and running these bytes through the data routines would generate spurious remote button presses.. so the receive routines do not start reading data until a flag is set to indicate that it should start processing the data... The data is left in the receive buffer... The Initialize() routine opens the port and sends the initialization commands, the flushes the receive buffer, the set the processing flag....
I, of course, forgot to set the processing flag!!! (BAD PROGRAMMER!!! no caffine ration for you! 8-} )
Yep... I need to add a number 4 to the above list... 4) learn to count...
In the changes to the Cleanup() routine, I miscounted the numbers of bytes sent to the display, causing MediaPortal to crash... So the required shutdown commands are never sent to the display... 8-{
I hope so... I'm looking over the logs now... With the number of logs you provided, I should be done by July... 8-} (I'm kidding!!! the amount of logging you are doing is GREAT!!!)
And what is this A4?
.
.
.
How did you get the idea, that this could be time/date information? I am confused
0XA4, 0x76
0x02 Minutes
0x0D Hours
0x02 Day
0x1F Days In Month
0x04 Day Of Week ( 1 - 7: 1 = Sunday)
0x01 Month
0x0A Seconds
0x0B Unknown (possibly the year offset)
This information was provided by -Manfred- in one of his source code edits.
Here is a quick fix for the last driver... complete logging is not required (yet 8-}, just the mediaportal.log for now...
Feedback on it's functionality is eagerly (and fearfully) awaited 8-}
Again... My appologies for all the work I caused you... hopefully, some good will come of it! 8-}
Regards,
CybrMage
[UPDATE] Apparently, (the "COMPLETE" log you posted seems to verify it), the {0xAA, 0xAA } command is an "Identify" command... The display responds with "MZ4".
During initialization, MHC open the port, sends
0xA4, 0x7D
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
0xAA, 0xAA
and closes the port... and the opens the port and starts communication with the display... so the routine MUST be part of the MHC device detection routine.... which make the 0xA$, 0x7D a "Wakeup" or "Reset" command... (I suspect it's a soft reset... MHC sends 10 "Identify" commands, but only receives 8 responses...)
Ingenious idea, but I'm affraid that can't solve my problem
I want to control other SW by my remote too, not only MP. So I need to have run some control SW in moment when I leave MP. My idea was, that this remote plugin will have option where I can specify executable file which it will search in memory when plugin started. It will close it on start if detects it and run it again on plugin exit.
Time / Date information?
Now I logged some sending to standby while fiddling with time and date settings. The result is, that the sequence sent by MHC to the VFD is
00 00 00
AE AE
A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43
65 6E 74 65 72 20 20 00
A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64
62 79 20 4D 6F 64 65 00
AC 47 47
A4 7E
A4 76
{8 bytes}
AE
A5 3B
Here are the 8 bytes for different time and date settings (decimal values in brackets):
One also has to find out, whether day of month starts on sunday being 0x01 or on saturday being 0x02. Unfortunately at the moment I can't do any COM port analyzing as this port monitor was a 14 days trial and due to setting the year back to 2007 and then again to 2008 the license has expired after 4 days
Any good hint for a FREE com port monitor that runs under XP64?
Now I logged some sending to standby while fiddling with time and date settings. The result is, that the sequence sent by MHC to the VFD is
00 00 00
AE AE
A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43
65 6E 74 65 72 20 20 00
A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64
62 79 20 4D 6F 64 65 00
AC 47 47
A4 7E
A4 76
{8 bytes}
AE
A5 3B
Here are the 8 bytes for different time and date settings (decimal values in brackets):
- Fri 02.02.07 15:50:20 - 32 0F 02 1C 06 02 14 0B (50 15 02 28 06 02 20 11)
- Wed 02.01.08 15:41:23 - 29 0F 02 1F 04 01 17 0B (41 15 02 31 04 01 23 11)
- Wed 02.01.08 16:39:52 - 27 10 02 1F 04 01 34 0B (39 16 02 31 04 01 52 11)
- Byte #1: Minutes
- Byte #2: Hours
- Byte #3: Day
- Byte #4: unknown
- Byte #5: Day of week
- Byte #6: Month
- Byte #7: Seconds
- Byte #8: unknown
One also has to find out, whether day of month starts on sunday being 0x01 or on saturday being 0x02. Unfortunately at the moment I can't do any COM port analyzing as this port monitor was a 14 days trial and due to setting the year back to 2007 and then again to 2008 the license has expired after 4 days
Any good hint for a FREE com port monitor that runs under XP64?
If you had read back through the thread, you would see that this has already been discussed...
At the moment, we are trying to get the display and the remote control fully functional.... That is the priority... other embelishments will be considered after the priority work is completed.
I don't think that the year is transmitted...
Byte 4 is the number of days in the month... (28 in february 2007, 29 in February 2008). That would only be significant IF the display does have an on-board calender, hence needs to know the number of days in the month so that it can change the month at the appropriate time.
I'll see what I can come up with.... (what are (were) you using?? BusHound??
Regards,
CybrMage