How to Give Dispatch Clear Coded Box Alarm Identification
By Andrew Erickson
July 1, 2026
A coded telegraph fire alarm system can tap out a box alarm exactly as designed and still leave dispatch guessing which building needs a response. The pulses arrive, the registering equipment counts them, and yet the operator at the console may see nothing more than a raw number - or nothing at all if the decoding equipment has aged out. Coded telegraph box monitoring is the practice of receiving those pulse-coded alarms from street boxes, pull stations, and building interfaces on a 100mA series loop, then translating each box code into a clear, actionable message for the people who dispatch responders. For many universities, municipalities, and military installations, that translation step is exactly where an otherwise dependable system starts to fall short.

What Is Coded Telegraph (McCulloh) Box Fire Alarm Monitoring?
Coded telegraph monitoring, sometimes called McCulloh or Gamewell-style box monitoring, moves alarm information as a series of current pulses over a 100mA loop. Each box on the loop is assigned a numeric code. When a box trips, it interrupts the loop current in a timed pattern that spells out its number, usually repeating for several rounds so the receiving equipment can confirm the code.
The loop is a series circuit. Boxes sit electrically in line with one another, and the head-end supervises the loop for opens, grounds, and current faults. A single loop can carry many boxes, and a campus or city may run a dozen or more loops back to a central point. Because the signaling is electromechanical at its core, these systems are durable and have remained in service for decades, long after the original manufacturers stopped supporting the head-end equipment.
The tradeoff is detail. A raw box code tells you a number, not a building, a floor, or a hazard. Turning "box 214" into "science building, second floor, corrosives storage" requires a decoding layer that maps each code to a human-readable message. Older decoders did this poorly or not at all, and many have simply failed. Digitize covers the mechanics of these circuits in more depth in its discussion of why facilities are moving away from unmaintained 100mA loops.
Why Keep a Coded Telegraph System as a Redundant Dispatch Path?
Many facilities that modernize their monitoring choose not to retire the coded loop. They treat it as a second, independent path to dispatch. If a primary network display or an IP-based readout goes offline, the coded loop still carries box alarms directly to the console over its own dedicated copper.
This redundancy logic is the same reasoning behind dual head-end monitoring architectures. A single reporting path, no matter how modern, is a single point of failure for life-safety signaling. Keeping the coded loop alive as a parallel channel means a network outage, a switch failure, or a maintenance window on the IP side does not blind dispatch to a box alarm. Digitize expands on this principle in its overview of redundant monitoring for continuous protection.
- The coded loop runs on its own physical wiring, independent of the building network.
- A failure in the IP or network-display path does not affect box delivery over the loop.
- Dispatch retains a direct, supervised channel for box alarms during network maintenance.
- The organization can modernize the display side without giving up a proven fallback.
Why Dispatch Often Loses Clear Box Identification
The problem is rarely the loop itself. It is usually the equipment between the loop and the operator. Several failure patterns show up repeatedly:
- The original decoder or annunciator has failed, so box codes no longer resolve into readable messages at the console.
- Dispatch depends entirely on a single network display fed by a third-party system. When that path drops, box identification disappears with it.
- The readout shows a bare code with no building name, location, or responder instructions, forcing the operator to look up the number by hand.
- The equipment waits for every round of the code before it enunciates, adding delay to a life-safety event.
Each of these is a display and decoding problem, not a wiring problem. That distinction matters, because it means dispatch identification can often be restored without touching the field loops or the boxes. Comparable dispatch-side failures on campuses are examined in Digitize's account of what to do when a campus fire alarm monitoring system fails.
What Does Good Dispatch-Side Coded Box Monitoring Look Like?
A monitoring setup that serves dispatch well shares a consistent set of characteristics. These criteria apply whether the site is a university, a municipality, or an industrial campus:
- First-round enunciation. The system displays the box as soon as it confirms one valid round, rather than waiting for the code to repeat several times.
- Custom per-box messages. Each code maps to a programmed message that can include building name, location, hazardous-material notes, and responder instructions.
- Clear acknowledge and clear controls. An acknowledge action silences the audible alert, and a separate clear action removes the alarm only after the operator has handled it.
- A permanent record. Alarms print to a paper tape or log so there is a physical and electronic history of every event.
- Standalone operation. The console decodes the loop directly, so it does not depend on a separate network path to show a box alarm.
- Scroll-back for stacked events. New alarms push prior ones down, but the operator can review earlier events rather than losing them.
How a Standalone Dispatch Monitor Decodes Box Alarms
The Digitize System 3505 Prism LX can sit at dispatch as a standalone monitor that decodes coded telegraph boxes directly. Placed on the loop or its repeater feed, it reads the box code, matches it to a programmed message, and presents the event to the operator. The general sequence looks like this:
- The box trips and taps out its numeric code over the 100mA loop.
- The Prism LX confirms a valid round and immediately displays the matching custom message, rather than waiting for all rounds to complete.
- The event appears with its programmed building name, location, and any responder notes, and prints to the paper record.
- The operator presses acknowledge to silence the audible alert while responders are dispatched.
- After the event is handled, the operator presses clear to remove it from the active display.
Because the unit decodes the loop on its own, it does not rely on a network display to identify a box. That independence is what makes it effective as a redundant dispatch path. An external acknowledge input is also available if dispatch wants a separate physical silence button wired to a contact closure.
How Do You Add Remote Displays Without a Second Head-End?
Some sites want the same alarm information visible in more than one place - for example, on apparatus, at a second dispatch position, or in a fire department office. A remote annunciator PC can mirror the console's alarm information over the network without adding a second head-end.
A standard configuration can support up to 10 remote annunciator PCs using the network display option. Each remote receives alarm information on the first round, the same as the main console. A remote annunciator does not independently clear an alarm; it reflects the state of the main system and clears when the main system receives a restore or clear. Any network-based option should involve the site's IT staff early, since it rides on the facility network. Digitize offers selection criteria for this hardware in its guide to choosing a remote annunciator for fire alarms.
What Are the Options for Modernizing the Coded Loop Itself?
When a site is ready to go beyond the dispatch display and address the loop hardware, there are a few distinct paths. They are not mutually exclusive, and many campuses phase them in over time.
| Approach | What it does | Best fit |
|---|---|---|
| Standalone dispatch monitor | Decodes existing coded boxes at the console with custom messages and first-round enunciation | Sites that need clear dispatch identification without changing field wiring |
| Form Four control center | Replaces a legacy 100mA coded head-end, supervising high current, low current, opens, and grounds across the loops | Sites whose original coded head-end has aged out and needs replacement |
| DET-16 electronic transmitters | Reports up to 16 supervised zone inputs as coded box signals, coexisting with mechanical boxes on the same loop | Interior building connections and new construction moving away from exterior pull hooks |
The DET-16 transmitter is worth a closer look for new interior connections. It behaves like a mechanical coded box on the loop, including its sequential, non-interfering operation, but reports relay contact closures for fire, supervisory, CO, or other building signals. It auto-resets after sending its alarm and can feed a trouble relay back to the local fire alarm panel. For campuses that expect future buildings to place equipment indoors, specifying electronic transmitters early gives architects a clear standard to design around.
A head-end replacement follows the same phased logic that Digitize recommends for replacing legacy fire alarm monitoring without a full rip-and-replace. The coded loop and its boxes stay in service while the head-end and dispatch display are modernized, so the site keeps continuous alarm visibility throughout the transition.
Frequently Asked Questions About Coded Telegraph Dispatch Monitoring
Can a modern monitor decode existing Gamewell or McCulloh box codes?
Yes. A monitor built for coded telegraph input reads the same pulse-coded box numbers the loop already produces. It does not care whether a code originated from a shunt-trip or a local-energy box; it decodes the transmitted box code and maps it to a programmed message. Single-digit through longer multi-digit codes are supported, though very low box numbers can carry a higher risk of false-code concerns and deserve review during programming.
Does dispatch have to wait for all rounds of the code before seeing the alarm?
No. A capable system enunciates after the first valid round while the remaining rounds continue to tap out. This shortens the time between the box tripping and the operator seeing a clear, identified event.
Will keeping the coded loop conflict with a newer network display?
No. The coded loop and a network display can run in parallel. The loop provides a direct, supervised path to dispatch, and the network display provides additional visibility. If one path fails, the other continues to deliver box alarms.
Can electronic transmitters share a loop with existing mechanical boxes?
Yes. Electronic transmitters such as the DET-16 are designed to coexist with mechanical coded boxes on the same 100mA loop. They follow the same ground-return behavior and sequential, non-interfering operation, so they can be added to buildings without replacing the loop.
Are there recurring software license fees for this kind of monitoring?
New systems typically include an annual support agreement as part of the guarantee, which can be renewed later to stay current with updates and features. This differs from a recurring per-seat software license. A local distributor can help scope support and installation; Digitize outlines how that works in its overview for distributors and installers.
Get Clear Box Identification at Your Dispatch Console
If your operators are staring at a bare box number - or at a decoder that no longer works - the fix usually starts at the display, not the field wiring. A standalone dispatch monitor can restore first-round, plain-language box identification while your coded loop keeps running as an independent, redundant path. From there, you can modernize the head-end and add electronic transmitters at your own pace. Digitize engineers work with universities, municipalities, and installers to scope exactly this kind of phased dispatch upgrade. To talk through your current loop and dispatch setup, Get a Free Consultation, call 973-663-1011, or email info@digitize-inc.com for options and pricing.
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 19 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and...Read More