Introducing LTE with VoLTE for SCADADroid

What is VoLTE?

Voice over LTE (Long Term Evolution) is a new protocol that allows voice calls to be made over the LTE datanetwork. You’re probably wondering how this was done before, since you currently are using the LTE network. Currently 4G phones are falling back on old technology to make voice calls and using LTE for data usage. New VoLTE technology and the 5G network are going to bridge this gap, making voice calls on the LTE data network.

What does this mean for SCADADroid?

On top of the existing three cellular modems available for SCADADroid, a fourth cellular modem option is being added: LTE with VoLTE. This means that voice calls will be faster, more efficient, higher quality and more reliable as VoLTE is rumored to reduce “blackspots” indoors. It also means that one of the two SIM card slots will be freed up to make room for an SD storage card. As network cellular providers move towards 5G technology instead of 4G, SCADADroid will be able to transition seamlessly.

LTE Modem Specs

From the manufacturers website:

"The LTE910CF v15.00 Common Footprint (CF) Socket Modem is an LTE Category 1 cellular modem with support for multiple carriers including AT&T, Verizon, T-Mobile and FirstNet, Rogers, Telus, and Bell cellular networks. Certification is complete for AT&T and pending for Verizon.

It utilizes the Telit LE910C1-NF module as its cellular engine. The LTE910CF v15.00 units operate in LTE bands B2, B4, B5, B12, B13, B14, B66, and B71."


SCADADroid Integration with Allen-Bradley


Integration of Allen-Bradley® PLC communications with alarm dialers previously required specific software and/or hardware converters, but by assigning the CompactLogix™ or ControlLogix® PLC a Modbus client, the SCADADroid® alarm dialer can read messages easily using the Modbus TCP/IP protocol.


Programming the CompactLogix™/ControlLogix® PLC as a Modbus TCP client within Allen-Bradley® RSLogix 5000®. Refer to Rockwell
Automation® website for sample programming code.

Alternate Solution: Another option is to use the connected HMI/OIT as a Modbus client and use the SCADADroid® to poll data from the HMI/OIT

Hardware requirements

ControlLogix®/CompactLogix™ PLC with an Ethernet port and a SCADADroid® alarm callout unit. Refer to Rockwell Automation® website for a complete list of compatible PLCs.

Memory requirements

Up to 300 KB of data and logic memory are required in the PLC, so be sure to confirm within RSLogix 5000® that there is adequate space for the ladder logic programming. The settings for this can be found in the controller properties “memory” tab.


Refer to Rockwell Automation® website for sample programming code.

