Bass Home :: SIA Standard Communications Protocol
SIA Standard Communications Protocol

 

Digital Communications Standard -

 “SIA Format” Protocol -

for Alarm System Communications

SIA DC-03-1990.01 (R2000.11)

Sponsor
Security Industry Association

Copyright © 1990 - 2000 – SIA

Publication Order Number: 14083


FOREWORD

This standards document is published by the Security Industry Association (SIA) and was developed and adopted by a consensus of industry volunteers in accordance with SIA’s standards development policies and procedures.  It is intended to facilitate product compatibility and interchangeability, to reduce misunderstandings between manufacturers and purchasers, and to assist purchasers in obtaining the proper products to fulfill their particular needs.

 

The existence of this or any SIA standards document shall not prevent any SIA member or non-member from manufacturing, selling, or using products not conforming to this or any SIA standard.  SIA standards are voluntary.  SIA encourages the use of this document but will not take any action to ensure compliance with this or any other SIA Standard.

 

SIA assumes no responsibility for the use, application or misapplication of this document.  Industry members using this document, particularly those having participated in its development and adoption, are considered by SIA to have waived any right they might otherwise have had to assert claims against SIA regarding the development process of this standard.

 

Although some SIA standards establish minimum performance requirements, they are intended neither to preclude additional product features or functions nor to act as a maximum performance limit.  Any product the specifications of which meet the minimum requirements of a SIA standard shall be considered in compliance with that standard.  Any product the specifications of which exceed the minimum requirements of a SIA standard shall also be considered in compliance with the standard, provided that such product specifications do not exceed any maximum requirements set by the standard.  SIA standards are not intended to supersede any recommended procedures set by a manufacturer for its products.

 

SIA reserves the right to revise this document at any time.  Because SIA policy requires that every standard be reviewed periodically and be either revised, reaffirmed, or withdrawn, users of this document are cautioned to obtain and use the most recent edition of this standard.  Current information regarding the revision level or status of this or any other SIA standard may be obtained by contacting SIA.

 

Requests to modify this document are welcome at any time from any party, regardless of membership affiliation with SIA.  Such requests, which must be in writing and sent to the address set forth below, must clearly identify the document and text subject to the proposed modification and should include a draft of proposed changes with supporting comments.  Such requests will be considered in accordance with SIA’s standards development policies and procedures.

Written requests for interpretations of a SIA standard will be considered in accordance with SIA’s standards development policies and procedures.  While it is the practice of SIA staff to process an interpretation request quickly, immediate responses may not be possible since it is often necessary for the appropriate standards subcommittee to review the request and develop an appropriate interpretation.

 

Requests to modify a standard, requests for interpretations of a standard, or any other comments are welcome and may be sent to:

Standards
Security Industry Association
635 Slaters Lane, Suite 110
Alexandria, VA,  22314

E-mail:
Standards@SIAOnline.org

This document is owned by the Security Industry Association and may not be reproduced, in whole or part, without the prior written permission from SIA.

ACKNOWLEDGEMENTS

 

This standard was developed by the SIA Digital Communications Standards Subcommittee. The voting members of the Subcommittee are listed below.

SIA gratefully acknowledges the efforts of the many volunteers from the security industry that helped the Subcommittee to develop this standard.

SIA Digital Communications Standards Subcommittee, November 1990 (Baseline of the Standard)

Chairman of the SIA Standards Committee:
Silent Knight Security Systems ................................................. Theodore A. Nesse

Chairman of the SIA Digital Communications Standards Subcommittee:
Pierson and Associates............................................................. Hugh F. Pierson

Contributing Members of the SIA Digital Communications Standards Subcommittee:

            Ademco................................................................................... Alan Wachtel

            Caddx-Caddi Controls............................................................... Jim Stevens

            Caddx-Caddi Controls............................................................... Deborah Traylor

            Detection Systems.................................................................... Jim Berube

            Detection Systems.................................................................... Jim Beseau

            Digital Monitoring Products........................................................ Rick Britton

            Pierson and Associates............................................................. Hugh Pierson

            Radionics................................................................................. Drew Chernoy

            Radionics................................................................................. Kam Oza

            Sentrol..................................................................................... David Terrett

            Silent Knight............................................................................. Ted Nesse

            Voyager Technologies.............................................................. Ron Fraser

 

Company Voting Members of the SIA Digital Communications Standards Subcommittee:

            ADT......................................................................................... Tony Fague

            ADT......................................................................................... Tom Mitchell

            Alarm Monitoring Service.......................................................... D. A. DeRoche

            Aritech-Moose.......................................................................... Kirk Phillips

            Detection Systems.................................................................... Tom Benedett

            FBI.......................................................................................... Robert Orlando

            Genesis Engineering................................................................. Steve Hayes

SIA Digital Communications Standard Committee, February (1995 Revision of the standard)

Chairman of the SIA Standards Committee:
L. T. Fiore, Inc. ....................................................................... Louis T. Fiore

Chairman of the SIA Digital Communications Standard Committee:
............................................................................................... Frank Clark

SIA Staff Administrator.......................................................................... L. Virginia Williams

Company Voting Members of the SIA Digital Communications Standards Subcommittee:

            Ademco................................................................................... Rich Hinkson

            Aritech Corp............................................................................ David S. Terrett

            C&K Systems........................................................................... Steve Suthers

            Dice Corporation...................................................................... Clifford Dice

            DigiFlash Corporation............................................................... Jian Zheng

            Europlex Technologies.............................................................. John Collins

Keltron Corporation............................................................................... Steve Sargent

Micro Key............................................................................................ Wayne Torrens

Osborne-Hoffman, Inc........................................................................... Ed Hoffman

Silent Knight......................................................................................... Jim Walters

SIMS/CSM Fax..................................................................................... Kenneth Utley

Sur-Gard............................................................................................. Jeffrey He

TeleLarm.............................................................................................. U.L.F. Lindsten

 

SIA Digital Communications Standard Committee, November (2000 Revision of the standard)

Chairman of the SIA Standards Committee:
ADT ........................................................................................ Bill Moody

Chairman of the SIA Digital Communications Standard Committee:
Radionics................................................................................. Rich Ader

SIA Staff Administrator.......................................................................... Wadei Powell

Company Voting Members of the SIA Digital Communications Standards Subcommittee:

            ACM Securidad Ltd.................................................................. Richard Arcuch

            Advanced Algorithms, Inc.......................................................... Greg P. Spar

            Detection Systems/Radionics.................................................... Rich Ader

            DSC, Ltd.................................................................................. David P. Clark

            Frank J. Meiners & Assoc......................................................... Frank J. Meiners

            Sur-Gard................................................................................. Stephan Frenette     ...............................................................................................

 

 

Revisions History

The following are the major revisions of this standard. Continuous maintenance of data codes is handles separately, as described in section 6.1.3 Data Code Additions.

 

FEBRUARY 1993

Baseline Release

 

OCTOBER 1997

 

Section

Change

1.3.4 (f)

Removed requirement of CCITT compatibility.

2

Added rom to glossary.

4.2.1.2.8

Added Name modifier.

4.2.1.2.9

Added Level modifier.

4.2.1.2.10

Added Value modifier.

4.2.1.2.11

Added Path modifier.

4.2.1.2.12

Added Route Group modifier.

4.2.1.2.13

Added Sub-Subscriber modifier.

4.3.4

Inserted Origin ID Block.

4.3.9.x.x

Added Video Block capabilities.

7.1.1

Modified requirement.

7.1.8

Added section.

7.2

Added section.

Appx A

Added “Address Field” column to Table 6.

Appx A

Added the following codes to Table 6:
AN, AS, BM, BV, BZ, CD, CM, CR, CS, DA, DB, DE, DH, DJ, DL, DM, DN, DP, DQ, DV, DW, DX, DY, DZ, EA, EE, EX, EZ, FC, FM, FZ, IA, IR, JK, JP, JY, JZ, NA, NC, NR, NS, NT, OH, OL, OS, RY, TC, TP, TT, XA, XH, XJ, XL, XM, XQ, XS, XX, YA, YH, YZ, ZU.

Appx B

Moved Block Format examples from within the text to the appendix.

Appx B

Corrected error in Example 1.

Appx B

Added Data Code Packets examples.

Appx B

Added Modifier Code examples.

Appx C

Added Interpretations.

 

 

 

 

 

 

NOVEMBER 1999

 

Section

Change

Table of Contents

Changed section and page numbering

Cover & Headers/ Footers

Revised nomenclature & designation

2, 3.1

Added new sections (and renumbered existing sections accordingly)

6

Renumbered section 6 (was 6 & 7)

Appx A

Added the following codes to Table 6:

BD, BE, TH, TJ, YI, YJ

Appx A

Made changes to the following codes in Table 6:

UY, UZ

Appx B

Added examples for the following Data Code Packets:

BD, BE, TH, TJ, YI, YJ

Index

Removed Index

 

NOVEMBER 2000

Section

Change

Appendix A

Added the following codes to Table 6:

AA, AB, BG, CO, CQ, CX, DI, EJ, EM, EN, ES, FG, FL, FQ, FV, FW, MI, NM, OQ, OU, OV, SC, TW, TZ, UG, YU

Appendix B

Added examples for the following Data Code Packets:

AA, AB, BG, CO, CQ, CX, DI, EJ, EM, EN, ES, FG, FL, FQ, FV, FW, MI, NM, OQ, OU, OV, SC, TW, TZ, UG, YU

 

 

 

 


Table of Contents

 

1.0              INTRODUCTION....................................................................................................................................... 1

1.1     SCOPE.................................................................................................................................................................................................... 1

1.2     PURPOSE.............................................................................................................................................................................................. 1

1.3     ESTABLISHMENT OF NEED................................................................................................................................................................ 1

1.3.1           HISTORY AND REQUIREMENT....................................................................................................................................... 1

1.3.2           CURRENT CAPABILITIES................................................................................................................................................ 2

1.3.3           ALTERNATIVES................................................................................................................................................................ 2

1.3.4           OBJECTIVES..................................................................................................................................................................... 2

2.0              REFERENCE DOCUMENTS................................................................................................................... 2

3.0              CONVENTIONS AND DEFINITIONS....................................................................................................... 2

3.1               CONVENTIONS........................................................................................................................................................................... 2

3.2               DEFINITIONS................................................................................................................................................................................ 3

4.0              TRANSMISSION PROTOCOLS.............................................................................................................. 4

