DTU Service

DTU service accepts transparent terminals that connect to TGateway as TCP clients. TGateway listens as the TCP server. Each terminal sends its registration ID after connecting; a collection device uses its configured DTU ID to select that registered connection. Multiple terminals can share one listening channel.

Prepare DTU access

Applicable Scenarios

Scenarios	Description
4G/5G DTU Active Internet Access	Terminals located on mobile networks or on-site intranets, Terminals actively connect to TGateway deployed on public or central networks.
Multiple terminals share listening ports	Multiple DTUs connect to the same TCP service channel, with gateways distinguishing connections by DTU ID of each terminal.
Remote Transmission of Serial Port Devices	DTU transmits the serial protocols of PLCs, instruments, or acquisition modules to TCP, while TGateway continues to use collection plugins like Modbus to access field devices.
DDP Protocol Terminal	When the terminal explicitly supports DDP, set the channel's DTU service type to DDP. Regular registered DTUs use "default".

Preparation Before Configuration

Before configuration, confirm the following information with the DTU manufacturer or on-site personnel.

Information	What needs to be confirmed
Connection direction	DTU must be actively connected as a TCP client TGateway.
Service address	gateway IP or domain name accessible by DTU, and TCP ports that are allowed to access it.
Registration Identifier	DTU The terminal number, reporting timing, and encoding method reported after connection is established.
Identifier Format	Identify whether it is plain text or original hexadecimal bytes, and whether it contains prefixes, postscripts, line breaks, or length fields.
DTU Service Type	Select "Default" for the regular terminal; Only select DDP when the terminal protocol is clearly set to DDP.
Transparent Protocol	Protocol, station number, address, data type, byte order, and response timeout used by devices behind the DTU.
Keepalive	Heartbeat content and interval, and whether the terminal expects a server response.
Network Policy	Whether firewalls, port mapping, security groups, and carrier networks allow the DTU to actively connect.

Rapid Test Configuration Generation

TGateway can generate a DTU test configuration for quickly establishing channels, devices, and variable skeleton.

1. Log in to TGateway Web and go to "Development Configuration → Collection Configuration".
2. Click the top right corner of the variable list to select "Show more → test data."
3. Select "DTU Test Data"; it is recommended to first fill in 1 for the number of devices.
4. "Slave Address" should be the address where the local machine or test environment can listen, for example, 127.0.0.1:15020.

5. Click "Generate". The page will create a TCP service tunnel, a Modbus collection device, a 400001 variable, and a supporting test forwarding configuration.
6. Open the automatically generated device "Plugin Properties" and record the dynamically generated DTU ID.
7. Enter the listening address and DTU ID in the real DTU or DTU/Modbus emulator, then start the terminal connection.

Test data will not replace the on-site terminal.

Successful generation only indicates that the configuration has been written. To see channels, devices, and variables online, a real DTU or protocol simulator still needs to actively connect, send a completely consistent DTU ID, and correctly respond to the collection protocol request.

Configure the channel, device and variables

Configure TCP Service Channel

Go to "Development Configuration → Collection Configuration", click "Channel Management → Add"; If you already have a channel, click "Edit".

1. "Channel Name" should be filled in to represent the name of the field link, for example dtu-modbus-service.
2. For "Channel Type," select TcpService.
3. Enable "Enable."
4. "Binding Address" is the TGateway local listening address. 0.0.0.0:15020 means listening for all network cards, 127.0.0.1:15020 only allows local connections.
5. In advanced configuration, check heartbeats, maximum number of connections, client expiration time, DTU service type, and DTU ID Hex.

The advanced settings include a default client expiry of 120000 ms.

Channel Parameters

