Purpose
The goal of this project is to tunnel LoRaWAN Class A traffic from devices over Meshtastic, allowing devices out of gateway range to reach a LoRaWAN Network Server (LNS) without changing the higher level of the device implementation. (For initial development, we assume use of using the Arduino LMIC.) To bridge traffic back to the LNS, a dedicated Meshtastic node forwards frames to a Linux process that emulates a gateway (Semtech UDP first; LoRa Basics Station later). We map LoRaWAN semantics (registration, OTAA/ABP, end‑to‑end security, and Class A ordering) onto Meshtastic transport without emulating the LoRa PHY at the LMIC
radio()layer. The LMIC high‑level API remains unchanged. We introduce new runtime regions likeCFG_Meshtastic_us915andCFG_Meshtastic_eu868whose constraints are defined by Meshtastic.
While Class A is our initial focus, Meshtastic’s always-on capability means Class C semantics can be supported with minimal complexity. The architecture is independent of the LoRaWAN MAC implementation; LMIC is our first target, but the design generalizes to other stacks.
flowchart LR
A["End Device (LoRaWAN MAC, e.g., LMIC)"] -- "LoRaWAN PHYPayload over Meshtastic" --> B["Meshtastic Node (dedicated, no relay)"]
B -- "USB/Serial" --> C["Linux Bridge"]
C -- "TTS (Semtech UDP / Basics Station)" --> D["LoRaWAN LNS (TTN/TTS)"]
D -- "Downlink (soft RX timing)" --> C
C -- "Meshtastic downlink" --> B
B --> A
- Preferred LNS: The Things Stack (TTN/TTS) for TTN compatibility; ChirpStack is fine for local testing.
- Transport limits: Meshtastic
Data.payloadmax 233 bytes; LoRaWAN FRMPayload ≤ 220 bytes (no FOpts) so total PHYPayload ≤ 233 bytes. - Timing: Use soft RX windows (e.g., RX1 delay 5–10 s) rather than strict LoRa PHY 1 s/2 s.
- ADR: Disabled for Meshtastic regions.
- Overview:
docs/lwom-overview.md - Implementation:
docs/lwom-implementation.md - Conversation summary:
docs/conversation_summary.md - Knowledge summary:
docs/project_knowledge_summary.md
Strict PHY-level emulation at the LMIC radio() interface produced timing constraints that are brittle and offer little value relative to the LoRaWAN system model we want (secure join, end-to-end encryption, Class A semantics). Meshtastic’s transport limits (not the LoRa PHY) now define our runtime region behavior, including payload cap and soft RX timing.
- Meshtastic payload/structure:
Data.payload233 B — seemesh.optionsand message architecture docs. - TTN/TTS US915 payload sizing and RX parameter controls.
- TTS gateway connectivity: Semtech UDP (legacy) and Basics Station (recommended).