4.1               COMMUNICATION SESSION.................................................................................................................................................... 4

4.1.1           HANDSHAKE TONE................................................................................................................................................ 4

4.1.2           SPEED SYNCHRONIZATION SIGNAL.................................................................................................................. 4

4.1.3           DATA BLOCKS........................................................................................................................................................ 4

4.1.4           CONTROL SIGNALS............................................................................................................................................... 6

4.1.4.1        FLAGS................................................................................................................................................... 6

4.1.4.2        ACKNOWLEDGEMENTS.................................................................................................................... 6

4.2               SIGNAL PROTOCOL.................................................................................................................................................................. 7

4.2.1           FREQUENCY ASSIGNMENTS................................................................................................................................ 7

4.2.2           TRANSMISSION RATES........................................................................................................................................ 7

4.2.3           TRANSMISSION MODE......................................................................................................................................... 7

4.3               BYTE PROTOCOL....................................................................................................................................................................... 7

4.3.1           START BIT............................................................................................................................................................... 7

4.3.2           DATA BITS............................................................................................................................................................... 7

4.3.3           PARITY BIT.............................................................................................................................................................. 8

4.3.4           STOP BITS............................................................................................................................................................... 8

4.3.5           BYTE TIMING........................................................................................................................................................... 8

4.4               BLOCK PROTOCOL................................................................................................................................................................... 8

4.4.1           DATA GROUPS....................................................................................................................................................... 8

4.4.2           TIMING RESTRAINTS............................................................................................................................................. 8

4.4.3           STANDBY MODE..................................................................................................................................................... 8

4.4.4           RE-TRANSMISSION............................................................................................................................................... 8

4.5               SESSION PROTOCOL............................................................................................................................................................... 9

4.5.1           ESTABLISHING CONTACT.................................................................................................................................... 9

4.5.2           CALL TERMINATION.............................................................................................................................................. 9

5.0              DATA FORMAT (BLOCK PROTOCOLS)............................................................................................... 9

5.1               SYSTEM BLOCKS...................................................................................................................................................................... 9

5.2               INFORMATION BLOCKS............................................................................................................................................................ 10

5.2.1           GENERAL CONVENTIONS..................................................................................................................................... 10

5.2.2           CONTROL BLOCK.................................................................................................................................................. 13

5.2.3           ENVIRONMENTAL BLOCK.................................................................................................................................... 13

5.2.4           EVENT BLOCK........................................................................................................................................................ 13

5.2.5           PROGRAM BLOCK................................................................................................................................................. 13

5.3               SPECIAL BLOCKS...................................................................................................................................................................... 14

5.3.1           CONFIGURATION BLOCK...................................................................................................................................... 14

5.3.2           ACCESS PASSCODE BLOCK............................................................................................................................... 15

5.3.3           ACCOUNT BLOCK.................................................................................................................................................. 15

5.3.4           ORIGIN ID BLOCK................................................................................................................................................... 15

5.3.5           ASCII BLOCK........................................................................................................................................................... 15

5.3.6           EXTENDED BLOCK................................................................................................................................................. 15

5.3.7           LISTEN-IN-BLOCK.................................................................................................................................................. 15

5.3.8           V-CHANNEL BLOCK............................................................................................................................................... 16

5.3.9           VIDEO BLOCK......................................................................................................................................................... 16

6.0             COMPATIBILITY....................................................................................................................................... 17

6.1               INDICATIONS OF COMPATIBILITY.......................................................................................................................................... 17

6.1.1           REVISION DATE...................................................................................................................................................... 18

6.1.2           COMPATIBILITY LEVELS...................................................................................................................................... 19

6.1.3           DATA CODE ADDITIONS....................................................................................................................................... 20

6.1.3.1        REQUESTS FOR DATA CODE ADDITIONS..................................................................................... 20

6.1.4           HANDLING UNRECOGNIZED EVENT BLOCK DATA.......................................................................................... 20

APPENDIX A – CODE DEFINITIONS................................................................................................................................................................................. 21

APPENDIX B – EXAMPLES............................................................................................................................................................................................... 29

BLOCK FORMATS.......................................................................................................................................................................................... 29

CONTROL BLOCK................................................................................................................................................................................ 29

ENVIRONMENTAL BLOCK.................................................................................................................................................................. 29

                              NEW EVENT BLOCK............................................................................................................................................................................ 29

                              OLD EVENT BLOCK............................................................................................................................................................................. 29

                              PROGRAM BLOCK............................................................................................................................................................................... 29

                              CONFIGURATION BLOCK.................................................................................................................................................................... 30

                              ACCESS PASSCODE BLOCK............................................................................................................................................................. 30

                              ACCOUNT BLOCK................................................................................................................................................................................ 30

                              ORIGIN ID BLOCK................................................................................................................................................................................. 30

                              ASCII TEXT BLOCK.............................................................................................................................................................................. 30

                              EXTENDED BLOCK............................................................................................................................................................................... 30

                              LISTEN-IN BLOCK................................................................................................................................................................................ 31

                              V-CHANNEL REQUEST BLOCK.......................................................................................................................................................... 31

                              V-CHANNEL HEADER BLOCK............................................................................................................................................................ 31

                              V-CHANNEL TERMINATOR BLOCK................................................................................................................................................... 31

                              VIDEO BLOCK....................................................................................................................................................................................... 31

                    DATA CODE PACKETS.................................................................................................................................................................................. 32

                    MODIFIER CODES........................................................................................................................................................................................... 39

APPENDIX C – INTERPRETATIONS................................................................................................................................................................................ 40


 

 

                                                            Digital Communications Standard -

                                “SIA Format” Protocol –

                         for Alarm System Communication

                                                                                                           

                                                  Copyright © 1990-1999 Security Industry Association

 


1.     INTRODUCTION

1.1.  Scope

This specification describes a standard for digital com­munication to be used in the alarm industry, with possible future uses in the areas of energy control and facilities monitoring and management.

 

The standard is voluntary and self-enforcing.  A RE­CEIVER and TRANSMITTER designed to meet this standard must be capable of receiving and transmitting to other manufacturers' equip­ment.  In case of incompati­bility, the problem should be resolved through manufac­turer to manu­facturer discussions.  The Digital Communications Standards Subcommittee will provide interpretations of the standard and act as an arbitration body if the problem cannot otherwise be re­solved.

 

This communication standard is designed to be open ended.  The block format al­lows for a vari­able length on the account number and data sections of the message.  The generalized message format allows for a theoretically un­limited length mes­sage in the form of multiple blocks (however, practical limits must be considered).  The open- ended design will allow for almost un­limited expansion within the provi­sions of the standard.

 

Requests for general revisions or additions to this standard should be submitted in writing to SIA.  All requests will be forwarded to the SIA Digital Communications Standards Subcommittee for approval.  Minor changes, if approved, will be issued as addendums to the current revision of the standard.  Major changes or accumulations of minor changes will result in a major revision (date) of the standard.  Discretion as to the extent of a change and if a major revision is necessary will be at the recommendation of the Subcommittee or the Subcommittee chair.

1.2.  Purpose

The purpose of this Standard is to establish a common signaling format, which can be adopted by any man­ufac­turer of digital communicators or receivers.  The standard communication format will provide an across-the-board compatibility of equipment designed to the Standard re­gardless of manufacturer.

 

1.3.  Establishment of Need

 

1.3.1.   History and Requirement

The existing communication formats were developed by manufacturers of digi­tal communicators as the products were being developed.  The formats are not always com­patible and there is no pub­lished documen­tation of their require­ments.  At the time of their conception, they were adequate to provide the type of service for which they were de­signed.  However, with the large growth in the field of digital alarm point monitoring, the need for a sys­tem with a higher data rate, greater data ca­pacity, and expansion potential, has become more critical.  An­other growing field of application is that of energy manage­ment, which requires the ability of bi-directional commu­nications.  With these re­quirements in mind, manufactur­ers have developed still more commu­nication formats, most of which are incompatible.

 

1.3.2.   Current Capabilities

There are currently four major categories of data formats on the mar­ket.  They are (1) Serial Pulse Tone, (2) FSK, (3) Bit Position, and (4) DTMF.  Each of these categories may have as many as four different formats or capa­bili­ties which are not always compatible with others, even in the same cate­gory.

 

1.3.3.   Alternatives

Alternatives considered during the course of the developing commit­tee meetings included FSK, DTMF and variations on the Serial Pulse Tone meth­ods.  Considering speed, reliability and cost factors, as well as the po­tential long range re­stric­tions of the switched telephone networks, half-duplex asyn­chronous FSK modulation was selected.

 

1.3.4.   Objectives

(a)        Spend minimum practical time on line per trans­ac­tion, to minimize the number of receivers re­quired to handle the traffic and minimize the time the line is seized and not available to the customer.

(b)        Minimize the transmission error rate.

(c)        Allow for a variable length data message.

(d)        Be amenable to transmission and reception by eco­nomical and reliable means, with the main emphasis on the trans­mission aspect as transmitters greatly out­number receivers.

(e)        Anticipate the future need for significant data flow from the central station to the protected premises.

(f)         Be compatible with FCC stan­dards.

(g)        Provide a secure data path not easily accessed with avail­able hardware, such as personal comput­ers, modems, etc.

2.     REFERENCE DOCUMENTS

SIA Standards:

SIA DC-01 - Digital Communication Standard - Computer to Receiver Interface Protocol

SIA DC-04 - Digital Communication Standard - “SIA 2000” Protocol for Alarm System Communications

 

Telecommunications Standards:

Bell 103  (This standard is no longer in print, but information on its relevant contents can be found in the Manual of Embedded Modem Design, Volume 1: K-Series Modem ICs, available from TDK Semiconductor Corporation.)

 

Underwriters Laboratory Standards

This standard is intended to comply with U.L. requirements.

 

 

Regulatory Agency Compliance

This specification is intended to comply with all relevant sections of the Rules and Regulations of the Federal Communications Commission.  For overseas applications, products designed to this standard must also meet the re­quire­ments set forth by the telecommunication authority for the particular region.

 

3.     CONVENTIONS AND DEFINITIONS

 

3.1      Conventions

Units of Measurement. 
In accordance with SIA Policy, the units of measurements used throughout this publication are the units of the System  International d’ Unites (SI), commonly known as metric units.  Equivalent English Units, enclosed in parenthesis, are also used in this publication.  These equivalent English Units are approximate conversions and are provided for easy reference.

 

