"First Test" Question (GLK24064-25-GW)

[ipscone]

Ok, I received my GLK24064-25-GW display today. I fired it up, and used all the defaults. Let me say first, that I had a different LCD on previously that was working fine, with my RS-232 setup. All I did was power this one and connect it to the same RS-232 line.

It worked but does something that the other LCD didn't do. There is some wierd <>>R> characters being displayed. Not sure what this is but it looks like some sort of echo of characters from the LCD. After pressing ENTER on my computer I get >R<>>R> that looks like this:

<>>R><R
<>>R> (where the red part is echoed after pressing each ENTER. The blue was already present from a previous ENTER)

As a sequence of events I have:

Photo 1: <>>R> shown on the display and I enter PRINT "TEST" (without hitting enter
Photo 2: Shows the display after ENTER is pressed
Photo 3: Shows the display after a second ENTER is pressed, so you can see what is echoed, after ENTER.

Click images for larger view


I'm sure I'll figure this out. Looks like some sort of echo that isn't needed. Or perhaps it something I didn't initialize.

Any ideas why this <R<>>R> is echoed each time I press ENTER?

[Raquel]

Hi,

Can you please query the module for its version number? Use command
254 / 54.

[ipscone]

I'll have to wait till later to do that as I'm away for a few hours. But I can say that this was just purchased only 2 days ago, if that helps. It just looks like it's displaying things that shouldn't be displayed.

The test case shown is just a BASIC statement that is being executed. I assume there are RETURN/LineFeeds that are sent, but never displayed. I don't know if that's what's going on here but I think it's something similar to that.

Regardless of version, does this >R<>>R>, ring any bells?

[Raquel]

Hi,

No, >R<>>R>, does not ring any bells. Besides, one would think that ENTER would probably be sending something like 0x0D 0x0A, which might display characters if these values hold a specific glyph. If not, the only control character that the GLK24064-25 implements is 0x0A which is new line.

You mentioned BASIC, does this mean that the host controller is ran by BASIC Stamp?

Did you upload this font yourself, or is this something that the unit came with?

[ipscone]

No BASIC was just the environment on a handheld device.

The font is just what are default on the LCD as received. But, like I also said, I did the very same test on another non-Matrix Orbital LCD display that I'm evaluating and it worked as one would expect, when executing that BASIC instruction. Only the MO display acts this way, which is why I posted this here.

All of the serial displays that I am evaluaing are connected to the same handheld running a BASIC environment and connected using RS-232 interface. The only thing that is different between each setup is the LCD is swapped out.

[Raquel]

Hi,

I wonder if you can please try something out for me? Would you happen to have uProject (MO software) or any terminal emulator that is capable of transmitting and receiving non-ASCII characters?

What would be nice is to see what ENTER is actually sending down the line. If you can please connect your BASIC host to a terminal emulator and then hit ENTER. You should be able to see what are the actual characters that BASIC is sending to the GLK24064-25-GW.

I do not need the revision number of the GLK24064-25-GW anymore, I did not realize that you have a totally different LCD module, I thought you were talking about an old GLK24064-25-GW.

Please let me know your findings.

[ipscone]

I just downloaded uProject and will try it tonight and report results. Does it work for the GLK series? The download site said "All LK/VK/PK, MOS, MX and LCD/VFD series".

I wonder too, I'm just using a 3 wire RS-232 connection, without any other jumpers or wires. All other pins are open except RX, TX and GND. Shouldn't that be ok? I assume the answer is "yes" since everything that I'm trying to send is actually showing up. It's just the extra characters that is the problem.

[Raquel]

Hi,

Although the GLK24064-25 is not included in the list of series that uProject can work with, uProject can difinitely be used with the GLK.

In the small task that I was talking about though, you will not be connecting the GLK24064-25 at all. It'll only be involving BASIC and uProject running at a different machine.

When you get to it, ie, say you got uProject running on a machine, connect via (a serial NULL modem cable) the comm port to the handheld device that runs BASIC. Open the communication by first selecting the proper COM port and baud setting in COM Setup tab of uProject, then click on Open COM. Go to the Main tab, by the Keypad section (around the bottom), there is a white rectangular window with a 'Clear' button under it. Watch this window as you then hit ENTER on the handheld device. I expect that the window will be displaying something like:
0x3E
0x52
0x3C
0x3E
0x3E
0x52
0x3E
0x0A

[ipscone]

Well, if it was sending those, I should see the same thing on my other serial LCD displays, since those are displayable characters. But I don't. I only see them on the GLK display. But I will check.

[Raquel]

Hi ipscone,

Yes, I understand where you're coming from. I just have not seen the GLK24064-25 act this way and the only way it would, is if it was told to display such characters.

Thank you for trying this out for me, hopefully we can understand more what's happening when we see the result of this test. If in case I was wrong, then we'll see what else we can try and see what is causing these >R<>> characters.

[ipscone]

Well, I did the test and found "good" and "bad" with this. Now, to find out how to resolve this.

1) Some extra characters are being sent. Not just the "<", ">" and "R", as displayed on the GLK display, but characters that are preceded with a 0x1B character. So "<" is actually

