Definition
DTU (Data Transfer Unit) transmits serial (RS232/RS485) data to the cloud via 4G LTE Cat.1/Cat.4 or NB-IoT networks transparently, supporting TCP/UDP/MQTT/HTTP. It is suitable for remotely networking dispersed devices such as charging stations, vending machines, meters, and PLCs, providing plug-and-play functionality.
Technical Features
DTUs usually provide 1–4 serial ports, supporting RS485, RS232, with configurable baud rates. Operating modes include transparent transmission (serial data forwarded as-is) and protocol parsing (e.g., Modbus to MQTT reporting). They support multiple master connections, automatic reconnection, and heartbeat keep-alive. Configuration methods include AT commands, local configuration tools, and remote configuration platforms. Power supply is commonly 9–36V DC; industrial versions may use 12–24V and support wide temperature ranges and IP protection.
Difference from RTU
RTUs have local I/O collection, logic control, and protocol conversion capabilities in addition to remote communication, commonly used in DCS, SCADA sites; DTUs focus on data transparent transmission and have simpler functionality. RTUs are suitable for complex sites and multi-protocol collection; DTUs are suitable for quickly networking existing serial devices. The boundary between the two is blurred, and some products combine DTU transparent transmission with RTU collection capabilities.
Use Cases
Charging stations: connect via serial port to BMS or charging controller, reporting data to the operation platform; vending machines: connect to the main control board to achieve remote monitoring and restocking alerts; smart meters: connect to Modbus meters, replacing wired meter reading; industrial equipment: PLCs, inverters, and instruments access the cloud platform via DTU; environmental monitoring: sensors collect data via serial port and report wirelessly. When selecting, consider the number of serial ports, communication protocol, power consumption, and environmental suitability.
Transparent byte streams and frame boundaries
A data transfer unit's job is to move bytes from the serial port into a network connection. It does not understand a frame header or a checksum unless protocol parsing is turned on separately. In transparent mode, the serial idle time and the network packet length decide how many pieces one frame is cut into. A master that parses on the assumption that one read is one complete frame treats a half frame as a checksum failure, and the next half does not line up with the start character. The packing time should be shorter than the gap between application frames, and not so short that one byte becomes one packet. On a multi-port model, baud rate, parity, and packing time are independent on each port. Configuring only the first port is not enough.
The condition is that the far end has a receive buffer ready, and that both sides agree who opens the connection. A device acting as a client needs the master address, the port, and a registration packet so the master can recognize the terminal. A device acting as a server needs an address that can be reached. After the address changes, a master that still connects to the old address fails indefinitely. A heartbeat only proves the network connection is still up. It does not prove the serial device downstream answered. When that instrument loses power, the network heartbeat still succeeds. For a query-response protocol, the master should send one query, wait for the reply or the timeout, and then send the next. Do not write several queries into the transparent channel at once.
Heartbeat, reconnect, and serial settings
If reconnect has no back-off, a base station that is unstable makes the terminal dial continuously, fills the master log with registration packets, and leaves application frames sandwiched between them. After a reconnect succeeds, a partial frame may still sit on the serial side. Discard a buffer that is short of one frame. Do not glue it to the first packet of the new connection. If parity or stop bits disagree with the instrument, the network is completely healthy and every byte from the serial port is wrong. If flow control is enabled and the other end has no flow-control wire, transmission blocks forever, which looks like a dead module.
The buffer is finite. After a long outage, some modules drop new data and some drop old data. The order of the catch-up after the link returns has to be agreed with the application. Do not assume the catch-up is a continuous history. Lowering the serial rate when the signal is weak does not raise the radio rate. It only stacks local frames in the buffer. A loose antenna connector, a SIM with no data service, and a wrong access-point name all look like a failed registration. Separate an attach failure from a rejection by the master. If a transparent module is treated as a collector that has already parsed the protocol, the platform stores raw bytes as numbers. To report registers, use a mode that parses the protocol, and check register order and byte order.
Registration packets and a leftover half frame
A registration packet lets the master recognize the terminal. It is not an application frame. If reconnects are too frequent, the registration packet lands between the two halves of an application frame, the master parses it as the application protocol, and checksum errors follow one after another. After a reconnect succeeds, drop a serial leftover that is short of one frame, then start new queries. Queries are still one question and one answer. Transparent mode does not queue them for the master.
A successful heartbeat only means the network connection is up. It does not fail when the serial device downstream loses power. A weak signal, a wrong access point, and a rejection by the master can all be logged as a failure to come online. Look at attach and registration as two steps. Whether the offline buffer keeps new data or old data has to be chosen for the application, and after recovery the data has to be ordered by time. When parity is wrong the network is completely healthy and every received byte is unusable. Before raw bytes are stored as numbers, confirm that the module really parsed them. Transparent mode does not do that step.
Set the serial packing time against the gap between characters inside an application frame. If the gap is shorter than a pause inside the frame, one frame is cut into several packets. If it is too long, several frames stick into one packet. However many pieces the master receives, it has to assemble the frame itself. It cannot assume each network packet is the reply to one command. Give registration packets, heartbeat packets, and application packets different headers, and branch on those headers. Do not try to match them all with one start character. After the downstream baud rate changes, change the module and the device together. Changing only the module produces a steady stream of wrong codes, and reconnecting will not repair it. If the first packet after a long offline period is a half frame, drop it. Do not glue it to the front of the next complete frame in the name of not losing data.