Zalman HD135 VFD (VlSys Mplay)

[cybrmage]

Here is a new version.

I discovered the problem with setting the fan speed that was introduced with the automtic fan control option... (I need to actually WRITe the values to the display... not just calculate them 8-} )

I also, hopefully eliminated the problem with the temperature readings...

Regards,
CybrMage

[Herr R aus B]

Originally Posted by cybrmage

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

We have that rather disgusting but somehow cultic european song contest going on every year, where some I dunno how many million europeans from all over the european union sit in front of their TV sets and watch how mostly terrible singers and bands perform terrible but popular music. then, after some 25 or 30 singers, bands and other creatures tortured the audience with their musical emissions, all brave europeans grab their phones and start a giant phone vote... and than the votings are being presented country by county... that's where the phrase comes from... btw - that is how ABBA became popular - they won that contest in the 70s with "Waterloo".

Originally Posted by cybrmage

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

Brilliant idea! Ppl will love you!

Originally Posted by cybrmage

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"??

I tested it again a little bit - and yes, there are ill effects I dunno how you treat the incoming data, but please don't regard the 0x7E as being part of a single button press! The remote is simply crap and produces random repeats because of the bad button material. You should have these buttons pressed yourself once - than you wuld understand :-) I mean it. And you can also see it in that Hyper Terminal screenshot I attached

What I get now is something like this: I press the UP button several times and then if I press the DOWN button once, I obviously get an UP event... And I just found out that the same is happening if the repeats are disabled in the configuration. I several times press the UP button, then press the DOWN button and get an UP event... The next time I press the DOWN button, I get a DOWN event.... Then pressing the DOWN button for several times and then pressing the UP button once results in another DOWN event. The next time I press the UP button I get an UP event and so on and so on...

Originally Posted by cybrmage

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 see... unfortunately I still can't sniff the serial port itself. Did my COM port logs show this 0x3F as well? I again looked at these functions, Manfred found. And there the sequence for requesting temp values is 0x00 0xAF. Lookng at all these functions it seems as if all function calls start with 0x00. What exactly are you sending?

Originally Posted by cybrmage

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)

As if things weren't complicated enough... But obviously the same happened here as well - I didn't see how long your article was - it was not shown correctly - when qutoing it, I've got your rather log description... Maybe our articles are too long I have to read that first, then think it over. This really is complicated...

Originally Posted by cybrmage

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

------------------------ 8< ------------------------

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.

this is all terrible. But the good information is, that the are using an event driven model. Just to get it right - the event handler for the same event is called several times when the event is not handled fast enough, or how was I supposed to understand that?

Here is what I think right now - this display driver originally wasn't thought to handle remote codes or any input. It's a plain output driver. Connecting to the VFD when needed, writing contrents to it, then going asleep. If it is like that, then we are just raping the concept a little bit So now I come up with a completely different idea:

I already started to set up a pure C++ project to test this damn device... Now, if I succeed, then why not setting up something as shown in the attached picture. Doing so your driver would simply access this socket on port 22000 and write the display contents to it. ANother driver then would connect to the remote service which might be a IRTrans servce - that's why I wrote port 21000. The administation service then could be used to read temperatures, set fan speeds and so on...

Originally Posted by cybrmage

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

How are mushrooms treated? I eat them and some years ago I smoked them...

Originally Posted by Herr R aus B

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

Originally Posted by cybrmage

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.

At least it would help with the basics of handling thee remote codes properl as I can directly try and test things. Then ou'd have a solid base for a code port... I will take into respect, that just have one handler routine. Or we do it like described above - that would result in a very slim driver tho At least even if you accessed all the offered interface, the background service can do all the sorting, so that you get your information prepared, sorted and in the right order....

Originally Posted by cybrmage

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

Originally Posted by cybrmage

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

De nada as I already said it's fun - I just didn't wanna give ou the impression of disappreciating your work done so far by coming up with a complete new model. But I think, I#ll be doing some coding in C++ now - Will try to give it a base class, that handles everthing, so that it would fit the needs of MP. Any suggestions or demands?

Originally Posted by cybrmage

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

Even worse - ahm, better!

