M-Bus Frame Decoder
Use this M-Bus Frame Decoder to analyze wired M-Bus telegrams, automatically identify single-character, short, control and long frames, verify length and checksum fields, decode C/A/CI values and inspect meter response data.
Variable Data Response Header
-
-
What Is an M-Bus Frame Decoder?
An M-Bus Frame Decoder interprets telegrams used by wired Meter-Bus systems. M-Bus is widely used for automated reading of utility meters such as heat, water, gas and energy meters.
At the data-link layer, a captured byte stream can represent a single acknowledgment character, a short request, a control telegram or a long telegram containing application data.
This decoder identifies the telegram structure automatically and checks the important structural fields before attempting to describe the message.
M-Bus Telegram Formats
| Telegram | Start | Primary Fields | Stop |
|---|---|---|---|
| Single Character | E5 | Acknowledgment only | — |
| Short Frame | 10 | C, A, Checksum | 16 |
| Control Frame | 68 | L=3, C, A, CI, Checksum | 16 |
| Long Frame | 68 | L, C, A, CI, User Data, Checksum | 16 |
M-Bus Short Frame Format
A short frame has a fixed five-byte structure:
The short-frame checksum is the eight-bit arithmetic sum of the C and A fields.
M-Bus Short Frame Checksum Example
M-Bus Long Frame Format
A long frame starts with hexadecimal 68 and contains two identical length fields followed by another 68 start character.
The length field includes the C, A and CI bytes plus the number of user-data bytes.
A frame with no application user data therefore has L=3 and is commonly described as a control frame.
M-Bus Long Frame Length Formula
Both copies of the L field must agree, and the actual number of bytes between the second start character and checksum must match that value.
M-Bus Long Frame Checksum
The long-frame checksum is an eight-bit arithmetic sum beginning with the Control field and ending with the final user-data byte.
The initial 68 and length bytes, checksum itself and final 16 stop byte are not included in that sum.
M-Bus Single Character E5
Hexadecimal E5 is the single-character acknowledgment used in
M-Bus communication.
Because it consists of only one byte, it does not contain a C field, address, CI field or checksum.
M-Bus Control Field
The C field describes the data-link action and also carries communication control bits. Several common master and slave telegram values are frequently seen during M-Bus captures.
| C Field | Name | Typical Purpose |
|---|---|---|
| 40 | SND_NKE | Initialize slave |
| 53 / 73 | SND_UD | Send user data to slave |
| 5A / 7A | REQ_UD1 | Request Class 1 data |
| 5B / 7B | REQ_UD2 | Request Class 2 data |
| 08 / 18 / 28 / 38 | RSP_UD | Data response from slave |
Example: Decode REQ_UD2
This is a valid short-frame request for Class 2 data addressed to primary address 1.
What Is the M-Bus Address Field?
The A field contains the data-link address used by the telegram. The meaning of specific address values can depend on the addressing operation and system configuration.
The decoder therefore shows both hexadecimal and decimal forms rather than silently making assumptions about the connected meter network.
What Is the M-Bus CI Field?
CI means Control Information. In a long or control telegram, this field connects the data-link telegram to the application-layer data format or action.
Some common response values include:
| CI | Meaning |
|---|---|
| 70 | General application error |
| 71 | Alarm status |
| 72 / 76 | Variable data response |
| 73 / 77 | Fixed data response |
M-Bus Variable Data Response Header
A variable-data response using CI 72 or 76 normally begins its application data with a 12-byte fixed data header.
When enough bytes are available, this calculator separates those fields before showing the remaining DIF/VIF records as application-record bytes.
M-Bus Identification Number
The meter identification number in the common variable-data header uses packed BCD representation.
The byte order and BCD representation are why reading the four bytes as an ordinary hexadecimal integer would produce the wrong identification number.
M-Bus Manufacturer Code
The two-byte manufacturer identifier packs three manufacturer letters into a 15-bit code. Each five-bit letter value corresponds to an uppercase alphabet position.
This decoder converts a valid manufacturer field into its three-letter form and also shows the raw hexadecimal manufacturer code.
M-Bus Medium Field
The medium byte describes the meter or measured medium in the variable-data header. Values can identify applications such as electricity, gas, heat, steam or water depending on the defined coding.
The decoder exposes the raw medium byte and recognizes several commonly encountered standard values while retaining the hexadecimal value for unrecognized codes.
Variable Data Records and DIF/VIF
After the fixed variable-data header, meter measurements are commonly represented by records using Data Information Fields and Value Information Fields.
DIF
Describes data coding, field length and related record information.
VIF
Describes the physical value, unit and scaling information for the associated record.
Because DIF/VIF decoding can involve extensions, storage numbers, tariffs, subunits and manufacturer-specific data, this page deliberately focuses on robust frame validation and header decoding instead of guessing unsupported record semantics.
M-Bus Checksum Mismatch
If the calculated checksum differs from the received checksum, the tool marks the frame invalid.
Common causes include a missing captured byte, an extra byte, copying only part of a long frame, corrupted serial data or accidentally interpreting decimal numbers as hexadecimal.
M-Bus Length Mismatch
Long M-Bus frames carry the same length byte twice. Both values must match. The decoder also compares the declared length with the actual frame length.
M-Bus vs Modbus
M-Bus and Modbus are different protocols despite their similar names.
M-Bus
Meter-oriented communication protocol commonly associated with utility metering and EN 13757 systems.
Modbus
Industrial client/server protocol using function codes, registers, coils and RTU, ASCII or TCP transports.
Their frame formats and checksum algorithms are different and should not be interchanged.
Common M-Bus Frame Decoder Mistakes
Including Start Byte in Checksum
The M-Bus checksum begins at the C field, not the start character.
Counting L Incorrectly
The long-frame L value includes C, A and CI plus application user data.
Ignoring Duplicate Length
The two long-frame L bytes should contain the same value.
Missing Stop 16
Short, control and long telegrams end with hexadecimal 16.
Reading BCD as Binary Integer
Fields such as meter identification can use packed BCD representation.
Confusing M-Bus With Modbus
Their telegram structures and error-checking algorithms are unrelated.
M-Bus Frame Decoder FAQs
What is an M-Bus frame?
What does E5 mean in M-Bus?
What starts an M-Bus short frame?
What starts an M-Bus long frame?
What ends an M-Bus frame?
How is an M-Bus short-frame checksum calculated?
How is an M-Bus long-frame checksum calculated?
Is the 68 start byte included in the checksum?
What does the M-Bus L field mean?
Why does the M-Bus long frame contain L twice?
What does C=5B mean?
What does C=40 mean?
What does CI=72 mean?
What does CI=73 mean?
How many bytes are in the variable-data fixed header?
Can this decoder read the meter manufacturer?
Does this decode every DIF/VIF meter record?
Is M-Bus the same as Modbus?
Decode and Validate Wired M-Bus Telegrams
Paste raw hexadecimal M-Bus bytes to identify the telegram format, verify length and checksum fields, inspect C/A/CI values and decode common variable-data meter response headers.