The physical layer makes certain demands on the data link layer. Besides half-duplex asynchronous serial transmission with data rates between 300 and 9600 Baud, these include the requirement that at least every eleventh bit should be a logical 1, and also that there should be a Master-Slave structure, since the slaves can not communicate with each other.

The protocol of the data link layer is based on the international standard IEC 870-5, which defines the transmission protocols for telecontrol equipment and systems. The M-Bus protocol described below derives from the above standard, but doesn’t use all the IEC functions.

The signal quality requirements for master and slaves are listed in the document ‘WG4N86R2.DOC’ § (available in the mailbox and via internet). It is based on the international standard IEC 7480.

5.1 Transmission Parameters

This protocol uses asynchronous serial bit transmission, in which the synchronization is implemented with start and stop bits for each character. There must be no pauses within a telegram, not even after a stop bit. Since quiescence on the line corresponds to a 1 (Mark), the start bit must be a Space, and the stop bit a Mark. In between the eight data bits and the even parity bit are transmitted, ensuring that at least every eleventh bit is a Mark. The bits of data are transmitted in ascending order, i.e. the bit with the lowest value (LSB = least significant bit) is the first one to be found on the line. The transmission takes place in half duplex and with a data rate of at least 300 Baud. In Figure 12, the transmission of a byte in calling and replying direction is represented.

Fig. 12 Transmission of a Character in Calling and Replying Direction

5.2 Telegram Format

According to IEC 870-5, three different data integrity classes (I1, I2 and I3) are envisaged for the transmission of remote control data. The data integrity class is a measure of the quotient between the rate of undetected false messages and the probability of faulty bits during transmission. For the data integrity classes mentioned above, various format classes have been identified, in which measures to recognize transmission faults are defined. For the M-Bus protocol of the data link layer the format class FT 1.2 is used, which is contained in the data integrity class I2, which specifies a Hamming Distance of four.

The format class FT 1.2 specifies three different telegram formats, which can be recognized by means of special start characters. Below, and in figure 13, the telegram formats used for the M-Bus will now be explained.

Single Character	Short Frame	Control Frame	Long Frame
E5h	Start 10h	Start 68h	Start 68h
	C Field	L Field = 3	L Field
	A Field	L Field = 3	L Field
	Check Sum	Start 68h	Start 68h
	Stop 16h	C Field	C Field
		A Field	A Field
		CI Field	CI Field
		Check Sum	User Data
		Stop 16h	(0-252 Byte)
			Check Sum
			Stop 16h

Fig. 13 Telegram Formats of the M-Bus Protocol

• Single Character

  This format consists of a single character, namely the E5h (decimal 229), and serves to acknowledge receipt of transmissions.

• Short Frame

  This format with a fixed length begins with the start character 10h, and besides the C and A fields includes the check sum (this is made up from the two last mentioned characters), and the stop character 16h.

• Long Frame

  With the long frame, after the start character 68h, the length field (L field) is first transmitted twice, followed by the start character once again. After this, there follow the function field (C field), the address field (A field) and the control information field (CI field). The L field gives the quantity of the user data inputs plus 3 (for C,A,CI). After the user data inputs, the check sum is transmitted, which is built up over the same area as the length field, and in conclusion the stop character 16h is transmitted.

• Control Frame

  The control sentence conforms to the long sentence without user data, with an L field from the contents of 3. The check sum is calculated at this point from the fields C, A and CI.

5.3 Meaning of the Fields

In this section, the fields used for telegram formats will be explained. These all have a length of 1 Byte, corresponding to 8 bits.

C Field (Control Field, Function Field)

Besides labeling the functions and the actions caused by them, the function field specifies the direction of data flow, and is responsible for various additional tasks in both the calling and replying directions. Figure 14 shows the coding of the individual bits of the C field:

Bit Number	7	6	5	4	3	2	1	0
Calling Direction	0	1	FCB	FCV	F3	F2	F1	F0
Reply Direction	0	0	ACD	DFC	F3	F2	F1	F0

Fig. 14 Coding of the Control Field

The highest value (most significant) bit is reserved for future functions, and at present is allocated the value 0; bit number 6 is used to specify the direction of data flow. The frame count bit FCB indicates successful transmission procedures (i.e. those that have been replied to or acknowledged - see 5.4), in order to avoid transmission loss or multiplication. If the expected reply is missing or reception is faulty, the master sends again the same telegram with an identical FCB, and the slave replies with the same telegram as previously. The master indicates with a 1 in the FCV bit (frame count bit valid), that the FCB is used. When the FCV contains a “0”, the slave should ignore the FCB. For more about the FCB see chapter 5.5.

