DEV Community: IOTRouter

Choosing an M.2 AI Accelerator: 5 Things to Check Beyond TOPS

Agnes Wang — Tue, 08 Sep 2026 06:27:43 +0000

M.2 AI accelerators are becoming a practical way to add dedicated inference compute to an edge system without replacing the entire industrial computer.

The problem is that they are often compared by one number: TOPS.

A 160 TOPS accelerator may look obviously better than a 20 TOPS device on paper, but that comparison says very little about how either one will behave in a real deployment. The result depends on the model, available memory, data movement between the host and accelerator, thermal conditions, and the software stack used to deploy the model.

When I evaluate an M.2 AI accelerator, these are the five areas I look at before the headline compute figure.

1. Define the Workload Before Comparing TOPS

Start with the application rather than the accelerator.

A multi-camera object detection system and a local LLM may both fall under “edge AI,” but they place very different demands on the hardware.

For a vision system, the important questions are usually how many camera streams need to be processed, at what resolution and frame rate, where video decoding and preprocessing happen, and what inference latency or FPS the application actually requires.

For an LLM or VLM, the priorities shift toward model size, quantization, context length, concurrency, memory consumption, and expected token generation speed.

This difference matters because the same accelerator can be a good fit for one workload and a poor fit for another. A device optimized for several INT8 vision models may have more than enough arithmetic throughput for that job while still lacking the memory needed for a larger generative model.

That is why TOPS makes more sense after the workload has been defined, not before.

2. Memory Can Become the First Practical Limit

For larger models, compute is often not the first constraint you run into.

Memory is.

The accelerator has to hold more than the model weights. Runtime memory may also be consumed by intermediate tensors, activations, temporary buffers, KV cache, and the runtime itself.

With LLMs, longer context windows and higher concurrency can increase that requirement quickly.

This is where two accelerators with similar theoretical compute can behave very differently. One may have enough local memory to keep most of the workload on the accelerator, while another may depend heavily on host memory.

If the model does not fit comfortably in local accelerator memory, the usual options are to reduce precision, shorten the context window, lower concurrency, or move part of the workload into host memory. None of those choices is free. They affect latency, throughput, memory traffic, or model quality somewhere else in the system.

Host-memory offloading can extend capacity, but it also increases data movement between the host and accelerator. Once that happens, PCIe becomes part of the performance equation as well.

So for local LLM workloads, I would not look at TOPS in isolation. Compute capability, accelerator memory, memory bandwidth, quantization, and real runtime memory usage need to be considered together.

3. Map the PCIe Data Path

An M.2 connector tells you the form factor. It does not tell you the full data path.

You still need to confirm the actual interface provided by the host: the M.2 key, PCIe generation, available lane count, electrical implementation, and any limitations imposed by the platform.

But even after confirming that a slot is PCIe x1, x2, or x4, lane count alone does not tell you whether PCIe will become a bottleneck.

What matters is how much data crosses that link during normal operation.

Consider a camera-based edge AI system. If the CPU decodes several high-resolution streams, performs preprocessing, and then sends frames to the accelerator, a large amount of data may continuously move across PCIe.

The path might look roughly like this:

Camera → CPU decode → preprocessing → PCIe transfer → AI accelerator → result

In that architecture, PCIe bandwidth can matter a lot.

Now consider a different system where the model is loaded into accelerator memory, the host sends relatively small inputs, inference remains local to the accelerator, and only compact results are returned. The PCIe link is still important, but it may no longer be the limiting factor.

That is why comparing x1, x2, and x4 without understanding the workload can be misleading.

The more useful question is not simply how many PCIe lanes are available. It is how much data has to cross those lanes during inference.

4. Peak Performance Is Not Sustained Performance

Short benchmarks are useful, but edge systems rarely operate for only a few minutes.

They may run continuously inside control cabinets, fanless industrial PCs, roadside enclosures, machines, or equipment rooms where cooling conditions are very different from a desktop test bench.

The accelerator also shares that thermal environment with the CPU, RAM, SSD, power circuitry, and sometimes a 4G or 5G modem.

As temperature rises, the accelerator or host processor may reduce frequency to stay within its thermal limits. The TOPS figure on the datasheet does not change, but the actual inference throughput does.

This is why sustained performance matters more than a short peak result for many industrial deployments.

A useful test should run the real workload long enough for the system to reach a stable thermal state. During that period, I would pay attention to accelerator and CPU temperatures, clock frequency, inference latency, FPS or tokens per second, and power consumption.

If a system starts at one performance level and drops noticeably after 30 or 60 minutes, that behavior matters more than the headline benchmark.

5. Validate the Software Stack Before Finalizing the Hardware

This is probably the area most likely to be underestimated.

Physically installing an M.2 accelerator is usually easy.

Deploying the model can be much harder.