• 0x1B, 0x3C (the "<")
• 0x1B, 0x3E (the ">")
• 0x1B, 0x3C (the "<")
• 0x1B, 0x52 (the "R")

Now, I have something to work with, but this is still a puzzle. This is only a problem with the GLK display. As you can see in the 3 screenshots, if I run an emulator, these don't show up and are not displayed, on the emulator. Also, these are not displayed on other LCD modules by other manufacturers. But on the GLK display, the 0x1B is ignored and the 0x3C is printed.

2) At least this gives me something to work with. I have two tasks.

• to find out why these pair of characters are being sent and
• to find out why ONLY the MO modules behave this way.

Can MatrixObrital help figure out why this is being displayed, on their display. It's like the display is ignoring the 0x1B and printing only the following character. Is this the way all MO modules work?

I will work to find out why the characters are being sent in the first place.

But at least there is progress in understanding this.

Images:
Image1: View of what the emulator looks like upon running test program. This is also the same on my OTHER LCD display modules.

Image2: The captured text in ascii format. The esc chars aren't displyaed on emulator and other LCD. They are on the GLK displays, except your display appears to ignore the first char and prints only the 2nd, as if the esc wasn't sent.

Image3: This is just captured data for 3 successive ENTER key presses.

Click Images for Larger View


If you refer to my first photos above, you will see how the GLK looks when it sees these extra characters. The 2 byte sequence is printed as if it's only the 2nd byte and shows up as "<", ">" and "R" characters. Emulators and other LCD ignore the 2 byte sequence as non-printable. Why doesn't the GLK and further, the GLK displays seem to ignore the 0x1B and see only the following char ("<", ">", "R", etc). This needs to be explained.

The thing that is problematic with using Matrix Orbital GLK displays is if this sequence is sent,

Code: Select all

0x1B, 0x3C (ESC "<")
0x1B, 0x52 (ESC "R")
0x0D, 0x0A (CR LF) (or visa versa)
0x1B, 0x3C (ESC "<")
0x1B, 0x3E (ESC ">")
0x1B, 0x3E (ESC ">")
0x1B, 0x52 (ESC "R")
0x1B, 0x3E (ESC ">")

and if MO displays are the ONLY displays that behave this way, I can't use them. All the other LCD displays that I'm testing, simply ignore those two byte ESC sequences, if not used in their display. Is there any workaround with MO display module for this?

You can see that even terminal emulators ignore those extra characters, as can be seen in photo 1. Seems common practice for display devices and emulators, to just ignore unused ESC sequences. Why is MO different? Seems to me that since these can be seen as ESC sequences, they should simply be ignored, if they aren't recognized, NOT printing of 2nd character, as if not ESCAPPED.

[Raquel]

Hi ipscone,

Now we know that there are extra characters sent by BASIC. And more so, it is sending ESC characters that are fortunately understood by Hyperterminal and the other LCD modules that you've tried.

Unfortunately, as I've mentioned, the only control character we implement is 0x0A. This is the reason why the MO is different than the other ones. We want to keep our module general and as close to a true terminal emulator as we can. Many different applications will require to actually print out 0x1B if it is associated with a glyph in the font file, and so we leave the filtering on the host end. This will be the only workaround this; to get the host to do some filtering before it sends the characters to the display.

[ipscone]

That is the option that I realized I can do. I have to design an interface to go from my equipment to the RS-232 anyway. I guess I can intercept those ESC sequences and translate them to similar commands on the LCD (mostly cursor positioning).

But let me ask one other question. Is there a version of the GLK and GLC that don't require RS-232 input? I mean is there a parallel version?

Also another issue

I have noticed something akin to burning on these LCD. I display something on the LCD and then after a few seconds, CLEAR the display, and the display is cleared, but you can still see faint memory (display) of the erased characters. I have photos of this, if you are not familar with this.

Also, When I first write a full screen of text, the brightness of the characters is very uneven. Some are dark and others are light. It's a little wierd as some characters, even within a word, are brighter than others. Also, characters at the end of the display are dimmer than those at the front. It takes several seconds before they are all dark (fully lit up).

Are you aware of this?

Thanks,

[Raquel]

Hi,

But let me ask one other question. Is there a version of the GLK and GLC that don't require RS-232 input? I mean is there a parallel version?

We only offer the GLK in RS232 / TTL and I2C protocols. If you are interested in parallel displays, please see the following: http://www.matrixorbital.com/index.php? ... aphic-lcds
Please note though, that these parallel displays do not offer the features the GLK does and all the leg work has to be done to talk to these displays


For your problematic contrast, it would be nice to see a picture of it. I will get our RMA department to look at it and see if you might have a defective LCD, or if this is something they have seen before, because by the sounds of it, I have not seen such symptoms.