Special Capitalization. 
Alarm sequence events, alarm system commands and states, and digital communication codes transmitted by the control panel to the central station are capitalized within the text of this standard.

 

Nomenclature and Identification of Sections. 
Sections within this standard are identified and referenced by the number preceding each section.  Unless otherwise specified, references to a section refer to only that section and not to subsequent subsections within the section.

 

Tolerances.

Unless otherwise specified, the tolerance for measurements specified within this standard shall be 10 percent (±10%).

 

Binding Language
This standard uses the term “shall” to convey binding requirements. 

The term “may” is used to convey features that are allowed but not required. 

Terms such as “is”, “are”, “will”, and others are used to convey statements of fact for advisory purposes only. 

The annotation “Note:” also precedes advisory information. 

Where this standard is silent on a feature, the feature is permitted so long as it is not in conflict with the requirements contained herein. 

Unless otherwise noted, appendices contain non-binding information provided to help clarify requirements but not to add requirements.

 

 

 

3.2 Definitions

Account, The portion of a transmitted message which contains the information identifying a particular lo­cation; ac­count number.

Acknowledgement, A signal sent from the RECEIVER to the TRANSMITTER indicating that the data has been re­ceived.  A Positive Acknowledgement means data was received without any detected errors.  A Negative Ac­knowledgement means data was re­ceived, but there were detected errors.  Also used as a command to initiate trans­mission.

 

Area, A defined section of the protected system that can be armed and disarmed independently.  Areas are num­bered consecutively beginning with 1.  A system must have at least one area, area 1.

 

Baud Rate, A measurement of transmission speed.  The number of signal elements per second based on the dura­tion of the shortest element.

 

Bit, The smallest element of digital information.  The value of a bit is either one or zero (true or false).

 

Block, A block of information consists of account or data information and includes the header and par­ity in­forma­tion.

 

Bypass, A zone state that ignores input changes re­gardless of the system arming state.  A bypassed zone will NOT cause an alarm event.

 

Byte, A byte is a group of eight (8) bits.  One alpha-numeric character can be repre­sented by one byte.

Close, The act of arming a system.

 

Data, That part of the transmitted data which refers to alarm point information or status of the sensors at a par­ticu­lar location.

Digital, Information in discrete or quantized form; not continuous.

Duplex Transmitter, One capable of receiving data from a central station.

ETC, or Early To Close, an event created by the arm­ing of a system before a specified time.

ETO, or Early To Open, an event created by the dis­arming of a system before a specified time.

FSK, Frequency Shift Keying.  A signaling method for transmitting digital information which uses a discrete au­dio frequency for a logic one and a different frequency for a logic zero.

FTC, of Fail To Close, an event created by a system at a preset time if it remains in the disarmed state.

FTO, or Fail To Open, an event created by a system at a preset time if it remains in the armed state. 

Full-Duplex, A mode of data transmission in which the data traffic in both directions can occur simultaneously.

Data Groups, A set of two or more blocks requiring only one acknowledgement, after the last block.

GMT, or Greenwich Mean Time, is the current time in Greenwich, England.  This is considered time zone 0.  Other time zones are East or West of time zone 0.  Time zones to the West are indicated by positive numbers, time zones to the East are indicated by negative numbers.

Half-Duplex, A mode of data transmission in which the data traffic travels in only one direction at a time, al­though the communication medium may allow full-duplex operation.

Handshake, A signal sent by the RECEIVER which indicates to the TRANSMITTER that a connection has been established.

Kiss Off, A term currently used in the industry for a positive acknowledgement.

LTC, or Late To Close, an event created by the arming of a system after a specified time.

LTO, or Late To Open, an event created by the dis­arm­ing of a system after a specified time.

Mark Frequency, The discrete audio frequency of the FSK signal used as the information bit, and de­fined as a logic one (1).

Most Significant, The digit or bit which represents the highest value or weight.

Open, The act of disarming a system.

Parity Bit, A redundant bit added to a record to allow the RECEIVER to detect an odd num­ber of bit er­rors in that record.

Parity Word, A record in which the data are redundant bits which allow the RECEIVER to de­tect an odd num­ber of bit errors in each column of data bits in that block.

Point, An electronically addressable sensor, sometimes used interchangeably with the term sensor. The term is usually used in multiplex alarm systems or for RF (wireless) sensors.

RECEIVER, The Digital Receiver located in the Cen­tral Station or Monitoring Location.

Recipient, The unit, TRANSMITTER or RECEIVER, currently in the process of receiving in­formation (decoding FSK tones) from the opposing unit.

Reverse Channel, The transmission of data blocks in a direction opposite the last block transfer.

ROM Read Only Memory

Sender, The unit, TRANSMITTER or RECEIVER, currently in the process of transmitting information (emitting FSK tones) to the opposing unit.

Simplex Transmitter, One which is only capable of transmitting information to the central station RE­CEIVER.

Sounder, A device at the TRANSMITTER site used to signal an event such as fire.  Sounders are numbered con­secutively beginning with 1.  A system is not required to have a sounder.

Space Frequency, The discrete audio frequency of the FSK signal which is the complement of the mark fre­quency, and defined as logic zero (0).

Subscriber, The person(s) at the TRANSMITTER site who operate and/or have access to the system.

TRANSMITTER, The Digital Communicator located at the protected premise.

User, See Subscriber.

Warning, A device at the TRANSMITTER site used to alert the subscriber to an event such as power failure.  Warning devices are numbered consecutively beginning with 1.  A system is not required to have a warning device.

Weekly Minutes, the measure of time as minutes be­ginning with 0 for Sunday at 00:00, and ending with 10079 for Saturday at 23:59.

 

 4.  TRANSMISSION PROTOCOL

This section describes the basic transmission protocol of a commu­nication session, and the protocols for the four layers of transmission: signal, byte, block and session. 

 

4.1      Communication Session

The TRANSMITTER to RECEIVER communication session is composed of four basic elements: Hand­shake Tone, Speed Synchronization Signal, Data Blocks, and Control Signals (Acknowledgements).  The Handshake is a sin­gle tone and the Speed Synchronization Signal is com­posed of two tones repeated in sequence.  The Data Blocks contain Bell 103 FSK encoded data.  The Ac­knowledgement Blocks can be either a single tone like the Hand­shake, or Data Encoded like a Data Block, based on the re­quirements established by the TRANSMITTER.

 

The Handshake Tone is produced only by the RE­CEIVER.  Its pur­pose is to signal the TRANSMITTER that the communication channel is ready.

4.1.1.1     Placement

The Handshake Tone is emitted by the RECEIVER after going off-hook and delaying an interval of at least 0.5 sec­onds but not greater than 2.0 seconds.  This time allows the phone net­work connection to settle before the com­munication process begins.

4.1.1.2     Composition

Handshake will be at RECEIVER mark frequency (2225 ± 6 Hertz).

4.1.1.3     Duration

The duration of the handshake from the RECEIVER to the TRANSMITTER is a minimum of 500 milliseconds.  The RE­CEIVER handshake should not exceed one (1) second.

The Speed Synchronization Signal is produced by the TRANSMIT­TER.  It is mandatory and cannot be omit­ted.  It allows the RE­CEIVER to determine the baud rate in use by the calling TRANS­MITTER. 

Once determined, the baud rate established by the Speed Synchroniza­tion Signal is used for all sub­sequent com­munications.  This applies to data being transmitted from RECEIVER to TRANSMITTER (reverse channel) as well as normal TRANSMITTER to RECEIVER com­muni­cation.

 

4.1.2.1     Placement

The speed synchronization signal is sent by the TRANS­MITTER no sooner than 200 and no later than 500 mil­liseconds after the cessa­tion of the RECEIVER's hand­shake tone.

 

4.1.2.2     Composition

The speed synchronization signal consists of a continuous stream of alter­nating ones and zeros (mark and space) with the bit timing ap­propriate for the baud rate desired by the TRANSMITTER.  Since allowable baud rates un­der this standard are 110 and 300, the speed synchroniza­tion signal is produced by emitting a 1270 Hertz tone for 3.33 ms (for 300 baud) or 9.09 ms (for 110 baud).  This is immedi­ately followed by the same period of a 1070 Hertz tone.  This se­quence is repeated for the duration speci­fied be­low.

 

4.1.2.3     Duration

The TRANSMITTER will transmit its speed synchroniza­tion signal for a period of at least 250 milliseconds but not longer than 350 milliseconds.  The Speed Synchronization Signal is followed directly by the initial carrier of the first data block.

 

The Data Block is used to transfer information by the TRANSMIT­TER and by the RECEIVER. 

 

4.1.3.1     Placement

Data Blocks can be sent in both directions.  The place­ment of these blocks varies depending upon the direction of data flow.

 

4.1.3.1.1  TRANSMITTER to RECEIVER

Data Blocks being sent from the TRANSMITTER to the RE­CEIVER can be initiated only after:

(a)        The completion of the required Speed Synchro­nization Signal, or

(b)        The completion of a previous data block NOT requir­ing RECEIVER acknowl­edgement, or

(c)        The cessation of an acknowledgement signal from the RECEIVER is detected to a previously sent data block re­quiring acknowledgement, or

(d)        The completion of a TRANSMITTER generated posi­tive ac­knowledgement with reverse channel com­mand (see section 4.1.4.2. Acknowledgements) in response to data from the RECEIVER.

When data blocks from the TRANSMITTER follow pre­vious transmis­sions from the TRANSMITTER, no inter­vening delay is required.  However, when data blocks from the TRANSMITTER follow signals or data from the RE­CEIVER, the TRANSMIT­TER must delay a mini­mum 200 (maximum 500) milliseconds before re-asserting car­rier. 

 

4.1.3.1.2  RECEIVER to TRANSMITTER

Data Blocks being sent from RECEIVER to TRANS­MITTER (reverse channel) can be sent only after:

(a)        The completion of a RECEIVER generated ac­knowl­edgement with reverse channel command (see Ac­knowledgement below) in response to data from the TRANSMITTER, or

(b)        The cessation of an acknowledgement signal from the TRANSMITTER is de­tected to a previously sent data block requiring acknowledgement, or

(c)        The completion of a previous data block NOT requir­ing TRANSMITTER ac­knowledgement.