Dedicated accelerators often depend on their own model converters, compilers, quantization tools, runtimes, drivers, and SDKs. An ONNX or PyTorch model does not automatically mean it can be moved onto every accelerator without changes.

Unsupported operators, conversion failures, accuracy changes after quantization, driver compatibility, or limited Linux support can all become real project delays.

This becomes even more important on ARM-based industrial computers. An accelerator may have a good SDK on x86 Linux but limited or immature support on the actual ARM platform used in the edge system.

I would therefore evaluate the software stack before committing to the hardware. The important questions are whether the target model architecture is supported, whether the required operators are available, what the model conversion path looks like, which quantization modes are supported, and whether the runtime works reliably on the target Linux environment.

In many projects, a lower-TOPS accelerator with a stable SDK and good documentation is easier to deploy than a faster device with a difficult toolchain.

Test the Complete Edge AI System

The accelerator is only one part of the platform.

The host CPU, memory subsystem, PCIe topology, storage, cooling, software stack, and I/O architecture all affect the result.

For a vision application, that means measuring the complete path from camera input through decoding, preprocessing, inference, and post-processing rather than looking only at the accelerator's inference time.

For an LLM, useful measurements include time to first token, tokens per second, memory consumption, context length, and concurrency.

The purpose of the test is to find out whether the complete system can meet the application requirement continuously, not whether one chip can produce an impressive benchmark in isolation.

A Simple Selection Checklist

Before choosing an M.2 AI accelerator, I would want clear answers to these five questions:

Workload: What model and application will actually run?
Memory: Does the model fit at the required context length and concurrency?
PCIe: How much data moves between the host and accelerator?
Thermal: Can the system sustain the required performance over time?
Software: Can the SDK reliably deploy and maintain the target model?

If those questions are answered first, the TOPS figure becomes much more useful.

Without that context, it is mostly a headline number.

Final Thought

TOPS is useful for narrowing down candidate hardware, but it is not enough to select the right accelerator.

A good M.2 AI accelerator has to fit the model, the host platform, the PCIe architecture, the thermal design, and the software environment at the same time.

That is what turns an accelerator specification into a working edge AI system.

For a deeper breakdown of memory, PCIe, thermal, and software trade-offs, see our M.2 AI accelerator selection guide.

What Is a Modbus Gateway? How It Connects PLCs and Industrial Devices to IoT Platforms

Agnes Wang — Thu, 13 Aug 2026 09:44:01 +0000

Modbus gateways are widely used in Industry 4.0, providing essential functions to connect PLCs and industrial devices to IoT platforms. In this article, we will explain how Modbus works and why this protocol still plays an important role in modern industrial applications.

1. What is Modbus?

Back in 1979, Modicon (now Schneider Electric) needed a way for its PLCs to talk to each other and to other gear, so they released Modbus. Fast-forward forty-odd years, and it's still the most widely deployed communication protocol in industrial settings.

Why has it survived this long? Three reasons:

Open. It’s a public protocol – anyone can implement it without paying licensing fees. That helped it spread like crazy from the 1980s into meters, drives, sensors, and all sorts of field devices.

Simple. The register read/write model is straightforward. Low implementation cost, low debugging barrier. Equipment makers can integrate it without headaches, and maintenance staff doesn't need a PhD to use it.

Widely compatible. Pretty much every industrial device out there supports it. PLCs, power meters, water meters, temperature/humidity sensors and controllers – they're all still talking Modbus on the factory floor today.

2. Modbus RTU, Modbus ASCII, and Modbus TCP

Modbus comes in three main flavors, depending on the physical layer and transmission method.

Modbus RTU – The most common mode in the field. It runs over RS-232 or RS-485 serial buses, uses binary encoding with CRC16 checksum, and relies on silent intervals between characters (3.5 character times) to delimit frames. RTU is efficient, simple to implement, and is the go-to for meters, sensors, and drives.

Modbus ASCII – Data is transmitted as ASCII characters – each byte becomes two hex characters, framed with a colon (:) at the start and CRLF at the end, with an LRC checksum. The upside: human-readable. You can stare at it on a serial terminal and figure out what's going on—the downside: half the efficiency of RTU.

That said, Modbus ASCII is rare in modern installations. Modbus ASCII is less common in modern industrial installations, whereas most industrial gateways focus on supporting Modbus RTU and Modbus TCP.

Modbus TCP – The Modbus frame is wrapped inside TCP/IP, default port 502. It replaces the RTU timing mechanism with a 7-byte MBAP header, and TCP takes care of error checking. Modbus TCP is used with Ethernet-enabled PLCs, controllers, and HMIs, and supports multiple simultaneous clients.

Modbus RTU vs Modbus TCP – what matters in practice

In short: RTU lives on RS-485 field devices like meters and sensors. TCP lives on Ethernet PLCs and controllers. For a detailed comparison of Modbus RTU and Modbus TCP communication, see our guide on Modbus RTU vs Modbus TCP.

