Background
I have a love/hate relationship with my smartphone. It’s an incredible tool; the number of things I can do on my red line commute each day with this little glass rectangle is pretty astounding. That being said, I have two major gripes:
- It’s boring: all smart phones look the same
- It’s addicting: I find myself reaching for it mid conversation or while watching a TV show
I’ve considered buying a dumb phone like the Light Phone (e-ink phone with no internet or app ecosystem), but this ignores the useful applications of a smartphone. I don’t want to remove all the tools, just the addiction.
I’ve also considered smartphones with some more dated form factors that rely on an old T9 keypad to add some friction into the phone experience. These are also tempting, but most lack regular security uptdates, which makes any payment app an immediate ’no.’ Plus, they’re all android, so no sexy blue bubbles.
Most recently, I’ve been considering an Apple Watch as an ironic path to digital minimalism. Ideally, I’d leave my phone at home in a drawer at least a few times a week, operating daily with only the watch. There’s just one main thing missing: a useable keyboard. Enter HTMAA!
Ideation
My first thought was to built a modern Blackberry with an Apple Watch as a screen. For one of our early weeks with electronics design I even designed the PCB for the keyboard. However, as I started scoping out the necessary dimensions, it didn’t feel like the best path. The Apple Watch would require massive bezels to match the necessary width for the keyboard, and making a PCB for the keyboard would require routes much smaller and more precise than what we can readily do in the shops.
Instead, I settled on building a “candybar phone” styled case (think like a Nokia) that would better match the width of the Apple Watch. This would enable a more spread-out PCB design with only 15 buttons (as opposed to 40) and would also let me easily retain access to the scroll wheel and menu button on the side of the watch.
I even made a rough mock-up of the concept!
Planning
This project has four main areas of effort:
- Case design and production (most likely through 3D printing)
- Button cap design and production (possibly also 3D printing)
- PCB design and production
- Integrated Programming and Networking (aka the code part)
The code was the area I was the most worried about; Apple has a notoriously closed ecosystem, and considering the Apple Watch is meant to be worn on your wrist, I wasn’t sure if I could get any Bluetooth Keyboard to work properly with it, nonetheless one I made.
I also brainstormed some areas for spiral development if time permitted
- A charging port for the keyboard battery
- A battery sensor for the keyboard battery
- Either adding a mini-speaker or designing directional cutouts in the case for the speaker in the Apple Watch to redirect sound to act like a normal phone (removing the need for bluetooth headphones to take calls)
- A camera attachment (to read pesky QR code menus)
PCB and Keyboard Design
Like I said, I originally wanted to use a traditional Blackberry as a model for the case. And while I’d love to pursue this eventually, my deicision to move to a candybar design was quickly reinforced.
When designing the PCB for a Blackberry Keyboard, I learned that my chosen microcontroller (an ESP32C3) did not actually have enough GPIO pins to map all the keys on its own. I’m using a matrix design for the keyboard, meaning each row and each column are assigned to a GPIO. For a Blackberry layout, this would be 4 rows of 10, meaning 14 GPIO pins.
There are ways around this (above is my initial draft of a schematic that would use a shift register to effectively add more GPIO pins), but the workarounds would add significantly more size and complexity. Between that and learning how much space pads for the switches added on the PCB, making a 15-button candybar phone seemed like the right move.
I stuck to using 6mm x 6mm tactile switches because they were readily available and I was pleasantly surprised with the feel of the “click,” but in future iterations I could see experimenting with more interesting switches, possibly something with more travel.
The matrix design also required that I make my PCB double sided and use vias so that the lines for rows and columns wouldn’t intersect. They’re not that interesting in the schematic, but they were a big part of my workflow in electronics production.
Here’s what the simpler T9 schematic ended up looking like:
Much cleaner! But still not complete. After thinking through the design, I realized there were a few changes that were needed:
- I hadn’t originally thought through how the PCB would be secured in the case, so I would need some mounting holes
- I completely neglected the need for a battery and would need to make space for it on the board (Anthony recommended a coincell battery)
- While this form factor worked, I recognized that I could save a lot of space by mounting both the battery and the microcontroller on the bottom side of the board
After incorporating these updates, I had the following final schematic:
Electronics Production
I’m not going to lie…manufacturing this PCB almost broke me.
I started by milling the board at EECS, as they have a milling machine that is set up to do double sided boards. It prompts you when to flip the board and when to change the bits and has an alignment tool to ensure that the top and bottom match up. So satisfying.
If you’re attentive, you’ll immediately see my first mistake. But if not, just keep reading. I’m convinced this one stupid mistake is what incurred every other issue afterwards.
After milling the board, I inserted the copper vias in the board. These make the connection between traces on each side of the board. Inserting them was simple but a bit tedious.
The vias are tiny, so it’s easiest to insert them with a pair of tweezers. They also have a flange on one side. This keeps them from falling straight through the board. To secure them, you essentially need to hammer out a flange on the other side.
In practice, this means inserting a tiny piece of copper and then trying to carefully hold it in the hole as you flip the board and position it on a flat surface to hammer. They fell out so many times as I tried to slide my finger or tweezers out when placing it on the desk. Eventually I started to get a feel for it though, and finished the process in roughly 30min.
The next big piece was attaching the microcontroller. On the XIAO ESP32C3, the battery terminals (VBAT) are on the bottom of the PCB.
To attach it, this meant putting a bit of soolder paste on the pads under the board, positioning the ESP32, and then gently heating the board up from the top and bottom with hot air until the solder melts.
The tough part about this is you can’t see when the solder melts. Additionally, it doesn’t immediately cement itself in place; it needs to be removed from heat first. This made it a bit of a guessing game.
To take some of the guess work out, I put a dab of solder paste on the corner of the board to have a general idea of when the heat was reaching a sufficient point. It took a couple tries, but was ultimately successful. What eventually worked was leaving the PCB sitting on the heating tray and letting it sit after the heat was turned off rather than moving it immediately. This gave the solder more time to set.
You can see in the last two pictures that the board got a bit of a tan from the process!
The next step was the finish soldering the board and begin soldering the switches…and this is when I realized my mistake. I finally looked more closely at the pads for my switches and realized I had completely forgotten to route the last row.
At first I thought I could carve out some paths manually, but when I realized I needed a few more vias, I knew I would need to start from scratch.
Doing it over again was the same workflow…just worse.
Starting with the PCB, for whatever reason the newly milled PCB seemed off. As far as I could tell no settings were different, but the results I got were far rougher than with my first board.
At first I thought that the tip I used was damaged or worn out, but changing it yielded similar results.
Eventually I got something passable and moved onto inserting my vias. This time I had the opposite problem than I had the first time. Rather than vias falling out as I flipped the board, the via holes were so tight that I could barely fit the vias in. I resorted to inserting the tweezers in the hole first and twisting to try to widen them up marginally.
Additionally, when I finally did get the vias through, they often didn’t go through smoothly. Because holes were tight on both sides, the vias occasionally got stuck underneath the copper route when I pushed them through and in a few cases completely pulled the route off the board.
This meant some board surgery would be necessary, but not before I attached a new ESP32C3.
Once again, getting the solder paste to melt under the microcontroller was an exercise in patience and frustration. By the time it was finally attached, my board looked like recently bought a beach house in Miami and didn’t believe in sunscreen.
Honestly, though, I kinda like the patina on the copper.
Okay, FINALLY onto the switches. Compared to everything else, soldering the little switches and the GPIOs on the microcontroller felt easy and satisfying.
I finished up my soldering section by repairing the main route that was damaged during via installation.
Little did I know what was about to happen.
After attaching everything to my board, I decided it was time to test it with my code before moving onto the battery. So, I hooked it up to my computer and…
The little light didn’t turn on and Arduino didn’t recognize it. Further investigation with a multimeter revealed that there was a short between the 3.3V and GND. With no identifiable connections between the two or their pads, Anthony surmised that I must have damaged the micrcontroller when attaching it with the solder paste. Too much sun.
Thankfully, he was willing to help and we managed to remove the old ESP32 and attach a new one without removing the switches. We ended up using more heat from the top this time to prevent effects on the other side of the board.
A quick test revealed no shorts! I also hooked it up to my computer and it worked perfectly. So, I went back and soldered the rest of the pins and…
IT HAPPENED AGAIN!!!
There was a short between GND and 3.3V again. I tried removing as much solder as I could in the area on the off chance there was a random connection, and even had Anthony inspect it. Despite out best efforts, no improvement.
Anthony helped me replace the ESP32 one more time, but this time we put down insulating tape on the 3.3V and 5V pads and in their vicinity. No matter how it was happening, we weren’t allowing a short the third time.
Finally, after a stressful few hours of extreme board surgery, it was working properly.
A few days later, after I’d finalized the code and done some troubleshooting with the case, it was time to attach the battery.
More trauma!
Originally, I was going to use a Coincell battery. Unfortunately, the footprint for the battery was a bit smaller than the actual battery, so I used a combination of the ultra-sonic knife and the insulating tape to ensure the battery wouldn’t short the board. I also put a bit of extra solder on the pad to lift the battery slightly off the board.
In the end, none of this mattered! A quick test revealed that the battery was not actually powerful enough to power the bluetooth program I was running (it could barely power an LED blinking program).
Thankfully, I was able to secire a 3.7V LiPo battery with a relatively flat form factor. Using it with my board, though, required some adjustments.
Rather than soldering it’s wires on directly, Anthony advised making it removeable. I soldered some silicon wires to my board and hot glued them in one spot to provide strain relief. Then Anthony walked me through crimping end pieces on so they could attach to the microplug on the LED.
This worked and the battery successfully powered my bluetooth program. Finally, my electronics production horror story was over.
Case Design and Production
In desiging the case, the first step was getting an accurate model of the Apple Watch to build around. I managed to find a step file online that’s linked below. It was pretty simple to remove the straps and I was of to the races!
Next, I referenced a Youtube video where someone designed a phone case in Fusion. In short, I projected the edges of the watch in a sketch, offset them by .2mm to give some tolerance, and then revolved the sketch around the watch’s perimeter to get the beginnings of my case!
From there I started building out the rest of the device. I used the Punkt phone as a basis, going for a relatively rectangular shape, and then went for the minimum width I could get that would still fit my PCB to ensure minimal bezels around the watch.
After I had the basic shape, I also knew that I wanted to make a cutout around where the scroll wheel and home button are, and that I wanted to try making a scoop to redirect sound from the speaker. A few more cuts, and I had my overall shape for the case!
Don’t get me wrong, there were a LOT of fixes to this, but the general shape remained the same.
The biggest shifts were in broader dimensions. At one point I realized my case was actually too small for my PCB, so I needed to increase the width of the phone.
Thankfully, I was RELIGIOUS with defining parameters as I modeled the case. While I was a little worried initially, I was releived that modifying my parameters did not break the model, making it very easy for me to adjust little dimensions.
This proved useful time and time again when I needed to adjust the screw holes / inserts, the depth of the case for the new battery, and overall tolerances on everything.
That last one was extremely important. On my first print, I tried using fuzzy skin because I thought it would give a satisfying texture. It kind of did, but I failed to exclude interlocking areas for the screws. This made it almost impossible to take the case back apart after I put it together the first time!
Subsequent prints were used to refine the fit of the watch and to add more space for PCB compontents. For example, you can see my 2nd case lacked enough depth.
I went through probable 6 prints between learning new mistakes and the battery change. Eventually, though, I dialed it in and had something relatively compact that still housed all necessary components (and finally got back on a printer with black fillament).
Originally I was also going to 3D print the buttons, but wasn’t really happy with their finish. Instead, I decided to laser cut some acrylic buttons.
Not only did these feel much more premium, but they also really tickled the 90s kid in me by being see-through and letting you see the internal components. It made me wish we had transparent purple PLA for the 3D printers!
Unfortunately, I almost ruined my entire project with this stunt. I attached the key caps with superglue. At first it seemed perfectly fine…and then after around 5min some started getting stuck. I ended up needing to replace a number of the switches, and got more practice at board surgery. I’ve gotta say, this board is going through hell and back.
I thought about cutting more acrylic buttons, but while I LOVED the look, I just didn’t trust myself to apply them properly. Instead, I went with an INNOVATIVE approach: I integrated the buttons into the case. What’s one more 3D print, right?
I am so happy I did this, because the results were great (other than a slightly messy print):
When I put it on it was initially a little tight; the board went up high enough that the new overhang buttons were all pressing into the switches. This was an easy fix though; I filed down the bottom screw terminals that the board rested on and this added the few mm of clearance to make it extremely useable.
Integrated Programming
The part that I thought would be the worst was oddly the most straightforward (other than one 3hr roadblock). Early in the semester I bought a cheap bluetooth keyboard and tested connecting it to the Apple Watch, and learned that it was possible when the watch is in VoiceOver mode.
This is an accessibility option that has the device read off menu items before you click them. While this is annoying for most things, it does enable additional devices to act as controllers, because the delay with reading makes it very difficult to use the touch screen. This was the only way to have the keyboard actually interact with the watch.
While using a keyboard with the watch, you use the left and right keys to navigate. It also registers an action button, which you would hold and then would allow spacebar to act as a click / select action.
In Week 12, I wanted to test using an ESP32 for these basic functions. I used my basic PCB from Week 6 that had 3 switches mapped to 3 GPIO pins and then was able to find a library for the ESP32 called BLE keyboard. This library both initializes bluetooth for the ESP32, and makes it discoverable as a Human Interface Device (HID). It’s this status as a, HID that makes it discoverable as a keyboard and not just any other device.
To my delight, the ESP32 was immediately discoverable! The buttons worked too, though voiceover made the experience a little finicky.
The next step for my code was changing the button assignments from one switch per GPIO to a matrix setup, where each GPIO has a row or a column mapped to it and different combinations of state changes in GPIOs trigger a specific keystroke.
Thankfully, this is also something I examined in past weeks. All the way back in Week 3 in WokWi I experimented with the code, so it was pretty straightforward.
Finally, for T9 typing, multiple button presses trigger a different character (two presses of ‘2’ produces a ‘b’). This was the part I hadn’t experimented with yet at all.
The solution was primarily around adding variables for number of button presses (pressCount) and the time since last press (lastPressTime). If time reached a certain point (I started with 1sec) or a different button was pressed, pressCount would reset. This ended up being more of a logic puzzle than a difficult coding problem.
The one other issue I needed to troubleshoot was that, while I had a delay for registering the button presses, I didn’t initially have a delay for the text actually printing. For example, with my first try at the code, if you pressed twice on ‘2’, you would get ‘ab’, not ‘b.’ Once I added a delay to actually send the keystroke, we were in business!
After this, it was just refinement. I implemented the shift key by defining a shift state that it would toggle and that would be shut off by another button press. I also spent a while messing with the right delay for sending / resetting button presses, and also added some debouncing logic to make the button presses smoother.
Still, one simple thing kept eluding me (this is the 3 hour roadblock I mentioned): when using a keyboard with the Apple Watch, Caps Lock + spacebar is used to click / select items. This worked extremely well during networking week when I had this mapped to one switch, but on my new board I was struggling to get it working.
I tried changing the syntax for caps lock and spacebar, making sure that capslock was engaged before the spacebar key was printed, and plenty of other tricks. It was odd because it would work, but would also do an arrow press one way or the other.
Eventually, I realized the problem wasn’t only this switch, but all the switches in that row; when pressing multiple switches in the top row in succession, the previous switch pressed would be keyed again before the new switch’s input would print.
This changed everything; it wasn’t a syntax error of the watch not recognizing the capslock + spacebar, but more likely a debouncing issue for the whole row. This made sense, as these switches were treated differently from the rest of the switches. Since they weren’t multipress and were used for navigation, I had their inputs print immediately rather than buffering while counting switch presses.
I added a line in the row’s logic to clear all keys first, then a short delay (shorter than the multipress buttons), and finally printing their input. FINALLY! Hours of troubleshooting and luckily it was a simple fix!
The final thing to solve was that the keyboard tended to time out without inputs when hooked up to battery; to restart you needed to hook it up to the computer again. This I solved on my first try with a quick bit of dummy code that sent the message "" every 60sec. There would be no actual output, but it was enough to make sure the keyboard didn’t go to sleep.
Final Product and Thoughts
I’m really happy with how this turned out. The phone has some nicks and imperfections (I’m still a little bitter than the only 3D print to have any issue was the very last one I needed), but I love the character it adds. I’d say it’s still a bit bigger than a Nokia, but it definitely evokes the era of early cell phones that makes me nostalgic.
What’s more, it works!
Here you can see me typing “My name is nate” in the Apple Watch, and it comes through perfectly even despite the fact that the Apple Watch isn’t natively set up for T9. Also, the clicks for the buttons are VERY satisfying.
It may feel a little anti-climactic to watch, but believe me that it’s pretty exciting to use. Especially for anyone who grew up with T9 texting, it’s amazing how quickly the muscle memory starts to return.
There are some things I would love to adapt for future iterations of this project:
- The Apple Watch doesn’t have great battery, so it’d be fantastic to enable a way for the case to charge the watch while doing all of this. My best thought is to take apart an Apple Watch charging cable, hook it up to a rechargable battery, and then add a slide switch to open and close the connection with the battery.
- While I like the form factor, now that I’ve truly finalized the build method, I’d love to start from scratch again designing the case to see if I can get something even more compact and sleek. I have a much better feel for how thin I can make the case, the required tolerances around components, and I’m just more comfortable modeling in general, so it’d be interesting to see what a true v2 case looks like
- My original idea was a Blackberry-style case rather than a candybar phone style. If I could get a used Apple Watch Ultra and potentially outsource the PCB, I’d love to try again with that form factor on the Ultra. It’s around 9mm wider than my Apple Watch (series 8 41mm), and with a commercial PCB and that extra width I think it could work very well.
Overall, I’m very proud and satisfied with my time in HTMAA and my growth. Going back to Week 1, I struggled to model even the most basic thing in Fusion. I honestly considered re-doing the Week 1 page out of embarassment, but I think it’s a good example of how far I’ve come.
My skills in parametric design and electronics production in particular have skyrocketed in response to the demands of this final project. I’ve also gotten more comfortable with just trying new things to see if they work (like the final buttons) instead of spending forever in CAD-land ideating on the perfect design.
Files: