Under Pressure

For my first big interactive puzzle, the primary form of input was in the form of a number of pressure plates. Sensitivity needed to be high enough to reliably detect whether or not a person was standing on a plate, but did not need to be fine enough to distinguish weights. A number of them were going to be necessary, so ease of construction was a factor as well. Three possible approaches were identified:

  • Simple electrical switch relying on a purely mechanical ‘pressure’ detection. In effect, a spring or similar mechanism keeping a top plate from touching the bottom plate, which would allow contact under weight, and wiring the plates so that when they touch a circuit would be complete.
  • Strain Gauge Load Cells. These are the components that are used in digital scales for actually measuring weights electronically.
  • Velostat Conductive Sheets. Sheets of a material whose resistance varies when pressure is applied to it.

Choosing The Approach

The first option, relying on a simple mechanical approach to open and close a circuit based on weight had a significant advantage in being the simplest approach from an electrical wiring perspective. The significant difficulty was that it would very heavily rely on the actual physical construction of the housing and mechanisms. Theoretically, something as simple as two pieces of plywood, with foam along the border to keep a little distance between the two, but with enough give that someone stepping would bring them together, could work. However, issues such as warping of the plywood, whether the foam(or spring, or other means of creating a ‘gap with give’) would deform, meant that there might be significant reliability issues. Making a physical mechanism to work reliably would actually be potentially prohibitive, so this option was removed from the running.

The strain gauge load cells would provide far more accuracy than was needed, and should prove fairly resilient to the potential reliability issues identified with the purely physical mechanisms. Actual construction would be much more forgiving than the physical mechanism approach. The components were the priciest of the three options however.

Velostat lacked the precision of the strain gauge, but had enough fidelity for the purposes of simple ‘is someone standing on this or not,’ was cheaper than the strain gauges, and was perhaps the simplest of all the options to actually construct. The combination of good enough, cheap and easy to assemble was what lead to this being the final choice for how to implement the pressure plates.

Velostat Basics

There are actually a large number of different variations of Velostat. Some have very high resistance, almost no resistance variation due to pressure, and are used as antistatic packaging. However, the type useful for this particular context exhibits a highly variable resistance based on pressure applied to the sheet. The particular variant I used was purchased from https://www.adafruit.com/

If you were to take a multimeter set to measure resistance, and place the leads on two different points on a Velostat sheet and then tried to press the sheet between the two points, you would not see much of a difference in the resistance at all. In fact, the resistance may be high enough a multimeter wouldn’t recognize it as having a closed circuit. The way to use the velostat is to take two flat conductive surfaces and sandwich the velostat between the two. Connecting a multimeter to two different surfaces sandwiching a velostat sheet, you will see a fairly high but measurable resistance if they are gently touching, and by applying pressure it should drop to near zero. The exact resistance without applied pressure will vary based on surface area touching, just how much weight or pressure is provided by the basic sandwiched position.

Measuring the Velostat from a microcontroller involved wiring a voltage divider circuit, with the Velostat serving as one resistor, and a fixed resistor as the second. Since reading the voltage that is ‘output’ by the voltage divider depends on the ratio of the Velostat resistance to the fixed resistor, it is important to choose a value for the fixed resistor that produces easily distinguished ranges for ‘pressed’ and ‘unpressed.’ I encountered issues with this when by improving how well the conductive surfaces and Velostat were touching I drastically shifted the ‘unpressed’ resistance(dropping it to at least 1/1000 of the previous value). Unfortunately, this meant the fixed resistors I had initially used were far too high and meant I had to rewire the microcontroller side of the system with different far lower resistance resistors.

Actual Internals

Here are the actual internals of the pressure plates. Two pieces of plywood, one with an upraised edge, the other cut just smaller so it will fit just within that upraised edge. The shiny foil like bits are copper tape. One word of caution, adhesives can serve as an insulator, there are copper tapes with conductive adhesive. For this sort of use, you definitely want the copper tape with conductive adhesive. The top side, with the visible copper tape, actually has a very thin(1/16 inch or less) square of foam underneath the copper tape. Since plywood can have some curve or bend, this helps maintain contact. On the opposite side, you see a square 12″ by 12″ piece of Velostat. Underneath that, there is a similar layer of copper tape. Wire is attached to both sides, and holes were drilled so the wires could be run out the bottom. In addition, the bottom piece of plywood had tracks routed so that the wires could be run underneath without the pressure plates resting directly upon them.