In real projects, both often coexist. A plant might have power meters on RTU and PLCs on TCP – the gateway has to handle both at the same time.

3. Why Modbus Still Matters in Industrial IoT

Walk into any factory, substation, or building mechanical room, and you'll find older PLCs that have been running production-critical processes for years. Those aren't going anywhere just because someone decides to "go digital." Replacing them means downtime, re-commissioning, re-validation – huge cost and risk.

So the real question isn't "should we swap them out?" but "how do we bring their data into a modern IoT system?"

That's where industrial gateways come in. They bridge the gap between Modbus gear and cloud platforms. The gateway pulls data over Modbus from field devices, then pushes it up to the cloud via MQTT.

Where does the gateway sit in the data flow?

An industrial Modbus gateway does three things: collect, translate, and transmit.

Collect: The gateway reads Modbus registers based on a device mapping configuration. The engineer sets up a register table from the device manual, and the gateway polls the field devices at configured intervals.
Translate: Raw register values get turned into meaningful engineering data – that means data type parsing, scaling, and unit conversion. In some cases, the gateway also does protocol translation – for example, Modbus to IEC 60870-5-104 for power SCADA integration.
Transmit: The formatted data – now with real units and context – is sent out via MQTT, HTTP, or another industrial protocol. MQTT is one of the most common protocols used by industrial gateways for cloud connectivity. Learn more about how MQTT connects PLCs and field devices to Industrial IoT platforms. The upper-layer systems consume that standardized data for monitoring, analytics, and control.

4. Main Application Scenarios for Modbus Gateways

Modbus gateways are used in four core verticals: manufacturing, energy, power utilities, and buildings.

Smart factories – Production lines usually have multiple PLCs and controllers using Modbus RTU or TCP. For example, PLCs such as Delta DVP series can be connected to IoT gateways through Modbus TCP for remote monitoring and data acquisition. The gateway collects operational data – runtime, production counts, fault codes – and sends it up to MES or cloud platforms. Traditional setups often needed extra software layers like SCADA or protocol servers. A gateway simplifies the data acquisition tier by cutting out unnecessary middleware.

Energy monitoring – Commercial and industrial power metering is a sweet spot for Modbus RTU. A distribution room might have dozens of multifunction meters daisy-chained on one RS-485 bus, all speaking Modbus RTU. The gateway polls voltage, current, power factor, and energy data from all those meters, then forwards it to an EMS for trend analysis, efficiency optimization, and anomaly detection. This setup is widely used in commercial & industrial storage, campus energy management, and data center PUE monitoring.

Power automation – The power sector has its own communication standards. Substation automation systems typically require IEC 60870-5-104 (IEC104), but the protection and control devices on the ground might only speak Modbus. The gateway handles the Modbus-to-IEC104 translation, dealing with the measurement and control data that utility systems need. In these scenarios, a Modbus to IEC104 gateway can convert field device data into IEC104 messages for SCADA systems without modifying existing PLC programs.

Building automation – Building management, HVAC, pump rooms – these are classic "unattended, remote monitoring" scenarios. In smart building projects, edge controllers can integrate Modbus devices, HVAC systems, and BMS platforms through unified communication. Field devices connect to an edge gateway via Modbus, and the gateway pushes data to the cloud over 4G or Ethernet. Products like the EM300 edge controller are built for this – they act as Modbus RTU/TCP masters, connect to multiple building devices, run local edge logic (like temperature control interlocks), and only send key data upstream.

5. How to Choose a Modbus Gateway

When you're picking a gateway, look at these dimensions:

Dual RTU/TCP support – Both protocols are common in the field, and often mixed. The gateway should work as a Modbus RTU master (for RS485 devices) and as a Modbus TCP client (for Ethernet PLCs) – ideally with transparent RTU-to-TCP routing as well.

Isolated RS485 interfaces – Industrial-grade isolation protects the gear from electrical noise. Field environments are full of EMI and surges – isolation isn't a luxury, it's a basic reliability requirement.

Multi-protocol translation – It's not just Modbus-to-MQTT. Real projects often need Modbus-to-OPC UA, Modbus-to-IEC 104, Modbus-to-BACnet (for buildings). The more protocols a gateway supports, the more you can reuse it across projects without stocking different hardware.

Cloud connectivity and edge computing – Modern gateways should support MQTT for reliable cloud ingestion. Key features include MQTT QoS, TLS encryption, offline caching, and secure communication. Edge computing capabilities let you do local filtering, alarm evaluation, and interlock logic – cutting down the amount of raw data that goes to the cloud.

Reliability design – Industrial environments run 24/7/365. Pay attention to MTBF, wide temperature range, power redundancy, watchdog timers – these determine whether the gateway can survive years on a shop floor without flaking out.

6. FAQ

