One-Way Serial Data RF Module Developer Guide

One-Way Serial Data RF Module Developer Guide Revision G

Preface Notice Copyright 2011 Inovonics Inovonics intends this manual for use by Inovonics customers only. All comments concerning the contents of this manual should be directed to the Inovonics marketing department. No part of this work covered by copyright may be reproduced in any form either graphically, electronically or mechanically; including photocopying, recording, taping, or storing in an information retrieval system without prior written permission from Inovonics. Note: Features and capabilities marked Future in this document are not implemented in current products. These capabilities are included for your application planning and design. Trademarks Inovonics and EchoStream are registered trademarks of Inovonics. All other brand names and product names used in this manual are trademarks, registered trademarks, or trade names of their respective holders. Technical Services Contact Information For Inovonics technical services: E-mail: support@inovonics.com Phone: (800) 782-2709; (303) 939-9336 Revision G 2

Document Conventions The following notices are used throughout this document: Note: Emphasizes points, provides supplementary infomation, or indicates minor problems in an expected outcome. Caution: Indicates possible damage to equipment or loss of data, as well as potential problems in an expected outcome. Warning:Indicates the possibility of minor injury to oneself or others. Danger:Indicates the possibility of serious or fatal injury to oneself or others. Revision History Revision Level B C D E F G Revision Description Edited Serial I/O - UART logic-levels Edited Serial I/O - UART logic-levels ; edited cover and made changes to paragraph styles Minor copy edits; added integration graphic to overview section Edited Low Battery Condition ; edited Message Notes ; edited 0x59 Low Priority Payload Message from RAC to Two-Way Serial Data RF Module Added note that the application controller must be designed to recognize the RF module PTI; edited Industry Canada number per latest feedback Removed installation information so as to create separate installation instructions. Revision G 3

Table of Contents Preface 2 Notice... 2 Trademarks... 2 Technical Services Contact Information... 2 Document Conventions... 3 Revision History... 3 Chapter 1 Overview 6 1.1 Introduction... 6 1.2 One-Way Serial Data RF Module Components... 7 1.2.1 Product Information...7 Chapter 2 Registration 8 2.1 Registration Overview... 8 2.2 Registration Procedure from the End User s Perspective... 8 2.3 Registration Procedure from the Developer s Perspective... 9 2.4 Removing a Registered Device from the System... 9 Chapter 3 Message Information 11 3.1 One-Way RF Messages... 11 3.1.1 Message Notes...11 3.1.2 Configuration Commands...11 3.1.2.1 0x05 Set Check-In from the Remote Application Controller to the RF Module...11 3.1.2.2 0x25 Request EchoStream Reset from RAC to One-Way Serial Data RF Module...12 3.1.3 One-Way Serial Data RF Module Inbound Payload Messages...12 3.1.3.1 0x58 High Priority Payload Message from RAC to One-Way Serial Data Revision G 4

RF Module...12 3.1.3.2 0x59 Low Priority Payload Message from RAC to Two-Way Serial Data RF Module...13 3.2 Data Acknowledgement... 13 3.2.1 0x06 Data Acknowledgement from One-Way Serial Data RF Module to RAC...13 3.2.2 0x15 Data Non-Acknowledgement from One-Way Serial Data RF Module to RAC...14 3.3 Check-In Messages... 14 3.3.1 0x1C Check-In Message from One-Way Serial Data RF Module to the Remote Application Controller...14 3.4 Product Type Identifiers for EchoStream Devices... 15 3.4.1 Product Naming Conventions...15 3.4.2 EchoStream Device Identifiers Table...16 Revision G 5

Chapter 1 Overview 1.1 Introduction EchoStream RF modules are designed to be easily interfaced with your electronic remote application controller (RAC). Your RAC contains application specific functionality and uses the RF module to send application-specific data over the wireless network. The RF module communicates with your application controller via a wireless connection, and your remote application controller via a serial connection, allowing the assimilation of any user-specific application into an EchoStream system. Once integrated with an existing product, an RF module provides you with complete EchoStream functionality. The E*1941XS, equipped with the UART logic-level serial connection, is primarily intended for use as a daughter board, interfacing directly with your RAC. Figure 1-1 One-Way System Components Revision G 6

Overview 1.2 One-Way Serial Data RF Module Components The E*1941XS is a one-way serial data transmitter, designed to physically interface with your product. Serial data sent to the E*1941XS from your remote application controller is formatted by the E*1941XS, and the data is then transmitted as an RF message to the network coordinator. 1.2.1 Product Information http://www.inovonics.com/one-way-serial-data-rf-module.aspx Revision G 7

