Miss The Predictive Text From Your Old Nokia? Build Your Own T9 Keypad

Do you miss the mind-blowing typing speed of your old Nokia brick with predictive text turned on? Well, so did [Guy Dupont], so he created a USB keypad with T9 predictive text built-in to turn typing into a one-handed affair. Video after the break.

T9 was the first predictive text technology to gain widespread use in the late ’90s and early 2000s. The goal was to minimize the number of keypresses required for typing on multi-press keypads by matching key sequences to a dictionary of the possible words. It prioritizes words based on the frequency of use and can adapt to user preferences. [Guy] implemented T9 in Circuit Python, mainly for the RP2040 microcontroller used on the Raspberry Pi Pico, which will appear as a normal USB keyboard when plugged into any device. The dictionary is stored in the flash memory and can be updated using a tool also created by [Guy]. It can also change modes for old multi-press typing, numeric pad, or macro pad.

We would be interested to see just how fast it’s possible to type one handed with T9, and what application our readers can imagine. It doesn’t look like this implementation can learn the user’s preferences, which we think would be a worthy feature to add.

We’ve covered several unique custom keyboards recently, some more practical than others. On the silly side, these include a grenade-shaped function pad, a five-button chording keyboard, and a tiny two-key keyboard.

22 thoughts on “Miss The Predictive Text From Your Old Nokia? Build Your Own T9 Keypad

      1. I know, it’s laughable; the incredibly inappropriate use of Raspberry Pis especially so. It makes the “Butter Passing Robot” bit in Rick and Morty the most sad and relatable thing in a world of sub-$1 32 bit CPUs and basic state machines implemented in python on Linux. It’s where we might end up if someday there are $10 artificial general intelligences on eBay.

        However! Sometimes developer time efficiency is way more important than machine-time efficiency or appropriate hardware. I actually gave a talk once at NIH about this. For a one-off, or few-off system or task, it might lead to better and quicker results to use an approach that is ludicrously inefficient from the standpoint of computing resources, but maximizes return for developer effort.

        1. (This is my project)

          Bryce nailed it. Totally aware that this is not the most efficient way (computationally) to build this. But it was definitely the most efficient way for me to get it done. And more importantly – the ability to patch code / update the dictionary on the fly is very much a key feature at the moment. The fact that I was able to send these out to less technical friends and family, knowing that I could have them adjust things by simply dragging a file made life so much easier.

          1. Yes, of course @Moryc : )
            File access from software is not the problem CircuitPython solves (though it makes that stupid easy, too). It’s the process of getting the files (source or otherwise) on to the flash. Development loop is super quick, and folks can modify their experience without needing to install anything.

        2. The problem is that bad and lazy programmers are writing big, multi-threaded, parallel-processing applications in Python. I experienced this first hand when trying to use bCNC, which is written in Python. And it’s slow as molasses. Especially when compared to something like Mach3, which was written in C with performance in mind.

          Python for me is a modern day BASIC, great for learning programming concepts and for quick hacks and one-off projects. But no one uses BASIC for major projects, and for a good reason…

          On related note there is a subset of Java that runs on 8- and 32-bit micros embedded in every SIM and SmartCard (including ATM cards) since 1996. I wonder if it’s faster than Python…

    1. I stuck with Sony Ericsson phones for at least a decade because the T9 prediction was rather predictable and reliable. Then I got a different brand one and realized how awful it can be if they don’t count how often you use each word and put the common ones up top.

  1. ahh here we are again with T9. dont remind me anymore. I built T9 before T9 was a thing. i could of been rich! I built it for Pager communication because my friends would send words by typing numbers in the return call. called it pcode. crashed my pc trying to build a dictionary from text files i had already on my pc :)

  2. This is awsome. I’ve been thinking about something 95% similar for some years now. Very happy there’s someone less lazy than I am :)
    Things I would do differently:
    1. Make it smaller so it can be handheld and still be able to type.
    2. Actually make the predictions optionally. I think the debate is somewhat similar to pineaple in pizzas, but to me what made feature phones keyboards so great was typing without looking at the screen. This also means you can type faster because you know exactly what will be inputted, prediction means uncertainty.

    But overall I think this could have a lot of real uses. From people with disabilities to people who just need one hand free for some other task.

  3. I recall trying to make a T9 trie data structure about 2010. Had a parser go through a dictionary, weight the words, then build the trie. Got it built in memory just fine, but the amount of RAM needed was absurd. Thought about converting it with pointers to words instead of strings at the leaf nodes (one week prototype, of course corners were cut), but by then the project that would have used it went a different direction.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.