When data blocks from the RECEIVER follow previous trans­missions from the RECEIVER, no intervening delay is required.  However, when data blocks from the RE­CEIVER follow signals or data from the TRANSMIT­TER, the RECEIVER must delay a mini­mum 200 (maximum 500) milliseconds before re-asserting carrier. 

 

4.1.3.2     Block Format

Each Data Block is composed of four components: Header, Func­tion Code, Data and Column Parity.

 
4.1.3.2.1  Block Header

The first byte after the Initial Carrier is the Header.  It is manda­tory for every block and is always one byte in length.  The Header bits have the following interpreta­tions:

 

Bit 7 - Reverse channel enable, when set, indicates to the recipient that re­verse channel data will be ac­cepted after this block. 

 

When using Tonal Acknowledgements, the presence of this bit is only detected in the zero block.  When using Data Acknowledgements, this bit allows the recipient to acknowl­edge using the implied method described in sec­tion 4.1.4.2. Acknowledgements.

 

Note that in order to send reverse channel data, bit 6 and 7 must be set (Reverse Channel Enable and Ac­knowl­edge Request).  Use of the Reverse Channel En­able Bit is encour­aged to allow transmitting devices con­trol over limited buffer re­sources.

 

Bit 6 - Acknowledge Request, this bit requests that the recipient transmit an ac­knowledgement signal after re­ceipt of the current block.  This bit may change from block to block but the zero block must have this bit set.

 

Bits 5 thru 0 - Block Length is a six (6) bit binary number, which indicates the num­ber of data bytes in the block.  This number does not include the header, function code or column parity.  Maximum block length is 63 + 3 or 66 bytes.

 

4.1.3.2.2  Function Code

This is a one (1) byte code that describes the type of data con­tained within the block.  Refer to Table 1, for a list of codes.

 

4.1.3.2.3  Data

The data bytes contain the information as specified by the func­tion code.  The block may contain up to 63 data bytes as specified in the block length field of the header. 

 

4.1.3.2.4  Column Parity

The column parity is one (1) byte.  The eight bits of data in this byte re­flect the odd parity of all corresponding bits in the block; i.e. bit 8 of the Column Parity byte is the odd parity of all bit 8's in the entire block. 

Column parity will be calculated by the sender as follows:

(a)        Begin with the value 255.

(b)        Exclusive OR the current value with the value of the first (or next) data byte beginning with the header byte.  Repeat until all bytes up to, but not includ­ing, the parity byte have been used.

(c)     Send the result in the column parity position.

 

Control Signals are used to manage the session protocol.  Control Sig­nals used by the sender are called flags.  Con­trol Signals used by the recipient are called acknowl­edgements. 

Control signals can be tonal or as data blocks. Control Signals in block form are called System Blocks.  System block length is always zero.  The function code character of all system blocks is numeric ASCII, i.e.0 – 2 are flags, 3 - 5 are [reserved for future use], and 6 – 9 are acknowledgements. 

 

4.1.4.1     Flags

Flags are system blocks sent by the sender in place of a data block.  They are used when the sender needs to in­form the recipient of a change in session status.

 

4.1.4.1.1  Zero Block  - End of Data

The zero block is used by the sender to mark the end of data.  The sender must set the Acknowledgement Request bit.  The Reverse chan­nel enable may also be set if the sender is able to accept reverse channel data blocks.  A positive acknowledgement (without a reverse channel command) to this block should be treated as a disconnect command. 

 

The zero block is required only when tonal acknowledge­ments are in use.  When data ac­knowledgements are in effect, TRANSMITTER and RECEIVER should use the Positive Ac­knowledge (eight block) (see section 4.1.4.2.2 Data Acknowledgement ). 

 

4.1.4.1.2  One Block - Wait

The wait block can be sent in place of a data block.  This allows the sender to remain on-line while additional data blocks are as­sembled.  The sender must set the Acknowl­edgement Request bit.  The Reverse channel en­able may also be set if the sender is able to accept re­verse channel data blocks. 

 

4.1.4.1.3  Two Block - Abort

The abort block indicates the sender must end the session imme­diately.  The sender may set the Acknowledge Re­quest bit, but is not required to wait for a response.  The Reverse Channel En­able bit should not be set.  The abort block should never be con­sidered a positive ac­knowl­edge­ment of previous blocks. 

 

4.1.4.2     Acknowledgements

Acknowledgements are tonal by default.  The TRANS­MITTER may, how­ever, request acknowl­edge­ment by data block.  This is accom­plished by the trans­mission of the optional configuration block (see section 5.3.1 Configuration Block).

 

The Acknowledgement must follow, within 400 millisec­onds, the re­ceipt of a complete data block received with the acknowledgement request bit set. 

 
4.1.4.2.1  Tonal Acknowledgements

The duration of tonal acknowledgements will be a mini­mum of 500 mil­liseconds, but not longer than one (1) second.

 

Negative Acknowledgement is at the recipient's mark frequency.

 

Positive Acknowledgement is at the recipient's space fre­quency.

 

Positive Acknowledge with Reverse Channel Command This Acknowledgement reverses the roles of TRANSMITTER and RECEIVER and can only be used af­ter the receipt of a correct (column parity) zero block with the reverse channel en­able bit set.

 

The normal Positive Acknowledgement is followed im­medi­ately by 150 millisec­onds of mark frequency.  The first Data Block as described above is sent after the 150 millisecond mark tone.  The channel may be reversed again only after the re­ceipt of a zero block with the re­verse channel enable bit set.

 

When operating in a reverse channel mode, the RE­CEIVER (now transmitting) must assume all oper­ating parameters re­quested by the TRANSMITTER, in­clud­ing baud rate and ac­knowledgement type.

 
4.1.4.2.2  Data Acknowledgement

The data acknowledgement is an extended capability pro­vided to transmitters requesting it with the configuration block discussed in section 5.3.1, Configuration Block.  It greatly re­laxes the reverse chan­nel re­quirements imposed by tonal acknowledgements.  In addition, it al­lows differentiation between the Negative and Reject Acknowl­edgements. 

 

Negative Acknowledgement is used when the data block received was incor­rect, i.e., loss of carrier was de­tected be­fore the required number of bytes was re­ceived, or the col­umn parity was in error.  The Nega­tive Ac­knowledgement is tonal, and is identical to the Neg­ative Acknowledgement de­scribed in section 4.1.4.2.1 Tonal Acknowledgements. 

 

The use of a tonal acknowledgement within the frame­work of Data Acknowledgements is considered desir­able in the case of Negative.  This avoids the conflict caused by a data block type of Negative Acknowledge­ment that is, it­self, re­ceived containing errors. 

 

Implied Positive Acknowledgement allows Data Blocks received correctly to be acknowledged by im­plica­tion, that is, by simply transmitting any valid block of information.  This allows the rapid bi-directional (within the bounds of the half-duplex environment) movement of data between two devices.  The Reverse Channel Enable bit must be set in a block received to al­low it to be acknowledged by impli­cation.

 

Nine Block - Reject is considered a Rejection of the data transfer.  It informs the sender that the data block be­ing transferred was received correctly, but the recipi­ent cannot comply.  Data blocks acknowledged with the nine block should not be repeated by the sending de­vice.

 

The RECEIVER may use the Reject acknowledge­ment to refuse an N or O block containing an un­known condi­tion code.  The TRANSMITTER may use the Reject ac­knowl­edgement to indicate non-compli­ance with com­mand fea­tures (not implemented or dis­abled by the user).

 

Eight Block - Positive Acknowledgement is used to acknowledge blocks received if the recipient has no data to send, or the header byte of the block received had the Reverse Channel Enable bit cleared and the Acknowledge bit set. 

 

Seven Block - Positive Acknowledge and Disconnect is sent by the RECEIVER to inform the TRANSMITTER that a disconnect should be initiated.  The Disconnect Ac­knowledgement can only be sent by the TRANSMITTER in response to a seven block from the RECEIVER.  The RECEIVER should transmit a seven block (reverse chan­nel enable and ac­knowledge­ment request set) to the TRANSMITTER in order to terminate a call.  The TRANSMITTER should re­spond with a seven block (reverse channel enable and acknowledge­ment request cleared) if no additional traffic has occurred.  The TRANSMITTER may also respond with a data block (thereby acknowledging by implication) to abort the dis­con­nect and continue the communication of data. 

 

The use of a normal Positive Acknowledgement (eight block) or Reject acknowledgement (nine block) by the TRANSMITTER in response to a seven block from the RECEIVER should be considered a failure and cause imme­diate disconnect by the RECEIVER.

 

Six Block - Positive Acknowledge and Standby is sent by the RECEIVER to instruct the TRANSMITTER to enter Standby Mode in which both the RECEIVER and TRANSMITTER listen concur­rently.  The Standby Ac­knowledgement can only be sent by the TRANSMITTER in response to a six block from the RECEIVER. The RECEIVER should transmit a six block (reverse channel enable and ac­knowledgement re­quest set) to the TRANSMITTER in order to enter Standby Mode.  The TRANSMITTER should respond with a six block (reverse channel en­able and acknowl­edgement request cleared) if no addi­tional traffic has oc­curred.  The TRANSMIT­TER may also respond with a data block (thereby ac­knowledging by implication) to abort the Standby Mode and con­tinue the communication of data. 

 

The use of a normal Positive Acknowledgement (eight block) or Reject acknowledgement (nine block) by the TRANSMITTER in response to a six block from the RE­CEIVER should be considered a failure and cause imme­diate dis­connect by the RECEIVER.

 

This section describes the frequencies and signal rates re­quired under this standard.

 

This format uses standard Bell 103 FSK frequency encod­ing.  The TRANSMITTER mark tone is 1270 ± 6 Hertz.  The TRANS­MITTER space tone is 1070 ± 6 Hertz.  The RECEIVER mark tone is 2225 ± 6 Hertz.  The RE­CEIVER space tone is 2025 ± 6 Hertz.

 

Two transmission rates are allowable under this standard.  They are deter­mined by the TRANSMITTER and com­municated to the RE­CEIVER by the transmission of the Speed Synchronization Burst de­scribed in section 4.1.2.  Normal speed is 300 ±1% Baud, or 3.33 mil­liseconds of mark or space tone per bit of data.  Slow speed is 110 ±1% Baud, or 9.09 milliseconds of mark or space tone per bit of data.

 

All data transfer is performed half-duplex.  Transmitters and receivers are not required to emit tones and listen concurrently. 

