MeshCore repeaters are often installed in places that are difficult to access—on rooftops, towers, or other elevated structures. While these locations are ideal for coverage, they introduce a major challenge: maintenance.

Updating firmware or recovering from failures becomes complicated when physical access is limited or impossible.

The Problem

In normal situations, you can update a device over Bluetooth using OTA (Over-The-Air) updates. However, this requires being within range of the device. More importantly, if the repeater crashes or becomes unresponsive, you cannot perform a hard reset remotely.

For installations in hard-to-reach locations, this is a serious limitation. What’s needed is a way to:

  • Access the device remotely
  • Recover it when it becomes unresponsive
  • Perform maintenance without physical intervention

The Idea: Out-of-Band Management

To solve this, I’m exploring an out-of-band control system—a secondary system that remains accessible even if the main repeater fails.

The concept is to pair the MeshCore node (based on the nRF52840) with a small Linux-based system like a Raspberry Pi Zero. While alternatives like ESP32 or other microcontrollers are possible, Linux provides a huge advantage: many tools (networking, SSH, update mechanisms) are already available out of the box.

The downside? A Raspberry Pi consumes significantly more power, which is a concern when running on batteries such as 18650 cells.

A Power-Efficient Approach

To balance power consumption and functionality, the Raspberry Pi should remain powered off most of the time and only turn on when needed.

This is where the nRF52840 comes in.

The idea is to use one of its GPIO pins to send a periodic watchdog signal. An external low-power circuit listens for this signal:

As long as the signal is present → everything is healthy If the signal stops → something is wrong

When the watchdog no longer detects the signal, it powers on the Raspberry Pi.

What Happens Next?

Once powered, the Raspberry Pi can:

  • Perform a health check on the repeater
  • Check for firmware updates
  • Attempt recovery actions
  • Provide remote access via SSH for manual intervention

For update checks, I’m considering a lightweight approach using DNS queries. By storing version information in DNS records, the system can quickly check for updates with minimal data usage—ideal for low-bandwidth or metered connections.

Firmware Features Needed

To support this system, the MeshCore firmware would need two additional features:

  1. Watchdog Signal Output
    A periodic signal sent via GPIO to indicate the system is alive.
  2. Maintenance Mode
    A way to intentionally stop the watchdog signal, forcing the Raspberry Pi to power on for maintenance.

The Next Step: Hardware Design

The next challenge is designing the physical system. Key questions include:

  • What watchdog or supervisory components should be used?
  • How do we reliably detect the absence of the watchdog signal?
  • What is the best way to switch power to the Raspberry Pi?
  • How can we keep overall power consumption as low as possible?

This project is essentially about bringing remote management capabilities—similar to those used in large-scale infrastructure—to small, battery-powered mesh nodes.

It’s still a work in progress, but the goal is clear:

👉 Make remote nodes recoverable, maintainable, and reliable, even in the most inaccessible locations.