Wireless telemetry systems are becoming increasingly important for plant-wide monitoring and control applications, as cabling cost and the disruption caused by the associated installation and maintenance work become prohibitive. Ian McNeilage, engineering manager at wireless telemetry specialist Omniflex, explains the differences between simple master-slave and multi-point wireless systems and how to manage traffic and disruptions in multi-point networks.
Wireless telemetry systems are becoming increasingly popular in a range of industrial sectors. In highly regulated industries, such as nuclear, petrochemical or oil and gas, laying cables for data monitoring applications is not always feasible because of strict regulations and the extensive planning permissions required. Here, wireless communication systems can help facility managers retrieve and manage critical data from the field wirelessly, safely and efficiently.
Wireless communication technology is also becoming increasingly beneficial for utility providers that connect to electrical, water and gas meters and gather data for billing and control purposes. And that is not the only way utilities providers are taking advantage of wireless systems, with them also making an impact in reservoir water pump monitoring and control applications where geographical considerations and prohibitive cost rule out using wired monitoring and control systems.
Types of wireless telemetry systems
There are two fundamental types of wireless networks. The first is a classic master-slave system, typically used when communicating with a top-end system like a SCADA system. The simplicity of these systems makes them easy to manage over a network as you get no signal clashes between devices.
Alternatively, you can get multi-point wireless systems that operate in a peer-to-peer manner and report by exception. Multi-point systems like this are common in applications where you have multiple devices communicating over a large area, instead of reporting to a central point like a SCADA. For example, a reservoir and pump system with several dispersed devices across a site that must communicate with each other.
In these systems, it is possible that multiple nodes will try to communicate with each other simultaneously and cause a signal collision that results in neither signal reaching their destination. The only way the node knows its signal didn’t reach its destination is if it doesn’t get the short acknowledgement message back from the other end.
Managing multi-point wireless traffic
To minimise clashes, these multi-point systems should use carrier sense multiple access (CSMA) protocols that allow all the nodes on the network to listen to the traffic and wait for a gap to send a signal. However, even with CSMA in operation, it is possible that multiple nodes may try to send a signal in the same gap in traffic and create a clash. In these cases, the system should then implement a backoff and retry mechanism.
Retry timings should be randomised as fixed timings are more likely to cause subsequent clashes. Furthermore, it best to set a retry limit of between three and five attempts as any more attempts than that are just needlessly blocking up the network while draining the nodes’ power supply.
Another way of minimising potential clashes is by ensuring there is not an excessive amount of nodes on a network. The more nodes you have, the more likely it is that signal clashes will occur. An effective wireless telemetry partner can advise on the optimal number of nodes for a given network, but as a general rule it is best not to exceed a dozen nodes to help keep traffic manageable.
For example, Omniflex delivers wireless telemetry systems for a wide range of industrial sectors, including utilities, mining, petrochemical, oil and gas and nuclear. It can provide either a simple master-slave system or a multi-point system depending on the given application and advise on network setup. Furthermore, its technology has been optimised to ensure reliable data traffic so any disruptions are minimised.
Omniflex’s wireless protocols contain an inbuilt digipeating feature, which solves the issue of having two devices wanting to communicate with one another when they cannot communicate directly because of lack of line of sight.
For example, node A wants to send a signal to node B where they both have network addresses but are either too far apart or out of line of sight. Here, we add a node C in a high point between them to relay the signal. Then, thanks to the digipeating address being ingrained in the message as part of the protocol, node C automatically knows to relay the signal it receives.