Chapter 2 Registration 2.1 Registration Overview Every device is programmed with a four-byte unique identification (UID) number. The UID is sent with every message, indicating the device which transmitted it. The UID is made up of a one-byte market identification (MID) number and a three-byte serial number. The bar code label on each printed circuit board includes the eight digit serial number. For example the bar code label 00991240-2028B-1 begins with the eight-digit serial number: 00991240. Converting this number to hexadecimal yields: 0F 20 08. Preceding this serial number with the MID (B2, the MID for security devices, for example) gives the UID: B2 0F 20 08, and will appear in every RF message sent by the device. The purpose of registration is to associate the unique ID in the wireless device with specific application functionality, such as a descriptive name, the location and point supervision. It is recommended that all wireless transmitters, transceivers and repeaters be registered. To ensure wireless devices are registered only when intended, the application controller should have a specific registration mode. 2.2 Registration Procedure from the End User s Perspective 1. The application controller is placed in registration mode, ready to associate the device s UID with application functionality. 2. The application controller prompts the end user to enter application specific information and send a registration message from the device. Revision G 8

Registration 3. The application controller receives the registration message, associates the device s UID with appropriate application information, and lets the end user know registration was successful. 2.3 Registration Procedure from the Developer s Perspective The developer must provide: 1. A means of initiating an inbound registration message from the device to the network coordinator. While in registration mode, the application controller should indicate when it is ready for the user to trigger a registration message from the device. A registration message is simply a reset message sent from the device. 2. A means of processing the message as it is passed from the RF gateway to the application controller. The registration message transmitted in the previous step will be received by the RF gateway and delivered serially to the application controller. The application controller must validate this message, extract the device s UID, and store it in the application database. Thereafter, the UID will be used to associate the wireless point with program functionality. 3. A means of letting the user know the registration message has been received by the application controller. At a minimum, the application controller should provide some indication that the registration was successful. Preferably, the UID of the registered device should be displayed. At this time the application controller may begin the setup process for the next point or may begin normal operation. This action is application specific. 2.4 Removing a Registered Device from the System To remove a registered wireless device from the system, the application controller is placed in registration mode. The user then selects the point to be deleted. Revision G 9

Registration When the user selects delete for that point, the application controller will adjust the database to remove all information, or replace the unique ID associated with that point with a unique ID of zero and set a flag to indicate that the point no longer has a device assigned to it. If a particular device has been registered to more than one point and the user wants to completely remove that device from the system, then the user must delete that device from each point to which it is registered. Revision G 10

Chapter 3 Message Information 3.1 One-Way RF Messages 3.1.1 Message Notes The RF module only transmits radio messages following a serial instruction from the RAC. The E*1941XS does not report status with RF messages. All status reports are serial messages sent to the RAC. The format of EchoStream messages will vary depending on the message type. Always check the message class byte before attempting to determine the contents of a message. A number in parentheses following a data signifier represents the number of bytes the item contains. For example, unique ID (4) is a 4-byte field. The checksum is the lower eight bits of unsigned arithmetic sum of all previous bytes of the message. If the E*1941XS is instructed to send a high priority message and it has already sent one within the last 30 seconds, then the message will be sent as medium priority. 3.1.2 Configuration Commands 3.1.2.1 0x05 Set Check-In from the Remote Application Controller to the RF Module [0x34] - RF module configuration header [0x06] - Length of this message, excluding checksum Revision G 11

Message Information [0x05] - Subcommand to set the time between the supervisory checkin messages from the RF module to the RAC, and to enable/disable all RF module status messages. [SERIAL CHECK-IN TIME (2)] - In units of seconds, most significant byte first. [CFG] - Set byte to 0x01 to disable all status messages; set to 0x00 to enable all status messages, including tamper change of state and reset. [CKSUM] - Checksum 3.1.2.2 0x25 Request EchoStream Reset from RAC to One-Way Serial Data RF Module This message is from the RAC, instructing the RF module to transmit a predefined EchoStream reset message. The message may be used by the application controller for registration of the RF module into its network if the application controller is in registration mode. [0x25] - Request EchoStream reset command header. [0x03] - Message length, excluding checksum. [0x00] - Reserved, do not modify. [CKSUM] - Checksum. 3.1.3 One-Way Serial Data RF Module Inbound Payload Messages 3.1.3.1 0x58 High Priority Payload Message from RAC to One-Way Serial Data RF Module This message commands the one-way serial data RF module to relay a high priority message, such as an alarm or a change of state, to a network coordinator. The one-way serial data RF module transmits the payload exactly as it was received from the RAC, without processing. Caution: It is recommended that this message only be used to send high priority messages. Using it for low priority messages can cause system load issues. [0x58] - Header for inbound payload message. [LEN] - Message length, excluding checksum. [0x00] - Reserved, do not modify. [0x18] - Message class byte, do not modify. [Payload] - Variable size, 50 bytes maximum. [CKSUM] - Checksum. Revision G 12

