The primary function of a RF gateway is to listen to RF signals and to decode messages from Inovonics end-devices. Then, once the message is successfully decoded, the RF gateway sends the message to your application controller, through the serial port.
Messages can be output from the RF gateway’s serial port at a rate of about 1 millisecond per byte (9600 baud). RF gateways do not buffer messages. Your application controller must be capable of receiving and buffering a virtually continuous stream of message from the RF gateway.
In a two-way system, the RF gateway is also responsible for packaging messages from your application controller and transmitting them via RF to end-devices.
Application Controller Primary Functions
In addition to receiving and buffering messages, your application controller is responsible for processing incoming end-device messages, and registering end-devices and high-power repeaters. Message processing includes handling redundant messages, monitoring end-device and high-power repeater status, calculating data and interfacing with the RF gateway.
In two-way systems, your application controller is also responsible for sending messages to end-devices and high-power repeaters.
When designing your application controller for your EchoStream system you want to consider the following factors to ensure your design is robust, always able to accept and buffer messages, and can perform the processing necessary to support your application effectively.
Each Inovonics end-device and high-power repeater is assigned a unique ID in the factory. This unique ID is included in each message originating from the device. Most applications include a method of associating each device’s unique ID with a description, such as the device’s location, or the type of device it is. The process of registering end-devices and high-power repeaters is the responsibility of your application controller.
End-Device, High-Power Repeater, and RF Gateway Status Monitoring
Most end-device, high-power repeater, and RF gateway messages include two bytes containing information about the status of the device. For example, when the end-device battery capacity drops to a prescribed threshold, the end-device sets a low battery flag in the status byte, sending a low battery warning. Your application controller then needs to notify the user of the device ID and low battery status so that appropriate action can be taken. Your application controller is responsible for decoding device status bytes, and acting on pertinent information.
End devices and repeaters send supervision messages at specified intervals to the RF gateway, and your application controller should notify the user to check on any device which doesn’t report in a timely manner.
In a one-way system, your application controller should also monitor the serial receiver’s messages. In a two-way system, your application controller and network coordinator should monitor each other. If the network coordinator fails to hear from your application controller within the defined window, a message can be sent to all two-way end-devices.
Redundant Message Handling
When most end-devices send data the message is transmitted multiple times on different frequencies to increase the probability the RF gateway hears the message. This transmission technique is a critical factor in the reliability and integrity of EchoStream systems. However, it also creates redundant messages at the RF gateway end of the system.
The RF gateway eliminates most of the redundant messages by comparing the current message to the last message. In busy systems your application controller may still receive redundant messages due to the sequence in which the RF gateway processes the messages; for example, if a redundant message from one end-device is interleaved with other messages. For this reason, your application controller must be able to handle redundant messages. A simplified means of handling them can be implemented by having the software compare each incoming message with a list of recently received messages. The list need only store enough messages to catch interleaved redundancies.
Monitoring Repeaters Not In Your Network
When using directed network messaging, it is a good idea to have your application controller log any messages that might be received from repeaters that are not in your system. That way, competing networks can be detected, and any resulting RF load can be determined.
After receiving and decoding messages from the end-device, your application controller is responsible for processing the data. Some processing options include presenting the information on the screen to the user, storing the data in a database, etc. The requirements of your unique application will determine the exact processing required by your application controller.