Field perspective
Where this usually goes wrong
Communication troubles are often split between three systems: the fire alarm panel, the communicator, and the supervising station. The fastest path is to prove each handoff instead of assuming the device with the trouble LED is the cause.
Define the communication architecture
Identify whether the site uses cellular, IP, dual-path, radio, legacy telephone lines, or a combination. Document how the fire alarm panel hands events to the communicator: Contact ID, SIA, relay inputs, serial data, network gateway, or another listed interface. Also identify which trouble outputs return to the FACP.
Check local power and panel signaling
Verify communicator AC or auxiliary power, battery if provided, antenna connections, Ethernet link status, and local trouble indicators. Then prove that the fire alarm panel is actually presenting the event to the communicator. A central station cannot receive a signal that never leaves the FACP, and a healthy communicator cannot correct a misprogrammed account code or disabled reporting group.
Verify the external path
For IP, verify the approved network connection, addressing method, gateway, DNS or required ports according to the communicator manufacturer and site IT policy. For cellular, check signal strength, antenna location, account activation, carrier status, and whether the communicator is registered. For legacy phone paths, verify line presence, seizure arrangement, dialing requirements, and whether the service provider has changed the line type.
NAPCO StarLink: daily tests and intermittent cellular signal
In fire-alarm service, “StarLink” usually means the NAPCO StarLink fire communicator. A manual signal received by the central station proves that one transmission succeeded; it does not prove the scheduled 24-hour test has been arriving consistently.
Determine whether the fire alarm panel or the StarLink communicator is configured to generate the daily test. NAPCO supports both arrangements, and blindly enabling both can create duplicate test events that mask a missing intended timer. Compare the exact receiver event and timestamp to the expected source.
For current StarLink MAX2 Fire equipment, the D3 green RF indicator provides a local RF-strength indication and NAPCO documents at least two blinks as minimally acceptable. If a reported signal swings substantially — for example roughly -95 to -115 dBm — treat that instability as a strong clue, not as a universal dBm pass/fail threshold. Check antenna/connection/location, approved non-resettable power, NOC Signal Log/check-in history, and the timing of the actual communication fault.
Coordinate with the supervising station
Place the system on test before sending signals. Confirm the correct account, receiver, format, partition or area, and expected event codes with the supervising station. Send a controlled alarm, supervisory, and trouble signal as required by the service scope and confirm both receipt and restoration. A local “kiss-off” or success indication is useful, but central-station confirmation closes the loop.
Document the handoff clearly
Record whether the failure was at the FACP output, communicator hardware, local network or carrier path, account programming, or central-station configuration. If another party owns the network or cellular account, document exactly what was proven so the next step is actionable rather than a generic “IT issue.”
Common mistakes to avoid
- Power-cycling the communicator before recording the original trouble and diagnostic status
- Blaming cellular or IP service before proving the FACP is sending the event
- Changing account or receiver settings without central-station coordination
- Ending the call without confirming an actual test signal at the supervising station
- Treating NAPCO StarLink as satellite internet when the fire-alarm context is cellular communicator service
Field checklist
- Identify primary and backup communication paths
- Record local communicator diagnostics before resetting
- Verify panel-to-communicator event handoff
- Check network/cellular/phone path per manufacturer procedure
- Confirm account and receiver data with the supervising station
- Transmit and verify test signals and restorals
- Document the exact failed handoff and corrective action
Frequently asked field questions
Why can a NAPCO StarLink manual test work while I still get a daily-test communication fault?
The manual transmission only proves the path worked at that moment. The scheduled panel- or communicator-generated 24-hour test can still be missing, late, or affected by intermittent cellular signal or power.
Should both the fire panel and StarLink send a 24-hour test?
Not automatically. Confirm the approved connection and monitoring method. Duplicate timers can mask a missed intended test, so identify which device is responsible for the scheduled report.
What to verify before you act
Use this article to organize the field problem, then verify the requirement or permitted method in the documents that govern the job:
- The adopted NFPA 72 edition and applicable building/fire code provisions
- Manufacturer installation, service, compatibility, and programming documentation
- Approved drawings, sequence of operations, project specifications, and AHJ direction
Primary references to check
These are the source documents I would verify for this topic before making a field, design, or compliance decision:
- NFPA 72 — supervising-station transmission requirements in the adopted edition
- Communicator installation/programming manual — reporting paths, supervision, and account configuration
- Monitoring-center receiver/format documentation and current account/zone list
Important limitation
This guide is a field-oriented starting point, not a substitute for the adopted code, approved drawings, project specifications, manufacturer instructions, site safety procedures, or the authority having jurisdiction. Do not bypass a listed protection feature or leave a required system impaired without following the approved impairment process.