a S cS a) = & a a Digital Communications Standard “SIA Format” Protocol for Alarm System Communications Sponser Security Industry Association Copyright © 1993 / 1997 - SIA Ser 99FORWARD ‘This standards document is published by the Security Industry Association (SIA) and was developed and adopted by aconsensus of industry volunteers in accordance with SIA’s standards development policies and procedures. Itis 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 STA’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 itis 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. Copyright © September 1997 Security Industry Association Page iTable of Contents ~ Table of Contents 1. INTRODUCTION AND JUSTIFICATION 1 #4, Sheet eke oy iat 43.21 Access Passcode Block 14 1.1. General Description 1 4.3.3. Account Block 4 43.8. Ongin ID Block 1% 1.2, Purpose 1 435. ASCII Block 14 43.6. Extended Block 4 1.3. Establishment of Need 1 43.7. Listen-In Block 15 3.1 History and Requirement 1 43,8. V-Channel Block 5 13.2. Current Capabilities 1 43,9. Video Block 5 133. Alternatives, 1 MT) ' 5, COMPATIBILITY 17 eee 1 6, REGULATIONS AND STANDARDS 19 3. TRANSMISSION REQUIREMENTS — 36.1. Regulatory Agency Compliance 19 ‘ML, Transmission Components 3 6.2, Underwriters Laboratory Standards 19 3.4 Handshake Tone 3 < Synchronization Signa 3 3.12 Speed Synchronization Signal 3 7, STANDARD ENFORCEMENT AND 3.1.4. Control Signals 4 REVISIONS 19 ignal Protocol 7.1, Revisions to Standard 19 37 Sierpl jueney Assignments é TALI. Data Code Addition Process 9 7 322. Transmission Rater 6 7.1.2 Indication of Additions in Products 19 323, Transmission Mode 6 7:13. Frequency of Additions 19 THB. Code Table Comp: 9 T'S, Requests for Code Table Additions 20 ae eeute ° 71.6. Release of Uncontested Code Table Additions 20 Baan aie c TT. Resolution of Contested Code Table Additions 20 335: payor fe TLS, Handling Unrecognized Event Block Data Codes 3.3.4. Stop Bits 7 aa Monier 2 335. Byte Timing 7 APPENDIX A- CODE DEFINITIONS — 21. 3.4. Block Protocol 1 3.4.1. Data Groups a 3:42. Timing Restraints 7 APPENDIX B - EXAMPLES 29 3.43. Standby Mode 7 348. Re-transmission 7 Block Formats » 3.5, Session Protocol $ Data Code Packets 3 35.1. Establishing Contact 8 3552 Call Termination Gees 5 4, DATA INTERPRETATION 8 APPENDIX C - INTERPRETATIONS "4 4.1, System Blocks 9 * INDEX 43 42. Information Blocks 9 “1211, General Conventions 9 42.2! Control Block 2 423. Environmental Block 2 42:4 Event Block 2 o~ 4.2.5. Program Block 12 Copyright © September 1997 Security Industry Association Page iiiTable of Contents List of Tables 1 Block Type Summary 9S Program Block Data Code Definitions a 2 Unit Types 106 Event Block Data Code Definitions 2 3SIA Digital Compatibility Levels 18 7Environmental Block Data Code Definitions 27 4 Control Block Data Code Definitions a List of Figures and Illustrations 1SIA Digital Compatibility Emblems 18 List of Examples BLOCK FORMATS 29 ASCH Text Block 20 1 Control Block 29 be canereatle® ca 2 Environmental Block 29 eee 4s New Event Block a9 18V-Channet Request Block 3 “Joa Event Block a9__-‘AV-Channet Header Block a 5 Program Block gg 18 V-Channel Terminator Block a 6 Configuration Block 30 eee = 7 Access Passcode Block 30 DATA CODE PACKETS 33 8 Account Block 30 MODIFER CODES 39 9 Origin ID Block 20 Page iv Digital Communication Standard - “SLA Format” Protocol for Alarm System Communications tealIntroduction and Justification Justification 1.1. General Deseription This specification describes a standard for digital eommunication 10 be used in the alarm industry, with possible future uses in the areas of energy control and facilities monitoring and management. 1.2. Purpose ‘The purpose of this Standard is to establish a common signalling format which can be adopted by any manufac turer of digital communicators or receivers. The standard, ‘communication format will provide an across-the-board compatibility of equipment designed to the Standard te- gardless of manufacturer. 1.3. Establishment of Need 1.3.1. History and Requirement ‘The existing communication formats were developed by ‘manufacturers of digital communicators as the products ‘were being developed, The formats are not always com- patible and there is no published documentation of their equitements. At the time of their conception, they were adequate to provide the type of service for which they were designed. However, with the large growth in the field of digital alarm point monitoring, the need for a system with a higher data rate, greater data capacity, and expansion potential, has become more critical. Another growing field ‘of application is that of energy management, which requires the ability of bi-directional communications. With these re- quirements in mind, manufacturers have developed still more communication formats, most of which are incompatible. 1.3.2. Current Capabilities ‘There are currently four major categories of data formats on the market. They are (1) Serial Pulse Tone, (2) FSK, (3), Bit Position, and (4) DTMF. Each of these categories may. hhave as many as four different formats oF capabilities which are not always compatible with others, even in the same ‘category. 1.33. Alternatives ‘Alternatives considered during the course of the developing committee meetings included FSK, DTMF and variations fon the Serial Pulse Tone methods. Considering speed, reliability and cost factors, as well as the potential long. range restrictions of the switched telephone networks, hall ‘duplex asynchronous FSK modulation was selected, 1.3.4. Objectives (a) Spend minimum practical time on line per transac- tion, to minimize the number of receivers required to hhandle the waffic and minimize the time the line is seized and not available to the customer. (b) Minimize the transmission error rate. (6) Allow for a variable length data message. (@) Be amenable to transmission and reception by eco- rnomical and reliable means, with the main emphasis on the transmission aspect as wansmitters greatly outnumber (e) Anticipate the future need for significant data flow from the central station to the protected premises (Be compatible with FCC standards. (g) Provide a secure data path not easily accessed with available hardware, such as personal computers, modems, atc. 2. Glossary Account, The portion of a transmitted message which ccontains the’ information identifying a particular location; account number. Acknowledgement, A signal sent from the RECEIVER to the TRANSMITTER indicating thatthe data has been re- ceived. A Positive Acknowledgement means data was received without any detected errors. A Negative Ac- knowledgement means data was received, but there were detected errors. Also used as a command to initiate trans- Area, A defined section of the protected system that can bbe armed and disarmed independently. Areas are numbered 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 duration of the shortest element. Bit, The smallest element of digital information, The value of a bitis either one or zero (true or false), Block, A block of information consists of account or data information and includes the header and parity in- formation, 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 represented by one byte Copyright © September 1997 Security Industry Association Page 1Glossary Close, The act of arming a system. Data, That part of the transmitted data which refers to ‘alarm point information or status ofthe sensors at a particu- 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 signalling method for transmitting digital information which uses a discrete audio frequency for a logic one and a different frequency for a logic 2er0, FIC, of Fail To Close, an event created by a system at 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 trafic 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, isthe 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 ravels in only one direction at atime, although 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 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- arming of a system after a specified time. Mark Frequency, The discrete audio frequency of the FSK signal used as the information bit, and defined 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 number of bit errors in that record Parity Word, A record in which the data are redundant bits which allow the RECEIVER to detect an odd number of bit errors in each column of data bits in that block. RECEIVER, The Digital Receiver located in the Cen- tral Station or Monitoring Location. Sender, The unit, TRANSMITTER or RECEIVER, currently in the process of transmitting information (emitting FSK tones) to the opposing unit, Sounder, A device at the TRANSMITTER site used to signal an event such as fire. Sounders are numbered con- secutively beginning with I. “A system is not required 10 have a sounder. Recipient, The unit, TRANSMITTER or RECEIVER, currently in the process of receiving information (decoding FSK tones) from the opposing unit. Reverse Channel, The transmission of data blocks in a direction opposite the last block transfer. Simplex Transmitter, One which is only capable of transmitting information to the central station RECEIVER. ‘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 atthe protected premise. User, See Subscriber. Page 2 Digital Communication Standard - “SIA Format” Protocol for Alarm System CommunicationsWarning, A device at the TRANSMITTER site used 0 alert the subscriber to an event such as power failure. Waring devices are numbered consecutively beginning ‘with I. A system is not required to have a warning device. Transmission Requirements Weekly Minutes, the measure of time as minutes be- ginning with O for Sunday at 00:00, and ending with 10079 for Saturday at 23:59. 3. Transmission Requirements This section describes the basic components of a commu- nication session, and the protocols for the four layers of transmission protocol: i.e, Signal, byte, block and session. 3.1. Transmission Components The TRANSMITTER to RECEIVER communication session is composed of four basic elements: the Handshake Tone, the Speed Synchronization signal, Data Blocks and Acknowledgements. The Handshake is'a single tone and the Speed Synchronization Signal is composed of two tones repeated in sequence. The Data Blocks contain Bell 103, FSK encoded data, ‘The Acknowledgement Blocks can be single tone, like the Handshake, or Data Encoded like a ala Block based on the requirements established by the ‘TRANSMITTER. 3.1.1. Handshake Tone ‘The Handshake Tone is produced only by the RECEIVER. Its purpose is to signal the TRANSMITTER that the ‘communication channel is ready. 311. 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 network connection to settle before the com- ‘munication process begins. 3.1.1.2. Composition Handshake will be at RECEIVER mark frequency (2225 6 Hert). 3.11.3. Duration ‘The duration of the handshake from the RECEIVER to the ‘TRANSMITTER is a minimum of 500 milliseconds. The RECEIVER handshake should not exceed one (1) second. 3.1.2. Speed Synchronization Signal ‘The Speed Synchronization Signal is produced by the ‘TRANSMITTER. It is mandatory and cannot be omitted, Icallows the RECEIVER to determine the baud rate in use by the calling TRANSMITTER. Once determined, the baud rate established by the Speed Synchronization Signal is used for all subsequent com- munications. This applies to data being transmitted from RECEIVER to TRANSMITTER (reverse channel) as well as normal TRANSMITTER to RECEIVER communication, 3.12.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 cessation of the RECEIVER's handshake tone. 3.1.2.2. Composition ‘The speed synchronization signal consists of a continuous stream of alternating ones and zeros (mark and space) with the bit timing appropriate for the baud rate desired by the TRANSMITTER, Since allowable baud rates under this standard are 110 and 300, the speed synchronization signal is produced by emitting @ 1270 Hertz tone for 3.33 ms (for 300 baud) or 9.09 ms (for 110 baud). “This is immediately Tollowed by the same period of a 1070 Hertz tone. This se~ quence is repeated for the duration specified below. 3.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. 3.1.3. Data Blocks ‘The Data Block is used to transfer information by the ‘TRANSMITTER and by the RECEIVER. U3. Placement Data Blocks can be sent in both directions. The placement of these blocks varies depending upon the direction of data flow. 3.13.11. TRANSMITTER to RECEIVER Data Blocks being sent from the TRANSMITTER to the RECEIVER 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 requiring RECEIVER acknowledgement, or Copyright © September 1997 Security Industry Association Page 3Transmission Requirements (©) The cessation of an acknowledgement signal from the RECEIVER is detected to a previously sent data block requiring acknowledgement, or (4) The completion of a TRANSMITTER generated positive acknowledgement with reverse channel command Gee section 3.1.4.2. Acknowledgements, page 5) in response to data from the RECEIVER. When data blocks from the TRANSMITTER follow pre~ vvious transmissions 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 TRANSMITTER must delay a minimum 200 (iaximum 00) milliseconds before re-asserting carrier. 3.1.3.1.2. RECEIVER to TRANSMITTER Data Blocks being sent from RECEIVER to TRANS- MITER (reverse channel) can be sent only after (a) The completion of a RECEIVER generated ac- knowledgement with reverse channel command (see Ac Kknowledgement below) in response to data from the ‘TRANSMITTER, or (b) The cessation of an acknowledgement signal from the TRANSMITTER is detected to a previously sent data block requiring acknowledgement, or (©) The completion of a previous data block NOT requiring TRANSMITTER acknowledgement. ‘When data blocks from the RECEIVER follow previous transmissions from the RECEIVER, no intervening delay is, required. However, when data blocks from the RECEIVER follow signals or data from the TRANSMITTER, the RECEIVER must delay a minimum 200 (maximum’'500) milliseconds before re-asserting carrie. 3.13.2. Block Format Each Data Block is composed of four components: Header, Function Code, Data and Column Party. 3.13.21. Block Header ‘The first byte after the Initial Carrier is the Header. It is mandatory for every block and is always one byte in length. ‘The Header bits have the following interpretations: Bit 7 - Reverse channel enable, when set, indicates to the recipient that reverse channel data will be accepted 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 acknowledge using the implied method described in section 3.1.4.2, Acknowledgements, on page 5. Note that in order to send reverse channel data, bit 6 and 7 must be set (Reverse Channel Enable and Acknowledge Request). Use of the Reverse Channel Enable Bit is, encouraged to allow transmitting devices control over limited buffer resources. Bit 6 - Acknowledge Request, this bit requests that the recipient transmit an acknowledgement signal after receipt ‘of the current block. This bit may change from block 10 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 number 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. 3.13.22. Funetion Code ‘This is a one (1) byte code that describes the type of data contained within the block. Refer to table 1 Block Type ‘Summary, page 9, for a list of codes. 3.1323. Data ‘The data bytes contain the information as specified by the function code. The block may contain up to 63 data bytes, as specified in the block length field of the header. 3.13.24. Column Parity ‘The column party is one (1) byte. The eight bits of data i this byte reflect the odd parity of all corresponding bits in the block; ie, bit 8 of the Column Parity byte is the odd parity ofall it 8's in the entire block. Column parity will be calculated by the sender as follows’ (a) Begin withthe 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 including, the parity, byte have been used. (©) Send the result in the column parity po: 3.14. Control Signals Control Signals are used to manage the session protocol. Control Signals used by the sender are called flags. Control, Signals used by the recipient are called acknowledgements. ‘Control signals can be tonal or 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 ASCTI, ie. 0-9. 3141. Flags Flags are sent by the sender in place of a data block. They are used when the sender needs to inform the recipient of a ‘change in session status, Page 4 Digital Communication Standard - “SLA Format” Protocol for Alarm System Communications3.14.11. End of Data (zero block) ‘The zero block is used by the sender to mark the end of data. ‘The sender must set the Acknowledgement Request bit. The Reverse channel enable may also be set if the sender is able to accept reverse channel data blocks. A. positive acknowledgement (without a reverse channel ommand) to this Boek should be teated asa disconnect ‘The zero block is required only when tonal acknowledge ‘ments are in use. When data acknowledgements are in effect, TRANSMITTER and RECEIVER should use the Positive Acknowledge block (see section 3.1.4.2. Data ‘Acknowledgement , page 5). 3.14.12. Wait (one block) ‘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 assembled. The sender must set the Acknowl- edgement Request bit, The Reverse channel enable may also be set if the sender is able to accept reverse channel data blocks. 3.14.13. Abort (two block) ‘The abort block indicates the sender must end the session, immediately. The sender may set the Acknowledge Re- quest bit, but is not required to wait for a response. The Reverse Channel Enable bit should not be set.. The abort block should never be considered a positive acknowledge ‘ment of previous blocks, 3.14.2. Acknowledgements Acknowledgements are tonal by default, The TRANS- MITER may, however, request acknowledgement by data block. This is accomplished by the transmission of the optional configuration block (see section 4.3.1. Configuration Block, page 13). ‘The Acknowledgement must follow, within 400 millisec~ nds, the receipt of a complete data block received with the acknowledgement request bit set 3.414.2.1. Tonal Acknowledgements ‘The duration of tonal acknowledgements will be a mini- mum of 500 ‘milliseconds, but not longer than one (I) second. Negative Acknowledgement will be at the recipient's mark frequency, Positive Acknowledgement will be at the recipients space frequency. Transmission Requirements ‘The Positive Acknowledge with Reverse Channel Command reverses the roles of TRANSMITTER and RECEIVER. This Acknowledgement can only be used af- ter the receipt of a correct (column parity) zero block with thé reverse channel enable bit se. ‘The normal Positive Acknowledgement is followed im- mediately by 150 milliseconds 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 receipt of a zero block with the reverse cchannel enable bit set ‘When operating in a reverse channel mode, the RECEIVER (now transmitting) must assume all operating parameters requested by the TRANSMITTER, including baud rate and acknowledgement type. 3.14.2.2 Data Acknowledgement ‘The data acknowledgement is extended capability provided to wansmitters requesting it with the configuration block discussed in section 4.3.1. Configuration Block, page 13. It tgreatly relaxes the reverse channel requirements imposed by tonal acknowledgements, In addition, it_allows differentiation between the Negative and Reject Acknowl- cedgements. ‘The Negative Acknowledgement is used when the data block received was incorrect, ie., loss of carrier was de- tected before the required number of bytes was received, or the column parity was. in error. ‘The Negative Ac- Knowledgement is tonal, and is identical to the Negative Acknowledgement described in section 3.1.4.2.1. Tonal ‘Acknowledgements, page 5. ‘The use of a tonal acknowledgement within the framework of Data Acknowledgements is considered desirable in the cease of Negative. This avoids the conflict caused by a data block type of Negative Acknowledgement that is, itself, re- ceived containing errors. ‘The Implied Positive Acknowledgement allows Data Blocks received correctly to be acknowledged by implica tion, that is, 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 allow it to be acknowledged by impli- cation. The Reject or nine block is considered a Rejection of the data transfer. It informs the sender that the data block be- ing tansferred was received correctly, but the recipient cannot comply. Data blocks acknowledged with the nine block should not be repeated by the sending device. Copyright © September 1997 Security Industry Association Page 5Transmission Requirements ‘The RECEIVER may use the Reject acknowledgement to refuse an N or O block containing an unknown condition code. The TRANSMITTER may use the Reject acknowl- cedgement to indicate non-compliance with command fea- tures not implemented or disabled by the user. ‘The Positive Acknowledgement or eight block is used to acknowledge blocks received ifthe recipient has no data 10 send, or the header byte of the block received had the reverse channel bit cleared and the acknowledge bit set. Positive Acknowledge and Disconnect or seven block 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 channel, enable and acknowledgement request set) tothe TRANSMITTER in order to terminate a call. The TRANSMITTER should respond with a seven block (reverse channel enable and acknowledgement. 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- connect 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 ‘immediate disconnect by the RECEIVER. Positive Acknowledge and Standby or six block is sent by the RECEIVER to instruct the TRANSMITTER to enter Standby Mode in which both the RECEIVER and TRANSMITTER listen concurrently. 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 acknowledgement request set) to the TRANSMITTER in order to enter Standby Mode. The ‘TRANSMITTER should respond with a six block (reverse channel enable and acknowledgement request cleared) if no ‘additional waffic has occurred. ‘The TRANSMITTER may also respond with a data block (thereby acknowledging by implication) to abort the Standby Mode and continue the ‘The use of a Normal Positive Acknowledgement (cight 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 disconnect by the RECEIVER. 3.2, Signal Protocol ‘This section describes the frequencies and signal rates re~ (uired under this standard. 3.2.1. Frequency Assignments ‘This format uses standard Bell 103 FSK frequency encod- ing. The TRANSMITTER mark tone is 1270 + 6 Hertz. ‘The TRANSMITTER space tone is 1070 + 6 Hertz. The RECEIVER mark tone is 2225 + 6 Hertz. The RECEIVER space tone is 2025 + 6 Hertz, 3.2.2. Transmission Rates Two transmission rates are allowable under this standard. They are determined by the TRANSMITTER and com- municated to the RECEIVER by the transmission of the Speed Synchronization Burst described in section 3.1.2 Speed Synchronization Signal on page 3. Normal speed is, 300 +1% Baud, or 3.33 milliseconds of mark or space tone per bit of data’ Siow speed is 110 +1% Baud, or 9.09 milliseconds of mark or space tone per bit of data. 3.2.3. Transmission Mode Al data transfer is performed half-duplex. Transmitters fand 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 decoding incoming tone, The absence of carrier must define a unit's ability to receive signals or data from the opposing unit, Carrier will bbe defined as the mark or space frequency of the sender. 3.3. Byte Protocol Data Blocks are composed of separate bytes in UART (Universal Asynchronous Receiver Transmitter) form, 3.3.1. Start Bit ‘There is one logic zero start bit at the sender's space fre ‘quency. 3.3.2. Data Bits There are eight (8) data bits, least significant bit first Logic zero is at the sender's space frequency. Logic one is, atthe sender's mark frequency. 3.33. Parity Bit There will be one parity bit. Parity will be odd, ie. 0 if the sum of all data bits is odd, 1 ifthe sum is even.’ Logic zero ig at the senders space frequency. Logic one is at the sender's mark frequency. Page 6 Digital Communication Standard - “SIA Format” Protocol for Alarm System Communications3.34, Stop Bits ‘There are two logic one stop bits at the sender's mark fre- quency, 3.35, Byte Timing Bytes within a data block may be separated by no more than I second. Two stop bits are considered minimum and mandatory. Failure to receive a start bit within the alloted time should be handled as a Communication Error. 3.4. Block Protocol ‘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, describes the Standby Mode, and sets the number of re-transmission attempts. 34.1. Data Groups Multiple blocks of data transmitted without individual ac- Knowledgements are called data groups. Multiple Blocks ‘may be sent under this standard provided the total number of bytes passed as dara does not exceed 500 for TRANSMITTER to RECEIVER communications or 300 for RECEIVER to TRANSMITTER communications (this excludes headers, function codes and parity bytes). TRANSMITTERS with limited buffer resources may in- form the RECEIVER, thereby setting new maximums on incoming data size through the use of the configuration block (see section 4.3.1. Configuration Block, page 13). All. data blocks within @ group must be sent contiguously, with the acknowledgement request bit cleared (logic zero) fon all but the last data block. Acknowledgements sent after the last data block always refer to the entre data group. Repeats of all blocks are required should the recipient require e-transmission. Should a communication failure dccur, all Blocks transmitted prior (othe failure and before the receipt of a valid positive acknowledgement must be considered not delivered by the sending device. 34.2, Timing Restraints 34.2.1. Initial Carrier Each Data Block must begin with a constant carrier tone to tenable the recipient to synchronize (0 the incoming block. ‘This carrier must be sent at the sender's mark frequency (270. Hertz for TRANSMITTER, 2225 Hertz for RECEIVER), Transmission Requirements ‘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 intervals (39.96 milliseconds at 300, bbaué, 109,08 milliseconds 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 carrier. This delay must be at least 200 nilliseconds and not greater than 500 milliseconds. The delay should not begin until the cessation of tone or data from the opposing device. The initial carrier duration must be lengthened to 150 milliseconds under this condition. 34.22. Block Timing Individual Data Blocks within Data Groups may be sepa rated by no more than 4 seconds. Cartier (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. 34.2.3. Tonal Acknowledgements After a data block containing an acknowledgement request has been sent, the sender should wait no more than 2.5 seconds for the opposing device to respond. A failure 10 respond should be handled as a Communication Error. After ansmitting an acknowledgement to a non-zero block, a device should wait a minimum of 4 seconds for a new data block. A failure to receive a new block should be handled as a Communication Error. ‘fier transmitting an acknowledgement to a zero block, a device may execute an immediate End of Session. 34.24. Data Acknowledgements ‘After a data block containing an acknowledgement request hhas 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. 3.43. Standby Mode Either the TRANSMITTER or the RECEIVER may end the Standby Mode by transmitting a 4 second mark frequency Tollowed by the outgoing new data block. Standby Mode should never exceed 60 seconds, The RE- CEIVER or TRANSMITTER may end the standby mode at any time deemed appropriate even if only to transmit a zero block. However, only the RECEIVER may re-initiate the Standby Mode by issuing the six block command. 3.44. Re-transmission ‘The TRANSMITTER or RECEIVER should re-transmit any data block after receipt of a Negative Acknowledge or 4 second loss of carrier. Either device should re-transmit at Copyright © September 1997 Security Industry Association Page 7least once, but no more than 3 times (total of four) before ‘executing a Communication Failure. Re-transmission should never occur when cartier is heard from the opposing device. 3.5. Session Protocol This section describes how contact is established, how se~ curity is maintained, and under what conditions’ a call is terminated 3.8.1. Establishing Contact 35.11. TRANSMITTER Initiated ‘The typical TRANSMITTER initiated session begins when the RECEIVER goes off-hook in response to a ring signal ‘The Receiver issues a Handshake signal described in section 3.1.1. Handshake Tone on page 3. The TRANSMITTER should respond with the Speed Syn- cchronization Signal and first data block. 38.1.2. RECEIVER Initiated ‘The RECEIVER may, as an extension of this standard, provide the ability to dial out and establish contact with TRANSMITTERS able to go off-hook in response to a ring signal. These TRANSMITTERS 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 Synchroniza- tion Signal must be repeated atleast 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 ‘Synchronization ‘Signal must respond with the Access Passcode data block. If the Access Passcode is valid, the ‘TRANSMITTER should give a positive tonal acknowledge with reverse channel command followed by a configuration block. If the Access Passcode is not valid, the TRANSMITTER should disconnect immediately. Only if the block containing the Access Passcode was in error (bad party) should the TRANSMITTER respond with a negative acknowledgement. 4. Data Interpretation This section describes the various function code blocks and theie respective data interpretations. Function blocks fall into three basic types: System, Information and Special 35.13. Security ‘TRANSMITTER initiated calls provide security by limiting access to a RECEIVER at a pre-programmed telephone number. TRANSMITTERS able to respond 10 a ring signal and establish contact by call must receive a data block with the access puscode function code before any ober data blocks, tF-any other function codes rgcsived, the JTRANSMITTER should immediately terminate thecal 3.2. Call Termination A communication session may end normally or be inter- rupted by external forces prior to normal termination, 35.21. 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 Fing signal to indicate 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 requiring communication. 3.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, printed and acknowledged by the operator 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 additional information remains undelivered. Ifa data block recipient detects framing or parity errors it should wait up to 12 seconds for loss of carrier. When the ‘opposing device's carrier ceases, the recipient should send a Negative Acknowledgement. If cartier does not cease within 12 seconds, the recipient should terminate the call by going on-hook. ‘System Blocks are unique in that they contain no data, but rather are used to control the block and session protocols. Information Blocks are used to move data in a packet form called Data Codes. This information can be event, em ronmental, control, or program information. Speci Blocks are used for special information not contained in a Page 8 Digital Communication Standard - “SLA Format” Protocol for Alarm System CommuData Code format. Special Blocks include Configuration, Access Passcode, Account, ASCII or Extended. 4.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 3.1.4 Control Signals on page 4. 4.2. Information Blocks Information Blocks carry information in packets called Data Codes. Information Blocks may contain multiple Data Code packets, provided they are separated with the packer separator 7, ASCH character 47. Table 1: Block Typ Data Interpretation 42.11. Data Code Packets Each Data Code is composed of three basic fields: type address and units. Only the type field is required. The basic form is: TTAAAA*UUUUUUun ‘where TT represents the type, AAAA represents the address number, UUUUUUuu is the units number. 421,11. Data Code Types Data Code packets always begin with a two character se~ quence: the Data Code Type. Valid characters for type ‘codes are the capital leters A through Z. Type codes have function scope only; ie., they are defined only for the Function Block type in which they are carried. The type code BA can have one definition within the Event Block (Burglar Alarm) and a different meaning for Environmental, Blocks. e Summary 0 | End of Data | Wait 2 [Abort No | Yes | 6 | Positive Acknowledge and Standby ‘No | Yes | 7 Positive Acknowledge and Disconnect ‘Yes [Yes | 8 | Positive Acknowledge Yes | Ves | 9 | Reject Yes [Yes | C_| Control (ent by TX in response to query) ‘Yes[ No | E| Environmental ‘Yes | No[ N—_| Event (new) ‘Yes [No | | Event old) Yes —[ Yes | P| Program (sent by TX in response to query) ‘Yes [No | @ | Configuration No [Yes |? | Access Passcode ‘Yes | Yes|¥ | Account ID Yes [No | & | Origin ID Yes | Yes [A | ASCIT Yes | Yes |X| Extended Yes [No | L| Listen-In i Yes —[ Yes | V__ | V-Channel Request 5 Yes [Yes |v V-Channel Frame special] Yes | Yes__| 1 | Video 4.2.1. General Conventions Most Data Code Packets have the same basic structure and represent events within the system. Several special packets, called modifiers, are allowed to add additional information about other packets in the block. These modifiers do not represent events and have meaning only in the presence of ‘other data code packets in the block. 42.1.1.2. Address Number ‘The address number is optional, If included, it must follow the 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 O through 9, ASCII 48 to 57, and A through F, ASCII 65 10 10. Copyright © September 1997 Security Industry Association a ae Page 9Data Interpretation ‘The address number must be at least one character (if present) and contain no more than 4 characters. Leading ‘eros may be included but are not required, 4.2.1.1.3. Units Field ‘The Units Field contains information about the magnitude of the event in the data code. The units field is optional. If included, it must follow the address number or data code type without spaces or other characters. The units field is, composed 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 beginning of a units number. ‘The Unit Number must follow the Unit Tag without spaces or other characters. The unit number must be an ASCIL representation of a decimal number. The valid characters for this field are O 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 (ASCIL 46) is allowable where vali ‘The unit number must be at least one character (if present) and contain no more than 6 characters. Leading zeros may be included but are not required. ‘The Unit Type is one or two ASCII characters and must follow the unit number. ‘The characters determine the unit ‘of measure. Table 2, Unit Types, below shows the types currently defined, New types willbe added upon request as detiled in seetion 71 Delinition of New Data Codes on page 19 42.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 itself and occur within the same data block, data packets that precede the modifiers, or follow in a different block are not affected. Modifier types have global scope, ic. they are defined for all Information Blocks. Modifier Code packets always begin with a two character type sequence. Modifier Codes are lower case to distinguish them from Data Codes. Valid characters for type codes are the lower case letters a through z, 4212.1. Date ‘The Date Modifier is used to indicate the date on which an ‘event took place. This allows historical 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 digits). Altemately, the day of week (1-7, Sunday = 1) may be passed in the DD position if ‘MM is set to zero. All numbers are ASCII represented, decimal numbers. 42.122. 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 - $9), and SS is Seconds (00 - 59). Seconds and the preceding ‘are optional. All numbers are ASCIL represented, decimal numbers. Both digits should be present even for values less than 10; eg., 7 should be represented as 07. Table 2: Unit Types | Amperes, Taches Celsius Degrees IM | Inches per Minute ‘Centimeters kg ‘Centimeters pivfinute M_ Fahrenheit Degrees a Feet per Minute ‘MA | Milliamperes Grams mM_| Meters per Minute Gallons per Hour MV _[ millivolts Gallons per Minute, Percent ‘Hours Volts: Page 10 Digital Communication Standard - “SIA Format” Protocol for Alarm System Communications4.2.1.2.3. Subseriber ID ‘The Subscriber ID is used to indicate the identity of the user causing the actions or events included 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 jis the subscriber number (0000 - 9999). ll numbers are ASCH represented, decimal numbers. Leading zeros may be included, but are not required. 42.124. Area ID ‘The Area ID is used to indicate the identity of a logical area causing the actions or events included 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 js the area number (0000 - 9999). All numbers are ‘ASCII represented, decimal numbers. Leading zeros may bbe included, but are not required. 4.2.1.2. 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). Ali hhumbers are ASCH represented, decimal numbers. Leading, zeros may be included, but are not required 4.2.1.26. 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 Automated ID Modifier is: aiSSSS where al is the type code for the Automated ID Modifier, and SSSS is the automated number (0000 - 9999). All ‘numbers are ASCII represented, decimal numbers. Leading zeros may be included, but are not required. 421.27. Telephone 1D ‘The Telephone ID indicates the index of the telephone service number used when the following events occurred. ‘The format forthe Telephone ID Modifier is phXXXX where ph is the type code for the Telephone ID Modifier, and X/ the telephone index in ASCII digits 0-9. Atleast, one digit must follow the modifier type code. Up to 4 digs may be represented. Hyphens, commas and other Data Interpretation non-numeric characters should nor 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. 421.28, Name “The Name Modifier is used to indicate the name of a specific user or zone ted to an event. Ttis a variable length modifier (maximum length is driven by the block length). All characters must be printable ACSII characters. 4.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: WLLLL where Iv is the type code for the Level Modifier, and LLL is the level number (0000 - 9999). All numbers are ASCIL represented, decimal numbers. Leading zeros may be included, but are not required. 4.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 vais 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. 4.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 ASCIL represented, decimal numbers. Leading zeros may be included, but are not required. 4.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 bbe included, but are not required. Copyright © September 1997 Security Industry Association Page 11| Data Interpretation 4.2.1.2.13. Sub-Subseriber ‘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: ss$SSS ‘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. 4.2.2. Control Block ‘The Control block is identified with a function code 67, ASCH character €. Control blocks contain information intended to modify the state of a TRANSMITTER output, ‘or temporary setting. ‘The RECEIVER sends control blocks to the TRANSMITTER under most conditions, however, the TRANSMITTER can send a control block in response to a query fom the RECEIVER. Control blocks from a TRANSMITTER always contain status information, never data intended to control the RECEIVER, Control information takes the general form xty, 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 4: Control Block Data Code Definitions. 4.2.3. Environmental Block The Environmental block is identified with a function code 69, ASCII character E. The E block is used to pass environmental information such as temperature, flow and humidity. All environmental data is presented unresolved, there is no equivalent of the event block O structure 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 degrees. Valid data odes used in the Environmental block are defined in Appendix A, Table 7: Environmental Block Data Code Definitions. 4.2.4. Event Block ‘The Event block is identified with a function code 78, ASCII character N, or a function code 79, ASCH character ©. The N block is used to identify information requiring resolution by the recipient. The O block is used to identify information which has been previously resolved, either locally or by previous communication to a RECEIVER. Event blocks are always sent by the TRANSMITTER to the RECEIVER Examples 3 and 4 in Appendix B show typical Event Blocks. In Example 3: New Event Block, an unresolved (N) panic alarm on zone 12 is being sent.’ In Example 4: Old Event Block, a previously resolved opening report is tansferred. This resolved opening report has met eriteria set by the local alarm system (user has permission to open and did so within a pre-programmed time window) and was reported 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. Information 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 requires resolution by the RECEIVER operator or Host Au- tomation System, Valid data Codes used in the Event block are defined in Appendix A, Table 6: Event Block Data Code Definitions. 425, Program Block ‘The Program block is identified with a function code 80, ASCII character P. Program blocks contain information intended to modify the operation 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 TRANSMITTER always 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 locations. ‘While this method provides access to only a small subset of, programming items ina TRANSMITTER, it allows an ‘operational RECEIVER access (0 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 ASCIL47, character. Page 12 Digital Communication Standard - “SIA Format” Protocol for Alarm System CommunicationsData Interpretation Example 5 in Appendix B shows a typical Program Block. ‘This tock shows a program request from the RECEIVER intended to change the Keyeode used by subscriber 8, The vali data codes used inthe program locks re defined in ‘Table 5 Program Block Data Code Definitions on page 21. 4.3. Special Blocks Special blocks are used to pass information not formatted in the Data Code Packet method. The interpretation of the data contained in a Special Block varies based on the function code, 43.1, Configuration Block ‘The configuration block is identified with a function code 64, ASCII character '@'. The configuration block is used by TRANSMITTERS requesting additional functions not supported in the base standard. 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 TRANSMITTER ‘may include only those fields required by the SIA Compati- bility Level or optional features being requested. Fields with arguments are followed directly by a minimum one character (maximum 6 character) ASCII coded number. ‘The Configuration fields defined are: 43.11. A-Data Acknowledgement Request ‘The TRANSMITTER may request Data Acknowledge ‘ments from the RECEIVER by including the A field. No ‘arguments are included. Note that acknowledgements are tonal by default. The acknowledgement to the configuration block will be tonal even if data acknowledgements have been requested. Data ‘acknowledgements can only begin after the RECEIVER has given a positive tonal acknowledgement tothe configura tion bloc! 43.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, 43.1.3. D-Dealer or Agency ID ‘The TRANSMITTER may provide an agency ID number indicating the company servicing the TRANSMITTER, 43.14, M-Manufacturer's ID Optional TRANSMITTER manufacturer ID number, issued by STA, 43.1.5. P-Product ID Options] TRANSMITTER product ID number, issued by manufacturer 43.1.6. _R- TRANSMITTER Rom Version Number Optional TRANSMITTER version and/or revision level 43.17. 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 integer 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 include this field fon 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 fon page 21, 43.18. _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. 43.19. B- Maximum TRANSMITTER Block Size Sets the maximum number of characters (bytes) that the TRANSMITTER may receive in one block. Must be less than the normal 63. This allows TRANSMITTERS with limited internal resources to function within the SIA standard. Also sets Group maximum to the same size unless the G field is also included, 43.1.10. G - Maximum TRANSMITTER Group Size Sets the maximum number of characters (bytes) that the ‘TRANSMITTER may receive in a multi-block group. Set to 300 by default, set equal to Block size if B option given. ‘This option resets the Group maximum size to the number passed. This option must follow a B option if also present in the block. Allows double buffering TRANSMITTERS. to have different sizes for incoming and processing buffers. Example 6 in Appendix B shows a typical Configuration Block. This example shows a configuration block requesting data acknowledgements” from a ‘TRANSMITTER installed by dealer 24 Copyright © September 1997 Security Industry Association Page 13Data Interpretation 4.3.2. Access Passcode Block ‘The access passcode block is identified with a function code 63, ASCII character "?’. The Access Passcode block is required only when a session 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 dependent ‘and not detailed in this standard. Because the Access Passcode Block must be followed by the Configuration Block from the TRANSMITTER, the Reverse Channel Enable bit must always be set on this block. Example 7 in Appendix B shows a typical Access Passcode Block. 433. Account Block ‘The account block is identified with a function code 35, ASCII character “#, and is required to be sent by the TRANSMITTER prior to any other block excepr the configuration block. The account block will contain the account number for the TRANSMITTER that is calling the RECEIVER. The account number is an ASCII coded umber of no more than six digits. The number is repre- sented most significant digit first. ‘The TRANSMITTER may send additional account blocks during a communication session to modify subsequent data blocks being sent to the RECEIVER. In this way, multiple account reports during a single call are supported. A TRANSMITTER may test the communication link by issuing an account block only (and ending the session as, appropriate). 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 identify the destination for control and programming information. ‘The RECEIVER is not required fo issue an account block before control or programming blocks are sent. The last account block received 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 4.3.4, Origin ID Block The Origin ID block is identified with a function code 38, ASCII character °&’, and may be sent by the TRANSMIT. ‘TER after the account block. The Origin ID block wil contain the Caller 1D, Cellular ESN or other media relative number that identifies the point of origin for the carrier being used by the TRANSMITTER. The Origin ID number is an ASCII coded number of no more than 32 digits. The number is represented most significant digit first. ‘The TRANSMITTER may send only one Origin ID block uring a communication session, Example 9 in Appendix B shows a typical Origin ID Block. ‘This example shows the acknowledge 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 o¢ CT hexadecimal 4.3.5. ASCII Block ‘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 ACSI Text Block. 4.3.6. Extended Block ‘The Extended block is identified with a function code 88, ASCII character X. This code signifies that the block contains arbitrary information not defined by the standard, ‘The action taken following this code is determined by the ‘manufacturer(s) of the RECEIVER and TRANSMITTER. Proprietary formats may be packaged using the X block alter providing device identification with the Configuration Block (see section 4.3.1 Configuration Block, on page 13). Implementation of features not found in the standard may be provided in this way. Note that data within the extended block is not required to be ASCH character oriented: i, data bytes may be the full range 00-FF Hex. However, for compatibility with the implementors are restricted to the printable range of ASCIL values (20-7E Hex). Example 11 in Appendix B shows a typical Extended Block, Page 14 Digital Communication Standard - “SIA Format” Protocol for Alarm System CommunicationsApplication may be made to have useful data structures submitted for incorporation into this Standard, see section 7.1 Definition of New Data Codes 4.3.7. Listen-In Block ‘The Listen-In block is identified with a function code 76, ASCII character L. This code signifies that the sender Wishes (0 insert a listen-in period. Listen-In allows the TRANSMITTER to place audio information from the protected premise directly on the phone line. Only the TRANSMITTER may request alisten-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 request 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 acknowledgement must be ‘a normal positive (no reverse channel, standby or dis- connect command), or any data block permitted under the rales of implied acknowledgement. Following the listen-in time, the TRANSMITTER will send ‘out the next data block in response to the block received from the RECEIVER prior to the listen in interval. The RECEIVER may hang up at any time during the listen-in period. 4.3.8. V-Channel Block ‘The V-Channel (voice) block is identified with a function code 86, ASCH character V. This code signifies that the sender wishes to insert a V-Channel period. V-Channel time allows the TRANSMITTER and RECEIVER to suspend use of the line for digital information, and allows the RECEIVER location and TRANSMITTER location to hhave voice communications. The V-Channe! interval itself is marked with V-Channel frame blocks using function code 118, ASCII character V. Data passed in the Y-Channel block defines the V-Channel time in seconds, ‘The time is represented by an ASCII ‘encoded number of no more than four digit. 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 response to the V- ‘Channel block Data Interpretation \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 TRANSMITTER (if able to comply) should respond with the v data group described below. Ifa request is made by the TRANSMITTER, the RECEIVER should acknowledge with a Reject response only if unable to comply. Any valid positive response (no reverse channel, standby or disconnect command) enables the TRANSMITTER to begin the V-Channel group immediately YV-Channel time is inserted between two blocks of a data group with the function 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 request bit. The V-Channel interval is in- serted after the completion of this block. AC 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. 4.39. Video Block ‘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. 3—0 ASCH Example 15: V-Channel Terminator Block WE [an [tien] Pence Dan iealatefeas 76 Tex @ ¥ ASCH Example 16: Video Block Tanto ro Tb toro —en007 — ios — au — aw Copyright © September 1997 Security Industry Association Page 31APPENDIX B - Examples Data Code Packets The following are examples of how to submit requests for Code Table Additions (see section 7.1.5) as well as examples of Data Code Packets. Analog Service Restoral ‘Two Letter Code: AN (Address Field = zone or point, Unit Field = Descriptive Phra: Analog Restoral, Description: ‘An Analog Fire Sensor which required service has restored to its normal operating range. Data Code Packet: “ANO14", analog sensor located at point 14 has returned to its normal operating range, Analog Service Required Two Letter Code: |AS (Address Field = zone or point, Unit Fiel Descriptive Phrase: Analog Service Description: ‘An Analog Fire Sensor needs to be cleaned or calibrated. Data Code Packet: "ASO14", analog sensor located at point 14 requires attention. Burglary Alarm with Cross Point in Alarm “Two Letter Code: BM (Address Field = zone or point, Unit Field Descriptive Phrase: Burglary Alarm-Cross Point. Description: Burglary Alarm with a Cross Point also in Alarm, Alarm Verified. Data Code Packet: "BMO14", point 14 has a verified burglary alarm, Missing Alarm with Recent Closing Two Letter Code: CM (Address Field = zone or point, Unit Field Descriptive Phrase: Missing Alarm-Recent Closing Description: ‘A point has gone missing within 2 minutes of closing. Data Code Packet: "CMO14", point 14 has a missing alarm reporting within 2 minutes of closing. Card Assigned Two Letter Code: DA (Address Field = new User ID, Unit Fiel Descriptive Phrase: Card Assigned Description: ‘An access identification has been added to the controller. Data Code Packet: "id024DA 123", user #24 has added access identification for user #123. Card Deleted ‘Two Letter Code: DB (Address Field = new User ID, Unit Field = Descriptive Phrase: Card Deleted Description: ‘An access identification has been deleted from the controller. Data Code Packet: *id024DB 123", user #24 has removed access identification for user #123. Request To Enter ‘Two Letter Code: DE (Address Field = door number, Unit Fick Descriptive Phrase: Request To Enter Description ‘An access point was opened via a Request to Enter (RTE) device. Data Code Packet: "DE027", door #27 was opened via an RTE device. Door Left Open-Restoral ‘Two Letter Code: DH (Address Field = door number, Unit Fiel Descriptive Phrase: Door Left Open-Restoral Description: ‘An access point in a Door Left Open state has restored Data Code Packet: "DHO12", door #12 which was previously left open has restored. Copyright © September 1997 Security Industry Association Page 33,APPENDIX B - Examples Door Forced- Trouble ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Door Left Open-Alarm ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Door Left Open-Trouble Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Request To Exit, ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: External Device Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Missing Alarm-Exit Error Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Fire Cancel Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Fire Alarm-Cross Point Two Letter Code: Descriptive Phrase: Description: Data Code Packet: DJ (Address Field = door number, Unit Field = Door Forced-Trouble ‘An access point has been forced open while the panel/area is in the disarmed state. "DJ042", door #42 has been forced open while disarmed DL (Address Field = door number, Unit Field = Door Left Open-Alarm ‘An access point was open when open time expired and the panel/area was armed. "DLO12", door #12 was propped open while the area was armed. DM (Address Field = door number, Unit Fiel Door Left Open-Trouble ‘An access point was open when open time expired and the panel/area was disarmed. "DLO12", door #12 was propped open while the area was disarmed, DX (Address Field = door number, Unit Field = Request To Exit An access point was opened via a Request to Exit (REX) device. "DX027", door #27 was opened via an REX device. EX (Address Field = condition number, Unit Field External Device Condition ‘A specific reportable condition has been detected on an extemal device. pi03EX18", external device #3 is reporting condition #18, EZ (Address Field = zone or point, Unit Field =~) Exit Missing Alarm ‘A point remained missing at the end of the exit delay period. "EZ245", point 245 remained missing at the end of exit delay. FC (Address Field = zone or point, Unit Field = Fire Cancel ‘A Fire Alarm has been cancelled by an authorized user. “id013FC112", fire alarm on point #112 has been cancelled by user #13. FM (Address Field = zone or point, Unit Field Fire Alarm-Cross Point Fire Alarm with a Cross Point also in Alarm, the Fire Alarma is Verified. “FMO14", point 14 has a verified fire alarm. Page 34 Digital Communication Standard - “SIA Format” Protocol for Alarm System CommunicationsAPPENDIX B - Examples Equipment Fail Condition ‘Two Letter Code: IA (Address Field = condition number, Unit Field = >). Descriptive Phra: Equipment Failure Condition Description: ‘A specific reportable condition has been detected on a device connected tothe -ontrol pane Data Code Packet: ‘pi871A07", equipment at location #87 is reporting condition #7, Equipment Fail- Restoral ‘Two Letter Code: IR (Address Field = condition number, Unit Field = ~~) Descriptive Phrase: Equipment Fail-Restoral Description: [A specific reportable condition on a device connected to the control panel has restored to normal. Data Code Packet: "pi871RO7", equipment at location #87 is back to normal. Network Condition ‘Two Letter Code: NC (Address Field = condition number, Unit Fiek Descriptive Phrase: Network Condition Description: ‘A specific reportable condition on a communications network exists. Data Code Packet: "pt02NCO6", communications network #2 is reporting a condition #6. Network Restoral Two Letter Code: NR (Adéress Field = condition number, Unit Field Descriptive Phrase: Network Restoral Description: ‘A communications network has retumed to operation, Data Code Packet "02NRO1”, communications network #2 has restored from failure condition Network Failure ‘Two Letter Code: NT (Address Field = condition number, Unit Fiel Descriptive Phrase: Network Failure Description: ‘A communications network has failed. Data Code Packet: *pt2NTO1", communications network #2 failed because of condition #1. Early To Open from Alarm ‘Two Letter Code: (OH (Address Field = user number, Unit Field = Descriptive Phrase: Early Open-From Alarm Description: ‘An area in alarm was disarmed before the opening window. Data Code Packet: "ri2/id830H", area #2 was in alarm when it was opened early by user #83. Late To Open from Alarm Two Letter Code: OL (Address Field = user number, Unit Field Descriptive Phrase: Late Open-From Alarm Description: ‘An area in alarm was disarmed after the opening window. Data Code Packet: "ri2/id83OL", area #2 was in alarm when it was opened late by user #83. All Points Tested ‘Two Letter Code: TC (Address Field = ----, Unit Field = Descriptive Phrase: All Points Tested Description: All points subject to current test mode have been tested, Data Code Packet: "TC", all points tested. (Data Code stands alone.) Copyright © September 1997 Security Industry Association Page 35,APPENDIX B - Examples Walk Test Point ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: ‘Tamper-Trouble ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Extra Account Two Letter Code: Descriptive Phrase: Description: Data Code Packet: REF Receiver Tamper Restoral ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Low Received Signal Strength Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Missing Alarm with Cross Point ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: RF Interference Two Letter Code Descriptive Phrase: Description: Data Code Packet: RF Receiver Tamper Two Letter Code Descriptive Phrase: Description: Data Code Packet: ‘TC (Address Field = zone or point, Unit Field Walk Test Point ‘This point was tested during a Walk Test. “TP214", point #214 was tested; panel is in Walk Test Mode, ‘TT (Address Field = zone or point, Unit Field = —--) ‘Tamper-Trouble ‘Alarm equipment enclosure opened with point or zone in disarmed state. "TT245", point #245 has a tamper alarm, the area or panel is disarmed. XA (Address Field = condition number, Unit Field Extra Account Report Central Station Receiver has received an event from an account not specified in its database "ptO3X02", the account reporting condition #2 over communications path #3 is not specified in the account number database. XJ (Address Field = —, Unit Fick RE Receiver Tamper-Restoral ‘A Tamper condition at a Premises RF Receiver has restored. "pi031XJ", premises RF Receiver at address 31 has had cover put back on. XL (Address Field = Low RSSI Level, ‘The signal strength of an event communicated via a radio carrier is below acceptable level "plO1/IvO2XL", a radio signal with low signal strength, level #2 has been received over communications path #1. ., Unit Field XM (Address Field = zone or point, Unit Field Missing Alarm-Cross Point Missing alarm with a Cross Point also in alarm (or missing), Alarm Verified. "XMO14", point 14 has a verified burglary alarm. XQ (Address Field RF Interference A radio device is detecting RF Interference. , Unit Field "pi37XQ", a radio device at address #37 has detected RF interference. XS (Address Field = —, Unit Field = RF Receiver Tamper. ‘A Tamper condition at a Premises RF Receiver is detected. "pi031XS", premises RF Receiver at address 31 has had cover removed, Page 36 Digital Communication Standard - “SIA Format” Protocol for Alarm System CommunicationsAPPENDIX B - Examples “Fail To Test Two Letter Code: XX (Address Field = condition, Unit Field Descriptive Phrase: Test Failed Description: AA specific test from a panel was not received. Data Code Packet: ptO4XX", a test signal due by a specified time over path #4 was not received. RF Interference-Restoral Two Letter Code: ‘XH (Address Field = ----, Unit Field = Descriptive Phrase: RF Interference Restoral Description: ‘A radio receiver that previously reported an RF Interference condition no longer detects that condition. Data Code Packet: "pi37XH", a radio receiver at address #37 no longer detects RF interference. Test Off Normal Two Letter Code: RY (Address Field = —--, Unit Descriptive Phrase: Test Off Normal Description: Routine test signal pls indication that one or more abnormal conditions exists at the protected premises. Data Code Packet: "RY", test plus indication that there is an unrestored condition existing. Missing Supervision ‘Two Letter Code: BZ (Address Field = zone/point, Unit Field = Descriptive Phrase: Missing Supervision. Description: ‘A non-Fire Supervisory point has gone missing, : Data Code Packet: "BZ214", non-fire supervisory point #214 has gone missing. /~ Door Left Open (non-Alarm, non-Trouble) Two Letter Code: DN (Address Field = door number, Unit Fiel Descriptive Phrase: Door Left Open Descriptior ‘An access point was open when the door eycle time expired. Data Code Packet: "DNO16", door #16 was propped open ‘Access Denied-Unauthorized Time ‘Two Letter Code: DP (Address Field = door number, Unit Fi Descriptive Phrase: Access Denied-Unauthorized Time. Description: ‘An access request was denied because the request is occurring outside the ‘user's authorized time window(s). Data Code Packet: id876DPO12", user #876 was denied access through door #12 because the request occurred outside his authorized time window. ‘Access Denied-Unauthorized Arming State ‘Two Letter Code: DQ (Address Field = door number, Unit Field = Descriptive Phrase: ‘Access Denied-Unauthorized Arming State. Description: ‘An access request was denied because the user is not authorized in this area ‘when the area is armed. Data Code Packet: id467DQ017", user #467 was denied access through door #17 because the request occurred when the area was armed and the user is only authorized in ‘area when itis disarmed, Copyright © September 1997 Security Industry Association Page 37APPENDIX B - Examples Access Denied-Unauthorized Authority Level Two Letter Code: Descriptive Phrase: , Description: Data Code Packet: Access Denied-Interlock Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Door Locked ‘Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Access Denied-Door Secured Two Letter Code: Descriptive Phrase: Description: Data Code Packet: Missing Fire Supervision Two Letter Code: Descriptive Phrase: Description: Data Code Packet: User Code Added Two Letter Code: Descriptive Phrase: Description: Data Code Packet: User Level Set Two Letter Code: Descriptive Phrase: Description: Data Code Packet: DV (Address Field = door number, Unit Field =~ ‘Access Denied-Unauthorized Authority Level. ‘An access request was denied because the user is not authorized in this area "id997DV026", user #997 was denied access through door #26 because the user is not authorized in this area. DW (Address Field = door number, Unit Fel ‘Access Denied-Interlock Active. ‘An access request was denied because the door’s associated Interlock point is, open. "2 1DWOO3, user #21 was denied access through door #3 ecause door #3's Interlock point was open. DY (Address Field = door number, Unit Fiel Door Locked. The door's lock has been engaged. "id2 14D Y042, user #214 has locked door #42. DZ (Address Field = door number, Unit Field ‘Access Denied-Door Secured. ‘An access request was denied because the door has been placed in an Access Closed state. id372DZ097, user #372 was denied access through door #97 because door #97 is in an Access Closed state. FZ (Address Field = zone/point, Unit Field Missing Fire Supervision. ‘A Fire Supervisory point has gone missing. "FZ036", fire supervisory point #36 has gone missing. JY (Address Field = user number, Unit Field = User Code Added. A.user’s code has been added. "id739Y36", subscriber #739 has added user #36. JZ (Address Field = user number, Unit Field User Level Set. A.user’s authority level has been set. "id25JZY414", subscriber #25 has set the authority level of user #414. Page 38 Digital Communication Standard - “SIA Format” Protocol for Alarm System Communications