Can Modbus devices connect to the cloud?
Yes. An industrial gateway converts Modbus data into MQTT or HTTP messages and sends them to the cloud – no need to replace existing field devices.
Do I have to replace my existing PLCs to do IoT?
No. Most industrial PLCs support Modbus. A gateway can bring them into an IoT platform without hardware swaps or PLC program changes.
What's the difference between a Modbus gateway and a protocol converter?
A protocol converter typically does a single, straightforward format translation (like RTU ↔ TCP). An industrial gateway is a more complete device – it handles data acquisition, edge computing, MQTT upload, store-and-forward for network outages, and more.
How many Modbus devices can one gateway connect to?
That depends on the gateway's hardware, baud rate, polling cycle, and device response times. Multiple serial ports or Ethernet interfaces can expand the device count.
Can RTU and TCP devices connect to the same gateway?
Yes. Many industrial gateways support both Modbus RTU and TCP, allowing RS485 field devices and Ethernet PLCs to coexist in one system. It's common in mixed environments – meters on RTU, PLCs on TCP, all feeding into the same gateway for unified cloud upload.

7. Closing Thoughts

Why are we still talking about Modbus today?

Because the installed base is enormous, and it's not going away anytime soon. Those PLCs that have been running for a decade, the meters hanging off RS485 buses, the sensors inside switchgear cabinets – they speak Modbus, and they'll keep speaking Modbus.

The real challenge in industrial IoT isn't inventing new protocols. It's getting the data from all that Modbus equipment to flow somewhere useful. An industrial gateway does exactly that: reads Modbus data, translates it, and ships it via modern protocols to the cloud.

Modbus handles the field-level conversation. MQTT provides a lightweight, reliable channel for cloud connectivity in many IIoT applications.

Together – Modbus, the gateway, and MQTT – form a practical, proven path to connect existing industrial assets to today's IoT platforms.

From 6 TOPS to 320 TOPS: Building a Scalable Edge AI Platform for Industrial Applications

Agnes Wang — Mon, 20 Jul 2026 07:12:20 +0000

In industrial projects, choosing an edge computer is rarely about buying the "most powerful hardware." The real challenge is finding a platform that can handle today's workloads while remaining flexible enough for future AI requirements. You don't want to overpay for compute you'll never use, but you also don't want to tear out a gateway six months later when the project scope inevitably expands.

A scalable edge computing architecture provides a practical way to address this challenge. The following discussion uses a specific platform as an example.

1. 6 TOPS Is the Starting Point — Scalable AI Computing up to 320 TOPS

This industrial edge platform is powered by the Rockchip RK3588J octa‑core industrial processor, featuring 4× Cortex‑A76 performance cores and 4× Cortex‑A55 efficiency cores, with a standard configuration of 8 GB RAM and 128 GB eMMC storage. The built‑in NPU delivers 6 TOPS of computing power, supporting mixed‑precision operations across INT4, INT8, INT16, and FP16.

What does 6 TOPS actually mean in practice? Running YOLOv8‑based object detection on a single 1080P video stream, inference latency can be kept under 50 ms depending on model size and deployment configuration. When running 4 industrial cameras simultaneously, CPU utilisation stays below 65%.

But what if the project needs to run large models? For example, equipment predictive maintenance may require a 7B‑parameter time‑series analysis model, or production line quality inspection may need to run a 35B‑parameter multimodal large model. 6 TOPS is clearly not enough.

The device's solution is to reserve 2× M.2 PCIe high‑speed interfaces on the chassis, supporting the addition of compute expansion modules. Optional R182X or LQ50 accelerator cards are available, with maximum heterogeneous computing power reaching 320 TOPS. Performance testing shows that dual LQ50 modules can simultaneously run inference workloads with two 35B‑parameter large models under the tested configuration, and the Qwen3.5 35B‑A3B model achieves a Decode TPS of 24.06. This means a single unit can serve simultaneously as a data acquisition gateway, an edge AI inference server, and a local large‑model inference platform.

This elastically expandable compute design essentially uses a combination of a general‑purpose main controller and dedicated AI accelerators to flexibly cover the full range of scenarios, from lightweight inference to complex industrial‑grade tasks.

2. Three Software Layers for Faster Industrial Application Development

Without the right software ecosystem, even powerful hardware cannot deliver practical industrial applications. The device comes pre‑installed with the NeuronEX‑Lite industrial protocol hub, co‑developed by IOTRouter and EMQ, plus the Node‑RED visual programming engine and the FUXA zero‑code configuration tool, forming a three‑layer software architecture covering protocol connectivity, visual programming, and industrial visualization.

NeuronEX‑Lite handles southbound protocol access. It is compatible with over 100 industrial protocols, including Modbus RTU/TCP, OPC UA, EtherNet/IP, Siemens S7, Omron, Allen‑Bradley, and more, enabling low‑latency industrial data acquisition and processing. Node‑RED provides drag‑and‑drop workflow orchestration, with over 50 pre‑built industrial nodes — from reading PLC data to publishing via MQTT; just connect the nodes and deploy. FUXA handles web‑based visual configuration, with a library of over 200 components supporting multi‑screen rendering, enabling zero‑code construction of data dashboards and process flow diagrams.

