Has anyone setup MQTT over a unlicensed 900Mhz radio network, such as GE Orbit?
Many of our customers have existing unlicensed 900Mhz networks that are utilized by Master/Slave PLC polling. Granted MQTT is a more efficient protocol, but since it is not Master/Slave that could mean more than one device is trying to talk on the network at one time which could cause collisions. So I’m wondering if anyone has implemented MQTT over an unlicensed 900Mhz radio network and what their experience has been?
Put an Edge device on the Master end of the link. Let the radio link continue running the existing protocol. Push to your network from your edge device in any protocol you like.
The below diagram might show better what I’m thinking about. The current network has a Master PLC that polls all the Remote PLCs over a 900Mhz network. The thought is if we put a MQTT Edge Of Node Gateway at each remote site, then the MQTT Edge Of Node Gateways will publish/subscribe directly to the Ignition MQTT server, the network has been changed from a Master Polling network to an MQTT network.
I’m wondering if anyone has implemented MQTT over a 900Mhz radio network and what their experience has been? My concern is if multiple MQTT Edge Of Node Gateways try to communicate to the Ignition MQTT Server over the 900Mhz network at the same time, could that cause a problems? Could there be problems with network traffic over the 900Mhz network?
I haven’t used the orbits, but have used the older iNets and other 900 MHz radios.
If you running them in an “ethernet” type mode, or as serial servers, then you shouldn’t have a problem. Multiples can talk at the same time, and the master can manage multiple connections. There probably is some connection limit, so best if you can stagger the edge pushes if possible. Not sure how many remotes you’re planning to have on a single AP. Usually in ethernet mode, these radios always maintain some kind of connection, and don’t completely idle like older serial radios.
Alternatively, if you have them configured in “serial” mode like older radios, then it may not work out like your expecting.
Why do you need 900Mz at all, you can directly connect remote PLCs with Ignition gateway over MQTT thru internet, if remote PLCs can be connected as MQTT clients to MQTT broker thru internet!
Existing infrastructure is 900Mhz. It’s easier to sell an MQTT Edge Gateway for each remote site than to sell an MQTT Edge Gateway + Cellular Modem + Monthly Cell Service for each remote site.
Why do you have to sell anything? Does the current polling setup not work? What does it matter if MQTT might use less bandwidth if bandwidth doesn’t cost anything?
The goal is to lower the latency. If everything is perfect in the existing network, it takes about 90 seconds to loop through messaging every remote. If one remote does not respond to a message, it takes 15 seconds for the message to fault, now you are looking at almost 2 minutes to loop through all the remotes. Best case, it takes a minute for a user to make a change before they see a response to that change.
With MQTT being report by exception, the goal would be to lower the response time to user changes from minutes to seconds.
900Mhz ethernet radios will support a separate connection from Ignition to each remote PLC (with some limit, IDK how many remotes you have). You would not round-robin poll them. I give each remote site a different scan class, each with a slightly different rate, e.g. Site 1: 2010ms, Site 2: 2020ms, etc. They won’t scan at the same time if you do that. If you are replacing an old serial MDS radio like a 9810 with an Orbit, your OTA throughput will go up by at least a factor of 10.
Your existing radio network timeout sounds way too high, btw.,
I’ve recently been working on a very similar architecture, however, the radios are on a licensed band.
The challenge is the master radio having only a single receive channel and the unpredictability of MQTT publishes. As you mentioned, collisions may occur when multiple edge nodes are attempting to transmit at the same time.
Two factors impacting communication stability is frequency and size of packets, the former having more an effect. We spent a fair amount of time in the lab tuning analog deadbands, varying amount of edge nodes, and size of tag maps to determine combinations that may be viable.
Another scenario to be aware of is when one or more MQTT connections are interrupted, the reconnection sequence (especially with SSL) will generate even more load and can cause issues with the other nodes on the network. Since control of communications cannot be effectively managed remotely, there is a risk of overloading the network and difficulty of recovering.
Additionally, and this may not be a concern for your system, but the lack of remote connectivity to the edge nodes (SSH or web interface) means these devices must be administered by a field techs.
