Zalman HD135 VFD (VlSys Mplay) (2 Viewers)

[Herr R aus B]

Volume knob????????? The device has a volume knob??????? oh, crap!! 8-}

DOn't panic - they are talking a different version of this VFD - there is no knob here

All other 0x7E where randomly ocurring.

Which is really annoying... The logs you provided definately show a 0x7E following each valid button press.... and they are consistently 109ms -125ms behind the keypress.... When the display is sending a 0x7E to indicate a repeat, they are consistently 90ms to 110ms apart...

This is because I did never concentrate on accurate pressing the buttons. Honestly - it seems as if one needs kinda driver's license and at least 10 years practical experience to operate that remote control. I mean, Tschernobyl was nothing compared to this hitec (well - rather lotec) device here So look at this hyper terminal screenshot and believe in the old man: These 0x7Es are irrelevant (7 of 9 would like that! Well - I like 7 of 9...)

Good suggestions... but I think there will be a problem with the 0x7E codes... the mediaportal logs still show that a 0x7e gets send for each button pressed, it's just not being received when it is expected...

You like those 0x7Es... don't you?

I think that the first thing to do will be to change the receive threshold from 1 byte to 2 bytes... that way we can see if there really is a "matched pair" for the button presses without having to do another complete rewrite of some perfectly good code (well... that's my opion of it... and I am entitled to it!! 8-} )

And you like the complicated way If there is the need of reading two bytes, why then did I make it to produce just one singe byte with one single button hit? I tell you, the 0x7E just tells you, that someone is sitting on the button! Well - this is gonna become a fight even worse than between cotholics and protestants... We somehow need our Martin Luther of the 0x7E...

HEy! That is MY rock! Go, lookfor your own rock! (Reminds me of Monty Python - but in Life of Brian it was a bush... And no flat jokes about George Walker now!)

ROFL!!!! Brilliant!!!..... I'll continue programming once I manage to pry myself of the floor!!!!

You are free to stand up whenever you want

Attached is a version with the receive threshold increased to two... Please test and report (with mediaportal.log please)... If it makes no difference, then we'll have another try at rewriting the logic.

Will be done as soo as these recordings are done

Greets

Axel
==============================================

this is called Agile rapid development method?!?

Actually... it's the PVRDA method (Programming Via Remote Data Aquisition)... The more feedback, the faster it goes 8-}

Fortunately you are not proceeding the cyclic ATW method, where ATW stands for "against the wall"... well...
==============================================

[If you can... run Mediaportal... let it sit until mediaportal blanks the screen... then, using the keyboard, have mediaportal resume and shut it down... then grab the log...

How long does it take mediaportal to blank the display?? I don't think I've ever seen Mediaportal blank the display... my machine goes into standby first...

Regards,
CybrMage

PS: Your using PowerScheduler..... It may be that plugin that is causing MediaPortal to blank the screen... I've experienced trouble with the iMONLCDg driver that are related to PowerScheduler.... If that is the case, there may be a workaround... (for after the remote issues are resolved).

I also found out, that, when the screen is blanked, it is not possible to wake it up with the remote. To be more precise: not only gets the screen blanked, it gets switched off - as my LCD TV says "no signal". Sitching it on again cn only be done using mouse or keyboard. And yes, it is Power Scheduler that blanks the screen... But it should send MP to standby. Actually it blanks or switches off the screen as recordings are going on. I have to inspect the entire behaviour more accurately, then will report again...

 

[cybrmage]

DOn't panic - they are talking a different version of this VFD - there is no knob here

Good... I live on the 15th floor... I was beginning to contemplate taking a flying leap 8-} (just kidding!!!)

You like those 0x7Es... don't you?

NO!!! As proof, I direct your attention to the configuration screen of the next version... 8-}

And you like the complicated way

No... I don't like complicated... However, I do want to make sure that it is done correctly...
I don't want to go from missing button presses to generating spurious duplicate button presses.

I think we may have lost (or missed) something in the setup... The Temperature reading command seems to be returning 0x3F consistently now.... maybe the way that the remote buttons are handled by the display is controlled by a command that has been overlooked (or removed)... I'm trying to work my way through the previous logs to see if anything was missed.

You are free to stand up whenever you want

I may have been free to... but I wasn't able to... 8-}

Will be done as soo as these recordings are done

Take your time.... your only missing two or three versions of the driver 8-}

Fortunately you are not proceeding the cyclic ATW method

Although it did seem like we were using that method while trying to get the "wake by remote" functioning!

Actually it blanks or switches off the screen as recordings are going on.

That is (or was) a known problem with PowerScheduler...
I compile the drivers against the 0.2.3 release sourcecode, so that there is maximum compatability... so any fixes that have been done since then to any of the process plugins, do not appear in the driver... If you find that it has been fixed since the MediaPortal 0.2.3 release, let me know and I will update my sources for it.


Regards,
CybrMage

 

[Herr R aus B]

I think we may have lost (or missed) something in the setup... The Temperature reading command seems to be returning 0x3F consistently now.... maybe the way that the remote buttons are handled by the display is controlled by a command that has been overlooked (or removed)... I'm trying to work my way through the previous logs to see if anything was missed.

Well, I dont think so. Especially I don't think, that there is a command that might change the behaviour. I don't think, that device is that intelligent But I am not quite sure. All I can say is, that regarding the remote code handling the 010208d worked better than the 010208e which I just tested. The only small reason to discuss anything was the rather high repeat frequency... Now the repeat behaviour is kinda messed up, that means being in the main menu (the one that scrolls cyclically) the folowing happens:

• 1 short hit on UP/DOWN button = 1 menu item up or down
• UP/DOWN button held = 1 menu item up or down, short break, then 2 menu items up or down at once for each repeat
• 1 short hit on OK button = 1 menu item up or down, then selection of the menu button

Maybe you might wanna give my minimal remote code handling strategy at least a little try? ;D

Actually it blanks or switches off the screen as recordings are going on.

That is (or was) a known problem with PowerScheduler...
I compile the drivers against the 0.2.3 release sourcecode, so that there is maximum compatability... so any fixes that have been done since then to any of the process plugins, do not appear in the driver... If you find that it has been fixed since the MediaPortal 0.2.3 release, let me know and I will update my sources for it.

OK - I am using the 0.2.3.0 with neither updates nor SVNs... I thi nk I found the problm - in my power saving options I told windows to switch of the screen after 20 minutes idle. The funny thing is, that the display is sent to standby then. There must be some event sent to MP by windows then...

 

[Herr R aus B]

break

It's 2am here now - I am gonna send myself to standby now. Hopefully with the proper command sequence so that I will wake up again tomorrow. Will be available a little bit later tomorrow! Good luck so far!

 

[-Manfred-]

For temp handling:

def readTemp(fd):
    # request the current temp
    write(fd, 0)
    write(fd, 0xAF)
    time.sleep(0.000040)

    res = select([fd], [], [])
    if len(res[0]):
	temp1 = -1
	temp2 = -1
	while temp2 == -1:
	    str = os.read(fd, 2)
	    if len(str) == 1:
		if temp1 == -1:
		    temp1 = ord(str[0])
		else:
		    temp2 = ord(str[0])

	    elif len(str) == 2:
		temp1 = ord(str[0])
		temp2 = ord(str[1])

	    else:
		sys.stdout.write("Unexpected data during remp read: ")
		for c in str:
		    sys.stdout.write( "0x%02x " % ord(c) )
		sys.stdout.write("\n")
		break

	if temp2 != -1:
	    if 1: # farenheit
		temp1 = (temp1 - 150) * 9 / 5 + 32
		temp2 = (temp2 - 150) * 9 / 5 + 32
	    else: # celcius
		temp1 = temp1 - 150
		temp2 = temp2 - 150

	    return (temp1, temp2)

    return None

