ARES and RACES Integration

• Integrating LoRa Mesh with ARES/RACES
• ICS/NIMS Terminology for Mesh Operators
• Go Kit Building for Mesh Nodes

Integrating LoRa Mesh with ARES/RACES

Overview

The Amateur Radio Emergency Service (ARES) and the Radio Amateur Civil Emergency Service (RACES) are the two primary organized frameworks through which licensed amateur radio operators support public safety and emergency management in the United States. LoRa mesh networks built on the Meshtastic platform are not a replacement for these established systems, but a powerful digital complement that fills capability gaps that voice HF and VHF radio alone cannot address.

Mesh is a supplement, not a lifeline. LoRa mesh is best-effort with no guaranteed delivery: messages can silently fail to arrive, the shared half-duplex channel saturates under load, and coverage depends on powered relay nodes being in range. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. Assign assured-delivery and life-safety traffic to voice with confirmed receipt (or Winlink for a record copy); use mesh for supplemental status, position, and welfare data.

ARRL ARES Structure

ARES is organized and administered by the American Radio Relay League (ARRL). It has four organizational levels - national, section, district, and local - and interfaces with / operates under ICS during activations rather than literally mirroring ICS/NIMS at every tier:

• Emergency Coordinator (EC) - Local (county or city) point of contact, recruits and trains volunteers, coordinates with served agencies.
• District Emergency Coordinator (DEC) - District-level coordinator overseeing several local ECs within a section.
• Section Emergency Coordinator (SEC) - Section-level coordinator (assistant to the Section Manager for emergency preparedness); ARRL Sections do not always correspond to states - several states contain more than one Section.
• Assistant EC (AEC) - Functional leads for specific disciplines, for example digital, VHF, HF, or public events. These discipline assignments are examples set locally by the EC, not a fixed national list (see the ARRL ARES manual).
• ARES Members - Licensed amateur operators who have completed enrollment and training requirements.

ARES groups typically maintain readiness on 2-meter FM simplex and repeater frequencies, HF voice and digital (Winlink/JS8Call), and increasingly on data mesh platforms. Training follows ARRL-published curricula and may align with FEMA IS-700/IS-100/IS-200 requirements set by served agencies.

RACES - Municipal Affiliation

RACES is authorized under 47 CFR §97.407 and operates only at the direction of the responsible civil-defense / emergency-management official - during emergencies and during authorized drills and tests. Routine RACES training drills and tests are expressly permitted (limited to a total of 1 hour per week without a declared emergency, with longer drills only by approval of the responsible official). Unlike ARES, which can operate at any time, RACES operation requires:

• Direction or authorization by the responsible civil authority (city, county, or state emergency management office) - either for an emergency or for an authorized drill/test.
• Enrollment of operators with that civil authority - not just ARRL membership.
• Operation only on frequencies and in modes authorized by that civil authority under RACES rules.

Many operators hold dual ARES/RACES enrollment, enabling them to transition from ARES pre-activation operations to RACES operations upon a formal activation.

How LoRa Mesh Fits Alongside HF/VHF Infrastructure

LoRa mesh on the 915 MHz ISM band (or 868 MHz in Region 1) operates independently of the amateur radio allocations used by HF/VHF operators. While 902-928 MHz is a shared band, this unlicensed Part 15 operation is independent of Part 97 amateur authority, creating a clean separation of roles:

Capability	HF/VHF Voice	LoRa Mesh
Long-distance voice relay	Excellent (HF)	Not applicable
Structured digital forms (ICS213)	Commonly via Winlink or other digital forms tools (FLMSG), or relayed by voice using formal message-handling procedures	Plain-text only; ICS form data must be manually condensed into ~230-character messages (no native structured-form transport)
Position tracking (blue force)	Via APRS (separate system)	Native GPS position sharing
Welfare traffic (check-ins)	Voice net, slow	Asynchronous text, fast (best-effort)
License required	Yes (Technician+)	No, IF operated under Part 15 (FCC-certified equipment, 1 W / 30 dBm conducted max, must accept interference and cause no harmful interference). Default-encrypted Meshtastic cannot lawfully move to amateur frequencies.
Deployed infrastructure needed	Repeaters, linked systems	Self-forming ad-hoc mesh

