Page 1 of 1

VK202-24-USB brightness doesn't work

Posted: Mon Mar 10, 2008 9:55 am
by ehrnam45
Well, after about 3 years I've resurrected my HTPC project and started tinkering with my display again. I downloaded uProject and set to work putting the display through its paces, only to discover that the brightness settings have no effect! The VFD Brightness slider sends thick bar graphs to the screen starting on the second row. Starting with the slider at 100% and moving it to 0% the bar graphs are: Full block, underscore, 1 pixel + underscore, 2 pixel + underscore. The LCD controls for brightness and contrast send garbled text, but I didn't expect those to actually work.

I also downloaded LCDC to see if it was just an issue with the uProject code. LCDC doesn't seem to be able to send brighness commands on the fly, and when sending text in the test/config menu, begins on the second line. The brightness setting seems to do the same thing as uProject, i.e. it sends the same bar graph size to the display when you connect.

I had some issues with this display when i bought it but thought they were just driver or code problems with the control software. The most notable problem was that the display would frequently stop writing to the top row. Is there a way I can verify the commands with something other than uProject or LCDC? I don't have enough coding experience to be able to use the instructions from the manual on my own, but i'm not opposed to trying.

Thanks in advace.

Posted: Mon Mar 10, 2008 12:16 pm
by Clark
Hi Ehrnam45,

Thanks for your question, sorry to hear you've had some trouble getting that VK202-24-USB up and running again. Glad to see that you've gotten uProject downloaded, that's always a good way to start out.

First, I'd like to make sure that you are communicating to the device correctly; sometimes strange output to the display is a result of a mis-match in the baud rate of the host and display. Try setting the baud to 19200; the default rate, as well as a couple others on the COM Setup list and observe the results.

Next, if you'd like to try to issue manual commands to the display, I would suggest that uProject may be the best way to start. Take a look at the Uploader tab on the right, this will let you create your own command list for the display. In particular select the Raw Data command from the Other tree. This will let you write to the display byte by byte, just as the commands are outlined in the manual. You can add bytes in decimal or hex form, but they will appear in the box as decimal numbers.

Hopefully, this info will give you a couple ideas to try out; let me know how things turn out, and feel free to post any more questions you think of along the way.

Thanks,
Troy

Posted: Tue Mar 11, 2008 12:30 am
by ehrnam45
Hi Clark, thanks for the prompt reply!

Setting the baud to 14400 and 38400 result in garbage characters being sent when the 'clear display' button is pressed. Setting it to 19200 behaves correctly.

If I send plain text with the raw data command before issuing any other commands, the text is displayed on the first line. Sending a clear screen command clears the screen (as expected) but then text or other commands end up on the second line thereafter. I may be forming the command bytes incorrectly, but the set brigtness command (sent as /254//89/2) produced a garbled character, possibly one of the custom characters. Variations on the format of 2 results in more strange characters and no change in brightness. As does setting the brightness to 0, 1 or 2

Another weird thing i saw was that after using an 'execute once' command, the main page shows that the display is no longer connected (Open COM is displayed instead of the expected Close COM). It seems like using the execute command auto-disconnects when the script completes, yes? Cycling the button to Connect COM reconnects the display, but all text is then sent to the second line.

Disconnecting the COM, then unplugging the USB cable resets the display to the load screen. Sending the brightness as /254//89/2 as the first command given bumps the top line down one row and puts a garbled character at position 21. Any effort to use the Set_VFDBrightness command with any value also bumps down the top line and sends a garbage character with no effect on the actual brightness.

Thinking back to when I first got the display, LCDC and other programs had the same problem of putting text on the second line as well. Could there be a problem with the firmware on this display? Here is the original post:
http://www.lcdforums.com/forums/viewtop ... highlight=
This is currently on a different computer with a fresh install of XP, the drivers and uProject, so the original suggestion of reinstalling seems to be ruled out. The USB cable is a standard external device cable, though I had planned on using the internal cable once I'm ready to mod my case and mount it.

I've also tried communicating with it on my linux box using lcdproc, but there are currently driver bugs that prevent me from getting it working on that box as well. When LCDd starts, the default daemon screen shows up mostly correct (a few stray characters) but starting lcdproc itself turns into a jumbled mess, though it can display on both lines. Would detailed hardware specs help with troubleshooting this from a driver conflict standpoint?

Thanks again![/url]

Posted: Tue Mar 11, 2008 6:43 am
by erd
ehrnam45 wrote:I've also tried communicating with it on my linux box using lcdproc, but there are currently driver bugs that prevent me from getting it working on that box as well. When LCDd starts, the default daemon screen shows up mostly correct (a few stray characters) but starting lcdproc itself turns into a jumbled mess, though it can display on both lines.
Hi,

I'm the present maintainer of the Matrix Orbital driver for LCDproc. Someone else was cleaning up the drivers between release 0.5.1 and 0.5.2 (someone who doesn't own a Matrix Orbital VFD), and a bug crept in where, for MtxOrb VFDs, an incorrect brightness sequence of 254 0x89 was sent where it should be 254 89.

