Definition
DL/T 645 National standard electricity meter communication protocol, used for data exchange between smart meters and concentrators or meter reading systems, supporting data collection such as electricity consumption, voltage, and current, and is used in conjunction with AMI smart metering.
Protocol Versions and Structure
DL/T 645 includes the 1997 version and the 2007 version, with the latter being more widely used. It uses master-slave half-duplex communication, the physical layer is mostly RS-485, and the frame format includes start character, address, control code, data field, checksum, and end character. Data items use Data Identifier (DI) coding, covering forward active total electricity, reverse active total electricity, voltage, current, power, power factor, demand, etc., and supports read, write, broadcast time synchronization, and other operations.
Role in AMI
Smart meters have built-in DL/T 645 communication interfaces that connect to the meter reading platform via concentrators or directly via NB-IoT/LTE Cat.1 modules. In concentrator mode, multiple meters are connected to the concentrator via RS-485 bus, and the concentrator uploads data through the cellular network; in direct connection mode, individual meters with built-in modules connect directly to the network. The platform parses data according to the DL/T 645 specification, completing billing, tiered electricity pricing, demand management, remote switching on/off, and other functions.
Communication modules required
Electricity meters are mostly installed in environments such as distribution rooms and corridors. The modules need to have industrial-grade features such as wide temperature range, anti-interference, and long lifespan. NB-IoT is suitable for low-frequency meter reading; LTE Cat.1 is suitable for scenarios requiring real-time control or high-frequency collection. The module communicates with the MCU via UART and needs to support transparent transmission or protocol stack to ensure correct packaging and transmission of DL/T 645 data.
Engineering Practice Supplement
Starting from "DL/T 645", common issues on-site often focus on "standards met in the laboratory but difficult to replicate in the field." Besides RF and protocol, power-ground bounce, connector contacts, and firmware race conditions should also be checked. On the cellular side, it is recommended to collect RSRP/SINR, cell reselection, and PDP reconnection records; on the application side, there should be clear strategies for retry, idempotency, and queue persistence. When data security and compliance are involved, write the collection scope, storage locations, retention period, and third-party sharing into privacy and contract attachments to avoid high costs of patching after deployment.
A data identifier and a password right are not the same thing
DL/T 645 means the electricity meter is the slave and the concentrator or reading module is the master. They use a defined frame to read or write energy, voltage, current, demand, and events. The data identifier decides which item is read. The control code and password decide whether that item may be written. The conditions are that both sides use the same generation of the protocol, that the address matches the meter, and that a write has the corresponding right. The 1997 and 2007 identifier systems cannot be mixed. Parsing the wrong version puts the value on the wrong decimal place, and the platform can still draw a curve that looks normal.
The cellular module here is the bearer, not the protocol. A direct meter connection collects a complete frame from the serial port and then wraps it. A concentrator finishes the question on the bus and then uploads the result. If transparent mode sets the timeout shorter than the meter’s response, a slow meter is treated as offline. Record a successful read and a successful write separately. Remote connect and disconnect in particular cannot treat “the message was sent” as “the meter confirmed it.”
Broadcast time sync is drowned by simultaneous replies
A broadcast frame has no single destination. When many meters answer together, a bus collision leaves the concentrator unable to decode anything, and the cellular side only sees a timeout. Time sync needs backoff, or it should be done meter by meter. If the password level is wrong, reads still succeed and writes are rejected. A site that tests only meter reading discovers this at the first remote disconnect. After a meter is replaced, retire the old address and the old password in the records, or the new meter’s data is written to the old account.
Coverage and supply interference in a switch room make the module attach again and again inside the reading window. Put retries inside the window rather than lengthening sleep without limit. Downlink arrival has to be designed together with the meter’s online window; see eDRX. Do not reuse these identifiers for water and gas meter frames.
A successful write reply does not mean the register has updated
Some items show the new value in the current register only after a following read. Looking only at the write reply, the platform shows a new tariff or a new switch position while the meter is still on the old state. An operation that changes a tariff or opens and closes the switch should be followed at once by a read-back. If the read-back does not match the expected value, keep the alarm. Do not mark the task complete. The data identifier used for the read-back must be the same item that was written. Reading a neighboring identifier returns a number that looks legal and is unrelated. If the read-back fails, leave the original task unfinished. Do not close the work order because the write reply succeeded.