Technical Architecture Specification: Hybrid Event Network & Store-and-Trigger Protocol

1. Architectural Conceptualization: The “Archipelago” Model

In the high-stakes environment of large-scale event production, traditional monolithic networks frequently fail when stretched across massive, 1000-acre discontiguous sites. The “Archipelago” model replaces the fragile “single network” philosophy with a decentralized strategy, treating separated event clusters as autonomous “Mesh Islands.” This approach ensures that local production environments remain fully operational for coordination and execution even if the primary backhaul to the cloud is severed. By isolating critical local traffic from wider network instabilities, we establish a robust foundation for high-reliability event engineering.

The efficacy of this model relies on a dual-layer communication strategy that separates local mesh resilience from global synchronization via a cloud bridge.

Operation Layer	Technology	Primary Function	Dependency
Intra-Island (Local Mesh)	LoRa (Meshtastic)	Local staff comms, GPS, and device triggers.	None (Works without internet)
Inter-Island (Cloud Bridge)	MQTT via Master Gateway	Synchronizing cues between discontiguous locations.	Cloud/Internet connection

This decentralized architecture significantly mitigates the risks associated with intermittent cloud connectivity. While an internet outage may temporarily disable inter-site synchronization, the Local Mesh continues to handle internal staff communication and local cue triggers without interruption. This isolation of failure domains ensures that a localized technical issue cannot paralyze the entire 1000-acre production, providing a stable environment for the deployment of specific hardware components.

2. Hardware Ecosystem: The “Adafruit Universe” Selection

The strategic hardware selection focuses on bridging the gap between low-bandwidth control signaling and high-bandwidth media playback. By utilizing modular components from the Adafruit and Raspberry Pi ecosystems, we create a scalable stack capable of handling both mission-critical triggers and complex media output. This modularity allows us to deploy specialized hardware profiles that are purpose-built for their specific roles within the production environment.

Primary Hardware Profiles

• The Gateway (The Island Hub)
  • Core Computer: Raspberry Pi 4 or 5 (Selected for robust USB and high-speed network handling).
  • Radio Interface: Adafruit LoRa Radio Bonnet (RFM95W).
  • Functional Role: Serves as the central bridge for each “Island,” running the meshtasticd daemon to relay local LoRa traffic to the cloud-based MQTT broker.
• Mobile Nodes (Staff & Performers)
  • Core Computer: Adafruit Feather nRF52840 Express (Highly energy-efficient and natively supported).
  • Radio Interface: Adafruit LoRa Radio Wing.
  • Functional Role: Wearable units for stage managers and roaming tech staff, powered by Lithium Ion Polymer batteries (1200mAh+).
• Media Triggers (Prop & Scenery Nodes)
  • Core Computer: Raspberry Pi Zero 2 W.
  • Radio Interface: Adafruit LoRa Radio Bonnet (RFM95W).
  • Functional Role: Discrete units embedded in scenery that monitor the mesh for specific text strings to execute local media playback.

A significant technical advantage of the Adafruit LoRa Radio Bonnet (RFM95W) is its native GPIO integration. Unlike standard USB dongles, which introduce latency and mechanical fragility, the Bonnet stacks directly onto the Raspberry Pi 4, 5, or Zero 2 W headers. This direct hardware link ensures a more stable communication interface, which is critical when managing signal propagation across expansive terrain.

3. Network Design & Signal Strategy

Operating LoRa at 915MHz (US) or 868MHz (EU) within a 1000-acre event space requires precise management of signal physics. While LoRa’s sub-GHz frequency penetrates obstacles like dense foliage and temporary structures far better than Wi-Fi, signal verticality is the primary determinant of success. To maximize the line of sight and coverage density, Gateway Pi antennas must be positioned at a minimum height of 10 feet, effectively clearing ground-level interference and human traffic.

In particularly dense environments—such as 50+ acres of woods—we employ a “Router Node” strategy to maintain mesh integrity. These standalone relay nodes, consisting of an Adafruit Feather and a solar panel, are deployed in elevated positions between Mesh Islands. Meshtastic automatically utilizes these nodes to repeat signals, extending the mesh’s reach and eliminating dead zones.

The technical foundation of this specification is the absolute decoupling of the network’s logical layers:

• Control Plane (Meshtastic/LoRa): Dedicated to “The Signal”—low-bandwidth data including text cues, GPS telemetry, and synchronization pulses.
• Media Plane (Raspberry Pi Local Storage): Dedicated to “The Content”—high-bandwidth audio and video files stored locally on each device.

