OpenHop Repeater: Build Dedicated LoRa Mesh Infrastructure with Python, SX1262, and MeshCore

TL;DR: OpenHop Repeater is a modular, open-source Python daemon that turns Linux single-board computers, virtual machines, or Proxmox LXC containers into high-performance, dedicated LoRa repeater infrastructure for the MeshCore mesh protocol. Operating with direct SPI SX1262 radios, CH341 USB-to-SPI bridges, or networked modems, OpenHop Repeater features a real-time web dashboard, a granular policy engine with in-flight packet decryption, multi-radio LoRa backhaul bridging, virtual Room Server BBS nodes, a TCP Companion frame server, CAD calibration, and an isolated out-of-process plugin supervisor.

Many off-grid mesh projects start with an ad-hoc philosophy: every pocket device acts as an autonomous relay node. While simple to deploy, uncontrolled broadcast flood-routing quickly degrades in dense areas. When dozens of handheld nodes retransmit every incoming packet over shared sub-GHz spectrum, channel utilization spikes, packets collide, and battery life vanishes.

The MeshCore ecosystem takes a different approach by separating high-elevation, dedicated repeater infrastructure from mobile client nodes. OpenHop Repeater (formerly known as pyMC_Repeater) is the reference daemon designed to manage this infrastructure on Linux hardware.

Built on the openhop_core Python library, OpenHop Repeater provides a complete control plane for LoRa repeater operations. It moves packet handling, policy enforcement, sensor telemetry, and remote administration off resource-constrained microcontrollers and onto reliable Linux platforms like Raspberry Pi, Luckfox, Orange Pi, and Proxmox LXC containers.

What Is OpenHop Repeater?

OpenHop Repeater is an open-source, lightweight Python daemon that runs on Linux single-board computers, virtual machines, and Proxmox LXC containers to route LoRa packets and manage dedicated repeater infrastructure for the MeshCore mesh protocol.

The project originated as pyMC_Repeater built on pyMC_core. As the ecosystem expanded, the codebase was unified and rebranded under the openHop umbrella (openhop-dev on GitHub). It provides a modular, hackable architecture that integrates with physical radios, environmental sensors, network backbones, and external monitoring platforms.

+-------------------------------------------------------------------------------+
|                       OPENHOP REPEATER ARCHITECTURE                           |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ LoRa RF Hardware Backends ]                                                |
|  * Native Linux SPI SX1262 (Raspberry Pi BCM GPIO)                            |
|  * CH341 USB-to-SPI Bridge (SX1262 on PC / Proxmox)                           |
|  * openHop Modem over TCP / Ethernet (EtherMesh-1W)                           |
|  * openHop Modem over USB-CDC (High-speed 921600 baud)                        |
|  * KISS Serial TNC Modems                                                     |
|                                                                               |
|                               | (Raw Packets)                                 |
|                               v                                               |
|  [ OpenHop Repeater Core Daemon (Python / openhop_core) ]                      |
|  +-------------------------------------------------------------------------+  |
|  | * Packet Router: Dedupe, Loop Detect (Path Hashes), Multi-ACK Wrapper  |  |
|  | * Policy Engine: Rule Evaluation, Hop Limits, In-Flight PSK Decrypt     |  |
|  | * FabricRadio: Dual-Radio Cross-Band LoRa Backhaul Bridging             |  |
|  | * Virtual Nodes: Primary Repeater + Virtual Room Servers (Mesh BBS)     |  |
|  | * Companion Gateway: TCP Frame Server (Ports 5000/5001 for Apps & Bots) |  |
|  | * CAD Engine: Automated Channel Activity Detection Threshold Sweeps     |  |
|  | * Telemetry & GPS: BME280, INA219, UPS HATs, CAP_SYS_TIME Clock Sync    |  |
|  +-------------------------------------------------------------------------+  |
|                               |                                               |
|       +-----------------------+-----------------------+                       |
|       |                       |                       |                       |
|       v                       v                       v                       |
|  [ Persistence ]       [ Telemetry / Net ]      [ Management & UI ]           |
|  * SQLite DB           * MQTT (MC2MQTT)         * CherryPy Web UI (Port 8000) |
|  * RRDTool Metrics     * pyMC_Glass Fleet       * Supervised Plugin Manager   |
|  * Event Journals      * WAEV / LetsMesh        * Real-time SSE / WebSockets  |
|                                                                               |
+-------------------------------------------------------------------------------+

