I am having a problem with the GLK12232-25-FGW graphics display, which I am using to replace a LK204-25 alphanumeric display.
Basically, is capable of having a 16 key max or 25 key max key pad connected.
In the data sheet, in the features section on page 4, I see the sentence, "Support for up to a twenty-five key matrix style keypad". Also in Section 10 for the keypad (page 35) I see:
"The GLK12232-25 supports up to a 25 key, matrix style, keypad and may be configured to allow key presses to be automatically transmitted via RS-232 or polled through I2C. The GLK12232-25 also allows for auto-repeating key presses, and remapping of all keypad character codes."
However, in section 2.2 for the Keypad interface connector on page 8, "The GLK12232-25 provides a Keypad Interface Connector which allows for up to a four by four matrix style keypad to be directly connected to the display module."
I have ported code for this display from the code for a LK204-25 display which uses a 24 key keypad and while all 24 keys are being detected there are only 15 unique codes (on the GLK display not the LK204 display); 14 keys share codes. I have tried re-assigning the keys and this does not help. (This would support the 16 key scenario).
The keypad connector appears to be the same for the GLK12232 display as the LK204-25 display and consequently I have it connected the same way. (Is the pinout different?)
GLK12232-25-FGW Keypad
Hello Rob,
Thank you for posting on the forum.
I checked the manual as you pointed and you are right; section 2.2 should have said five by five matrix style keypad. I am going to get the technical writer correct this.
You said that you are porting from the alphanumeric LK204-25 to the graphic GLK12232-25-FGW but are having troubles with the keypad. Which PCB Rev LK204-25 were you using before?
I am not sure of the '15 unique codes and 14 keys that share codes'. Maybe I'll get you to please send me the combinations of rows and columns you want and help you develop the parameters for the command Assign Key Codes 254 / 213 so that we can assign the right codes.
With the LK204-25 and GLK12232-25-FGW supporting 25 keys, the pinout may be different (rows / columns) depending on the PCB Rev, but we should be able to achieve what you had last time.
Thanks,
Thank you for posting on the forum.
I checked the manual as you pointed and you are right; section 2.2 should have said five by five matrix style keypad. I am going to get the technical writer correct this.
You said that you are porting from the alphanumeric LK204-25 to the graphic GLK12232-25-FGW but are having troubles with the keypad. Which PCB Rev LK204-25 were you using before?
I am not sure of the '15 unique codes and 14 keys that share codes'. Maybe I'll get you to please send me the combinations of rows and columns you want and help you develop the parameters for the command Assign Key Codes 254 / 213 so that we can assign the right codes.
With the LK204-25 and GLK12232-25-FGW supporting 25 keys, the pinout may be different (rows / columns) depending on the PCB Rev, but we should be able to achieve what you had last time.
Thanks,
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
Thanks RaquelRaquel wrote:Hello Rob,
Thank you for posting on the forum.
I checked the manual as you pointed and you are right; section 2.2 should have said five by five matrix style keypad. I am going to get the technical writer correct this.
You said that you are porting from the alphanumeric LK204-25 to the graphic GLK12232-25-FGW but are having troubles with the keypad. Which PCB Rev LK204-25 were you using before?
I am not sure of the '15 unique codes and 14 keys that share codes'. Maybe I'll get you to please send me the combinations of rows and columns you want and help you develop the parameters for the command Assign Key Codes 254 / 213 so that we can assign the right codes.
With the LK204-25 and GLK12232-25-FGW supporting 25 keys, the pinout may be different (rows / columns) depending on the PCB Rev, but we should be able to achieve what you had last time.
Thanks,
I did some tests without our usual keyboard connector and found that the GLK12232 will read back 25 keys when I short the row and column pins with a jumper wire. The same test produced the same results for the LK204 display. So the row and column pin layout appears the same.
However I still get different results when connect the keyboard connector. The only connections to the keyboard connector are between the row and column pins. So this has got me confused.
I will look into this further....
While I am here are the times of 375us and 625us for delays between transactions (I am assuming complete commands) and data bytes respectively correct? They seem awfully long (and are hogging up our processor resources)....
Thank you
Yes, please let me know what you find.
As per the 375us and 625u delays, this is on the conservative side; you might want to decrease this gradually and see how it affects performance in I2C.
Graphics displays are slower than alphanumerics because text is not built in the hardware.
Thanks and Best Regards,
As per the 375us and 625u delays, this is on the conservative side; you might want to decrease this gradually and see how it affects performance in I2C.
Graphics displays are slower than alphanumerics because text is not built in the hardware.
Thanks and Best Regards,
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
Hi Raquel
I have a bit of a weird problem. The keys (all 25) are detected when I short the rows and columns directly together. However if I connect our keypad (that detects all 25 keys with the LK204). Then the key that is normally 'D' (row 1 column 4) is detected as 'A'. Unless I break the connection to the line that is connected to column 1 (row 1 column 1 is 'A'). Then I do get 'D'.
So pressing row 1 column 4 is being detected on row 1 column 1. The key presses form a short between columns of 30-200ohms normally (bounces around a lot as it is a membrane keypad).
There is no short (or even any significant resistance) between column 1 and row 1 when I press the key for column 1 and row 4.
So I am at a loss. Do you have a schematic for the keypad circuitry?
I have a bit of a weird problem. The keys (all 25) are detected when I short the rows and columns directly together. However if I connect our keypad (that detects all 25 keys with the LK204). Then the key that is normally 'D' (row 1 column 4) is detected as 'A'. Unless I break the connection to the line that is connected to column 1 (row 1 column 1 is 'A'). Then I do get 'D'.
So pressing row 1 column 4 is being detected on row 1 column 1. The key presses form a short between columns of 30-200ohms normally (bounces around a lot as it is a membrane keypad).
There is no short (or even any significant resistance) between column 1 and row 1 when I press the key for column 1 and row 4.
So I am at a loss. Do you have a schematic for the keypad circuitry?
Hi Rob,
I wonder, does this happen in I2C reads? Can you please confirm, when in RS232, that the problem still exists?
You will need to put the display back in RS232 (will need to do a bit of soldering) and try out uProject. Key presses as reported gets displayed in uProject's Main tab, bottom right corner, a white rectangular box.
I wonder, does this happen in I2C reads? Can you please confirm, when in RS232, that the problem still exists?
You will need to put the display back in RS232 (will need to do a bit of soldering) and try out uProject. Key presses as reported gets displayed in uProject's Main tab, bottom right corner, a white rectangular box.
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
The problem still exists with RS232. However we have traced the problem down a bit further.
If we leave the membrane keypad disconnected from its aluminium backing plate keys 'A' and 'D' are detected as normal. If we place the keypad on the plate then we see the problem It seems a bit crazy
. Although we don't think it is down entirely to the display.
This problem does not occur on the LK204 display we use so we are wondering what the difference between the row/column short detection circuitry on the two displays is.
If we leave the membrane keypad disconnected from its aluminium backing plate keys 'A' and 'D' are detected as normal. If we place the keypad on the plate then we see the problem It seems a bit crazy
. Although we don't think it is down entirely to the display. This problem does not occur on the LK204 display we use so we are wondering what the difference between the row/column short detection circuitry on the two displays is.
OK.
The problem does not occur if we use the graphics display with a hard wooden backplate for the membrane keyboard. The problem does occur if we use an aluminium backplate for the membrane keypad.
The keypad still has its sticky label on the back so there are no (apparent) connecting conductive surfaces. Changing the debounce time to huge value has no effect. Sliding a piece of paper between the aluminium backplate and the back of the membrane keypad and the problem goes away.
Also, repeating the same test on the LK204 and the problem does not occur.
At the moment, I suspect that the method used on the graphics display for detecting row and columns is too sensitive, in terms of EMI, when compared with the alphanumeric LK204 (on fact there are no other options I can see at the moment).
The problem does not occur if we use the graphics display with a hard wooden backplate for the membrane keyboard. The problem does occur if we use an aluminium backplate for the membrane keypad.
The keypad still has its sticky label on the back so there are no (apparent) connecting conductive surfaces. Changing the debounce time to huge value has no effect. Sliding a piece of paper between the aluminium backplate and the back of the membrane keypad and the problem goes away.
Also, repeating the same test on the LK204 and the problem does not occur.
At the moment, I suspect that the method used on the graphics display for detecting row and columns is too sensitive, in terms of EMI, when compared with the alphanumeric LK204 (on fact there are no other options I can see at the moment).
Hi Rob,
I have checked the keypad circuitry difference between the 2 displays, and I did find something. It seems that this difference and its effect is only apparent in some keypads. Keypad properties and characteristics vary quite widely; for most of our customers, the keypad implementation on our graphic displays works well. But we have had heard of same problem; and has rectified it. Hopefully it will do the same trick for you. You can find details of the change in this PCN.
Can you please send me via PM your email address?
Thanks,
I have checked the keypad circuitry difference between the 2 displays, and I did find something. It seems that this difference and its effect is only apparent in some keypads. Keypad properties and characteristics vary quite widely; for most of our customers, the keypad implementation on our graphic displays works well. But we have had heard of same problem; and has rectified it. Hopefully it will do the same trick for you. You can find details of the change in this PCN.
Can you please send me via PM your email address?
Thanks,
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital