This is the final part in a series of three, describing the hardware behind the puzzle gadget I designed for Curtis’ birthday puzzle game. If you arrived at this page from elsewhere, you may want to start at Part 1.
The story so far: a secret surprise puzzle game, a hardware gadget that was designed and built, but needed more than proof-of-concept code, looming deadlines, oh yeah, and there’s that wireless data communications module we just barely touched upon.
Do you remember, way back in Part 1, when I said I would build the hardware and write the software, but I did not also want to be on the line for writing a puzzle? While all of this designing and building was going on, Jeff and Donna of Los Jefes were on the case. Donna wrote an amazing puzzle (or, rather, set of mini-puzzles) and Jeff was, I kid you not, retrofitting a tricorder! We knew pretty early on that because this is an interactive device, it could have multiple answers or multiple stages leading to a final answer. For instance, in my proof-of-concept hardware, different answers printed different messages.
Jeff independently had the plan to retrofit a toy tricorder with a color screen and microprocessor. He also found some RF modules — a transmitter and corresponding receiver — on SparkFun and put together the idea that the tricorder and puzzle box could wirelessly talk to each other. The puzzle box could have different states and transmit out a beacon to indicate what state it is in. The tricorder could then pick up on that beacon and use that information to show different scan results. Beautiful!
Except he was in Seattle and I’m here in Portland, and we probably wouldn’t get the chance to perform any sort of integration testing until the night before. Yeay…?
Running with this device pairing, Donna came up with a great set of five mini-puzzles. I have to admit that a couple of them stumped me and the playtesters (“YAR!”)… though typically just one digit out of a four or six digit number. (Brute forcing, for the win!) Much like the other puzzles in this particular game, the trivia and difficulty level were tuned specifically to Curtis, so some things that would be obvious for him caused us to struggle in testing.
Without getting too spoilery (though I don’t know how you’d play unless you decided to build your own copy of the puzzle gadget — which you are free, and encouraged, to do given that all the design files are Creative Commons licensed and all the parts are openly available), the tricorder cycles pictures and numbers that act as a primer for pictures cycling on the puzzle box. There are five stages of this, not exactly with increasing difficulty, but with different mechanisms for each stage.
Five stages, four images per = twenty images. I wasn’t using a fancy display with integrated SD card system. That used too many pins. The keypad alone ate up seven pins. The printer ate a couple pins. The screen ate half a dozen. The wireless module another. I had 32K to fit the code, the text strings, the libraries for talking to the printer and screen, and those images. Miraculously, I got everything to fit in memory: 32,234 bytes out of 32,256. Just 22 bytes to spare.
It looked like everything was ready to go: my snazzy puzzle box, Jeff’s mind-blowing tricorder, Donna’s amazing puzzles. But I worry. I’m an Eagle Scout. I like to be prepared with backup plans. We had no way to test the two devices together until the eleventh hour and I wasn’t totally comfortable with that.
The first thing I did was to build my own fake tricorder. Jeff built his own fake puzzle box. My tricorder wasn’t fancy enough to display pictures, but it could show me the beacon code it is currently receiving. With each of us with our fake “other device,” we could at least do some amount of independent integration testing.
This actually revealed a timing quirk in my puzzle box. In our agreed-upon protocol, I transmit a single byte code at 400bps every 50 milliseconds. 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 beacon. My event loop that cycles images and waits for input has a 10ms delay at the bottom. I retransmitted every five cycles of that loop, but forgot to take into account the delays inside of library code — for example, scanning the keypad or refreshing the display. I tuned the beacon retransmit counter to better account for this variable delay.
But still, my testbed tricorder had some problems. Often, it would get the right beacon code. Occasionally, it would slip in to a mode where it either got out of sync or there was surrounding RF interference. At those times, it only got garbage with an occasional beacon code, but not enough in a row to be considered a solid hit. I found signal to be much more clean on the edge of the puzzle box with the RF module retaining clip, so I drafted a Starfleet message pointing to “weakened shielding” on that edge:
But more importantly: how the heck were we going to playtest the puzzle without the tricorder??? Enter the Emergency Backup Tricorder. I threw together a quick webapp, optimized for the iPhone, to take the place of the tricorder. Obviously, it could not auto-detect the puzzle box’s beacon code. You had to manually select which mini-puzzle stage you were playing, but it otherwise conveyed the same information. It worked well in the playtest, and the redshirts escorting Curtis around had a Starfleet communication flyer, pointing to the Emergency Backup Tricorder, ready in case of an RF emergency:
The playtest was successful, aside from a printing hiccup. I had always assumed that the Arduino was built for 5V input. The CPU it is based around operates at 5V. When powering and programming the board via a USB cable, it is supplied with 5V. But it turns out the voltage regulator on the Arduino board is really more happy with 6 or 7 volts. You can usually get by with 5, but the thermal printer gobbles up power when it prints. My original testing was with a 5V 2A power supply, which seemed to work on my workbench. The difference being I also had the Arduino board plugged in to my laptop via USB, to quickly and frequently upload new code. This alternate power path kept the CPU alive during heavy printing. With just the 5V supply, the printer would occasionally starve the main board’s voltage regulator, causing it to reboot. I fixed this by bumping up to a 9V 2A supply. That’s more than enough power and current. When the puzzle’s location switched from indoors (a paintball studio) to outdoors (a park with no nearby power outlets), I did two things. First, I threw together a 6V external power supply made with D batteries. This worked for me at home, but failed during the playtest. Second, I modified the print code slightly to go a little easier on the thermal 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 understand, the game day itself went well (though, again, may have had a return of the print error). I was at HQ all day, listening for updates, blacking out windows for Artemis, and assorted other random tasks.
If I were to do this again, I would probably ditch the printer. It added bulk, cost, and a lot of unpredictability to the power requirements. I think I would have been better served by switching to a larger, possibly color, screen. On a longer timeline, I might have toyed with different mechanisms of securing a piece of paper or other object inside of a locking panel. Most geocaches are wooden boxes. Not only is the texture pleasing on your hands, but you have plenty of wiggle-room with regard to placing hinges, latches, solenoids, and servos. 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 better within the properties of the plastic. My guess would be a drawer, latched into place with a solenoid (or a servo and cut power to it when not in use, so it is not constantly trying to maintain its position).
Despite the snags, I had a lot of fun designing and building this puzzle box. Curtis now owns it and can do what he wants with it. I know he has toyed around with home automation (cf. cat food robot). The Arduino is really easy to write code for, especially when you have a functioning platform with buttons and a screen. The USB programming port is exposed right through the side of the case, the complete production source code is on Github as well as various 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 communications probe indefinitely. I’m fine with that, too.
Happy birthday, Curtis!
4 thoughts on “Using the Chubby Tricorder”
Great work, especially given the time!
FYI, an easy/foolproof-ish way to make a lock box (reverse geocache, etc) is to get a cheap (~$20) electronic safe (cheap safes are mostly electronic now). If you open up the door (from the inside) there’s a pretty simple mechanism and some wires you can tap into to open the solenoid on command. Of course you still have to pack the rest of your electronics somewhere. Also, the aesthetics of a cheap safe might not be great for any given purpose.
I like the physicality of printed output. There’s no wonder in a device, custom or otherwise, that shows something on a screen — we’re surrounded by screens that show things on command, and they are widely employed in puzzle hunts. “Oh look you glued a phone into a box. Yay?”
Printers aren’t exactly novel either but it’s less common for a puzzle gadget to emit a slip of custom printed paper.
Thanks, Dan. I only did minimal research on the lockboxes (back in Part 1), but have to agree that the aesthetics just didn’t feel right for this Game. I definitely wanted the presentation to be more “tech artifact” than “puzzle to work through.” In a different Game with a different storyline, the lockbox may actually be a better solution.
And yes, I loved the tactility (is that a word?) of a physical, printed output. I also like that it gives nearly unlimited output possibilities. As in the tech demo (and in a few easter eggs I left in), different codes can print different things — though in the final version of the code, the alternate codes are all silliness and do not actually advance the puzzle or story.
I know that cost and resources are a limitation, and that it’s so easy these days to spit out a web or iPhone app, but I’d love to see more gadgets well-integrated into Games. There’s just something magic about having a strange object in your possession versus looking at pixels on your day-to-day phone. 🙂