Sorry for the delayed response - I was close to several heart attacks here, as my notebook broke down again and again until I finally got the idea that I once when I bought it some 4 years ago got a tools CD with it. On that CD I found a power management tool I completely ignored. After having installed it, the notebook fan - which always made terrible noises - went off after a while and the notbook itself doesn't heat up any longer as it did before... Now there's silence, the notebook keeps running and unfortunately now I have to go to the kitchen to fry eggs... well... Remember I am a computer scientist and I really sat her for a long time thinking "why the heck did ASUS construct a notebook with such a bad heat and energy management..." Fortunately Firefox has this option to restore the last session...

WELL!

Originally Posted by cybrmage

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

But they are setting up an auto run entry in the registry - and that one contains the complete path. The problem is, that I deleted it the other day, because this autostarting of MHC annoyed me - but maybe Manfred or jaylemur can look that up... I just remember it was in Software...local machine...run - but I cant remember exactly - and there were two occurences...

Originally Posted by cybrmage

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

------------------------ 8< ------------------------

processing). Unfortunately, their device is the MR700, and the commands do not correlate with the MR300...

Woud ou mind refreshing the list of functions and their syntax as far as we've got it at this time? That would be helpful for me when coding this background stuff...

Greets

Axel

[-Manfred-]

You mean this?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run]
"MHC"="C:\\Program Files\\M.Play Home Center\\MHC.exe"

[Herr R aus B]

Originally Posted by cybrmage

Here is a new version.

I discovered the problem with setting the fan speed that was introduced with the automtic fan control option... (I need to actually WRITe the values to the display... not just calculate them 8-} )

I also, hopefully eliminated the problem with the temperature readings...

Regards,
CybrMage

They are roaring - both Good idea to do anything beyond calculating BUT! It'd be a rather great feature, if one could set separate standby values, because the 40% are rather loud and the case is that well cooled by the fans controlled by the mainboard, that the 40% fan speed in standby is just a wasting of energy and ears Btw I looked at the MHC again. I don't think, that fan speeds are restricted to these intervals (0,40,50,60,70,80,90,100) but can be set linear from 0 through 100 in 1% steps. At least this can be done using MHC's direct fan speed setting option. But I just looked at the values we assumed for the steps - they don't match linear values, because they are increased by 0x11 or 0x12 instead of 0xA - any idea what the systematic would be? The difference beteen 0x47 for 40% and 0xB1 is 106 decimal... strange...

The repeat behaviour is still naughty And judged from the logs you're stillr eading 0x3F - do you requst the temperature with 0x00 0xAF or just sending 0xAF?

[Herr R aus B]

Originally Posted by -Manfred-

You mean this?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Run]
"MHC"="C:\\Program Files\\M.Play Home Center\\MHC.exe"

Exactly!

[cybrmage]

Here is a new version....

I changed the device initialization to, hopefully, re-enable temperature readings....
I changed to serial data processing routine again... it now works like this:
1) If we receive a valid button code, fire the event immediately
2) If we receive a repeat code,
a) if a button code was just received, ignore it
b) if the repeat delay period has expired, and it has been less than 2.5 times the delay period, fire the last button event
b) if the repeat delay period has expired, and it has been more than 2.5 times the delay period, ignore it
I also fixed the control of the M.Play Home Center software... If enabled, the driver will stop MHC when it starts, and restart it when it finishes.


Regards,
CybrMage

[cybrmage]

Originally Posted by Herr R aus B

We have that rather disgusting but somehow cultic european song contest....

Umm... yeah... actually... never mind 8-}

Originally Posted by Herr R aus B

don't regard the 0x7E as being part of a single button press!

It's hard to ignore when all the logs show that there is a 0x7E after each button press... But I think I've figured out a way around it, and it should also solve the problem you are seeing.... see the latest driver post...

Originally Posted by Herr R aus B

Did my COM port logs show this 0x3F as well?

The com port logs did not.

Originally Posted by Herr R aus B

I again looked at these functions, Manfred found. And there the sequence for requesting temp values is 0x00 0xAF.

With that particular driver, yes, they prefix the command with 0x00... But the com logs clearly show that the 0x00 sent before the 0xAF is part of the previous serial write operation. I tend to trust confirmed information (the logs you provided) over unconfirmed information (the linux driver source code)... plus, the temperature reports were working up until the standby issue was resolved...

