4X4 Key Pad problem
krazyideas
Posts: 119
Well I am using the 4X4 key pad.
I am also using the 4x4 kepad decoder by Beau Schwabe off of the object exchange. (The same one that is in the propellor library when you down load the Propellor tool)
The problem is that there are a couple of buttons that come out with the same value, and the value that comes up when you press a button is not always the same but changes from one value to another (between just 2 values).
I do not know why. I have it connected exactly how it says to do it in the object.
I thought that maybe it was a bad keypad, so I ordered and tried 2 others and they do the same thing. The values the buttons produce are not consistent, and the same value comes up for two different buttons.
Then I tried to lengthen the wires coming from the key pad by 12 inches, and it caused more problems.
Some thoughts would be apprecated.
Thanks
I am also using the 4x4 kepad decoder by Beau Schwabe off of the object exchange. (The same one that is in the propellor library when you down load the Propellor tool)
The problem is that there are a couple of buttons that come out with the same value, and the value that comes up when you press a button is not always the same but changes from one value to another (between just 2 values).
I do not know why. I have it connected exactly how it says to do it in the object.
I thought that maybe it was a bad keypad, so I ordered and tried 2 others and they do the same thing. The values the buttons produce are not consistent, and the same value comes up for two different buttons.
Then I tried to lengthen the wires coming from the key pad by 12 inches, and it caused more problems.
Some thoughts would be apprecated.
Thanks
Comments
You may want to change your project to use this object and add the necessary 74c922.
I added 0.1uF caps to either the columns or the rows (I don't remember which) and it worked fine.
There's also a way to monitor the keypad more directly but you need to add current limiting resistors (I think 100ohm) to some of the lines.
Shouldn't I be able to write a little program that would set each row high and then low one row at a time, and while it is high check to see if any of the colums goes high indicating which button was pressed??
Shouldn't something like this work??
Something like that should work fine, but you would need pulldown resistors on your ina lines... also you could potentially run into problems if multiple keys are pressed causing a short between your out lines if they are in disagreement.
Duane is on the right track by adding capacitors to the row and columns to combat external electrical interference. ... and distance between the keypad and the Propeller.
I did have to put in some pull down resistors to make it work.
I never thought about if the pins could be shorted out or not. I never knew that could be a problem.
So am I to understand that if a pin is set to be an output it is really bad to put a voltage to it even if it is 3.3 volts or less?
To fix the shorting proplem couldn't I just put some diodes in line with the output pins to stop the voltage from ever reaching them even if the current was trying to go into them??
Thanks guys.
I have said it once and I'll say it again. This Form and the people who use it are downright awsome.
You can use diodes, but better and cheaper is probably series resistors of a few hundred ohms.
Those also buy you some ESD protection.
You can also save any contention power, by idling the scan lines all low.
If they are all equal, then there is no contention current on multiple key closures during the non-scan times.
Some designs also drive all scan lines active, (H if you use pull downs) and look for any read-lines H,
If none are found, the extra tests can be skipped.
( "I ended up using weak pull ups on one set of lines and small resistors (I think around 220ohm) on the other set.")
Related links:
KeyPad demo http://forums.parallax.com/showthread.php/155364-MCP23008-Keypad-Interrupt-On-Change-demo
Alaem system http://forums.parallax.com/showthread.php/155592-Hackaday-Alarm-System-Propeller-keypad-(w-MCP23008)-LCD
I used pull-down resistors because of the way I used the shift registers for output and input. You could use pull-up resistors instead and just reverse all the "high" states and "low" states in the following description.
Pins 5 through 8 will be connected to the Prop's I/O pins are read as inputs. All four of the inputs should normally read low. Pins 1 through 4 will be controlled with output from the Prop. When pin 1 is set high, when a button in the first column is press, it will set one of the input pins high. If for example, when pin 1 is set high, and pin 6 is read as a high input, then you know button "4" was pressed.
Each of the pins 1 through 4 are set high one at a time, at the same time the inputs on 5 through 8 are monitored. By detecting which input pins go high while an output pin is set high, you can figure out which button was pressed.
If you had an error in your code which set pins 5 through 8 as outputs, then you could have too much current flowing between pins 1 through 4 to 5 through 8. You can eliminate possible damage to the Propeller from this sort of error by using series resistors on pins 1 through 4. 100 ohms would be enough to protect the I/O pins.
If you wanted to be really safe, you could put an 100 ohm resistor on each line. It is possible (if you had severe errors in your code) to drive the pins 5 though 8 to opposite states. While these pins were in opposite states and multiple buttons were pressed on the keypad, it would be possible to send excess current from one I/O pin to the other. This would really require some serious coding error and multiple button presses to be a problem. Personally, I wouldn't worry about it.
And here's the super paranoid version.
Again, the pull-down resistors could be pull-up resistors (connected to 3.3V instead of ground). I used pull-down resistors because the shift registers I was using but I think I'd use pull-up resistors if I were connecting it directly to the Prop (I'm not sure why, probably out of habit).
That said, I haven't used it long enough to determine if drift is a problem in the RC measurements, though each key does have a pretty wide range of readings that'll accept.
The values in the link seem to need a lot of drive energy, and 1uF caps tend to be large and not really precise or stable.
With the smallest margin just under 5%, you would be better with a bridge measuring scheme, that adds a 9th resistor (either in series, with a flip in direction, or to a 3rd pin).
That removes the C from the equation, and relies on resistor ratios, which should be fine @ ~ 5% (1% R's are common these days)
Keypad resistance values are from left to right top to bottom:
0720 1720 2720 3720
0480 1480 2480 3480
0240 1240 2240 3240
0000 1000 2000 3000
Two std values certainly appeals.
This has a min ratio change of just under 7%, so CAL is still needed for best margins.
Rather than a complex flip of R4 direction, I think I'd prefer to add a 1K to the Top Right hand corner, to give a 'KeyBoard Presence Sense & Calibrate' value of 4720, & CAL can use the same code as key read.
This is just a very quick idea on the spur of the moment but it sounded easy to implement as I would just use 2 tiny 4 way resnets and the cap. There are possible variations but the basic idea is there and yes the string could be terminated with a 1K in place of R4 though.
Realized I only need seven resistors, tweaked the values a little more, added a polling method to the object, and updated the Obex file.
The circuit Peter gave, can be used in single-pin mode, by X to Vcc with R1 value, and lowering R4, to be << R1..R3
Yes, sounds good - smaller caps are more stable and cheaper.
You can get 1% caps, but at a much higher price, so a system that
a) uses more same-value resistors
b) can auto-cal (CAP drift and precision become irrelevant) and Auto-detect keypad presence.
is going to be the lowest cost to produce.
There are also phantom keys possible in a Resistor keypad, for 'undocumented features' or modes.
For fun, I ran this up in LT spice - attached.
R9 is ESD/Protection/current limiting, and std values are 10k(x4) and 39k(x4), C2 is chosen to suit.
I saw a reference to this chip earlier but I must ask, why oh why would anyone use an encoder from the 70's that uses all those I/O lines just to interface??? Besides they are non-stocked .
If you must use an encoder IC there was one that was mentioned on this forum, the MAX7370 which runs off the I2C lines P28,P29 and will handle 8x8 keypads and LEDs and only costs a buck or so. Alternatively I just use a 50 cent micro for this task.
I favour lower values of R but of course in the same ratio as keypads tend to be mounted with some length of lead involved and are more prone to EMI or even just "hum" and switching noise injection from fingers. The termination calibration method works but requires a bit more software as it can never assume that the value that it read on initialization is correct as a key may be pressed at this time, so a maximum window value (max +/- %) needs to be updated to allow for the maximum reading (termination) to be processed as the calibration value.
I only had about 5 minutes to spare the other day when I came up with the idea but later on today I should be able to make up a circuit and write some code. I even have an idea about linearising the discharge curve that I might try out but either way software can be written to clean up the reading nicely.
BTW, the two X & Y terminals from the keypad are just meant to represent the connections electrically, whether we do use one or two I/O is application dependant.
Any keypress is going to need a check-for-stable, as key-change can give an interim value.
There is a ~25% margin between the No-Key presence detect value and the highest Key-Down value.
That can be increased to ~50% with 2 x 39k, but I'd expect 25% to be ok with 5% caps and 1% resistors, to cover drift issues.
To me, the 6.8% smallest-change is going to need some tracking calibration to be reliable in production.
- ie the decision point, will be 3.4% above one KeyValue, and 3.4% below the other.
Given the T=RC, and same Voltage end-point in all cases, I'm not sure that 'linearising the discharge curve' gains anything ?
Yes, of course, my mind's not right into it at the moment and since the switching threshold is approximately 0.5 VDD then the discharge curve is still fairly linear and so the readings should be also. Anyway, once I sit down to it and wire it up and code it I should have my "mind into it"
Tracking calibration would follow on a key release and continually in between key-presses as keypads are not normally roll-over.
4 x 4 keypad 1-pin rev C.spin
The 74C922/74C923 are officially dead! The reason that Mouser does not stock them is that they cannot be had. This holds true for Digikey and Newark (Element 14). I thought I had found some in China but that was a dead lead too. The only company that still has some of both part numbers (anywhere) is the Jameco Electronics. I have used the 74C923 and it works flawlessly. That and a parallel-to-serial shift register and you should be in business.
The other alternative is one that Parallax's own Chris Savage steered me to is the Palladin Semicinductor p/n PDN1188 which I belive will handle an 8x8 keypad. There is a "light" version which I believe is a PDN 1144 which is the 4x4 part. They will deal with you directly.