I’ve been working on a new round of Sentinel development, and it brings together a lot of the things I enjoy building: small computers, radios, sensors, drones and software that can still do something useful when there is no internet connection.

The part I care about most is keeping the edge open. By “edge,” I mean the little box out in the field: the hardware reading a sensor, receiving a result from a camera system, or sending a report back over the radio. I want people to be able to understand that box, change it and build something useful with it.

A thread that goes back to ResQ

If you’ve followed my projects for a while, you may remember ResQ, my open-source search-and-rescue project. I started that work in 2018, exploring what small, inexpensive electronics could contribute to finding people in places with poor cellular coverage.

That question has stayed with me. How do we get a useful observation out of the field and into the hands of someone who can act on it? How do we make the equipment accessible enough that another builder can try an idea, improve it and share what they learned?

Sentinel is another step along that path. It can be a ground sensor or part of an airborne payload. The aim is to bring observations, location and radio communication together in a form a person can actually review.

Let the Pi do the looking

The new piece I’m particularly excited about is companion observations. A Raspberry Pi or another companion computer runs your camera and recognition software. When it sees something worth reporting, it passes a small result to Sentinel: what it thinks it saw, its confidence, a count and information about the observation’s age.

Think of a classifier reporting possible smoke or fire. The Pi sends the result through Sentinel’s USB connection. Sentinel can then add the position it already has from MAVLink telemetry and send a compact Sentinel report over the LoRa mesh. At the other end, XTOC can bring that report into the operator’s view.

The camera images stay on the companion computer. Keeping the radio message small gives us a practical way to share an observation over a low-bandwidth link. Your own software decides what to look for; the interface gives it a way to report the result.

A map point has to mean something

I want the report to be honest about what the hardware knows. If Sentinel has a usable recent GPS fix, it can include it. If the fix is old, the report marks it as stale. If there is no usable telemetry, it sends the observation with NO GPS.

There is another important detail here: those coordinates belong to the observing sensor. A camera seeing smoke in the distance does not magically give us the fire’s exact position. That distinction matters if someone is deciding where to send a team.

For search and rescue, I see this as a way to give people another clue to check. A camera observation, a motion cue or a radio detection still needs context and human review. A detection doesn’t establish that we’ve found a missing person, and silence from a node doesn’t establish that an area is clear.

Open firmware, familiar parts

Sentinel’s firmware and examples are available in the public Sentinel project, with its GPLv2 licence. The documented hardware uses familiar ESP32 and LoRa parts, including the XIAO ESP32-S3 and Wio-SX1262 combination.

I want someone to be able to follow the data from the input to the packet. You can inspect the code, adapt the companion sender to your own classifier and work out how it fits your project. You don’t need my particular camera setup to start experimenting.

The open-source part I’m talking about here is Sentinel at the edge. XTOC is the operator application in this workflow, and XPASS provides optional curated trigger and plugin templates. They are separate from the open Sentinel firmware.

Those templates let an operator choose which reports deserve attention: fire, smoke, a custom label, or an observation that needs a location check. The rules start disabled so you can choose the source, confidence and GPS conditions that make sense for your setup.

On the ground, or carried with you

Wraith is one carrier I’m developing around, but the observation interface is useful beyond an aircraft. A stationary node could report from a remote site. A portable setup could move with a team. The same basic idea applies: do the sensing locally and send the useful information back.

The aircraft work also includes MAVLink telemetry and a separate paired LoRa path for supervised mission actions. That flight-control path is a direct link rather than a multi-hop command mesh. The autopilot handles the flying; this low-rate link is for supervision and telemetry, with separate pilot and video links.

For me, the next useful work is trying these pieces in realistic conditions: poor links, changing light, interrupted telemetry and the false positives that come with real cameras. That is how we learn whether a report is useful to the person receiving it. I’m developing tools to support that work, and practical SAR use needs evaluation with the people who would rely on them.

Build on it

If you have an idea for a field sensor or a companion classifier, have a look at the Sentinel code and hardware notes. The Training Hub has the setup guides and field manuals; enter your email once to open the guide library.

I’d love to see what other people build around this. Useful feedback includes the things that didn’t work: the missed observation, the bad location, the radio report that never arrived. Those are the details that help make the next version better.

Small, understandable tools that people can build on—and that might help a team get better information when it matters. That’s why I’m keeping at it.