In the replying direction, both these bits can undertake other tasks. The DFC (data flow control) serves to control the flow of data, in that the slave with a DFC=1 indicates that it can accept no further data. With an ACD bit (access demand) with a value of 1, the slave shows that it wants to transmit Class 1 data. The master should then send it a command to request Class 1 data. Such Class 1 data is of higher priority, which (in contrast to Class 2 data) should be transmitted as soon as possible. The support of Class 1 data and the bits DFC and ADC is not required by the standard.

The bits 0 to 3 of the control field code the true function or action of the message. Table 1 shows the function codes used in the calling and the replying directions. The functions shown in this table will be explained in more detail in the next section. All additional function codes defined in IEC 870-5-2 can also be used.

Name	C Field Binary	C Field Hex.	Telegram	Description
SND_NKE	0100 0000	40	Short Frame	Initialization of Slave
SND_UD	01F1 0011	53/73	Long/Control Frame	Send User Data to Slave
REQ_UD2	01F1 1011	5B/7B	Short Frame	Request for Class 2 Data
REQ_UD1	01F1 1010	5A/7A	Short Frame	Request for Class1 Data (see 8.1: Alarm Protocol)
RSP_UD	00AD 1000	08/18/28/38	Long/Control Frame	Data Transfer from Slave to Master after Request

Table 1 Control Codes of the M-Bus Protocol (F : FCB-Bit, A : ACD-Bit, D : DFC-Bit)

A Field (Address Field)

The address field serves to address the recipient in the calling direction, and to identify the sender of information in the receiving direction. The size of this field is one Byte, and can therefore take values from 0 to 255. The addresses 1 to 250 can be allocated to the individual slaves, up to a maximum of 250. Unconfigured slaves are given the address 0 at manufacture, and as a rule are allocated one of these addresses when connected to the M-Bus. The addresses 254 (FEh) and 255 (FFh) are used to transmit information to all participants (Broadcast). With address 255 none of the slaves reply, and with address 254 all slaves reply with their own addresses. The latter case naturally results in collisions when two or more slaves are connected, and should only be used for test purposes. The address 253 (FDh) indicates that the adressing has been performed in the Network Layer (see chapter 7) instead of Data Link Layer. The remaining addresses 251 and 252 have been kept for future applications.

CI Field (control information field)

The control information field is already a part of the Application Layer, and is described in more detail in section 6.1. It was included in the telegram format used, in order to distinguish between the formats of the long and the control frames. The control information allows the implementation of a variety of actions in the master or the slaves.

Check Sum

The Check Sum serves to recognize transmission and synchronization faults, and is configured from specific parts of the telegram. These parts are mentioned when presenting the individual telegram formats in 5.2. The Check Sum is calculated from the arithmetical sum of the data mentioned above, without taking carry digits into account.

5.4 Communication Process

The Data Link Layer uses two kinds of transmission services:

• Send/Confirm : SND/CON
• Request/Respond : REQ/RSP

§ After the reception off a valid telegram the slave has to wait between 11 bit times and (330 bit times + 50ms) before answering (see also EN1434-3).

Send/Confirm Procedures

• SND_NKE → Single control character

  This procedure serves to start up after the interruption or beginning of communication. The value of the frame count bit FCB is adjusted in master and slave, i.e. the first master telegram with FCV=1 after SND_NKE contains a FCB=1. The slave responds to a correctly received SND_NKE with an acknowledgment consisting of a single character (E5h).

• SND_UD → Single control character

  With this procedure the master transfers user data to the slave. The slave can either confirm the correct receipt of data with a single character acknowledge (“$E5”), or by omitting a confirmation signal that it did not receive the telegram correctly.

Request/Respond Procedures

• REQ_UD2 → RSP_UD

  The master requests data from the slave according to Class 2. The slave can either transfer its data with RSP_UD, or give no response indicating that the REQ_UD2 telegram has not been received correctly or that the address contained in the REQ_UD2 telegram does not match.

Minimum Communication

According to the European standard EN1434-3, as a minimum for communication the procedures REQ_UD2 / RSP_UD and § SND_NKE / $E5 are needed. All other functions are optional.