Software to run the pressure sensors was actually fairly simple. A basic ‘analogRead’ on the appropriate pin would produce a value based on the voltage ‘output’ by the voltage divider. First, the software would need to calibrate itself. A number of readings would be taken over a configurable ‘calibration time.’ This would be multiplied by a configurable percentage, and if the value was below this threshold, then that would be considered ‘pressed,’ if above it would be considered ‘unpressed.’ There is an additional layer of very basic ‘debouncing.’ In order to avoid false positives, or values rapidly switching from one state to another when during a transition, it’s normal to apply what are called debouncing algorithms. In this case, I used a very simple approach, where the voltage had to be on one side or the other of the threshold for a set number of readings in a row before acknowledging the change. This number of readings was configurable as well.

My First Microcontroller Prop

While I had previously dabbled in very basic light up props before, they were fairly basic: a pile of LEDs hand wired to a battery, resistor and switch with no actual logic or controller involved. My first prop to actually employ a microcontroller was built for my player character in the Cottington campaigns. The character, Johan, is in short a mad scientist with a bent for dreaming and the mind, and he has a variety of devices for measuring and influencing brain waves. The initial design concept was to actually make a simple but interactive representation of one of these devices, that would actually have a quick ‘synchronize with the recipients brain waves’ phase.

Final Device

A quick demonstration of the device

The eventual device was housed in a simple wooden box, small enough to be easy to carry around, but large enough to easily contain the electronic components. It has a gauge display with a rotating needle, four LED lights, two dials to adjust, and a switch to turn the device on and off.

One LED is simply to designate if the device is in the operational state, a second is used during the ‘synchronization’ phase. The final two are used for feedback during the ‘operational’ phase, one turning on for ‘high’ values displayed by the gauge, the other turning on for ‘low’ values displayed by the gauge.

On turning on the device enters a synchronization state, the two knobs must be adjusted (to randomly determined values), with feedback provided in terms of the rate of blinking on the yellow ‘sync’ light. Once achieved, it switches to ‘operational’ state.

The operational state is a slowly shifting gauge (all randomly driven), where passing certain thresholds turn on the red and blue leds.


Here are the internals, paired with a view of my very sloppy wiring. The bottom left from this view is an Arduino Uno, which is the microcontroller that drives everything. The actual chip itself is fairly small, but the Uno board also provides power regulation (as I’ve learned in later projects, juggling battery voltages to the right levels for various components can be difficult, using the build in power regulation on an Uno is definitely simpler for learning), and the board provides a much more convenient USB connection for uploading code to the microcontroller, as well as providing easier to use headers for connecting wires to the system (as opposed to having to solder directly to a microchip). The Arduino can be programmed using a pared down subset of the C++, code uploaded via USB. There are a number of ‘pins’ as they are referred to, for connecting wires to. Certain pins can be simply used as digital inputs or outputs (there either is a signal, or is not), others can be used as analog inputs or outputs(the signal may have a strength, in this case voltage). There are some more advanced facets, where there are certain protocols which certain pins are required for. In this simpler device, I made use of two analog inputs (for the dials), one analog output (for the dial gauge), and four digital outputs (for the LEDs).

The top left is a tangle of wires, with a resistor hidden under liquid electrical tape that the various LED’s are wired to.

Example of a servo

The center of device houses a servo. While servos can be used to mean a few different things, in this case (and the most common use of the term), this refers to what is essentially an electrical motor that can turn through a limited range of motion, and you can control what position it is at by means of adjusting an analog input to the system. I will briefly note that these analog outputs from the Arduino to a Servo are not actually truly analog, and are in fact what is called ‘Pulse Width Modulation,’ basically switching between off and on very quickly where how much of the time it is on versus off being the actually varying value. But for simplicity’s sake, they can be thought of as analog outputs in this case. If you provide minimal voltage, the servo will move to one extreme, let us say clockwise. If you provide the maximum voltage, it will rotate to it’s other extreme in the counter-clockwise direction. Servos require three connections, a connection to positive voltage and ground to supply power in addition to the analog(PWM) input which is used to drive their position. While it is possible with a single small servo such as this to directly power it from the Arduino board itself, in general it is preferable to connect servos to other power sources, since the power regulator on an Arduino can only supply a limited amount of current.

Above the battery to the left, you can see the backs of the dials. The dials are actually potentiometers. Potentiometers are an implementation of what is known as a voltage divider. By arranging a circuit such that the current crosses one resistor, then has two routes to ground, one directly to ground, the other to ground but through a second resistor, then the voltage along the path that leads directly to ground will actually not be the full voltage that was applied to the beginning of the circuit. Instead, it will be that voltage time a ratio of the two resistance values. A potentiometer is a voltage divider, with one of the resistors being a variable resistor whose resistance is controlled by the knob. They have three connections, and by connecting the first to positive voltage, the last to ground, and the central connection to ground by way of an analog input connection (in this case, in the Arduino), you can then read the voltage of that final connection, and control and change said value by adjusting the knob.