Message Information 3.1.3.2 0x59 Low Priority Payload Message from RAC to Two-Way Serial Data RF Module This message commands the one-way serial data RF module to relay a low priority message, such as a check in message, to a network coordinator. The one-way serial data RF module transmits the payload exactly as it was received from the RAC, without processing. [0x59] - Header for inbound payload message. [LEN] - Message length, excluding checksum. [0x00] - Reserved, do not modify. [0x18] - Message class byte, do not modify. [Payload] - Variable size, 50 bytes maximum. [CKSUM] - Checksum. Note: For RF gateway message information, see the Commercial Mesh Developer Guide. 3.2 Data Acknowledgement 3.2.1 0x06 Data Acknowledgement from One-Way Serial Data RF Module to RAC The data acknowledgement from the one-way serial data RF module to the RAC indicates the one-way serial data RF module has received and processed the message and is ready for another. Note: The remote application controller must wait for the acknowledgement from the RF module before sending another serial message. [0x06] - Header for data acknowledgment from the one-way serial data RF module. [0x02] - Message length, excluding checksum. [0x08] - Checksum. Revision G 13

Message Information 3.2.2 0x15 Data Non-Acknowledgement from One-Way Serial Data RF Module to RAC The data non-acknowledgement (NAK) message is sent from the one-way serial data RF module when it cannot process a configuration message from the remote application controller. [0x15] - Header for data non-acknowledgement from RF module. [0x03] - Message length, excluding checksum. [ERROR] - One byte error code [0x01] - Checksum incorrect [0x02] - Unrecognized header [0x03] - Serial buffer full [0x04] - Timeout (incomplete message) [0x05] - Write error [0x06] - Read error [0x07] - Invalid data [0x08] - Unrecognized command [0x09-0xFF] - Reserved [CKSUM] - Checksum. 3.3 Check-In Messages One-way serial data RF modules send periodic check-in messages to ensure functionality. The time between messages is defined in the NVM section of the device and can be changed by the RAC. The RF module sends its check-in message serially to the RAC. The RAC should compose and send a low priority inbound payload message periodically to allow the application controller to supervise the end device. 3.3.1 0x1C Check-In Message from One-Way Serial Data RF Module to the Remote Application Controller [0x1C] - Header for check-in message from one-way serial data RF module to RAC [0x05] - Message length, excluding checksum [DATA] - Number of messages sent to the RAC since the last check-in message [STAT1] - Reserved [Bit 7] - Reserved [Bit 6] - Reserved Revision G 14

Message Information [Bit 5] - Reserved [Bit 4] - Reserved [Bit 3] - Reserved [Bit 2] - Reserved [Bit 1] - Secondary alarm [Bit 0] - Primary alarm [STAT2] - [Bit 7] - Reserved [Bit 6] - Low battery [Bit 5] - Case tamper [Bit 4] - Supervision (no change of state since last check-in message) [Bit 3] - Reset [Bit 2] - Reserved [Bit 1] - Reserved [Bit 0] - Reserved [CKSUM] - Checksum. 3.4 Product Type Identifiers for EchoStream Devices 3.4.1 Product Naming Conventions ES indicates EchoStream products with selectable 868 or 900 MHz operation. EN indicates EchoStream products that operate at 900 MHz only. EE indicates EchoStream products that operate at 868 MHz only. E* represents products available in both EE and EN versions. Revision G 15

Message Information 3.4.2 EchoStream Device Identifiers Table Note: In cases where a system contains more than one product type a security system that includes RF modules, for instance the application controller must be able to recognize product type identifiers for all products within the system. Otherwise, the application controller will simply ignore those product types that it doesn t recognize. Product Description Market ID Product Type End Device Type E*1941XS One-Way Serial Data RF Module End Device, Serial Input 0xB2 N/A One-Way Revision G 16