Mesh nodes are useful for low-bandwidth supplemental data: ICS form text, GPS tracks, welfare check-ins, and resource status messages. Note that mesh transport is best-effort with no guaranteed delivery and very limited store-and-forward; assign assured-delivery traffic (formal ICS forms needing a record) to Winlink/voice and use mesh for supplemental, confirm-when-it-matters data. Voice radio remains superior for command coordination, situational awareness broadcasts, and long-haul links.

Under FCC Part 15, the 915 MHz limit is on conducted transmitter output power - up to 1 W (30 dBm) for frequency-hopping/digital systems per 47 CFR §15.247 - with separate provisions governing antenna gain and EIRP (antennas above 6 dBi require a dB-for-dB reduction in conducted power). "1 W EIRP" is not the correct phrasing for the limit.

Digital Data Transport Use Cases

• ICS Forms: ICS 213 general messages and ICS 214 activity logs can be sent as plain-text messages (manually entered, or via external tooling - there is no built-in ICS-form module) over mesh hops toward an EOC node for printing or forwarding via Winlink. Mesh delivery is best-effort and not guaranteed, so a form sent this way is not assured to arrive; use Winlink/voice when a record copy must be delivered.
• Position Tracking: Meshtastic built-in GPS position sharing provides a blue-force track of all mesh-equipped operators, visible on the map view of the Meshtastic app or on third-party integrations such as a TAK server via atak-forwarder. Note atak-forwarder is a third-party project; verify it is still maintained and compatible with your current Meshtastic firmware before relying on it (as of this writing).
• Welfare Traffic: Mass-casualty or shelter-in-place events generate high welfare check-in volume. Mesh text messages allow operators to report status without consuming voice net time - on a best-effort basis.

MOU Considerations with Served Agencies

A Memorandum of Understanding (MOU) between an ARES group and a served agency (hospital, Red Cross chapter, VOAD, county OES) should address LoRa mesh explicitly if it is part of the deployed communications plan. Key provisions to negotiate:

• Which frequency channel preset will be used and how frequency coordination is handled if the served agency operates nearby LoRa sensors.
• Who owns and maintains the fixed relay nodes installed at agency facilities such as a node on the EOC rooftop.
• Data handling: are mesh messages logged, and if so, where? Who has access to those logs?
• Activation triggers: under what conditions does the mesh network activate, and who issues the activation order?
• Training requirements: which agency staff will be issued Meshtastic devices, and what minimum proficiency is required?
• Liability and risk allocation: limitation of liability, mutual indemnification, insurance/coverage expectations, and an explicit clause stating that mesh is a supplemental, best-effort capability with no guaranteed delivery and is not to be relied upon as a primary or life-safety channel. Have counsel review any MOU before signing.

ICS/NIMS Terminology for Mesh Operators

Why Mesh Operators Must Know ICS

When a LoRa mesh network is activated in support of a formal emergency response, it operates within the National Incident Management System (NIMS) framework and is subject to Incident Command System (ICS) discipline. Mesh operators who arrive at an EOC or a field operations post without basic ICS literacy create coordination friction. This page provides the essential vocabulary and structural concepts every mesh operator should understand before deployment.

Key ICS Forms

Form	Name	Mesh Relevance
ICS 201	Incident Briefing	Read-only for most operators; contains current situation, resources assigned, and initial incident map. Mesh operators should receive this at check-in.
ICS 205	Incident Radio Communications Plan	Lists all assigned frequencies, channels, and modes for an operational period. Mesh channel selection must not conflict with assignments listed here. The ICS 205 is built (in part) from the pre-incident resource availability data on the ICS 217A.
ICS 213	General Message	The standard form for written messages between ICS positions. Frequently relayed over mesh or Winlink. Fields: To, From, Subject, Date/Time, Message, Reply.
ICS 214	Activity Log	A chronological log kept by each ICS position. This is the form for real-time, time-stamped status: mesh operators maintaining a node should keep an ICS 214 documenting activation time, channel changes, node counts, and any outages. Live node status belongs here (or on an incident status board), not on the ICS 217A.
ICS 217A	Communications Resource Availability Worksheet	A pre-incident planning worksheet that inventories communications resources (radios, mesh nodes, repeaters) that could be available, by type, quantity, and capability. It feeds the ICS 205 — it is not a live, real-time status log. Use it to declare what mesh resources your group can bring; track their live operational status on the ICS 214 or a status board.

