// nobulb

// nobulb

Dr. Disaster's Doomsday Console

Software Engineering System Architecture Computer-aided Design Circuit Fabrication Embedded Devices Hardware Prototyping Soldering

This was one piece of a project to create props for a pre-written escape room game. The backstory of the game is Dr. Disaster has a bomb which will destroy the lab within a certain period of time… unless the participant defuses the bomb using this console.


Two Doomsday consoles were built. The only requirements were that it was large enough to enclose and separately lock some control surfaces and two drawers. The client found and provided two second-hand roll top desks in great condition. Each of the consoles had three panels which became accessable upon unlocking and opening the rolling top.

The panel layouts were drawn in CAD software and cut to size by a vendor with a mill capable of cutting through the hefty 3/16" aluminum sheet metal. The side panels were designed to have an assortment of low-voltage components for thematic flair. The center console would house an Apple iPad running a custom application written for the game.

Each panel had vinyl decorations designed, cut and applied to complete the retro look. The surface was finished and sealed to ensure it would last against regular human interaction.


The electronics were managed by a custom relay controller. At its heart, an Espressif ESP8266 (the ESP-12 package): a 3.3V 32-bit SoC microcontroller with some really nice features such as low power consumption, 802.11 b/g/n wifi with WPA2, built-in interface protocols (I2C, SPI, SDIO, UART, IR), onboard 4MB flash memory, and an excellent array of general purpose IO. (swoon) The package selected around this chip was a Feather HUZZAH from Adafruit which included some further quality-of-life improvements over what the ESP already provided: nice IO breakouts, voltage regulation, header for an external battery and USB for power/programming, reset button, and a debug/status light.

The relay controller’s PCB was designed in CAD and printed by a hobbyist, short-run, online fabricator (shoutout, Oshpark). I populated three of the PCBs with components where I used sockets for the packages which were expected to fail more frequently due to pushing current-sink limits. 8-bit latching shifters were used to multiplex two digital outputs (along with ground) to control a package with eight MOSFET relays which would sufficiently sink the current necessary to drive its connected components. Each relay path allowed for its own resistor to limit current to a safe level based on the needs for that component which gave the controller a lot of flexibility around current draw.

With four sets of shifter/relay packages, the controller was able to drive up to 28 independent components with configurable voltage and current (up to 24V depending on the installed voltage regulator and up to 3A total limited by each component’s paired resistor). It would be possible to support up to 32 components with a re-designed PCB, however, space was limited for this revision.

Each controller would drive electronics mounted on the left and right panels and the magnetic locks for the roll top and two drawers. (The center panel would contain an iPad and required no external electronics more than USB-provided power.)


The ESP8266 brains were written in C++ and programmed using AVR programmers packaged with PlatformIO, an opensource embedded systems IDE, and supported by libraries pre-written for the Feather HUZZAH and ESP8266 packages.

The consoles (and other devices they communicate with) respond to the local network via mDNS and use MQTT to share events. mDNS makes network configuration dead simple and provides a nice way of potentially exposing a web-based interface as a future improvement. Using MQTT fit nicely with the system’s hub-and-spoke design. This kept clients small and efficient to run on such a low-power chip and allowed a central application to manage if-this-then-that logic.

The design for the consoles required them to detect and respond to success events from two other devices, one SNES controller which is expecting a specific sequence of inputs and the iPad central to the console which would spam a UDP message to the network. (Unfortunately, the iPad app was a black, unconfigurable box.) When the SNES emits success, then the relay opens the magnetic locks for the rolltop and drawers. When the iPad emits success, the console changes the pattern of lights and dials to simulate a “panic” mode has activated which happens in concert with other devices in the system.

Configuration would be managed by a central application which would manage the MQTT server, rules regarding events and triggers, and providing an easy interface for an operator to run the escape room game.