Above the battery and to the left, there is a small black box, this is the backside of a push button switch for turning the device on and off.

Beneath the battery, the four black splotches with wires running to them are the four LEDs. LED’s are fairly simple to wire, they do have a direction to them. Typically, they will have one longer ‘leg’ which will be the side to which the positive voltage is applied. Due to LED’s having a maximum current they can withstand, you should generally have a resistor in series with a LED to limit the current.

Putting It All Together

The parts for this particular project were fairly simple. The microcontroller to serve as the ‘brains’ of the prop, two very simple inputs that are only used during the first phase, outputs are four LEDs which are simply on or off and a single analog(PWM) signal to control a servo.

The code for the Arduino and the wiring was thoroughly tested and developed before any attempt was made to build it into an actual prop. Taking the baby steps of using a Serial output system for debugging (basically, allowing the Arduino to print text to the computer while connected), I could make certain the potentiometers worked correctly and gave me the value range I was expecting, and similar basic testing.

The devil is always in the details, coming up with how to determine the blink timing for synchronization required quite a bit of iteration to find an approach that felt right, and it was basically a case of keep trying different approaches and testing.

There was some similar testing and revisions in adjusting the random patterns for the gauge needle positioning.

But, once all the testing was done with temporary wiring, all that was left was permanently affixing pieces to the actual prop housing, and making the wiring permanent.

Inaugural Post: On Wireless Prop Networking

First off, welcome to the initial post of these musings. The intent behind this site is to have someplace better suited than typical social media for rambling about current crafting projects, discussing lessons learned in various projects, possibly posting instructions or the like. For this first post, I intend to discuss what I’ve learned in my first forays into developing electrical prop driven puzzles for a campaign boffer LARP, specifically regarding the networking aspect of the design. How the pieces communicate, how and where the state information resides.

The Initial Project

I had been working with some electrically driven props for a character I play in Cottington. Nothing very complicated, but it did have some basic concept of being in different states, and requiring some user input. A very basic system necessitating the user to ‘synchronize’ a device to start with by adjusting dials, and providing feedback so that the user would be able to recognize their progress on that synchronization. I realized that I wanted to push further and make more interactive and solvable puzzles, something more involved than I could justify as a prop for a player character. It was at this point that I talked with the staff I had been a core NPC for at Madrigal, and soon wound up being, perhaps foolishly, given carte blanche to develop an entire mod. Given the original impetus, a key design goal was to, in effect, have an electronic prop driven escape room style encounter as a mod.

It was from this that the Steps of Sobek mod was born. One of the concepts that drove it was the idea of splitting the players into two groups, and requiring coordination between the groups. This in turn drove a need to be able to have the props communicate wirelessly, in order to enable that design goal.


With wireless communication deemed a requirement, one of my first steps was to do a cursory investigation of what wireless communication options were available. At that point in time, all of my experience had been with the actual Arduino ecosystem, using Arduino Uno and Megas. There were three principle options I investigated to begin with. Generic 433mhz RF transmitter and receiver modules, the nrf24l01 wireless transceiver modules, and the esp8266-01 wi-fi module.

  • Generic 433 mhz RF Modules
    • Pros: Individual modules are cheap.
    • Cons: Required two separate modules to both transmit and receive. Required construction of antenna with finicky specific length requirements to optimize range. No channels or the like, only one unit can transmit at a time or signals will be scrambled.
  • nrf24l01
    • Pros: Radio Transceiver, requires only a single module and no need for an access point. Can handle moderate number of channels at once.
    • Cons: Transceiver is potentially limited to only receive or only transmit at any point in time, juggling timing of messages around this while doable would be involved. Antenna for improved range available but somewhat bulky. Number of channels potentially limited to six, which may prove inadequate.
  • esp8266-01
    • Pros: Wi-Fi meant personal experience with network coding could be taken advantage of. With external access point(potentially battery powered router), effectively limitless number of props could be networked. Makes integration of a laptop very easy.
    • Cons: Theoretically higher power draw, since I was working off of batteries. Requires external access point to truly provide limitless prop count(the esp8266-01 can serve as a limited access point for roughly 6 connections, in theory).

The generic 433mhz RF systems would be a huge increase in effort with only a savings in cost to offset it. The nrf24l01 was a reasonable choice, but the flexibility and power of having a full actual network stack by going with wi-fi won out in the end.

In the process of actually developing the props, the ESP32s development boards cropped up as additional tools to use. They combine the wi-fi capabilities of the esp8266-01 with being a full microcontroller with similar capabilities(in fact, far more memory and processing speed) than the Arduino Uno or Mega.