Configuration Items	Current Default Value	Description
Channel Type	TcpClient	DTU Service must be changed to TcpService, the gateway waits for the terminal to proactively connect.
Binding address	Blank	TCP server required. For production environments, you can specify the network card address or 0.0.0.0: port.
Connection Timeout	3000 ms	Timeout for establishing a connection or executing related connection operations. If the network quality is poor, the size can be increased appropriately.
Cache timeout	500 ms	channel packet and protocol read cache window. Normal scenarios remain by default.
Maximum concurrency	1	Concurrent limit for requests on the same channel. On-site equipment requires strict sequential maintenance to maintain 1.
Heartbeat content	Empty	Filled in according to the DTU protocol. After enabling the right side of Hex, the content is parsed by hexadecimal bytes.
Maximum number of connections	10000	The number of clients the TCP service channel can maintain simultaneously. It should exceed the planned total number of DTUs connected, with room for expansion.
Client expiry	120000 ms	Disconnects clients with no communication during this interval. 0 disables this idle cleanup.
DTU Service Type	Default	Regular Registered DTU uses default mode; Only terminals that clearly support the DDP protocol choose DDP.
DTU ID Hex	Off	Decodes registration bytes as UTF-8 text when off; represents them as a hexadecimal ID when on. The device ID must use the same representation.

How to set client expiration time?

Set client expiry comfortably above the heartbeat interval, typically allowing at least two or three heartbeat periods. The default 120000 ms suits intervals well below 120 seconds. A value of 0 disables idle cleanup; account for the resulting idle connections when sizing the service.

Configure DTU Collection Device

Click "Device Management → New", complete the basic information first, then enter "Plugin Properties".

1. "Device Name" is the unique name of the field device or DTU.
2. Select the protocol used by the field device as Device Plugin. This page uses ModbusMaster.
3. "Associate Channels" select the previously created TcpService channel.
4. Set Execution Interval for the required collection period; 1000 schedules at a nominal interval of 1000 milliseconds. Communication and retries also affect the complete scan time.
5. Open "Plugin Properties" and enter the identifier reported after terminal connection in the DTU ID.
6. Continue checking the Modbus type, default station number, read/write timeout, and data parsing order.

Key Device Parameters

Configuration Items	Description
Device Plug-in	Choose the collection protocol used by real devices behind the DTU, not a universal "DTU plug-in."
Channel Association	Multiple DTUs can associate with the same TCP service channel.
Execution interval	determines the collection request cycle. If your mobile network latency is high, don't set it too low.
DTU ID	Must match the registered terminal identifier, including case, prefixes, suffixes, and the text or Hex representation.
Default station number	slave address for protocols such as Modbus must match the device behind the DTU.
Read and write timeout	The waiting time for a single protocol request to respond should be set together with the mobile network latency settings.

Do not confuse the channel with the device ID settings.

The channel's DTU ID Hex setting determines how registration bytes are represented. The device's DTU ID selects a registered connection. Assign distinct IDs to different DTU terminals and enter the actual terminal ID in each associated collection device; the collection device name is not a registration ID.

Configure variables

Return to the main Collection Configuration workspace and click Add Variable. Verify the link with one to three typical points before importing the complete point list.

Configuration Items	Example	Description
Variable Name	modbus400001	Recommended to correspond to the on-site point table name.
Belonging Device	Current DTU Device	Variable must belong to the device configured with the correct DTU ID.
Variable Address	400001	Fill in according to the address rules of the collection plugin.
Data Type	Int16	must match the actual data in the field register.
Read and write permissions	Read-only	For first-time joint debugging, it is recommended to use read-only points first.

Text and Hex DTU ID

Registration bytes	DTU ID Hex	Device DTU ID	Meaning
Text DTU-001	Off	DTU-001	Match the UTF-8 text identifier.
The same bytes 44 54 55 2D 30 30 31	On	4454552D303031	Match the hexadecimal representation without separators.

Both rows use identical wire bytes: the UTF-8 encoding of DTU-001 is 44 54 55 2D 30 30 31. Hex changes the gateway's ID representation; it does not require the terminal to send the literal characters 4454552D303031. Keep the channel setting and device ID consistent. Hex mode also supports binary identifiers.