The practical effect of this combination is that, in many industrial scenarios, IoT application development cycles can be shortened from weeks to days. Protocol access, data processing, business logic, and visual presentation are all completed on a single EC700 device.

3. IT and OT Convergence: Southbound Manages Heterogeneous Devices, Northbound Directly Connects to Major Clouds

The most vexing problem on industrial sites is not technology itself — it is heterogeneity. Siemens PLCs, Mitsubishi inverters, Omron sensors — each speaks its own protocol. The upper‑layer platform might be Alibaba Cloud IoT, OneNET, or a customer's self‑built private cloud.

This edge platform is positioned as an IT/OT integration hub. On the southbound side, it manages heterogeneous devices through NeuronEX‑Lite; on the northbound side, it directly connects to various cloud platforms via MQTT, HTTP, TCP, UDP, WebSocket, and other protocols. In a project test environment, the southbound side simultaneously connected a Modbus RTU power meter, an OPC UA machine tool, and a Siemens S7‑1200 PLC, while the northbound side connected to the Alibaba Cloud IoT Platform — the entire configuration took less than 30 minutes.

In many industrial deployments, integrating gateway, edge computing, and visualization functions into one platform can significantly reduce hardware investment and system complexity. Fewer devices mean fewer cables, fewer support calls, and fewer failure points — which translates directly to lower total cost of ownership.

4. Industrial‑Grade Fanless Thermal Design — Reliable Operation from ‑20°C to 70°C

The environmental challenges on industrial sites far exceed those faced by ordinary commercial equipment. High temperatures, dust, and electromagnetic interference are the norm. The EC700 uses an all‑metal finned chassis with dual pure‑copper heat pipes, with the SoC directly contacting the thermal base, establishing a complete thermal path from the chip to the heat pipes to the outer chassis. The fanless design prevents dust accumulation, and the operating temperature range is ‑20°C to 70°C.

In terms of electrical safety, it uses a DC 12 V power supply with reverse‑connection protection. All interfaces are isolation‑designed: RS485 features galvanic isolation, DI uses optocoupler isolation, and DO uses relay outputs with a load capacity of 5 A @ 30 VDC / 5 A @ 250 VAC. EMC testing has passed electrostatic discharge Level 3 (±8 kV air discharge, ±4 kV contact discharge), and both surge and burst tests have reached Level 2 (±1 kV), meeting relevant industrial EMC testing standards.

Hardware watchdog plus dual software watchdog mechanisms ensure automatic reset under extreme anomalies, enabling 24/7 unattended stable operation.

5. Multi‑Network Intelligent Switching and Integrated Visual and Audio Monitoring Capability

Network stability is the lifeline of industrial IoT. The EC700 supports 4G/5G + dual Gigabit Ethernet ports + Wi‑Fi 6 multi‑mode network access, with automatic reconnection on drop and multi‑channel hot‑standby. The 4G module uses Quectel Cat.4, supporting LTE‑FDD bands B1/B3/B5/B8 and others; the 5G module supports SA n1/n28/n41/n77/n78/n79 and NSA n41/n78/n79 bands. Wi‑Fi 6 supports dual‑band 2.4 GHz + 5 GHz with a maximum throughput of 600.4 Mbps.

For visual and audio monitoring, the device provides HDMI input and output interfaces, supporting 8K video decoding and 4K encoding, and can directly connect to large screens to display production status in real time. The 3.5 mm audio jack supports device warning audio output. This integrated visual/audio design is particularly practical in production line quality inspection scenarios: industrial camera feeds are displayed in real time on the HDMI large screen, AI inference results are overlaid with annotations, and audio alerts sound on anomalies — operators can grasp the full situation without leaving their workstations.

6. Boundary‑Free Remote Operations and Maintenance — Debug PLCs from Thousands of Miles Away

The more dispersed the devices, the higher the operations and maintenance costs. The EC700 comes with IOTRouter's self‑developed free remote O&M software, supporting remote configuration, remote debugging, remote diagnostics, and remote updates. Core capabilities include virtual serial ports and virtual network interfaces, allowing engineers to debug downstream devices from their computers with the same experience as plugging a cable in on‑site.

More critically, it has built‑in NAT traversal and P2P hole‑punching technology. Even if the device is deployed behind a carrier‑grade NAT or corporate firewall, no public IP address and no router port forwarding are required to enable secure remote access. The technical principle is that the EC700 actively maintains a persistent connection to the cloud handshake server; when an O&M engineer initiates an access request, the cloud assists in establishing a point‑to‑point encrypted tunnel, reducing unnecessary cloud forwarding and improving latency and bandwidth efficiency.

