Signal types, formats and response at the monitoring centre

Marguerite gives Sasha a printout from the signal receiving centre's raw receiver log for one of Bramwell's buildings. It is a column of lines like '1234 18 1 110 01 012'. 'That is what your communicator actually says,' she says. 'Our automation turns it into words on the screen. When the words are wrong, you need to be able to read the line yourself.' This lesson covers how fire alarm signals are coded, how the centre sorts and handles them, and how false and unwanted alarms are managed without delaying a real one.

Kinds of signal

Every signal a fire alarm system sends off the premises falls into one of a few classes, and each class is handled differently:

• Fire alarm signals: a detector, manual station or waterflow switch has operated. These are dispatched to the fire department.
• Supervisory signals: a fire protection system needs attention, such as a valve closed, dry-pipe air low, a fire pump running or off power, or a low temperature in a valve room.
• Trouble signals: a fault in the fire alarm system itself, such as an open circuit, a ground fault, loss of primary power, a low battery or a failed communication path.
• Restorals: a condition has returned to normal.
• Test signals: periodic timer tests, and signals sent during maintenance while the account is on test.

Some systems also send other signals off the premises, such as carbon monoxide alarms, sprinkler supervisory signals from a separate panel, or signals from special hazard systems. The account record says how each is handled.

How signals are coded

Communicators and receivers use standard message formats so that equipment from different makers can work together. Two formats appear most often in Bramwell's work. Contact ID, developed for dialers and still widely used inside newer formats, sends a fixed set of digits: the account number, a message type, a qualifier that says whether the event is new or a restoral, a three-digit event code, a group or partition number, and a zone or user number. SIA DC-09, an internet protocol standard, wraps messages such as Contact ID in a frame with a sequence number, receiver and account identifiers, a time stamp and usually encryption.

The event codes are grouped by type. In the 100 range are alarms: 110 is a general fire alarm, and codes such as 111 smoke, 113 waterflow, 114 heat and 115 pull station refine it. In the 200 range are fire supervisory signals. In the 300 range are system troubles, such as 301 for loss of AC power, 302 for low battery and 373 for a fire loop trouble. Test signals use codes in the 600 range, such as 602 for a periodic test. The qualifier digit is 1 for a new event and 3 for a restoral.

# Decode a Contact ID message (fire-related codes only; illustrative table)
codes = {"110": "fire alarm", "111": "smoke detector", "113": "waterflow", "114": "heat detector",
         "115": "pull station", "200": "fire supervisory", "301": "AC power loss", "302": "low battery",
         "373": "fire loop trouble", "602": "periodic test"}
def decode(msg):
    acct, mt, q, ev, grp, zone = msg.split()
    state = {"1": "new event", "3": "restoral", "6": "previously reported"}.get(q, "unknown")
    return f"account {acct}: {codes.get(ev, 'code ' + ev)}, {state}, group {int(grp)}, zone {int(zone)}"
for m in ["1234 18 1 113 01 004", "1234 18 3 113 01 004", "1234 18 1 200 01 007", "1234 18 1 602 00 000"]:
    print(decode(m))

account 1234: waterflow, new event, group 1, zone 4
account 1234: waterflow, restoral, group 1, zone 4
account 1234: fire supervisory, new event, group 1, zone 7
account 1234: periodic test, new event, group 0, zone 0

The decoder shows a waterflow alarm on zone 4, its restoral, a supervisory signal on zone 7 and a periodic test. When the centre's screen says 'zone 4, gym smoke' but the raw line says event 113 on zone 4, the code is right and the account's zone description is wrong.

# Read the fields of a DC-09 style frame (illustrative sample, no encryption)
frame = '"ADM-CID"0042R1L0#1234[#1234|1113 01 004]_14:22:07,11-03-2026'
proto = frame.split('"')[1]
seq = frame.split('"')[2][:4]
acct = frame.split("#")[1].split("[")[0]
data = frame[frame.index("[") + 1: frame.index("]")]
stamp = frame.split("_")[1]
print("protocol:", proto)
print("sequence:", seq, " account:", acct)
print("message:", data)
print("time stamp:", stamp)

protocol: ADM-CID
sequence: 0042  account: 1234
message: #1234|1113 01 004
time stamp: 14:22:07,11-03-2026

The frame carries a sequence number so the receiver can tell a new message from a repeat, and a time stamp so it can reject old or replayed messages. Real DC-09 traffic is normally encrypted, and the technician never sees it in plain text; the point of the exercise is to understand what the receiver checks.

Priority and handling

At the centre, signals are queued by priority: fire alarms first, then supervisory signals, then troubles. Within a priority, older signals come first. The operator works from the account's instructions. For a fire alarm, the operator calls the fire department's dispatch centre with the address, the type of alarm and the zone description, and then calls the premises or the owner's contacts. For a supervisory signal, the operator calls the owner's contacts and, where the instructions say so, the service company. For a trouble, the operator calls the owner or the service company, and follows up if the trouble does not restore within the time in the instructions.

