Zalman HD135 VFD (VlSys Mplay)

[Herr R aus B]

Originally Posted by cybrmage

I also found the problem with the serial receive routine... and have rewritten it again...

Which was? I am always also interested in causes

Originally Posted by cybrmage

Please install the new driver, run Mediaportal and then:

1) press and release the buttons 1,2,3,4,5 and 6 on the remote (wait 1 to 2 seconds between each button press)
2) Press and release the button 9 on the remote (then wait 1 to 2 seconds)
3) Press and hold the button 9 on the remote... hold the button for at least 30 second.

The shut down MediaPortal and post the logs... thanks...

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

[cybrmage]

Originally Posted by Herr R aus B

On what speed will the fans run when between OFF and 100% treshold?

I simple take the temperature difference between 100% and OFF and divide by 6 (there are 6 "step" between OFF and 100%)... then, every time the temperature goes up by that amount, the fan speed is increased by one step.

IE:
OFF = 35 degrees, 100% = 59 degrees
step = ( 59 - 35 )/6 = 4 degrees.
When the temperature is below 35 degrees, the fan is off.
When the temperature is below 39 degrees, the fan is at 40%.
When the temperature is below 43 degrees, the fan is at 50%.
When the temperature is below 47 degrees, the fan is at 60%.
When the temperature is below 51 degrees, the fan is at 70%.
When the temperature is below 55 degrees, the fan is at 80%.
When the temperature is below 59 degrees, the fan is at 90%.
When the temperature is above 59 degrees, the fan is at 100%.

This should give the effect of increasing the fan speed as the temperature goes up (the system is more heavily loaded)... hopefully reducing the temperature and allowing the fans to reduce their speed.
If you tweak the values, you should be able to get it to the point that the fans remain off (or at low speed) during normal operation.

Originally Posted by Herr R aus B

why did I do all this stuff, when you already knew it - and where did you knew it from?

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.

Originally Posted by Herr R aus B

anyway, there is this logo definition now

What logo?

Originally Posted by Herr R aus B

you seem to be wrong about the order in which the custom character definitions are transferred to the VFD.

I could be wrong... but I don't think so... Please explain why you think I'm wrong.

Originally Posted by Herr R aus B

For some resaon that didn't work.

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

Originally Posted by Herr R aus B

Finally I realized, that clicking the CANCEL button in the remote mapping dialogue wouldn't close the dialogue...

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.

Originally Posted by Herr R aus B

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

Originally Posted by Herr R aus B

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

Originally Posted by Herr R aus B

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

[Herr R aus B]

Originally Posted by 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.

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

[cybrmage]

Originally Posted by Herr R aus B

I think you didn't see this article

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

Originally Posted by Herr R aus B

the custom character definitions are being transferred to the VFD in a rather strange order

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

Originally Posted by Herr R aus B

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

Originally Posted by Herr R aus B

Btw - of course I am not using google translation to write down all this here Or is my english that bad? Darn...

No... your english is very good.... I just couldn't resist the retort!! 8-}



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

[Herr R aus B]

Originally Posted by cybrmage

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

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.

Originally Posted by cybrmage

Because the 0x00 is used as a termination, it can't be used as a character...

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.

Originally Posted by cybrmage

At least we both managed to determine the character encoding correctly 8-}

That's the point!

Originally Posted by cybrmage

(unless you are planning on moving to a reasonable timezone 8-} )

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?

Originally Posted by cybrmage

No... your english is very good.... I just couldn't resist the retort!! 8-}

Originally Posted by cybrmage

Here is another test version...

[...]

(why are we geting 0x3F all of a sudden???)

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

Originally Posted by cybrmage

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 am all excited about the new driver

Originally Posted by cybrmage

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

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

[Herr R aus B]

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

• V.010108c.start stop MP.complete traffic.txt (COM port log)
• V.010108c.start stop MP.log (MP log)

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

• 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)

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

• 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

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:

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

[cybrmage]

Originally Posted by Herr R aus B

Honestly I'd love to move to canada

Canada is a nice place to live... Escpecially if it's the only place you remember living... 8-}

Originally Posted by Herr R aus B

canada and alaska amaze me.

Alaska is too cold... Then again, so is Canada... but you seem to be well travelled in the Scandanavian countries, so you are probably used to it 8-} (That's assuming, of course, that anyone can get used to -50C temperatures)

Originally Posted by Herr R aus B

.... finding a reasonable job ....

If you're in the oil or construction industry or retailing, chances are very good..., The IT industry, OK, others... not so much... At least that is the case out west... I haven't lived in the east for 10 years...

Originally Posted by Herr R aus B

You seem to be from the east coast - where?

Born in England, raised in Southern Ontario (about 40 minutes South West of Toronto - the armpit of Ontario), currently living in South Central Alberta...



Oh... Sorry.... got a little off topic... 8-} (Nice little change of pace)

Originally Posted by Herr R aus B

Actually (and unfortunately) it's getting worse.

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

Originally Posted by Herr R aus B

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

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-} )

Originally Posted by Herr R aus B

you still switch off the VFD as in nothing is displayed and the red indicator LED is off.

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

Originally Posted by Herr R aus B

At least this should help you maybe finding out the proper sequence.

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!!!)

Originally Posted by Herr R aus B

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

[cml11]

Originally Posted by Herr R aus B

what about simply uninjstalling it?

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.

[Herr R aus B]

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)

So your assumption was right and as far as I understand it these bytes are

• 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

I wonder how to compute the year tho... Byte #8 is always the same und byte #4 is different for 2007 and 2008. But however there should be a difference of 1 - and there isn't. The difference between the valuesfor byte #4 is 3. Maybe there is no year transmitted as the display, when in standby, looks like shown in this attachment from yesterday...

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?

[cybrmage]

Originally Posted by cml11

It will close it on start if detects it and run it again on plugin exit.

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.

Originally Posted by Herr R aus B

Maybe there is no year

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.

Originally Posted by Herr R aus B

Any good hint for a FREE com port monitor that runs under XP64?

I'll see what I can come up with.... (what are (were) you using?? BusHound??

Regards,
CybrMage