Using the Chubby Tricorder

This is the final part in a series of three, describ­ing the hard­ware behind the puz­zle gad­get I designed for Curtis’ birth­day puz­zle game. If you arrived at this page from else­where, you may want to start at Part 1.

The story so far: a secret sur­prise puz­zle game, a hard­ware gad­get that was designed and built, but needed more than proof-of-concept code, loom­ing dead­lines, oh yeah, and there’s that wire­less data com­mu­ni­ca­tions mod­ule we just barely touched upon.

Do you remem­ber, way back in Part 1, when I said I would build the hard­ware and write the soft­ware, but I did not also want to be on the line for writ­ing a puz­zle? While all of this design­ing and build­ing was going on, Jeff and Donna of Los Jefes were on the case. Donna wrote an amaz­ing puz­zle (or, rather, set of mini-puzzles) and Jeff was, I kid you not, retro­fitting a tri­corder! We knew pretty early on that because this is an inter­ac­tive device, it could have mul­ti­ple answers or mul­ti­ple stages lead­ing to a final answer. For instance, in my proof-of-concept hard­ware, dif­fer­ent answers printed dif­fer­ent mes­sages.

Jeff inde­pen­dently had the plan to retro­fit a toy tri­corder with a color screen and micro­proces­sor. He also found some RF mod­ules — a trans­mit­ter and cor­re­spond­ing receiver — on SparkFun and put together the idea that the tri­corder and puz­zle box could wire­lessly talk to each other. The puz­zle box could have dif­fer­ent states and trans­mit out a bea­con to indi­cate what state it is in. The tri­corder could then pick up on that bea­con and use that infor­ma­tion to show dif­fer­ent scan results. Beautiful!


Except he was in Seattle and I’m here in Portland, and we prob­a­bly wouldn’t get the chance to per­form any sort of inte­gra­tion test­ing until the night before. Yeay…?

Running with this device pair­ing, Donna came up with a great set of five mini-puzzles. I have to admit that a cou­ple of them stumped me and the playtesters (“YAR!”)… though typ­i­cally just one digit out of a four or six digit num­ber. (Brute forc­ing, for the win!) Much like the other puz­zles in this par­tic­u­lar game, the trivia and dif­fi­culty level were tuned specif­i­cally to Curtis, so some things that would be obvi­ous for him caused us to strug­gle in test­ing.

Without get­ting too spoil­ery (though I don’t know how you’d play unless you decided to build your own copy of the puz­zle gad­get — which you are free, and encour­aged, to do given that all the design files are Creative Commons licensed and all the parts are openly avail­able), the tri­corder cycles pic­tures and num­bers that act as a primer for pic­tures cycling on the puz­zle box. There are five stages of this, not exactly with increas­ing dif­fi­culty, but with dif­fer­ent mech­a­nisms for each stage.

Five stages, four images per = twenty images. I wasn’t using a fancy dis­play with inte­grated SD card sys­tem. That used too many pins. The key­pad alone ate up seven pins. The printer ate a cou­ple pins. The screen ate half a dozen. The wire­less mod­ule another. I had 32K to fit the code, the text strings, the libraries for talk­ing to the printer and screen, and those images. Miraculously, I got every­thing to fit in mem­ory: 32,234 bytes out of 32,256. Just 22 bytes to spare.

It looked like every­thing was ready to go: my snazzy puz­zle box, Jeff’s mind-blowing tri­corder, Donna’s amaz­ing puz­zles. But I worry. I’m an Eagle Scout. I like to be pre­pared with backup plans. We had no way to test the two devices together until the eleventh hour and I wasn’t totally com­fort­able with that.

The first thing I did was to build my own fake tri­corder. Jeff built his own fake puz­zle box. My tri­corder wasn’t fancy enough to dis­play pic­tures, but it could show me the bea­con code it is cur­rently receiv­ing. With each of us with our fake “other device,” we could at least do some amount of inde­pen­dent inte­gra­tion test­ing.


This actu­ally revealed a tim­ing quirk in my puz­zle box. In our agreed-upon pro­to­col, I trans­mit a sin­gle byte code at 400bps every 50 mil­lisec­onds. Through a bit of trial and error, Jeff found that the 50ms gives just the right amount of time for the receiver to lock on to the eye-pattern of the transmitter’s bea­con. My event loop that cycles images and waits for input has a 10ms delay at the bot­tom. I retrans­mit­ted every five cycles of that loop, but for­got to take into account the delays inside of library code — for exam­ple, scan­ning the key­pad or refresh­ing the dis­play. I tuned the bea­con retrans­mit counter to bet­ter account for this vari­able delay.

But still, my test­bed tri­corder had some prob­lems. Often, it would get the right bea­con code. Occasionally, it would slip in to a mode where it either got out of sync or there was sur­round­ing RF inter­fer­ence. At those times, it only got garbage with an occa­sional bea­con code, but not enough in a row to be con­sid­ered a solid hit. I found sig­nal to be much more clean on the edge of the puz­zle box with the RF mod­ule retain­ing clip, so I drafted a Starfleet mes­sage point­ing to “weak­ened shield­ing” on that edge:

Probe Shielding

But more impor­tantly: how the heck were we going to playtest the puz­zle with­out the tri­corder??? Enter the Emergency Backup Tricorder. I threw together a quick webapp, opti­mized for the iPhone, to take the place of the tri­corder. Obviously, it could not auto-detect the puz­zle box’s bea­con code. You had to man­u­ally select which mini-puzzle stage you were play­ing, but it oth­er­wise con­veyed the same infor­ma­tion. It worked well in the playtest, and the red­shirts escort­ing Curtis around had a Starfleet com­mu­ni­ca­tion flyer, point­ing to the Emergency Backup Tricorder, ready in case of an RF emer­gency:

Backup Tricorder


The playtest was suc­cess­ful, aside from a print­ing hic­cup. I had always assumed that the Arduino was built for 5V input. The CPU it is based around oper­ates at 5V. When pow­er­ing and pro­gram­ming the board via a USB cable, it is sup­plied with 5V.  But it turns out the volt­age reg­u­la­tor on the Arduino board is really more happy with 6 or 7 volts. You can usu­ally get by with 5, but the ther­mal printer gob­bles up power when it prints. My orig­i­nal test­ing was with a 5V 2A power sup­ply, which seemed to work on my work­bench. The dif­fer­ence being I also had the Arduino board plugged in to my lap­top via USB, to quickly and fre­quently upload new code. This alter­nate power path kept the CPU alive dur­ing heavy print­ing. With just the 5V sup­ply, the printer would occa­sion­ally starve the main board’s volt­age reg­u­la­tor, caus­ing it to reboot. I fixed this by bump­ing up to a 9V 2A sup­ply. That’s more than enough power and cur­rent. When the puzzle’s loca­tion switched from indoors (a paint­ball stu­dio) to out­doors (a park with no nearby power out­lets), I did two things. First, I threw together a 6V exter­nal power sup­ply made with D bat­ter­ies. This worked for me at home, but failed dur­ing the playtest. Second, I mod­i­fied the print code slightly to go a lit­tle eas­ier on the ther­mal printer, adding pauses between lines of heavy text. This seemed to then work (but may or may not have again failed on actual game day).

From what I under­stand, the game day itself went well (though, again, may have had a return of the print error). I was at HQ all day, lis­ten­ing for updates, black­ing out win­dows for Artemis, and assorted other ran­dom tasks.

If I were to do this again, I would prob­a­bly  ditch the printer. It added bulk, cost, and a lot of unpre­dictabil­ity to the power require­ments. I think I would have been bet­ter served by switch­ing to a larger, pos­si­bly color, screen. On a longer time­line, I might have toyed with dif­fer­ent mech­a­nisms of secur­ing a piece of paper or other object inside of a lock­ing panel. Most geo­caches are wooden boxes. Not only is the tex­ture pleas­ing on your hands, but you have plenty of wiggle-room with regard to plac­ing hinges, latches, sole­noids, and ser­vos. You just pick a spot and use a wood screw. I have not seen a reverse-geocache made of acrylic, so don’t know if a hinged-door design or a drawer would work bet­ter within the prop­er­ties of the plas­tic. My guess would be a drawer, latched into place with a sole­noid (or a servo and cut power to it when not in use, so it is not con­stantly try­ing to main­tain its posi­tion).

Despite the snags, I had a lot of fun design­ing and build­ing this puz­zle box. Curtis now owns it and can do what he wants with it. I know he has toyed around with home automa­tion (cf. cat food robot). The Arduino is really easy to write code for, espe­cially when you have a func­tion­ing plat­form with but­tons and a screen. The USB pro­gram­ming port is exposed right through the side of the case, the com­plete pro­duc­tion source code is on Github as well as var­i­ous board bring-up test apps, and the box is fairly easy to open up in the event that one would want to, say, swap out the printer for some other device on those same pins. Or it can stay a com­mu­ni­ca­tions probe indef­i­nitely. I’m fine with that, too.

Happy birth­day, Curtis!

Posted in: Dear Diary Gadgets MakerBot Puzzle Games

4 thoughts on “Using the Chubby Tricorder

  1. Great work, espe­cially given the time!

    FYI, an easy/foolproof-ish way to make a lock box (reverse geo­cache, etc) is to get a cheap (~$20) elec­tronic safe (cheap safes are mostly elec­tronic now). If you open up the door (from the inside) there’s a pretty sim­ple mech­a­nism and some wires you can tap into to open the sole­noid on com­mand. Of course you still have to pack the rest of your elec­tron­ics some­where. Also, the aes­thet­ics of a cheap safe might not be great for any given pur­pose.

    I like the phys­i­cal­ity of printed out­put. There’s no won­der in a device, cus­tom or oth­er­wise, that shows some­thing on a screen — we’re sur­rounded by screens that show things on com­mand, and they are widely employed in puz­zle hunts. “Oh look you glued a phone into a box. Yay?”

    Printers aren’t exactly novel either but it’s less com­mon for a puz­zle gad­get to emit a slip of cus­tom printed paper.

    1. Thanks, Dan. I only did min­i­mal research on the lock­boxes (back in Part 1), but have to agree that the aes­thet­ics just didn’t feel right for this Game. I def­i­nitely wanted the pre­sen­ta­tion to be more “tech arti­fact” than “puz­zle to work through.” In a dif­fer­ent Game with a dif­fer­ent sto­ry­line, the lock­box may actu­ally be a bet­ter solu­tion.

      And yes, I loved the tac­til­ity (is that a word?) of a phys­i­cal, printed out­put. I also like that it gives nearly unlim­ited out­put pos­si­bil­i­ties. As in the tech demo (and in a few easter eggs I left in), dif­fer­ent codes can print dif­fer­ent things — though in the final ver­sion of the code, the alter­nate codes are all silli­ness and do not actu­ally advance the puz­zle or story.

      I know that cost and resources are a lim­i­ta­tion, and that it’s so easy these days to spit out a web or iPhone app, but I’d love to see more gad­gets well-integrated into Games. There’s just some­thing magic about hav­ing a strange object in your pos­ses­sion ver­sus look­ing at pix­els on your day-to-day phone. :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>