LoRa and Low-Power Mesh Hardware Track
External, accessory, fixed-relay, and future integrated radio options for Agent Mesh.
LoRa and Low-Power Mesh Hardware Track
Goal
Prove infrastructure-independent Agent Mesh communication without coupling the product model to one radio chipset or requiring an unlicensed internal phone redesign during early development.
Hardware stages
Stage 1 — external compatibility node
Use a documented Meshtastic-compatible device connected by BLE or USB. This proves envelope mapping, identity, receipts, emergency UX, routing policy and field testing before native radio work.
Stage 2 — Agent OS accessory
Prototype a USB-C or case-mounted module with:
- SX1262-class sub-GHz radio;
- low-power controller such as nRF52/ESP32-class silicon selected by measured power and documentation;
- region-selectable certified front-end and antenna variants;
- hardware timestamping and wake signal;
- optional GNSS and emergency button;
- signed firmware, recoverable update and serial provenance;
- isolated power domain so the application processor may sleep or shut down.
Stage 3 — fixed relay and gateway
Create solar, roof, vehicle and indoor nodes. Fixed nodes may bridge raw LoRa, local IP, Internet, satellite or LoRaWAN providers while treating Agent Mesh payloads as opaque encrypted bundles.
Stage 4 — future integrated device
An ODM/JDM device may integrate the radio only after antenna, coexistence, thermal, battery, firmware, certification and supply-chain gates pass. No current milestone assumes this integration exists.
Device-service boundary
The radio provider exposes packet send/receive, channel profile, link metrics, wake, duty-cycle budget, timestamp and diagnostics. It does not expose arbitrary registers or allow applications to select illegal frequency, power or airtime settings.
Bulk payloads remain outside LoRa. The provider accepts bounded envelopes or fragments and reports exact airtime, retry and power costs.
Power model
- the low-power controller may retain queued work while the main SoC sleeps;
- wake the main SoC only for policy, user interaction, key access or payload processing that cannot remain isolated;
- measure idle, receive, transmit, scan, BLE bridge and relay duty;
- enforce per-project and emergency energy budgets;
- expose battery impact before enabling continuous relay mode.
Candidate configurations
| Role | Initial configuration | Purpose |
|---|---|---|
| Compatibility | Meshtastic-certified/documented node | Fast protocol and UX evidence |
| Phone accessory | MCU + SX1262 over USB-C/BLE | Native Agent Mesh provider prototype |
| Fixed relay | Weatherproof MCU + radio + solar/battery | Store-and-forward field network |
| Gateway | Radio + Ethernet/Wi-Fi/satellite uplink | Optional infrastructure bridge |
| Integrated future device | Separate low-power connectivity island | Always-available mesh without waking main SoC |
Evidence programme
Field tests cover dense urban streets, reinforced-concrete indoor paths, suburban movement, open rural terrain, moving vehicles, body obstruction, antenna orientation, interference and region-compliant settings. Record hardware revision, antenna, enclosure, firmware, frequency plan, power, airtime, weather, route, delivery ratio and battery consumption.
Stop conditions
Stop or change configuration when certification scope is unclear, antenna performance requires unsafe transmit settings, firmware provenance is unavailable, the controller cannot be recovered, relay power is incompatible with the product budget, or a radio provider requires ambient system authority.