M-BUS Wired Telegram Analyzer

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.

✓ Short Frame ✓ Long Frame ✓ Checksum Validator ✓ C / A / CI Decoder ✓ Meter Header Decode
68
Decode Wired M-Bus Telegram
● Ready
Enter hexadecimal bytes separated by spaces, commas or hyphens. Continuous hexadecimal input and 0x prefixes are also accepted.
Decoder scope: The tool validates the M-Bus data-link frame itself and provides a basic application-header interpretation for common variable-data responses. Manufacturer-specific payloads and arbitrary DIF/VIF record semantics are left as raw user-data bytes rather than guessed.
M-Bus Frame Result Valid
Detected Telegram
Frame Type
Control Field
Address Field
CI Field
Length Field
User Data
Checksum
Total Bytes

Variable Data Response Header

Identification
Manufacturer
Version
Medium
Access Number
Status
Signature
Remaining Records
Frame Breakdown -
Normalized Frame
-

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:

10 C A CS 16 where: 10 = Start C = Control Field A = Address Field CS = Checksum 16 = Stop

The short-frame checksum is the eight-bit arithmetic sum of the C and A fields.

M-Bus Short Frame Checksum Example

Frame: 10 5B 01 5C 16 Checksum calculation: 0x5B + 0x01 = 0x5C Received checksum: 0x5C Therefore the checksum is valid.

M-Bus Long Frame Format

A long frame starts with hexadecimal 68 and contains two identical length fields followed by another 68 start character.

68 L L 68 C A CI DATA… CS 16

The length field includes the C, A and CI bytes plus the number of user-data bytes.

L = 3 + User Data Length

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

If: User Data = 12 bytes then: L = C + A + CI + Data = 3 + 12 = 15 = 0x0F

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.

For: 68 L L 68 C A CI DATA… CS 16 calculate: CS = (C + A + CI + every DATA byte) mod 256

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.

E5

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

Frame: 10 5B 01 5C 16 Fields: Start = 10 C = 5B = REQ_UD2 Address = 01 Checksum = 5C Stop = 16 Checksum: 0x5B + 0x01 = 0x5C

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.

Identification Number 4 bytes Manufacturer 2 bytes Version 1 byte Medium 1 byte Access Number 1 byte Status 1 byte Signature 2 bytes ——————————– Total 12 bytes

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.

Bytes: 78 56 34 12 Decode as: 12345678

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.

A checksum match confirms the arithmetic frame check, but it does not prove that every application-layer value is semantically correct for a particular meter.

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.

Expected complete frame length: Total bytes = L + 6 because the surrounding bytes are: 68 L L 68 … CS 16

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?
It is a data-link telegram used to exchange commands and meter data over an M-Bus connection.
What does E5 mean in M-Bus?
Hexadecimal E5 is the single-character acknowledgment telegram.
What starts an M-Bus short frame?
A short frame starts with hexadecimal 10.
What starts an M-Bus long frame?
A long or control frame begins with hexadecimal 68.
What ends an M-Bus frame?
Short, control and long frames use hexadecimal 16 as their stop character.
How is an M-Bus short-frame checksum calculated?
Add the C and A bytes and keep the least-significant eight bits of the sum.
How is an M-Bus long-frame checksum calculated?
Add every byte from the C field through the final user-data byte and retain the least-significant eight bits.
Is the 68 start byte included in the checksum?
No. The start and length bytes are outside the checksum region.
What does the M-Bus L field mean?
It specifies the number of bytes from the C field through the last application user-data byte, including C, A and CI.
Why does the M-Bus long frame contain L twice?
The duplicated length value contributes to frame synchronization and integrity checking. The two copies should agree.
What does C=5B mean?
Hexadecimal 5B is a common REQ_UD2 request for Class 2 data.
What does C=40 mean?
Hexadecimal 40 is SND_NKE, used to initialize a slave’s data-link state.
What does CI=72 mean?
CI 72 indicates a common variable-data response format with least-significant byte first ordering for multibyte application data.
What does CI=73 mean?
CI 73 identifies a fixed-data response format.
How many bytes are in the variable-data fixed header?
The common variable-data response fixed header contains 12 bytes before the variable data records.
Can this decoder read the meter manufacturer?
For common CI 72/76 variable-data responses with a complete fixed header, the tool decodes the two-byte manufacturer identifier into its three-letter code.
Does this decode every DIF/VIF meter record?
No. The tool validates the frame and decodes the standard variable-data fixed header, while leaving arbitrary or manufacturer-specific record bytes visible without inventing unsupported meanings.
Is M-Bus the same as Modbus?
No. They are separate protocols with different message structures and checksum methods.

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.

Scroll to Top