Net Control Station (NCS) Role

In a traditional voice net, the Net Control Station directs traffic, grants permission to transmit, and maintains net discipline. On a LoRa mesh there is no protocol-level NCS — the peer-to-peer architecture has no central station granting permission to transmit. That does not mean nodes transmit with no constraints, however: Meshtastic uses managed flood routing with listen-before-transmit (CSMA-style) channel access, and shared airtime and duty-cycle limits mean undisciplined traffic still congests the mesh. Human net discipline therefore remains necessary, and a mesh operator should be designated as the logical NCS responsible for:

• Monitoring mesh traffic and flagging missed check-ins.
• Coordinating channel changes if interference is detected.
• Serving as the interface between the mesh network and the ICS Communications Unit Leader (COML). A human mesh coordinator interfacing with the COML is recommended practice; see the FEMA NIMS 509 COML job aid.
• Maintaining the live node-status log on the ICS 214 (the pre-incident resource list is the ICS 217A).

Tactical Call Signs

NIMS requires the use of plain language and tactical identifiers — not codes or personal call signs — during multi-agency operations. Mesh node names should follow the tactical naming convention established in the Incident Action Plan (IAP). Examples:

• EOC-MAIN - Primary EOC mesh node
• SHELTER-A - Node at Shelter Alpha
• DIV-BRAVO-1 - First field node in Division Bravo

Note on station identification: NIMS tactical identifiers are used for coordination, but any transmission on amateur (Part 97) frequencies must still include the operator's FCC-assigned call sign at least every 10 minutes and at the end of communications (47 CFR §97.119). Tactical names supplement, not replace, FCC station ID on any amateur-band leg. Mesh-only traffic on the unlicensed Part 15 915 MHz band has no FCC call-sign requirement.

Avoid using personal amateur radio call signs as node names on an ICS-integrated mesh - doing so mixes amateur radio identity with ICS tactical identity and can cause confusion in logs. This naming advice applies to the Part 15 mesh layer only; it does not waive the §97.119 call-sign ID requirement on any amateur-frequency link the operator also uses.

Radio Discipline on Mesh

Although mesh is asynchronous, operators should observe the following discipline to maintain operational effectiveness:

• Identify yourself: Begin each sent message with your tactical identifier even though Meshtastic shows the sender node name. This reinforces ICS message format habits. (Note: this is a readability convention, not security — typing your name does not cryptographically authenticate you and does not prevent spoofing.)
• Time-stamp critical messages: ICS 213 format requires a date-time group. Include it in mesh messages that will be transcribed to paper forms.
• No unnecessary traffic: Mesh bandwidth is limited. Test messages and chatter consume airtime. Use a separate channel or Meshtastic admin channel for testing.
• Acknowledge receipt: Meshtastic provides delivery acknowledgment for direct ("reliable") messages — but not for broadcast/channel messages — and an ACK can be a best-effort relay acknowledgment rather than proof a human read or acted on the message. Always require an explicit human reply such as RCVD/WILCO for ICS 213 messages requiring action.

Mapping Mesh Nodes to ICS Resources

Under NIMS, all resources are typed and tracked. Mesh nodes fall under the Communications Unit (COMU) — led by the Communications Unit Leader (COML) — within the Logistics Section (Service Branch). The COML is responsible for all communications equipment. Mesh operators should:

• Check in their nodes with the COML on arrival, declaring their resources using the pre-incident ICS 217A availability data.
• Report node status changes (battery level, coverage gaps, node failures) to the COML, and log them in real time on the ICS 214.
• Not change mesh channels or configurations without COML authorization.

NIMS Typing for Communications Resources

