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

                                                                                                           

 

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.

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.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.

 

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.

 

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.

 

(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.

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.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.

 

 

 

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.

 

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. 

 

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

 

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.

 

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