This is only tangentially about the GruePhone.  It appears that NextThing computer company has folded (probably actually ceased operation months ago)… apparently it has closed up shop and left a lot of people with outstanding (paid-for) orders unfulfilled.  This is sad on many levels.  It certainly sucks for people who are out the cash, but also because the device had so much promise.

The C.H.I.P. computer, despite its flaws, was a really nifty little device for an incredible price*.  It preceded (and may have driven) the development of the Raspberry Pi zero (and zero-W, which is closest to the C.H.I.P. in price and features.)  The integrated battery management made the device ideal for GruePhone 2.0.  Future phones will doubtless use either a Pi 3 or Pi Zero-W, but the lack of battery management means that I’ll either have to come up with some other solution or have the devices tethered to an external battery pack, neither of which is ideal.  I hope the C.H.I.P. in GruePhone 2.0 stays healthy.

[*] Maybe the price was a little too incredible.  Lack of profitability is the leading cause of failure in start-ups, and I think they priced it more on the cost of manufacture rather than the total cost of development.  Maybe they couldn’t sell enough of them to make ends meet on such narrow margins. If that’s the case, I wish they had charged $15-$20 and were still around.


In a flurry of activity, I’ve added yet another game.  This time the classic “Hunt the Wumpus‘.  It’s fairly faithful to the basic version, though the numbering of the rooms is different (still a dodecahedron though.)  For those not familiar with the game, you are an intrepid explorer in a cave with 20 interconnected rooms.  In some other room there resides a horrible (though usually very sleepy) beast known as a Wumpus, and it’s your job to kill it.  The cave is also home to bats (which carry you off to a random room) and deep pits where you will fall to your death.  To aid you in your quest, you have 5 crooked arrows, that can each fly through up to 5 rooms (if you can map out that far ahead.) If you fire and miss however, the wumpus wakes up and might move to an adjacent room, possibly the one you’re in–a fatal mistake. Wandering into the room with the wumpus is also sometimes fatal, though you usually just scare it off.

I’ve always had a soft spot for this game–it may be the first computer game I played.  I first played this game on a mainframe at my father’s work when I was about 7 years old.  At the time it seemed cool, though almost impossibly difficult.  Now it seems much easier, though I have the benefit of a map and better skills.

The game would actually be very fun and playable if not the the abysmal recognition accuracy I’m getting from the pocketsphinx STT engine.  It consistently mishears ‘shoot’ as ‘eight’, and ‘two’ as ‘ten’, making certain situations very frustrating.  I have three solutions in mind.  First, train the pocketsphinx engine.  Second, toss it out in favor of an online STT engine like or Google.  Third, and possibly the most appropriate for the phone, I could replace the voice input of numbers with using the dial on the phone, though this may prove equally frustrating to use in practice.

Sample test game after the break.  (more…)

New games

I’ve gotta be better with these updates.  It’s been about 10 months since my last post.

Work on the new phones is slow to non-existant, but I finally spent some time getting the old phone in better shape, both hardware and software.

First, the phone is now back in one piece after sitting disassembled for six months.  I took it apart to reflash the C.H.I.P. comptuer since it was having filesystem errors, and in the process broke off one of the wires for the on-hook switch inside the wiring block where I couldn’t get at it. It was a simple fix, but I just took forever to get around to it.

Second, the software fix I mentioned last time works great.  It basically allows each module (game) to have its own vocabulary.  That means that if I have a game/module with a large vocabulary (like Zork with its nearly 700 words), it doesn’t negatively impact the recognition performance of modules with limited vocabulary (like Animal, which uses only about 5 words.)  It means I can leave Zork enabled and add lots of other games without having them conflict with each other.

To that end I’ve been trying to find classic computer games that only require text input/output and have relatively limited vocabularies.  I’ve got 3 so far.  The first was actually implemented at last year’s Maker Faire: Animal. (It wasn’t demoed because the computer died before it was complete.) Animal plays simple guessing game where it asks you to think of an animal and asks you yes-or-no questions about it.  The neat thing about the original is that if you stump it, it can add a question and learn that animal.  The learning part hasn’t been implemented in the phone version, but a command-line variant allows me to populate the database.  It currently knows 122 different animals, but some of the questions are less than ideal.  (Does a cat have stripes?  Some do, some don’t, but ‘sometimes’ isn’t a valid answer to this program, so I chose “yes”)  I actually didn’t refer to the BASIC source when coding this up, so there are some minor differences.

Recently I’ve added two more: Blackjack and Hammurabi.

Blackjack isn’t yet as full featured as the original basic program.   Right now it only allows you to hit or stand, and doesn’t allow for betting, splitting or doubling down, but I’ll get there.

Hammurabi allows you to rule Babylon like the real Hammurabi (sorta).  You try to feed your people, grow more grain, and manage your land over 10 years.  Starve too many or sell too much land and they’ll revolt.  I based the game play on several different versions I found online, but it’s fairly faithful in how it follows the rules (that were consistent across different implementations anyway).  The phone based game makes a few concessions to the limitations of the interface.  First, you only rule for 5 years rather than the original 10, because talking through a 10 year reign was just tedious.  Second, it removes the need to do quite as much mental math-for instance, by allowing you to specify how many people you want to feed rather than how many bushels of wheat you want to feed them, and also suggests quasi-optimal plays.  The biggest technical hurdle for this game was parsing numbers spoken out loud.  My first pass at a parser is basically stolen from stackoverflow, but it has some limitations/bugs, and there appear to be better implementations.  This is especially annoying when you try to say ‘fifty five’, but the STT engine hears ‘fifteen five’ which parses to twenty.  Similarly if you say 270 as ‘two seventy’ you get 72 instead.  The TTS engine also has some quirks that are making this challenging.  It reads 1040 as “ten forty”, and more confusingly it reads 1800 as merely “eighteen”, missing the hundred entirely.  I’m guessing this is partly due to the way people typically say years (1986 is “nineteen eighty six” after all, seldom do people say “one thousand nine hundred and eighty six”.)

You can check out the code in the gitbub fork I have of the jasper project.  It’s not all pretty or elegant, but it’s at least mostly functional.

New (old) phones

One of the problems I had at the maker faire was that people wanted to try different games, but enabling them all at once caused problems.  I’m working on a software solution to mitigate some of those problems, but my wife suggested that next year I can have more than one phone available to use.

So I’ve gotten several more old phones to turn into GruePhones, and they can each run a different game. Two will be based on old Deco-tel “chest”phones, sometimes called spy-phones…

… because they’re hidden in a box.  Open one and it looks like this:

This one is push-button, but I also have a rotary one (in slightly better shape even).

So that’s two, but I also have one (maybe two with all the parts I got) of these babies:

I’m thinking that the push buttons on this one can be used to save different games…. and I think I can make them even more interesting.

Maker Faire round up

My booth at the 2017 Bay Area Maker Faire.

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.

Validation of my existence.

Demo of a short game

The first real demo of the phone so far

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.

In the phone

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.

Full handset functional

Handset wired up

Handset wired up

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.