The MSG path must be set to 1, 0 (ControlLogix® will be 1, the slot # of the Ethernet module) per Rockwell Automation® tech note 470690 - Socket Communication in ControlLogix® and CompactLogix™
For CompactLogix™ controllers The MSG must be Unconnected so the Connected checkbox must be cleared per Rockwell Automation ® tech note 530345 – CompactLogix™ 5370: Error Code 16#0001 with Extended Error Code 16#0000_0318 or 16#0001_0103

Agriculture Case Study

SCADADroid® with MQTT- Providing Peace of Mind for Alberta’s Farmers 

Reonix Automation Inc. set about automating an Alberta farmers’ grain dryer. One of the core requirements of the application was providing a more hands-off approachby relaying some of the crucial data straight to the customer’s hands.  

We were able to do just that…  

Through the use of a SCADADroid® Android ® application, and MQTT (a tried and tested communication protocol). Our customer was provided a window in to this crucial process, while gaining the freedom to continue a host of other work required to keep the farm running.  

In this case, Reonix made use of several components at different levels of the industrial control system, to ensure a much more automated approach.  

At the field level, switchesmoisture and temperature sensors are connected to an electrical box, which is further connected to a PLCThe PLC uses the moisture and temperature readings to determine the amount of drying time required which then adjusts the VFDs (connected to the auger motors). Moisture levels of the finished and unfinished product are read as well as the dry gain temperature.  

The PLC also acts as a Modbus server, making all this information available.  The SCADADroid® reads this data using Modbus TCP from the PLC. It polls the PLC for the speed of the augers, the temperature of the grain, and any failsafe switches for on or off status. Once it detects an alarm condition, it sends out alarms through the cellular mobile phone network, i.e. SMS text, email and voice dial.  

At the production levels, in the case of the dryer, the everyday smartphone acts as the monitoring terminal. Here is where the magic happens. Aside from sending texts and automated voice-dial messages (standard to any alarm dialer), the SCADADroid® pushes the Modbus data straight to the farmer’s smartphoneThe data is sent over the cellular data network using MQTT, so it’s fast, efficient, and lets a farmer know the immediate performance of the grain dryer while harvestingenjoying time with their family or any of the 100 things on the ‘to-do list’ – before the critical situation of an alarm. Using the custom Android® app, the key data values display on a handheld screen wherever they may be. 

For a little insight in to the technology the SCADADroid® utilizes, we can take a look at what MQTT is and how it is applied: 

MQTT is a fast messaging protocol, which minimizes signal traffic over wireless networks. If there’s an interruption in the transmission of data, the last known values are saved on the publishing device (in this case, the SCADADroid®), and then pushed out to the client device (in this case, the farmer’s smartphone) as soon as the cell signal is re-established. MQTT makes this failsafe through its characteristic message queueing system, which also allows it to keep data transmission volume over a cellular network much lower than traditional types of communication, which require a constant stream of information being broadcast 

The benefits of these features can free up a farmer’s time. What used to require constant supervision of a grain dryer that could experience a fault at any time, can now be sent to a phone. Farmers can get a full night’s sleep instead of checking up on a dryer in the dead of night. They can change alarm setpoints through the app, instead of requiring a technician to reprogram PLCs, or an electrician to rewire costly electrical relays. And MQTT keeps cellular data plan usage to a minimum while the client keeps tabs on the dryer! 

Would you like to know more about MQTT and the future of automation? Read our blog post:

For a more concise overview of the specifications and equipment involved, download our case study PDF:


Sending text alerts without a cell modem

It is possible to use an Ethernet to send text through email, without a cell modem. Each cellular service provider has an email format in order to send an email that will text a mobile phone. These text messages would be a one-way communication (Do not reply), therefore acknowledging these alarms through text would not be possible. In order to circumvent this, the user can send two emails from the SCADADroid, one to the email-to-text address, and one to an email address that can be acknowledged once the user receives the text alert.

Setting up email-to-text

Each major carrier in North America has a different configuration for sending text messages through email, so check with your provider to see which will work for you. Below are examples from some major carriers:

  • Verizon: (source)
    • example
  • AT&T: (source)
    • example:
  • Bell: (source)
    • example:
  • Rogers: (source)
    • example:


ClearSCADA and SCADADroid

Utilize Your Existing Database to get SMS Alarms, direct to your Operators

With network upgrades happening all over the world as we begin to prepare for the inevitable switchover to a 5G infrastructure, many cellular providers are starting phase-outs of their existing 3G technology. With Verizon already announcing the end of its 3G service at the end of 2019, this has left many ClearSCADA users in need of cellular callout options scrambling to find something to fill the upgrade gap. A variety of LTE capable solutions exist, but many require a duplication of databases and may require expensive software or costly time spent on training operators to implement. The issue can be compounded when solutions may not work with your existing IT or cellular provider infrastructure, adding layers of complexity.We have heard your feedback, and today are happy to announce that Reonix Automation has introduced capability into its new SCADADroid® R2+ line of 4G LTE capable remote monitoring devices to provide a reliable GSM Modem solution for ClearSCADA. Through a simple Ethernet connection, utilizing the TCP protocol, the SCADADroid R2+ can be configured to act as an SMS Pager over ClearSCADA’s built-in SMS Service, giving you the capability to…
  • Utilize your existing ClearSCADA database of alarms, users and setpoints to get notifications out to a multitude of operators’ devices without the need to manage a separate system
  • Acknowledge alarms with user-specific codes, only if you choose to enable two-way communication
  • Have peace of mind through SCADADroid®’s built-in communication overview, providing you with a secondary point to see all communication history for each device

The SCADADroid® R2+ can do this all while retaining its many robust monitoring features. Meaning you can still utilize Modbus TCP/IP communications to tie directly to a PLC or simply use the device’s on-board 8 digital inputs for any supplementary site-specific alarms. This, combined with SCADADroid®’s VPN Gateway capability give you the ability to change any SCADADroid® settings, or even provide secure access to other devices connected to it, remotely from the comfort of your office.

The entire setup of the integration can take as little as 15 minutes. It consists of:
  • SCADADroid R2+ SetupConnect the device to a local computer, log in through any major browser to the default IP Address (
  • On the Overview page, ensure cellular connectivity exists and the signal is sufficient
  • Change the device’s IP to one which aligns or doesn’t conflict with your existing network
  • ClearSCADA Setup (in your existing database)Create a new SMS Service:
    • Right Click > Create New > Pager > SMS Service
    • Enable the Service: Click once on the new SMS Service and under the SMS Service Tab > Enable the ‘In Service’ checkbox > Enable the ‘Process Incoming SMS Messages’ checkbox> Click save icon in top left corner
    • Create a new SMS Pager Channel: Right Click > Create New > Pager > SMS Pager Channel
    • Link SMS Pager Channel to the created SMS Service under the: Click once on the new SMS Service and under the Channel Tab > Enable the ‘In Service’ checkbox > Click the ‘…’ button next to Pager Service, locate the SMS Service which you created in Step 1. and highlight it > Click OK > From ‘Line Speed’ select 115200 Bits/second > Change Modem Command to read “AT” > Click the save icon in the top left corner
    • Change the connection type: Under the Connection Tab > Change Connection Type to TCP/IP > Under Host Address input the SCADADroid R2+ IP Address which you established in Step 3 of the SCADADroid Setup > Change the Port to 2002 > click the save icon in the top left corner of the screen.
    • Enable the SMS Service as a mode of notification for your contacts: Locate a user > Click once on the user > Under the Contact Information Tab ensure that the user’s phone number is present under ‘Pager ID’ > Click the ‘…’ button next to Pager Service, locate the SMS Service which you created in Step 1. and highlight it > Click OK > Enable the ‘SMS Commands’ checkbox

A helpful way to view the implementation is with the help of the  ClearSCADA specific video on Reonix Automation’s YouTube channel.

ClearSCADA is a registered trademark of Control Microsystems, Inc.

SCADADroid is a registered trademark of Reonix Automation, Inc.

MQTT, Industry 4.0 and the Future of Automation

How Remote Monitoring can be Revolutionized by MQTT
To speak to the issue of telemetry like MQTT, it must first be put into context. Why a protocol can revolutionize an industrial application depends on how industry will be conducted, and what tools will be used in the near and far futures –so as to avoid investment in soon-to-be-outdated control systems.Industry 4.0, a term describing the future of primary, secondary, and even tertiary industrial processes,will heavily rely on leveraging a massive flow of data –between end-users, Industrial & Consumer IoT devices, Intranets, Big Data, and perhaps even Blockchain. This transformation will probably involve Artificial Intelligences (or if not quite that level of machine cognition, at the very least,machine learning), and it will definitely involve machine to machine (m2m) interface and processing.
Machine to machine interface and communication protocols are key to the future of industrial automation, as stringent industrial control system requirements will soon be met by rapidly improving standards in the IoT environment; IoT as applied to industry is now known as IIoT, but we will likely see an integration between the two.Events are the impetus for administrative operators responding to alarm conditions, and for now the actionable response is often left to humans. But soon, IIoT devices will have complex responses to contingencies based on acquired data, and much of SCADA’s supervisory level(and beyond to the production and scheduling levels),can be automated for better efficiency. Such a shift in procedure will free up your operational personnel’s attention–diverting their hands and eyes from HMI terminals, and towards other areas requiring attention. This means rolling with the momentum of the Industry 4.0 Revolution rather than struggling against it or missing out entirely. For the time being, operators are content to remain in control at the supervisory level of industrial control systems. What used to be constant supervision of industrial control systems now requires response only when critical events trigger alarms, at least in a SCADA setting. The role of the human being in this process is now much more meaningful. It makes the operators in charge of event response an executive rather than a sentry, and the automation of datalogging presents the opportunity to ensure that they are not overburdened with Quality Management or Safety Standard documentation as well.
Development of SCADA Hardware and Software
The development of SCADA equipment is varied and few solutions on the market are identical. Multifunctional equipment is a de facto market offering, so products with an initial function in a SCADA setup may often take on complementary functions, rather than having a dedicated function, since fragmenting the required equipment would make clutter for the plant operators. The downside to a wide variation in equipment function is the complexity of the setup, necessitating the consulting services of systems integrators to ensure that equipment from different companies can be utilized, rather than submitting to dependency upon a SCADA equipment sales company to do their customer’s purchase planning for them.But the most exciting benefit of IIoT functionality in a multipurpose device is how it enhances and integrates other digital and physical features into a much broader virtual process. One such IIoT protocol is MQTT, a reliable protocol first developed by IBM. Message Queue Telemetry Transport is a lightweight protocol that can ration the transfer of data packets going over cellular by way of its queuing procedure.Essentially, an MQTT device at a remote site can act as an IIoT Gateway, bridging smart field devices to cloud servers. Minimal transfer from a remote location to a cloud based broker, is further distributed to the edge of the wired network (if the centralized distributed network on the internet is called a cloud, then server computing localized nearer to the IoT field level and control level devices can be called a ‘fog’(i.e. clouds reaching down into a city street),meaning that only essential data is transferred over cellular, and telemetry transports in carefully measured quantities. High priority is fire-and-forget, whereas lower priority data packets will queue for the right network latency, applicable to the purpose of saving on cellular data consumption overall. Lower priority queuing preserves bandwidth by waiting for data bottleneck at the gateway to clear before sending
Data Efficiency and MQTT: Ways this Lightweight Protocol Can save on Cellular Costs Today
1.Queuing: Communication limited to a small code size allows the m2m client to send published values (data points)collected from the m2m server device(such as a sensor)to the cloud-computing broker, where any access or further data processing can be sent to local area networks unconstrained by data restrictions; the m2m part of the telemetry compresses and rations the packets sent out, whereas the machine to cloud, and machine to human portions of the Pub-Sub (publish and subscribe) telemetry can relay back and forth more freely.
2.Actionable Messages: Actionable data sent over MQTT, as with digital or analog I/O for instance,saves enough money to give the operators the choice between using a cell budget to access and reconfigure the setpoints of field bus clients remotely, through VPN for instance, or sending personnel to deal with the remote site if remote access fails to resolve the problem.
3.Telemetry Prioritization: GPS is a data efficient technology when the positioning results are communicated to a networked device over MQTT. If your remote monitoring is on the move, as with a fleet management application, then it’s imperative that positioning data be of the right level of importance, and that it be sent in such a way that keeps cellular data consumption costs low–as there’s no doubt that mobile GSM expenses can hurt a company’s bottom line, especially where less than critical information must consume more bandwidth to reach the MQTT Broker. MQTT as a protocol makes assessments of the event-data’s urgency, and queues events’data for efficient transport.
4.Alarm Conditions Only: With a fieldbus setup like Modbus, polling events communicable over MQTT makes SCADA a low-cost proposition. Rather than sending Modbus read-commands over cellular to the supervisory level client, the Modbus control level client can queue alarm condition data and publish events to the MQTT broker. From the broker, the supervisory level(using devices such as personal computers, smartphones, and tablets)can be notified of subscribed-to topics and can publish new setpoints back to the Modbus client via the cloud broker.
5.Computing on the Edge: At a remote site IIoT integrated via MQTT, multiple sensors and (or) data processing units can communicate with one another, and if necessary, can be formed into a distributed cloud-like processing network that serves as a local extension of the cloud –in essence, fog computing or edge computing. A fog will be able to roll down from the cloud to the remote site, and much of the data processing work that would be done in the cloud (distributed processing over the internet) can be done right there at the remote site; rolling the fog down to your remote site would mean that only the most essential data would be published to client devices via MQTT Broker, which in turn would mean that cellular data consumption would be kept to a minimum.