By separating the trigger from the media content, the network remains agile and responsive. This hardware-software decoupling necessitates a rigorous synchronization protocol to ensure that commands traveling over the Control Plane translate into perfect execution on the Media Plane.

4. The “Store and Trigger” Synchronization Protocol

The “Store and Trigger” workflow is engineered to bypass the bandwidth limitations of LoRa while achieving millisecond-accurate synchronization. Because LoRa cannot stream media, the protocol treats the network as a signaling path for commands, rather than a delivery path for content. This approach ensures that high-definition audio and video can be triggered across vast distances without the latency or packet loss inherent in wireless streaming.

Protocol Phases

1. Pre-Load: All media assets (audio/video) are manually staged on the local SD cards of every Raspberry Pi station prior to the event. This eliminates real-time network load during the show.
2. The Trigger: A Stage Manager broadcasts a specific text string (e.g., EXECUTE_SCENE_04) to a designated Mesh channel.
3. The Action: While staff see the text on their mobile nodes for coordination, the Prop Pis (Media Triggers) run a background daemon that monitors the mesh. Upon parsing the correct string, the listener script fires a local command to play the media through HDMI or audio outputs instantly.

To ensure mission-critical cues are prioritized, we configure a dedicated MEDIA_CUES channel. Unlike standard staff communication, this channel utilizes “High Reliability” settings—prioritizing lower transmission speeds and higher error correction levels. This configuration ensures that even in an electromagnetically “noisy” environment, the signal reaches its destination. This transition from theoretical protocol to physical execution is managed through a specific deployment and configuration workflow.

5. Deployment & Configuration Manual

The MQTT Broker serves as the “Central Post Office” for the Archipelago model, acting as the essential glue that binds disparate Mesh Islands. By using the broker to relay cross-island triggers that LoRa cannot physically reach, we create a unified production network from isolated clusters.

Technical Configuration Steps

1. MQTT Broker Setup: Deploy a cloud-based Mosquitto broker (AWS or a dedicated static-IP Pi). Establish a hierarchical topic structure (e.g., meshtastic/location_A/cues) to organize data flow between islands.
2. Gateway Pi Configuration: Install the meshtasticd Linux native daemon. In config.yaml, enable the MQTT module and set the device to “Client Proxy” mode, allowing the Pi to use its internet connection to bridge local mesh traffic to the global cloud broker.
3. Feather (Node) Flash & Config: Flash the nRF52840 Feathers with the specific Meshtastic firmware for that board. Match the LoRa region to the Gateway. Critically, the MEDIA_CUES channel must be configured as a secondary channel to ensure administrative traffic remains on the primary channel without interference.

The performance of the “Prop Pi” (Media Trigger) is the most critical element of the deployment. By using a local Python daemon to listen for mesh strings, we achieve a deterministic execution environment. Unlike network-triggered events that are subject to non-deterministic latency and jitter, local script execution ensures that once a cue is received, the media fires with consistent, repeatable timing. This rigorous configuration leads directly to the final materials and procurement requirements.

6. Materials & Procurement Specification

The Archipelago hardware stack provides a superior cost-to-value ratio by leveraging off-the-shelf components for complex wide-area engineering. This approach offers significantly higher flexibility and resilience than expensive, proprietary industrial wireless solutions.

Bill of Materials

Role	Device	Adafruit Part Ref	Estimated Cost
Gateway Hub	Raspberry Pi 4 + Case	#4295	~$55
Prop Pi (Media)	Raspberry Pi Zero 2 W	N/A (per source)	~$15
Radio (Pi/Zero)	RFM95W LoRa Bonnet	#4074	~$30
Staff Node	Feather nRF52840 Express	#4062	~$25
Radio Wing	LoRa Radio Wing	#3231	~$20
Mobile Power	LiPo Battery (1200mAh+)	N/A (per source)	~$10
Antenna	900Mhz Antenna (uFL)	#4269	~$5

In summary, the Archipelago model represents the most robust solution for modern, large-scale event engineering. By respecting the bandwidth constraints of LoRa for signal propagation while utilizing the local processing power of the Raspberry Pi for media delivery, we create a network that is nearly impossible to crash. This hybrid approach ensures that even in the event of a total cloud failure, the local islands remain synchronized and the production continues without interruption.