Zalman HD135 VFD (VlSys Mplay) (1 Viewer)

[cybrmage]

Here is log for repeating key. 3-5 normal key press and then button down for a while. Sometimes this repeating is triggering too fast as you can see from the log. And also when repeating is wanted it is really fast and thus hard to stop at right place. This is only my opinion and maybe that's why user setting is preferrable.

/m

That log is from the older version, right!?!? (just want to make sure).

Ignoring the "repeat" issue for a moment... When you press a button, does it react right away? do you have to press a button twice to get a response?

As for the repeat... in time...

Regards,
CybrMage

 

[-Manfred-]

It behaves a bit strange. Sometimes first command is ignored (but led flashes) and sometimes it acts as double press. Yes that log was from... some version... can't keep count anymore - this is called Agile rapid development method?!? But here is a new one from newest version. (Put version info to logging?)

 

[cybrmage]

Unfortunately, your new version didn't change the behaviour.
.
.
.
Seems to have problem requesting the temperature.

It seems that the temperature data returned by the display is outside of the "allowable" limits that we have determined to be valid.... (that damned 0x3f again)...

Unless your case really is at -87C... (a REALLY efficient glycol cooling system, or maybe a liquid CO2 system???) 8-}

I think maybe some of the initialization commands have gotten messed up... I'll check them over...

Regards,
CybrMage

 

[-Manfred-]

Maybe I can help with that temp issue as can compile and check. You can PM that source if you see that reasonable, there is still this remote thing for you then

 

[Herr R aus B]

That's not exactly accurate... Yes, the remote doesn't function.... But the state machine does... And the "guess" I made on how to handle the remote's "repeat" function appears to be valid... (The last set of logs you provided confirm it).

What happens is that the received data is scrubbed of invalid data (IE: data that can not be a temperature reading, or a remote button) and then it is processed. If the state machine receives a remote button press, it caches it... and waits for the 0x7E command (This appears to be a button press indicator...)... When the 0x7E indicator is received, it fires the event that is associated with the button. (but the last version tried to fire the 0x7E and not the cached button)

If a 0x7E is received AND there is no button in the cache AND at least 100ms has passed since the last event was fired, we fire the last button we received.

I am afraid that is a little bit too complicated. I finally found that article by dero which even is in english. Furthermore I made some tests using Hyper Terminal - see attached snapshot, where '~' is 0x7E and 'T' is 0x54 as defined for the LEFT button. You can see the unpredictable behaviour of these remote buttons. I marked the two situations where I held the button pressed. All other 0x7E where randomly occurring. And as you can see, touching them "the right" way really makes the remote just send one single poor and lonely byte... I guess they used cheap contacts... Maybe these terrible slide contacts...

Facit: 0x7E definately is JUST a repeat indicator but NO button pressed indicator!

So my suggestion would still be as follows:

1. receiving a valid remote code immediately results in sending it to MP
2. the last valid remote code is being rememberd / cached until the next valid remote code comes around
3. subsequent 0x7E receivings are translated to sending the cached valid remote code to MP
4. after receiving a valid remote code the mnext 4-5 directly following 0x7Es are being ignored to produce a reasonable delay

but the standby sequence seems to be OK now

Good... finally 8-}

YEAH! *applause*

I also notice, in the last logs you posted, that the 0xA0 command has a 2 second delay after being sent, and the 0x00 0x00 0x00 sequence has a 500ms delay....

So that probably means that the 0xA0 is a "reset" command and the 0x00 sequence is probably an "attention" command.

I have added the appropriate delays to the new version.

You don't think these were random delays?

MHC must REALLY want the display to go to standby mode.... it sends it to the display a lot!!!.

Well - either we didn't discover the biggest secret of all yet or the MHC software is just the result of quick and dirty coding... I assume the latter is more likely... Maybe the coder has children or a wife who usually don't pay much attention to him, so that he has to repeat everything several times before he gets heard - so maybe he (or she) thinks, communication always has to be like that - who knows? Or it's maybe just another interpretation of the mass effect law - much helps much... or something like that...

It appears in your logs (although 0x0B is much more frequent) and the code provided by -Manfred-... I changed it to 0x0B because I assumed that it way an aberant occurence...

Pardon me... a what??? Got me...

I am a ......

If you'll excuse me.... I'm going to go crawl under a rock.... 8-}

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

I'm ranting again... oops 8-}

I fully understand why

Fortunately... The work on this driver seems to be appreciated... 8-}

Indeed!

And as for the new version - I can't complain so far. Repeats work well, remote works, standby works - but I doubt, that these artificial delays are necessary... Hard to say...

Anyway here are the logs and the screenshot from Hyper Terminal...

 

[cybrmage]

I behaves a bit strange. Sometimes first command is ignored (but led flashes) and sometimes it acts as double press.

I figured it was doing something like that...

Yes that log was from... some version... can't keep count anymore -

Welcome to the "driver of the minute" club 8-}

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

(Put version info to logging?)

I can tell by the data that it logged what version it is (as the logging always changes based on what I need to determine)... I just thought I'd make it easier for everyone else to determine what version created the log 8-}

Regards,
CybrMage

 

[Herr R aus B]

Yes that log was from... some version... can't keep count anymore -

Welcome to the "driver of the minute" club 8-}

Better call it driver of the second! While I was typing this article here you guys were one driver ahead - damn, I am too old for this shit I honestly advise not too make the repeat code thing too complicated - see my previous article Furthermore I agree with Manfred and jaylemur, that the repeat frequency is a little bit high... maybe you just ignere each other 0x7E - there are sooooooooo many 0x7Es out there anyway...

Here are my logs for version 010208d - I guess after posting this article I#ll find out that version 010208m is the one up to date...

 

[Herr R aus B]

New issue

Arghl...

I think I found a new bug. When MP is blanking the screen which is NOT going to standby, then the VFD is sent to standby. As a result the remote woudn't function any longer. Pressing PwrOff on the remote then sends windows to standby. Then it can be woke up with the remote again. After that my windows crashed as in the display driver - I mean the VGA) crashes - I've got a blu/white picture and then windows went off - so I dont have a log, as MP restarted automatically when windows came up again and overwrote the log. Hard to determine whether all that is related. But somehow the VFD is been sent to standby when MP blanks the screen. I can't do any testing the next 2 hours due to recordings. But I'am gona test that at least tomorrow unless you don't have any idea what that could be.

Regards anyway

 

[cybrmage]

I finally found that article by dero which even is in english.

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

All other 0x7E where randomly occurring.

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

So my suggestion would still be as follows:

1. receiving a valid remote code immediately results in sending it to MP
2. the last valid remote code is being rememberd / cached until the next valid remote code comes around
3. subsequent 0x7E receivings are translated to sending the cached valid remote code to MP
4. after receiving a valid remote code the mnext 4-5 directly following 0x7Es are being ignored to produce a reasonable delay

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

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

You don't think these were random delays?

From MHC, they appear to be consistent... I even went back to the older logs to double check... and I figure that since the delays are in the Initialize() and Cleanup() routines(), that they can't hurt...

Pardon me... a what??? Got me...

Sorry... I mis-spelled it... it should be aberrant...
aberrant: deviating from the ordinary, usual, or normal type; exceptional; abnormal.
(If figured, with your cerdentials, that I should probably start using bigger word in order to save face 8-} )

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



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.


Regards,
CybrMage

 

[cybrmage]

I think I found a new bug.

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