Originally Posted by Herr R aus B

This really is complicated...

and frustrating!!

Originally Posted by Herr R aus B

the event handler for the same event is called several times when the event is not handled fast enough

That is correct... The event handler get executed every time new data arrives on the serial port... That issue has been resolved with a mutex that prevents the second (or third, or fourth, etc) instance from processing data until the first has finished. Once the first has finished, the second will then process any data that has been received after the first event was fired... Ironically, we serialize the serial port 8-}


Here is what I think right now - this display driver originally wasn't thought to handle remote codes or any input. It's a plain output driver. Connecting to the VFD when needed, writing contrents to it, then going asleep. If it is like that, then we are just raping the concept a little bit So now I come up with a completely different idea:

Originally Posted by Herr R aus B

I already started to set up a pure C++ project to test this damn device...

Then this driver would be redundant, as MediaPort already has a driver for an IRTrans compatible remote, and the ExternalDisplay plugin has a driver for an IRTrans compatble display.

Originally Posted by Herr R aus B

How are mushrooms treated?

Mushrooms destined for the consumer market (IE: not wild mushrooms) are grown in large, dark underground caverns and fertilized with manure... The are literally "kept in the dark and fed SH**" 8-}

Originally Posted by Herr R aus B

But they are setting up an auto run entry in the registry - and that one contains the complete path.

Unfortunately, as you mentioned, the autorun entries can be deleted, so they are not a reliable way to get the executable path.

That issue has been resolved... You can get the executable path with the System.Diagnostic.Process namespace and the Process.MainModule.Filename proprty. That way, we don't need to search the registry...

Originally Posted by Herr R aus B

refreshing the list of functions

What??? You want up to date information??? You want to make life easier??? 8-}

Originally Posted by Herr R aus B

I don't think, that fan speeds are restricted to these intervals

I don't think so either... From the information I found, i suspected that this was the case (but it wasn't explicitly mentioned)... So I decided to leave it the way it is...

I actually think that the fan controller is just a fan voltage controller rather than a fan speed controller... (one of the people on another forum mentioned that two different brands of fan ran at different speeds with the same settings)... This means that the 0x00 value will shut the fan off completely (0V), and a value of 0xFF will turn it on at full speed (12V)... but a value of 0x20 (1.5V - 12.5% of full scale) will probably not turn on any fan (except for a very high efficiency low voltage unit). This makes it hard to find a starting point to use as a benchmark for when the fan is actually turned on... The Linux driver uses a base of 0x6E (5.1V - 42% of full scale) as an "on" point.

Originally Posted by Herr R aus B

do you requst the temperature with 0x00 0xAF or just sending 0xAF?

just 0xAF...


Regards,
CybrMage

[Herr R aus B]

Originally Posted by cybrmage

Here is a new version....

I changed the device initialization to, hopefully, re-enable temperature readings....
I changed to serial data processing routine again... it now works like this:
1) If we receive a valid button code, fire the event immediately
2) If we receive a repeat code,
a) if a button code was just received, ignore it
b) if the repeat delay period has expired, and it has been less than 2.5 times the delay period, fire the last button event
b) if the repeat delay period has expired, and it has been more than 2.5 times the delay period, ignore it
I also fixed the control of the M.Play Home Center software... If enabled, the driver will stop MHC when it starts, and restart it when it finishes.


Regards,
CybrMage

Some progress! Some big one!