More info here: http://lists.omnipotent.net/pipermail/lcdproc/2007-October/011966.html

and for repeating key here: http://www.nabble.com/New-driver-for-Vlsys-mplay-%28the-one-in-Zalman-Hd135-case%29-td14282379.html#a14468936

 

[cybrmage]

-Manfred-: I appreciate the pointers.... But, I have seen them before, and they are not helpful in this situation.... (they are Linux drivers, and use a totally different IO model)...


Here is a new version....

I added and option to disable remote button repeat mode completely (I told you I do not like the 0x7E!! 8-} ), and I added an option to adjust the repeat key delay.

The delay setting basically ignores a repeat request for the specified periof of time after the last button press.

Regards,
CybrMage

 

[cybrmage]

Another new version...

I've added an option to manage the M.Play Home Center software.

When enabled (in configuration), the driver will stop the MHC program when the display is initialized (if it is running), and when the display is shut down MHC will be restarted (if it was running when the display was initialized).

Regards,
CybrMage

 

[Herr R aus B]

And here are the results from the German jury... Hm... You might not understand that joke, coz it's european... Anyway - I tested like hell and had a big grin in my face. Now it's time to also add some tool tips to the config dialogue containing bad remote bashing words, especially describing your very personal relation to 0x7E occurences

I first tested just repeating on different repeat frequencies using just the UP button. Here is what I watched:

1. Default repeat frequency: Not possible to determine whether each repeat scrolls two items or one, but most of the times after releasing the remote button, the menu scrolls one item back
2. Repeat frequency 100ms: Obviously still that behaviour of scrolling one item at the first repeat and then consequently two items each following repeat. Partly jumping one item back after releasing the button
3. Repeat frequency 200ms: same as above
4. Repeat frequency 300ms: behaves OK
5. Repeat frequency 400ms: behaves OK
6. Repeat frequency 500ms: behaves OK

Afterwards I did some excessive UP, DOWN, LEFT, RIGHT, OK all over the menus. Got one frozen screen that got alive after some time again. Don't think that's related to your driver tho...

Then I also tested fan control a little bit. Unfortunately fan control seems to be dead - is that deliberately disabled at this time? I tested two scenarios:

1. Fan 1 set to manual control at 100%, fan 2 set to automatic control according to the default values, started and immediately stopped MP
2. Fan 2 set to manual control at 100%, fan 1 set to automatic control according to the default values, started and immediately stopped MP

The result was absolute silence as in nothing happened.

My interpretation especially of the remote behaviour would be that you should return to reading single byte bursts (well, bursts...) and maybe you are somehow taking over yourself regarding speed - especially using a repeat frequency below 300ms. Just a guess. As this coding just looking at logs must be a real pain I have in mind that I try to set up a little program here to maybe code a base algorithm for all this reading and writing. I dunno, how the serial port arbitration is done in MP. I would do it using a number of threads:

1. thread to read single bytes and put the bytes read in two different queues: One queue for remote codes, one for non remote codes
2. thread to arbitrate the remote code queue (including our beloved 0x7E)
3. thread to arbitrate the rest of the receivings
4. probably additional thread to handle outbound bytes

Whether or not the serial port should be secured using a semaphore or whatever synch mechanism I cant decide. I assume it should be able to process in full duplex mode. Furthermore I would read bytewise and then decide for each byte what to do - using kinda grammar tree or whatever one should call it to make decisions and control the associated state machine.

I think the biggest problem is that state machine, as you are coding blindly. I remember that I once set up a state machine within a CTI client simulating a telephone with all its function and getting asynch signals from a CTI server. That state machine had about 15 flags controlled by some 25 boolean equations - it was a nightmare So coding this all without being able to immediately see the results of your algorithms must be a nightmare, too...

