Games with IR comms

Introduction

A few years ago I set up a geocache¹ where the coordinates of the container were flashed in Morse Code by infra-red LEDs hidden in a bird-box. To receive the signal, people had to construct a detector from a kit of parts provided in an earlier stage of the puzzle.

Belatedly, here are a few notes on the hardware.

The basic idea

In essence the idea is simple: flash an infra-red LED so that it sends a message in Morse code.² Given that most people can’t see infra-red, some sort of detector will be needed, and this was something that the person doing the geocache would have to build. I thought it would be more fun if the detector made a noise rather than just flashed a light. To keep the detector as simple as possible, the tone is generated in the transmitter and broadcast in the IR signal.

By generating all the signals in the transmitter, the detector could be as simple as a photodiode AC-coupled to an amplifier driving a pair of headphones. It might be nice to have some sort of sensitivity or volume adjustment too.

As is probably obvious, the emitter will be a microcontroller of some sort driving a few IR LEDs.

Basic timings

All the timings in Morse Code transmissions are multiples of the time taken to send a dit, which is about 50ms for a reasonably fast operator. So, sending A (which is .- in Morse code) looks like this:

Morse is often transmitted at 800Hz, and if we adopt this convention each dit will be 40 tone cycles long:

Extra Modulation

Although this plan seemed straightforward, I was worried about the sun. Any photographer knows just how much visible light there is outside, and black-bodies being what they are, the same is presumably true of infra-red too. It seemed quite plausible to me that the sun’s IR would swamp the signal from my transmitter. Even if it didn’t, the detector might have to extract a small AC signal (from my transmitter) from a large DC offset (from the sun).

To complicate matters, I wasn’t confident that I could set up a representative test, and I did my early outdoor experiments in autumn where the sun wasn’t as bright as it would be in summer.

Set against these concerns is the well known result that infra-red remote controllers work well even in very sunny rooms, despite having small batteries which last for ages. Part of the explanation for this is that remote controls modulate their control signals, typically at a frequency of 30–50kHz. A detector can look for this signal and be relatively immune to the sun and other sources of noise. As you might expect people make inexpensive sensors which contain an IR-photodiode plus a filter and amplifier with automatic-gain-control (AGC). Besides making life easier for us, I suspect it’s easier to make a stable high-gain amplified when it’s so close to the sensor.

For example Vishay make the TSOP13xxx series³. To fully specify the part you need to specify both the carrier frequency and the algorithm used for the AGC. If you you think about it you’ll realise that the optimal AGC algorithm must depend on the signal being sent.

40kHz seemed a good choice because it’s a multiple of the 800Hz tone frequency, and an exact divisor of common CPU clocks e.g. 8MHz. In particular, we can fit exactly 25 40kHz cycles into the on time of the 800Hz tone.

Detector Design

Most of the complexity disappears inside the Vishay detector: accordingly very few technical design decisions need to be made once we’ve decided to use it. The digital output from the detector merely needs to be amplified to drive headphones. A volume control seems civilized, and I think there’s merit in a bit of low-pass filtering too so the listener hears a purer tone that a raucous square-wave.

Desiderata

The detector will be built by people who might have very little experience of building electronics, and the key objectives are:

• to end up with a working detector;
• to have fun;
• to feel a sense of accomplishment.

Thus it seemed sensible that:

• different components should look significantly different;
• the design should be simple;
• the design shouldn’t be too simple.

Finally, something I did not worry about: I doubted I’d need more than a hundred detectors, so cost wasn’t really an issue.

My original plan was to force people to solder up the detector, but on balance that seemed too daunting. So I designed both the permanent PCB-based board, and a simpler design which could be built on a breadboard. Both detectors do basically the same job, though the breadboard version is a bit simpler.

The detectors are discussed in more detail in separate articles:

PCB-based detector 4

Breadboard-based detector 5

Emitter Design

I needed a couple of different emitters for the puzzle.

One design was for field deployment hidden inside a birdbox hidden in the middle of nowhere. The main constraint here was that it needs to run reliably for at least a year on one set of batteries. I only wanted a handful of these, so again cost didn’t matter.

The other emitter was a test transmitter included with the detector kits. In the end, adding a daughter board to the a Blue Pill⁶ STM32 board was easier and cheaper than spinning my own STM32 board.

The two emitters are discussed in more detail in separate articles:

Emitter for birdbox 7

Bluepill-based detector 8

Design Files

All the design files can be downloaded from GitHub⁹. The electronics was designed KiCad, the firmware is written in C and uses libopencm3¹⁰. Random bits of Haskell and python were used too.

Conclusions

Although I’m sure the designs aren’t optimal, they work. Novices have built the detectors, and the emitters have worked reliably.

Written by Martin Oldfield on 26 Jan 2022.
Contact: Martin Oldfield, ex-atelier@mjoldfield.com
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.