RDC from Digital Barriers is a revolutionary unattended ground sensor (UGS) system for intrusion detection and remote asset protection. It combines an innovative rapid deployment design, exceptional power efficiency, accurate target detection/classification and intelligent mesh-based two-way wireless networking. RDC Config is a Windows software application for configuring RDC networks. RDC Config can be run as a standalone application or is embedded within EdgeVis Shield when used with Digital Barriers TVI encoders. The standalone application is used when there is a direct serial connection between the Master Node and a PC or via a serial bridge.

This document provides detailed instructions for using RDC Config. It should be read in conjunction with:

RDC Config is installed as part of the EdgeVis Shield 6.5 client. The application can be run in one of two modes:

RDCConfig cannot be used for creating networks of nodes by setting the frequency and network ID. This is performed using the Staging Tool (see Staging Tool User Guide for details). RDC Config assumes that the network already exists. This will be the case for many users and therefore use of the Staging Tool is only necessary if a node requires replacement or new nodes must be added to the network.

There are two types of RDC Node. These are Ultramesh and Ultramesh+. Details of the differences between UM and UM+ can be found in Appendix A. They can be identified by the label fitted to the underside of each node. Older Multi-hop (MH) Nodes are not supported by RDC Config.

UM+ Master Nodes must be used with RDC Config. RDC Config does not support UM Master Nodes. RDC Control software can be used for configuration of networks with UM Master Nodes. Note that RDC Control can be used with EdgeVis Shield but it is a separate application, not integrated.

RDC Config supports both Ultramesh (UM) and Ultramesh Plus (UM+) Sensor Nodes. UM and UM+ Alternative Sensor Nodes (ASN) are also supported by RDC Config. ASNs are used for adding third party sensors such as PIR sensors to RDC networks.

Note that UM Sensor Nodes can be used with UM+ Master Nodes.

The table below provides details of encoders that support RDC and also the node combinations that are available to the user.

Notes:

RDC Config is comprised of four main views:

There are also two further views which can be accessed by pressing the Switch to Advanced Mode button. These are:

In Advanced Mode there are also some configuration options not available within the Standard Mode.

There is also an about button providing information about RDC Config.

The network view provides details of the network connections that are available to the user.

The view is different depending upon whether RDC Config is running with EdgeVis Shield or standalone.

The view provides a list of online encoders. Select the network to be configured and press Connect.

The red icon next to the selected encoder rotates to show that the connection is being established.

Once the connection is made the icon turns green.

RDC Config establishes the network configuration. The information shown is:

To make a connection to a network over the serial port press ‘Add Serial’. This will provide details of the Master Node USB cables connected.

Select the required serial connection. Then select it in the list of networks and press Connect.

Whilst RDC Config is acquiring information about the Master Node the red icon will rotate. When this process is complete it will turn green.

There are several reasons why the connection may not be made.

EdgeVis Shield:

Standalone:

A connection to an encoder or COM port can be disconnected by selecting the connection and pressing Disconnect. It is recommended that connections to encoders are disconnected whenever they are not in use because only one user can connect at a time. Leaving the connection open blocks access by other users.

The load profiles button allows alternative configurations to be applied for special circumstances. If an alternative profile is required to replace the default profile used by RDC Config the requirements for this will be discussed with the customer.

The Configuration view is the main working area of RDCConfig.

RDCConfig stores the network configuration in a database on the local machine. When the configuration view is opened it will show a list of all networks it has in the database.

When the connection to the nodes has been confirmed the icon for each node will turn green.

When RDC Config is running in EdgeVis the connection name is the name of the encoder to which the network is connected. When RDC Config is run standalone this will be the COM port number.

The node type is displayed in the table.

MN – Master Node

SN – Sensor Node

ASN – Alternative Sensor Node

TN – Trigger Node (functionally similar to an ASN)

Selecting a node provides details of its configuration. The current profile is shown. A new or ‘desired’ profile can be defined. This will only be changed when the Commit changes button is pressed. The configuration options shown depend upon the node type and the firmware version.

The ‘application/environment’ allows the user to optimise the configuration for a particular environment or application. The precise configuration is modified to suit the selected environment. For person, vehicle and digging categories the user has the option to select low, medium and high sensitivities. Large seismic disturbance and diagnostics are only available in the Advanced Mode and should be changed by advanced users only.

The ‘Default’ environment will be the most commonly used configuration. For open ground which is not soft, chalk, desert or woodland/forest select Default. The ‘ShortDemonstration’ application should be used whenever repeated tests or demonstrations are being undertaken. In these circumstances repeated intrusions causing seismic vibrations may cause some of the adaptive filters to be activated reducing the detection performance. Under normal circumstances these filters would be activated when there is excess environmental noise which may cause false alarms to occur.