If I make it to do some coding here, it surely would be either in Java or more likely in C++ as I don't have any clue about C# that you obviously are using. Maybe Java would be better, as it seems to be rather similar to C# from what I saw. But I dunno whether I'll be able to address the COM port using Java on a XP64 machine... Never tried that. Would that be of any help for you, or would that rather insult your coder's honour? ;-) Hopefully you are not of klingon decent then...

I am proposing that, because you are fighting this now since almost one week and as I am sitting in front of that bloody device I should support you as much as possible...

Greetings

Axel

PS: What about a neat little splash screen showing the MP logo and keeping the user informed about the driver? There could also be a banner telling the declined user all the names of all the ppl who worked on that driver Maybe it shouldn't exceed 10 minutes playing time, but could also contain a clear and almost political statement by you regarding the world economy and peace under circumstances where there are too many 0x7Es which should be controlled similar to all these chinese birth control laws and... WELL!

 

[Herr R aus B]

Another new version...

I've added an option to manage the M.Play Home Center software.

When enabled (in configuration), the driver will stop the MHC program when the display is initialized (if it is running), and when the display is shut down MHC will be restarted (if it was running when the display was initialized).

Regards,
CybrMage

Great! Once again I have been taken over by historical events regarding the VL System MR300 driver landscape... Fortunately I managed to eliminate MHC from the auto start registry entries - so it's not running, but I certainly will have a look at the new driver tho

===================================

Seems to work as in kicks off MHC, but doesn't restart it after MP shutdown. Should it?

-Manfred-: I appreciate the pointers.... But, I have seen them before, and they are not helpful in this situation.... (they are Linux drivers, and use a totally different IO model)...

===================================

Me again - I just have been looking at the first of the URLs, Manfred posted. And I find these little functions interesting, as there are some, we obviously never took into account - these are the gotoXY function, that also sends a 0xA7 that we couldn't determine its meaning so far and the initFans function. The other functions match pretty good our results... Unfortunately we still can't be sure whther this 0xA4 0x7E we discussed here really is setting the display to internal standby mode or to display the internal time. If 0xA4 0x7D really means "init fans" than 0xA4 0x7E might be "init display" meaning setting the display to its internal standby screen... Maybe these delays they are using in there functions might be of any interest... Finally this cler function explains the 0xA0...

[FONT="Courier New"][SIZE="2"]def write(fd, v):
    os.write(fd, chr(v))

def writeChr(fd, c):
    os.write(fd, c)

def writeLn(fd, ln):
    for i in range(0, min(len(ln), 20)):
	writeChr(fd, ln[i])
    time.sleep(0.000040)

[COLOR="LightBlue"]def clear(fd):
    write(fd, 0xA0)
    time.sleep(0.000040)
[/COLOR]
[COLOR="Blue"]def gotoXY(fd, x, y):
    write(fd, 0)
    write(fd, 0xA1+y)
    write(fd, x)
    write(fd, 0xA7)
    time.sleep(0.000040)

def initFans(fd):
    write(fd, 0)
    write(fd, 0xA4)
    write(fd, 0x7D)[/COLOR]

def setFans(fd, fan1, fan2):
    write(fd, 0)
    write(fd, 0xAC)
    write(fd, fan1)
    write(fd, fan2)
    time.sleep(0.000040)

def setChars(fd, chars):
    write(fd, 0)
    write(fd, 0xAD)
    for char in chars:
	for row in char:
	    write(fd, row)
    time.sleep(0.000040)[/SIZE][/FONT]

I scanned one of the old logs and found this right after the COM port was initialized:

[FONT="Courier New"][SIZE="2"][COLOR="Blue"]00                                                .
A1                                               ¡
00 A7                                             .§[/COLOR]
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
20 20 20 20 
[COLOR="Blue"]00                                                .
AF                                                ¯[/COLOR]
00                                                .
A2                                                ¢
00 A7                                             .§
[COLOR="Blue"]20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
20 20 20 20    [/COLOR]                                       
[/SIZE][/FONT]

According to these functions that would be