Core Architecture and Packet Routing Engine

At the core of OpenHop Repeater is a disciplined routing engine built on openhop_core.protocol and openhop_core.node. Rather than blindly retransmitting every overheard signal, the daemon applies deterministic forwarding rules designed to protect channel airtime.

+-------------------------------------------------------------------------------+
|                       OPENHOP REPEATER ROUTING ENGINE                         |
+-------------------------------------------------------------------------------+
|                                                                               |
|  Incoming LoRa Frame (SPI / CH341 / Modem TCP / Modem USB / KISS)             |
|         |                                                                     |
|         v                                                                     |
|  [ 1. Duplicate Packet Cache Check (Configurable TTL) ]                       |
|         |                                                                     |
|         v                                                                     |
|  [ 2. Loop Detection & Path Hash Inspection (off / min / mod / strict) ]     |
|         |                                                                     |
|         v                                                                     |
|  [ 3. Max Flood Hops Check (max_flood_hops: 64) ]                             |
|         |                                                                     |
|         v                                                                     |
|  [ 4. Policy Engine Evaluation (Rules, PSK Decryption, ACLs) ]                |
|         |                                                                     |
|         +---> MATCH DROP ---> Drop & Log Reason (DropReason Enum)             |
|         |                                                                     |
|         v                                                                     |
|  [ 5. Duty Cycle Enforcement & Airtime Multiplier Calculation ]               |
|         |                                                                     |
|         v                                                                     |
|  [ 6. Multi-Ack Wrapper Generation (multi.acks MULTIPART) ]                  |
|         |                                                                     |
|         v                                                                     |
|  [ 7. FabricRadio Interface Selection (Default / Sticky / Bridge) ]           |
|         |                                                                     |
|         v                                                                     |
|  Outgoing Transmission with Randomized Backoff Delay                          |
+-------------------------------------------------------------------------------+

1. Loop Detection and Path Hashes

To prevent routing loops in multi-hop topologies, MeshCore frames encode per-hop path hashes. OpenHop Repeater inspects these hashes on incoming flood packets. Operators can configure loop detection across four distinct modes:

• off: Loop detection disabled.
• minimal: Allows up to 3 self-hashes before dropping.
• moderate: Allows up to 1 self-hash before dropping.
• strict: Rejects packets containing any matching self-hash.

The path hash width is configurable to 1-byte, 2-byte, or 3-byte modes, matching network conventions.

2. Multi-Ack Redundancy

Packet loss is common on weak sub-GHz paths. OpenHop Repeater implements MeshCore’s multi.acks specification. When enabled, a relayed routed acknowledgment (ACK) is preceded by a MULTIPART-wrapped copy. This delivers redundancy across noisy paths without initiating full broadcast floods.

3. Score-Based Adaptive Transmission Delays

The daemon calculates packet transmission delays using dynamic airtime multipliers (tx_delay_factor and direct_tx_delay_factor). The actual delay before transmission is randomized across a window of [0, 5 * packet_airtime * factor] seconds. This minimizes packet collisions when multiple repeaters overhear the same originating transmission simultaneously.

4. Duty Cycle Enforcement

For regulatory compliance in jurisdictions with strict sub-GHz airtime restrictions (such as Europe’s 868 MHz band), OpenHop Repeater includes built-in duty cycle tracking. If configured, the daemon caps maximum airtime per minute (e.g. 3,600 ms/min) and drops non-essential packets when limits are exceeded.

Multi-Radio Fabric: Cross-Band LoRa Backhaul

One fundamental limitation of conventional single-radio repeaters is half-duplex contention: a repeater cannot receive while transmitting, and heavy local messaging congests long-distance relay paths.

OpenHop Repeater addresses this with FabricRadio, an architecture that allows a single daemon to control multiple physical LoRa transceivers simultaneously.

