The Maker Faire was excellent, even if there was a significant hardware failure that took the phone off-line for part of Saturday and all of Sunday.
It was too noisy to even attempt to play Zork, so I had prepared the framework so it could run a much simpler game called Moonglow, written byÂ Dave Bernazzani in 2004. It was designed to fit in a very small program, and as a result hasÂ a vocabulary of only ~70 words, rather than more than 650 for Zork. That worked well enough in testing and at the preview on Friday afternoon, but Saturday was Â significantly more crowded, and therefore noisy. The game was mostly unplayable. So Friday afternoon I hacked up a new game that only requires yes or no answers. Â It was suggested by my old friend Kevin Savetz, and inspired by the classic BASIC game animal.Â ItÂ asks a series of yes or no questions in an attempt to guess what animal you’re thinking of. Â If it fails, it asks you to contribute a new question that would have helped distinguish the new animal from the old. Â Adding new questionss was too challenging for the STT engine in such a noisy environment, so I didn’t allow updates. But with a pre-built database of 70ish animals and nearly as many questions, it did okay… for a few hours until the computer died late Saturday.
It had been having increasing problems with packet loss (30%) on the little WiFi network I had set up, so I attempted to restart the wlan interface, but that wedged. Â Attempting to reboot the whole computer yielded a unbootable computer. Â I had a spare computer with me, but the software backups were A) several days old and B) source only. Â So I reconstructed as much of the software as I could but recompiling on the chip computer itself took FOREVER. Â I probably should have worked out a cross compile environment, but I didn’t expect a single FST library file to take ~20 hours to compile. Â It spent most of that time swapping hard because the compiler was taking 650MB of virtual memory, and the poor little chip only has 512MB of RAM.
Despite the computer eating itself, I ended up getting an award.
This is the first demo of the phone more-of-less complete. Â You can see a video over at my facebook page. Â Apologies for those who don’t use facebook, but the raw video is too big for wordpress to handle.
After the demo, I decided that it was time to tear the phone apart and try interfacing with the phone hardware. Â Below you see roughly how theÂ parts fit together inside the phone.
The guts of the phone
There isn’t a lot of room in there to maneuver, but I managed to get the switches for the hook (the bar in the back) and the PTT button (the leafÂ switch in the center) hooked up for XIO-P6 and XIO-P7 respectively. Â It looks like:
The wires for the hook switch and the PTT button.
It ain’t pretty, and the wires don’t stay in very well, but once it’s all wedged into the phone, it works reasonably well.
My first pass at having the code react to these switches is pretty crude, but I have an idea of how to improve it.
So, after a several month hiatus, I’m back at it. Â I managed to get all the parts into the phone, though to make room I had to remove the bells from the ringer mechanism, which makes me sad.
You’ll notice the USB cord hanging out the back: that’s for charging the on-board 1,100 mAh LiPoly battery (and gives me a serial console if I plug it into my laptop or desktop), but the phoneÂ can run for hours without charging.
The software remains problematic. Â The speech recognition is still hit-or-miss. Â I need to give it more context about what words are likely, and to do thatÂ I think I’m going to have to implement a z-code interpreter in python, but that’s a non-trivial undertaking.
So it turns out that the transformer wasn’t necessary. Â I broke out a pocket oscilloscope, and it boosted the voltage from 1.5V pp, to 7.5V pp, and the resulting volume in the earpiece was VERY LOUD, so I tried without the transformer, and it worked perfectly, and at a much more reasonable volume with the alsamixer controls on the computerÂ set to mid-range.
Since that worked so well, I decided to try hooking the phone’s mouthpiece/mic straight up to the mic jack, and that worked like a charm as well. Â I was able to play the game with only a few problems with the STT engine due to slightly noisy input. I think I can tune that away using alsamixer again.
Lesson learned. Â A standard, cheap sound card/dongle is capable of interfacing with an old phone directly.
Here is a mostly complete list of offline text-to-speech engines I have at my disposal. Â I have cleaned up the text somewhat from the last time, so theyÂ should be easier to understand. Â Let me know what your favorite is in the comments.
Espeak is a very robotic, but relatively lightweight engine:
Festival is a quirky, but also lightweight engine. Â It was developed at the University of Edinburg, so it has a distinctly Scottish accent, which is cool:
Pico was developed by a company called SVOX, and was chosen byÂ Google to beÂ the voice of Android 1.6 “Donut”:
There is also Festival LightÂ developed at CMU, it has a variety of voices available to it:
Wow, it really has been a while, but improvements in technology have given me an idea of how to improve upon the original Dial-a-Grue phone.
The idea is to use a small embedded computer, this time a $9 “chip” computerÂ and actually embed it into a gutted phone. Â From there I can use text-to-speech (tts) and speech-to-text (stt) engines to allow you to play Zork, Adventure, and a variety of other games just by listening to the descriptions in the handsetÂ and speaking the commands back to the phone.
I’ve already got a passable prototype of the software running by building modules for Jasper. Â I’m using the pocketsphinx stt engine currently, and the results are acceptable, but not stellar. Â I’ll try to get some samples up soon.