Fike Fault Finding Guide for Engineers

Three genuinely different architectures sit under the Fike name in the UK market, and the single most useful thing an engineer can do before touching a Fike panel with a fault showing is work out which one is actually in front of them. Get that wrong and a perfectly sound diagnostic instinct from one Fike range gets applied to wiring that doesn't work the way you're expecting.

Who this is for

This is written for competent fire alarm engineers working on any Fike panel — Cheetah Xi, Duonet or Twinflex. The experience level assumed is competent engineer. It gives the approach to identifying the architecture and diagnosing from there; the specific fault messages and codes are defined in the Fike documentation for the confirmed product family and firmware, which is the authoritative reference. Work within BS 5839-1 maintenance practice and safe isolation throughout.

Three product families under one name

Cheetah Xi is Fike's standalone addressable panel. Duonet extends the same addressable foundation across a network of panels for larger or multi-building sites. Twinflex is something else entirely: a two-wire system carrying both power and signalling on a single cable pair, blending conventional and addressable characteristics rather than using a dedicated addressable loop. All three carry the Fike name and a broadly similar look on the wall, which is exactly why confirming which one you're dealing with matters more here than it does for most single-architecture manufacturers.

Confirming which one you're actually looking at

Check the panel labelling first, then the installation or commissioning documentation for the site — not the enclosure styling, which doesn't reliably distinguish the ranges from a glance. This confirmation step costs a couple of minutes and prevents a much longer one: applying a Cheetah Xi or Duonet addressable-loop fault-finding sequence to a Twinflex circuit, where the physical wiring simply doesn't behave the same way, wastes time and can lead to a wrong diagnosis on wiring that was never faulty in the way you were testing for.

Cheetah Xi and Duonet: the addressable side

Both report faults through the panel display and status indicators, with events recorded in the log, following the pattern common to addressable systems generally — the display names the affected loop, zone, device or circuit and the fault's general nature, and the log carries timing and sequence, which is what actually resolves an intermittent condition that has already cleared. Duonet adds inter-panel communication as a distinct fault category on top of everything Cheetah Xi already reports, because a networked estate can develop a fault in the link between panels that has nothing to do with any individual loop. The exact display wording and codes for either range come from the Fike documentation for the specific panel and firmware — not from general addressable-panel experience on a different manufacturer's equipment.

Twinflex: a genuinely different wiring problem

Twinflex's two-wire architecture means power and signalling share a single circuit rather than running on a dedicated addressable loop, and that changes how a wiring fault physically presents and how it should be traced compared with Cheetah Xi or Duonet. The conceptual fault categories — circuit, power, device, battery — still hold, but the specific checks, the fault-finding sequence and the display behaviour belong to the Twinflex documentation specifically. Treating a Twinflex circuit fault as though it were an addressable loop fault, because that's the more familiar pattern, is a route to a wrong diagnosis rather than a faster one.

Verification after any repair

Clearing the display indication is not the same as verified repair on any of the three Fike ranges — confirm the fix by re-checking the display and log after a reasonable settling period, and where the repair touched a shared circuit or network element, extend that verification to everything else the fix could plausibly have affected. From general site observations, a repair confirmed only by an indication disappearing, without that follow-up check, is a common reason the same fault resurfaces on a later visit and gets logged as new rather than recognised as incomplete the first time.

Test equipment for a two-wire circuit

Fault finding a Twinflex circuit calls for test equipment and technique suited to a shared power-and-signalling pair rather than the multimeter-and-loop-tester habits that work well enough on Cheetah Xi or Duonet. Basic continuity and insulation resistance testing still has a place, but interpreting readings on a two-wire circuit carrying both functions needs more care than on a dedicated addressable loop, where power and data are more cleanly separable in how a fault presents. From field experience and general site observations, engineers moving onto their first Twinflex job after years of purely addressable work often lose time here simply because the readings don't behave the way loop testing has trained them to expect — worth flagging before the job starts, not discovering partway through it.

Power supply sizing quirks worth knowing

Standby battery and power supply calculations differ in the details between a Twinflex two-wire circuit, which draws power for both signalling and devices over the same pair, and the more conventional dedicated power arrangements on Cheetah Xi or Duonet loops. A power-related fault or a battery duration that doesn't match expectations is worth checking against the load calculation method appropriate to the actual architecture rather than a generic addressable-panel assumption, since the two-wire arrangement's power budget doesn't map directly onto a standard loop's figures.

When the panel predates all three of these

Older Fike installations can predate Cheetah Xi, Duonet and Twinflex altogether, particularly on sites that haven't seen a panel replacement in a long time. Where a call-out turns up equipment that doesn't match the labelling, product literature or general appearance of any of the three current ranges, the correct response is to stop and identify exactly what's actually installed from whatever documentation exists on site, rather than forcing it into the nearest-looking category of the three architectures covered here. Legacy equipment outside the current product range needs its own manual and, in some cases, a specialist familiar with that specific discontinued product, not a best guess extrapolated from the current range's behaviour.

