Answer: The RK3568 is purpose-built for industrial IoT gateway deployments — its quad-core Cortex-A55 CPU, dual Gigabit Ethernet, native CAN bus, RS-485/RS-232, and PCIe 3.0 interface cover every southbound device connection a factory floor demands. Combined with a Linux-based protocol stack handling Modbus RTU/TCP, MQTT, and OPC UA simultaneously, an RK3568 gateway can aggregate hundreds of field devices, pre-process data at the edge, and forward structured payloads to AWS IoT, Azure IoT Hub, or a private SCADA platform — all within a 5W thermal envelope that fits a DIN-rail enclosure.
The global IoT gateway devices market was valued at USD 5.5 billion in 2026 and is projected to reach USD 14.3 billion by 2035, driven by the migration of legacy OT systems toward edge-cloud architectures. At the center of this transition sits the industrial gateway — the device that bridges decades-old Modbus sensors and PLCs to modern MQTT-based cloud analytics. Choosing the right processor for that gateway is the engineering decision that determines whether the deployment lasts three years or twelve.
This guide covers the RK3568's architecture in the context of industrial IoT gateway design: why its hardware interface set matches factory-floor requirements, how to build the protocol translation software stack, what the deployment topology options look like across different industry segments, and how to select between the RK3568 SBC and SoM form factors depending on your production scenario. Whether you're migrating a brownfield Modbus installation or designing a greenfield IIoT node from scratch, this is the technical reference your team needs before the first PCB layout.
Основные выводы
- RK3568's dual Gigabit Ethernet + RS-485 + CAN bus interfaces cover the southbound side of any industrial gateway without external expansion chips
- PCIe 3.0 enables 4G/5G cellular modem integration for remote deployments via a single M.2 slot — no USB latency penalty
- Linux kernel 5.10 LTS on RK3568 provides stable long-term support with upstream Rockchip BSP maintenance
- Protocol stack: Modbus RTU → libmodbus → Node-RED → Mosquitto MQTT → cloud is the validated reference path for RK3568 deployments
- RK3568J (industrial-grade variant) operates from -40°C to +85°C and carries extended component availability commitment
- SoM form factor (e.g., ieeker's RK3568 core board) reduces time-to-market for custom gateway enclosures vs. designing from SoC
- OPC UA server capability enables direct SCADA/MES integration without a separate middleware layer
- Edge preprocessing reduces cloud data ingestion costs by 60–80% compared to raw-stream forwarding architectures
Why the RK3568 Is Engineered for Industrial IoT Gateways
Not every ARM SoC is a viable industrial IoT gateway processor. The selection criteria for gateway silicon differ fundamentally from consumer embedded applications: you need deterministic interface timing for serial fieldbus polling, enough CPU headroom to run protocol translation daemons in parallel, low idle power to sustain 24/7 operation, and a peripheral set that covers industrial connectivity without external chips that add BOM cost and failure points.
The RK3568 satisfies all four requirements natively. Here is what the silicon brings to an industrial IoT gateway design without any external peripherals:
| Интерфейс | RK3568 Native Capability | Industrial Gateway Use |
|---|---|---|
| Dual Gigabit Ethernet | 2× independent GbE MACs | LAN (field devices) / WAN (cloud uplink) separation without a switch chip |
| PCIe 3.0 × 2 | M.2 / mPCIe expansion | 4G LTE / 5G NR modem, NVMe SSD for local historian |
| CAN Bus × 2 | ISO 11898-1 compliant | Direct PLC / actuator connectivity, automotive sensor integration |
| UART × 3 | Full-duplex, up to 4 Mbps | RS-232 / RS-485 Modbus RTU polling (with level shifter) |
| USB 3.0 × 1 + USB 2.0 × 2 | Host + OTG | USB-to-serial adapters, cellular dongles (fallback), USB storage |
| SATA III | 6 Gbps | Local data historian (2.5" SSD, years of process data) |
| SPI / I²C / GPIO | Multiple channels | Environmental sensors, RTC, DI/DO expansion, watchdog circuits |
| NPU (1.0 TOPS) | RKNN inference engine | On-device anomaly detection, predictive maintenance ML models |
The dual Gigabit Ethernet deserves particular emphasis. Most gateway designs require physical separation between the field network (where PLCs, sensors, and meters communicate) and the WAN uplink (where cloud data flows). Achieving this with a single-Ethernet SoC requires an external managed switch — adding cost, board space, and a potential failure point. The RK3568's two independent GbE MACs allow a proper two-interface topology in Linux (br0 for field LAN, eth1 for WAN) with firewall rules isolating OT traffic from the internet without external hardware.
For a deeper comparison of RK3568 versus RK3588 for compute-intensive applications, see our RK3568 vs RK3588 comparison guide. For IoT gateway work specifically, the RK3568's lower power consumption (3–5W typical vs. 8–12W for RK3588 under gateway workloads) makes it the correct choice in the majority of DIN-rail deployments.
The RK3568 IoT Gateway Software Stack: From Field Device to Cloud
Hardware capability is only half the equation. An industrial IoT gateway runs a software stack that must reliably perform four functions simultaneously: poll southbound field devices, translate protocols, pre-process and filter data, and forward structured payloads northbound to cloud or SCADA. On the RK3568, this stack runs on Linux — either a minimal Buildroot system for production deployment or a full Debian/Ubuntu image during development.
Layer 1 — Operating System: Linux 5.10 LTS
The reference OS for production RK3568 IoT gateway deployments is Linux 5.10 LTS (Long-Term Support), maintained in the upstream Rockchip BSP. LTS kernels receive security patches for six years — critical for deployments where firmware updates are infrequent or require change-control procedures. For development and rapid prototyping, Ubuntu 22.04 LTS provides the richest package ecosystem and is fully validated on the RK3568 platform.
Key kernel configuration items for gateway deployments: enable CONFIG_CAN и CONFIG_CAN_FLEXCAN for CAN bus, CONFIG_SERIAL_8250 for UART/RS-485, and CONFIG_BRIDGE for the LAN/WAN bridging setup. ieeker's RK3568 industrial board SDK includes a pre-configured gateway kernel build with all industrial interface drivers compiled in — no manual kernel configuration required.
Layer 2 — Protocol Southbound: Modbus, CAN, OPC UA
The southbound layer connects to field devices — PLCs, sensors, meters, drives. Three protocols cover the majority of industrial installations:
- Modbus RTU (RS-485): The most widely deployed industrial protocol globally. On RK3568,
libmodbusprovides a C library for Modbus RTU/TCP polling. A typical configuration polls 32 slave devices at 115200 baud with 100ms cycle time — fully achievable on a single UART thread with ≤2% CPU utilization. As explained in the Modbus protocol specification, the master-slave polling model is synchronous and deterministic, making it straightforward to implement as a Linux user-space daemon. - Modbus TCP (Ethernet): For Ethernet-connected PLCs and meters, Modbus TCP runs over the RK3568's LAN interface. The same
libmodbuslibrary handles both RTU and TCP with a simple transport-layer switch. - CAN Bus (ISO 11898): For automotive-derived industrial sensors (AGV battery management, vehicle CAN buses, some PLCs), the RK3568's two native CAN controllers with
SocketCANdriver support in Linux provide a standardcan0/can1network interface. Tools likecandumpиcansendenable rapid testing. - OPC UA: For modern PLC integration (Siemens S7-1200/1500, Allen-Bradley), open62541 — the open-source OPC UA stack — runs efficiently on RK3568, consuming approximately 30MB RAM for a full OPC UA server instance. This enables bidirectional communication: the gateway can read process values and write setpoints back to the PLC.
Layer 3 — Edge Processing: Node-RED or Custom Python/C Daemon
Raw field data rarely goes directly to the cloud. Before northbound forwarding, the gateway performs filtering, unit conversion, threshold alerting, and data aggregation — what the industry calls "reporting by exception." This reduces cloud data ingestion costs dramatically. According to analysis of edge computing Modbus-MQTT deployments, an event-based forwarding strategy (only sending data when values change beyond a threshold) reduces upstream bandwidth consumption by 60–80% compared to constant polling forwarding.
Two practical approaches for the edge processing layer on RK3568:
- Node-RED: The visual flow programming tool runs on Node.js and deploys in under 5 minutes on RK3568 Debian/Ubuntu. Node-RED's Modbus, MQTT, and OPC UA nodes cover most gateway use cases with no custom code. Idle RAM footprint is approximately 80MB — well within the RK3568's typical 2–4GB LPDDR4 configuration. Suitable for rapid deployment and projects where non-engineers need to modify data flows.
- Custom C/Python daemon: For high-frequency polling (sub-10ms cycle) or deployments requiring minimal RAM, a custom daemon written in C (using
libmodbus+libmosquitto) achieves sub-millisecond Modbus polling latency with under 10MB RAM footprint. This is the preferred approach for high-channel-count gateways (100+ Modbus slaves) or when the gateway is also running NPU inference workloads.
Layer 4 — Northbound: MQTT + Cloud Platform Integration
MQTT is the standard northbound protocol for industrial IoT gateways. On RK3568, Mosquitto provides the local MQTT broker (for inter-process communication between the Modbus daemon and the cloud forwarder), and the libmosquitto client library handles cloud connections to AWS IoT Core, Azure IoT Hub, or a self-hosted broker.
Production MQTT configuration for RK3568 gateway deployments should include: TLS 1.2/1.3 encryption on port 8883, QoS level 1 for critical alarm messages (at-least-once delivery), local store-and-forward buffer (SQLite or flat file) for offline operation during WAN outages, and automatic reconnect with exponential backoff to prevent broker overload on network recovery.
For understanding OS selection trade-offs on Rockchip platforms (particularly Linux vs. Android for gateway vs. HMI use cases), see our detailed Linux vs Android industrial OS comparison.
From the Factory Floor: Migrating 140 Modbus Sensors to MQTT in a Tire Manufacturing Plant
About fourteen months ago, I led the gateway hardware selection for a brownfield IIoT retrofit project in a tire vulcanization plant in Shandong province. The plant had 140 temperature and pressure sensors distributed across 18 vulcanization presses — all connected via Modbus RTU on RS-485 buses, originally installed in 2009. The customer's goal was simple: get all sensor data into their new AWS-based MES without replacing any field wiring or sensors. Total retrofit budget was constrained.
The challenge was that the existing Modbus bus topology was non-standard — three separate RS-485 segments, each with between 40 and 55 devices, running at 9600 baud with mixed vendor device addresses (some duplicated within segments from a prior expansion that was never properly documented). The plant environment ran at 55–65°C ambient near the presses. Any gateway hardware had to operate reliably at that temperature and handle three simultaneous Modbus polling threads without address conflicts.
We selected our RK3568J-based gateway board for two specific reasons: the J-grade SoC is rated to 85°C junction temperature (giving comfortable thermal margin in a ventilated DIN-rail enclosure at 65°C ambient), and the three UART interfaces allowed three independent Modbus RTU masters — one per RS-485 segment — running as separate libmodbus daemon instances with isolated device address spaces. There was no cross-segment address conflict issue because each segment was logically isolated at the software layer.
The complete software stack was: three Modbus daemons → local Mosquitto broker → Python aggregator with 10-second rolling averages and threshold alerting → AWS IoT Core via TLS 1.2 MQTT. Total polling latency for all 140 sensors: under 800ms round-trip across all three segments. Cloud data volume was reduced to approximately 8% of raw poll rate through reporting-by-exception filtering — the customer's AWS data ingestion cost dropped from their initial estimate by 73%.
The deployment has been running for fourteen months with zero unplanned downtime attributable to the gateway hardware. Two firmware updates have been applied via SSH — one BSP security patch and one application-layer improvement to the threshold alerting logic. The thermal imaging we ran at month six showed the RK3568J running at 71°C junction temperature under full polling load in the 65°C ambient environment — well within the 85°C rated maximum.
RK3568 Industrial IoT Gateway Deployment Topologies
Gateway architecture varies significantly by industry, connectivity environment, and data volume. The RK3568 supports four primary deployment patterns, each with different hardware configuration and software stack requirements.
Topology 1 — Wired Factory Gateway (Ethernet LAN + WAN)
The most common topology for factory-floor deployments. The RK3568's two GbE interfaces are configured: eth0 as the field LAN (connected to a managed switch serving PLCs, meters, and Ethernet-capable sensors) and eth1 as the plant WAN (connected to the factory IT network or internet router). Linux network namespaces or iptables firewall rules enforce OT/IT network isolation. Latency from Modbus poll to MQTT publish: typically 50–150ms including edge processing.
Topology 2 — Cellular Gateway (4G/5G Remote Deployment)
For remote infrastructure (pumping stations, substations, agricultural monitoring, pipeline monitoring), the RK3568's PCIe 3.0 slot accepts an M.2 4G LTE or 5G NR modem. The modem appears as a network interface (wwan0) in Linux via the mbim или qmi-wwan driver. A store-and-forward buffer in local SQLite handles data persistence during cellular outages — the gateway continues polling field devices and buffering locally, then flushes to the cloud on reconnection. Typical buffer capacity: 30 days of 1-minute sensor readings from 64 devices in under 500MB.
Topology 3 — Multi-Protocol Aggregation (Modbus + CAN + BLE)
Manufacturing environments increasingly run mixed device ecosystems: legacy Modbus meters, newer CAN-bus actuators, and wireless BLE sensors from condition monitoring systems. The RK3568 handles all three simultaneously: Modbus RTU on UART, CAN bus via SocketCAN, and BLE via a USB Bluetooth 5.0 dongle or a Bluetooth-integrated carrier board. All three data streams feed the edge processing layer, which normalizes them into a unified JSON payload before MQTT forwarding.
Topology 4 — Edge AI Gateway (NPU-Accelerated Anomaly Detection)
The RK3568's 1.0 TOPS NPU enables lightweight ML inference on the gateway itself. For predictive maintenance applications, a quantized LSTM or autoencoder model (typically 2–8MB in RKNN format) runs on the NPU to score sensor readings in real time. Only anomalies — vibration signatures, temperature patterns, current waveforms — trigger cloud upload; normal readings are summarized into hourly aggregates. This reduces cloud storage and processing costs significantly while enabling sub-second anomaly detection without cloud round-trip latency.
To understand the full NPU inference workflow on Rockchip platforms using RKNN-Toolkit2, see our NPU performance deep-dive — the RKNN workflow is identical between RK3568 and RK3588, differing only in peak throughput (1.0 TOPS vs 6.0 TOPS).
SBC vs. SoM: Which RK3568 Form Factor for Your Gateway Design?
Once you've validated the RK3568 platform for your gateway application, the next decision is hardware form factor: use a standard RK3568 development board (SBC) directly, or build a custom enclosure around an RK3568 SoM (System-on-Module) mounted on a custom carrier board. This decision drives cost, time-to-market, certification scope, and long-term supply chain complexity.
| Фактор | RK3568 SBC | RK3568 SoM + Custom Carrier |
|---|---|---|
| Time to first prototype | Days (software only) | 8–12 weeks (carrier board design + fab) |
| NRE cost | $0 (standard board) | $4,000–$12,000 (carrier design) |
| Unit cost at 500 units | Higher (full SBC BOM) | Lower (carrier has minimal BOM) |
| Form factor flexibility | Fixed (standard dimensions) | Fully custom (fit any enclosure) |
| Настройка интерфейса | Limited (fixed connector layout) | Full (carrier defines all I/O layout) |
| CE/FCC certification scope | SBC already certified (verify SKU) | System-level certification needed for end product |
| Recommended production volume | <500 units/year | >500 units/year |
The crossover point in total cost of ownership typically falls between 300 and 600 production units depending on carrier board complexity. Below that volume, the SBC's zero NRE cost makes it the right choice even if per-unit cost is higher. Above that volume, the SoM + custom carrier amortizes the NRE across enough units to show meaningful per-unit savings, while also enabling the custom form factor and interface layout that products sold through sales channels typically require.
For a full analysis of the SoM vs SBC decision framework including BOM cost breakdowns, see our SoM vs SBC design guide. ieeker offers both the RK3568 development board for rapid prototyping and the RK3568 SoM with carrier board customization service for production-scale gateway OEM programs.
RK3568 IoT Gateway Applications by Industry
The RK3568's interface versatility means a single hardware platform can serve distinctly different industries with primarily software-layer differentiation. Here is how the gateway architecture maps to the four highest-volume industrial IoT gateway deployment sectors.
Smart Manufacturing / Industry 4.0
The core use case: connecting legacy PLCs, CNC machines, SCADA systems, and power meters to cloud analytics platforms. The RK3568 gateway typically sits at cell or line level — one gateway per production cell, aggregating 20–60 devices via Modbus TCP/RTU and forwarding to a plant-level historian (OSIsoft PI, Ignition) or directly to cloud MES. The NPU enables on-device tool wear detection and OEE calculation without cloud dependency.
Energy & Utilities (Smart Grid, BESS, Solar)
Substations, solar inverter strings, and battery energy storage systems (BESS) increasingly require remote monitoring via cellular uplink. The RK3568's PCIe 4G/5G modem slot + SATA SSD for local historian storage makes it the right choice for these often-isolated deployments. Modbus TCP connects to inverters; the CAN bus handles BESS battery management systems (BMS) that use CANopen or a proprietary CAN protocol. IEC 60870-5-104 (the utility industry's SCADA protocol) is supported via open-source libraries.
Building Automation (BACnet / KNX)
Smart building systems (HVAC, lighting, access control, energy metering) use BACnet/IP as the dominant protocol. The RK3568 runs a BACnet/IP stack (open-source BACnet4Linux or commercial options) on its LAN interface, aggregating building subsystem data for BEMS platforms. This is a particularly strong market for compact DIN-rail RK3568 gateway designs given the typically mild temperature environment and 5–10 year replacement cycles in commercial building infrastructure.
Cold Chain & Logistics
Refrigerated warehouse and transport monitoring requires multi-sensor aggregation (temperature, humidity, door status, power consumption) with cellular uplink and reliable store-and-forward. The RK3568's cellular modem integration and local SQLite buffer make it well-suited for deployments where internet connectivity is intermittent. BLE sensor integration (for wireless shelf-level temperature loggers) via the USB Bluetooth path enables high-density warehouse coverage without running new wiring.
Project Case: Building a Cellular IoT Gateway for Remote Solar Farm Monitoring
One of the clearest demonstrations of the RK3568's cellular gateway capability came from a project we supported for a renewable energy operator in the Middle East. The customer operated 14 solar farms across remote desert locations in Saudi Arabia, each with between 20 and 45 string inverters connected via Modbus TCP on a site-local Ethernet LAN. Each farm had a commercial cellular router for internet access, but their existing SCADA gateway hardware — PC104-form-factor boards from a European supplier — was hitting end-of-life and failing at an accelerating rate in the 55°C+ ambient temperatures.
The replacement requirement: a gateway board that could operate at 55°C ambient without active cooling, poll all inverters via Modbus TCP at 1-minute intervals, forward generation data to their Azure IoT Hub, maintain a 90-day local data buffer for regulatory compliance, and fit into the existing DIN-rail enclosure (limiting dimensions to 150mm × 100mm PCB footprint).
We supplied a custom RK3568J carrier board built to those dimensions: dual GbE (field LAN + cellular WAN via M.2 LTE module), 32GB eMMC + 256GB SATA SSD for the historian, passive heatsink rated to 60°C ambient, and a conformal-coated PCB for the high-dust desert environment. The software stack ran Buildroot Linux with a custom Modbus TCP polling daemon and Azure IoT Hub SDK integration.
Deployment results across the first 12 months at all 14 sites: 99.7% gateway uptime (the 0.3% downtime was attributable to two cellular network outages, with no data loss due to store-and-forward buffering). Peak junction temperature logged: 78°C at the hottest site in July. Average Azure data ingestion volume: 1.4 GB/month per site versus the customer's initial estimate of 6.8 GB/month — a 79% reduction achieved through the edge filtering logic. The customer has since committed to deploying the same design across an additional 22 sites in the next phase.
Security and Reliability Considerations for Production Gateway Deployments
An industrial gateway sits at the intersection of OT and IT networks, making it one of the highest-priority attack surfaces in an industrial environment. Security is not an optional post-deployment add-on — it must be designed into the system from the hardware selection stage. For RK3568-based gateways, the following are non-negotiable production requirements.
Secure Boot and Encrypted Storage
The RK3568 supports hardware-backed secure boot using RSA-2048 or ECDSA-256 signature verification on the bootloader and kernel image. Enabling secure boot prevents unauthorized firmware modifications — critical for gateways deployed in physically accessible locations (substations, remote pump stations). eMMC storage encryption using dm-crypt (AES-256-XTS) protects stored credentials, certificates, and buffered sensor data if the device is physically removed.
Network Segmentation
As referenced earlier, the dual GbE interface configuration enforces hardware-level OT/IT separation. Complement this with iptables rules that: block all inbound connections from the WAN interface to the field LAN, allow only outbound MQTT/TLS on port 8883 from gateway to cloud, and drop all unsolicited inbound traffic to the gateway management interface except SSH on a non-standard port with key-based authentication only.
Certificate-Based Authentication
All cloud MQTT connections should use mutual TLS (mTLS) with device-unique X.509 certificates. AWS IoT Core and Azure IoT Hub both support mTLS natively. The device private key should be stored in a hardware security module (HSM) or TPM chip if the carrier board includes one — this prevents private key extraction even if an attacker gains root access to the Linux filesystem.
Watchdog and Remote Recovery
Production gateways must self-recover from software faults without human intervention. The RK3568 has a hardware watchdog timer — configure it with a 60-second timeout and arm it from the application daemon. Add a secondary software watchdog at the systemd service level that checks MQTT broker connectivity every 5 minutes and restarts the application stack if connectivity is lost. For remote deployments where on-site access is impossible, an out-of-band management path (LTE modem SMS command interface or dedicated management VLAN) provides a recovery path when the primary application is stuck.
ieeker RK3568 Gateway Hardware Options
ieeker manufactures RK3568-based boards in two configurations suited to different stages of the IoT gateway development and production journey:
- RK3568 Industrial Development Board (SBC): Dual GbE, RS-485, CAN bus, M.2 PCIe (LTE modem slot), SATA III, USB 3.0, HDMI, and full GPIO header. Ships with validated Buildroot, Debian 11, and Ubuntu 22.04 images. Available for immediate evaluation from single-unit quantities. Designed for prototype, pilot, and small-volume production deployments. See the RK3568 industrial board product page for full specifications.
- RK3568 SoM (Core Module) + Custom Carrier: The RK3568 SoM exposes all SoC interfaces on a SODIMM-314P or MXM connector, allowing carrier board design for custom enclosure dimensions, custom interface layout, industrial connector types (M12, DIN-rail terminal blocks), and conformal coating for harsh environments. NRE from $4,000. Production units from 50 pieces. Learn more about the custom development board design and OEM workflow.
Building an industrial IoT gateway on RK3568?
Share your interface requirements and deployment environment — we'll recommend the right board configuration and provide BSP documentation within 24 hours.
→ Get RK3568 Gateway Technical Support →Часто задаваемые вопросы
How many Modbus devices can an RK3568 gateway poll simultaneously?
The limiting factor is serial bus bandwidth, not CPU. Each RS-485 UART supports up to approximately 40–60 Modbus RTU slaves at 115200 baud with a 500ms polling cycle. With three UART interfaces on the RK3568, a single gateway can poll 120–180 Modbus RTU devices. Via Modbus TCP over Gigabit Ethernet, the device count scales to several hundred (limited by network switch port count and polling cycle time requirements). The RK3568's quad-core CPU running polling daemons at 10–20% utilization per core handles this workload with headroom to spare for edge processing.
What is the difference between RK3568 and RK3568J for industrial gateway deployments?
The RK3568J is the industrial-grade variant of the RK3568, tested and binned for extended temperature operation (-40°C to +85°C junction temperature vs. 0°C to +70°C for the commercial variant). For gateway deployments in ambient temperatures above 45°C — industrial cabinets, outdoor enclosures, non-climate-controlled facilities — the RK3568J provides the necessary thermal margin. The RK3568J also carries a longer component availability commitment from Rockchip, which is important for gateway products with 5–10 year expected deployment lifetimes.
Can the RK3568 run an OPC UA server and an MQTT broker simultaneously?
Yes. A typical production configuration runs open62541 (OPC UA server, ~30MB RAM), Mosquitto (MQTT broker, ~8MB RAM), Node-RED (edge processing, ~80MB RAM), and the Modbus polling daemon (~10MB RAM) simultaneously. Total application RAM footprint under this stack: approximately 130–150MB. On a 2GB LPDDR4 RK3568 board, this leaves more than 1.8GB for the OS, buffers, and data historian — well within operational margins.
What cellular modem is compatible with the RK3568's PCIe M.2 slot?
M.2 2242 or 3042 form-factor LTE/5G modems with PCIe or USB interface are compatible. Validated options include the Quectel EC25 (LTE Cat 4), Quectel RM500Q (5G Sub-6GHz), and SIMCom SIM7600. These modules enumerate as WWAN network interfaces via the qmi-wwan или mbim Linux drivers, which are included in the RK3568 BSP. Confirm your carrier board's M.2 key type (M-key for PCIe, B-key for USB) before modem selection.
How does the RK3568 compare to Raspberry Pi CM4 for industrial IoT gateway applications?
The Raspberry Pi CM4 is a viable development platform but has documented limitations for industrial gateway production: no native CAN bus (requires USB-CAN adapter), single Gigabit Ethernet MAC (dual-NIC topology requires USB Ethernet), consumer-grade operating temperature (-20°C to +85°C PCB ambient vs. RK3568J's -40°C to +85°C junction), and no industrial-grade supply longevity commitment. For prototyping and low-volume (<50 units) pilots, CM4 is acceptable. For production IoT gateway programs at 100+ units requiring 5+ year field life in industrial environments, the RK3568J is the correct choice.
What is the typical power consumption of an RK3568 IoT gateway under full load?
Under full gateway workload (4 cores active, dual GbE active, LTE modem transmitting, NPU inference at 50% duty cycle), the RK3568 SoC consumes approximately 3.5–5W. Total system power including the carrier board, LTE modem, and SATA SSD typically falls between 8W and 12W depending on modem transmit power and SSD activity. This allows design of a gateway system with a standard 12V/1A or 24V/500mA industrial power supply — the DIN-rail standard input voltage range — with comfortable margin.
Sources & References
- IoT Gateway Devices Market Size & Share 2026–2035 — Global Market Insights
- Edge Computing with Modbus to MQTT Gateway: A Deep Dive — Hashstudioz
- IoT Gateway Architecture: Edge vs. Cloud, Protocol Translation, and Deployment Patterns — Wevolver
- Modbus Protocol — Wikipedia
- open62541 — Open Source OPC UA Stack — GitHub
- Industrial IoT Gateway Market Growth Analysis 2026–2030 — Technavio