Transmission Procedures in case of faults

A fault in a received telegram can be detected by the receiver (master or slave), by checking the following points:

• Start /Parity /Stop bits per character
• Start /Check Sum /Stop characters per telegram format
• the second Start character, the parity of the two field lengths, and the number of additional characters received (= L Field + 6) with a long or control frame

When a fault has been detected as a result of the above checks, the transmission will not be accepted, and the reply or acknowledgement will not be sent.

After a time limit of (330 bit periods + 50 ms) the master interprets the lack of a reply as a fault and repeats the same telegram up to two times. If a valid telegram has not been received at that time a so called “idle time” of at least 33 bit periods is introduced. When slaves send faulty or corrupt replies, three attempts are also made, and if there is a fault during the last attempt then the 33 bit periods “idle time” is introduced.

The master may try a SND_NKE. If this fails also it will continue with the next slave address.

5.5 FCB- and FCV-Bits and Addressing

(§ whole chapter reworked)

The FCB (Frame Count-Bit) in the REQ_UD2 can be considered as the LSB of a telegram counter of transmitted telegrams in the slave to master direction. On the other hand, the FCB in the SND_UD can be considered as the LSB of a (separate) telegram counter for the transmitted telegrams in the master to slave direction. A set FCV (Frame Count Valid)-Bit signals whether this frame count mechanism is active.

5.5.1 Applications of the FCB-mechanism

1.) Multi-telegram answers (RSP_UD) from slave to master

If a total answer sequence from a slave will not fit into a single RSP_UD (respond user data) telegram from the slave to the master, the master signals by a toggled FCB-Bit together with a set FCV-Bit in the next REQ_UD (Request user data) telegram that its link layer has properly received the last RSP_UD-telegram from the slave. The slave answers to a REQ_UD-request with toggled FCB-Bit with a set FCV-bit from the master with a RSP_UD containing the next link layer telegram section of a multi-telegram answer, otherwise it will repeat the last telegram. Note that a slave with a single RSP_UD-telegram may simply ignore the FCB in the REQ_UD2-telegram and send always the same (single) telegram. Note also that a slave with exactly two (sequential) RSP_UD-answer telegrams may simply use the FCB of the REQ_UD2 to decide which of both telegrams should be transmitted. Thus a slave with one or two (sequential) RSP_UD answer-telegrams does not require an internal “Last-REQ_UD2-FCB”-image bit. A slave with three or more (sequential) RSP_UD answer telegrams requires such an internal memory bit. Note that such an internal memory bit for the RSP_UD-direction must be independent of an possible additional internal memory bit for the SND_UD direction (see master to slave section).

2.) Frozen answer telegrams from slave to master

In same instances a slave will freeze the data of its last RSP_UD answer telegram into an additional temporary storage and will repeat these previously frozen RSP_UD answer, if the FCB has not been toggled. After the reception of a toggled FCB-Bit with a set FCV-Bit or after the reception of a REQ_UD2 with the FCV-Bit cleared, the slave will generate a next answer telegram reflecting the current state of all its data instead of repeating the data values frozen at the first REQ_UD2 attempt with toggled FCB. In meter applications this frozen-telegram aproach will result in possibly very old meter data if the last REQ_UD2 with toggled FCB-bit occured a long time ago. Thus for meter readout this frozen telegram technique is not recommended.

3.) Multi-telegram data (SND_UD) from master to slave

If the master sends a large (sequential) data block to a slave (e.g. RAM/EEPROM-initialize, code upload) which must be divided into multiple telegrams a similar situation like in the slave to master direction might occur. If the slave receives a telegram correctly and answers with a positive acknowledge (usually by a $E5 single byte answer) but the master does not receive this positive answer correctly, the master will repeat the last telegram with the identical FCB-Bit as in the first attempt. From this the slave can recognize that this next telegram does not contain the next data block but repeats the last data block which has been received correctly. So the slave may either ignore this telegram repetition completely or may accept it thus overwriting the last telegrams data with the second identical data. In both cases an internal telegram sequence counter is not incremented. Note that a slave which will accept only single telegram master to slave communication may simply ignore the FCB in the SND_UD. Note also that a master which can accept exactly two (sequential) SND_UD-telegrams may simply use the FCB of the SND_UD to decide which of both telegrams has been sent. Thus a slave which can accept one or two (sequential) SND_UD answer-telegrams does not require an internal “Last-SND_UD-FCB”-image bit. A slave which can accept three or more (sequential) SND_UD telegrams requires such an internal memory bit. Note that such an internal memory bit for the SND_UD-direction must be independent of an possible additional internal memory bit for the RSP_UD direction.