7. Secure and Flexible Industrial Computing Architecture

The EC700 uses a hardware and software architecture designed for supply‑chain reliability and long‑term industrial deployment. The core processor, Rockchip RK3588J, is paired with an embedded Linux operating system, and the software stack — Node‑RED and NeuronEX‑Lite — is either open‑source or customised for industrial use. This approach provides flexibility, transparency, and the ability to adapt to specific project security requirements.

For customers with volume requirements, IOTRouter also offers OEM/ODM services, including hardware silk‑screen customisation, firmware feature customisation, and private deployment of the management platform. The product has passed CCC certification.

Frequently Asked Questions

Q1: How is the EC700's 320 TOPS heterogeneous computing power calculated? How many cards need to be added?

The EC700's standard RK3588J built‑in NPU provides 6 TOPS of compute power. The chassis has 2× M.2 PCIe high‑speed interfaces reserved for adding compute expansion modules. A single LQ50 module provides 160 TOPS@INT8, and dual modules stacked deliver 320 TOPS. The R182X module provides 20 TOPS@INT8 per unit, suitable for 3B to 7B parameter models; the LQ50 module provides 160 TOPS@INT8 per unit, suitable for 7B to 35B parameter models. Users can choose to install 1 or 2 modules as needed, achieving elastic compute upgrades.

Q2: How many large models can the EC700 run simultaneously? What is the inference latency for a 35B‑parameter model?

According to IOTRouter's internal performance testing data, under the dual LQ50 module configuration, the EC700 can simultaneously run inference workloads with two 35B‑parameter large models. Taking the Qwen3.5 35B‑A3B model as an example, under conditions of Input: 128 tokens and Output: 128 tokens, the TTFT (time to first token) is approximately 738 ms, TPOT (time per output token) is approximately 24.06 ms, and Decode TPS is approximately 24.06. The end‑to‑end latency is within an acceptable range, meeting the real‑time inference requirements of industrial edge AI.

Q3: What is the secondary development environment for the EC700? Which AI frameworks does it support?

The EC700 is based on an open embedded Linux system and provides a full development kit and API documentation. For AI inference, it supports mainstream deep learning frameworks such as TensorFlow, PyTorch, Caffe, and MXNet, as well as the ONNX universal model format, with flexible deployment based on Docker containers. The compute modules integrate a dedicated NPU plus the RK3588 ISP vision processing unit, natively supporting integrated multimodal inference across text, image, and video.

Q4: What industrial protocols does the EC700 support? Can it simultaneously connect to Siemens S7 and Mitsubishi FX?

The device supports over 100 industrial protocols via NeuronEX‑Lite, including Modbus RTU/TCP, OPC UA, EtherNet/IP, Siemens S7, Omron, Allen‑Bradley, and more. The device provides 2× RS485 + 1× RS232 serial ports, each configurable with different baud rates and protocols. This means a single EC700 can simultaneously communicate with multiple PLCs from different brands over different interfaces and protocols, with data unified and processed internally before being sent to the cloud.

Q5: Does the EC700's remote O&M require a public IP address? How is security guaranteed?

No public IP address is required. The EC700 has built‑in NAT traversal and P2P hole‑punching technologies and actively maintains a persistent connection to the cloud handshake server. When the O&M side initiates access, the cloud assists in establishing a point‑to‑point encrypted tunnel, reducing unnecessary cloud forwarding and improving latency and bandwidth efficiency. Together with IOTRouter's self‑developed free remote O&M software, it provides comprehensive capabilities for remote configuration, debugging, diagnostics, and updates — debugging PLCs deployed at remote sites feels much like being connected locally.

Learn More: Edge AI for Industrial Applications

Disclaimer: This article is based on publicly available product specifications and performance data from the manufacturer. All performance claims are sourced from the manufacturer's published test results.

Why Autonomous Tractors Fail in the Field: The Hidden Challenge of CAN Bus Integration

Agnes Wang — Wed, 15 Jul 2026 09:49:43 +0000

Autonomous tractors have made significant progress in recent years. RTK-GNSS systems can now provide centimeter-level positioning accuracy, and autonomous navigation systems have already been deployed in commercial agricultural applications.

However, in real retrofit projects, engineers often see the same pattern: the system works correctly during controlled testing, but reliability problems appear after the machine enters actual field operation.

In many cases, the problem is not the positioning system or the navigation algorithm. The vehicle may know its location accurately and calculate the correct path, but the different electronic systems inside the machine still need to communicate reliably before autonomous operation can work consistently.

Unlike a purpose-built autonomous vehicle, most agricultural retrofit projects start with an existing tractor. Engineers inherit vehicle systems developed by different manufacturers, including steering controllers, engine ECUs, implement controllers, GNSS receivers, and additional sensors.