+-------------------------------------------------------------------------------+
|                       FABRICRADIO MULTI-BAND BRIDGING                         |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ Local Client Mesh ]                                                        |
|  * 869.618 MHz | SF8 | 14 dBm                                                 |
|  * Handhelds, mobile nodes, portable companions                               |
|         |                                                                     |
|         v                                                                     |
|  +-------------------------------------------------------------------------+  |
|  |  Radio 1: Local Access (SX1262 SPI)                                     |  |
|  +-------------------------------------------------------------------------+  |
|         |                                                                     |
|         v                                                                     |
|  [ Fabric Engine: Bridge Mode ] <=== Cross-Band Packet Translation ===>       |
|         |                                                                     |
|         v                                                                     |
|  +-------------------------------------------------------------------------+  |
|  |  Radio 2: Inter-Repeater Backhaul (SX1262 CH341 USB, 30 dBm E22)        |  |
|  +-------------------------------------------------------------------------+  |
|         |                                                                     |
|         v                                                                     |
|  [ Long-Distance Mountain Link ]                                              |
|  * 864.200 MHz | SF11 | 30 dBm (1 Watt)                                       |
|  * Distant hilltops, inter-city backbone repeaters                             |
|                                                                               |
+-------------------------------------------------------------------------------+

FabricRadio Transmission Modes

• default Mode: Always transmits on the designated default radio interface.
• sticky Mode: Dynamically transmits on the specific radio interface that last received traffic from that node.
• bridge Mode: Cross-band transceiver operation. Packets received on the local access channel are automatically repeated on the long-distance backhaul link, and backhaul packets are relayed to local users.

This dual-frequency approach lets operators run fast, low-spreading-factor settings (e.g. 869.618 MHz, SF8) for local handhelds, while maintaining a slow, high-power link (e.g. 864.200 MHz, SF11 at 1 Watt) for linking mountain repeaters tens of kilometres away.

The Policy Engine: Granular Packet Inspection and Decryption

OpenHop Repeater includes a standalone Policy Engine that evaluates incoming frames against top-down rules defined in policy.yaml or managed via the web interface.

Unlike simple blacklists that only check node IDs, the Policy Engine inspects transport codes, hop counts, payload formats, and encrypted channel contents.

# Example: Drop Channel packets that have traveled more than 2 hops
rules:
  - id: "drop-long-hop-group-chat"
    name: "Limit Public Channel Hops"
    enabled: true
    if:
      all:
        - field: "payload_type"
          op: "equals"
          value: "GRP_TXT"
        - field: "path_hop_count"
          op: "greater_than"
          value: 2
    then:
      action: "drop"

# Example: Whitelist emergency channel and prioritize forwarding
rules:
  - id: "allow-emcomm-channel"
    name: "Prioritize Emcomm Traffic"
    enabled: true
    if:
      field: "channel_hash"
      op: "equals"
      value: "0xA4"
    then:
      action: "allow"

In-Flight Channel Decryption

A unique feature of OpenHop Repeater is its ability to inspect encrypted group text packets (PAYLOAD_TYPE_GRP_TXT). When channel pre-shared keys (PSKs) are supplied in the policy configuration, the daemon derives the channel hash, verifies the MAC, and decrypts the plaintext message body in memory.

This enables advanced filtering options:

• Match specific channel text patterns (e.g. dropping automated bot chatter).
• Filter on channel_sender names.
• Verify whether packets are cryptographically valid before relaying them.

Supported actions include allow, drop, and log_only (evaluating rules for auditing without dropping traffic).

Virtual Identities: Repeater, Room Servers, and Companion Frame Servers

A single OpenHop Repeater instance can host multiple logical entities on the mesh simultaneously:

+-------------------------------------------------------------------------------+
|                       OPENHOP REPEATER MULTI-IDENTITY                         |
+-------------------------------------------------------------------------------+
|                                                                               |
|  +---------------------------+  +--------------------------+                  |
|  |  PRIMARY REPEATER NODE    |  |  VIRTUAL ROOM SERVER     |                  |
|  |  - Node Type 2 (Repeater) |  |  - Node Type 3 (BBS)     |                  |
|  |  - Routing & Discovery    |  |  - Independent Keypair   |                  |
|  |  - Token Bucket Limits    |  |  - Guest/Admin Passwords |                  |
|  +---------------------------+  +--------------------------+                  |
|                                                                               |
|  +---------------------------------------------------------+                  |
|  |  COMPANION TCP FRAME SERVER                             |                  |
|  |  - MeshCore Frame Protocol over TCP (Ports 5000, 5001)  |                  |
|  |  - SQLite Message, Contact, and Channel Persistence     |                  |
|  |  - Connects MeshCore Mobile Apps, Web Consoles, & Bots  |                  |
|  +---------------------------------------------------------+                  |
+-------------------------------------------------------------------------------+

