Notes for GrueBox 2 rotary mechanism wiring

This is the wiring block from the rotary mechanism:

Rotary wiring for GrueBox 2

The connections are as follows with the dial facing down with the wiring lugs at the top, from left to right they are yellow, blue, white, and red.

Blue, white, and red are open when the dial is at rest, and closed when the dial is rotated.

Yellow and blue are normally closed, but pulse open N times when the number N is dialed (10 times for a 0).

Blue and white are connected together by default, and will probably be used as a common ground point Since blue and white are shorted when the dial is rotated, the blue can act as a ground with yellow and red being used for GPIO connections on the Pi. White can remain disconnected.

I’m considering using the red line as equivalent of the push-to-talk button, since I don’t have a better solution at this point. The alternative is to either add a button to the phone (which will ruin the look), or remove the need for a push-to-talk button altogether, which is technically challenging, especially if I’m hoping to operate in the relatively noisy Maker Faire.

Miracle cure

There’s an old engineering meme about wd40 and duct tape. It’s really true. The dial mechanism on the rotary gruebox was slow and balky–running maybe 1/4 the speed it was supposed to, and one shot of wd40 and it’s running right as rain.

Contrary to popular myth, wd40 isn’t a lubricant exactly. It’s mostly a solvent with a little bit of lubricant. The solvent dissolves whatever’s gumming up the works, and the small shot of lubricant gets it running smoothly again. It’s not a replacement for proper lubrication, but it’s amazing stuff nonetheless.

Gutting GrueBox 2

I’ve gutted the rotary chest-phone that I am going to make into the third gruephone. What’s amazing to me is how little there actually is to them:

Rotary chest phone guts

Other than the bell, it’s just a dozen or so discrete components on a simple circuit board, mostly capacitors and resistors, with one transformer thrown in. The rotary mechanism is nifty bit of kit, but I didn’t cut that out, since I’m planning on using it (and it’s an integral part of the phone’s look.)

Getting the keypad working.

So, if I’m going to have 3 working phones for the Maker faire, I better get to building them. Today’s project is to get the keypad working. Oringally this keypad used a touch-tone signaling mechanism, but that wasn’t necessary for my purposes, so I just cut out all the DTMF hardware to get at the switches that the buttons operate. There are 12 buttons (3 columns and 4 rows) of numbers and symbols. The way these keypads operate is that each row and column has it’s own switch, and each button closes the switch for that column and that row. I wired each of those switches up to an I/O line on the raspberry pi 3B that I’m using as the brains of the Gruebox 1.

In the original phone, each column and row had its own tone, and so each number/symbol played two tones, hence Dual Tone Multi-Frequency. I just built a lookup table of switch values that map to symbols/numbers, and that’s how I decode which button is pressed.

Here’s a test run of the decoding:

Testing Gruebox1 keypad

So all 12 buttons work. There is also a switch for the on/off hook that isn’t connected yet, so I’m just wired of off-hook for now, so I can test.

I also removed the fake wood-grain sticker on the faceplate. It’s still got some residue from the adhesive, but I’ll take care of that later. Assembled it looks like:

Gruebox 1 keypad assembled and ready to put into the case.

Maker Faire again

I’ll be presenting at the Bay Area Maker Faire again this year. I’ll have a little more to show this year. My hope is to have at least 3 phones working, as well as a fourth under construction at the faire. This is an ambitious goal, and I’m not sure I’ll make it, but I’m going to give it a try.

In addition to having more phones, I’ve got all the software improvements since last time, such as module specific vocabularies, several new games, and I’m hoping to eliminate the push-to-talk button that makes the interface so problematic.

I hope to see you there!

Monitoring the phone

My day job is basically a DevOps/SRE type role, so it’s unsurprising that I’ve built a lot of monitoring into the phone.  Here’s a sample of a discharge/charge cycle of the battery:

You can see that heat dissipation during charging is something I still have to work on.  57 degrees C isn’t fatal, but it’s not ideal either.   I have discovered that it runs hotter when enclosed in the phone, so improving airflow might be a good option.  I am also thinking about ways to thermally couple the computer to the metal base of the phone, as that’s a pretty good heatsink.

Goodbye Nextthing.co

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.

Wumpus

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 wit.ai 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-existent, 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.