# ARES, RACES, and Served Agency Integration

Integrating LoRa mesh with amateur radio emergency service organizations and their served agencies.

# Mesh Networking in Amateur Radio Emergency Service (ARES)

<div id="bkmrk-operational-note%3A-th" style="background:#fff3cd;border-left:4px solid #ffc107;padding:12px 16px;margin-bottom:20px;"> **Operational Note:** This page may be consulted during active emergency operations. All procedures are based on current FCC regulations and ARRL ARES guidelines as of 2025. Verify local ARES group policies before deployment. </div>## What Is ARES?

 The **Amateur Radio Emergency Service (ARES)** is a program of the American Radio Relay League (ARRL) that organizes licensed amateur radio operators to provide emergency communication support to government agencies, relief organizations, and other served agencies when normal communications infrastructure fails or is overloaded. ARES is organized at the local, section, and national levels, with Emergency Coordinators (ECs) managing groups at the county or city level, Section Emergency Coordinators (SECs) at the state level, and national leadership through the ARRL.

 ARES members hold FCC amateur radio licenses (Technician, General, or Extra class) and participate in regular nets, exercises, and deployments. ARES groups typically operate on designated VHF/UHF repeater frequencies for voice communications and may also operate HF stations for long-range traffic handling. The National Traffic System (NTS) provides formal written message traffic capability via radiogram.

## How LoRa Mesh Complements VHF/UHF ARES Operations

 Traditional ARES operations are voice-centric: operators check into nets, relay verbal messages, and pass formal radiograms by voice or digital modes like Winlink. LoRa mesh (particularly Meshtastic) adds a complementary *data layer* that addresses specific gaps in traditional ARES capabilities:

<table id="bkmrk-capability-tradition" style="width:100%;border-collapse:collapse;"> <thead style="background:#2c3e50;color:#FFFFFF;"> <tr> <th>Capability</th> <th>Traditional ARES (VHF/UHF Voice)</th> <th>LoRa Mesh Addition</th> </tr> </thead> <tbody> <tr> <td>Short text messaging</td> <td>Voice relay only; requires operator attention</td> <td>Asynchronous store-and-forward; no operator attention needed for relay</td> </tr> <tr> <td>Position reporting</td> <td>Verbal position reports; APRS on separate system</td> <td>Automatic GPS position sharing on mesh; visible to all nodes</td> </tr> <tr style="background:#f8f9fa;"> <td>Net congestion</td> <td>Single voice channel; traffic serialized</td> <td>Parallel data channel; does not compete for voice net time</td> </tr> <tr> <td>Message logging</td> <td>Manual logging by net control</td> <td>Automatic message log on all receiving nodes</td> </tr> <tr style="background:#f8f9fa;"> <td>No-license users</td> <td>Not applicable (licensed only)</td> <td>Part 15 operation allows non-licensed served agency staff on mesh</td> </tr> <tr> <td>Infrastructure requirement</td> <td>Repeater or simplex range</td> <td>No infrastructure; ad-hoc mesh self-forms</td> </tr> </tbody></table>

## LoRa Mesh as a Supplemental Data Layer

 In ARES deployments, LoRa mesh is most valuable as a **supplemental data layer** running alongside, not replacing, the primary voice net. Common use cases include:

- **Position tracking:** Each ARES operator with a Meshtastic node automatically broadcasts GPS position. A Meshtastic client running on a laptop at net control can display all operator positions on a map without consuming voice net time for position reports.
- **Short message traffic:** Operators in the field can send short status messages ("shelter at Lincoln School now at 47 occupants") without requiring net control to be available to receive a voice transmission.
- **Pre-positioned relay nodes:** ARES groups can deploy solar-powered mesh relay nodes at elevated sites (hilltops, water towers, repeater sites) to extend mesh coverage across the operating area.
- **Served agency liaison:** A mesh node running in Part 15 mode at the served agency (Red Cross shelter, hospital, EOC) allows served agency staff to send text messages to ARES operators without needing a ham license.

## How to Introduce Mesh to Your Local ARES Group