• killing / restarting MHC works - maybe a checkbox to enable/disable this feature?
• initializing / setting to standby / waking up works
• behaviour of remote is acceptable between 100ms and 200ms and good at 300ms and above - well, setting the repeat frequency to "default" switches the repeat off (well, you already announced this behaviour in a way, didn't you?) - maybe the default is not used anyway between 100ms and 200ms one can notice artificial breaks in the repeating - it's like a hickup or something each 10-15 repeats
• fan control is still not the real thing. switching MP off or sending windows to standby, the fans obviously go up to 100%. This might be due to the default shut down state of the VFD, but there were versions of the driver where you've set fan speed to a minimum of 40%. The best would be to have two additional combos to set the offline fan speeds. Judging from the logs you still don't read any temerature values tho - but therefore there don't seem to be any 0x3F neither...
• the splash screen doesn't work as it maybe should. During the entire testing (started/stopped MP some 10 times) I saw it just once for a rather short time. Doesn't MP at least give you the time you need to initialize your driver?

So compared to the last versions this driver is much of an improvement! See logs attached...

[Herr R aus B]

Originally Posted by cybrmage

It's hard to ignore when all the logs show that there is a 0x7E after each button press... But I think I've figured out a way around it, and it should also solve the problem you are seeing.... see the latest driver post...

Yes, I understand your point, but look at that Hyper Terminal screen shot - that's no fake. I managed it for several times to produce just one single byte - in my opinion that indicates, that 0x7Es are not part of the single button press, which also somehow is approved by dero's article - eventhough he never exactly said so - but the history of this driver shows us, that nobody seems to have a real clue on that MR300 stuff. btw - you mentioned they were talking a MR700 device? I can't find such a device. They have a MR500 with a nice little description on this page (look under OEM/ODM) saying

MR-500 detect the temperature by thermo sensor and it could be minimized the fan noisy to increase the fan RPM in case of need. This calculates the temperature and fan RPM in artificial intelligence (AI) then will be increased or decreased the fan speed.

Artificial intelligence! Yeeeehah!! That's exactly what we'd need... I love these marketing geeks....

Originally Posted by cybrmage

The com port logs did not.

Darn... Maybe a bug in MP's COM port handling?

Originally Posted by cybrmage

That is correct... The event handler get executed every time new data arrives on the serial port... That issue has been resolved with a mutex that prevents the second (or third, or fourth, etc) instance from processing data until the first has finished. Once the first has finished, the second will then process any data that has been received after the first event was fired... Ironically, we serialize the serial port 8-}

Let me put it like that: F**K!
But looking at MP's HP they already pointed out that the entire plugin model might not be very sufficient...

Originally Posted by cybrmage

Then this driver would be redundant, as MediaPort already has a driver for an IRTrans compatible remote, and the ExternalDisplay plugin has a driver for an IRTrans compatble display.

Definately not, as not everybody might wanna have a windows service running and as you can see with jaylemur's demands, ppl still wanna make use of this MHC software, which btw. controls MP as well. So if you look at it like that, the driver must have been redundant from the beginning. I don't agree at all! I don't like the MHC software that much. I want a slim solution that does exactly what's needed. The MHC thing can do this and that is colorful has a brilliant(ly annoying) splash screen and so on... I want something, that resides in the background and does its work. So your driver is one great alternative for those who love MHC but also want to have display functionality. And I am the one who also wants fan control all the time and doesn't like MHC - so...

btw. do you have a source for a valid, understandable and complete description of the IRTRans protocol? As the vendors say, the software is open source... any documentation you could advise?

Originally Posted by cybrmage

Mushrooms destined for the consumer market (IE: not wild mushrooms) are grown in large, dark underground caverns and fertilized with manure... The are literally "kept in the dark and fed SH**" 8-}

Somewhat cynical if not sarcastical and ironical - aren't you? As for the dark - open your windows Or do you mean your workplace? That was one of the reasons I never wanted to work in the states unless having a german contract... These 4m² booths would make me most depressive I think. But they have the same in England as I could see, when I was working in London... Terrible customs!

Originally Posted by cybrmage

Unfortunately, as you mentioned, the autorun entries can be deleted, so they are not a reliable way to get the executable path.

The registry is a pain anyway...

Originally Posted by cybrmage

What??? You want up to date information??? You want to make life easier??? 8-}

Yes, indeed! And eventho I once was a programmer I love doumentation. Well structured, readable, understandable and complete doumentation. My bosses hated me for alle the time uplifts I added to my projects due to documenting. Maybe that's because I passed my maturity exam in german literature and english - I love the spoken and written word I also tried to get this into the ppl in the software development teams I led later on until now - almost impossible... They all are bound to this damn KISS principle. And when it gets to a desasterous point, they all cry for good documentation... I also could start a long discussion on total quality management, on the extra money we have to spend for dealing with those bugs we've got, because we saved some money in the beginning for the sake of quick results... You know what? I hate economists! Well - now I am ranting. In the end I again end up with Tom DeMarco and Timothy Lister - the said, it would be much better to get together making spaghetti than to sit in endless formal meetings...