1. gotoXY(0,0) as in place the cursor in the upper left corner (at least I assume that the upper left corner is at 0,0),
2. write 20 spaces at the current cursor position and thus, clear the first line of the display
3. call temp values (0x00 0xAF as can be read in the function Manfred posted)
4. gotoXY(0,1) as in put the cursor to the first character of the second line
5. write 20 spaces at the current cursor position and thus, clear the second line of the display

 

[cybrmage]

And here are the results from the German jury...

Is that anything like "views from the banana republic"?? 8-}

Now it's time to also add some tool tips{/QUOTE]
I've been considering making a change to the config screen... "Disable remote" becomes "enable remote" with the default value being "disabled"... Then when the remote is enabled:
1) present a "Are you sure?" dialog
2) If the user selects "Yes", present an "Are you really sure?" dialog.
3) If the user selects "Yes", present an "Are you really, really sure?" dialog.
.
.
.
42) If the user selects "Yes", present an "Well... OK... It's not advisable.... but..." messagebox.
43) present an "Enabling the remote can cause undesirable side effects... Are you really sure?" dialog.
44) If the user selects "Yes", continue at step 1.

Is that OK??? maybe I should just stick with what we've got!? 8-}

I first tested just repeating on different repeat frequencies

So it looks like 300ms is the magic number.... Otherwise, there are no other ill effects??
What happens if you press a single button then wait... does the event get firesd ok??
What about repeatedly pressing a button quickly 4 (or 5, or however many) times?? do all the events get fired, or do some get "missed"??

Then I also tested fan control a little bit.

No... The fan control is NOT diliberately disabled... It's just that the device now seems to only return 0x3F to the request for temperature information...

I haven't been able to look at your fan logs yet... (the message board won't seem to send me the file.. it gets half way and stops... likely a transient problem... will try again after I finish my replies)

The result was absolute silence as in nothing happened.

So... that means that the fan control is the ULTIMATE option for the HTPC crowd... Doesn't everyone want an absolutely silent HTPC????? Consider it an added bonus from the programmer 8-}!! (JK!!)

My interpretation....

Unfortunately, the doing a polled serial routine is rather difficult...
Once the driver is configured and initialized, it goes to "slepp"... The driver is called by the base ExternalDisplay plugin every time that it needs to update the display (by calling the SetLine() function), which happens every 250 to 350ms... (actually, the SetLine() function is called twice every 250ms to 350ms, once for each line of the display...)

In the small period of time available to us we have to send the display data to the screen, and then process a single byte of information... So what would happen is that the user will press a number of buttons per second to do their navigation... because we are only processing data every 250 - 350ms, the button will not cause actions right away, so the user will press the button again... which does not respond right away, the they press the button again... Since we can only process 6 to 8 bytes per second, that leads to ever increasing lag in remote response time.

If we try to process all the keys that are in the data buffer, we will end up exceeding the reasonable amount of time that we have to process the data (approximately 100 to 150ms)... and that will result in a lag in the information that is displayed on the device....

The way we (and all other code in MediaPortal the uses the serial port) handle serial communications is to use the events that are available with the SerialPort class. The SerialPort class is the c# interface to the serial hardware, and provided data (RX and TX) buffering and events to indicate various changes to the state of the serial port. The driver adds it's data handling routine to the DataReceived event for the serial port we open. When data is received on the serial port, the system creates a new thread (independant of the driver thread) to handle run our WhenDataReceived event. This event is fired whenever the data in the read buffer exceeds a predefined threshold. This allows us to respond to a button press as soon as it is generated by the device rather than up to 1/3 of a second later.

The problem is - the buffer will contain as many bytes of data as was received from the display... If we decide not to read any of these bytes in our handling routine, then as soon as another byte of data is received, the event is fired again, and another copy of the WhenDataReceived() function is started to process the NEW data... To prevent this, I have added code that prevents this second instance of the WhenDataReceived thread from running until the first one has completed... (this was 4 or 5 versions back...) The WhenDataReceived() function will individually process each byte of data available to it....

