Event Management and Crowd Safety Large Event Communications with Mesh Networks Large Event Communications with Mesh Networks Managing communications across a sprawling outdoor event - a music festival, marathon, county fair, or major sporting event - has traditionally meant either expensive commercial radio rental packages or reliance on cellular networks that buckle under crowd-generated load. LoRa mesh networking offers event organisers a self-contained, scalable communications infrastructure that can be deployed, operated, and torn down entirely by in-house staff. Important reliability note: LoRa mesh is a best-effort, low-bandwidth, text-and-telemetry coordination layer with no guaranteed message delivery. It is a supplement to - not a replacement for - dedicated event safety communications, public-safety radio, or 911. Do not rely on it as the sole channel for medical, security, or evacuation traffic. The Scale Problem Events covering 15 to 50 acres typically require coordinated communications between dozens of staff roles: stage managers, security personnel, medical teams, parking attendants, vendor coordinators, and the central operations tent. Commercial radio costs vary widely by what is included: a bare two-way radio rental commonly runs on the order of $10-40 per radio per day, while full managed packages that bundle programming, frequency coordination, on-site support, and repeater rental cost substantially more (sometimes several hundred dollars per radio per day for a fully coordinated, staffed deployment). Confirm current figures against a vendor quote for your event. A comparable mesh deployment covering the same venue can be built for roughly $1,500-3,000 in hardware (illustrative - depends on node count and board choice; e.g. a Heltec WiFi LoRa 32 V3 is about $18-20 direct, plus antennas, enclosures, power, and mounting) that the event organisation owns outright and amortises across many events. Typical Deployment Architecture A 15-node mesh for an event of around 5,000 people might be laid out as follows: Infrastructure nodes (5-6 nodes): Mounted on light poles, temporary scaffold masts, or the roof of the main stage structure. These nodes provide the backbone coverage layer and are configured with external antennas (3-6 dBi gain omnidirectional). Note that transmit power is capped by hardware and regulation: the SX1262 radio used in common boards tops out near +22 dBm conducted, and total radiated power (transmit power plus antenna gain) must comply with FCC Part 15.247 in the 902-928 MHz band - higher-gain antennas require corresponding power reductions, so you cannot simply add gain and power without limit. Each backbone node is powered from AC mains via a weatherproof enclosure with a battery backup to survive generator cycling. Operations tent node (1 node): Connected to a laptop running the Meshtastic web client or a dedicated display showing the network map and recent messages. This serves as the command-and-control hub. Mobile nodes (8-9 nodes): Carried by key staff (security supervisor, medical team lead, stage manager, parking coordinator, etc.). Standard handheld Meshtastic devices with the default 2.5 dBi antenna can perform well where they have reasonable line-of-sight to a backbone node; coverage depends on line-of-sight and antenna height rather than being uniform across the venue, so expect weaker spots behind large structures or in low areas. Position Tracking for Staff and Security GPS-enabled Meshtastic nodes broadcast position reports at configurable intervals (typically every 30-120 seconds for a moving staff member). The operations tent display shows a live map of all staff positions, enabling resource dispatch. If a medical situation occurs in the southeast corner of the venue, the operations coordinator can see roughly which medical team member is nearest and direct them via text message over the mesh. Because position updates lag by 30-120 seconds and mesh message delivery is best-effort, treat this as an aid, not the primary medical-dispatch channel: confirm any time-critical dispatch by voice on a dependable radio channel and use the mesh as a supplement. Integration with Venue Maps Some Meshtastic client apps can display staff positions against custom base maps (for example, georeferenced site plans exported from tools like QGIS). Support varies by client, and loading custom venue base maps may require offline-tile setup or a third-party integration (such as an ATAK/MeshtasticTAK bridge) rather than being a built-in Meshtastic feature - verify what your chosen client supports before relying on it. This is particularly useful for events held in venues with complex layouts - multi-stage festival grounds, fairgrounds with dozens of vendor areas, or racecourses with non-obvious access paths. Deployment Logistics A well-organised team of two people can deploy a 15-node infrastructure mesh in 3-4 hours on the morning before an event. Key logistics considerations include: Pre-event configuration: All nodes should be pre-configured and tested in the shop before arrival on-site. Channel settings, node names, and firmware versions should all be verified. A checklist for each node prevents configuration errors under time pressure. Repeater placement: Infrastructure nodes should be sited with line-of-sight to as much of the venue as possible. Walking the venue with a test node and recording RSSI values at key locations before finalising mast positions will prevent coverage surprises. Power planning: All infrastructure nodes need power. AC runs or portable battery packs should be planned before event day. Runtime varies widely with transmit duty and configuration; a 20,000 mAh pack typically powers an infrastructure node for a day or more, but budget from measured current draw for your specific board rather than assuming a flat figure. Teardown: Label every node and cable clearly. Post-event teardown should follow a documented node-by-node checklist to ensure all equipment is recovered. GPS tracking on infrastructure nodes provides a recovery safety net. Illustrative Scenario: ~5,000-Person Outdoor Event The following is a hypothetical, illustrative scenario rather than a documented deployment. A 15-node Meshtastic mesh might be deployed across a roughly 22-acre venue for a two-day event, with infrastructure nodes mounted on a few light poles and a temporary mast near the main stage. Over such an event the mesh could plausibly carry on the order of a thousand short staff text messages. Real-world reliability depends on node placement, congestion, and terrain - mesh delivery is best-effort and outages or dropped messages can occur, so any "zero outages" expectation should not be assumed. As a rough cost comparison (illustrative; verify against current quotes), the hardware for such a build might run on the order of $1,800, versus a fully managed commercial radio rental package for the same staff complement that could cost considerably more per day - exact figures depend on the vendor and package and should be confirmed by quote. Crowd Monitoring and Safety Applications Crowd Monitoring and Safety Applications Beyond staff communications, LoRa mesh infrastructure deployed at events can support a crowd safety function - carrying low-bandwidth, periodic density counts and text alerts (not real-time movement tracking) to give incident command a degree of near-real-time situational awareness. Bear in mind that LoRa is very low-bandwidth (effectively sub-kbps on long-range presets) and best-effort, with no delivery guarantee: it cannot carry continuous real-time crowd-movement data, and any safety use must treat it as a supplementary layer, not a dependable life-safety system. These capabilities are particularly relevant for large events where crowd crush is a genuine risk, or for venues where incident command needs additional visibility into conditions across a large area. Crowd Density Monitoring via Proxy Sensors Direct counting of individual people is both technically complex and raises significant privacy concerns. One alternative is to use passive WiFi and Bluetooth probe request counting as a rough proxy for crowd density. Note that the accuracy of this technique is substantially degraded by MAC randomisation on modern phones: peer-reviewed work confirms that randomisation defeats simple MAC counting, so probe-request counts are a relative proxy at best, not an absolute headcount, and they are not suitable as a sole crowd-crush safeguard. Smartphones periodically broadcast probe requests when not associated to a network; rates vary and MAC addresses are randomised on modern devices (since iOS 8 and Android 8+), and probe-request rates are reduced when the screen is off or the device is already connected to WiFi. These requests are detectable by a WiFi-capable device in passive monitoring mode, but they are sporadic and randomised, yielding only a noisy proxy. A sensor node - typically a small single-board computer like a Raspberry Pi Zero 2W paired with a LoRa radio module - can count probe requests in a defined time window and transmit the count (not any identifying information) over the mesh to the operations centre. Correlating these counts with known venue capacity for each zone gives event safety staff a relative density indicator - not a calibrated headcount - and it should not be used as the sole basis for crowd-safety decisions. Heavy calibration and validation are required before any such heatmap can be trusted, and it must be backed by direct observation by trained staff. Important caveats: probe request counting provides relative density rather than absolute headcounts, and iOS and Android devices vary in probe request behaviour due to MAC randomisation policies - which on modern phones makes the technique a rough relative proxy only. Calibrating the system during setup by counting known groups provides a partial correction factor, but does not make probe counting a reliable absolute crowd-counting method. Evacuation Coordination In an emergency requiring full or partial venue evacuation, the mesh can provide an independent supplementary communications channel that does not rely on cellular and WiFi infrastructure - both of which will be saturated by thousands of people simultaneously trying to call, text, and post to social media. This independence is genuine, but the mesh is best-effort, very low-bandwidth, and offers no delivery guarantee or message priority: it must not replace the venue's primary life-safety communications. Incident command can use it to push evacuation instructions to staff as a text message and to monitor staff GPS positions, but bear in mind that Meshtastic broadcasts are best-effort with no guaranteed simultaneous delivery to all nodes: only direct messages get a per-recipient acknowledgement, and a broadcast at most yields a single node's acknowledgement. Confirming receipt from each zone leader therefore requires individual direct messages, which add airtime and latency on a congested low-bandwidth network and are not instantaneous. Do not rely on the mesh as the sole evacuation-alerting path: expect message latency and loss under the heavy channel load of an active incident, back it with PA, two-way radio, and on-the-ground zone leaders, and treat the absence of a receipt confirmation as possible non-delivery. Pre-event planning should include documented mesh-based evacuation protocols: which node operators are responsible for which zones, what messages signal different alert levels (shelter-in-place vs. full evacuation), and how to confirm all-clear. These protocols should be practised at least once before the event in a tabletop exercise. Lost Child and Patron Location Assistance GPS-enabled nodes worn or carried by children (or vulnerable patrons in need of escort services) can transmit their position over the mesh to a family reunification station. Bear in mind that mesh position updates are periodic and best-effort, not continuous real-time tracking, and are subject to coverage gaps; this is an aid, not a guaranteed tracker, and it does not replace staffed lost-child procedures. At a practical level, this is most useful as a check-in/check-out system at large family events: a wristband node given to a child at entry can be tracked to the family reunification tent if the child becomes separated. Note that wristband-form-factor Meshtastic nodes are not standard off-the-shelf hardware - this would be a custom build, with battery life, size, and a child-safe enclosure to solve - so staffed reunification procedures should remain the primary system. Medical Team Dispatch Medical teams at large events benefit from mesh communications in several ways beyond simple voice replacement. A text-based dispatch system over mesh allows the medical coordinator to send structured information (location grid reference, nature of complaint, resources needed) to the responding team - information that is easy to mishear over radio in a noisy festival environment. That said, medical dispatch is life-safety and time-critical: the mesh supplements, and must not replace, primary medical-dispatch comms. Primary medical dispatch should use a guaranteed or acknowledged channel (licensed two-way radio with a confirmation protocol); treat mesh as a redundant overlay and verify critical dispatches by voice, because a dropped or delayed message could delay care for a critical patient. The GPS position of the medical team can be monitored by dispatch to confirm arrival and to direct the nearest available team to new incidents. Privacy Considerations Event organisers deploying crowd monitoring systems should address privacy proactively: Aggregate data only: Density counts by zone, not individual tracking, should be the operational norm. Log files should contain zone counts, not device identifiers. Disclosure: If probe request counting is used, this should be disclosed in event terms and conditions and on signage at venue entrances. Many events already disclose security camera use; WiFi monitoring disclosure belongs in the same category. In some jurisdictions (for example under the EU GDPR, where probe data may be treated as personal data even when MAC addresses are randomised), such monitoring may trigger legal disclosure or consent obligations - consult counsel. Data retention: Density logs should be deleted after the event unless there is a specific safety or legal reason to retain them. Establish a data retention policy before deployment. Staff GPS tracking: Staff should be informed that their GPS position is visible to operations centre staff during the event. This is typically disclosed in staff onboarding materials. Integration with Incident Command Structure For permitted events with a formal incident command structure (often required by local permitting authorities for large events above a certain attendance threshold), the mesh communications system should be integrated into the ICS organisation chart. The communications unit leader should understand the mesh system capabilities and limitations, and the operations section should include mesh-based status reporting in its protocols. Pre-event coordination with local fire, EMS, and law enforcement should identify whether those agencies want read-only access to the mesh map or whether they prefer to operate on their own networks with liaison officer communications.