Default registration treats the first received content on a new connection as the complete identifier. It does not strip line endings, headers, or checksums. The terminal must send its complete registration content before business traffic. If registration is split across receives or arrives together with the first business message, inspect the actual ID in the new connection log and check the terminal's registration format and send timing. Configure DDP terminals using DDP rather than ordinary text registration.

Verify and deploy

Actual Runtime Verification

After completing configuration, let the DTU actively connect to TGateway and perform acceptance in the following order.

1. The left channel shows "Online," with the number of online devices at 1/1.
2. Devices under the channel show green online status.
3. Variables no longer display "Abnormal"; current and original values can be refreshed normally.
4. Collection times are continuously updated, and the reading results are consistent with field equipment, PLC software, or simulators.

The screenshot shows where to check online state, current value, original value, and collection time. In a real project, use the field DTU ID, variable address, and device response values.

Passed Standard

Check	Acceptance criterion
TCP	channel is activated, and the port is in listening mode.
DTU registration	The registered connection appears and logs confirm the expected DTU ID.
Device Status	Devices using this DTU ID are displayed online.
Variable Quality	No abnormal markers for variables; current, original, and collection times update normally.
Numerical Accuracy	Reading results match the settings of field instruments, PLC software, or simulators.
Disconnected Recovery	After disconnecting and reconnecting the DTU, the device can resume online and continue data collection.

Production Deployment Recommendations

Project	Recommendations
Listening addresses	Only listening for network cards and ports required by the business; When using 0.0.0.0, it works with firewalls to limit sources.
Public Network Access	Confirm public IP addresses, port mappings, security groups, and operator network policies; do not directly expose unprotected management ports.
DTU ID	assigns a unique identifier to each terminal, and upon delivery, the DTU ID, device name, and site location are compiled into a corresponding table.
Heartbeat and Expiration	The heartbeat cycle must be less than the client's expiration time, with reserved time for network jitter and retransmission.
Maximum Number of Connections	Set according to the official number of terminals and expansion plans, avoiding connections that are too small and not expanding without boundaries.
Log-level	Debugging can temporarily use Debug or Traceto restore Info after stabilization.
TLS	Enable SSL and configure certificates when the DTU supports TLS; When not supported, use private networks, VPNs, firewalls, and source restriction protection links.
Write access	Verify reads first. Before enabling RPC writes, check field interlocks and permissions, then verify a write with an independent field readback.

Troubleshooting

Phenomenon	Key Inspection
Channel Fails to Start	Check whether the bound address belongs to the local machine, whether the port is occupied, whether the listening port has permissions, and whether the firewall policy is correct.
Channel shows 0/N	Confirm that the DTU connects to the correct IP/port and sends its registration content.
Log prompts Client (DTU) not connected	The DTU ID in the device does not match the terminal registration identifier, or the terminal has not yet completed registration. Focus on checking text/Hex, case sensitivity, prefixes, and spaces.
Channel online but device offline	There may be a client connection but no valid connection matching the device's DTU ID, or protocol requests may keep timed out.
Device online but variable anomalies	Checkstation number, variable address, data type, Modbus type, byte order, and read/write timeout.
Periodic disconnections	Check client expiry, heartbeat interval, and heartbeat content. Leave a margin between the heartbeat interval and expiry.
Default mode cannot register	Confirm whether the terminal actually uses DDP; Service types are only switched when the protocol is explicitly DDP.
Multiple DTUs are swapped out	Check if the same DTU ID is being used repeatedly. Each terminal must use a unique identifier.
After reconnection, still use the old connection	Check whether the terminal sends the full DTU ID immediately after the new connection is established, and confirm the new connection is registered through the channel log.

Related Documentation

• Collection Configuration - Complete Operation Instructions for Channels, Devices, and Variables
• Plugin Manual Index - Protocol read/write and log debugging for the selected plugin
• Data Forwarding - Forwarding the collected data to the external system