Carrier must be provided at all times when a device is at­tempting or preparing to broadcast.  Carrier must be sus­pended when a device is listening or decod­ing incoming tone.  The absence of carrier must de­fine a unit's ability to re­ceive signals or data from the opposing unit.  Carrier will be defined as the mark or space frequency of the sender.

 

Data Blocks are composed of separate bytes in UART (Universal Asyn­chronous Receiver Transmitter) form.

 

There is one logic zero start bit at the sender's space fre­quency.

 

There are eight (8) data bits, least significant bit first.  Logic zero is at the sender's space frequency.  Logic one is at the sender's mark fre­quency.

 

There will be one parity bit.  Parity will be odd, i.e. 0 if the sum of all data bits is odd, 1 if the sum is even.  Logic zero is at the sender's space frequency.  Logic one is at the sender's mark frequency.

 

There are two logic one stop bits at the sender's mark fre­quency.

 

Bytes within a data block may be separated by no more than 1 second.  Two stop bits are considered minimum and mandatory.  Failure to re­ceive a start bit within the allotted time should be handled as a Com­munication Er­ror.

 

This section describes the requirements of data block movement between the TRANSMITTER and the RE­CEIVER.  It describes how data blocks may be grouped, sets time-out limits for block delivery, de­scribes the Standby Mode, and sets the number of re-transmission attempts.

 

Multiple blocks of data transmitted without individual ac­knowledge­ments are called data groups.  Multiple Blocks may be sent under this standard provided the total num­ber of bytes passed as data does not exceed 500 for TRANSMITTER to RECEIVER communications or 300 for RECEIVER to TRANSMITTER communications (this ex­cludes headers, function codes and parity bytes).  TRANSMITTERS with limited buffer resources may in­form the RECEIVER, thereby set­ting new maximums on incoming data size through the use of the con­figuration block (see section 5.3.1, Configuration Block). 

 

All data blocks within a group must be sent contiguously, with the ac­knowledgement request bit cleared (logic zero) on all but the last data block.  Acknowledgements sent after the last data block always refer to the entire data group.  Repeats of all blocks are required should the recipient require re-transmission.  Should a communica­tion failure oc­cur, all blocks transmitted prior to the fail­ure and before the receipt of a valid positive acknowl­edgement must be considered not delivered by the sending device.

 

4.4.2.1     Initial Carrier

Each Data Block must begin with a constant carrier tone to enable the re­cipient to synchronize to the incoming block.  This carrier must be sent at the sender's mark frequency (1270 Hertz for TRANSMITTER, 2225 Hertz for RECEIVER).

 

When the Data Block follows another tone or data block also sent by the sender, the duration of the initial carrier can be a minimum of 12 bit inter­vals (39.96 milliseconds at 300 baud, 109.08 millisec­onds at 110 baud).

 

When the Data Block follows the receipt of data or tone from the opposing device, the sender must insert a delay before asserting car­rier.  This delay must be at least 200 milliseconds and not greater than 500 milliseconds.  The delay should not begin until the cessa­tion of tone or data from the op­posing device.  The initial carrier duration must be lengthened to 150 mil­liseconds under this condi­tion.

 

4.4.2.2     Block Timing

Individual Data Blocks within Data Groups may be sepa­rated by no more than 4 seconds.  Carrier (mark) must be asserted at all times between blocks of a group.  Loss of carrier between blocks of a group should be handled as a Communication Error.

 

4.4.2.3     Tonal Acknowledgements

After a data block containing an acknowledgement re­quest has been sent, the sender should wait no more than 2.5 seconds for the opposing device to respond.  A failure to respond should be handled as a Communication Error.

After transmitting an acknowledgement to a non-zero block, a de­vice should wait a minimum of 4 seconds for a new data block.  A failure to re­ceive a new block should be handled as a Communica­tion Error.

After transmitting an acknowledgement to a zero block, a device may exe­cute an immediate End of Session.

 

4.4.2.4     Data Acknowledgements

After a data block containing an acknowledgement re­quest has been sent, the sender should wait no more than 2.5 seconds for the opposing device to respond.  A failure to respond should be handled as a Communication Error.

 

Either the TRANSMITTER or the RECEIVER may end the Standby Mode by transmitting a 4 sec­ond mark fre­quency followed by the out­going new data block. 

Standby Mode should never exceed 60 seconds.  The RE­CEIVER or TRANSMITTER may end the standby mode at any time deemed ap­propriate even if only to transmit a zero block.  However, only the RECEIVER may re-initi­ate the Standby Mode by issuing the six block command. 

 

The TRANSMITTER or RECEIVER should re-transmit any data block after receipt of a Negative Acknowledge or 4 second loss of car­rier.  Either device should re-transmit at least once, but no more than 3 times (total of four) be­fore executing a Communication Failure.

Re-transmission should never occur when carrier is heard from the opposing device.

 

This section describes how contact is established, how se­curity is maintained, and un­der what conditions a call is terminated.

 

 

4.5.1.1  TRANSMITTER Initiated

The typical TRANSMITTER initiated session begins when the RECEIVER goes off-hook in re­sponse to a ring signal.  The Re­ceiver is­sues a Handshake signal de­scribed in section 4.1.1, Handshake Tone.  The TRANSMITTER should respond with the Speed Syn­chronization Signal and first data block.

 

4.5.1.2  RECEIVER Initiated

The RECEIVER may, as an extension of this standard, provide the ability to dial out and estab­lish contact with TRANSMITTERS able to go off-hook in response to a ring signal.  These TRANSMIT­TERS must issue a Speed Synchronization Signal two seconds after going off-hook.  TRANSMITTERS should wait up to 4 seconds for the first data block from the RECEIVER.  The Speed Syn­chroniza­tion Signal must be repeated at least once but no more than three times (total of four) before the TRANSMITTER aborts and goes back on-hook.

 

The RECEIVER, upon detecting the end of the Speed Synchroniza­tion Signal must respond with the Access Passcode data block.  If the Access Passcode is valid, the TRANSMITTER should give a positive tonal ac­knowl­edge with reverse channel command followed by a config­uration block.  If the Access Passcode is not valid, the TRANSMITTER should dis­connect immediately.  Only if the block containing the Access Passcode was in error (bad parity) should the TRANSMITTER respond with a negative acknowledgement.

 

4.5.1.3  Security

TRANSMITTER initiated calls provide security by limit­ing access to a RECEIVER at a pre-pro­grammed tele­phone number. 

 

TRANSMITTERS able to respond to a ring signal and establish contact by call-in must receive a data block with the access passcode function code before any other data blocks.  If any other function code is received, the TRANSMITTER should immediately termi­nate the call.

 

A communication session may end normally or be inter­rupted by ex­ternal forces prior to normal termination. 

 

4.5.2.1     End of Session

When a call is properly terminated by one of the above processes, the RECEIVER may go on-hook and wait for the ring signal to in­dicate the start of a new call. 

When a call is properly terminated by one of the above processes, the TRANSMITTER may go on-hook and wait for new activity re­quiring communication. 

 

4.5.2.2     Communication Failure

When a call is interrupted before a normal termination occurs, the RECEIVER should generate an internal event with the condition code RT.  This event should be handled as if it were received from the TRANSMITTER, i.e., printed and acknowledged by the opera­tor and/or passed on to a host automation system.

 

When a call is interrupted before a normal termination occurs, a TRANSMITTER should re-dial and attempt to re-connect only if addi­tional information remains unde­livered.

If a data block recipient detects framing or parity errors it should wait up to 12 seconds for loss of carrier.  When the opposing de­vice's carrier ceases, the recipient should send a Negative Ac­knowledgement.  If carrier does not cease within 12 seconds, the re­cipient should termi­nate the call by go­ing on-hook.

 

This section describes the various function code blocks and their respective data in­terpretations.  Function blocks fall into three basic types: System, Information and Special.  System Blocks are unique in that they contain no data, but

rather, are used to control the block and session proto­cols.  Information Blocks are used to move data in a packet form called Data Codes.  This infor­mation can be event, envi­ronmental, control, or program information.  Special Blocks are used for special in­formation not con­tained in a Data Code format.  Special Blocks in­clude Configura­tion, Access Passcode, Account, ASCII or

 

5.1.    System Blocks

Function codes 0 - 9 are reserved for system use and do not contain data.  The block header bits 0 through 5 of these blocks are zero (data byte count). The function and use of these data blocks is described in section 4.1.4, Control Signals.

 

5.2.      Information Blocks

Information Blocks carry information in packets called Data Code Packets.  Informa­tion Blocks may contain mul­tiple Data Code Packets, provided they are sepa­rated with the packet separator '/', ASCII character 47. 

 

Most Data Code Packets have the same basic structure and represent events (or conditions) within the system. 

 

Several special packets, called modifiers, are allowed to add additional in­formation about other packets in the block.  These modi­fiers do not represent events and have meaning only in the presence of other data code packets in the block.

 



Table 1: Block Type Summary


 


Block Type

Sent by TX

Sent by RX

Block Code


Block Type

System

Yes

Yes

0

End of Data

System

Yes

Yes

1

Wait

System

Yes

Yes

2

Abort

System

-

-

3-5

Reserved for future use

System

No

Yes

6

Positive Acknowledge and Standby

System

No

Yes

7

Positive Acknowledge and Disconnect

System

Yes

Yes

8

Positive Acknowledge

System

Yes

Yes

9

Reject

Info

Yes

Yes

C

Control (sent by TX in response to query)

Info

Yes

No

E

Environmental

Info

Yes

No

N

Event (new)

Info

Yes

No

O

Event (old)

Info

Yes

Yes

P

Program (sent by TX in response to query)

Special

Yes

No

@

Configuration

Special

No

Yes

?

Access Passcode

Special

Yes

Yes

#

Account ID

Special

Yes

No

&

Origin ID

Special

Yes

Yes

A

ASCII

Special

Yes

Yes

X

Extended

Special

Yes

No

L

Listen-In

Special

Yes

Yes

V

V-Channel Request

Special

Yes

Yes

v

V-Channel Frame

Special

Yes

Yes

I

Video

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table 2: Unit Types

 

Type Code

 

Description

Type Code

 

Description

A_

Amperes

I_

Inches

C_

Celsius Degrees

IM

Inches per Minute

cm

Centimeters

kg

Kilograms

cM

Centimeters p/Minute

M_

Minutes

F_

Fahrenheit Degrees