The ‘Repeater’ application is used to switch off the detection algorithms so that a node can operate as a relay for other nodes without generating events.

The current profile for multiple nodes can be selected for viewing or changing the configuration simultaneously as long as they are the same node type and have the same firmware.

The blue icon for the both the Sensor Node and its associated Master Node indicates that a configuration change is being applied. Note that this indication will also be visible when a sensor is added to a network or a network is connected to the PC for the first time. This indicates that the configuration is being queried and when complete will be stored in the local database.

ASNs have options for configuring the external inputs. The input for each ASN can be set as OFF, Normally Open or Normally Closed. It is also possible to configure the node to send an event to show that the input has changed to its non-detecting state e.g. if a door which was opened has been closed.

The Master Node can be set to operate in one of two modes:

Changing the Master Node mode also changes the operation of the Sensors/ASNs and affects their battery life. See Appendix A for details of expected battery life in each mode.

When configuring a network it is recommended that the Master node is put into Fast Configuration mode otherwise configuration changes can be slow. Upon completion of configuration it is recommended to switch the Master Node into Extended Battery Life mode.

Note that switching modes causes the Sensor nodes to disconnect from the network and the network has to re-establish. This can take several minutes. It is recommended to switch modes only infrequently. If a network is in Extended Battery Life mode and only one or two configuration changes are required it is recommended not to switch modes because of the time this can take. Instead, the configuration should be done in the Extended Battery Life mode.

Other than changing a node’s configuration there are several actions that can be taken within the Configuration view. These are accessed by selecting the Tools icon.

Fusion rules can be set by selecting two nodes. They must be part of the same network. Node type and firmware can be different.

With pair fusion, an alarm is raised if two paired sensors declare alarms (of specified types) within a given time period. The processing for pair fusion takes place on the Master Node, so that an attached encoder can remain asleep whilst the Master Node determines whether to wake it up, thus preserving battery life of the attached device. Up to 50 pair fusion rules may be operational.

Fusion is a very powerful technique for minimising false or nuisance alarms but must be used with care to avoid missing valid events. Appendix B provides guidance for using fusion.

A new fusion rule can be set by selecting a pair of nodes and selecting Set Fusion from the Tools menu. Press the ‘+’ symbol and select the Node IDs and event type for the fusion rule. Press the Commit Changes button. To create further rules using the same pair of nodes press the copy symbol beneath the ‘+’ symbol. To create further rules with different nodes select another pair of nodes.

Note that the rule can set as non-directional or directional.

Greater flexibility in selecting node IDs is available when operating in Advance mode. This is useful if creating a large number of rules.

The rules that are currently applied can be viewed by selecting any node in a network and pressing Get All Fusion Rules. This will show a list of all currently active rules.

Fusion rules can be deleted in the Get All Fusion Rules view. Press the Commit Changes button to remove the selected rules.

Note that the rules are non-volatile. Power cycling the Master Node will not erase the rules. The network view indicates whether there are any rules set. This can take a few seconds to update after a rule is applied or removed.

EdgeVis Shield will also show whether fusion rules have been set. This will be shown when the encoder is selected on the map.

Events generated by RDC can be viewed by selecting either the Events List or Events Graph. If using EdgeVis Shield it is recommended to use the EdgeVis central alarm management service to create rules, perform actions and generate alerts. See the knowledgebase article ‘EdgeVis Alarm Management – Creating Rules and Alerts’. When used in standalone mode RDC Config can be used to view events generated by RDC networks. The Events graph provides a pictorial view of events that have occurred during the previous hour. It is possible zoom in or out of specific time periods using the scroll button on a mouse or pressing ‘=’ or ‘-‘ simultaneously with CTRL. By holding the left mouse button the display can be dragged backwards and forward in time.

There are two views that provide diagnostics information that is useful during network deployment or for diagnosing performance issues.

The Background view provides information about the likely detection conditions. Three environmental factors affect the detection performance of RDC. These are:

The Background view shows the affect that background noise may have on detection performance for each node. This is shown as a level from 0-10 (10 = very low noise, 0 = very high noise). It is also shown as a bar chart, where a full green chart indicates that the background noise is low and therefore detection conditions are likely to be good for that particular ground type and stimulus. Finally, there is a graph showing the background noise for the previous hour.

If detection conditions are reported as being below 4 or 5, moving the Node(s) to another location should be considered if practical. In ‘poor’ and ‘very poor’ conditions, a high level of false alarms may be experienced. The background conditions are updated once every 3 minutes.

Note that:

The Radio Performance view is important for assessing whether a Node has good connection to a network. It is important that all Nodes in a network have a good connection before any testing of detection performance is undertaken.

Once every 3 minutes a Sensor Node (or ASN) sends an ‘alive’ message. RDC Config determines if alive messages are received as expected and calculates the missed alive rate. Generally, the missed alive percentage should be less than 3%. Higher figures indicate that the Node has a poor connection to the network.

Since the alive messages are only sent once every 3 minutes it may take several hours before a clear picture of radio performance is built up. However, if a Node has a very poor radio connection to the network it may be obvious quickly. The RSSI (Received Signal Strength Indication) can also be helpful for providing an indication of the signal quality between a Node and its parent.

If the missed alive rate is high then there are several options for improving it:

The Deploy Tool is very useful for helping to determine the best location for a Repeater Node. See RDC Deploy User Guide for details.

Note that that when a network is established a Node’s parent may change quite frequently until it determines the best path to the Master Node. The number of hops taken for messages to reach the Master Node may also vary.

The Master Node sends an alive message to RDC Config once every 30 seconds. This can be used to indicate whether there are any problems with the communications to the Master Node.

Firmware versions:

Battery Life:

*repeater node

Assumes nominal 19Ah battery. 19Ah is only available in ideal conditions (temperature and constant current of 4mA). From experience of real world conditions we de-rate this to 15.5Ah.

Battery life in very hot or very cold conditions may be reduced.

Event Types:

Detection Algorithm:

Notes:

Fusion:

*EdgeVis Shield will not indicate that fusion rules have been set

Other:

Notes:

A pair fusion rule consists of the following specification:

Alarms of type EA from Node-A, or type EB from Node-B, are only raised if a node-A event of type EA occurs within tmin to tmax seconds of a node-B event of type EB. The time-gap is based on the original detection times of the events, not the time-of-arrival at the Master Node. This allows for robustness to transmission delays through the network.

The rule can be defined as directional or non-directional. If the rule is specified as directional an event from the first node specified must occur before an event from the second node sepcified if the rule is to be met.

If a node ID and event type is specified in a pair fusion rule, then individual instances of the alarm are only declared by the Master node if the pair rule is met. When a pair fusion rule is met the first event in the pair (where first is the time-of-arrival at the master) is forwarded on by the master, and then immediately afterwards the second event in the pair is forwarded on. This ordering might not be the same as the actual detection time ordering, because multi-hop transmission delays can lead to the times-of-arrival at the Master Node being different to the detection ordering. The original detection times are preserved in the event messages, so time ordering could be determined at the recipient. An alarm whose node ID and event type is not specified in a pair fusion rule is forwarded immediately by the Master Node. This applies even if all other event types with that node ID are part of fusion rules.

Important: Fusion rules are stored in non-volatile memory. Therefore, rules are not erased when the Master Node is power cycled.

To gain maximal benefit from fusion, it is recommended that the nodes should be deployed in a way that is optimised for pair fusion rules.

Suppose that two nodes in a fusion pair are close together, with overlapping detection zones (e.g. are less than 30-40m apart for person detection). Then to avoid missing legitimate targets, one would have to set the minimum time gap in the fusion rule to be very short, and potentially even zero seconds. Thus the pair fusion rule would lose the ability to eliminate false alarms due to them occurring too close together (e.g. if caused by a global nuisance event). For car detections, potholes and bumps in the road can lead to long range detections. This can lead to a second node 40m further away from the bump than a first node detecting at a near identical time to the first node. This again stops us from being able to use the minimum time gap in a fusion rule.

Nodes separated by greater distances, such as 50m for walks, and 100m for vehicles should be able to utilise both the minimum and maximum time gaps to full effect. However, if the nodes are too far apart then there is an increased risk of a target deviating from the expected path, stopping briefly or moving slowly and therefore not being detected by both nodes (which would mean that there would be no fusion detection).

For any given deployment, with well-separated nodes, there is a trade-off in how aggressively to set the time gaps. Setting tight time gaps will increase the false alarm rejection, but might lead to some legitimate targets being missed (due to early (or late) detections, and faster (or slower) than expected speeds). Setting loose time gaps will reduce the number of false alarms that will be removed, but should prevent legitimate targets from being rejected. A recommended approach is to estimate the likely maximum time gap, and then add 20% or 5s, whichever is the larger. Minimum time gaps need a larger additional tolerance, perhaps up to 50%. Where possible trials runs should be used to help determine typical detection transit times between nodes. Transit times can also be estimated by determining the distances between nodes, and using estimates of minimum and maximum speeds to bound the detection time gaps.

​