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.
Soon the script kiddies will need one core per key.
Yeah, they should make this keyboard with a 555! /s
‘Member when people used to program their 8-bit 1-4MIPS microcontrollers in C? These micros still run faster than Python equivalent on modern hardware…
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.
(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.
You know that high-level compiled languages, like C(++) can access files, right? ;)
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.
Raspberry Pi ≠ RP2040
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…
You all realize this is a keyboard project, right? I mean, speed isn’t an especially critical part of it.
Your comments are always so bright and positive. I don’t know what I would have done if I hadn’t read your comment today. I really needed that pick me up.
I had T9 dictionary on my Ericsson. It was awesome, probably better than some modern cheap smartphones. Is Nokias T9 the same software as in Ericsson ?
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.
one handed*
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 :)
“Could of?”
Common mistake by native speakers who don’t really understand the grammar they’re using. Comes from an overuse of “could’ve” or “could have”.
Um. “Could have” is literally what “could’ve” is a contraction of. And it is perfectly proper grammar. How do you believe it is overused?
We need this on APRS-enabled hand-held radios. Tapping out a text message on those things is like using a late-90s mobile phone: no predictive text whatsoever.
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.
+1 I loved that I could write a message without looking at the screen on my N95
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.
Great stuff! It really inspired me and gave me some Ideas for my own project. I love your approach that focuses on getting it done your way and while making it available for guys like me who are not able to write that in assembler code. I followed on YT and i am happy to see more projects of youry :) keep it up!