FEMA has published NIMS resource typing definitions for communications assets (the Operational Communications resource typing). LoRa mesh nodes do not yet have a dedicated NIMS type definition, so groups should document their resources under the closest applicable communications category — or as a clearly labeled local convention if no published type fits. (The label "Communications Unit - Data" used in some local plans is a convention, not a verified FEMA resource-type name; confirm against the current FEMA resource typing library before citing it formally.) Key attributes to document include throughput in bps, maximum hop count, battery endurance in hours, and whether the node supports a gateway or internet bridge function.

EOC Connectivity

An EOC typically operates as the hub of the mesh topology. Recommended EOC mesh configuration:

• At least two redundant nodes (primary and backup) on separate power circuits.
• One node configured as a MQTT gateway (if internet connectivity is available) to provide mesh traffic visibility on a remote dashboard. If you bridge mesh traffic off-site via MQTT, secure and restrict it (authentication/TLS), avoid carrying personal or sensitive data off-site, and follow the served agency's data-handling rules.
• Node antenna elevated to rooftop or mast level to maximize coverage.
• ICS 214 activity log maintained for each node, updated at each operational period change. (An operational period is the timeframe set for executing a given set of objectives — usually 12 to 24 hours.)

Go Kit Building for Mesh Nodes

Introduction

A well-built mesh go kit allows rapid deployment of a fully functional LoRa mesh node in any environment - whether that is a shelter parking lot, a hilltop relay position, or the back of a command vehicle. This page covers case selection, power systems, antenna options, node hardware, and a pre-deployment checklist.

Case Selection

Weatherproofing is the first priority. The two most common case families are:

• Pelican cases (e.g., 1510 carry-on, 1450 mid-size): High-quality latches, pressure equalization valve, pick-and-pluck foam. Manufacturer-rated waterproof (Pelican rates the Protector line IP67 with the purge valve closed — check the current spec). More expensive but very durable.
• Apache cases (Harbor Freight): A good budget alternative that costs substantially less than Pelican. Harbor Freight markets Apache cases as IP67-rated as well (verify the current manufacturer spec). They are similar but not identical — latch durability and warranty differ. Pre-cut foam available; customizable with aftermarket inserts. Treat any price comparison as approximate and check current pricing.

For a single-node portable kit, a mid-size case (Apache 3800 or Pelican 1450) is sufficient. For a multi-node relay kit with a larger battery, the Apache 4800 or Pelican 1510 provides adequate volume.

Power Systems

Battery Chemistry Comparison

Parameter	LiFePO4	SLA (AGM)
Energy density	Higher (lighter for same Ah)	Lower (heavy)
Cycle life	2,000+ cycles	300-500 cycles
Self-discharge	~3% per month	~5% per month
Cold weather performance	Can discharge to about -20C, but must NOT be charged below 0C (32F) unless the pack has dedicated low-temperature charging support; a BMS usually disables charging when too cold (it blocks cold charging, it does not enable it)	Degrades below 0C
Cost per Wh	Higher upfront, lower lifetime	Low upfront
Recommended use	Primary portable kit	Base-station backup

A 10 Ah, 12 V LiFePO4 battery stores 120 Wh nominal (total) capacity; at 80% depth of discharge about 96 Wh is usable. This is adequate for most single-node 12-hour deployments.

Charge Controller

If solar charging is desired, a 10-20W solar panel is sufficient for a single-node kit. Use a charge controller that is explicitly LiFePO4-compatible (correct voltage setpoints), since LiFePO4 uses a different charge curve than SLA — the older Renogy Wanderer's lithium support varies by model and firmware, so verify before relying on it. Note that a 10A controller is far larger than a 10-20W panel needs; a small lithium-aware MPPT controller may charge more efficiently for the cost. Do not use a generic PWM controller without confirming its LiFePO4 voltage support.

Power Budget Calculation

Before deployment, calculate the required battery capacity. Where possible, work the budget in watt-hours (Wh), not raw mAh, to avoid mixing voltage domains (a node runs at ~3.7-5 V while a "12 V" pack is at 12 V):