4.) Incremental actions in slave initiated by master

If single telegram SND_UD will initiate some incremental action in a slave (like toggling a relais or counting something) in contrast to sending some “absolute” data or parameters the FCB-mechanism allows as in the multi-telegram SND_UD situation a distinction between a repetition of the last telegram due to missed acklowledge reception and the next action. In this case the action is only taken if the FCB of the current SND_UD-telegram is different from the FCB in the previous SND_UD-telegram.

5.5.2 Implementation aspects for primary addressing

1.) Master

The master must always contain a “Next REQ_UD2-FCB-image bit” and also a “Next SND_UD-FCB image bit” for each primary slave address used by its application layer. After sending a SND_NKE-request to a slave adress both these “Next FCB-image bit” associated with this address contained in the request must be set. Thus for each primary address the first REQ_UD2 or SND_UD telegram after a SND_NKE contains a set FCB-Bit. Note that after a memory loss (usually due to a power failure) of these “Next FCB-image bits” the master is required to send a SND_NKE to all affected addresses. All subsequent RSP_UD2-telegrams must contain the “Next REQ_UD2- FCB-image bit” of the appropriate primary address as a FCB. This “Next REQ_UD2 FCB-image bit” is toggeled after an error free link layer RSP_UD telegram has been received. All subsequent SND_UD-telegrams must contain the “Next SND_UD- FCB-image bit of the appropriate primary address as a FCB. If a SND_UD has been successfully transmitted to a slave (reception of a valid acknowledge byte $E5 or a valid RSP_ACK telegram) this “Next SND_UD-FCB-image bit” associated with this address is toggled.

2.) Slave

If a slave wants to utilize the FCB-Bit mechanism for the REQ_UD2-type (slave to master) transfers for more than two sequential telegrams it must provide a “Last REQ_UD2-FCB”-memory bit. If a valid REQ_UD2 telegram with a set FCV-Bit is received its FCB-Bit is compared to this “Last REQ_UD2-FCB-Bit”. If they differ or the FCV-bit is clear, the next actual telegram data are used for the RSP_UD answer otherwise the last (stored) telegram is repeated.

If a slave wants to utilize the FCB-Bit mechanism for the SND_UD-type (master to slave) transfers for more than two sequential telegrams it must provide a “Last SND_UD-FCB”-memory bit. If a valid SND_UD telegram with a set FCV-Bit is received, its FCB-Bit is compared to this “Last SND_UD-FCB-memory Bit”. If they differ or the FCV-bit is clear, the next actual telegram data are used for the RSP_UD answer otherwise the last (stored) telegram is repeated.

Note that after a valid reception of a SND_NKE to the primary address of the device or to the test adress 254 ($FE) or the broadcast adress 255 ($255) these internal “Last FCB” memory bits must be cleared.

3.) Implementation for multiple address slaves

A slave might be configured to respond to more than one primary address. This could be useful for slaves which internally consist of more than one independent functional blocks. If this slave wants to utilize FCB-funcionalities they must implement the appropriate number of internal memory bits (0, 1 or 2) for each of these adresses.

4.) Implementation for the primary (broadcast) address 255

All transfers to the primary broadcast address 255 ($FF) are not answered and should hence be implemented by the master with the FCV-Bit cleared. Note that a SND_NKE to primary address 255 will clear the internal “Last received FCB”-Bits of all slaves with primary addresses 0-250 and with FCB-Bit implementation simultaneously.

5.) Implementation for the primary (test) address 254 ($FE)

A slave should answer to all requests to the primary address 254 ($FE=test address) irrespective of its own primary address. The answer must contain its own primary address and not the address 254 ($FE). This test address is used by readout- or test equipment in point-to-point mode. Although this is a second primary address for each slave separate “Last received FCB”- Bit(s) are not required for this special case, since any test equipment or master is required to issue a SND_NKE after each reconnect or power fail thus clearing the “Last received FCB”-Bit(s) and thus preparing for a virgin transaction irrespective of the previous communication history.

6.) Implementation for secondary addressing

For the usage of the FCB-Bit in secondary addressing see chapter 7.2.