A diagnostic sequence that works for all three

Once the architecture is confirmed, the same underlying discipline applies regardless of which Fike range is fitted: read the display and event log fully before doing anything else, identify the affected loop or circuit, zone, device and fault category, and establish whether the condition is live or intermittent. From there, work systematically outward from the reported location — wiring continuity, device seating and terminations, power as appropriate to the category — using the log's timing information to catch anything intermittent that a single spot-check would miss. Consult the Fike documentation for the specific product family for the exact message meaning, and never substitute a guess for that reference.

Sounder and VAD circuits on the same wiring philosophy

Sounder and visual alarm device circuits on Fike systems generally follow the same wiring philosophy as whichever core architecture is fitted — conventional-style monitored circuits alongside a Twinflex installation, addressable output modules alongside Cheetah Xi or Duonet. A sounder or VAD fault is diagnosed the same way as any other output circuit fault once you know which architecture governs it: check the circuit monitoring indication at the panel, then trace outward to the actual devices, rather than assuming the output side of the system behaves differently from the detection side just because it drives sounders rather than reading detectors.

Recording the architecture at first visit

Because three genuinely different Fike architectures exist and outwardly resemble each other, the single highest-value thing to add to a site's own documentation on a first visit is an explicit, unambiguous record of which one is fitted — Cheetah Xi, Duonet or Twinflex — rather than leaving it as something every future engineer has to work out again from the panel labelling. This is a small addition to a commissioning or handover record that pays for itself the first time a different engineer attends an out-of-hours call and needs to know, before opening the panel, which documentation and test approach to bring. Where a site's existing records don't already make this clear, correcting that gap is worth doing as part of the visit, not just noting it for someone else to fix later.

Servicing whichever system is actually fitted

Routine service follows what the panel itself is reporting. Confirm no unexpected faults are showing, work through the event log for anything recurring or intermittent, verify standby batteries and power supply are healthy, and check circuit or loop and device integrity against the panel's own indications. On Duonet, extend that check to inter-panel communication across the network. From field experience, an unaddressed intermittent event sitting quietly in the log is one of the more common findings across all three ranges, and it deserves proper investigation rather than being cleared without comment.

Cause and effect doesn't change with the wiring architecture

Whichever of the three families is fitted, the cause and effect programmed for the site — what each detection input should make each output do — is a design document independent of whether the underlying wiring is a Cheetah Xi loop, a Duonet network, or a Twinflex circuit. A wiring or circuit fault on any of the three can affect whether a specific input or output actually functions, but it doesn't change what the cause and effect says should happen. After resolving a fault of any kind on a Fike system, verifying the affected input or output against the cause and effect, rather than assuming the fix restored correct behaviour, is the step that turns a plausible repair into a confirmed one.

Safety warning: never consider a Fike fault fully resolved until the affected detection, sounder or interface function has actually been tested against the cause and effect — a cleared display indication is not the same as confirmed correct panel behaviour.

Mistakes that come from crossing the three ranges

One of the more common engineer mistakes on Fike systems is cross-applying experience between the three product families as though the Fike name guarantees identical behaviour — most commonly, treating a Twinflex circuit fault with an addressable-loop mindset, or assuming Duonet's network-level fault categories and loop behaviour apply to a standalone Cheetah Xi panel that has no network to fault on. A second is clearing the indication at the panel before anyone has actually opened and read the stored log entries, throwing away exactly the timing detail an intermittent circuit or loop problem depends on to be traced. A third is skipping the initial confirmation of which product family is actually installed, particularly on an unfamiliar site or one being taken over from another contractor, where the wrong assumption can persist for an entire visit before anyone questions it. Confirming the architecture first, every time, is what gives real confidence in the diagnosis that follows.

When not to rely on this alone

When not to use this article: do not treat it as a substitute for the Fike documentation for the confirmed product family, or for specific fault-code meanings. Those come from the manufacturer's documentation, applied by competent professionals within BS 5839-1.

Relevant standards and documentation

Fault finding follows the Fike documentation for the confirmed product family and BS 5839-1, a code of practice, for maintenance — good site records reference the confirmed product family explicitly, since a generic "Fike" note leaves the next engineer guessing which of three architectures they're dealing with. The legal duty for fire precautions in most non-domestic premises sits under the Regulatory Reform (Fire Safety) Order 2005. Confirm the product family before relying on any specific guidance, and always work to current editions.

Professional disclaimer

This is an educational and workflow resource for competent engineers and does not replace the Fike documentation, the current British Standards, or competent judgement. Verify specific fault messages against the manufacturer's documentation for the confirmed product family and firmware.

Related documentation

Use this with the Fike documentation for the confirmed product family and firmware, and the current BS 5839-1. Confirm which Fike architecture is installed before relying on any specific fault-finding detail, and consult the manufacturer's documentation for specific messages.