There were some minor tribulations in moving to ESP32s development from Arduino development. There are a number of different ways to actually program the ESP32s, one which is directly based on the Arduino ecosystem, and others which are not. Since I had already developed some libraries within the Arduino style framework, I went with the Arduino style ESP32s programming approach. The fact that the ESP32s space is split between different entire architectures at the software layer, paired with the fact that the ESP32s was not intentionally built as a hobbyist platform in the same way the Arduino family was, leads to a situation where there are a lot of conflicting guides and approaches, and a lot more potential hang-ups when first learning the platform. For anyone interested in learning these things, I feel like starting with Arduino and then moving on is probably a better approach, so as to get the basics understood before having to grapple with the complications and rough edges that get added in when working with the ESP32s.

That said, the increased memory, far faster connection to the network time, ease in not needing to wire in a secondary processor module for every prop(and thus less connections or wires to potentially have hardware failure with at runtime) have lead me to the decision that, moving forward, I intend to use the ESP32s development boards by default. I may look into the esp8266 variants other than the 01, which are less powerful than the ESP32s, but can be used as stand alone modules in a similar fashion as an alternative.

Finite State Machines And Where The State And Logic Live

The implementation of the puzzle state was handled by implementing logic in each prop following your fairly standard finite state machine approach. The one key thing to mention in terms of design which I realized afterwards could use improvement was the fact that each individual prop was it’s own finite state machine, with its own state.

There proved to be two big flaws with the state machines living in the props. First, as part of the development process, I had a very simply console style application for viewing output and providing simple input to the system, and I was able to develop a tool for sending messages to potentially fix or address issues during a live use of the system. The problem was that if a specific prop had significant and complicated state information to convey, it would require a network protocol to send the entire state to the prop in order to ‘reset’ or clear an error during runtime. Second, it is much more difficult to reflash a new program to a prop during an event, with the tools available on site. While this did not directly come up, supporting different mods with different puzzles or logic behind them would be, not impossible, but very awkward if the logic and state data was maintained in the props themselves.

By redesigning the props to be entirely focused around networking, simply taking network inputs to perform actions/provide feedback to players and providing network output for any input from the players, we could make the props reusable in different puzzle configurations without needing to reflash and update the props themselves during an event. And since the props would not be responsible for puzzle logic and state information, any external tools for overriding systems would work without limitations. This does impose the requirement that an external piece would provide all puzzle state tracking and the logic for adjudicating the mechanics, in the form of an application or similar on a laptop. However, since such a tool will likely be wanted for some degree of overrides no matter what, this really is not a significant imposition and will be a net benefit long term.

When reusing the light board and pressure pads from the Steps of Sobek mod for a Crooked House/Red Door mod, I began to implement some of these design changes, and it definitely simplified things during the debugging and development phases, though I still wound up with a very small bit of state information in the light board which I should have avoided. The puzzle mechanics were essentially a Simon game, and the playing of the pattern as an example was managed by the light board. I definitely should have gone to a system where the laptop simply instructed the light board as to what lights to turn on or off, but the network protocol implementation I was working with had some message size limitations which discouraged going all the way with that approach.

Network Protocol

The Arduino build system does provide the capability to develop libraries, and I developed a number of fairly simple ones for the props. In particular, a general network protocol was developed and a library implementation was thrown together so that it could rapidly be reused to develop the different props.

The wi-fi modules did have a networking limitation in that they could only support a limited number of TCP sockets at a time. A low enough number that I decided to employ a broadcast UDP approach with a self implemented message received ‘ack’ response protocol to deal with the non-guaranteed delivery of UDP packets. This also avoided the difficulties in not necessarily knowing the IP addresses that would be assigned to each specific prop, or the connected laptop application. There are actually two different versions of this library, one that works with the Arduinos communicating via separate esp8266-01 modules, and a second for use on the ESP32s development boards. The protocol is the same, but the libraries to access the network differ enough that separate libraries were somewhat easier to manage.

Given the desire to move to a system where all props simply connect to a single control application on a laptop, with the state and puzzle logic living in the application, this means that the TCP socket limitation will no longer actually be an impediment. I have begun the work on a new networking library, as well as computer side server code, to follow this new pattern. By using TCP sockets it will no longer be necessary to rely on responses to verify messages were heard, and I’ll make certain to have a message format with more size flexibility than the previous approach (which was principally limited since memory on an Arduino is very tight, and if you need to have a queue of sent messages so you can track if you’ve received acknowledgement of receipt from the destination, the messages cannot be long).

For reference in case anyone is interested, I have uploaded both the Arduino and the ESP32 versions of the networking libraries.