FS-8700-48 Fike Cheetah Driver Overview (FieldServer)
This page documents the FS-8700-48 FieldServer driver for the Fike Cheetah protocol. The driver is used in FieldServer/QuickServer gateway applications where data is received from a Fike Cheetah fire detection / monitoring system and exposed to a supervisory system, historian, or building automation interface.
The Fike Cheetah driver is best understood as a consumer of data that is produced by a Cheetah controller. In this operating mode the gateway receives unsolicited messages (i.e., messages pushed by the controller) and updates its internal data map accordingly. This is a common architecture in life-safety and fire monitoring integrations where the controller publishes status, alarms, troubles, and supervisory points without being actively polled by an external client.
The Cheetah system is manufactured by the Fike Corporation (www.fike.com).
FieldServer Driver – Fieldbus FS-8700-48 Fike Cheetah
| Driver Code: | Fike |
| Version: | 1.00a |
| Protocol Documentation: | Fike Protocol Specification |
| Protocol Version: | – |
| Physical Interface: | RS-232 or RS-485 |
| Baud: | 9600 |
| Parity: | None |
| Data bits: | 8 |
| Stop bits: | 1 |
| Handshaking: | None |
The parameters above reflect typical serial settings for the Cheetah protocol as implemented in this driver. In practice, the integrator should confirm the serial configuration on the site controller (RS-232 vs RS-485 selection, termination/bias requirements for RS-485, and port assignment on the Cheetah panel). For RS-485 networks, the physical layer quality (grounding, shielding, correct polarity, and appropriate cable type) is often a determining factor in reliable communication.
Driver Description
Client and Server. The Cheetah Protocol driver allows the Communications Bridge to transfer data to and from devices over either RS232 or RS485 using the Cheetah device protocol. The Cheetah system provides fire detection / monitoring equipment and is manufactured by the Fike Corporation (www.fike.com). The Bridge can emulate either a Server or Client but it should be noted that it can only process unsolicited messages from the Cheetah devices. Thus, it does not provide an active client driver. It is best to consider this driver as a consumer only driver with the data being produced by a Cheetah controller.
In operational terms, this limitation is important for commissioning and troubleshooting:
- The gateway must be connected to a Cheetah controller configured to transmit the required status/alarm information on the serial link.
- If the Cheetah controller is not configured to send the relevant messages (or if the serial link is miswired), the gateway will not have a mechanism to “poll” for missing information.
- Verification typically involves observing inbound serial traffic and confirming that the expected unsolicited frames are being received by the gateway.
This approach is often appropriate for fire/life-safety monitoring integrations where the supervisory system is intended to observe state changes and alarms, rather than perform continuous interrogation of the panel. It also reduces the risk of introducing traffic patterns that could interfere with a controller’s intended operation.
Integration Notes for Field Deployments
When integrating Fike Cheetah systems into building automation or monitoring platforms, the work typically centers around translating panel events into the target system’s point model. Common engineering considerations include:
- Point interpretation: mapping alarms, troubles, supervisory states, and device status into meaningful points.
- Update behavior: understanding which events are sent asynchronously and whether periodic refresh frames are sent.
- Serial layer design: RS-232 point-to-point versus RS-485 multi-drop topologies and associated wiring practices.
- Fail-safe expectations: deciding how the supervisory system should represent loss of communications and stale data.
Because the driver is reliant on unsolicited messages, commissioning should confirm both the serial layer (electrical integrity and correct settings) and the application layer (that the controller is producing the required messages). If an integration requires values that are not produced by the panel’s event stream, that requirement should be identified early because it may require a different configuration approach or different data source.
Fike Cheetah to BACnet/IP Gateway
If your objective is to integrate a Fike Cheetah system into a BACnet/IP building automation system, Chipkin offers a dedicated gateway option that uses the Fike Cheetah protocol on the serial side and exposes data as BACnet/IP on the network side.
Reference link: Fike Cheetah to BACnet/IP QuickServer Gateway
In a typical architecture, the gateway is installed adjacent to the Cheetah controller (RS-232 or RS-485 connection) and provides BACnet/IP objects to the BAS. Engineering tasks usually include confirming the required point list, object naming conventions, and how alarm/trouble conditions should be represented for operator workflows in the BAS.
Frequently Asked Questions (FAQ)
Is this driver an active polling client?
No. Although the bridge can emulate either a Server or Client, it can only process unsolicited messages from Cheetah devices. It should be treated as a consumer-only driver where the Cheetah controller produces the data.
What is the most common cause of “no data” during commissioning?
The two most common causes are (1) serial layer issues (incorrect wiring, wrong interface type, incorrect baud/parity, or RS-485 termination/bias problems) and (2) the Cheetah controller not being configured to transmit the expected unsolicited messages on the connected port.
What physical interfaces are supported?
RS-232 or RS-485 are supported. The typical settings listed for this driver are 9600 baud, 8 data bits, no parity, 1 stop bit, and no handshaking.
Can the gateway be used to integrate to BACnet/IP?
Yes. A common use case is exposing Cheetah panel status/alarm data to a BACnet/IP BAS via a protocol conversion gateway. See the gateway reference section above for the specific product page.
Does the driver require the Fike protocol specification?
The driver references the “Fike Protocol Specification” as protocol documentation. For project work, having the panel’s protocol and point documentation helps ensure the correct interpretation and mapping of transmitted status and alarm conditions.