Incident Command
Edit on GitHubHow a rescue incident is organized, what the beacon operator should know, and how to report in a way that helps rather than hinders.
Incident Command
When something goes wrong in the mountains, the response is not chaos: it is a structure called incident command. Knowing the structure makes your one beacon transmission vastly more useful.
The structure in one paragraph
One person (the incident commander) owns the big picture: who searches where, who treats whom, who calls for helicopters. Under them, teams have narrow jobs. Every report flows to the commander, and only the commander reassigns people. If you transmit into this system, address the system, not individuals.
What the beacon operator contributes
Your transmissions provide three inputs to the system:
- Position (where you are)
- Identity and numbers (who you are, how many with you)
- Status updates (injuries, weather, movement)
The firmware’s payload carries the first two automatically. The third is why the beacon repeats on a schedule: a stable, repeating signal is itself a status report (still alive, still in place).
Reporting to a team
If you reach a rescue team by voice:
- State who you are and your position in their format (see Position Reporting)
- Report injuries and needs in plain language
- Do not move unless asked; a moving subject is much harder to find
- Repeat the frequency and schedule you are transmitting on
The moving subject trap
The most common beacon mistake: the subject transmits from point A, then walks to point B, and the team searches A. If you must move, transmit from the new position and, if possible, note the direction of travel in a status message. The Search Patterns and Procedure page explains how teams handle this.
Related pages
- Rescue Communication Basics for the radio picture
- Position Reporting for the format
- Emergency Response Scenarios for the scenarios