[J8g8j] has been playing around with an old cellphone. He wanted to control it using a microcontroller but since there’s 24 buttons he wasn’t thrilled about hooking up a couple dozen relays to do the switching. Instead, he managed to control all 24-buttons using just 6-pins of a microcontroller.
The proof-of-concept video that he posted on his site shows the phone responding to an arbitrary string of button presses. [J8g8j] spent the majority of his time reverse engineering how the phone’s keypad is wired. Once he figured out the rows and columns of the key matrix he soldered wires to access each of them. This turns out to be 14 connections. To these, he wired up a set of opto-isolators to handle the switching. These are in turn controlled by a set of three 74HC138A 3-8 bit decoders. what’s left are six input pins that leave plenty of room for him to hook up other items to the Arduino serving as the microcontroller.
You can also do it with 2 8-bit latching shift registers and 3 output pins on the microcontroller.
Potentially he could have done it with 2 micro controller pins (UART Tx and UART Rx) using AT Commands. Have a look at the AT Command Set (page 48): http://affon.narod.ru/GSM/GSM0707.pdf
@NickS: Actually, I had drafted serial control as an alternative switch controller design. By my analysis with 74HC595 shift registers, I would need 5 pins for *full control* of the serial chain. This would include OE_B and SRCLR_B, in addition to SRCLK, RCLK and SER (data) pins. I know all I *need* is the last three, but that has drawbacks. In particular, it makes dealing with power-on indeterminate state trickier. For instance I want the phone to be powered-up when I set it, not because the I/O pulled-it down during power-up. Hence, the desire to control OE_B and SRCLR_B. Another drawback of the serial chain approach is the serial control software is more complex than a simple parallel write. (Even with the Arduino’s nativele serialized write functions.) Don’t get me wrong, if/when I run out of I/Os (like if I port it over to an MSP430 Launchpad) I may revisit the serial approach. But, for the time being, I’d like to keep it simple and move forward with the overall project.
If you used 4 pins to select each row/column and resistors you would need only one ADC pin to read the whole keypad, totaling 5 pins and no additional ICs. This, of course has the limitation that you cannot press 2 buttons from the same row/column (whichever is 4) at the same time.
Of course, it’s not a big limitation, your pc keyboard has it too.
To add even more: you can read 8 switches on the ADC pin and 3 other pins for selecting(6/2), totaling 4 pins. I wouldn’t go over 8 switches on an ADC pin.
@alan: Thanks for the comment. I truly was not aware that all cell phones can understand AT commands. (That phrase “AT Commands”… sends a chill from the the dial-up days.) Plus, when I tried, I could not find a data cable available for this phone. I’m almost certain Virgin Mobile made it a point to disable this capability. In any case, the point of this hack is to demonstrate hacking a keypad electrically. Not how to hack a cell phone per se. If you can’t use a serial cable to talk to the phone this demonstrates a viable option. Even if AT commands could be used, what AT commands are useful for navigating through the phone’s menus? Is it not phone-specific? It sounds like a neat idea that I will look into some day. (Like when button phones disappear.) But for now, I’ll stick to overriding the keypad “manually”. To me it is a more interesting hardware hack.
@Bogdan: I don’t understand how an Arduino ADC can be used to *control* a keypad. ADC to read a single key press, sure. But write/control?
Nice job, did the same with relays a few years back (in the link). A couple of months ago I did this with an old Nokia and using MOSFETs. Scroll down the comments on that site (click my name) and you will see a good discussion about some problems intercepting a keypad matrix. I can try to upload some pics..
@j8g8j: did you run into any problems with “false” or “double” key presses?
Some fotos here: http://www.instructables.com/id/Controlling-a-keypad-matrix-via-a-microcontroller/
I wonder if Charlieplexing could have been used to drive the opto-isolators with fewer pins? Most opto-isolators use an LED on the input side.
I did something similiar to control a radio scanner with a Commodore VIC-20(yeah VIC-20). You wire 2 CD4051 8 to 1 analog multiplexers with common I/O’s tied together and the 8 I/O lines of one 4051 to the rows of the keypad and the other 4051 wired to the columns, this gives you control of a 8X8 matrix(64 keys) with 6 lines of a parallel port.
@j8g8j: I sense a small misunderstanding here vs. Bogdan :)
I understand what you did was to replicate the 24-key keyboard using 24 optocouplers wired into a matrix identical to the original one, then simply connected the rows and columns of the original to the opto-matrix.
I think what Bogdan was talking about would be a solution where the “scanning output” side of the original key matrix (the rows or the columns) would get connected into an R-2R ladder, then into the MCU’s ADC pin (thus conveying at all times which row or column the phone is trying to scan at that instant), then using output pins of the MCU to dynamically react to that using the “scanning input” side of the original key matrix (the columns or the rows) thus spoofing the scan results.
In other words, sense by ADC when the phone tries to scan the line the key you want to press is on, and activate one of the inputs accordingly (then immediately deactivate it when the scan moves to another line).
All that would take plus one pin (plus ground) – likely 7-8-9 pins in all.
Interesting, the HTML filter ate my brackets. The last line was supposed to look like this (only foolishly using brackets instead of quotes):
All that would take “number of either rows or colums, whichever turns out to be the phone’s input side of the matrix” plus one pin (plus ground) – likely 7-8-9 pins in all.
Here is what i am talking about:
http://www.scienceprog.com/interface-multiple-keys-with-one-wire-and-save-pins-of-mcu/
You built that, but adaptated to 6 buttons. The thing is, instead of 6 buttons you will have 6 wires coming fron the matrix keyboard each corresponding to a row. Instead of connecting the thing to vcc you connect each of the 4 columns to 4 pins of the micro. You then apply vcc to each, in order and read what button from each column is pressed. You will need a total of 4 + 1 = 5 pins. We don’t count gnd or vcc here, just the number of pins required from the mcu.
And if you really wanna use few pins, check this out at page 2:
http://www.edn.com/contents/images/6360317.pdf
Nice job, did the same with relays a few years back (in the link). A couple of months ago I did this with an old Nokia and using MOSFETs. Scroll down the comments on that site (click my name) and you will see a good discussion about some problems intercepting a keypad matrix. I can try to upload some pics..
@j8g8j: did you run into any problems with “false” or “double” key presses?
Some crude pics here: http://www.instructables.com/id/Controlling-a-keypad-matrix-via-a-microcontroller/
@All: Thanks for the comments! I am learning some new things and getting some great ideas for future projects.
@Technics: I just found the “Charlieplexing” Wikipedia page and will check it out.
@B.L. Johansen: Funny you mention this. I had a problem with two button presses “for the price of one” and some ineffective “presses”. This turned out to be due to a cross-point bus wiring error. After fixing it, I do not have that problem. I’d speculate that what you are seeing may be due to using MOSFETS. With MOSFETS, I think there is a risk of current flow in both directions (Drain-to-Sourse as well as Source-to-Drain). So, pulling some pins “up” may pull others on the same row up too. You may need a “harder” pull-up/down on the FET gates to make sure they are “off”. But, I am just speculating. The optocouplers have NPN BJTs for outputs. It is much harder to induce a reverse current in a BJT. Also, the optocouplers provide excellent electrical isolation, comparable to an array of relays. So I do not need to worry about “gate” voltages being affected by source or drain voltage.
@Mad Max: I’ve looked at Bogdan’s follow-up links. I still think he is confused as to what I’ve done here. On the other hand, you seem to understand. What you are describing is implementing a “scanner” that is synchronized with the phone’s keypad scanner. Interesting idea, but in my experience, timing synchronization is not a trivial design challenge.
@Bogdan: Thanks for caring and sharing links. They have confirmed to me that you are confused. Both articles describe key press detect/read circuits/techniques. Please watch the video on my blog demonstrating the functionality of this build. In it you will see that my build does not read the keypad. It effectively “presses” keys.
@j8g8j you are right. I was confused, it’s because i was having a discussion about matrix keys with someone else. I understood your goal in the beginning, but when i later came to the website… i understood something different. Sorry for the confusion.
NEVER try to solder to the exposed pads of the phone, they are many layers and prone to warping with the heat of an iron.. I found out this the hard way about 7 years ago now.
The best solution I found to making a decent connection is to use silver loaded epoxy resin (yes its expensive, but worth every penny)
It is much better to use a single output pin per keypad input because there is less chatter and the phone sees a ‘firmer’ keypress.
To effect a decent and reliable system you need to connect both inner and outer conductor rings to opto isolators because on some phones the different keys ‘see’ different voltages, e.g. key1 2.2 volt, but key 5 1.7 and if you try to use a common ground you get unexpected results.
A video of my working demo is at :
http://realfred.uphero.com/Projects/gsm_0001.wmv
@j8g8j: I agree with you that “stray”current flow can be a hassle. I did work it out in the end but some keypads are so sensitive that simply touching the pads directly with a bare finger can be enough. Good shielding is essential. I was initially going for optocouplers but they were all out so I went for mosfets. I must say though, if you remove the enclosures of relays they are superb when prototyping. Firstly, they ALWAYS work. Secondly, they act as buttons since you can push directly on them. Thirdly, they make a nice click and you can actually see them working. Makes it that much easier WHEN you code wrong:)
@Fred (1/3): Your warning regarding soldering is applicable to all hacks that require soldering multilayer PCBs: Too much heat kills! Solder at own risk! Etc. Etc. Etc.
@Fred (2/3): I guess I lucked-out on my first try with my old Virgin Mobile “Flare” (LG LX165). It was easy to solder thin-guage Cat5 strands to the key conductors and it has a simple set of pull-ups/downs for the keypad addressing: All non-power key outer conductors pull-up to 2.8V thru 300-Ohms. Inner conductors are tied to the cell phone’s ground. (The power key conductors had different properties.) I did a bunch of keypad voltage, resistance and continuity measurements to evaluate feasibility of this hack long before I even got around to designing the controller board.
@Fred (3/3): Based on what I’ve learned from Bogdan’s links about single-wire keypad address detection. I think this may be what you encountered. Of course, your “brute-force” array of switches approach works, but here’s another take: The multiple voltages and pull-up values may hint at a single-wire key addressing design (or something like it). This will be more complex to deal with (more analog than digital). I would do several experiments first to help map voltage values to key values. (Eg: Short key conductors and measure voltage at that point.) If it is using single-wire addressing, I think we could use one (or more) DACs to “emulate” the specific voltage of a specific key press. To reduce MCU IO pin consumption, I would use a serially controlled DAC IC (with an I2C bus, perhaps). (Or build a DAC, just for the heck of it… but will require a handful of relays, do doubt.)
@tanntraad: Relays. I could not agree more. They are simple and reliable. In fact, I have one relay for the pwr key which I often use “manually” as I debug by gnd’g the neg coil pin. The pwr key was on that mis-wired bus, so I wired-in its own relay to bypass the optocoupler (and rule it out as a root-cause). Even though I may not actually need the relay for the pwr key anymore, I plan to keep it. I find the “click” of the relay very reassuring that *something* is happening. (Taking the case off is a neat idea… for low-voltage apps.)
@tanntraad:
Can you post the the schematics of the Mosfet version?
@xtrender: I can’t find it at the moment but from what I can see: http://www.instructables.com/file/F5XG7M7GP7IISY6/
The rows and columns are marked A to D and E to I (each got a mosfet). I made a “common” rail by connecting the mosfets like this:
http://www.instructables.com/file/FS365T5GPBD2T24/Now, in order to make a button push I pull a row and a column to the common rail (e.g. the “meny” button is activated by sending a signal to mosfets C and F. http://www.instructables.com/files/orig/FXA/E4WI/GP7IS3G6/FXAE4WIGP7IS3G6.jpg). I don’t know what the usual method is but it works :) I do run the microcontroller on the SAME battery as the mobile! this is not advised and can lead to erratic operation…
@tanntraad:
Does the commmon rail need to be conected to gnd?
And if the µC and the cellphone runs on diferent voltage sources, both grounds need to be connected right?
i’m new to eletronics..
Thanks.
@xtrender: Wait, there’s a glitch in the matrix. I see now that the common rail is NOT connected to anything. Thanks for pointing that out!
The second question is much harder to answer.. In theory they need to be because there must be a potential difference between gate and source. In practice it CAN work without a common ground (Because even minute voltages can “turn on” a mosfet). I’ll leave it to the experts to correct me and explain better.
@All: I have posted my schematics to my blog (http://mibifici.blogspot.com/ Click the “Appedix” tab to see them).
@xtrender: Electrical isolation (using relays or optocouplers) enables you to implement a design that emulates a real key press while reducing the risk of “adverse side effects”. Tying grounds may work well enough, but it may also induce undesirable ground currents between the different power domains since you will not know enough about the internal phone wiring to determine the best ground points. This may affect the operation and reliability of the phone as well as the MCU circuit.
@tanntraad: It looks like you did not implement a cross-point switch matrix design. Instead, you are pulling the rows and columns up/down independently of each other to turn-on two transistors instead of using just one as my cross-point design uses to “press” a key. This would explain the glitchy multiple-key-press problem you’ve had. Your design has a critical timing path: If the assertion of the two switches is not simultaneous (eg. one wire is longer than the other, or there is an MCU interrupt routine call between output writes), you will get two keys presses due to the delay between switching of the two FETs. This condition is impossible with a cross-point design where one switch connects both key conductors. Since this is basically how a standard keypad works, I don’t see why this would not work for your phone though it obviously has different row and column voltages. Unless your keypad pulls all voltages to ground… but why two pins then? (PS: your wiring pic shows NPN BJTs not P-channel Enhancement MOSFETS.)
@j8g8j: The “glitch”-part was more of a reference to the movie:) I did get it working in the end and the “double presses” was more about bad isolation and induced currents from all the cable bundles. Did you see the comment where i made the mistake?
The reason I went for my design was that i did not want to deal with timing. I’ve corrected the image now; http://www.instructables.com/file/FWVY3O7GPBDF2W7/
As you can see now, you can pull, say, “A” and it would do nothing. It would just be connected to the common rail which is “nothing”. Then, you can pull “E” and it too would connect to the rail and hence A and E are connected and a press is registered.
e.g by this code snippet:
high A
high E
pause 100
low A
low E
pause 500
…etc
During that 100ms any scanning would have hit. But as I’ve said before, this is not a good way to do it with mosfets. ..With relays it’s awesome:).
Yes that pic is wrong in terms of type of transistor but it was more to illustrate the idea:)
As long as you pull one row (A,B,C,D) and one column (E,F,G,H,I) it will register. It is essentially what happens in real life where a piece of metal, the button a.k.a. the rail, is connecting to the outher ring and then the center pad.
@tanntraad: *Now* I understand how your circuit works (“Common” != “Ground” –> Big diff!). A nice feature of your design is that it requires fewer switches than a cross-point design. So, in my case, I may have needed only 14 key conductor switches (one per row, one per column) instead of 24 (one per key/button). Since pressing multiple keys at the same time is not required for this application, I’ll take a closer look at this idea if a “Rev2” opportunity ever comes up. Thanks for sharing.
@j8g8j: Yes, maybe I should have pointed that out. Since I’m using the picaxe 18x I’m limited by its number of pins. Also, with this setup I can just identify the rows and columns on (almost) any phone and implement it there.
@Technics: I finally got around to studying Charlieplexing. Yes this could have been used to control the IR LEDs that control the Optocouplers output BJTs. However, with the 23-switch cross-matrix design, it will not save me any MCU pins. (N_led=N_pins*(N_pins-1)). However, if/when I build a Rev2 design, I am going to use a “shared-bus” design tanntraad describes instead of a cross-point matrix. This requires only 12 switches (or LEDs). Using Charlieplexing would eliminate the need for 3-to-8 decoders and bring the number of pins on the MCU down to 5 (4 for charlieplexed switches and 1 for relay (pwr key)) My only concern is that it looks like if an LED fails (shorts), it is hard to isolate the problem. So, I may just stick with my Rev2 approach that keeps the decoders. If I ever get around to a Rev3, I may try it just for the sake of trying something new. In any case, thanks for the suggestion.
So, do optocouplers work to hard-wire the keys on the Nokia 3310/3330 ?
Do they work well?
In this respect, does anyone have any good suggestions for optocoupler chips, the have to be cheap, as cheap as chips :)
I’m going to try to very carefully solder enameled .1mm wire to the contacts so that the rubber keypad still works, wish me luck :)
Wouldn’t it be great if there was an integrated circuit of tiny relays, they only have to power low voltages and could be turned on by 1 – 5 volts
then you wouldn’t have to worry about all that electronic stuff :)
Great thread! The potential applications are mind boggling!
Well done chaps!
ian