Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature request] Optional BLE repeater observer transport with bounded queues

Open
  • Is something wrong?
#3,640 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, github
Domain
embedded-iot

Research direction

Read the proposed implementation at https://github.com/throny/meshcore-ble-observer and its source/provenance tooling, then review MeshCore's CONTRIBUTING guidance for the maintainer discussion. The request leaves API boundaries and PR split undecided, and validation is incomplete across long duration, RF, energy, recovery, security and other hardware. Done means maintainer agreement on scope and boundaries before a feature PR.

Written by the indexing model from the issue text.

Description

Problem

A repeater observer normally needs a permanent USB connection to forward the
repeater's own packet observations to a host. A nearby Companion observes its
own RF reception, not the repeater's internal observations. An opt-in BLE export
would support installations where a permanent USB data cable is impractical.

Proposed approach

  • Default-off repeater observer feature selected through a separate custom build
    target; no automatic replacement or update of stock firmware.
  • Physical enrollment, bonded/encrypted BLE, one pinned observer peer and explicit
    revocation. No automatic or open enrollment after reboot.
  • Bounded packet/log callbacks, record queues and fragmentation with session and
    sequence identifiers, complete-record ACKs and explicit loss counters.
  • ACK means host RAM reassembly, not MQTT delivery; no lossless/durable replay
    claim. RF forwarding must remain the primary responsibility.
  • Shared protocol/queue primitives, with an initial nRF52/SenseCAP Solar P1-Pro
    binding. Other boards need reviewed transport bindings and actual validation;
    no generic cross-board compatibility claim.

An experimental implementation, source/provenance tooling and independently
maintained optional meshcoretomqtt BLE adapter are at:
https://github.com/throny/meshcore-ble-observer

Validation and limits

The current implementation cleanly replays against official repeater-v1.18.0.
Hosted CI builds the custom image and runs native/exact-source tests. Initial
P1-Pro/Linux-host checks exercised identity-preserving application updates,
bonded BLE packet reception, parsing and MQTT connections. Long-duration,
matched RF, energy, recovery and full interruption/security acceptance remain
incomplete; other hardware is unvalidated. This is not an official release or
an unattended/solar-readiness claim.

Following CONTRIBUTING, this issue seeks maintainer agreement before a large
feature PR. Would you consider this as a default-off repeater capability, and
what API boundaries/PR split would you prefer before a port to dev?

Dominant language
C
Stars
3.9k
Forks
1.5k
Avg merge
1d 3h
Merged PRs (30d)
24

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from meshcore-dev/MeshCore

All issues in meshcore-dev/MeshCore

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.