1. Primary Repeater Identity

The physical node identity that participates in routing, responds to zero-hop discovery queries, and broadcasts periodic node advertisements. It includes a token-bucket rate limiter and an exponential penalty box to protect the mesh against misconfigured nodes sending excessive discovery bursts.

2. Virtual Room Servers (Mesh BBS)

OpenHop Repeater can host one or more independent MeshCore Room Servers inside the daemon. Each room server operates with its own Ed25519 cryptographic keypair, independent flood advert schedules, and configurable admin/guest passwords. Users on the mesh can discover the room, log in, read bulletin boards, and leave messages directly on the repeater.

3. TCP Companion Frame Server

The daemon includes a built-in Companion Frame Server that implements the binary MeshCore frame protocol over TCP (e.g. ports 5000 and 5001).

This allows operators to connect external client software (such as the MeshCore Android/iOS app, the OpenHop Web Console, or automated bots) directly to the repeater over LAN or VPN without needing a separate Bluetooth or USB connection. The server includes SQLite persistence for queued messages, contacts, channel state, and battery/storage telemetry.

Supported Hardware Backends and Presets

OpenHop Repeater abstracts radio hardware through openhop_core, supporting multiple physical interfaces:

Turnkey Hardware Support

The daemon includes pre-configured presets for several commercial and maker platforms:

• ClockworkPi uConsole: Out-of-the-box support for the HackerGadgets SX1262 expansion card.
• Zindello Industries UltraPeater: Luckfox-based 1W high-power repeater.
• MeshSmith PiMesh-1W & EtherMesh-1W: High-power 30 dBm Raspberry Pi HAT and Ethernet-connected network modems.
• Frequency Labs meshadv & meshadv-mini: Dedicated Raspberry Pi LoRa repeater HATs.

CAD Calibration: Tuning Channel Activity Detection

In LoRa networks, Listen-Before-Talk (LBT) relies on Channel Activity Detection (CAD) to identify whether another station is actively transmitting on frequency before keying up.

Incorrect CAD thresholds cause two major failure modes:

1. Thresholds too low: Noise triggers false carrier detects, blocking the repeater from transmitting.
2. Thresholds too high: The repeater fails to hear faint signals on air, talking over weak distant nodes.

+-------------------------------------------------------------------------------+
|                       CAD CALIBRATION ENGINE & WEB TOOL                       |
+-------------------------------------------------------------------------------+
|                                                                               |
|  Spreading Factor : [ SF8 (Default: Peak 22, Min 10) ]                        |
|  Test Range       : Peak: 20 to 26  |  Min: 8 to 14                           |
|                                                                               |
|  CAD Test Matrix:                                                             |
|  Peak Threshold ->  20     21     22     23     24     25     26              |
|  ------------------------------------------------------------                 |
|  Min: 8          | [OK]   [OK]   [OPT]   [OK]   [FAIL] [FAIL] [FAIL]          |
|  Min: 10 (Std)   | [OK]   [OK]   [OPT]   [OK]   [OK]   [FAIL] [FAIL]          |
|  Min: 12         | [WARN] [OK]   [OK]    [OK]   [OK]   [OK]   [FAIL]          |
|                                                                               |
|  Result: Optimum calibrated operating point: Peak=22, Min=10                  |
+-------------------------------------------------------------------------------+

OpenHop Repeater includes a built-in CAD Calibration Engine and web UI tool. It runs automated sweeps across peak and minimum detection thresholds for any spreading factor (SF7 to SF12), benchmarking background RF noise to find the optimal operating point for your antenna and environment.

Sensors, Environmental Telemetry, and GPS Synchronization

OpenHop Repeater is built for remote mountain and solar-powered installations. It features a comprehensive sensor subsystem with automatic Python dependency installation.

Supported Sensors

• Environmental: Bosch BME280 (temperature, humidity, barometric pressure), ScioSense ENS210, Sensirion SHTC3.
• Power Monitoring: Texas Instruments INA219 (measures DC bus voltage, shunt current, and total power draw from solar panels).
• Battery & UPS HATs: Waveshare UPS HAT (D and E variants), LAFVIN UPS 3S.
• System Health: CPU load, RAM usage, storage capacity, internal board temperature, and network throughput.
• Remote Modem Telemetry: An openhop_modem sensor that queries remote TCP-connected modems over HTTP /api/stats to capture remote RF health and battery metrics.