These systems often use different communication interfaces and protocols. A typical autonomous tractor may involve J1939 communication over CAN for vehicle systems, NMEA output from an RTK receiver through RS232, Modbus RTU sensors over RS485, and ISOBUS communication with agricultural implements.

Each technology works well in its own application area, but connecting them into one autonomous system is where many projects become complicated.

The challenge is not simply adding autonomous software. The real challenge is building a communication architecture that can reliably connect existing vehicle systems under real field conditions.

Why CAN Integration Becomes the Bottleneck

CAN bus itself is not a new technology. It has been widely used in vehicles for decades because of its reliability and ability to connect distributed electronic controllers.

The difficulty in autonomous tractors is not the CAN network itself, but understanding and integrating the information exchanged through it.

Many agricultural vehicles use J1939-based communication between electronic control units. ISOBUS (ISO 11783) is an agricultural communication standard based on CAN technology that enables interoperability between tractors and implements from different manufacturers.

However, standard protocols do not always mean simple integration.

In real projects, engineers may encounter manufacturer-specific message definitions or proprietary extensions. A steering controller may support standard communication structures while also including manufacturer-specific messages or extensions. An implement may follow ISOBUS requirements while adding additional functionality defined by the manufacturer.

A gateway used in this environment cannot simply forward CAN frames.

It needs to understand the message structure, process relevant parameters, and provide a flexible way to map data between different systems.

This is especially important in retrofit projects because every tractor platform may have different combinations of controllers, implements, and sensors.

Without a flexible communication layer, every new vehicle model may become a new custom integration project.

Why Real-Time Steering Should Stay Local

Another challenge appears when engineers try to move too much processing into the cloud.

Cloud platforms are extremely useful for agricultural applications. They provide fleet monitoring, remote diagnostics, historical data analysis, and centralized management.

However, real-time steering control has very different requirements.

The problem is not average network speed. The problem is unpredictable communication delay.

Agricultural fields rarely provide a perfectly stable network environment. Cellular coverage changes depending on location, and temporary signal interruptions are common.

A delay that is acceptable for uploading operational data may become a problem when it affects a steering correction loop.

For this reason, time-sensitive control decisions should remain on the vehicle.

A practical architecture keeps the control loop local.

The RTK receiver provides positioning information. The edge controller processes the data locally. The steering command is sent directly through the vehicle CAN network.

The cloud remains valuable, but mainly for monitoring, data synchronization, and fleet management.

This separation also improves reliability. If the cellular connection temporarily disappears, the tractor can continue operating because the essential control process does not depend on an external network.

Choosing Between PLC, IPC, and CAN Gateway

When designing an autonomous tractor system, engineers usually consider three types of architectures: PLC-based control, industrial PC platforms, and dedicated edge gateways.

PLCs remain one of the most reliable solutions in industrial automation. They provide deterministic control and long-term stability, making them suitable for fixed automation tasks.

However, autonomous tractors require more than traditional sequence control. The system needs to communicate with multiple vehicle networks, process positioning information, and integrate different protocols. Extending a PLC system to support these requirements may require additional modules and engineering effort.

Industrial PCs provide much higher computing capability and are the right choice for demanding workloads such as computer vision, AI inference, ROS-based navigation, or advanced sensor processing.

However, high computing performance also introduces practical considerations. Vehicle installations require attention to power consumption, thermal management, communication expansion, and long-term environmental reliability.

For many retrofit projects, the main challenge is not computing power.

It is communication integration.

This is where a dedicated CAN gateway provides a practical balance. Instead of replacing existing vehicle controllers, the gateway focuses on connecting them and handling communication between different systems.

For applications such as RTK-based guidance, CAN communication, and implement integration, this architecture often matches the actual requirements more closely.

A Practical Edge Gateway Architecture

A practical autonomous tractor system does not necessarily require replacing every existing controller.

The goal is to create a communication layer that connects existing systems.

An industrial edge gateway can connect the RTK receiver through RS232, communicate with CAN-based devices, collect sensor data through RS485, and provide remote connectivity through cellular networks.

One example implementation is the IOTROUTER EG8200, an industrial gateway designed for applications that require multiple communication interfaces in a compact fanless platform.

With CAN interfaces, RS232, RS485, wide-range DC input, and wireless connectivity, it provides a practical hardware platform for connecting different field devices and communication networks.

In agricultural retrofit projects, this type of architecture allows existing tractors and implements to be connected without redesigning the original vehicle control system.

In this architecture, the gateway handles local communication processing, while cloud connectivity is used for monitoring and management.

The key value is not simply the number of interfaces available. It is keeping communication between vehicle systems reliable while allowing existing equipment to participate in an autonomous platform.

Field Deployment: Where Design Decisions Are Tested

A system that works in a laboratory environment does not always survive a full agricultural season.

During field deployment, engineers need to consider factors that are often overlooked during initial development, including vibration, temperature changes, dust exposure, vehicle power fluctuations, and CAN network installation details.