YES! A NICE DOCUMENTATION OF THE ACHIEVED WOULD BE GREAT!

Eventhough it might be against the unspoken RTFM law, where we are not explaining things to ppl, because it took us days to find out about the proper solution but then could be explained in minutes - so why should these ppl have an easier life? Let them go through the entire frustrating procedure themselves... A collegue of mine, who mastered in philosophy and sociology once said, that this is the usual process of desolidarization (!) Well - he definately is an intellectual - but he writes the most comprehensive infrastructure and security concepts I ever read...

True - most of the ppl would use these results without even saying thank you and at the same time would also keep on with the practice of information hiding theirselves. Well then... Poor characters. I like to give and get... Usually it pays back from time to time...

And if Zalman or VL System would simply have answered my requests they probably wouldn't have lost anything, as ppl obviously still want to use their software, that btw free anyways. They could just have gained respect by simply documenting the interface and publishing it... As in a nice guesture...

Well - so far with this little baseline speech... Maybe I am demanding too much...

[cybrmage]

Originally Posted by Herr R aus B

[*]killing / restarting MHC works - maybe a checkbox to enable/disable this feature?

Already in configuration... I just ignore it with the test version

Originally Posted by Herr R aus B

[*]initializing / setting to standby / waking up works

Good...

Originally Posted by Herr R aus B

[*]behaviour of remote is acceptable

Good...

Originally Posted by Herr R aus B

setting the repeat frequency to "default" switches the repeat off

hmm.... that's strange... Does setting the delay to default completely disable repeats?? or does it just make it work strangely???

BTW, a log with some remote button presses would be useful 8-}

Originally Posted by Herr R aus B

[*]fan control

New behaviour in new version... see the configuration page.


[quote=Herr R aus B;220705][*]the splash screen [/QUOTE}
What??? Are you halucinating??? (Too much german beer at new years???) 8-}

Originally Posted by Herr R aus B

Doesn't MP at least give you the time you need to initialize your driver?

Nope... As soon as the Initialize() routine is called, it starts sending data to the display.

Originally Posted by Herr R aus B

look at that Hyper Terminal screen shot

I saw it... and I'm not saying that you are wrong... I'm just saying that this device doesn't always seem to react predictably... And I'd like to be able to account for unpredictable data being received... It could be that if a button is press quickly, the 0x7E is not generated, but it it is pressed more slowly (but not actually held) the 0x7E is generated (indicating that the device's repeat delay is really too short for normal operation).... The damn thing should be sending a "button pressed and held" code and a "button released", but I guess that is asking too much 8-}

Originally Posted by Herr R aus B

they were talking a MR700 device? I can't find such a device.

it's HERE.

Originally Posted by Herr R aus B

artificial intelligence (AI)

They are using an alternate definition...
Artificial: Not genuine.
Artificial: imitation; simulated; sham

Originally Posted by Herr R aus B

Darn... Maybe a bug in MP's COM port handling?

MediaPortal does not have any serial port handling... The SerialPort control is a .NET v2 Framework component.

Originally Posted by Herr R aus B

But looking at MP's HP they already pointed out that the entire plugin model might not be very sufficient...

Sufficient or not, It's all we've got.

Originally Posted by Herr R aus B

valid, understandable and complete description of the IRTRans protocol?

It may be open source... but it is still shrouded in mystery... I haven't been able to find anything comprehensible for it (I *WAS* considering purchasing a case that included an IRTrans receiver... Not any more)

Originally Posted by Herr R aus B

Somewhat cynical if not sarcastical and ironical - aren't you?

I prefer a sarcastic wit... And I prefer to be thought of as a realist...

[quote=Herr R aus B;220727]As for the dark[/QUOTE
"darK" = lack of information

Originally Posted by Herr R aus B

These 4m² booths

If the cubicle is that size, the employer is being very generous with space...

I actually like my workplace.... It has all the amenities of home and a 12 second commute from "home".

Originally Posted by Herr R aus B

Yes, indeed!

Now your just getting TOO damn demanding!!! 8-}


Regards,
CybrMage