Several alarms from the same building in quick succession, such as a smoke detector, then waterflow, then a second smoke detector, strongly suggest a real fire. The centre's procedures usually treat a second signal as confirmation, not as a reason to wait.

Verification and unwanted alarms

Unwanted alarms, from cooking, dust, steam, testing without notice or faulty devices, are a large share of the alarms that reach fire departments. Some fire departments allow the centre to make a quick verification call to the premises for certain signals, such as a single smoke detector in a residential suite, before dispatch. Where the authority and the standard allow it, the verification must be quick, and waterflow and manual station signals are normally dispatched at once without verification. Bramwell's role is to keep the system from producing unwanted alarms in the first place, and to make sure test signals are sent only when the account is on test.

# Unwanted-alarm rate from a year of monitoring records (illustrative)
year = {"Riverlight Tower": (14, 1), "Tamarind House": (3, 0), "Willowbank School": (6, 0), "Cartwright DC": (2, 1)}
for site, (unwanted, real) in year.items():
    total = unwanted + real
    share = 100 * unwanted / total if total else 0
    print(f"{site:18s} alarms {total:3d}  unwanted {unwanted:3d} ({share:4.0f} %)  {'review causes' if unwanted >= 5 else ''}")

Riverlight Tower   alarms  15  unwanted  14 (  93 %)  review causes
Tamarind House     alarms   3  unwanted   3 ( 100 %)  
Willowbank School  alarms   6  unwanted   6 ( 100 %)  review causes
Cartwright DC      alarms   3  unwanted   2 (  67 %)

At Riverlight, most unwanted alarms come from cooking near suite entry smoke detectors and from two parking garage detectors that foul quickly. The fix is not to slow down the monitoring but to change the devices: heat detectors where the code allows them in suites near cooking, and a different detector type in the garage, with the designer's agreement.

Putting an account on test

Before any work that could send signals, the technician calls the centre, gives the account number and a pass code, and asks for the account to be placed on test for a set time. Signals received while the account is on test are recorded but not dispatched. At the end of the work, the technician calls again, asks what was received, compares it with what was sent, and takes the account off test. An account left on test after the technician leaves is a building that cannot summon the fire department, so many centres put a time limit on test status and call back when it expires.

# Compare what was sent during testing with what the centre received
sent = ["110 zone 1", "113 zone 4", "200 zone 7", "373 zone 2", "301"]
received = ["110 zone 1", "113 zone 4", "373 zone 2", "301"]
missing = [s for s in sent if s not in received]
print("received", len(received), "of", len(sent))
for m in missing:
    print("not received:", m, "- check programming and path")

received 4 of 5
not received: 200 zone 7 - check programming and path

Records

The centre keeps every signal, call and action with the time. Bramwell can ask for an event history for any account, and the service report for a test includes the centre's confirmation of what it received. When a building has a fire, the records show when the first signal arrived, when the fire department was called and what the operator was told, which is why the account information and the zone descriptions matter so much.

Common signal problems and their causes

When a building's signals arrive at the centre wrongly, the cause is usually one of a few things. Sasha keeps a list in her notebook:

• Wrong description: the panel's zone numbers changed and the account didn't. Fix the account and retest the points.
• Wrong signal type: the communicator reports a supervisory condition with a trouble code, or an alarm with a supervisory code, because of a programming error. The operator then follows the wrong procedure. Fix the communicator's programming.
• Missing restorals: the communicator reports a condition but not its restoral, so the centre's screen shows a building still in trouble after it was fixed. Check the communicator's settings for restoral reporting.
• Repeated signals: a device that keeps going in and out of trouble sends dozens of signals, burying more important ones. Fix the device, not the reporting.
• Late test signals: the communicator's test timer is set differently from what the centre expects, or the clock is wrong. Align them.

# Spot a chattering point in a day of events (illustrative)
events = ["zone 12 trouble", "zone 12 restore"] * 23 + ["zone 4 supervisory", "zone 4 restore", "AC loss", "AC restore"]
from collections import Counter
c = Counter(e.split()[0] + " " + e.split()[1] for e in events)
for point, n in c.most_common():
    print(f"{point:9s} {n:3d} events  {'chattering - repair the device' if n > 10 else ''}")

zone 12    46 events  chattering - repair the device
zone 4      2 events  
AC loss     1 events  
AC restore   1 events

Each of these is fixed at the building, then proved by testing the affected points to the centre and checking the result on the operator's screen or the centre's event report.

Signals the fire department receives

Fire departments differ in what they want from monitoring centres. Some want only fire alarm signals; others also want supervisory signals from sprinkler systems in certain buildings; some want particular information, such as whether the building has a known hazard or a key box. The account instructions reflect the fire department's requirements, and the technician confirms them with the authority when setting up a new account.

Some fire departments also ask monitoring centres to pass on information about the building's condition when they report an alarm, such as whether the alarm is a second signal from the same building or whether the owner has reported work on the system. The account instructions record these requests so that every operator handles the building the same way.