Send Secret Messages from 500m Away with Packet Radios

The Idea

Reliance on certain wireless networks/protocols can add significant costs to a project, as well as limit how far away they can be. WiFi and Bluetooth both use the 2.4GHz band, which limits them to around 50-60 meters from an access point. This can be detrimental if all you want is to send a simple message between two points. Additionally, other protocols don't have builtin encryption standards, which can leave messages prone to snooping.

This device fixes these problems. By using the RFM69 radio module, messages can be sent up to 500 meters away while also being encrypted with an AES-128 cypher.

Hardware

The hardware required to build this project is quite simple and consists of three primary components: an Adafruit Feather M0 with RFM69 Packet Radio, a 128 by 64 pixel OLED display, and an analog joystick. From these items, a pair of identical devices can be created and used to pass messages back and forth. The entire thing fits on a single mini breadboard and could be easily adapted to a PCB format instead.

Wiring and Setup

The OLED screen connects to the Feather's I2C bus on pins D20 (SDA) and D21 (SCL), which makes it simple to add. The joystick's two axes are attached to the analog 0 and analog 1 pins for the X and Y axes respectively. It reads in a value between 0 and its analog resolution and converts it to a number between -1 and 1. Finally, there are three momentary push-button switches connected to digital pins 5, 6, and 9, and they control functions such as drawing, pairing, and sending a message.

The Adafruit Feather board doesn't have a PCB antenna, so you have to solder one onto a pin at the back. Since EM frequency correlates with the length of the antenna, you'll need to solder on a 7.8cm length of wire for the 915MHz variant.

Software Overview

The software that I wrote goes through several steps when powered on and then enters into a while loop that continuously checks for several things and performs their corresponding actions. There are three distinct classes that handle this: the RadioComms class, the InputManager class, and the Display class. Using encapsulation greatly simplifies and cleans up the development process, rather than using one monolithic ino file.

Connecting

When a device first boots up, it doesn't know its own address or which other address it needs to connect to. This is done to simplify the programming and allow for more than two to potentially work together in the future. There's an onboard button that selects between a sender that broadcasts packets and a receiver that accepts potential connections. To begin, both devices assign themselves a random ID between 0 and 50, which makes the probability they will be the same at ~2%. Those are small enough odds, so the code doesn't have a way to reassign the ID if two match, although it could be changed. The sender then goes and sends a test packet to each ID until it gets a response, thus making the receiver bind with the packet sender's ID and the sender binds with the response packet sender's ID. With both of them saved, they're ready to start sharing messages.

Sending and Receiving Messages

After the program has entered the main loop, it continually checks for new, incoming messages and input from the joystick. Messages are encoded in a two-dimensional array using bit packing (because the display is either black or white), which makes the size of the message 1/8 the size. If there is a new message available, the program takes the message and places it into a buffer within a struct, where it is then displayed.

In the other way around, pressing the send button will cause the current screen buffer to be copied over into a packet. Next, the packet gets sent to the destination address for it to be disseminated and shown.

The Display

For the display I went with DFRobot's 128 by 64 OLED screen. It is simple to use and has the SSD1306 driver, which makes it compatible with the Adafruit SSD1306 and Adafruit GFX libraries. The Display class contains an OLED object and controls it by displaying certain screens (defined in an enum) and showing messages.

Future Improvements

This system is not perfect. I would like to add the ability to support multiple connections simultaneously, with a list of potential senders and receivers.