m_

Meters

FM

Feet per Minute

MA

Milliamperes

G_

Grams

mM

Meters per Minute

GH

Gallons per Hour

MV

millivolts

GM

Gallons per Minute

P_

Percent

H_

Hours

V_

Volts

 

 

 


 

 

 

 

 

 

 

 

 

 


 

 

5.2.1.1     Data Code Packets

Each Data Code Packet is composed of three basic fields: type, address and units.  Only the type field is required.  The basic form is:

TTAAAA*UUUUUUuu

Where TT represents the type, AAAA represents the address number, and UUUUUUuu is the units number.

 

5.2.1.1.1. Data Type Codes

Data Code packets always begin with a two character se­quence: the Data Type Code.  Valid characters for type

codes are the capital letters A through Z.  Type codes have function scope only; i.e., they are de­fined only for the Function Block type in which they are carried.

For example, the type code BA can have one defini­tion within the Event Block (Burglar Alarm) and a different meaning for Environmen­tal Blocks.

 
5.2.1.1.2. Address Number

The address number is optional and its meaning is relative to the Data Code Type it follows, as shown in Appendix A.  If included, it must fol­low the data type code without

spaces or other characters.  The address number must be an ASCII representation of a hexadecimal number.  The

valid characters for this field are 0 through 9, ASCII 48 to 57, and A through F, ASCII 65 to 70.

 

The address number must be at least one character (if present) and contain no more than 4 characters.  Leading zeros may be in­cluded but are not required. 

 
5.2.1.1.3  Units Field

The Units Field contains information about the magnitude of the event in the data type code.  The units field is optional.  If in­cluded, it must follow the address number or data code type with­out spaces or other characters.  The units field is com­posed of three sub-fields: the unit tag, the unit number and the unit type. 

 

The Unit Tag, (the asterisk character '*', ASCII 42) is used to mark the be­ginning of a units number. 

 

The Unit Number must follow the Unit Tag without spaces or other characters.  The unit number must be an ASCII rep­resentation of a decimal number.  The valid characters for this field are 0 through 9, ASCII 48 to 57.  Negative numbers may be represented, where valid, by prefixing the number with the '-' (ASCII 45) character.  The decimal point '.' (ASCII 46) is allow­able where valid. The unit number must be at least one character (if pre­sent) and contain no more than 6 characters.  Leading ze­ros may be included but are not required. 

 

The Unit Type is one or two ASCII characters and must follow the unit number.  The characters de­termine the unit of measure.  Table 2 shows the types currently defined. New types will be added upon request as detailed in sec­tion 6.1.3.

 

5.2.1.2     Modifier Code Packets

Modifier Code Packets act as adjectives to describe the Data Code Packets to follow.  Modifiers only act upon packets that follow the modifier it­self and occur within the same data block. Data pack­ets that precede the modi­fiers, or follow in a different block, are not affected. 

 

Modifier types have global scope, i.e., they are defined for all In­formation Blocks.  Modifier Code packets always begin with a two character type se­quence.  Modifier Codes are lower case to distin­guish them from Data Codes.   Valid characters for type codes are the lower case letters a through z. 

 
5.2.1.2.1  Date

The Date Modifier is used to indicate the date on which an event took place.  This allows his­torical information to be passed to the RECEIVER.  The format for the Date Modifier is:

daMM-DD-YY

where da is the type code for the Date Modifier, MM is the month (01 -12), DD is the day (01 - 31), and YY is the year (least significant two dig­its).  Alternately, the day of week (1 - 7, Sun­day = 1) may be passed in the DD posi­tion if MM is set to zero.  All numbers are ASCII repre­sented, decimal numbers. 

 
5.2.1.2.2  Time

The Time Modifier is used to indicate the time at which an event took place.  The format for the Time Modifier is:

tiHH:MM:SS

where ti is the type code for the Time Modifier, HH is hours (00 - 23), MM is minutes (00 - 59), and SS is sec­onds (00 - 59).  Seconds and the preceding ':' are optional. 

 

All numbers are ASCII represented, decimal numbers.  Both digits should be pre­sent even for values less than 10; e.g., 7 should be represented as 07.

 
5.2.1.2.3  Subscriber ID

The Subscriber ID is used to indicate the identity of the user causing the actions or events in­cluded in the current block.  The format for the Subscriber ID Modifier is:

idSSSS

where id is the type code for the Subscriber ID Modifier, and SSSS is the subscriber number (0000 - 9999).  All numbers are ASCII repre­sented, decimal numbers.  Leading zeros may be in­cluded, but are not required. 

 

5.2.1.2.4  Area ID

The Area ID is used to indicate the identity of a logical area causing the actions or events in­cluded in the current block.  The format for the Area ID Modifier is:

riSSSS

where ri is the type code for the Area ID Modifier, and SSSS is the area number (0000 - 9999).  All numbers are ASCII repre­sented, decimal numbers.  Leading zeros may be in­cluded, but are not required. 

 
5.2.1.2.5  Peripheral ID

The Peripheral ID is used to indicate the identity of a physical device causing the actions or events included in the current block.  The format for the Peripheral ID Modifier is:

piSSSS

where pi is the type code for the Peripheral ID Modifier, and SSSS is the peripheral number (0000 - 9999).  All numbers are ASCII repre­sented, decimal numbers.  Leading zeros may be in­cluded, but are not required. 

 

5.2.1.2.6  Automated ID

The Automated ID is used to indicate the identity of a logical function or timer causing the actions or events in­cluded in the current block.  The format for the Auto­mated ID Modifier is:

aiSSSS

where ai is the type code for the Automated ID Modifier, and SSSS is the automated number (0000 - 9999).  All numbers are ASCII repre­sented, decimal numbers.  Leading zeros may be in­cluded, but are not required. 

 
5.2.1.2.7  Telephone ID

The Telephone ID indicates the index of the telephone service number used when the follow­ing events occurred.  The format for the Telephone ID Modifier is:

phXXXX

where ph is the type code for the Telephone ID Modifier, and X is the telephone index in ASCII digits 0 - 9.  At least one digit must follow the modifier type code.  Up to 4 digits may be represented.  Hyphens, commas and other non-numeric characters must not be included in this field.  This modifier can be used to provide the identity of a RECEIVER line called by a TRANSMITTER when some form of communication error occurred. 

 

5.2.1.2.8.  Name

The Name Modifier is used to indicate the name of a specific user or zone tied to an event.  It is a variable length modifier (maximum length cannot exceed the end of the block).  All characters must be printable ACSII characters.

(format and details TBD)

 

 

5.2.1.2.9.  Level

The Level Modifier is used to indicate a state that has multiple, meaningful levels which can be quantitative or qualitative.  The format for the Level Modifier is:

lvLLLL

where lv is the type code for the Level Modifier, and LLLL is the level number (0000 - 9999).  All numbers are ASCII represented, decimal numbers.  Leading zeros may be included, but are not required.

 

5.2.1.2.10.  Value

The Value Modifier is used to transmit a numerical value associated with the event code reported.  The format for the Value Modifier is:

vaVVVV

where va is the type code for the Value Modifier, and VVVV is the value number (0000 - 9999).  All numbers are ASCII represented, decimal numbers.  Leading zeros may be included, but are not required.

 

5.2.1.2.11.  Path

The Path Modifier is used to transmit which of multiple communications paths the event code relates to.  The format for the Path Modifier is:

ptPPP

where pt is the type code for the Path Modifier, and PPP is the path number (000 - 999).  All numbers are ASCII represented, decimal numbers.  Leading zeros may be included, but are not required.

 

5.2.1.2.12.  Route Group

The Route Group Modifier is used to identify which of several communications path groupings (primary and secondary) has failed to communicate.  The format for the Route Group Modifier is:

rgGG

where rg is the type code for the Route Group Modifier, and GG is the path number (00 -99).  All numbers are ASCII represented, decimal numbers.  Leading zeros may be included, but are not required.

 

5.2.1.2.13.  Sub-Subscriber

The Sub-Subscriber Modifier is used to provide flexibility in the number used to describe and identify an individual access control system user (in a manner analogous to the way a Area is used to identify a sub-group of an account).  By creating a second group of ID numbers, access control system operators at large facilities can use one number group to describe a category of user and the second number group to identify the individual (or vice versa).  The format for the Sub-Subscriber Modifier is:

ssSSSS

where ss is the type code for the Sub-Subscriber Modifier, and SSSS is the number (0000 - 9999).  All numbers are ASCII represented, decimal numbers.  Leading zeros may be included, but are not required.

 

The Control block is identified with a function code 67, ASCII charac­ter C.  Control blocks contain information intended to modify the state of a TRANSMITTER output or temporary setting.  The RECEIVER sends con­trol blocks to the TRANSMITTER under most conditions, however, the TRANSMITTER can send a control block in response to a query from the RECEIVER.  Control blocks from a TRANSMIT­TER always contain status in­formation, never data in­tended to control the RE­CEIVER.

 

Control information takes the general form x*y, with the meaning of x and y defined by the data code.  The RE­CEIVER may omit the y parameter in order to query the TRANSMITTER state for the given x item.  Further, the x parameter may be omitted to query the state of all x items.  Multiple queries and commands may be mixed within a single data block provided they are separated by the '/', ASCII 47, character. 

 

Example 1 in Appendix B shows a typical Control Block.  This block shows a control request from the RECEIVER intended to close area 2 at the TRANSMITTER location. Valid data codes used in the Control block are defined in Appendix A, Table 0: Control Block Data Code Definitions.

 

The Environmental block is identified with a function code 69, ASCII charac­ter E.  The E block is used to pass environmental information such as temper­ature, flow and humidity.  All environmental data is presented unresolved, there is no equivalent of the event block O struc­ture.

 

Example 2 in Appendix B shows a typical Environmental Block.  This block sends a temperature report (DA) on zone 2 indicating a Celsius temperature of 21 de­grees. Valid data codes used in the Environmental block are defined in Appendix A, Table 7: Environmental Block Data Code Definitions.

 

The Event block is identified with a function code 78, ASCII character N (new event), or a function code 79, ASCII charac­ter O (old event).  The N block is used to identify informa­tion requir­ing resolution by the recipi­ent.  The O block is used to identify in­formation which has been previously re­solved, ei­ther locally or by previous communication to a RE­CEIVER.  Event blocks are always sent by the TRANS­MITTER to the RECEIVER.

 