1. **Start with the EC (Emergency Coordinator).** Schedule a 15-minute briefing. Lead with the problem mesh solves: "We can't track field operator positions without using net time." Avoid jargon. Bring a working demo node.
2. **Run a small demo at a regular meeting.** Set up two or three Meshtastic nodes in the room. Demonstrate position sharing on a phone screen. Let skeptical operators handle the hardware.
3. **Propose a parallel track at the next exercise.** Ask permission to run mesh alongside the normal voice exercise - not as a replacement. Offer to provide equipment for participants who want to try it.
4. **Document results.** After the exercise, provide a written after-action report comparing mesh message delivery vs. voice net efficiency. Numbers matter: "Mesh delivered 23 position updates automatically while voice net handled 8 formal messages."
5. **Propose group endorsement.** After successful exercises, request the EC formally endorse mesh as an ARES supplemental tool and add mesh node operation to the local ARES training curriculum.

## FCC Part 15 vs. Part 97: Regulatory Considerations for ARES

<div id="bkmrk-critical-regulatory-" style="background:#e8f4f8;border:1px solid #bee5eb;padding:16px;margin:16px 0;">### Critical Regulatory Distinction

 Meshtastic devices operating in [the 915 MHz ISM band](https://wiki.meshamerica.com/books/getting-started/page/the-915-mhz-ism-band) (US) operate under **FCC Part 15** - the same rules as Wi-Fi and Bluetooth. Part 15 operation:

- Requires **no license** to operate
- Limits power to typically 1 watt EIRP (30 dBm) in the 915 MHz band with frequency hopping spread spectrum
- Prohibits causing harmful interference to licensed services
- Requires accepting interference from other Part 15 devices
- Does **not** allow power increases beyond Part 15 limits, even by licensed amateurs
 
 **Part 97 (Amateur Radio)** allows licensed amateurs to operate in the 33 cm (902 - 928 MHz) band with higher power (up to 1500W PEP in some cases, subject to local coordination). However, Part 97 operation **prohibits**:

- Encryption of message content (except for certain control signals)
- Commercial use or pecuniary interest
- Communications in which the licensee has a pecuniary interest
 
 **Meshtastic's default encryption** (AES-128) means Meshtastic operation is *technically not Part 97 compliant* for content transmission, as Part 97 prohibits obscuring the meaning of messages. ARES groups should operate Meshtastic nodes under Part 15 rules with channels configured to unencrypted or use encryption only for served-agency traffic not transmitted under Part 97 authority.

 **Practical guidance:** For ARES operations, use Part 15 power levels and configure channels with no encryption (or document your encryption key for legal Part 97 operation in jurisdictions where encryption is approved by your Section Manager). Consult your ARRL Section Manager for local guidance.

</div>## Getting ARES Group Endorsement for Mesh Infrastructure

 Formal ARES group endorsement provides several benefits: shared deployment of pre-positioned nodes, group funding or donations for equipment, and integration into official exercise planning. To pursue endorsement:

1. Write a one-page proposal for the EC describing: (a) the problem mesh solves, (b) equipment required and cost, (c) regulatory compliance (Part 15), (d) maintenance plan, (e) training requirements.
2. Present the proposal at a group meeting and invite questions.
3. Offer a formal training session covering Meshtastic setup, channel configuration, and emergency protocols.
4. Request inclusion in the group's Standard Operating Procedures (SOPs) as "Supplemental Mesh Data Layer."
5. Coordinate with the Section Emergency Coordinator (SEC) if seeking section-level endorsement or cross-group interoperability.

## Quick Reference: ARES + Mesh Checklist

- ☐ EC briefed and supports mesh integration
- ☐ At least one mesh exercise conducted alongside voice net
- ☐ After-action report documenting mesh performance documented
- ☐ Channel plan documented and distributed to all mesh operators
- ☐ Part 15 power compliance verified on all deployed nodes
- ☐ Encryption policy documented and compliant with Section Manager guidance
- ☐ Mesh roles assigned in ARES activation plan (mesh coordinator, relay node operators)
- ☐ At least two operators trained on mesh node setup and troubleshooting
- ☐ Mesh node inventory maintained with deployment locations
- ☐ Mesh SOP incorporated into ARES local plan

# Integrating with Served Agencies

<div id="bkmrk-operational-note%3A-th" style="background:#fff3cd;border-left:4px solid #ffc107;padding:12px 16px;margin-bottom:20px;"> **Operational Note:** This page provides guidance for ARES operators and mesh advocates working with served agencies including Red Cross, hospitals, EOCs, and fire/EMS. Establish relationships before an emergency - these conversations are far harder during an active event. </div>## Understanding Served Agency Communication Requirements

 Served agencies have specific, often rigid communication requirements driven by their own SOPs, legal obligations, and incident command structures. Understanding these requirements is essential before proposing mesh integration.

### Red Cross / American Red Cross

- Needs: shelter population counts, resource requests (cots, meals, water), staff check-ins
- Message traffic: typically short, structured (ICS-213 equivalent), not conversational
- Key concern: reliability and accountability - messages must be logged
- Staffing: mix of trained volunteers and paid staff; not all are technically sophisticated
- Integration point: mesh node at each shelter feeding position/status to EOC

### Hospitals

- Needs: patient counts by severity (START triage), resource status (available beds, O2, blood), evacuation coordination
- Message traffic: HIPAA-sensitive - do not transmit identifying patient information over mesh
- Key concern: HIPAA compliance; any mesh content must be aggregate, not individual patient data
- Integration point: hospital HAM radio operator or communications officer; mesh for non-PHI status only

### Emergency Operations Center (EOC)

- Needs: comprehensive situational awareness; resource tracking; inter-agency coordination
- Message traffic: high volume, multi-agency, documented
- Key concern: integration with existing systems (WebEOC, ICS forms, CAD)
- Integration point: MQTT bridge connecting mesh to EOC dashboard; mesh coordinator assigned at EOC

### Fire and EMS

- Needs: incident position, resource status, casualty counts, scene perimeter
- Message traffic: tactical and time-critical; concise
- Key concern: interoperability with CAD and dispatch; not adding cognitive load to incident commanders
- Integration point: mesh as supplemental position tracking, not primary tactical comms

## Mesh in the ICS Communications Hierarchy

 The Incident Command System (ICS) defines a strict communications structure. Mesh fits into this structure as a **supplemental tactical channel**, not a command channel.

<table id="bkmrk-ics-traffic-type-pri" style="width:100%;border-collapse:collapse;"> <thead style="background:#2c3e50;color:#FFFFFF;"> <tr> <th>ICS Traffic Type</th> <th>Primary Channel</th> <th>Mesh Role</th> </tr> </thead> <tbody> <tr> <td>**Command** (incident command decisions)</td> <td>Voice (P25, VHF/UHF)</td> <td>NOT appropriate for mesh - use designated voice channels</td> </tr> <tr style="background:#f8f9fa;"> <td>**Tactical** (field team coordination)</td> <td>Voice (simplex or repeater)</td> <td>Supplemental: short status messages, position updates</td> </tr> <tr> <td>**Logistics** (resource requests, supply)</td> <td>Voice or Winlink email</td> <td>Supplemental: structured request messages via mesh</td> </tr> <tr style="background:#f8f9fa;"> <td>**Situation Awareness** (mapping, tracking)</td> <td>Manual boards, GIS</td> <td>Primary supplement: GPS position sharing is a natural mesh strength</td> </tr> <tr> <td>**Public Information**</td> <td>Designated PIOs only</td> <td>NOT appropriate - no public-facing mesh traffic</td> </tr> </tbody></table>

<div id="bkmrk-warning%3A-never-use-m" style="background:#f8d7da;border-left:4px solid #dc3545;padding:12px 16px;margin:16px 0;"> **Warning:** Never use mesh as a primary command channel during active incidents. Mesh has variable latency (seconds to minutes), no guaranteed delivery, and no acknowledgment in basic operation. Life-safety commands must use primary voice channels with confirmed receipt. </div>## What Served Agencies Actually Need

 When pitching mesh to served agency coordinators, focus on what they actually want - not the technology:

- **Reliable short messages:** "Is the shelter at Lincoln School open and how many people are there?" Mesh can deliver a 230-character answer without consuming repeater air time.
- **Position data:** "Where are my teams right now?" Meshtastic's automatic GPS position broadcast answers this continuously without any operator action.
- **No additional training burden:** Served agency staff should be able to use mesh with minimal training. A Meshtastic node with a preconfigured channel and a simple phone app meets this bar.
- **Works when infrastructure fails:** The core value proposition: mesh works when cell towers, internet, and repeaters are down.

## How to Pitch Mesh to an OES or EOC Coordinator

<div id="bkmrk-the-three-minute-pit" style="background:#d4edda;border-left:4px solid #28a745;padding:16px;margin:16px 0;">### The Three-Minute Pitch

1. **Open with their problem:** "During the \[local event\] last year, your shelter coordinators couldn't reach EOC for 4 hours because the repeater was down. LoRa mesh works without repeaters or cell service."
2. **Show one capability:** Hand them a Meshtastic device. Send a message from across the room. Show the position on the map. "This works on battery for 3 days."
3. **Make the ask small:** "I'm not asking you to replace anything. I'm asking to run this in parallel at your next exercise so you can see how it works."
 
</div>## Common Objections and Responses

<table id="bkmrk-objection-response-%22" style="width:100%;border-collapse:collapse;"> <thead style="background:#2c3e50;color:#FFFFFF;"> <tr> <th>Objection</th> <th>Response</th> </tr> </thead> <tbody> <tr> <td>"We already have radios."</td> <td>"Absolutely - and mesh doesn't replace them. It adds a text and position data layer so your voice channels stay clear for important calls."</td> </tr> <tr style="background:#f8f9fa;"> <td>"What if it breaks?"</td> <td>"Mesh is decentralized - there's no single point of failure. If one node fails, traffic routes around it. And your existing radio systems remain the primary comms."</td> </tr> <tr> <td>"Our staff can't learn new technology during a disaster."</td> <td>"The basic interface is a phone app most people can learn in 5 minutes. We train before the disaster, not during it. We can include it in your next tabletop exercise."</td> </tr> <tr style="background:#f8f9fa;"> <td>"Is it secure/encrypted?"</td> <td>"Meshtastic supports AES-128 encryption. For served agency use over Part 15, we recommend a private channel with a strong key shared only with authorized nodes."</td> </tr> <tr> <td>"Who maintains it?"</td> <td>"The ARES group maintains the infrastructure nodes. Each served agency location just needs a single low-cost device that runs unattended on solar power."</td> </tr> <tr style="background:#f8f9fa;"> <td>"We don't have budget."</td> <td>"A complete node costs $30 - 80. The ARES group can provide and maintain pre-positioned nodes at your facilities at no cost to you."</td> </tr> </tbody></table>

## Training and Exercise Requirements

 Before a served agency relies on mesh in an actual emergency, the following training milestones should be met:

1. **Initial orientation (30 - 60 min):** Demonstrate mesh hardware, install [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) on agency-designated device, configure pre-set channel, send and receive test messages.
2. **Tabletop exercise integration:** Include mesh message traffic in a tabletop exercise scenario. Evaluate whether served agency staff can successfully send and receive mesh messages during a simulated event.
3. **Field exercise:** Deploy mesh nodes at served agency locations during a full field exercise. Test coverage, message delivery, and integration with EOC display systems.
4. **SOP integration:** Served agency communications SOP should reference mesh as a supplemental channel, identify who is responsible for the node at each location, and document how to initiate mesh use during an activation.
5. **Annual verification:** Test each served agency node annually. Replace batteries, update firmware, verify channel configuration is current.

## Served Agency Integration Checklist

- ☐ Met with served agency communications officer or OES coordinator
- ☐ Demonstrated mesh capability during non-emergency visit
- ☐ Identified served agency mesh liaison (person responsible for the node)
- ☐ Installed and configured mesh node at served agency location
- ☐ Trained served agency liaison on basic operation (send/receive messages, check battery)
- ☐ Conducted tabletop or field exercise with mesh integration
- ☐ Documented served agency location in ARES mesh node inventory
- ☐ Integrated mesh into served agency communication SOP
- ☐ Annual maintenance schedule established
- ☐ Backup/spare node available if primary fails

# Running a Mesh-Enabled EMCOMM Exercise

<div id="bkmrk-planning-note%3A-this-" style="background:#fff3cd;border-left:4px solid #ffc107;padding:12px 16px;margin-bottom:20px;"> **Planning Note:** This page is a planning and evaluation guide for emergency communications exercises that incorporate LoRa mesh alongside traditional voice operations. Use this as a template and adapt to your local group's capabilities, geography, and served agency relationships. </div>## Why Combined Voice + Mesh Exercises?

 Training separately on voice and mesh produces operators who can use each system independently. Combined exercises reveal how the systems interact, where they complement each other, and - critically - where operators might accidentally rely on mesh when they should use voice or vice versa. Combined exercises also let you measure mesh performance in realistic field conditions before relying on it in an actual emergency.

## Scenario Design

### Scenario Elements That Benefit from Mesh

- Multiple geographically dispersed field teams that need to track each other's positions
- Served agency location (shelter, hospital, EOC staging area) that needs to report resource status periodically
- Net control station that needs to track field team positions without consuming voice net time for position reports
- A simulated infrastructure failure (repeater "goes down" at a pre-planned time mid-exercise) to test mesh as a fallback

### Sample Scenario: [Earthquake Response](https://wiki.meshamerica.com/books/emergency-communications/page/earthquake-response), Day 1

```

SCENARIO: 6.2 magnitude earthquake, 0730 local time.
Infrastructure status: Cell towers out, internet out, primary repeater unknown (simulate partial coverage).
ARES activation: County EC activates all available operators.
Objectives: - Establish EOC comms link (primary: voice on simplex; supplemental: mesh) - Assess four pre-designated shelter sites (teams of 2 per site) - Report shelter status (capacity, occupancy, needs) every 30 minutes - Track all field team positions continuously - Pass a minimum of 10 formal ICS-213 messages via mesh

Inject at T+60 min: Primary simplex frequency congested; shift mesh position reporting
to free up voice channel for priority traffic.

Inject at T+90 min: Shelter #3 reports mass casualty event; all traffic deprioritized
except medical coordination.
```

## Pre-Positioning Infrastructure

### Infrastructure Checklist (T-7 days before exercise)

- ☐ Identify all exercise areas and map expected operating locations
- ☐ Identify elevated relay sites within exercise area (hilltops, buildings, repeater sites)
- ☐ Deploy solar relay nodes at 1 - 3 elevated sites at least 24 hours before exercise
- ☐ Verify relay node solar charging is functioning (check battery voltage)
- ☐ Test message delivery from all expected field team operating areas to EOC node
- ☐ Configure all nodes with exercise channel (separate from operational channel)
- ☐ Assign node names following naming convention (e.g., RELAY-HILLTOP-1, FIELD-TEAM-A)
- ☐ Verify all field team nodes have GPS lock in outdoor test
- ☐ Brief all participants on channel configuration before exercise day
- ☐ Assign backup power (charged batteries or power banks) to all deployed nodes

## Assigning Mesh Roles to Participants

<table id="bkmrk-role-responsibilitie" style="width:100%;border-collapse:collapse;"> <thead style="background:#2c3e50;color:#FFFFFF;"> <tr> <th>Role</th> <th>Responsibilities</th> <th>Equipment</th> </tr> </thead> <tbody> <tr> <td>**Mesh Coordinator (EOC)**</td> <td>Monitors mesh map at EOC; logs all mesh message traffic; escalates time-sensitive messages to voice net control; manages mesh channel discipline</td> <td>Laptop running Meshtastic web client with map view; dedicated EOC mesh node with antenna</td> </tr> <tr style="background:#f8f9fa;"> <td>**Field Team Leader** (per team)</td> <td>Sends periodic status reports via mesh; monitors team position on [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app); escalates voice if mesh delivery fails</td> <td>Meshtastic handheld node; phone running Meshtastic app (BLE connected)</td> </tr> <tr> <td>**Relay Node Monitor**</td> <td>Checks relay node status periodically; adjusts or repositions if coverage is inadequate; troubleshoots connectivity issues</td> <td>Laptop or phone with access to relay node; spare node and hardware</td> </tr> <tr style="background:#f8f9fa;"> <td>**Served Agency Liaison** (if applicable)</td> <td>Operates mesh node at served agency location; sends structured status reports; reports mesh problems to field team leader</td> <td>Pre-configured Meshtastic node; phone or tablet with Meshtastic app</td> </tr> <tr> <td>**Exercise Evaluator**</td> <td>Records all mesh message delivery data (sent time, received time, recipient); tracks voice net traffic for comparison; notes any mesh failures or anomalies</td> <td>Log sheet or tablet; Meshtastic client with message log visible</td> </tr> </tbody></table>

## Evaluating Performance: Key Metrics

### Message Delivery Rate

 The primary mesh performance metric is the percentage of sent messages that were received by the intended recipient within an acceptable latency window. Calculate separately for:

- Direct node-to-node (single hop) delivery rate
- Multi-hop delivery rate (messages relayed through 2+ hops)
- Delivery rate under different field conditions (urban, rural, elevated)

### Latency Measurement

 Record the timestamp when each message is sent and the timestamp when it is confirmed received at the destination. Meshtastic's message log provides send time; the receiving node's log provides receive time. Target latency benchmarks:

<table id="bkmrk-hop-count-acceptable" style="width:100%;border-collapse:collapse;"> <thead style="background:#495057;color:#FFFFFF;"> <tr> <th>Hop Count</th> <th>Acceptable Latency</th> <th>Concerning Latency</th> </tr> </thead> <tbody> <tr> <td>Direct (0 hops)</td> <td>&lt; 2 seconds</td> <td>&gt; 5 seconds</td> </tr> <tr style="background:#f8f9fa;"> <td>1 hop</td> <td>&lt; 5 seconds</td> <td>&gt; 15 seconds</td> </tr> <tr> <td>2 - 3 hops</td> <td>&lt; 15 seconds</td> <td>&gt; 30 seconds</td> </tr> <tr style="background:#f8f9fa;"> <td>4 - 7 hops (max)</td> <td>&lt; 30 seconds</td> <td>&gt; 60 seconds</td> </tr> </tbody></table>

### Net Efficiency Comparison

 Record the number of voice net transmissions consumed for position reports and status updates before mesh was deployed vs. after. A successful mesh integration typically reduces voice net traffic by 30 - 60% for routine status/position traffic.

## Post-Exercise Debrief Template

<div id="bkmrk-exercise-after-actio" style="background:#f8f9fa;border:1px solid #dee2e6;padding:16px;">### Exercise After-Action Report: Mesh Component

**Exercise Name:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Date:** \_\_\_\_\_\_\_\_\_\_ **Duration:** \_\_\_\_\_\_\_\_\_\_

**Participants:** \_\_\_\_\_\_\_\_\_\_ **Mesh Nodes Deployed:** \_\_\_\_\_\_\_\_\_\_

#### Quantitative Metrics

- Total mesh messages sent: \_\_\_\_\_\_\_\_\_\_
- Total mesh messages received at intended destination: \_\_\_\_\_\_\_\_\_\_
- Message delivery rate: \_\_\_\_\_\_\_\_\_\_%
- Average delivery latency (single hop): \_\_\_\_\_\_\_\_\_\_ sec
- Average delivery latency (multi-hop): \_\_\_\_\_\_\_\_\_\_ sec
- Voice net transmissions for position/status BEFORE mesh: \_\_\_\_\_\_\_\_\_\_
- Voice net transmissions for position/status WITH mesh: \_\_\_\_\_\_\_\_\_\_
- Voice net efficiency improvement: \_\_\_\_\_\_\_\_\_\_%
- Infrastructure node failures or outages: \_\_\_\_\_\_\_\_\_\_
 
#### Qualitative Assessment

- What worked well with mesh integration?
- What failed or caused confusion?
- Were there coverage gaps? Where?
- Did any operators misuse mesh (sent life-safety traffic that should have been voice)?
- Was the Mesh Coordinator role effectively staffed?
- Were served agency liaisons able to use mesh without difficulty?
 
#### Corrective Actions

 <table style="width:100%;border-collapse:collapse;"> <thead style="background:#495057;color:#FFFFFF;"> <tr><th>\#</th><th>Issue Identified</th><th>Corrective Action</th><th>Owner</th><th>Due Date</th></tr> </thead> <tbody> <tr><td>1</td><td></td><td></td><td></td><td></td></tr> <tr style="background:#f8f9fa;"><td>2</td><td></td><td></td><td></td><td></td></tr> <tr><td>3</td><td></td><td></td><td></td><td></td></tr> </tbody> </table>

#### Recommendations for Next Exercise

- Additional relay nodes needed at: \_\_\_\_\_\_\_\_\_\_
- Training improvements needed: \_\_\_\_\_\_\_\_\_\_
- Equipment changes recommended: \_\_\_\_\_\_\_\_\_\_
- SOP changes recommended: \_\_\_\_\_\_\_\_\_\_
 
</div>