I - 1.2.2. alarm sending, I - 1.2.2 – Fire-Lite IPDACT-2UD Technical Reference User Manual

Page 8

Advertising
background image

IPDACT-UD - Introduction

I-5

Doc.DM385-I

Rev. 2.0

access through echo ICMP packets (ping) to a known address: if the echo
ICMP packets (ping) towards this address fail then a code 356 alarm is
generated from the Contact-ID protocol (Loss of central polling).

Apart from the above codes, the VisorALARM also generates others related
to network backup.

I - 1.2.2.

Alarm sending

When the IPDACT-UD has connectivity with the Teldat VisorALARM, the
former intercepts the telephone line and processes all the incoming and
outgoing calls taking place.

The supported alarm sending protocol is Contact-ID. This format sends
alarms through DTMF digits complying with the following format:

AAAA MM QEEE GG CCC S

where AAA is the client number, MM the type of message, Q an event
qualifier, EEE the type of alarm, GG the group or partition number, CCC the
zone number and lastly S is the frame validation digit.

When the panel opens to send an alarm, the IPDACT-UD provides power and
emits the dialing tone. When the control panel dials the alarm center
telephone number, it issues the Contact-ID handshake and receives the alarm
frame. From this point, the IPDACT-UD sends this alarm to the
VisorALARM.

The control panel is not given the frame sent acknowledgement (kissoff) until
the said acknowledgement is received from the Teldat VisorALARM. If the
IPDACT-UD does not receive the acknowledgement within 2 seconds, this
carries on resending a configured number of times after which connection with
the Teldat VisorALARM is assumed lost and the control panel sends the
alarm over the telephone line. From this point, the IPDACT-UD tries to re-
establish communication with the VisorALARM as previously described. In
cases where the network backup functionality is operative, a failure in sending
an alarm to the main VisorALARM changes into an attempt to establish
communications with the backup VisorALARM and to send the alarms to this
second device. If this attempt also fails, then the control panel takes over the
process of sending the alarms.

It’s essential that the total time, in which the IPDACT-UD deactivates
in cases where communications fail with both the IP receivers, is
greater than the control panel’s highest retry time.

The IP VisorALARM receiver on receiving an alarm from an IPDACT-UD
stores this in a non-volatile internal memory. When the operation has
successfully finished, it sends the acknowledgement to the IPDACT-UD
originating the alarm so that in turn this is sent to the associated control panel.
If the alarm storage memory cannot store the alarm, no acknowledgement is
given.

Advertising