Examples 3 and 4 in Appendix B show typical Event Blocks.  In Example 3: New Event Block (N), an unresolved panic alarm on zone 12 is being sent.  In Ex­ample 4: Old Event Block (O), a previ­ously resolved opening re­port is trans­ferred.  This re­solved opening report has met criteria set by the local alarm system (user has permission to open and did so within a pre-pro­grammed time window) and was re­ported using the O block instead of the N block.  This in­forms the RECEIVER operator or Host Automation System that no further action is required.  Infor­mation passed using the O block may be historical rather than real-time, but the difference between the N and O blocks is whether the event re­quires resolution by the RECEIVER operator or Host Au­tomation Sys­tem.  Valid data codes used in the Event block are de­fined in Appendix A, Table 6: Event Block Data Code Definitions.

 

The Program block is identified with a function code 80, ASCII charac­ter P.  Program blocks con­tain information intended to modify the op­eration of a TRANSMITTER.  The RECEIVER sends program blocks to the TRANS­MITTER under most conditions, however, the TRANS­MITTER can send a program block in response to a query from the RECEIVER.  Program blocks from a TRANSMITTER al­ways contain current program infor­mation, never data intended to program the RECEIVER. 

 

Program control codes effect virtual program information at the TRANSMITTER, not addressable program loca­tions.  While this method provides access to only a small subset of programming items in a TRANSMITTER, it allows an operational RECEIVER access to the most heavily used items without the necessity of managing large TRANSMITTER specific binary conversion tables.  More complete programming of a TRANSMITTER can be ac­complished with X blocks defined in this standard.

 

Program information takes the general form x*y, with the meaning of x and y defined by the data code.  The RE­CEIVER may omit the y parameter in order to query the TRANSMITTER state for the given x item.  Further, the x parameter may be omitted to query the state of all x items.  Multiple queries and commands may be mixed within a single data block provided they are separated by the '/', ASCII 47, character. 

 

Example 5 in Appendix B shows a typical Program Block.  This block shows a program request from the RE­CEIVER intended to change the keycode used by sub­scriber 8.  The valid data codes used in the program blocks are defined in Table 5 Program Block Data Code Definitions.

 

Special blocks are used to pass information not formatted in the Data Code Packet method.  The interpre­tation of the data contained in a Special Block varies based on the function code. 

The configuration block is identified with a function code 64, ASCII character '@'.  The configuration block is used by TRANSMITTERS requesting addi­tional functions not supported in the base stan­dard.  The TRANSMITTER must always set the Acknowledge Request bit of the con­figuration block.  The Reverse Channel Enable should be cleared on the Configuration Block.  The Configuration Block has several ASCII coded fields.  A TRANS­MIT­TER may include only those fields required by the SIA Compati­bility Level or op­tional features being re­quested.  Fields with ar­gu­ments are followed directly by a minimum one character (maximum 6 character) ASCII coded number.  The Configuration fields defined are:

 

5.3.1.1     A - Data Acknowledgement Request

The TRANSMITTER may request Data Acknowledge­ments from the RECEIVER by including the A field.  No arguments are in­cluded. 

Note that acknowledgements are tonal by default.  The acknowl­edgement to the configuration block will be tonal even if data ac­knowledgements have been requested.  Data acknowledge­ments can only begin after the RE­CEIVER has given a positive tonal ac­knowledgement to the configura­tion block. 

 

5.3.1.2     L - SIA Compatibility Level

The TRANSMITTER should inform the RECEIVER of its SIA Level if the Level of the TRANSMITTER is greater than 2. 

 

5.3.1.3     D - Dealer or Agency ID

The TRANSMITTER may provide an agency ID number indicating the company servicing the TRANSMITTER.

 

5.3.1.4     M - Manufacturer's ID

Optional TRANSMITTER manufacturer ID number, is­sued by SIA.

 

5.3.1.5     P - Product ID

Optional TRANSMITTER product ID number, issued by manufac­turer.

 

5.3.1.6     R - TRANSMITTER Rom Version Number

Optional TRANSMITTER version and/or revision level.

 

5.3.1.7     T - Time Zone Data

Optional TRANSMITTER time zone location as an offset from Greenwich Mean Time.  West of GMT values are positive; e.g. Los Angeles is 8, New York is 5.  East of GMT values are negative.  A .5 may be appended to inte­ger value if the target time zone is a 30 minute zone.  Time zones smaller than 30 minutes are not supported by this standard.  The TRANSMITTER need not in­clude this field on every call, but only if a time stamp is needed.  The RECEIVER will close the current session with the TRANSMITTER adjusted time in weekly minutes and day of year.  See table 5 Program Block Data Code Definitions.

 

5.3.1.8     U - Daylight Savings UNOBSERVED

This indicates that the TRANSMITTER location does not observe Daylight Savings Time.  This must accompany the T option above if DST is not observed.  Note that this does not indicate the current status of DST, only that the TRANSMITTER location does not observe DST during the normal DST time period.

 

5.3.1.9     B - Maximum TRANSMITTER Block Size

Sets the maximum number of characters (bytes) that the TRANS­MITTER may receive in one block.  Must be less than the normal 63.  This allows TRANSMITTERS with limited internal re­sources to function within the SIA standard.  Also sets Group maximum to the same size unless the G field is also included.

 

5.3.1.10   G - Maximum TRANSMITTER Group Size

Sets the maximum number of characters (bytes) that the TRANS­MITTER may receive in a multi-block group.  Set to 300 by default, set equal to Block size if B option given.  This option re­sets the Group maximum size to the number passed.  This option must fol­low a B option if also present in the block.  Allows double buffering TRANSMITTERS to have different sizes for in­coming and pro­cessing buffers. 

 

Example 6 in Appendix B shows a typical Configuration Block.  This example shows a configuration block requesting data acknowl­edgements from a TRANSMITTER installed by dealer 24. 

 

5.3.2 Access Passcode Block

The access passcode block is identified with a function code 63, ASCII charac­ter '?'.  The Access Passcode block is required only when a ses­sion is initiated by the RE­CEIVER.  It must contain an ASCII coded number of at least four digits, but no more than sixteen digits.  The sig­nificance and use of this number is manufacturer de­pen­dent and not detailed in this standard.  Because the Ac­cess Passcode Block must be followed by the Configura­tion Block from the TRANSMITTER, the Reverse Chan­nel Enable bit must always be set on this block.

 

Example 7 in Appendix B shows a typical Access Passcode Block.

 

The account block is identified with a function code 35, ASCII charac­ter '#', and is required to be sent by the TRANSMIT­TER prior to any other block except the configuration block. The ac­count block will contain the account number for the TRANSMITTER that is calling the RECEIVER. The account num­ber is an ASCII coded number of no more than six digits. The number is repre­sented most significant digit first.

 

The TRANSMITTER may send additional account blocks during a communi­cation session to mod­ify subsequent data blocks be­ing sent to the RECEIVER.  In this way, multiple account reports during a single call are sup­ported. 

 

A TRANSMITTER may test the communication link by issu­ing an ac­count block only (and ending the session as ap­propriate).  Account blocks should never be grouped with other account blocks, hence the acknowledge request bit should be set.

 

The RECEIVER may issue account blocks to the TRANSMITTER to iden­tify the destination for control and programming information.  The RECEIVER is not required to issue an account block before control or pro­gramming blocks are sent.  The last account block re­ceived from the TRANSMITTER always indicates the current working account. 

 

Example 8 in Appendix B shows a typical Account Block.  This example shows an account block with the acknowl­edge request bit set and the reverse channel enable bit cleared.  While the acknowledge request bit should be set at all times, the reverse channel enable bit may be set as required by the TRANSMITTER.  Based on this, the block header could be 46 or C6 hexadecimal. 

 

The Origin ID block is identified with a function code 38, ASCII charac­ter '­&', and may be sent by the TRANSMIT­TER after the account block.  The Origin ID block will contain the Caller ID, Cellular ESN or other media relative number that identifies the point of origin for the carrier being used by the TRANSMITTER.  The Origin ID num­ber is an ASCII coded number of no more than 32 digits.  The number is repre­sented most significant digit first.

 

The TRANSMITTER may send only one Origin ID block during a communi­cation session.

 

Example 9 in Appendix B shows a typical Origin ID Block.  This example shows the acknowl­edge request bit set and the reverse channel enable bit cleared.  While the acknowledge request bit should be set at all times, the reverse channel enable bit may be set as required by the TRANSMITTER.  Based on this, the block header could be 47 or C7 hexadecimal. 

 

The ASCII block is identified with a function code 65, ASCII character A.  This code signifies that the block contains text information and is used to transmit ASCII data.  ASCII data longer than 63 bytes may be transferred in data groups. This block may be used for general comments.

 

Example 10 in Appendix B shows a typical ACSII Text Block.

 

The Extended block is identified with a function code 88, ASCII char­acter X.  This code signifies that the block contains arbitrary infor­mation not defined by the standard.  The action taken following this code is de­termined by the manu­facturer(s) of the RECEIVER and TRANS­MITTER.

 

Proprietary formats may be packaged using the X block after provid­ing device identification with the Configura­tion Block (see section 5.3.1).  Implementa­tion of features not found in the standard may be provided in this way.  Note that data within the ex­tended block is not required to be ASCII character ori­ented; i.e. data bytes may be the full range 00-FF Hex.  However, for compatibil­ity with the SIA Computer Interface Standard, implementors are restricted to the printable range of ASCII values (20-7E Hex).

 

Example 11 in Appendix B shows a typical Extended Block. Application may be made to have useful data structures submitted for incorpo­ration into this Standard, see sec­tion

 

The Listen-In block is identified with a function code 76, ASCII char­acter L.  This code signifies that the sender wishes to insert a listen-in period.  Listen-In allows the TRANSMITTER to place audio informa­tion from the protected premise directly on the phone line.  Only the TRANSMITTER may request a listen-in period.

Data passed in the listen-in block defines the listen-in time in seconds.  The time is represented by an ASCII encoded number of no more than four digits.

 

Example 12 in Appendix B shows a typical Listen-In Block.  The example shows a TRANSMITTER requesting a listen-in time of 30 seconds.  RECEIVERS unable to support the listen-in re­quest should give a Reject response to the listen-in block.

 

Listen-in time is inserted into the normal communication session after the sender receives a positive acknowledge­ment to the listen-in block.  The ac­knowledgement must be a normal positive (no re­verse channel, standby or dis­connect command), or any data block permitted under the rules of implied ac­knowledgement. 

 

