Skip to content

ADR 0009: MeshCore Protocol & COTS Pilot Hardware Selection

Date: 2026-05-19
Status: ACCEPTED
Supersedes (in part): ADR 0007 — MVP Topology & Protocol Selection (replaces Meshtastic with MeshCore), ADR 0008 — COTS-First MVP Strategy (resolves Member COTS candidate and positioning open items).
Related Correspondence: Grinn Global Engineering Proposal (Igor Rutkowski, 2026-05-18).

Context

Following ADR 0008, the project shifted to a COTS-first MVP strategy to validate the tower-less mobile mesh concept. Two critical open items remained: 1. Selecting the COTS Member hardware candidate and verifying its power/protocol feasibility. 2. Deciding between Path A (On-Device GNSS) and Path B (Mesh-Relative ToF/RSSI Triangulation).

Furthermore, while the previous Strategic Brief referenced Meshtastic as the open-source mesh protocol benchmark, Grinn's engineering review raised serious legal and architectural concerns regarding its GPLv3 license (which forces copyleft open-sourcing of commercial product code) and its limited hop capability (3–7 hops).

Decisions

To address these constraints for the Phase 1 Foundation Pilot, we adopt the following hardware, firmware, and protocol stack:

  1. Protocol Selection: MeshCore (via ZephCore)

    • Permissive Licensing: Adopt MeshCore instead of Meshtastic. MeshCore is licensed under the permissive MIT License, allowing us to compile and link proprietary business logic (such as FluxRig components and behavioral plugins) without exposing source code.
    • Zephyr Integration: Implement MeshCore via its native Zephyr RTOS port, ZephCore. This preserves our core OS choice of Zephyr RTOS, allowing event-driven WFI (Wait For Interrupt) low-power sleep, CAD-based RX duty cycling, and Kconfig/Devicetree unified drivers.
    • Deep Hops: Leverage MeshCore's support for up to 64 hops (compared to Meshtastic's 3–7) to overcome body-shadowing attenuation across extensive pastures.
    • Topology Alignment: Use MeshCore's role-based routing (Clients vs. Repeaters). Standard Member tags will run in Client mode (no forwarding, minimizing power consumption), while Cowbell Leaders will act as Repeaters.

  2. Positioning Strategy: Path A (On-Device GNSS)

    • Standardize on Path A (On-Device GNSS) for the primary pilot. Mesh-relative triangulation is deferred due to the high risk of RF instability (antenna detuning, multi-path fading) in extensive fields.
    • GNSS Hardware: Use the Quectel LC76G module paired with an AVX 9002137 antenna.
    • Variant Tiers:
      • Variant A (Leader Gateway): LoRa (RAK3172) + GNSS (Quectel LC76G) + NTN Backhaul (Murata/Quectel).
      • Variant B (Standard Member Tag): LoRa (RAK3172) + GNSS (Quectel LC76G).
      • Variant C (Low-Cost Fallback): LoRa only (no GNSS), relying on proximity to Leaders for location grouping if GNSS budget scales poorly.

  3. Member & Power Hardware Simplifications

    • MCU + Radio: Standardize on the RAK3172 module (STM32WLE5 SoC, CPU and LoRa integrated), optimizing both PCBA space and footprint cost.
    • Fuel Gauge Omission: Skip the dedicated battery fuel gauge IC for the Phase 1 pilot batch. State of Charge (SoC) will be approximated via simple voltage division to save costs and reduce layout complexity.

  4. Validation Phase Deployment Scale

    • Scale down the initial validation batch from 5,000 devices to a ~100-device pilot (mix of Variants A, B, and C). This batch size is sufficient to validate LoRa mesh convergence, solar-harvesting power budgets, and physical enclosure seals in the field prior to capital-intensive runs.

MeshCore under Mobility (Moving Cows Analysis)

Applying MeshCore to a mobile herd of grazing cattle presents specific RF and algorithmic challenges that must be mitigated by software configuration:

1. The Route Stale-out Challenge (Dynamic Topology)

  • The Issue: MeshCore is designed for static infrastructure (fixed repeaters) and mobile clients. In our setup, the repeaters (Leader collars) are also moving. As cattle graze and walk, the physical RF paths between Members and Leaders change constantly.
  • Flooding Risk: MeshCore uses a path cache. When a route is found, it directs subsequent packets along that specific path to reduce channel noise. In a dynamic herd, these cached routes will break frequently (often hourly or every few minutes). Every broken route triggers a discovery flood to rebuild the path. If multiple tags flood the network frequently, it will cause packet collisions (RF storms) and severely drain device batteries.

2. Algorithmic Mitigation: The Client-Only Member Tag

  • To protect the Member tags' battery life, standard tags (Variants B/C) will be configured strictly as Clients (Companions) with zero repeating enabled. They do not route or forward packets for other animals.
  • Only Leader Gateways (Variant A), which carry larger batteries and solar panels, will act as Repeaters.
  • This creates a hybrid Mobile Star (Cluster) topology: Members communicate directly (1-hop) with any available Leader in their physical vicinity. Because the Leaders move together as a cohesive group with the herd, their relative positions shift slowly, keeping the "backbone" network stable.

3. GNSS Time-Sync Critique (Power Budget)

  • Igor's proposal suggests synchronizing the sleep/wake windows of the devices using GNSS time. While technically precise, boot cycles for GNSS receivers (even hot-fixes of ~1–2 seconds) draw significant current (~15–25 mA).
  • Booting the GNSS module frequently just for clock synchronization is incompatible with the +3-year battery life target.
  • Mitigation: Wake/sleep synchronization must be driven by low-power local RF beaconing from the Leaders (which carry a constant time reference) during defined synchronization slots, rather than spinning up the GNSS receiver on the Member tags.

Consequences

  • Licensing Security: JAAB Tech retains complete commercial control over its proprietary firmware runtime (FluxRig) and behavioral analytics plugins.
  • BOM Cost Reduction: Standardizing on the RAK3172 and removing the fuel gauge chip helps offset the temporary unit cost penalty of using COTS hardware.
  • Firmware Portability: Running ZephCore under Zephyr RTOS ensures that firmware written for the COTS RAK3172 can be ported to custom silicon (e.g., nRF52/nRF91 series or custom ASICs) in later phases with minimal rewriting.
  • Operational Validation: The ~100-device pilot allows rapid loop iterations on the mechanical ear-tag enclosure, solar panel placement, and antenna matching under real field stress (body shadowing, weather, animal behavior).
  • Mesh-Storm Prevention: Restricting Member tags to Client mode prevents the dynamic topology of the moving herd from collapsing the RF channel under frequent discovery floods.
  • Clock-Sync Power Optimization: Relying on local RF beaconing for sleep/wake synchronization preserves the critical multi-year battery budget of the Member tags.