1. Measure or look up the current draw of the node hardware at full transmit and receive. These are approximate and depend heavily on configuration (light sleep, GPS state, screen); confirm against a meter or the Espressif/Semtech datasheets for your build. Typical ranges:
   • T-Beam v1.1 (ESP32 + SX1276 + GPS, GPS on, no light sleep): approximately 120 mA average (idle/receive), 200 mA peak (transmit) — lower with light sleep enabled
   • RAK4631 (nRF52840 + SX1262): a few mA average with light sleep (~200 uA in deep sleep), higher in continuous receive; ~100+ mA peak during transmit. Actual average depends on sleep configuration.
2. Add loads for any accessories: OLED display ~30 mA; USB hub ~50 mA; Raspberry Pi companion ~400 mA.
3. Calculate: mAh required = total_mA x hours divided by efficiency_factor. Use 0.85 for a new LiFePO4 pack. To compare against a 12 V pack, convert the node load to Wh and compare to the battery's Wh rather than comparing mAh figures across different voltages.
4. Example: T-Beam (150 mA avg) + OLED (30 mA) = 180 mA x 12 h / 0.85 = 2,541 mAh minimum at the node's ~5 V rail (roughly 13 Wh). Note that a "5 Ah 12 V" battery is about 60 Wh, so it carries well over 2x margin in energy terms — but do not read the 2,541 mAh and 5 Ah figures as a direct ratio, because they are at different voltages. Always compare in watt-hours.

Antenna Options

Antenna Type	Gain	Best Use
Stub/whip (stock)	2-3 dBi	Portable, handheld, omnidirectional coverage
Mag-mount whip (915 MHz)	3-5 dBi	Vehicle rooftop, rapid deploy, omnidirectional
Yagi (3-6 element)	8-13 dBi	Point-to-point relay link, fixed direction
Fiberglass vertical (1/2 wave)	5-6 dBi	Elevated fixed relay node, omnidirectional

Part 15 power note: Under 47 CFR §15.247, antenna gain above 6 dBi requires a dB-for-dB reduction in conducted transmitter power below the 1 W (30 dBm) maximum to keep EIRP within the limit. With an 8-13 dBi Yagi you must reduce transmitter output accordingly (e.g., a 13 dBi antenna requires roughly a 7 dB power reduction from 30 dBm). Pairing a 13 dBi Yagi with a full 1 W node would exceed the lawful EIRP — verify your configuration stays within the limit.

For most go kits, a 5 dBi mag-mount whip on a metal ground plane (cookie sheet, vehicle roof) provides a practical balance of gain and omnidirectional coverage. Include SMA adapters and short coax pigtails in the kit.

Node Hardware Selection

• LILYGO T-Beam v1.1 or v1.2: Integrated ESP32, SX1276/SX1262, GPS, and 18650 battery holder. Best for portable handheld use. Available with 868/915/923 MHz variants.
• RAK4631 (WisBlock): nRF52840 + SX1262 modular system. Excellent power efficiency, compact. Requires WisBlock Base Board. Best for compact fixed relay builds. GPS available as an add-on module.
• Heltec LoRa32 v3: ESP32-S3 + SX1262 + integrated OLED. Good budget option for fixed relay nodes.

Pre-Deployment Checklist

• [ ] Node firmware updated to latest stable Meshtastic release
• [ ] Node name set to tactical identifier per IAP (e.g., SHELTER-B)
• [ ] Channel/PSK configured to match operational channel plan
• [ ] GPS fix confirmed (cold start may take 2-5 minutes outdoors)
• [ ] Battery charged and voltage verified. Note: 12.8V is the nominal voltage of a 4S LiFePO4 pack, not the fully-charged figure — a fully charged 4S LiFePO4 pack rests near 13.3-13.6V (and reads ~14.2-14.6V during or just after charging). Do not treat 12.8V as 100% state of charge, or you will under-charge the pack.
• [ ] Antenna SMA connector torqued finger-tight plus 1/8 turn (do not over-torque)
• [ ] Coax and antenna tested for continuity (SWR check if meter available)
• [ ] Spare 18650 cells or USB power bank included
• [ ] Meshtastic app (iOS/Android) or web client tested and connected via BLE/WiFi
• [ ] Deployment contact list (COML name, frequency, mesh channel, check-in interval) printed and laminated
• [ ] ICS 214 form (blank) included for activity logging
• [ ] Case latches and pressure valve inspected; foam dry