This bug has been corrected in the CVS tree and appears in the nightly tarballs, but there hasn't been a release of LCDproc since 0.5.2, so rather than wait for 0.5.3, you can check around line 750 of server/drivers/MtxOrb.c for a line that looks like this...

Code: Select all

                unsigned char out[5] = { '\xFE', '\x89', 0 };
and change it to this

Code: Select all

                unsigned char out[5] = { '\xFE', 'Y', 0 };
(it's 'Y', not 89, to match the style of the other MtxOrb commands in the module).

Be sure to tell the driver you have a VFD with "Type=vkd" in LCDd.conf, too. If you forget, it defaults to LCD/LKD command strings and behavior, and a quick check of the MtxOrb docs will show that LCDs and VFDs have incompatible brightness and contrast commands.

That should do the trick for your display.

-ethan

Posted: Tue Mar 11, 2008 9:45 am
by ehrnam45
Ethan-

Thanks for your input! I had set my LCDd.conf to type=vfd, but I will try vkd as soon as i get a successful compile. I doubt that my mythbuntu box has gcc and the kernel headers, but a quick apt-get should fix that.

Have you posted this on launchpad yet? I didn't come across anything for it in my googling, but i was only searching for this model number.

Posted: Tue Mar 11, 2008 10:22 am
by Clark
Hi Ehrnam45,

Looks like Ethan has been able to provide a little direction on the Linux end of things, let me know if that improves your VFD situation at all, once you get that compile that is.

Thanks,
Troy

Posted: Tue Mar 11, 2008 10:26 am
by erd
ehrnam45 wrote:Ethan-
Thanks for your input! I had set my LCDd.conf to type=vfd, but I will try vkd as soon as i get a successful compile. I doubt that my mythbuntu box has gcc and the kernel headers, but a quick apt-get should fix that.

Have you posted this on launchpad yet? I didn't come across anything for it in my googling, but i was only searching for this model number.
Glad to help. I found this thread because I was helping someone else who already filed a bug report on launchpad... https://bugs.launchpad.net/ubuntu/+sour ... bug/187605

I think I'll see about posting an LCDproc patch to the docs and perhaps the LCDd.conf file to make it clear to Matrix Orbital users that they have to set the display type in the config file or they will get strange things. This is not the first time I've run across this. I think it should be clearer.

Oh... and don't forget to change MtxOrb.c if you are using unpatched LCDproc 0.5.2. There is a bug in that version only.

-ethan[/i]

Posted: Tue Mar 11, 2008 11:37 am
by ehrnam45
Well, no luck with the CVS package install. It compiled without complaint, and the flickering seems to be gone, but the display drops to the second line as with windows. If I grab the nightly tarball, can that be added into the CVS tree, or should i just compile it in a separate folder?

Posted: Sun Mar 16, 2008 10:30 pm
by ehrnam45
Still no luck with getting the display to cooperate. At this point, what other things can I do to debug the problem? I hate to just leave it unused, but I also can't sell it to someone else in good conscience if it's defective.

Posted: Mon Mar 17, 2008 9:47 am
by Clark
Hi Ernham,

Thanks for through those troubleshooting ideas for me, sorry to hear you've had little improvement in that display. I'll send you a PM with directions on how to proceed from this point to get that display working for you.

Thanks,
Troy