_1772746035263-CVlnBaHI.png){kind=logo}
Customer Success Story · Oil & Gas Operator
Validating MQTT on a Legacy 900 MHz SCADA Network
A leading oil & gas operator needed absolute certainty before overlaying modern MQTT (NATS) traffic on their existing Xetawave SCADA radios. Twin Eagle delivered a packet-level network performance evaluation that turned guesswork into proof — and cleared the runway for next-generation edge data.
0%
Packet loss across all five test scenarios
75 ms
Steady average latency under heaviest load
4.2%
Peak radio utilization (vs 2.6% baseline)
5
Live, 55-minute stress-test scenarios
Executive Summary
Modern MQTT data, on the radios already in the field.
A leading oil and gas operator (“The Operator”) wanted to upgrade their edge communications by integrating modern MQTT-based traffic alongside their legacy SCADA infrastructure. They engaged Twin Eagle Solutions to run a comprehensive network performance evaluation. The objective was specific: determine the exact impact of overlaying NATS (MQTT) traffic — while simultaneously increasing SCADA polling frequencies — on an existing 900 MHz ISM wireless network.
Through precision tracking, hardware deployments, and expert packet-level analysis, Twin Eagle Solutions eliminated the guesswork. By delivering concrete diagnostics, we empowered The Operator to deploy their next-generation data applications with complete confidence — validating network scalability without compromising critical daily operations.
The Challenge
Upgrading edge data without sacrificing stability.
The Operator’s field SCADA network was built on Xetawave 900 MHz ISM wireless radios delivering roughly 500 Kbps per link, supporting legacy polling through Cygnet and XSPOC.
As digital transformation initiatives demanded real-time data from the edge, The Operator needed to introduce MQTT (NATS protocol) communications and increase SCADA polling intervals at the same time. The risk wasn’t theoretical — pushing a legacy radio system too far could corrupt data fidelity, cause costly packet loss, and interrupt critical well-pad monitoring and control.
They needed absolute certainty that their RF network could handle the increased payload without failure. Not a vendor pitch — proof.
The Twin Eagle Approach
Inline at the hub tower, packet-level the whole way.
Twin Eagle Solutions approaches mission-critical connectivity with precision and field-tested methodology. To deliver a defensible answer, we deployed specialized field engineers to the hub tower and ran live, in-line analysis on the operating network — no simulations, no synthetic loads.
- Hardware-level precision: a 1 Gbps inline Ethernet tap installed between the core network switch and the master radio at the hub tower
- Deep-packet analytics with Wireshark, capturing raw frames across every operational state
- Five rigorous 55-minute test scenarios, each isolating a single variable so the data couldn't lie
- Bandwidth utilization, packets-per-second, protocol distribution, and latency tracked end-to-end
- Field engineers on site for the duration — no remote guesswork, no synthetic traffic
Test 1 — Baseline Operations — Standard legacy polling intervals (1 hr Inter-poll / 20 min ESP) with no MQTT traffic. Establishes the network's normal operating posture.
Test 2 — High-Frequency Polling — Cygnet polling accelerated to 5–15 minute intervals to stress the legacy radio system and surface any saturation behavior.
Test 3 — Variable Isolation (No ESP Polling) — High-frequency polling repeated with ESP polling disabled, isolating which subsystem was actually causing the dropoffs.
Test 4 — NATS Batch Integration — Normal polling running alongside the new MQTT (NATS Batch) protocol, measuring the real cost of overlaying modern edge data.
Test 5 — Maximum Load (Batch + Live) — Heavy stress: standard polling, NATS Batch, and dense NATS Live traffic on a 5-second interval, all on the same Xetawave radios.
Key Finding #1 — Polling Bottlenecks
The radios weren’t the problem. The polling configuration was.
When legacy polling intervals were accelerated to 5 minutes (Test #2), the system struggled to resolve requests. From a distance, that looks like classic radio saturation — the kind of result that would normally end the conversation about MQTT before it ever started.
Methodical testing isolated the interference. By disabling ESP polling in Test #3, network requests improved significantly — the same radios, carrying the same accelerated Cygnet load, suddenly behaved.
That single insight gave The Operator a clear troubleshooting path: segmenting communications channels for individual devices resolved the collisions. The radio network itself wasn’t over-saturated. It had the necessary headroom — it just needed an optimized configuration.
Key Finding #2 — MQTT / NATS Validation
MQTT overlay barely moved the needle.
When modern MQTT traffic was deployed in both Batch and Live states, the results were striking. Tracking the capture metrics, Twin Eagle proved that MQTT communications produced minimal impact on the legacy network architecture. Average radio utilization climbed only from 2.6% at baseline to 4.2% under the heaviest load.
| Metric | Test #1Baseline | Test #2High-Freq | Test #3No ESP | Test #4NATS Batch | Test #5Batch + Live |
|---|---|---|---|---|---|
| Packets | 59,877 | 94,078 | 72,552 | 56,691* | 80,006 |
| Avg PPS | 18.2 | 28.2 | 21.8 | 17.2* | 24.3 |
| Avg Pkt Size (B) | 91 | 77 | 104 | 102* | 110 |
| Total Bytes | 5,443,519 | 7,204,021 | 7,566,344 | 5,763,155* | 8,823,705 |
| Avg Bytes/s | 1,651 | 2,162 | 2,278 | 1,745* | 2,675 |
| Avg Bits/s | 13 Kbps | 17 Kbps | 18 Kbps | 13 Kbps* | 21 Kbps |
| Avg Utilization | 2.6% | 3.4% | 3.6% | 2.6%* | 4.2% |
| Peak Bit/s | 130 Kbps | 110 Kbps | 165 Kbps | 280 Kbps* | 180 Kbps |
| Peak Utilization | 26% | 22% | 33% | 56%* | 36% |
Most importantly, packet loss remained at 0%, with a steady, low latency average of 75 ms — even with NATS Live traffic running on a 5-second cadence on top of normal Cygnet polling.
Per-test continuity by application (spike removed in Test 4)
The Conclusion
Empowering the edge — with no rip-and-replace.
Twin Eagle Solutions prevented prolonged trial-and-error out in the field. Our network performance analysis definitively proved that The Operator’s existing radio infrastructure was highly capable of supporting next-generation MQTT-based edge communications with zero adverse impacts.
We also delivered a roadmap for optimizing their legacy SCADA polling frequencies, turning intermittent errors into a highly responsive, manageable, and scalable system.
When downtime isn’t an option, and continuous data flow is the lifeblood of operations, the most advanced energy operators trust Twin Eagle Solutions to seamlessly bridge the gap from the office to the edge.
Headroom proven
4.2%
Peak utilization at maximum load — the radios had room to spare.
Data integrity
0% loss
Across all five 55-minute scenarios, including maximum load.
Real-time ready
75 ms
Steady average latency under the heaviest combined workload.
Appendix · Deep Packet Network Analysis
Wireshark I/O graphs, every test, every minute.
For complete transparency, Twin Eagle captured Wireshark I/O activity across every ~55-minute test scenario. The graphs below show, side-by-side, exactly how the network behaved as polling frequencies ramped up and MQTT traffic was layered in.