GPS and Precision System Clock Sync

For repeaters operating off-grid without NTP or internet access, OpenHop Repeater can interface directly with serial GPS modules (e.g. /dev/serial0) or NMEA text streams.

Key GPS capabilities include:

• System Time Synchronization: Automatically synchronizes the host Linux system clock from GPS UTC timestamps using CAP_SYS_TIME.
• Location Advertising: Dynamically injects live GPS coordinates into outgoing mesh advertisement packets.
• Privacy and Obfuscation: Configurable coordinate precision rounding (location_precision_digits: 2) to obscure the exact physical location of sensitive repeater sites while providing regional positioning.

Data Acquisition: SQLite, RRDTool, and MQTT Backbones

Monitoring network performance is essential for maintaining large LoRa meshes. OpenHop Repeater provides a three-tier data acquisition architecture:

+-------------------------------------------------------------------------------+
|                       DATA ACQUISITION & TELEMETRY ARCHITECTURE               |
+-------------------------------------------------------------------------------+
|                                                                               |
|  [ 1. SQLite Database (repeater.db) ]                                         |
|     - Complete packet audit trail (SNR, RSSI, path hashes, payload types)     |
|     - Companion event journal, queued messages, and contact lists             |
|     - Automatic daily retention vacuuming (default: 31 days)                  |
|                                                                               |
|  [ 2. RRDTool Time-Series Engine ]                                            |
|     - Fixed-size circular buffer storage for historical performance graphs    |
|     - 1-minute resolution for 7 days                                          |
|     - 5-minute resolution for 30 days                                         |
|     - 1-hour resolution for 365 days                                          |
|                                                                               |
|  [ 3. Multi-Broker MQTT Client (MC2MQTT / LetsMesh / WAEV) ]                  |
|     - Publishes live telemetry, packet streams, and node status               |
|     - Automated zero-hop neighbor sweeps and scope discovery                  |
|     - pyMC_Glass fleet control-plane inform loop                              |
+-------------------------------------------------------------------------------+

Automated Neighbor Scope Sweeps

OpenHop Repeater can execute automated 24-hour neighbor discovery sweeps. The daemon broadcasts a zero-hop node discovery probe, queries visible zero-hop repeaters for their regional flood scopes sequentially to prevent packet collisions, and publishes the assembled topology map to MQTT brokers on the neighbors topic.

Supervised Plugin Architecture

Extending repeater functionality historically meant hacking monolithic codebases. OpenHop Repeater introduces a dedicated out-of-process Plugin Manager (openhop-plugin-manager.service).

Key Plugin Principles