But it appears that when you press a single button on the remote (and then wait several second), The device generates a byte to represent the button and then a 0x&E (damn them!)... It you press a series of buttons in quick succession, the device with generate individual bytes for each of the buttons pressed AND a 0x7E at the end...

The latest version of the WhenDataReceived() does the following:
1) read the data from the read buffer into a storage buffer
2) scann the storage buffer to eliminate bytes that are not remote button codes or temperature values (and removes the 0x7E if the "disable repeat" option is selected)
3) process each remaining byte with the following criteria
a) if the byte is a temperature value, record it to the appropriate temperature variable (using a simple state machine to track the the read temperature command is sent and how many temperature reading have been received)
b) if the byte is a button code and is NOT 0x7e: remember the value in a single byte cache... If the cache already contains a value, then fire the event for the cached button and discard it before storing the current value
c) If the byte is 0x7E:
c1) If the button cache contains a valid button then fire the event for that button and invalidate the cache.
c2) If the button cache is empty AND the delay period has not expired, ignore the 0x7E byte.
c3) If the delay period has expired, then fire the last button event again.

I would do it using a number of threads:

I would normally do that as well... but MediaPortal sometimes has a hard time shutting down when additional threads are used... even when thread safe flags and even brute force is used to terminate these threads, causeing MediaPortal to hang on exit... I would like to avoid using additional threads if at all possible.

So coding this all without being able to immediately see the results of your algorithms must be a nightmare, too...

Not really... more like a bad dream.... but I'm used to being treated like a mushroom... so it's not a situation that I am unfamiliar with...

If I make it to do some coding here, it surely would be either in Java or more likely in C++

Unfortunately, I think that any time you use to code in Java or C++ would be wasted (at least from the perspective of using said code in MediaPortal)...

C# is a "managed code" environment... c++ and Java are not... Even though they have similar classes for serial communications and are functionally equivilent, they exhibit different behavior... Although it would be a good educational experience.

Hopefully you are not of klingon decent then...

I am of Scottish decent.... Klingons dcended from us 8-}

I should support you as much as possible...

Your support has been termendous!!! far better than the support that I have received for any of the other drivers I have written.... Thank you!!

PS: What about a neat little splash screen....

You mean in a similar fashion to the "enable remote" option?? 8-}

Great! Once again I have been taken over by historical events regarding the VL System MR300 driver landscape...

Isn't sleep mode a b****.... 8-}

Seems to work as in kicks off MHC, but doesn't restart it after MP shutdown. Should it?

If MHC was running when the driver started, it should restart it when it shuts down.

Unfortunately, V Systems was lazy when they wrote the installer for MHC... The installer creates a registry entry that indicates that it was installed... but they do not record the installation path....

I expected the restart to be problematic.... So the driver already has logging to help with the restart problem... I'll make changes as soon as I manage to see the logs...

there are some, we obviously never took into account

Yes, the "clear display" was explained...

The GotoXY function is due to the way their driver framework operates and the programmers style... It is a variation of the 0xA1 0x00 and 0xA2 0x00 functions we use... They use the 0xA7 command with a single character, preceeding it with the cursor positioning command... We use the 0xA& command with an entire line of data... (and the trailing 0x00 is the end of data marker)

The InitFans command is a new definition for a code that we already use (and doesn't seem to work right now)

The thread you pointed out with the post by Dero yieled some interesting results... It indicates that there is definately a command that controlls the "power mode" of the device (either "ACPI", where the device intercept the power button on the remote, or "Pass through" mode, where the button code is passed to the computer for processing). Unfortunately, their device is the MR700, and the commands do not correlate with the MR300...


Regards,
CybrMage

PS: HOLY CR!!!

I had to post this as 10 seperate posts... The board would not let me post it as one....
I guess VL Systems does not want info about their devices leaked so they are going to EXTREAME lengths 8-}