Following the listen-in time, the TRANSMITTER will send out the next data block in response to the block re­ceived from the RE­CEIVER prior to the lis­ten in inter­val.  The RECEIVER may hang up at any time during the listen-in period.

 

The V-Channel (voice) block is identified with a function code 86, ASCII character V.  This code signifies that the sender wishes to insert a V-Channel period.  V-Channel time al­lows the TRANSMITTER and RECEIVER to suspend use of the line for digital information, and al­lows the RECEIVER location and TRANSMITTER location to have voice communications.  The V-Channel in­terval itself is marked with V-Channel frame blocks using function code 118, ASCII character v. 

 

Data passed in the V-Channel block defines the V-Channel time in sec­onds.  The time is represented by an ASCII encoded number of no more than four digits. 

 

Example 13 in Appendix B shows a device requesting a V-Channel time of 30 seconds.  Devices unable to support the V-Channel request should give a Reject re­sponse to the V-Channel block.

V-Channel time must be requested with the use of the V function code.  The sender must provide an interval in seconds in the request block.  If the request is made by the RECEIVER, the TRANSMIT­TER (if able to comply) should respond with the v data group de­scribed below.  If a request is made by the TRANSMITTER, the RE­CEIVER should acknowledge with a Reject re­sponse only if unable to comply.  Any valid positive response (no reverse channel, standby or discon­nect command) en­ables the TRANSMITTER to begin the V-Channel group immediately. 

 

V-Channel time is inserted between two blocks of a data group with the func­tion code v (lower case) sent by the TRANSMITTER, as shown in Examples 14 and 15 in Appendix B.  The first block (header) is sent with the V-Channel interval in seconds, but without the ac­knowledgement re­quest bit.  The V-Channel interval is in­serted after the comple­tion of this block.  At the end of the V-Channel interval, the second block (terminator) of the group is sent without a numerical value and with the acknowledgement request bit set.

The Video Block is identified with a function code 73, ASCII character I.  This code signifies that the sender wants to insert a video period.  It allows the TRANSMITTER to place video image information from the protected premises directly on the phone line.  Only the TRANSMITTER may initiate a video period, but the RECEIVER may request additional information from the TRANSMITTER, after the video period has been initiated by the TRANSMITTER, using the Video Block.

 

5.3.9.1.  Video Block Modifier Code Packets

The Video Block may contain Modifier Code Packets, and each Modifier Code Packet is separated by the packet code separator code 47, ACSII character”/”.

 

5.3.9.1.1.  Protocol

The Protocol Modifier is used to indicate the video signal transmitting protocols used by the manufacturers.  Each manufacturer who intends to implement the video block should request a unique code from the SIA Digital Communications Standards Subcommittee.  The format for the Protocol Modifier is:

                        ptPPP

where pt is the type code for the Protocol Modifier, and PPP is the protocol number (000-999).  Numbers 000 through 009 are reserved for default SIA video signal transmitting protocols.

 

5.3.9.1.2.  Camera

The Camera Modifier is used to indicate the camera from which the video image was captured.  The format for the Camera Modifier is:

                        cnCCC

where cn is the type code for the Camera Modifier, and SSS is the camera number (000-999).

 

5.3.9.1.3.   Image

The Image Modifier is used to indicate the number of images that will be sent by the TRANSMITTER.  The format for the Image Modifier is:

                        imIII

where im is the type code for the Image Modifier, and III is the number of images (000-999).

 

5.3.9.1.4.   Additional Image

The Additional Image Modifier is used to indicate that the RECEIVER requests additional information from the TRANSMITTER after the video period is over.  The format for the Additional Image Modifier is:

                        adTTT

where ad is the type code for the Additional Image Modifier, and TTT is the total number of images requested by the RECEIVER (000-999).

5.3.9.1.5.  Duration

The Duration Modifier is used to define the video time in seconds.  The format for the Duration Modifier is:

                        duSSS

where du is the type code for the Duration Modifier, and SSS is the time in seconds (000-999).

 

Note:  It is recommended that video durations be kept to 30 seconds or less to limit the line loading on receivers.

 

5.3.9.1.6.  Resolution

The Resolution Modifier is used to define the video resolution level.  The format for the Duration Modifier is:

                        reL

where re is the type code for the Resolution Modifier, and L is the level number (0-9) as defined by the manufacturer for a given video protocol.

 

5.3.9.1.7.  Audio

The Audio Modifier is used to indicate that the TRANSMITTER requests a listen-in period after the video period is over.  The format for the Audio Modifier is:

                        auSSS

where au is the type code for the Audio Modifier, and SSS is the time of the listen-in period in seconds (000-999).

 

5.3.9.1.8.  Terminator

The Terminator Modifier is used to indicate that the TRANSMITTER requests that the video period be terminated.  The format for the terminator Modifier is:

                        tm

where tm is the type code for the Terminator Modifier.

 

Example 16 in Appendix B shows a typical Video Block, where the TRANSMITTER requests a video period with the Protocol number 010, images captured on camera number 7, images sent in 90 seconds, and the TRANSMITTER to insert a two-way audio period after transmitting the images.

 

5.3.9.2.  Video Period

The Video Period is inserted into the normal communication session after the TRANSMITTER receives a positive acknowledgment to the Video Block.  The acknowledgment must be normal positive (no reverse channel, standby, or disconnect command).

 

5.3.9.2.1  Priority Events

The video period can be terminated by the TRANSMITTER if priority events occur during the video period. The TRANSMITTER must stop the image transmission after the current image frame is transmitted and switch back to the normal communication session to send the priority events, and initiate the video period again after this session if necessary.

 

5.3.9.2.2.  Rejection

RECEIVERS unable to support the Video Block must  give a reject response to the  TRANSMITTER.

 

5.3.9.2.3.  Acknowledgment

Following the video session, the TRANSMITTER sends a  Configuration Block requesting a Data Acknowledgment.  The RECEIVER  sends a tonal ACK.  The TRANSMITTER then sends the Video Block with the Terminator Modifier.

 

5.3.9.2.4.  Additional Image Request

For a  RECEIVER to request additional information from a TRANSMITTER , the RECEIVER sends a Video Block with Additional Image Modifier and/or Camera Modifier as the Implied Positive ACK to the TRANSMITTER’s  Video Block Terminator Modifier

 

5.3.9.2.5.  Termination

To terminate the video session, the RECEIVER sends a Positive ACK to the Video Block Terminator  Modifier.

The communication may be terminated during the video period under the definition of Section 3.5.2 Call Termination.

 

 

6.1   Indications of Compatibility

There are three indicators that are used to determine compatibility between two SIA devices: Revision Date of this standard, Compatibility Levels, and Data Code Table identifier. 

 

6.1.1    Revision Date

The Major Revi­sion Date of the standard is indicated by the year and month of re­lease in the designation of this standard.  For example, previous major revisions were 1984, 1986, 1989, 1990, and 1993. 

 

Additionally, Section 5 of this standard outlines three Com­patibility Levels, (I, II and III).  Figure 1 depicts product emblems for annunciation of a product’s compatibility level.

 

Finally, an alphabetic suffix ("data code table identifier") is used to designate which code table has been implemented for a particular security de­vice.  For a particular major revision of the standard, the code table identifier will start with "a" and be incremented with each addition to the code table.  The code table identifier will be reset to "a" with each major release. 

 

As an example, a basic communicator for the current re­

vision of this standard would be indicated as "SIA 1997 Level Ia".  A full featured receiver might be "SIA 1997 Level IIIa".

 

In order to ensure compatibility between a TRANSMITTER and RECEIVER, the RECEIVER must have a code table identifier that is the same or later than the TRANSMITTER.

6.1.2 Capability Levels

Manufacturers supporting the SIA Digital Communica­tions Standard may do so at one of three Lev­els (I, II, or III) based on a progression of features imple­mented. 

 

TRANSMITTERS must be able to communicate with a RECEIVER of a higher level without loss of event infor­mation or other critical failure.  RECEIVERS must communicate with any TRANSMITTER of the same or lower level.  RECEIVERS may terminate a call from a TRANSMITTER of a higher level after attempting to determine the calling TRANSMITTER'S Account ID and printing an operator warning message. 

 

Equipment supporting the SIA Digital Communications Standard may dis­play one of the emblems shown in Figure 1.  Functions and operational requirements for the various compatibility ratings are detailed in Table 0.

 



Table 3: Compatibility Levels

Level 1

Level 2

Level 3

Function or Capability

TRANSMITTER (1)

RECEIVER (1)

Ö

Ö

Ö

Support Tonal Acknowledgements

required

required

Ö

Ö

Ö

Support N Blocks with Zone Numbers Only

Required (2)

required

Ö

Ö

Ö

Support Single Account Block per Call

required

required

Ö

Ö

Ö

Support O Blocks

(optional) (2)

required

Ö

Ö

Ö

Support X Blocks

(optional)

required

Ö

Ö

Ö

Support 300 Baud (FAST)

(optional)

required

 

Ö

Ö

Support Configuration Block

required

required

 

Ö

Ö

Support Data Acknowledgements

required

required

 

Ö

Ö

Support Modifier Codes

(optional)

required

 

Ö

Ö

Support Multiple Account Blocks per Call

(optional)

required

 

Ö

Ö

Support E Blocks

(optional)

required

 

Ö

Ö

Support Data Codes with Units Numbers

(optional)

required

 

 

Ö

Support RECEIVER call out and Access Passcode

required

required

 

 

Ö

Support Reverse Channel C Blocks

required

required

 

 

Ö

Support Reverse Channel P Blocks

required

(optional)

 

 

Ö

Support Reverse Channel A Blocks

(optional)

required

 

 

Ö

Support Dynamic Block and Group Sizes

(optional)

required

 

 

Ö

Support Listen-in Block

(optional)

required

 

 

Ö

Support A Blocks to RECEIVER

(optional)

required

 

 

Ö

Support V-Channel Communications

(optional)

(optional)

 

 

Ö

Support Video Block Communications

(optional)

(optional)

(1)   For Reverse Channel, Receiver capabilities apply to transmitter

(2)   Not all data code types need to be supported by TRANSMITTER. Individual subsets allowed.

 

Figure 1: Compatibility Level Emblems

 

SIA DC - 03

“SIA FORMAT”