• Out-of-Process Execution: Plugins run as independent OS processes with dedicated Python virtual environments (venv). A crashing plugin cannot bring down the core repeater.
• Curated Catalogue with Cryptographic Verification: Repeater connects to an R2-hosted plugin catalogue (https://repeater-plugins.openhop.dev/catalogue.json). Packages are fetched directly from GitHub Releases and verified against SHA-256 checksums before installation.
• Headless and UI Applications: Supports headless backend bridges (such as the openhop.nomad plugin connecting local LLM bots to the mesh) and web application plugins (such as openhop.console).

Step-by-Step Installation and Setup

OpenHop Repeater supports three primary installation methods depending on your infrastructure.

Method 1: Native Linux Installation (Raspberry Pi / Debian / Ubuntu)

1. Update package repositories and install Git:

   sudo apt update && sudo apt install git -y

2. Clone the official repository:

   git clone https://github.com/openhop-dev/openhop_repeater.git
   cd openhop_repeater

3. Run the interactive installer:

   sudo bash ./manage.sh install

   The script provisions a dedicated repeater service user, creates directory structures under /opt/openhop_repeater, /etc/openhop_repeater, and /var/log/openhop_repeater, sets up hardware permissions, and enables the systemd service.

4. Open your browser and complete the onboarding wizard:

   http://<your-device-ip>:8000

Method 2: One-Line Proxmox LXC Installation

For homelab and data center deployments, OpenHop Repeater can run inside a lightweight Debian 13 LXC container on Proxmox VE 8.x or 9.x:

# Execute on the Proxmox host shell:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/openhop-dev/openhop_repeater/main/scripts/proxmox-install.sh)"

The script creates an unprivileged or privileged container with USB passthrough, pre-configures udev rules for CH341 USB-to-SPI adapters, clones the repository, and provisions the service automatically.

Method 3: Docker Compose

For containerized environments, create a docker-compose.yml file:

services:
  openhop-repeater:
    image: openhop/openhop-repeater:main
    container_name: openhop-repeater
    restart: unless-stopped
    ports:
      - "8000:8000"
      - "5000:5000"
    devices:
      - /dev/spidev0.0:/dev/spidev0.0
      - /dev/gpiochip0:/dev/gpiochip0
    cap_add:
      - SYS_RAWIO
    group_add:
      - "20"   # dialout GID
      - "986"  # gpio GID
      - "989"  # spi GID
      - plugdev
    volumes:
      - openhop-repeater-config:/etc/openhop_repeater
      - openhop-repeater-data:/var/lib/openhop_repeater

volumes:
  openhop-repeater-config:
  openhop-repeater-data:

Launch the container:

docker compose up -d

Comparison Matrix: OpenHop Repeater vs. Other Mesh Platforms

Why OpenHop Repeater Matters for Amateur Radio and Emcomm

OpenHop Repeater bridges the gap between maker microcontrollers and professional communication infrastructure.

In emergency communications (Emcomm) and amateur radio field deployments:

1. Infrastructure Stability: Running on Linux gives operators proper process supervision, automated backups, remote SSH maintenance, and robust system logging.
2. Channel Discipline: Granular policy rules prevent runaway chat storms and low-priority traffic from swamping critical frequency bands.
3. Flexible Interoperability: Whether connecting via high-power SPI HATs, USB adapters on a laptop, or networked Ethernet modems atop a tower, the daemon presents a unified API and web interface.
4. Local Autonomy: With local SQLite storage, virtual Room Server BBS nodes, and offline GPS clock synchronization, the system maintains complete operational independence when internet backhauls fail.

Frequently Asked Questions (FAQ)

What is OpenHop Repeater?

OpenHop Repeater is an open-source Python daemon built on openhop_core that manages dedicated LoRa repeater infrastructure, packet routing, web dashboards, and telemetry for the MeshCore mesh protocol on Linux systems.

Can I run OpenHop Repeater without a Raspberry Pi?

Yes. OpenHop Repeater runs on x86 servers, laptops, and Proxmox LXC containers using a low-cost CH341 USB-to-SPI bridge connected to an SX1262 LoRa module, or via TCP modems over your local network.

How does FabricRadio multi-radio bridging work?

FabricRadio allows the daemon to control multiple transceivers simultaneously, enabling cross-band operation where local client traffic on one frequency and spreading factor is automatically bridged to a dedicated, high-power inter-repeater backhaul channel.

What is the purpose of the CAD Calibration tool?

The CAD Calibration engine tests Channel Activity Detection threshold curves across spreading factors to optimize Listen-Before-Talk performance, preventing false channel-busy triggers while ensuring weak incoming packets are detected.

Does OpenHop Repeater require internet access to function?

No. OpenHop Repeater operates fully off-grid. It logs packets to local SQLite databases, generates RRDTool metrics, hosts local Room Server bulletin boards, and synchronizes system time directly from serial GPS receivers without internet.

Summary: Building Robust Mesh Infrastructure

The evolution from pyMC_Repeater to OpenHop Repeater reflects a maturing off-grid mesh ecosystem. By treating repeaters as dedicated, highly configurable Linux infrastructure rather than simple microcontroller relays, OpenHop Repeater provides the stability, control, and multi-radio capabilities needed for resilient community and emergency communications.

73 from 9M2PJU.

Sources and Further Reading

• OpenHop Repeater GitHub Repository – Source code, issues, and releases.
• OpenHop Repeater Official Documentation – Hardware setup, configuration, and API guides.
• OpenHop Core Library – Python implementation of the MeshCore protocol stack.
• MeshCore Official Community Portal – MeshCore protocol specifications and community Discord.
• MeshSmith Hardware – PiMesh-1W and EtherMesh-1W LoRa repeater hardware.
• Zindello Industries UltraPeater – Luckfox-based high-power LoRa repeater systems.
• HackerGadgets uConsole LoRa Module – ClockworkPi uConsole expansion hardware.
• HamRadio.my Amateur Radio Portal – Amateur radio news, open-source firmware, and off-grid guides.
• 9M2PJU About & Open Source Projects – Malaysian amateur radio station and open-source project catalog.