Many problems that appear to be software issues may actually be caused by communication wiring, network configuration, or environmental conditions.

This is why autonomous tractor projects require both software capability and industrial engineering experience.

The most reliable systems usually follow a simple principle:

Keep critical control local. Keep communication flexible. Keep hardware suitable for the environment.

Conclusion

Autonomous tractors are often discussed as a problem of navigation accuracy, artificial intelligence, or positioning technology.

Those technologies are important, but reliable field operation depends on something more fundamental: communication between different vehicle systems.

The future of autonomous agriculture will not only depend on smarter algorithms. It will depend on better integration between machines, sensors, and controllers.

For autonomous tractor retrofit projects using RTK positioning, CAN communication, and agricultural equipment integration, the biggest challenge is not adding more computing power.

It is building a communication architecture that continues to work when the tractor leaves the laboratory and enters the field.

IOTRouter specializes in the R&D and manufacturing of industrial IoT hardware, including 4G/5G edge gateways, DTUs, and RTUs. We focus on providing stable, field-proven connectivity solutions to bridge the gap between industrial field devices and cloud platforms.

Explore our industrial edge solutions: [https://en.iotrouter.com]

Technical Support: For data sheets or project technical consultation, contact our team at agneswang@iotrouter.com.

Building reliable connectivity for Industry 4.0.

Solving Industrial Connectivity Challenges: An 11-Year Journey of IOTRouter Innovation

Agnes Wang — Mon, 06 Jul 2026 03:18:39 +0000

Beyond Connection: Solving Real-World Industrial Data Challenges

In the world of Industrial IoT, connectivity is never just about plugging in a cable. The core challenge lies in maintaining data integrity in harsh environments and bridging the gap between legacy machine protocols and modern cloud platforms.

As we enter 2026, CHENGDU IOTROUTER TECHNOLOGY CO., LTD marks its 11th year of expertise. Since 2015, we have focused on one mission: ensuring the system stays reliable when the network or environment fails. Here are our practical approaches to common roadblocks in the industrial IoT gateway market.

1. Handling Network Failures: Ensuring Data Continuity

In industrial settings, unstable wireless links are a reality. Rather than promising a perfect signal, our industrial IoT gateway design focuses on handling link interruptions effectively.
In collaboration with ThingsBoard Edge and EMQX architectures, our hardware utilizes a “Store and Forward” mechanism. When the connection drops, the gateway automatically buffers data in its local storage. Once the network is restored, it triggers an automatic retransmission. This ensures your historical data remains intact despite temporary Wi-Fi or cellular glitches.

2. Official Ecosystem Integration: Reliable System Performance

Setting up a new system often involves struggling with driver compatibility. As an official hardware partner for ThingsBoard and EMQX, we have handled the foundational integration for you:

Validated Stability: Our edge gateway series undergoes long-term runtime testing on these platforms to ensure underlying environmental stability.

Optimized Resource Management: We fine-tune hardware resource allocation, ensuring the gateway remains responsive while running edge software, preventing system crashes during multi-protocol processing.

3. Representative Solutions for Diverse Industrial Scenarios

In 2026, customers are moving toward purpose-built smart terminals. We provide a rich hardware portfolio to solve specific pain points:

Modular Innovation (EM300 Series): Our new EM300 Industrial Edge Controller addresses the limitation of fixed-function gateways. Its modular design allows engineers to customize I/O configurations based on specific site requirements—whether it's high-density analog input or specialized protocol conversion—without replacing the entire system.

Industrial-Grade LoRaWAN Connectivity (EG2000): For large-scale distributed environments like smart agriculture or expansive manufacturing parks, the EG2000 LoRaWAN Gateway provides long-range, low-power connectivity. It excels in penetrating complex industrial structures and maintaining reliable data transmission across vast distances, making massive sensor deployment financially and technically viable.

Cost-Effective 5G Connectivity (ER5200 Router): Designed for high-bandwidth requirements, the ER5200 utilizes 5G RedCap technology. It provides the low-latency benefits of 5G while avoiding the high power consumption and hardware costs of traditional 5G modules.

A Decade of Commitment to Industrial Reliability We don’t just build devices; we build a foundation. With 50+ patents, a state-level “Specialized and Sophisticated” SME certification, and over 5,000 global customers since 2015, IOTRouter knows that in this industry, reliability is everything. Every industrial IoT gateway we manufacture is ISO9001, CE, and FCC certified because, in a mission-critical environment, “good enough” is never enough.

About IOTRouter
Bridging the gap between IT and OT since 2015. We provide a comprehensive hardware ecosystem—including edge gateways, industrial routers, HMIs, and I/O modules—ensuring stable and intelligent connectivity for global industrial equipment.

Ready to optimize your industrial data architecture? Explore our full range of solutions: https://en.iotrouter.com/